Как эффективно масштабировать в Windows Azure?

У меня возникли некоторые трудности с определением правильных конфигураций для эффективного масштабирования моего облачного сервиса. Я предполагаю, что нам просто нужно использовать раздел шкалы портала управления и ничего программно? Моя текущая конфигурация для веб-роли:

ВМ среднего размера (4 ГБ ОЗУ) Автомасштабирование — Диапазон CPUInstance — от 1 до 10 Целевой ЦП — от 50 до 80 Масштабирование вверх и вниз по 1 экземпляру за раз Время ожидания увеличения и уменьшения масштаба — 5 минут

Я использовал сайт http://loader.io/ для проведения нагрузочного тестирования путем отправки одновременных запросов к API. И он мог поддерживать только 50-100 пользователей. После этого я получал ошибки тайм-аута (10 секунд). Мое приложение будет ориентировано на миллионы пользователей в огромных масштабах, поэтому я не совсем уверен, как я могу эффективно масштабироваться, чтобы справиться с такой большой нагрузкой на сервер.

Я думаю, что проблема может заключаться в том, что время масштабирования составляет 5 минут (я думаю, что оно очень велико), а на портале управления самый низкий вариант — 5 минут, так что не знаю, как я могу его уменьшить?

Какие-либо предложения?


azure c# concurrency scalability azure-web-roles
person Bitsian    schedule 09.08.2013    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Механизм автоматического масштабирования Azure каждые 5 минут проверяет среднее значение загрузки ЦП за 60 минут. Это означает, что каждые 5 минут у него есть шанс решить, не слишком ли высока загрузка ЦП, и масштабировать вас.

Если вам нужно что-то более надежное, я бы рекомендовал подумать о следующем:

  • Использование ЦП редко является хорошим показателем для масштабирования веб-сайтов. Посмотрите на запросы/сек или запросы/ток вместо использования ЦП.
  • Рассмотрите возможность более частого масштабирования (каждую минуту?). Портал Azure не может этого сделать. Вам потребуется либо WASABi, либо AzureWatch для этого
  • В зависимости от ваших моделей использования, рассмотрите возможность просмотра более коротких средних значений времени, чтобы принять решение (например, в среднем более 20 минут, а не 60 минут). Еще раз, ваш выбор здесь: WASABi или AzureWatch.
  • Подумайте о том, чтобы посмотреть на /скорость/ роста показателей, а не только на сами последние средние значения. IE: запросы в секунду выросли на 20% за последние 20 минут. Опять же, механизм автоматического масштабирования Azure не может этого сделать, рассмотрите либо WASABi (который может это сделать), либо AzureWatch, который определенно может это сделать.

WASABi — это блок приложения от Microsoft. (то есть: DLL), которую вам нужно настроить, разместить и контролировать где-то самостоятельно. Он довольно гибкий, и вы можете переопределить любую функциональность, поскольку он с открытым исходным кодом.

AzureWatch — это сторонняя управляемая служба, которая отслеживает/автомасштабирует/лечит ваши роли Azure/виртуальные машины/веб-сайты/SQL Azure. /и т.д. Это стоит денег, но вы позволяете кому-то другому делать всю грязную работу.

Недавно я написал блог о сравнении трех продуктов

Раскрытие информации: я связан с AzureWatch

ХТН

person Igorek    schedule 09.08.2013
comment
Небольшое уточнение: вам не нужны WASABi или AzureWatch. Есть и другие сервисы, такие как MetricsHub. И вы даже можете создавать свои собственные, изучая счетчики производительности, журналы приложений, длины очередей и т. д., и вы можете выполнять действия по масштабированию с помощью вызовов PowerShell. Сказав все это: автоматическое масштабирование сложное, и вам, вероятно, лучше использовать библиотеку или сервис, как упоминал @Igorek. Но есть и другие варианты. - person David Makogon; 10.08.2013
comment
Спасибо, я зарегистрировался для получения пробной версии Azure Watch. Я все еще разбираюсь, как поставить все счетчики производительности ..... вариантов так много. Я просмотрел параметр запросов/сек в разделе веб-сервиса, и его минимальный период агрегации составлял 5 минут. Как это поможет мне, если в течение 1 минуты будет 1000 запросов, а моя веб-роль не масштабируется до 5 минут? - person Bitsian; 12.08.2013
comment
К сожалению, я не могу придумать никаких решений для сверхвнезапных всплесков, которые не имеют коррелирующих опережающих индикаторов. Вам нужно будет подождать не менее 5 минут, чтобы было запущено X серверов. Однако если бы эти всплески были связаны с каким-то графиком маркетинга/продвижения, временем суток, количеством регистраций или каким-то другим опережающим индикатором, то, безусловно, можно было бы приспособить стратегию опережающего масштабирования. - person Igorek; 12.08.2013
comment
Внезапные, неожиданные всплески тяжелы. Вы можете нести дополнительную мощность, чтобы справиться с всплеском приличного размера (скажем, на 30%-50% больше, в зависимости от вашей терпимости к риску/стоимости). Конечно, вы, возможно, не сможете выдержать одновременное воздействие огромной нагрузки, но с дополнительной емкостью вы получите возможность уменьшить воздействие, пока другие серверы работают. Кроме того, рассмотрите идею сокращения функций, если ваш сайт обнаруживает, что он сильно загружен. Ухудшение опыта, а не отказ сайта. - person MikeWo; 13.08.2013

arrow_upward
0
arrow_downward

Еще одна причина, по которой минимальное время составляет 5 минут, заключается в том, что Azure требуется некоторое время, чтобы назначить дополнительные компьютеры для вашей облачной службы и реплицировать на них ваше программное обеспечение. (У веб-приложений нет этой «проблемы»). Работая администратором SaaS, я обнаружил, что для облачных сервисов время разгона после масштабирования может составлять около 3-5 минут для нашего программного пакета.

Если вы хотите настроить масштабирование на портале Azure, я предлагаю значительно снизить диапазоны ЦП. Как упомянул Игорек, при масштабировании Azure учитывается среднее значение за последние 60 минут. Если облачная служба большую часть времени работает на 5% ЦП, а затем внезапно достигает пика и работает на 99%, потребуется некоторое время, чтобы среднее значение увеличилось и активировало ваши настройки масштабирования. Если оставить значение 80%, масштабирование произойдет слишком поздно. Пример RL: я управляю порталом, на котором выполняются вычисления с интенсивным использованием ЦП. При обычном использовании наши облачные сервисы, как правило, загружают ЦП на 2-5%, но в редких случаях мы видели, что они поднимаются до 99% и остаются на этом уровне некоторое время.

Моей первой попыткой масштабирования было 2 экземпляра и увеличение до 2 при средней загрузке ЦП 80%, но затем для запуска события потребовалось около 40 минут, потому что средняя загрузка ЦП не увеличивалась так быстро. Прямо сейчас у меня все настроено на масштабирование, когда средняя загрузка ЦП превысит 25%, и я вижу, что наши службы будут масштабироваться через 10-12 минут. Я не говорю, что 25% — это магическое число, я говорю, что вы работаете со «в среднем более 60 минут».

Во-вторых, Azure Portal показывает только ограниченный набор параметров масштабирования, а масштабирование можно задать более подробно при использовании Powershell/REST. Например, можно уменьшить 60-минутный интервал, по которому рассчитывается среднее значение.

person Krullthor    schedule 26.09.2016