Nhiều trung tâm dữ liệu và lưu lượng HTTP: Robin Round Robin là cách DUY NHẤT để đảm bảo sự thất bại tức thì?

Nhiều bản ghi A trỏ đến cùng một tên miền dường như chỉ được sử dụng để triển khai DNS Round Robin như một kỹ thuật cân bằng tải giá rẻ.

Cảnh báo thông thường đối với DNS RR là nó không tốt cho tính sẵn sàng cao. Khi 1 IP ngừng hoạt động, khách hàng sẽ tiếp tục sử dụng nó trong vài phút.

Một cân bằng tải thường được đề xuất là một lựa chọn tốt hơn.

Cả hai tuyên bố đều không hoàn toàn đúng:

1. Khi lưu lượng truy cập là HTTP, hầu hết các trình duyệt HTML có thể tự động thử bản ghi A tiếp theo nếu trước đó không hoạt động, mà không cần tra cứu DNS mới. Đọc ở đây chương 3.1 và ở đây .

2. Khi có nhiều trung tâm dữ liệu tham gia, DNS RR là tùy chọn duy nhất để phân phối lưu lượng truy cập trên chúng.

Vì vậy, có đúng là, với nhiều trung tâm dữ liệu và lưu lượng HTTP, việc sử dụng DNS RR là cách DUY NHẤT để đảm bảo sự cố ngay lập tức khi một trung tâm dữ liệu ngừng hoạt động?

Cảm ơn,

Valentino

Biên tập:

• Dĩ nhiên, mỗi trung tâm dữ liệu đều có Bộ cân bằng tải cục bộ với phụ tùng nóng.
• Bạn có thể hy sinh mối quan hệ phiên cho một thất bại ngay lập tức.
• AFAIK cách duy nhất để DNS đề xuất một trung tâm dữ liệu thay vì một trung tâm dữ liệu khác là trả lời chỉ bằng IP (hoặc IP) được liên kết với trung tâm dữ liệu đó. Nếu trung tâm dữ liệu không thể truy cập được thì tất cả các IP đó cũng không thể truy cập được. Điều này có nghĩa là, ngay cả khi các trình duyệt HTML thông minh có thể thử ngay một bản ghi A khác, tất cả các lần thử sẽ thất bại cho đến khi mục nhập bộ nhớ cache cục bộ hết hạn và tìm kiếm DNS mới, tìm nạp IP hoạt động mới (tôi cho rằng DNS tự động đề xuất với trung tâm dữ liệu mới khi một lần thất bại). Vì vậy, "DNS thông minh" không thể đảm bảo chuyển đổi dự phòng ngay lập tức.
• Ngược lại, một vòng tròn DNS cho phép nó. Khi một trung tâm dữ liệu bị lỗi, các trình duyệt HTML thông minh (hầu hết trong số chúng) sẽ ngay lập tức thử các bản ghi A được lưu trong bộ nhớ cache khác nhảy đến một trung tâm dữ liệu (đang hoạt động) khác. Vì vậy, vòng tròn DNS không đảm bảo mối quan hệ phiên hoặc RTT thấp nhất nhưng dường như là cách duy nhất để đảm bảo sự thất bại tức thì khi các máy khách là trình duyệt HTML "thông minh".

Chỉnh sửa 2:

• Một số người đề xuất TCP Anycast là một giải pháp dứt khoát. Trong bài báo này (chương 6) được giải thích rằng Anycast fail-over có liên quan đến sự hội tụ BGP. Vì lý do này, Anycast có thể sử dụng từ 15 phút đến 20 giây để hoàn thành. Có thể có 20 giây trên các mạng nơi cấu trúc liên kết được tối ưu hóa cho việc này. Có lẽ chỉ các nhà khai thác CDN có thể cấp thất bại nhanh như vậy.

Chỉnh sửa 3: *

• Tôi đã thực hiện một số tra cứu và theo dõi DNS (có thể một số chuyên gia có thể kiểm tra lại) và:
  • CDN duy nhất sử dụng TCP Anycast dường như là CacheFly, các nhà khai thác khác như mạng CDN và BitGravity sử dụng CacheFly. Có vẻ như các cạnh của chúng không thể được sử dụng như các proxy ngược. Do đó, chúng không thể được sử dụng để cấp dự phòng ngay lập tức.
  • Akamai và LimeLight dường như sử dụng DNS nhận biết địa lý. Nhưng! Họ trả lại nhiều hồ sơ A. Từ các traceroutes dường như các IP được trả về nằm trên cùng một trung tâm dữ liệu. Vì vậy, tôi rất băn khoăn về cách họ có thể cung cấp SLA 100% khi một trung tâm dữ liệu ngừng hoạt động.

Khi tôi sử dụng thuật ngữ "DNS Round Robin", tôi thường hiểu theo nghĩa "kỹ thuật cân bằng tải giá rẻ" như OP mô tả.

Nhưng đó không phải là cách duy nhất DNS có thể được sử dụng cho tính khả dụng cao toàn cầu. Hầu hết thời gian, thật khó để những người có nền tảng (công nghệ) khác nhau có thể giao tiếp tốt.

Kỹ thuật cân bằng tải tốt nhất (nếu tiền không phải là vấn đề) thường được coi là:

1. Một mạng toàn cầu gồm các máy chủ DNS 'thông minh',
2. và một tập hợp các trung tâm dữ liệu trải rộng trên toàn cầu,
3. trong đó mỗi nút DNS thực hiện Split Horizon DNS,
4. và giám sát tính khả dụng và lưu lượng truy cập có sẵn cho các nút DNS 'thông minh' trong một số trường hợp,
5. để yêu cầu DNS của người dùng chảy đến máy chủ DNS gần nhất thông qua IP Anycast ,
6. và máy chủ DNS này cung cấp Bản ghi A / bộ Bản ghi A thấp cho Trung tâm dữ liệu gần nhất / tốt nhất cho người dùng cuối này thông qua DNS chân trời phân chia 'thông minh'.

Sử dụng anycast cho DNS nói chung là tốt, vì phản hồi DNS là không trạng thái và gần như cực kỳ ngắn. Vì vậy, nếu các tuyến đường BGP thay đổi, rất khó có khả năng làm gián đoạn truy vấn DNS.

Anycast ít phù hợp hơn cho các cuộc hội thoại HTTP dài hơn và có trạng thái, do đó hệ thống này sử dụng DNS đường chân trời phân chia. Một phiên HTTP giữa máy khách và máy chủ được giữ cho một trung tâm dữ liệu; nó thường không thể chuyển sang trung tâm dữ liệu khác mà không phá vỡ phiên.

Như tôi đã chỉ ra với "bộ Bản ghi A", cái mà tôi sẽ gọi là 'Robin Round Robin' có thể được sử dụng cùng với thiết lập ở trên. Nó thường được sử dụng để phân tán tải lưu lượng trên nhiều bộ cân bằng tải khả dụng cao trong mỗi trung tâm dữ liệu (để bạn có thể dự phòng tốt hơn, sử dụng bộ cân bằng tải nhỏ hơn / rẻ hơn, không áp đảo bộ đệm mạng Unix của một máy chủ lưu trữ, v.v.).

Vì vậy, có đúng là, với nhiều trung tâm dữ liệu và lưu lượng HTTP, việc sử dụng DNS RR là cách DUY NHẤT để đảm bảo tính sẵn sàng cao?

Không, điều đó không đúng, không phải bởi 'DNS Round Robin', chúng tôi chỉ đơn giản là trao nhiều bản ghi A cho một tên miền. Nhưng sự thật là việc sử dụng DNS thông minh là một thành phần quan trọng trong bất kỳ hệ thống có tính sẵn sàng cao toàn cầu nào. Trên đây minh họa một cách phổ biến (thường là tốt nhất) để đi.

Chỉnh sửa: Bài viết của Google "Di chuyển ngoài thông tin đường dẫn từ đầu đến cuối để tối ưu hóa hiệu suất CDN" đối với tôi dường như là công nghệ tiên tiến trong phân phối tải toàn cầu để có hiệu suất tốt nhất cho người dùng cuối.

Chỉnh sửa 2: Tôi đã đọc bài viết "Tại sao lại dựa trên DNS .. GSLB .. Không hoạt động" mà OP liên kết đến và đó là một tổng quan tốt - Tôi khuyên bạn nên xem xét nó. Đọc nó từ đầu.

Trong phần "Giải pháp cho vấn đề bộ nhớ đệm của trình duyệt", nó ủng hộ các phản hồi DNS với nhiều Bản ghi A chỉ đến nhiều trung tâm dữ liệu như là giải pháp khả thi duy nhất cho sự cố tức thời.

Trong phần "Tưới nước xuống" ở gần đáy, điều hiển nhiên là việc gửi nhiều Bản ghi A là không hợp lý nếu chúng trỏ đến các trung tâm dữ liệu trên nhiều lục địa, bởi vì máy khách sẽ kết nối ngẫu nhiên và do đó thường xuyên bị 'chậm' DC trên lục địa khác. Do đó để điều này hoạt động thực sự tốt, cần có nhiều trung tâm dữ liệu trên mỗi lục địa.

Đây là một giải pháp khác với các bước 1 - 6. Tôi không thể cung cấp một câu trả lời hoàn hảo về vấn đề này, tôi nghĩ rằng một chuyên gia DNS từ Akamai hoặc Google là cần thiết, bởi vì phần lớn điều này nắm rõ các bí quyết thực tế về những hạn chế của bộ nhớ cache và trình duyệt DNS được triển khai ngày hôm nay. AFAIK, các bước 1-6 của tôi là những gì Akamai làm với DNS của họ (bất kỳ ai cũng có thể xác nhận điều này?).

Cảm giác của tôi - đến từ việc làm PM trên các cổng trình duyệt di động (điện thoại di động) - là sự đa dạng và mức độ hoàn toàn bị phá vỡ của các trình duyệt ngoài kia là không thể tin được. Cá nhân tôi sẽ không tin tưởng một giải pháp HA yêu cầu thiết bị đầu cuối của người dùng cuối phải 'làm điều đúng đắn'; do đó tôi tin rằng thất bại tức thời toàn cầu mà không phá vỡ một phiên là không khả thi ngày hôm nay.

Tôi nghĩ rằng các bước 1-6 ở trên của tôi là tốt nhất có sẵn với công nghệ hàng hóa. Giải pháp này không có thất bại tức thời trên.

Tôi muốn một trong những chuyên gia DNS từ Akamai, Google, v.v. đến và chứng minh tôi sai. :-)

Câu hỏi của bạn là: "DNS Round Robin có phải là cách DUY NHẤT để đảm bảo sự thất bại tức thì không?"

Câu trả lời là: "DNS Round Robin KHÔNG BAO GIỜ là cách đúng đắn để đảm bảo sự thất bại tức thì".

(ít nhất là không phải của riêng mình)

Cách đúng để đạt được sự cố ngay lập tức là sử dụng định tuyến BGP4 sao cho cả hai trang web đều sử dụng cùng một địa chỉ IP. Sử dụng công nghệ định tuyến lõi này của internet được sử dụng để định tuyến các yêu cầu đến đúng trung tâm dữ liệu, thay vì sử dụng công nghệ xử lý địa chỉ cốt lõi của internet .

Trong cấu hình đơn giản nhất, điều này chỉ cung cấp chuyển đổi dự phòng. Nó cũng có thể được sử dụng để cung cấp Anycast, với lời cảnh báo rằng các giao thức dựa trên TCP sẽ thất bại tại thời điểm chuyển đổi nếu có bất kỳ sự mất ổn định nào trong định tuyến.

Vì vậy, có đúng là, với nhiều trung tâm dữ liệu và lưu lượng HTTP, việc sử dụng DNS RR là cách DUY NHẤT để đảm bảo tính sẵn sàng cao?

Rõ ràng đó là một tuyên bố sai - bạn chỉ cần nhìn vào Google, Akamai, Yahoo, để thấy rằng họ không sử dụng phản hồi vòng tròn [*] như một giải pháp duy nhất của họ (một số có thể sử dụng một phần, cùng với các phương pháp khác .)

Có nhiều tùy chọn có thể, nhưng nó thực sự phụ thuộc vào những hạn chế khác mà bạn có, với dịch vụ / ứng dụng của bạn mà bạn chọn.

Có thể sử dụng các kỹ thuật quay vòng theo cách tiếp cận máy chủ cùng vị trí đơn giản và không phải lo lắng về sự cố máy chủ, nếu bạn cũng sắp xếp cho việc 'thất bại' địa chỉ IP. (Nhưng hầu hết lựa chọn các kỹ thuật cân bằng tải, một địa chỉ IP duy nhất và chuyển đổi dự phòng giữa các bộ cân bằng tải.)

Có thể bạn cần tất cả các yêu cầu cho một phiên duy nhất để đến cùng một máy chủ, nhưng bạn muốn các yêu cầu được trải rộng trên các cụm máy chủ khu vực khác nhau? Vì vậy, vòng tròn không phù hợp, vì điều đó: bạn cần làm một điều gì đó để đảm bảo mọi khách hàng cụ thể truy cập vào cùng một cụm máy chủ vật lý (trừ khi xảy ra 'ngoại lệ', chẳng hạn như lỗi máy chủ). Họ nhận được một địa chỉ IP nhất quán từ truy vấn DNS hoặc được chuyển đến cùng một cụm máy chủ vật lý. Các giải pháp cho điều đó bao gồm các "bộ cân bằng tải" DNS thương mại và phi thương mại khác nhau hoặc (nếu bạn có quyền kiểm soát nhiều hơn đối với mạng của mình) quảng cáo mạng BGP. Bạn chỉ có thể sắp xếp để máy chủ tên miền của riêng bạn đưa ra các phản hồi hoàn toàn khác nhau (nhưng, vì các yêu cầu DNS có thể được gửi đi khắp nơi, bạn đã thắng '

[* Tôi sẽ sử dụng "round-robin", vì 'RR' trong thuật ngữ DNS có nghĩa là "hồ sơ tài nguyên".]

Quan sát rất tốt vmiazzo +1 cho bạn !! Tôi bị mắc kẹt chính xác nơi bạn đang ở .. gặp khó khăn với cách những CDN này thực hiện phép thuật của họ.

Sau đây là dự đoán của tôi về cách CDN chạy mạng của họ:

• Sử dụng Anycast DNS (được đề cập bởi Jesper Mortensen) để có được trung tâm dữ liệu gần nhất
• Họ điều hành một mạng cục bộ trải rộng trên các trung tâm dữ liệu khác nhau cho phép họ thực hiện một số thứ như CARP trên các máy chủ của họ trên các trung tâm dữ liệu khác nhau

Hoặc là

• Họ sử dụng Giao thức cân bằng tải cổng trên bộ định tuyến hoặc Giao thức bộ định tuyến dự phòng nóng (HSRP) . mà đối phó với sự cố mất trung tâm dữ liệu.
• Lý do chúng bao gồm nhiều IP là để máy khách thử lại và vào thời điểm máy khách thử lại, đường dẫn định tuyến có thể đã thay đổi.

Tại thời điểm giải pháp sau đây hoạt động với tôi: - DNS trả về nhiều IP, ví dụ:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Điểm cuối cùng đến một proxy ngược tại đám mây amazon, thông minh chuyển đến máy chủ có sẵn (hoặc cung cấp dưới trang bảo trì)

Reverse proxy vẫn bị tấn công nhưng bot nặng như chính.

Tại sao RFC 2782 (áp dụng giống như MX / ưu tiên cho các dịch vụ như http, imap, ...) không được triển khai trong bất kỳ loại trình duyệt nào? Mọi thứ sẽ dễ dàng hơn ... Có một lỗi về, đã mở trong mười năm trong Mozilla !!! bởi vì nó sẽ là sự kết thúc của ngành công nghiệp cân bằng tải thương mại ??? Tôi rất thất vọng về điều đó.

2 - Bạn có thể làm điều này với Anycast bằng Quagga

(Ngay cả khi có một số thông tin rằng Anycast không tốt với TCP, vẫn có một số công ty lớn sử dụng nó như CacheFly)

Tôi tự hỏi có bao nhiêu người trả lời những câu hỏi này đang thực sự điều hành một mạng lưới máy chủ lớn trên toàn thế giới? Google đang sử dụng robin tròn và công ty của tôi đã sử dụng nó trong nhiều năm. Nó có thể hoạt động khá tốt, với một số hạn chế. Có, nó cần phải được tăng cường với các biện pháp khác.

Chìa khóa thực sự là sẵn sàng chấp nhận một hoặc hai trục trặc nếu máy chủ gặp sự cố. Khi tôi rút phích cắm trên máy chủ, nếu trình duyệt đang cố truy cập máy chủ đó, sẽ có độ trễ khoảng một phút trong khi trình duyệt biết rằng địa chỉ IP bị hỏng. Nhưng sau đó nó đi đến một máy chủ khác rất nhanh.

Nó hoạt động rất tốt và những người cho rằng nó gây ra nhiều vấn đề không biết họ đang nói về cái gì. Nó chỉ đòi hỏi thiết kế đúng.

Failover hút. HA tốt nhất sử dụng tất cả các nguồn lực mọi lúc.

Tôi đã làm việc với HA từ năm 1986. Tôi đã trải qua khóa đào tạo mở rộng để tạo ra các hệ thống chuyển đổi dự phòng và tôi hoàn toàn không phải là người hâm mộ của failover.

Ngoài ra, RR không hoạt động để phân phối tải, ngay cả khi thụ động chứ không phải chủ động. Nhật ký máy chủ của chúng tôi hiển thị rõ ràng tỷ lệ lưu lượng truy cập phù hợp trên mỗi máy chủ - theo lý do.

Một lựa chọn rất đơn giản khác là sử dụng mức thấp (mức độ thấp phụ thuộc vào nhu cầu của bạn) trong bản ghi DNS A hoặc CNAME và cập nhật bản ghi này để chọn IP nào sẽ được sử dụng.

Chúng tôi có 2 ISP và một số dịch vụ công cộng và chúng tôi đang sử dụng thành công phương pháp này với tính sẵn sàng cao từ 3 năm.

Một cờ lê trong công việc là một số ISP có các bộ phân giải được cấu hình kém, ghi lại bộ đệm trong một khoảng thời gian đã đặt và hoàn toàn bỏ qua các cài đặt TTL. Không nên như vậy và không có lý do gì cho điều đó, nhưng thật đáng buồn từ kinh nghiệm của tôi với việc di chuyển nhiều trang web và dịch vụ nó xảy ra.

TCP Anycast thực sự rất ổn định và được CacheFly (từ năm 2002), Prolexic và BitGravity sử dụng. Một bài thuyết trình hay về TCP Anycast đã được thực hiện tại NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Nhiều bản ghi A là cách duy nhất để loại bỏ một điểm có thể xảy ra. Bất kỳ giải pháp nào khác đều buộc tất cả các yêu cầu đến phải đi qua một thiết bị ở đâu đó giữa máy chủ và máy khách.

Vì vậy, để dự phòng tuyệt đối, nó là cần thiết. Đó là lý do tại sao google làm điều đó, hoặc bất cứ ai khác muốn được đảm bảo về tính sẵn có của dịch vụ liên tục.

Một điều khá rõ ràng là tại sao đây là trường hợp ... nhiều bản ghi A là cách duy nhất để di chuyển điểm mà tại đó các yêu cầu được chuyển đến trình duyệt của máy khách. Bất kỳ phương pháp nào khác sẽ dựa vào một điểm duy nhất giữa trình duyệt máy khách và máy chủ có thể xảy ra lỗi, làm giảm dịch vụ của bạn. Bằng cách sử dụng các bản ghi A, điểm duy nhất thất bại từ máy khách đến máy chủ trở thành chính máy khách.

Nếu bạn không thiết lập nhiều bản ghi A, bạn sẽ yêu cầu thời gian chết ...

Phương pháp này rõ ràng không thể dựa vào để cân bằng tải mặc dù.