Dịch vụ AWS ELB Apache2 503 Không khả dụng: Máy chủ phụ trợ đang hoạt động

Chúng tôi đã chạy một vài trang web ngoài cơ sở hạ tầng Amazons AWS trong khoảng hai năm nay và khoảng hai ngày trước, máy chủ web bắt đầu ngừng hoạt động một hoặc hai lần một ngày với lỗi duy nhất tôi có thể tìm thấy:

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

Không có báo động (CPU / Đĩa IO / DB Conn) đang được CloudWatch kích hoạt. Tôi đã thử truy cập trang web thông qua IP đàn hồi để bỏ qua ELB và nhận được điều này:

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

Tôi không thấy bất cứ điều gì khác thường trong nhật ký apache và xác minh rằng chúng đang được xoay đúng. Tôi không gặp vấn đề gì khi truy cập vào máy khi nó "xuống" thông qua SSH và nhìn vào danh sách quy trình tôi thấy 151 quy trình apache2 xuất hiện bình thường đối với tôi. Khởi động lại apache tạm thời khắc phục vấn đề. Máy này hoạt động như một máy chủ web đằng sau ELB. Bất kỳ đề xuất sẽ được đánh giá rất cao.

Trung bình sử dụng CPU: 7,45%, tối thiểu: 0,00%, tối đa: 25,82%

Sử dụng bộ nhớ Trung bình: 11,04%, Tối thiểu: 8,76%, Tối đa: 13,84%

Hoán đổi trung bình sử dụng: Không áp dụng, Tối thiểu: Không áp dụng, Tối đa: Không áp dụng

Sử dụng không gian đĩa cho / dev / xvda1 được gắn trên / Trung bình: 62,18%, Tối thiểu: 53,39%, Tối đa: 65,49%

Hãy để tôi làm rõ Tôi nghĩ rằng vấn đề là do cá thể EC2 chứ không phải ELB tôi chỉ không muốn loại trừ mặc dù tôi không thể truy cập IP đàn hồi. Tôi nghi ngờ ELB chỉ trả về kết quả đánh vào thể hiện EC2 thực tế.

Cập nhật: 2014-08-26 Tôi nên cập nhật điều này sớm hơn nhưng "cách khắc phục" là chụp nhanh ví dụ "xấu" và bắt đầu AMI kết quả. Nó đã không đi xuống kể từ đó. Tôi đã xem xét kiểm tra sức khỏe khi tôi vẫn gặp vấn đề và có thể vào trang kiểm tra sức khỏe ( curl http://localhost/page.html) ngay cả khi tôi gặp vấn đề về năng lực từ bộ cân bằng tải. Tôi không tin đó là vấn đề kiểm tra sức khỏe nhưng vì không ai, kể cả Amazon, có thể cung cấp câu trả lời tốt hơn nên tôi đánh dấu nó là câu trả lời. Cảm ơn bạn.

Cập nhật: 2015-05-06 Tôi nghĩ rằng tôi sẽ quay lại đây và nói rằng một phần của vấn đề mà bây giờ tôi tin chắc là cài đặt kiểm tra sức khỏe. Tôi không muốn loại trừ sự cố của họ với AMI vì nó chắc chắn đã tốt hơn sau khi AMI thay thế được đưa ra nhưng tôi phát hiện ra rằng kiểm tra sức khỏe của chúng tôi là khác nhau đối với mỗi bộ cân bằng tải và là vấn đề gặp nhiều rắc rối nhất đã có một ngưỡng thực sự không lành mạnh và thời gian chờ phản hồi. Lưu lượng truy cập của chúng tôi có xu hướng tăng đột biến và tôi nghĩ giữa các thiết lập kiểm tra sức khỏe tích cực và tăng đột biến trong giao thông, đó là một cơn bão hoàn hảo.

Bạn sẽ nhận được "Máy chủ phụ có dung lượng" khi bộ cân bằng tải ELB thực hiện kiểm tra sức khỏe và nhận được "trang không tìm thấy" (hoặc lỗi đơn giản khác) do cấu hình sai (thường là với máy chủ NameVirtual).

Hãy thử lấy thư mục tệp nhật ký bằng tác nhân người dùng "ELB-HealthChecker". ví dụ

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

Điều này thường sẽ cung cấp cho bạn một lỗi 4x hoặc 5x dễ dàng sửa chữa. ví dụ như Flooding, MaxCl Client v.v ... đang cho vấn đề quá nhiều tín dụng.

FYI Amazon: Tại sao không hiển thị phản hồi trả về từ yêu cầu? Ngay cả một mã trạng thái sẽ giúp.

Tôi chỉ chạy vào vấn đề này bản thân mình. Amazon ELB sẽ trả lại lỗi này nếu không có trường hợp lành mạnh. Các trang web của chúng tôi đã bị định cấu hình sai, do đó, kiểm tra sức khỏe ELB không thành công, điều này khiến ELB phải đưa hai máy chủ ra khỏi vòng quay. Với các trang web không có sức khỏe, ELB đã trả về 503 Dịch vụ không khả dụng: Máy chủ back-end đang hoạt động.

[EDIT sau khi hiểu rõ hơn về câu hỏi] Không có bất kỳ kinh nghiệm nào về ELB, tôi vẫn nghĩ rằng điều này nghe có vẻ đáng ngờ giống như lỗi 503 có thể bị ném khi Apache đối mặt với Tomcat và làm ngập kết nối.

Hiệu quả là nếu Apache cung cấp nhiều yêu cầu kết nối hơn mức có thể được xử lý bởi phụ trợ, thì hàng đợi đầu vào phụ trợ sẽ lấp đầy cho đến khi không thể chấp nhận thêm kết nối. Khi điều đó xảy ra, hàng đợi đầu ra tương ứng của Apache bắt đầu lấp đầy. Khi hàng đợi đầy đủ, Apache sẽ ném 503. Điều đó sẽ xảy ra tương tự khi Apache là phụ trợ và giao diện sẽ cung cấp với tốc độ như vậy để làm cho hàng đợi được lấp đầy.

Giải pháp (giả thuyết) là định cỡ các đầu nối đầu vào của đầu nối phụ và đầu ra của giao diện. Điều này biến thành một hành động cân bằng giữa mức độ ngập dự kiến ​​và RAM có sẵn của các máy tính liên quan.

Vì vậy, khi điều này xảy ra, hãy kiểm tra cài đặt tối đa của bạn và theo dõi các nhân viên bận rộn của bạn trong Apache (mod_status.). Làm tương tự nếu có thể với bất cứ thứ gì ELB có tương ứng với backlog của trình kết nối Tomcats, maxthreads, v.v. Tóm lại, hãy xem mọi thứ liên quan đến hàng đợi đầu vào của Apache và hàng đợi đầu ra của ELB.

Mặc dù tôi hoàn toàn hiểu rằng nó không thể áp dụng trực tiếp, liên kết này chứa một hướng dẫn định cỡ cho trình kết nối Apache. Bạn sẽ cần nghiên cứu các kỹ thuật xếp hàng ELB tương ứng, sau đó thực hiện phép toán: http://www.cubrid.org/blog/dev-pl platform / maxclents-in-apache-and-it-eectect-on-tomcat-during- đầy đủ gc /

Theo quan sát trong phần bình luận bên dưới, để áp đảo trình kết nối Apache, lưu lượng truy cập tăng đột biến không phải là khả năng duy nhất. Nếu một số yêu cầu được phục vụ chậm hơn các yêu cầu khác, tỷ lệ cao hơn cũng có thể dẫn đến hàng đợi kết nối được lấp đầy. Điều này đúng trong trường hợp của tôi.

Ngoài ra, khi điều này xảy ra với tôi, tôi đã gặp khó khăn rằng tôi phải khởi động lại dịch vụ Apache để không được phục vụ 503: s nữa. Chỉ đơn giản là chờ đợi lũ lụt kết nối là không đủ. Tôi chưa bao giờ hiểu được điều đó, nhưng người ta có thể suy đoán về việc phục vụ Apache từ bộ đệm của nó có lẽ?

Sau khi tăng số lượng công nhân và các cài đặt tối đa trước ngã ba tương ứng (đây là Apache đa luồng trên Windows có một vài chỉ thị khác cho hàng đợi nếu tôi nhớ chính xác), vấn đề 503 đã biến mất. Tôi thực sự đã không làm toán, nhưng chỉ điều chỉnh các giá trị cho đến khi tôi có thể quan sát được mức chênh lệch lớn đến mức tiêu thụ cao nhất của tài nguyên hàng đợi. Tôi để nó đi ở đó.

Hy vọng điều này đã giúp đỡ một số.

bạn có thể tăng các giá trị của trình kiểm tra sức khỏe elb, do đó, một phản hồi chậm sẽ không kéo máy chủ khỏi khuỷu tay. tốt hơn là có một vài người dùng nhận được dịch vụ không có sẵn, hơn là trang web bị sập cho tất cả mọi người.

EDIT: Chúng tôi có thể thoát khỏi mà không cần làm nóng bộ đệm trước bằng cách tăng thời gian kiểm tra sức khỏe lên 25 giây ...... sau 1-2 phút ... trang web phản hồi nhanh như địa ngục

EDIT :: chỉ cần khởi chạy một loạt các yêu cầu và khi các công cụ giám sát của bạn cho thấy quản lý của bạn nhanh như thế nào, thì hãy trả trước RI amazon: P

EDIT: có thể, một ví dụ đăng ký elb phụ trợ là không đủ. chỉ cần khởi chạy thêm một chút và đăng ký chúng với khuỷu tay, và điều đó sẽ giúp bạn thu hẹp vấn đề của mình

Đã trễ vài năm, nhưng hy vọng điều này sẽ giúp được ai đó.

Tôi đã gặp lỗi này khi trường hợp đằng sau ELB không được gán IP công cộng phù hợp. Tôi cần phải tự tạo một IP đàn hồi và liên kết nó với thể hiện sau thời điểm ELB nhặt nó gần như ngay lập tức.