Qrator تصفية نظام تسليم تكوين الشبكة

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

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

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

في البداية ، كان هناك Word ... الذي سرعان ما أصبح بروتوكول الاتصال في حاجة إلى ترقية.

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

إليك النظام الذي توصلنا إليه:

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

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


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


نفس لقطة الشاشة الثانية مع traceroute إلى هونج كونج

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

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

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

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

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

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

طبقتين النقل العمارة

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

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

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

هناك بعض الخيارات الأخرى ، مثل protobuf / gRPC ، رغم أننا عندما بدأنا بمشروعنا ، كانت gRPC غير ناضجة وقد ترددنا في استخدامه.

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

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

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

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

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

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

لتقديم ملف التكوين ، نحتاج إلى طلب jmespath ، قالب لملف المسار والوجهة ، قالب للتكوين نفسه. أيضًا ، في هذه المرحلة ، من الجيد تحديد حقوق الوصول إلى الملفات. تم جمع كل هذا لحسن الحظ في ملف واحد - قبل قالب التكوين ، نضع رأس 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) }}

لإجراء التهيئة لمحيط جديد ، نضيف ملفًا جديدًا للقالب ، ولا يلزم إجراء أي تغييرات في التعليمات البرمجية المصدر وتحديثات برنامج PoP.

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

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