Чем определяется быстродействие гостевой виртуальной машины
Как ускорить работу виртуальной машины
Тем не менее, грамотная оптимизация BM позволит вам увеличить производительность последней без оказания существенного влияние на хостовой компьютер.
Фиксированный размер диска
Используйте фиксированный размер виртуального диска.
Большинство систем виртуализации по умолчанию создают динамические диски, увеличивающиеся по мере «разрастания» установленной на них операционной системы. С одной стороны, использования такого типа контейнеров позволяет экономить место на физическом диске, однако установленная на динамический диск система работает медленнее, причем ее производительность падает с увеличением последнего.
Используйте дополнения гостевой ОС
Даже если вы не собираетесь пользоваться общими папками, буфером обмена и другими опциями расширения функциональности, не пренебрегайте установкой дополнений гостевой ОС, их инсталляция в систему обеспечивает более эффективное использование ресурсов хостовой машины.
Особенности использования антивирусов
Не устанавливайте в гостевую операционную систему антивирусных программ, в этом нет никакой необходимости, заботиться нужно о безопасности не виртуальной, а хостовой системы. Отключите в виртуальной ОС встроенную защиту, если не собираетесь использовать ее в рамках тестирования. Рекомендуем также добавить весь каталог с ВМ в исключения вашего антивируса.
Сканирование контейнера с ВМ не только замедляет ее работу, но и не приносит никакой пользы с точки обнаружения вредоносного ПО внутри виртуального контейнера.
Проверьте настройки виртуальной машины вручную
Что касается установленных по умолчанию параметров виртуальной машины, здесь нужно действовать по принципу «доверяй, но проверяй».
Зайдите в настройки вашей ВМ и и проверьте эти параметры:
Оперативная память
Увеличьте, если возможно, объем выделенной ОЗУ до 2 Гб.
Процессор
Выделите максимально допустимое количество ядер процессора и убедитесь, что в пункте PAE/NX стоит галочка. Если в вашей системе виртуализации доступны функции Nested VT-х/AMD-v, включите их, они улучшают виртуализацию.
Дисплей
Выделите виртуальной машине максимальный объем видеопамяти и включите, если выключено, ускорение 2D и 3D.
Установка виртуальной машины на SSD
Файл подкачки и автозагрузка
Не стоит пренебрегать и внутренней оптимизацией. Для увеличения производительности виртуальной машины используйте внутри нее файл подкачки, особенно на популярных Linux-системах. Размер файла свопа в данном случае определяется общими правилами.
К внутренней оптимизации также следует отнести отключение неиспользуемых элементов автозагрузки, визуальных эффектов, фоновых приложений, службы автоматического обновления системы и индексирования.
Некоторые особенности использования виртуальных машин для новичков
Виртуальные машины, такие как 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) — это будет гораздо медленнее.
Анализ производительности ВМ в VMware vSphere. Часть 3: Storage
Сегодня разберем метрики дисковой подсистемы в vSphere. Проблема со стораджем – самая частая причина медленной работы виртуальной машины. Если в случаях с CPU и RAM траблшутинг заканчивается на уровне гипервизора, то при проблемах с диском, возможно, придется разбираться с сетью передачи данных и СХД.
Тему буду разбирать на примере блочного доступа к СХД, хотя при файловом доступе счетчики примерно те же.
Немного теории
Когда говорят о производительности дисковой подсистемы виртуальных машин, обычно обращают внимание на три связанных друг с другом параметра:
Пропускная способность важна для нагрузок последовательного характера: доступ к блокам, расположенным друг за другом. Например, такую нагрузку могут генерировать файловые сервера (но не всегда) и системы видеонаблюдения.
Пропускная способность связана с количеством операций ввода/вывода следующим образом:
Throughput = IOPS * Block size, где Block size – это размер блока.
Размер блока является довольно важной характеристикой. Современные версии ESXi пропускают блоки размером до 32 767 КБ. Если блок еще больше, он делится на несколько. Не все СХД могут эффективно работать с такими большими блоками, поэтому в Advanced Settings ESXi есть параметр DiskMaxIOSize. С помощью него можно уменьшить максимальный размер блока, пропускаемого гипервизором (подробнее здесь). Рекомендую перед изменением данного параметра проконсультироваться с производителем СХД или хотя бы протестировать изменения на лабораторном стенде.
Большой размер блока может пагубно сказываться на производительности СХД. Даже если количество IOPS и throughput относительно невелики, при большом размере блока могут наблюдаться высокие задержки. Поэтому обращайте внимание на этот параметр.
Latency – самый интересный параметр производительности. Задержка операций ввода/вывода для виртуальной машины складывается из:
GAVG и DAVG измеряются, а KAVG рассчитывается: GAVG–DAVG.
Источник
Остановимся подробнее на KAVG. При нормальной работе KAVG должен стремиться к нулю или, по крайней мере, быть сильно меньше, чем DAVG. Единственный известный мне случай, когда KAVG ожидаемо высокий, – ограничение по IOPS на диске ВМ. В таком случае при попытке превышения лимита будет расти KAVG.
Самой значительной составляющей KAVG является QAVG – время в очереди на обработку внутри гипервизора. Остальные составляющие KAVG пренебрежимо малы.
Очередь в драйвере дискового адаптера и очереди к лунам имеет фиксированный размер. Для высоконагруженных сред данный размер бывает полезно увеличить. Здесь описано, как увеличить очереди в драйвере адаптера (одновременно увеличится очередь к лунам). Данная настройка работает, когда с луном работает только одна ВМ, что бывает редко. Если на луне несколько ВМ, необходимо также увеличить параметр Disk.SchedNumReqOutstanding (инструкция здесь). Увеличив очередь, вы уменьшаете QAVG и KAVG соответственно.
Но, опять же, сначала ознакомьтесь с документацией от вендора HBA и протестируйте изменения на лабораторном стенде.
На размер очереди к луну может влиять включение механизма SIOC (Storage I/O Control). Он обеспечивает равномерный доступ к луну со стороны всех серверов кластера за счет динамического изменения очереди к луну на серверах. То есть, если на каком-то из хостов работает ВМ, которая требует непропорционально много производительности (noisy neighbor VM), SIOC уменьшает длину очереди к луну на данном хосте (DQLEN). Подробнее здесь.
С KAVG разобрались, теперь немного о DAVG. Тут все просто: DAVG – это задержка, которую вносит внешняя среда (сеть передачи данных и СХД). В любой современной и не очень СХД есть свои счетчики производительности. Для анализа проблем с DAVG имеет смысл смотреть на них. Если же со стороны ESXi и СХД все нормально, проверяйте сеть передачи данных.
Чтобы не было проблем с производительностью, выбирайте правильную Path Selection Policy (PSP) для вашей СХД. Практически все современные СХД поддерживают PSP Round-Robin (с ALUA, Asymmetric Logical Unit Access, или без). Данная политика позволяет использовать все доступные пути к СХД. В случае с ALUA используются только пути до контроллера, который владеет луном. Не для всех СХД на ESXi есть дефолтные правила, которые устанавливают политику Round-Robin. Если для вашего СХД правила нет, используйте плагин от производителя СХД, который создаст соответствующее правило на всех хостах кластера, или создайте правило самостоятельно. Подробности здесь.
Также часть производителей СХД рекомендуют менять количество IOPS на путь со стандартного значения 1000 на 1. В нашей практике это позволяло «выжать» из СХД больше производительности и значительно сократить время, которое требуется на failover в случае выхода из строя или обновления контроллеров. Сверьтесь с рекомендациями вендора, и если противопоказаний нет, то попробуйте изменить данный параметр. Подробности здесь.
Основные счетчики производительности дисковой подсистемы виртуальной машины
Счетчики производительности дисковой подсистемы в vCenter собраны в разделах Datastore, Disk, Virtual Disk:
В разделе Datastore находятся метрики по дисковым хранилищам vSphere (датасторам), на которых лежат диски ВМ. Здесь вы найдете стандартные счетчики по:
В разделе Disk находятся метрики по блочным устройствам, которые используются ВМ. Тут есть счетчики по IOPS типа summation (количество операций ввода/вывода за период измерения) и несколько счетчиков, относящихся к блочному доступу (Commands aborted, Bus resets). Данную информацию, на мой взгляд, также удобнее смотреть в ESXTOP.
Раздел Virtual Disk – самый полезный с точки зрения поиска проблем производительности дисковой подсистемы ВМ. Здесь можно посмотреть производительность по каждому виртуальному диску. Именно эта информация нужна, чтобы понять, есть ли проблема у конкретной виртуальной машины. Помимо стандартных счетчиков количества операций ввода/вывода, объема чтения/записи и задержек, в данном разделе присутствуют полезные счетчики, которые показывают размер блока: Read/Write request size.
На картинке ниже график производительности диска ВМ, на котором можно увидеть количество IOPS, задержки и размер блока.
Также метрики производительности можно посмотреть по всему датастору, если включен SIOC. Здесь представлена базовая информация по средней Latency и IOPS’ам. По умолчанию данную информацию можно посмотреть только в реальном времени.
ESXTOP
В ESXTOP несколько экранов, на которых представлена информация по дисковой подсистеме хоста в целом, отдельным виртуальным машинам и их дискам.
Начнем с информации по виртуальным машинам. Экран “Disk VM” вызывается клавишей “v”:
NVDISK – это количество дисков ВМ. Чтобы посмотреть информацию по каждому диску, нажмите “e” и введите GID интересующей ВМ.
Значение остальных параметров на данном экране понятно из их названий.
Еще один полезный при поиске проблем экран – Disk adapter. Вызывается клавишей “d” (на картинке ниже выбраны поля A,B,C,D,E,G):
NPTH – количество путей к лунам, которые видны с данного адаптера. Чтобы получить информацию по каждому пути на адаптере, нажмите “e” и введите название адаптера:
AQLEN – максимальный размер очереди на адаптере.
Также на этом экране представлены счетчики задержек, о которых я рассказывал выше: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
На экране Disk device, который вызывается клавишей “u”, представлена информация по отдельным блочным устройствам – лунам (на картинке ниже выбраны поля A, B, F, G, I). Здесь можно увидеть состояние очереди к лунам.
DQLEN – размер очереди для блочного устройства.
ACTV – количество команд ввода/вывода в ядре ESXi.
QUED – количество команд ввода/вывода в очереди.
%USD – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.
Если %USD высокий, стоит рассмотреть возможность увеличения очереди. Чем больше команд в очереди, тем выше QAVG и, соответственно, KAVG.
Также на экране Disk device можно посмотреть, работает ли на СХД VAAI (vStorage API for Array Integration). Для этого нужно выбрать поля A и O.
Механизм VAAI позволяет перенести часть работы из гипервизора непосредственно на СХД, например, зануление, копирование блоков или блокировки.
Как видно на картинке выше, на данной СХД VAAI работает: активно используются примитивы Zero и ATS.
Почему виртуалки “на вырост” начинают тормозить, и что с этим делать новичку
Клиенты все чаще мигрируют в облака в погоне за гибкостью: здесь намного проще добавить диск, память и процессоры, если чего-то не хватает. Но иногда новички обнаруживают, что добавление ресурсов перестает помогать. Скорость работы не растет, а с бэкапом и восстановлением начинаются проблемы.
Сегодня вместе с @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 процессора на каждой. Вдобавок это уменьшит площадь отказа.
Ставить виртуальные машины на внутренний мониторинг. В этом случае клиент может выбрать наиболее важные показатели работы ВМ и быстро получать оповещения об их состоянии. Это позволит вычислять неочевидные проблемы, которые не заметны на общем мониторинге.