Балансировщик ресурсов Service Fabric использует устаревшую нагрузку.

Изучая балансировщик ресурсов и показатели динамической нагрузки в Service Fabric, мы столкнулись с некоторыми вопросами (запуск devbox SDK GA 2.0.135).
В обозревателе Service Fabric (портал и отдельное приложение) мы видим, что балансировка выполняется очень часто, большую часть времени она выполняется почти мгновенно и это происходит каждый второй. При просмотре информации о метрике нагрузки на узлах или разделах она не обновляет значения по мере того, как мы сообщаем о нагрузке.

Мы отправляем отчет о динамической нагрузке на основе нашего взаимодействия (запрос HTTP к службе), значительно увеличивая сообщаемые данные о нагрузке одного раздела. Этот всплеск становится виден где-то через 5 минут, после чего балансировщик фактически начинает балансировать. Кажется, это интервал, в течение которого данные загрузки обновляются. Время последнего отчета постоянно обновляется, но без нового значения.

Мы добавили метрики в манифест приложения и манифест кластера, чтобы убедиться, что они используются при балансировке. Это означает, что балансировщик ресурсов использует одни и те же данные в течение 5 минут. Это настраиваемый параметр? Это ограничение, потому что оно работает на devbox? Мы испробовали множество переменных в манифесте кластера, но ни одна из них не влияет на время обновления.

Если это невозможно адаптировать, может кто-нибудь объяснить, зачем запускать балансировщик с устаревшими данными? и почему был выбран этот 5-минутный интервал?


azure-service-fabric metrics rebalancing
person P. Gramberg    schedule 07.04.2016    source источник

Ответы (1)


arrow_upward
7
arrow_downward

Это действительно настраиваемый параметр, и по умолчанию он составляет 5 минут. Идея заключается в том, что в prod у вас есть тонны реплик, все из которых постоянно сообщают о нагрузке, и поэтому вы хотите объединить их в пакеты, чтобы не спамить Cluster Resource Manager всеми этими независимыми сообщениями.

Вероятно, вы правы в том, что это значение намного слишком велико для локальной разработки. Мы рассмотрим возможность изменения этого для локальных кластеров, а пока вы можете добавить следующее в манифест локального кластера, чтобы изменить время ожидания по умолчанию. Если там уже есть другие настройки, просто добавьте строку SendLoadReportInterval. Значение указано в секундах, и вы можете настроить его соответствующим образом. Ниже показано, как изменить интервал отчетов о нагрузке по умолчанию с 5 минут (300 секунд) на 1 минуту (60 секунд).

    <Section Name="ReconfigurationAgent">
        <Parameter Name="SendLoadReportInterval" Value="60" />
    </Section>

Обратите внимание, что это увеличивает нагрузку на некоторые системные службы (TANSTAAFL), и, как всегда, если вы работаете со сгенерированным или полным манифестом кластера, перед его развертыванием обязательно выполните команду Test-ServiceFabricClusterManifest. Если вы работаете с локальным кластером разработки, самый простой способ его развертывания — это, вероятно, просто изменить шаблон манифеста кластера (по умолчанию здесь: «C:\Program Files\Microsoft SDK\Service Fabric\ClusterSetup\NonSecure\ClusterManifestTemplate. xml») и просто добавьте строку, затем щелкните правой кнопкой мыши диспетчер локального кластера Service Fabric на панели задач и выберите «Сбросить локальный кластер». Это восстановит локальный кластер с вашими изменениями в шаблоне.

person masnider    schedule 07.04.2016
comment
Вы упомянули сценарий локальной разработки, но как это сделать для кластера Azure, развернутого с помощью шаблона ARM JSON? Я не вижу параметр SendLoadReportInterval в списке Настройка параметров кластера Service Fabric - person rktect; 19.05.2017
comment
Это связано с тем, что на самом деле это не тот параметр, который, как мы думаем, люди должны трогать, и поэтому он помечен как «Внутренний» — настройка этого значения может сломать ваш кластер из-за слишком большой нагрузки на системные службы. В продакшне мы не видим, чтобы люди на практике его трогали, поэтому это не описывается. Тот же перевод синтаксиса из XML в JSON, который вы видите здесь, например, будет применяться, если по какой-то причине вы хотите изменить это в prod. Не рекомендуется. - person masnider; 25.05.2017
comment
Справедливо - очень полезно. Я хочу придерживаться рекомендуемых настроек, но просто ради моего [недостатка] понимания - скажем, у меня есть служба наблюдения, отслеживающая мои показатели, означает ли это, что в производственной среде обычно приемлемо, чтобы любая видимость или реактивные действия задерживались до до пяти минут? Я стараюсь максимально использовать встроенный функционал. - person rktect; 25.05.2017
comment
Да, это то, что произойдет, и это верхняя граница. И такая задержка в целом приемлема для балансировки и исправления этих идеализированных метрических ограничений пропускной способности. Это управление ресурсами кластера — оптимизация. Также имейте в виду, что по мере того, как это масштабируется до множества узлов и служб — если все действительно так сложно, вы будете видеть, что ограничения нарушаются и исправляются все время (каждый запуск диспетчера ресурсов кластера — каждые несколько секунд) с момента запуска. узлы оказываются размазанными по всему 5-минутному отчетному окну. На практике они заканчивают тем, что постоянно отчитываются. - person masnider; 25.05.2017
comment
Также просто в качестве примечания. Если вам действительно нужно жесткое, мгновенное управление потреблением ресурсов, то /логические/ метрики, вероятно, не лучшее место для этих требований, и вам следует взглянуть на Управление ресурсами, которые мы выпустили в версии 5.6, но это только для реальных ресурсов (ЦП и Память на момент написания этой статьи). - person masnider; 25.05.2017
comment
Чрезвычайно полезные ответы - спасибо @masnider, что нашли время. Обратите внимание, что вы и команда SF круты! - person rktect; 25.05.2017
comment
Кроме того, на данный момент я использую нулевой вес метрики, а мои настраиваемые логические метрики предназначены только для видимости (а не для управления/управления ресурсами). Я хотел использовать для этого внутренние метрики SF, так как он уже выполняет всю агрегацию и обработку запросов. - person rktect; 25.05.2017