VC5

يتم حالياً تحديث ملف README هذا ليعكس التغييرات الأخيرة - قد لا تعكس بعض المعلومات قاعدة الشيفرة الحالية. هذا الإصدار من الشيفرة ليس جاهزاً بعد للاستخدام الإنتاجي - استخدم إصدار v0.2 للإنتاج

موازن تحميل من الطبقة الرابعة (L4LB) قابل للتوسع أفقياً مع إرجاع الخادم المباشر (DSR) لنظام Linux باستخدام XDP/eBPF.

إذا كنت تعتقد أن هذا قد يكون مفيداً أو لديك أي أسئلة/اقتراحات، فلا تتردد في الاتصال بي على [email protected] أو إنشاء مشكلة على GitHub.

الآن يدعم IPv6 والتوزيع في الطبقة الثالثة (المعروفة أيضاً باسم النفق)! تم تحديث مكتبة XVS لتشمل هذه الميزات، كما أنها تستغني عن الحاجة إلى تشغيل فحوصات الصحة من مساحة اسم شبكة، مما يبسط الشيفرة بشكل كبير. سينهي هذا شرط أن تشارك جميع الخوادم الخلفية شبكة VLAN مع موازن التحميل.

القيود الحالية في الشيفرة تعني أن تمكين النفق على أساس كل خدمة غير مدعوم. استخدام الخيار -tunnel يسمح بتفعيل النفق في الطبقة الثالثة عالمياً باستخدام مخطط واحد (IP-in-IP، GRE، FOU أو GUE). مستقبلاً، سيتم تحديث الشيفرة للسماح بتكوين النفق على مستوى الخدمة.

سيظل موازنة التحميل في الطبقة الثانية مدعومة - السبب الرئيسي لبدء المشروع هو عدم وجود دعم للطبقة الثانية في موازن تحميل Katran من Facebook.

يتم تضمين ملف تكوين عينة لـ IPv6/L3 - ستتبع وثائق أفضل قريباً.

حول

VC5 هو موازن تحميل شبكي مصمم للعمل كبديل لأجهزة الأجهزة التقليدية. يسمح بتوزيع الخدمات ذات عناوين IP الافتراضية (VIPs) على مجموعات من الخوادم الخلفية ("الحقيقية"). قد تقوم الخوادم الحقيقية بتشغيل الخدمات بأنفسها أو تعمل كوكلاء لطبقة أخرى من الخوادم (مثل HAProxy يعمل كموجه HTTP في الطبقة 7 / تفريغ SSL عندما تحتاج إلى اتخاذ قرارات على طبقة التطبيق). الشرط الوحيد هو أن يتم تكوين عناوين VIP على جهاز حلقة (loopback) على كل خادم حقيقي، على سبيل المثال: ip addr add 192.168.101.1/32 dev lo

يتم تحديد الخدمات والخوادم الحقيقية في ملف تكوين، إلى جانب تعريفات فحوصات الصحة. عندما تجتاز الخوادم الخلفية الفحوصات ويتوفر عدد كافٍ لتقديم خدمة، يتم الإعلان عن عناوين IP الافتراضية للموجهات عبر BGP.

أصبح توزيع حركة المرور في كل من الطبقة الثانية والطبقة الثالثة مدعوماً الآن. يتطلب التوزيع في الطبقة الثانية أن تشترك الخوادم الحقيقية في شبكة VLAN مع موازن التحميل؛ عند استلام حزمة لتوزيعها، يقوم موازن التحميل بتحديث عناوين الأجهزة الإيثرنت في الحزمة لاستخدام عنوان MAC للخادم الحقيقي كوجهة وعنوان MAC الخاص به كمصدر، ويعيد توجيه الحزمة عبر الواجهة المناسبة، مع تحديث معرف VLAN 802.1Q إذا كانت الحزم موسومة بـ VLAN.

يتطلب التوزيع في الطبقة الثالثة تغليف الحزم في بروتوكول نفق موجه إلى IP الخادم الحقيقي وإعادة توجيهها عبر موجه (إلا إذا كان الخادم وموازن التحميل يشتركان في شبكة VLAN). إذا، عند التغليف، تجاوزت حزمة الحجم الأقصى للإرسال في الشبكة، يتم إرسال رسالة ICMP إلى المصدر بنصيحة حول MTU المناسب للاستخدام. تحتاج الخوادم الخلفية فقط إلى فك تغليف الحزم - التوجيه ثنائي الاتجاه مع موازنات التحميل غير مطلوب.

يجب أن يكون خادم واحد بواجهة شبكة 10Gbit/s قادراً على دعم خدمة HTTP يزيد عرض النطاق الترددي للخروج عن 100Gbit/s بسبب الطبيعة غير المتماثلة لمعظم حركة مرور الإنترنت. للخدمات الأصغر، من المحتمل أن يتعامل جهاز افتراضي متواضع أو اثنان مع خدمة تولد عدة غيغابت/ثانية من حركة مرور الخروج.

إذا لم تكن نسخة واحدة كافية، يمكن إضافة المزيد من الخوادم لتوسيع السعة أفقياً (وتوفير التكرار) باستخدام ميزة ECMP للموجه الخاص بك. يتم دعم واجهات bonded 802.3ad و VLAN trunking 802.1Q (انظر دليل examples/).

لا حاجة لوحدات kernel أو إعدادات معقدة، على الرغم من أنه للحصول على أفضل أداء، يُوصى باستخدام بطاقة شبكة مع دعم وضع XDP الأصلي (مثل: mlx4، mlx5، i40e، ixgbe، ixgbevf، nfp، bnxt، thunder، dpaa2، qede). قائمة كاملة متاحة في صفحة دعم برامج تشغيل مشروع XDP.

الأهداف/الحالة

• ✅ نشر بسيط مع ثنائي واحد
• ✅ اختيار خلفية مستقر باستخدام خوارزمية التجزئة Maglev
• ✅ حقن صحة المسار تتم تلقائياً؛ لا حاجة لتشغيل برامج أخرى مثل ExaBGP
• ✅ غير اختراقي؛ لا يتطلب أي تعديل لقواعد iptables على الموازن
• ✅ لا تعديل لخوادم الخلفية بخلاف إضافة VIP إلى جهاز حلقة/إنهاء النفق مع توزيع L3
• ✅ يتم تشغيل فحوصات الصحة ضد VIP على الخوادم الخلفية، وليس عناوينها الحقيقية
• ✅ فحوصات صحة HTTP/HTTPS، استقصاء SYN نصف مفتوح و UDP/TCP DNS مدمجة
• ✅ تحويل الحزم داخل kernel مع eBPF/XDP؛ برامج تشغيل الوضع الأصلي تتجنب تخصيص sk_buff
• ✅ دعم VLAN متعددة
• ✅ دعم NIC متعددة لتطبيقات ذات عرض نطاق أقل/تطوير
• ✅ أجهزة شبكة موسومة/m bonded لدعم التوفر العالي/عرض النطاق العالي
• ✅ إمكانية المراقبة عبر وحدة تحكم ويب، تسجيل Elasticsearch (قيد التطوير) ومقاييس Prometheus
• ✅ دعم IPv6 والقدرة على مزج خوادم خلفية IPv4 و IPv6 مع أي نوع من VIP.
• ✅ توزيع حركة المرور في الطبقة الثالثة مع دعم IP-in-IP، GRE، FOU و GUE.

بداية سريعة

للحصول على أفضل النتائج، يجب تعطيل/إلغاء تثبيت irqbalance.

ستحتاج إلى تحديد IP أساسي لتمريره إلى الموازن. يتم استخدام هذا كمعرف موجه BGP.

مثال بسيط على خادم بواجهة إيثرنت واحدة غير موسومة:

• apt-get install git make libelf-dev golang-1.20 libyaml-perl libjson-perl ethtool (أو ما يعادله في توزيعتك)
• ln -s /usr/lib/go-1.20/bin/go /usr/local/bin/go (تأكد من وجود ثنائي Go في مسارك)
• git clone https://github.com/davidcoles/vc5.git
• cd vc5/cmd
• cp config.sample.yaml config.yaml (قم بتحرير config.yaml ليتوافق مع متطلباتك)
• make (يسحب مكتبة libbpf، ويبني الثنائي وملف تكوين JSON)
• ./vc5 10.1.10.100 config.json eth0 (عدّل لاستخدام عنوان IP لخادمك وواجهة إيثرنت)
• ستكون وحدة التحكم الويب على منفذ 80 لخادم موازن التحميل افتراضياً
• أضف VIP الخاص بك إلى جهاز الحلقة (loopback) على خوادمك الخلفية (مثل: ip addr add 192.168.101.1/32 dev lo)
• قم بتكوين شبكتك/عميلك لإرسال حركة المرور لـ VIP الخاص بك إلى موازن التحميل، إما عبر BGP (انظر ملف التكوين) أو التوجيه الثابت

من الأسهل بالتأكيد استخدام الثنائي من أحدث إصدار Github (المجمّع لـ x86-64). سيكون هذا قد تم اختباره في الإنتاج لذا يجب أن يكون موثوقاً. تأكد من أن تكوينك متوافق مع هذا الإصدار باستخدام script config.pl من الإصدار الموسوم (أو، بالطبع، يمكنك بناء تكوين JSON الخاص بك كما تفضل).

إذا قمت بتحديث ملف تكوين YAML وأعدت توليد JSON (make config.json) يمكنك إعادة تحميل التكوين الجديد عن طريق إرسال SIGINT (Ctrl-C) أو SIGUSR2 إلى العملية. SIGQUIT (Ctrl-\) أو SIGTERM سيؤدي إلى إنهاء العملية بأناقة عن طريق إغلاق اتصالات BGP والخروج.

مثال أكثر تعقيداً مع جهاز إيثرنت bonded LACP يتكون من واجهتين (Intel X520 10Gbps على خادم الاختبار الخاص بي)، مع تمكين وضع برنامج تشغيل XDP الأصلي و VLANs موسومة:

config.yaml إدخال vlans:

vlans:
  10: 10.1.10.0/24
  20: 10.1.20.0/24
  30: 10.1.30.0/24

سطر الأوامر:

./vc5 -n 10.1.10.100 config.json enp130s0f0 enp130s0f1

سيكتشف الثنائي واجهات VLAN الخاصة بك بالبحث عن أجهزة تحتوي على عناوين IP موجودة في بادئات VLAN في ملف التكوين. إذا كنت تستخدم واجهات فيزيائية غير موسومة منفصلة ، فيجب أن يعمل هذا الآن بشفافية دون أي إعداد إضافي، فقط قم بإدراج جميع الواجهات في سطر الأوامر حتى يتم تحميل شيفرة eBPF في كل منها.

نظراً لأن حالة الاتصال يتم تتبعها على أساس كل نواة (BPF_MAP_TYPE_LRU_PERCPU_HASH)، يجب التأكد من أن RSS (Receive Side Scaling) سيوجه الحزم الخاصة بتدفق باستمرار إلى نفس نواة CPU في حالة اختيار المحول لواجهة مختلفة عند تغير طوبولوجيا LACP. قم بتعطيل irqbalance، وتأكد من أن إعدادات القناة متماثلة على كل واجهة (ethtool -l/-L) وأن توزيع تجزئة تدفق RSS متطابق (ethtool -x/-X).

يمكن اختبار الإعداد عن طريق بدء اتصال طويل الأمد (مثل استخدام iperf مع الخيار -t) لمجموعة من الخوادم الخلفية، ثم تعطيل الخادم الخلفي المختار بإضافة علامة نجمية بعد عنوان IP في ملف التكوين، وتحديد الواجهة التي تستقبل التدفق على موازن التحميل (مثل، watch -d 'cat /proc/interrupts | grep enp130s0f' وابحث عن عداد IRQ المتزايد بسرعة) ثم إسقاط هذه الواجهة من LACP (ifenslave -d bond0 enp130s0f0). يجب أن ترى التدفق ينتقل إلى واجهة الشبكة الأخرى ولكن لا يزال يصيب نفس النواة.

عند استخدام خوادم خلفية في شبكات فرعية متعددة، ولأفضل أداء يجب التأكد من أن جميع VLANs موسومة على واجهة trunk واحدة (LACP bonded إذا كان لديك أكثر من واجهة فيزيائية) مع تعيينات شبكة فرعية/معرف VLAN المحددة في قسم vlans من ملف التكوين.

إذا لم يكن ذلك ممكناً (على سبيل المثال إنشاء واجهات trunked على vSphere ليس بسيطاً)، فيمكنك تعيين كل شبكة فرعية لواجهة غير موسومة مختلفة:

./vc5 10.1.10.100 config.json eth0 eth1 eth2

خلفية/معلومات إضافية

ملخص جيد للمفاهيم المستخدمة تمت مناقشته في محادثة Patrick Shuff "Building a Billion User Load Balancer" و محادثة Nitika Shirokov's Katran

يتم تضمين وحدة تحكم ويب أساسية وخادم مقاييس Prometheus:

دعم elasticsearch لتسجيل البيانات (مباشرة إلى مجموعتك، لا حاجة لجمع سجلات النظام) مضمن الآن. يتم تسجيل كل استقصاء للخوادم الخلفية، لذلك إذا تعطل أحدها يمكنك رؤية الخطأ الذي تم إرجاعه بالضبط، بالإضافة إلى العديد من الشروط الأخرى. سيتطلب هذا الكثير من التحسين وتسمية أكثر منطقية لمعلمات السجل، إلخ. (إذا كان لديك أي رؤى، يرجى الاتصال)، لكنه يجب أن يؤدي إلى القدرة على الحصول على بعض الرؤى الجيدة حول ما يحدث مع النظام - محاولتي الأولى غير الكفؤة لإنشاء لوحة Kibana كمثال:

الأداء

تم اختبار هذا بشكل أساسي باستخدام خوادم خلفية Icecast مع عملاء يسحبون مزيجاً من تدفقات ذات معدلات بت منخفضة وعالية (48kbps - 192kbps).

يبدو أن ضيف VMWare (4 نوى، 8GB) باستخدام برنامج تشغيل XDP العام سيدعم 100K عميل متزامن، و 380Mbps/700Kpps من خلال موازن التحميل و 8Gbps من حركة المرور من الخوادم الخلفية مباشرة إلى العملاء.

على معالج Intel Xeon Gold 6314U واحد (غير افتراضي) (2.30GHz 32 نواة فيزيائية، مع تمكين hyperthreading لـ 64 نواة منطقية) وبطاقة إيثرنت Intel 10G 4P X710-T4L-t، تمكنت من تشغيل 700K تياراً عند 2Gbps/3.8Mpps حركة مرور دخول و 46.5Gbps خروج. كان الخادم خاملاً بأكثر من 90%. لسوء الحظ، لم تكن لدي الموارد المتاحة لإنشاء المزيد من العملاء/الخوادم.

التشغيل

هناك ثلاثة أوضاع تشغيل: بسيط، VLAN، ومتعدد NIC. في الوضع البسيط، يجب أن تكون جميع المضيفين على نفس الشبكة الفرعية لعنوان IP الأساسي لموازن التحميل. في وضع VLAN (مفعل عن طريق إعلان إدخالات تحت قسم "vlans" في ملف تكوين YAML/JSON)، يجب أن تطابق إدخالات الخادم إدخال شبكة فرعية/CIDR الخاصة بـ VLAN. يجب إنشاء واجهات VLAN موسومة في نظام التشغيل وتعيين عنوان IP داخل الشبكة الفرعية. في وضع متعدد NIC، تُعطى الشبكات الفرعية معرفات بنفس طريقة VLANs، ولكن يتم استخدام bpf_redirect() لإرسال حركة المرور خارج الواجهة المكونة بشكل مناسب (بدلاً من تغيير معرف VLAN واستخدام XDP_TX).

في وضع VLAN، يجب أن تكون جميع حركة المرور لموازن التحميل على VLAN موسوم (لا يتم دفع أو إزالة 802.1Q بعد).