Od około dwóch lat prowadzimy kilka stron internetowych przy infrastrukturze Amazons AWS i od około dwóch dni serwer przestał działać raz lub dwa razy dziennie z jedynym błędem, jaki mogę znaleźć:
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
CloudWatch nie uruchamia żadnych alarmów (CPU / Disk IO / DB Conn). Próbowałem wejść na stronę za pomocą elastycznego adresu IP, aby pominąć ELB i otrzymałem:
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.
Nie widzę nic niezwykłego w dziennikach apache i zweryfikowałem, że były one odpowiednio obracane. Nie mam problemów z dostępem do komputera, gdy jest on „wyłączony” przez SSH i patrząc na listę procesów widzę 151 procesów apache2, które wydają mi się normalne. Ponowne uruchomienie apache tymczasowo rozwiązuje problem. Ta maszyna działa jak serwer sieciowy za ELB. Wszelkie sugestie będą mile widziane.
Średnie wykorzystanie procesora: 7,45%, minimum: 0,00%, maksimum: 25,82%
Średnia wykorzystanie pamięci: 11,04%, minimum: 8,76%, maksimum: 13,84%
Średnia wykorzystania wymiany: nie dotyczy, minimum: nie dotyczy, maksimum: nie dotyczy
Wykorzystanie miejsca na dysku dla / dev / xvda1 zamontowane na / Średnia: 62,18%, Minimalna: 53,39%, Maksymalna: 65,49%
Pozwól mi wyjaśnić, że myślę, że problem dotyczy indywidualnej instancji EC2, a nie ELB. Po prostu nie chciałem tego wykluczyć, mimo że nie byłem w stanie osiągnąć elastycznego adresu IP. Podejrzewam, że ELB zwraca wyniki trafienia w rzeczywistą instancję EC2.
Aktualizacja: 2014-08-26 Powinienem był to zaktualizować wcześniej, ale „poprawka” polegała na zrobieniu migawki „złej” instancji i uruchomieniu wynikowego AMI. Od tego czasu nie spadł. Patrzyłem na sprawdzanie kondycji, kiedy wciąż miałem problemy i mogłem przejść do strony sprawdzania kondycji ( curl http://localhost/page.html), nawet gdy otrzymywałem problemy z pojemnością z modułu równoważenia obciążenia. Nie jestem przekonany, że to był problem z kontrolą zdrowia, ale ponieważ nikt, w tym Amazon, nie może udzielić lepszej odpowiedzi, zaznaczam to jako odpowiedź. Dziękuję Ci.
Aktualizacja: 2015-05-06 Myślałem, że wrócę tutaj i powiem, że częścią problemu, który teraz mocno wierzę, były ustawienia kontroli zdrowia. Nie chcę wykluczyć, że są problemem z AMI, ponieważ zdecydowanie poprawiło się po uruchomieniu zastępczego AMI, ale dowiedziałem się, że nasze testy kondycji były różne dla każdego modułu równoważenia obciążenia i że ten, który miał najwięcej problemów miał naprawdę agresywny niezdrowy próg i limit czasu reakcji. Nasz ruch ma tendencję do gwałtownego wzrostu i myślę, że między agresywnymi ustawieniami kontroli zdrowia a skokami ruchu był to idealny sztorm.
Odpowiedzi:
Otrzymasz komunikat „Serwer zaplecza ma pojemność”, gdy moduł równoważenia obciążenia ELB wykonuje kontrole kondycji i otrzymuje komunikat „Nie znaleziono strony” (lub inny prosty błąd) z powodu nieprawidłowej konfiguracji (zwykle z hostem NameVirtual).
Spróbuj grep folderu plików dziennika za pomocą agenta użytkownika „ELB-HealthChecker”. na przykład
Zazwyczaj daje to błąd 4x lub 5x, który można łatwo naprawić. np. powódź, MaxClients itp. przypisuje problemowi zbyt wiele uznania.
FYI Amazon: Dlaczego nie pokazać zwróconej odpowiedzi z żądania? Pomógłby nawet kod stanu.
źródło
Właśnie wpadłem na ten problem. Amazon ELB zwróci ten błąd, jeśli nie będzie żadnych zdrowych instancji. Nasze witryny zostały źle skonfigurowane, więc sprawdzenie poprawności ELB nie powiodło się, co spowodowało, że ELB wyłączył oba serwery z obrotu. Przy zerowych zdrowych witrynach ELB zwróciło usługę 503 Niedostępna: serwer zaplecza ma pełną pojemność.
źródło
[EDYCJA po lepszym zrozumieniu pytania] Nie mając doświadczenia z ELB, nadal myślę, że brzmi to podejrzanie jak błąd 503, który może zostać wyrzucony, gdy Apache stawi czoło Tomcatowi i zaleje połączenie.
Skutkuje to tym, że jeśli Apache dostarcza więcej żądań połączeń, niż może to przetworzyć backend, kolejki wejściowe backendu zapełniają się, dopóki nie będzie można zaakceptować więcej połączeń. Kiedy tak się dzieje, odpowiednie kolejki wyjściowe Apache zaczynają się zapełniać. Gdy kolejki są pełne, Apache rzuca 503. Z tego wynika, że to samo może się zdarzyć, gdy Apache jest backendem, a frontend dostarcza z taką szybkością, że kolejki się zapełniają.
(Hipotetyczne) rozwiązanie polega na zmianie rozmiaru złączy wejściowych backendu i złączy wyjściowych frontendu. To zmienia się w równowagę między przewidywanym poziomem powodzi a dostępną pamięcią RAM zaangażowanych komputerów.
Gdy tak się stanie, sprawdź ustawienia maxclients i monitoruj zajętych pracowników w Apache (mod_status.). Zrób to samo, jeśli to możliwe, z tym, co ma ELB, co odpowiada zaległościom złącza Tomcats, maksymalnym wątkom itp. Krótko mówiąc, spójrz na wszystko dotyczące kolejek wejściowych Apache i kolejek wyjściowych ELB.
Chociaż w pełni rozumiem, że nie ma to bezpośredniego zastosowania, ten link zawiera przewodnik dotyczący zmiany rozmiaru złącza Apache. Musisz zbadać odpowiednie dane techniczne kolejki ELB, a następnie wykonać obliczenia matematyczne: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- pełny gc /
Jak zauważono w komentarzu poniżej, aby przytłoczyć złącze Apache, skok ruchu nie jest jedyną możliwością. Jeśli niektóre żądania są obsługiwane wolniej niż inne, wyższy ich stosunek może również prowadzić do zapełnienia kolejek konektora. Tak było w moim przypadku.
Ponadto, gdy mi się to przydarzyło, zdziwiło mnie, że musiałem ponownie uruchomić usługę Apache, aby ponownie nie otrzymać 503: s. Samo czekanie na zalanie złącza nie wystarczyło. Nigdy tego nie rozgryzłem, ale można spekulować na temat serwowania Apache z jego pamięci podręcznej?
Po zwiększeniu liczby pracowników i odpowiadających im ustawień maksymalnych klientów przed rozwidleniem (był to wielowątkowy Apache w systemie Windows, który ma kilka innych dyrektyw dla kolejek, jeśli dobrze pamiętam), problem 503 zniknął. Właściwie nie zrobiłem matematyki, ale po prostu poprawiłem wartości, aż mogłem zaobserwować szeroki margines szczytowego zużycia zasobów kolejki. Puściłem to.
Mam nadzieję, że to pomogło.
źródło
możesz podnieść wartości sprawdzania kondycji łokcia, aby pojedyncza wolna odpowiedź nie wyciągała serwera z łokcia. lepiej, aby kilku użytkowników było niedostępnych dla tej usługi, niż że strona jest niedostępna dla wszystkich.
EDYCJA: Jesteśmy w stanie uciec bez podgrzewania pamięci podręcznej, zwiększając limit czasu testu stanu zdrowia do 25 sekund ...... po 1-2 minutach ... strona reaguje jak diabli
EDYCJA :: po prostu uruchom kilka na żądanie, a gdy twoje narzędzia monitorowania pokażą zarządzanie, jak szybko jesteś, to po prostu przedpłać RI amazon: P
EDYCJA: jest możliwe, pojedyncza zarejestrowana instancja elb zaplecza nie wystarczy. po prostu uruchom kilka kolejnych i zarejestruj je w elb, a to pomoże ci zawęzić problem
źródło
Jest kilka lat spóźnienia, ale mam nadzieję, że to komuś pomoże.
Widziałem ten błąd, gdy do instancji ELB nie przypisano odpowiedniego publicznego adresu IP. Musiałem ręcznie utworzyć elastyczny adres IP i powiązać go z instancją, po czym ELB odebrał go niemal natychmiast.
źródło