Có thể sử dụng nhiều bộ cân bằng tải để chuyển hướng lưu lượng truy cập đến các máy chủ ứng dụng của tôi không?

Tôi mới sử dụng cân bằng tải và tôi tự hỏi liệu có thể sử dụng nhiều bộ cân bằng tải để chuyển hướng lưu lượng truy cập đến các máy chủ ứng dụng của mình không. Tôi thực sự không hiểu làm thế nào điều này có thể được thực hiện. Không phải tên miền phải khớp một với một địa chỉ IP của một máy chủ nhất định (trong trường hợp này là IP của một bộ cân bằng tải)? Nếu mỗi máy chủ cân bằng tải có một IP khác nhau, làm thế nào có thể nhận được yêu cầu của cả hai bộ cân bằng tải (hoặc bởi 10 bộ cân bằng tải hoặc 50 hoặc 100)?

Sử dụng DNS vòng tròn không phải là điều tuyệt vời cho tính khả dụng cao - nếu một máy chủ ngoại tuyến, khách hàng vẫn sẽ cố gắng kết nối với nó và chờ thời gian chờ.

Có nhiều cách khác để đạt được điều này.
1) Bộ cân bằng tải chủ động / thụ động
Về cơ bản, một bộ cân bằng tải xử lý tất cả lưu lượng truy cập cho một địa chỉ IP.
Nếu bộ cân bằng đó đi xuống, nút thụ động nhảy vào và chiếm lấy IP.
Hãy nhớ rằng các bộ cân bằng tải khá nhiều chỉ chuyển tiếp lưu lượng, vì vậy đối với các trang web có quy mô vừa và nhỏ, điều này có thể hoạt động tốt.

2)
Bộ cân bằng tải hoạt động / hoạt động Cùng một IP lưu lượng được cấu hình trên cả hai (hoặc nhiều hơn nữa) bộ cân bằng tải.
Lưu lượng truy cập đến được gửi đến tất cả các bộ cân bằng tải nhưng thuật toán chọn bộ cân bằng nào sẽ đáp ứng, tất cả các loại khác sẽ loại bỏ lưu lượng đó.
Cách đơn giản để nghĩ về nó, bạn có hai bộ cân bằng tải:
Khi IP yêu cầu kết thúc bằng số chẵn thì tải cân bằng A trả lời, nếu không thì tải cân bằng B trả lời.

Tất nhiên cơ sở hạ tầng của bạn phải hỗ trợ điều này và có phí do lưu lượng truy cập được gửi nhưng bị loại bỏ.
Thêm thông tin, ví dụ tại đây: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-hosted-IP-addresses-in-Stingray/ta-p/73867

Tính sẵn sàng cao với các bộ cân bằng tải thường được triển khai bằng giao thức địa chỉ IP ảo (VIP) cho phép một số máy chủ (tức là bộ cân bằng tải) trả lời một địa chỉ IP chung theo một trong các cách có thể (biến thể chủ động / thụ động, chủ động / hoạt động) .

Có một số lượng tốt các giao thức này, những giao thức mà tôi đã thấy nhiều nhất với các bộ cân bằng tải thông thường là VRRP và NLB (cũng như nhiều giao thức hộp đen không cần thiết trong các thiết bị). Mở rộng sang các bộ định tuyến và tường lửa, người ta cũng có thể gặp CARP , HRSP , GLSP .

Chiến lược này có một số lợi ích đối với việc cân bằng tải DNS, đây là một chiến lược đơn giản hơn (và được quan tâm trong câu trả lời khác).

Ví dụ, cân bằng tải DNS bị gánh nặng với:

• doanh thu chậm của các cơ chế bộ nhớ đệm dns
• thuật toán cân bằng tải hạn chế (thường chỉ là quay vòng)
• gia công của quyết định cân bằng tải cho khách hàng (thông qua bộ nhớ đệm của bản ghi dns)
• Việc thoát chậm hàng đợi dịch vụ khi một máy chủ (tức là bộ cân bằng tải) được đưa ra khỏi vòng quay (dựa trên các bản ghi dns ghi lại được xử lý bởi ISP và máy khách )
• Chuyển đổi dự phòng chậm trên thất bại cân bằng tải

Ví dụ, sử dụng giao thức ip ảo cho HA, người ta có thể có một lựa chọn để đạt được:

• Lựa chọn thuật toán cân bằng tải trong số các cân bằng tải
• Các quyết định cân bằng tải trung tâm của máy chủ (ví dụ như các biện pháp và định tuyến dựa trên sức khỏe của dịch vụ)
• Thoát nhanh hơn các hàng đợi dịch vụ khi một bộ cân bằng tải được đưa ra khỏi vòng quay.
• Chuyển đổi dự phòng ngay lập tức trên thất bại cân bằng tải

Chỉ có bạn biết chiến lược và giao thức nào phù hợp nhất với kịch bản của bạn.

Các yêu cầu: có một giải pháp thực tế hoạt động cho đám mây hoặc bất kỳ loại môi trường nào không có quyền truy cập vào bộ cân bằng tải phần cứng, giao thức BGP và tất cả những thứ đó.

Số yêu cầu thu nhập của ứng dụng là không xác định nhưng phải đủ cao để đáp ứng kỳ vọng tải tăng mà không sợ hãi.

Chúng ta hãy tìm một ứng dụng có tính chất tải tương tự, ví dụ như cửa hàng ghi nhật ký và ứng dụng tìm kiếm. Tôi tìm thấy một .

Những gì họ muốn:

1. Cân bằng tải trên các bộ sưu tập
2. Cung cấp khả năng chịu lỗi, cho phép chúng tôi tiếp tục nhập dữ liệu nếu một trong những người thu thập chết hoặc đang gặp sự cố
3. Quy mô theo chiều ngang với sự tăng trưởng trong khối lượng nhật ký của chúng tôi

Họ đã cố gắng và học được gì về ELB:

1. Không hoạt động như mong đợi
2. Vấn đề độ trễ do tải tăng
3. Không đủ cơ sở giám sát
4. Quá nhiều giới hạn (số cổng mở và số giao thức)

Tại sao họ chọn với Route53:

1. "Vòng tròn là cân bằng tải khá cơ bản, nhưng nó hoạt động tốt cho chúng tôi từ quan điểm hiệu quả"
2. "Chúng tôi tận dụng lợi thế của kiểm tra sức khỏe dự phòng tuyến 53".
3. "Nếu có vấn đề với người thu gom, Tuyến 53 sẽ tự động đưa nó ra khỏi dịch vụ; khách hàng của chúng tôi sẽ không thấy bất kỳ tác động nào."
4. Không cần khởi động trước với Tuyến 53

Tuyến 53 hóa ra là cách tốt nhất để Loggly tận dụng lợi thế của các nhà sưu tập hiệu suất cao với khối lượng nhật ký khổng lồ, các biến thể không thể đoán trước và tăng trưởng liên tục trong kinh doanh của chúng tôi. Nó phù hợp với mục đích cốt lõi của người thu thập: Để thu thập dữ liệu ở tốc độ đường truyền mạng mà không mất và cho phép chúng tôi hưởng lợi từ tính co giãn của tất cả các dịch vụ AWS chúng tôi sử dụng tại Loggly.

Ví dụ cụ thể đó cho thấy rằng trong một số trường hợp (bộ thu thập nhật ký, dịch vụ quảng cáo hoặc tương tự) bộ cân bằng tải là dự phòng và "giải pháp vòng kiểm tra sức khỏe DNS" thực hiện rất tốt công việc của mình.

Hãy xem AWS nói gì về chuyển đổi dự phòng DNS:

Với DNS Failover, Tuyến 53 có thể phát hiện sự cố ngừng hoạt động của trang web của bạn và chuyển hướng người dùng cuối của bạn đến các vị trí thay thế hoặc sao lưu mà bạn chỉ định. Lộ trình chuyển đổi dự phòng DNS 53 phụ thuộc vào kiểm tra sức khỏe - thường xuyên thực hiện các yêu cầu Internet đến các điểm cuối ứng dụng của bạn từ nhiều địa điểm trên khắp thế giới - để xác định xem mỗi điểm cuối của ứng dụng của bạn lên hay xuống.

Kỹ thuật đó cũng làm cho ELB (không bắt buộc, chỉ cần ghi chú) mạnh mẽ hơn, một lần nữa, nó dựa trên RR + Kiểm tra sức khỏe:

Chuyển đổi dự phòng DNS 53 xử lý tất cả các tình huống lỗi này bằng cách tích hợp với ELB ở hậu trường. Khi được bật, Tuyến 53 sẽ tự động định cấu hình và quản lý kiểm tra sức khỏe cho các nút ELB riêng lẻ.

Bây giờ chúng ta hãy xem cách nó hoạt động đằng sau hậu trường. Câu hỏi rõ ràng là làm thế nào để đối phó với bộ nhớ đệm DNS:

Tuy nhiên, bộ nhớ đệm DNS vẫn có thể là một vấn đề ở đây (xem bài đăng trước của chúng tôi, nơi vấn đề "đuôi dài" được đề cập) nếu tất cả các lớp giữa máy khách của bạn và Tuyến 53 không được tôn trọng. gửi yêu cầu đến một tên miền duy nhất

("http://<unique-id>.<your-domain>") 

và xác định tài nguyên ký tự đại diện

Record "*.<your-domain>" to match it.

Algolia đã giới thiệu "chiến lược thử lại máy khách" hoạt động khá tốt nếu máy khách của bạn (JS trong trường hợp của bạn) có thể xử lý việc đó:

Chúng tôi đã kết thúc việc thực hiện chiến lược thử lại cơ bản trong các máy khách API của mình. Mỗi máy khách API được phát triển để có thể truy cập ba máy khác nhau. Ba bản ghi DNS khác nhau được đại diện cho mỗi người dùng: USERIDID-1 .acheolia.io, USERID-2.acheolia.io vàUSERID-3.acheolia.io. Việc thực hiện đầu tiên của chúng tôi là chọn ngẫu nhiên một trong các bản ghi và sau đó thử lại với một bản ghi khác trong trường hợp thất bại.