Наскільки погано насправді встановити Linux на одному великому розділі?

Ми будемо запускати CentOS 7 на новому сервері. У нас є накопичувачі 6 x 300 Гб в raid6, внутрішні для сервера. (Зберігання значною мірою зовнішнє у вигляді рейдового вікна 40 Тб.) Внутрішній об'єм дорівнює приблизно 1,3 ТБ, якщо він форматований як один том. Наша система sadadmin вважає, що це дуже погана ідея встановити ОС на одному великому розділі 1.3TB.

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

Як ми можемо найкраще використовувати наявний 1,3 ТБ, щоб переконатися, що доступний простір, коли і де це потрібно, але не створити кошмар технічного обслуговування для sysadmin ??

Основними (історичними) причинами поділу є:

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

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

• Квота. Дискова квота дозволяє адміністраторові заборонити окремому користувачу використовувати весь наявний простір, порушуючи сервіс для всіх інших користувачів системи. Індивідуальна дискова квота призначається для кожної файлової системи, тому один розділ і, отже, одна файлова система означає лише 1 дисковий кворум. Кілька розділів (LVM) означає декілька файлових систем, що дозволяють більш детально керувати квотами. Залежно від сценарію використання, ви можете, наприклад, дозволити кожному користувачеві 10 Гб у своєму домашньому каталозі, 2 ТБ в каталозі / даних на зовнішньому масиві зберігання та встановити велику спільну область подряпин, де кожен може скинути набори даних занадто великі для свого домашнього каталогу і коли політика стає "повною є повною", але коли це відбувається, теж нічого не порушується.

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

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

• Настроювання Можливо, вам знадобляться різні параметри настройки або навіть зовсім різні файлові системи.

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

Зазвичай я рекомендую розділити основний об'єм на єдиний великий фізичний об'єм Linux LVM, а потім створити логічні томи, що відповідають вашим поточним потребам та на іншу частину вашого дискового простору, залишити без призначення, поки це не потрібно .

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

Скорочення обсягів LVM є тривіальним, але часто скорочення файлових систем на них не підтримується дуже добре, і, ймовірно, цього слід уникати.

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

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

Це можна запобігти, якщо ви використовуєте різні розділи для місць, у яких користувачі або процеси зазвичай пишуть (/ home, / var, / tmp).

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

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

Ви побачите, де накопичується найбільше даних, і правильно спроектуєте свою наступну систему. "-D 1" обмежує вихід лише на один рівень глибини папки, роблячи її більш зрозумілою.

Основна проблема створення єдиного великого розділу полягає в тому, що при заповненні файлової системи можливо не ввійти в систему вже неможливо.

Через корінь користувача є своя домашня папка ( /root) поза /homeцим. Якщо файлова система заповнена за певних обставин, навіть root не може увійти та не зможе відновити систему.

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

ІМХО, маючи один розділ як /, цілком розумно.

Але ви можете використовувати lvm (логічний диспетчер томів). Використовуйте весь диск як групу lvm, але створюйте невеликі логічні диски для /, / home, / usr і будь-якого, що бажає ваш sysadmin. Потім увімкніть деякий моніторинг, коли ви знаєте, коли ваша система почне заповнюватися, і розгорніть ті диски, які вам потрібні. lvresize and resize2fs - це онлайн-інструменти, і ви можете робити розширення без перезавантаження сервера. Однак ви не можете зменшити диски, тому вам потрібно почати розумно мале і збільшити там, де у вас є потреба.

Існують мінімальні проблеми навколо налаштування linux для одного-одного розділу, але це має великі винагороди.

Зміна макета розділів є дещо важкою та ризикованою справою, яку часто не обійтися без тривалих простоїв.

Єдиною його перевагою є те, що у вас є певний захист від повних проблем на диску. Але ви знайдете ці проблеми дуже часто. Уявіть ситуацію, якщо одна з ваших секцій повна, і ви не можете використовувати простір для інших розділів, навіть якщо вони майже порожні !

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

Існує проста система з назвою lvm , яка дозволяє в ході переміщувати / змінювати розмір "розділів" (у своїй термінології, томах). Але на одному локальному сервері департаменту IMHO зазвичай не потрібен.

Є дві основні причини поділу:

1. Щоб статичні дані були подалі від нестатичних даних
2. Захист загальнодоступних даних від приватних даних

Перша причина є найбільш очевидною - вам потрібно виділити області, які заповнюватимуться файлами, від тих, які не мають, і ви особливо хочете захистити /, щоб уникнути незавантажуваної системи. Наприклад, каталог / var, як правило, там, де будуть зберігатися файли журналу (var означає "змінну"), і саме тому / var має тенденцію встановлюватися на окремий розділ від /.

Друга причина, наведена вище, менш наводиться (я востаннє чув її на курсі Veritas Volume Manager близько 15 років тому), і вона справді стосується лише систем, де багато людей заходять у систему та виконують роботу.

Існує щось мистецтво для ефективного розподілу, і, можливо, тому є Sys Admins, які забирають це занадто далеко (IMO). Вам не тільки потрібно знати файлову систему зсередини, але ви також повинні знати її використання. Особисто я вважаю, що це досить старомодний підхід, який стає все менш актуальним для того, як сьогодні використовуються сервери.

Як розробник програмного забезпечення, мені особливо набридло створення віртуальних машин відділу Ops із бездумними схемами розподілу, які суттєво обмежують розмір / tmp, / home, / var та /, незалежно від загальної кількості дискового простору, але тоді не не можу встановлювати очевидні варіанти, такі як / usr або / opt окремо. Ці машини, як правило, розміщують все, що залишилося від дискового простору, про який ви просили, в "/ stuff" об'єм, який неминуче закінчуєтеся встановленням і символікою все, але це навряд чи втіха. Результатом цього є те, що ми часто витрачаємо більше часу на перемішування файлів і надсилання попереджувальних електронних листів, ніж на реальні роботи.

Немає нічого по суті "поганого" в тому, щоб мати єдину перегородку. У будь-якій системі вам слід активно проводити моніторинг використання вашого диска та застосовувати розумні стратегії ведення домашнього господарства (наприклад, обертання журналу, квоти в домашніх каталогах), тому єдиним реальним питанням є: скільки окремих файлових систем ви хочете турбуватися?

Тому я б сказав: якщо ви не впевнені на 100% у своїй здатності ефективно розподілити систему для вашого конкретного випадку використання, взагалі не розбивайте її .

ІМХО, цілком залежить від вас. Спочатку розглянемо кілька речей, хоча цілком дещо відносне.

• чи буде часто застосовуватися ця система?
• Чи буде цією системою користуватися один або кілька користувачів?
• чи буде ця система виконувати функції робочого столу чи сервера, або обох?

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

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

Це також залежить від того, як ви визначаєте використання для цієї системи, яке окреслює вимоги до розподілу. Використання для LVM включено.

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

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

Це забезпечує велику модульність вашої системи, вона також дозволяє робити такі дурні речі, як, наприклад, клонування цього розділу в VM. Або створення резервного копіювання на рівні блоків за допомогою dd.

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

Горизонт /

• 1 Гб (якщо використовуються окремі точки кріплення для / var / usr / opt / home / tmp)
• +10 або навіть +20 ГБ, якщо використовується як настільна система з окремим / домашнім

якщо ви використовуєте місце монтажу / будинок

• присвоїти весь вільний простір, якщо використовується, / home ne

якщо використовується точка монтажу / опт

якщо ви використовуєте mountpoint / usr

• це складний і дуже залежить від встановленої бази програмного забезпечення

якщо використовується точка монтажу / var

• це складний і дуже залежить від встановленої бази програмного забезпечення
• наприклад, бази даних записують свої дані сюди в системи на базі Debian, якщо не на всіх Linux
• мати окремий / var / tmp - це нерозумно

якщо використовується точка монтажу / tmp

• врахуйте, що tmpfs існує та виділяє / tmp в оперативну пам'ять
• Подумайте, деякі програми можуть записувати тут багато даних

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

Отже, кілька спостережень:

• 1,3 ТБ вже не великий привід. 2 ТБ - це більш-менш стандартний розмір накопичувача SATA у світі робочого столу в наші дні.

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

• точка монтажу для / home повинна вказувати на щось відключене на 40TB RAID-сервері. Немає необхідності в цих даних, домашніх каталогах користувачів, бути в будь-якому місці цього кореневого пристрою. Розміщення їх на RAID-сервері, ймовірно, забезпечує кращий захист. І, швидше за все, це легко розширювана програма NAS, тоді як маленький RAID, вбудований у серверну коробку, швидше за все, ні.

• ви, ймовірно, повинні помістити своє спеціальне програмне забезпечення в окремий розділ (точка монтажу для / usr / local / bin тощо), щоб ви могли зберегти це через оновлення ОС та серветки кореневих розділів. Інакше ви стикаєтесь з можливістю, що вам доведеться перевстановити свої "спеціальні" програмні програми після оновлення / виправлення ОС / будь-якого іншого.

• якщо ви хочете потурбуватися про адміністрацію вашої системи, я б задав інше запитання: що таке процес відновлення після аварій після того, як будівля загоряється, а сервери та коробки RAID знищуються? Якщо дані, які вам цікавлять, не залишаються повністю у вашій голові, це питання, яке повинен задати кожному користувачеві своїм ІТ / системним адміністратором. Стратегія повинна включати такі питання, як "як ми будемо копіювати необхідне нам обладнання" та "скільки часу пройде, перш ніж ми зможемо створити резервну копію та працювати". Деяка дискусія про віртуалізацію ваших серверів може допомогти вирішити проблеми навколо апаратних залежностей та відновити роботу резервних пристроїв без необхідності перенастроювати вашу ОС (оскільки це може бути налаштовано на запуск у "м'якому" середовищі пристрою, яке не змінюється,

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

-

Це дозволяє зробити резервну копію, відновити або перевстановити операційну систему незалежно від даних користувача. Це дає вам свободу, незалежність та безпеку.

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

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

3. Повернутися до попередньої версії операційної системи досить просто, якщо вам не подобається нещодавно застосований "великий оновлення" (потрібне подвійне завантаження).

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

Моя коротка відповідь полягає в тому, що навіть робочий стіл ніколи не повинен використовувати "одну велику секцію". Нещодавно я спробував це проти мого кращого судження, оскільки це був "просто ноутбук", і автоінсталятор використав один розділ, і я просто натиснув кнопку.

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

В ідеалі, поставте / на SSD, / home на жорсткому диску, / var на жорсткому диску, / usr може бути на SSD або HDD, залежно від того, як часто ви плануєте оновлення. / tmp на жорсткому диску. Зазвичай я роблю інший розділ для спільних мультимедійних файлів, таких як mp3 та фільми із посиланнями на нього з мого / будинку. Зауважте, що / sbin є частиною кореня, і є / bin та / root. Ця різниця між / bin та / usr / bin, is / usr - це речі, які можуть бути недоступні, поки всі ваші диски не змонтовані, тому команда mount не може бути в / usr! Зазвичай я зберігаю пару додаткових розділів для інших дистрибутивів Linux, наприклад, той, що знаходиться на моєму жорсткому диску, на випадок, якщо я викручую щось по-справжньому погано, у мене є інша жива система, готова виконати роботу з відновлення.

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

Вам не потрібно встановлювати програмне забезпечення до / usr / local, ви можете встановити все програмне забезпечення з іншим префіксом, який може бути в / home. Більшість програмного забезпечення може це зробити, коли ви компілюєте його з джерела, запустивши, наприклад ./configure --prefix=/home/bin

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

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

Погляньте на наш список пакетів, які ми можемо встановити лише за допомогою однієї команди, як біолог ви можете розпізнати їх багато ;-)

Відмова: Я розробник EasyBuild

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

Перша і більш публічно практична причина цього полягає в тому, що більшість усіх систем Linux потребує розділу swap (як правило, це має бути від 1-2 * вашої оперативної пам’яті) також вимагає окремої системи, завантажувальних або домашніх розділів і у випадку завантаження UEFI-систем Linux розділ EFI (всього 500 МБ).

Друга причина, спеціально застосовна до вашої ситуації, полягає в тому, що використання 6-ти дискових накопичувачів на 300 ГБ і здійснення їх рейду 6 не є, щонайменше, оптимальним рішенням. Незважаючи на те, що нові технології називають Raid 6 універсально кращою системою, алгоритм зачистки є більш необхідним і простір, необхідний для зберігання інформації (порівняно з RAID 5), має більший розмір.

Не кажучи вже про те, що RAID 6 вимагає додаткового обладнання. Який, на мою повагу, слід використовувати у вашому випадку для придбання великих дисків, щоб уникнути виходу з ладу диска, простоїв, відновлення після аварій або додаткових витрат на технічну допомогу. Я розумію, що деякі, можливо, багато хто не погодиться зі мною, і я хочу ще раз підтвердити, що коли диски набудуть великих розмірів протягом наступних двох років (оскільки вони впали в ціні за останні кілька) RAID6, для більших масивів і Очевидним вибором будуть великі доходи корпорацій. Однак у цьому випадку я не пропоную використовувати RAID 6.

До другого питання (не на основі RAID) створення одного гігантського розділу при дзеркальному відображенні може працювати для вас, однак, якщо ви хочете досягти максимальної ефективності, використовуйте більші диски та декілька розділів. Таким чином, якщо у вас є збій на двох дисках, у вас не буде простоїв на певних точках кріплення або мало, залежно від / dev + / dir.

Принаймні змусьте ваш / sys (систему, ядро ​​тощо) працювати окремо, так що якщо з якої-небудь причини ваше ядро ​​вирішить не завантажуватися, ви можете просто використовувати ядро ​​відновлення, віддалене завантаження або PXE, завантаження диска і т. Д. Ваше ядро ​​і мати компанію широкий доступ до вашої інформації під час процесу відновлення d.

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

Одна любов до нашого спільноти Linux Spencer Reiser

PS Особливо на мережевих серверах або системах, доступних для широкої громадськості, навіть якщо через облікові дані, було б справді найкраще відокремити свої розділи. Інші можуть більше вводити сюди, мені потрібно більше кави.