Опыт использования Starwind VSAN и EMC ScaleIO (VxFlexOS) + шпаргалка по мини Enterprise СХД (1 часть)

Иногда возникает необходимость в организации отказоустойчивого хранилища СХД маленького объема до 20Тб, но с функционалом Enterprise — All-Flash, SSD кэш, MPIO,HA(Activ-Activ) и всё это с бюджетной ценой. Готовые аппаратные решения с данными функциями начинаются от сотен терабайт и цены из 8 и более знаков в рублях. Имея маленький бюджет 6-7 знаков в р. и необходимость в маленьком и быстром (но надежном) хранилище, с 2009 года были опробованы и переведены в промышленную эксплуатацию два варианта СХД (Общее у этих систем это, высоконадёжные системы без единой точки отказа +можно потрогать руками до покупки или «обойтись без неё»(FREE)).

Кому интересен данный опыт, далее будет описано следующее:

1. Опыт эксплуатации ПО StarWind Virtual SAN (VSAN).
2. Как сделать маленькое Enterprise СХД.
3. История разгона IOPS(практика).
4. Шпаргалка по развертыванию и эксплуатации СХД EMC ScaleIO (VxFlexOS) (при отсутствии технической поддержки силами специалистов «НЕ Linux-guru») 1 часть.

1. Опыт эксплуатации ПО StarWind Virtual SAN (VSAN)

StarWind Virtual SAN (VSAN) – в решении Activ- Activ (синхронная репликация на 3-х серверах), в эксплуатации с 2009 -2016 год в разных редакциях(Starwind ISCSI SAN HA-3) на основании серверов с аппаратными RAID массивами.

Плюсы:

• Легко и быстро, устанавливается даже не профессионалом;
• MPIO по ISCSI Ethernet;
• HA (Activ-Activ);
• На новых (гарантийных) серверах (с новыми дисками) можно на несколько лет забыть об обслуживании СХД (пользователи не заметят даже выход из строя двух серверов из трех);
• RAM и SSD кэш томов;
• Быстрая Fast-синхронизация при мелких сбоях в сети.

Минусы:

• Ранее существовала только версия под Windows платформу;
• При длительной эксплуатации (более 3 лет) – трудно найти диск взамен вышедшего из строя (сняты с производства) для ремонта RAID массива (при разнородных дисках возможны сбои в массиве);
• Увеличение количества сетевых интерфейсов и занимаемых под них слотов PCI(дополнительно для синхронизации -сетевые карты, коммутаторы) ;
• При использовании LSFS- «журналируемой файловой системы», длительное выключение системы, которое может быть пагубно при срабатывании UPS при отключении питания;
• Очень длительное время полной синхронизации при большом томе.

Возможно уже вылеченные проблемы(ранее случившиеся при эксплуатации в нашем ЦОД):

• При развале RAID массива – сервер остается виден по каналу синхронизации и данных, но диск в Windows сервере вне сети, раздувается лог Starwind и пожирается память сервера, как следствие зависание сервера. Возможное лечение назначение контрольного файла и убирание из настроек логов не критичных сообщений.
• При выходе из строя коммутатора или сетевых интерфейсов – неоднозначный выбор ведущего сервера (иногда случалось- система не могла понять с кого синхронизировать).

Полезные новости(ещё не опробованные):
StarWind Virtual SAN for vSphere (гиперконвергентное решение), позволяет встраивать в кластер виртуализации Vmware без привязки к Windows серверам(на базе линукс виртуальных машин).

Резюме: Отказоустойчивое решение, при наличии нормальной программы замены аппаратных серверов по окончании гарантии и наличии технической поддержки StarWindSoftWare.

2. Как сделать маленькое Enterprise СХД

Постановка задачи:

Создать отказоустойчивую сеть хранения данных небольшого объема итого 4 TB-20TB, с гарантированным функционированием в среднесрочной перспективе без значительных дополнительных финансовых затрат.

• Cистема должна быть отказоустойчивой (спокойно переносить выход из строя, как минимум одного коммутатора, одного сервера, дисков и сетевых карт в сервере).
• По максимуму использовать все ресурсы имеющегося аппаратного парка серверов (3-10 летних серверов и коммутаторов).
• Обеспечивать функционирование томов разных уровней: All-Flash и HDD +SSD cache.

Исходные данные:

• ограниченный бюджет;
• оборудование поколения 3-10 летней давности;
• специалисты — «Не Linux- Guru».

Расчет характеристик

Чтобы избежать узкие мест в части производительности при использовании SSD дисков, которая будет срезаться, чем то из цепочки оборудования: сетевые карты ,RAID (HBA) контроллер, экспандер (корзина), диски.

Необходимо на момент создания предусмотреть исходя их требуемых характеристик определенную конфигурацию оборудования.

Можно конечно запустить на 1Gb/s сетях и 3G контроллерах конфигурация с SSD кешированием SAS HDD, но результат будет в 3-7 раз хуже, чем на 6Gb RAID и 10Gb/s сетях (проверено тестами).
В инструкции по тюнингу VxFlexOS описана простая инструкция по расчету необходимой пропускной способности, исходя из оценки SSD -450 МБ/C и HDD -100 МБ/C, при последовательной записи (на пример при ребалансе и ребильде серверов хранения).

Например:

• (SSD кэш + 3 HDD), получаем ((450*1)+(3*100))*8/1000= 6Гб
• (ALL FLASH SSD) + (SSD кэш + 3 HDD) ((450*2)+(3*100))*8/1000= 9,6Гб

Для определения пропускной способности сети по IOPS (штатная нагрузка на серверах баз данных и нагруженных виртуальных серверах), есть ориентировочная таблица от StariWindSoftware

Итоговая конфигурация:

• ПО СХД, которое может не объединять диски в RAID-массивы, а передавать их СХД в виде отдельных дисков (чтоб не было проблем с заменой через определенный период дисков при выходе их из строя, а просто подбирать их по емкости);
• Сервера Поколения процессоров e55xx- x56xx и выше, шинами pci-express v 2.0 и выше, Raid (HBA) контроллерами 6G -12Gс памятью, корзинами экспандерами на 6-16 дисков;
• Коммутаторы SMB 10G Layer 2 (JUMBO FRAME, LACP).

Способ решения

На данный момент не найдено бюджетных вариантов «Аппаратных Enterprise СХД» маленького объема, с указанными выше требованиями.

Остановились на программных решениях, позволяющих пользоваться преимуществами Enterprise СХД, при варианте использования существующих серверов, которые при этом варианте имеют право умереть от старости без ущерба СХД.

• Сeph — не хватает Linux специалистов;
• EMC ScaleIO — за пару лет технической поддержки — можно обойтись существующими кадрами.
• (как оказалось, познания в Linux можно иметь минимальные, об это дальше в шпаргалке).

3. История разгона IOPS (бюджетная практика)

Для ускорение операций чтения, записи в систем хранения применялись SSD устройства:

3.1. Контролеры с функциями SSD кэширования.

В 2010 году появились RAID контролеры с функциями SSD кэширования Adaptec 5445 с MaxIQ диском(для ощутимого результата нужно было иметь хотя бы 10% MaxIQ диска от объема кэшируемого тома), результат есть но незначительный *проверено на себе;
Позже появились контролеры которые могут использовать произвольный SSD диск для кэширования, как у Adaptec серия Q, так и LSI CacheCade ( но там лицензирование отдельно);

3.2. Программное кэширование с использование дисков, типа Intel DC S3700, которые видит контроллер и экспандер брендовых серверов HP, IBM, FUJI ( большинство серверов их удачно опознает, для All-Flash дороговато, а вот для 10% на SSD cache — терпимо не выпуски их под партномерами IBM, HP, FUJI, а просто Intel). *Но сейчас есть более дешевые совместимые варианты(см.п. 3.5.);

3.3. Программное кэширование с использование адаптера PCIe- M.2, SSD Synology M.2 M2D18 , проверено, работает и в обычных серверах( не только в Synology), полезно когда RAID контроллер и корзина отказывается видеть SSD, которые не указал производитель в совместимых (н.п. HP D2700)? *;

3.4. Гибридные диски Seagate EXOS, н.п. 600Gb Seagate Exos 10E2400 (ST600MM0099) {SAS 12Gb/s, 10000rpm, 256Mb, 2.5″}, * проверено опознается серверами HP,IBM, FUJI (альтернатива вариантам 3.1.-3.3.);

3.5. Диски SSD c большим ресурсом и сопоставимой ценой с SAS корпоративного класса,
Crucial Micron 5200 MAX MTFDDAK480TDN-1AT1ZABYY, *проверено опознается серверами HP,IBM, FUJI
(альтернатива вариантам замены HDD дисков на совместимые по п.3.4 и совместимые со старыми серверами SAS диски: Жесткий диск SAS2.5″ 600GB AL14SEB060N TOSHIBA*,
C10K1800 0B31229 HGST, ST600MM0099 SEAGATE ). Позволяет бюджетно перейти от HDD+SSD, к All-Flash томам.;

4. Шпаргалка по развертыванию и эксплуатации СХД EMC ScaleIO (VxFlexOS) 1часть

СХД EMC ScaleIO (VxFlexOS)

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

Аппаратная часть:

FUJI CX2550M1 (E5-2xxx)– 3 шт. (основной кластер виртуализации серверов VmWare VSphere + ScaleIO клиент SDC и сервер SDS);
+5 серверов поколения HP G6(G7) или IBM M3 (e55xx-x56xx) — сервера ScaleIO SDS;
+ 2 коммутатора NetGear XS712T-100NES

На работающем СХД в режиме RFCache, удалось при помощи Iometer разогнать до 44KIops

Конфигурация СХД:

12TB сырой емкости(минимальная лицензия на момент когда еще продавалась как софт)

8 серверов SDS 28 дисков

Read RAM cache 14 Gb

Read Flash cashe 1,27 TB (RFCashe)

В промежуточном варианте, где только 3 серверах 2х10Gb имеют сетевые карты, в остальных 2 х1Gb.

Наглядно видно, что даже при SSD кэшировании при 1Gb вместо 10Gb, идет потеря пропускной способности SDS в три раза и более, при идентичных носителях.

Без кеширования, если считать по данным «нормативам» то при 28 дисках HDD,
получим 28Х140=3920 IOPS, т.е. чтобы получить результат в 44000 IOPS нужно было бы в 11 раз больше дисков. Экономически выгодней при малых потребностях в объемах, не увеличивать количество дисков а, SSD кэш.

На вопрос, зачем такие скорости при маленьком объеме, отвечу сразу!

Есть такие маленькие организации(как наша), в которых есть большое количество электронных документов, которые в программном комплексе обрабатываются долго (контроли каждого реестр на отправку ПП до 1 часа, даже на этом разогнанном СХД). Все остальные варианты уже применены ранее (увеличение на РМ -ОЗУ, CPU i5, SSD, 1Gb- NET). Даже применение на СХД только связки SSD+SAS (пока без ALL-Flash) позволило использовать большую часть ресурсов серверов виртуализации, перенос нагруженных ВМ на ScaleIO — увеличил загрузку процессоров FUJI CX400M1 в два раза (ранее сдерживало хранилище).