sbulb
v0.3.0
نموذج أولي للحمل UDP باستخدام BCC (XDP/BPF)
usage: sbulb [-h] -vs VIRTUAL_SERVER
(-rs REAL_SERVER [REAL_SERVER ...] | -cfg CONFIG_FILE) -p PORT
[PORT ...] [-d {0,1,2,3,4}]
[-l {CRITICAL,ERROR,WARNING,INFO,DEBUG,TRACE}] [-mp MAX_PORTS]
[-mrs MAX_REALSERVERS] [-ma MAX_ASSOCIATIONS]
ifnet
positional arguments:
ifnet network interface to load balance (e.g. eth0)
optional arguments:
-h, --help show this help message and exit
-vs VIRTUAL_SERVER, --virtual_server VIRTUAL_SERVER
<Required> Virtual server address (e.g. 10.40.0.1)
-rs REAL_SERVER [REAL_SERVER ...], --real_server REAL_SERVER [REAL_SERVER ...]
<Required> Real server address(es) (e.g. 10.40.0.2 10.40.0.3)
-cfg CONFIG_FILE, --config_file CONFIG_FILE
<Required> a path to a file containing real server address(es).
File will be polled each second for modification and configuration
updated dynamically. A file content example :
[Real Servers]
10.0.0.4
10.0.0.2
10.0.0.6
-p PORT [PORT ...], --port PORT [PORT ...]
<Required> UDP port(s) to load balance
-d {0,1,2,3,4}, --debug {0,1,2,3,4}
Use to set bpf verbosity, 0 is minimal. (default: 0)
-l {CRITICAL,ERROR,WARNING,INFO,DEBUG,TRACE}, --loglevel {CRITICAL,ERROR,WARNING,INFO,DEBUG,TRACE}
Use to set logging verbosity. (default: ERROR)
-mp MAX_PORTS, --max_ports MAX_PORTS
Set the maximum number of port to load balance. (default: 16)
-mrs MAX_REALSERVERS, --max_realservers MAX_REALSERVERS
Set the maximum number of real servers. (default: 32)
-ma MAX_ASSOCIATIONS, --max_associations MAX_ASSOCIATIONS
Set the maximum number of associations. (default: 1048576)
This defined the maximum number of foreign peers supported at the same time.
على سبيل المثال: sudo python3 -m sbulb eth0 -vs 10.188.7.99 -rs 10.188.100.163 10.188.100.230 -p 5683 5684
يمكن اعتبار موازن التحميل هذا بمثابة طبقة تحميل الطبقة 4 NAT لأنه يعدل فقط عنوان IP.
لحركة المرور:
clientip:port/realserverip Association.لحركة الخروج:
clientip:port/realserverip Association.نحتفظ بهذا الارتباط هو خريطة LRU كبيرة لأطول فترة ممكنة ، مما يعني أن أقدم جمعية تتم إزالة فقط إذا كانت خريطة LRU ممتلئة ويجب إنشاء ارتباط جديد.
الخوارزمية المستخدمة هي روبن مستدير بسيط.
في المجموعة ، تكون الممارسة الجيدة بشكل عام مشاركة الحالات بين كل مثيلات خادم ، ولكن في وقت ما لا يمكن مشاركة بعض الحالات ...
مثل مجموعة من الخوادم التي لا يمكن مشاركة اتصال DTLS ، في هذه الحالة تريد دائمًا إرسال حزمة من عميل معين إلى نفس الخادم للحد من عدد المصافحة.
للقيام بذلك ، تحتاج إلى إنشاء ارتباط طويل الأجل بين العميل والخادم ، ولكن معظم udp loadbalancer هي أن يكون لها ارتباط الفلكي. في معظم الأوقات ، يمكن تكوين عمر الارتباط هذا ويمكنك تعيين قيمة كبيرة ، ولكن هنا بفضل خريطة LRU ، يمكننا الحفاظ على الارتباط طالما استطعنا.
النقطة الأخرى هي الاتصال الخادم . نريد أن نكون قادرين على بدء الاتصال من خادم تمامًا كما لو أن الاتصال بدأ من قبل العميل. وهذا يعني استخدام جدول الارتباط نفسه.
هذا هو محمل بسيط للحمل ، ولذا فإنه يحتوي على بعض القيود:
تحتاج:
يدعم SBULB آلية SD_NOTIFY (3) ، ولكن لا تتطلب تشغيل SystemD أو أي مكتبة SystemD. هذا يسمح لـ SBULB بإخطار SystemD عندما يكون جاهزًا لقبول الاتصالات. لاستخدام هذه الميزة ، يمكنك كتابة خدمة مثل هذه:
[Unit]
Description=UDP Load Balancer
Wants=network-online.target
[Service]
Type=notify
NotifyAccess=all
Environment=PYTHONUNBUFFERED=1
ExecStart=/usr/bin/python3 -m slulb args...
[Install]
WantedBy=multi-user.target
انظر صفحة الويكي الخاصة بنا حول ذلك.
لإطلاق اختبارات الوحدة:
sudo python3 -m unittest # all tests
sudo python3 -m unittest sbulb.tests.IPv4TestCase # only 1 test case
sudo python3 -m unittest sbulb.tests.IPv4TestCase.test_lru # only 1 test
تحتاج الاختبارات إلى BCC V0.14 (Python3-BPFCC) و SCAPY (PYTHON3-SCAPY).
لماذا XDP/BPF؟ لماذا يستبدل مجتمع kernel iPtables بـ BPF؟.
اقرأ عن XDP/BPF: الغوص في BPF: قائمة مواد القراءة.
الإلهام:
الوثائق:
أُطرُوحَة :
