تخطيط السعة لتطبيقات Service Fabric

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

عند إنشاء نظام مجموعة Service Fabric، يمكنك تحديد أنواع الأجهزة الظاهرية (VMs) التي تشكل نظام المجموعة. يأتي كل جهاز ظاهري مع كمية محدودة من الموارد في شكل وحدات المعالجة المركزية (ذاكرة أساسية والسرعة) وعرض النطاق الترددي للشبكة وRAM وتخزين القرص. مع نمو خدمتك بمرور الوقت، يمكنك الترقية إلى الأجهزة الظاهرية التي توفر موارد أكبر و/أو إضافة المزيد من الأجهزة الظاهرية إلى نظام مجموعتك. للقيام بهذا الأخير ، يجب عليك تصميم خدمتك في البداية حتى تتمكن من الاستفادة من الأجهزة الظاهرية الجديدة التي تتم إضافتها ديناميكيا إلى نظام المجموعة.

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

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

يتم تحديد عدد العقد التي تحتاج إليها

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

لنفترض أن تطبيقك يحتوي على خدمة واحدة ذات حالة واحدة لها حجم متجر تتوقع أن ينمو إلى حجم قاعدة بيانات غيغابايت في غضون عام. كن على استعداد لإضافة المزيد من التطبيقات (والأقسام) كما واجهت النمو بعد ذلك العام. يؤثر عامل النسخ المتماثل (RF)، الذي يحدد عدد النسخ المتماثلة لخدمتك على إجمالي حجم قاعدة بيانات. إجمالي حجم قاعدة بيانات عبر جميع النسخ المتماثلة هو عامل النسخ المتماثل مضروبا في حجم قاعدة بيانات. يمثل حجم العقدة مساحة القرص/ RAM لكل عقدة تريد استخدامها لخدمتك. للحصول على أفضل أداء ، يجب أن يتناسب حجم قاعدة بيانات مع الذاكرة عبر المجموعة ، ويجب اختيار حجم العقدة حول الـ RAM للجهاز الظاهري. من خلال تخصيص حجم قاعدة البيانات أكبر من سعة RAM، فإنك تعتمد على ترحيل الصفحات الذي يوفره وقت تشغيل Service Fabric. وبالتالي، قد لا يكون أداؤك مثاليا في حالة كانت بياناتك بأكملها تعتبر ساخنة (منذ ذلك الحين يتم تقسيم البيانات إلى داخل / خارج). ومع ذلك، بالنسبة للعديد من الخدمات التي يكون فيها جزء صغير فقط من البيانات ساخنا، فهي ذات فعالية أكبر من حيث التكلفة.

تستطيع حساب عدد العقد المطلوبة لتحقيق أقصى قدر من الأداء على النحو التالي:

Number of Nodes = (DB_Size * RF)/Node_Size

حساب عملية النمو

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

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

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

استخدام الجدول الخاص بالبيانات لحساب التكلفة

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

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

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

الخطوات التالية

تحقق من خدمات تقسيم Service Fabric لمعرفة المزيد حول تقسيم الخدمة.