مشاركة عبر

المناهج البنيوية للحساب في حلول متعددة المستأجرين

  • مقالة

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

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

الاعتبارات والمتطلبات الرئيسية

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

المقياس‬

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

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

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

غالباً ما تظل مشكلات الأداء غير مكتشفة حتى يتم تحميل التطبيق. يمكنك استخدام خدمة مدارة بالكامل، مثل Azure Load Testing، لمعرفة كيفية تصرف تطبيقك تحت الضغط.

مشغلات المقياس

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

المنطقة

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

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

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

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

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

هام

تجنب تسريب البيانات بين المستأجرين، عندما تستخدم ذاكرات التخزين المؤقت في الذاكرة أو المكونات الأخرى التي تحافظ على الحالة. على سبيل المثال، ضع في اعتبارك تقديم مُعرّف مستأجر مسبقاً لجميع مفاتيح ذاكرة التخزين المؤقت، للتأكد من فصل البيانات لكل مستأجر.

العزل

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

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

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

مناهج وأنماط يجب مراعاتها

التحجيم التلقائي

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

نمط الخوادم المخصصة للتوزيع

لمزيد من المعلومات حول كيفية استخدام نمط طوابع التوزيع لدعم حل متعدد المستأجرين، راجع نظرة عامة.

حساب نمط توحيد الموارد

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

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

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

  • Azure App Service وAzure Functions: توزيع خطط خدمة التطبيقات المشتركة، والتي تمثل البنية الأساسية لخادم الاستضافة.
  • Azure Container Apps: قم بتوزيع البيئاتالمشتركة.
  • خدمة Azure Kubernetes (AKS): توزيع البودات المشتركة، باستخدام تطبيق مدرك متعدد الشركات.
  • الأجهزة الظاهرية: قم بتوزيع مجموعة واحدة من الأجهزة الظاهرية ليستخدمها جميع المستأجرين.

موارد حساب مخصصة لكل مستأجر

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

بناءً على خدمات حساب Azure التي تستخدمها، تحتاج إلى توزيع موارد مخصصة مختلفة، على النحو التالي:

  • Azure Functions App وAzure: قم بتوزيع خطط خدمة تطبيقات منفصلة لكل مستأجر.
  • Azure Container Apps: قم بتوزيع بيئات منفصلة لكل مستأجر.
  • خدمة Azure Kubernetes (AKS): قم بتوزيع مجموعات مخصصة لكل مستأجر.
  • الأجهزة الظاهرية: قم بتوزيع أجهزة ظاهرية مخصصة لكل مستأجر.

موارد حساب شبه معزولة

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

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

تمكّنك Azure Container Apps من توزيع تطبيقات متعددة في بيئة مشتركة، ثم استخدام Dapr والأدوات الأخرى لتكوين كل تطبيق على حدة.

توفر Azure Kubernetes Service (AKS) وKubernetes على نطاق أوسع مجموعة متنوعة من الخيارات للشركات المتعددة الاستئجار، بما في ذلك ما يلي:

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

تمكّنك AKS أيضاً من تطبيق إدارة على مستوى الحجرة للتخفيف من مشكلة الجوار المزعج. لمزيد من المعلومات، راجع أفضل الممارسات لمطوري التطبيقات لإدارة الموارد في Azure Kubernetes Service (AKS).

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

أنماط مضادة لتجنب

النمط المضاد للجار المزعج

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

تسرب البيانات بين المستأجرين

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

Antipattern مشغول الجبهة الأمامية

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

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

تحجيم غير مرن أو غير كافٍ

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

تأكد من الاستفادة الجيدة من مرونة وحجم السحابة. ضع في اعتبارك ما إذا كان يجب عليك استخدام تغيير الحجم الأفقي أو الرأسي، واستخدام تغيير الحجم التلقائي للتعامل مع الارتفاعات في الحِمل تلقائياً. اختبر الحل الخاص بك لفهم كيف يتصرف في ظل مستويات مختلفة من الحمل. تأكد من تضمين أحجام الأحمال المتوقعة في الإنتاج والنمو المتوقع. يمكنك استخدام خدمة مدارة بالكامل، مثل Azure Load Testing، لمعرفة كيفية تصرف تطبيقك تحت الضغط.

النمط المضاد No Caching

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

الحالة غير الضرورية

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

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

  • ديكسيت أرورا | مهندس عملاء أول، FastTrack لـAzure
  • جون داونز | مهندس البرامج الرئيسي

مساهمون آخرون:

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

راجع الإرشادات الخاصة بالخدمة لخدمات الحوسبة الخاصة بك: