Là Round-Robin DNS, có đủ tốt để tải cân bằng nội dung tĩnh không?

Chúng tôi có một bộ nội dung tĩnh được chia sẻ mà chúng tôi phục vụ giữa các trang web của chúng tôi tại http://sstatic.net . Thật không may, nội dung này hiện không được cân bằng tải - nó được phục vụ từ một máy chủ duy nhất. Nếu máy chủ đó có vấn đề, tất cả các trang web dựa vào nó đều bị ngừng hoạt động vì tài nguyên được chia sẻ là các thư viện và hình ảnh javascript được chia sẻ thiết yếu.

Chúng tôi đang xem xét các cách để cân bằng nội dung tĩnh trên máy chủ này, để tránh sự phụ thuộc của máy chủ.

Tôi nhận ra rằng DNS vòng tròn tốt nhất là giải pháp cấp thấp (một số người thậm chí có thể nói là ghetto ), nhưng tôi không thể tự hỏi - liệu DNS tròn có phải là một giải pháp "đủ tốt" để cân bằng tải cơ bản của nội dung tĩnh ?

Có một số thảo luận về điều này trong các thẻ [dns] [cân bằng tải] và tôi đã đọc qua một số bài viết tuyệt vời về chủ đề này.

Tôi nhận thức được những nhược điểm chung của việc cân bằng tải DNS thông qua nhiều bản ghi A vòng tròn:

• Thông thường không có nhịp tim hoặc phát hiện lỗi với các bản ghi DNS, vì vậy nếu một máy chủ nhất định trong vòng quay bị hỏng, bản ghi A của nó phải được xóa thủ công khỏi các mục DNS
• thời gian tồn tại (TTL) nhất thiết phải được đặt ở mức khá thấp để điều này hoạt động hoàn toàn, vì các mục DNS được lưu trữ mạnh mẽ trên internet
• các máy khách có trách nhiệm thấy rằng có nhiều bản ghi A và chọn đúng bản ghi

Nhưng, liệu DNS tròn có đủ tốt để bắt đầu hay không, tốt hơn là không có gì, "trong khi chúng tôi nghiên cứu và thực hiện các hình thức thay thế tốt hơn" cho cân bằng tải cho nội dung tĩnh của chúng tôi? Hoặc là vòng tròn DNS khá nhiều vô giá trị trong mọi trường hợp?

Jeff, tôi không đồng ý, cân bằng tải không bao hàm sự dư thừa, thực tế nó hoàn toàn ngược lại. Bạn càng có nhiều máy chủ, bạn càng có nhiều khả năng gặp sự cố ngay lập tức. Đó là lý do tại sao sự dư thừa là bắt buộc khi thực hiện cân bằng tải, nhưng thật không may, có rất nhiều giải pháp chỉ cung cấp cân bằng tải mà không thực hiện bất kỳ kiểm tra sức khỏe nào, dẫn đến một dịch vụ kém tin cậy.

DNS roundrobin là tuyệt vời để tăng dung lượng, bằng cách phân phối tải trên nhiều điểm (có khả năng phân phối theo địa lý). Nhưng nó không cung cấp fail-over. Trước tiên bạn phải mô tả loại thất bại mà bạn đang cố gắng bao gồm. Lỗi máy chủ phải được bảo vệ cục bộ bằng cách sử dụng cơ chế tiếp nhận địa chỉ IP tiêu chuẩn (VRRP, CARP, ...). Một lỗi chuyển đổi được bao phủ bởi các liên kết đàn hồi trên máy chủ đến hai thiết bị chuyển mạch. Lỗi liên kết WAN có thể được bao phủ bởi thiết lập đa liên kết giữa bạn và nhà cung cấp của bạn, bằng cách sử dụng giao thức định tuyến hoặc giải pháp layer2 (ví dụ: PPP đa liên kết). Một lỗi trang web phải được bảo vệ bởi BGP: địa chỉ IP của bạn được sao chép trên nhiều trang web và bạn thông báo chúng lên mạng chỉ khi chúng khả dụng.

Từ câu hỏi của bạn, có vẻ như bạn chỉ cần cung cấp giải pháp khắc phục sự cố máy chủ, đây là giải pháp đơn giản nhất vì nó không liên quan đến bất kỳ phần cứng cũng như hợp đồng với bất kỳ ISP nào. Bạn chỉ cần thiết lập phần mềm thích hợp trên máy chủ của mình, và đó là giải pháp đáng tin cậy và rẻ nhất.

Bạn hỏi "nếu máy haproxy bị lỗi thì sao?". Nó giống nhau. Tất cả những người tôi biết sử dụng haproxy để cân bằng tải và tính sẵn sàng cao đều có hai máy và chạy ucarp, keepalive hoặc heartbeat trên chúng để đảm bảo rằng một trong số chúng luôn có sẵn.

Hy vọng điều này sẽ giúp!

Khi cân bằng tải, nó ghetto nhưng hiệu quả hơn hoặc ít hơn. Nếu bạn có một máy chủ bị rơi khỏi tải và muốn truyền bá nó đến nhiều máy chủ, đó có thể là một lý do tốt để làm điều này, ít nhất là tạm thời.

Có một số lời chỉ trích hợp lệ về DNS vòng tròn là tải "cân bằng", và tôi không khuyên bạn nên làm điều đó cho mục đích đó ngoài việc hỗ trợ ban nhạc ngắn hạn.

Nhưng bạn nói động lực chính của bạn là để tránh sự phụ thuộc vào một máy chủ. Không có một số cách tự động để đưa các máy chủ chết ra khỏi vòng quay, nó không có giá trị như một cách ngăn chặn thời gian chết. .

Nếu một trong hai máy chủ bị cướp vòng của bạn ngừng hoạt động, thì 50% khách hàng của bạn sẽ gặp thất bại. Điều này tốt hơn thất bại 100% chỉ với một máy chủ, nhưng hầu như bất kỳ giải pháp nào khác thực hiện chuyển đổi dự phòng thực sự sẽ tốt hơn thế này.

Nếu xác suất thất bại của một máy chủ là N, với hai máy chủ thì xác suất của bạn là 2N. Nếu không tự động, chuyển đổi dự phòng nhanh , sơ đồ này làm tăng khả năng một số người dùng của bạn sẽ gặp phải lỗi.

Nếu bạn có kế hoạch đưa máy chủ chết ra khỏi vòng quay một cách thủ công, bạn sẽ bị giới hạn bởi tốc độ mà bạn có thể làm điều đó và DNS TTL. Nếu máy chủ chết lúc 4 giờ sáng thì sao? Phần tốt nhất của chuyển đổi dự phòng thực sự là ngủ qua đêm. Bạn đã sử dụng HAProxy , vì vậy bạn nên làm quen với nó. Tôi thực sự khuyên bạn nên sử dụng nó, vì HAProxy được thiết kế cho chính xác tình huống này.

DNS tròn không phải là những gì mọi người nghĩ. Là một tác giả của phần mềm máy chủ DNS (cụ thể là BIND ), chúng tôi khiến người dùng tự hỏi tại sao vòng tròn của họ ngừng hoạt động theo kế hoạch. Họ không hiểu rằng ngay cả với chỉ số 0 giây sẽ có một số lượng bộ nhớ đệm ngoài đó, vì một số bộ nhớ cache đặt thời gian tối thiểu (thường là 30-300 giây) bất kể là gì.

Ngoài ra, trong khi các máy chủ AUTH của bạn có thể thực hiện vòng tròn, không có gì đảm bảo những người bạn quan tâm - bộ nhớ cache mà người dùng của bạn nói với - sẽ. Nói tóm lại, robin tròn không đảm bảo bất kỳ thứ tự nào theo quan điểm của khách hàng, chỉ những gì máy chủ xác thực của bạn cung cấp cho bộ đệm.

Nếu bạn muốn chuyển đổi dự phòng thực sự, DNS chỉ là một bước. Việc liệt kê nhiều hơn một địa chỉ IP cho hai cụm khác nhau là một ý tưởng không tồi, nhưng tôi sẽ sử dụng công nghệ khác ở đó (chẳng hạn như anycast đơn giản) để thực hiện cân bằng tải thực tế. Cá nhân tôi coi thường phần cứng cân bằng tải phần cứng, điều này tương tự với DNS vì nó thường bị lỗi. Và đừng quên DNSSEC đang đến, vì vậy nếu bạn chọn một cái gì đó trong khu vực này, hãy hỏi nhà cung cấp của bạn điều gì xảy ra khi bạn ký tên vào khu vực của bạn.

Tôi đã nói điều đó nhiều lần trước đây và tôi sẽ nói lại lần nữa - nếu khả năng phục hồi là vấn đề thì thủ thuật DNS không phải là câu trả lời .

Các hệ thống HA tốt nhất sẽ cho phép khách hàng của bạn tiếp tục sử dụng cùng một địa chỉ IP chính xác cho mọi yêu cầu. Đây là cách duy nhất để đảm bảo rằng khách hàng thậm chí không nhận thấy sự thất bại.

Vì vậy, quy tắc cơ bản là khả năng phục hồi thực sự đòi hỏi thủ thuật cấp độ định tuyến IP . Sử dụng thiết bị cân bằng tải hoặc OSPF "đa đường có chi phí bằng nhau" hoặc thậm chí VRRP.

Mặt khác, DNS là một công nghệ đánh địa chỉ . Nó tồn tại duy nhất để ánh xạ từ không gian tên này sang không gian tên khác. Nó không được thiết kế để cho phép các thay đổi động rất ngắn hạn đối với ánh xạ đó và do đó khi bạn cố gắng thực hiện các thay đổi đó, nhiều khách hàng sẽ không chú ý đến chúng, hoặc tốt nhất sẽ mất nhiều thời gian để chú ý đến chúng.

Tôi cũng sẽ nói rằng vì tải không phải là vấn đề đối với bạn, nên bạn cũng có thể có một máy chủ khác sẵn sàng để chạy như một chế độ chờ nóng. Nếu bạn sử dụng tính năng quay vòng câm, bạn phải chủ động thay đổi bản ghi DNS của mình khi có sự cố, do đó bạn cũng có thể chủ động lật máy chủ dự phòng nóng thành hành động và không thay đổi DNS của mình.

Tôi đã đọc qua tất cả các câu trả lời và một điều tôi không thấy là hầu hết các trình duyệt web hiện đại sẽ thử một trong những địa chỉ IP thay thế nếu máy chủ không phản hồi. Nếu tôi nhớ chính xác thì Chrome thậm chí sẽ thử nhiều địa chỉ IP và tiếp tục với máy chủ phản hồi trước. Vì vậy, theo tôi, cân bằng DNS Round Robin Load luôn tốt hơn thì không có gì.

BTW: Tôi thấy DNS Round Robin là giải pháp phân phối tải đơn giản.

Tôi đến trễ với chủ đề này, vì vậy câu trả lời của tôi có lẽ sẽ chỉ lơ lửng một mình ở phía dưới, bị bỏ quên, đánh hơi.

Trước hết, câu trả lời đúng cho câu hỏi không phải là trả lời câu hỏi, mà là nói:

1. "Bạn có thể muốn cân bằng tải mạng Windows thay thế." HOẶC LÀ
2. "Hãy hòa nhập với thời gian, đặt nội dung tĩnh của bạn lên một cái gì đó như Cloud Files hoặc S3 và có một bản sao CDN trên toàn thế giới."

NLB là người trưởng thành, phù hợp với nhiệm vụ và khá dễ thiết lập. Các giải pháp đám mây đi kèm với những ưu và nhược điểm riêng, nằm ngoài phạm vi của câu hỏi này.

Câu hỏi

DNS tròn có đủ tốt để bắt đầu, tốt hơn không, "trong khi chúng tôi nghiên cứu và thực hiện các giải pháp thay thế tốt hơn" cho cân bằng tải cho nội dung tĩnh của chúng tôi?

Giữa, nói, 2 hoặc 3 máy chủ web tĩnh? Có, tốt hơn là không có gì, vì có những nhà cung cấp DNS sẽ tích hợp DNS Round Robin với kiểm tra sức khỏe của máy chủ và sẽ tạm thời xóa các máy chủ đã chết khỏi các bản ghi DNS. Vì vậy, theo cách này, bạn có được phân phối tải tốt và một số tính sẵn sàng cao; và tất cả chỉ mất chưa đầy 5 phút để thiết lập.

Nhưng những cảnh báo được vạch ra bởi những người khác trong chủ đề này được áp dụng:

• Các trình duyệt hiện tại của Microsoft lưu dữ liệu DNS trong 30 phút , do đó bạn đang xem thời gian chuyển đổi dự phòng hơn 30 phút cho một tập hợp con của người dùng, tùy thuộc vào trạng thái bộ đệm DNS ban đầu của họ.
• Những gì người dùng nhìn thấy trong quá trình chuyển đổi dự phòng có thể là ... lạ (bạn không sử dụng auth trên nội dung tĩnh và chắc chắn không phải là auth, nhưng liên kết hiển thị một cái gì đó cần chú ý).

Các giải pháp khác

HAProxy thật tuyệt vời, nhưng vì Stack Overflow nằm trong kho công nghệ của Microsoft, có thể sử dụng công cụ cân bằng tải & tính sẵn sàng cao của Microsoft sẽ có ít chi phí quản trị hơn. Cân bằng tải mạng xử lý một phần của vấn đề và Microsoft thực sự có bộ cân bằng tải / proxy ngược L7 HTTP ngay bây giờ.

Tôi chưa bao giờ sử dụng ARR cho mình, nhưng cho rằng nó đã được phát hành lần thứ hai và đến từ Microsoft, tôi cho rằng nó đã được thử nghiệm đủ tốt. Đây là tài liệu dễ hiểu , đây là một cách họ thấy phân phối nội dung tĩnh và động trên webnodes và đây là phần về cách sử dụng ARR với NLB để đạt được cả phân phối tải và tính sẵn sàng cao.

Điều đáng chú ý là có bao nhiêu người đóng góp đang giúp đóng góp thông tin về DNS Round Robin như một cơ chế phục hồi tải và khả năng phục hồi. Nó thường hoạt động, nhưng bạn cần phải hiểu cách thức hoạt động của nó và tránh những sai lầm gây ra bởi tất cả những thông tin sai lệch đó.

1) Các bản ghi TTL trên DNS được sử dụng cho Vòng tròn phải ngắn - nhưng KHÔNG PHẢI. Có chỉ số TTL ở mức 0 sẽ phá vỡ cách thức chính mà khả năng phục hồi được cung cấp.

2) DNS RR lây lan, nhưng không cân bằng tải, nó lan truyền nó bởi vì trên một cơ sở khách hàng lớn, họ có xu hướng truy vấn máy chủ DNS một cách độc lập và do đó kết thúc với các mục DNS lựa chọn đầu tiên khác nhau. Những lựa chọn đầu tiên khác nhau đó có nghĩa là các máy khách được phục vụ bởi các máy chủ khác nhau và tải được trải ra. Nhưng tất cả phụ thuộc vào thiết bị nào đang thực hiện truy vấn DNS và thời gian giữ kết quả. Một ví dụ phổ biến là tất cả các máy khách phía sau proxy công ty (thực hiện truy vấn DNS cho chúng) đều sẽ nhắm mục tiêu đến một máy chủ duy nhất. Tải được lan truyền - nhưng nó không cân bằng đồng đều.

3) DNS RR cung cấp khả năng phục hồi miễn là phần mềm máy khách thực hiện đúng cách (và cả khoảng chú ý của người dùng và TTL không quá ngắn). Điều này là do robin vòng DNS cung cấp một danh sách các địa chỉ IP máy chủ được sắp xếp và phần mềm máy khách sẽ cố gắng liên lạc lần lượt với từng địa chỉ đó cho đến khi tìm thấy máy chủ chấp nhận kết nối.

Vì vậy, nếu máy chủ lựa chọn đầu tiên bị hỏng thì kết nối TCP / IP của máy khách hết thời gian và không cung cấp khoảng thời gian chú ý hoặc TTL, thì phần mềm máy khách sẽ thực hiện một kết nối khác với mục nhập thứ hai trong danh sách - và cứ thế cho đến khi TTL hết hạn hoặc đến cuối danh sách (hoặc người dùng bỏ cuộc trong sự ghê tởm).

Một danh sách dài các máy chủ bị hỏng (lỗi của bạn) và giới hạn thử lại kết nối TCP / IP lớn (lỗi cấu hình máy khách) có thể tạo ra trong một thời gian dài trước khi Máy khách thực sự tìm thấy máy chủ hoạt động. Quá ngắn một TTL có nghĩa là nó không bao giờ được đưa đến cuối danh sách, và thay vào đó đưa ra một truy vấn DNS mới và được cung cấp một danh sách mới (hy vọng theo một thứ tự khác).

Đôi khi Khách hàng gặp xui xẻo và danh sách mới vẫn bắt đầu với các máy chủ bị hỏng. Để cung cấp cho hệ thống cơ hội tốt nhất để cung cấp khả năng phục hồi của khách hàng, bạn nên đảm bảo TTL dài hơn khoảng chú ý thông thường và để khách hàng có thể đi đến cuối danh sách.

Khi máy khách đã tìm thấy một máy chủ hoạt động, nó sẽ ghi nhớ nó và khi cần thực hiện kết nối tiếp theo, nó sẽ không lặp lại tìm kiếm (trừ khi hết hạn sử dụng). Một TTL dài hơn làm giảm tần suất người dùng gặp phải sự chậm trễ trong khi máy khách tìm kiếm một máy chủ hoạt động - mang lại trải nghiệm tốt hơn.

4) DNS TTL trở thành của riêng bạn, khi bạn muốn thay đổi thủ công các bản ghi DNS (ví dụ: để loại bỏ một máy chủ bị hỏng lâu dài) thì một TTL ngắn cho phép thay đổi đó lan truyền nhanh chóng (khi bạn đã bắt đầu thực hiện), vì vậy xem xét sự cân bằng giữa thời gian cần thiết trước khi bạn biết về vấn đề và thực hiện thay đổi thủ công đó - và thực tế là các khách hàng bình thường sẽ chỉ phải thực hiện tìm kiếm mới cho máy chủ hoạt động khi hết hạn.

Robin roundin có hai tính năng nổi bật giúp nó rất hiệu quả trong nhiều tình huống - thứ nhất là miễn phí và thứ hai là nó gần như phân tán về mặt địa lý như cơ sở khách hàng của bạn.

Nó không giới thiệu một 'đơn vị thất bại' mới mà tất cả các hệ thống 'thông minh' khác làm. Không có thành phần bổ sung nào có thể gặp phải lỗi chung và đồng thời trên toàn bộ tải các phần tử liên kết với nhau.

Các hệ thống 'thông minh' rất tuyệt vời và giới thiệu các cơ chế tuyệt vời để phối hợp và cung cấp một cơ chế cân bằng và thất bại liền mạch, nhưng cuối cùng, chính các phương pháp mà chúng sử dụng để cung cấp trải nghiệm liền mạch đó là gót chân Achilles của chúng - điều phức tạp thêm có thể sai, và khi có, sẽ cung cấp một trải nghiệm liền mạch về hệ thống thất bại rộng.

Vì vậy, CÓ, vòng tròn DNS chắc chắn là "đủ tốt" cho bước đầu tiên của bạn ngoài một máy chủ duy nhất lưu trữ tất cả nội dung tĩnh của bạn ở một nơi.

Windows Vista & Windows 7 triển khai hỗ trợ khách hàng cho việc luân chuyển khác nhau khi họ đưa ra lựa chọn địa chỉ IPv6 cho IPv4. ( RFC 3484 )

Vì vậy, nếu bạn có số lượng đáng kể người dùng Vista, Windows 7 và Windows 2008, bạn có thể sẽ thấy hành vi không phù hợp với suy nghĩ theo kế hoạch của bạn trong giải pháp cân bằng tải ersatz của bạn.

Tôi đã luôn sử dụng DNS Round-Robin, với TTL dài, làm bộ cân bằng tải. Nó hoạt động thực sự tốt cho các dịch vụ HTTP / HTTPS với trình duyệt .

Tôi thực sự căng thẳng với các trình duyệt vì hầu hết các trình duyệt đều thực hiện một số «thử lại trên một IP khác», nhưng tôi không biết các thư viện hoặc phần mềm khác sẽ xử lý nhiều giải pháp IP như thế nào.

Khi trình duyệt không nhận được phản hồi từ một máy chủ, nó sẽ tự động gọi IP tiếp theo, rồi gắn bó với nó (cho đến khi nó ngừng hoạt động ... và sau đó thử một máy chủ khác).

Quay trở lại năm 2007, tôi đã thực hiện bài kiểm tra sau:

• thêm iframe trên trang web của tôi, chỉ vào một mục Round-Robin, chẳng hạn như http://roundrobin.test:10080/ping.php
• trang được phục vụ bởi 3 socket PHP, nghe trên 3 IP khác nhau, tất cả trên cổng 10080 (tôi không đủ khả năng để kiểm tra trên cổng 80, vì trang web của tôi đang chạy trên đó)
• một ổ cắm (giả sử A ) đã ở đó để kiểm tra xem trình duyệt có thể kết nối trên cổng 10080 (vì nhiều công ty chỉ cho phép các cổng tiêu chuẩn)
• hai ổ cắm khác (giả sử B và C ) có thể được bật hoặc tắt khi đang di chuyển.

Tôi để nó chạy một giờ, có rất nhiều dữ liệu. Kết quả là trong 99,5% số lần truy cập vào ổ cắm A , tôi đã có một lần truy cập vào một trong hai ổ cắm B hoặc C (dĩ nhiên tôi không vô hiệu hóa cả hai lần này). Các trình duyệt là: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Vì vậy, ngay cả các trình duyệt không tuân thủ cũng đã xử lý đúng!

Cho đến ngày hôm nay, tôi chưa bao giờ thử nghiệm lại, nhưng có lẽ tôi sẽ thiết lập một thử nghiệm mới vào một ngày hoặc phát hành mã trên github để những người khác có thể kiểm tra nó.

Lưu ý quan trọng: ngay cả khi nó hoạt động hầu hết thời gian, nó sẽ không loại bỏ thực tế là một số yêu cầu sẽ thất bại. Tôi cũng sử dụng nó cho các yêu cầu POST, vì ứng dụng của tôi sẽ trả về một thông báo lỗi trong trường hợp nó không hoạt động, để người dùng có thể gửi lại dữ liệu và rất có thể trình duyệt sẽ sử dụng IP khác trong trường hợp này và lưu sẽ hoạt động . Và đối với nội dung tĩnh, nó hoạt động thực sự tuyệt vời.

Vì vậy, nếu bạn đang làm việc với các trình duyệt, hãy sử dụng DNS Round-Robin, cho nội dung tĩnh hoặc động, bạn sẽ ổn. Máy chủ cũng có thể đi xuống giữa giao dịch và ngay cả với bộ cân bằng tải tốt nhất bạn cũng không thể xử lý trường hợp như vậy. Đối với nội dung động, bạn phải làm cho các phiên / cơ sở dữ liệu / tệp của mình được đồng bộ hóa, nếu không bạn sẽ không thể xử lý việc này (nhưng điều đó cũng đúng với bộ cân bằng tải thực).

Lưu ý thêm: bạn có thể kiểm tra hành vi trên IP của chính mình bằng cách sử dụng iptables. Ví dụ: trước quy tắc tường lửa của bạn cho lưu lượng HTTP, hãy thêm:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(nơi 12.34.56.78rõ ràng là IP của bạn)

Không sử dụng DROP, vì nó để cổng được lọc và trình duyệt của bạn sẽ đợi cho đến khi hết thời gian. Vì vậy, bây giờ, bạn có thể kích hoạt hoặc vô hiệu hóa một máy chủ này hoặc máy chủ khác. Thử nghiệm rõ ràng nhất là vô hiệu hóa máy chủ A, tải trang, sau đó kích hoạt máy chủ A và vô hiệu hóa máy chủ B. Khi bạn tải lại trang, bạn sẽ thấy một chút chờ đợi từ trình duyệt, sau đó nó sẽ tải từ máy chủ Một lần nữa. Trong Chrome, bạn có thể xác nhận IP của máy chủ bằng cách xem yêu cầu trong bảng điều khiển mạng. Trong Generaltab của Headers, bạn sẽ thấy một tiêu đề giả có tên Remote Address:. Đây là IP từ nơi bạn nhận được câu trả lời.

Vì vậy, nếu bạn cần chuyển sang chế độ bảo trì trên một máy chủ, chỉ cần vô hiệu hóa lưu lượng HTTP / HTTPS theo một iptables REJECTquy tắc, tất cả các yêu cầu sẽ chuyển đến các máy chủ khác (với một chút chờ đợi, hầu như không thể nhận thấy đối với người dùng).

Tôi không nghĩ rằng đó là một giải pháp đủ tốt bởi vì giả sử bây giờ bạn có hai máy chủ và bạn làm tròn việc sử dụng DNS đến địa chỉ IP của mỗi máy chủ. Khi một máy chủ ngừng hoạt động, các máy chủ DNS không biết rằng nó đã bị hỏng và sẽ tiếp tục phục vụ địa chỉ IP đó, như là một phần của quy trình RR. Sau đó, 50% khán giả của bạn sẽ nhận được một trang web bị hỏng thiếu javascript hoặc hình ảnh.

Có lẽ dễ dàng hơn để chỉ đến một địa chỉ IP phổ biến được xử lý bởi Windows NLB đại diện cho hai máy chủ phía sau. Trừ khi bạn đang sử dụng máy chủ Linux cho nội dung tĩnh của mình, nếu tôi nhớ đọc nó ở đâu đó?

Cân bằng tải vòng tròn chỉ hoạt động khi bạn cũng kiểm soát Vùng DNS để bạn có thể thay đổi danh sách các máy chủ và đẩy nó đến các chủ khu vực kịp thời.

Như đã đề cập trong một trong những câu trả lời khác, cái ác tiềm ẩn của trò chơi vòng tròn là bộ nhớ đệm DNS có thể xảy ra ở bất cứ đâu giữa máy chủ của bạn và máy khách, điều này phủ nhận hoàn toàn lợi ích nhỏ của giải pháp này. Ngay cả với DNS TTL được đặt ở giá trị rất thấp, bạn vẫn có ít quyền kiểm soát đối với bộ đệm DNS của khách hàng hoặc thậm chí bộ đệm DNS của khách hàng sẽ duy trì hoạt động của địa chỉ IP hiện đã chết.

Chắc chắn đó là một cải tiến so với SPOF, nhưng chỉ là cận biên. Tôi sẽ xem ai đã từng lưu trữ máy chủ của bạn và xem những gì họ cung cấp, nhiều người có một số loại dịch vụ cân bằng tải cơ bản mà họ có thể cung cấp.

Bạn cũng có thể có một máy chủ duy nhất có nội dung tĩnh được sao chép trong S3 và chuyển sang CNAME S3 khi chính của bạn bị hỏng. Bạn sẽ kết thúc với cùng một độ trễ nhưng không có chi phí nhiều máy chủ.

Điều này thực sự phụ thuộc vào những gì bạn đang nói và số lượng máy chủ bạn đang quay vòng. Tôi đã từng có một trang web chạy trên một số máy chủ và tôi đã sử dụng vòng tròn DNS do đó chủ yếu là người mới của tôi vào thời điểm đó và nó thực sự không phải là một vấn đề lớn. Đó không phải là một vấn đề lớn vì nó đã không sụp đổ. Đó là một hệ thống không phức tạp thực sự ngu ngốc, vì vậy nó đã được duy trì và có mức lưu lượng truy cập khá ổn định. Nếu nó bị va chạm từ giao thông, đó là vào ban ngày và tôi có thể dễ dàng chăm sóc nó. Tôi muốn nói rằng nội dung tĩnh của bạn đủ điều kiện đủ đơn giản để không gây ra sự cố.

Bên ngoài lỗi phần cứng, vv, máy chủ của bạn đã ổn định như thế nào? Làm thế nào "tăng đột biến" là lưu lượng truy cập của bạn trên nội dung này? Giả sử thẳng lên Apache hoặc một cái gì đó và lưu lượng truy cập tương đối bằng phẳng, nó sẽ không gặp sự cố nhiều, và tôi sẽ nói vòng tròn là "đủ tốt".

Tôi chắc chắn rằng tôi sẽ bỏ phiếu vì tôi không giảng về giải pháp HA 100%, nhưng đó không phải là điều bạn yêu cầu. Nó thuộc về những gì bạn sẵn sàng chấp nhận như một giải pháp so với nỗ lực bỏ ra.

Nếu bạn đang sử dụng RR DNS để cân bằng tải, nó sẽ ổn, nhưng bạn thì không. Bạn đang sử dụng nó để kích hoạt một máy chủ dự phòng, trong trường hợp đó là không ổn.

Như một bài viết trước đã nói, bạn cần một cái gì đó để phát hiện nhịp tim và ngừng đánh nó cho đến khi nó quay trở lại.

Tin tốt là nhịp tim có sẵn thực sự rẻ, trong các thiết bị chuyển mạch hoặc trong Windows.

Dunno về các hệ điều hành khác nhưng tôi cho rằng nó cũng ở đó.

Tôi khuyên bạn nên chỉ định một địa chỉ IP bổ sung cho mỗi máy chủ của mình (ngoài IP tĩnh mà bạn sử dụng, giả sử, ssh) và bạn đưa địa chỉ đó vào nhóm DNS. Và sau đó bạn sử dụng một số phần mềm để chuyển xung quanh các địa chỉ IP này trong trường hợp máy chủ bị lỗi. Heartbeat hoặc CARP có thể làm điều đó, ví dụ, nhưng có những giải pháp khác ngoài kia.

Điều này có lợi thế là đối với các khách hàng sử dụng dịch vụ của bạn, không có gì phải thay đổi trong quá trình thiết lập và bạn không phải lo lắng về bộ nhớ đệm DNS hoặc TTL, nhưng bạn vẫn có thể tận dụng "cân bằng tải" vòng tròn DNS .

Nó có thể sẽ thực hiện công việc, đặc biệt nếu bạn có thể có nhiều IP trên các hộp tĩnh của mình. có một IP "phục vụ nội dung tĩnh" và một IP "quản lý máy". Nếu một hộp bị hỏng, bạn có thể sử dụng giải pháp HA hiện có hoặc can thiệp thủ công để đưa IP từ máy bị lỗi lên một trong những "thành viên cụm" khác hoặc một máy hoàn toàn mới (tùy thuộc vào tốc độ của nó để có được điều đó và chạy).

Tuy nhiên, một giải pháp như vậy sẽ có một số vấn đề nhỏ. Cân bằng tải sẽ không ở bất cứ đâu gần hoàn hảo và nếu bạn dựa vào can thiệp thủ công, bạn có thể bị mất điện đối với một số khách truy cập.

Bộ cân bằng tải phần cứng có thể có thể thực hiện tốt hơn cả việc chia sẻ tải và cung cấp "thời gian hoạt động của cụm" so với vòng tròn DNS. Mặt khác, đó là một (hoặc hai, vì lý tưởng nhất là bạn có các phần cứng LB trong cụm HA) sẽ cần mua, cấp nguồn và làm mát và (có thể) một thời gian để làm quen (nếu bạn chưa có có cân bằng tải chuyên dụng).

Để ngắn gọn trả lời câu hỏi (là round robin DNS đủ tốt như một starter, có còn hơn không "trong khi chúng tôi nghiên cứu và triển khai các giải pháp thay thế tốt hơn" hình thức cân bằng tải cho nội dung tĩnh của chúng tôi?), Tôi sẽ nói rằng nó là tốt hơn so với không có gì, nhưng bạn chắc chắn nên tiếp tục nghiên cứu các hình thức cân bằng tải khác.

Khi nghiên cứu Windows Load Balance vài năm trước, tôi đã thấy một tài liệu nói rằng trang trại của Microsoft được cấu hình thành nhiều nhóm cân bằng tải, với vòng tròn DNS giữa chúng. Vì bạn có thể có nhiều máy chủ DNS phản hồi trong từng không gian tên và do tính năng cân bằng tải của Microsoft là tự phục hồi, nên điều này cung cấp cả dự phòng và cân bằng tải.

Nhược điểm: bạn cần ít nhất 4 máy chủ (2 máy chủ x 2 nhóm).

Trả lời nhận xét của Jeff về câu trả lời của Schof, có cách nào để kết nối vòng tròn DNS giữa các máy chủ HAProxy không?

Nó có công dụng rất nhỏ, đủ để giúp bạn có được trong khi bạn đưa ra một giải pháp thực sự. Giống như bạn nói, các TTL phải được đặt ở mức khá thấp. Tuy nhiên, điều này có lợi ích phụ khi rút một máy có vấn đề khỏi DNS trong khi nó có vấn đề. Giả sử bạn có SvrA, SvrB và SvrC đang phân phát nội dung của bạn và SvrA đi xuống. Bạn kéo nó ra khỏi DNS và sau khoảng thời gian ngắn được xác định bởi chỉ số TTL thấp của bạn, bộ phân giải sẽ tìm ra một máy chủ khác (SvrB hoặc SvrC) đang hoạt động. Bạn nhận được SvrA trực tuyến và đưa nó trở lại DNS. Một thời gian chết ngắn cho một số người, không có cho những người khác. Không tuyệt vời, nhưng hoàn toàn khả thi. Càng nhiều máy chủ tĩnh bạn đặt trong hỗn hợp, bạn càng ít có khả năng có nhiều nhóm người dùng ngừng hoạt động.

Bạn chắc chắn sẽ không nhận được phân phối cân bằng thực sự mà một giải pháp cân bằng tải thực sẽ cung cấp do cấu trúc liên kết của Internet. Tôi vẫn sẽ xem tải trên tất cả các máy chủ liên quan.