Làm cách nào tôi có thể triển khai cụm haproxy đáng tin cậy có thể mở rộng trên Amazon EC2?


25

Chúng tôi cần một số chức năng nâng cao hơn ELB cung cấp (chủ yếu là kiểm tra L7), nhưng không rõ ràng làm thế nào để xử lý những thứ như nhịp tim và tính sẵn sàng cao với thứ gì đó như haproxy bằng EC2. Có khả năng cao là chúng ta cần 3 nút haproxy trở lên trong cụm, vì vậy nhịp tim đơn giản giữa hai nút sẽ không hoạt động.

Có vẻ như có một lớp nhịp tim ở phía trước các nút haproxy sẽ là cách để sử dụng, có thể sử dụng IPVS, nhưng xử lý các thay đổi cấu hình khi cụm EC2 thay đổi (thông qua thay đổi có chủ ý, như mở rộng hoặc vô ý, như mất một Nút EC2) có vẻ không tầm thường.

Tốt nhất là giải pháp sẽ kéo dài ít nhất hai Vùng sẵn có.

Trả lời Qs: Không, phiên không dính. Và vâng, chúng tôi sẽ cần SSL, nhưng về mặt lý thuyết có thể được xử lý hoàn toàn bởi một thiết lập khác - chúng tôi có thể hướng lưu lượng SSL đến một vị trí khác với lưu lượng không phải SSL.


Tôi đang nghiên cứu cách làm chim hoàng yến triển khai với tỷ lệ lưu lượng truy cập tăng dần đến phiên bản mới của phần mềm và tôi cực kỳ tò mò về nơi bạn đã kết thúc việc này. Cuối cùng bạn đã thử bất kỳ lời đề nghị nào của Jesper chưa?
Iain

Câu trả lời:


14

OK, tôi chưa bao giờ tự mình xây dựng giải pháp cân bằng tải AWS với lưu lượng trên các cấp độ của SmugMug, nhưng chỉ nghĩ về lý thuyết và dịch vụ của AWS, một vài ý tưởng nảy ra trong đầu.

Câu hỏi ban đầu thiếu một vài điều có xu hướng ảnh hưởng đến thiết kế cân bằng tải:

  1. Phiên dính hay không? Tốt nhất là không sử dụng phiên dính và chỉ để tất cả các bộ cân bằng tải (LB) sử dụng vòng tròn (RR) hoặc lựa chọn phụ trợ ngẫu nhiên. RR hoặc các lựa chọn phụ trợ ngẫu nhiên là đơn giản, có thể mở rộng và cung cấp phân phối tải đều trong mọi trường hợp.
  2. SSL hay không? Cho dù SSL có được sử dụng hay không, và bao nhiêu phần trăm yêu cầu, thường có tác động đến thiết kế cân bằng tải. Thông thường nên chấm dứt SSL càng sớm càng tốt, để đơn giản hóa việc xử lý chứng chỉ và giữ cho CPU SSL tải khỏi máy chủ ứng dụng web.

Tôi đang trả lời từ góc độ làm thế nào để giữ cho lớp cân bằng tải có sẵn cao. Giữ các máy chủ ứng dụng HA chỉ được thực hiện với các kiểm tra sức khỏe được tích hợp trong bộ cân bằng tải L7 của bạn.

OK, một vài ý tưởng nên hoạt động:

1) "Cách AWS":

  • Lớp đầu tiên, ở phía trước, sử dụng ELB ở chế độ L4 (TCP / IP).
  • Lớp thứ hai, sử dụng các thể hiện EC2 với bộ cân bằng tải L7 của bạn (nginx, HAProxy, Apache, v.v.).

Lợi ích / ý tưởng: Bộ cân bằng tải L7 có thể khá đơn giản EC2 AMI, tất cả được nhân bản từ cùng một AMI và sử dụng cùng một cấu hình. Do đó, các công cụ của Amazon có thể xử lý tất cả các nhu cầu HA: ELB giám sát các bộ cân bằng tải L7. Nếu L7 LB chết hoặc không phản hồi, ELB & Cloudwatch sẽ tự động sinh ra một thể hiện mới và đưa nó vào nhóm ELB.

2) "Vòng tròn DNS với cách theo dõi:"

  • Sử dụng robin vòng DNS cơ bản để có được phân phối tải trọng thô trên một vài địa chỉ IP. Giả sử bạn xuất bản 3 địa chỉ IP cho trang web của bạn.
  • Mỗi trong số 3 IP này là một Địa chỉ IP đàn hồi AWS (EIA), được liên kết với một thể hiện EC2, với bộ cân bằng tải L7 mà bạn chọn.
  • Nếu EC2 L7 LB chết, tác nhân người dùng (trình duyệt) tuân thủ chỉ nên sử dụng một trong các IP khác thay thế.
  • Thiết lập một máy chủ giám sát bên ngoài. Giám sát từng 3 EIP. Nếu một người không phản hồi, hãy sử dụng các công cụ dòng lệnh của AWS và một số tập lệnh để chuyển EIP sang phiên bản EC2 khác.

Lợi ích / ý tưởng: Các tác nhân người dùng tuân thủ sẽ tự động chuyển sang địa chỉ IP khác nếu một địa chỉ không phản hồi. Do đó, trong trường hợp thất bại, chỉ có 1/3 người dùng của bạn sẽ bị ảnh hưởng và hầu hết những người này không nên chú ý bất cứ điều gì vì UA của họ âm thầm thất bại trước một IP khác. Và hộp giám sát bên ngoài của bạn sẽ nhận thấy rằng EIP không phản hồi và khắc phục tình trạng này trong vài phút.

3) DNS RR tới các cặp máy chủ HA:

Về cơ bản, đây là gợi ý riêng của Don về nhịp tim đơn giản giữa một cặp máy chủ, nhưng được đơn giản hóa cho nhiều địa chỉ IP.

  • Sử dụng DNS RR, xuất bản một số địa chỉ IP cho dịch vụ. Theo ví dụ trên, giả sử bạn xuất bản 3 IP.
  • Mỗi IP này đi đến một cặp máy chủ EC2, do đó tổng cộng có 6 trường hợp EC2.
  • Mỗi cặp này sử dụng Heartbeat hoặc một giải pháp HA khác cùng với các công cụ AWS để giữ cho 1 địa chỉ IP tồn tại, trong cấu hình hoạt động / thụ động.
  • Mỗi phiên bản EC2 có cài đặt cân bằng tải L7 của bạn.

Lợi ích / ý tưởng: Trong môi trường ảo hóa hoàn toàn của AWS, thực sự không dễ để lý giải về các dịch vụ L4 và chế độ chuyển đổi dự phòng. Bằng cách đơn giản hóa một cặp máy chủ giống hệt nhau chỉ giữ 1 địa chỉ IP, việc kiểm tra và kiểm tra trở nên đơn giản hơn.

Kết luận: Một lần nữa, tôi chưa thực sự thử bất kỳ thứ gì trong sản xuất. Chỉ từ cảm nhận của tôi, tùy chọn một với ELB ở chế độ L4 và các phiên bản EC2 tự quản lý vì L7 LB dường như phù hợp nhất với tinh thần của nền tảng AWS và là nơi Amazon có khả năng đầu tư và mở rộng sau này. Đây có lẽ sẽ là lựa chọn đầu tiên của tôi.


1
Vì vậy, tôi thích cách tiếp cận số 1, đó là hướng mà tôi đã nghiêng, nhưng vẫn còn một số vấn đề thú vị - không phải là ít nhất là ELB không xử lý toàn bộ AZ thất bại rất tốt (điều chúng tôi đã xảy ra ). "Giải pháp" dễ dàng, nhưng không may mắn là phải có các haproxies phía sau ELB được cấu hình để vượt qua AZ (có thể có một cụm sao lưu trong một AZ khác) vì vậy nếu có ít nhất một haproxy trong mỗi AZ, chúng ta sẽ ổn. Nhưng điều đó chỉ bắt chước, không loại bỏ vấn đề. Bất kỳ ý tưởng xung quanh vấn đề này?
Don MacAskill

@Don MacAskill: Tôi biết AWS đã có một vài thời gian ngừng dịch vụ quy mô lớn, nhưng làm tốt hơn độ tin cậy của AZ trên AWS là khó. Chuyển sang hoạt động đa AZ của frontend có thể dễ dàng là bước đầu tiên hướng tới hoạt động đa AZ của toàn bộ stack, và đó là toàn bộ ấm đun nước của rắn ...
Jesper M

@Don MacAskill: Một tùy chọn sẽ là độ phân giải DNS nhận biết địa lý như DynDNS Dynect -> ELB + L7 LB bên trong một AZ, với ELB + L7 khác ở chế độ chờ nóng trong AZ khác. (Bên cạnh nhận thức về địa lý, Dynect cũng có một số kiểm tra sức khỏe.) DynDNS có một hồ sơ theo dõi tuyệt vời về thời gian hoạt động, nhưng ngay cả như vậy, việc thêm DNS nhận biết địa lý là một SPOF khác. Việc Dynect + cân bằng tải trong 2 AZ có thời gian hoạt động dài hạn tốt hơn so với chỉ một AWS AZ không rõ ràng đối với tôi. Xem phần này để biết tổng quan về ý nghĩa của tôi, tìm kiếm cơ sở dữ liệu đa AZ: dev.bizo.com/2010/05/improving-global-application.html
Jesper M

@Don MacAskill: Chỉ một điều cuối cùng - hãy nhớ rằng một trường hợp ELB duy nhất có thể trải rộng trên nhiều AZ. Nó không thể trải dài trên các khu vực EC2 . Nhưng nếu chỉ sử dụng ELB đến L7 LB ở hai AZ trong cùng một khu vực thì có thể chấp nhận được, điều này sẽ đơn giản nhất ... Bạn đã viết "ELB không xử lý toàn bộ AZ thất bại rất tốt", có lẽ bạn đã biết nhiều hơn Tôi làm.
Jesper M

Vâng, nếu ELB kéo dài nhiều AZ và gặp một số lỗi mà nó không thể xảy ra với bất kỳ nút phụ trợ nào trong AZ (chúng bị quá tải, xuống, trả về 503, bất cứ điều gì), người dùng cuối sẽ thấy những lỗi đó - đó không phải là ' t lại tuyến đường đến AZ (s) khác. Tôi hy vọng đó là kế hoạch, nhưng nó đã cắn chúng tôi một lần rồi.
Don MacAskill

2

Nếu bạn không thực hiện các phiên dính hoặc nếu bạn đang sử dụng kiểu tomcat / apache (nối ID nút vào sessionid, trái ngược với trạng thái lưu trữ trong LB), thì tôi sẽ sử dụng ELB trước một nhóm các haproxies. ELB có một kiểm tra sức khỏe được tích hợp sẵn, vì vậy bạn có thể yêu cầu nó theo dõi các haproxies và đưa bất kỳ con nào ra khỏi bể bơi. Rất ít để thiết lập hơn failover heartbeat.

Theo như tuyên truyền thay đổi, tôi không có câu trả lời tuyệt vời. Con rối rất tốt cho cấu hình ban đầu và thực hiện các thay đổi, nhưng để thêm / xóa các nút, bạn có xu hướng muốn phản hồi nhanh hơn khoảng thời gian bỏ phiếu 30 phút của nó.


1
Đó là một giải pháp tốt (và một câu hỏi hay!) Bạn có thể sử dụng Amazon SNS để tuyên truyền thay đổi cấu hình theo kiểu đẩy. Bạn cần một hệ thống thông báo để thêm / xóa các nút khỏi cấu hình haproxy.
Rafiq Maniar

Một tùy chọn khác để quản lý các máy chủ phụ trợ (những máy chủ mà haproxy đang chuyển tiếp) là để mỗi máy chủ phụ trợ gửi tất cả các haproxies hoặc máy chủ cấu hình, đăng ký định kỳ (30 giây hoặc lâu hơn). Nếu một người chết, nó sẽ không được đăng ký nhanh chóng (và haproxy nên chú ý bằng mọi cách); nếu một cái mới xuất hiện, nó sẽ tự động được đưa vào vòng quay. Đây rõ ràng là những gì Netflix làm.
Ben Jencks

1

Tôi đã không sử dụng nó cho mình nhưng tôi đã thấy rất nhiều người đề cập đến việc sử dụng con rối để xử lý các loại vấn đề này trên EC2


Vâng, Puppet trên EC2 làm cho việc quản lý một cụm khá đơn giản. Chỉ cần tạo một cá thể vi mô và sử dụng nó như con rối của bạn.
Tom O'Connor

1
Chúng tôi sử dụng con rối trong các trung tâm dữ liệu của mình, nhưng chưa thử trên EC2. Con rối có nhận biết EC2 bằng cách nào đó, để nó có thể tìm thấy các nút bằng cách sử dụng mô tả ec2 hoặc một cái gì đó và tự động cấu hình / cấu hình lại dựa trên đầu ra đó không? Và làm thế nào bạn sẽ xử lý con rối đi đột ngột?
Don MacAskill

Tại sao nó sẽ biến mất đột ngột?
Tom O'Connor

Nó không nhận biết EC2, nhưng bạn có thể thiết lập nó để các nút mới sẽ được đánh dấu để ký khi bạn khởi động chúng và sử dụng tập lệnh nút bên ngoài để mô tả chúng. Tôi đã viết một số python để làm điều này với SimpleDB (các nút bên ngoài) và SQS (hàng đợi yêu cầu ký cho các nút mới); một nhà phát triển Ubuntu đã viết các tập lệnh bằng S3: ubuntumathiaz.wordpress.com/2010/04/07/ trên
Ben Jencks

Nếu con rối biến mất đột ngột, nó sẽ không chạy bảng kê khai, tức là nó rời khỏi các nút ở bất kỳ trạng thái nào chúng đang ở.
Ben Jencks
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.