Pertimbangan jaringan untuk penyebaran cloud Azure Stack HCI, versi 23H2

Artikel
06/12/2024

Berlaku untuk: Azure Stack HCI, versi 23H2

Artikel ini membahas cara merancang dan merencanakan jaringan sistem Azure Stack HCI versi 23H2 untuk penyebaran cloud. Sebelum melanjutkan, biasakan diri Anda dengan berbagai pola jaringan Azure Stack HCI dan konfigurasi yang tersedia.

Kerangka kerja desain jaringan

Diagram berikut menunjukkan berbagai keputusan dan langkah-langkah yang menentukan kerangka kerja desain jaringan untuk sistem Azure Stack HCI Anda - ukuran kluster, konektivitas penyimpanan kluster, niat lalu lintas jaringan, konektivitas manajemen, dan konfigurasi adaptor jaringan. Setiap keputusan desain memungkinkan atau mengizinkan opsi desain yang tersedia dalam langkah-langkah berikutnya:

Langkah 1: Tentukan ukuran kluster

Untuk membantu menentukan ukuran sistem Azure Stack HCI Anda, gunakan alat pengukur Azure Stack HCI, di mana Anda dapat menentukan profil Anda seperti jumlah komputer virtual (VM), ukuran VM, dan penggunaan beban kerja VM seperti Azure Virtual Desktop, SQL Server, atau AKS.

Seperti yang dijelaskan dalam artikel persyaratan server sistem Azure Stack HCI, jumlah maksimum server yang didukung pada sistem Azure Stack HCI adalah 16. Setelah Menyelesaikan perencanaan kapasitas beban kerja, Anda harus memiliki pemahaman yang baik tentang jumlah simpul server yang diperlukan untuk menjalankan beban kerja pada infrastruktur Anda.

Jika beban kerja Anda memerlukan empat node atau lebih: Anda tidak dapat menyebarkan dan menggunakan konfigurasi tanpa switch untuk lalu lintas jaringan penyimpanan. Anda perlu menyertakan sakelar fisik dengan dukungan untuk Akses Memori Langsung Jarak Jauh (RDMA) untuk menangani lalu lintas penyimpanan. Untuk informasi selengkapnya tentang arsitektur jaringan kluster Azure Stack HCI, lihat Gambaran umum pola referensi jaringan.
Jika beban kerja Anda memerlukan tiga node atau kurang: Anda dapat memilih konfigurasi tanpa switch atau beralih untuk konektivitas penyimpanan.
Jika Anda berencana untuk meluaskan skala nanti ke lebih dari tiga simpul: Anda perlu menggunakan sakelar fisik untuk lalu lintas jaringan penyimpanan. Setiap operasi peluasan skala untuk penyebaran tanpa switchless memerlukan konfigurasi manual kabel jaringan Anda antara simpul yang tidak divalidasi Microsoft secara aktif sebagai bagian dari siklus pengembangan perangkat lunaknya untuk Azure Stack HCI.

Berikut adalah pertimbangan yang dirangkum untuk keputusan ukuran kluster:

Keputusan	Pertimbangan
Ukuran kluster (jumlah simpul per kluster)	Konfigurasi tanpa pengalihan melalui templat portal Azure atau Azure Resource Manager hanya tersedia untuk 1, 2, atau 3 kluster simpul. Kluster dengan 4 simpul atau lebih memerlukan sakelar fisik untuk lalu lintas jaringan penyimpanan.
Persyaratan peluasan skala	Jika Anda berniat untuk meluaskan skala kluster Anda menggunakan orkestrator, Anda perlu menggunakan sakelar fisik untuk lalu lintas jaringan penyimpanan.

Langkah 2: Tentukan konektivitas penyimpanan kluster

Seperti yang dijelaskan dalam Persyaratan jaringan fisik, Azure Stack HCI mendukung dua jenis konektivitas untuk lalu lintas jaringan penyimpanan:

Gunakan sakelar jaringan fisik untuk menangani lalu lintas.
Sambungkan simpul secara langsung di antara mereka dengan jaringan crossover atau kabel serat untuk lalu lintas penyimpanan.

Kelebihan dan kekurangan dari setiap opsi didokumentasikan dalam artikel yang ditautkan di atas.

Seperti yang dinyatakan sebelumnya, Anda hanya dapat memutuskan antara dua opsi ketika ukuran kluster Anda adalah tiga atau kurang simpul. Kluster apa pun dengan empat node atau lebih secara otomatis disebarkan menggunakan sakelar jaringan untuk penyimpanan.

Jika kluster memiliki kurang dari tiga simpul, keputusan konektivitas penyimpanan memengaruhi jumlah dan jenis niat jaringan yang dapat Anda tentukan di langkah berikutnya.

Misalnya, untuk konfigurasi tanpa switch, Anda perlu menentukan dua niat lalu lintas jaringan. Lalu lintas penyimpanan untuk komunikasi timur-barat menggunakan kabel crossover tidak memiliki konektivitas utara-selatan dan sepenuhnya terisolasi dari infrastruktur jaringan Anda lainnya. Itu berarti Anda perlu menentukan niat jaringan kedua untuk konektivitas keluar manajemen dan untuk beban kerja komputasi Anda.

Meskipun dimungkinkan untuk menentukan setiap niat jaringan hanya dengan masing-masing satu port adaptor jaringan fisik, yang tidak memberikan toleransi kesalahan apa pun. Dengan demikian, kami selalu menyarankan untuk menggunakan setidaknya dua port jaringan fisik untuk setiap niat jaringan. Jika Anda memutuskan untuk menggunakan sakelar jaringan untuk penyimpanan, Anda dapat mengelompokkan semua lalu lintas jaringan termasuk penyimpanan dalam satu niat jaringan, yang juga dikenal sebagai konfigurasi jaringan host hyperconverged atau sepenuhnya terkonvergen .

Berikut adalah pertimbangan ringkasan untuk keputusan konektivitas penyimpanan kluster:

Keputusan	Pertimbangan
Tidak ada sakelar untuk penyimpanan	Konfigurasi tanpa pengalihan melalui penyebaran templat portal Azure atau Resource Manager hanya didukung untuk 1, 2, atau 3 kluster simpul. 1 atau 2 kluster tanpa sakelar penyimpanan simpul dapat disebarkan menggunakan templat portal Azure atau Resource Manager. 3 kluster tanpa sakelar penyimpanan simpul hanya dapat disebarkan menggunakan templat Resource Manager. Operasi peluasan skala tidak didukung dengan penyebaran tanpa switch. Setiap perubahan pada jumlah simpul setelah penyebaran memerlukan konfigurasi manual. Setidaknya 2 niat jaringan diperlukan saat menggunakan konfigurasi tanpa sakelar penyimpanan.
Sakelar jaringan untuk penyimpanan	Jika Anda berniat untuk meluaskan skala kluster Anda menggunakan orkestrator, Anda perlu menggunakan sakelar fisik untuk lalu lintas jaringan penyimpanan. Anda dapat menggunakan arsitektur ini dengan sejumlah simpul antara 1 hingga 16. Meskipun tidak diberlakukan, Anda dapat menggunakan satu niat untuk semua jenis lalu lintas jaringan Anda (Manajemen, Komputasi, dan Penyimpanan)

Keputusan

Pertimbangan

Tidak ada sakelar untuk penyimpanan

Konfigurasi tanpa pengalihan melalui penyebaran templat portal Azure atau Resource Manager hanya didukung untuk 1, 2, atau 3 kluster simpul.

1 atau 2 kluster tanpa sakelar penyimpanan simpul dapat disebarkan menggunakan templat portal Azure atau Resource Manager.

3 kluster tanpa sakelar penyimpanan simpul hanya dapat disebarkan menggunakan templat Resource Manager.

Operasi peluasan skala tidak didukung dengan penyebaran tanpa switch. Setiap perubahan pada jumlah simpul setelah penyebaran memerlukan konfigurasi manual.

Setidaknya 2 niat jaringan diperlukan saat menggunakan konfigurasi tanpa sakelar penyimpanan.

Sakelar jaringan untuk penyimpanan

Jika Anda berniat untuk meluaskan skala kluster Anda menggunakan orkestrator, Anda perlu menggunakan sakelar fisik untuk lalu lintas jaringan penyimpanan.

Anda dapat menggunakan arsitektur ini dengan sejumlah simpul antara 1 hingga 16.

Meskipun tidak diberlakukan, Anda dapat menggunakan satu niat untuk semua jenis lalu lintas jaringan Anda (Manajemen, Komputasi, dan Penyimpanan)

Diagram berikut ini meringkas opsi konektivitas penyimpanan yang tersedia untuk Anda untuk berbagai penyebaran:

Langkah 3: Menentukan niat lalu lintas jaringan

Untuk Azure Stack HCI, semua penyebaran mengandalkan ATC Jaringan untuk konfigurasi jaringan host. Niat jaringan secara otomatis dikonfigurasi saat menyebarkan Azure Stack HCI melalui portal Azure. Untuk memahami selengkapnya tentang niat jaringan dan cara memecahkan masalah tersebut, lihat Perintah ATC jaringan umum.

Bagian ini menjelaskan implikasi keputusan desain Anda untuk niat lalu lintas jaringan, dan bagaimana pengaruhnya terhadap langkah kerangka kerja berikutnya. Untuk penyebaran cloud, Anda dapat memilih antara empat opsi untuk mengelompokkan lalu lintas jaringan Anda ke dalam satu atau beberapa niat. Opsi yang tersedia tergantung pada jumlah simpul di kluster Anda dan jenis konektivitas penyimpanan yang digunakan.

Opsi niat jaringan yang tersedia dibahas di bagian berikut.

Niat jaringan: Mengelompokkan semua lalu lintas

NETWORK ATC mengonfigurasi niat unik yang mencakup lalu lintas jaringan manajemen, komputasi, dan penyimpanan. Adaptor jaringan yang ditetapkan ke niat ini berbagi bandwidth dan throughput untuk semua lalu lintas jaringan.

Opsi ini memerlukan sakelar fisik untuk lalu lintas penyimpanan. Jika Anda memerlukan arsitektur tanpa switch, Anda tidak dapat menggunakan jenis niat ini. portal Azure secara otomatis memfilter opsi ini jika Anda memilih konfigurasi tanpa sakelar untuk konektivitas penyimpanan.
Setidaknya dua port adaptor jaringan disarankan untuk memastikan Ketersediaan Tinggi.
Setidaknya antarmuka jaringan 10 Gbps diperlukan untuk mendukung lalu lintas RDMA untuk penyimpanan.

Niat jaringan: Manajemen grup dan lalu lintas komputasi

ATC Jaringan mengonfigurasi dua niat. Niat pertama mencakup lalu lintas jaringan manajemen dan komputasi, dan niat kedua hanya mencakup lalu lintas jaringan penyimpanan. Setiap niat harus memiliki sekumpulan port adaptor jaringan yang berbeda.

Anda dapat menggunakan opsi ini untuk konektivitas penyimpanan yang dialihkan dan tanpa switch, jika:

Setidaknya dua port adaptor jaringan tersedia untuk setiap niat untuk memastikan ketersediaan tinggi.
Sakelar fisik digunakan untuk RDMA jika Anda menggunakan sakelar jaringan untuk penyimpanan.
Setidaknya antarmuka jaringan 10 Gbps diperlukan untuk mendukung lalu lintas RDMA untuk penyimpanan.

Niat jaringan: Mengelompokkan lalu lintas komputasi dan penyimpanan

ATC Jaringan mengonfigurasi dua niat. Niat pertama mencakup lalu lintas jaringan komputasi dan penyimpanan, dan niat kedua hanya mencakup lalu lintas jaringan manajemen. Setiap niat harus menggunakan sekumpulan port adaptor jaringan yang berbeda.

Opsi ini memerlukan sakelar fisik untuk lalu lintas penyimpanan karena port yang sama dibagikan dengan lalu lintas komputasi, yang memerlukan komunikasi utara-selatan. Jika Anda memerlukan konfigurasi tanpa switch, Anda tidak dapat menggunakan jenis niat ini. portal Azure secara otomatis memfilter opsi ini jika Anda memilih konfigurasi tanpa sakelar untuk konektivitas penyimpanan.
Opsi ini memerlukan sakelar fisik untuk RDMA.
Setidaknya dua port adaptor jaringan disarankan untuk memastikan ketersediaan tinggi.
Setidaknya antarmuka jaringan 10 Gbps direkomendasikan untuk niat komputasi dan penyimpanan untuk mendukung lalu lintas RDMA.
Bahkan ketika niat manajemen dinyatakan tanpa niat komputasi, Network ATC membuat sakelar virtual Switch Embedded Teaming (SET) untuk memberikan ketersediaan tinggi ke jaringan manajemen.

Niat jaringan: Konfigurasi kustom

Tentukan hingga tiga niat menggunakan konfigurasi Anda sendiri selama setidaknya salah satu niat mencakup lalu lintas manajemen. Kami menyarankan agar Anda menggunakan opsi ini saat Anda memerlukan niat komputasi kedua. Skenario untuk persyaratan niat komputasi kedua ini termasuk lalu lintas penyimpanan jarak jauh, lalu lintas cadangan VM, atau niat komputasi terpisah untuk jenis beban kerja yang berbeda.

Gunakan opsi ini untuk konektivitas penyimpanan yang dialihkan dan tanpa switch jika niat penyimpanan berbeda dari niat lain.
Gunakan opsi ini ketika niat komputasi lain diperlukan atau ketika Anda ingin sepenuhnya memisahkan jenis lalu lintas yang berbeda melalui adaptor jaringan yang berbeda.
Gunakan setidaknya dua port adaptor jaringan untuk setiap niat untuk memastikan ketersediaan tinggi.
Setidaknya antarmuka jaringan 10 Gbps direkomendasikan untuk niat komputasi dan penyimpanan untuk mendukung lalu lintas RDMA.

Diagram berikut ini meringkas opsi niat jaringan yang tersedia untuk Anda untuk berbagai penyebaran:

Langkah 4: Menentukan konektivitas jaringan manajemen dan penyimpanan

Dalam langkah ini, Anda menentukan ruang alamat subnet infrastruktur, bagaimana alamat ini ditetapkan ke kluster Anda, dan jika ada persyaratan proksi atau ID VLAN untuk simpul untuk konektivitas keluar ke internet dan layanan intranet lainnya seperti Sistem Nama Domain (DNS) atau Layanan Direktori Aktif.

Komponen subnet infrastruktur berikut harus direncanakan dan ditentukan sebelum Memulai penyebaran sehingga Anda dapat mengantisipasi persyaratan perutean, firewall, atau subnet apa pun.

Driver adaptor jaringan

Setelah menginstal sistem operasi, dan sebelum mengonfigurasi jaringan pada simpul, Anda harus memastikan bahwa adaptor jaringan Anda memiliki driver terbaru yang disediakan oleh OEM atau vendor antarmuka jaringan Anda. Kemampuan penting adaptor jaringan mungkin tidak muncul saat menggunakan driver Microsoft default.

Kumpulan IP manajemen

Saat melakukan penyebaran awal sistem Azure Stack HCI, Anda harus menentukan rentang IP berturut-turut untuk layanan infrastruktur yang disebarkan secara default.

Untuk memastikan rentang memiliki IP yang cukup untuk layanan infrastruktur saat ini dan yang akan datang, Anda harus menggunakan rentang setidaknya enam alamat IP yang tersedia berturut-turut. Alamat ini digunakan untuk - IP kluster, VM Azure Resource Bridge, dan komponennya.

Jika Anda mengantisipasi menjalankan layanan lain di jaringan infrastruktur, kami sarankan Anda menetapkan buffer TAMBAHAN IP infrastruktur ke kumpulan. Dimungkinkan untuk menambahkan kumpulan IP lain setelah penyebaran untuk jaringan infrastruktur menggunakan PowerShell jika ukuran kumpulan yang Anda rencanakan awalnya habis.

Kondisi berikut harus dipenuhi saat menentukan kumpulan IP Anda untuk subnet infrastruktur selama penyebaran:

#	Kondisi
1	Rentang IP harus menggunakan IP berturut-turut dan semua IP harus tersedia dalam rentang tersebut. Rentang IP ini tidak dapat diubah pasca penyebaran.
2	Rentang IP tidak boleh menyertakan IP manajemen node kluster tetapi harus berada di subnet yang sama dengan simpul Anda.
3	Gateway default yang ditentukan untuk kumpulan IP manajemen harus menyediakan konektivitas keluar ke internet.
4	Server DNS harus memastikan resolusi nama dengan Direktori Aktif dan internet.
5	IP manajemen memerlukan akses internet keluar.

ID VLAN Manajemen

Sebaiknya subnet manajemen kluster Azure HCI Anda menggunakan VLAN default, yang dalam banyak kasus dinyatakan sebagai ID VLAN 0. Namun, jika persyaratan jaringan Anda adalah menggunakan VLAN manajemen tertentu untuk jaringan infrastruktur Anda, itu harus dikonfigurasi pada adaptor jaringan fisik yang Anda rencanakan untuk digunakan untuk lalu lintas manajemen.

Jika Anda berencana menggunakan dua adaptor jaringan fisik untuk manajemen, Anda perlu mengatur VLAN pada kedua adaptor. Ini harus dilakukan sebagai bagian dari konfigurasi bootstrap server Anda, dan sebelum terdaftar ke Azure Arc, untuk memastikan Anda berhasil mendaftarkan simpul menggunakan VLAN ini.

Untuk mengatur ID VLAN pada adaptor jaringan fisik, gunakan perintah PowerShell berikut:

Contoh ini mengonfigurasi VLAN ID 44 pada adaptor NIC1jaringan fisik .

Set-NetAdapter -Name "NIC1" -VlanID 44

Setelah ID VLAN diatur dan IP simpul Anda dikonfigurasi pada adaptor jaringan fisik, orkestrator membaca nilai ID VLAN ini dari adaptor jaringan fisik yang digunakan untuk manajemen dan menyimpannya, sehingga dapat digunakan untuk VM Azure Resource Bridge atau VM infrastruktur lain yang diperlukan selama penyebaran. Tidak dimungkinkan untuk mengatur ID VLAN manajemen selama penyebaran cloud dari portal Azure karena ini membawa risiko merusak konektivitas antara simpul dan Azure jika VLAN sakelar fisik tidak dirutekan dengan benar.

ID VLAN Manajemen dengan sakelar virtual

Dalam beberapa skenario, ada persyaratan untuk membuat sakelar virtual sebelum penyebaran dimulai.

Catatan

Sebelum Anda membuat sakelar virtual, pastikan untuk mengaktifkan peran Hype-V. Untuk informasi selengkapnya, lihat Menginstal peran Windows yang diperlukan.

Jika konfigurasi sakelar virtual diperlukan dan Anda harus menggunakan ID VLAN tertentu, ikuti langkah-langkah berikut:

1. Buat sakelar virtual dengan konvensi penamaan yang direkomendasikan

Penyebaran Azure Stack HCI mengandalkan NETWORK ATC untuk membuat dan mengonfigurasi sakelar virtual dan adaptor jaringan virtual untuk niat manajemen, komputasi, dan penyimpanan. Secara default, ketika Network ATC membuat sakelar virtual untuk niat, ia menggunakan nama tertentu untuk sakelar virtual.

Sebaiknya beri nama sakelar virtual Anda dengan konvensi penamaan yang sama. Nama yang direkomendasikan untuk sakelar virtual adalah sebagai berikut:

"ConvergedSwitch($IntentName)", di mana $IntentName harus cocok dengan nama niat yang ditikkan ke portal selama penyebaran. String ini juga harus cocok dengan nama adaptor jaringan virtual yang digunakan untuk manajemen seperti yang dijelaskan pada langkah berikutnya.

Contoh berikut menunjukkan cara membuat sakelar virtual dengan PowerShell menggunakan konvensi penamaan yang direkomendasikan dengan $IntentName. Daftar nama adaptor jaringan adalah daftar adaptor jaringan fisik yang Anda rencanakan untuk digunakan untuk manajemen dan lalu lintas jaringan komputasi:

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

2. Mengonfigurasi adaptor jaringan virtual manajemen menggunakan konvensi penamaan ATC Jaringan yang diperlukan untuk semua simpul

Setelah sakelar virtual dan adaptor jaringan virtual manajemen terkait dibuat, pastikan bahwa nama adaptor jaringan mematuhi standar penamaan ATC Jaringan.

Secara khusus, nama adaptor jaringan virtual yang digunakan untuk lalu lintas manajemen harus menggunakan konvensi berikut:

Nama adaptor jaringan dan adaptor jaringan virtual harus menggunakan vManagement($intentname).
Nama ini peka huruf besar/kecil.
$Intentname dapat berupa string apa pun, tetapi harus nama yang sama dengan yang digunakan untuk sakelar virtual. Pastikan Anda menggunakan string yang sama ini di portal Azure saat menentukan Mgmt nama niat.

Untuk memperbarui nama adaptor jaringan virtual manajemen, gunakan perintah berikut:

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string “vEthernet” to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

3. Mengonfigurasi ID VLAN untuk mengelola adaptor jaringan virtual untuk semua simpul

Setelah sakelar virtual dan adaptor jaringan virtual manajemen dibuat, Anda dapat menentukan ID VLAN yang diperlukan untuk adaptor ini. Meskipun ada berbagai opsi untuk menetapkan ID VLAN ke adaptor jaringan virtual, satu-satunya opsi yang didukung adalah menggunakan Set-VMNetworkAdapterIsolation perintah .

Setelah ID VLAN yang diperlukan dikonfigurasi, Anda dapat menetapkan alamat IP dan gateway ke adaptor jaringan virtual manajemen untuk memvalidasi bahwa id tersebut memiliki konektivitas dengan simpul lain, DNS, Direktori Aktif, dan internet.

Contoh berikut menunjukkan cara mengonfigurasi adaptor jaringan virtual manajemen untuk menggunakan ID 8 VLAN, bukan default:

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

4. Mereferensikan adaptor jaringan fisik untuk niat manajemen selama penyebaran

Meskipun adaptor jaringan virtual yang baru dibuat menunjukkan sebagai tersedia saat menyebarkan melalui portal Azure, penting untuk diingat bahwa konfigurasi jaringan didasarkan pada ATC Jaringan. Ini berarti bahwa saat mengonfigurasi manajemen, atau niat manajemen dan komputasi, kita masih perlu memilih adaptor jaringan fisik yang digunakan untuk niat tersebut.

Catatan

Jangan pilih adaptor jaringan virtual untuk niat jaringan.

Logika yang sama berlaku untuk templat Azure Resource Manager. Anda harus menentukan adaptor jaringan fisik yang ingin Anda gunakan untuk niat jaringan dan tidak pernah adaptor jaringan virtual.

Berikut adalah pertimbangan ringkasan untuk ID VLAN:

#	Pertimbangan
1	ID VLAN harus ditentukan pada adaptor jaringan fisik untuk manajemen sebelum mendaftarkan server dengan Azure Arc.
2	Gunakan langkah-langkah tertentu saat sakelar virtual diperlukan sebelum mendaftarkan server ke Azure Arc.
3	ID VLAN manajemen dibawa dari konfigurasi host ke VM infrastruktur selama penyebaran.
4	Tidak ada parameter input ID VLAN untuk penyebaran portal Azure atau untuk penyebaran templat Resource Manager.

IP kustom untuk penyimpanan

Secara default, ATC jaringan akan secara otomatis menetapkan IP dan VLAN untuk penyimpanan dari tabel berikut:

Adaptor Penyimpanan	Alamat IP dan Subnet	VLAN
pNIC1	10.71.1.x	711
pNIC2	10.71.2.x	712
pNIC3	10.71.3.x	713

Namun, jika persyaratan penyebaran Anda tidak sesuai dengan IP dan VLAN default tersebut, Anda dapat menggunakan IP, subnet, dan VLAN Anda sendiri untuk penyimpanan. Fungsionalitas ini hanya tersedia saat menyebarkan kluster menggunakan templat ARM dan Anda harus menentukan parameter berikut dalam templat Anda.

enableStorageAutoIP: Parameter ini, ketika tidak ditentukan diatur ke true. Untuk mengaktifkan IP penyimpanan kustom selama penyebaran, parameter ini harus diatur ke false.
storageAdapterIPInfo: Parameter ini memiliki dependensi dengan parameter "enableStorageAutoIP" dan selalu diperlukan saat parameter IP otomatis penyimpanan diatur ke false. Dalam parameter "storageAdapterIPInfo" dalam templat ARM Anda, Anda juga perlu menentukan parameter "ipv4Address" dan "subnetMask" untuk setiap node dan adaptor jaringan dengan IP dan subnet mask Anda sendiri.
vlanId: Seperti yang dijelaskan di atas dalam tabel, parameter ini akan menggunakan VLAN default ATC Jaringan jika Anda tidak perlu mengubahnya. Namun, jika VLAN default tersebut tidak berfungsi di jaringan Anda, Anda dapat menentukan ID VLAN Anda sendiri untuk setiap jaringan penyimpanan Anda.

Templat ARM berikut mencakup contoh kluster HCI dua simpul dengan sakelar jaringan untuk penyimpanan, di mana IP penyimpanan disesuaikan 2 penyebaran Node dengan IP penyimpanan kustom

Penetapan IP node dan kluster

Untuk sistem Azure Stack HCI, Anda memiliki dua opsi untuk menetapkan IP untuk simpul server dan untuk IP kluster.

Protokol Protokol Konfigurasi Host Statis dan Dinamis (DHCP) didukung.
Penetapan IP node yang tepat adalah kunci untuk manajemen siklus hidup kluster. Tentukan antara opsi statis dan DHCP sebelum Anda mendaftarkan simpul di Azure Arc.
VM dan layanan infrastruktur seperti Arc Resource Bridge dan Network Controller tetap menggunakan IP statis dari kumpulan IP manajemen. Itu menyiratkan bahwa bahkan jika Anda memutuskan untuk menggunakan DHCP untuk menetapkan IP ke node Dan IP kluster Anda, kumpulan IP manajemen masih diperlukan.

Bagian berikut membahas implikasi dari setiap opsi.

Penetapan IP statis

Jika IP statis digunakan untuk simpul, kumpulan IP manajemen digunakan untuk mendapatkan IP yang tersedia dan menetapkannya ke IP kluster secara otomatis selama penyebaran.

Penting untuk menggunakan IP manajemen untuk simpul yang bukan bagian dari rentang IP yang ditentukan untuk kumpulan IP manajemen. IP simpul server harus berada pada subnet yang sama dari rentang IP yang ditentukan.

Kami menyarankan agar Anda hanya menetapkan satu IP manajemen untuk gateway default dan untuk server DNS yang dikonfigurasi untuk semua adaptor jaringan fisik simpul. Ini memastikan bahwa IP tidak berubah setelah niat jaringan manajemen dibuat. Ini juga memastikan bahwa simpul menyimpan konektivitas keluar mereka selama proses penyebaran, termasuk selama pendaftaran Azure Arc.

Untuk menghindari masalah perutean dan mengidentifikasi IP mana yang akan digunakan untuk konektivitas keluar dan pendaftaran Arc, portal Azure memvalidasi jika ada lebih dari satu gateway default yang dikonfigurasi.

Jika sakelar virtual dan adaptor jaringan virtual manajemen dibuat selama konfigurasi OS, IP manajemen untuk simpul harus ditetapkan ke adaptor jaringan virtual tersebut.

Penetapan IP DHCP

Jika IP untuk simpul diperoleh dari server DHCP, IP dinamis juga digunakan untuk IP kluster. VM dan layanan infrastruktur masih memerlukan IP statis, dan itu menyiratkan bahwa rentang alamat kumpulan IP manajemen harus dikecualikan dari cakupan DHCP yang digunakan untuk simpul dan IP kluster.

Misalnya, jika rentang IP manajemen didefinisikan sebagai 192.168.1.20/24 hingga 192.168.1.30/24 untuk IP statis infrastruktur, Cakupan DHCP yang ditentukan untuk subnet 192.168.1.0/24 harus memiliki pengecualian yang setara dengan kumpulan IP manajemen untuk menghindari konflik IP dengan layanan infrastruktur. Kami juga menyarankan agar Anda menggunakan reservasi DHCP untuk IP simpul.

Proses menentukan IP manajemen setelah membuat niat manajemen melibatkan penggunaan alamat MAC adaptor jaringan fisik pertama yang dipilih untuk niat jaringan. Alamat MAC ini kemudian ditetapkan ke adaptor jaringan virtual yang dibuat untuk tujuan manajemen. Ini berarti bahwa alamat IP yang diperoleh adaptor jaringan fisik pertama dari server DHCP adalah alamat IP yang sama dengan yang digunakan adaptor jaringan virtual sebagai IP manajemen. Oleh karena itu, penting untuk membuat reservasi DHCP untuk IP node.

Logika validasi jaringan yang digunakan selama penyebaran Cloud akan gagal jika mendeteksi beberapa antarmuka jaringan fisik yang memiliki gateway default dalam konfigurasinya. Jika Anda perlu menggunakan DHCP untuk penetapan IP host, Anda perlu membuat sakelar virtual SET (switch embedded teaming) dan adaptor jaringan virtual manajemen seperti yang dijelaskan di atas, jadi hanya adaptor jaringan virtual manajemen yang memperoleh alamat IP dari server DHCP.

Pertimbangan IP node kluster

Berikut adalah pertimbangan ringkasan untuk alamat IP:

#	Pertimbangan
1	IP node harus berada pada subnet yang sama dari rentang kumpulan IP manajemen yang ditentukan terlepas dari apakah itu alamat statis atau dinamis.
2	Kumpulan IP manajemen tidak boleh menyertakan IP simpul. Gunakan pengecualian DHCP saat penetapan IP dinamis digunakan.
3	Gunakan reservasi DHCP untuk simpul sebanyak mungkin.
4	Alamat DHCP hanya didukung untuk IP node dan IP kluster. Layanan infrastruktur menggunakan IP statis dari kumpulan manajemen.
5	Alamat MAC dari adaptor jaringan fisik pertama ditetapkan ke adaptor jaringan virtual manajemen setelah niat jaringan manajemen dibuat.

Persyaratan proksi

Proksi kemungkinan besar diperlukan untuk mengakses internet dalam infrastruktur lokal Anda. Azure Stack HCI hanya mendukung konfigurasi proksi yang tidak diautentikasi. Mengingat bahwa akses internet diperlukan untuk mendaftarkan simpul di Azure Arc, konfigurasi proksi harus diatur sebagai bagian dari konfigurasi OS sebelum simpul server terdaftar. Untuk informasi selengkapnya, lihat Mengonfigurasi pengaturan proksi.

OS Azure Stack HCI memiliki tiga layanan berbeda (WinInet, WinHTTP, dan variabel lingkungan) yang memerlukan konfigurasi proksi yang sama untuk memastikan semua komponen OS dapat mengakses internet. Konfigurasi proksi yang sama yang digunakan untuk simpul secara otomatis dibawa ke Arc Resource Bridge VM dan AKS, memastikan bahwa mereka memiliki akses internet selama penyebaran.

Berikut adalah pertimbangan ringkasan untuk konfigurasi proksi:

#	Pertimbangan
1	Konfigurasi proksi harus diselesaikan sebelum mendaftarkan simpul di Azure Arc.
2	Konfigurasi proksi yang sama harus diterapkan untuk variabel WinINET, WinHTTP, dan lingkungan.
3	Pemeriksa Lingkungan memastikan bahwa konfigurasi proksi konsisten di semua komponen proksi.
4	Konfigurasi proksi Arc Resource Bridge VM dan AKS secara otomatis dilakukan oleh orkestrator selama penyebaran.
5	Hanya proksi yang tidak diautentikasi yang didukung.

Persyaratan firewall

Saat ini Anda diharuskan membuka beberapa titik akhir internet di firewall Anda untuk memastikan bahwa Azure Stack HCI dan komponennya dapat berhasil terhubung ke sana. Untuk daftar terperinci titik akhir yang diperlukan, lihat Persyaratan firewall.

Konfigurasi firewall harus dilakukan sebelum mendaftarkan simpul di Azure Arc. Anda dapat menggunakan pemeriksa lingkungan versi mandiri untuk memvalidasi bahwa firewall Anda tidak memblokir lalu lintas yang dikirim ke titik akhir ini. Untuk informasi selengkapnya, lihat Pemeriksa Lingkungan Azure Stack HCI untuk menilai kesiapan penyebaran untuk Azure Stack HCI.

Berikut adalah pertimbangan ringkasan untuk firewall:

#	Pertimbangan
1	Konfigurasi firewall harus dilakukan sebelum mendaftarkan simpul di Azure Arc.
2	Pemeriksa Lingkungan dalam mode mandiri dapat digunakan untuk memvalidasi konfigurasi firewall.

Langkah 5: Menentukan konfigurasi adaptor jaringan

Adaptor jaringan memenuhi syarat berdasarkan jenis lalu lintas jaringan (manajemen, komputasi, dan penyimpanan) yang digunakan. Saat Anda meninjau Katalog Windows Server, sertifikasi Windows Server 2022 menunjukkan lalu lintas jaringan mana yang memenuhi syarat adaptor.

Sebelum membeli server untuk Azure Stack HCI, Anda harus memiliki setidaknya satu adaptor yang memenuhi syarat untuk manajemen, komputasi, dan penyimpanan karena ketiga jenis lalu lintas diperlukan di Azure Stack HCI. Penyebaran cloud bergantung pada ATC Jaringan untuk mengonfigurasi adaptor jaringan untuk jenis lalu lintas yang sesuai, sehingga penting untuk menggunakan adaptor jaringan yang didukung.

Nilai default yang digunakan oleh NETWORK ATC didokumenkan dalam pengaturan jaringan Kluster. Kami menyarankan agar Anda menggunakan nilai default. Dengan demikian, opsi berikut dapat diambil alih menggunakan templat portal Azure atau Resource Manager jika diperlukan:

VLAN Penyimpanan: Atur nilai ini ke VLAN yang diperlukan untuk penyimpanan.
Paket Jumbo: Mendefinisikan ukuran paket jumbo.
Network Direct: Atur nilai ini ke false jika Anda ingin menonaktifkan RDMA untuk adaptor jaringan Anda.
Teknologi Langsung Jaringan: Atur nilai ini ke RoCEv2 atau iWarp.
Traffic Priorities Datacenter Bridging (DCB): Tetapkan prioritas yang sesuai dengan kebutuhan Anda. Kami sangat menyarankan Anda menggunakan nilai DCB default karena ini divalidasi oleh Microsoft dan pelanggan.

Berikut adalah pertimbangan ringkasan untuk konfigurasi adaptor jaringan:

#	Pertimbangan
1	Gunakan konfigurasi default sebanyak mungkin.
2	Sakelar fisik harus dikonfigurasi sesuai dengan konfigurasi adaptor jaringan. Lihat Persyaratan jaringan fisik untuk Azure Stack HCI.
3	Pastikan adaptor jaringan Anda didukung untuk Azure Stack HCI menggunakan Katalog Windows Server.
4	Saat menerima default, Network ATC secara otomatis mengonfigurasi IP adaptor jaringan penyimpanan dan VLAN. Ini dikenal sebagai konfigurasi IP Otomatis Penyimpanan. Dalam beberapa kasus, IP Otomatis Penyimpanan tidak didukung dan Anda perlu mendeklarasikan setiap IP adaptor jaringan penyimpanan menggunakan templat Resource Manager.

Langkah berikutnya

Tentang Azure Stack HCI, penyebaran versi 23H2.

Bagikan melalui