NAS ( Построение простейшей распределённой расширяемой сетевой горизонтальной файловой системы с использованием технологий DRBD, AoE и MHDDFS. )

OS: Debian Linux.

Задача: построение распределённой расширяемой "на лету" сетевой горизонтальной файловой системы на некотором количестве (от четырёх) непрофессиональных компьютеров с разномастными дисковыми устройствами. По условиям задачи большого количества параллельных операций записи и чтения не предполагается, потому нет необходимости создавать систему с множеством точек обращения к ней извне, достаточно обеспечить возможность замещения вышедшей из строя центральной точки доступа рабочей. На всех компьютерах в схеме очень и очень желательно иметь высокоскоростные сетевые интерфейсы, например: GigabitEthernet, в противном случае операции синхронизации будут проходить очень не быстро; для вывода фоновых сетевых операций очень желательно иметь ещё по одному высокоскоростному сетевому интерфейсу на каждом компьютере схемы.

Условия: используемое программное обеспечение должно быть бесплатным, свободно распространяемым, имеющим стабильную версию, не требующим внесения изменений в коде операционной системы и не запрашивающим специального оборудования.

Особое условие: работа сетевой распределённой системы должна быть понятна от начала и до конца при развёртывании даже не высококвалифицированному специалисту; не должна выглядеть эдаким "чёрным ящиком" для обслуживающего персонала. В общем, нужно сделать так, чтобы каждый этап развёртывания и сопровождения системы был понятен и максимально прост.


В связи с вышеприведённым условием, "специалистам", устанавливающим GFS, OCFS2, Lustre и тому подобные FS за два "клика" в три команды - привет и пока. Где то я встретил замечание о том, что система "высокой готовности" с плохо понятым принципом работы, невнятным конфигурированием и неявной методикой тестирования - не является системой "высокой готовности"; совершенно согласен с этим.

Для решения поставленной цели применим решение из нескольких этапов:


Перед тем, как приступать к работе с физическими дисковыми устройства считаю желательным ввести прослойку именования, позволяющую абстрагироваться от автоматического именования операционной системой блочных устройств. Введем свою систему именования требуемых нам блочных устройств: odsk0.0, odsk0.1, ..., odsk0.X для первого компьютера, odsk1.0, odsk1.1, ..., odsk1.X - для второго, и так далее. По хорошему, нужно бы это делать с помощью UDEV.

Для обеспечения приемлемого уровня целостности хранимых данных применим подход с использованием зеркальных копий на уровне физических дисковых носителей. С помощью технологии DRBD (Distributed Replicated Block Device) создадим на основе объединённых в группы дисковых носителей блочные устройства. Блочные устройства будут включать группы дисковых носителей, каждый диск из которых возможно расположить в произвольном месте нашей инфраструктуры, как на одном физическом компьютере, так и на разнесённых в сети. Своего рода RAID-1, только с разнесёнными по сети TPC/IP дисковыми устройствами. Особенное внимание необходимо обратить на мониторинг сбоев аппаратного обеспечения для своевременной замены вышедших из строя узлов для того, чтобы наша система не стала из зеркалируемой на уровне блоков незеркалируемой.

DRBD обеспечивает зеркалирование информации записанной на первичное устройство элементарными операциями дублирования на вторичные дисковые устройства. Скорость записи от этого не снижается, насколько я понимаю, так как передача на вторичные устройства происходит в фоновом режиме. На скорость считывания информации эта технология влияния не оказывает, так как операции чтения идут только с первичного блока. Разумеется, скорость записи и чтения будет зависеть от месторасположения наших дисковых устройств, сильно далеко устройства не разнесешь; например, от моего месторасположения до Москвы задержки при прохождении пакетов от 150 до 300 миллисекунд, разумеется, располагать там часть файловой инфраструктуры было бы несколько неумно.

DRBD (Distributed Replicated Block Device), а не AoE (ATA over Ethernet) в комплексе с RSync, например, выбрана исходя из того, что технология работает с маршрутизируемым протоколом TCP/IP и блоки могут зеркалироваться куда угодно в сети, в то время как "ATA over Ethernet" работает только в пределах сетевого сегмента.

После того, как блочные устройства будут синхронизированы с помощью DRBD, оснастим их единообразной файловой системой. Я остановился на XFS. Она дает нам все, что нужно для решения задачи и, в конце концов, имеет историю развития наводящую на мысли о том, что особо вопиющие баги из неё давно вычистили. Поддержка XFS требует более производительного процессора, чем большинство иных файловых систем, но, в конце концов, мы не балуемся, а распределённую систему создаем, можно подобрать что-то по мощнее Celeron 800.

Доставлять блочные устройства, полученные с помощью DRBD, в единую точку управления и обмена трафиком будем с помощью технологии AoE (ATA over Ethernet). Изначально AoE разрабатывался для поддержки простых ATA устройств, но в 2006 году он был модернизирован для поддержки SerialATA. AoE - это низкоуровневый широковещательный сетевой протокол; проще, чем TCP/IP и даже проще IP, что позволяет достигнуть максимальной производительности использующих его узлов в рамках Ethernet сети. Если в случае с DRBD основным естественным ограничением на разнесение узлов блочных устройств друг от друга является задержка при передачи пакетов по сети (чем она больше, тем не эффективнее работает схема в целом), то для AoE основным ограничением является то, что технология работает только на уровне Ethernet, не используя протокол TCP/IP.

На самом деле у AoE есть альтернатива - GNBD (Global Network Block Device), имеющая некоторое преимущество - работа поверх TCP/IP. GNBD может доставлять блочные устройства за пределы Ethernet сети, проходя маршрутизаторы; удобно и то, что контроль целостности обеспечивается сетевым протоколом TCP/IP. Но, GNBD работает только в окружении кластера RedHat, что не есть хорошо для нашей простенькой распределённой системы, собираемой "на коленке". Фактически, чтобы использовать GNBD, нужно использовать и GFS, а мы такой цели перед собой пока не ставим. Несомненным плюсом в использовании AoE является то, что поддержка протокола (клиентская часть, во всяком случае) реализована для большого количества распространённых операционных систем, таких как: Linux, FreeBSD, OpenBSD, Solaris, Mac OS, Windows.

Необходимо обратить особое внимание на то, что AoE не имеет собственных средств контроля целостности передаваемой информации и нужно тщательно выбирать сетевое оборудование связывающее наши узлы. Сетевые интерфейсы должны быть качественные и высокоскоростные, а коммутаторы иметь средства контроля за отсутствием коллизий и иметь достаточную производительность для полноценного контроля за целостностью и последовательностью проходящих через них пакетов (применение "дешёвки" может привести к тому, что коммутатор захлебнется массой проходящих через него пакетов и станет просто широковещательно рассылать из на все порты без какого либо контроля, периодически удаляя часть данных, с которыми не успеет справиться). Учитывая то, что все узлы нашей распределённой сетевой файловой системы будут располагаться на расстоянии не более трёх метров друг от друга, можно с высокой долей вероятности предполагать, что потерь большого количества информации при передачи по сети не будет.

После того, как блочные устройства будут собраны в одном месте, объединим их в группу в единой точке монтирования с помощью MHDDFS. Почему именно MHDDFS, а не LVM, например? Тут все просто - потому, что проще. LVM - низкоуровневая прослойка, возится с которой в случае её сбоя мы будем просто вынуждены, так как без её корректной работы не будут доступны данные, что находятся на её "томах"; иначе говоря, пока "тома" LVM не буду собраны в предусмотренном порядке - до данных мы не доберемся. MHDDFS работает по другому принципу; все данные доступны в независимости от корректности работы MHDDFS, по отдельности, на каждом из носителей. Рассуждения о разнице в скорости работы этих двух технологий в связи с уровнем взаимодействия (ядро и пользовательский) меня не особо впечатляют в силу отсутствия внятных доводов и преимуществ, рассматривать которые можно было бы в контексте выгоды.

Чтобы не запутаться в конфигурационных файлах с именами, идентификаторами и IP адресами сразу определимся о единой для всей нашей схемы системе адресации.

Для адресации компьютеров выберем формат доменного имени "nodeX.storage.local", где "X" - число из последовательности "0, 1, 2 и так далее". Можно и нужно описать доменные имена всех компьютеров с корпоративной системе NS, а для гарантии работоспособности нашего сервиса продублировать эти описания в файлах "/etc/hosts"; лишняя возня, можно запутаться и забыть, но повышается надёжность.



Разумеется, имена компьютеров, участвующих в схеме синхронизации очень желательно так же привести к общему образцу, то есть, соответственно: node0.storage.local, node1.storage.local и так далее.

Без информирования администраторов с помощью электронной почты о событиях, происходящих в под ведомственных им системах мне трудно себе представить современную схему. Скриптов много, в каждом из них переписывать почтовые адреса - непродуктивно. Потому, вынесем список почтовых адресов администраторов в отдельный файл подключаемый по необходимости:


Переход к настройкам аппаратного обеспечения файловой системы.