Лучший способ развести диски в Linux? (рейд, раздел или LVM)

Мой предпочтительный макет:

2 disks for the OS in RAID1 (protected against a HDD failure)
2n disks for the RAID10 (protected against a HDD failure)
rest of the disks for RAID0 (no redundancy, maximum speed)

Если вы действительно настаиваете на единственном системном диске, это не меняет структуру.

На (каждом из) системных дисков у меня был бы отдельный раздел для файловой системы / boot. Остальные диски я превратил в физический том LVM. Мне нравится иметь файловые системы ОС, которые могут заполнять отдельные логические тома (/ tmp, / var, / opt, если что-то записывает туда журналы). В результате будут созданы файловые системы / boot (зеркальные, без LVM) и /, / tmp, var и, возможно, / opt, каждая из которых находится на отдельном логическом томе на зеркальном диске.

На каждом из других дисков я бы создал отдельный раздел типа рейда Linux и соответствующие массивы RAID (один RAID 10, один RAID 0). На каждом из массивов я бы создал один раздел типа Linux LVM и две отдельные группы томов, одну для избыточных и одну для неизбыточных данных. Затем для каждой файловой системы, которую вы планируете создать, я бы создал логический том.

В каждой группе томов я бы рекомендовал оставить неиспользуемое пространство, чтобы вы могли сделать снимок LVM и выполнить fsck файловой системы, не останавливая сервер. Я бы также отключил автоматический fsck для всех файловых систем (tune2fs -i 0 -c 0 / device / name).

Обоснование

1) Зеркальное отображение дисков ОС.

Отказ системного жесткого диска приводит к поломке всей машины. Ваши данные защищены, но производство останавливается до тех пор, пока вы не принесете запасной диск и не переустановите / не восстановите ОС. В производственной среде обычно дешевле установить еще один диск.

2) Разметка дисков для RAID-массивов.

На всех серверах, которые я использую, есть таблицы разделов. Вы можете использовать только целые диски в качестве томов RAID / LVM, но тогда вы получите некоторые машины, у которых есть таблицы разделов (материал на / dev / sdX1), а некоторые нет (материал на / dev / sdX). В случае сбоя и необходимости восстановления в условиях стресса я предпочитаю иметь в среде на одну переменную меньше.

3) LVM на RAID-массивах

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

4) tune2fs -i 0 -c 0

Неожиданный сбой в работе большой файловой системы после перезагрузки - занятие, требующее много времени и нервов. Отключите его и выполняйте регулярные проверки файловых систем LVM.

Вопрос: в / opt / backup вы планируете хранить резервные копии своей производственной среды?

Не надо.

Храните резервные копии где-нибудь еще с машины. Вредоносная программа, неправильно написанная команда (например, rm -rf / tmp/unimportant/file) или вода, пролитая / затопленная не в том месте, оставит вас без вашей системы и без резервных копий. Если ничего не помогает, возьмите два внешних USB-диска для резервного копирования, все же лучше, чем раздел внутри того же ящика.

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

 /opt/data/database/data
         4 (maybe 6) dedicated disks as RAID 1+0

По-видимому, в этом и заключается ценность сервера - поэтому вы хотите, чтобы он был максимально быстрым / безопасным.

Raid 0 для файловой системы tmp имеет смысл только тогда, когда вы храните там много очень больших файлов и используете последовательный доступ. Обычно это не тот шаблон доступа, который я ожидал бы увидеть для временных файлов. Raid 0 подходит для ваших журналов, но действительно ли вы хотите выделить 2 диска только для журналов? Я бы, вероятно, выбрал 2 диска, разделенных на 2 раздела, по одному с каждого диска как raid 0 для журналов, по одному с каждого диска как raid 1 для tmp.

Я настоятельно рекомендую зеркалировать корневую файловую систему для обеспечения отказоустойчивости. Итак, здесь 2 диска, опять же в 2-х разделах, зеркально отображаемых для корневой файловой системы и чередующихся для свопа.

В зависимости от взаимосвязи между пространством tmp и виртуальной памятью, если они не делают то же самое, может быть целесообразно объединить 2 набора по 2 раздела для tmp и подкачать их в массив наборов полосок из 4 дисков.

.... и у вас осталось 2 диска для резервного копирования. Но я бы рекомендовал вам хранить свои резервные копии в другом месте. Если бы это был я, я бы использовал их в качестве временных членов набора рейдов базы данных - затем разбил бы набор и запустил их как независимый набор / запустил на них новый экземпляр СУБД, чтобы получить резервные копии с минимальным временем простоя.

Что касается того, используете ли вы разделы или LVM - здесь не так уж много выбора - я бы склонился к разделам, поскольку это затрудняет настройку действительно беспорядочного набора перекрестных зависимостей.

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

В таких системах действительно важно не делать «слишком странных» вещей.