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

Azure
Azure SQL Database
Azure Storage

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

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

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

من المهم مراعاة الأساليب التي تستخدمها لخدمات التخزين والبيانات من عدد من وجهات النظر، والتي تقريبًا تتوافق مع ركائز Azure Well-Architected Framework.

المقياس

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

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

إمكانية التنبؤ بالأداء

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

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

عزل البيانات

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

  • عند استخدام Azure Cosmos DB، يمكنك توزيع حاويات منفصلة لكل مستأجر، ويمكنك مشاركة قواعد البيانات والحسابات بين مستأجرين متعددين. بدلاً من ذلك، قد تفكر في توزيع قواعد بيانات مختلفة أو حتى حسابات لكل مستأجر، اعتمادًا على مستوى العزل المطلوب.
  • عند استخدام Azure Storage لبيانات الكائن الثنائي كبير الحجم، يمكنك توزيع حاويات كائن ثنائي كبير الحجم منفصلة لكل مستأجر، أو يمكنك توزيع حسابات تخزين منفصلة.
  • عند استخدام Azure SQL، يمكنك استخدام جداول منفصلة في قواعد البيانات المشتركة، أو يمكنك توزيع قواعد بيانات أو خوادم منفصلة لكل مستأجر.
  • في جميع خدمات Azure، يمكنك التفكير في نشر الموارد ضمن اشتراك Azure مشترك واحد، أو يمكنك استخدام اشتراكات Azure متعددة - ربما اشتراك واحد لكل مستأجر.

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

تعقيد التنفيذ

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

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

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

تعقيد الإدارة والعمليات

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

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

التكلفة

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

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

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

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

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

قواعد البيانات المشتركة متعددة المستأجرين ومخازن الملفات

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

Diagram showing a single shared multitenant database for all tenants' data.

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

ومع ذلك، عند العمل مع البنية الأساسية المشتركة، توجد العديد من التحذيرات التي يجب مراعاتها:

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

نمط التقسيم

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

Diagram showing a sharded database. One database contains the data for tenants A and B, and the other contains the data for tenant C.

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

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

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

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

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

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

Diagram showing different databases for each tenant.

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

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

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

من المهم استخدام نهج التوزيع التلقائي عند توفير قواعد البيانات لكل مستأجر.

نمط المواقع الجغرافية

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

Diagram showing the Geode pattern, with databases deployed across multiple regions that synchronize together.

Azure Cosmos DB يوفر عمليات كتابة متعددة المستويات الرئيسية لدعم هذا النمط، وتدعم Cassandra المجموعات متعددة المناطق. خدمات البيانات الأخرى بشكل عام غير قادرة على دعم هذا النمط، دون تخصيص كبير.

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

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

بالنسبة لقواعد البيانات الارتباطية، وهي تشمل:

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

قواعد البيانات

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

  • الأمان على مستوى الصف يمكن أن يوفر عزل أمان لبيانات مستأجرين محددين في قاعدة بيانات مشتركة متعددة المستأجرين. هذه الميزة تتوفر في Azure SQL وPostgres Flex، ولكنها غير متوفرة في قواعد البيانات الأخرى، مثل MySQL أو Azure Cosmos DB.
  • التشفير على مستوى المستأجر قد يكون مطلوبًا لدعم المستأجرين الذين يقدمون مفاتيح التشفير الخاصة بهم لبياناتهم. هذه الميزة تتوفر في Azure SQL كجزء من Always Encrypted. يوفر Azure Cosmos DB مفاتيح يديرها العميل على مستوى الحساب ويدعم أيضا Always Encrypted.
  • تجميع الموارد يوفر القدرة على مشاركة الموارد والتكلفة، بين قواعد بيانات أو حاويات متعددة. تتوفر هذه الميزة في تجمعات Azure SQL المرنة والمثيلاتالمدارة وفي معدل نقل قاعدة بيانات Azure Cosmos DB، على الرغم من أن كل خيار له قيود يجب أن تكون على علم بها.
  • التقسيم والتقسيم يحتويان على دعم أصلي أقوى في بعض الخدمات من غيرها. هذه الميزة تتوفر في Azure Cosmos DB، باستخدام تقسيمها المنطقي والمادي، وفي PostgreSQL Hyperscale. في حين أن Azure SQL لا يدعم التقسيم في الأصل، فإنه يوفر أدوات التقسيم لدعم هذا النوع من البنية.

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

تخزين الملفات والكائنات الثنائية كبيرة الحجم

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

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

توزيع التكلفة

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

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

المساهمون

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

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

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

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

لمزيد من المعلومات حول تعدد المستأجرين وخدمات Azure المحددة، راجع ما يلي: