У меня есть веб-приложение Azure (план обслуживания приложений S2), для которого настроено автоматическое масштабирование, но минимальное количество экземпляров равно 1. Поскольку оно в основном простаивает, реальное количество экземпляров также почти всегда равно 1.
На прошлой неделе "что-то" произошло, и сайт больше не был доступен. На каждый запрос был дан ответ http-статус 500. Это продолжалось около 10 часов, и внезапно сайт снова стал доступен. Я ничего не менял за несколько дней до появления ошибки и не делал ничего, чтобы сайт снова вернулся.
Я начал запрос поддержки для этого, и инженер службы поддержки занимался этим. По его словам, причиной проблемы стали:
основная причина указывает на службу активации процессов Windows, которая не смогла запустить процесс, связанный с вашим приложением, и платформа не смогла восстановить его в указанный период времени.
Учитывая, что у меня нет возможности настроить WPA, я предполагаю, что это проблема платформы. Инженер поддержки подтвердил.
я считать это означает, что лазурь должна иметь дело с таким состоянием и делать все необходимое, чтобы снова запустить приложение. Поскольку для возобновления работы службы потребовалось 10 часов, я предполагаю, что это произошло случайно, и лазурь здесь ничего не сделала. Должен ли я опубликовать отчет об этом инциденте? (Инженер поддержки здесь не особо полезен ...)
Кроме того, инженер службы поддержки настаивает на том, что наличие более одного экземпляра решило бы проблему доступности, потому что
Например, я могу подтвердить, что в этом сценарии вариант аварийного переключения избыточности будет заключаться в масштабировании сайта как минимум до двух экземпляров. Таким образом, если один из экземпляров будет недоступен, его возьмет на себя второй.
Я думаю, это просто не может быть правильным, потому что веб-приложение было объявлено лазурным как «работоспособное» и действительно ответило на запрос, хотя и со статусом 500.
Будет ли в этом случае Azure действительно отправлять трафик только тому экземпляру, который не возвращал статус 500? А также, учитывая, что я не знаю, что в первую очередь вызвало проблему с WPA - возможно ли, что такая же проблема возникла бы и со вторым экземпляром?
При масштабировании до нескольких экземпляров веб-приложения они будут находиться за балансировщиком нагрузки (вы этого не увидите, но это то, что происходит за кулисами). Зонд балансировщика нагрузки должен обнаруживать 500 ошибок, исходящих от вашего первого экземпляра, и не направлять на него трафик.
Ваши экземпляры веб-приложений будут работать на разных виртуальных машинах под капотом, поэтому, если проблема с WPA возникает на первой, она не должна влиять на вторую. Тем не менее, существует вероятность того, что на втором узле может возникнуть другая проблема с WPA, особенно если что-то в вашем приложении вызывает эту проблему.