DAS (Direct Attached Storage). Это выглядит привычно: один сервер - один дисковый массив. К слову сказать, ранее было куда привычнее видеть схему: один сервер и внутренние диски в нем.
Типовая схема DAS:
Чем хороша схема DAS:
-
Надежность. Мы понимаем, что выход из строя дисковой системы затронет только сервер, к которому она подключена. Если сервер обслуживает критически важные данные, мы хотим защититься от сбоев и ставим дисковую систему с двумя контроллерами и диски с двойным подключением.
-
Простота. Здесь все понятно и привычно – есть сервер, в нем есть оптическая карта или SAS адаптер, есть дисковый массив с портами FC или SAS. Мы подключаем одним или более кабелями сервер к массиву. Все предельно понятно и просто – мы вынесли дисковую систему из сервера во внешнее устройство и подключили это устройство кабелями.
Далее, мы строим систему резервного копирования. Обычно это выделенный сервер с устройством хранения на лентах либо варианты (диски, оптика). Либо сам сервер имеет встроенный ленточный накопитель. Резервное копирование делается путем передачи данных через сеть Ethernet: от сервера, содержащего данные к серверу резервного копирования и далее на ленты. И хорошо, если передача данных сделана по отдельной сети Ethernet, а не по тем же каналам, где работают пользователи.
Теперь ситуацию развиваем дальше. У нашего сервера есть еще узкие места и недостатки кроме дисковой системы – это сам сервер! Обычно ставят второй (резервный сервер). И этому серверу также требуется дисковый массив.
Далее появляются дополнительные сервисы, которые устанавливать необходимо на отдельные серверы (новые). Совмещать приложения далеко не всегда есть возможность. И появляется парк серверов, со своими дисковыми массивами, устройствами резервирования и так далее.
Далее ситуация идет по пути: приложение требует больше ресурсов. Если ресурс, которого не хватает это дисковая система, делаем:
a. резервное копирование
b. устанавливаем новый массив – тут обычно получается так, такие же массивы, как были ранее в работе, уже не выпускаются, есть новые модели и они отличаются. Разбираемся, ставим, подключаем.
c. Восстанавливаем данные с ленты на массив.
Все время замены – это время простоя приложения.
Если ресурс, которого не хватает это серверный ресурс (ЦПУ, память) то делаем:
a. резервное копирование
b. установка нового сервера – тут обычно так, сервер покупается новый и более мощный, другие драйверы, другое управление. Разбираемся, ставим, подключаем.
c. Работаем с массивом и данными что остались на нем от старого сервера.
Время подключения сервера к массиву – время простоя. Это обычно время установки ОС, патчей, ПО приложений, драйверы.
Если посмотреть на ситуацию, когда групп сервер-массив становится более двух-трёх, мы видим, что мы должны поддерживать парк различных устройств.
Еще один немаловажный момент, который часто встречается – у одного сервера дисковый массив новый и содержит дисковое пространство в избытке, а у других серверов наблюдается дефицит дискового пространства. И хотелось бы отдать избыток дискового пространства другому серверу, но это невозможно.
Итог DAS:
- Надежен и прост.
- Менее затратен на этапе внедрения
- Дорог при модернизации и замене, если групп сервер-массив более двух-трех
- Не эффективен в распределении дискового пространства
- Простой приложений при авариях занимает значительное время
- Большое окно резервного копирования
Попробуем шагнуть дальше по технологиям.
Первым шагом считаем внутренние диски в серверах, вторым шагом – внешние дисковые массивы с подключением DAS. Третий шаг – SAN. Это по сути своей развитие технологии DAS. Мы имеем дисковый массив, состоящий из:
- Пары высокопроизводительных RAID-контроллеров
- Различные КЭШ на уровне контроллер-сервер и на уровне диск-контроллер.
- Дублированных источников питания
- ПО управления и сервисные функции
В итоге дисковый массив в среде SAN не должен иметь единой точки отказа. Контроллеры в паре, каждый диск имеет двойное подключение (DualPort), дублированное электропитание, батареи для хранения информации в кэш в случае аварийного отключения питания, также благодаря наличию батарей мы имеем возможность включать режим кэш Write-Back, что существенно увеличит скорость отработки запросов записи.
SAN не ограничивается дисковым массивом. Обязательные элементы технологии – массив,фабрика и ПО (программное обеспечение). Фабрика – это пара оптических коммутаторов, которые коммутируют соединения между хостами и массивами в SAN плюс ПО.
ПО имеет огромное значение. Надо сказать, что ПО в SAN работает на фабриках, массивах и хостах.
На хостах: это драйверы оптических карт (FC HBA) и механизм множественных путей доступа, которая обеспечивает возможность соединения по всем возможным путям доступа от сервера к дисковым ресурсам а также механизм балансировки трафика по этим путям.
На фабрике: это ОС (операционная система), которая выполняет функции маршрутизации трафика, создание зон доступа (разделение различных хостов друг от друга), сервера имен.
На массиве: это ОС, которая выполняет огромное количество функций (зависит от производителя). Например функции управления и создания LUN, маскирование, зонирование, мгновенные снимки, репликация и так далее….
Перенесем нашу схему из DAS в SAN:
Итак, что мы получили? У нас появилось новое звено – фабрика. Это звено необходимо, потому что SAN подразумевает множественный доступ устройств. Кроме того, среда может быть гетерогенной, то есть, серверы могут быть под управлением ОС Windows, Linux, Solaris и так далее. В качестве примера приведу проблему, когда сервер под управлением Windows перегружается, происходит посылка команды SCSI_RESET по шине SCSI. Если мы не разделим серверы по зонам, то этот сигнал получат все серверы и поскольку разные ОС по разному реагируют на разные сигналы, то например сервер под управлением HP-UX также перезагрузится. Кроме того есть соображения безопасности и элементарной необходимости, когда нельзя показывать LUN одного сервера – другому. Проблемы могут быть различными – например монтирование LUN с файловой системой UFS на двух и более серверах, приведет к порче данных.
Дисковых массивов в среде SAN может быть от одного и более. Ленточных устройств так же может быть несколько.
Дисковые массивы обычно имеют по два порта на каждый контроллер для подключения хостов. Обычно каждый контроллер подключается к каждому свитчу фабрики. Хосты для коммерческих приложений также обычно имеют по два FC адаптера и подключаются к каждому свитчу. Таким образом хост соединен двумя путями с каждым контроллером. В случае аварии на одном из двух свитчей или на одном из контроллере массива, хост имеет всегда второй путь доступа к своим дисковым ресурсам.
Рассмотрим ситуации:
1. На сервере 1 установлено приложение, которое требует 500Гб дискового пространства. Со временем требуется увеличить объем до 700Гб. Мы делаем:
- на массиве расширяем LUN до 700ГБ
- на сервере на уровне ОС расширяем файловую систему
- работаем дальше
Приложение останавливать не требуется.
2. Сервер 2 перестал отвечать требованиям приложения. Мы покупаем новый сервер, подключаем его в SAN, с помощью ПО массива и фабрики разрешаем доступ новому серверу к LUN старого сервера, и работаем дальше.
3. Сервер 3 больше не может работать в качестве сервера СУБД и потому мы бы хотели дисковое пространства с сервера 3 отдать другим серверам. Мы делаем удаление LUN сервера 3 и автоматически происходит отдача объема в пул массива. Мы имеем возможность добавить объем другим северам как указано в первом пункте.
4. Сервер 4 обслуживает приложение, которое требуется бэкапить. Окно бэкапа составляет час. Если объем данных для бэкапа очень велик и не может быть передан на ленты за один час, мы делаем :
- останавливаем приложение
- создаем снимок (snapshot)
- запускаем приложение
- делаем резервное копирование не мешая работе приложения
5. Требуется понять причину неверной работы базы. Есть рабочий сервер СУБД и есть тестовый. Нам нужно сделать копию рабочей базы на тестовую. Мы делаем:
- останавливаем СУБД
- создаем снимок
- запускаем СУБД
- с помощью ПО массива и фабрики разрешаем доступ к снимку тестовому серверу
- монтируем базу на тестовом сервере и работаем
время создания снимка составляет минуты.
6. Бэкап делаем при помощи технологии Serverless Backup, которая подразумевает передачу данных от массива к ленточному устройству по оптике минуя Ethernet и бэкапный сервер. Тем самым уменьшается время восстановления и бэкапа данных, очень существенно снижается нагрузка на сеть и на серверы! Если бэкап делать с помощью снимков (snapshot), мы реально снижаем простои приложения на порядки.
Кроме того, есть возможности и такие:
1. Использовать различные диски – например для СУБД установить диски FC, которые стоят дорого но очень производительны, а для приложений типа файловых архивов можно установить дешевые медленные но большого объема диски SATA. Делаем различные пулы (наборы дисков) и создаем на базе этих пулов виртуальные диски (LUN) и отдаем их в работу серверам.
2. При недостатке дисков в массиве, имеется возможность без остановок массива и приложений добавить диски в систему.
3. В SAN можно включать серверы под управлением различных ОС
4. В SAN можно включать несколько дисковых массивов.
5. В SAN можно подключить старые дисковые массивы, которые работают на шине SCSI через специальные устройства-преобразователи SCSI-FC.
6. SAN позволяет делать репликацию данных между массивами (в том числе географически удаленными) без привлечения серверов.
7. SAN может включать в себя устройства, позволяющие конвертировать и предоставлять доступ к ресурсам SAN посредством iSCSI, NAS.
8. SAN имеет единое управление инфраструктурой.
9. На сегодня стандарт соединения по оптике составляет 4Gb.
Что плохо в SAN.
- На этапе внедрения затраты будут очевидно выше чем при внедрении DAS. Но стоит рассматривать ближайшее будущее. Стоимость владения в итоге окажется ниже.
- У каждого устройства есть свои пределы возможностей. Когда то придет время замены дискового массива на более мощный. Эта операция конечно же потребует простоя приложений. Но даже в этом случае этот простой можно свести к минимуму! Новый массив включаем в SAN, один из серверов делаем управляющим процессом (если конечно массивы разные по своей природе и нет возможности использовать репликацию). Далее процесс выглядит так. Останавливаем приложение, делаем копию данных по оптической сети данных со старого массива на новый, отдает LUN с данными с нового массива серверу – работаем. Замена фабрики не составляет труда и ее можно провести без простоя приложений.
- Консолидированные дисковый массив может содержать сотни физических дисков. Как известно, чем больше дисков, тем чаще будет происходить их замена. Потому настоятельно рекомендуется приобретать поддержку системы SAN. Также это касается и поддержки ПО массива и фабрики.
