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


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

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

Как мы можем наилучшим образом использовать доступную 1.3TB, чтобы убедиться, что пространство доступно, когда и где это необходимо, но не создает кошмар для обслуживания sysadmin ??


89
2017-09-18 08:12


Источник


Используйте LVM и изменяйте размер по желанию - thanasisk
@thanasisk At will resizability - это миф, потому что нет файловой системы на linux, которая была в состоянии сжиматься. ext2 имел такой патч в древние времена. - peterh
@PeterHorvath - тогда вы счастливы, если я замените «resize» на «expand»? - thanasisk
Немножко нереально ожидать, что все, что вы сейчас настроите, по-прежнему будет оптимальным за 2,5 года! И тот факт, что неспециализированные пользователи создают беспорядок, тем более объясняет разделение ОС на данные. - JamesRyan
@PeterHorvath Я читал ваш комментарий не один раз, чтобы понять это. Вы написали, что были бы счастливы, если бы существовала файловая система, которая могла расшириться, и я указал на файловую систему. Это все. - gparent


Ответы:


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

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

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

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

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

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

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

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

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

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

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


101
2017-09-18 09:49



Что касается производительности, я думаю, стоит также отметить, что в случае файловой системы требуется быстрый ответ, а «df» будет возвращать полезную информацию намного быстрее, чем «du -s $ DIRNAME», - symcbean
Я не уверен, что согласен с "пока ... RH7 ... нет поддерживаемого пути обновления«Я делал поддерживаемые обновления с тех пор, пока не с ума, и определенно обновил системы RH4-> 5. только RH5-> RH6, которому не хватало такого пути, насколько мне известно, - и я получаю чувство RH, которое было полностью распущено их пользователями из-за этого недостатка. Тем не менее +1 для остальной части отличного ответа. - MadHatter
О чем вы говорите: «До выхода RHEL 7 не было поддерживаемого пути обновления»? Будет ли RHEL поддерживать обновления между основными версиями от RHEL 7 и forward? - Mark Lindroos
Модернизация работала, но согласно Красная Шапка общая политика по-прежнему такова: Red Hat не поддерживает обновления на месте между любыми крупными версиями Red Hat Enterprise Linux.  и немного нюанса дальше вниз В настоящее время Red Hat поддерживает обновления от Red Hat Enterprise Linux 6 до Red Hat Enterprise Linux 7 только для конкретных / целевых случаев использования а также вот руководство Проверять - HBruijn♦


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

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

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

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

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

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


17
2017-09-18 08:38





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

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

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


12
2017-09-18 08:23



на некоторых файловых системах (ext3 f.e.) у вас может быть немного зарезервированного пространства для пользователя root, чтобы предотвратить это поведение. вам придется использовать квоты, чтобы предотвратить это, то же самое для / tmp, которое часто забывается. - Dennis Nolte
@DennisNolte Я забыл о /tmp, Спасибо, я добавлю это к моему ответу. - Uwe Plonus
@DennisNolte зарезервированное пространство поможет, но я считаю, что техническое обслуживание сложнее, чем использование разных разделов, поскольку вам необходимо правильно настроить квоты. - Uwe Plonus
Я думаю, что более важная причина для /root быть снаружи /home что на некоторых установках /home будет на сетевом диске. В случае возникновения проблемы по сети, файлы root остаются доступными. (Это можно сравнить с тем, как обычно есть текстовый редактор в /bin, в случае /usr не будет монтироваться.) Я подозреваю, что это более распространенный сценарий на практике, в наши дни, чем /home заполняя весь путь. - Eliah Kagan


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

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


10
2017-09-18 08:22





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

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

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

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

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


9
2017-09-18 08:43



Какой мазохистский админ нравится играть с картами разделов ??? Интересная часть - это создание ядра, могу ли я получить аминь??? - bishop
аминь! Теперь о том, что администраторы любят играть с разделами, я просто хотел бы противостоять этому тем, что у linux, вероятно, 100 разных типов файловой системы и в зависимости от шаблонов использования выбор правильной системы фильтрации для конкретной задачи может означать разница между оптимальной системой и нефункциональной системой. И, может быть, вам просто нужна эта файловая система в нескольких папках. Там. - Lennart Rolland


Существуют две основные причины разделения:

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

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

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

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

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

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

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


3
2017-09-18 09:41



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


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

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

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

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

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

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

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

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

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

Mounpoint /

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

при использовании mountpoint / home

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

при использовании mountpoint / opt

если используется mountpoint / usr

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

при использовании mountpoint / var

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

при использовании mountpoint / tmp

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

2
2017-09-18 14:18





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

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

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

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

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

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

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

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

  • -

2
2017-09-23 13:10





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

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

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

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

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


2
2017-09-18 11:13



И почему -1? Не могли бы вы ожидать ожидания без беспроводной связи для исправления ошибок в качестве более профессионального подхода? Был исправлен через три недели, BTW. - h22
Я не знаю, но компенсировал. Если вы видите нечто подобное, сделайте это. - peterh


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

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

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

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


1
2017-09-20 05:38