linux nhiều kết nối internet cân bằng tải với xử lý không thành công


7

Tôi có hai kết nối ISP và cần cân bằng tải tự động giữa chúng. Tôi cũng cần xử lý các kết nối bị lỗi (không sử dụng kết nối không hoạt động).

Liên kết đầu tiên là kết nối PPTP ( ppp0), thứ hai là Ethernet thông thường. Hệ thống là Gentoo Linux.

Hiện tại, tôi đã đạt được sự cân bằng cơ bản với ip route, nhưng có vẻ như nó không hoạt động tốt. Đây là những gì tôi đã sử dụng:

ip rule $ADD from $IP1 table rt_link1
ip rule $ADD fwmark 1 lookup rt_link1
ip rule $ADD from $IP2 table rt_link2
ip rule $ADD fwmark 2 lookup rt_link2
$NET2 dev eth2 src $IP2 table rt_link2
default via GW2 table rt_link2
$NET2 dev eth2 src $IP2
$NET1 dev ppp0 src $IP1 table rt_link1
default via GW1 table rt_link1
$NET1 dev ppp0 src $IP1
default scope global nexthop via $GW1 weight 1 nexthop via $GW2 dev eth2 weight 1

Câu trả lời:


3

Là cựu thành viên nhóm nòng cốt của dự án LVS, tôi sẽ khuyên bạn không nên sử dụng công nghệ này để cân bằng nhiều kết nối internet; thực tế tôi gần như có thể đảm bảo với bạn rằng nó sẽ không hoạt động như mong đợi.

Bây giờ, việc xử lý các liên kết nhà cung cấp không thành công thường được gọi là phát hiện cổng chết (DGD) và đôi khi được gọi là phát hiện không thể truy cập hàng xóm (NUD). Theo RFC816 và RFC1122, có nhiều cách để thực hiện DGD, tuy nhiên tôi chỉ thấy khoảng 3 trong số đó (từ một bài đăng cũ của tôi đến danh sách gửi thư của LVS):

  • Thông tin lớp liên kết phát hiện và báo cáo lỗi máy chủ đáng tin cậy (ví dụ: ARPANET Destination Dead message) nên được sử dụng làm lời khuyên tiêu cực.
  • Thông điệp chuyển hướng ICMP từ một cổng cụ thể nên được sử dụng làm lời khuyên tích cực về cổng đó.
  • Các gói đến từ một địa chỉ lớp liên kết cụ thể là bằng chứng cho thấy hệ thống tại địa chỉ này còn sống. Tuy nhiên, việc chuyển thông tin này thành lời khuyên về các cổng yêu cầu ánh xạ địa chỉ lớp liên kết thành địa chỉ IP, sau đó kiểm tra địa chỉ IP đó theo các cổng được chỉ ra bởi bộ đệm tuyến. Điều này có lẽ là không hiệu quả.

Khi tôi rời khỏi sự phát triển mạng nhân linux đang hoạt động vào năm 2006, vẫn chưa có quyết định rõ ràng nào về cách thực hiện các thay đổi trạng thái NUD. Một người bạn của tôi và nhà phát triển cốt lõi của LVS, Julian Anastasov, cần phải giải quyết thách thức của bạn vào năm 2002. Vì vậy, vào một buổi tối, anh ấy ngồi xuống và viết một phiên bản làm việc của DGD để định tuyến tĩnh bằng cách thêm trạng thái NUD vào FIB (thông tin chuyển tiếp căn cứ). Bạn có thể tìm thấy bản vá của mình ở đây và các tài liệu ở đây , đâyđây . Điều này sẽ cung cấp cho bạn nhiều thông tin về nhiệm vụ tiếp theo của bạn trong việc giải quyết nhiệm vụ không tầm thường này. Tôi thấy rằng các bản vá vẫn còn được sử dụng rất nhiều và do đó được cập nhật với các hạt nhân gần đây. Bạn có thể muốn bắt đầu với một tập lệnh như sau (được viết bởiRobert Kurjata ):

#!/bin/bash
# This script is done by : Robert Kurjata Sep, 2003.
# feel free to use it in any useful way

# CONFIGURATION
IP=/sbin/ip
PING=/bin/ping

#--------------- LINK PART -----------------
# EXTIFn - interface name
# EXTIPn - outgoing IP
# EXTMn  - netmask length (bits)
# EXTGWn - outgoing gateway
#-------------------------------------------

# LINK 1
EXTIF1=eth2
EXTIP1=
EXTM1=
EXTGW1=

# LINK 2
EXTIF2=eth1
EXTIP2=
EXTM2=
EXTGW2=

#ROUTING PART
# removing old rules and routes

echo "removing old rules"
${IP} rule del prio 50 table main
${IP} rule del prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule del prio 202 from ${EXTIP2}/${EXTM2} table 202
${IP} rule del prio 221 table 221
echo "flushing tables"
${IP} route flush table 201
${IP} route flush table 202
${IP} route flush table 221
echo "removing tables"
${IP} route del table 201
${IP} route del table 202
${IP} route del table 221

# setting new rules
echo "Setting new routing rules"

# main table w/o default gateway here
${IP} rule add prio 50 table main
${IP} route del default table main

# identified routes here
${IP} rule add prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule add prio 202 from ${EXTIP2}/${EXTM2} table 202

${IP} route add default via ${EXTGW1} dev ${EXTIF1} src ${EXTIP1} proto static table 201
${IP} route append prohibit default table 201 metric 1 proto static

${IP} route add default via ${EXTGW2} dev ${EXTIF2} src ${EXTIP2} proto static table 202
${IP} route append prohibit default table 202 metric 1 proto static

# mutipath
${IP} rule add prio 221 table 221

${IP} route add default table 221 proto static \
            nexthop via ${EXTGW1} dev ${EXTIF1} weight 2\
            nexthop via ${EXTGW2} dev ${EXTIF2} weight 3

${IP} route flush cache

while : ; do
  ${PING} -c 1 ${EXTGW1}
  ${PING} -c 1 ${EXTGW2}
  sleep 60
done

Ngoài ra, bạn có thể kiểm tra tùy chọn chạy các giao thức định tuyến động.


có lẽ kịch bản này quá cũ Nó không hoạt động trên Ubuntu mới nhất.
Zibri

@Zibri: Tôi không hiểu phần "quá cũ" kết hợp với tập lệnh, nhưng chính xác thì cái gì không hoạt động và cái gì tạo thành "Ubuntu mới nhất"?
Moreaki

0

Sử dụng LVS kết hợp với lvs-Kiss. Hoặc một cái gì đó tương tự.

LVS về cơ bản là ìpvsadmlệnh. Hạn chế duy nhất của bộ cân bằng tải đó là nó không giám sát. Vì vậy, bạn cần một chương trình làm điều đó cho bạn và loại bỏ liên kết chết khỏi cấu hình của bạn (và thêm nó trở lại một lần nữa).

ldirectord từ stack heartbeat có thể là một bổ sung lvs khác (thay vì lvs-Kiss).


thx, tôi sẽ kiểm tra
sss123next

xin lỗi, tôi không hiểu cách sử dụng lvs để sử dụng hai đường lên, vì tôi biết lvs là để cân bằng lưu lượng đến giữa nhiều nút phisical, nhưng tôi cần sử dụng nhiều kết nối internet trên một máy
ảo

Vì vậy, trong trường hợp này, máy chủ của bạn là giám đốc và hai máy chủ thực sự trong cùng một hộp. Một máy chủ thực sự đang phục vụ ppp0, eth2 khác. Lưu lượng truy cập mạng LAN đến từ eth0 và / hoặc eth1?
Nils

bao gồm lưu lượng truy cập lan đến từ br1, nhưng tôi vẫn không hiểu cách sử dụng lvs cho NAT
sss123next

@ sss123next thay vì sử dụng NAT Tôi khuyên bạn nên sử dụng proxy phù hợp - ví dụ: SQUID.
Nils
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.