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

Переходим дальше, к тестированию, но сначала, небольшое отступление…

Возвращаясь к Resource Monitor, мы можем наблюдать в нем пропускную способность (Throughput = IOPS x I/O), которая выражается в байтах/сек. Пример, 10.000 IOPS блоками 16k это (10000 x 16k) = 160.000 кб/сек пропускной спобосности в 160 Мб/сек.

Нам нужно опираться на данные значения, т.к. они напрямую связаны с IOPS. Но важнее всего, это задержки (latency). Само по себе измерение IOPS без привязки к Latency не имеет смысла, если у вас будет 100.000 IOPS при значении отклика в 10 секунд это будет ужасной производительностью, по сравнению с 20.000 IOPS и откликом в 1 мс. Особенно, это будет заметно на приложениях, которым время отклика очень важно, такие как Базы Данных.

Итак, представьте, что вы приехали на мойку машин.Это специальная мойка, где клиенты (I/O) обслуживаются спецмойками (HDD) со средней скоростью 10 мс. Если вы поделите одну секунду на 10 мс, мы понимаем, что эта мойка сможет обрабатывать 100 машин в секунду. Но только по одному и последовательно. Нельзя же заехать на одну мойку сразу несколькими машинами.

Поэтому, когда клиент прибывает на мойку, и в течение этих 10 мс времени обработки приходит второй клиент, этот клиент должен ждать. Как только мойка ожидает клиента, ее обработка все равно занимает всего 10 мс, но общее время обработки составит 15 мс, а в худшем случае (два клиента прибыли одновременно) и 20 мс.

Поэтому важно понимать, что, хоть диск и может обрабатывать отдельные операции I/O со средней задержкой 10 мс, фактическая задержка, воспринимаемая приложением, может быть выше, так как некоторые операции ввода-вывода должны ждать в очереди. Этот пример также иллюстрирует, что ожидание в очереди увеличивает задержку для определенного ввода-вывода, который будет обработан. Поэтому, если вы увеличите очередь I/O, вы заметите, что средняя задержка (AVG latency) увеличится. Более длинные очереди будут означать более высокую задержку, но при этом мы получим больше IOPS.

Как это получается? Хитрость заключается в том, что СХД может быть умной, она смотрит на очередь и затем упорядочивать операции ввода-вывода таким образом, чтобы фактический шаблон доступа к диску был более последовательным. Таким образом, диск может обслуживать больше операций ввода-вывода в секунду за счет увеличения средней задержки. Для еще одного примера, если надо прочитать 3 блока на диске, 1ый блок расположен у начала диска (ближе к центру), 2ой в конце диска, 3ий опять вначале диска, то выгоднее, прочитать первый блок, подождать 1мс, прочитать 3ий блок и после этого перевести головку диска к концу и прочитать 2ой блок еще через 5мс, чем прочитать 1ый, перевести головку (+5мс), прочитать блок и певерести обратно головку (+5мс). Да, из-за этого вырастет время отклика, но не настолько критично. Тут надо соблюдать баланс. А вот на SSD таких проблем нет, т.к. вся механика отсутствует. За это мы их и любим 🙂

Еще надо не забывать, что все операции I/O обрабатывает процессор, и чем больше дисков, тем больше нужно процессорной мощности на эти операции. Довольно реальной методикой подсчета «А хватит ли нам процессорной мощности обрабатывать 24 SSD?» можно считать отношением IOPS/ГГц, это значение не сильно изменяется для различных СХД среднего уровня, и в среднем, равно 10000 IOPS/ГГц.

Окей, еще немного времени уделим (хотя, про это только ленивый не писал) вычислению IOPS до покупки СХД в следующей статье.