Bagikan melalui

Praktik terbaik Azure Operator Service Manager untuk onboarding dan menyebarkan fungsi jaringan

  • Artikel

Microsoft telah mengembangkan banyak praktik yang terbukti untuk mengelola fungsi jaringan (NF) dengan menggunakan Azure Operator Service Manager. Artikel ini menyediakan panduan yang dapat diikuti vendor NF, operator telco, dan mitra mereka untuk mengoptimalkan desain. Ingatlah praktik ini saat Anda onboarding dan sebarkan NF Anda.

Pertimbangan umum

Kami menyarankan agar Anda terlebih dahulu melakukan onboarding dan menyebarkan NF paling sederhana (satu atau dua bagan) dengan menggunakan mulai cepat untuk membiasakan diri dengan alur keseluruhan. Anda dapat menambahkan detail konfigurasi yang diperlukan dalam perulangan berikutnya. Saat Anda melalui mulai cepat, pertimbangkan poin-poin berikut:

  • Susun artefak Anda agar selaras dengan penggunaan yang direncanakan. Pertimbangkan untuk memisahkan artefak global dari artefak yang ingin Anda variasikan menurut situs atau instans.
  • Pastikan komposisi layanan beberapa NF dengan sekumpulan parameter yang sesuai dengan kebutuhan jaringan Anda. Misalnya, Anda mungkin memiliki bagan yang memiliki 1.000 nilai dan Anda hanya menyesuaikan 100 di antaranya. Pastikan di lapisan Skema Grup Konfigurasi (CGS) (tercakup lebih luas di bagian berikut) bahwa Anda hanya mengekspos 100.
  • Pikirkan lebih awal tentang bagaimana Anda ingin memisahkan infrastruktur (misalnya, kluster) atau penyimpanan artefak dan akses antara pemasok, khususnya dalam satu layanan. Buat set sumber daya penerbit Anda cocok dengan model ini.
  • Situs Azure Operator Service Manager adalah konsep logis, representasi tujuan penyebaran. Contohnya adalah kluster Kubernetes untuk Containerized Network Functions (CNF) atau lokasi kustom yang diperluas Azure Operator Nexus untuk Virtualized Network Functions (VNF). Ini bukan representasi situs tepi fisik, jadi Anda memiliki kasus penggunaan di mana beberapa situs berbagi lokasi fisik yang sama.
  • Azure Operator Service Manager menyediakan berbagai API sehingga mudah digabungkan dengan ADO atau alat alur lainnya.

Pertimbangan penerbit

  • Kami menyarankan agar Anda membuat satu penerbit per pemasok NF. Praktik ini memberikan dukungan, pemeliharaan, dan pengalaman tata kelola yang optimal di semua pemasok dan menyederhanakan desain layanan jaringan Anda saat terdiri dari beberapa NF dari beberapa vendor.

  • Setelah serangkaian sumber daya dan artefak penerbit Azure Operator Service Manager yang diinginkan diuji dan disetujui untuk penggunaan produksi, sebaiknya tandai seluruh set sebagai tidak dapat diubah untuk mencegah perubahan yang tidak disengaja dan memastikan pengalaman penyebaran yang konsisten. Pertimbangkan untuk mengandalkan kemampuan imutabilitas untuk membedakan antara sumber daya dan artefak yang digunakan dalam produksi versus yang digunakan untuk tujuan pengujian dan pengembangan. Anda dapat mengkueri status sumber daya penerbit dan manifes artefak untuk menentukan mana yang ditandai sebagai tidak dapat diubah. Untuk informasi selengkapnya, lihat Penyewa penerbit, langganan, wilayah, dan manajemen pratinjau.

    Ingatlah logika berikut:

    • Jika Fungsi Desain Layanan Jaringan (NSDV) ditandai sebagai tidak dapat diubah, CGS juga harus ditandai sebagai tidak dapat diubah. Jika tidak, panggilan penyebaran gagal.
    • Jika Versi Desain Fungsi Jaringan (NFDV) ditandai sebagai tidak dapat diubah, manifes artefak juga harus ditandai sebagai tidak dapat diubah. Jika tidak, panggilan penyebaran gagal.
    • Jika hanya manifes artefak atau CGS yang ditandai tidak dapat diubah, panggilan penyebaran berhasil terlepas dari apakah NFDV dan NSDV ditandai sebagai tidak dapat diubah.
    • Menandai manifes artefak sebagai tidak dapat diubah memastikan bahwa semua artefak yang tercantum dalam manifes tersebut (biasanya, bagan, gambar, dan templat Azure Resource Manager [templat ARM]) ditandai tidak dapat diubah juga dengan memberlakukan izin yang diperlukan di penyimpanan artefak.

  • Pertimbangkan untuk menggunakan konvensi penamaan dan teknik tata kelola yang disepakati untuk membantu mengatasi kesenjangan yang tersisa.

Pertimbangan Grup Definisi Fungsi Jaringan dan Versi

Network Function Definition Group (NFDG) mewakili komponen terkecil yang Anda rencanakan untuk digunakan kembali secara independen di beberapa layanan. Semua bagian NFDG selalu disebarkan bersama-sama. Bagian-bagian ini disebut networkFunctionApplications. Misalnya, wajar untuk onboarding satu NF yang terdiri dari beberapa bagan dan gambar Helm sebagai satu NFDG jika Anda selalu menyebarkan komponen tersebut bersama-sama. Dalam kasus ketika beberapa NF selalu disebarkan bersama-sama, wajar untuk memiliki satu NFDG untuk semuanya. NFDG tunggal dapat memiliki beberapa NFDV.

Untuk Versi Definisi Fungsi Jaringan Terkontainer (CNF NFDV), networkFunctionApplications daftar hanya dapat berisi paket helm. Sangat masuk akal untuk menyertakan beberapa paket helm jika selalu disebarkan dan dihapus bersama-sama.

Untuk Versi Definisi Fungsi Jaringan Virtual (VNF NFDV), networkFunctionApplications daftar harus berisi setidaknya satu VhdImageFile dan satu templat ARM. Templat ARM harus menyebarkan satu komputer virtual (VM). Untuk menyebarkan beberapa VM untuk satu VNF, pastikan untuk menggunakan templat ARM terpisah untuk setiap VM.

Templat ARM hanya dapat menyebarkan sumber daya Resource Manager dari penyedia sumber daya berikut:

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

Catatan

Untuk templat ARM yang berisi apa pun di luar daftar sebelumnya, semua panggilan PUT dan Put Ulang pada VNF mengakibatkan kesalahan validasi.

Kasus penggunaan umum yang memicu Versi Desain Fungsi Jaringan pembaruan versi minor atau utama

  • Memperbarui CGS/Configuration Group Values (CGV) untuk rilis yang ada yang memicu perubahan deployParametersMappingRuleProfile.
  • Memperbarui nilai yang dikodekan secara permanen di NFDV.
  • Menandai komponen tidak aktif untuk mencegahnya disebarkan melalui applicationEnablement: Disabled.
  • Rilis NF baru, seperti bagan dan gambar.

Catatan

Jumlah minimum perubahan yang diperlukan setiap kali payload NF tertentu berubah. Rilis NF minor atau utama tanpa mengekspos parameter CGS baru hanya memerlukan pembaruan manifes artefak, mendorong gambar dan bagan baru, dan menabrak versi NFDV.

Pertimbangan Grup Desain Layanan Jaringan dan Versi

Network Service Design Group (NSDG) adalah komposit dari satu atau beberapa NFDG dan komponen infrastruktur apa pun (seperti kluster Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS] dan komputer virtual) yang disebarkan secara bersamaan. Layanan jaringan situs (SNS) mengacu pada satu NSDV. Desain tersebut menjamin penyebaran layanan jaringan yang konsisten dan berulang ke situs tertentu dari satu SNS PUT.

Contoh NSDG adalah:

  • Fungsi Server Autentikasi (AUSF) NF
  • NF Manajemen Data Terpadu (UDM)
  • Admin VM yang mendukung AUSF/UDM
  • Unity Cloud (UC) Session Management Function (SMF) NF
  • Kluster NAKS, tempat AUSF, UDM, dan SMF disebarkan

Kelima komponen ini membentuk satu NSDG. Satu NSDG dapat memiliki beberapa NSDV.

Kasus penggunaan umum yang memicu Versi Desain Layanan Jaringan pembaruan versi minor atau utama

  • Membuat atau menghapus CGS.
  • Perubahan dalam templat NF ARM yang terkait dengan salah satu NF yang sedang disebarkan.
  • Perubahan dalam templat ARM infrastruktur, misalnya, AKS/NAKS atau VM.

Catatan

Perubahan NFDV tidak boleh memicu pembaruan NSDV. Nilai NFDV harus diekspos sebagai parameter dalam CGS, sehingga operator dapat mengontrol apa yang harus disebarkan dengan menggunakan CGV.

Pertimbangan Skema Grup Konfigurasi

Sebaiknya Anda selalu memulai dengan satu CGS untuk seluruh NF. Jika ada parameter khusus situs atau khusus instans, kami masih menyarankan Agar Anda menyimpannya dalam satu CGS. Sebaiknya bagi menjadi beberapa CGS ketika ada beberapa komponen (jarang NF, lebih umum, infrastruktur) atau konfigurasi yang dibagikan di beberapa NF. Jumlah CGS mendefinisikan jumlah CGV.

Skenario

  • FluentD, Kibana, dan Splunk (komponen pihak ketiga umum) selalu disebarkan untuk semua NF dalam NSD. Sebaiknya kelompokkan komponen ini ke dalam satu NFDG.
  • NSD memiliki beberapa NF yang semuanya berbagi beberapa konfigurasi (lokasi penyebaran, nama penerbit, dan beberapa konfigurasi bagan).

Dalam skenario ini, kami sarankan Anda menggunakan satu CGS global untuk mengekspos konfigurasi NF umum dan komponen pihak ketiga. Anda dapat menentukan CGS khusus NF sesuai kebutuhan.

Pilih parameter untuk diekspos

  • CGS hanya boleh memiliki parameter yang digunakan oleh NF (konfigurasi hari 0/N) atau komponen bersama.
  • Parameter yang jarang dikonfigurasi harus memiliki nilai default yang ditentukan.
  • Jika beberapa CGS digunakan, kami sarankan sedikit atau tidak ada tumpang tindih antara parameter. Jika tumpang tindih diperlukan, pastikan nama parameter dapat dibedakan dengan jelas antara CGS.
  • Apa yang dapat didefinisikan melalui API (Azure Operator Nexus, Azure Operator Service Manager) harus dipertimbangkan untuk CGS. Dibandingkan dengan, misalnya, menentukan nilai konfigurasi tersebut melalui file CloudInit.
  • Ketika tidak yakin, titik awal yang baik adalah mengekspos parameter dan memiliki default yang wajar yang ditentukan dalam CGS. Contoh berikut menunjukkan sampel CGS dan payload CGV yang sesuai.
  • Satu identitas terkelola yang ditetapkan pengguna harus digunakan di semua templat NF ARM dan harus diekspos melalui CGS.

Payload CGS:

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

Payload CGV yang sesuai diteruskan oleh operator:

{
"qwe": 20
}

Menghasilkan payload CGV yang dihasilkan oleh Azure Operator Service Manager:

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

Pertimbangan Nilai Grup Konfigurasi

Sebelum mengirimkan pembuatan sumber daya CGV, Anda dapat memvalidasi bahwa skema dan nilai file YAML atau JSON yang mendasar cocok dengan apa yang diharapkan CGS yang sesuai. Untuk mencapainya, salah satu opsinya adalah menggunakan ekstensi YAML untuk Visual Studio Code.

Pertimbangan CLI

Ekstensi Azure Operator Service Manager CLI membantu penerbitan NFD dan NSD. Gunakan alat ini sebagai titik awal untuk membuat NFD dan NSD baru. Pertimbangkan untuk menggunakan CLI untuk membuat file awal. Kemudian edit untuk menggabungkan komponen infrastruktur sebelum Anda menerbitkan.

Pertimbangan layanan jaringan situs

Kami menyarankan agar Anda memiliki satu SNS untuk seluruh situs, termasuk infrastruktur. SNS harus menyebarkan infrastruktur apa pun yang diperlukan (misalnya, kluster NAKS/AKS dan komputer virtual), lalu menyebarkan NF yang diperlukan di atasnya. Desain tersebut menjamin penyebaran layanan jaringan yang konsisten dan berulang ke situs tertentu dari satu SNS PUT.

Sebaiknya setiap SNS disebarkan dengan identitas terkelola yang ditetapkan pengguna daripada identitas terkelola yang ditetapkan sistem. Identitas terkelola yang ditetapkan pengguna ini harus memiliki izin untuk mengakses NFDV dan harus memiliki peran Operator Identitas Terkelola itu sendiri. Untuk informasi selengkapnya, lihat Membuat dan menetapkan identitas terkelola yang ditetapkan pengguna.

Pemetaan sumber daya Azure Operator Service Manager per kasus penggunaan

Dua skenario berikut mengilustrasikan pemetaan sumber daya Azure Operator Service Manager.

Skenario: Fungsi jaringan tunggal

NF dengan satu atau dua komponen aplikasi disebarkan ke kluster NAKS.

Perincian sumber daya:

  • NFDG: Jika komponen dapat digunakan secara independen, dua NFDG, satu per komponen. Jika komponen selalu disebarkan bersama-sama, maka satu NFDG.
  • NFDV: Sesuai kebutuhan berdasarkan kasus penggunaan yang disebutkan di bagian "Kasus penggunaan umum" sebelumnya yang memicu pembaruan versi minor atau utama NFDV.
  • NSDG: Tunggal. Menggabungkan NF dan definisi kluster Kubernetes.
  • NSDV: Sesuai kebutuhan berdasarkan kasus penggunaan yang disebutkan di bagian "Kasus penggunaan umum" sebelumnya yang memicu pembaruan versi minor atau utama NSDV.
  • CGS: Tunggal. Sebaiknya CGS memiliki sub bagian untuk setiap komponen dan infrastruktur yang disebarkan untuk manajemen yang lebih mudah, dan menyertakan versi untuk NFD.
  • CGV: Tunggal berdasarkan jumlah CGS.
  • SNS: Tunggal per NSDV.

Skenario: Beberapa fungsi jaringan

Beberapa NF dengan beberapa komponen bersama dan independen disebarkan ke kluster NAKS.

Perincian sumber daya:

  • NFDG:
    • NFDG untuk semua komponen bersama.
    • NFDG untuk setiap komponen independen atau NF.
  • NFDV: Beberapa per setiap NFDG per kasus penggunaan yang disebutkan di bagian "Kasus penggunaan umum" sebelumnya yang memicu pembaruan versi minor atau utama NFDV.
  • NSDG: Tunggal. Menggabungkan semua NF, komponen bersama dan independen, dan infrastruktur (kluster Kubernetes atau VM pendukung apa pun).
  • NSDV: Sesuai kebutuhan berdasarkan kasus penggunaan yang disebutkan di bagian "Kasus penggunaan umum" sebelumnya yang memicu pembaruan versi minor atau utama NSDV.
  • CGS:
    • Satu. Global untuk semua komponen yang memiliki nilai konfigurasi bersama.
    • NF CGS per NF, termasuk versi NFD.
    • Bergantung pada jumlah total parameter, pertimbangkan untuk menggabungkan semua CGS ke dalam satu CGS.
  • CGV: Sama dengan jumlah CGS.
  • SNS: Tunggal per NSDV.

Pertimbangan peningkatan perangkat lunak

Dengan asumsi NF mendukung peningkatan di tempat/dalam layanan, untuk CNF:

  • Jika bagan dan gambar baru ditambahkan, Azure Operator Service Manager menginstal bagan baru.
  • Jika beberapa bagan dan gambar dihapus, Azure Operator Service Manager menghapus bagan yang tidak lagi dideklarasikan dalam NFDV.
  • Azure Operator Service Manager memvalidasi bahwa NFDV/NSDV berasal dari NFDG/NSDG yang sama dan karenanya penerbit yang sama. Peningkatan lintas penerbit tidak didukung.

Untuk VNF:

  • Peningkatan di tempat saat ini tidak didukung. Anda perlu membuat instans VNF baru dengan gambar yang diperbarui secara berdampingan. Kemudian hapus VNF yang lebih lama dengan menghapus SNS.
  • Jika VNF disebarkan sebagai sepasang VM untuk ketersediaan tinggi, Anda dapat merancang layanan jaringan sedemikian rup sehingga Anda dapat menghapus dan meningkatkan VM satu per satu. Kami merekomendasikan desain berikut untuk memungkinkan penghapusan dan peningkatan masing-masing VM:
    • Setiap VM disebarkan dengan menggunakan templat ARM khusus.
    • Dari templat ARM, dua parameter perlu diekspos melalui CGS: Nama VM, untuk memungkinkan menunjukkan instans mana yang primer/sekunder, dan kebijakan penyebaran, mengontrol apakah penyebaran VM diizinkan atau tidak.
    • Dalam NFDV, deployParameters dan templateParameters perlu diparmetris sedih sehingga Anda dapat menyediakan nilai unik dengan menggunakan CGV untuk masing-masing.

Ketersediaan tinggi dan pertimbangan pemulihan bencana

Azure Operator Service Manager adalah layanan regional yang disebarkan di seluruh zona ketersediaan di wilayah yang mendukungnya. Untuk semua wilayah tempat Azure Operator Service Manager tersedia, lihat Produk Azure menurut wilayah. Untuk daftar wilayah Azure yang memiliki zona ketersediaan, lihat Memilih wilayah Azure yang tepat untuk Anda.

Pertimbangkan persyaratan ketersediaan tinggi dan pemulihan bencana berikut:

  • Untuk menyediakan geo-redundansi, pastikan Anda memiliki penerbit di setiap wilayah tempat Anda berencana untuk menyebarkan NF. Pertimbangkan untuk menggunakan alur untuk memastikan artefak dan sumber daya penerbit tetap sinkron di seluruh wilayah.
  • Nama penerbit harus unik per wilayah per penyewa Microsoft Entra.

Catatan

Jika suatu wilayah menjadi tidak tersedia, Anda dapat menyebarkan (tetapi tidak memutakhirkan) NF dengan menggunakan sumber daya penerbit di wilayah lain. Dengan asumsi bahwa artefak dan sumber daya identik antara penerbit, Anda hanya perlu mengubah networkServiceDesignVersionOfferingLocation nilai dalam payload sumber daya 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

Pemecahan masalah dan pertimbangan

Selama penginstalan dan peningkatan secara default, opsi atomik dan tunggu diatur ke true, dan batas waktu operasi diatur ke 27 minutes. Selama onboarding, kami sarankan Anda mengatur bendera atom untuk false mencegah pemutaran kembali Helm setelah kegagalan. Cara optimal untuk mencapai yang ada di templat ARM NF.

Di templat ARM, tambahkan bagian berikut:

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

Nama komponen ditentukan dalam NFDV:

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

Pertimbangan pembersihan

Hapus sumber daya operator dalam urutan berikut untuk memastikan tidak ada sumber daya tanpa intim yang tertinggal:

  • SNS
  • Site
  • CGV

Penting

Pastikan SNS dihapus sebelum Anda menghapus NFDV.

Hapus sumber daya penerbit dalam urutan berikut untuk memastikan tidak ada sumber daya tanpa intim yang tertinggal:

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • Manifes Artefak
  • Penyimpanan Artefak
  • Publisher

Langkah berikutnya