Лучшие практики для тонких серверов Linux (на VMware)

У меня есть около 20 машин Linux, каждый из которых содержит около 30-150 гигабайт данных клиентов. Вероятно, размер данных будет расти значительно быстрее на некоторых машинах, чем на других. Это виртуальные машины в кластере VMware vSphere. Образы дисков хранятся в системе SAN.

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

Теоретически, я бы просто создал большие диски для каждой машины и использовал бы тонкую настройку. Каждый диск будет расти по мере необходимости. Однако, похоже, что файловая система ext3 объемом 500 ГБ, содержащая только 50 ГБ данных и довольно небольшое количество операций записи, по-прежнему легко увеличивает образ диска, например. 250 ГБ со временем. А может я тут что-то не так делаю? (Я был удивлен тем, как мало я нашел по этому вопросу в Google. Кстати, на serverfault.com даже нет тега тонкой инициализации.)

В настоящее время я планирую создать большие диски с тонким предоставлением, но с небольшим объемом LVM на них. Например: том 100 ГБ на диске 500 ГБ. Таким образом я мог бы легко увеличивать объем LVM и размер файловой системы по мере необходимости, даже в режиме онлайн.

Теперь по актуальному вопросу:

Есть ли лучшие способы сделать это? (то есть для увеличения размера данных по мере необходимости без простоев.)

Возможные решения включают в себя:

• Использование дружественной файловой системы с тонким предоставлением, которая пытается снова и снова занимать одни и те же места, не увеличивая при этом размер изображения.

• Поиск простого метода восстановления свободного места на разделе (повторное уменьшение?)

• Что-то другое?

Дополнительный вопрос: если я согласен с моим текущим планом, вы бы порекомендовали создать разделы на дисках ( pvcreate /dev/sdX1vs pvcreate /dev/sdX)? Я думаю, что использование сырых дисков без разделов противоречит соглашениям, но было бы немного проще вырастить диски, если это когда-либо понадобится. Это все дело вкуса, верно?

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

Другой вариант - создание файлов VMDK достаточного размера, чтобы справиться с вашим текущим использованием и ожидаемыми скачками роста, и просто добавлять больше файлов VMDK по мере роста использования данных вашего приложения. Новые файлы VMDK могут быть добавлены на виртуальную машину в режиме реального времени, вам просто нужно выполнить повторное сканирование (echo "- - -"> / sys / class / scsi_host / host? / Scan). Вы можете разделить новый диск, добавить его в свой LVM и расширить файловую систему в режиме реального времени. Таким образом, вы всегда будете знать, сколько места выделено для каждой из виртуальных машин, и вы не сможете случайно запустить свою VMFS из пространства гостя.

Что касается того, следует ли разделять или нет, если диск будет использоваться только LVM, я всегда делю разделы. Разбиение диска предотвращает появление любых предупреждений о поддельных таблицах разделов при загрузке машины и дает понять, что диск выделен. Это немного вуду, но я также хочу, чтобы раздел начинался с 64, чтобы убедиться, что раздел и файловая система выровнены по блокам с основным хранилищем. Это трудно обнаружить и классифицировать, так как обычно вам не с чем сравнивать, но если файловая система ОС не выровнена должным образом с базовым хранилищем, вы можете получить дополнительные IOPS, необходимые для обслуживания запросов, которые пересекают границы блоков на основное хранилище.

Лучшее предложение, которое я могу придумать, - это создать установку LVM с физическими томами, группами томов и логическими томами, а затем подключить эти логические тома в качестве файловой системы вашей виртуальной машины через iSCSI .

Это позволит вам изменить размер логического тома, а затем все, что вам нужно будет сделать после этого, - это перезапустить ваш демон iscsi и программное обеспечение виртуальной машины и убедиться, что у него есть новые параметры размера, а затем изменить размер файловой системы гостя, чтобы соответствовать.

Разбиение будет работать как со стандартным жестким диском, так как это будет выглядеть как LV гостевой виртуальной машины.

Изменить: не берите в голову, у меня сложилось ложное впечатление, что вы работали с VMware под Linux, а не Linux под VMware.

Я не знаю, как это работает в VMware, но Redhat RHEV-M / RHEV-H возможен, и он поддерживает RHEL 4.8 - 5.X и одновременно выигрывает 2k3 R2 и выигрывает 2k8. Для получения дополнительной информации http://studyhat.blogspot.com/2010/05/rhev-for-servers-22-installation-and.html

Другое предложение: настройте файловый сервер, который будет хранить все ваши пользовательские данные.

Этот файловый сервер, конечно же, должен управляться с помощью LVM в целях онлайн-управления мощностью.

Если вы хотите, вы можете создать ha-setup (drbd + heartbeat) с одной копией вашего файлового сервера в SAN и второй копией снаружи или аналогично. (для параноиков)

Поскольку ваши клиенты основаны на Linux, вы можете использовать NFS, которая, как говорят, работает быстрее, чем Samba. FileServer обеспечит вам стратегию централизованного резервного копирования, а также мониторинг использования централизованного хранилища. И с точки зрения вашего тонкого вопроса обеспечения:

Создайте настройку LVM так, как вы предполагали (в вашем примере LV на 100 ГБ на PV на 500 ГБ, просто измените числа, соответствующие сумме хранилища, которая нужна вашим ВМ). Расширьте этот LV при необходимости, как вы планировали сделать в каждой виртуальной машине отдельно. Но просто сделайте это РАЗ на вашем файловом сервере. Каждый раз, когда виртуальная машина уменьшает использование памяти, это пространство будет доступно для всех ваших виртуальных машин ;-)

Используйте квоты на вашем файловом сервере, если это необходимо или желательно, чтобы предотвратить заполнение вашего файлового сервера одной виртуальной машиной.

Можете ли вы расширить том, не выключая виртуальную машину, используя ее? Я обычно делаю это, но я не знаю, каковы ваши настройки хранилища или как VMware может усложнить ситуацию. Если вы можете, то я бы сделал это

1) Не разбавляйте провизию. Сделайте каждый том размером, который вам нужен. 2) Не используйте разделы. Сделайте каждую файловую систему своим собственным томом. 3) Контролируйте рост файловой системы, чтобы вы могли активно изменять размеры томов.

Когда приходит время наращивать объем

1) В вашей сети SAN или в VMware сделайте все, что вам нужно для расширения тома. 2) В linux запустите echo 1 > /sys/block/EXAMPLE/device/rescan, где EXAMPLE - это имена устройств в / sys / block /. 3) В linux запустите resize2fs /dev/EXAMPLE, где EXAMPLE - имя устройства в / dev.

Этот подход хорошо работает для меня. Я рассмотрел ваш подход с тонкой инициализацией и LVM, и я думаю, что он также сработает.

Если вы решили пойти по маршруту LVM, я рекомендую не разбивать диски. Как вы сказали, отсутствие таблицы разделов облегчает рост виртуального диска. Без таблицы разделов вы можете просто запустить pvresize, и linux распознает, что физический том вырос. С таблицей разделов вы должны размонтировать все файловые системы, удалить таблицу разделов, заново создать таблицу разделов, а затем запустить pvresize. Это намного больше работы, и это требует простоя.