Мы будем запускать 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/ и т.д.) , снижение операционного риска плохо себя вести пользователей и / или приложений.
Квота. Дисковая квота позволяет администратору не допустить, чтобы отдельный пользователь использовал все доступное пространство, нарушая работу всех остальных пользователей системы. Индивидуальная дисковая квота назначается каждой файловой системе, поэтому один раздел и, следовательно, одна файловая система означает только одну дисковую квоту. Несколько разделов (LVM) означают несколько файловых систем, позволяющих более детально управлять квотами. В зависимости от вашего сценария использования вы можете, например, разрешить каждому пользователю 10 ГБ в их домашнем каталоге, 2 ТБ в каталоге / data на внешнем массиве хранения и настроить большую общую рабочую область, где любой может сбрасывать наборы данных, слишком большие для их домашнего каталога. и где политика становится "полный заполнен", но когда это происходит, ничего не ломается.
Предоставление выделенные пути ввода-вывода. У вас может быть комбинация твердотельных накопителей и вращающихся дисков, и вам будет полезно обратиться к ним по-другому. Не такая большая проблема на сервере общего назначения, но довольно распространенная проблема в настройках базы данных - также назначать определенные шпиндели (диски) для разных целей для предотвращения конфликтов ввода-вывода, например отдельный диск для журналов транзакций, отдельные диски для фактических данных базы данных и отдельные диски для временного пространства. .
Загрузки Возможно, вам понадобится отдельный /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 чтобы иметь возможность войти в систему как минимум как root для восстановления системы, когда один из других разделов заполнен.
IMHO, иметь один раздел как / вполне разумно.
Но вы можете использовать lvm (диспетчер логических томов). Используйте весь диск как группу lvm, но создавайте небольшие логические диски для /, / home, / usr и всего того, что предпочитает ваш системный администратор. Затем включите некоторый мониторинг, который, как вы знаете, когда ваша система начнет заполняться, и расширьте те диски, которые вам нужны. lvresize и resize2fs - это онлайн-инструменты, и вы можете выполнять расширение без перезапуска сервера. Однако вы не можете уменьшить количество дисков, поэтому вам нужно начать с малого и увеличивать там, где вы считаете нужным.
Есть минимальные проблемы с настройкой Linux с одним большим одним разделом, но она имеет большие преимущества.
Изменение схемы разделов - дело несколько сложное и рискованное, и зачастую без длительных простоев не обойтись.
Его единственное преимущество в том, что у вас есть некоторая защита от проблем с заполнением диска. Но вы найдете эти проблемы много довольно часто. Представьте себе ситуацию, если один из ваших разделов заполнен, и вы не можете использовать место на других разделах, даже если они почти пусты!
У некоторых профессиональных системных администраторов на этот счет совершенно иное мнение. Они говорят, что наличие нескольких разделов может сделать вашу систему более надежной, и перед разбиением вы должны знать, какого размера будут ваши разделы. На мой взгляд, этого просто нельзя сказать, это ужасный недостаток гибкости системы, и их настоящая мотивация заключается в том, что они просто любит играть с картами разделов.
Существует простая система под названием lvm, который позволяет на лету перемещать / изменять размер «разделов» (в его терминологии, томов). Но на одном локальном сервере отдела, ИМХО, он обычно не нужен.
Есть две основные причины разделения:
Первая причина наиболее очевидна - вам нужно изолировать области, которые будут заполнены файлами, от тех, которые этого не сделают, и вы особенно хотите защитить /, чтобы избежать незагружаемой системы. Например, каталог / var обычно является местом хранения файлов журнала (var означает «переменная»), и именно поэтому / var обычно монтируется в разделе, отличном от /.
Вторая причина, указанная выше, менее цитируется (последний раз я слышал ее на курсе Veritas Volume Manager около 15 лет назад), и она действительно актуальна только для систем, в которых много людей входят в систему и выполняют работу.
В эффективном разделении на разделы есть что-то вроде искусства, и, возможно, поэтому есть системные администраторы, которые заходят слишком далеко (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 /
при использовании точки монтирования / home
при использовании точки монтирования / opt
при использовании точки монтирования / usr
при использовании точки монтирования / var
при использовании точки монтирования / tmp
Я должен спросить, прежде всего, почему вы вообще задаете этот вопрос здесь, будучи биологом, который спорит с очевидно компетентным системным администратором по поводу тонкостей разбиения жесткого диска! (без обид, просто интересно, почему вы не доверяете своему системному администратору).
Итак, несколько наблюдений:
1,3 ТБ - это уже не большой диск. 2 ТБ - это более или менее стандартный размер диска SATA для настольных компьютеров в наши дни.
для установки любого дистрибутива Linux вряд ли потребуется более 100 ГБ. Конечно, размер для / (корень) и (своп) должен быть легко определен как числа с верхним пределом, сильно увеличив их размер (для корня) или руководствуясь рекомендациями по конфигурации системы (своп).
точка монтирования для / home должна указывать на что-то на вашем RAID-сервере 40 ТБ. Нет необходимости, чтобы эти данные, домашние каталоги пользователей, находились где-либо на этом корневом устройстве. Размещение их на сервере RAID, вероятно, в любом случае даст вам лучшую защиту. И, скорее всего, это легко расширяемое хранилище NAS, тогда как небольшой RAID, встроенный в серверную коробку, скорее всего, нет.
вам, вероятно, следует поместить свое специальное программное обеспечение в отдельный раздел (точка монтирования для / usr / local / bin и т. д.), чтобы вы могли сохранить это при обновлениях ОС и очистке корневого раздела. В противном случае вы столкнетесь с вероятностью того, что вам придется переустанавливать свои «специальные» программные приложения после обновления / исправления ОС или чего-то еще.
Если вы хотите беспокоиться об администрировании вашей системы, я бы задала другой вопрос: каков процесс аварийного восстановления после возгорания здания и уничтожения серверов и RAID-блоков? Если данные, о которых вы заботитесь, не остаются полностью в вашей голове, это вопрос, который каждый пользователь должен задать своим ИТ-специалистам / системным администраторам. Стратегия должна включать такие вопросы, как «как мы будем копировать необходимое нам оборудование» и «сколько времени потребуется, прежде чем мы сможем снова приступить к работе». Некоторое обсуждение виртуализации ваших серверов может помочь решить проблемы, связанные с зависимостями оборудования, а также с резервным копированием и запуском без необходимости перенастраивать вашу ОС (поскольку ее можно настроить для работы в «программной» среде устройства, которая не меняется, даже если базовое оборудование совершенно другое)
Точно так же вы можете спросить, какова стратегия защиты пользовательских данных от потери данных из-за программных и пользовательских ошибок. Сохранение пустого файла поверх действительно отличного черновика вашей исследовательской статьи или если пользователь вводит неправильную команду (например, rm -rf *), это приведет к потере данных с такой же вероятностью, как землетрясение, пожар или другой физический ущерб. Решения для восстановления отдельных файлов немного отличаются (или могут быть!) От наиболее полезных для массового аварийного восстановления.
Это позволяет выполнять резервное копирование, восстановление или переустановку операционной системы независимо от пользовательских данных. Это дает вам свободу, независимость и безопасность.
Намного проще перейти на другой дистрибутив Linux, сохранив при этом абсолютное большинство пользовательских данных.
Отменить обновления с ошибками легко, применив резервную копию раздела операционной системы (требуется двойная загрузка). Эта резервная копия может быть даже довольно старой - вы можете применить ее, а затем обновить до заведомо стабильной версии.
Если вам не нравится недавно примененное «серьезное обновление» (требуется двойная загрузка), вернуться к предыдущей версии операционной системы просто.
Для наибольшего потенциала этого подхода вам также следует настроить двойную загрузку (также может быть CentOS / CentOS), чтобы вы могли перезаписать один раздел операционной системы при запуске операционной системы из другого. И, конечно же, вы должны делать резервную копию системного раздела хотя бы раз в несколько месяцев.
Мой короткий ответ заключается в том, что даже на рабочем столе никогда не следует использовать «один большой раздел». Я недавно попробовал это вопреки моему здравому смыслу, потому что это был «просто ноутбук», а автоустановщик использовал один раздел, и я просто нажал кнопку.
Когда я пошел устанавливать другой дистрибутив, мне пришлось перераспределить диски, потому что установщик не собирался устанавливать поверх существующего дистрибутива. Он может и БУДЕТ сохранять ваш / home нетронутым, если он находится на отдельном разделе. Итак, я закончил загрузку gparted live-cd и сжал раздел, создал новые разделы для / home и других, переместил мои данные в новые разделы, а затем, наконец, загрузился в установщик для новой ОС.
В идеале, установите / на SSD, / home на жесткий диск, / var на жесткий диск, / usr может быть на SSD или HDD, в зависимости от того, как часто вы планируете обновляться. / tmp на жесткий диск. Я обычно делаю еще один раздел для общих мультимедийных файлов, таких как mp3 и фильмы, с символическими ссылками на него из моего / home. Обратите внимание, что / sbin является частью root, а также / bin и / root. В этом разница между / bin и / usr / bin, это то, что / usr - это то, что может быть недоступно, пока все ваши диски не будут смонтированы, поэтому команда монтирования не может находиться в / usr! Я обычно сохраняю пару дополнительных разделов для других дистрибутивов Linux, например, gparted на моем жестком диске на случай, если я испорчу что-то действительно плохое, у меня есть еще одна живая система, готовая выполнить восстановление.
Для сервера, на котором вам может потребоваться перемещать вещи, динамически добавлять хранилище и который должен постоянно работать, определенно используйте LVM !!!
Вам не нужно устанавливать программное обеспечение в / usr / local, вы можете установить все программное обеспечение с другим префиксом, который может находиться в / home. Большинство программ могут сделать это, когда вы компилируете их из исходного кода, например, запустив ./configure --prefix=/home/bin
Поскольку вы биолог, вас может заинтересовать много программного обеспечения, которое неправильно упаковано в rpm или deb, и вам все равно придется скомпилировать его из исходников.
Я системный администратор системы HPC, среди наших пользователей много биологов, мы устанавливаем все программное обеспечение, которое они запрашивают, в файловую систему / apps /, поэтому я знаю, что это возможно для большинства программ, однако иногда это может быть быть очень жестким. Чтобы решить эту проблему, я и мои коллеги использовали инструмент под названием EasyBuild (Бесплатно и с открытым исходным кодом) Он может компилировать и устанавливать программное обеспечение из исходного кода, а также устанавливать его в другую папку и автоматически создавать модуль среды файл для вас, так что вы можете установить две разные версии одного и того же программного обеспечения и не иметь конфликтов.
Взгляните на наши список пакетов мы можем установить с помощью одной команды, как биолог, вы можете узнать много из них ;-)
Отказ от ответственности: я разработчик EasyBuild
Я думаю, что в целом для новичка / начинающего пользователя * ix можно работать с наименьшим количеством разделов, пока не узнает больше о природе системы. Однако у вас не может быть просто одного паритета, и в вашем случае, сэр, по нескольким причинам.
Первая и более общедоступная практическая причина этого заключается в том, что для большинства систем Linux требуется раздел подкачки (обычно он должен находиться между 1-2 * вашей ОЗУ), также требуется отдельный системный, загрузочный или домашний раздел, а в случае загрузки UEFI-систем Linux раздел EFI (всего 500 МБ).
Вторая причина, особенно применимая к вашей ситуации, заключается в том, что брать 6 дисков по 300 ГБ и делать из них raid 6 не является, мягко говоря, оптимальным расположением. Хотя новая технология приветствует Raid 6 как универсальную лучшую систему, алгоритм чередования требуется больше, а пространство, необходимое для хранения информации (по сравнению с RAID 5), больше по размеру.
Не говоря уже о том, что для RAID 6 требуется дополнительное оборудование. Что, по моему уважительному мнению, следует использовать в вашем случае для покупки дисков большего размера, чтобы избежать сбоев диска, простоев, аварийного восстановления или дополнительных затрат на техническую помощь. Я понимаю, что некоторые, может быть, многие не согласятся со мной, и я хочу еще раз подтвердить, что, когда диски станут больше в размере в течение следующих двух лет (поскольку они упали в цене за последние несколько лет), RAID6 для больших массивов и очевидным выбором будут корпорации с большим доходом. Однако в этом случае я не предлагаю использовать RAID 6.
Что касается второй проблемы (без RAID), создание одного гигантского раздела при зеркалировании может сработать для вас, однако, если вы хотите максимизировать эффективность, используйте диски большего размера и несколько разделов. Таким образом, если у вас произошел сбой двойного диска, у вас не будет простоев на определенных точках монтирования или будет немного, в зависимости от каталога / dev + /.
По крайней мере, пусть ваш / sys (система, ядро и т. Д.) Запускается отдельно, чтобы, если по какой-либо причине ваше ядро решает не загружаться, вы можете просто использовать ядро восстановления, удаленную загрузку или PXE, загрузку с диска и т. Д. Ваше ядро и иметь компанию- широкий доступ к вашей информации во время процесса d-восстановления.
Ваша компания может не заботиться об этих акцентах, пока система работает, но я пытаюсь объяснить причины, по которым люди что-то делают. Я также хотел бы услышать больше от других за и против этого аргумента и поднять другие вопросы. Если вы не согласны, дайте мне знать, почему. Плакат - Я также отправлю вам в личку несколько ссылок.
Одна любовь к нашему сообществу Linux Спенсер Рейзер
PS Особенно на сетевых серверах или системах, доступных для широкой публики, даже если через учетные данные, было бы действительно лучше разделить ваши разделы. Другие могут ввести здесь больше, мне нужно еще кофе.