OK, từ đầu;
Bỏ phiếu cho câu hỏi của bạn từ tôi; câu hỏi của bạn không đủ rõ ràng dựa trên câu trả lời của bạn trong các bình luận cho câu trả lời của người khác. Bạn đã cho rằng giải pháp là liên quan đến kỹ thuật mạng nhưng dường như bạn không biết và đưa ra ấn tượng rằng bạn hy vọng ai đó sẽ cung cấp cho bạn câu trả lời bạn cần.
Bạn có yêu cầu vấn đề sau đây;
host1 và host2 được kết nối thông qua router1 và router2 với hai liên kết giữa chúng. Mỗi bộ định tuyến sao chép mọi gói đến từ máy chủ trước khi chuyển tiếp chúng vào cả hai liên kết. Sau đó, bộ định tuyến ngang hàng hoặc ngăn xếp IP máy chủ đích sẽ xử lý việc loại bỏ gói dự phòng.
- Trừ khi kết nối của máy chủ cuối của bạn với bộ định tuyến cục bộ của họ gấp đôi tốc độ lưu lượng truy cập qua một liên kết duy nhất giữa
router1và router2, mà bạn chưa đề cập, máy chủ của bạn sẽ cần hai kết nối đến bộ định tuyến cục bộ của họ. Có NO phần mềm bản địa hoặc sản phẩm bất cứ nơi nào có thể chạy trên một host cuối và mất hai TCP suối xuống cùng NIC hoặc hai người riêng biệt và kéo từ một dòng thay thế thiếu gói từ dòng đầu tiên. Làm thế nào để tôi biết điều này? Vì đó không phải là cách mạng hoạt động, IP & TCP đơn giản là không được thiết kế để hoạt động như vậy. Có thể có các sản phẩm để sao chép các gói, nhưng đây là một phân khúc thích hợp, không có phạm vi rộng, vì đó là câu trả lời sai cho câu hỏi.
Tại sao điều này là một yêu cầu bonkers như vậy;
Bạn dường như đang cố gắng đặt một cái chốt tròn vào một cái lỗ vuông. Sự hiểu biết của tôi về yêu cầu vấn đề của bạn là bạn muốn dự phòng cho dữ liệu của ứng dụng của bạn di chuyển giữa các máy chủ từ xa. Dữ liệu được gửi hai lần từ đầu đến cuối trong trường hợp liên kết bị lỗi. Đó là tất cả những gì bạn đang bảo vệ chống lại ở đây với các luồng TCP kép, thất bại lớp 1 vật lý. Nếu có sự tạm dừng trong việc gửi một gói từ máy chủ này sang máy chủ khác, nó sẽ bị trễ khi cả hai liên kết bộ định tuyến đến bộ định tuyến. Nếu xảy ra sự cố thoáng qua trên một liên kết chứ không phải liên kết khác, chẳng hạn như tắc nghẽn, bộ định tuyến ở cuối liên kết, sẽ cần theo dõi đồng thời cả hai luồng TCP để thấy rằng khi một gói đến liên kết 2 với số thứ tự tiến hành trong đó tiêu đề và không có gì đã đến trên link1, sau đó gói trên link1 bị trễ và nếu nó bật lên, nó cần phải loại bỏ nó.
Điều gì sẽ xảy ra nếu bạn thấy bản thân mình trong tình huống có tắc nghẽn trên link1 nhưng không có lưu lượng truy cập nào bị giảm, do lược đồ QoS tốt, nhưng đó là hàng đợi, các gói xuống link1 hiện luôn nằm sau link2. Điều gì sẽ xảy ra nếu link2 không thành công và bộ định tuyến chuyển các gói trên link1 đến các máy chủ cuối, nó sẽ nhận được các gói kép, dừng và truyền lại, v.v., và gây ra sự chậm trễ. Không có gì đạt được ở đây.
Chuyển sang một giải pháp;
Theo tôi, một ý tưởng tốt hơn là có các liên kết lớp 2 giữa hai máy chủ cuối, mở rộng các miền phát sóng của chúng để bao gồm cả các NIC khác. Bạn có thể thực hiện việc này thông qua kết nối trực tiếp lớp 2, mở rộng MPLS / VPLS, dịch vụ của nhà cung cấp lớp 2, đưa bạn chọn, điều này không liên quan nghiêm ngặt ở đây. Mở rộng mạng lớp 2 giữa các máy chủ có nghĩa là bạn không cần phải gây rối với TCP hoặc thực hiện bất kỳ sửa lỗi ma thuật đen hoặc hỗ trợ băng thông nào. TCP sẽ hoàn toàn không biết gì về công nghệ cơ bản và bạn vẫn sẽ có lớp dự phòng liên kết vật lý lớp 1 / vật lý.
Nếu bạn sử dụng giải pháp dựa trên MPLS, bạn có thể sử dụng các tính năng như kỹ thuật lưu lượng (MPLS-TE) để theo dõi độ trễ trên các liên kết và luôn sử dụng liên kết có độ trễ thấp nhất. Bạn có thể sử dụng BFD với MPLS FRR, có thể khiến bạn thất bại 50ms ~ theo thời gian giữa các liên kết. Tôi biết bạn nói rằng bạn không muốn dự phòng thất bại trong giải pháp, nhưng theo tôi thì 50ms là khá nhanh. Nếu ứng dụng của bạn không thể xử lý mất kết nối 50ms, thì bạn cần quay lại bảng vẽ ứng dụng. Không có hệ thống nào tăng 100% thời gian, bạn phải lập kế hoạch cho các lỗi, bảo trì theo kế hoạch và ngừng hoạt động thông qua mục đích xấu / bảo mật liên quan; để tất cả xảy ra tại một số điểm. Bạn phải thực tế.
Trong một bình luận bạn đã nói như sau;
tốt, IP SLA là công nghệ đang được sử dụng ít nhất ở một đầu cho đến nay ... :) tuy nhiên phải mất khá nhiều thời gian để cả hai đầu phát hiện lỗi liên kết và đôi khi ứng dụng không đồng bộ ... và các liên kết có thể đôi khi lấp lánh ... đó là lý do tại sao chúng ta đang tìm kiếm thứ gì đó không có độ trễ
Không có điều như vậy; Thời gian phải trôi qua để các sự kiện có thể trở thành hiện thực. Bạn cần suy nghĩ lại về mức độ trì hoãn "chấp nhận được".
Cũng trong một bình luận khác mà bạn nói;
BGP phải mất khá nhiều thời gian để phát hiện ra rằng tuyến đường được coi là hoạt động hiện đã ngừng hoạt động; cuối cùng các bộ định tuyến nhận ra điều này và chuyển đổi các tuyến hoạt động, nhưng phải mất thời gian và giao thức cấp ứng dụng có thể bị ảnh hưởng
BGP có một bộ đếm thời gian xin chào, điều này đang phát hiện sự hiện diện của người hàng xóm ngay lập tức. Mặc định là 30 giây, tôi nghi ngờ đây là những gì bạn đang đề cập quá. Nếu cả hai bộ định tuyến trong cấu trúc liên kết của bạn nói BGP với ISP tại mỗi trang hoặc thậm chí trực tiếp với nhau, thì các bộ định tuyến đó sẽ tạo các đường hầm IP-in-IP của đường hầm GRE hoặc L2TP (v3) giữa hai bộ định tuyến, qua các đường hầm đó chạy BFD hoặc IP SLA. Bây giờ bạn có thể phát hiện mất kết nối đầu cuối trong 1 hoặc 2 giây và định tuyến lại đến đường hầm khác bằng cách sử dụng các đối tượng xử lý.
Nhìn chung, dường như bạn đang trộn lẫn các lớp công nghệ khác nhau. BGP không giả sử cung cấp định tuyến lại nhanh, TCP không được cho là trùng lặp, v.v. Bạn đang nhìn vào mức độ trừu tượng sai để giải quyết vấn đề này. Mình hy vọng rằng nó đã có ích.