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

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

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

15
Чому ви повинні перезавантажити, щоб збільшити розмір точки монтування? Я думаю, що всі спільні файлові системи, які підтримуються в Інтернеті, розширюються в цій точці.
додано Автор TomG, джерело

5 Відповіді

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

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

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

17
додано
@onionjake Ні, не обов'язково. Але вони заваляться, якщо / заповниться.
додано Автор Pedro, джерело
Дякуємо за записку про те, що журнали виходять з-під контролю. Ці конкретні віртуальні машини використовують SAN, тому я вважаю, що IO вже розповсюджений і не викликає занепокоєння в цій конкретній ситуації.
додано Автор MooseLucifer, джерело
До цього моменту, якщо ви хочете, щоб одна віртуальна машина охоплювала кілька пулів VMFS у ESXi, вам доведеться використовувати декілька віртуальних дисків (які відображаються як фізичні диски в VM). Ви все ще можете об'єднати їх в одну точку монтування з LVM, якщо ви дійсно хочете, але це погана практика, на мій погляд.
додано Автор Paul Gear, джерело
Хіба машина ще не вдасться зупинитися, навіть якщо/var (або/tmp) у повному обсязі?
додано Автор Lucy Yang, джерело

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

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

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

5
додано
Я особисто використовую LVM і завантажується на своєму власному розділі, а не на групу томів, я вважаю (якщо ви використовуєте grub legacy).
додано Автор Timur, джерело

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

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

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

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

  • / is typically small and does not grow much.
  • /boot is predictable in size and the growth is controlled by the frequency of kernel updates.
  • /tmp is application and environment dependent, but can be sized appropriately. Monitoring it separately helps meter abnormal behavior and protects the rest of the system.
  • /usr Should be predictable, containing executables, etc.
  • /var grows, but the amount of data churn can be smaller. Nice to be able to meter it separately.
  • And a growth partition. In this case, it's /data, but if this were a database system, it may be /var/lib/mysql or /var/lib/pgsql... Note that it's a different block device, /dev/sdb. This is simply another VMDK on this virtual machine, so it can be resized independently of the VMDK containing the real OS partitions.

# 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

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

Normal enter image description here

Abnormal. The sudden rise in /var would not have been easy to detect if one large / partition were used. enter image description here


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

4
додано

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

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

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

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

2
додано
Як виявити проблеми, наприклад, /opt або /tmp під налаштування одного розділу?
додано Автор Pedro, джерело
Якщо сервер починає швидко з'їдати свій дисковий простір, щось на зразок du -m --max-depth = 4/| sort -nr | голова -n 30 | менше є дивно ефективним. І в контрольованому. моніторингу навколишнього середовища, скільки потенційних місць ви маєте для такого роду матеріалів? /var/log , /tmp , /opt/*/log , можливо щось інше? Не надто важко.
додано Автор Janne Pikkarainen, джерело

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

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

1
додано
Питання стосувалося віртуальних серверів, тому біт про/boot на RAID 1 не застосовується. Але це безумовно гарна ідея на фізичних серверах.
додано Автор Paul Gear, джерело