أفضل ممارسات Azure Operator Service Manager لإعداد وظائف الشبكة وتوزيعها

مقالة
11/16/2023

طورت Microsoft العديد من الممارسات المثبتة لإدارة وظائف الشبكة (NFs) باستخدام Azure Operator Service Manager. توفر هذه المقالة إرشادات يمكن لموردي NF ومشغلي الاتصالات وشركائهم اتباعها لتحسين التصميم. ضع هذه الممارسات في الاعتبار عند إلحاق ونشر NFs الخاصة بك.

اعتبارات عامة

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

قم بتركيب البيانات الاصطناعية الخاصة بك لتتوافق مع الاستخدام المخطط له. ضع في اعتبارك فصل البيانات الاصطناعية العمومية عن البيانات الاصطناعية التي تريد تغييرها حسب الموقع أو المثيل.
تأكد من تكوين الخدمة ل NFs متعددة مع مجموعة من المعلمات التي تطابق احتياجات شبكتك. على سبيل المثال، قد يكون لديك مخطط يحتوي على 1000 قيمة ويمكنك تخصيص 100 منها فقط. تأكد في طبقة مخطط مجموعة التكوين (CGS) (التي تغطيها بشكل أوسع في الأقسام التالية) من أنك تعرض 100 فقط.
فكر مبكرا في كيفية فصل البنية الأساسية (على سبيل المثال، المجموعات) أو مخازن البيانات الاصطناعية والوصول بين الموردين، خاصة داخل خدمة واحدة. اجعل مجموعة موارد الناشر تطابق هذا النموذج.
يعد موقع Azure Operator Service Manager مفهوما منطقيا، وهو تمثيل لوجهة التوزيع. الأمثلة هي مجموعة Kubernetes لوظائف الشبكة الحاوية (CNFs) أو موقع مخصص موسع ل Azure Operator Nexus لوظائف الشبكة الظاهرية (VNFs). إنه ليس تمثيلا لموقع الحافة الفعلية، لذلك لديك حالات استخدام حيث تشترك مواقع متعددة في نفس الموقع الفعلي.
يوفر Azure Operator Service Manager واجهات برمجة تطبيقات مختلفة تجعل من السهل الجمع مع ADO أو أدوات البنية الأساسية لبرنامج ربط العمليات التجارية الأخرى.

اعتبارات الناشر

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

ضع في اعتبارك المنطق التالي:
- إذا تم وضع علامة على وظيفة تصميم خدمة الشبكة (NSDV) على أنها غير قابلة للتغيير، يجب وضع علامة على CGS على أنها غير قابلة للتغيير أيضا. وإلا، يفشل استدعاء النشر.
- إذا تم وضع علامة على إصدار تصميم وظيفة الشبكة (NFDV) على أنه غير قابل للتغيير، يجب وضع علامة على بيان البيانات الاصطناعية على أنه غير قابل للتغيير أيضا. وإلا، يفشل استدعاء النشر.
- إذا تم وضع علامة غير قابل للتغيير على بيان البيانات الاصطناعية أو CGS فقط، ينجح استدعاء النشر بغض النظر عما إذا تم وضع علامة على NFDV وNSDV على أنهما غير قابلين للتغيير.
- يضمن وضع علامة على بيان البيانات الاصطناعية على أنه غير قابل للتغيير وضع علامة على جميع البيانات الاصطناعية المدرجة في هذا البيان (عادة، المخططات والصور وقوالب Azure Resource Manager [قوالب ARM]) غير قابلة للتغيير أيضا عن طريق فرض الأذونات الضرورية على مخزن البيانات الاصطناعية.
فكر في استخدام اصطلاحات التسمية وتقنيات الحوكمة المتفق عليها للمساعدة في معالجة أي ثغرات متبقية.

مجموعة تعريف وظيفة الشبكة واعتبارات الإصدار

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

بالنسبة لإصدارات تعريف وظيفة الشبكة المضمنة في حاويات (CNF NFDVs)، networkFunctionApplications يمكن أن تحتوي القائمة على حزم helm فقط. من المعقول تضمين حزم helm متعددة إذا تم نشرها وحذفها دائما معا.

بالنسبة لإصدارات تعريف دالة الشبكة الظاهرية (VNF NFDVs)، networkFunctionApplications يجب أن تحتوي القائمة على قالب ARM واحد VhdImageFile على الأقل. يجب أن يوزع قالب ARM جهازا ظاهريا واحدا (VM). لنشر أجهزة ظاهرية متعددة ل VNF واحد، تأكد من استخدام قوالب ARM منفصلة لكل جهاز ظاهري.

يمكن لقالب ARM نشر موارد Resource Manager فقط من موفري الموارد التاليين:

Microsoft.Compute
Microsoft.Network
Microsoft.NetworkCloud
Microsoft.Storage
Microsoft.NetworkFabric
Microsoft.Authorization
Microsoft.ManagedIdentity

إشعار

بالنسبة لقوالب ARM التي تحتوي على أي شيء خارج القائمة السابقة، تؤدي جميع استدعاءات PUT وإعادة PUT على VNF إلى خطأ في التحقق من الصحة.

حالات الاستخدام الشائعة التي تؤدي إلى تحديث الإصدار الثانوي أو الرئيسي لإصدار "تصميم دالة الشبكة"

تحديث قيم مجموعة CGS/التكوين (CGVs) لإصدار موجود يؤدي إلى تغيير deployParametersMappingRuleProfile.
تحديث القيم التي تم ترميزها في NFDV.
وضع علامة على المكونات غير نشطة لمنع نشرها عبر applicationEnablement: Disabled.
إصدار NF جديد، مثل المخططات والصور.

إشعار

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

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

مجموعة تصميم خدمة الشبكة (NSDG) هي مركب مكون من مجموعة NFDG واحدة أو أكثر وأي مكونات بنية أساسية (مثل Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS] clusters and virtual machines) المنشورة في نفس الوقت. تشير خدمة شبكة الموقع (SNS) إلى NSDV واحد. يضمن هذا التصميم نشرا متسقا وقابلا للتكرار لخدمة الشبكة إلى موقع معين من SNS PUT واحد.

مثال على NSDG هو:

دالة خادم المصادقة (AUSF) NF
NF لإدارة البيانات الموحدة (UDM)
مسؤول VM يدعم AUSF/UDM
Unity Cloud (UC) Session Management Function (SMF) NF
مجموعة NAKS، التي يتم نشر AUSF وUDM وSMF إليها

تشكل هذه المكونات الخمسة مجموعة أمان شبكة واحدة. يمكن أن تحتوي NSDG واحدة على NSDVs متعددة.

حالات الاستخدام الشائعة التي تؤدي إلى تحديث الإصدار الثانوي أو الرئيسي لتصميم خدمة الشبكة

إنشاء أو حذف CGSs.
التغييرات في قالب NF ARM المقترن بأحد NFs التي يتم نشرها.
التغييرات في قالب ARM للبنية الأساسية، على سبيل المثال، AKS/NAKS أو VM.

إشعار

يجب ألا تؤدي التغييرات في NFDV إلى تشغيل تحديث NSDV. يجب عرض قيمة NFDV كمعلمة داخل CGS، بحيث يمكن للمشغلين التحكم في ما يجب نشره باستخدام CGVs.

اعتبارات مخطط مجموعة التكوين

نوصي بأن تبدأ دائما ب CGS واحد ل NF بأكمله. إذا كانت هناك معلمات خاصة بالموقع أو خاصة بالمثيل، فما زلنا نوصي بالاحتفاظ بها في CGS واحد. نوصي بالتقسيم إلى CGSs متعددة عندما تكون هناك مكونات متعددة (نادرا ما تكون NFs أو البنية الأساسية الأكثر شيوعا) أو التكوينات التي تتم مشاركتها عبر NFs متعددة. يحدد عدد CGSs عدد CGVs.

السيناريو

يتم دائما نشر FluentD وKibana وSplunk (مكونات الجهات الخارجية الشائعة) لجميع NFs داخل NSD. نوصي بتجميع هذه المكونات في NFDG واحد.
يحتوي NSD على عدة NFs تشترك جميعها في بعض التكوينات (موقع النشر واسم الناشر وبعض تكوينات المخطط).

في هذا السيناريو، نوصي باستخدام CGS عمومي واحد لعرض تكوينات مكونات NF والجهات الخارجية الشائعة. يمكنك تحديد CGS الخاصة ب NF حسب الحاجة.

اختيار معلمات لعرضها

يجب أن تحتوي CGS فقط على معلمات تستخدمها NFs (تكوين اليوم 0/N) أو المكونات المشتركة.
يجب أن تحتوي المعلمات التي نادرا ما يتم تكوينها على قيم افتراضية محددة.
إذا تم استخدام عدة CGSs، نوصي بتراكب ضئيل أو معدوم بين المعلمات. إذا كان التداخل مطلوبا، فتأكد من أن أسماء المعلمات مميزة بوضوح بين CGSs.
يجب مراعاة ما يمكن تعريفه عبر واجهة برمجة التطبيقات (Azure Operator Nexus، Azure Operator Service Manager) لخدمة CGS. على عكس، على سبيل المثال، تعريف قيم التكوين هذه عبر ملفات CloudInit.
عندما تكون غير متأكد، فإن نقطة البداية الجيدة هي كشف المعلمة و يكون لها افتراضي معقول محدد في CGS. يوضح المثال التالي نموذج CGS وحمولة CGV المقابلة.
يجب استخدام هوية مدارة واحدة يعينها المستخدم في جميع قوالب NF ARM ويجب كشفها عبر CGS.

حمولة CGS:

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

حمولة CGV المقابلة التي تم تمريرها بواسطة عامل التشغيل:

{
"qwe": 20
}

حمولة CGV الناتجة التي تم إنشاؤها بواسطة Azure Operator Service Manager:

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

اعتبارات قيم مجموعة التكوين

قبل إرسال إنشاء مورد CGV، يمكنك التحقق من أن مخطط وقيم ملف YAML أو JSON الأساسي تتطابق مع ما تتوقعه CGS المقابلة. لتحقيق ذلك، أحد الخيارات هو استخدام ملحق YAML ل Visual Studio Code.

اعتبارات CLI

يساعد ملحق Azure Operator Service Manager CLI في نشر NFDs وNSDs. استخدم هذه الأداة كنقطة بداية لإنشاء NFDs وNSDs جديدة. ضع في اعتبارك استخدام CLI لإنشاء الملفات الأولية. ثم قم بتحريرها لدمج مكونات البنية الأساسية قبل النشر.

اعتبارات خدمة شبكة الموقع

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

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

تعيين موارد Azure Operator Service Manager لكل حالة استخدام

يوضح السيناريوهان التاليان تعيين موارد Azure Operator Service Manager.

السيناريو: دالة شبكة واحدة

يتم نشر NF مع مكون تطبيق واحد أو اثنين إلى نظام مجموعة NAKS.

تصنيف الموارد:

NFDG: إذا كان من الممكن استخدام المكونات بشكل مستقل، فإن مجموعتي NFDG، واحدة لكل مكون. إذا كانت المكونات تنشر دائما معا، فإن NFDG واحد.
NFDV: استنادا إلى حالات الاستخدام المذكورة في أقسام "حالات الاستخدام الشائعة" السابقة التي تقوم بتشغيل تحديثات الإصدار الثانوي أو الرئيسي ل NFDV.
NSDG: مفرد. يجمع بين NFs وتعريفات مجموعة Kubernetes.
NSDV: حسب الحاجة استنادا إلى حالات الاستخدام المذكورة في أقسام "حالات الاستخدام الشائعة" السابقة التي تقوم بتشغيل تحديثات الإصدار الثانوي أو الرئيسي ل NSDV.
CGS: مفرد. نوصي بأن تحتوي CGS على أجزاء فرعية لكل مكون والبنية الأساسية التي يتم نشرها لتسهيل الإدارة، وتتضمن إصدارات NFDs.
CGV: واحد استنادا إلى عدد CGSs.
SNS: مفرد لكل NSDV.

السيناريو: وظائف شبكة متعددة

يتم نشر NFs متعددة مع بعض المكونات المشتركة والمستقلة إلى نظام مجموعة NAKS.

تصنيف الموارد:

NFDG:
- NFDG لجميع المكونات المشتركة.
- NFDG لكل مكون مستقل أو NF.
NFDV: متعدد لكل NFDG لكل حالة استخدام مذكورة في أقسام "حالات الاستخدام الشائعة" السابقة التي تقوم بتشغيل تحديثات الإصدار الثانوي أو الرئيسي ل NFDV.
NSDG: مفرد. يجمع بين جميع NFs والمكونات المشتركة والمستقلة والبنية الأساسية (مجموعة Kubernetes أو أي أجهزة ظاهرية داعمة).
NSDV: حسب الحاجة استنادا إلى حالات الاستخدام المذكورة في أقسام "حالات الاستخدام الشائعة" السابقة التي تقوم بتشغيل تحديثات الإصدار الثانوي أو الرئيسي ل NSDV.
CGS:
- أعزب/عزباء. عمومي لكافة المكونات التي تحتوي على قيم تكوين مشتركة.
- NF CGS لكل NF، بما في ذلك إصدار NFD.
- اعتمادا على العدد الإجمالي للمعلمات، ضع في اعتبارك دمج جميع CGSs في CGS واحدة.
CGV: يساوي عدد CGSs.
SNS: مفرد لكل NSDV.

اعتبارات ترقية البرامج

بافتراض دعم NFs للترقيات الموضعية/في الخدمة، ل CNFs:

إذا تمت إضافة مخططات وصور جديدة، يقوم Azure Operator Service Manager بتثبيت المخططات الجديدة.
إذا تمت إزالة بعض المخططات والصور، يقوم Azure Operator Service Manager بحذف المخططات التي لم تعد معلنة في NFDV.
يتحقق Azure Operator Service Manager من أن NFDV/NSDV نشأ من نفس NFDG/NSDG ومن ثم نفس الناشر. الترقيات عبر الناشرين غير مدعومة.

بالنسبة إلى VNFs:

الترقيات الموضعية غير مدعومة حاليا. تحتاج إلى إنشاء مثيل VNF جديد مع صورة محدثة جنبا إلى جنب. ثم احذف VNF الأقدم عن طريق حذف SNS.
إذا تم نشر VNF كزوج من الأجهزة الظاهرية لقابلية الوصول العالية، يمكنك تصميم خدمة الشبكة بطريقة يمكنك من خلالها حذف الأجهزة الظاهرية وترقيتها واحدا تلو الآخر. نوصي بالتصمين التالي للسماح بحذف الأجهزة الظاهرية الفردية وترقيتها:
- يتم نشر كل جهاز ظاهري باستخدام قالب ARM مخصص.
- من قالب ARM، يجب الكشف عن معلمتين عبر CGS: اسم الجهاز الظاهري، للسماح بالإشارة إلى المثيل الأساسي/الثانوي، ونهج النشر، والتحكم في ما إذا كان نشر الجهاز الظاهري مسموحا به أم لا.
- في NFDV، deployParameterstemplateParameters وتحتاج إلى أن تكون معلمة بطريقة يمكنك من خلالها توفير القيم الفريدة باستخدام CGVs لكل منها.

اعتبارات التوافر العالي والتعافي من الكوارث

Azure Operator Service Manager هي خدمة إقليمية موزعة عبر مناطق التوفر في المناطق التي تدعمها. بالنسبة لجميع المناطق التي يتوفر فيها Azure Operator Service Manager، راجع منتجات Azure حسب المنطقة. للحصول على قائمة مناطق Azure التي تحتوي على مناطق توفر، راجع اختيار منطقة Azure المناسبة لك.

ضع في اعتبارك متطلبات قابلية الوصول العالية والتعافي من الكوارث التالية:

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

إشعار

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

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

اعتبارات استكشاف الأخطاء وإصلاحها

أثناء التثبيت والترقية بشكل افتراضي، يتم تعيين خيارات الذرية والانتظار إلى true، ويتم تعيين مهلة العملية إلى 27 minutes. أثناء الإعداد، نوصي بتعيين العلامة الذرية لمنع false التراجع عن Helm عند الفشل. الطريقة المثلى لتحقيق ذلك هي في قالب ARM من NF.

في قالب ARM، أضف القسم التالي:

"roleOverrideValues": [
    "{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]

يتم تعريف اسم المكون في NFDV:

     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'fed-crds'
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }

اعتبارات التنظيف

احذف موارد عامل التشغيل بالترتيب التالي للتأكد من عدم ترك أي موارد معزولة خلفك:

جوهريه
Site
CGV

هام

تأكد من حذف SNS قبل حذف NFDV.

احذف موارد الناشر بالترتيب التالي للتأكد من عدم ترك أي موارد معزولة:

CGS
NSDV
NSDG
NFDV
NFDG
بيان البيانات الاصطناعية
مخزن البيانات الاصطناعية
Publisher

Share via

أفضل ممارسات Azure Operator Service Manager لإعداد وظائف الشبكة وتوزيعها

اعتبارات عامة

اعتبارات الناشر

مجموعة تعريف وظيفة الشبكة واعتبارات الإصدار

حالات الاستخدام الشائعة التي تؤدي إلى تحديث الإصدار الثانوي أو الرئيسي لإصدار "تصميم دالة الشبكة"

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

حالات الاستخدام الشائعة التي تؤدي إلى تحديث الإصدار الثانوي أو الرئيسي لتصميم خدمة الشبكة

اعتبارات مخطط مجموعة التكوين

السيناريو

اختيار معلمات لعرضها

اعتبارات قيم مجموعة التكوين

اعتبارات CLI

اعتبارات خدمة شبكة الموقع

تعيين موارد Azure Operator Service Manager لكل حالة استخدام

السيناريو: دالة شبكة واحدة

السيناريو: وظائف شبكة متعددة

اعتبارات ترقية البرامج

اعتبارات التوافر العالي والتعافي من الكوارث

اعتبارات استكشاف الأخطاء وإصلاحها

اعتبارات التنظيف

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

الموارد الإضافية