amarao (amarao_san) wrote,
amarao
amarao_san

Абстрактные размышления о модели ограничения iops'ов для Xen'ае

Существующая схема в XCP подразумевает использование cgroups и io-скедулеров. Но это слишком неудобно, как мне кажется.

Поскольку готовых удобных решений нет, давайте подумаем, как должны выглядеть готовые красивые решения?

Я исхожу из модели blktap(2), то есть виртуального блочного устройства, которое обслуживается в dom0 и присутствует в domU, по одному instance на каждую виртуалку.

Итак, что мы хотим ограничить? В самом абстрактном смысле - сделать так, чтобы io одного человека не мешало io другого, а в случае конфликта, выдавало бы каждому не менее X операций в секунду.

Этот наивный подход утыкается в проблему, которую я так и не смог решить, и которая, как мне кажется, так и не имеет решения: мы не можем сказать, сколько IOPS'ов у нас есть. Есть статистические замеры, есть худший и лучший случаи, но вот реального числа "будет не менее XX иопсов" у нас нет. Точнее, такое число есть, но оно очевидно неудовлетворительно и определяется случаем, когда все запросы с диску пробивают все кеши и попадают на один и тот же диск в худшем для него порядке. Такого случая исключить нельзя (хотя он очень маловероятен), таким образом, нижняя оценка производительности у нас оказывается чрезмерно заниженной. Все остальные оценки же не являются достоверными, так как мы всегда можем оказаться "чуть ниже прогноза".

Альтернативным решением является внимательное рассмотрение обратной к IOPS величине - времени выполнения дисковой операции. Но тут нас поджидает некоторая неприятность - было бы разумно ожидать, что хранилище в секунду может обработать не больше секунды запросов. Это было бы так, если бы все запросы обрабатывались строго синхронно и последовательно. В реальности же, благодаря наличию очереди запросов мы можем иметь (де-факто) исполнение запросов в параллель, таким образом, время отдельных запросов не может быть суммироваться.

Однако, пусть и косвенным признаком, но время выполнения дисковой операции может служить симптомом наличия перегрузки на хранилище, хотя, опять же, если размер размер блока не изменен (блоки разного размера обрабатываются за разное время при той же самой фактической загрузке).

Дополнительным фактором, осложняющим анализ, является конкурентный доступ к хранилищу с нескольких хостов - мы не можем использовать сумму запросов с одного хоста как показатель загруженности хранилища. Выходить же на уровень хранилища для анализа загруженности можно, но решение получится сильно неавтономным (так как каким-то образом эти метрики нужно ещё достоверно и быстро доставлять на хосты, а алгоримты хостов каким-то образом должны предсказывать поведения друг друга, либо потребуется координационный сервер...).

Итак, проблема номер один звучит так: у нас нет достоверных метрик, по которым мы могли бы определять загруженность хранилища (это раз), и два, нет достоверных оценок в числовом выражении, каким ресурсом мы располагаем.

Проблема номер два звучит примерно так: каким образом мы будем ограничивать IOPS'ы? Во-первых, нам хочется предоставить возможность burst'а для редкозагруженных машин, с другой, нам не хочется, чтобы эти отдельные пики сказывались на работе остальных машин.

Третья проблема чуть более практичная: каким образом мы формулируем ограничения? Это относительный приоритет, абсолютное число или абстрактное best-efforts в надежде, что наши усилия окажутся лучше, чем дефолтный io-скедулер?

Четвёртая проблема уже упоминалась, но всё равно требует отдельного внимания: любого рода скедулеры уровня хоста не будут учитывать наличие прочих хостов с равноконкурентным доступом к хранилищу; скедулер же уровня хранилища не сможет разделять виртуальные машины между друг другом (если мы стоим на модели lvmoiscsi). Другими словами, предлагаемое решение должно каким-то образом учитывать помехи от соседей как объективную реальность и действовать в своих пределах, не мешая соседям. При этом, опять же, нужно избегать стадного эффекта при работе алгоритма (все одновременно сделали бурст, потом одновременно же из-за затора тормознулись).

Выписываем проблемы ещё раз:
1) Как определить затор, желательно до его начала?
2) Как совместить burst с отсутствием задержек у окружающих?
3) По каким признакам накладывать ограничения?
4) Как учитывать конкурентный доступ к ресурсу со стороны неконтролируемых конкурентов при ограничении контролируемых?
Tags: xen, философия
Subscribe

Recent Posts from This Journal

  • Rust soundness

    Каждый раз, когда я сталкиваюсь с маленькими "но" в Rust'е, это ощущение тщательной продуманности. Например, простейшие fold-функции для итераторов:…

  • still_ntp

    В ходе локального мозгового штурма у меня родилась суперидея. Надо написать ntp сервер, который может отдавать указанную дату. Т.е. сказали при…

  • arping'а не достаточно

    Я обнаружил, что arping не умеет делать целый запрос полностью (т.е. source mac, dest mac, source ip, dest ip). Dest либо IP, либо mac, и это немного…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 4 comments