Откуда берутся ресурсы для работы виртуальной машины
Процесс потребления ресурсов ВМ в виртуальной среде
Процесс потребления ресурсов ВМ в виртуальной среде
Находясь в защищенной инфраструктуре провайдера, клиенты получают гарантии высокой доступности сервиса, безопасности и возможности работать из любой точки мира. Однако виртуальные машины, развернутые в рамках IaaS-инфраструктуры, зачастую выполняют гораздо более серьезные функции. Почему стоит отдавать предпочтение виртуальным машинам, а не физическим серверам? Требуется ли стопроцентное резервирование ресурсов в публичном облаке? На эти и другие вопросы ответим в статье.
Преимущества ВМ над физическими серверами
В чем разница между виртуальными машинами и физическими серверами? Почему сегодня так много говорят о плюсах виртуализации, переводя физическую реализацию к разряду экономически неэффективных методов ведения бизнеса? Факты и наглядные примеры помогут в этом разобраться.
Давайте вспомним ситуацию, когда ресурсов физического сервера становилось недостаточно. Первым делом приходилось докупать дополнительные линейки памяти, расширять дисковое пространство, в худшем случае – менять процессор или выполнять полный апгрейд оборудования. При добавлении ресурсов чаще всего требуется выключать сервер. От этого, безусловно, страдают пользователи, ведь подобные действия провоцируют остановку работы приложений. К тому же на разборку и сборку сервера уходит немало времени, не говоря о том, что поиск и покупка совместимых комплектующих – тоже трудозатратная процедура.
«А как же «горячая» замена составляющих?» – спросите вы. Ведь такой формат работы позволяет без прерывания работы оборудования добавлять новые ресурсы. Несмотря на то что существует и такой вариант решения проблемы, он все же не дает той гибкости в конфигурации, которую можно получить при использовании виртуальных машин. В случае с ВМ изменение конфигурации происходит за несколько минут, а в зависимости от ОС иногда даже без остановки работы машины. В любом случае увеличение процессорных мощностей, оперативной памяти или дисков выполняется гораздо быстрее, нежели в случае с физическим оборудованием, пусть даже поддерживающим режим работы Hot Swap.
Важно понимать: виртуальные ресурсы не ломаются! Это означает, что даже в случае выхода из строя физической части оборудования на стороне провайдера виртуальная машина будет автоматически запущена на другом, менее загруженном оборудовании.
Многие клиенты, перенося физическую инфраструктуру на облачную площадку, тянут за собой совершенно ненужные для виртуального окружения привычки. Это, к примеру, касается вопроса резервирования ресурсов для виртуальных машин. Стоит ли уделять внимание этому вопросу? Давайте посмотрим, чем процедуры в облаке отличаются от аналогичных процедур для физических хостов.Почему не стоит резервировать ресурсы ВМ на 100%
# Резервирование ресурсов для физического сервера
Итак, резервирование ресурсов для физического сервера основывается на предоставлении максимально возможного объема мощностей, например дисковой памяти, исходя из расчетов жизненного цикла сервера и возможной нагрузки в ближайшие пару лет. Поскольку нагрузка на сервер со временем увеличивается, заказчик, учитывая эту особенность, помимо дисковой подсистемы, наращивает процессорные ресурсы и количество оперативной памяти, выделяя гораздо больше, чем это требуется в настоящее время.
# Резервирование ресурсов для виртуальной инфраструктуры
Как обстоит дело с виртуальной инфраструктурой? Здесь процесс выглядит несколько иначе: для виртуальных машин выделяют ровно столько ресурсов, сколько требуется на текущий момент. А если мощностей становится мало, их можно добавить позднее по необходимости и без перерыва в работе систем и сервисов. Именно по этой причине не стоит делать «стратегических запасов», ведь чрезмерное выделение CPU, RAM, HDD приводит к неэкономному использованию инфраструктуры и понижению уровня консолидации.
Помните! Предоставление необходимых мощностей, которые требуются здесь и сейчас, делает виртуальные машины гибкими в конфигурации. Это гарантирует высокий уровень загрузки, который составляет порядка 70 %. В сценарии с физическими серверами дополнительные ресурсы закладываются на случай непредвиденного увеличения спроса или отказа оборудования, что приводит к излишней трате денежных средств. При этом средний уровень загрузки типового физического сервера далек от идеала и составляет около 7–15 %. Таким образом, купив сервер за 100 % стоимости, чаще всего используют лишь 10 %.
Заключение
В завершение приведем еще несколько примеров, отлично иллюстрирующих, почему не стоит гнаться за 100%-ным резервированием ресурсов в виртуальной IaaS-инфраструктуре.
И, наконец, если серверная ВМ претерпевает пиковую загрузку раз в год, скажем, в новогодние праздники, когда наблюдается повышенный спрос на покупку подарков, а в остальное время машина работает на 20 % своих ресурсов, лучше урезать ресурсы в 4 раза, а в случае всплеска обращений добавить необходимые мощности.
Как виртуальные машины используют ресурсы
Идея облачных технологий развилась всего из одной оставленной дома флешки. Использование виртуальных машин для конечных пользователей сейчас уже ни выглядит магией. Теперь всегда можно получить свой файл из облака, где бы вы не находились. Вся библиотека документов может быть с собой в любом месте и ничего не потеряется по дороге. Но несправедливо было бы говорить, что виртуальные машины ограничиваются этим функционалом. ВМ, развернутые как IaaS-инфраструктура способны на большее. Как правило, их задачи более объемны и сложны, так что имеет смысл сравнить работу ВМ с физическими серверами.
Виртуальные машины VS физические серверы
Сегодня большое внимание уделяют вопросам виртуализации. Много говорят о том, что на покупку и обслуживание физических серверов тратится огромное количество ресурсов компании. В таком случае лучше не доверять абстрактным мнениям, а разобрать факты и ситуации, с которыми может столкнуться бизнес.
Главный вывод из этого другой. В случае поломки виртуальные машины перезапускаются на незанятом оборудовании, поэтому выход из строя какого-либо железа на стороне провайдера не имеет значения для клиента.
Есть ряд вещей, которые продолжают тяготить клиентов в силу определенных привычек, даже когда они уходят в Облако. Дело в том, что сама технология требует иного подхода и то, что работало на физической инфраструктуре, теперь только навредит. Например, для ВМ не следует резервировать все ресурсы.
Почему для физических серверов это было актуально? Брался прогноз на 1,5-2 года и в зависимости от этого подбиралась железо под необходимый набор мощностей. Нагрузка за отведенный срок постепенно увеличивается, а значит, заказчик должен развивать и мощности с неким опережением, чтобы ресурсов хватало всегда. Дополнительные мощности нужны физическим серверам на случай выхода из строя или пиковых ситуаций.
Получается, что клиент может заплатить полную стоимость физического сервера, но использовать при этом 10-30% от его максимальной мощности. IaaS позволяет оплачивать только те ресурсы, которые находятся в работе на данный момент. Это дает определенную гибкость в обе стороны, как для увеличения мощностей, например, в праздничный период, так и на снижение, если компания знает по опыту, что сейчас им столько не потребуется.
Некоторые особенности использования виртуальных машин для новичков
Виртуальные машины, такие как Virtualbox, используются для эмуляции виртуальное оборудование и запуска нескольких операционных систем на компьютере. Чем лучше будет у вас CPU и чем больше будет оперативной памяти, тем быстрее будут выполнятся виртуальные машины на вашем компьютере.
Я предлагаю несколько советов которые помогут вам сэкономить время при начальной настройке виртуальных машин. Это будет полезно для работы с виртуальными машинами VirtualBox, VMware, Parallels, или любой другой. 
Обязательно установите дополнения гостевой ОС VirtualBox или VMware Tools
Установка пакета проста — в VirtualBox, после загрузки гостевой операционной системы, нажмите кнопку меню Устройства и выберите «Install Guest Additions». Если вы используете VMware, выберите «Install VMware Tools» в меню Virtual Machine. Следуйте инструкциям на экране для завершения установки — если вы используете Windows в качестве гостевой операционной системы, то это будет аналогично установке любого другого приложения.
Убедитесь, что вы имеете самую последнюю версию Guest Additions — если вы видите уведомление, что доступно обновление для Guest Additions или VMware Tools, вы должны установить его.
Создание фиксированного размера дисков при первоначальной настройке
При создании виртуальной машины, вы можете создать два различных типа виртуальных дисков. По умолчанию программа обычно предлагает использовать динамически выделяемые диски, которые растут, вместе с занимаемым местом гостевой ОС.
Например, если вы создаете новую виртуальную машину с динамически выделяемым диском с максимальным размером 30 Гб, это не займет до 30 Гб места на жестком диске сразу.После установки операционной системы и программ, диск может только занять до 10 Гб. По мере добавления файлов на виртуальном диске, он будет расширяться до максимального размера в 30 Гб.
Это может быть удобно — каждая виртуальная машина не будет занимать неоправданно много места на вашем жестком диске. Тем не менее, это медленнее, чем создание фиксированного размера диска (диск с заранее выделенным местом). При создании фиксированного размера диска, все 30 Гб, будет занято немедленно на вашем компьютере.
Здесь есть компромисс — фиксированный размер диска занимает больше места на жестком диске, но работает с виртуальным жестким диском быстрее. Вы также избавитесь от фрагментации файла — место будет занято большим блоком вместо того, чтобы добавлять по всему диску более мелкие куски.
Исключите каталог виртуальных машин в вашем антивирусе
Ваш антивирус может сканировать файлы виртуальной машины, когда к ним происходит обращение, снижая производительность. Антивирус не сможет определить вирус внутри виртуальной машины, работающий на вашей гостевой операционной системе, так что эта проверка только вредит.
Чтобы ускорить процесс, вы можете добавить свой виртуальный каталог машины в список исключений антивирусного автора. Как только он находится в списке, ваш антивирус будет игнорировать все файлы в этом каталоге.
Выделите больше памяти
Виртуальные машины любят много виртуальной памяти. Microsoft рекомендует 2 Гб RAM для 64-битной Windows 7, и эта рекомендация относится и к Windows 7 x32, когда он работает в виртуальной машине. Если вы работаете большими приложениями в виртуальной машине, вы можете выделить более 2 Гб оперативной памяти.
Вы можете выделить больше оперативной памяти в диалоге настроек вашей виртуальной машины (виртуальная машина должна быть выключена, чтобы сделать это). Если на Вашем компьютере не хватает памяти, чтобы комфортно работать вместе с виртуальной машиной, вы можете заметить очень большое снижение производительности компьютера при использовании файла подкачки на жестком диске.
Выделите больше процессоров
Если у Вас компьютер с несколькими процессорами или ядрами, вы можете выделить дополнительные процессоры для вашей виртуальной машины из окна настроек VM. VM с двухъядерным (или четырехъядерным) процессором будет более шустро реагировать.
Если вы собираетесь инсталлировать ОС семейства MS-Windows и в будущем чтобы можно было использовать больше ядер при инсталляции указывайте 2 ядра для того чтобы поставился корректный HAL, после инсталляции вы можете выключить машину и поставить 1 ядро по умолчанию для повседневного использования. Но для будущего вы всегда сможете добавить ядра без деинсталляции ОС. Linux VM может динамически определять любое количество ядер при загрузке ОС.
Настройте параметры видео
Тонкая настройка параметров видео и выделение большего объема видеопамяти поможет также улучшить скорость вашей виртуальной машины. Например, включение функции 2D ускорение в VirtualBox улучшает воспроизведение видео в виртуальных машинах, включение 3D-ускорения позволит вам использовать некоторые 3D-приложения.
По большому счету нужно минимизировать использование 3D например ОС Windows 7 — отключив Aero.
Убедитесь, что функции Intel VT-x или AMD-V включены
Intel VT-x и AMD-V являются специальными расширениями процессора, которые улучшают скорость виртуализации. Новые Intel и AMD процессоры обычно включают в себя эти функции. Тем не менее, некоторые компьютеры не включают автоматически VT-x или AMD-V — вам придется включить этот параметр в BIOS вашего компьютера.
Чтобы определить, поддерживает ли Ваш Intel процессор расширение Intel VT, воспользуйтесь утилитами показывающими системную информацию. Если ваш процессор поддерживает эту функцию, но опция недоступна в вашей виртуальной машине, вы должны в BIOS вашего компьютера включить эту функцию. Этот параметр обычно включен по умолчанию в материнских платах с процессорами AMD.
Поместите файлы виртуальной машины на другой диск
Производительность диска может ограничить скорость вашей виртуальной машины. Размещение файлов виртуальной машины на отдельном физическом диске или не на системном диске — может улучшить производительность. Ваша виртуальная машина и система не будут конкурентно читать и писать с одного диска.
Однако, вы не должны запускать виртуальную машину с внешнего диска (USB) — это будет гораздо медленнее.
Как распределяются ресурсы при виртуализации?
Попытаюсь максимально четко сформулировать вопрос. Мне стало интересно, как распределяются ресурсы компьютера при виртализации N’го кол-во машин. Если быть более точным, меня интересует именно Unified Networking Lab. Я ставлю виртуальную машину с ОС *nix и выделяю ей некое кол-во ресурсов. (Пусть будет 6 ГБ озу и 1 процессор с 4 ядрами) Все запустил, работает. Но помимо самой ОС, я в неё закидываю образы Dynamips, IOL, QEMU, которым так же надо выделять определенное кол-во ОЗУ. В чем соль вопроса: Если я запущу около 20-30 этих разных образов внутри виртуальной машины и потребление одного образа в среднем будет около 512 ОЗУ (512*25/1024=12.5) то сможет ли все это работать? На компьютере 8 ГБ озу. Виртуальной машине повторюсь, выделили 6 Гб ОЗУ. И как именно работаеет распределение ресурсов на виртуальную машину? Просто совершенно недавно, где то вычитал, что виртуальной машине можно выделить в 2 раза больше ОЗУ чем есть на ПК, т.к. она использует озу лишь на половину и так же на половину использует Жесткий Диск.
Простите если плохо или слишком сложно сформулировал. Если можно то какие нибудь ссылки на статьи или небольшие свежие книги по виртуализации.
Спасибо за внимание. Лев.
Это очень тонкий вопрос.
Также нужно понимать, что у гипервизора есть средства аппетиты машины умерить. Например, такие механизмы, как balooning. Т. е. если память, которую гостевая система отвела под какие-то свои нужды, резко потребуется другой виртуальной машине, то гипервизор через специальный драйвер надует baloon, и отберёт часть памяти у одной гостевой машины, чтобы отдать его другим.
Почему виртуалки “на вырост” начинают тормозить, и что с этим делать новичку
Клиенты все чаще мигрируют в облака в погоне за гибкостью: здесь намного проще добавить диск, память и процессоры, если чего-то не хватает. Но иногда новички обнаруживают, что добавление ресурсов перестает помогать. Скорость работы не растет, а с бэкапом и восстановлением начинаются проблемы.
Сегодня вместе с @kvolodin мы расскажем, почему бесконечное увеличение ресурсов ВМ может вредить пользователям и как спланировать рост производительности очевидными, но действенными способами. Статья полезна тем, кто переехал или планирует переезд в облако и еще знакомится с нюансами облачной среды.
Очевидные причины: ограничения железа и бэкапов
Сейчас в нашем облаке добавление ресурсов сверх лимита можно ограничить на уровне софта. Если кто-то попробует выйти за пределы, сразу получит сообщение в интерфейсе Cloud Director:
Но так было не всегда. В старых версиях vCloud Director мы не могли жестко ограничить некоторые параметры и прописывали лимиты только в договоре. К сожалению, иногда информация из контракта даже не попадала к инженерам клиента, и они могли почувствовать последствия на своей шкуре.
Много лет назад мы предоставили клиенту квоту в 20 ТБ и предупредили про ограничение на диск в 16 ТБ. Резервное копирование данных делали с помощью Veeam Backup&Replication. Когда клиент вышел за пределы диска в 16 ТБ, все задачи на создание бэкапов просто зависли. Veeam не успевал забэкапить большую ВМ и на всякий случай оставлял неполный снэпшот, а затем создавал новый. Дерево снэпшотов стало расти слишком быстро, общая производительность диска тоже упала. Пришлось полночи заново создавать дерево снэпшотов, а затем переносить данные на диски поменьше.
В те времена от подобных инцидентов нас защищал мониторинг. Мы сразу видели непорядок на дашбордах и обращали внимание клиента на проблему. Трудность была в том, что в случае IaaS сами виртуалки оставались ответственностью клиента. Инженеру клиента нужно было самому пересоздавать ВМ, иногда с большим трудом.
Клиенту выделили квоту в 40 ТБ на СХД, а для диска ВМ прописали ограничение в 20 ТБ. Администратор клиента создал ВМ в 30 ТБ и разметил все дисковое пространство одним диском. Техподдержка обнаружила проблему, сообщила клиенту, что нужно пересоздать ВМ с дисками меньшего размера, но администраторы долго не выходили на связь.
В это время данные начали записываться на созданный диск большими темпами. Пока на СХД было свободное место, мы увеличивали размер дата-стора и ждали ответа от клиента. Но если бы расширять дата-стор дальше было невозможно, клиенту пришлось бы рисковать данными. Нужно было бы создать новый диск и перегнать данные на него. Миграция такой большой ВМ могла потребовать несколько дней, и оставалась вероятность неудачного переезда.
Базовые лимиты защищают клиента от многих проблем и позволяют обслуживать железо в штатном режиме. Мы не допускаем разрастания ВМ до пределов физического диска и избегаем трудностей с миграцией. Добавить ресурсы по запросу клиента по-прежнему можно, но только если в этом правда есть необходимость.
Но даже если физический лимит не превышен, могут возникнуть другие трудности.
Неочевидная работа гипервизора
Если виртуальная машина в облаке начинает тормозить и захлебываться, клиент чаще всего ищет причину в нехватке ресурсов. Увеличение виртуальной машины кажется логичным и быстрым ходом. Но в некоторых случаях расширение только ухудшает скорость работы.
У клиента регулярно возникали пиковые периоды активности. Раз в месяц нагрузка на системы увеличивалась и требовала больше процессоров. Клиент решил не отключать эти процессоры после пика, а оставить их про запас. Но в период низкой активности производительность упала и не давала выполнять рутинные задачи. Дело в том, что гипервизор “отодвинул” недозагруженные системы на второй план. Так работает планировщик: если ВМ не требует ресурсов, то в очереди она спускается ниже.
Клиенту облака по умолчанию доступна только информация из диспетчера задач и монитора ресурсов. Бывает и так, что на ОС клиент видит загрузку части ядер на 100%. В это же время мы на гипервизоре видим, что часть ядер не используется, потому что приложение не рассчитано на многопоточность. В таких ситуациях парадоксальным образом помогает именно уменьшение ресурсов до необходимого и достаточного уровня. После этого гипервизор лучше распределяет небольшие ВМ в очередях.
Некорректный сайзинг приложения в облаке
К сожалению, переезд приложения с физических хостов не всегда возможен “в лоб”. Даже если все работало на физических 24 процессорах, столько же процессоров в облаке не всегда решают проблему.
Один из клиентов перед переездом на новое железо решил временно разместить в облаке виртуальную АТС. Мы заглянули в документацию вендора и обнаружили явную несовместимость с vCloud Director. Производители АТС изначально не гарантировали стабильную работу своего приложения в облачной среде. Тем не менее, нашим инженерам удалось настроить работу софта с помощью нескольких хитростей. Клиент спокойно работал в облаке, пока не дождался поставки собственного железа. Но если бы он захотел внести изменения в настройки, возникли бы трудности.
У крупных производителей софта несовместимость с облаком сразу прописана в документах. Менее очевидно дело обстоит с самописным ПО.
Клиент заказал виртуальную машину для переезда собственного приложения в облако. Через пару месяцев работы софт начал сильно тормозить. При аудите выяснилось, что объемные файлы по умолчанию сохраняются в одну директорию и нагружают файловую систему. За несколько месяцев там накопились уже миллионы файлов, и для решения проблемы понадобилась новая архитектура с несколькими хранилищами.
Даже если случай не такой экстремальный, при переезде с физических хостов не помешает пересмотреть подход к сайзингу приложения, изменить модель потребления ресурсов.
Например, бывают ситуации, когда пользователь привык к быстрой работе на ноутбуке с высокочастотными процессорами, а в облаке сталкивается с низкой скоростью. Характеристики Enterprise-железа в дата-центре рассчитаны на долгосрочную работу в режиме 24/7 и не допускают пограничных состояний. Если такой пользователь разгонял процессоры на своем ноутбуке до опасного максимума, то в облаке он не сможет добиться тех же скоростей от похожего процессора.
Случается и так, что приложение рассчитано на высоконагруженную базу, но размещается в облаке на SATA-дисках. Клиент видит загрузку процессоров и увеличивает ресурс CPU, не подозревая проблемы именно с дисками.
В то же время облако дает лучшие результаты при оптимизации приложения под несколько хранилищ. На физических хостах у разработчика меньше возможностей для маневра: как правило, все хранится на локальных одинаковых дисках. В облаке появляется вариативность: можно выбрать разные диски для разных типов хранения и даже немного сэкономить.
Один из клиентов хранил в своей базе данные трекинговой системы за три года ― такой срок хранения был предусмотрен нормативом. После переезда в облако удалось разделить хранилище на “холодное” и “горячее”. Редко используемые данные перемещались на медленные и дешевые “холодные” диски, а востребованная информация оставалась на быстрых дисках в “горячем” хранилище.
Подозрительная активность на ВМ
Когда снижение производительности подкрадывается постепенно, то переход на более производительные диски может и правда решить проблему. Если же загрузка ресурсов выросла резко, скорее всего, дело в шифровальщике или залетном майнере криптовалюты.
Неправильная настройка облачного межсетевого экрана у новых клиентов встречается не так уж редко. Иногда администраторы разрешают на граничном маршрутизаторе всем и все, а потом забывают об этом. Если мошенник обнаруживает уязвимость и завладевает машиной, то он забирает все ресурсы сразу, и докидывание процессоров не решает проблему.
Откуда берутся лимиты на ресурсы в облаке
Ограничения на диск
Есть технические ограничения СХД. Яркий пример: блочный том многих моделей NetApp не может быть более 16 ТБ.
Мы как провайдер провели тесты производительности СХД и рассчитали оптимальный размер дата-стора.
Инфраструктура резервного копирования лучше справляется с бэкапом нескольких мелких объектов, чем одного большого.
Ограничения на CPU и память
Ограничен размер физического хоста, на котором располагаются ВМ клиентов.
При размере хоста 144 vCPU и 2 TБ памяти ВМ большего размера не получится создать при всем желании. (Cпасибо, кэп!)
Для оптимального обращения к памяти мы учитываем особенности работы мультипроцессорных систем. Мы уже рассказывали об этом в статье про первую виртуальную машину.
У клиента может быть сервис, который сам эффективно распределяет ресурсы памяти, ― тогда проблем не возникнет. В остальных же случаях нужно настраивать лимиты.
С помощью некоторых лимитов мы можем управлять виртуальной платформой и предоставлять предсказуемый сервис с соблюдением SLA.
Ограничения на IOPS
В облаке также встречаются клиенты, у которых намного выше среднего параметры IOPS: количество операций ввода/вывода. Чаще всего это происходит в трех случаях:
Клиент решил протестировать выделенные мощности на больших нагрузках.
У клиента наблюдается аномальная нагрузка, например, из-за некорректной работы самописного софта или вирусов.
Клиент установил высокопроизводительное приложение.
На любой из этих случаев мы задаем ограничения потребляемых дисковых мощностей, опираясь на результаты нагрузочного тестирования СХД. Сейчас можем ограничить каждый диск фиксированным значением IOPS или исходить из IOPS на ГБ.
Как новому клиенту вписаться в лимиты и обеспечить производительность
При планировании переезда в облако ознакомиться с документацией на ПО. Некоторые производители софта сразу указывают, что их приложение не работает в облачной среде.
До переезда протестировать работу приложения в облачной инфраструктуре. Большинство провайдеров позволяют клиентам брать пробный период и запускать синтетические тесты.
Не стесняться обращаться в техподдержку. Инженеры могут оценить производительность со стороны гипервизора и дать рекомендации.
Расти маленькими шагами: увеличить диски намного проще, чем резко их уменьшить. Увеличивать процессоры тоже лучше постепенно, начинать с одного ядра.
Расти не вертикально, а горизонтально. Например, не добавлять 8 процессоров на одну ВМ, а создать 4 ВМ по 2 процессора на каждой. Вдобавок это уменьшит площадь отказа.
Ставить виртуальные машины на внутренний мониторинг. В этом случае клиент может выбрать наиболее важные показатели работы ВМ и быстро получать оповещения об их состоянии. Это позволит вычислять неочевидные проблемы, которые не заметны на общем мониторинге.