IOPS, VDI, IOMETER — Часть 1

Идея этой статьи в том, что пока я не нашел адекватной инструкции по пользованию такой классической программой как IOmeter. Также, не нашел готовых профилей для нагрузки, в зависимости от типа задач, это тоже отдельный вопрос. Постараюсь рассказать максимально просто про IOPS, с картинками и с неким углублением в VDI (виртуализицию рабочих столов) на ОС Windows 10.
Сама инструкция будет во второй статье, сначала начнем с теории, будет много текста.

Windows, изначально, был спроектирован для использования локальных дисков и требует постоянный доступ к дисковой подсистеме, даже в момент простоя. В дополнение к этому, Windows будет использовать столько операций ввода-вывода или пропускной способности диска, насколько это возможно. Это означает, что ВМ (виртуальная машина) при использовании общего хранилища, пытается перетянуть одеяло доступных IOPS на себя. В результате, когда вы виртуализируете много рабочих станций, и у вас общее хранилище данных (SAN или NAS), все они конкурируют за использование максимально возможного дискового ввода-вывода, чтобы максимизировать свою производительность (без знания потребностей других ВМ которые используют тот же аппаратный ресурс). Если ОС не будет получать достаточно требуемого кол-ва операций ввода-вывода, производительность рабочего стола снизится, и пользователи увидят его в виде длительного времени загрузки / входа в систему, медленного запуска приложений и в целом, низкой производительности рабочего стола.

Основная нагрузка на диск идет в момент загрузки ОС, во время проверки антивирусом, установки обновлений и их очистки. В связи с этим, существует одна из главных проблем под названием «boot storm», когда люди приходят на свои рабочие места, скажем, в 9 утра, и включают компьютер. Еще Windows, при наличии в нем антивируса, более чем в 2 раза увеличивает кол-во потребляемой памяти, благо, с этим в последнее время все проще, сервера стали нести на себе большой объем RAM. Однако, главная проблема в антивирусе, это критическое увеличение потребляемых IOPS. Это, конечно, проблема VDI инфраструктуры, но об этом позже, смысл не меняется.

Windows складывает операции чтения и записи в очереди, чтобы обработать их когда ресурс станет доступным. Очереди чтения/записи ведут к задержкам (latency), задержки же превращаются в проблемы с производительностью. Все становится еще хуже, когда мы имеем дело с виртуализованной ОС, т.к. это в свою очередь накладывает свои «накладные расходы» связанные с сетью передачи данных, гипервизором и др. Таким образом, отклик диска из 5мс на локальных дисках, превращается в 20+ мс при тех же нагрузках на виртуализации при конкуретном (когда каждая виртуальная машина пытается урвать себе как можно больше дисковых операций) использовании ресурсов другими ВМ на этой же системе хранения.

Какие есть варианты решения этих проблем?
1. SuperFetch — Эта фича пытается предсказать поведение пользователя. Она записывает поведение пользователя и пытается загрузить нужные страницы в память, прежде чем, что они будут нам нужны (или не будут). Сама Microsoft считает, это функцией повышения производительности, но не функцией оптимизации вводы-вывода (IOPS), т.к. причина в том, что она наоборот вредит использованию диска, пытаясь предсказать поведение пользователя считывая информацию с диска, вызывая тем самым увеличенную нагрузку на диск.
2. ReadyBoost — Эта фича уже неактуальна, т.к. предполагает использование USB флешки как место хранения кеша. Учитывая повсеместное внедрение SSD дисков, где даже самый дешевый и медленный SSD намного быстрее самой дорогой флешки (и дешевле). Также, эту функцию не выйдет использовать в виртуализации.
3. ReadyDrive — Эта фича позволяет Windows использовать специальные аппаратные средства в жестких дисках с встроенной флэш-памятью, они же — гибридные диски, они же — SSHD. Первыми начали выпускать такое Seagate и Samsung, но недавно подтянулась и Western Digital. Чтобы определить, какие данные следует поместить во флэш-память, ОС использует команды ATA/ATAPI-8, отвечающие за две важные функции: управление данными, которые нужно хранить во флэш-памяти, и управление переходом в режим работы с флэш-памятью. К примеру, при завершении работы система сохраняет в этом кэше данные для загрузки, что позволяет ускорить следующий запуск системы. При переходе в режим сна в кэше сохраняются некоторые части файла гибернации, что ускоряет возобновление работы. Поскольку кэш активен даже когда диск остановлен, система может использовать флэш-память для кэширования записи на диск, что позволяет не раскручивать диск, что существенно влияет на энергопотребление и позволяет сэкономить время на приведение диска на рабочую скорость. Опять же, технология была интересной 10 лет назад, когда SSD диски стоили дорого, и даже небольшой SSD кеш в жестком диске давал преимущество, сейчас это уже не имеет смысла.
4. Перевести хранение ВМ с классических HDD СХД на SSD СХД — На первый взгляд все отлично, новая технология, все очень быстро. Но дорого. И пока объемы SSD не достигли объемов HDD, а если и достигли, то ценник на них — как на крыло от самолета. А это значит, что вам нужно купить больше SSD -> это тянет за собой покупку большего кол-ва контроллеров -> значит нужно купить больше систем хранения. Это совсем не вяжется с глобальной концепцией виртуализации, которая предназначена для того, чтобы сэкономить пространство, электроэнергию и охлаждение в ЦОДе. Если вам необходимо добавлять стойки жестких дисков в ЦОД, вы потеряете почти все преимущества виртуализации. Это означает, что ваши затраты на CAPEX / OPEX и сложность развертывания VDI значительно возрастают. Однако, стоит очень сильно оговориться о том, что машинки прекрасно жмутся инлайново (Inline Deduplication) и это даёт офигенную такую экономию. А учитывая, что почти у всех вендоров сейчас есть гарантированные программы эффективности на SSD 1:3 — довольно спорно утверждать, что SSD будет очень дорог.

Окей, вернемся к IOPS. Как же их измерять? Измерение IOPS может вызвать затруднения, поскольку оно не связано напрямую с производительностью. Эта комбинация IOPS которые ОС запросила (requested), и тех, которые ей доступны (available), это дает нам задержку дисковой подсистемы (storage latency). Вот эта storage latency уже напрямую связана с производительностью, т.к. большая задержка приводит к тому, что ОС и приложения перестают отвечать на запросы (классические «фризы» и подвисания системы»). Хотелось бы как-то измерить IOPS, которую запрашивает Windows. Сделать это можно через vscsiStats (как с этим работать, можно почитать в отдельной статье). Есть возможность измерить IOPS доступные. Чем ближе значение очереди к нулю, тем ближе к идеальным значения запрошенных и доступных IOPS. Это одна из основных наших задач — снижение дисковой очереди.

Что нам понадобится — Perfmon (Perfomance Monitor) и его Счетчики (counters), ESXTOP (команда статистики ESXI) и IOmeter.

Счетчики, которые нам пригодятся: Раздел PhysicalDisk
1. Disk Reads/sec — IOPS на чтение.
2. Disk Writes/sec — IOPS на запись.
3. Disk Transfers/sec — Общее кол-во IOPS.
4. Current Disk Queue Length — Глубина очереди, которая скопилась в ОС.

Значения в поле Value следует читать до запятой, т.е. ниже, на скриншот, это 475 IOPS.

На картинке ниже, у нас все плохо, очередь скопилась, что вызвало увеличение времени отклика (response time, оно же latency).

Следующее, что нам потребуется — ESXTOP
Заходим на ESXI, запускаем esxtop, жмем U (нас перекинет в раздел по части дисков).

Нас интересуют вот эти показатели (можно обновлять результаты по нажатию кнопки 2):

Из того, что нам нужно в этих блоках:
1. CMDS/s — это сумма IOPS в READS/s и WRITES/s
2. GAVG/cmd — это задержка

Как же, в итоге, тестировать нашу инфраструктуру? Продолжим это во второй статье.