DNS và cách thức hoạt động của nó có lẽ đi kèm với sự hiểu lầm, truyền thuyết, mê tín và thần thoại nhiều hơn bất kỳ khía cạnh nào của CNTT.
Ngay cả những người trong chúng ta biết rằng về cơ bản chúng ta đang nói dối (hoặc ít nhất là quá đơn giản hóa) khi chúng ta nói về "sự truyền bá" các thay đổi vẫn có xu hướng sử dụng thuật ngữ này để mô tả một cái gì đó - đồng thời - cực kỳ đơn giản và đơn giản ... nhưng khó giải thích ... và không có gì để làm với công tác tuyên truyền cho mỗi gia nhập , nhưng tất cả mọi thứ để làm với bộ nhớ đệm và bộ nhớ đệm tiêu cực, cả hai đều là một thành phần thiết yếu của cách thức hoạt động hệ thống (và, cho là, làm thế nào nó tránh được sự sụp đổ hoàn toàn dưới trọng lượng riêng của nó) - về cơ bản là từ trong ra ngoài, ngược lại với "lan truyền" thực tế, kéo - không đẩy.
Đối với tất cả những lo lắng và vặn vẹo về các TTL ngắn, chúng có xu hướng hoạt động thường xuyên hơn không, đến mức có thể bạn chỉ muốn thử chúng. Tại $ {day_job}, khi các trang web của chúng tôi di chuyển từ nền tảng "cũ" sang nền tảng "mới", điều đó thường có nghĩa là họ đang di chuyển theo cách mà không có gì trong cơ sở hạ tầng được chia sẻ. Bước đầu tiên của tôi trong quá trình di chuyển như vậy là giảm độ trễ xuống còn 60 giây trước khi cắt để TTL cũ có nhiều bội số của chính nó, cho tôi một sự đảm bảo hợp lý rằng các RR chuyển tiếp có TTL ngắn này sẽ "lan truyền" . " Khi tôi sẵn sàng cắt, tôi cấu hình lại bộ cân bằng cũ để lưu lượng kẹp tóc vào hệ thống mới - trên Internet - sao cho bộ cân bằng không còn cân bằng nhiều hệ thống nội bộ, mà thay vào đó, là "
Sau đó, tôi cắt DNS và xem bộ cân bằng mới và cũ.
Tôi luôn ngạc nhiên khi thấy quá trình chuyển đổi diễn ra nhanh như thế nào. Các tổ chức dường như hầu như luôn luôn là các con nhện tìm kiếm và các trang web "kiểm tra sức khỏe" của bên thứ ba không thể giải thích được về các hồ sơ cũ.
Nhưng có một kịch bản bị phá vỡ có thể dự đoán được: khi cửa sổ trình duyệt của người dùng vẫn mở, họ có xu hướng bám vào địa chỉ đã được phát hiện và thường nó vẫn tồn tại cho đến khi tất cả các cửa sổ trình duyệt của họ bị đóng.
Nhưng trong phần tường thuật trên, bạn tìm thấy giải pháp cho vấn đề: "bộ cân bằng tải" - cụ thể và chính xác hơn là proxy ngược - có thể là hệ thống mà bản ghi DNS được hiển thị của bạn trỏ tới.
Sau đó, proxy ngược lại chuyển tiếp yêu cầu đến đúng địa chỉ IP đích, nó sẽ giải quyết bằng cách sử dụng tên máy chủ "giả" thứ hai với một TTL ngắn, trỏ đến máy chủ back-end thực sự. Bởi vì proxy luôn tôn vinh DNS TTL trên đó Nhập DNS giả, bạn yên tâm về việc chuyển đổi nhanh chóng và đầy đủ.
Mặt trái là bạn có thể định tuyến lưu lượng truy cập thông qua cơ sở hạ tầng bổ sung không cần thiết hoặc trả thêm tiền để vận chuyển qua nhiều ranh giới mạng, một cách dự phòng.
Có những dịch vụ cung cấp loại khả năng này trên phạm vi toàn cầu và dịch vụ mà tôi quen thuộc nhất là CloudFront. (Rất có thể, Cloudflare sẽ phục vụ chính xác cùng một mục đích, vì rất ít thử nghiệm mà tôi đã thực hiện chỉ ra rằng nó cũng hoạt động chính xác và tôi chắc chắn có những mục đích khác.)
Mặc dù chủ yếu được bán trên thị trường dưới dạng CDN, CloudFront là cốt lõi của một mạng lưới các proxy ngược toàn cầu với khả năng tùy chọn lưu trữ các phản hồi. Nếu www.example.comcác điểm tới CloudFront và CloudFront được định cấu hình để chuyển tiếp các yêu cầu này backend.example.comvà bản ghi DNS để backend.example.comsử dụng một TTL ngắn, thì CloudFront sẽ thực hiện đúng, vì nó tôn trọng TTL ngắn đó. Khi bản ghi back-end thay đổi, tất cả lưu lượng sẽ di chuyển theo thời gian TTL chạy xuống.
TTL trên bản ghi phía trước chỉ vào CloudFront và liệu trình duyệt và bộ giải quyết bộ đệm có tôn trọng nó không quan trọng hay không, vì các thay đổi đối với đích phía sau không yêu cầu thay đổi trên www.example.combản ghi ... vì vậy khái niệm "Internet" có liên quan đến mục tiêu chính xác www.example.comlà phù hợp, bất kể hệ thống back-end xảy ra ở đâu.
Điều này, với tôi, giải quyết hoàn toàn vấn đề bằng cách giải phóng trình duyệt mọi nhu cầu "theo dõi" các thay đổi đối với IP của máy chủ gốc.
tl; dr: định tuyến các yêu cầu đến một hệ thống đóng vai trò proxy cho máy chủ web thực, do đó chỉ có cấu hình proxy cần điều chỉnh thay đổi IP máy chủ gốc - không phải DNS đối diện với trình duyệt.
Lưu ý rằng CloudFront cũng giảm thiểu độ trễ bằng một số phép thuật DNS mà nó áp đặt ở phía trước, điều này dẫn đến www.example.comviệc giải quyết vị trí cạnh CloudFront tối ưu nhất dựa trên vị trí của trình duyệt đang truy vấn www.example.com, do đó, có khả năng lưu lượng truy cập đi theo tuyến đường không cần thiết từ trình duyệt đến cạnh đến nguồn gốc ... nhưng phần này là minh bạch và tự động và nằm ngoài phạm vi của câu hỏi.
Và, tất nhiên, bộ nhớ đệm nội dung cũng có thể có giá trị bằng cách giảm tải trên máy chủ gốc hoặc vận chuyển - Tôi đã định cấu hình các trang web trên CloudFront nơi máy chủ gốc nằm trên mạch ADSL và ADSL vốn bị hạn chế về băng thông ngược dòng. Máy chủ gốc nơi CloudFront kết nối để tìm nạp nội dung không cần phải là máy chủ bên trong hệ sinh thái AWS.
Tôi nói về bộ cân bằng như một thực thể duy nhất khi trên thực tế nó có nhiều nút. Khi bộ cân bằng là ELB, một máy phía sau bộ cân bằng hoạt động như một máy chủ ứng dụng giả và thực hiện việc kẹp tóc thực sự cho bộ cân bằng của nền tảng mới, vì ELB không thể tự làm điều này.
² Kiến thức duy nhất của nhà đầu tư mới về nhà đầu tư cũ là cần phải tin tưởng vào X-Forwarded-For của nhà đầu tư cũ và không nên thực hiện bất kỳ giới hạn tỷ lệ dựa trên IP nào trên các địa chỉ nguồn của nhà đầu tư cũ.
Khi proxy là một hoặc nhiều máy chủ mà bạn kiểm soát, bạn có tùy chọn bỏ qua sử dụng DNS ở mặt sau và chỉ cần sử dụng địa chỉ IP trong cấu hình proxy, nhưng kịch bản được lưu trữ / phân phối được thảo luận sau đó cần lớp DNS thứ hai đó .