Enterprise Storage OS (ESOS)
LVEE 2016
Enterprise Storage OS (ESOS).
Создание и обслуживание сетей хранения данных (Storage Area Network или сокращенно SAN) одна из интересных технических задач для технических специалистов обслуживающих системы хранения данных в различных компаниях. Прежде всего это обусловлено самой моделью SAN, и техническими требованиями предъявляемыми к системе хранения данных в целом, особенно с учетом широкого использования средств визуализации и необходимостью хранить большие объемы данных.
Очень часто техническим специалистам, сопровождающим крупные системы хранения данных, приходится решать трудные задачи, связанные с расширением объема доступного дискового пространства, надежностью хранения информации и интеграции с другими СХД, в частности с распределенными файловыми системами. Именно поэтому поиск оптимального решения подобных задач является критически важным, а оптимальный вариант должен обеспечивать должный уровень надежности, гибкости и возможности гибкого расширения без сложных структурных реорганизаций.
Поэтому вполне логично, что поиск решений для оптимизации и расширения существующей корпоративной архитектуры сети хранения данных начинается с решений на рынке свободного программного обеспечения (обзор некоторых из них был представлен мною в рамках доклада «Обзор решений на рынке открытого ПО для создания СХД» на зимней сессии LVEE в феврале этого года1). По совету коллег несколько лет назад я обратил внимание на один очень интересный проект Enterprise Storage OS (ESOS)2.
В ESOS основное внимание у меня привлекло возможность создания дисковых хранилищ для систем хранения данных модели SAN и возможности интеграции существующей SAN в объектное хранилище данных Ceph.
С физической точки зрения отдельное дисковое хранилище в SAN представляет собой законченное техническое решение состоящее отдельных дисковых полок (с установленных в них дисками) подключенных к контроллеру управления, а для подключения к сетевой инфраструктуре SAN на нем устанавливаются HBA (host bus adapter) адаптеры. Управление оборудованием осуществляется через консоль или по локальной сети через специальное приложение установленное на компьютере или web – приложение.
Но прежде чем приступить к описанию всех достоинств использования ESOS в SAN, необходимо кратко рассмотреть ее физическую и программную модели.
Физическая модель SAN состоит из трех основных компонентов: серверной фермы, сетевой инфраструктуры и дискового массива. В состав серверной фермы SAN входят сервера SAN не имеющих собственной подсистемы дисковой памяти и подключаются к сетевой инфраструктуре хранилища через специальный адаптеры HBA (host bus adapter). В состав сетевой архитектуры SAN входит активное сетевое оборудование (концентраторы, коммутаторы, мосты, маршрутизаторы) и пассивное оборудование (кабели, коннекторы). В состав дискового массива входят специализированные дисковые стойки (устройства состоящие из десятков дисков управляемые контроллером или сервером) подключаемые к сетевой инфраструктуру через адаптеры HBA.
Программная модель взаимодействия основных компонентов SAN между собой базируется на клиент-серверной модели семейства протоколов SCSI. Согласно ее клиентские приложения устанавливаются на сервера серверной фермы SAN, сервер выступает в роли инициатора (Initiator) сессии взаимодействия с целевым устройством (Target) в дисковой подсистемой хранилища через сетевую инфраструктуру SAN. Target обрабатывает команды адресуемые ему от Initiator и формирует ответ.
При казалось бы видимой простоте программной модели следует отметить важные моменты:
- взаимодействия между Initiator и Target осуществляется блоками заданной длины (т. е. все устройства представляются в виде сетевых блочных устройств);
- Target это логическое устройство которому присвоен уникальный номер, и с одним Target могут взаимодействовать несколько Initiator;
- Initiator не взаимодействует напрямую с дисками в хранилище данных, а использует одно или несколько логических устройств с уникальным номером — LUN (logical unit number);
- LUN абстрагирован от физической архитектуры дискового хранилища и представляет собой виртуальный диск созданный посредством специального ПО.
Таким образом, становится очевидно, первое, что сервер SAN подключенный с сети хранения данных напрямую не управляет физическими дисками подключенными к нему, все манипуляции с ними осуществляет через LUN (один или несколько) на Target. Второе Target может быть как отдельное физическое хранилище имеющий свой уникальный физический номер, так и может выступать как программный интерфейс к распределенной файловой системе через блочный интерфейс доступа. При этом логический номер Target присваиваться в программном обеспечении контроллера (сервера) управляющего дисковым хранилищем (Data Storage) или сервера на котором установлено программное обеспечение интерфейса блочного доступа к распределенной файловой системе или другому хранилищу данных.
При этом важно отметить, что сервера серверной фермы SAN не имеют собственной подсистемы дисковой памяти и с точки зрения физической архитектуры, LUN выделенный на Target для сервера, представляет собой обычный физический диск на который будет установлена операционная система для развертывания клиентского ПО. Следовательно программное обеспечение с помощью которого создается LUN должно поддерживать эмуляцию большинства типов файловых систем в том числе гипервизоров систем виртуализации, например, VMware.К моему удивлению все это было объединено в проекте ESOS. В его основе был положен проект SCST (Generic SCSI Target Subsystem for Linux)3, дополненный всеми необходимыми инструментами управления дисками (включая поддержку RAID-массивов), пакетами драйверов поддержки инфраструктуры SAN (оборудования производства QLogic, Emulex и других вендоров), мониторинга работы сервера и компонентами для поддержки пулов хранения в формате VMFS VMware ESX/ESXi, томов Windows NTFS и дисков Linux. Что дает возможность создавать хранилища данных (Data Storage) для SAN на базе серверов модели DAS1.
Также в состав компонентов ESOS входят модули поддержки распределенной файловой системы Ceph (в частности используется Ceph RBD в качестве оконечных устройств хранения данных) и поддержки кластеризации (Pacemaker&Corosync и DRBD).
Исходные коды ESOS находятся на GitHub 4 и компилируется виде Linux-дистрибутива с очень компактным кодом и распространяется под лицензией GPL. Ключевой особенностью ESOS является его полное резидентное расположении в памяти, при этом загрузка осуществляется с USB-накопителя и не требует отдельного диска для установки дистрибутива. При этом реализованы механизмы восстановления работоспособности системы в случае сбоев.
Ссылки
1 А. Клыга. Обзор решений на рынке открытого ПО для создания СХД // Материалы конференции LVEE Winter 2016, Минск, 12-14 ферваля 2016 г.
2 ESOS: ESOS – Enterprise Storage OS // ESOS
3 SCST GENERIC SCSI TARGET SUBSYSTEM FOR LINUX // SCST Project
4 The project ESOS on GitHub // ESOS on GitHub
Abstract licensed under Creative Commons Attribution-ShareAlike 3.0 license
Back