نظرة عامة #

الهدف من المقالة التالية هو تقديم نظرة عامة معمارية على RELIANOID موازن التحميل البرامج الداخلية الموجهة إلى مسؤولي النظام ومطوري البرامج المهتمين بمعرفة المزيد حول كيفية RELIANOID برنامج ADC فعال. يمكن استخدام جميع هذه المعلومات أيضًا للمساعدة في تهيئة أنظمة الإنتاج أو استكشاف الأخطاء وإصلاحها.

RELIANOID هندسة معمارية #

RELIANOID يدير العمليات من كل من مساحة المستخدم والنواة مما يسمح بجمع أكبر قدر من الأداء ولكن مع أكبر قدر من المرونة أيضًا لأداء جميع المهام المفوضة إلى وحدة التحكم في تسليم التطبيق مثل موازنة التحميل والأمان والتوافر العالي.

يوضح الرسم البياني أدناه عرضًا شاملاً للمكونات المختلفة التي تشكل RELIANOID داخليًا. تم تجاهل أجزاء إضافية أقل أهمية لتقديم رؤية أبسط وأوضح.

في الأقسام التالية سيتم وصف الأجزاء المختلفة وكيفية ارتباطها ببعضها البعض.

RELIANOID موازن التحميل في مساحة المستخدم #

الأنظمة الفرعية المستخدمة في مساحة المستخدم هي:

واجهة المستخدم الرسومية للويب: واجهة المستخدم الرسومية للويب التي يستخدمها المستخدمون لإدارة تكوين وإدارة النظام بأكمله، ويتم إدارتها بواسطة خادم ويب HTTPS الذي يستهلك RELIANOID واجهة برمجة التطبيقات لجميع الإجراءات التي يتم إجراؤها على موازن التحميل.

RELIANOID API: or RELIANOID واجهة برنامج التطبيق، مصممة وفقًا لـ REST و JSON يتم استهلاكها من خلال HTTPS، ويتم استخدامها بواسطة واجهات مستخدم مختلفة أخرى من وجهة نظر المستخدم مثل واجهة المستخدم الرسومية للويب واجهة أو زد سي إل آي (RELIANOID تتحقق هذه الأداة من أي إجراء ضد نظام فرعي RBAC، وإذا سُمح به، فسيتم اتخاذ الإجراء في RELIANOID الجهاز. واجهة برمجة التطبيقات قادرة على الاتصال وإدارة أي نظام فرعي آخر لمساحة المستخدم كما هو موضح في الرسم التخطيطي.

RBAC: التحكم في الوصول القائم على الأدوار هو آلية وصول وتحكم مُحددة للمستخدمين والمجموعات والأدوار. تُحدد هذه الوحدة الإجراءات المسموح بها للمستخدم مع مستوى عالٍ من التهيئة بين المجموعات والمستخدمين والأدوار. وهي مُدمجة بالكامل في واجهة المستخدم الرسومية للويب، مما يسمح بتحميل عروض الويب بناءً على دور المستخدم. بالإضافة إلى ذلك، يتم استخدام هذا النظام الفرعي من خلال API أو أي أداة أخرى تستخدم API.

LSLB – HTTP(S): يتم تنفيذ وحدة LSLB (موازن تحميل الخدمة المحلية) المُكوّنة من ملف تعريف HTTP(S) في مساحة المستخدم بواسطة وكيل عكسي يُسمى Zproxy، والذي يُدير التطبيقات عالية الإنتاجية بكفاءة عالية. يتم تكوين هذا النظام الفرعي بواسطة واجهة برمجة التطبيقات (API)، ويمكن حمايته بواسطة نظام IPDS الفرعي (باستخدام القوائم السوداء، وقواعد DoS، وقواعد RBL، وWAF).

GSLB: يتم تنفيذ وحدة GSLB (موازن حمل الخدمة العالمي) المُنفَّذة باستخدام نموذج ملف تعريف GSLB في مساحة المستخدم بواسطة عملية خادم DNS تُسمى Gdnsd، وهي قادرة على العمل كخادم أسماء DNS متقدم مع ميزات موازنة الحمل. يتم تكوين هذا النظام الفرعي بواسطة واجهة برمجة التطبيقات (API)، ويمكن حمايته بواسطة نظام IPDS الفرعي (باستخدام القوائم السوداء، وهجمات الحرمان من الخدمة، وهجمات RBL).

فحوصات طبية: يتم تكوين هذا النظام الفرعي بواسطة واجهة برمجة التطبيقات (API)، وتستخدمه جميع وحدات موازنة الأحمال (LSLB وGSLB وDSLB) للتحقق من سلامة الخوادم الخلفية. تُنفذ عمليات فحص بسيطة ومتقدمة على الخوادم الخلفية، وفي حال فشل الفحص، تُعلَّم الخوادم الخلفية للمزرعة المعنية بأنها معطلة، ولا تُعاد توجيه أي بيانات حتى يعمل الفحص مجددًا على الخوادم الخلفية. "حارس المزرعة" مسؤول عن هذه الفحوصات، وهو مصمم بمرونة عالية وقابلية للتكوين.

نظام ملفات التكوين: يتم استخدام هذا الدليل لأغراض حفظ التكوين، وسيتم تكرار أي تغيير في هذا الدليل إلى المجموعة، إذا تم تمكين هذه الخدمة.

Nftlb: يتم إدارة عملية مساحة المستخدم هذه بواسطة نظام فرعي API ويتم استخدامها لغرضين رئيسيين: LSLB – L4XNAT إدارة وتكوين اي بي دي اس وحدة النظام الفرعي.

RELIANOID مُوازن التحميل في مساحة النواة #

الأنظمة الفرعية المستخدمة في Kernel Space هي:

نظام Netfilter LSLB L4xNAT: يستخدم Nftlb نظام Netfilter الفرعي لأغراض موازنة التحميل. تُحمّل قواعد Netfilter في النواة بواسطة عملية Nftlb هذه من أجل: بناء موازن تحميل عالي الأداء L4يُحمّل Nftlb قواعد مُوازن التحميل في النواة بكفاءة لإدارة حزم البيانات على النحو الأمثل. بالإضافة إلى ذلك، يُحمّل Nftlb قواعد Netfilter لمنع التطفل والحماية منه (القوائم السوداء، وهجمات RBL، وهجمات الحرمان من الخدمة).

القوائم السوداء لـ IPDS: هذا النظام الفرعي مُدمج في نظام Netfilter ويُدار بواسطة Nftlb. يتكون من مجموعة قواعد مُهيأة قبل قواعد مُوازن التحميل من أجل: إسقاط الاتصالات لعناوين IP الأصلية المحددة. داخليًا، يقوم بإنشاء مجموعة من القواعد مرتبة حسب الفئة والبلد وأنواع المهاجمين وما إلى ذلك ويتم تحديثها على أساس يومي.

IPDS RBLعلى غرار سابقه، يُدمج هذا النظام الفرعي أيضًا في Netfilter ويُدار بواسطة Nftlb. يتم التقاط عنوان IP الأصلي قبل إنشاء الاتصال، ويتم التحقق من صحة عنوان IP الخاص بالعميل. خدمة DNS الخارجيةإذا تم حل عنوان IP، فسيتم وضع علامة على عنوان IP باعتباره ضارًا وسيتم قطع الاتصال.

IPDS DoS: نظام التكوين نفسه للوحدتين السابقتين، مُدمج في Netfilter ويُدار بواسطة Nftlb. وهو عبارة عن مجموعة قواعد مُهيأة قبل قواعد موازنة الحمل للتحقق مما إذا كانت الحزم جزءًا من هجوم رفض الخدمةيتم تطبيق بعض القواعد على تدفق الحزمة لاعتراض الهجوم قبل تنفيذه.

نظام تتبع الاتصال: يستخدم هذا النظام بواسطة نظام Netfilter الفرعي لأغراض إدارة الاتصال وترجمة الشبكة ولأغراض وحدة الإحصاء، فضلا عن فحص طبي نظام فرعي لفرض إجراءات الاتصال عند اكتشاف مشكلة في الواجهة الخلفية. كما يستخدم نظام تتبع الاتصال خدمة التجميع من أجل إعادة توجيه حالة الاتصال إلى العقدة الثانية للمجموعة، في حالة فشل عقدة رئيسية للمجموعة، تكون العقدة الثانية قادرة على إدارة حركة المرور في نفس حالة الاتصال الخاصة بالعقدة الرئيسية السابقة.

نظام التوجيه وDSLB: تُدار هذه الأنظمة الفرعية بواسطة واجهة برمجة التطبيقات (API) وتُهيأ في مساحة النواة. يُبنى نظام التوجيه الفرعي باستخدام iproute2 مما يسمح لنا بإدارة جداول التوجيه المتعددة بالترتيب لتجنب الحفاظ على مجموعة قواعد معقدة للتوجيه الثابتبالإضافة إلى ذلك، بفضل iproute2، تم إنشاء وحدة DSLB (موازن تحميل خدمة Datalink) لتوفير موازنة تحميل الروابط الصاعدة مع عدة بوابات.

في لحظة كتابة هذا المقال ، RELIANOID تم إطلاق الإصدار 6 في مرحلة الإنتاج، لذا يمكن أن تتطور هذه الأنظمة الفرعية في الإصدارات المستقبلية لتقديم أداء أفضل أو ميزات أكثر.

وثائق اضافية #

RELIANOID معايير zproxy، ملف تعريف LSLB -HTTP(S)
RELIANOID معايير nftlb، ملف تعريف LSLB – L4xNAT