Вкратце 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 может потягаться с железными СХД начального и среднего уровня, особенно если у Вас есть уже сервера которые освободились после виртуализации.

Решил начать с 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 очков дополнительно этому продукту.

В данном примере я буду использовать хост на ESX 4, два физических сетевых адаптера выделенных для работы под трафик iSCSI и СХД HP MSA 2324i с двумя контролерами (что то по серьезней пока нет под рукой для свободного разделывания), работающими в режиме Active-Active ULP.  Конфигурация из этого примера подойдет для настройки ESX/ESXi c другими типами СХД. Тут я затрону только настройку самого ESX, по умолчанию мы уже имеем несколько LUN на СХД(в моем примере 2 LUN).

Описывать настройку портов VMkernel, как и iSCSI инициатора в ESX/ESXi подробно не буду, а сразу перейду к настройки мультипатчинга и Round Robin.

Сама суть конфигурации для обеспечения multipathing в следующем. Каждый физический интерфейс отдаем только под использование 1-го порта VMkernel, в идеале вообще под монопольное использование. Т.е этот же интерфейс не должен быть задействован на другом порте VMkernel, который также будет использоваться для трафика iSCSI.

Есть два варианта конфигурации.

1. С одним vSwitch и несколькими портами VMkernel, а также несколькими привязанными физ. сетевыми к нему.

2. С несколькими vSwitch, в каждом из которых по 1-му порту VMkernel и к каждому привязана 1 физ. сетевая.

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

Сама железная конфигурация выглядит так.

Далее конфигурируем хост для работы по iSCSI с мультипатчингом.

Создаем vSwitch с двумя портами VMkernel и привязываем к этому vSwitch 2-е физические сетевые карты.

Проделываем следующие: заходим в свойства порта VMkernel в моем примере iSCSI1 (Идем у нужного нам vSwitch в Properties -> выбираем нужный порт -> Edit) и переходим на вкладку NIC Teaming.

Включаем Failover Order, затем выбираем одну из сетевых карт которая будет не использована в данном подключение и перетаскиваем ее с помощью кнопки Move Down в секцию Unused Adapters. Этим действием мы оставили в использование под VMkernel порт только одну сетевую карту.

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

Теперь из консоли нужно выполнить следующую команду esxcli swiscsi nic add -n <port_name> -d <vmhba>, где port_name имя порта VMkernel, а vmhba имя iSCSI адаптера. Этим действием мы привязываем порты VMkernel к iSCSI инициатору хоста.

В моем примере я последовательно добавляю каждый порт

esxcli swiscsi nic add -n vmk1 -d vmhba34

esxcli swiscsi nic add -n vmk2 -d vmhba34

Далее командой esxcli swiscsi nic list -d <vmhba> можно просмотреть привязанные порты VMkernel к iSCSI адаптеру.

Теперь осталось сделать Rescan. Идем Configuration — > Storage Adapters. В правом верхнем углу жмем Rescan. По завершению процедуры у нас появятся 4 пути, по 2 на каждый LUN.

На вкладке Paths это хорошо видно.

По умолчанию для данного типа хранилищ работающих в режиме Active/Active политика multipathing является Fixed.  О политиках multipathing можно прочесть в другой моей заметки.

Возвращаемся на вкладку Devices и щелкаем правой кнопкой мыши по первому LUN и выбираем Manage Paths.

Вот тут как раз и меняем политику multipathing с Fixed на Round Robin.

Затем тоже самое проделываем со следующим LUN.

В итоге у меня получилась вот такая картина.

Вот и все с настройкой.

Из скринов видно что с Round Robin одновременно активны сразу два контролера и оба контролера участвуют во операциях I/O, в отличие от политики Fixed где одновременно активны оба контролера, но в операциях I/O участвует только один контролер.

Все видео на английском, но думаю там и так понятно все будет.

Установка VMware ESX 4.

Установка VMware vCenter и его компонентов.

Конфигурирование vSphere 4 через vCenter (iSCSI, HA, vMotion, Virtual Appliance).

Установка и настройка VMware Fault Tolerance.

Горячее добавление устройств и Thin-Provisioning (тонкие диски).

Storage vMotion.

Немного об iSCSI.
Про iSCSI можно почитать, например, тут или тут.
А теперь главное. Что меня самого поначалу путало, так это терминология. Особено понятия клиетской и серверной части.  Иногда  и сейчас путаю их в состояние своей большой загрузки 
iSCSI target (цель) — это контролер или приложение предоставляющее доступ к общему хранилищу данных. Попросту это может быть физическая железка или же ее программный вариант. Это и есть серверная часть.
iSCSI initiator (инициатор) — клиентская часть, осуществляющая клиентский доступ к хранилищу данных по iSCSI. Так же может быть реализовано и аппаратно и программно.

В VMware ESX/ESXi 4 Server уже есть программный инициатор iSCSI и основная его настройка не очень сложна. Далее опишу процесс активации и конфигурации инициатора iSCSI и добавления LUN в datastore в VMware ESX/ESXi 4 Server.

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

И еще небольшое отступление. Для активации инициатора iSCSI у вас должен быть сконфигурирован VMKernel, т.е  порт группа должна быть добавлена к vSwitch. Если не сконфигурирован VMKernel, то придется его конфигить. Как добавить порт группу для VMkernel можно прочитать тут.

Поехали.

Активация  iSCSI инициатора в VMware ESX/ESXi 4 и добавление цели.

Открываем VMware vSphere клиент и конектимся к нужному хосту. Идем в  Configuration — > Storage Adapters. Далее в Storage Adapters находим iSCSI Software Adapter.

Лезем  в Properties. И видим следующее. Пока инициатор iSCSI не задействован. Жмем Configure.

И просто ставим галку Enabled.

После получится примерно следующее

Теперь инициатор iSCSI в ESX активирован. Далее надо настроить таргет. Поэтому идем на вкладку Dynamic Discovery.

Нажимаем Add и забиваем IP и порт iSCSI цели. После получается примерно следующее.

Далее просто закрываем все и нас попросят сделать рескан адаптеров, с чем и соглашаемся.

Вуаля, все.  После появится описание добавленого iSCSI таргета.

Вот и все с активацией инициатора iSCSI и добавлением тагрета.

Теперь осталось добавить iSCSI LUN в datastores.

Добавление iSCSI LUN в в datastores.

Идем Configuration -> Storage и жмем Add Storage.

Выбираем Disk/LUN.

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

Тут отображается инфа о подключаемом сторадже.

Забиваем имя нового datastore.

Выбираем размер блока, от него зависит какой максимальный размер файла будет на сторадже. Также тут можно выбрать и размер раздела.

В конце мастер выдаст суммарную информацию о создаваемом datastore. Все жмем Finish и ждем когда создастся новый datastore.

Теперь в списке datastores появился новый datastore.

Вот и все по инициатору iSCSI и добавление iSCSI LUN в  datastores.

Немного о VMkernel.
VMkernel – это ядро VMware ESX/ESXi Server. Оно занимает слой виртуализации и управляет большинством физических ресурсов: процессорами, памятью, системами хранения данных, сетевыми контролерами и п.р. Кто то может заметить, что в VMware ESX Server есть Red Hat Enterprise Linux, так и есть, но роль линукса сводится только к тому, чтобы загружить машину и само ядро VMkernel, вот оно то и управляет всем. Сам линукс в ESX Server служит только для предоставления командной консоли, а также для установки агентов мониторинга железа и бекапа. Кстати в VMware ESXi Server тоже есть линукс, но он просто очень и очень сильно обрезан.

Сетевые сервисы использующие стек TCP/IP такие как VMotion, iSCSI, NFS также работают через VMkernel, поэтому для включения их необходимо правильно сконфигурировать VMkernel. Стек TCP/IP в VMkernel полностью отделен от стека TCP/IP используемого в Service Console . Стек TCP\IP VMkernel создается как порт группа VMkernel и подключается к одному или нескольких vSwitch, которые в свою очередь подключены к различным сетям.

Конфигурирование сетевых сервисов VMkernel.
Как я уже выше писал, для работы VMotion, инициатора iSCSI и NFS необходимо сконфигурировать стек TCP\IP VMkernel. Конфигурация довольна, проста и заключается в добавление порт группы VMkernel к vSwitch на через который должен течь трафик сетевых сервисов iSCSI, NFS, VMotion. Все хватит теории, я больше люблю практику.

Go — go — go!

Открываем клиент vSphere и идем в раздел Configuration->Networking. В данном примере у меня на хосте 2-ве физические сетевые карты. Первая карта подключена vSwitch0, к которому подключены ВМ. Вторая карта подключена на vSwitch1, вот как раз на нем я и собираюсь создать порт VMkernel и гонять трафик.

Жмем Properties на нужном нам vSwitch и в  появившемся окне жмем Add.

Потом выбираем VMkernel.

И просто забиваем нужные параметры.  Думаю тут все понятно, имя порта и vlan id если необходим.

Далее сконфигурируем IP адрес, маску, и шлюз для VMkernel порта.

Жмем Next. Смотрим суммарную инфу и жмем Finish. После завершения мастера создастся порт VMkernel со своим сетевым интерфейсом.

Остается только проверить доступен ли только что созданный сетевой интерфейс VMkernel. Просто пингуем с машины которая находится в одной сети с портом VMkernel его интерфейс или же можно с консоли ESX пингануть какую либо машину в сети. Для пинга через интерфейс VMkernel используется команда vmkping.

Вот и вся конфигурация. Далее теперь можно сконфигурировать VMotion, iSCSI и NFS. Но это уже выходит за рамки этой публикации.

О конфигурации VMotion можно прочесть тут.

О конфигурации iSCSI тут.