"Ще вдень" ми завжди відокремлювали наші диски ОС (в Windows) від наших накопичувачів даних. У світі Linux, хоча я з цим набагато менше знайомий, я знаю, що мудрість диктує ще більше обсягів, визначених та використовуваних у конфігурації найкращих практик.
Тепер, коли сховище на сервері так само є на SAN (де дискові ресурси поділяються багатьма окремими операційними системами та програмами), чи справді вже не важливо, що розділи ОС і Дані будуть відокремлені на рівні гучності?
Які ваші думки?
Відповіді:
Існує три основні драйвери для збереження операційної системи для зберігання ОС та даних.
Крім того, деякі операційні системи (серед яких Windows) не надто люб'язно змінюють розмір об’єму ОС, а це означає, що вам, як правило, потрібно віддавати стільки, скільки потрібно для його форматування під час форматування сервера. Порівнюйте це з томами даних, які можна і часто змінювати за багато разів протягом життя сервера. Навіть у повністю віртуалізованих середовищах, де ОС і Datavvolumes розміщуються в одній фактичній пам’яті, неможливість змінити об'єм вашої ОС може бути головним негативним фактором. Зараз Windows 2008+ рекомендує 30 Гб для диска C: \, що набагато більше, ніж 10 Гб, який ми використовували на сервері 2003; це те, що приверне багато адміністраторів Windows під час перетворення з 2003 по 2008 рік.
Так, швидше за все, відокремлюють ОС від даних. Я знову і знову бачив, коли зі спільним розділом розділ закінчується заповненням і унеможливлює виправлення ОС, неможливе розширення розділу (через різні причини) тощо.
IMO, накладні витрати на управління двома перегородками - це невелика ціна, яку потрібно заплатити за надану ізоляцію.
Що стосується систем, підтримуваних SAN, про які ви згадували, вони все ще не захистять вас від заповнення даних вашого ОС. При повністю віртуалізованому сховищі вам не потрібно переживати над тим, щоб забезпечити, щоб ОС і дані працювали на окремих шпинделях.
Загалом, я думаю, що відокремлення простору ОС за замовчуванням (наприклад, C :) від даних (D :) - це гарна ідея, але я б також рекомендував створити менший розділ для файлів журналу (L :), щоб їх трохи не було). більш безпечні та запобігають деяким видам атак на відмову від обслуговування.
Linux дуже приємний тим, що файлова система залишається ієрархічно під одним кореневим каталогом незалежно від того, скільки фізичних дисків або віртуальних розділів ви використовуєте. Я б напевно розділив диск, але це не обов'язково для поділу даних проти ОС (оскільки дуже часто вони все-таки змішуються).
Я б подивився на:
Рекомендації щодо розподілу розділів для Linux (ну, справді Unix) частково пояснюються його джерелами як (мережева) ОС сервера мейнфреймів, на що, як я підозрюю, вплинула (тодішня) відносна ненадійність обладнання. Наприклад, журнали та тимчасові дані, як правило, відокремлюються, оскільки ці місця зберігання сильно зношуються, але це не було великою проблемою, якщо вони були втрачені.
Якщо ви будуєте настільну систему, я б пішов на поділ data / non-data / swap. Якщо ви не будуєте сервер, який очікує серйозного відмови, такі речі, як seperate / usr / local та / var / tmp, просто стають головним болем при розподілі місця.
Я б сказав, що це все-таки приємно мати - у вас є 100Gb даних (занадто багато pr0n чувак :)), і вам потрібно перевстановити ОС (або, відповідно до історії Windows, регулярно перевстановлюйте її, щоб видалити вбудовану версію cruft), то його дуже проста справа - зберегти його неушкодженим, ніж якби він був і на C-розділі.
Однак я б сказав, що в цьому є проблема, оскільки Windows особливо любить вміщувати всі види матеріалів у каталоги на диску C - це не лише каталог користувачів, але всі дані програми та різні біти та шматочки, які в кінцевому підсумку застрягли в ProgramData теж.
Крім того, є ще один фактор - окрім дійсно великих речей (так, знову, що pr0n), існує безліч інструментів резервного копіювання в Інтернеті (або локальних утиліт резервного копіювання), які виконують постійне резервне копіювання. Враховуючи ці, не такий пріоритет для розділення даних, оскільки ви можете легко відновити їх із резервного місця.
Особисто я намагаюся розділити дані + ОС. Я також намагаюся розміщувати програми на іншому розділі, щоб мої резервні копії ОС були значно меншими.
Я буду прихильником диявола для іншої школи думки.
Припустимо, з причин продуктивності ваш постачальник рекомендує розділ ОС не "рідкий", і хоче, щоб ви виділили повний розділ ОС наперед. Це призводить до 10Gb до 20Gb (або більше) невикористаного простору на накопичувачі SAN.
Це добре для однієї VM, але, швидше за все, у вас буде декілька "критично важливих" серверів, кожен з яких має власні 10–20 Гбіт пробілів. У нашому середовищі цей пробіл становив 20% нашого диска SAN. Майте на увазі, що є обмеження, до яких нам слід заповнити SAN-диск (але це вже інша історія).
У менеджменту був вибір
1) Поглиньте 20% витраченого простору на SAN, що є доповненням до інших вимог "білого простору", і виділіть будь-який сценарій "повного диска", який може виникнути
2) Покладіть усе на диск C: \ і ризикуйте заповнити диск через журнали додатків.
Що вони зробили?
Враховуючи, що Windows 2008R2 може динамічно розширювати привід C: \ хост-операційної системи та може розширювати накопичувач, коли повноцінне, керівництво взяло "економію" витрат і реінвестувало його в інструменти моніторингу, такі як SCOM.
Тепер ми отримуємо більше, ніж просто простий захист заповнення диска C: \, але у нас є більш повний моніторинг систем для вирішення інших проблем, перш ніж це станеться.