حالات الاستخدام أو ما تفتقر إليه موازنات الحمل

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

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

GET /docs/index.html HTTP/1.1 Host: www.company.com Accept-Language: en-us Accept-Encoding: gzip, deflate 

يتم إرسالها إلى مجموعة واحدة من الخوادم مع ضغط لاحق للنتائج والتخزين المؤقت والطلبات

 POST /api/object-put HTTP/1.1 HOST: b2b.company.com X-Auth: 76GDjgtgdfsugs893Hhdjfpsj Content-Type: application/json 

معالجتها وفقًا لقواعد مختلفة تمامًا.

يسمح لك فهم دلالات البروتوكول بتنظيم الجلسة على مستوى كائنات بروتوكول التطبيق ، على سبيل المثال ، باستخدام رؤوس HTTP أو ملفات تعريف الارتباط RDP أو طلبات تعدد الإرسال لملء جلسة نقل واحدة مع العديد من طلبات المستخدم إذا كان مستوى التطبيق للبروتوكول يسمح بذلك.
في بعض الأحيان يتم تخيل نطاق تطبيق ADC بشكل غير معقول فقط من خلال خدمة حركة مرور HTTP ، في الواقع ، قائمة البروتوكولات المدعومة لمعظم الشركات المصنعة أوسع بكثير. حتى عند العمل دون فهم دلالات بروتوكول طبقة التطبيق ، يمكن أن يكون ADC مفيدًا لحل المهام المختلفة ، على سبيل المثال ، شاركت في بناء مزرعة افتراضية مكتفية ذاتيًا من خوادم SMTP ، أثناء الهجمات غير المرغوب فيها ، يزداد عدد المثيلات باستخدام التحكم في التعليقات على طول قائمة انتظار الرسائل لتوفير وقت مرضٍ لفحص الرسائل باستخدام خوارزميات كثيفة الاستخدام للموارد. أثناء التنشيط ، قام الخادم بالتسجيل مع ADC واستلم حصته من جلسات TCP الجديدة. في حالة بروتوكول SMTP ، تم تبرير مخطط التشغيل هذا بشكل كامل بسبب ارتفاع إنتروبيا الاتصالات على مستوى الشبكة والنقل ؛ لتوزيع الحمل المنتظم أثناء هجمات البريد العشوائي ADC ، يلزم دعم TCP فقط. يمكن استخدام نظام مماثل لبناء مزرعة من خوادم قواعد البيانات أو مجموعات ملقمات DNS عالية الوصول أو DHCP أو AAA أو الوصول عن بُعد عندما يمكن اعتبار الخوادم متكافئة في المجال وعندما لا تختلف خصائص أدائها كثيرًا عن بعضها البعض. لن أذهب أبعد من ذلك في موضوع ميزات البروتوكول ، وهذا الجانب واسع للغاية بحيث لا يمكن ذكره في المقدمة ، إذا كان هناك شيء مثير للاهتمام - اكتب ، ربما هذه مناسبة لمقال مع عرض أعمق لبعض التطبيقات ، والآن دعنا نصل إلى النقطة.

في أغلب الأحيان ، تقوم ADC بإغلاق طبقة النقل ، بحيث تصبح جلسة TCP-to-end بين المستهلك والخادم مركبة ، ويقوم المستهلك بإنشاء جلسة مع ADC ، و ADC مع أحد الخوادم.


الشكل 1

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

1. ADC كبوابة افتراضية لشبكة الخادم ؛
2. البث إلى عناوين المستهلك ADC في أحد عناوين الواجهة الخاصة به.

في الواقع ، تبدو نظرة أكثر واقعية قليلاً لمخطط التطبيق الأول على هذا النحو ، وهذا هو الأساس الذي سنبدأ منه:


الشكل 2

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

تشير الدراسات إلى أن التطبيقات الحديثة متعددة المستويات تولد المزيد من حركة المرور بين الغرب والشرق ، ومن غير المحتمل أن ترغب في مرور جميع حركة المرور داخل الكود / بين المقاطع عبر ADC. ليست المفاتيح في الشكل 2 بالضرورة مادية - يمكن تنفيذ مجالات التوجيه باستخدام الكيانات الافتراضية ، والتي تسمى الموجه الظاهري أو vrf أو vr أو vpn-مثيل أو جدول توجيه افتراضي لمختلف الشركات المصنعة.

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


الشكل 3

لذلك ، لدينا مركز بيانات أساس واحد ، كما هو موضح في الشكل 2 ، دعونا نفكر في المشاكل التي يمكن أن تدفع مركز بيانات الأساس إلى التطور ، أرى موضوعين للتحليل:

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

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

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


الشكل 4

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


الشكل 5

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

تبدأ فوائد Active / Active بالظهور عند العمل مع أكثر من جهازين. لنفترض أنك بحاجة إلى ضمان أداء 8 وحدات عشوائية (8 آلاف اتصال في الثانية ، أو 8 ملايين جلسة متزامنة) وتوفير سيناريو فشل جهاز واحد ، في الإصدار النشط / النشط ، تحتاج فقط إلى ثلاث حالات ADC بسعة 4 ، في حالة Active / Standby - اثنان في 8. إذا ترجمت هذه الأرقام إلى موارد خاملة ، تحصل على الثلث إلى النصف. يمكن استخدام نفس مبدأ الحساب لتقدير نسبة الاتصالات المقطوعة خلال فترة فشل جزئي. مع زيادة عدد الحالات النشطة / النشطة ، تصبح الرياضيات أكثر متعة ، ويحصل النظام على فرصة لزيادة الإنتاجية تدريجيًا بدلاً من Active / Standby التدريجي.

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

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

ومع ذلك ، هناك أشياء إيجابية:

1. المجموعة سهلة التركيب وسهلة التشغيل.
2. في بعض الأحيان يمكنك أن تتوقع استخدامًا شبه مثالي للموارد.

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


الشكل 6

قد لا يكون الموقع الجديد بعيدًا جدًا ، ثم ستحل المشكلة بنجاح عن طريق تجديد نطاقات التوجيه. حالة أكثر عمومية ، والتي لا تستبعد ظهور الموقع في مدينة أخرى أو في بلد آخر ، ستطرح تحديات جديدة لمركز البيانات:

1. الاستفادة من القنوات بين المواقع ؛
2. الفرق في وقت المعالجة للطلبات التي أرسلتها ADC للمعالجة إلى الخوادم القريبة والبعيدة.

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

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


الشكل 7

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

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


الشكل 8

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


الشكل 9

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

ولكن انظر مرة أخرى إلى الشكل 9 ، هل ترى ما يمكن تحسينه هناك؟
العيب الرئيسي للعمل مع سلسلة ADC هو أنه يستهلك موارد اثنين من ADC لمعالجة جزء من الجلسات. في حالة هذا العميل ، كان الاختيار واعيًا تمامًا ، ويرجع ذلك إلى تفاصيل التطبيقات والحاجة إلى أن تكون سريعًا جدًا (من 20 إلى 50 ثانية) لإعادة توزيع الحمل بين خوادم المواقع المختلفة. في فترات زمنية مختلفة ، استغرقت المعالجة المزدوجة ما متوسطه 15 إلى 30 في المائة من موارد ADC ، وهو ما يكفي للتفكير في التحسين. بعد مناقشة هذه النقطة مع مهندسي العميل ، اقترحنا استبدال دعم جدول جلسات ADC بربط الواجهة بتوجيه المصدر على الخوادم التي تستخدم PBR على مكدس Linux IP. كمفتاح ، اعتبرنا خيارات مثل:

1. عنوان IP إضافي على الخوادم على واجهة مشتركة لكل ADC ؛
2. عنوان IP للواجهة على الخوادم على 802.1q منفصل لكل ADC ؛
3. شبكة نفق تراكب منفصلة على خوادم لكل ADC.

سيؤثر الخياران الأول والثاني بطريقة أو بأخرى على الشبكة ككل. من بين الآثار الجانبية للخيار الأول ، بدا من غير المقبول بالنسبة لنا أن الزيادة التي كانت مضاعفة لعدد ADC ، جداول ARP على المحولات ، والخيار الثاني يتطلب زيادة في عدد مجالات البث الشامل بين المواقع أو المثيلات الفردية لجداول التوجيه الافتراضية. بدت الطبيعة المحلية للخيار الثالث جذابة للغاية بالنسبة لنا ، وبدأنا العمل ، مما أدى إلى وحدة تحكم بسيطة تعمل تلقائيًا على تكوين الأنفاق على الخوادم و ADC ، بالإضافة إلى تكوين PBR على مكدس IP لخوادم Linux.


الشكل 10

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

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

بالإضافة إلى ذلك ، قد يجد بعض العملاء أنه من المناسب التبديل من نموذج PULL للتفاعل مع الخوادم إلى نموذج PUSH. إن إمكانات التطبيق على الخوادم واسعة للغاية ، لذلك في بعض الأحيان يكون من الأسهل تنظيم تحقق جاد من تطبيق معين للخدمة على الوكيل نفسه. إذا كان الشيك يعطي نتيجة إيجابية ، فإن الوكيل ينقل المعلومات ، على سبيل المثال ، في نموذج مشابه لمجتمع تكلفة BGP ، لاستخدامه في خوارزميات الحساب الموزونة.
في كثير من الأحيان ، تقوم إدارات مختلفة من المؤسسة بإجراء صيانة للخادم و ADC ؛ قد يكون التبديل إلى نموذج تفاعل PUSH أمرًا مثيرًا للاهتمام لأن هذا النموذج يلغي الحاجة إلى التنسيق بين الأقسام على واجهة بين البشر. يمكن نقل الخدمات التي يشارك فيها الخادم مباشرة من الوكيل إلى ADC في شكل شيء مشابه لـ BGP Flow-Spec المتقدمة.

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