#azure #azure-appfabric
#azure #azure-appfabric
Вопрос:
У меня есть проект Azure webrole, который включает в себя длительную задачу запуска установки стороннего программного обеспечения на экземпляр; Иногда я видел экземпляры, которые не отвечают, поэтому я внедряю проверку, чтобы балансировщик нагрузки принял это к сведению и не направлял трафик на плохие экземпляры. Этого, конечно, недостаточно — я бы хотел, чтобы Azure (Fabric?) Затем перезагрузил экземпляр, и если это не поможет (то есть заставить экземпляр правильно отвечать на запрос) — повторно создайте экземпляр. Это поведение, и если да, то где это задокументировано? Я искал довольно долго, но не нашел ничего полезного.
Спасибо
Комментарии:
1. Я знаю, что это не ответ на ваш вопрос, но думали ли вы об использовании виртуальных машин вместо веб-ролей?
Ответ №1:
Используя API управления, вы должны иметь возможность внешне отслеживать экземпляры своих ролей. Затем, если он занимает много времени, вы должны иметь возможность принудительно отобразить его повторно.
Ответ №2:
http://blogs.msdn.com/b/kwill/archive/2013/02/28/heartbeats-recovery-and-the-load-balancer.aspx описывает работоспособность экземпляра роли, что Azure делает для восстановления и как использовать проверку балансировки нагрузки.
Когда вы говорите, что ваш экземпляр не отвечает, означает ли это, что экземпляр отображается как занятый (или что-то помимо готовности) на портале, или просто IIS не отвечает на запросы? Если первый (экземпляр показывает занятость), то вам не нужна проверка балансировки нагрузки, поскольку Azure автоматически удалит этот экземпляр из ротации. Если последнее (IIS не отвечает), то вы потенциально можете реализовать событие проверки состояния в своем веб-коде таким образом, что если у самого w3wp возникла проблема, то экземпляр будет выведен из ротации фабрикой, но если сам w3wp исправен, и это просто запросы, которые не отвечают, тогда вы можетепотребуется проверка балансировки нагрузки.
Наличие хорошего решения для мониторинга и восстановления очень ценно, но я бы рекомендовал вместо перезагрузки экземпляров для устранения проблемы с w3wp, вместо этого вам следует исследовать основную причину, по которой ваши экземпляры не отвечают. Исправьте источник проблемы, а не накладывайте пластырь :). Сообщение в блоге на http://blogs.msdn.com/b/kwill/archive/2013/02/28/heartbeats-recovery-and-the-load-balancer.aspx , и, в частности, сценарий устранения неполадок 5, может быть хорошим местом для начала расследования.
Комментарии:
1. Спасибо! экземпляры отображаются на портале Azure как «Готовые». Когда я выполняю RDP и просматриваю их локально, они возвращают HTTP 400, а когда я просматриваю внешний URL-адрес службы, я получаю «Ой! Google Chrome не удалось подключиться «. Таким образом, похоже, что сбой зонда не приводит к тому, что экземпляры считаются плохими.
2. как вы думаете, я должен вернуть ошибку 500, в которой говорится, что виноват сервер, а не клиент?