Я был на учебном мероприятии Dell EqualLogic, и докладчик высказал мысль, что, возможно, неплохо было бы создать единое хранилище данных для одной виртуальной машины, а не создавать большое хранилище данных и размещать на нем несколько виртуальных машин. Он аргументировал это тем, что соотношение виртуальных машин и хранилищ данных 1: 1 было лучшим вариантом для управления моментальными снимками, созданными Dell Host Integration Toolkit Auto Snapshot Manager. Он также отказался от оговорки, что это наиболее выгодно для дорогостоящих виртуальных машин, а не обязательно для каждой виртуальной машины, которая у вас есть.
Единственная причина, по которой я знаю, почему вы не захотите это делать, заключается в том, что каждое хранилище данных, которое vCenter должен сканировать, увеличивает общее время, необходимое для сканирования вашей SAN.
Что ж, в их случае это работает, потому что для обычного снимка виртуальной машины вам нужно освободить дополнительное пространство в хранилище данных, чтобы разместить разницу в данных между снимком и базой; с их инструментами, вместо этого у него есть ручка для хранения. Не уверен, что при этом создается моментальный снимок всего LUN в хранилище - если это так, то это объясняет преимущества разделения виртуальных машин на разные хранилища данных.
Также есть что сказать в пользу традиционного аргумента в пользу меньшего количества виртуальных машин на хранилище данных: блокировка SCSI. Если в одном хранилище слишком много виртуальных машин, их блокировки ввода-вывода будут накладываться друг на друга.
Обратной стороной, конечно же, является боль от управления всем этим. Добавить новый диск для ВМ? Чтобы освободить место, нужно место для хранения вещей vMotion. Развернуть диск? То же самое. Перенести на новое хранилище? Вы инициализируете много новых LUN. Безусловно, с точки зрения управления намного проще использовать хранилища данных большого объема.
В настоящее время люди используют виртуальные машины с плотностью 20-40 виртуальных машин на хранилище данных и не имеют проблем с вводом-выводом, чтобы решить одну из ваших задач. Я играю очень осторожно, чувствую, держу ~ 10-15, и у меня нет проблем с задержкой ввода-вывода / готовностью процессора. VMware движется к более крупным хранилищам данных, чтобы упростить управление, поэтому на самом деле это работает прямо противоположно тому, куда движется виртуальная среда. С vSphere5 у вас могут быть очень большие хранилища данных, поэтому моментальные снимки, заполняющие DS, не должны вас беспокоить, потому что 1) у вас есть больше свободного места и больше времени до возникновения условия нехватки места 2) При включенном SDRS вы можете либо автоматически перенести виртуальную машину на следующий лучший DS, основанный на IO / пространстве, прогнозируется на 24 часа.
Кроме того, моментальные снимки не должны оставаться открытыми в течение длительного времени и не являются допустимым вариантом резервного копирования / восстановления. Сколько раз у вас был моментальный снимок, заполнивший хранилище данных, и происходили «плохие вещи»? Вы можете избавиться от этого возможного взрыва, если не используете SDRS и не используете тонкий диск на диске, который вы планируете держать открытыми в течение длительного времени.
Если вы планируете запускать больше виртуальных машин, чем количество LUN на хост, указанное в Максимумы конфигурации doc для вашей версии VMware, вы бы не хотели иметь один LUN на каждую виртуальную машину. Для vSphere 4.1 это 256. Для ESX 3.5 это только 62 (как я узнал вчера, когда не смог увидеть несколько новых LUN, которые пытался подключить).