- серверы без дисков (только небольшие «зеркала» под систему) — 2 шт.;
- недорогая дисковая полка JBOD с двумя SAS интерфейсами – 1 шт.;
- HDD SAS – не менее 10 шт. (лучше – больше);
- SSD SAS – хотя бы 2 шт.;
- сетевые адаптеры 1-10 GBit (лучше – с поддержкой RDMA) – 2-4 шт.;
Подготовительные работы
Итак, берем дисковую полку в режиме JBOD. Набиваем ее дисками, хотя бы два из которых должны быть SSD. У корзины должно быть два SAS-экспандера, по два разъема на каждом. Через них подключаем корзину к двум серверам, желательно одинаковым. Для этой цели вполне подойдут простые одноюнитовые серверы. На серверах в качестве контроллеров устанавливаем обычные SAS HBA.
Далее по пунктам:
- Подключаем блочное хранилище с помощью SAS-интерфейса к двум серверам.
- Устанавливаем на каждый сервер ОС Windows Server 2012 R2.
- Настраиваем сетевые подключения, устанавливаем обновления, вводим серверы в домен.
- Добавляем роль Файловый сервер на каждом сервере.
- На одном из серверов открываем консоль Диспетчер отказоустойчивости кластеров.
- С помощью мастера создаем стандартный кластер с отработкой отказа (Failover Cluster).
- Создаем новый пул: Хранилище -> Пулы -> Создать новый пул.
- Добавляем в пул SSD и HDD диски, при необходимости указываем параметры доступа.
- Создаем виртуальный диск: Пул –> правый клик –> Новый виртуальный диск.
- С помощью мастера задаем тип дисковой подсистемы (Mirror).
- C помощью мастера создаем том на диске, присваиваем букву, форматируем в NTFS.
- Создаем общий кластерный том (CSV): Выбираем нужный диск -> Добавить в общие тома кластера.
- Задаем роль: Роли -> Настроить роль -> Файловый сервер -> Масштабируемый файловый сервер.
- Чтобы не ждать, сбрасываем кэш распознавателя DNS (ipconfig /flushdns).
- Выбираем роль -> Добавить общий файловый ресурс -> Общий ресурс SMB –> Профиль приложений.
- Указываем расположение общего ресурса, даем ему название.
Таким образом, мы получили готовую сеть хранения данных. Принципиальное отличие ее от традиционных SAN состоит в том, что для подключения используется протокол SMB 3.0, а не какой-то из блочных протоколов (iSCSI/FC), что в определенном смысле является даже преимуществом.
У кого-то может возникнуть желание развернуть роль Hyper-V прямо на кластерном сервере, разместив виртуальные диски на общем хранилище. Придется огорчить. К сожалению, такая конфигурация пока не поддерживается. Для ролей Hyper-V и SQL Server необходимо поднимать отдельные серверы, которые будут работать с нашей СХД по SMB-протоколу.
Осталось подвести итоги…
Отказоустойчивость
Обеспечивается на всех уровнях: хранения данных, серверов, сетевого взаимодействия.
Производительность.
Будет зависеть от нескольких факторов. В типичном случае сопоставима с производительностью решений на базе iSCSI. А в случае задействования всех имеющихся возможностей, включая технологию RDMA, пропускная способность СХД окажется даже выше, чем при FC-подключении (до 56 GBit/s).
Масштабируемость
На уровне дисковой подсистемы обеспечивается простым добавлением дисков или каскадированием хранилищ JBOD. На уровне серверов – добавлением узлов в кластер. На сетевом уровне – добавлением сетевых адаптеров, объединением их в группы (NIC teaming) или заменой их на другие, с большей пропускной способностью.
Безопасность
Дисковые пулы можно контролировать с помощью списков контроля доступа (ACL), а также делегировать полномочия администраторам. Управление хранилищами может быть полностью интегрировано с ADDS.
Стоимость
Очевидно, что даже при использовании всех возможностей, заложенных в данную технологию стоимость готового решения будет в несколько раз ниже традиционного SAN.
А как же недостатки? Разумеется, они тоже имеются. К примеру, СХД и серверы нельзя разнести на значительное расстояние, как в случае FC или iSCSI. Нельзя выстроить сложную топологию. Коммутаторы SAS – пока еще редкость. Кроме того, SAS не поддерживает аппаратную репликацию – ее придется реализовывать программными средствами.
Поэтому, описанная выше концепция – не панацея, а всего лишь альтернатива традиционным СХД. Если у вас уже есть развернутый аппаратный SAN, это ни коим образом не повод от него отказываться. Железо должно отрабатывать вложенные в него деньги. Но если вы пока еще только задумываетесь об архитектуре будущей системы хранения данных, имеет смысл рассмотреть и данный вариант, как вполне обоснованный с инженерной и экономической точек зрения.
Ну и напоследок хотелось бы отметить, что «суп из SAN» можно сварить не только на технологиях Microsoft. Если у вас имеется хранилище с интерфейсом iSCSI, можете воспользоваться такими продуктами, как StarWind iSCSI SAN, VMware Virtual SAN, Openfiler, FreeNAS, Open-E DSS V6 и т.п.
