Чи все-таки при віртуалізації має сенс використовувати кілька точок кріплення?

Чи має сенс у 2013 році мати ще кілька точок монтажу на новому образі Linux, чи виділяючи весь простір для / має більше сенсу?

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

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

З багатьма віртуальними машинами ви все одно хочете відокремити IO. Ймовірно, ви хочете, щоб ваші бази даних були на окремих шпинделях, і єдиний спосіб досягти цього - це мати окрему точку монтування для вашої бази даних. Бази даних осторонь, це забезпечує більш детальну гнучкість у дорозі, якщо ви переросте свій оригінальний дизайн.

Отже, коротше, так, все ж є вагомі причини для цього у 2013 році.

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

Всього 2 або 3, особливо з тією, яка різниться за розмірами. Це залежить від того, що ви використовуєте. Я б сказав просто / (відносно стабільний) та / var (мінливий). Залежно від ОС та геометрії диска, / boot також може знадобитися. / tmp - це, ймовірно, кріплення tmpfs, встановлене інсталятором.

Зміна (/ вар, переважно, але може бути просто / var / log та / var / lib / mysql тощо), як правило, є тим, про що потрібно турбуватися та планувати розширення. Тому, якщо можливо, використовуйте lvm і т.д. для полегшення зміни розміру.

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

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

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

У своїх системах я намагаюся зробити наступне:

• / зазвичай невеликий і не дуже росте.
• /boot передбачуваний розмір, а зростання регулюється частотою оновлень ядра.
• /tmpзалежить від програми та середовища, але може бути відповідним розміром. Моніторинг її окремо допомагає ненормальній поведінці вимірювача та захищає решту системи.
• /usr Повинно бути передбачуваним, містити виконувані файли тощо.
• /varзростає, але кількість даних збільшити може бути меншим. Приємно, що можна вимірювати його окремо.
• І розділ для зростання. У цьому випадку, це /data, але якщо б це була система баз даних, це може бути /var/lib/mysqlабо /var/lib/pgsql... Зверніть увагу , що це інше блоковий пристрій, /dev/sdb. Це просто ще одна VMDK на цій віртуальній машині, тому вона може бути змінена незалежно від VMDK, що містить реальні розділи ОС.

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              12G  2.5G  8.8G  23% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             291M  131M  145M  48% /boot
/dev/sda7             2.0G   68M  1.9G   4% /tmp
/dev/sda3             9.9G  3.5G  5.9G  38% /usr
/dev/sda6             6.0G  892M  4.8G  16% /var
/dev/sdb1             360G  271G   90G  76% /data

Відокремлення деяких з цих розділів значно простіше визначити тенденції та виявити аномальну поведінку; наприклад, 4 Гб ядра /var, процес, який виснажує /tmp,

Нормальний

Ненормальне. Раптовий підйом /varне було б легко виявити, якби /була використана одна велика перегородка.

Нещодавно мені довелося застосувати коктейль параметрів та атрибутів монтування файлової системи (nodev, nosuid, noexec, noatime, nobarrier) для захищеного безпекою шаблону VM. Розділення були абсолютною вимогою для цього, оскільки деякі розділи вимагали конкретних налаштувань, які не можна було застосувати в усьому світі. Ще один пункт даних.

Впевнені, що кілька точок монтажу все ще мають свої переваги, віртуалізований сервер чи ні.

Але при віртуалізації ви, мабуть, також використовуєте шаблони віртуальних машин, правда? А ваша система моніторингу, наприклад Nagios (з NConf?), Також підтримує шаблони? Якщо так, то вам потрібно пройти цю боротьбу з розумовою горою лише один раз.

Повернутися до теми.

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

Для файлових серверів я також схильний монтувати /homeгучність на власному розділі / диску та використовувати noexecпараметр під час монтажу. Параноїя, але не дозволяє користувачам виконувати файли з домашніх папок.

Крім того, я схильний поміщати /bootгучність на дзеркало RAID 1 на всіх накопичувачах, але знову ж таки, за старою практикою, я випливаю, що я ще не бачу недоліків