Насколько плохо устанавливать Linux на один большой раздел?

Мы будем запускать CentOS 7 на нашем новом сервере. У нас есть 6 х 300 ГБ дисков в raid6 для внутреннего использования на сервере. (Хранилище в основном внешнее в виде рейд-бокса 40 ТБ.) Внутренний том составляет около 1,3 ТБ, если отформатирован как один том. Наш системный администратор считает плохой идеей установить ОС на один большой раздел размером 1,3 ТБ.

Я биолог. Мы постоянно устанавливаем новое программное обеспечение для запуска и тестирования, большая часть которого находится в / usr / local. Однако, поскольку у нас есть около 12 биологов, не разбирающихся в компьютерах, использующих систему, мы также собираем много взяток в / дома. Наш последний сервер имел раздел 200 ГБ для /, а через 2,5 года он был заполнен на 90%. Я не хочу, чтобы это повторилось, но я также не хочу идти против совета экспертов!

Как мы можем наилучшим образом использовать 1,3 ТБ, чтобы убедиться, что место доступно, когда и где это необходимо, но не создавать кошмар обслуживания для системного администратора ??

Основными (историческими) причинами разделения являются:

• чтобы отделить операционную систему от ваших пользователей и приложений данных . До выпуска RHEL 7 не было поддерживаемого пути обновления, и для обновления основной версии потребовалась бы переустановка, а затем наличие, например, /homeи других данных (приложений) на отдельных разделах (или томах LVM) позволяет легко сохранять пользовательские данные. и данные приложения и стереть разделы ОС.

• Пользователи не могут войти в систему должным образом, и ваша система начинает отказывать интересными способами, когда вы полностью исчерпываете место на диске. Несколько разделов позволяют вам выделить зарезервированное дисковое пространство для ОС и отделить его от области, в которой пользователям и / или определенным приложениям разрешено писать (например, /home /tmp/ /var/tmp/ /var/spool/ /oradata/и т. Д.), Снижая операционный риск плохого поведения пользователей и / или приложений.

• Квота. Дисковая квота позволяет администратору запретить отдельному пользователю использовать все доступное пространство, нарушая обслуживание всех остальных пользователей системы. Индивидуальная дисковая квота назначается для каждой файловой системы, поэтому один раздел и, следовательно, одна файловая система означают только 1 дисковую квоту. Несколько (LVM) разделов означает несколько файловых систем, позволяющих более детально управлять квотами. В зависимости от сценария использования вы можете, например, разрешить каждому пользователю 10 ГБ в своем домашнем каталоге, 2 ТБ в каталоге / data в массиве внешнего хранилища и настроить большую общую область с нулями, где любой может выгрузить наборы данных, слишком большие для их домашнего каталога. и где политика становится «полный - полный», но когда это происходит, ничто не нарушается.

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

• Загрузка Вам может понадобиться отдельный /bootраздел. Исторически для решения проблем BIOS с загрузкой сверх предела 1024 цилиндров, в настоящее время чаще всего требовалось поддерживать зашифрованные тома, поддерживать определенные контроллеры RAID, HBA, которые не поддерживают загрузку из SAN, или файловые системы, которые не поддерживаются непосредственно установщиком и т. Д.

• Настройка Вам могут понадобиться разные параметры настройки или даже совершенно разные файловые системы.

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

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

Вы можете расширить эти тома и их файловые системы по мере необходимости (это тривиальная операция, которую можно выполнить в реальной системе), или создать дополнительные.

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

Концепция использования нескольких разделов заключается в том, что заполнение в неправильном месте не приведет к неожиданной работе всей системы.

Рассмотрим процесс на машине, заполняющий файл журнала довольно быстро, вплоть до того, что свободного места не будет. На машине с одним разделом это может, например, помешать системе записывать новые данные в / tmp. Если есть другой процесс, который захочет записать в / tmp, он, вероятно, завершится с ошибкой, что приведет к неожиданному поведению.

Этого можно избежать, если вы используете разные разделы для мест, где пользователи или процессы обычно пишут (/ home, / var, / tmp).

Я бы порекомендовал вам проверить ваш старый сервер, какие папки имеют тенденцию к увеличению. Вы можете сделать это в командной строке с

du -h -d 1 / 2> /dev/null

Вы увидите, где накапливается наибольшее количество данных, и соответствующим образом спроектируете вашу следующую систему. «-D 1» ограничивает вывод только одним уровнем глубины папки, делая его более читаемым.

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

Из-за этого пользователь root имеет свою домашнюю папку ( /root) вне /home. Если файловая система заполнена при некоторых обстоятельствах, даже root не может войти в систему и не может восстановить систему.

Это причина , почему вы обычно создают отдельные точки крепления для /var, /tmpи , /homeчтобы иметь возможность войти в систему, по крайней мере , как корень , чтобы восстановить систему , когда один из других разделов заполняется.

ИМХО, иметь один раздел как / вполне разумно.

Но вы можете использовать lvm (менеджер логических томов). Используйте весь диск как группу lvm, но создайте небольшие логические диски для /, / home, / usr и всего, что предпочитает ваш системный администратор. Затем включите мониторинг, который вы знаете, когда ваша система начнет заполняться, и расширьте те диски, которые вам нужны. lvresize и resize2fs - это онлайн-инструменты, и вы можете выполнять расширение без перезапуска сервера. Однако вы не можете уменьшить количество дисков, поэтому вам нужно начинать с малого и увеличивать там, где вы считаете нужным.

Существуют минимальные проблемы с установкой linux с большим одним разделом, но она имеет большие преимущества.

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

Его единственным преимуществом является то, что у вас есть некоторая защита от проблем с заполнением диска. Но вы найдете эти проблемы гораздо чаще. Представьте себе ситуацию, если один из ваших разделов заполнен, и вы не можете использовать пространство на других разделах, даже если они почти пусты !

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

Существует простая система с именем lvm , которая позволяет на лету перемещать / изменять размеры «разделов» (в терминологии, томах). Но на одном локальном сервере отдела ИМХО это обычно не нужно.

Есть две основные причины для разделения:

1. Чтобы сохранить статические данные от нестатических данных
2. Держать публичные данные подальше от личных данных

Первая причина наиболее очевидна - вам нужно изолировать области, которые будут заполнены файлами, от тех, которые этого не делают, и вы особенно хотите защитить /, чтобы избежать загрузки системы. Например, в каталоге / var обычно хранятся файлы журналов (var обозначает «переменная»), и именно поэтому / var обычно монтируется на отдельном разделе из /.

Вторая причина, приведенная выше, упоминается реже (в последний раз я слышал об этом на курсе Veritas Volume Manager около 15 лет назад), и она действительно имеет отношение только к системам, в которых многие люди входят в систему и выполняют работу.

В эффективном разделении есть что-то вроде искусства, и, возможно, именно поэтому есть Sys Admins, которые слишком далеко зашли (IMO). Вам нужно не только знать файловую систему наизнанку, но и знать, для чего она предназначена. Лично я считаю, что это довольно старомодный подход, который становится все менее и менее актуальным для современных серверов.

Как разработчик программного обеспечения, я особенно сыт по горло тем, что в отделе Ops создаются виртуальные машины с бездумными схемами разбиения, которые строго ограничивают размер / tmp, / home, / var и / независимо от общего доступного дискового пространства, но потом Не устанавливайте очевидные варианты, такие как / usr или / opt отдельно. Эти машины обычно помещают все то, что осталось от дискового пространства, которое вы запрашивали, в том «/ stuff», в который вы неизбежно в конечном итоге устанавливаете и вставляете символические ссылки, но это вряд ли утешительно. Конечным результатом является то, что мы часто тратим больше времени на перетасовку файлов и рассылку предупреждений, чем на любую реальную работу.

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

Поэтому я бы сказал: если вы не уверены на 100% в своей способности эффективно разделить систему в вашем конкретном случае, не делайте ее вообще .

ИМХО, это зависит от вас полностью. Сначала рассмотрим несколько вещей, хотя целиком и полностью относительных.

• будет ли эта система администрироваться часто?
• будет ли эта система использоваться одним или несколькими пользователями?
• будет ли эта система служить настольным компьютером или сервером или и тем, и другим?

Поскольку можно считать (почти) любой каталог точкой монтирования, следует также учитывать, что содержит несколько растущих данных и что содержит растущие данные.

Вы будете удивлены тем, как мало требуется для запуска системы linux (несколько растущих данных) и сколько потребляется растущими данными (обычно / var / opt / home / srv)

Это также зависит от того, как вы определяете использование для этой системы, в котором изложены требования к разделению. Использование для LVM включено.

Типичная настольная система потребует около 20 ГБ для установки загрузки программного обеспечения, тогда все остальное, назначенное на выделенный / домашний, будет в порядке. LVM вызывает незначительные издержки в вашей системе, и в данном конкретном случае это не такая большая выгода. Хотя мнения могут отличаться.

На сервере менее вероятно, что установленное программное обеспечение будет таким же динамичным, как и для настольной системы. Также разумнее иметь фактические точки монтирования для типичных компонентов файловой системы, таких как / tmp / var / usr / home / opt / srv. Использование LVM здесь не обязательно является обязательным.

Это обеспечивает большую модульность вашей системы, а также позволяет делать глупости, например, клонировать этот раздел в виртуальную машину. Или создание резервной копии на уровне блоков с использованием dd.

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

Mounpoint /

• 1 ГБ (при использовании отдельных точек монтирования для / var / usr / opt / home / tmp)
• +10 или даже +20 ГБ при использовании в качестве настольной системы с отдельным / домашним

если используется точка монтирования / home

• назначьте все свободное место, если используется, / home ne

если используется точка монтирования / opt

если используется точка монтирования / usr

• это сложная задача, которая сильно зависит от установленного программного обеспечения

если используется точка монтирования / var

• это сложная задача, которая сильно зависит от установленного программного обеспечения
• например, базы данных пишут свои данные здесь в системах на основе Debian, если не во всех Linux
• наличие отдельного / var / tmp не является необоснованным

если используется точка монтирования / tmp

• считать, что tmpfs существует и выделяет / tmp в ОЗУ
• Рассмотрим некоторые приложения, может написать много данных здесь

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

Итак, несколько замечаний:

• 1,3 ТБ больше не большой диск. 2 ТБ - это более-менее стандартный размер SATA-дисков в мире настольных компьютеров.

• установка любого дистрибутива Linux вряд ли потребует более 100 ГБ. Конечно, размер для / (root) и (swap) должен быть легко определен как числа с верхним ограничением путем щедрого увеличения их размера (для root) или в соответствии с рекомендациями по конфигурации системы (swap).

• точка монтирования для / home должна указывать на что-то на вашем 40-ТБ RAID-сервере. Нет необходимости, чтобы эти данные, домашние каталоги пользователей, находились где-либо на этом корневом устройстве. Размещение их на сервере RAID, вероятно, в любом случае даст вам лучшую защиту. И, скорее всего, это легко расширяемое средство NAS, тогда как маленький RAID, встроенный в серверную коробку, скорее всего, нет.

• вам, вероятно, следует поместить ваше специальное программное обеспечение в отдельный раздел (точка монтирования для / usr / local / bin и т. д.), чтобы вы могли сохранить его при обновлении ОС и удалении корневых разделов. В противном случае вы столкнетесь с возможностью переустановки «специальных» программных приложений после обновления / исправления ОС / чего-либо еще.

• если вы хотите позаботиться об администрировании вашей системы, я бы задала другой вопрос: как происходит аварийное восстановление после того, как здание загорелось, а серверы и блоки RAID были разрушены? Если данные, о которых вы заботитесь, не останутся полностью в вашей голове, это вопрос, который каждый пользователь должен задать своим ИТ-специалистам / администраторам. Стратегия должна включать такие вопросы, как «как мы будем тиражировать необходимое оборудование» и «сколько времени пройдет, прежде чем мы сможем начать работу». Некоторое обсуждение виртуализации ваших серверов может помочь решить проблемы, связанные с аппаратными зависимостями, и восстановить и запустить все без необходимости перенастройки вашей ОС (поскольку ее можно настроить для работы в «мягкой» среде устройства, которая не меняется,

• Точно так же вы можете спросить, какова стратегия защиты пользовательских данных от потери данных программы и пользовательских ошибок. Сохранение пустого файла поверх действительно замечательного черновика вашей исследовательской работы или наличие пользователя, набирающего неправильную команду (например, rm -rf *), приведет к потере данных так же, как землетрясение, пожар или другой физический ущерб. Решения для восстановления отдельных файлов немного отличаются (или могут быть!) От тех, которые наиболее полезны для аварийного восстановления.

-

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

1. Проще перейти на другой дистрибутив Linux, сохраняя при этом абсолютное большинство пользовательских данных.

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

3. Можно просто вернуться к предыдущей версии операционной системы, если вам не нравится недавно примененное «серьезное обновление» (требуется двойная загрузка).

Для наибольшего потенциала этого подхода вы должны также настроить двойную загрузку (также может быть CentOS / CentOS), чтобы вы могли перезаписать один раздел операционной системы при запуске операционной системы из другого. И, конечно же, вы должны создавать резервные копии системного раздела хотя бы раз в несколько месяцев.

Мой короткий ответ таков: даже настольный компьютер никогда не должен использовать «один большой раздел». Недавно я попробовал это вопреки своему здравому смыслу, потому что это был «просто ноутбук», и автоинсталлятор использовал один раздел, и я просто нажал кнопку.

Когда я пошел устанавливать другой дистрибутив, мне пришлось перераспределить мои диски, потому что установщик не собирался устанавливать поверх существующего дистрибутива. Он может и будет держать ваш / дома нетронутым, если он находится на своем собственном разделе. Итак, я закончил тем, что загрузил gparted live-cd и сжал раздел, создав новые разделы для / home и других, перенеся мои данные в новые разделы, а затем, наконец, загрузился в установщик новой ОС.

В идеале, / SSD, / home на жестком диске, / var на жестком диске, / usr может быть на SSD или HDD в зависимости от того, как часто вы планируете обновление. / TMP на жесткий диск. Я обычно делаю другой раздел для общих медиафайлов, таких как mp3 и фильмы, с символическими ссылками на него из моего / home. Обратите внимание, что / sbin является частью root, и является / bin и / root. Вот в чем разница между / bin и / usr / bin, то есть / usr - это то, что может быть недоступно, пока не смонтированы все ваши диски, поэтому команда mount не может быть в / usr! Обычно я оставляю пару дополнительных разделов для других дистрибутивов Linux, например, этот gparted находится на моем жестком диске, на случай, если я испорчу что-то действительно плохое, у меня есть другая живая система, готовая для работы по восстановлению.

Для сервера, на котором вам может понадобиться что-то перемещать, динамически добавлять хранилище, и вам нужно постоянно работать, определенно используйте LVM !!!

Вам не нужно устанавливать программное обеспечение в / usr / local, вы можете установить все программное обеспечение с другим префиксом, который может быть в / home. Большая часть программного обеспечения может сделать это, когда вы компилируете его из исходного кода, запустив, например, ./configure --prefix=/home/bin

Поскольку вы биолог, вас может заинтересовать множество программ, которые не упакованы должным образом в rpm или deb, и вам все равно придется скомпилировать их из исходного кода.

Я являюсь системным администратором системы HPC с большим количеством биологов среди наших пользователей, мы устанавливаем все программное обеспечение, которое они запрашивают, в / apps / filesystem, поэтому я знаю, что это можно сделать для большинства программ, однако иногда это может быть очень сложным Чтобы решить эту проблему, я и мои коллеги писали об инструменте под названием EasyBuild (бесплатный и открытый). Он может компилировать и устанавливать программное обеспечение из исходного кода, устанавливать его в другую папку и автоматически создавать для вас файл модуля среды , поэтому на самом деле вы можете установить 2 разные версии одного и того же программного обеспечения и не иметь конфликтов.

Посмотрите на наш список пакетов, которые мы можем установить с помощью одной команды, как биолог, вы можете узнать их много ;-)

Отказ от ответственности: я разработчик EasyBuild

Я думаю, что в целом для начинающего / вводного пользователя * ix, который имеет наименьшее количество разделов, может работать, пока больше не узнают о природе системы. Тем не менее, вы не можете просто иметь один паритет и в вашем случае, сэр, по нескольким причинам.

Первая и более общепринятая практическая причина этого заключается в том, что большинству всех систем Linux требуется раздел подкачки (обычно это должно быть от 1 до 2 * вашей оперативной памяти), а также отдельный системный, загрузочный или домашний разделы, а в случае UEFI - загрузка систем Linux раздел EFI (всего 500 МБ).

Вторая причина, особенно применимая к вашей ситуации, заключается в том, что использование 6x 300 ГБ дисков и превращение их в raid 6 не является, по меньшей мере, оптимальным выбором. Несмотря на то, что новая технология признает Raid 6 универсально лучшей системой, алгоритм чередования более необходим, а пространство, необходимое для хранения информации (по сравнению с RAID 5), имеет больший размер.

Не говоря уже о том, что RAID 6 требует дополнительного оборудования. Что следует использовать, на мой взгляд, в вашем случае для покупки дисков большего размера, чтобы избежать сбоя диска, простоев, аварийного восстановления или дополнительных затрат на техническую помощь. Я понимаю, что некоторые, может быть, многие не согласятся со мной, и я хочу еще раз подтвердить, что, когда диски станут больше в размере в течение следующих двух лет (как они упали в цене за последние несколько лет), RAID6, для больших массивов и Крупные корпорации доходов будут очевидным выбором. Однако в этом случае я не предлагаю использовать RAID 6.

Что касается второй проблемы (не основанной на RAID), создание одного гигантского раздела с зеркальным отображением может помочь вам, если вы хотите добиться максимальной эффективности, используйте диски большего размера и несколько разделов. Таким образом, если у вас сбой в работе двух дисков, у вас не будет простоев на определенных точках монтирования или он будет небольшим в зависимости от / dev + / dir.

По крайней мере, заставьте ваш / sys (system, kernel и т. Д.) Работать отдельно, чтобы, если по какой-либо причине ваше ядро ​​решило не загружаться, вы можете просто использовать ядро ​​восстановления, удаленную загрузку или PXE, загрузку с диска и т. Д. И иметь компанию широкий доступ к вашей информации во время процесса восстановления.

Ваша компания может не заботиться об этих акцентах, пока работает система, но я пытаюсь объяснить причины, по которым люди что-то делают. Я также хотел бы услышать больше от других за и против этого аргумента и поднять другие вопросы. Если вы не согласны, дайте мне знать, почему. Афиша - я тоже напишу вам несколько ссылок.

Одна любовь к нашему сообществу Linux Spencer Reiser

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