[AWS] Routing Policies

1. Route 53 – Routing Policies.

• Định nghĩa cách Route 53 phản hồi các truy vấn DNS.

Route 53 là một dịch vụ quản lý tên miền (DNS) được cung cấp bởi Amazon Web Services (AWS). Nó được sử dụng để kết nối tên miền với địa chỉ IP của máy chủ hoặc tài nguyên trên AWS. Khi một truy vấn DNS được gửi đến Route 53, nó sẽ phản hồi bằng cách trả về địa chỉ IP của máy chủ hoặc tài nguyên liên quan đến tên miền đó.

• Đừng nhầm lẫn với từ “Routing”.

Không như chức năng định tuyến (routing) trong load balancer, định tuyến (routing) trong Route 53 chỉ phản hồi các truy vấn DNS và không định tuyến bất kỳ lưu lượng nào.

• DNS không định tuyến bất kỳ lưu lượng nào, nó chỉ phản hồi các truy vấn DNS.

DNS là viết tắt của Domain Name System, có nhiệm vụ chuyển đổi tên miền sang địa chỉ IP. Khi một truy vấn DNS được gửi đến một máy chủ DNS, nó sẽ trả về địa chỉ IP liên quan đến tên miền đó. DNS không định tuyến lưu lượng, mà chỉ phản hồi các truy vấn DNS và trả về địa chỉ IP liên quan đến tên miền được yêu cầu.

• Route 53 hỗ trợ các chính sách định tuyến sau:

Route 53 hỗ trợ nhiều chính sách định tuyến để cung cấp sự linh hoạt và tùy chỉnh cho việc định tuyến các truy vấn DNS. Các chính sách định tuyến này bao gồm:

• Simple: Chính sách đơn giản sẽ phản hồi một địa chỉ IP cố định cho tất cả các truy vấn DNS.
• Weighted: Chính sách định tuyến theo trọng số sẽ phân phối lưu lượng truy cập vào các tài nguyên khác nhau với tỷ lệ trọng số khác nhau.
• Failover: Chính sách định tuyến sự cố sẽ chuyển hướng truy vấn DNS sang một tài nguyên thay thế khi tài nguyên chính không khả dụng.
• Latency-based: Chính sách định tuyến dựa trên độ trễ sẽ định tuyến các truy vấn DNS tới các máy chủ gần nhất đến người dùng để cải thiện hiệu suất và tăng tốc độ phản hồi của trang web hoặc ứng dụng.
• Geolocation: Chính sách định tuyến dựa trên vị trí địa lý sẽ định tuyến các truy vấn DNS đến máy chủ gần nhất với vị trí địa lý của người dùng.
• Multi-Value Answer: Chính sách định tuyến giá trị đa sẽ trả về nhiều giá trị IP cho một tên miền để cải thiện sự sẵn sàng và khả dụng của ứng dụng.
• Geoproximity: Chính sách định tuyến địa lý sẽ sử dụng tính năng Route 53 Traffic Flow để định tuyến các truy vấn DNS đến máy chủ tối ưu dựa trên nhiều yếu tố như vị trí địa lý, tính khả dụng và trạng thái mạng.

Tóm lại, Route 53 là một dịch vụ quản lý tên miền (DNS) mạnh mẽ của AWS, cung cấp nhiều tùy chọn định tuyến khác nhau để cải thiện hiệu suất và sẵn sàng của ứng dụng. Nó không phải là một công cụ định tuyến (routing) cho lưu lượng mạng, mà chỉ phản hồi các truy vấn DNS và định tuyến chúng đến các máy chủ phù hợp nhất dựa trên các chính sách định tuyến khác nhau.

2. Routing Policies – Simple.

• Thường thì, các truy vấn DNS sẽ được định tuyến đến một tài nguyên duy nhất.
• Tuy nhiên, bạn có thể chỉ định nhiều giá trị cho cùng một bản ghi DNS.
• Nếu nhiều giá trị được trả về, một giá trị ngẫu nhiên sẽ được chọn bởi máy khách (client).
• Khi bật tính năng Alias, chỉ có thể chỉ định một tài nguyên AWS duy nhất.
• Không thể liên kết với Health Check (kiểm tra sức khỏe).

Nói cách khác, Route 53 cho phép bạn định tuyến các truy vấn DNS đến một tài nguyên duy nhất trong hầu hết các trường hợp. Tuy nhiên, bạn có thể chỉ định nhiều giá trị cho cùng một bản ghi DNS để cải thiện sự sẵn sàng và khả dụng của ứng dụng. Nếu nhiều giá trị được trả về, máy khách sẽ chọn ngẫu nhiên một trong số đó.

Khi bạn bật tính năng Alias, bạn chỉ có thể chỉ định một tài nguyên AWS duy nhất. Tính năng này giúp tăng tốc độ phản hồi và cải thiện khả năng mở rộng của ứng dụng. Tuy nhiên, nó không thể được liên kết với Health Check để kiểm tra sức khỏe của tài nguyên. Health Check là một tính năng trong Route 53 cho phép bạn kiểm tra sức khỏe của các tài nguyên mạng của mình và đảm bảo rằng chúng luôn sẵn sàng và hoạt động tốt.

Hãy thử thực hành phần Simple này xíu nhé:

Đầu tiên hãy tạo 1 Record mới với sub domain là simple, TTL mình để số nhỏ là 20 giây, Routing policy lựa chọn Simple routing.

Sau khi tạo xong, mình có thêm 1 record mới như vậy.

Kiểm tra kết quả.

Sử dụng lệnh dig bạn sẽ thấy có 1 record A đã thêm vào với TTL là 20s và giá trị là 54.251.92.166.

Giờ mình sẽ thêm 1 value mới bằng cách vào edit record của sub domain simple.stephanetheteacher.com.

Hãy thêm 1 value mới 54.172.8.44 và lưu lại.

Sau khi lưu lại sub domain simple.stephanetheteacher.com bạn sẽ thấy có 2 giá trị 54.25192.166 và 54.172.8.44.

Kết quả khi sử dụng lệnh dig bạn cũng sẽ thấy 2 giá trị này với TTL là 20s.

Bây giờ trên trình duyệt bạn truy cập simple.stephanetheteacher.com bạn sẽ thấy AZ ap-southeast-1b (54.251.92.166) đang trả lời.

Chờ hết 20s TTL, bạn hãy tải lại trang và kết quả là AZ us-east-1a (54.172.8.44) đang trả lời bạn

3. Routing Policies – Weighted.

The Weighted Routing Policy in Route 53 allows you to control the percentage of DNS queries that are routed to specific resources.

– Bạn có thể chỉ định một trọng số tương đối cho mỗi bản ghi DNS:

+ traffic (%) = Trọng số của một bản ghi cụ thể / Tổng trọng số của tất cả các bản ghi.

+ The weights do not need to add up to 100.

– Các bản ghi DNS phải có cùng tên và loại.

– Các bản ghi có thể được liên kết với Health Checks để đảm bảo rằng các tài nguyên được chọn để xử lý các truy vấn DNS là hoạt động tốt.

– Một số trường hợp sử dụng Weighted Routing Policy bao gồm cân bằng tải giữa các khu vực khác nhau, thử nghiệm các phiên bản mới của ứng dụng…

– Bạn có thể chỉ định một trọng số bằng 0 cho một bản ghi để ngừng gửi lưu lượng truy cập đến một tài nguyên cụ thể.

– Nếu tất cả các bản ghi có trọng số bằng 0, thì tất cả các bản ghi sẽ được trả về với tỉ lệ như nhau.

Tóm lại, Weighted Routing Policy cho phép bạn cấu hình định tuyến truy vấn DNS đến các tài nguyên khác nhau với tỷ lệ phần trăm xác định. Điều này cho phép bạn tùy chỉnh hành vi định tuyến truy vấn DNS để cân bằng tải các tài nguyên mạng của bạn hoặc thử nghiệm các phiên bản mới của ứng dụng. Bạn có thể chỉ định trọng số cho mỗi bản ghi DNS để xác định tỷ lệ phần trăm các truy vấn DNS được định tuyến đến mỗi tài nguyên. Bạn có thể liên kết các bản ghi DNS với Health Checks để đảm bảo rằng các tài nguyên được chọn để xử lý các truy vấn DNS là hoạt động tốt.

Được rồi bây giờ hãy thử demo để dễ hình dung hơn. Bây giờ hãy tạo 1 bản ghi mới với value là 54.251.92.166 và Weighted là 10% và TTL mình để 3s.

Tạo thêm 1 bản ghi thứ 2 với value là 54.172.8.44 và Weighted là 70% và TTL mình để 3s.

Tiếp tục tạo thêm 1 bản ghi thứ 2 với value là 3.70.14.253 và Weighted là 20% và TTL mình để 3s.

Sau khi thiết lập xong, bấm Create records để tạo bản ghi, bạn sẽ có 3 bản ghi weighted stephanetheteacher.com như dưới, chúng khác nhau ở chỉ số Weighted.

Khi truy cập weighted.stephanetheteacher.com mình nhận được phản hồi đầu tiên từ AZ us-east-1a, điều này là đúng vì nó được gắn weighted là 70%.

Kết quả khi bạn sử dụng lệnh dig, bạn nhật được value là 54.172.8.44.

Và nếu bạn bấm tải lại trang liên tục hoặc chạy lệnh dig liên tục bạn sẽ có 1 kết quả khác là 3.70.14.253 như dưới.

Lúc này bạn truy cập trên trình duyệt, bạn sẽ nhận được kết quả AZ eu-central-1c trả lời cho bạn.

4. Routing Policies – Latency – Based.

Chính sách định tuyến dựa trên độ trễ (Latency based routing) của Route 53 cho phép điều hướng các yêu cầu đến tài nguyên gần nhất, đảm bảo thời gian đáp ứng nhanh nhất và độ trễ thấp nhất cho người dùng. Với chính sách này, Route 53 sử dụng độ trễ của các máy chủ DNS của nó để tìm ra địa chỉ IP của tài nguyên (ví dụ như một máy chủ web) mà có độ trễ thấp nhất đối với người dùng. Điều này đặc biệt hữu ích đối với các ứng dụng yêu cầu thời gian đáp ứng nhanh và độ trễ thấp như trò chơi trực tuyến, video streaming, hay các ứng dụng tài chính trực tuyến.

Chính sách định tuyến dựa trên độ trễ cũng có khả năng sử dụng chức năng Health Check của Route 53 để kiểm tra tính khả dụng của các tài nguyên. Nếu một tài nguyên không khả dụng, Route 53 sẽ tự động chuyển hướng các yêu cầu đến tài nguyên khác trong khu vực có độ trễ thấp nhất.

Bây giờ chúng ta hãy demo phần này nhé. Hãy tạo 1 bản ghi mới như dưới với Routing policy là latency ở khu vực Asia Pacific (Singapore) và giá trị value là 54.251.92.166.

Tạo bản ghi thứ 2 với Routing policy là latency ở khu vực US East (N. Virginia) và giá trị value là 54.172.8.44.

Tạo bản ghi thứ 3 với Routing policy là latency ở khu vực Europe (Frankfurt) và giá trị value là 3.70.14.253.

Sau khi khai báo xong, bấm Create records để tạo bản ghi này, bạn sẽ có kết quả như dưới.

Hiện tại mình đang ở Châu Âu nên kết quả trả về sẽ là AZ eu-central-1c nằm ở vùng Châu Âu.

Kết quả khi sử dụng lệnh dig, bạn thấy giá trị value là 3.70.14.253 nằm tại AZ eu-central-1c.

Trên PC mình sử dụng VPN để chuyển vùng từ Châu Âu sang Canada.

Và kết quả trả về là AZ eu-central-1c nằm ở Châu Mỹ.

Nhưng ở trên Cloud Shell mình vẫn nằm ở vùng Châu Âu nên kết quả vẫn không thay đổi.

Giờ mình sẽ chuyển vùng sang HồngKông.

Và kết quả trả về là AZ ap-southeast-1b nằm ở khu vực Châu Á.

5. Route 53 – Health Checks.

Chính sách kiểm tra sức khỏe của Route 53 cho phép theo dõi tính khả dụng của các tài nguyên và tự động chuyển hướng yêu cầu đến tài nguyên khác nếu tài nguyên hiện tại không khả dụng. Sức khỏe của tài nguyên được theo dõi thông qua các kiểm tra sức khỏe, bao gồm các kiểm tra HTTP, TCP và HTTPS.

Tuy nhiên, kiểm tra sức khỏe HTTP chỉ dành cho các tài nguyên công khai, tức là các tài nguyên có thể được truy cập từ Internet. Để kiểm tra sức khỏe của các tài nguyên riêng tư, Route 53 cung cấp các tùy chọn khác như kiểm tra sức khỏe của các AWS resource khác như server, application, hoặc theo dõi sức khỏe của các health check khác (Calculated Health Checks). Ngoài ra, Route 53 cũng cung cấp tích hợp với CloudWatch Metrics, cho phép bạn theo dõi và quản lý các chỉ số sức khỏe của các tài nguyên.

Nếu một tài nguyên không khả dụng, Route 53 sẽ tự động kích hoạt chức năng DNS Failover và chuyển hướng các yêu cầu đến tài nguyên khác có sẵn và khả dụng. Việc này giúp đảm bảo rằng ứng dụng của bạn luôn có sẵn để phục vụ người dùng, ngay cả khi xảy ra sự cố với một số tài nguyên.

6. Health Checks – Monitor an Endpoint.

Đây là các chi tiết về chức năng Health Check của Route 53:

• Route 53 sử dụng khoảng 15 trình kiểm tra toàn cầu để kiểm tra tình trạng sức khỏe của điểm cuối (endpoint).
• Ngưỡng Sức khỏe/Không khỏe – mặc định là 3.
• Khoảng thời gian kiểm tra – mặc định là 30 giây (có thể đặt thành 10 giây – tăng chi phí).
• Giao thức được hỗ trợ: HTTP, HTTPS và TCP.
• Nếu hơn 18% trình kiểm tra sức khỏe báo cáo điểm cuối (endpoint) là sức khỏe, Route 53 sẽ xem xét là Sức khỏe. Nếu không, nó sẽ không Sức khỏe.
• Có thể chọn vị trí mà bạn muốn Route 53 sử dụng để thực hiện kiểm tra sức khỏe.
• Kiểm tra sức khỏe sẽ báo đúng khi điểm cuối (endpoint) phản hồi với các mã trạng thái 2xx và 3xx.
• Kiểm tra sức khỏe có thể được thiết lập để báo đúng/sai dựa trên văn bản trong 5120 byte đầu tiên của phản hồi.
• Cấu hình router / tường lửa của bạn để cho phép các yêu cầu đến từ Route 53 Health Checkers.

7. Route 53 – Calculated Health Checks.

Tính năng mà bạn đang nói đến là Calculated Health Checks trong Amazon Route 53. Đây là tính năng cho phép bạn kết hợp kết quả từ nhiều Health Checks con thành một Health Check cha.

Bạn có thể sử dụng các phép toán logic OR, AND hoặc NOT để kết hợp kết quả từ các Health Check con. Ví dụ, bạn có thể tạo một Health Check cha sử dụng phép toán AND với hai Health Check con, một Health Check kiểm tra sức khỏe của máy chủ web và một Health Check kiểm tra sức khỏe của cơ sở dữ liệu. Khi cả hai Health Check con đều trả về kết quả là “pass”, thì Health Check cha cũng trả về kết quả “pass”.

Bạn cũng có thể chỉ định số lượng Health Check con cần phải pass để Health Check cha trả về kết quả là “pass”. Ví dụ, bạn có thể tạo một Health Check cha sử dụng phép toán OR với hai Health Check con, và chỉ định rằng Health Check cha sẽ pass nếu ít nhất một trong hai Health Check con pass.

Calculated Health Checks hữu ích khi bạn muốn thực hiện bảo trì cho trang web của mình mà không gây ra tất cả các Health Check đều fail. Bằng cách kết hợp các Health Check con lại, bạn có thể kiểm soát việc kết hợp kết quả của các Health Check con và đưa ra quyết định về trạng thái sức khỏe của toàn bộ hệ thống dựa trên kết quả này.

Để hiểu rõ hơn chúng ta bắt đầu thực hành, mình sẽ tạo 3 Health checks tương ứng với 3 vùng. Để tạo Health checks đầu tiên hãy vào Health checks -> Create health check.

Tại Configure health check đặt tên cho health check này.

Mình lựa chọn Protocol là HTTP và ip address endpoint là 54.172.8.44 lắng nghe ở port 80.

Phần tiếp theo sẽ có 1 số thành phần sau đây:

• Request interval: Đây là khoảng thời gian giữa các lần Health Checks kiểm tra sức khỏe của ứng dụng hoặc dịch vụ. Thời gian này được đặt bởi người dùng, thường từ vài giây đến vài phút. Khi thời gian này được đặt quá ngắn, nó có thể gây tốn tài nguyên và làm ảnh hưởng đến hiệu suất của ứng dụng hoặc dịch vụ. Tuy nhiên, khi thời gian này được đặt quá dài, thì sự chậm trễ trong việc phát hiện và khắc phục lỗi có thể dẫn đến gián đoạn dịch vụ.
• Failure threshold: Đây là số lần kiểm tra sức khỏe thất bại liên tiếp trước khi Health Checks xem như ứng dụng hoặc dịch vụ đã bị lỗi. Khi số lần kiểm tra thất bại vượt quá ngưỡng này, Health Checks sẽ đưa ra cảnh báo hoặc thực hiện hành động như khởi động lại ứng dụng hoặc dịch vụ. Điều này giúp đảm bảo rằng ứng dụng hoặc dịch vụ luôn hoạt động tốt và đáp ứng được yêu cầu của người dùng.
• String matching: Đây là tùy chọn để kiểm tra xem phản hồi từ ứng dụng hoặc dịch vụ có chứa một chuỗi cụ thể hay không. Điều này có thể giúp xác định xem ứng dụng hoặc dịch vụ có đang hoạt động đúng cách hay không, đặc biệt là trong trường hợp phản hồi trả về là “200 OK” nhưng không chứa nội dung phù hợp.
• Latency graphs: Đây là biểu đồ thể hiện thời gian phản hồi của ứng dụng hoặc dịch vụ trong suốt quá trình kiểm tra sức khỏe. Biểu đồ này giúp người dùng hiểu rõ hơn về hiệu suất của ứng dụng hoặc dịch vụ và có thể phát hiện được các sự cố liên quan đến tốc độ phản hồi của ứng dụng hoặc dịch vụ.
• Invert health check status: Đây là tùy chọn để đảo ngược trạng thái sức khỏe của ứng dụng hoặc dịch vụ. Khi tùy chọn này được kích hoạt, trạng thái sức khỏe sẽ được đảo ngược: nếu trước đó ứng dụng hoặc dịch vụ được xem là đang hoạt động bình thường, thì bây giờ nó sẽ được xem là bị lỗi, và ngược lại. Điều này có thể hữu ích trong việc kiểm tra khả năng xử lý lỗi của hệ thống hoặc trong trường hợp muốn kiểm tra cách thức xử lý của các hệ thống khác khi gặp phải sự cố.
• Disable health check: Đây là tùy chọn để tạm dừng kiểm tra sức khỏe của ứng dụng hoặc dịch vụ. Khi tùy chọn này được kích hoạt, Health Checks sẽ không kiểm tra sức khỏe của ứng dụng hoặc dịch vụ và sẽ không đưa ra cảnh báo nếu sức khỏe của nó bị lỗi. Tùy chọn này thường được sử dụng trong trường hợp cần thực hiện bảo trì hoặc nâng cấp hệ thống.
• Health checker regions: Đây là tùy chọn để chọn khu vực hoặc vị trí của các máy chủ sẽ được sử dụng để kiểm tra sức khỏe của ứng dụng hoặc dịch vụ. Việc chọn khu vực này có thể giúp cải thiện hiệu suất và độ tin cậy của kiểm tra sức khỏe, đặc biệt là trong trường hợp ứng dụng hoặc dịch vụ được triển khai trên các khu vực khác nhau trên thế giới.

Mình lựa chọn Failure threshold là 3 và Request interval là Standard (30 seconds). Phần Health checker regions mình chọn Use recommended.

Để được thông báo khi kiểm tra sức khỏe của ứng dụng hoặc dịch vụ thất bại, bạn có thể sử dụng tính năng thông báo của Health Checks. Tính năng này cho phép bạn đặt một số người nhận thông báo được gửi đến khi sức khỏe của ứng dụng hoặc dịch vụ của bạn bị lỗi.

Để cấu hình tính năng thông báo, bạn có thể làm theo các bước sau:

• Đăng nhập vào tài khoản Health Checks của bạn.
• Chọn ứng dụng hoặc dịch vụ mà bạn muốn cấu hình thông báo.
• Chọn tab “Notifications”.
• Chọn phương thức thông báo bạn muốn sử dụng, ví dụ như email hoặc Slack.
• Cấu hình thông tin chi tiết của phương thức thông báo được chọn, chẳng hạn như địa chỉ email hoặc webhook URL của kênh Slack.
• Thiết lập ngưỡng thất bại và thời gian chờ để xác định khi nào thông báo nên được gửi. Ví dụ: nếu bạn thiết lập ngưỡng thất bại là 3 và thời gian chờ là 5 phút, thông báo sẽ được gửi sau khi có 3 kiểm tra thất bại liên tiếp và khoảng cách giữa các lần kiểm tra là 5 phút.

Sau khi bạn đã cấu hình thông báo, bạn sẽ nhận được thông báo khi sức khỏe của ứng dụng hoặc dịch vụ của bạn bị lỗi. Điều này giúp bạn có thể xử lý các sự cố nhanh chóng và đảm bảo rằng hệ thống của bạn hoạt động ổn định.

Trường hợp của mình thì để đơn giản mình sẽ chọn No và bấm Create health check để tạo Health checks đầu tiên.

Và đây là health check đầu tiên của mình.

Mình tiếp tục tạo Health checks thứ 2 ở vùng ap-southeast-1.

Mình lựa chọn Protocol là HTTP và ip address endpoint là 54.251.92.166 và cũng lắng nghe ở port 80.

Bấm Next để tiếp tục.

Mình bỏ qua cảnh báo nên mình sẽ lựa chọn là No, bấm Create health check để tiếp tạo Health checks.

Và đây là kết quả khi tạo xong Health checks thứ 2.

Mình tiếp tục tạo Health checks thứ 3 ở vùng eu-central-1.

Mình lựa chọn Protocol là HTTP và ip address endpoint là 3.70.14.253 và cũng lắng nghe ở port 80.

Bấm Next để tiếp tục.

Chọn no để không gửi thông báo, bấm Create health check để tạo Health checks thứ 3.

Và đây là kết quả khi tạo xong 3 Health checks.

Bây giờ để kiểm tra kết quả, hãy vào 1 Instance nào đó, mình sẽ lựa chọn Instance ở Singapore.

Vào Security Groups và xoá 2 rule liên quan đến HTTP port 80.

Quay lại Health checks, bạn thấy Health checks ở vùng Singapore đã chuyển quan trạng thái Unhealthy và 2 vùng còn lại vẫn đang trạng thái Healthy vì Security Groups của Instance 2 vùng này vẫn còn rule HTTP port 80.

Qua tab Health checkers bạn có thể thấy các logs bị fail chi tiết ở cột status.

Nếu xem ở các vùng khác bạn sẽ thấy logs của các vùng này là Success.

Bạn có thể bấm vào 1 dòng log bất kỳ để xem chi tiết log như hình dưới.

Bây giờ chúng ta hãy thực hành với 1 phương thức Health checks khác là Status of other health checks (calculated health check) nhé. Vậy Status of other health checks (calculated health check) là gì? Status of other health checks hay còn được gọi là calculated health check là trạng thái sức khỏe được tính toán dựa trên kết quả của các health check khác trên các endpoint khác nhau. Nó được sử dụng để xác định trạng thái sức khỏe tổng thể của một ứng dụng hoặc dịch vụ mà có nhiều endpoint hoặc máy chủ cung cấp dịch vụ. Các health check được tính toán có thể bao gồm sự kết hợp của các health check endpoint, tình trạng của kết nối mạng, hoặc nhiều yếu tố khác để đưa ra một quyết định cuối cùng về trạng thái sức khỏe của ứng dụng hoặc dịch vụ đó.

Report healthy when là một tính năng của Route 53 cho phép người dùng tùy chỉnh các điều kiện để đưa ra quyết định về trạng thái của một endpoint. Có ba thành phần khác nhau trong Report healthy when đó là:

1. At least 2 of 3 selected health checks are healthy: Khi tính năng này được chọn, Route 53 sẽ báo cáo endpoint là healthy khi ít nhất 2 trong số 3 health checks được chọn đạt trạng thái healthy.
2. All health checks are healthy (AND): Khi tính năng này được chọn, Route 53 sẽ báo cáo endpoint là healthy khi tất cả các health checks đều đạt trạng thái healthy.
3. One or more health checks are healthy (OR): Khi tính năng này được chọn, Route 53 sẽ báo cáo endpoint là healthy khi ít nhất một trong số các health checks đạt trạng thái healthy.

Những điều này cho phép người dùng tùy chỉnh cách xử lý thông tin trạng thái endpoint một cách linh hoạt hơn, phù hợp với các yêu cầu và điều kiện của họ.

Trường hợp này mình lựa chọn là all health checks are healthy (AND).

Lựa chọn No và bấm Create health check.

Bạn sẽ có 1 Health checks mới như dưới.

Sau 1 lúc chờ đợi nó check thì Health checks mới có trạng thái Unhealthy, lý do là đã có 1 Instance bị xoá rule HTTP port 80, không đạt điều kiệu 3/3 vùng listen nên Health checks trả về trạng thái Unhealthy.

Trong Health checks vẫn còn 1 loại nữa là CloudWatch alarm nhưng mình sẽ không thực hành nó nữa để tránh mất thời gian. Trong Route 53 Health checks, CloudWatch alarm được sử dụng để gửi thông báo khi tình trạng của một health check vượt quá một ngưỡng nào đó được định trước. Trong trường hợp này, state của CloudWatch alarm có thể có ba giá trị:

• OK: nếu tình trạng của health check không vượt quá ngưỡng cảnh báo.
• ALARM: nếu tình trạng của health check vượt quá ngưỡng cảnh báo được định trước.
• INSUFFICIENT_DATA: nếu CloudWatch không có đủ dữ liệu để xác định tình trạng của health check, hoặc nếu đang có lỗi xảy ra trong quá trình lấy dữ liệu.

Khi state của CloudWatch alarm chuyển từ OK sang ALARM, Route 53 sẽ gửi thông báo cảnh báo. Khi state của CloudWatch alarm trở lại OK, Route 53 sẽ gửi thông báo khôi phục.

8. Health Checks – Private Hosted Zones.

Trong Amazon Route 53, các bộ kiểm tra sức khỏe (health checkers) được sử dụng để giám sát tính sẵn sàng của các tài nguyên như máy chủ, ứng dụng hoặc máy ảo. Tuy nhiên, các bộ kiểm tra sức khỏe này được triển khai bên ngoài VPC và không thể truy cập vào các điểm cuối riêng tư (private endpoint) như tài nguyên VPC hoặc tài nguyên trên nền tảng on-premises.

Để giám sát các tài nguyên private endpoint, bạn có thể tạo ra một CloudWatch Metric và liên kết nó với một CloudWatch Alarm, sau đó tạo một bộ kiểm tra sức khỏe để kiểm tra chính alarm này. Điều này cho phép bạn giám sát các tài nguyên private endpoint và báo cáo lại trạng thái của chúng thông qua Amazon Route 53.

9. Routing Policies – Failover (Active-Passive).

Routing Policies – Failover (Active-Passive) trong Amazon Route 53 là một chính sách định tuyến dùng để giải quyết vấn đề khả năng sẵn sàng cao (high availability) cho các ứng dụng. Được sử dụng cho các môi trường chịu lỗi (disaster recovery) và sự cố (outage), chính sách này sử dụng hai bản sao của ứng dụng, một bản chính (active) và một bản dự phòng (passive). Trong một kịch bản sự cố, Route 53 tự động chuyển hướng yêu cầu tới bản sao dự phòng.

Với chính sách Failover, Route 53 sử dụng một health check định kỳ để giám sát trạng thái của tài nguyên. Nếu tài nguyên chính (active) bị lỗi, Route 53 tự động chuyển hướng yêu cầu đến tài nguyên dự phòng (passive) và bảo đảm rằng yêu cầu được xử lý một cách đúng đắn. Điều này đảm bảo rằng người dùng sẽ không bị ảnh hưởng bởi sự cố và các dịch vụ vẫn có thể tiếp tục hoạt động.

Tuy nhiên, chính sách Failover có một số hạn chế. Vì chỉ có một bản sao được sử dụng, chính sách này không thể giải quyết vấn đề tải cao (high traffic) hoặc nâng cao hiệu suất ứng dụng. Nếu tài nguyên dự phòng phải được sử dụng, có thể xảy ra thời gian chuyển đổi từ bản chính sang bản dự phòng, trong đó có thể làm gián đoạn dịch vụ cho người dùng.

Do đó, chính sách Failover thường được sử dụng trong các trường hợp khi sự sẵn sàng cao là ưu tiên hàng đầu và không có yêu cầu về tải cao hoặc hiệu suất cao.

Hãy tạo bản ghi đầu tiên với Failover record type là Primary, Routing policy chọn Failover, Health check mình chọn là vùng eu-central-1, TTL cài đặt 60s và value là 3.70.14.253.

Hãy tạo bản ghi thứ 2 với Failover record type là Primary, Routing policy chọn Failover, Health check mình chọn là vùng us-east-1, TTL cài đặt 60s và value là 54.172.8.44.

Sau khi tạo xong, bạn có 2 bản ghi như dưới.

2 bản ghi mình tạo đang có trạng thái Health check là Healthy.

Kết quả kiểm tra trên trình duyệt, máy chủ AZ eu-central-1c đang trả lời bạn.

Bây giờ mình sẽ vào EC2 nằm tại Frankfurt và xoá 2 rule liên quan đến HTTP.

Vào Security group để xoá HTTP port 80 nhé.

Sau khi xoá rule HTTP, chờ 1 lát bạn sẽ nhận được trạng thái của Health check thuộc eu-central-1 trả về trạng thái Unhealthy.

Chuyển qua tab Monitoring bạn sẽ thấy biểu đồ đang ở trên cao bị sụt xuống 0.

Như vậy nếu bạn tải lại trang, bạn sẽ nhận được kết quả trả về từ us-east-1a chứ không phải eu-central-1 như lúc nãy.

10. Routing Policies – Geolocation.

Routing Policies – Geolocation là một trong các chính sách định tuyến trong Route 53, cho phép định tuyến dựa trên vị trí địa lý của người dùng. Khác với chính sách định tuyến dựa trên độ trễ hoặc phân phối tải, chính sách Geolocation sẽ định tuyến các yêu cầu của khách hàng đến các tài nguyên gần nhất về vị trí của họ.

Việc định tuyến được thực hiện dựa trên địa lý của khách hàng, có thể là lục địa, quốc gia hoặc bang (trong trường hợp Hoa Kỳ). Trong trường hợp xảy ra trùng lặp, vị trí chính xác nhất được chọn. Để đảm bảo tính linh hoạt và phù hợp với nhiều trường hợp sử dụng, nên tạo một bản ghi “Mặc định” (Default) (trong trường hợp không có phù hợp với bất kỳ vị trí nào).

Chính sách định tuyến Geolocation được sử dụng phổ biến để tối ưu hóa truy cập tài nguyên trên website, phân phối nội dung địa phương, hạn chế truy cập theo địa điểm và phân phối tải trên vị trí địa lý khác nhau. Nó cũng có thể được kết hợp với Health Check để đảm bảo tính khả dụng của các tài nguyên đối với khách hàng tại các vị trí địa lý khác nhau.

Tạo 3 bản ghi lần lượt như sau, bản ghi đầu tiên lựa chọn Routing policy là Routing policy, location là asia có value là 54.251.92.166.

Bản ghi đầu tiên lựa chọn Routing policy là Routing policy, location là United States có value là 54.172.8.44.

Bản ghi đầu tiên lựa chọn Routing policy là Routing policy, location là Default có value là 3.70.14.253.

Bạn sẽ có kết quả như dưới.

Truy cập vào domain geo.stephanetheteacher.com bạn nhận được kết quả từ eu-central-1c, lý do là mình đang ở EU.

Hãy chuyển VPN sang Ấn Độ.

Bạn nhận được kết quả ap-southeast-1b từ Châu Á trả về.

Hãy chuyển VPN qua United States.

Bạn sẽ nhận kết quả từ máy chủ us-east-1a nằm ở Châu Mỹ trả về.

Ví dụ cuối cùng mình sẽ chuyển sang Mexico.

Kết quả server mặc định ở Châu Âu vùng eu-central-1c trả về cho bạn.

11. Routing Policies – Geoproximity.

Đây là tính năng của Route 53 Traffic Flow, cho phép bạn định tuyến lưu lượng truy cập đến các tài nguyên của bạn dựa trên vị trí địa lý của người dùng và tài nguyên. Tính năng này cho phép bạn chuyển đổi số lượng lưu lượng truy cập được định tuyến đến tài nguyên của bạn dựa trên giá trị bias đã xác định.

Để thay đổi kích thước của khu vực địa lý, bạn chỉ cần xác định giá trị bias. Nếu bạn muốn mở rộng khu vực địa lý, bạn có thể đặt giá trị bias từ 1 đến 99 để tăng lưu lượng truy cập đến tài nguyên. Nếu bạn muốn thu hẹp khu vực địa lý, bạn có thể đặt giá trị bias từ -1 đến -99 để giảm lưu lượng truy cập đến tài nguyên.

Bạn có thể định tuyến lưu lượng truy cập đến tài nguyên AWS hoặc tài nguyên không phải của AWS. Nếu bạn định tuyến đến các tài nguyên AWS, bạn cần chỉ định khu vực AWS. Nếu bạn định tuyến đến các tài nguyên không phải của AWS, bạn cần chỉ định vĩ độ và kinh độ của tài nguyên. Tuy nhiên, để sử dụng tính năng này, bạn cần sử dụng Route 53 Traffic Flow.

12. Routing Policies – Multi-Value.

Multi-Value routing policy là một trong những Routing Policy của Route 53, được sử dụng để điều phối lưu lượng đến nhiều nguồn tài nguyên khác nhau. Với Multi-Value routing policy, Route 53 sẽ trả về nhiều giá trị/tài nguyên cho một truy vấn, điều này giúp tăng tính sẵn sàng và khả năng chịu lỗi của ứng dụng.

Multi-Value routing policy có thể được kết hợp với Health Checks để chỉ trả về giá trị/tài nguyên lành mạnh. Tối đa 8 bản ghi/tài nguyên lành mạnh sẽ được trả về cho mỗi truy vấn Multi-Value.

Tuy nhiên, Multi-Value routing policy không thể thay thế cho ELB (Elastic Load Balancer) để cân bằng tải giữa các nguồn tài nguyên. Multi-Value routing policy chỉ phù hợp khi muốn trả về nhiều giá trị/tài nguyên để tăng độ sẵn sàng của hệ thống.

Tạo 3 bản ghi lần lượt như sau, bản ghi đầu tiên lựa chọn Routing policy là Multivalue answer, Health check là us-east-1 có value là 54.172.8.44.

Bản ghi thứ 2 lựa chọn Routing policy là Multivalue answer, Health check là ap-southeast-1 có value là 54.251.92.166.

Bản ghi thứ 2 lựa chọn Routing policy là Multivalue answer, Health check là eu-central-1 có value là 3.70.14.253.

Bạn sẽ có các bản ghi như dưới.

Kết quả khi bạn sử dụng lệnh dig, bạn sẽ nhận được 3 value như dưới.

Bây giờ mình sẽ đánh lừa Health check bằng cách đảo ngược giá trị, vào Edit health check.

Tích vào Invert health check status và lưu lại.

Giờ bạn thấy Health check có tên eu-central-1 đã chuyển trạng thái Unhealthy.

Khi sử dụng lệnh dig bạn sẽ không thấy value ở trạng thái Unhealthy.

13. Domain Registar vs. DNS Service.

Khi bạn muốn sở hữu một tên miền (domain name), bạn có thể mua hoặc đăng ký với một nhà đăng ký tên miền (Domain Registrar) thông thường bằng cách trả phí hàng năm (ví dụ như GoDaddy, Amazon Registrar Inc.,…). Sau đó, nhà đăng ký tên miền thường cung cấp cho bạn một dịch vụ DNS để quản lý các bản ghi DNS của bạn.

Tuy nhiên, bạn có thể sử dụng một dịch vụ DNS khác để quản lý các bản ghi DNS của mình. Ví dụ, bạn có thể mua tên miền từ GoDaddy và sử dụng Route 53 để quản lý các bản ghi DNS của mình. Việc này cho phép bạn sử dụng các tính năng mạnh mẽ của Route 53 để quản lý DNS của bạn như kiểm soát dịch vụ và các bản ghi của bạn, tối ưu hóa các bản ghi DNS để cải thiện hiệu suất và độ tin cậy của ứng dụng của bạn, cũng như giám sát hoạt động của tên miền và các bản ghi DNS của bạn.

14. GoDaddy as Registrar & Route 53 as DNS Service.

GoDaddy là một trong những nhà cung cấp dịch vụ đăng ký tên miền (Domain Registrar) phổ biến trên thế giới, cho phép người dùng đăng ký và quản lý tên miền cho các trang web, ứng dụng và dịch vụ trực tuyến của họ.

Route 53 là dịch vụ DNS (Domain Name System) do Amazon cung cấp, cho phép quản lý các bản ghi DNS, như A, CNAME, MX và nhiều hơn nữa, giúp ánh xạ tên miền đến địa chỉ IP của máy chủ.

Khi mua tên miền từ GoDaddy, người dùng sẽ được cung cấp một dịch vụ DNS miễn phí từ nhà cung cấp này. Tuy nhiên, người dùng cũng có thể sử dụng dịch vụ DNS của Route 53 để quản lý bản ghi DNS cho tên miền của họ. Điều này có thể hữu ích đối với các khách hàng AWS đã sử dụng các dịch vụ khác của AWS và muốn quản lý tất cả các tài nguyên của mình từ cùng một nơi.

Với việc sử dụng GoDaddy làm nhà cung cấp đăng ký tên miền và sử dụng Route 53 làm dịch vụ DNS, người dùng có thể tận dụng được tính năng và lợi ích của cả hai dịch vụ để quản lý tên miền và bản ghi DNS của mình một cách hiệu quả và thuận tiện.

15. 3rd Party Registrar with Amazon Route 53.

Khi bạn mua tên miền của mình từ một đăng ký tên miền của bên thứ ba, bạn vẫn có thể sử dụng Route53 làm nhà cung cấp Dịch vụ DNS. Để làm điều này, bạn cần tạo một Vùng lưu trữ trên Route 53 và cập nhật các bản ghi NS (Name Server) trên trang web của đăng ký tên miền thứ ba để sử dụng Name Server của Route 53.

Tuy nhiên, cần phải hiểu rằng Đăng ký tên miền không phải là Dịch vụ DNS. Mỗi Đăng ký tên miền thường đi kèm với một số tính năng DNS. Tuy nhiên, bạn vẫn có thể sử dụng một nhà cung cấp Dịch vụ DNS khác để quản lý bản ghi DNS của mình nếu muốn.