StarWind Native SAN для Hyper-V: история успеха

--> Дата: Ноя 18, 2011 173

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

Зачем понадобилась виртуализация?

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

Какой гипервизор выбрать?

Сначала мы думали использовать VMware ESX, поскольку этот продукт доминировал на рынке гипервизоров. Однако в тот момент, когда мы были готовы его купить, VMware как раз выпустила vSphere 5, полностью изменив ценовую политику. Мы с нашим ограниченным бюджетным планом оказались не у дел, поскольку просто не могли позволить себе потратить столько денег на ПО. Неожиданно мы поняли, что раз мы являемся пользователями ОС Windows, для нас естественно было бы использовать гипервизор Hyper-V от Microsoft. Таким образом нам удалось бы избежать затрат на покупку гипервизора, а кроме того функциональность Hyper-V подходила нам настолько же, насколько и ESX. Нам всего-то была нужна возможность переводить работающие виртуальные машины с одного физического хоста на другой для технического обслуживания, и нас абсолютно не интересовало, как эта возможность будет называться – vMotion (ESX) или Live Migration (Hyper-V).

Как быть с совместно используемым хранилищем?

Однако триумф был недолгим. Создание виртуальной среды требовало наличия того, о чем мы не имели ни малейшего понятия. Камнем преткновения стала сеть хранения данных (SAN). Практически сразу мы отказались от варианта использования Fibre Channel: чтобы купить FC-кабели, адаптеры и коммутаторы, а также нанять специалиста, работающего с технологией Fibre Channel, пришлось бы отдать целое состояние. Мы внимательно присматривались к iSCSI SAN, обеспечивающей производительность равную или эквивалентную показателям Fibre Channel, – последнее, конечно, за счет использования 10-Гбит/с сети Ethernet, которая у нас, кстати, уже имелась. К тому же iSCSI SAN обеспечивает более высокий уровень избыточности, или как минимум такой же, как FC, благодаря использованию правильно сконфигурированной MPIO, а также является более мощной – и все это стоит лишь малую часть того, что пришлось бы заплатить за технологию Fiber Channel.

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

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

Вначале мы стали проверять различные решения на базе Linux и Solaris, поскольку они не требовали покупки дополнительных лицензий Windows и в то же время имели разумную цену. Первое сомнение возникло практически сразу: мы же пользователи Windows и не имеем ни малейшего понятия, что делать с Unix в случае серьезной поломки. Дальнейшие сомнения также появились довольно скоро и касались технической поддержки и в какой-то степени доверия. Компании, продающие ПО SAN на базе платформ Linux и Solaris, не занимались ни его разработкой, ни разработкой самих платформ, на которых работает это ПО, что оставляло открытым вопрос о технической поддержке в случае возникновения серьезных проблем. Последнее сомнение касалось архитектуры этих решений. ПО для Linux и Solaris не имело симметрической модели высокой доступности в режиме active-active, а наоборот, использовало устаревающий сценарий active-passive. Он предполагал, что лишь один узел хранилища обслуживает запросы, в то время как другой находится в ждущем режиме и получает реплицированные копии всех обработанных запросов. Такая модель в результате давала низкую производительность, невысокий показатель использования оборудования, что в свою очередь обусловливало высокий коэффициент TCO и низкий коэффициент возврата инвестиций (ROI). К тому же нас беспокоил один важный момент: нефиксированное время переключения между узлами кластера с возможным простоем всего кластера хранилища. По понятным причинам этого мы не могли допустить в нашем основном хранилище информации: упавший кластер хранилища автоматически привел бы к сбою в работе гипервизора, что, в свою очередь, остановило бы все рабочие процессы.

Поэтому мы вновь мысленно вернулись к Windows и решили создать устройства iSCSI SAN на базе этой платформы, используя обычное аппаратное обеспечение и лицензии Windows, которые у нас уже были. Пока вроде бы все сходилось. Нам удалось найти несколько продуктов, предлагавших необходимую функциональность по более-менее приемлемой цене. Обещанная продуктивность нас также устраивала, поскольку решения использовали модель active-active, а также имели усовершенствованное кэширование, если бы не одно «но»… Да, нам удалось решить проблему с остановкой рабочих процессов. Теперь все наши физические серверы были переведены на виртуальные машины и работали в кластерной конфигурации, в режиме высокой доступности. Виртуальные серверы практически полностью исключали возникновение простоя. К тому же наше совместно используемое хранилище было полностью избыточным, и мы могли отключить любой гипервизор или узел хранилища для технического обслуживания без ущерба для бизнес-процессов. Однако каждый хост Hyper-V, сконфигурированный в кластер, должен был соединяться с парой Windows-машин с установленным ПО iSCSI SAN, обеспечивающих высокую доступность с помощью синхронной репликации. В результате мы создали виртуальное пространство, но количество физических машин от этого практически не уменьшилось! На всех машинах была установлена ОС Windows, часть из них была отведена под гипервизоры, а часть – под ПО iSCSI SAN. Теоретически мы могли установить ПО виртуального устройства хранения (VSA), но на наших виртуальных машинах стояла ОС Linux. Это само по себе порождало целый ряд вопросов, связанных с управлением, производительностью и надежностью системы, которая падала, не выдерживая даже средней нагрузки. Задача казалась неразрешимой…

Почему native (родной)?

Мы были удручены и подавлены, пока не обнаружили решение одной из компаний-разработчиков в области хранения информации. ПО имело название StarWind Native SAN для Hyper-V. В отличие от VSA это ПО для создания SAN ставилось не на виртуальную машину под контроль гостевой ОС. Этот программный продукт был разработан специально для установки поверх гипервизора в так называемый родительский раздел, в котором выполняется операционная среда Windows. Таким образом, мы смогли избежать работы с незнакомой нам ОС, исключить падение производительности гостевой виртуальной машины, а также нам не пришлось покупать дополнительное оборудование, ведь мы использовали серверы, на которых стояли гипервизоры! Мы построили несколько кластеров, использовав существующие два хоста Hyper-V в каждом их них. С помощью ПО StarWind Native SAN для Hyper-V наше хранилище DAS было преобразовано в сеть хранения SAN высокой доступности. Новое хранилище SAN оказалось очень надежным и продемонстрировало превосходную производительность.

Итак, мы успешно завершили свой проект виртуализации и преобразовали ИТ-инфраструктуру всей компании в пространство высокой доступности, не вложив ни доллара в покупку дополнительных лицензий ОС и в ПО гипервизоров. К тому же нам не только не пришлось покупать дополнительное аппаратное обеспечение – наоборот, мы смогли уменьшить количество серверов практически вдвое! Единственным, что потребовало вложения некоторых средств, было ПО для создания и управления хранилищем SAN. Но оно оказалось настолько доступным по цене, что мы его оценили как наиболее полезное и ценное ПО, которое мы когда-либо приобретали! В общем, мы в абсолютном восторге от решения StarWind Native SAN for Hyper-V.