При развертывании виртуальной инфраструктуры серверов VMware Virtual Infrastructure, один из основных вопросов, который встает перед администраторами и CIO – это выбор правильной системы хранения и необходимого дискового пространства. От правильного сайзинга виртуальных машин по томам VMFS зависит в будущем то, насколько производительной и гибкой будет виртуальная инфраструктура.
Ниже приведем основные рекомендации по созданию хранилищ VMFS для виртуальных машин в части выбора их размера и правильной конфигурации.
Итак, для начала несколько рекомендаций:
Помните, что лучшей практикой является создание одного тома VMFS для одного LUN. Добавление дополнительных LUN в качестве экстентов (extents) не рекомендуется.
Для уменьшения риска необходимости расширения тома VMFS при создании снапшотов и прочих непредвиденных обстоятельств виртуальные машины размещаются таким образом, что 30% тома VMFS должны оставаться свободными.
Да улучшения производительности на одном VMFS-томе размещаются от 5 до 15 виртуальных машин на LUN. Не рекомендуется размещать более 30 виртуальных машин.
Создавайте все LUN унифицированного размера, например, по 1024 ГБ или 2048 ГБ. Не храните ISO-образы на дорогих FC LUN – используйте для этого NFS-шары.
Для маленьких LUN необходимо учитывать, что метаданные тома VMFS также занимают некоторое дисковое пространство. Объем метаданных, расположенных на томе VMFS вычисляется по следующей формуле:
500Мб + (x – 1)*(0.016Кб), где x-объем, выделенный тому VMFS в гигабайтах.
Например, для тома емкостью в 200 Гб объем метаданных будет равен:
500Mб + (200 - 1) (0.016Кб) = 503.184 Мб
Для доступа к одному тому VMFS используйте не более 10-15 хостов. При большем количестве хостов ESX / ESXi в вашей инфраструктуре – лучше создать два кластера DRS / HA во избежание проблем с производительностью. Если у вас виртуальные машины с большими требованиями к I/O (серверы БД), не используйте более 8 хостов ESX / ESXi на том VMFS.
Одним из важных параметров является размер очереди к диску (Disk Queue). Если вы мигрируете существующие ВМ в виртуальную среду – необходимо сначала изучить размеры средней очереди к диску систем и распределить их потом по LUN так, чтобы средние значения дисковой очереди на LUN были приблизительно одинаковы. Провести такое обследование (Virtualization Assessment) может авторизованный консультант (VMware Authorized Consultant, VAC), который использует ПО VMware Capacity Planner для централизованного сбора информации об Inventory и загрузках физических серверов.
Занимаемое пространство виртуальной машиной на томе VMFS может рассчитываться исходя из формулы disk*2+RAM. RAM понятно для чего – на случай приостановки (suspend) виртуальной машины. Дисковое пространство умножается в два раза исходя из учета возможного создания «снэпшота» виртуальной машины, файл отличий которого может увеличиться до размера базового диска. Почему так? Да потому, что NTFS работает таким образом: при записи файлов на диск сначала используются полностью свободные блоки, а только после того, как они закончились – блоки, которые помечены как свободные. То есть при записи файлов – vmdk разрастается, а при удалении – размер не уменьшается.
Таким образом, файл отличий vmdk, который из гостевой ОС видится как диск размером с базовый, быстро вырастет до его размера, и у нас получится два диска исходного размера. Это происходит еще и потому, что Windows постоянно производит запись и удаление чего-то на диск – например, работает с файлом подкачки.
Кроме того, очень важный момент – резервное копирование виртуальных машин средствами VMware Consolidated Backup (VCB), который пользуется технологией снапшотов. Иногда VCB забывает удалить снапшот виртуальной машины после того, как отработает, и этот снапшот продолжит расти.
Отдельная история, если вы планируете внедрить Virtual Desktop Infrastructure (VDI) на базе, например, продукта VMware View. При использовании технологии Linked Clones, которая предоставляется средствами VMware View Composer и позволяет создавать несколько ВМ с файлами отличий от базового образа виртуального диска, отдельное внимание нужно уделить быстродействию системы хранения. Поскольку пространство под виртуальные диски связанных клонов выделяется динамически (блоками по 16 МБ) – это вызывает дополнительные операции по резервированию LUN хостом ESX / ESXi. Таким образом, если таких клонов много – система хранения начнет испытывать проблемы с производительностью.
Теперь несколько примеров по выбору размера тома VMFS:
Пример 1. Минималистичный и экономичный.
Сайзим виртуальные машины по тому VMFS по номинальному размеру дисков vmdk. Оставляем 30% тома свободным на случай снапшотов и Suspend’ов виртуальных машин.
Пример 2. Сбалансированный.
Суммируем все виртуальные машины, учитывая диски таким образом: (disk +RAM)*1.1. Считаем, что 10% от номинального размера vmdk будут исполь зоваться снапшотами, за ростом которых будет следить системный администратор. Прибавляем еще 30-35% к получившемуся размеру, которые всегда остаются свободными на случай отпуска системного администратора или создания внеплановых ВМ. Этот вариант учитывает, что файл *.vmss, содержащий RAM виртуальной машины, которая поставлена «на паузу» (suspend), не удаляется при ее старте (удаляется только после полной остановки). Поэтому, возможно, у каждой машине в папке будет лежать файл *.vmss, равный размеру номинальной RAM виртуальной машины.
Пример 3. Максимальный запас.
Сайзим виртуальные машины по формуле disk*2+RAM. Этот вариант учитывает, что для всех машин будет по одному снапшоту, эти снапшоты разрастутся до размера базового диска, и все машины когда-либо будут приостановлены. Самым волнующимся можно добавить сюда еще 30%.
RSS
