Вкратце Starwind  iSCSI SAN Storage Software это коммерческий программный iSCSI таргет, работающие на платформе Windows (x86 или x64 MS Windows XP-2008).  Я уже писал о версии 5.4, в статье подробно описаны самые вкусные фишки, ниже краткий обзор функций как старых, так совсем новых.

Основные функции

• Синхронное зеркалирование данных: зеркалирование данных в режиме реального времени через кластер хранения, состоящий из двух узлов
• Высокая доступность / Автоматическое преодоление отказа: отказоустойчивая технология исключает единую точку сбоя
• Восстановление с быстрой Синхронизацией: восстановление к оригинальному состоянию системы после автоматического восстановления
• Удаленная / асинхронная репликация: воспроизводит систему хранения данных на удаленный узел через сеть интернет
• Точки восстановления и мгновенные снимки (snapshots): создает точку восстановления с неограниченным количеством откатов
• Сервер кластеризации: обеспечивает общее хранилище для кластеризации серверов c высокой доступностью
• Тонкое резервирование: распределяет пространство динамично для высокоэффективного использования дисковых ресурсов

Существует ряд коммерческих редакций, подробнее тут.

Кстати надо отдать должное компании Starwind, ребята публикуют на сайте массу полезной документации и видео (StarWind iSCSI SAN Software Manuals, StarWind iSCSI SAN Software White Papers, Videos and Webcasts).

Что нового в данной версии.

Дедупликация данных

Что такое дедупликация данных объяснять не буду, кто не знает могут прочитать тут или тут. Модная нынче штука (как и облака ) и главное экономически выгодная, снижаем объем хранимых данных -> снижаем затраты на физические носители.

И так в Starwind 5.6 появилась дедупликация данных, пока данная функция экспериментальная.  Скажу сразу, за время тестирования багов я не нашел, все работает прекрасно. У Александра Самойленко есть статья о дедупликации данных на Starwind 5.6.

Вкладка Events (Событие)

Еще одно нововведение — вкладка Events (Событие) в которой отображаются все события для сервера Starwind.

Уведомление о событиях

Данной опцией можно настроить уведомление о событиях.

Есть три варианта уведомлений.

• Записывать в журнал Windows Event Log
• Послать сообщение на email
• Записать в текстовый файл

Все эти варианты можно комбинировать между собой, а также настроить срабатывание на разные типы событий.

И еще некторые мелочи, поменялся немного дизайн консоли в лучшую сторону и появились интересные сплешы.

И почему именно животные из африканской фауны?

Впечатления

За время тестового полета, а это примерно 7-8 дней, продукт оставил у меня положительные впечатления, собственно как и в предыдущем тестирование и обзоре только более ранней версии.

Опять же немного повторюсь, это: легкость установки и настройки (установка и конфигурирование самого софта заняло около 10 минут), удобный и понятный  GUI интерфейс консоли управления, режим работы нод HA кластера Active/Active (кстати синхронизация при failover стала заметно быстрее), дедупликация данных, сетевой RAID-1, снапшоты и много других полезных функций.

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

Все бы хорошо но есть НО, см. ниже.

Теперь снова о минусах

Главный минус как я считаю это все-таки стоимость платформы MS Windows. Из за этого общая цена решения возрастает. Хочется видеть данный продукт на *nix платформах (тот же Linux), а также в виде VSA.  Будет очень конкуренто.

Хотя при грамотном сайзинге и конфигурации (повторяюсь ), все-таки в секторе SMB, Starwind может потягаться с железными СХД начального и среднего уровня, особенно если у Вас есть уже сервера которые освободились после виртуализации.

У MS Windows NLB есть несколько режимов работы – это Unicast и Multicast (KB — Microsoft Network Load Balancing Multicast and Unicast operation modes).

Multicast mode

При работе NLB в Multicast не нужно делать каких либо специфических настройках на хостах, но зато придётся конфигурировать гостевые ВМ и физические свитчи. Подробнее в этих KB — Sample Configuration — Network Load Balancing (NLB) Multicast Mode Configuration и Sample Configuration — Network Load Balancing (NLB) Multicast mode over routed subnet — Cisco Switch Static ARP Configuration.

Скажу что этот режим работы, не считая настроек менее капризен и не имеет недостатков Unicast режима.

Unicast Mode

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

Чтобы NLB в Unicast режиме функционировала, на vSwitch в котором есть ВМ входящие в кластер NLB необходимо сделать следующее – зайти в свойства vSwitch и на вкладке Security необходимо параметр Forged Transmits установить в Accept на вкладке NIC Teaming параметр Notify Switches установить в NO.

Подробнее в этих KB — Sample Configuration — Network Load Balancing (NLB) UNICAST Mode Configuration.

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

При функционирование кластера Windows NLB в Unicast режиме есть условия:

• Все ВМ входящие в кластер NLB должны быть на одном хосте.
• На каждом сервере входящем в кластер NLB должен быть дополнительный виртуальный сетевой интерфейс для коммуникаций, так как все сервера кластера имеют одинаковые IP и MAC адрес и соответственно коммуникация между ними не возможна.
• Не мигрировать ВМ, для таких ВМ отлючить DRS. VMotion обычно проблематичен и/или не возможен.

Я например в своей практике встречался с несколькими ситуациями когда при Unicast режиме ВМ входящие в кластер разносились по разным хостам и в результате флудинга на физическом свитчахсрабатывал Spanning Tree и просто отключались порты.

И еще на последок скажу что сама Microsoft не рекомендует использовать Windows NLB в средних и крупных инфраструктурах и в место этой службы использовать железные NLB решения и тут я с MS согласен, так как Windows NLB подходит для тестов и мелких инфраструктур.

Наконец таки решил написать.

Стораджи бывают разные….

Но я не об этом. Я о режимах работы их контроллеров.

И так в природе есть несколько режимов работы контроллеров (на английском часто называют Storage Processor или SP) у различных СХД —  это Active/Passive и Active/Active. Последние еще делятся на SAA и ААА.

Более подробно ниже.

Active/Passive

Старый вариант СХД, сейчас этот вид отживает последний срок. К ним относятся такие стораджи как HP MSA первого поколения, HP EVA (предыдущих поколений), IBM DS 3xxx/4xxx (предыдущих поколений), EMC CLARiiON с CX по СX3 и много других.  Суть работы такова. Один из контроллеров является активным и участвует в операциях I/O. Второй контроллер просто находится в ожидающем состояние и не участвует в операциях ввода вывода. Как только произошел сбой или авария (умер контроллер, упали все пути до контроллера и т.п.) активным контроллером становиться пассивный (это происходит автоматически или же выполняется администратором вручную).

Active/Active

Данные класс делиться на два подкласса:

• Symmetrical Active/Active (SAA)
• Asymmetric Active-Active (AAA)

Symmetrical Active/Active (SAA)

Это СХД хайэнд класса уровня enterprise. Очень шустрые, мега функциональные и жутко дорогие. В этих стораджах все контроллеры участвуют в операциях I/O. Причем в таких СХД обычно больше двух контроллеров. К ним относятся такие стораджи как EMC SYMETRIX, HP XP, IBM 8xxx.

Asymmetric Active-Active (AAA)

Самый широкий по моделям класс СХД (начальный и средний уровень). Кстати почти все модели стораджей которые раньше были Active/Passive теперь стали AAA. К примеру таже HP MSA первого поколение, после определенной прошивки (не помню номер), становиться ААА. Сейчас к этому классу относиться HP MSA второго и третьего поколения, HP EVA, IBM DS 3xxx/4xxx/5xxx, EMC CLARiiON CX4 и много других.

Принцип работы AAA стораджей отличается от их старших собратьев SAA. Причем у разных производителей дела обстоят по разному.

В общем схема выглядит так, оба контроллера активны. К определенному контроллеру привязывается LUN (такой контроллер называется  owner [владелец] данного LUN). И все операции I/O идут только через контроллер владелец.  Путь или пути от HBA до LUN через owner контроллер называются оптимизированными, при этом достигается максимальная производительность. В случае сбоя операции ввода вывода пойдут через другой контроллер не являющийся владельцем LUN. Такие пути или путь называются не оптимизированными и обычно в таких случаях наблюдается потеря производительности. Почему собственно так происходит? Дело в том что, операция I/O идущие через неоптимизированный путь, попадают на второй контроллер, далее второй контроллер по внутренней шине передает их на owner контроллер, тот обрабатывает запросы и передает все в обратном порядке.  Такой способ передачи данных по интерконекту не является быстрым, да плюс ко всему живой контроллер обрабатывает еще операции I/O со своими  “родными ”LUN, в итоге мы получаем на живом контроллере большую нагрузку.

В этих же стораджах (но не во всех) применяется и еще такая технология как ALUA .

ALUA  — Asymmetric Logical Unit Access. Протокол стандарта SCSI-2 и SCSI-3 предоставляющий доступ к данным через разные пути передачи, причем с разными видами доступа. Она также помогает автоматически переключиться на оптимизированные пути.

Итак рассмотрим ситуацию, на СХД имеем два контроллера и два LUN-a, на хосте 2 одно портовых HBA, каждая из которых подключена к контроллеру одним путем.

При сбое путей, автоматически срабатывает failover и данные начинают передаваться через  второй контроллер, по неоптимизированным путям.

После того как основные пути поднялись сторадж без ALUA продолжает работать по тем же не оптимизированным путям. Чтобы переключить I/O на оптимизированные пути администратору необходимо выполнить это действие вручную.

Вот тут как раз нам приходит на помощь ALUA, она как раз и занимается тем, что автоматически переключает операции I/O на оптимизированные пути.

Multipath

Я уже писал о политиках multipath в vSphere. Тут снова немного повторюсь.

Для Active/Passive лучше всего подходит политика MRU и она обычно используется, но сразу замечу что и для многих стораджей типа AAA тоже используется MRU. К примеру по умолчанию для IBM DS 3xxx/4xxx сторджей.

Для SAA стораджей используется обычно Fixed, а также можно и нужно использовать Round Robin, так как достигается максимальная производительность. Отдельно напишу о Round Robin чуть ниже.

Для AAA Fixed или же RR.

К слову сказать часто производители стораджей делают свои плагины для multipath, например powerpath для EMC стораджей.

И так round robin лучше всего включать, когда есть несколько путей. В идеально данная политики подходит для SAA стораджей. Мы получаем и повышение производительности и отказоустойчивость.

Также хорошо включать данную политику для AAA стораджей. Благодоря ей мы получим автоматическую работу по всем оптимизированным путям, а также прибавку в производительности. Но особо высокой прибавки в производительности не стоит ожидать при RR на AAA стораджах.

И еще к слову часто читал в интернете что при RR на AAA стораджах наблюдаеться падение производительности. Собственно я ни разу за практику такого не наблюдал, не считая авральных случаев с отваливание всех путей до owner контроллера, но тут и так понятно, что будет потеря.

И на последок несколько рекомендаций для админов AAA стораджей:

• Не вешайте на один контроллер все LUN.
• Планировать SAN так, чтобы был multipath, желательно как минимум по два пути от одного хоста к каждому контроллеру СХД.
• Разделите особо нагруженные LUN по разным контроллерам.
• Используйте политику Round Robin. Если нет родной политики multipath. Перед включение RR на продакшен LUN’ах, протестируйте работу политики на тестовых LUN’ах.
• На AAA стораджах без ALUA, особенно после сбоев, обращайте внимание на warning сообщение СХД о том, что данные идут по неоптимизированным путям.

30 августа 2010 г. вышел VMware vCloud Director (vCD). Этот проект ранее был известен под названием Redwood.

vCD – это служба которая предоставляет ресурсы VMware vSphere в виде каталога служб. Ориентированно в первую очередь на провайдеров услуг и крупные компании. Собственно vCD это еще один уровень абстракции теперь над VMware vSphere.

Подробней  о продукте VMware vCloud Director  на сайте VMware.

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

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

Ссылки где можно почитать о vCD

Официальная документация

Подборка статей о vCD сделанная Duncan Epping:

• VMware vCloud Director (vCD)
• Unloading the vCD Agent
• vCD – Networking part 1 – Intro
• vCD – Networking part 2 – Network Pools
• vCD – Networking part 3 – Use case
• vCD – Networking part 3 – Use case 2
• Creating a vCD Lab on your Mac/Laptop
• Error during creation of NAT Routed network via VMware vCloud Director (vCD)

Статьи о vCD от Hany Michael

Установка продукта

Буду краток, так как в интернете есть много информации по установки vCD. Приведу основные моменты.

Для установки vCD нужно:

1. VMware vSphere и VMware vCenter;
2. База данных и причем только на Oracle;
3. Кластер в VMware vSphere;
4. VMware vShield;
5. Виртуальная машина с Red Hat Enterprise Linux 5 (64 bit)

VMware vCloud Director 1.0 installation requirements

Если все есть. Скачиваем сам VMware vCloud Director. Закидываем его в ВМ. Устанавливаем.

KB с видео — установка VMware vCloud Director.

На этом пока все.

Многим  знаком режим unsupported в ESXi 4 и чтобы войти в данный режим надо было набрать unsupported на клавиатуре в локальной консоли, после этого мы попадали в busybox консоль ESXi.  Еще, наверное, многие помнят, как было немного геморно включать SSH на ESXi 4.  Да и кстати данные вещи официально не поддерживались VMware, так что если что то случилось после работы в режиме unsupported и Вы пошли писать письмо о помощи или с вопросом, то можно было сказать прощай офф. саппорту. Единственными официальными способами работы из командной строки были vSphereCLI и vMA.

Но парни из VMware не стоят на месте и в версии ESXi 4.1 официально появилась поддержка интерфейса командной строки busybox консоли как локально, так и удаленно через SSH и называются они соответственно Local Tech Support и Remote Tech Support . Активация этих режимов стала очень быстрой и удобной.

Существует два вариант активации Tech Support Mode

1. Локально из DCUI консоли ESXi;
2. Через vSphere Client;

Активация через DCUI.

Логинимся и заходим в локальную консоль.

Нас интересует Troubleshooting Options. В этом разделе как раз все и включается, а также и отключается.

Идем туда и видим

Опция Enable Local Tech Support включает локальный интерфейс командной строки.

Опция Enable Remote Tech Support (SSH) включает удаленный доступ к командной строке busybox консоли через SSH.

Опция Modify Tech Support timeout — это время ожидание в минутах при котором оба режима Tech Support  отключаются автоматом. Если есть открытые сессии, то на них эта опция не распространяется. Опция срабатывает только в том случае если нет открытых сессий (локальной и/или удаленных). Чтобы отключить данную опцию необходимо выставить время таймаута в 0.

Активация через GUI vSphere Client.

Идем в раздел Configuration -> Security Profile

Далее Properties.

Тут в принципе все теже опции что и в локальной консоли ESXi. Службы для Local Tech Support и Remote Tech Support (SSH) не запущены.

Выбираем нужный сервис (Local Tech Support/Remote Tech Support (SSH) ) и жмем Options.

Далее жмем кнопку Start дабы сейчас запустить сервис, а затем выбираем в Startup Policy режим автоматического запуска.

После выполнение процедуры видим что статус демонов стоит в Running.

Чтобы включить/отключить/изменить таймаут для автоматического отключения Tech Support Mode (в DCUI опция назывывается Modify Tech Support timeout) в GUI vSphere Client необходимо сделать следующее.

Идем Configuration -> Advansed Settings -> UserVars. Далее параметр UserVars.TSMTimeOut.

Кстати тут время измеряется в секундах, а не в минутах как в опции Modify Tech Support timeout в DCUI ESXi. Чтобы отключить таймаут необходимо просто выставить значение времени в 0. Любое другое значение означает, что таймаут включен.

1. Виртуальное железо должно быть не ниже версии 7.
2. USB Arbitrator
3. USB controller
4. USB устройство или хаб

Все основные моменты по поддержки USB можно прочитать в этом KB или в доке Virtual Machine Administration Guide.

Поддерживаются устройства как USB 2.0 так и USB 1.1. Список  официально поддерживаемых устройств.

Я для тестов брал несколько флешек разных производителей и все они поддерживались и прекрасно работали. К сожалению, под рукой не было алладиновского ключа чтобы и этот вариант опробовать, но думаю работать будет без проблем, если заявлено официально. А вот USB DVD-RW от ASUS так и не заработал, его хосты видеть отказались.

Какие существуют ограничения для проброса USB

Контроллер USB

• 1 ВМ может иметь 1 виртуальный контроллер USB
• USB Arbitrator может работать только с 15 физическими контроллерами USB
• Перед тем как добавить в ВМ USB устройство, нужно в эту же ВМ добавить виртуальный USB контроллер
• Перед тем как удалить виртуальный USB контроллер из ВМ, необходимо удалить все USB устройства

USB устройства

• 1-ой ВМ можно давать несколько устройств USB, максимум 20
• Устройство USB  доступно только 1-ой ВМ к которой оно подключено
• Официально не поддерживаемые устройства (линк на список поддерживаемых девайсов), могут некорректно работать с каким либо функционалом (к примеру с VMotion)
• Перед тем как сделать HotAdd  виртуального железа на ВМ, необходимо отключить все USB устройства, так как при горячем добавление автоматически отключаются от ВМ все USB устройства.
• Если ВМ была suspend, а затем снова продолжала работу, то USB устройства ведут себя, так как будто их отключили и снова включили.

Для устройств USB поддерживается VMotion и DRS. Это наверное самое вкусное. Так как можно спокойно мигрировать машины с хоста на хост и иметь подключенный USB девайс. Кстати DPM не поддерживается, так что на хостах где есть USB девайсы нужно отключить DPM.

Подключение

Тут все просто. Cкажем, берем флешку, вставляем в USB порт хоста, далее идем в консоль vSphere.

Идем в свойства ВМ которой нужно добавить USB устройство.

Так как виртуального USB контроллера нет на ВМ, с начала добавлем его.

Затем уже добавляем USB устройство.

Выбираем из списка нужное устройство. Если необходимо чтобы устройство поддерживало VMotion, ставим галку Support vMotion while device is connected.

Жмем ОК и идем в ВМ смотреть что получилось.

Опа, вот и она, моя флешка уже в ВМ.

Далее я пробовал мигрировать (VMotion) данную ВМ с прокинутой флешкой на разные хосты. Флешка была доступна!

Кстати если открыть свойства ВМ, а затем посмотреть свойства USB устройства то в поле USB Unique ID как раз будет указан хост и путь где подключен девайс.

Итог таков что в версии vSphere 4.1 прокидывание USB есть и оно работает замечательно как с VMotion так и без него. Огорчает правдо не такой внушительный список поддержки USB устройств, но я думаю, в будущем он расширится.

Решил начать с iSCSI Hardware Offloads.

Из релиза известно что

vSphere 4.1 enables 10Gb iSCSI hardware offloads (Broadcom 57711) and 1Gb iSCSI hardware offloads (Broadcom 5709).

Что это и с чем его едят? Собственно теперь сетевые карточки с функцией iSCSI Offload  или Accelerated iSCSI в терминологии HP и некоторых других производителей будут в ESX/ESXi работать как iSCSI HBA и в документации VMware дается обозначение таким адаптерам как Dependent Hardware iSCSI Adapters.

Более точное определение из доков VMware что такое Dependent Hardware iSCSI Adapters (зависимый железный iSCSI адаптер)

A dependent hardware iSCSI adapter is a third-party adapter that depends on VMware networking, and iSCSI configuration and management interfaces provided by VMware.

This type of adapter can be a card, such as a Broadcom 5709 NIC, that presents a standard network adapter and iSCSI offload functionality for the same port. The iSCSI offload functionality appears on the list of storage adapters as an iSCSI adapter. Although the iSCSI adapter is enabled by default, to make it functional, you must set up networking for the iSCSI traffic and bind the adapter and an appropriate VMkernel iSCSI port.

Ура, возрадуйтесь коллеги у кого есть сетевухи построенные на выше перечисленных чипах, раньше данный функционал был доступен только в ОС семейства Windows, RHEL и еще некоторых *nix систем для которых нужно было инсталлировать  драйвер, в ESX/ESXi данной поддержки не было.

Пока официально поддерживаются только два чипа это Broadcom 57711 и Broadcom 5709, не очень много, но все же, хотя думаю, в будущем список расширится.

Супер, пробежала мысль в голове, но мне пока не судьба сейчас попробовать заявленный  iSCSI Hardware Offloads, так как у меня нет хостов с данными чипами, но есть хост с парой сетевых карточек HP NC373T построенных на Broadcom 5708. Чипы 5708 и 5709 почти что похожи, но с некоторыми функциональными отличиями, хотя драйвер используют один и тот же и оба поддерживают iSCSI Offload. Каково мое было удивление, когда после обновления до ESXi 4.1 в разделе Storage adapter я увидел два iSCSI HBA которые как раз и были моими картами на 5708 чипе.

Так как Dependent Hardware iSCSI Adapters не чисто отдельная железная HBA, а сетевуха с функцией iSCSI Offload  то ее необходимо правильно настроить. ESX/ESXi 4.1 видят такую сетевую как два устройства: физ. сетевую карту и физическую iSCSI HBA. В моем примере vmnic2 она же vmhba32 и vmnic3 она же vmhba33.

Для полноты картины приведу рисунок общей конфигурации из доков VMware.

На рисунке в левой части показано подключение через софтверный iSCSI инициатор через две сетевые карты с 2-мя портами VMkernel, а справа через две сетевые карты которые поддерживают iSCSI Offload.

Конфигурация очень похожа чем то на конфигурацию софтверного iSCSI инициатора в ESX/ESXi с небольшими нюансами.  Для информации моя статья о конфигурации  софтверного iSCSI инициатора, а также статья о настройки multipathing и RR для софтверного iSCSI инициатора.

Едем дальше.

Первым делом что нужно сделать это создать порты VMKernel для трафика iSCSI и сделать активными только те сетевые карты, которые соответствуют своим HBA. В моем примере iSCSI1 будет работать через vmnic2, а iSCSI2 будет работать через vmnic3. Для этого я сделаю отдельный vSwitch и делаю все необходимые настройки.

Далее необходимо порты VMkernel  привязать к существующим зависимым адаптерам iSCSI.

Это уже делается из консоли либо локальной (благо теперь уже и у ESXi она тоже официально поддерживается), либо удаленной или через vSphere CLI.

Я удаленно через SSH все сделаю.

esxcli swiscsi nic add -n vmk1 -d vmhba32

esxcli swiscsi nic add -n vmk2 -d vmhba33

Осталось настроить таргеты в свойствах iSCSI HBA (также как и в софтверном инициаторе) и сделать рескан адаптеров.

Добавил 2 LUN. Вот что у меня получилось.

А вот и multipathing до LUN.

На этом все.

И так теорию о iSCSI писать не буду, а переду сразу к делу.

Повторюсь, ПО Starwind это программный iSCSI таргет с отличным функционалом (о нем чуть позже) выступающий как конкурент железным решениям и дает нам возможность виртуализовать хранилища данных, а также в зависимости от версии обеспечить высокую доступность хранилищ. Существует несколько вариантов продукта: free версия с урезанным функционалом, а также несколько коммерческих версий. Более подробно о коммерческих версиях тут.

На днях как раз знакомился и тестировал  полную коммерческую версию продукта. Работает ПО на платформах Windows от XP до 2008.

Собственно с помощью Starwind можно организовать iSCSI таргет за 30 мин (так заявляет  производитель). Забегая вперед скажу действительно можно, я вообще справился с этим делом за 10 мин и это не вызвало больших проблем.

Функционал.

Существует ряд версий отличающихся друг от друга функционалом и доступными фичами.

Доступный функционал.

• Синхронное зеркалирование данных: зеркалирование данных в режиме реального времени через кластер хранения, состоящий из двух узлов.
• Высокая доступность / Автоматическое преодоление отказа: отказоустойчивая технология исключает единую точку сбоя
• Восстановление с быстрой Синхронизацией: восстановление к оригинальному состоянию системы после автоматического восстановления
• Удаленная / асинхронная репликация: воспроизводит систему хранения данных на удаленный узел через сеть интернет
• Точки восстановления и мгновенные снимки (snapshots): создает точку восстановления с неограниченным количеством откатов
• Сервер кластеризации: обеспечивает общее хранилище для кластеризации серверов c высокой доступностью
• Тонкое резервирование: распределяет пространство динамично для высокоэффективного использования дисковых ресурсов

Установка.

Подробно описывать не буду процесс установки, скажу одно, он до безобразия прост, 2 мин и все готово. Далее остается сконфигурировать таргеты. Тут немного по сложнее, но все делается через удобный графический интерфейс.

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

RAID-1

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

На скриншоте Test2-Mirror-Synch как раз таргет с виртуальным сетевым RAID-1. Основное зеркало лежит на первом сервере локально, второе на другом сервере (TSSRV2, таргет Mirror-Test2-dev1).

Принцип работы прост, первый диск (основной) презентуется хосту с ESX/ESXi (второй диск зеркало тоже можно презентовать, но этого делать не стоит, до момента пока не откажет первый диск и Вам не потребуются с него срочно данные) и с ним идет основная работа, когда данные пишутся на этот диск, то одновременно они же и записываются на второй диск (зеркало) в режиме реального времени, только уже посредством самого Starwind’a. Как чуть выше уже упомянул, при каком либо краше основного диска, можно хосту презентовать второй диск, предварительного его сделав основным в консоли Starwind. Затем восстановить сбойнувший диск и сделать принудительную полную синхронизацию.

Starwind HA

Что это и что дает Starwind HA? А все очень просто, отказоустойчивое решение, работающее в режиме Active/Active с синхронизацией данных между двумя нодами. Для этого надо 2 сервера Strawind (основной сервер и сервер партнер в терминологии Starwind, в работе же оба сервера получаются равноправными) и сконфигурированное High Availability device.

Как это работает? И так кластер из двух нод (Starwind), которые всегда активны, ноды между собой постоянно синхронизируются в режиме реального времени при любых операциях I/O к HA кластеру по выделенному каналу для синхронизации. В случае сбоя одной из нод, автоматически весь трафик предназначавшийся сбойнутой ноде перенаправляется на рабочую ноду. При восстановление неработающей ноды, происходит синхронизация данных между двумя серверами, в данной версии ПО (5.3) после сбоя необходимо сделать полную синхронизацию нод в ручную с консоли, в следующей версии все будет работать автоматом.

На скриншоте Test1-HA-Dev1 первый таргет HA кластера на первом сервере, Test1-HA-Dev1-Partner второй таргет, на сервере партнере.

Собственно далее прописываем оба сервера на хосте и получаем два пути к одному и тому же LUN. Кстати если данный LUN настроить в ESX/ESXi на работу с политикой Round Robin, то пути до обоих нод будут активными и операции I/O будут проходить сразу на обе ноды.

Вообще Starwind HA работает по тому же принципу, как и железные хранилища типа SAA.  Кроме отказоусточивости мы еще получаем и распределение нагрузки. Конечно, чтобы это все правильно работало, нужно грамотно сконфигурировать инфраструктуру, данную тему затрагивать не буду, опять же отошлю к доками Strawind’a.

Пару слов о производительности

Собственно решение дает практически максимальную производительность которую может дать то железо (сервер, диски, сеть и д.р.) на котором вы используете данный софт. Детальное тестирование не проводил, но вкратце погонял пару тестов и судя по результатам решение работает очень достойно.

Впечатления

Впечатления очень положительные от Strawind. Легкость установки и настройки. Понравился удобный GUI интерфейс консоли управления. Действительно при HA конфигурации, режим работы нод Active/Active, как это реализовано на железных СХД хайэнд класса. Сетевой RAID-1 для повышения надежности данных и много других вкусностей, как снапшоты и thin provision. Ну и конечно цена решения. Если не брать в учет стоимость лицензий ОС Windows, то получается совсем вкусно и очень конкурентно с железными решениями даже начального уровня. Так что думаю, главной целевой аудиторией продукта будет сектор SMB.

Немного о минусах

Наверное, то что мне бросается в глаза сразу так это то что ПО работает под управление ОС семейства Windows – а это дополнительная трата на лицензии. Хотя представители Starwind говорят, что в этапе бета тестирования VSA версия продукта, так что думаю, в скором времени этот минус отпадет. Конечно, хочется увидеть реализации и на Linux платформах, что даст 10 очков дополнительно этому продукту.

Jumbo Frames – это сетевые кадры размером 9000+ байтов. Обычные кадры, использующиеся в сети имеют размером 1500 байт.  Jumbo Frames работает в сетях 1Гбит и выше. Для чего же нужны большие кадры? Собственно для того чтобы увеличить быстродействие сети при передачи большого числа данных и снизить накладные расходы. Рекомендуется включать Jumbo Frames в сетях, где наблюдается интенсивная пересылка больших объемов данных, например трафик iSCSI. Подробнее тут.

ESX/ESXi 4 имеет поддержку Jumbo Frames и ниже я расскажу как ее включить на примере хоста с ESX 4.

По умолчанию у нас есть коммутатор, который поддерживает Jumbo Frames и на нем уже включена поддержка больших кадров для нужных портов. Также есть хост, на котором уже есть отдельный vSwitch и два порта VMkernel использующийся для трафика iSCSI. Вот как раз на нем я включу поддержку Jumbo Frames.

Все операции по включению Jumbo Frames производятся из консоли. Включать поддержку Jumbo Frames я буду на vSwitch2.

Первым делом идем в консоль и смотрим командой esxcfg-vswitch –l какие у нас есть виртуальные свитчи и какой MTU выставлен. По умолчанию MTU = 1500.

Далее выполняю команду esxcfg-vswitch -m 9000 vSwitch2, тем самым включая поддержку больших кадров на виртуальном свитче vSwitch2.

Теперь остается включить Jumbo Frames для портов VMkernel, которым это необходимо. В моем примере они созданы, так что их придется пересоздавать.

В начале выполняем команду esxcfg-vmknic –d <port_group_name>, этой командой мы удалим VMkernel NIC в порт группе, в моем примере esxcfg-vmknic –d iSCSI1.

Затем выполняем команду esxcfg-vmknic -a -i <IP> -n <network_mask> -m 9000 <port_group_name>, этим действием мы заново создадим порт VMkernel с нужным IP, маской и размером кадра в 9000 байт, в моем примере esxcfg-vmknic –a –i 192.168.10.5 255.255.255.0 –m 9000 iSCSI1.

Тоже самое я проделаю и со вторым портом VMkernel.

esxcfg-vmknic –d iSCSI2

esxcfg-vmknic –a –i 192.168.10.6 255.255.255.0 –m 9000 iSCSI2

Теперь можно посмотреть, что получилось командой esxcfg-vmknic –l.

Все с конфигурацией.

Касетельно ESXi.

Тут есть несколько способов. Через unsupported mode или vSphere CLI или vMA.

Как сконфигурировать хост и сетевую инфраструктуру расскажу на примере одной реальной задачи. И так нужно сделать для ВМ и VMotion быструю сеть, а также обеспечить отказоустойчивость на случай выхода из строя одного канала, причем в наличие есть только две выделенные физические сетевые и один физический коммутатор с поддержкой IEEE 802.3ad.  Плюс ко всему разделить порт группы ВМ по своим VLAN. Особо тут не разгуляешься, и отказоустойчивость можно получить на случай выхода из строя одной из  сетевых плат или патча. В данной конфигурации существует единая точка отказа, это физический свитч. Деваться некуда, так как задача стоит и ее нужно решить. Собственно решение созрело сразу это LA.

Что для этого нужно, это собственно любой физический свитч, поддерживающий LA (IEEE 802.3ad) и VLAN. В ESX/ESXi уже включена поддержка LA, НО с некоторыми оговорками, работает только в режиме 802.3ad static. Почитать подробнее можно в этом KB.

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

И так у нас есть хост, 2 физические сетевые, свитч HP 2824 и 2 свободных порта на нем и несколько VLAN.

Конфигурация состоит из 2-х этапов.

1)      Конфигурация самого хоста.

2)      Конфигурация физического свитча.

Схема физического подключения.

1. Конфигурация Networking

Первое это нужно создать отдельный vSwitch, на котором будет использоваться LA или использовать существующий и привязать к нему наши две физические сетевые для аплинка. Далее идем в свойства vSwitch вкладка Ports -> vSwitch и на вкладке NIC Teaming необходимо убедиться, что обе сетевые активные.  В поле Load Balancing указываем Route based on ip hash.

Еще одно важное замечание. В поле Network Failover Detection должен быть выбран Link Status only, с beaconing probe работать не будет.

2. Конфигурация физ. свитча.

И так сама конфигурация на примере HP ProCurve 2824. Тут все просто. Заходим в консоль, далее в config и выполняем следующие trunk <port_list> < trk1 … trk60 > trunk

В моем примере патчи от физ. сетевых хоста висят на портах 11 и 12, и я ввожу trunk 11-12 trk1 trunk. После можете посмотреть, что получилось командой show trunk.

Ну осталось еще одно. Нашу группу trk1 пометить как tagged и прокинуть во все vlan. Это легко делается из веб интерфейса управления свитча или же из той же консоли.

Вот и все с конфигурацией.

А да кстати если кто незнает как настроить на работу с VLAN ESX/ESXi, то вот эта статья Вам в помощь.