Unix-сервер и разделы файловой системы

В Интернете много противоречивой информации о разделении Unix-серверов, поэтому мне нужен совет, как действовать дальше.

До сих пор на серверах I в нашей тестовой среде , я не забочусь о разделении и я настроил единый монолитный /плюс раздел подкачки. Такая схема разбиения не кажется хорошей идеей для наших производственных серверов. Я нашел хорошую отправную точку здесь , но это кажется очень расплывчатым в деталях.

В основном у меня есть сервер, на котором я буду работать с базовым стеком LAMP (Apache, PHP и MySQL). Он должен обрабатывать загрузки файлов (до 2 ГБ). Система имеет массив RAID 1 объемом 2 ТБ.

Я планирую установить:

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

Это звучит нормально, или я слишком усложняю вещи?

При разметке разделов нужно помнить о режимах сбоев. Обычно этот вопрос имеет вид: «Что происходит, когда раздел x заполняется?» Дорогой 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вырезаны, чтобы помочь защитить их от исчерпания ресурсов. Кроме того, audd может выполнять некоторые специальные действия (обычно в средах с более высокой безопасностью), когда его хранилище журналов начинает заполняться. Размещая его в своем разделе, это обнаружение ресурса работает лучше.

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

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

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

nosuid Не разрешать вступать в силу битам 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) используют очень простую структуру файловой системы: /and [swap].

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

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

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

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

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

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

Общая схема секционирования 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заполнение всего диска.

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

Что касается уровня raid, который вам нужно использовать, вы должны помнить, что основная цель raid состоит не в защите данных (для этого нужны резервные копии), а в поддержании времени безотказной работы. Если вы установите /tmpraid0, ваш сервер все равно выйдет из строя, и вам придется его починить, если один из дисков выйдет из строя. Вы также можете использовать 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).