Потекин Вячеслав Викторович, руководитель ИТ—отдела ГК «МЕДВЕДЬ-ХОЛДИНГ»

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

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

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

Рисунок 1. Схема принципа работы классической SAN.

Рисунок 2. Схема принципа работы StarWind Native SAN для 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 оказалось очень надежным и показало превосходную производительность. Мы были в абсолютно выигрышной ситуации! Мы успешно завершили свой проект виртуализации и преобразовали IT инфраструктуру всей компании в пространство высокой доступности, не вложив ни доллара в покупку дополнительных лицензий операционной системы и в ПО гипервизоров. К тому же нам не только не пришлось покупать дополнительное аппаратное обеспечение, а наоборот, мы смогли уменьшить количество серверов практически вдвое! Единственным, что потребовало вложения некоторых средств, было программное обеспечение для создания и управления хранилищем SAN. Но оно оказалось настолько доступным по цене, что мы его оценили как наиболее полезное и ценное ПО, которое мы когда-либо приобретали! Мы в абсолютном восторге от решения StarWind Native SAN for Hyper-V!