StorageTek QFS

Часто для работы проектов требуется совместный доступ к одной общей файловой системе. Для Linux я бы в такой ситуации использовал GFS + Cluster Suite. Для Solaris я опробовал QFS.
Я не описываю подробности зачем и для чего нужна эта система, для этого есть документация. Мои заметки создаются для того, что бы быстро вспомнить как сделать на практике то, с чем однажды пришлось повозиться. Документация по SAM-FS есть на сайте docs.sun.com.
Итак, мне необходимо сделать общую файловую систему, например, для трёх серверов. Все три сервера подключаем к дисковому массиву по оптике. На массиве создаются LUN для работы QFS.
В моем примере:
1. сервер prima - активный metadata server
2. сервер secunda - потенциальный metadata server
3. сервер t2000 - клиент.

Файловая система будет доступна на чтение-запись всем трём серверам.
Надо сказать, что QFS по своей структуре имеет один активный META-сервер и до 3-х потенциальных META-серверов. Если мы не используем Sun Cluster, то переключение на потенциальный META-сервер производится вручную.
Типы работы и варианты построения смотреть в документации.
Строим файловую систему в которой указываем тим MA (раздельные устройства для данных и мета-информации). Для увеличения производительности и надежности я использую два LUN для мета-данных и два LUN для данных.
Сделаем четыре LUN на дисковом массиве. Причем учитываем тот факт, что размер мета-устройства расчитываем как примерно 10% от объема данных. И еще, используя Lun Masking (Domains) сделаем так, что бы LUN для мета-данных были доступны только мета-серверу и всем потенциальным мета-серверам (в нашем варианте prima, secunda), а LUN с данными - всем серверам. В этом случае обмен мета-данными происходит по Ethernet, а доступ к данным - по оптике.
Установку пакетов ПО QFS я опускаю - это делается как обычно (скачиваем 4.6 версию, она бесплатна и pkgadd). Замечу, что система состоит из SAM и QFS. SAM мне не нужен для работы, поскольку это система применяется в случаях, когда нужно обеспечить движение данных между носителями, в зависимости от их частоты использования - менее нужные данные перемещаются на более медленные и дешёвые носители, более востребованные - на быстрые диски. В моем примере ставим только пакеты QFS (SUNWqfsu, SUNWqfsr). Прописываем в .profile пути к испольняемым файлам $PATH:/opt/SUNWsamfs/sbin:/opt/SUNWsamfs/bin/opt/SUNWsamfs/tools.
пусть будут активны:
#. /.profile

Теперь начнем настройку с мета-сервера.
- Конфигурационные файлы лежат здесь: /etc/opt/SUNWsamfs.
- отработаем разбивку дисков (format). Я делал разбивку так, что оставлял только раздел s2 - весь диск.
- создаем основной файл - mcf:
в моем примере это такой:
------------------------------------------------------------------
vn1 10 ma vn1 on shared
/dev/dsk/c4t600A0B80002A3F9200000D41482CEF2Ad0s2 11 mm vn1 on
/dev/dsk/c4t600A0B80002A3F9200000D49482CEF5Cd0s2 12 mm vn1 on
/dev/dsk/c4t600A0B80002A3F9200000D39482CEEF0d0s2 13 mr vn1 on
/dev/dsk/c4t600A0B80002A3F9200000D59482CF264d0s2 14 mr vn1 on
----------------------------------------------------------------

Что здесь такое:
первая строка описывает имя файловой системы - vn1. По этому имени потом будем обращаться к этой файловой системе. 10 - это уникальный идентификатор записи. MA - тип построения файловой системы, при котором мы содержим мета-данные на отдельный разделах от данных. (можно совместить мета и данные указав тип MS). Снова vn1 - это уже имя семейства, по которому будут объединяться строки в этом файле (у нас может быть много файловых систем, и что бы понимать для какой файловой системы что описано, применяется это имя). Ключ ON - говорит что файловая система включена (активна). И последнее поле SHARED - говорит о том, что мы создаем разделяемую файловую системы (то есть эту файловую систему могут смонтировать более одного хоста одновременно).
вторая и третья строка отписывают разделы для хранения мета-данных. Тип у этих разделов как видно - MM. 11 и 12 - уникальные идентификаторы строк. VN1 - имя семейства, к которому относятся эти строки. ON - разделы активны.
четвертая и пятая строка описывают два раздела для данных. Тут все так же как и у разделов для мета-данных, за исключением типа - здесь MR. Кстати тип у разделов данных может быть не только MR. MR в этом случае указывает на то, что будет использоваться алгоритм Round-Robin. Можно указать MD и указать при монтировании тип доступа как Striped. Или же указать тип gXXX, что сделает возможным описать Stripe-группы. А потом к этим группам привязать определенные каталоги файловой системы! Ну например для видео-файлов и музыки можно сделать две Stripe-группы. В первой будут хранится видео-файлы для обработки которых требуется обеспечить большую производительность. И мы делаем эту Stripe-группу состоящей из множества устройств (дисков на разных контроллерах например). Для музыки же может указать только один диск. Также можно указать различную ширину полосы доступа к группам (от 16 кб до 64 Мб).

Далее создаем файл hosts.vn1
именно такое имя: hosts.XXX, где XXX имя нашей файловой системы в файле mcf. Для каждой файловой системы , описаной в mcf мы делаем такой отдельный файл. Это удобно и гибко если мета-сервер один а файловые системы разные и клиенты у них разные. Если все клиенты и серверы одинаковые, делаем общие настройки в default.conf.
Мой вариант файла для примера:
prima 172.16.112.10 1 0 server
secunda 172.16.112.15 2 0
t2000 172.16.112.2 0 0

ВНИМАНИЕ! Имена в первой колонке обязательно должны совпадать с тем что выдает hostname на каждом из участников!
Первая колонка - имя сервера, вторая - адрес, третья - приоритет, 0 - группа, server - указывает что это активный мета-сервер.

делаем также и третий файл: hosts.vn1.local, где указываем пару имя-адрес мета-серверов (включая потенциальные):
prima 172.16.112.10
secunda 172.16.112.15

теперь проверим наши настройки на ошибки:
#sam-fsd
если есть проблемы - исправляем

далее сконфигурим систему:
#samd config

далее создаем файловую систему:
#sammkfs -S vn1
-S потому что мы делаем разделяемую файловую систему. (можно было сделать не разделяемую файловую систему и потом сконвертить впоследствии в разделяемую и наоборот)

создаем точку монтирования
#mkdir /vn
chmod 755 /vn

Теперь добавим строчку в /etc/vfstab для монтирования файловой системы:
vn1 - /vn samfs - yes stripe=0,shared

stripe=0 потому что мы указали тип разделов данных как MR.

Если после установки пакетов QFS мы не перегружали сервер, запустим службу QFS:
#/etc/rc2.d/S73samfs.shared
тут же будет произведена попытка смонтировать файловую систему vn1.
Если же запуск уже производился, то монтируем вручную
#mount vn1

ну вот уже есть у нас теперь файловая система, к которой мы можем обращаться как обычно.
Проверим что говорит статистика:
#samfsinfo vn1

можно еще запустив samu, посмотреть что где и как делается.

Не забудем глянуть файл default.conf. Там все параметры замаркированы. Они понятны в основном по названиям (а те что не понятны - читаем документацию или не трогаем).
---------------------------------------------

Теперь займемся потенциальным мета-серверов.
первым делом отработаем разделы командой format НО! не трогаем разделы а только сомтрим на них.А точнее на их имена. например в нашем примере LUN c4t600A0B80002A3F9200000D39482CEEF0d0 навтором сервере может иметь другой номер контроллера, как у меня в примере:
vn1 10 ma vn1 on shared
/dev/dsk/c5t600A0B80002A3F9200000D41482CEF2Ad0s2 11 mm vn1 on
/dev/dsk/c5t600A0B80002A3F9200000D49482CEF5Cd0s2 12 mm vn1 on
/dev/dsk/c5t600A0B80002A3F9200000D39482CEEF0d0s2 13 mr vn1 on
/dev/dsk/c5t600A0B80002A3F9200000D59482CF264d0s2 14 mr vn1 on

на первом сервере контроллер C4, на втором - C5.
Заметим, что мы указываем все разделы - и данные и мета-данные, ведь это потенциальный мета-сервер, а значит, он когда-то может стать активным мета-сервером.
Кстати, все потенциальные и мета-серверы ДОЛЖНЫ быть одинаковой архитектуры! нельзя смешать Sparc и x64.
Так же создаем файл hosts.vn1 - проще всего скопировать с мета-сервера.
Также делаем каталог для монтирования и добавляем строчку по аналогии в vfstab.
Монтируем файловую систему:
#mount vn1

Если все хорошо прошло - имеем файловую систему на двух серверах одновременно и можем читать и писать туда. Если есть проблемы, активируем журналы:
/etc/syslog.conf:
local7.debug /var/adm/sam-log
touch /var/adm/sam-log
рестарт syslog

монтируем снова и смотрим, где беда. Самая распространненая проблема - не соответствие имени хоста в hosts.XXX и имени что выдает команда hosts. Так же часто есть беда при ошибке в адресах. Все проверяем и при внесении изменений в файл mcf или hosts.XXX выполняем samd config. Кстати если внесены критические изменения в файлы (смотрим в доках что именно так называется), то на активном мета-сервере выполняем:
#samsharefs -u vn1
это если файловая система смонтирована
и
#samsharefs -u -R vn1
если не смонтирована

Не ошибаемся иначе все можно угробить.

Далее займемся третьим сервером - t2000. Он отличается от первых двух тем, что мы его называем клиентом и значит, он не имеет доступа к LUN с мета-данными. Отсюда и изменения в файлах. Итак файл mcf:
vn1 10 ma vn1 on shared
nodev 11 mm vn1 -
nodev 12 mm vn1 -
/dev/dsk/c4t600A0B80002A3F9200000D39482CEEF0d0s2 13 mr vn1 on
/dev/dsk/c4t600A0B80002A3F9200000D59482CF264d0s2 14 mr vn1 on

видно, что вместо разделов MM мы указываем ключ nodev.
Файл hosts.vn1 как и на предыдущих серверах
Но тут еще появится обязательно файл hosts.vn1.local, в котором указаны адреса мета-серверов:
secunda 172.16.112.15
prima 172.16.112.10
Хотя я лукавлю, он не обязателен, но его наличие дает тот эффект, что он читается первым если есть. Если его нет, то данные о мета-серверах будут получены из разделов с данными.

Запускаем samd config

Итак, делаем каталог для монтирования, добавляем строчку в vfstab и монтируем файловую систему.

Вот и все пожалуй - у нас три сервера с общей файловой системой. Для клиентов, которым нужен нужен доступ к этой файловой системе, но нет доступа к FC, сделаем им доступ по NFS.
Я опустил различного рода настройки производительности - их много и по ситуации и применению могут быть различными - все в документации. По умолчанию режим работы файловой системы установлен как Paged (buffered). Можно указать directio. А можно указать тип доступа вплоть до файла! (setfa). Поддерживаются квоты, расширение файловой системы, работа с большими файлами.

Самое интересное, что всегда хочется проверить, а что же случится, когда активный мета-сервер умирает. Сюрприз....
В документации очень сильно предупреждают, что нужно быть очень осторожными с экспериментами. Можно потерять мета-данные которые лежат в кэше. Итак умер мета-сервер. Самое простое - перегрузить его, или как-то вернуть его к жизни. Если не получается или же это долгий процесс, активируем потенциальный мета-сервер. Кстати, сменить активный мета-сервер на рабочей системе тоже можно, например мы собрались отправить активный текущий мета-сервер на профилактику и хотим передать его функции другому серверу. Делаем:
Если акливный мета-сервер жив и мы передаем функции потенциальному:
на существующем активном мета-сервере (prima) даем команду
#samsharefs -s secunda vn1

Если активный текущий мета-сервер умер и не поднимается, на потенциальном мета-сервере даем команду:
#samsharefs -R -s secunda vn1
терпеливо ждем отработки на клиентах! ПРоверяем работоспособность.
Когда после починки поднимется предыдущий мета-сервер он станет потенциальным.


Очень интересен был факт построения веб-системы, где на трех серверах создавались зоны, в глобальной зоне создавалась файловая система QFS, и передавалась в зоны в режиме только для чтения - зачем веб-серверу иметь права на запись:)

Вот пока и все.