Виртуализация считается чудодейственным средством решения множества ИТ-проблем бизнеса. Она сулит всё сразу: и повышенную готовность приложений, и простое восстановление данных в чрезвычайных ситуациях, и несложную инфраструктуру, и снижение расходов. Более того, серверная виртуализация обещает упростить администрирование ИТ и даже “озеленить” вычисления.

Вот только чтобы эта технология приносила максимальную пользу, ее должны адекватно дополнять другие элементы инфраструктуры, и в первую очередь — система хранения данных. Без этого на успех рассчитывать нечего: приложения начинают ползти, как черепахи, обещанная дешевизна вычислений оборачивается солидными расходами ради достижения полной функциональности, а повышение времени работы приложений и серверов вдруг вскрывает слабые места в других областях ИТ-инфраструктуры. Давайте рассмотрим две самые распространенные ошибки виртуализации.

Ошибка № 1: неправильный выбор платформы хранения

Одно из главных достоинств серверной виртуализации — способность таких систем обслуживать работу гостевых приложений без гипервизора на отдельной машине. Во имя чего бы это ни делалось — будь то планирование работы канала, балансировка нагрузки или восстановление работы в чрезвычайных ситуациях, — одним из главных стимулов перехода на виртуализацию является независимость аппаратных средств. Если же хранилище данных тесно связано с конкретным аппаратным сервером, перемещать приложения становится потруднее, да и не столь уж это целесообразно.

Для хранения данных виртуализированных серверов часто применяются сетевые хранилища NAS. Реализовать их довольно просто, а наращивать можно без гипервизора. Но у них, правда, есть одно очень слабое место — невысокая производительность, из-за которой многие приложения, включая Microsoft Exchange работают с NAS не слишком-то хорошо. С учетом этого большинство производителей виртуализированных систем рекомендуют тем, кто хочет обеспечить достойную скорость работы, использовать в них сети хранения SAN.

Сети хранения Fibre Channel

Когда дело касается сетей хранения Fibre Channel (FC), приходится не только обосновывать высокую цену хранения данных, коммутации и администрирования, но и приобретать дорогие адаптеры хост-шины (HBA) для каждого подключаемого к такой SAN сервера. И это касается даже тех компаний, у которых уже развернута сеть хранения Fibre Channel. Чтобы воспользоваться всеми достоинствами серверной виртуализации, вся инфраструктура FC (включая коммутаторы и адаптеры хост-шины) должна поддерживать технологию виртуализации NPIV (N_Port ID Virtualization), а это исключает применение в ней солидной части приобретенного ранее оборудования.

Но даже в тех случаях, когда NPIV поддерживается, ПО VMware способно перемещать гостей лишь между машинами одной зоны Fibre Channel. Так что хотя пользователи и обретают независимость от аппаратных серверов, все физические серверы группы, между которыми могут передаваться гостевые приложения, вынуждены ограничиваться хранением данных в одной-единственной FC-зоне (а это может быть и один дисковый массив, и даже один-единственный диск). В результате аппаратная независимость с точки зрения серверов рискует вылиться в опасную аппаратную же зависимость многих приложений от системы хранения данных.

Оптимальные хранилища для виртуализированной среды

Для хранения данных в виртуализированной серверной среде лучше всего подходят iSCSI- или IP-сети SAN. Они не только обходятся дешево, но и обеспечивают вполне достаточный уровень готовности, скорости и масштабируемости виртуальной архитектуры. А сеть хранения на базе протокола iSCSI, кроме того, дает немалые преимущества тем компаниям, которые проводят виртуализацию с целью восстановления данных через глобальные вычислительные сети (WAN) в чрезвычайных ситуациях. Когда имеется локальный мгновенный снимок системы, данные в любой момент можно дублировать не только в месте его хранения, но и на расположенном вдали вторичном сайте.

Нельзя также не отметить, что система хранения на базе iSCSI SAN может использоваться в глобальных вычислительных сетях, чем выгодно отличается от сетей хранения на базе Fibre Channel. Последние для репликации данных через глобальную сеть требуют приобретения дорогостоящих шлюзов FCIP (Fibre Channel over IP), тогда как в iSCSI SAN развертывать и сопровождать никаких дополнительных систем не нужно, не говоря уже об управлении ими. Ведь iSCSI представляет собой протокол семейства TCP/IP, которое разрабатывалось специально для глобальных вычислительных сетей. И еще одно: при репликации данных через WAN в обоих типах хранилищ — FC и iSCSI — скорость передачи данных может уменьшаться из-за увеличения дальности передачи или потери пакетов. Но при использовании технологии iSCSI SAN с этим явлением можно бороться посредством оптимизаторов WAN или TCP/IP, которые практически не оказывают влияния на шлюзы FCIP.

Ошибка № 2: дилемма переподписки

Как бы ни хороша была сеть хранения данных, приложения после перевода в виртуализированную среду иногда начинают ползти черепахой. Если аппаратный сервер сконфигурирован правильно, администратор в недоумении начинает искать истинную причину торможения. А она нередко бывает связана с хранением данных.

Эффективное использование инфраструктуры при виртуализации зачастую достигается за счет того, что гипервизоры специально распределяют между приложениями гораздо больше вычислительных ресурсов, чем имеется в физической системе. Так как по статистике весьма маловероятно, что наличные ресурсы одновременно потребуются всем виртуальным гостевым приложениям сразу, то каждому из них выделяются квоты, близкие к оптимальным, что ведет к так называемой переподписке. При разумной реализации этот подход на практике вполне оправдывается. Однако такой же принцип уже используется в большинстве SAN и их хранилищ, а двухуровневая переподписка на физические ресурсы хранения чревата самыми неприятными последствиями.

Когда инфраструктура хранения перегружена, начинается борьба за ресурсы, возникают заторы, переполняется буфер. Если же она ведется сразу на нескольких уровнях инфраструктуры, жизнь администратора становится еще сложнее.

На используемых дисках попросту заполняются очереди запросов на ввод-вывод (I/O). Особенно остро это ощущается на сравнительно медленных дисках SATA (Serial Advanced Technology Attachment), где длина такой очереди обычно находится в пределах 0--32 запроса, тогда как на дисках Serial Attached SCSI (SAS) и FC она достигает 256--512 запросов. Таким образом, тем компаниям, которые хотят развернуть виртуализированную инфраструктуру и при этом применять для многоуровневого хранения недорогие диски SATA, нужно искать решение SAN без особых требований к типу серверных дисков.

На уровне логического хранения гипервизор обычно самостоятельно нарезает физический пул хранения на несколько виртуальных LUN (logical unit number — номер логического устройства), которые затем распределяет между виртуализированными гостевыми приложениями. Но при этом физический LUN не способен различать отдельные гостевые приложения, и возникающие конфликты снижают производительность системы хранения.

Точно так же переподписка на уровне гипервизора может создавать проблемы для HBA, инициаторов, портов и коммутаторов на уровне инфраструктуры SAN, поскольку в самой сети хранения эти ресурсы уже зачастую переподписаны в соотношении 8:1, а то и больше. Кумулятивный эффект такой двойной переподписки может не ограничиться простым падением производительности, а вызвать перерывы в запросах и даже зависание приложений.

Борьба с конфликтами посредством виртуализированных хранилищ SAN

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

Альтернативный вариант предполагает решение проблемы со стороны хранилища за счет снижения уровня переподписки, присущего используемой архитектуре SAN. В физических сетях хранения сделать это очень сложно, к тому же возникает опасность резкого снижения производительности входящих сюда невиртуализированных хостов. В виртуализированных хранилищах SAN изменить конфигурацию намного проще, да и гипервизоры можно разнести по физическим хостам, что позволяет оптимизировать общую производительность сети хранения.

Еще больше способствует борьбе с конфликтами то, что виртуализированные SAN позволяют распределять индивидуальные LUN по разным ресурсам хранения. Так что виртуализированные сети хранения данных сочетают в себе высокую производительность хранилищ SAN с простотой NAS.