VMFS-5 LUN Sizing

[#1]

Источник: VMFS-5 LUN Sizing

У меня был вопрос по поводу моей старой статьи на тему сайзинга хранилища: "VMFS/LUN size?", которую я написал еще в конце июня 2009 года. Вопрос заключался в следующем: "как, исходя из сегодняшних реалий, применять формулу и производить расчеты, если учесть тот факт, что новая ФС VMFS-5 не за горами". Это очень правильный и нужный вопрос, поэтому я решил взять свою предыдущую статью и переписать её. Ниже представлен список параметров со значениями, с помощью которых и будет выстроена конечная формула и произведен расчет.

Параметры:

• MinSize = 1.2GB
• MaxVMs = 40
• SlackSpace = 20%
• AvgSizeVMDK = 30GB
• AvgDisksVMs = 2
• AvgMemSize = 3GB

Перед тем, как привести конечную формулу, я хочу вам немного рассказать о том, как вычислить значение параметра "MaxVMs". Первым делом, вам нужно выяснить, какое количество операций ввода-вывода в секунду (IOps) способен обработать ваш LUN (дополнительную информацию вы можете получить, прочитав эту статью: О производительности: IOPS vs. MB/s). Помимо количества IOps вы также должны принять во внимание и неожиданный всплеск в потребностях к ресурсам со стороны виртуальных машин, расположенных на данном LUN (например, если все ВМ на данном LUN'е одновременно начнут загружаться). Ну и, конечно, не стоит забывать и про RTO (Recovery Time Objective на Википедии), принятое для этой среды.

MaxVMs = ((IOpsPerLUN – 20%) / AVGIOpsPerVM) 
MaxVMs ≤ (MaxVMsWithinRTO)

Как видно выше, я вычитаю 20%, тем самым резервируя ресурсы на случай их резкой потребности со стороны виртуальных машин. Резервирование 20% не является самой лучшей практикой. Вам следует использовать другое, более оптимальное число, в зависимости от размера вашего LUN и общего количество IOps, которое LUN способен обработать. Например, если вы используете 8 SATA дисков, то 20% - это всего лишь 80 IOps (многое, конечно, зависит от уровня RAID). В случае если вы используете 8 SAS дисков, то 20% - это, примерно, 280 IOps и это огромная разница по сравнению с SATA дисками. В любом случае, вам решать, какое количество ресурсов оставить под резерв. Лично я использовал 20% для резервирования дискового пространства (для снапшотов и swap-файлов) и производительности с целью сильно не усложнять конечные расчеты. Итак, с 20% разобрались, осталось рассмотреть последний, достаточно важный, параметр: MaxVMsWithinRTO. Смысл данного параметра сводится к следующему: убедитесь в том, что вы можете восстановить работоспособность виртуальных машин, расположенных на данном хранилище, в пределах ранее определенного времени восстановления (RTO). Вы же не хотите оказаться в ситуации, когда RTO составляет 4 часа, а по факту общее время восстановления составляет 24 часа.

Наконец, мы и дошли до формулы. Прошу заметить, что я не принимал во внимание традиционные ограничения, такие как "SCSI Reservations Conflicts", поскольку с появлением файловой системы VMFS-5 и VAAI SCSI Locking Offload эти ограничения сняты. Если ваш массив не поддерживает типовую операцию Atomic Test and Set (ATS), то SCSI-блокировку вам следует иметь в виду. Хотя механизм SCSI-блокировок был значительно усовершенствован в последние годы, все же, если у вас много Power-On событий, vMotion событий и так далее, то SCSI-блокировки все еще могут вас ограничить.

(((MaxVMs * AvgDisksVMs) * AvgSizeVMDK) + ( MaxVMs * AvgMemSize)) + 
+ SlackSpace ≥ MinSize

Небольшое отступление: "параметр MinSize определяет минимальный размер хранилища, который необходим для размещения метаданных тома VMFS". Ну, а теперь, используя ранее определенные числа, производим вычисления:

(((40 * 2) * 30GB) + (40 * 3GB)) + 20% = (2400GB + 120GB) * 1.2 = 3024 GB

Надеюсь, что данный материал поможет вам при сайзинге хранилища.