Современный бизнес в большом количестве генерирует новые и новые задачи, а ИТ, в свою очередь, должны обеспечить их решение, причем с максимальной скоростью и минимальными издержками. Бизнес выводит на рынок новые услуги и сервисы, и чем быстрее он это сделает, тем больше вероятность завоевать прочные позиции с перспективой дальнейшего роста. ИТ же обязаны предоставить и развернуть соответствующие приложения, обеспечивающие работу этих сервисов. В этот раз мы расскажем об одном из новейших ИТ-решений для среднего и малого бизнеса – гиперконвергентной инфраструктуре Fujitsu Integrated System Appliance for VMware EVO: RAIL.

Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.

Команда UNMAP стандартизирована в рамках набора команд T10 SCSI и используется для высвобождения пространства из тонких лунов назад хрнилищу данных в SAN окружении. Как я писал ранее, протоколы SAN и NAS понемногу заимствуют друг у друга всё лучшее. Одна из полезных вещей которая появилась достаточно давно, это возможность обратной связи СХД и хоста, для того чтобы «возвращать» удалённые блоки в тонкий лун, чего раньше так не хватало в SAN. Функцией UNMAP по-прежнему мало кто пользуется в SAN окружении, хотя она очень полезна в сочетании как с виртуализированными так и не виртуализированными средами.

Без поддержки команды UNMAP любой тонкий лун созданный на стороне СХД всегда мог только увеличиваться в размере. Его рост был вопросом времени, который безоговорочно всегда заканчивался тем, что такой тонкий лун в конце концов станет занимать свой полный объём, который ему положен, т.е. в конце концов он станет толстым.

Дело было так.

Одна маленькая организация государственных масштабов решила обновить во владении своем местном оборудование серверное. И обратились ее мужи к нашим доблестным менеджерам, мол, хотим мы серверов с дисками для сервисов наших важных. И узнали они от менеджеров о виртуализации заморской, отказоустойчивой да с кластеризацией.

Собственно, долго сказка сказывается, да быстро дело делается.

Так и появилась у организации той связка из двух серверов Fujitsu PRIMERGY RX 200 S8 и системы хранения данных ETERNUS DX 100 S3. И никто на тот момент не думал, что очень скоро ресурсов серверов тех не станет хватать. А наоборот, посчитали и были уверены, что хватит, и надолго. Но быстро машины виртуальные плодится стали и прожорливы они были да тучны. И тогда расширенно было пространство дисковое, а к двум RX 200 подселился брат их юный Fujitsu PRIMERGY RX2530 M1.

О подселении нового сервера в кластер, а также о добавлении в контроллерные блоки новых карт расширения с дополнительными FC-интерфейсами мы и расскажем. А вернее, о простоте, безопасности и удобстве всех этих и других инженерных манипуляций, которые возможны (в нашем случае) с виртуализацией VMware и оборудованием Fujitsu. Те, кто уже имеет СХД и ту или иную реализацию виртуализации серверов (или просто в теме) не удивятся и, наверное, не почерпнут ничего нового из этого текста. Но есть еще много организаций, где какие-либо действия с оборудованием, его перезагрузкой и остановкой вызывают ужас и заставляют скрупулезно планировать и минимизировать предстоящий downtime.