У меня есть установка примерно из 20 машин Linux, каждая с примерно 30–150 гигабайтами данных клиентов. Вероятно, размер данных на одних машинах будет расти значительно быстрее, чем на других. Это виртуальные машины в кластере VMware vSphere. Образы дисков хранятся в системе SAN.
Я пытаюсь найти решение, которое бы экономно использовало дисковое пространство, но при этом позволяло бы легко наращивать отдельные машины.
Теоретически я бы просто создал большие диски для каждой машины и использовал тонкое выделение ресурсов. Каждый диск будет расти по мере необходимости. Однако кажется, что файловая система ext3 объемом 500 ГБ с только 50 ГБ данных и довольно небольшим количеством операций записи по-прежнему легко увеличивает образ диска до, например,. 250 ГБ со временем. А может я тут что-то не так делаю? (Я был удивлен, как мало я нашел на эту тему с помощью Google. Кстати, на serverfault.com даже нет тега тонкого обеспечения.)
В настоящее время я планирую создать большие диски с тонким предоставлением, но с небольшим объемом LVM на них. Например: том 100 ГБ на диске 500 ГБ. Таким образом, мне было легче увеличивать объем LVM и размер файловой системы по мере необходимости, даже в режиме онлайн.
А теперь собственно вопрос:
Есть ли лучшие способы сделать это? (то есть для увеличения размера данных по мере необходимости без простоев.)
Возможные решения включают:
Использование дружественной файловой системы с тонким предоставлением ресурсов, которая пытается занимать одни и те же места снова и снова, не увеличивая размер образа.
Поиск простого метода восстановления свободного места на разделе (повторное прореживание?)
Что-то другое?
Бонусный вопрос: если я придерживаюсь своего текущего плана, вы бы рекомендовали создавать разделы на дисках (pvcreate /dev/sdX1 против 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 и в то же время для win 2k3 R2 и win 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, где ПРИМЕР - это имена устройств в / sys / block /. 3) В Linux запустите resize2fs /dev/EXAMPLE, где ПРИМЕР - это имя устройства в / dev.
Мне этот подход подходит. Я рассмотрел ваш подход с тонким выделением ресурсов и LVM, и я думаю, что он тоже сработает.
Если вы все же решите пойти по пути LVM, я рекомендую не разбивать диски на разделы. Как вы сказали, отсутствие таблицы разделов упрощает рост виртуального диска. Без таблицы разделов вы можете просто запустить pvresize, и Linux распознает, что физический том вырос. С таблицей разделов вы должны размонтировать любые файловые системы, удалить таблицу разделов, заново создать таблицу разделов, а затем запустить pvresize. Это намного больше работы и требует простоя.