AWS ELB Apache2 503 Сервіс недоступний: сервер бек-енду працює

Ми працювали пару веб-сайтів з інфраструктури Amazons AWS вже близько двох років, і приблизно два дні тому веб-сервер почав знижуватись один-два рази на день, з єдиною помилкою, яку я можу виявити:

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

CloudWatch не спрацьовує жодних тривог (CPU / Disk IO / DB Conn). Я спробував зайти на сайт через еластичний IP, щоб пропустити ELB, і отримав таке:

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.

Я не бачу нічого незвичайного в журналах apache і переконався, що вони правильно обертаються. У мене немає проблем з доступом до машини, коли вона "вниз" через SSH і переглядаючи список процесів, я бачу 151 apache2 процесів, які здаються мені нормальними. Перезапуск апаша тимчасово усуває проблему. Ця машина працює як просто веб-сервер за ELB. Будь-які пропозиції будуть дуже вдячні.

Середнє використання процесора: 7,45%, Мінімум: 0,00%, Максимум: 25,82%

Середнє використання пам'яті: 11,04%, Мінімум: 8,76%, Максимум: 13,84%

Середнє значення використання заміни: N / A, Мінімум: N / A, Максимум: N / A

Використання дискового простору для / dev / xvda1, встановленого на / середній: 62,18%, мінімум: 53,39%, максимум: 65,49%

Дозвольте мені уточнити, я думаю, що проблема полягає в індивідуальному екземплярі EC2, а не в ELB, я просто не хотів цього виключати, навіть якщо мені не вдалося досягти еластичного IP. Я підозрюю, що ELB просто повертає результати попадання на фактичний екземпляр EC2.

Оновлення: 2014-08-26 Я повинен був оновити це раніше, але "виправлення" було зробити знімок "поганого" екземпляра і запустити отриманий AMI. З тих пір вона не зникла. Я дивився на перевірку стану здоров’я, коли у мене ще виникали проблеми, і я міг потрапити на сторінку перевірки здоров’я ( curl http://localhost/page.html), навіть коли отримував проблеми з пропускною спроможністю від балансира навантаження. Я не переконаний, що це питання медичної перевірки, але оскільки ніхто, включаючи Амазонку, не може дати кращої відповіді, я відзначаю це як відповідь. Дякую.

Оновлення: 05.05.2015 Я думав, що повернусь сюди і скажу, що частиною проблеми, на яку я зараз твердо вірю, є налаштування перевірки здоров’я. Я не хочу виключати їх виникнення проблеми з AMI, тому що після запуску замісної AMI це, безумовно, стало краще, але я з’ясував, що наші перевірки здоров’я були різними для кожного балансира навантаження і того, що мав найбільше проблем мав дійсно агресивний нездоровий поріг та тайм-аут реакції. Наш трафік має тенденцію сприймати непередбачувано, і я думаю, що між агресивними налаштуваннями перевірки здоров’я та шипами в трафіку це була ідеальна буря.

Ви отримаєте "Задній сервер працює на потужність", коли балансир навантаження ELB виконає перевірку стану здоров'я та отримає "сторінку не знайдено" (або іншу просту помилку) через неправильну конфігурацію (як правило, з хостом NameVirtual).

Спробуйте зімкнути папку файлів журналів за допомогою користувача "ELB-HealthChecker". напр

grep ELB-HealthChecker  /var/log/httpd/*

Зазвичай це призведе до 4 - або 5-разової помилки, яку легко виправити. наприклад, затоплення, MaxClients тощо надає проблемному шляху занадто багато кредиту.

FYI Amazon: Чому б не показати повернуту відповідь із запиту? Навіть код статусу допоможе.

Я просто натрапив на це питання сам. Amazon ELB поверне цю помилку, якщо немає здорових випадків. Наші веб-сайти були неправильно налаштовані, тому перевірка здоров'я ELB виявилася невдалою, що призвело до того, що ЕЛБ вийняв два сервери з обертання. З нульовими здоровими сайтами, ELB повернув 503 Сервіс недоступний: сервер "бек-енд" працює на потужності.

[EDIT після того, як краще зрозуміти питання] Не маючи жодного досвіду ELB, я все ще думаю, що це звучить підозріло, як помилка 503, яка може бути викинута, коли Apache фронтує Tomcat і затоплює з'єднання.

Ефект полягає в тому, що якщо Apache доставляє більше запитів на з'єднання, ніж може бути оброблено за допомогою резервного пакета, черги введення для резервного введення заповнюються до тих пір, поки більше ніяких з'єднань не може бути прийнято. Коли це станеться, відповідні черги виводу Apache починають заповнюватися. Коли черги заповнені, Apache кидає 503. Звідси випливає, що те ж саме може статися, коли Apache є резервним, і фронтенд подає з такою швидкістю, щоб змусити черги заповнюватися.

Рішення (гіпотетичне) полягає в розмірі вхідних з'єднувачів резервного та вихідного з'єднувачів фронтенду. Це перетворюється на акт балансування між передбачуваним рівнем затоплення та доступною оперативною пам’яттю задіяних комп'ютерів.

Отже, як це відбувається, перевірте свої параметри maxclients і стежте за своїми зайнятими працівниками в Apache (mod_status.). Зробіть те саме, якщо можливо, з тим, що має ELB, що відповідає відставанню роз'єму Tomcats, maxthreads тощо. Коротше, подивіться все, що стосується вхідних черг Apache та вихідних черг ELB.

Хоча я повністю розумію, що це не застосовується безпосередньо, це посилання містить посібник щодо розмірів роз'єму Apache. Вам потрібно буде вивчити відповідні технічні характеристики черги ELB, а потім зробити математику: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- повний gc /

Як зазначається в коментарі нижче, перекрити роз'єм Apache шипом у трафіку - не єдина можливість. Якщо деякі запити подаються повільніше, ніж інші, більш високе співвідношення цих запитів також може призвести до заповнення черг на роз'єми. Це було правдою в моєму випадку.

Крім того, коли це трапилося зі мною, я був збентежений тим, що мені довелося перезапустити службу Apache, щоб знову не отримати сервіс 503: s. Просто очікування затоплення роз'єму було недостатньо. Я ніколи цього не з'ясував, але, можливо, можна міркувати в Apache, який подає з кешу?

Після збільшення кількості робітників та відповідних параметрів maxclients pre-fork (це був багатопотоковий Apache в Windows, який має декілька інших директив щодо черг, якщо я правильно пам’ятаю), проблема 503 зникла. Я насправді не займався математикою, а просто підганяв значення, поки не міг спостерігати широкий запас максимального споживання ресурсів черги. Я це відпустив.

Сподіваюся, що це допомогло.

Ви можете збільшити значення перевірки здоров’я ліктя, так як одна повільна реакція не зможе витягнути сервер з локтя. краще, щоб декілька користувачів отримували послугу недоступною, ніж веб-сайт для всіх.

EDIT: Ми можемо піти без попереднього прогрівання кешу, збільшивши час очікування перевірки стану здоров’я до 25 секунд ...... через 1-2 хвилини ... сайт реагує на пекло

EDIT :: просто запустіть купу на вимогу, і коли ваші інструменти моніторингу показують, наскільки швидко ви керуєте, тоді просто передоплачуйте RI amazon: P

EDIT: можливо, одного екземпляра, зареєстрованого локальним сервером, недостатньо. просто запустіть ще декілька і зареєструйте їх на лікті, і це допоможе вам звузити проблему

На кілька років пізно, але, сподіваємось, це комусь допоможе.

Я бачив цю помилку, коли екземпляру за ELB не було призначено належного загальнодоступного IP-адреси. Мені потрібно було вручну створити Elastic IP та пов’язати його з екземпляром, після якого ELB підняв його майже миттєво.