مشاركة عبر


تكوين إعدادات الوسيط لقابلية الوصول العالية والتحجيم واستخدام الذاكرة

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

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

للحصول على قائمة بالإعدادات المتوفرة، راجع مرجع Broker API.

تكوين إعدادات التحجيم

هام

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

لتكوين إعدادات التحجيم لوسيط MQTT، حدد حقول العلاقة الأساسية في مواصفات مورد Broker أثناء توزيع عمليات Azure IoT.

العلاقة الأساسية للتوزيع التلقائي

لتحديد العلاقة الأساسية الأولية تلقائيا أثناء النشر، احذف حقل العلاقة الأساسية في مورد Broker.

العلاقة الأساسية التلقائية غير مدعومة بعد عند نشر عمليات IoT من خلال مدخل Microsoft Azure. يمكنك تحديد وضع نشر نظام المجموعة يدويا كعقدة واحدة أو عقدة متعددة. لمعرفة المزيد، راجع نشر عمليات Azure IoT.

لقطة شاشة توضح مكان تحديد إعداد عقدة واحدة أو متعددة في مدخل Microsoft Azure.

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

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

تكوين العلاقة الأساسية مباشرة

لتكوين إعدادات العلاقة الأساسية مباشرة، حدد كل حقل من حقول العلاقة الأساسية.

عند اتباع الدليل لنشر عمليات IoT، في قسم التكوين ، ابحث ضمن تكوين وسيط MQTT. هنا، يمكنك تحديد عدد النسخ المتماثلة الأمامية وأقسام الواجهة الخلفية وعمال الواجهة الخلفية.

لقطة شاشة توضح مكان تكوين العلاقة الأساسية للوسيط مباشرة في مدخل Microsoft Azure.

فهم العلاقة الأساسية

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

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

الواجهة الأمامية

يحدد الحقل الفرعي للواجهة الأمامية إعدادات قرون الواجهة الأمامية. الإعدادان الرئيسيان هما:

  • النسخ المتماثلة: عدد النسخ المتماثلة الأمامية (pods) المراد نشرها. توفر زيادة عدد النسخ المتماثلة الأمامية توفرا عاليا في حالة فشل إحدى القرون الأمامية.
  • العاملون: عدد العاملين المنطقيين في الواجهة الأمامية لكل نسخة متماثلة. يمكن لكل عامل استهلاك ما يصل إلى ذاكرة أساسية واحدة لوحدة المعالجة المركزية على الأكثر.

سلسلة الواجهة الخلفية

يحدد الحقل الفرعي لسلسلة الواجهة الخلفية إعدادات أقسام الواجهة الخلفية. الإعدادات الرئيسية الثلاثة هي:

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

الاعتبارات

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

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

تكوين ملف تعريف الذاكرة

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

هام

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

لتكوين إعدادات ملف تعريف الذاكرة لوسيط MQTT، حدد حقول ملف تعريف الذاكرة في مواصفات مورد Broker أثناء نشر عمليات IoT.

عند استخدام الدليل التالي لنشر عمليات IoT، في قسم التكوين ، ابحث ضمن تكوين وسيط MQTT وابحث عن إعداد ملف تعريف الذاكرة. هنا، يمكنك التحديد من ملفات تعريف الذاكرة المتوفرة في قائمة منسدلة.

لقطة شاشة توضح مكان تكوين ملف تعريف الذاكرة في مدخل Microsoft Azure.

هناك ملفات تعريف ذاكرة معرفة مسبقا مع خصائص استخدام ذاكرة مختلفة لنشر الرسائل. لا يوجد حد لعدد الجلسات أو الاشتراكات التي يمكن للوسيط التعامل معها. يتحكم ملف تعريف الذاكرة فقط في استخدام الذاكرة لحركة مرور PUBLISH.

صغيره

استخدم ملف التعريف هذا عندما يكون لديك موارد ذاكرة محدودة وحركة مرور نشر العميل منخفضة.

عند استخدام ملف التعريف هذا:

  • الحد الأقصى لاستخدام الذاكرة لكل نسخة متماثلة أمامية هو 99 ميجابايت تقريبا، ولكن قد يكون الحد الأقصى الفعلي لاستخدام الذاكرة أعلى.
  • الحد الأقصى لاستخدام الذاكرة لكل نسخة متماثلة خلفية هو حوالي 102 ميبي بايت مضروبا في عدد العاملين في الخلفية، ولكن قد يكون الحد الأقصى الفعلي لاستخدام الذاكرة أعلى.
  • الحد الأقصى لحجم الرسالة هو 4 ميغابايت.
  • الحد الأقصى لحجم المخزن المؤقت الوارد لبيانات PUBLISH هو حوالي 16 ميجابايت لكل عامل خلفية. ومع ذلك، قد يكون الحجم الفعلي أقل بسبب آليات الضغط على الظهر، والتي يتم تنشيطها عندما يصل المخزن المؤقت إلى 75% السعة مما يؤدي إلى حجم مخزن مؤقت يبلغ حوالي 12 ميجابايت. تحتوي الحزم المرفوضة على استجابة PUBACK مع رمز خطأ تجاوز الحصة النسبية .

التوصيات عند استخدام ملف التعريف هذا:

  • يجب استخدام واجهة أمامية واحدة فقط.
  • يجب ألا يرسل العملاء حزما كبيرة. يجب عليك فقط إرسال حزم أصغر من 4 ميبي بايت.

منخفض

استخدم ملف التعريف هذا عندما يكون لديك موارد ذاكرة محدودة وينشر العملاء حزما صغيرة.

عند استخدام ملف التعريف هذا:

  • الحد الأقصى لاستخدام الذاكرة لكل نسخة متماثلة أمامية هو حوالي 387 ميبي بايت، ولكن قد يكون الحد الأقصى الفعلي لاستخدام الذاكرة أعلى.
  • الحد الأقصى لاستخدام الذاكرة لكل نسخة متماثلة خلفية هو حوالي 390 ميبي بايت مضروبا في عدد العاملين في الخلفية، ولكن قد يكون الحد الأقصى الفعلي لاستخدام الذاكرة أعلى.
  • الحد الأقصى لحجم الرسالة هو 16 ميغابايت.
  • الحد الأقصى لحجم المخزن المؤقت الوارد لبيانات PUBLISH هو حوالي 64 ميجابايت لكل عامل خلفية. ومع ذلك، قد يكون الحجم الفعلي أقل بسبب آليات الضغط على الظهر، والتي يتم تنشيطها عندما يصل المخزن المؤقت إلى 75% السعة مما يؤدي إلى حجم مخزن مؤقت يبلغ حوالي 48 ميبي بايت. تحتوي الحزم المرفوضة على استجابة PUBACK مع رمز خطأ تجاوز الحصة النسبية .

التوصيات عند استخدام ملف التعريف هذا:

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

متوسط

استخدم ملف التعريف هذا عندما تحتاج إلى معالجة عدد متوسط من رسائل العميل.

متوسط هو ملف التعريف الافتراضي.

  • الحد الأقصى لاستخدام الذاكرة لكل نسخة متماثلة أمامية هو 1.9 غيغابايت تقريبا، ولكن قد يكون الحد الأقصى الفعلي لاستخدام الذاكرة أعلى.
  • الحد الأقصى لاستخدام الذاكرة لكل نسخة متماثلة خلفية هو حوالي 1.5 غيغابايت مضروبا في عدد العاملين في الخلفية، ولكن قد يكون الحد الأقصى الفعلي لاستخدام الذاكرة أعلى.
  • الحد الأقصى لحجم الرسالة هو 64 ميغابايت.
  • الحد الأقصى لحجم المخزن المؤقت الوارد لبيانات PUBLISH هو حوالي 576 ميجابايت لكل عامل خلفية. ومع ذلك، قد يكون الحجم الفعلي أقل بسبب آليات الضغط على الظهر، والتي يتم تنشيطها عندما يصل المخزن المؤقت إلى 75% السعة مما يؤدي إلى حجم مخزن مؤقت يبلغ حوالي 432 ميبي بايت. تحتوي الحزم المرفوضة على استجابة PUBACK مع رمز خطأ تجاوز الحصة النسبية .

درجة عالية

استخدم ملف التعريف هذا عندما تحتاج إلى معالجة عدد كبير من رسائل العميل.

  • الحد الأقصى لاستخدام الذاكرة لكل نسخة متماثلة أمامية هو حوالي 4.9 غيغابايت، ولكن قد يكون الحد الأقصى الفعلي لاستخدام الذاكرة أعلى.
  • الحد الأقصى لاستخدام الذاكرة لكل نسخة متماثلة خلفية هو حوالي 5.8 غيغابايت مضروبا في عدد العاملين في الخلفية، ولكن قد يكون الحد الأقصى الفعلي لاستخدام الذاكرة أعلى.
  • الحد الأقصى لحجم الرسالة هو 256 ميغابايت.
  • الحد الأقصى لحجم المخزن المؤقت الوارد لبيانات PUBLISH هو حوالي 2 غيغابايت لكل عامل خلفية. ومع ذلك، قد يكون الحجم الفعلي أقل بسبب آليات الضغط على الظهر، والتي يتم تنشيطها عندما يصل المخزن المؤقت إلى 75% السعة مما يؤدي إلى حجم مخزن مؤقت يبلغ حوالي 1.5 غيغابايت. تحتوي الحزم المرفوضة على استجابة PUBACK مع رمز خطأ تجاوز الحصة النسبية .

حساب إجمالي استخدام الذاكرة

يحدد إعداد ملف تعريف الذاكرة استخدام الذاكرة لكل نسخة متماثلة للواجهة الأمامية والخلفية ويتفاعل مع إعدادات العلاقة الأساسية. يمكنك حساب إجمالي استخدام الذاكرة باستخدام الصيغة:

M_total = R_fe * M_fe + (P_be * RF_be) * M_be * W_be

المكان:

المتغير الوصف
M_total إجمالي استخدام الذاكرة
R_fe عدد النسخ المتماثلة الأمامية
M_fe استخدام الذاكرة لكل نسخة متماثلة للواجهة الأمامية
P_be عدد أقسام الواجهة الخلفية
RF_be عامل التكرار الخلفي
M_be استخدام الذاكرة لكل نسخة متماثلة خلفية
W_be عدد العمال لكل نسخة متماثلة خلفية

على سبيل المثال، إذا اخترت ملف تعريف الذاكرة المتوسطة ، فإن ملف التعريف لديه استخدام ذاكرة أمامية تبلغ 1.9 غيغابايت واستخدام ذاكرة الواجهة الخلفية 1.5 غيغابايت. افترض أن تكوين الوسيط هو نسختين متماثلتين للواجهة الأمامية، وقسمين خلفيين، وعامل تكرار الخلفية من 2. إجمالي استخدام الذاكرة هو:

2 * 1.9 غيغابايت + (2 * 2) * 1.5 غيغابايت * 2 = 15.8 غيغابايت

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

2 * 99 ميغابايت + (2 * 2) * 102 ميغابايت * 2 = 198 ميغابايت + 816 ميغابايت = 1.014 غيغابايت.

هام

يبدأ وسيط MQTT في رفض الرسائل عندما تكون الذاكرة 75% ممتلئة.

حدود موارد العلاقة الأساسية وKubernetes

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

يطلب وسيط MQTT حاليا وحدة وحدة معالجة مركزية واحدة (1.0) لكل عامل واجهة أمامية ووحدتي CPU (2.0) لكل عامل خلفية. لمزيد من المعلومات، راجع وحدات موارد وحدة المعالجة المركزية Kubernetes.

على سبيل المثال، قد تطلب العلاقة الأساسية التالية موارد وحدة المعالجة المركزية التالية:

  • بالنسبة للواجهات الأمامية: وحدتان لوحدة المعالجة المركزية لكل جراب أمامي، يبلغ إجماليهما 6 وحدات وحدة معالجة مركزية.
  • بالنسبة للخلفيات: 4 وحدات وحدة معالجة مركزية لكل جراب خلفية (لاثنين من عمال الواجهة الخلفية)، مرة 2 (عامل التكرار)، أو 3 (عدد الأقسام)، بإجمالي 24 وحدة وحدة معالجة مركزية.
{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

لتعطيل هذا الإعداد، قم بتعيين generateResourceLimits.cpu الحقل إلى Disabled في مورد Broker.

generateResourceLimits تغيير الحقل غير مدعوم في مدخل Microsoft Azure. لتعطيل هذا الإعداد، استخدم Azure CLI.

النشر متعدد العقد

لضمان توفر عال ومرونة عالية مع عمليات النشر متعددة العقد، يقوم وسيط MQTT لعمليات IoT تلقائيا بتعيين قواعد مكافحة الترابط لوحدات الجراب الخلفية.

هذه القواعد معرفة مسبقا ولا يمكن تعديلها.

الغرض من قواعد عدم الترابط

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

التحقق من إعدادات عدم الترابط

للتحقق من إعدادات عدم الترابط ل pod الخلفية، استخدم الأمر التالي:

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

يظهر الإخراج تكوين مكافحة الترابط، على غرار المثال التالي:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

هذه القواعد هي قواعد مكافحة الترابط الوحيدة التي تم تعيينها للوسيط.