Личные Best Practise построения SAN?

Question

[Vi]

Я особо с таким редко работаю, но вот появилась задача организовать storage. Имеется разнообразное железа от производителя Dell, и какое то количество SaS дисков, по 150-300 гигобайт.
Есть несколько серверов в которые можно вставить до 10 дисков, с рейд контролерами позволяющие строить рейды 1, 0, 01, 10, 5, 6 etc
Я бы хотел собрать кластер iscsi(не знаю правильных названий), чтобы подключаться к нему и хранить на нем виртуалки для миграции между серверами(имеется ввиду виртуализация на самом сервере который играет роль хранилища) - звучит прикольно но даже не знаю применяется ли такое и как.

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

Для меня эта тема новая, пока организовал только Centos 7, + Raid5 5Disk 250GB + LVM (две группы)
что дальше делать не знаю. думаю поднять еще одну точно такую же систему и использовать DRBD для синхронизации данных.

Прошу советов картинок, шутливых расказов.

Answer 1

[Армянское Радио]

Правила такие
1. RAID5 - последнее дело. Статистика показывает, что вероятность выхода из строя диска во время ребилда - более 70%. Выход из строя второго диска как правило означает, что массив можно выбрасывать.
2. Создание RAID средствами аппаратного контроллера - плохая идея. Вы таким образом создаете единую точку отказа (этот самый контроллер). Если контроллер выйдет из строя, вам придется искать ему замену (такой же точно контроллер с той же прошивкой), иначе данные из массива будет очень сложно выудить.
3. Centos содержит придурочный NetworkManager (и systemd, но последнее еще можно пережить). А вот управление сетью через dbus - пережить сложно. Или выламывайте NetwokManager, или переходите на нормальный дистрибутив - SuSE
4. Классика кластеростроения для виртуалок и миграции, вариант 1.

Два сервера, на серверах массивы RAID10. Диски отдаются в мир через DRBD в режиме active-active.

Поверх дисков работает распределенная кластерная система OCFS2.
Управление кластером осуществляет pacemaker.

RAID10 - это массив, сочетающий относительно высокую надежность (должно выйти из строя не менее половины всех дисков массива) и относительно высокую скорость работы (за счет разбивки файла по дискам)

DRBD - это такой сетевой RAID1. Данные во время работы реплицируются между узлами, так что остановка одного узла из пары не приводит к остановке хранилища.

OCFS2 - это кластерная ФC, которая позволяет куче машин видеть одно блочное устройство как свою локальную ФС. В ней работает отображение файлов в память и глобальные блокировки. И самое полезное для виртуалок - есть возможность создавать reflink. Reflink - это моментально создающаяся копия файла (образа диска виртуалки). Для новой копии, OCFS2 будет только хранить отличия от первоначального файла.

pacemaker - это менеджер кластера+балансировщик нагрузки.

Как это все поднять?

1. Ставите на все машины OpenSuSE 42.1
2. Собираете RAID10 через LVM (для этого есть GUI - Yast называется)
3. В том же YAST поднимаете DRBD
4. Ставите пакет ha-cluster-bootstrap
5. На одном из узлов делаете ha-cluster-init и следуете его инструкциям
6. На остальных узлах делаете ha-cluster-join

Это в общих чертах, задавайте вопросы.

Comments

[Vi]

Я не против поставить и OpenSUSE и использовать его, но вот не очень понял доводы против CentOS, systemd - как по мне клевая штука, но вот нюансы про NetworkManager и dbus я не знаю(можно ли тут поподробнее)

Непротив я и изменить Raid с 5 на 10.
OCFS2 плохо понял что это такое, буду разбираться.

[Армянское Радио]

Vi: Отправляйтесь на xgu.ru и читайте статьи. Судя по всему - все.

Answer 2

[Karmashkin]

как менее модный вариант: freebsd+zfs+hast.

Answer 3

[Vadim K]

freenas+zfs+raidz2

Answer 4

[athacker]

SAN -- это несколько сложнее, чем просто пачка серверов с дисками, включенные в сеть :-)

> Я бы хотел собрать кластер iscsi(не знаю правильных названий), чтобы подключаться к
> нему и хранить на нем виртуалки для миграции между серверами(имеется ввиду
> виртуализация на самом сервере который играет роль хранилища)

Вы смешали в кучу целую кучу понятий, простите за каламбур :-) iSCSI -- это, если на пальцах, сетевая версия протокола SCSI, который предназначен для доступа к блочным устройствам (хранилищам) через сеть.

Миграция -- оно совсем никакого отношения к iSCSI не имеет, и реализуется целой кучей технологий, далеко не только с помощью iSCSI-хранилищ.

"виртуализация на самом сервере, который играет роль хранилища" -- это то, что по-модному называется "конвергентная система". И реализуется отдельной пачкой технологий и продуктов, совсем не обязательно включающих в себя iSCSI.

В общем, в зависимости от того, что конкретно вы по итогу хотите получить, сценарии и используемый софт будут разными. Блочное хранилище, миграция и конвергенция -- вещи, конечно, связанные, но не одно и то же. Примерно как Карл Маркс и Фридрих Энгельс или, если угодно, Ленин и партия ;-)

Отвечу по последнему пункту, по конвергентной системе. Если есть желание добиться именно этого, то совсем бесплатно и с большим геморроем можно посмотреть в сторону ceph. На сервера можно поставить линукс, на линукс какой-нибудь гипервизор (типа KVM), а также компоненты ceph. И устроить из всего этого конвергентную систему.

Есть вариант реализовывать хранилище на виртуальных машинах. Т.е. в первую очередь ставится гипервизор, на нём разворачивается некоторое количество виртуальных машин, в которые презентуются диски с серверов, а потом на основе этих виртуалок сшивается общее хранилище. Так делает EMC ScaleIO, например. По сравнению с Ceph, ScaleIO гораздо проще и логичнее устроено, имеет компоненты и драйвера доступа для линукс, винды и драйвера напрямую под ESXi (т.е. не надо морочиться с сетевыми протоколами типа iSCSI или NFS). Но есть и недостатки -- оно бесплатно официально только для тестовых окружений. Соответственно, в продакшене можно юзать только на свой страх и риск, поддержки от производителя не будет. И оно не очень хорошо документированно по части своих внутренностей. Есть мануалы "как развернуть" и "как управлять", а вот мануалов "как оно может сломаться, почему, и как это чинить" -- увы, нет. Тут только либо натурными экспериментами, либо с помощью сообщества (оно небольшое, но есть), либо забить и использовать что-нибудь другое :-)

Comments

[Vi]

путаюсь в понятиях тк не знаю как все обьединить одним словом. упоминул ISCSI так надеясь задать тему блочноых устройст соединеных по сети.
Обязательно посмотрю в сторону ScaleIO и Ceph.

Конечный результат это гипервизоры подключенные по сети к хранилищю чтобы сохранять там виртуалки и мигрировать их между друг другом(это как минимум).

А скажите какие преищусетва мы получаем от конвергентной системы? я по правде не знаю, и спрашивал выше чтобы узнать что это дает

[athacker]

Vi: при классической схеме организации виртуализации инфраструктура делится на три части: вычисления (т. е. собственно гипервизоры), сеть -- коммутаторы и пр., и хранилище -- СХД или NAS или любые иные виды.

При конвергентной структуре у нас выпадает необходимость в СХД как в отдельной сущности. А при гипер-конвергетной структуре -- ещё и в отдельных коммутаторах :-)

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

У нас используется ScaleIO в тестовом кластере VMware. В каждом узле стоит по 4 диска, в ESXi установлен драйвер, и на каждом хосте крутится виртуалка ScaleIO, в которую напрямую проброшен дисковый контроллер. И все эти виртуалки делают так, что из дисков, воткнутых в хосты виртуализации мы получаем 13-терабатное хранилище с резервированием и возможностью линейного роста -- добавили ещё один узел, наторкали туда ещё дисков, на узел накатили ESXi, развернули ещё одну ScaleIO-шную виртуалку, и у нас появился одновременно ещё один узел виртуализации и заодно расширилось дисковое пространство в кластере.