Lỗi đơn lẻ trên ứng dụng mở rộng trên AWS

Question

Chúng tôi có ứng dụng dựa trên đường ray, cơ sở hạ tầng triển khai liên kết với AWS. schema hiện tại bao gồm các lớp sau:

• cân bằng tải (HAProxy)
• Rails ứng dụng (EC2) x2
cơ sở dữ liệu
• mysqld (EC2 master-slave)
• Redis, nền DelayedJob xử lý
• Máy chủ media Wowza (EC2)
• Lưu trữ tài sản S3 (dữ liệu được chia sẻ)

Có 3 SPF: cân bằng tải, cơ sở dữ liệu, máy chủ phương tiện.

Câu hỏi của tôi là về dư thừa, làm thế nào tôi có thể giảm SPF:

1. cân bằng tải. Chúng tôi có kế hoạch thiết lập cân bằng tải phụ, nhưng tên miền vẫn như cũ. Có phải Lỗi chuyển đổi vòng xoay DNS A/AAAA trong trường hợp đó không? AWS có cân bằng tải tốt để sử dụng không?
2. Có phải MMM (Trình quản lý sao chép đa chủ) có đáng tin cậy không? Làm thế nào nó làm việc với Rails (đọc/ghi vào máy chủ độc lập)?
3. Máy chủ phương tiện Wowza, có bất kỳ giải pháp HA nổi tiếng nào để hợp tác không?

Answer 1

Tôi thích những câu hỏi này vì chúng luôn có vẻ đơn giản để trả lời khi thực tế là không.

Để bắt đầu, BIGGEST SPF của bạn là mọi thứ đều có trên Amazon. Tôi yêu AWS vì nhiều lý do, nhưng trong mọi tình huống mà bạn cần sự sẵn có thực sự, bạn chủ yếu tự bắn mình bằng cách dựa vào chúng 100%. Vì vậy, kế hoạch đầu tiên của bạn nên là phân phối dịch vụ của bạn cho hơn 1 nhà cung cấp (đám mây, VPS hoặc chuyên dụng).

Tôi muốn hỏi bạn một câu hỏi: nếu AWS đi xuống, bạn có thể chú ý và sau đó làm điều gì đó và bạn cần các dịch vụ của mình để sao lưu và chạy nhanh trong bao lâu ? Lý do tôi hỏi là: DNS cân bằng tải của A/AAAA hồ sơ là một giải pháp tuyệt vời, tiếc là bạn không thể thiết lập trọng lượng hoặc ưu tiên như bạn có thể với các bản ghi SRV/MX. Điều này có nghĩa là nếu AWS hoàn toàn không khả dụng, bạn sẽ phải thực hiện thay đổi DNS thật nhanh chóng để xóa IP. Điều đó CÓ THỂ được tự động nếu nhà cung cấp DNS của bạn có API cho phép điều đó. Mặt khác, DNS caching được thực hiện ở rất nhiều nơi có thể không đáng để thay đổi DNS, nghĩa là bạn sẽ có sẵn từ 50% đến 100% nếu 1 IP không khả dụng (giả sử bạn có 2 bản ghi A), bởi vì một số trình duyệt có thể thử IP thứ hai nếu số 1 không hoạt động.

Theo tôi, xem xét thời gian hoạt động tuyệt vời của AWS, bạn sẽ không có lỗi khi chỉ định 2 IP khác nhau (trên 2 nhà cung cấp khác nhau) cho miền của bạn. Tôi nghĩ rằng nó tốt hơn là có sẵn 0% khi 1 IP bị hỏng, nhưng vẫn không có niềm vui khi mất 50% yêu cầu của bạn.

Bạn có thể có 2 bộ cân bằng tải trên mỗi nhà cung cấp và cho phép chúng chuyển tiếp yêu cầu tới nhà cung cấp khác nếu các trường hợp/máy chủ nhất định bị hỏng. Nói cách khác, bạn chỉ cần các chức năng cân bằng tải tại các nhà cung cấp BOTH và các máy chủ/trường hợp chức năng tại nhà cung cấp ONE. Đảm bảo chọn nhà cung cấp thay thế không có quá nhiều thời gian chờ AWS;)

MMM cũng là một công cụ tuyệt vời, nhưng nó không liên quan đến Rails theo bất kỳ cách nào. Cá nhân tôi thích đặt cân bằng tải ở phía trước tất cả các máy chủ cơ sở dữ liệu của mình và cho phép họ xử lý những người nhận yêu cầu, v.v. Vì dữ liệu trên máy chủ cơ sở dữ liệu rất quan trọng, nên tốt hơn là hãy xem xét và đảm bảo mọi thứ đều ổn khi có vấn đề, trái ngược với việc cho phép một công cụ quản lý tính khả dụng, cấu hình, vv .. MMM hoạt động trong nhiều tình huống, có lẽ bạn nên thử nó và xem nó có đáp ứng nhu cầu của bạn hay không. Tôi không thể nói bất cứ điều gì xấu về nó.

Tôi hoàn toàn không quen thuộc với máy chủ phương tiện Wowza, nhưng tìm kiếm nhanh đã giải thích một vài điều. Vì Wowza sử dụng RTSP (UDP và TCP), HAProxy là NOT một giải pháp vì nó chỉ thực hiện TCP. Mặt khác, mặt khác có thể thực hiện cân bằng tải UDP (nó sử dụng IVPS/LVS). Trong thực tế, Keepalived cũng nên được sử dụng để cân bằng tải nô lệ cơ sở dữ liệu của bạn nếu bạn có các truy vấn dài.

Một lưu ý cuối cùng, có rất nhiều cách để "cuộn" các dịch vụ giống như AWS của bạn như bộ nhớ S3. Nếu bạn muốn tránh có SPF nhưng vẫn cần chức năng giống như các dịch vụ AWS, bạn nên xem xét việc chạy các biến thể nguồn mở, chẳng hạn như Eucalyptus/Cloud.com/Openstack/GlusterFS. Có rất nhiều công việc liên quan đến việc thiết lập tất cả những thứ đó, nhưng bạn sẽ hạnh phúc vào ngày bạn có thể nói: "vì vậy nếu nhà cung cấp X bị hỏng, Y có thể tiếp quản".

Answer 2

Dưới đây là một số gợi ý:

1) Load Balancer: Tạo hai trường hợp ha_proxy với cấp ứng dụng của bạn cân bằng tải kiến ​​thức và khả năng tự động tạo một đối tượng mới theo yêu cầu. Dây lên Amazon Elastic Load Cân bằng ở phía trước của họ với kiểm tra sức khỏe để tuyến đường xung quanh một lỗi ha_proxy duy nhất. Tự động trộn trong trường hợp ha_proxy mới khi một thất bại.

2) Cơ sở dữ liệu: Tôi không nghĩ có cách để xử lý chuyển đổi dự phòng tự động của bạn trong MySQL, nhưng nếu bạn giới thiệu một lớp để đọc từ bản sao và ghi vào chính bạn có thể giữ chỉ đọc hoạt động nếu Primary bị hỏng.

3) Wowza: Bạn sẽ có thể để cân bằng tải nhiều trường Wowza đằng sau lớp ha_proxy bạn w/kiểm tra sức khỏe do đó, một thất bại Wowza duy nhất không vô hiệu hóa streaming media

Answer 3

Tại Scalarium chúng tôi có một giải pháp làm giảm SPF đáng kể, bạn có thể nhìn thấy một hình ảnh thông tin tại Rails in the Cloud trên trang 12.

1. bạn sử dụng Amazon Elastic cân bằng tải để định tuyến giữa các trường ha_proxy của bạn. Để bảo mật hơn, bạn có thể chia ứng dụng của mình thành nhiều vùng khả dụng.

2. Sao chép tổng thể chính của MySQL không phải là điều đơn giản nhất. Bạn có thể có một thể hiện chính và có nhiều nô lệ trong nhiều vùng khả dụng. Sau đó, bạn có thể hỗ trợ các hành động đọc ngay cả khi chủ của bạn đã ra đi.Tôi nghĩ rằng một bậc thầy thực sự với failover là không thể.

3. ha_proxy sẽ có thể tải cân bằng các phiên bản Wowza của bạn.