Гостевой пост компании ИТ-ГРАД. Переход в облако – актуальная задача, с которой сегодня сталкиваются многие компании. Виртуализировав парк локальных серверов и перенеся на облачную площадку приложения, организация избавляется от ряда проблем, с которыми приходилось сталкиваться ранее. Однако правильность конфигурации виртуальной среды, в частности виртуальных машин, остается вопросом номер один. На что обратить внимание при работе с ВМ, как создать максимально производительную инфраструктуру и не допустить ошибок – расскажем в этой статье.
Предварительный сайзинг – залог успеха
Перед тем как приступить к развертыванию ВМ в облаке провайдера, необходимо определить хотя бы ее примерный размер. При этом важно понимать, что не всегда больше ресурсов означает больше производительности. К тому же, если компания сталкивается с вопросом миграции уже существующих приложений, следует проанализировать данные мониторинга. Это позволит определить, какие ресурсы требует ВМ и в каком объеме.
Перенос приложений в облако провайдера
При переносе приложения из локальной инфраструктуры в облачную убедитесь в корректности работы ПО. То есть приложение, которое теперь находится внутри ВМ, необходимо протестировать. Если это тяжеловесный софт, еще на начальном этапе рекомендуют придерживаться следующей методики: запустить ВМ на одном ESXi-сервере, зарезервировав при этом ресурсы процессора и памяти. После чего начать тестирование на определение производительности и работоспособности, а полученные результаты занести в baseline. Дополнительно оценивается, как приложение работает на определенной архитектуре в условиях отсутствия рабочих нагрузок.
После того как статистика по ВМ и приложениям собрана, создаются условия, приближенные к рабочим: к хосту добавляют несколько дополнительных виртуальных машин, формируя добавочную нагрузку. При этом каждая ВМ использует выделенные под нее ресурсы процессора и памяти. Теперь, когда нагрузка возросла, снова запускают тест производительности и сравнивают полученные результаты с уже имеющимся baseline. На этом этапе важно понять, снижаются ли показатели производительности и насколько. Если в условиях увеличенной нагрузки приложения работают штатно, а производительность хоть и упала, но является достаточной для функционирования сервисов, можно продолжать увеличивать количество ВМ. Но делать это необходимо внимательно, постоянно отслеживая распределение ресурсов.
Особенности настройки виртуальных машин
При настройке виртуальных машин в среде VMware следует обращать внимание на такой параметр, как количество виртуальных процессоров. Желательно, чтобы этот показатель был не больше 8. Также важно понимать, что, если виртуальная машина использует больше ядер и больше памяти, чем приходится на один процессор, происходит обращение к памяти другого CPU, в результате чего снижается производительность, поскольку такой процесс выполняется медленно. Это связано с архитектурой неравномерного доступа к памяти, или NUMA.
NUMA-архитектура. Отметим, что большинство современных процессоров относятся к представителям NUMA-архитектуры, где у каждого CPU существует собственная локальная память. При этом CPU и RAM в совокупности объединяются в NUMA-узел. Таким образом, ОС виртуальной машины использует локальную память процессора и в случае ее нехватки обращается к удаленной памяти другого NUMA-узла. Важно понимать, что доступ к локальной RAM осуществляется быстрее, нежели к удаленной.
Сценарий, при котором виртуальная машина ассоциируется с одним физическим NUMA-узлом и использует локальную память, является идеальным. Но если возникает необходимость создать ВМ, физически превышающую размер NUMA-узла, стоит обратить внимание на соответствие физической NUMA и виртуальной. Также полезно использовать параметр cores per socket. Предоставляя виртуальной машине некоторое количество виртуальных процессоров, можно определить варианты их отображения внутри ВМ: как один CPU с большим количеством ядер, несколько одноядерных процессоров или прочие комбинации.
Если виртуальная машина целиком помещается на физический NUMA-узел, cores per socket не оказывает влияния на производительность. Если же приложение имеет ограничение по количеству процессоров, следует использовать эту метрику, чтобы ПО обращалось к доступным CPU.
Для наглядности рассмотрим пример, в котором компания переносит базу данных SQL Server 2012 версии Standard в облако по модели IaaS. Такая БД имеет ограничение на использование процессорных сокетов, по умолчанию равное 4. Следовательно, если ВМ необходимо 32 виртуальных процессора или 32 потока выполнения, можно использовать комбинацию из 4 сокетов с 8 ядрами.
Нюансы работы с Hot Add
Что делать, если ресурсов виртуальной машины в какой-то момент становится недостаточно, а останавливать работу приложений или ВМ не представляется возможным? На помощь приходит опция Hot Add, которая позволяет на лету добавлять ресурсы процессора и памяти. При этом важно понимать, что Hot Add для процессора, именуемый в настройках ВМ как Hot Plug, приводит к отключению vNUMA.
Настройка опции CPU Hot Add
Следовательно, машине с активированной опцией CPU Hot Add не будет видно разделения NUMA-узлов, а свободную память ОС будет расценивать как единое плоское пространство. Следует иметь в виду, что такой сценарий подходит далеко не для всех приложений. Поэтому Hot Add по процессору не всегда выгодно использовать.
Особенности Scale UP, Scale OUT-подхода
При переходе на виртуальную площадку большинство компаний идет по пути наименьшего сопротивления: с одного ресурсоемкого физического хоста, на котором, к примеру, находилось большое количество баз данных, переносят содержимое, размещая БД в пределах одной виртуальной машины. И в случае, если требуется нарастить ресурсы, администратор добавляет к существующей ВМ дополнительные вычислительные мощности: увеличивает объем памяти и количество процессоров. Такой механизм представляет собой вариант вертикального масштабирования, или Scale UP, о чем подробнее рассказывалось в статье Виртуальный ЦОД.
В случае со Scale OUT, или горизонтальным масштабированием, в инфраструктуру добавляются новые ресурсы, например увеличивают количество виртуальных машин в составе кластера. Следовательно, плюс озвученного подхода заключается в том, что при выходе какой-либо единицы из строя это не влияет на целостность инфраструктуры.
Управление памятью
При настройке памяти и распределении объема между виртуальными машинами не забывайте про физический хост. Помимо RAM, которую используют ВМ, физический узел также нуждается в ресурсах. Поэтому для сервера выделяют несколько дополнительных гигабайт, а при создании виртуальных машин этот объем не задействуют.
Пример того, как не стоит использовать RAM. На физическом узле с памятью в 120 Гб и двумя процессорами по 8 ядер решили развернуть четыре ВМ, каждая из которых использует 32 Гб RAM и 8 ядер CPU. В таком сценарии совокупный объем памяти, необходимый для виртуальных машин, превышает доступные размеры хоста. На практике рассмотренный подход лучше не использовать. И хотя на VMware ESXi такая конфигурация запустится, производительность при этом будет далека от оптимальной. Поэтому прежде чем создавать виртуальные машины, определитесь с объемом памяти, который необходимо выделить для хоста.
Заключение
Уделяя внимание особенностям настройки виртуальных машин в IaaS-облаке сервис-провайдера, помните: от выбранной стратегии зависит конечный результат. Поскольку требования к инфраструктуре разных компаний могут сильно отличаться, следует использовать максимально приближенный к требованиям организации вариант конфигурирования.
RSS
