Пожалуй самая популярная и распространенная на сегодняшний день версия кластерной файловой системы Xsan 3.1 от Apple вышла в составе операционной системы OS X 10.9 (Mavericks) еще в 2013 году. Это была усовершенствованная версия Xsan 3.0, дебютировавшей годом ранее в составе OS X 10.8 (Mountain Lion). Из таблицы ниже видно, что версия Xsan 3.1 поддерживает версии клиентов предыдущих версий систем на три поколения назад, вплоть до MacOS 10.6.8 (Snow Leopard). Это делало ее чрезвычайно универсальным решением в экосистеме Apple и она надолго закрепилась на многочисленных SAN (Storage Area Network) по всему миру. Многие до сих пор вынуждены использовать именно версию Xsan 3.1 и OS X 10.9 из за ограничений, вызванных системными требованиями оборудования и урезанного функционала старших версий Xsan.
Каждая версия OS X, выходящая следом, несла в себе новый Xsan, основанный в свою очередь на следующей версии файловой системы StorNext от Quantum Corporation.
1. При включении “Ignore permissions”, все клиенты должны быть также Xsan 5.
2. Для включения “case insensitivity”, все клиенты должны быть Xsan 2.3 или новее.
В 2016 году в составе macOS 10.12 (Sierra) была представлена Xsan 5, которая отличалась от предыдущих версий сильнее прежних. Ее основой стала StorNext 5.3, претерпевшая существенные переработки по сравнению со своими предшественницами.
В этой статье мы постараемся осветить наиболее важные изменения в Xsan за последние 5 лет и узнаем что нового приготовила для нас Xsan 5.
OS X 10.9, Xsan 3.1
Начнем с Xsan 3.1. Это последняя версия файловой системы, комплектовавшаяся графической утилитой Xsan Admin, универсальным инструментом, хоть и уступающим по функционалу терминальному набору команд начинающихся с cv (CentraVision File System — оригинальное название файловой системы StorNext) и snfs (StorNext File System), но обладающим богатым функционалом и наглядностью. Xsan Admin позволяла создавать новый SAN, управлять томами, клиентами и правами доступа.
Чтобы проследить развитие Xsan, мы создадим тестовый том Xsan 3.1 в 10.9 (Mavericks) и постепенно будем обновлять его версию, выполняя апгрейд в соответствиями с рекомендациями Apple. Создадим у тестового тома два пула с affinity “Video1”, “Video2” и убедимся, что функционал работает как положено. В будущем на каждой новой версии Xsan я буду соответствующим образом переименовывать том, для большей наглядности вывода команд:
$ snfsdefrag -r -k Video1 -m 0 /Volumes/Xsan31/1
1 file and 0 streams visited: 1 defragged, 0 skipped
$ cvaffinity -l /Volumes/Xsan31/1
/Volumes/Xsan31/1: Video1 (0x316f65646956)
$ snfsdefrag -r -k Video2 -m 0 /Volumes/Xsan31/1
1 file and 0 streams visited: 1 defragged, 0 skipped
$ cvaffinity -l /Volumes/Xsan31/1
/Volumes/Xsan31/1: Video1 (0x316f65646956)OS X 10.10, Xsan 4
Первое, что бросается в глаза после апгрейда на OS X 10.10 (Yosemite), это отсутствие Xsan Admin. Инструменты графического управления Xsan были сильно урезаны и оставшийся функционал теперь скромно представлен вкладкой Xsan в Server.app. Набор терминальных команд претерпел незначительные изменения в ряде командных ключей и остался доступен в полном объеме.
Для работы службы Xsan теперь обязателен мастер каталога Open Directory на контроллере метаданных, так как конфигурация SAN теперь хранится в LDAP. Кстати, с новым OD вы все еще можете использовать версию Workgroup Manager для 10.9 на OS X, вплоть до Sierra включительно.
При первом запуске вам будет предложено создать новый SAN, либо восстановить старую конфигурацию. Выбрав второй пункт, конфигурация (далее “конфиг”) нашего Xsan 3.1 будет сконвертирована в новый формат Xsan 4.0, после чего том запустится автоматически.
При пристальном изучении нового конфига, выясняется, что файл тома теперь имеет расширение .cfgp и имеет формат XML, в отличие от старого .cfg в формате Plain Text (ASCII). Из конфига пропал параметр Allocation Strategy отвечающий за выбор схемы записи в пулы. Схему нельзя выбрать и в Server.app, так что единственный способ управлять ей, это ручное добавление соответствующих строк в конфиг тома:
<key>allocationStrategy</key>
<string>round</string>Исходные значения StripeBreadth и FSBlockSize у тестового томы были:
FsBlockSize 16K
StripeBreadth 64В новом формате конфига они были автоматически изменены на байты:
<key>fsBlockSize</key>
<string>16384</string>
<key>stripeBreadth</key>
<string>1048576</string>Affinity созданные в прошлой версии Xsan успешно перенеслись и работают на новом томе:
$ cvaffinity -l /Volumes/Xsan40/1
/Volumes/Xsan40/1: Video1 (0x316f65646956)
$ cvaffinity -s Video2 /Volumes/Xsan40/1
$ cvaffinity -l /Volumes/Xsan40/1
/Volumes/Xsan40/1: Video2 (0x326f65646956)
$ snfsdefrag -r -k Video1 -m 0 /Volumes/Xsan40/1
1 file and 0 streams visited: 1 defragged, 0 skipped
$ cvmkdir -k Video1 /Volumes/Xsan40/2
$ cvaffinity -l /Volumes/Xsan40/2
/Volumes/Xsan40/2: Video1 (0x316f65646956)Однако, если вы создадите том Xsan 4 (или новее) с нуля, в нем не будет возможности назначить affinity для пулов. Вам придется внести в конфиг соответствующие строки для добавления этого функционала.
OS X 10.11, Xsan 4.1
После апгрейда на OS X 10.11 (El Capitan), в соответствующей версии Server.app повторяем процедуру восстановления старой конфигурации Xsan. C выходом El Capitan публике был представлен результат совместной работы Apple и Quantum Corporation — DLC (Distributed LAN Client), отныне встроенный во все последующие версии OS X. Он позволяет получать доступ к тому StorNext по локальной сети (Fibre Channel over IP), правда для этого необходима оригинальная СХД от Quantum. DLC был добавлен чтобы сделать миграцию с Xsan на StorNext еще более гладкой и привлекательной для пользователей.
Следует отметить, что присоздании нового тома, параметр fsBlockSize автоматически выбирается равным 16384. Если вам необходим другой размер блока, придется исправить его вручную в конфиге (вместе c journalSize) и выполнить Erase Volume.
Кроме прочего, в конфиге появилось несколько новых параметров, соответствующих переходу на следующую версию StorNext, но мы не будет заострять на них внимание.
Проверяем что affinity по прежнему работают:
$ cvaffinity -l /Volumes/Xsan41/2
/Volumes/Xsan41/2: Video1 (0x316f65646956)
$ cvaffinity -s Video2 /Volumes/Xsan41/2
$ cvaffinity -l /Volumes/Xsan41/2
/Volumes/Xsan41/2: Video2 (0x326f65646956)
$ snfsdefrag -r -k Video2 -m 0 /Volumes/Xsan41/1
1 file and 0 streams visited: 1 defragged, 0 skipped
$ cvmkdir -k Video1 /Volumes/Xsan41/3
$ cvaffinity -l /Volumes/Xsan41/3
/Volumes/Xsan41/3: Video1 (0x316f65646956)Прежде чем мы перейдем к следующей версии, сделаем одно важное замечание. Несмотря на официальные данные Apple, вы все же можете откатить версию Xsan на более старую (в нашем случае откатывали на Xsan 3.1) с более старших версий — Xsan 4 и Xsan 4.1. Это стало возможным потому, что на уровне лунов изменений между версиями не происходило. Если все параметры в конфигах: количество и название лунов, размер блока и stripeBreadth прописаны верно – том успешно запустится. При переходе же на Xsan 5, происходят кардинальные изменения в луне метаданных и откат на предыдущие версии Xsan становится невозможен.
macOS 10.12, Xsan 5
И вот, наконец мы подошли к обновлению на macOS 10.12 (Sierra) и обновлению до Xsan 5. При старте службы Xsan в Server.app и привычном выборе восстановления прежней конфигурации, том не запустится как ранее. Напротив названия тома появится надпись Needs Upgrade. Это связано с кардинальными изменениями в StorNext 5.3 на которой основан Xsan 5, и в частности с жестко заданным размером блока, имеющим теперь размер 4К.
В процессе апгрейда конвертируется размер блока файловой системы и меняется формат хранения метаданных. Это односторонний процесс, о чем нас предупреждают перед началом апгрейда и возможности обратной конвертации не предусмотрено. Это значит, что том созданный или конвертированный в формат Xsan 5 невозможно будет запустить на контроллере метаданных младше OS X 10.12 (Sierra).
Убеждаемся что наши affinity по прежнему работают:
$ cvaffinity -l /Volumes/Xsan5/1
/Volumes/Xsan5/1: Video2 (0x326f65646956)
$ cvaffinity -s Video1 /Volumes/Xsan5/1
$ cvaffinity -l /Volumes/Xsan5/1
/Volumes/Xsan5/1: Video1 (0x316f65646956)
$ snfsdefrag -r -k Video1 -m 0 /Volumes/Xsan5/1
1 file and 0 streams visited: 1defragged, 0 skipped
$ cvmkdir -k Video2 /Volumes/Xsan5/4
$ cvaffinity -l /Volumes/Xsan5/4
/Volumes/Xsan5/4: Video2 (0x326f65646956)Напомню, что наш изначальный том был создан с блоком 16К и сейчас нас ждет очередной неприятный сюрприз: несмотря на конвертацию файловой системы, информация о размере блока в конфиге останется прежней:
<key>fsBlockSize</key>
<string>16384</string>И все терминальные утилиты (к примеру cvadmin) будут использовать именно этот размер блока при выводе информации о томе, размерах stripe breadth и пулов в его составе. Это документированное поведение StorNext (и соответственно Xsan). Единственный способ вернуть корректный вид “старому” тому — выполнить Erase Volume (ранее Reinitialize volume в Xsan Admin), при этом данные на томе будут потеряны. При выполнении, в логе команды будет особо отмечено, что в файле конфига она заменила значение fsBlockSize, выставив реальный размер блока, и посоветует изменить размер stripeBreadth в соответствии с новым блоком для лучшей производительности:
cvmkfs changed fsBlockSize to 4096 in
config file /Library/Preferences/Xsan/Xsan5.cfgp.
Other parameters such as stripeBreadth and
perfectFitSize may need to be adjusted accordingly.В самом конфиге Xsan 5 увеличились размеры inodeCacheSize = 131072 (в 8 раз) и bufferCacheSize = 536870912 (в 16 раз), что может быть связано с общим развитием технологий и доступности большего количества ресурсов в современных системах. Появился параметр ignorePermissions, при включении которого на томе перестают видеться назначенные ранее ACL. Проверка показала: на самом деле они остаются на месте, если вернуть настройку в положение выключено, что очень удобно.
Дотошный администратор заметит, что при создании нового тома или добавлении пулов пропала возможность задавать их имена (Pool Name). Теперь они стандартизированы и для пулов данных имеют вид: Data, Data-1, Data-2 и т.д..
В терминальных утилитах основными изменениями стали перенос функционала по бэкапу метаданных из отдельной утилиты snmetadump (отсутствует) в обновленную cvadmin и пропажа в последней функционала по управлению квотами на томах. Запуск проверки файловой системы утилитой cvfsck может приятно вас удивить: в ходе ее работы выводится непривычно много новой и подробной статистики по файловой системе, что обусловлено новым форматом хранения метаданных.
Любопытный курьез из прошлого: начиная с OS X 10.7 (Lion), в комплект управления файловой системой acfs (Apple Cluster File System, внутреннее название Xsan) входит утилита sncfgedit, призванная упростить ручное редактирование файла конфигурации тома Xsan. И она никогда не работала…
По сути она представляет из себя shell-скрипт, который сам разбирается с местоположением конфигурационного файла тома, делает его бэкап, копирует содержимое во временный файл, открывает его в редакторе vi, проверяет формат после внесения изменений и подменяет файл конфига после успешной правки. По всей видимости из-за неработоспособности, она не получила широкой известности и в сети можно лишь отыскать редкие отзывы людей, столкнувшихся с ошибкой при ее запуске. Однако, причину проблемы легко обнаружить и устранить: она связана с использованием в скрипте утилиты stat с ключом -c, используемым в linux-версии, в то время как в bsd-версии stat для явного указания формата используется его аналог -f. Достаточно изменить всего один символ в скрипте и вуаля — sncfgedit готова отредактировать ваш конфиг, спустя 6 лет и столько же версий OS X после своего дебюта!
Однозначную оценку Xsan 5 давать пока рано. Аналогичная версия StorNext производителем позиционируется как более совершенная во многих случаях применения, в том числе и при работе с большими файлами (видео, вплоть до 8k), но при импорте изменений в Xsan некоторые параметры конфигурирования были зафиксированы в коде, и насколько они оптимальны, покажет только практика.
Мы с интересом следим за её работой у наших коллег и клиентов, но также будем рады услышать от вас впечатления о работе различных функций, таких как ignorePermissions, Spotlight и стабильности ее работы в целом.
Сейчас же мы можем только порадоваться за то, что Apple продолжает развивать свое недорогое SAN решение для небольших и средних производств.