Назад | Перейти на главную страницу

Как мне организовать разделы / LV для зеркального сервера 30 ТБ?

Я планирую обновить бесплатный зеркальный сервер и буду признателен за совет по установке новых основных дисков.

Мое текущее использование:

Я, вероятно, получу 44 ТБ дисков, которые я бы распределил по трем аппаратным массивам RAID-5, в общей сложности 34 ТБ (плюс запасные части).

Я думал, что сделаю массивы в LVM2 PV и построю виртуальную группу емкостью 34 ТБ, которую я как-то разделю, сделав LV для каждого зеркала. Тогда у меня был бы том extN или XFS для каждого из дистрибутивов.

Одна проблема в том, что я не могу точно предсказать рост любого из зеркал. Возможно, мне придется либо создавать много накладных расходов в каждом LV, либо часто наращивать LV. Большая усадка зеркала на самом деле не проблема; они становятся все больше и больше. Есть ли реальная потеря производительности из-за повышенной фрагментации при многократном изменении размера LV?

Возможно, я захочу оптимизировать некоторые файловые системы для определенных рабочих нагрузок, например, небольшие текстовые файлы или образы компакт-дисков, так что это удар против использования одной файловой системы. Подход с несколькими FS позволил бы мне легче отслеживать шаблоны использования диска по каждому дистрибутиву. Последним возможным недостатком сохранения единой большой файловой системы является задержка при поиске ОС по дереву. Насколько это беспокоит?

У меня будет 24 или 48 ГБ ОЗУ, и я планирую обслуживать 30-50 ТБ в месяц, при этом несколько больших файлов (установщики, образы компакт-дисков) попадают в кеш, а многие файлы размером 2-20 МБ отсутствуют.

Учитывая размер массива и тот факт, что вы скоро собираетесь его расширять, я бы рекомендовал использовать RAID-6 вместо RAID-5 + запасные части для массива. На моем оборудовании восстановление массива 20 ТБ занимает около 2-3 недель, поэтому, если вы используете RAID-5 и диск выходит из строя, вы будете подвергаться риску в течение длительного периода времени во время восстановления. Также хорошо задокументирован тот факт, что во время восстановления происходит множество сбоев, которые будут фатальными для массива RAID-5.

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

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

Прежде всего, держитесь подальше от RAID. Это того не стоит. С массивом 14 ТБ перестройка займет несколько дней. Вы не хотите, чтобы ваши диски перемешивались в течение нескольких дней, тогда лучше потерять часть зеркала и снова получить данные при замене диска.

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

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

Типичным решением при работе с большими и растущими зеркальными хранилищами является создание уровня абстракции, который отслеживает, где файлы расположены на диске (обычно с использованием базы данных), а затем распределяет файлы по нескольким физическим дискам без избыточности. Это встроено во многие решения NAS.

Вы можете найти дополнительную информацию в предыдущем ответе Вот.