UMGUM.COM (лучше) 

XFS + DRBD ( Применение файловой системы XFS. )

1 августа 2010  (обновлено 2 ноября 2014)

Эта публикация отнесена в архив. Она неактуальна.
Ресурс по следующей ссылке является преемником: Построение простейшей распределённой расширяемой сетевой горизонтальной файловой системы с использованием технологий MDADM, LVM, NFS и MHDDFS.

OS: Debian Linux.

И так, мы имеем блочные устройства DRBD, синхронизируемые на уровне "ниже" используемого файловыми системами. Разместим на блочных DRBD устройствах файловые системы; заодно проверим, будет ли наши виртуальные DRBD устройства работать так, как предполагалось. Создадим для теста на одном из них файловую систему, директорию и файл. Поменяем роли членов блока, поработаем с файловой системой.

Инсталлируем пакет утилит поддержки XFS:

# aptitude install xfsprogs

Создаем файловую систему XFS на стороне первичного устройства:

# mkfs.xfs -d agcount=256 -l size=128m /dev/drbd0

Где:

"-d agcount" (allocation groups) - параметр, влияющий на эффективность параллельной записи на устройство. В соответствии с рекомендациями разработчиков на каждые 4 (четыре) Гигабайта на блочном устройстве желательно иметь одну "allocation groups". Если пропустить назначение этого параметра, драйвер сам будет его определять и, все хором говорят, это не лучшим образом скажется на производительности;
"-l size" - параметр, определяющий размер журнала для "метаданных". Внятных рекомендаций я не нашёл, но подумал, что для "терабайтного" диска вполне должно хватить и 128 (ста двадцати восьми) Мегабайт.

Монтируем новоприобретённую файловую систему:


# mount -t xfs -o noatime,nodiratime,osyncisdsync /dev/drbd0 /mnt

Где:

"noatime,nodiratime" - опции, отключающие обновление информации о времени обращения (не модификации) к файлам, что даст определённый выигрыш при операциях чтения;
"osyncisdsync" - опция, влияющая на параметры синхронизации таким образом, что производительность операций чтения/записи несколько возрастает (применять эту опцию или нет - решать каждому после вдумчивого изучения вопроса; лично у меня в процессе эксплуатации схемы возникло недоказуемое на моём уровне квалификации мнение о нежелательности её применения).

# df

Filesystem           1K-blocks      Used Available Use% Mounted on
....
/dev/drbd0           976599080     12320 976586760   1% /mnt
....

# mount
....
/dev/drbd0 on /mnt type xfs (rw,noatime,nodiratime,osyncisdsync)
....

Создаем директорию и файл:

# cd /mnt
# mkdir ./test
# cd ./test
# touch ./test.txt

Пишем в файл:

# echo "Test text" >> /mnt/test/test.txt

Отключаем устройство от нашей файловой системы:

# cd /
# umount /dev/drbd0

Меняем роли членов виртуального блочного DRBD устройства местами с помощью следующих команд:

# drbdsetup /dev/drbd0 primary
# drbdsetup /dev/drbd0 secondary

Монтируем устройство на той стороне, что ранее была вторичной:

# mount -t xfs -o noatime,nodiratime,osyncisdsync /dev/drbd0 /mnt

Проверяем, есть ли там все, что мы создали ранее на первичном устройстве. Проводим произвольные тесты. Возвращаем все, "как было".
Общая проверка результатов нашей деятельности завершена, блочное устройство готово к эксплуатации.

Создаем на всех остальных блочных DRBD устройствах файловую систему XFS по приведённому выше образцу.

Переход к настройке экспорта и импорта блочных устройств AoE.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )