Нередко при общении с заказчиками на тему виртуальной инфраструктуры (частного облака) я получаю от них требование по автоматическому масштабированию ресурсов для виртуальных машин. Система должна выделять виртуальной машине больше процессоров, оперативной памяти, полосы пропускания сетевого адаптера или дисковых операций, когда та становится сильно загружена, желательно - автоматически, а еще лучше - проактивно, до возникновения проблемы с производительностью. Кто-то оперирует терминами, вроде "автоматизация" и "эластичность" из маркетинговых презентаций вендоров, другие "на пальцах" рассказывают о сервере с аналитическим ПО, на котором раз в месяц запускается ресурсоемкая задача, в остальное же время сервер фактически простаивает и зря греет воздух.
Такая потребность возникает по разным причинам, например, из-за желания повысить отдачу от внедрения виртуализации, или из-за желания администраторов снять с себя ответственность за сайзинг, мол, пусть система сама выделит столько ресурсов, сколько нужно виртуальной машине. Однако существует несколько причин, по которым реализация подобного функционала сильно осложнена и, по факту, не имеет практического применения в виртуальной инфраструктуре.
1. Ресурсы виртуальной инфраструктуры, развернутой внутри компании, в отличии от публичного облака провайдера, конечны. В кластере есть определенное количество серверов, с определенным количеством процессоров и оперативной памяти. Администраторам сразу доступны все вычислительные ресурсы, за исключением некоего резерва, который оставляют для обеспечения высокой доступности на случай выхода из строя одного или нескольких серверов. Отсюда возникает вопрос - если появится потребность выделить дополнительные вычислительные ресурсы одной или нескольким ВМ, то откуда их брать? Будут ли это ресурсы из запаса, оставленного под возможный рост виртуальной инфраструктуры, ресурсы, отобранные у других ВМ, или резерв, сделанный для отказоустойчивости? Не будет ли более правильным с точки зрения планирования учесть пиковые нагрузки в работе приложений, заложить и заранее выделить ресурсы нужной ВМ?
2. Следует разделять понятие выделенных ресурсов (allocated) и реально используемых/потребляемых (consumed) ресурсов. Если одной машине выделено 8 процессорных ядер, то это не означает, что она их утилизирует на 100% все время, пока запущена и работает. Гипервизоры давно научились эффективно распределять процессорные ресурсы между несколькими ВМ. На одном сервере, может быть создано множество ВМ, и все ВМ могут работать одновременно, не конкурируя друг с другом за ресурсы, пока нагрузка на них невелика. У всех современных гипервизоров есть механизмы возврата выделенной, но неиспользуемой памяти из ВМ, например Memory Ballooning и Host Swap у VMware vSphere, Dynamic Memory у Microsoft Hyper-V и т.д. В случае нехватки вычислительных ресурсов, т.н. перезакладки (overcommitment), гипервизор начнет использовать различные механизмы планирования, основанные на пропорциональном делении ресурсов, резервировании и лимитировании потребления. Изменяя эти метрики, можно обеспечить гарантированный уровень производительности для определенных ВМ в ущерб остальным, менее критичным.
3. Производительность ВМ ограничена производительностью физического сервера. Больше всего ресурсов ВМ сможет получить, если она будет единственной ВМ работающей на сервере, и количество процессоров и объем памяти будут равны или чуть меньше, чем у физического сервера (этакий Monster VM), т.е. при коэффициенте консолидации 1:1. Поэтому в ряде случаев проблему производительности можно решить, разнеся ресурсоемкие ВМ по разным физическим серверам (чем, например, занимается VMware DRS вместе с Anti-Affinity Rules).
4. Отсутствие у большинства гипервизоров механизмов выделения процессоров и памяти ВМ "на лету". Хотя возможность горячего добавления (Hot Plug/Hot Add) процессоров и памяти присутствует в гипервизоре VMware vSphere, данный механизм требует предварительной настройки и резервирует под свою работу часть вычислительных ресурсов сервера. Кроме того, на текущий момент нет возможности отбирать у ВМ назад не используемые процессоры и оперативную память, не выключая ее. По этой причине изменение аппаратной конфигурации виртуальных машин - не очень хороший вариант для сервисов, требующих непрерывной доступности.
5. Отсутствие готовых решений, позволяющих на основании данных системы мониторинга выполнять изменение конфигурации ВМ. Такую возможность, конечно, можно реализовать с помощью исполняемых сценарием и средств оркестрации/автоматизации, но это потребует серьезной работы "напильником", а также учета большого количества всевозможных условий. Например, должен учитываться не только сам факт роста загрузки ВМ, но и его длительность, время возникновения, периодичность, причина повышения загрузки (требуется ли выделать больше ресурсов под задачи антивирусного сканирования или резервного копирования, или только под задачи приложений) и т.д., чтобы не запускать процедуру изменения конфигурации ВМ по малейшему поводу.
Суммируя все вышесказанное, наибольшей производительности работы приложений можно добиться при правильном планировании ресурсов и выборе подходящей архитектуры для виртуальной инфраструктуры. Для этого следует, в первую очередь, придерживаться рекомендаций производителей программного и аппаратного обеспечения, проводить нагрузочное тестирование, а также осуществлять мониторинг с помощью систем, позволяющие проводить анализ производительности и выдавать рекомендации по оптимальному сайзингу ресурсов для ВМ, например, VMware vCenter Operations Manager или Veeam ONE.
0 коммент.:
Отправить комментарий