Имеет ли смысл использовать несколько точек монтирования при виртуализации?

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

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

Короче говоря, да, для этого в 2013 году все еще есть веские причины.

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

Всего 2 или 3, особенно. с одним, который различается по размеру. Это зависит от того, что вы используете. Я бы сказал, просто / (относительно стабильно) и / var (меняется). В зависимости от ОС и геометрии диска также может потребоваться / boot. / tmp, скорее всего, является монтированием tmpfs, созданным установщиком.

Изменяющиеся тома (в основном / var, но могут быть просто / var / log и / var / lib / mysql и т. Д.) Обычно являются тем, о чем вам нужно беспокоиться и планировать расширение. Поэтому, если возможно, используйте lvm и т. Д., Чтобы упростить изменение размера.

Да, я по-прежнему использую несколько разделов на виртуальных машинах и точки монтирования для мониторинга, безопасности и обслуживания.

Я не поклонник виртуальных машин с одиночной или ограниченной точкой монтирования (если только они не являются одноразовыми). Я обращаюсь с виртуальными машинами так же, как с физическими серверами. Выравнивание перегородок с некоторыми Стандарт иерархии файловой системы 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) для шаблона виртуальной машины с усиленной безопасностью. Разделение на разделы было абсолютным требованием для этого, потому что некоторые разделы требовали определенных настроек, которые нельзя было применить глобально. Еще одна точка данных.

Конечно, у нескольких точек монтирования есть свои преимущества, виртуализированный сервер или нет.

Но с виртуализацией вы, вероятно, также используете шаблоны виртуальных машин, верно? А ваша система мониторинга, например Nagios (с NConf?), Тоже поддерживает шаблоны? Если это так, то вам нужно пройти этот бой за мысленную точку маунта только один раз.

Вернемся к теме.

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

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

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