Разбиение сервера на разделы и структура файловой системы

При планировании перегородок следует помнить о режимах отказа. Обычно этот вопрос имеет форму: "Что происходит, когда разделение Икс заполняется? »Дорогой voretaq7 поднял ситуацию с полным / вызывая любое количество трудных для диагностики проблем. Давайте посмотрим на некоторые более конкретные ситуации.

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

Что происходит в системе на основе RPM, когда /var полон? Диспетчер пакетов не будет устанавливать или обновлять пакеты и, в зависимости от вашей конфигурации, может автоматически выйти из строя.

Заполнить раздел легко, особенно когда пользователь может писать в него. Ради интереса запустите эту команду и посмотрите, как быстро вы сможете создать довольно большой файл: cat /dev/zero > zerofile.

Это выходит за рамки заполнения разделов: когда вы размещаете места в разных точках монтирования, вы также можете настраивать их параметры монтирования.

Что происходит, когда /dev/ не установлен с noexec? поскольку /dev обычно предполагается, что она поддерживается ОС и содержит только устройства, которые она часто (а иногда и до сих пор) использовала для сокрытия вредоносных программ. Уходя noexec позволяет запускать хранящиеся там двоичные файлы.

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

Если мы посмотрим на RedHat Enterprise Linux 6, рекомендуемая схема разбиения будет следующей:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

Принцип, лежащий в основе всех этих изменений, состоит в том, чтобы предотвратить их влияние друг на друга и / или ограничить то, что может быть сделано на определенном разделе. Возьмите варианты для /tmp например. Это говорит о том, что там нельзя создавать узлы устройств, оттуда нельзя запускать никакие программы, и бит set-uid не может быть установлен ни на чем. По самой своей природе /tmp почти всегда доступен для записи всем и часто представляет собой особый тип файловой системы, которая существует только в памяти. Это означает, что злоумышленник может использовать его в качестве простой промежуточной точки для удаления и выполнения вредоносного кода, а затем при сбое (или просто перезагрузке) система сотрет все улики. Поскольку функциональность /tmp не требует какой-либо из этих функций, мы можем легко отключить эти функции и предотвратить такую ​​ситуацию.

Места хранения журналов, /var/log и /var/log/audit вырезаются, чтобы защитить их от истощения ресурсов. Кроме того, auditd может выполнять некоторые специальные действия (обычно в средах с более высоким уровнем безопасности), когда его хранилище журналов начинает заполняться. Помещая его в свой раздел, это обнаружение ресурсов работает лучше.

Чтобы быть более подробным, цитирую mount(8), это именно то, что использовалось выше:

noexec Не разрешайте прямое выполнение любых двоичных файлов в смонтированной файловой системе. (До недавнего времени в любом случае можно было запускать двоичные файлы с помощью команды типа /lib/ld*.so / mnt / binary. Начиная с Linux 2.4.25 / 2.6.0 этот трюк не работает.)

nodev Не интерпретируйте символы и не блокируйте специальные устройства в файловой системе.

без жидкости Не позволяйте битам set-user-identifier или set-group-identifier вступать в силу. (Это кажется безопасным, но на самом деле довольно небезопасно, если у вас установлен suidperl (1).)

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

Также имейте в виду, что домашний каталог пользователя root по умолчанию - /root. Это означает, что он будет в / файловая система, не в /home.

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

В прошлом я рекомендовал следующее в качестве исходных.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

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

Игнорирование базового массива RAID (См. Этот вопрос для получения дополнительных сведений об уровнях массива RAID и о том, когда вы хотите их использовать.), давайте сосредоточимся на основном вопросе, который вы задаете:
«Как мне расположить файловые системы моего Unix-сервера?»

Что не так с одним гигантом / раздел?

Как вы отметили в своем вопросе, многие дистрибутивы Linux (особенно дистрибутивы «Desktop», такие как Ubuntu) используют очень простую структуру файловой системы: / и [swap].

Эта схема имеет преимущество простота - отлично подходит для пользователей DOS / Windows, которые привыкли к домашнему ПК с «жестким диском» как одним большим монолитным контейнером (C:\), в который вы сбрасываете файлы, и вам не нужно беспокоиться о нехватке места в файловых системах - просто убедитесь, что вы не превышаете емкость диска, и все (по крайней мере, теоретически) в порядке.

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

Вышеупомянутые проблемы плюс четкое чувство организации - вот почему серверы Unix обычно имеют несколько файловых систем.

Как разбить файловую систему Unix?

Надеюсь, вы убедились в том, что наличие нескольких файловых систем имеет смысл. Теперь вопрос в том, как разбить систему на логические части и как решить, сколько места получит каждый?
Ответ заключается в том, что вы знаете и понимаете, что ваша операционная система будет размещать. Отправной точкой для этого понимания является hier справочная страница. Большинство систем Unix поставляются с (man hier из системы Linux, и man hier из системы BSD), и это плюс ваше знание того, что код ты are install is going to do, поможет вам создать разумную схему разбиения на разделы.

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

Общая схема разбиения на разделы Unix

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Специальные файловые системы

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

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

Практически нет причин делать это больше. Единственная оставшаяся причина для этого - если вы хотите, например, предотвратить /tmp от заполнения всего диска.

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

Что касается того, какой уровень рейда использовать, вы должны помнить, что основная цель рейда - не защита данных (для этого нужны резервные копии), а поддержание времени безотказной работы. Если вы положите /tmp на raid0, ваш сервер все равно выйдет из строя, и вам придется его ремонтировать, если один из дисков выйдет из строя. Вы также можете использовать raid10 вместо raid1, чтобы повысить производительность.

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

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

Я бы увеличил swap и смонтировать /tmp на tmpfs. Вы /tmp затем будет использовать подкачку в качестве резервного хранилища, но использовать память по мере ее доступности. Размер вашего /tmp выглядит очень высоко, но будет обрабатывать прерванную загрузку, которая не была очищена.

Я бы подумал о перемещении файлов MySQL в /srv. Это относительно новый уровень в иерархии дисков.

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

В зависимости от вашей архитектуры - вы можете не захотеть использовать / tmp, поскольку он очищается после каждой перезагрузки. Если ваш сайт имеет дело с окончательной обработкой загрузок, можно изменить это место (через php.ini); в котором вы можете сделать любую точку монтирования.

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

Я также настоятельно рекомендую выделить отдельный раздел для данных MySQL (вы все равно можете смонтировать его в / var / lib / mysql).