Tại sao DNS failover không được đề xuất?

Từ việc đọc, có vẻ như DNS failover không được khuyến nghị chỉ vì DNS không được thiết kế cho nó. Nhưng nếu bạn có hai máy chủ web trên các mạng con khác nhau lưu trữ nội dung dư thừa, thì có những phương pháp nào khác để đảm bảo rằng tất cả lưu lượng truy cập được chuyển đến máy chủ trực tiếp nếu một máy chủ ngừng hoạt động?

Đối với tôi có vẻ như DNS failover là tùy chọn chuyển đổi dự phòng duy nhất ở đây, nhưng sự đồng thuận là nó không phải là một lựa chọn tốt. Tuy nhiên, các dịch vụ như DNSADEeasy.com cung cấp nó, vì vậy phải có công với nó. Có ý kiến ​​gì không?

Bởi 'DNS failover' Tôi hiểu ý bạn là DNS Round Robin kết hợp với một số giám sát, tức là xuất bản nhiều địa chỉ IP cho tên máy chủ DNS và xóa địa chỉ chết khi giám sát phát hiện thấy máy chủ ngừng hoạt động. Điều này có thể khả thi cho các trang web nhỏ, ít buôn bán.

Theo thiết kế, khi bạn trả lời yêu cầu DNS, bạn cũng cung cấp Thời gian sống (TTL) cho phản hồi bạn đưa ra. Nói cách khác, bạn đang nói với các máy chủ DNS khác và lưu trữ "bạn có thể lưu câu trả lời này và sử dụng nó trong x phút trước khi kiểm tra lại với tôi". Những hạn chế đến từ đây:

• Với chuyển đổi dự phòng DNS, một tỷ lệ phần trăm người dùng không xác định sẽ lưu trữ dữ liệu DNS của bạn với số lượng TTL khác nhau. Cho đến khi hết hạn, chúng có thể kết nối với máy chủ đã chết. Có nhiều cách nhanh hơn để hoàn thành chuyển đổi dự phòng hơn thế này.
• Vì những điều trên, bạn có xu hướng đặt TTL khá thấp, giả sử 5-10 phút. Nhưng việc đặt nó cao hơn sẽ mang lại lợi ích hiệu suất (rất nhỏ) và có thể giúp việc truyền DNS của bạn hoạt động đáng tin cậy ngay cả khi có một trục trặc ngắn trong lưu lượng mạng. Vì vậy, việc sử dụng chuyển đổi dự phòng dựa trên DNS đi ngược lại với các TTL cao, nhưng các TTL cao là một phần của DNS và có thể hữu ích.

Các phương pháp phổ biến hơn để có được thời gian hoạt động tốt liên quan đến:

• Đặt các máy chủ với nhau trên cùng một mạng LAN.
• Đặt mạng LAN trong trung tâm dữ liệu với các mặt phẳng mạng và nguồn có sẵn cao.
• Sử dụng bộ cân bằng tải HTTP để phân tán tải và thất bại đối với các lỗi máy chủ riêng lẻ.
• Nhận mức độ dự phòng / thời gian hoạt động dự kiến ​​bạn cần cho tường lửa, cân bằng tải và công tắc.
• Có một chiến lược truyền thông thay thế cho các lỗi trung tâm dữ liệu đầy đủ và sự thất bại thường xuyên của một máy chủ chuyển đổi / cơ sở dữ liệu / tài nguyên khác không thể dễ dàng được nhân đôi.

Một số rất nhỏ các trang web sử dụng các thiết lập đa trung tâm dữ liệu, với 'cân bằng địa lý' giữa các trung tâm dữ liệu.

DNS failover chắc chắn hoạt động tuyệt vời. Tôi đã sử dụng nó trong nhiều năm để tự chuyển lưu lượng giữa các trung tâm dữ liệu hoặc tự động khi hệ thống giám sát phát hiện mất điện, sự cố kết nối hoặc máy chủ bị quá tải. Khi bạn thấy tốc độ hoạt động của nó và khối lượng lưu lượng truy cập trong thế giới thực có thể được thay đổi dễ dàng - bạn sẽ không bao giờ nhìn lại. Tôi sử dụng Zabbix để theo dõi tất cả các hệ thống của mình và các biểu đồ trực quan cho thấy những gì xảy ra trong tình huống chuyển đổi DNS khiến mọi nghi ngờ của tôi bị chấm dứt. Có thể có một số ISP ngoài đó bỏ qua các TTL và có một số người dùng vẫn ở ngoài đó với các trình duyệt cũ - nhưng khi bạn đang xem lưu lượng truy cập từ hàng triệu lượt xem trang mỗi ngày trên 2 vị trí trung tâm dữ liệu và bạn thực hiện dịch chuyển lưu lượng DNS - lưu lượng truy cập còn lại trong đó bỏ qua TTL là buồn cười.

DNS không được thiết kế để chuyển đổi dự phòng - nhưng nó được thiết kế với các TTL hoạt động tuyệt vời cho nhu cầu chuyển đổi dự phòng khi kết hợp với hệ thống giám sát vững chắc. TTL có thể được đặt rất ngắn. Tôi đã sử dụng hiệu quả TTL trong 5 giây trong sản xuất để làm sáng các giải pháp chuyển đổi dự phòng DNS nhanh. Bạn phải có máy chủ DNS có khả năng xử lý tải thêm - và được đặt tên sẽ không cắt nó. Tuy nhiên, powerdns phù hợp với hóa đơn khi được hỗ trợ với cơ sở dữ liệu nhân rộng mysql trên các máy chủ tên dự phòng. Bạn cũng cần một hệ thống giám sát phân tán vững chắc mà bạn có thể tin tưởng để tích hợp chuyển đổi dự phòng tự động. Zabbix hoạt động với tôi - Tôi có thể xác minh sự cố ngừng hoạt động từ nhiều hệ thống Zabbix phân tán gần như ngay lập tức - cập nhật các bản ghi mysql được sử dụng bởi powerdns khi đang di chuyển - và cung cấp khả năng chuyển đổi dự phòng gần như ngay lập tức khi mất điện và tăng lưu lượng truy cập.

Nhưng này - tôi đã xây dựng một công ty cung cấp dịch vụ chuyển đổi dự phòng DNS sau nhiều năm làm cho nó hoạt động cho các công ty lớn. Vì vậy, hãy lấy ý kiến ​​của tôi với một hạt muối. Nếu bạn muốn xem một số biểu đồ lưu lượng truy cập zabbix của các trang web có khối lượng lớn trong thời gian ngừng hoạt động - để tự mình xem chính xác cách thức chuyển đổi dự phòng DNS hoạt động tốt - hãy gửi email cho tôi tôi rất vui được chia sẻ.

Vấn đề với chuyển đổi dự phòng DNS là, trong nhiều trường hợp, nó không đáng tin cậy. Một số ISP sẽ bỏ qua các TTL của bạn, điều đó không xảy ra ngay lập tức ngay cả khi họ tôn trọng các TTL của bạn và khi trang web của bạn hoạt động trở lại, điều đó có thể dẫn đến một số điều kỳ lạ với các phiên khi bộ đệm DNS của người dùng hết thời gian và họ kết thúc qua máy chủ khác.

Thật không may, đó là khá nhiều lựa chọn duy nhất, trừ khi bạn đủ lớn để thực hiện định tuyến (bên ngoài) của riêng bạn.

Ý kiến ​​phổ biến là với DNS RR, khi IP bị hỏng, một số khách hàng sẽ tiếp tục sử dụng IP bị hỏng trong vài phút. Điều này đã được nêu trong một số câu trả lời trước cho câu hỏi và nó cũng được viết trên Wikipedia.

Dù sao,

http://crypto.stanford.edu/dns/dns-rebinding.pdf giải thích rằng điều đó không đúng với hầu hết các trình duyệt HTML hiện tại. Họ sẽ thử IP tiếp theo sau vài giây.

http://www.tenereillo.com/GSLBPageOfShame.htm dường như còn mạnh hơn nữa:

Việc sử dụng nhiều bản ghi A không phải là một mánh khóe trong giao dịch, hoặc một tính năng được hình thành bởi các nhà cung cấp thiết bị cân bằng tải. Giao thức DNS được thiết kế với sự hỗ trợ cho nhiều bản ghi A vì lý do này. Các ứng dụng như trình duyệt và proxy và máy chủ thư sử dụng phần đó của giao thức DNS.

Có thể một số chuyên gia có thể nhận xét và đưa ra lời giải thích rõ ràng hơn về lý do tại sao DNS RR không tốt cho tính sẵn sàng cao.

Cảm ơn,

Valentino

PS: xin lỗi vì liên kết bị hỏng nhưng, với tư cách là người dùng mới, tôi không thể đăng nhiều hơn 1

Tôi đã chạy failover DNS RR trên một trang web sản xuất vừa phải nhưng bị buôn bán nghiêm trọng (qua hai khu vực địa lý) trong nhiều năm.

Nó hoạt động tốt, nhưng có ít nhất ba sự tinh tế tôi đã học được một cách khó khăn.

1) Trình duyệt sẽ chuyển từ IP không hoạt động sang IP hoạt động sau 30 giây (lần cuối tôi kiểm tra) nếu cả hai được coi là hoạt động trong bất kỳ DNS nào được lưu trong bộ nhớ cache có sẵn cho khách hàng của bạn. Đây là một điều tốt.

Nhưng việc "một nửa" người dùng của bạn đợi 30 giây là không thể chấp nhận được, vì vậy bạn có thể muốn cập nhật các bản ghi TTL của mình trong vài phút, không phải vài ngày hoặc vài tuần để trong trường hợp mất điện, bạn có thể nhanh chóng gỡ bỏ máy chủ xuống từ DNS của bạn. Những người khác đã ám chỉ điều này trong phản ứng của họ.

2) Nếu một trong những máy chủ tên của bạn (hoặc một trong hai khu vực địa lý của bạn) hoàn toàn phục vụ tên miền vòng tròn của bạn và nếu một trong số chúng bị hỏng, tôi mơ hồ nhớ lại bạn có thể gặp phải các vấn đề khác khi cố gắng loại bỏ điều đó máy chủ tên bị giảm từ DNS nếu bạn chưa thiết lập / hết hạn sử dụng cho máy chủ tên của bạn ở một giá trị đủ thấp. Tôi có thể có các chi tiết kỹ thuật sai ở đây, nhưng có nhiều hơn một cài đặt TTL mà bạn cần có để thực sự bảo vệ chống lại các điểm thất bại duy nhất.

3) Nếu bạn xuất bản API web, dịch vụ REST, v.v., những dịch vụ này thường không được trình duyệt gọi, và do đó, theo tôi, chuyển đổi dự phòng DNS bắt đầu hiển thị các lỗ hổng thực sự. Đây có thể là lý do tại sao một số người nói, như bạn nói "nó không được khuyến khích". Đây là lý do tại sao tôi nói vậy. Đầu tiên, các ứng dụng tiêu thụ các URL đó thường không phải là trình duyệt, vì vậy chúng thiếu các thuộc tính / logic chuyển đổi dự phòng 30 giây của các trình duyệt phổ biến. Thứ hai, mục nhập DNS thứ hai có được gọi hay thậm chí DNS được thăm dò lại hay không phụ thuộc rất nhiều vào chi tiết lập trình cấp thấp của các thư viện mạng trong các ngôn ngữ lập trình được sử dụng bởi các máy khách API / REST này, cộng với chính xác cách chúng được gọi bởi ứng dụng khách API / REST. (Dưới nắp của chúng, thư viện có gọi get_addr không và khi nào? Nếu ổ cắm bị treo hoặc đóng, ứng dụng có mở lại ổ cắm mới không? Có logic nào hết thời gian không? V.v.)

Đó là giá rẻ, được thử nghiệm tốt và "chủ yếu là hoạt động". Vì vậy, như với hầu hết mọi thứ, số dặm của bạn có thể thay đổi.

Có một nhóm người sử dụng chúng tôi (Dyn) để chuyển đổi dự phòng. Đó là lý do tương tự các trang web có thể thực hiện một trang trạng thái khi chúng có thời gian chết (nghĩ về những thứ như Fail Whale của Twitter) ... hoặc chỉ đơn giản là định tuyến lại lưu lượng truy cập dựa trên các TTL. Một số người có thể nghĩ rằng DNS Failover là ghetto ... nhưng chúng tôi nghiêm túc thiết kế mạng của chúng tôi với chuyển đổi dự phòng ngay từ đầu ... để nó hoạt động tốt như phần cứng. Tôi không chắc DME làm như thế nào, nhưng chúng tôi có 3 trong số 17 PoP được phát sóng gần nhất của chúng tôi giám sát máy chủ của bạn từ vị trí gần nhất. Khi nó phát hiện từ hai trong số ba cái đó, chúng ta chỉ cần định tuyến lại lưu lượng đến IP khác. Thời gian chết duy nhất là dành cho những người được yêu cầu trong phần còn lại của khoảng thời gian đó.

Một số người thích sử dụng cả hai máy chủ cùng một lúc ... và trong trường hợp đó có thể thực hiện một số việc như cân bằng tải vòng tròn ... hoặc cân bằng tải dựa trên địa lý. Đối với những người thực sự quan tâm đến hiệu suất ... trình quản lý lưu lượng thời gian thực của chúng tôi sẽ giám sát từng máy chủ ... và nếu máy chủ chậm hơn ... hãy định tuyến lại lưu lượng đến tốc độ nhanh nhất dựa trên IP mà bạn liên kết trong tên máy chủ của mình. Một lần nữa ... điều này hoạt động dựa trên các giá trị bạn đặt vào UI / API / Portal của chúng tôi.

Tôi đoán quan điểm của tôi là ... chúng tôi đã thiết kế chuyển đổi dự phòng. Mặc dù DNS không được tạo để chuyển đổi dự phòng khi nó được tạo ban đầu ... mạng DNS của chúng tôi được thiết kế để triển khai nó ngay từ đầu. Nó thường có thể hiệu quả như phần cứng..không khấu hao hoặc chi phí phần cứng. Hy vọng điều đó không khiến tôi nghe có vẻ khập khiễng khi cắm Dyn ... có rất nhiều công ty khác làm điều đó ... Tôi chỉ đang nói từ quan điểm của nhóm chúng tôi. Hi vọng điêu nay co ich...

Một tùy chọn khác là thiết lập máy chủ tên 1 ở vị trí A và máy chủ tên 2 ở vị trí B, nhưng thiết lập từng máy chủ để tất cả các bản ghi A về lưu lượng điểm NS1 thành IP cho vị trí A và trên NS2 tất cả các bản ghi A đều trỏ đến IP cho vị trí B. Sau đó, đặt các TTL của bạn cho một số rất thấp và đảm bảo rằng bản ghi tên miền của bạn tại cơ quan đăng ký đã được thiết lập cho NS1 và NS2. Theo cách đó, nó sẽ tự động tải số dư và không thành công nếu một máy chủ hoặc một liên kết đến một vị trí bị hỏng.

Tôi đã sử dụng phương pháp này theo một cách hơi khác. Tôi có một địa điểm với hai ISP và sử dụng phương pháp này để điều hướng lưu lượng truy cập qua mỗi liên kết. Bây giờ, có thể bảo trì nhiều hơn một chút so với bạn sẵn sàng ... nhưng tôi đã có thể tạo một phần mềm đơn giản tự động lấy bản ghi NS1, cập nhật địa chỉ IP bản ghi cho các vùng được chọn và đẩy các vùng đó sang NS2.

Thay thế là một hệ thống chuyển đổi dự phòng dựa trên BGP. Nó không đơn giản để thiết lập, nhưng nó phải là bằng chứng đạn. Thiết lập trang web A ở một vị trí, trang web B trong một giây tất cả có địa chỉ IP cục bộ, sau đó nhận một lớp C hoặc khối ip khác có thể di động và thiết lập chuyển hướng từ IP di động sang IP cục bộ.

Có những cạm bẫy, nhưng nó tốt hơn các giải pháp dựa trên DNS nếu bạn cần mức độ kiểm soát đó.

Một tùy chọn cho chuyển đổi dự phòng đa trung tâm dữ liệu là đào tạo người dùng của bạn. Chúng tôi quảng cáo cho khách hàng của mình rằng chúng tôi cung cấp nhiều máy chủ ở nhiều thành phố và trong email đăng ký của chúng tôi và bao gồm các liên kết trực tiếp đến từng "máy chủ" để người dùng biết nếu một máy chủ ngừng hoạt động, họ có thể sử dụng liên kết đến máy chủ khác.

Điều này hoàn toàn bỏ qua vấn đề chuyển đổi dự phòng DNS bằng cách chỉ duy trì nhiều tên miền. Người dùng truy cập www.company.com hoặc company.com và đăng nhập sẽ được chuyển hướng đến server1.company.com hoặc server2.company.com và có lựa chọn đánh dấu trang trong số đó nếu họ nhận thấy họ có hiệu suất tốt hơn bằng cách này hoặc cách khác . Nếu một người đi xuống, người dùng được đào tạo để đi đến máy chủ khác.

Tôi đã sử dụng cân bằng trang web và chuyển đổi dự phòng dựa trên DNS trong mười năm qua và có một số vấn đề, nhưng những vấn đề này có thể được giảm nhẹ. BGP, trong khi một số cách vượt trội không phải là giải pháp 100% với độ phức tạp tăng lên, có thể là chi phí phần cứng bổ sung, thời gian hội tụ, v.v ...

Tôi đã tìm thấy kết hợp cân bằng tải cục bộ (dựa trên mạng LAN), GSLB và lưu trữ vùng dựa trên đám mây đang hoạt động khá tốt để khắc phục một số vấn đề thường liên quan đến cân bằng tải DNS.

Tất cả những câu trả lời này đều có giá trị đối với họ, nhưng tôi nghĩ nó thực sự phụ thuộc vào những gì bạn đang làm và ngân sách của bạn là gì. Tại CloudfloorDNS, một tỷ lệ lớn doanh nghiệp của chúng tôi là DNS và cung cấp không chỉ DNS nhanh, mà cả các tùy chọn TTL và chuyển đổi dự phòng DNS thấp. Chúng tôi sẽ không kinh doanh nếu điều này không hoạt động và làm việc tốt.

Nếu bạn là một tập đoàn đa quốc gia với ngân sách không giới hạn về thời gian hoạt động, vâng, bộ cân bằng tải GSLB phần cứng và trung tâm dữ liệu cấp 1 là tuyệt vời, nhưng DNS của bạn vẫn cần phải nhanh và ổn định. Như nhiều bạn đã biết, DNS là một khía cạnh quan trọng của bất kỳ cơ sở hạ tầng nào, ngoài chính tên miền, đó là dịch vụ cấp thấp nhất mà mọi phần khác trong sự hiện diện trực tuyến của bạn sử dụng. Bắt đầu với một công ty đăng ký tên miền vững chắc, DNS cũng quan trọng như việc không để tên miền của bạn hết hạn. DNS đi xuống, điều đó có nghĩa là toàn bộ khía cạnh trực tuyến của tổ chức của bạn cũng bị sập!

Khi sử dụng DNS Failover, các khía cạnh quan trọng khác là giám sát máy chủ (luôn luôn kiểm tra nhiều vị trí địa lý và luôn luôn kiểm tra nhiều nhất (ít nhất là 3) để tránh các lỗi tích cực) và quản lý bản ghi DNS đúng cách. Chỉ số TTL thấp và một số tùy chọn với chuyển đổi dự phòng có thể biến điều này thành một quy trình liền mạch và đánh bại việc thức dậy với máy nhắn tin vào giữa đêm nếu bạn là quản trị viên hệ thống.

Nhìn chung, DNS Failover thực sự hoạt động và có thể rất phải chăng. Trong hầu hết các trường hợp từ chúng tôi hoặc hầu hết các nhà cung cấp DNS được quản lý, bạn sẽ nhận được Anycast DNS cùng với giám sát và chuyển đổi dự phòng cho một phần chi phí của các tùy chọn phần cứng.

Vì vậy, câu trả lời thực sự là có, nó hoạt động, nhưng nó là cho tất cả mọi người và mọi ngân sách? Có thể không, nhưng cho đến khi bạn thử nó và tự kiểm tra, thật khó để bỏ qua nếu bạn là một doanh nghiệp vừa và nhỏ với ngân sách CNTT hạn chế muốn có thời gian hoạt động tốt nhất có thể.

"và tại sao bạn tận dụng cơ hội của mình để sử dụng nó cho hầu hết các môi trường sản xuất (mặc dù nó tốt hơn không có gì)."

Trên thực tế, "tốt hơn không có gì" được thể hiện tốt hơn là "lựa chọn duy nhất" khi sự hiện diện rất đa dạng về mặt địa lý. Cân bằng tải phần cứng là tuyệt vời cho một điểm hiện diện, nhưng một điểm hiện diện duy nhất cũng là một điểm thất bại duy nhất.

Có rất nhiều trang web lớn sử dụng thao tác lưu lượng truy cập dựa trên dns để có hiệu quả tốt. Họ là loại trang web biết trên cơ sở hàng giờ nếu bán hàng bị tắt. Có vẻ như họ là người cuối cùng đứng lên vì "nắm lấy cơ hội của bạn sử dụng nó cho hầu hết các môi trường sản xuất". Thật vậy, họ đã xem xét các lựa chọn của họ một cách cẩn thận, lựa chọn công nghệ và trả tiền tốt cho nó. Nếu họ nghĩ rằng một cái gì đó tốt hơn họ sẽ rời đi trong tích tắc. Thực tế là họ vẫn chọn nói nhiều về việc sử dụng thế giới thực.

Chuyển đổi dự phòng dựa trên Dns chịu một độ trễ nhất định. Không có cách nào xung quanh nó. Nhưng, nó vẫn là cách tiếp cận khả thi duy nhất để quản lý failover trong một kịch bản đa pop. Là lựa chọn duy nhất, nó còn hơn cả "tốt hơn không có gì".

Ngày nay các bộ cân bằng tải toàn cầu tốt hoạt động bằng kỹ thuật đó và hoạt động khá tốt. Kiểm tra ví dụ Trình quản lý lưu lượng Azure https://azure.microsoft.com/en-us/service/traffic-manager/

Nếu bạn muốn tìm hiểu thêm, hãy đọc ghi chú ứng dụng tại

http://edgedirector.com

Chúng bao gồm: chuyển đổi dự phòng, cân bằng tải toàn cầu và một loạt các vấn đề liên quan.

Nếu kiến ​​trúc phụ trợ của bạn cho phép nó, tùy chọn tốt hơn là cân bằng tải toàn cầu với tùy chọn chuyển đổi dự phòng. Bằng cách đó, tất cả các máy chủ và băng thông đang hoạt động càng nhiều càng tốt. Thay vì chèn thêm một máy chủ khả dụng khi gặp sự cố, thiết lập này rút một máy chủ bị lỗi khỏi dịch vụ cho đến khi được phục hồi.

Câu trả lời ngắn gọn: nó hoạt động, nhưng bạn phải hiểu những hạn chế.

Tôi tin rằng ý tưởng về chuyển đổi dự phòng đã được dự định để phân cụm, nhưng vì nó cũng có thể chạy một mình nên vẫn có thể hoạt động trong tình trạng sẵn có một-một.

Tôi muốn khuyên bạn nên chọn A, chọn một trung tâm dữ liệu đa dạng trên AS hoặc B của chính nó, lưu trữ các máy chủ tên của bạn trong một đám mây công cộng. Thật sự không chắc là EC2, hoặc HP hoặc IBM sẽ ngừng hoạt động. Chỉ là một ý nghĩ. Mặc dù DNS hoạt động như một bản sửa lỗi, nhưng nó chỉ đơn giản là một bản sửa lỗi cho một thiết kế kém trong nền tảng mạng trong trường hợp này.

Một tùy chọn khác, tùy thuộc vào môi trường của bạn, là sử dụng kết hợp với IPSLA, PBR và FHRP để thực hiện các nhu cầu dự phòng của bạn.