Розділення та розміщення файлової системи Unix


29

Існує багато суперечливої ​​інформації про розділення сервера Unix в Інтернеті, тому мені потрібні поради щодо того, як діяти далі.

Поки що на серверах, що знаходяться в нашому тестовому середовищі, я не дуже переймався розділенням, і я налаштував єдиний монолітний /плюс swap-розділ. Ця схема розподілу не здається гарною ідеєю для наших виробничих серверів. Я знайшов хорошу відправну точку тут , але мені здається , дуже розпливчастим на деталях.


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

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

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

Це звучить здорово, чи я занадто ускладнюю речі?


1
Яка ваша кінцева мета? Що саме ви намагаєтеся досягти?
Скотт Пак

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

Відповіді:


33

Одне, що потрібно пам’ятати, коли викладаєте перегородки, - це режими відмов. Зазвичай це питання має форму: "Що відбувається, коли розділ 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вирізане, щоб допомогти їх захистити від виснаження ресурсів. Крім того, аудид може виконувати деякі особливі речі (як правило, у більш високих середовищах безпеки), коли його сховище журналу починає заповнюватися. Розмістивши його на своєму розділі, ця система виявлення працює краще.

Щоб бути більш детальним і цитувати mount(8), саме так описані вище варіанти:

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

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

nosuid Не дозволяйте набір ідентифікатора користувача set або біт-ідентифікатор групи набути чинності. (Це здається безпечним, але насправді є досить небезпечним, якщо у вас встановлений 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 і проти виділення всього диска. Це дозволить вам легко виростити або додати розділи, якщо такі речі потрібні.


1
noexecСпостереження є важливою в цілому - це вважається хорошою практикою для установки /tmpз noexecпрапором , щоб уникнути зловмисних користувачів UPLOADING руткітів з допомогою експлойтів безпеки браузера. Аналогічно /homeчасто встановлюється, nosuidоскільки немає ніяких причин для встановлених бінарних файлів. Re: /devі noexecна багатьох (хоча і не всіх) сучасних системах /devчасто є devfsфайлова система і не дозволяє користувачам створювати / зберігати звичайні файли взагалі (у FreeBSD він повертається " Operation not supported", в Ubuntu udevфайлова система, встановлена ​​на /devдозволяє створювати звичайні файли. ).
voretaq7

2
@ voretaq7: Так, використання /tmpв якості стрибка для стрибків - це велике задоволення, оскільки воно завжди є і майже ніколи не замикається.
Скотт Пак

Дякую за поради з тези. Я перевірю на noexec, оскільки це покращує безпеку!
Бузут

12

Ігноруючи базовий масив RAID ( див. Це питання для отримання більш детальної інформації про рівні RAID-масиву та коли ви хочете їх використовувати ), давайте зосередимось на основному питанні, яке ви задаєте:
"Як я маю викласти файлові системи мого сервера Unix?"


Що не так з однією гігантською /секцією?

Як ви зазначали у своєму запитанні, у багатьох дистрибутивах Linux (особливо у настільних дистрибутивах, як Ubuntu) використовується дуже проста компонування файлової системи: /і [swap].

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

У схеми однофайлової системи є кілька недоліків - найпоширенішим недоліком є ​​те, що системи Unix, як правило, дуже погано реагують, коли коренева файлова система заповнюється (до відмови від завантаження), і якщо все пише в /(root) одна спрямована програма або користувач може зняти всю систему.
Єдина велика файлова система також схильна до повної втрати у випадку збою системи та подальшої пошкодження файлової системи.

Вищезазначені питання, а також сильне почуття організації - це те, чому Unix-сервери зазвичай мають декілька файлових систем.


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

Тож сподіваємось, ви переконані, що мати декілька файлових систем має сенс. Питання зараз полягає в тому, як ти розбиваєш систему на логічні шматки, і як ти вирішуєш, скільки місця отримує кожен?
Відповідь - ви знаєте і розумієте, куди подіться ваша операційна система. Вихідним моментом для цього розуміння є hierсторінка man. Більшість систем Unix оснащені ( man hierз системи Linux та man hierBSD ), і плюс ваші місцеві знання про те, який код ви встановлюєте, буде орієнтувати вас у створенні здорового макета розділів.

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

Загальна схема розбиття 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.

2
Дві причини, які ви перерахували, сьогодні значною мірою застаріли. ext [234] залишає деякий простір для root та не дозволить програмам користувачів все це використовувати, тому система не матиме проблем із відсутністю місця, а всі сучасні файлові системи використовують журнал, щоб вони не пошкодилися після крах.
psusi

2
@psusi Простір, відведений для кореневого користувача (як правило, 5-10% розміру файлової системи), не допоможе вам, якщо користувачем root є той, хто пише файли, що заповнюють диск (як це часто буває з файлами журналів). Неправильно також припускати, що лише через керування файловою системою вона завжди буде захищена від корупції - журнал збільшує надійність, але це не гарантує безпеки (особливо якщо натрапити на нерозкриту помилку у файловій системі / журнальному коді та згортати журнал - Люди з ReiserFS можуть розповісти про це чудові історії з перших днів цієї файлової системи).
voretaq7

2
Непошкодженим /usrабо /varне допомагає, якщо /він пошкоджений. Так само недоторканість /не допомагає (сильно), якщо /homeвона пошкоджена. Зрештою, вам доведеться відновити з резервного копіювання будь-який спосіб. Не кажучи вже про такі невдачі - один мільйон, якщо ви не працюєте з новою / нестабільною ФС.
psusi

4

Практика створення файлової системи подібна до тих часів, коли не було програмного нальоту, а дискові накопичувачі були невеликими, тому вам довелося використовувати декілька з них, і таким чином, єдиний спосіб зробити це - зламати файлову систему і розміщувати різні каталоги на різних дисках. Інша історична причина цього полягала в тому, що ви могли легко відключити розділ і dumpйого для резервного копіювання, що ви не могли зробити з коренем. Цей інструмент значною мірою прийшов у непридатність в наші дні, і натомість його можна використовувати на знімку LVM навіть у корені.

Причин для цього вже мало. Про єдину причину, що залишилася це зробити, це якщо ви хочете, наприклад, не дозволяти /tmpзаповнювати весь диск.

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

Що стосується того, який рівень рейду використовувати, потрібно пам’ятати, що головна мета рейду - не захист даних (саме для цього створюються резервні копії), а підтримка часу роботи. Якщо ви поставите /tmpraid0, то ваш сервер все-таки знизиться, і вам доведеться його відремонтувати, якщо один з дисків вийде з ладу. Ви також можете використовувати raid10 замість raid1, щоб ви також отримали кращу ефективність.

Дуже вагомою причиною НЕ порушувати файлову систему є те, що якщо ви неправомірно розподілилися, ви можете закінчити повну частину файлової системи, незважаючи на те, що в іншому місці є багато вільного місця. Виправити це може бути складно, якщо ви не використовуєте LVM і не залишили місця без призначення.


4
Є багато причин для продовження створення традиційної системи файлової системи Unix. Якби не було причин для цього, ми б зараз зупинилися - sysadmins не ТО, що прив’язані до
таємничих

1
@ voretaq7, то назвіть деякі. Якщо ви не можете, то сліпо вважати, що повинно бути, є дурним.
psusi

1
Тим, хто схиляється до того, щоб насправді надати протилежний аргумент, а не сліпо папугати звичайною мудрістю.
psusi

2
Захищає / var / log не брати все, заповнюючи. Обмежує пошкодження файлової системи. Спрощує резервне копіювання - будь то знімки або правила монтажу проходу, часто хочеться створювати резервні копії речей за різними графіками. Спрощує зображення / оновлення. Дозволяє вибирати продуктивність на основі файлових систем, пов'язану із завданням.
Джефф Ферланд

1
@JeffFerland, в кращому випадку це слабка причина розмістити / var / log на своєму власному розділі, але не для кількох інших розділів. Якщо ви все ще не використовуєте dump, резервне копіювання різних частин файлів не потрібно, щоб ці частини були на різних розділах. Оновлення не турбуються так чи інакше. Зображення теж не дуже хороший спосіб робити речі.
psusi

3

Багато інформації про розділення було створено, коли мені не вистачало місця на диску. В результаті ви побачите відносно невеликі розділи для ряду випадків. Необхідні розміри розділів залежать від використання сервера. Найбільш змінної , як правило /tmp, /var, home, /opt, і /srv. /usrмає тенденцію бути розумним і стабільним розміром. Простір для /може містити будь-які або всі інші перегородки та їхні вимоги до місця. Розміри дійсно залежать від того, що ви робите в системі.

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

Я б розглядав можливість переміщення файлів MySQL /srv. Це відносно новий рівень в ієрархії диска.

Якщо ви не знаєте своїх кінцевих вимог, подумайте про використання LVM та розширення розділів як заповнення.


Будьте обережні, збільшуючи своп - Добре мати "достатньо" заміни, але якщо у вас занадто багато, ви ніколи не будете користуватися ним (адже до того часу, коли ви поміняєтесь, то продуктивність системи просто надто болісна). Я б сказав, що запропонований у запитанні 4G, ймовірно, "достатній" для стека LAMP - якщо ви використовуєте 4G свопу (і насправді перезаписуєте ці дані в і поза), ви, ймовірно, також по телефону кричали, оскільки веб-сайт повільний :)
voretaq7

1
@ voretaq7 Не має значення, який розмір розміру є, якщо ви використовуєте для активних програм. Використання його для tmpfs, де великі файли виписуються на диск, але менші файли залишаються в пам'яті - це розумне використання swap. Це дозволяє економити на записі кожного файлу на диск, коли має намір помістити його в інше місце. Я запропонував збільшити обмінний простір, оскільки, здається, /tmpможе знадобитися великий простір.
BillThor

Чому б не використовувати звичайний файл для swap? Чи давно вони не були такими швидкими, як спеціалізований розділ для заміни?
Кріс Сміт

@ChrisSmith Звичайний файл повинен бути майже таким же швидким, як виділений розділ, але він може не бути суміжним на диску, що веде до розбиття запитів вводу / виводу. Це може бути складено за допомогою смугастих. Крім того, відносно легко випадково видалити файл свопу. Видалений файл не стане очевидним, поки система не перезавантажиться, коли в ньому більше не буде місця для обміну.
BillThor

@BillThor Це правда - якщо ви використовуєте tmpfsі очікуєте, що ви отримаєте swap як резервний магазин, у вас повинен бути "достатньо" свопів, щоб відповідати вашим вимогам tmpfs, а також відповідний резерв для системи. (Це я не те, про що я зазвичай думаю, оскільки єдина система, в якій я використовую tmpfs, налаштована не для удару свопом, оскільки вона має надлишок оперативної пам’яті, і я використовую тимчасовий простір для крихітних файлів, які швидко створюються / видаляються :)
voretaq7

2

Залежно від вашої архітектури - ви, можливо, не захочете фактично використовувати / tmp, оскільки це очищається після кожного перезавантаження. Якщо ваш сайт займається можливою обробкою завантажень, зміна цього місця на інше місце (через php.ini) може бути ідеєю; в якому ви можете зробити це будь-якою точкою кріплення.

Як було запропоновано раніше, настійно рекомендується використовувати LVM та приріст за потребою.

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


Як правило, гарна ідея припустити, що файлів у /tmpпізніше не буде, - позбавить вас від неприємних сюрпризів пізніше :-)
voretaq7
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.