Có cách nào để giao thức DNS tự nhiên có thể giữ một bản sao lưu Một địa chỉ máy chủ bản ghi, như máy chủ tên dự phòng hoặc bản ghi máy chủ thư không? Khi tìm kiếm này, tôi chỉ thấy kết quả trên máy chủ tên dự phòng (bản ghi NS).
Nếu không có cách nào để DNS hỗ trợ sao lưu bản ghi A, cách tốt nhất để mô phỏng kết quả là gì để người dùng sẽ được chuyển đến máy chủ hoạt động trong trường hợp máy chủ chính không phản hồi?
Câu trả lời:
Ừ kiểu vậy, chắc vậy.
Có hai điều bạn có thể làm ở đây: Nếu bạn đặt nhiều bản ghi A vào máy chủ DNS của mình cho một tên cụ thể, thì tất cả chúng sẽ được phục vụ cho khách hàng và những khách hàng đó sẽ chọn một từ để thiết lập để kết nối, có nghĩa là lưu lượng truy cập sẽ được "phân phối" đồng đều giữa tất cả các trang web cùng một lúc. Đây thực sự không phải là những gì bạn dường như đang mô tả, nhưng đó là một tình huống phổ biến (mặc dù tôi không tin tưởng nó, vì nhiều lý do).
Tùy chọn khác là bạn chỉ đặt một bản ghi A trong máy chủ DNS của mình và máy chủ DNS (hoặc một cái gì đó có tính chất đối với nó, như tập lệnh giám sát) sẽ theo dõi địa chỉ chính của trang web của bạn và nếu nó bị lỗi thì máy chủ DNS sẽ bị lỗi hồ sơ được thay đổi để trang web khác của bạn. Điều này có nghĩa là chỉ có một trang web sẽ nhận được lưu lượng truy cập tại một thời điểm.
Nhược điểm của chiến lược thứ hai này là bộ nhớ đệm DNS. Bất cứ ai có địa chỉ trang web cũ sẽ là SOL cho đến khi các mục trong bộ đệm DNS chứa địa chỉ cũ bị xóa. Điều này có nghĩa là bạn phải giữ cho các TTL của bạn ở mức thấp (tăng tải cho cơ sở hạ tầng DNS của bạn, mặc dù điều đó hiếm khi là một vấn đề thực tế), nhưng vẫn còn vấn đề về bộ đệm DNS "lừa đảo", không tôn trọng các TTL. Đây là một nỗi đau lớn cho bất cứ ai những người đã từng phải thay đổi các mục nhập DNS, nhưng họ tệ hơn gấp triệu lần đối với bất kỳ ai cần thay đổi các mục nhập DNS "thường xuyên" (hy vọng trang web của bạn không bị sập nhiều lần trong ngày, nhưng về cơ bản, bất cứ ai cũng vậy đằng sau một trong những bộ đệm DNS lưu trữ sai này sẽ thấy trang web của bạn bị "ngừng hoạt động" trong một khoảng thời gian cực kỳ dài và chỉ cần thử giải thích với họ rằng đó là bộ đệm DNS của họ có lỗi ...
Nói tóm lại, tôi sẽ không làm điều đó cho một trang web, bởi vì có nhiều cách tốt hơn để giảm thiểu bất kỳ rủi ro nào bạn nghĩ đến, nhưng bạn sẽ cần mô tả rủi ro đó nếu bạn muốn đề xuất về cách giảm thiểu nó.
Mọi người dường như nghĩ rằng bạn đang nói về máy chủ WWW, mặc dù bạn đã viết rõ ràng
Sự thật bị bỏ qua là dịch vụ HTTP là ngoại lệ và không phải là tiêu chuẩn khi nói đến điều này. Trong trường hợp bình thường, có, có là một cơ chế để công bố thông tin đối với khách hàng thông qua DNS để họ đúng cách dự phòng từ các máy chủ sơ cấp đến các máy chủ sao lưu. Cơ chế đó lànhư một máy chủ tên dự phòng hoặc máy chủ thư
SRVcác bản ghi tài nguyên, được sử dụng bởi các máy khách dịch vụ cho nhiều giao thức khác ngoài HTTP. Xem RFC 2782.
Với SRVhồ sơ tài nguyên, khách hàng được cho biết một danh sách các máy chủ, với các ưu tiên và trọng số, và được yêu cầu thử các máy chủ theo thứ tự ưu tiên, chọn giữa các máy chủ có mức độ ưu tiên như nhau theo trọng số, chọn các máy chủ có trọng số cao hơn thường xuyên hơn những cái. Vì vậy, với SRVcác bản ghi tài nguyên, quản trị viên máy chủ có thể cho khách hàng biết máy chủ dự phòng là gì và cách phân phối tải của họ trên một tập hợp các máy chủ có mức độ ưu tiên như nhau.
Bây giờ các máy chủ DNS nội dung được định vị bằng một loại bản ghi tài nguyên đặc biệt của chính bản ghi tài nguyên của chúng, NSkhông có thông tin ưu tiên và trọng số. Tương tự, các máy chủ SMTP Relay được định vị theo loại bản ghi tài nguyên đặc biệt của riêng chúng MX, có thông tin ưu tiên nhưng không có thông tin trọng số. Vì vậy, đối với các máy chủ DNS nội dung không có quy định để xuất bản dự phòng và tải thông tin phân phối; và nếu một người đang sử dụng MXcác bản ghi tài nguyên thì đối với các máy chủ SMTP Relay sẽ không có điều khoản nào để xuất bản thông tin phân phối tải.
Tuy nhiên, SRVMTSes -capable hiện tồn tại. (Đầu tiên là exim, đã được cấp phép SRVtừ năm 2005.) Và đối với các giao thức dịch vụ khác , không bị ảnh hưởng bởi hành lý MXvà NShồ sơ tài nguyên, SRVviệc áp dụng là triệt để và phổ biến hơn nhiều. Ví dụ: nếu bạn có tên miền Microsoft Windows, thì toàn bộ dịch vụ được định vị thông qua SRVtra cứu trong DNS . Đó là trường hợp trong hơn một thập kỷ, tại thời điểm này.
Vấn đề là mọi người đều nghĩ về HTTP, khi HTTP đến nay, ngày nay là năm 2011, ngoại lệ và không phải là quy tắc ở đây.
SRVhồ sơ là cách xác định để xác định vị trí các dịch vụ. Cũng lưu ý rằng câu hỏi là liệu cơ chế tồn tại và nó là gì. Cơ chế tồn tại, và đây là cơ chế. Nó đã được sử dụng rộng rãi trong một thập kỷ.
nếu bạn đang phục vụ nội dung động và không thực tế khi chỉ có hai máy chủ cung cấp nội dung đồng thời thì tùy chọn khác của bạn là có nhiều bản ghi trên DNS của bạn và định cấu hình máy chủ dự phòng để ném cổng ICMP không thể truy cập tới các máy khách thử và kết nối với nó ; Nếu tại bất kỳ thời điểm nào, máy chủ chính ngừng hoạt động thì bạn chỉ cần xóa khối cổng 80 trên bản sao lưu và lưu lượng sẽ bắt đầu đi vào.
Cách duy nhất (ngân sách) khác mà bạn sẽ có thể thực hiện là thiết lập một máy (hoặc hai) riêng biệt để thực hiện NAT theo yêu cầu, do đó, nếu máy chủ web chết, bạn chỉ cần xóa quy tắc NAT cho nó.
Không có bản ghi A dự phòng, nhưng có thể có một số bản ghi A được đưa ra theo thứ tự ngẫu nhiên.
Hầu hết các trình duyệt có khả năng thử một máy chủ khác nếu một lỗi. (Xem: Khả năng phục hồi Web với Round Robin DNS )
Bạn có thể có một địa chỉ IP cụm được hỗ trợ bởi một số máy chủ với VRRP hoặc CARP . Máy chủ dự phòng chiếm địa chỉ khi máy chủ chính bị lỗi.
Có, nhưng bạn phải tự làm điều đó ;-)
Bạn có thể cung cấp thêm thông tin về lý do tại sao bạn muốn có một "bản ghi dự phòng" và cách thức và trong những trường hợp bạn muốn đến bản sao lưu.
Ngoài ra, sẽ rất hữu ích khi biết mối quan hệ từ góc độ mạng giữa máy chủ chính và máy chủ dự phòng.
Đây là một câu hỏi khá cũ nhưng hai công nghệ khá quan trọng chưa được đưa ra trong các câu trả lời: DNS động và CDN.
DNS động được thiết lập để các bản ghi DNS có thể được sửa đổi trong gần như thời gian thực, do đó, máy khách giám sát có thể kích hoạt các thay đổi đối với bản ghi DNS A công khai khi có sẵn dịch vụ. (Tất nhiên, dịch vụ lưu trữ DNS của bạn phải hỗ trợ DNS động.)
CDN cũng có thể được sử dụng để phân phối DNS, ví dụ như Cloudflare (được ra mắt vào năm 2010, tôi tin vậy).