Cách chính xác để thiết lập DNS chính / phụ / xóa để dự phòng và giảm độ trễ?

Tôi nghĩ DNS chính / phụ cho mục đích dự phòng là đơn giản. Tôi hiểu rằng bạn nên có một chính và ít nhất một thứ cấp, và bạn nên thiết lập thứ cấp của mình ở một vị trí địa lý khác nhau, nhưng cũng đằng sau một bộ định tuyến khác (ví dụ: /server/48087 / why-are-there-many-nameervers-for-my-domain )

Hiện tại, chúng tôi có hai máy chủ tên cả trong trung tâm dữ liệu chính của chúng tôi. Gần đây, chúng tôi đã bị mất điện vì nhiều lý do khác nhau đã loại bỏ cả máy chủ tên và khiến chúng tôi và khách hàng của chúng tôi không hoạt động DNS trong vài giờ. Tôi đã yêu cầu nhóm sysadmin của mình hoàn tất việc thiết lập máy chủ DNS trong một trung tâm dữ liệu khác và định cấu hình nó làm máy chủ tên phụ.

Tuy nhiên, các hệ thống quản trị hệ thống của chúng tôi cho rằng điều này không giúp ích nhiều nếu trung tâm dữ liệu khác ít nhất không đáng tin cậy như trung tâm dữ liệu chính. Họ tuyên bố rằng hầu hết khách hàng vẫn sẽ không tìm kiếm đúng cách hoặc hết thời gian quá lâu, khi trung tâm dữ liệu chính bị hỏng.

Cá nhân, tôi tin rằng chúng tôi không phải là công ty duy nhất có loại vấn đề này và rất có thể nó đã là một vấn đề được giải quyết. Tôi không thể tưởng tượng tất cả những công ty internet bị ảnh hưởng bởi loại vấn đề của chúng tôi. Tuy nhiên, tôi không thể tìm thấy các tài liệu trực tuyến tốt giải thích những gì xảy ra trong các trường hợp thất bại (ví dụ: thời gian chờ của khách hàng) và cách khắc phục chúng.

Tôi có thể sử dụng những lý lẽ nào để chọc vào lỗ hổng trong lý luận của hệ thống của chúng tôi? Bất kỳ tài nguyên trực tuyến nào tôi có thể tham khảo để hiểu rõ hơn các vấn đề mà họ cho là tồn tại?

Một số lưu ý bổ sung sau khi đọc trả lời:

• chúng tôi trên Linux
• chúng tôi có thêm nhu cầu DNS phức tạp; các mục nhập DNS của chúng tôi được quản lý bởi một số phần mềm tùy chỉnh, với BIND hiện đang bị trượt khỏi triển khai DNS Twisted và một số chế độ xem trong hỗn hợp. Tuy nhiên, chúng tôi hoàn toàn có khả năng thiết lập máy chủ DNS của riêng mình tại một trung tâm dữ liệu khác.
• Tôi đang nói về DNS có thẩm quyền để người ngoài tìm thấy máy chủ của chúng tôi, chứ không phải máy chủ DNS đệ quy cho các máy khách cục bộ của chúng tôi.

Có một tài liệu "Thực tiễn tốt nhất" thực sự tuyệt vời, mặc dù khá kỹ thuật có thể chứng minh hữu ích khi chống lại sysadmin của bạn. http://www.cisco.com/web/about/security/intellect/dns-bcp.html

Nếu anh ấy / cô ấy không nhận ra tính hợp lệ của các bài viết được viết bởi Cisco, thì bạn cũng có thể ngừng tranh cãi với sysadmin - đi lên một cấp quản lý.

Nhiều tài liệu "Thực tiễn tốt nhất" khác khuyên bạn nên phân tách máy chủ tên chính và phụ của bạn không chỉ bằng khối IP, mà bằng vị trí thực tế. Trên thực tế, RFC 2182 khuyến nghị rằng các dịch vụ DNS thứ cấp được phân tách theo địa lý. Đối với nhiều công ty, điều này có nghĩa là thuê một máy chủ trong một trung tâm dữ liệu khác hoặc đăng ký vào một nhà cung cấp DNS được lưu trữ như ZoneEdit hoặc UltraDNS .

Tuy nhiên, các hệ thống quản trị hệ thống của chúng tôi cho rằng điều này không giúp ích nhiều nếu trung tâm dữ liệu khác ít nhất không đáng tin cậy như trung tâm dữ liệu chính. Họ tuyên bố rằng hầu hết khách hàng vẫn sẽ không tìm kiếm đúng cách hoặc hết thời gian quá lâu, khi trung tâm dữ liệu chính bị hỏng.

Ah, trọng tâm là đáng tin cậy . Có vẻ như họ đang lấy một cái jab ở liên kết của bạn ra bên ngoài, thay vì thiết lập DNS thứ cấp. Tất cả đều giống nhau, hãy thiết lập DNS thứ cấp và tiến hành từ đó. Nó sẽ giúp tải và sẽ đẩy mọi thứ lên một cách khó khăn ... nhưng hãy hỏi xem tại sao họ nghĩ rằng vị trí khác không đáng tin cậy .

Cá nhân, tôi tin rằng chúng tôi không phải là công ty duy nhất có loại vấn đề này và rất có thể nó đã là một vấn đề được giải quyết. Tôi không thể tưởng tượng tất cả những công ty internet bị ảnh hưởng bởi loại vấn đề của chúng tôi.

Bạn không phải là công ty duy nhất và điều này có lẽ đã được thử nghiệm hàng triệu lần trong các công ty trên toàn thế giới.

Tuy nhiên, tôi không thể tìm thấy các tài liệu trực tuyến tốt giải thích những gì xảy ra trong các trường hợp thất bại (ví dụ: thời gian chờ của khách hàng) và cách khắc phục chúng.

Tôi có thể sử dụng những lý lẽ nào để chọc vào lỗ hổng trong lý luận của hệ thống của chúng tôi? Bất kỳ tài nguyên trực tuyến nào tôi có thể tham khảo để hiểu rõ hơn các vấn đề mà họ cho là tồn tại?

• Tôi đang nói về DNS có thẩm quyền để người ngoài tìm thấy máy chủ của chúng tôi, chứ không phải máy chủ DNS đệ quy cho các máy khách cục bộ của chúng tôi.

Bạn có thể thực hiện tất cả mọi việc, bao gồm thiết lập dịch vụ DNS bên ngoài được đăng ký làm cơ quan cho khu vực của bạn, nhưng bí mật làm cho các máy chủ ủy quyền (bên ngoài) trở thành máy chủ DNS của riêng bạn (bên trong). Cấu hình này thật kinh khủng, sai, cho thấy tôi thực sự là một SysAdmin xấu xa và một con mèo con chết mỗi khi tôi giới thiệu nó. Nhưng nó có hai điều:

• Bạn nhận được dịch vụ DNS của mình để xử lý gánh nặng tải, đưa ra các câu hỏi về khả năng của DNS (nội bộ) của riêng bạn dưới dạng mô phỏng.
• Bạn nhận được dịch vụ DNS của mình để duy trì trong khi các máy chủ DNS nội bộ của bạn có thể ngừng hoạt động, vì vậy việc liên kết của bạn đáng tin cậy đến mức nào - điều quan trọng là nhà cung cấp dịch vụ DNS của bạn đáng tin cậy đến mức nào .

Những lý do mà đây là điều sai trái để làm:

• Bạn sẽ thiết lập cái được gọi là "máy chủ tên lén lút", bởi vì trong khi nó sẽ hiển thị trong hồ sơ vùng của bạn và bạn có thể truy vấn IP để biết tên của máy chủ, nó sẽ không bao giờ bị bên ngoài chạm vào. Truy vấn khách hàng sẽ không bao giờ đạt được nó.
• Mặc dù DNS của bạn sẽ tiếp tục hoạt động tốt (vì dịch vụ được lưu trữ của bạn sẽ giải quyết được vấn đề) nhưng điều đó không có nghĩa là bất kỳ trang web nào bạn có sẽ hoạt động nếu kết nối internet của bạn bị hỏng, nghĩa là, nó chỉ giải quyết được một nửa vấn đề . Nó thực sự có vẻ như có những vấn đề khác mà các quản trị viên quan tâm.

Thật không may, trình phân giải DNS của Linux dường như không hỗ trợ trực tiếp để phát hiện và thực hiện các lỗi cho máy chủ DNS. Nó tiếp tục cung cấp các yêu cầu cho máy chủ tên giải quyết chính của bạn, chờ thời gian chờ được cấu hình, thử lại, v.v.

Điều này thường có nghĩa là sự chậm trễ lên đến 30 giây cho bất kỳ yêu cầu. Không có đầu tiên cố gắng thứ cấp miễn là chính là xuống.

Tôi muốn giải quyết vấn đề này vì máy chủ tên giải quyết Amazon EC2 của chúng tôi không thể truy cập được đối với nhiều nhân viên của chúng tôi. Điều này gây ra sự chậm trễ lớn trong quy trình của chúng tôi và thậm chí thời gian chết trong một số trường hợp vì chúng tôi dựa vào độ phân giải. Tôi muốn có một chuyển đổi dự phòng tốt cho máy chủ tên Google / Level3 trong trường hợp Amazon lại gặp sự cố. Và quay trở lại càng sớm càng tốt, bởi vì sau đó Amazon sẽ phân giải tên máy chủ thành địa chỉ địa phương nơi áp dụng, giải quyết trong độ trễ thấp hơn, ví dụ như giao tiếp cá thể.

Nhưng bất kể usecase là gì, cần có chuyển đổi dự phòng tốt hơn. Tôi muốn giải quyết điều này. Tôi muốn tránh xa các trình tiện ích, dịch vụ ủy quyền, v.v. Vì điều đó sẽ chỉ giới thiệu thêm nhiều điểm thất bại. Tôi muốn sử dụng một công nghệ cổ xưa và mạnh mẽ nhất có thể.

Tôi quyết định sử dụng crontab & bash và viết nsfailover.sh . Hi vọng điêu nay co ich.

Nghe có vẻ như vấn đề là các khách hàng có thể là bất cứ ai, bất cứ nơi nào mà nhìn thấy hai máy chủ DNS và nếu một máy chủ bị lỗi, họ sẽ không chuyển sang máy chủ thứ cấp hoặc có một khoảng thời gian dài trước khi họ làm.

Tôi đồng ý rằng các máy chủ DNS chính và phụ nên được đặt tại các cơ sở khác nhau như một cách thực hành tốt nhất, nhưng tôi không thấy cách đó sẽ khắc phục vấn đề cụ thể này.

Nếu khách hàng sẽ khăng khăng truy vấn một địa chỉ IP cụ thể, bỏ qua địa chỉ IP phụ (hoặc mất một thời gian để hết thời gian đến đó), thì bạn chỉ cần đưa ra giải pháp giúp địa chỉ IP đó hoạt động, ngay cả khi máy chủ chính bị sập.

Một số hướng để khám phá sẽ là một bộ cân bằng tải có thể chuyển hướng lưu lượng truy cập cho một địa chỉ IP duy nhất đến nhiều máy chủ tại các trung tâm dữ liệu khác nhau; hoặc có lẽ định tuyến anycast.

Miễn là mỗi trung tâm dữ liệu của bạn nằm trên các mạch khác nhau (lý tưởng là với các nhà cung cấp ngược dòng khác nhau trên đám mây), bạn có thể thiết lập DNS khá đáng tin cậy chỉ với hai trung tâm dữ liệu. Bạn chỉ cần đảm bảo rằng công ty đăng ký lựa chọn của bạn điền các bản ghi keo thích hợp vào các máy chủ lớn trên bầu trời.

Thiết lập của chúng tôi là:

• 2 trung tâm dữ liệu vật lý (mạch riêng, ISP và nhà cung cấp ngược dòng)
• 2 máy chủ truy vấn vật lý trong một cụm phía sau SLB tại mỗi cơ sở
• 2 thiết bị cân bằng tải để phục vụ các bản ghi cụ thể mà chúng tôi muốn quản lý số dư giữa hai cơ sở dữ liệu
• ẩn chủ có thể truy cập nội bộ bởi cả hai cụm máy chủ (tôi tin tưởng rất mạnh vào các thiết lập chính ẩn để bảo mật)

Thiết lập này đã đủ hiệu quả để cung cấp cho chúng tôi khoảng 5 9 giờ hoạt động trong 6 hoặc 7 năm qua, ngay cả khi máy chủ thỉnh thoảng ngừng hoạt động để cập nhật, v.v. Nếu bạn sẵn sàng chi thêm một vài đô la, bạn có thể xem xét thuê ngoài lưu trữ của khu vực với một người như ultradns ...

Đối với cuộc hội thoại tải mà KPWINC đã đề cập, điều đó đúng 100%. Nếu trung tâm dữ liệu nhỏ nhất của bạn không thể xử lý 100% tải của bạn, thì dù sao bạn cũng có khả năng bị rút xương vì sự cố ngừng hoạt động của bạn sẽ xảy ra khi bạn ít muốn nhất =)

Tôi lấy tải tối đa từ tất cả các bộ định tuyến biên của mình, cộng tất cả chúng lại với nhau và sau đó chia cho 0,65 ... đó là băng thông tối thiểu mà chúng ta phải có tại mỗi trung tâm dữ liệu. Tôi đưa quy tắc đó vào vị trí khoảng 5 năm trước, với một số tài liệu để chứng minh rằng tôi đã thu thập được từ CCO và về internet, và nó chưa bao giờ làm chúng tôi thất bại. Tuy nhiên, bạn phải kiểm tra các số liệu thống kê ít nhất mỗi quý. Chúng tôi đã tăng lưu lượng truy cập gần gấp 3 lần từ tháng 11 đến tháng 2 năm ngoái và tôi đã không chuẩn bị cho điều đó. Mặt sáng đó là tình huống đã cho phép tôi tạo ra một số dữ liệu cứng rất rõ ràng với mức tải 72% trên mạch WAN của chúng tôi, chúng tôi bắt đầu bỏ các gói. Không có lời biện minh bổ sung nào từng được yêu cầu đối với tôi về băng thông nhiều hơn.

Tôi nhận ra từ việc đọc mô tả của bạn rằng không rõ liệu bạn có nghĩa là DNS có thẩm quyền để người ngoài tìm thấy máy chủ của bạn hay máy chủ DNS đệ quy cho các máy khách cục bộ của bạn. Hành vi của hai người đó rất khác nhau.

Đối với các máy chủ DNS có thẩm quyền, "máy khách" sẽ là các máy chủ DNS khác có bộ nhớ đệm và nhiều thông minh. Họ sẽ có xu hướng thử nhiều máy chủ cùng một lúc nếu máy chủ đầu tiên chậm và sẽ có xu hướng thích máy chủ trả lời nhanh hơn. Thời gian chết cho một trung tâm dữ liệu trong trường hợp đó sẽ có tác động hiệu suất rất nhẹ.

Đối với các máy chủ DNS đệ quy, các máy khách là các máy khách cục bộ của bạn có thể có các máy chủ DNS được liệt kê trong DHCP. Họ sẽ thử máy chủ của mình theo thứ tự được liệt kê mỗi lần, với thời gian chờ rất dài (vài giây) trước khi chuyển từ máy chủ đầu tiên sang máy chủ thứ hai.

Nếu trung tâm dữ liệu chính của bạn không hoạt động, không ai có thể truy cập các máy chủ đó, nhưng thường thì các lỗi từ đó dễ hiểu hơn các lỗi từ các máy chủ DNS không thể truy cập. "Không thể liên lạc với máy chủ" hoặc "hết thời gian kết nối" thay vì "không thể tìm thấy máy chủ" hoặc "không có máy chủ như vậy". Chẳng hạn, hầu hết các máy chủ SMTP sẽ xếp hàng thư trong một tuần nếu họ thấy máy chủ trong DNS nhưng không thể truy cập được; nếu họ không thể tìm thấy nó trong DNS, họ có thể từ chối ngay cả khi cố gắng gửi nó đến miền của bạn.

DNS thứ cấp được phân tách theo địa lý và mạng là một điều tốt. Bạn có thể giao dịch DNS thứ cấp với một công ty thân thiện và có rất nhiều nhà cung cấp DNS bạn có thể trả tiền để làm điều đó cho bạn. Một số nhà đăng ký cũng có DNS phụ như một dịch vụ.

Thomas,

Sau khi đọc cập nhật của bạn, tôi đã sửa bài đăng của mình (bài trước có tham khảo phần mềm Windows).

Tôi gần như nghe có vẻ như sysadmin của bạn đang nói với bạn rằng vị trí thứ cấp của bạn không có phần cứng cần thiết để xử lý FULL LOAD?

Nghe có vẻ như anh ta đang nói: "Này anh bạn, nếu vị trí chính của chúng tôi (bao gồm DNS chính) bị hỏng thì DNS là RẤT NHIỀU lo lắng của chúng tôi bởi vì nếu COLO1 không hoạt động thì dù sao thì COLO2 cũng không thể xử lý tải."

Nếu đó là trường hợp, thì tôi sẽ đề nghị bạn xem qua cơ sở hạ tầng của bạn và thử và đưa ra một thiết kế tốt hơn. Điều này nói dễ hơn làm, đặc biệt là bây giờ bạn đang sống trong môi trường sản xuất.

Ngoài ra, trong một thế giới hoàn hảo, COLO1 và COLO2 sẽ có thể đứng một mình và xử lý tải của bạn.

Khi đã có ... DNS thực sự không có gì khác ngoài việc có đủ máy chủ DNS với khả năng làm mới đủ nhanh và nếu một bên thất bại, bạn có thể viết lại DNS của mình để trỏ đến các máy chủ đang TĂNG.

Tôi đã sử dụng phương pháp này trong các môi trường có kích thước nhỏ đến hợp lý và nó hoạt động rất tốt. Chuyển đổi dự phòng thường mất ít hơn 10 phút.

Bạn chỉ cần đảm bảo rằng các máy chủ DNS của bạn có thể xử lý tải thêm của một TTL ngắn (thời gian tồn tại).

Hi vọng điêu nay co ich.

Sysadins của bạn (hầu hết) sai.

Các máy chủ đệ quy truy vấn các máy chủ có thẩm quyền của bạn sẽ nhận thấy rất nhanh nếu một trong hai trang web không phản hồi.

Có, có một số khả năng khách hàng có thể gặp phải độ trễ độ phân giải DNS rất khiêm tốn khi bị ngừng hoạt động, nhưng họ sẽ chỉ là một hoặc hai giây và một khi các máy chủ DNS của chính khách hàng biết rằng một trong các máy chủ sẽ ngừng sử dụng các máy chủ còn lại ưu tiên cho máy chủ bị lỗi.

Nếu cần thiết (để xoa dịu các sysadmin) tiếp tục chạy hai máy chủ tại trung tâm dữ liệu chính của bạn, nhưng hãy đặt ít nhất một máy chủ bên ngoài.

Một máy chủ dns thứ cấp không bao giờ bị tổn thương, tùy thuộc vào nơi nó được lưu trữ, nó sẽ cung cấp cho bạn ít nhiều chức năng.

Nếu máy chủ chính của bạn thất bại, một máy phụ có thể tiếp quản bất kể nó ngồi cạnh nó hay ở một địa điểm xa. Tuy nhiên, nếu đường lên trung tâm dữ liệu của bạn không thành công, bạn vẫn có thể nhận được phản hồi DNS từ máy chủ trong một trung tâm dữ liệu khác nhưng dù sao bạn cũng không thể truy cập máy chủ của mình. Vì vậy, người dùng cuối của bạn sẽ không được hưởng lợi trực tiếp từ DNS thứ cấp ở vị trí xa.

Các máy khách khác nhau phản ứng theo các cách khác với các máy chủ DNS không khả dụng vì vậy có một số sự thật đối với các máy khách hết thời gian, nhưng không phải tất cả.

Tuy nhiên, một DNS thứ cấp trong một trung tâm dữ liệu từ xa sẽ vẫn có khả năng giải quyết địa chỉ IP của máy chủ mà bạn muốn truy cập để bạn có thể gỡ lỗi định tuyến và xem khi nào chúng xuất hiện trở lại. Và nếu bạn đã thiết lập chính xác các máy chủ MX thứ cấp, bạn thậm chí sẽ không mất bất kỳ thư nào.