مشاركة عبر

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

  • مقالة

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

إشعار

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

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

خدمات البنية الأساسية والنظام أساسي

ستختلف مخاوفك بشأن مكونات الشبكة، اعتماداً على فئة الخدمات التي تستخدمها.

خدمات البنية الأساسية

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

خدمات النظام الأساسي

إذا كنت تستخدم خدمات النظام الأساسي لـ Azure، مثل App Service أو Azure Cosmos DB أو Azure SQL Database، فإن البنية المحددة التي تستخدمها ستحدد خدمات الشبكات التي تحتاجها.

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

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

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

تأكد من أنك تفهم الآثار المترتبة على استخدام الشبكات الخاصة.

تحجيم الشبكات الفرعية

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

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

وبالمثل، عند العمل مع الخدمات المُدارة، من المهم أن تفهم كيفية استهلاك عناوين IP. على سبيل المثال، عند استخدام خدمة Azure Kubernetes مع Azure Container Networking Interface (CNI)، سيستند عدد عناوين IP المستهلكة من شبكة فرعية إلى عوامل مثل عدد العقد، وكيفية تغيير الحجم أفقيا، وعملية نشر الخدمة التي تستخدمها. عند استخدام Azure App Service وAzure Functions مع تكامل VNet، يعتمد عدد عناوين IP المستهلكة على عدد مثيلات الخطة.

راجع إرشادات تقسيم الشبكة الفرعية عند التخطيط للشبكات الفرعية.

الوصول العام أو الخاص

ضع في اعتبارك ما إذا كان المستأجرون لديك سيصلون إلى خدماتك عبر الإنترنت أو من خلال عناوين IP الخاصة.

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

إذا كنت بحاجة إلى تمكين الاتصال بالخدمة الخاصة بك باستخدام عناوين IP الخاصة، ففكر في استخدام Azure Private Link Service أو نظير الشبكة الظاهرية عبر المستأجرين. بالنسبة لبعض السيناريوهات المحدودة، قد تفكر أيضاً في استخدام Azure ExpressRoute أو Azure VPN بوابة لتمكين الوصول الخاص إلى الحل الخاص بك. ننصحك فقط باستخدام هذا الأسلوب عندما يكون لديك عدد صغير من المستأجرين، ونشر شبكات ظاهرية مخصصة لكل مستأجر.

الوصول إلى نقاط نهاية المستأجرين

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

إذا كنت بحاجة إلى إرسال البيانات إلى نقاط نهاية المستأجرين، ففكر في الأساليب الشائعة التالية:

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

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

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

شبكات VNets الخاصة بالمستأجر مع عناوين IP التي يختارها مزود الخدمة

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

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

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

شبكات VNets الخاصة بالمستأجر مع عناوين IP التي يختارها المستأجر

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

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

تخطيط الشبكة المحورية

يتيح لك hub and talk VNet topology نظير شبكة VNet مركزية مع شبكات VNet متعددة مكبرات الصوت. يمكنك التحكم مركزياً في دخول وخروج نسبة استخدام الشبكة لشبكة VNets الخاصة بك، والتحكم في ما إذا كانت الموارد في كل VNet الخاصة بكل حديث يمكن أن تتواصل مع بعضها. يمكن لكل VNet التحدث أيضاً الوصول إلى المكونات المشتركة، مثل Azure Firewall، وقد يكون قادراً على استخدام خدمات مثل Azure DDoS Protection.

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

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

تلميح

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

عنوان IP ثابت

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

عند العمل مع الأجهزة الظاهرية ومكونات البنية الأساسية الأخرى، ضع في اعتبارك استخدام موازن التحميل أو جدار الحماية لكل من عناوين IP الثابتة الواردة والصادرة. ضع في اعتبارك استخدام بوابة NAT للتحكم في عنوان IP لنسبة استخدام الشبكة الصادرة. لمزيد من المعلومات حول استخدام بوابة NAT في حل متعدد المستأجرين، راجع اعتبارات Azure NAT Gateway للتعددية.

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

الوكلاء

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

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

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

تتضمن أمثلة خدمات Microsoft التي توفر وكلاء للاتصال بشبكات المستأجرين ما يلي:

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

لمزيد من المعلومات حول Private Link ومتعددة المستأجرين، راجع Multitenancy وAzure Private Link.

أسماء المجالات والمجالات الفرعية وTLS

عند العمل مع أسماء المجال وأمان طبقة النقل (TLS) في حل متعدد المستأجرين، هناك عدد من الاعتبارات. راجع الاعتبارات المتعلقة بأسماء المجالات واستئجار متعدد.

أنماط توجيه البوابة وتفريغ البوابة

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

  • طلبات التوجيه إلى الخلفيات أو طوابع التوزيع الخاصة بالمستأجر.
  • التعامل مع أسماء المجالات الخاصة بالمستأجر وشهادات TLS.
  • فحص الطلبات بحثاً عن تهديدات الأمان، باستخدام جدار حماية تطبيق الويب (WAF).
  • استجابات التخزين المؤقت لتحسين الأداء.

يوفر Azure العديد من الخدمات التي يمكن استخدامها لتحقيق بعض أو كل هذه الأهداف، بما في ذلك Azure Front Door وAzure Application بوابة وAzure APIM Management. يمكنك أيضاً توزيع الحل المخصص الخاص بك، باستخدام برامج مثل NGINX أو HAProxy.

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

نمط Hosting المحتوى الثابت

يتضمن نمط Hosting المحتوى الثابت تقديم محتوى الويب من خدمة تخزين سحابية أصلية، واستخدام شبكة توصيل المحتوى (CDN) لتخزين المحتوى مؤقتاً.

يمكنك استخدام Azure Front Door أو CDN آخر للمكونات الثابتة للحل الخاص بك، مثل تطبيقات JavaScript أحادية الصفحة، وللمحتوى الثابت مثل ملفات الصور والمستندات.

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

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

الفشل في التخطيط لاتصال VNet

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

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

لا تخطيط للحدود

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

الشبكات الفرعية الصغيرة

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

تقسيم الشبكة غير المناسب

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

الاعتماد فقط على ضوابط أمان طبقة الشبكة

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

إعادة كتابة عناوين المضيف دون اختبار

عند استخدام نمط إلغاء تحميل البوابة، يمكنك التفكير في إعادة كتابة Host عنوان طلبات HTTP. يمكن لهذه الممارسة تبسيط تكوين خدمة تطبيق الويب الخلفية الخاصة بك عن طريق إلغاء تحميل المجال المخصص وإدارة TLS إلى البوابة.

ومع ذلك، يمكن أن تتسبب عمليات إعادة كتابة العنوان Host في حدوث مشكلات في بعض خدمات الواجهة الخلفية. إذا أصدر تطبيقك عمليات إعادة توجيه HTTP أو ملفات تعريف الارتباط، فقد يؤدي عدم التطابق في أسماء المضيف إلى تعطيل وظائف التطبيق. على وجه الخصوص، يمكن أن تنشأ هذه المشكلة عند استخدام خدمات الواجهة الخلفية متعددة المستأجرين نفسها، مثل Azure App Service وAzure Functions وAzure Spring Apps. لمزيد من المعلومات، راجع أفضل ممارسات الاحتفاظ باسم المضيف.

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

المساهمون

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

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

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

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

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