У меня есть веб-служба REST в Azure, которая имеет очень высокую, но переменную нагрузку, все настроено на автоматическое масштабирование с помощью Paraleap, так что он может обрабатывать пиковые периоды, но снижает затраты, когда становится тише.
Мне никогда не удавалось найти способ, используя какие-либо показатели, предсказать, когда сервер начнет работать на максимуме. перед он на самом деле достигает максимума! Итак, решение, которое у меня есть на данный момент, - это отдельная программа, которая постоянно проверяет, включен ли сервер, если он начинает возвращать ошибки, он сообщает серверу начать возвращать сообщение об ошибке определенному проценту пользователей, возвращая простую ошибку занимает меньше ресурсов сервера, что позволяет большинству пользователей по-прежнему иметь службу, а затем он сообщает Paraleap увеличить количество экземпляров ... увеличение количества экземпляров обычно занимает 10-15 минут, поэтому в этот период дела не идут хорошо и у некоторых пользователей возникают ошибки, но в конечном итоге запускается новый экземпляр и нормальное обслуживание возобновляется.
Я надеялся, что Azure Traffic Manager станет моим решением, я надеялся, что смогу использовать режим аварийного переключения, и при обнаружении сбоя в моей основной веб-службе я мог перенаправить x% запросов в резервную копию, которая вернула бы основной- сервис в рабочее состояние .. в то же время я бы независимо сказал основному веб-сервису масштабироваться, и когда он закончился, диспетчер трафика перенаправил бы все обратно на основной веб-сервис. Другими словами, я бы получил мгновенное увеличение емкости, которое восполнит пробел, пока я загружаю новые экземпляры.
К сожалению, я не могу найти способ сделать это! Похоже, диспетчер трафика при обнаружении сбоя перенаправляет 100% трафика в резервную копию. Таким образом, мне нужно более чем удвоить емкость моего сервера только на эти моменты, т.е. иметь экземпляр X для основного веб-сервиса и x + 1, ожидающий в резервной копии, сбой с основным отвлечет 100% запросов на резервное копирование, что приведет к иметь больше возможностей, тогда я бы запустил больше экземпляров для основного, в конечном итоге диспетчер трафика отправил бы все запросы туда, после чего мне нужно было бы добавить больше экземпляров в резервную копию, и он снова будет ждать. Это было бы огромным перебором и стоило бы мне целого состояния!
Есть ли у кого-нибудь предложения о том, как я могу лучше справиться с этим?
Спасибо!
Стивен. Похоже, вам нужно потратить немного времени на изучение вашей установки, а также вам нужно рассмотреть вопрос о стоимости и доступности.
Виртуальные машины Azure поддерживают автоматическое масштабирование через облачную службу, в которой они развернуты, и используют возможности автомасштабирования облачной службы для управления подготовкой новых экземпляров (которые должны иметь возможность автоматически настраиваться). Хороший обзор можно найти на Веб-сайт документации Azure.
Если вы обнаружите, что возвращаете ошибки до масштабирования, вам необходимо установить более низкий порог для триггера масштабирования (например, более низкий порог ЦП) или запустить конфигурацию N + 1, где N - ваше минимальное количество виртуальных машин без нагрузки. сценарии использования. Это для уменьшения TTSO вашего API.
Вы никогда не достигнете мгновенной шкалы, если у вас нет уже работающего юнита.
Наконец, диспетчер трафика может помочь распределить нагрузку только там, где вы используете маршрутизацию с наименьшей задержкой, что означает запуск разных экземпляров вашего API в разных регионах Azure. Если это не то, что вам нужно, тогда диспетчер трафика - не решение.
Полное раскрытие информации: меня зовут Ларс Ларссон, архитектор программного обеспечения в Elastisys AB.
Вы описываете именно то, что может вам помочь облачная платформа Elastisys: она собирает данные мониторинга и может предсказуемо увеличивайте масштаб для удовлетворения спроса по мере его поступления, а не просто реагируйте, когда ваш сервис уже страдает. Алгоритмы основаны на серьезных исследованиях, проведенных группой распределенных систем Университета Умео, Швеция.
Однако пока нет поддержки взаимодействия с Azure (поддержка AWS, OpenStack и CityCloud доступна на нашем сайте). Страница GitHub).
пожалуйста связаться с Elastisys если вы захотите стать для нас примером использования, поскольку мы встраиваем поддержку Azure в будущие версии нашего программного обеспечения.