نظام إدارة تكوين شبكة تصفية Qrator

TL ؛ DR : وصف بنية خادم العميل لنظام إدارة تكوين الشبكة الداخلية ، QControl. يعتمد على بروتوكول نقل ثنائي المستوى يعمل مع رسائل gzip معبأة دون إلغاء الضغط بين نقاط النهاية. تتلقى أجهزة التوجيه ونقاط النهاية الموزعة تحديثات التكوين ، ويسمح البروتوكول نفسه بتثبيت المرحلات الوسيطة المترجمة. يعتمد النظام على مبدأ النسخ الاحتياطي التفاضلي ("الثبات الحديث" ، الموضح أدناه) ويستخدم لغة استعلام JMESpath مع محرك القالب Jinja لتقديم ملفات التكوين.

تقوم Qrator Labs بإدارة شبكة تخفيف الهجمات الموزعة عالميًا. تعمل شبكتنا على مبدأ anycast ، ويتم الإعلان عن الشبكات الفرعية عبر BGP. نظرًا لأننا نتواجد شبكة BGP anycast موجودة فعليًا في العديد من مناطق الأرض ، فيمكننا معالجة وتصفية حركة المرور غير المشروعة بشكل أقرب إلى جوهر الإنترنت - مشغلي المستوى 1.

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

في البداية كانت الكلمة. سرعان ما أصبح بروتوكول اتصال في حاجة إلى التحديث.

حجر الزاوية في وجود QControl وفي الوقت نفسه السبب الرئيسي لقضاء قدر كبير من الوقت والموارد لبناء مثل هذا البروتوكول هو الحاجة إلى الحصول على مصدر موثوق واحد للتكوين ، وفي نهاية المطاف ، مزامنة نقاط وجودنا معها. كان المستودع نفسه مجرد واحد من المتطلبات المتعددة أثناء تطوير QControl. بالإضافة إلى ذلك ، نحتاج أيضًا إلى التكامل مع الخدمات الحالية والمخططة في نقاط التواجد (TP) ، والأساليب الذكية (والقابلة للتخصيص) للتحقق من صحة البيانات ، بالإضافة إلى التحكم في الوصول. بالإضافة إلى ذلك ، أردنا أيضًا إدارة مثل هذا النظام باستخدام الأوامر ، بدلاً من إجراء تعديلات على الملفات. قبل QControl ، تم إرسال البيانات إلى نقاط التواجد في الوضع اليدوي تقريبًا. إذا كانت إحدى نقاط التواجد غير متوفرة ، ونسينا تحديثها لاحقًا ، فقد تبين أن التهيئة غير متزامنة - كان عليك قضاء بعض الوقت في إعادتها إلى الخدمة.

نتيجة لذلك ، توصلنا إلى المخطط التالي:

خادم التكوين مسؤول عن التحقق من صحة البيانات وتخزينها ، ويحتوي جهاز التوجيه على العديد من نقاط النهاية التي تتلقى وتحديث تحديثات التكوين من العملاء وفرق الدعم إلى الخادم ، ومن الخادم إلى نقاط التواجد.

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


استعراض منتصف المدة من براغ إلى سنغافورة


نفس الشيء لهونغ كونغ

التأخير الكبير يعني سرعة أقل. بالإضافة إلى ذلك ، هناك فقدان الحزمة. لا يعوض عرض القنوات عن هذه المشكلة ، والتي ينبغي دائمًا أخذها في الاعتبار عند إنشاء أنظمة لا مركزية.

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

تصميم مستقر مؤخرا

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

نتيجة لذلك ، توصلنا إلى حل مثير للاهتمام إلى حد ما - لدينا طبقة دعم واحدة فقط ، ثابتة ، دعنا نسميها مستقرة ، وفرق واحد فقط لأنه حديث. يعتمد كل حديث على آخر تشكيل ثابت ويكفي لإعادة تكوين بيانات التكوين. بمجرد وصول حديث جديد إلى وجهته ، لم تعد هناك حاجة إلى القديم.

يبقى فقط من وقت لآخر لإرسال تكوين مستقر جديد ، على سبيل المثال ، بسبب حقيقة أن الأخيرة أصبحت كبيرة للغاية. من المهم أيضًا هنا إرسال جميع هذه التحديثات في وضع البث / البث المتعدد ، دون القلق بشأن المستلمين الفرديين وقدرتهم على جمع أجزاء من البيانات معًا. بمجرد أن نحن مقتنعون بأن كل شخص لديه الاستقرار الصحيح ، نرسل فقط الأخيرة الجديدة. هل يستحق كل هذا العناء لتوضيح أن هذا يعمل؟ إنه يعمل. يتم تخزين التخزين المؤقت مؤقتًا على خادم التكوين والمستلمين ، ويتم إنشاء أحدث حسب الحاجة.

مستويين هندسة النقل

لماذا بنينا وسائل النقل لدينا على مستويين؟ الجواب بسيط للغاية - أردنا فصل التوجيه عن المنطق عالي المستوى ، مستوحىً من نموذج OSI بطبقة النقل وطبقة التطبيق. بالنسبة لدور بروتوكول النقل ، اتخذنا Thrift ، ولتنسيق رسالة التحكم عالية المستوى ، تنسيق تسلسل msgpack. هذا هو السبب في أن جهاز التوجيه (تنفيذ الإرسال المتعدد / البث / الترحيل) لا ينظر إلى داخل msgpack ، ولا يفك حزم ولا يحزم المحتويات مرة أخرى ، ويقوم فقط بنقل البيانات.

Thrift (من الإنجليزية - تُعرف كلمة "التوفير" ، وضوحا [θrift]) لغة وصف للواجهة تُستخدم لتعريف وإنشاء خدمات بلغات البرمجة المختلفة. إنه إطار لاستدعاء الإجراء عن بعد (RPC). فهو يجمع بين خط أنابيب البرنامج ومحرك توليد الشفرة لتطوير الخدمات التي تعمل ، بدرجة أو بأخرى ، بكفاءة وسهولة بين اللغات.

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

هناك خيارات أخرى ، مثل protobuf / gRPC ، ومع ذلك ، عندما بدأنا مشروعنا ، كانت gRPC صغيرة جدًا ولم نتجرأ على أخذها على متنها.

بالطبع ، يمكننا (وفي الواقع ، كان الأمر يستحق القيام به) إنشاء دراجة خاصة بنا. سيكون من الأسهل إنشاء بروتوكول لما نحتاج إليه ، لأن بنية خادم العميل بسيطة نسبيًا في التنفيذ مقارنةً ببناء جهاز توجيه على Thrift. بشكل أو بآخر ، هناك موقف متحيز تقليديًا تجاه البروتوكولات المكتوبة ذاتيا وتنفيذ المكتبات الشعبية (وليس عبثا) ، بالإضافة إلى ذلك ، فإن المناقشة تثير دائما السؤال: "كيف سننقلها إلى لغات أخرى؟" لذلك ، ألقينا على الفور الأفكار حول الدراجة.

Msgpack هو مثيل لـ JSON ، لكنه أسرع وأقل. هذا هو تنسيق تسلسل بيانات ثنائي يسمح بتبادل البيانات بين لغات متعددة.

في المستوى الأول ، لدينا Thrift مع الحد الأدنى من المعلومات اللازمة لجهاز التوجيه لإعادة توجيه الرسالة. في المستوى الثاني يتم تعبئتها هياكل msgpack.

لقد اخترنا msgpack لأنه أسرع وأكثر إحكاما مقارنة بـ JSON. ولكن الأهم من ذلك ، أنه يدعم أنواع البيانات المخصصة ، مما يسمح لنا باستخدام ميزات رائعة مثل نقل الثنائيات الأولية أو الكائنات الخاصة التي تشير إلى نقص البيانات ، والتي كانت مهمة لنظامنا الثابت الأخير.

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

جينجا
بالنسبة لبعض المستهلكين ، نحتاج إلى تحويل التكوين إلى ملف - لذلك نحن نستخدم محرك القالب و Jinja هو الخيار الواضح. بمساعدتها ، نقوم بإنشاء ملف تكوين من القالب والبيانات المستلمة في الوجهة.

لإنشاء ملف التكوين ، نحتاج إلى طلب JMESPath ، قالب لموقع الملف في FS ، قالب للتهيئة نفسها. في هذه المرحلة أيضًا ، من الجيد توضيح أذونات الملفات. اتضح أن كل هذا تم دمجه بنجاح في ملف واحد - قبل بدء قالب التكوين ، وضعنا الرأس في تنسيق YAML ، الذي يصف الباقي.

على سبيل المثال:

---
selector: "[@][?@.fft._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


من أجل إنشاء ملف تكوين لخدمة جديدة ، نضيف فقط ملف قالب جديد. لا يلزم إجراء أي تغييرات على شفرة المصدر أو البرنامج عند نقاط التواجد.

ما الذي تغير منذ تقديم QControl إلى العمليات؟ الأول والأهم هو التسليم المتسق والموثوق لتحديثات التكوين عبر جميع العقد في الشبكة. والثاني هو الحصول على أداة قوية للتحقق من التكوين وإجراء تغييرات عليها من قبل فريق الدعم لدينا ، وكذلك من قبل مستهلكي الخدمة.

لقد نجحنا في القيام بكل هذا باستخدام نظام التحديث المستقر الأخير لتبسيط الاتصال بين خادم التكوين ومستلمي التكوين. استخدام بروتوكول من طبقتين لدعم طريقة توجيه البيانات المستقلة عن المحتوى. بعد أن نجح في دمج محرك توليد التهيئة المستندة إلى Jinja في شبكة تصفية موزعة. يدعم هذا النظام مجموعة واسعة من أساليب التكوين للأجهزة الطرفية الموزعة والمتنوعة الخاصة بنا.

شكرًا على كتابة المواد بفضل VolanDamrod و serenheit و NoN .

النسخة الإنجليزية من هذا المنصب.