Persyaratan jaringan fisik untuk Azure Stack HCI
Berlaku untuk: Azure Stack HCI, versi 23H2 dan 22H2
Artikel ini membahas pertimbangan dan persyaratan jaringan fisik (struktur dasar) untuk Azure Stack HCI, terutama untuk switch jaringan.
Catatan
Persyaratan untuk versi Azure Stack HCI di masa mendatang dapat berubah.
Switch jaringan untuk Azure Stack HCI
Microsoft menguji Azure Stack HCI berdasarkan standar dan protokol yang diidentifikasi di bagian Persyaratan switch jaringan di bawah ini. Meskipun Microsoft tidak mensertifikasi switch jaringan, kami bekerja sama dengan vendor untuk mengidentifikasi perangkat yang mendukung persyaratan Azure Stack HCI.
Penting
Meskipun switch jaringan lain yang menggunakan teknologi dan protokol yang tidak tercantum di sini dapat berfungsi, Microsoft tidak dapat menjamin switch tersebut akan bekerja dengan Azure Stack HCI dan kami mungkin tidak dapat membantu memecahkan masalah yang terjadi karenanya.
Saat membeli sakelar jaringan, hubungi vendor sakelar Anda dan pastikan bahwa perangkat memenuhi persyaratan Azure Stack HCI untuk jenis peran yang Anda tentukan. Vendor berikut (sesuai urutan abjad) telah mengonfirmasi bahwa switch mereka mendukung persyaratan Azure Stack HCI:
Klik tab vendor untuk melihat sakelar yang divalidasi untuk setiap jenis lalu lintas Azure Stack HCI. Klasifikasi jaringan ini dapat ditemukan di sini.
Penting
Kami memperbarui daftar ini seperti yang kami informasikan tentang perubahan oleh vendor sakelar jaringan.
Jika switch Anda tidak disertakan, hubungi vendor switch Anda untuk memastikan bahwa model switch Anda dan versi sistem operasi switch mendukung persyaratan di bagian berikutnya.
Persyaratan switch jaringan
Bagian ini mencantumkan standar industri yang wajib untuk peran tertentu dari sakelar jaringan yang digunakan dalam penyebaran Azure Stack HCI. Standar ini membantu memastikan komunikasi yang andal antara node dalam penyebaran kluster Azure Stack HCI.
Catatan
Adapter jaringan yang digunakan untuk komputasi, penyimpanan, dan lalu lintas manajemen memerlukan Ethernet. Untuk informasi selengkapnya, lihat Persyaratan jaringan host.
Berikut adalah standar dan spesifikasi IEEE yang wajib:
Persyaratan Peran 23H2
| Persyaratan | Manajemen | Penyimpanan | Komputasi (Standar) | Komputasi (SDN) |
|---|---|---|---|---|
| LAN Virtual | ✓ | ✓ | ✓ | ✓ |
| Kontrol Alur Prioritas | ✓ | |||
| Pemilihan Transmisi Yang Ditingkatkan | ✓ | |||
| LLDP Port VLAN ID | ✓ | |||
| Nama VLAN LLDP | ✓ | ✓ | ✓ | |
| Agregasi Tautan LLDP | ✓ | ✓ | ✓ | ✓ |
| Konfigurasi ETS LLDP | ✓ | |||
| Rekomendasi ETS LLDP | ✓ | |||
| Konfigurasi PFC LLDP | ✓ | |||
| Ukuran Bingkai Maksimum LLDP | ✓ | ✓ | ✓ | ✓ |
| Unit Transmisi Maksimum | ✓ | |||
| Protokol Gateway Batas | ✓ | |||
| Agen Relay DHCP | ✓ |
Catatan
RDMA tamu memerlukan Komputasi (Standar) dan Penyimpanan.
Standar: IEEE 802.1Q
Switch Ethernet harus sesuai dengan spesifikasi IEEE 802.1Q yang mendefinisikan VLAN. VLAN diperlukan untuk beberapa aspek Azure Stack HCI dan diperlukan dalam semua skenario.
Standar: IEEE 802.1Qbb
Sakelar Ethernet yang digunakan untuk lalu lintas penyimpanan Azure Stack HCI harus mematuhi spesifikasi IEEE 802.1Qbb yang menentukan Priority Flow Control (PFC). PFC diperlukan di mana Data Center Bridging (DCB) digunakan. Karena DCB dapat digunakan dalam skenario RDMA RoCE dan iWARP, 802.1Qbb diperlukan dalam semua skenario. Minimal tiga prioritas Class of Service (CoS) diperlukan tanpa menurunkan kemampuan switch atau kecepatan port. Setidaknya salah satu kelas lalu lintas ini harus memberikan komunikasi yang lossless.
Standar: IEEE 802.1Qaz
Sakelar Ethernet yang digunakan untuk lalu lintas penyimpanan Azure Stack HCI harus mematuhi spesifikasi IEEE 802.1Qaz yang menentukan Enhanced Transmission Select (ETS). ETS diperlukan di mana DCB digunakan. Karena DCB dapat digunakan dalam skenario RDMA ROCE dan iWARP, 802.1Qaz diperlukan dalam semua skenario.
Minimal tiga prioritas CoS diperlukan tanpa menurunkan kemampuan switch atau kecepatan port. Selain itu, jika perangkat Anda memungkinkan penetapan rasio QoS masuk, sebaiknya Anda tidak mengonfigurasi rasio masuk atau mengonfigurasinya dengan nilai yang sama persis dengan rasio keluar (ETS).
Catatan
Infrastruktur dengan konvergensi tinggi memiliki ketergantungan yang tinggi pada komunikasi Timur-Barat Lapisan-2 dalam rak yang sama dan karena itu membutuhkan ETS. Microsoft tidak menguji Azure Stack HCI dengan Differentiated Services Code Point (DSCP).
Standar: IEEE 802.1AB
Switch Ethernet harus sesuai dengan spesifikasi IEEE 802.1AB yang mendefinisikan Link Layer Discovery Protocol (LLDP). LLDP diperlukan untuk Azure Stack HCI dan memungkinkan pemecahan masalah konfigurasi jaringan fisik.
Konfigurasi Type-Length-Values (TLV) LLDP harus diaktifkan secara dinamis. Switch tidak memerlukan konfigurasi tambahan di luar pengaktifan TLV tertentu. Misalnya, mengaktifkan Subtipe 3 802.1 akan secara otomatis mengiklankan semua VLAN yang tersedia di port switch.
Persyaratan TLV kustom
LLDP memungkinkan organisasi untuk mendefinisikan dan menyandikan TLV kustom mereka sendiri. Hal ini disebut TLV Khusus Organisasi. Semua TLV Khusus Organisasi dimulai dengan Tipe TLV LLDP bernilai 127. Tabel di bawah ini memperlihatkan subjenis Organizationally Specific Custom TLV (TLV Type 127) mana yang diperlukan.
| Organisasi | Subtipe TLV |
|---|---|
| IEEE 802.1 | ID Port VLAN (Subjenis = 1) |
| IEEE 802.1 | Nama VLAN (Subtipe = 3) Minimal 10 VLAN |
| IEEE 802.1 | Agregasi Tautan (Subjenis = 7) |
| IEEE 802.1 | Konfigurasi ETS (Subjenis = 9) |
| IEEE 802.1 | Rekomendasi ETS (Subjenis = A) |
| IEEE 802.1 | Konfigurasi PFC (Subjenis = B) |
| IEEE 802.3 | Ukuran Bingkai Maksimum (Subtipe = 4) |
Unit Transmisi Maksimum
Unit transmisi maksimum (MTU) merupakan bingkai ukuran atau paket terbesar yang dapat ditransmisikan pada seluruh tautan data. Rentang 1514 - 9174 diperlukan bagi enkapsulasi SDN.
Protokol Gateway Batas
Sakelar Ethernet yang digunakan untuk lalu lintas komputasi Azure Stack HCI SDN harus mendukung Border Gateway Protocol (BGP). BGP adalah protokol perutean standar yang digunakan untuk bertukar informasi perutean dan keterjangkauan antara dua jaringan atau lebih. Rute akan ditambahkan secara otomatis pada tabel rute seluruh subnet dengan penyebaran BGP yang diaktifkan. Hal ini diperlukan untuk mengaktifkan beban kerja penyewa dengan SDN serta peering dinamis. RFC 4271: Protokol Gateway Batas 4
Agen Relay DHCP
Sakelar Ethernet yang digunakan untuk lalu lintas manajemen Azure Stack HCI harus mendukung agen relai DHCP. Agen relay DHCP adalah host TCP/IP apa pun yang digunakan untuk meneruskan permintaan serta balasan antara server DHCP dan klien ketika server ada di jaringan yang berbeda. Hal ini diperlukan bagi layanan boot PXE. RFC 3046: DHCPv4 atau RFC 6148: DHCPv4
Lalu lintas jaringan dan arsitektur
Bagian ini ditujukan terutama untuk administrator jaringan.
Azure Stack HCI dapat berfungsi dalam berbagai arsitektur pusat data termasuk 2-tingkatan (Spine-Leaf) dan 3-tingkatan (Core-Aggregation-Access). Bagian ini lebih mengacu pada konsep dari topologi Spine-Leaf yang umum digunakan dengan beban kerja dalam infrastruktur dengan konvergensi tinggi seperti Azure Stack HCI.
Model jaringan
Lalu lintas jaringan dapat diklasifikasikan berdasarkan arahnya. Lingkungan tradisional Storage Area Network (SAN) cenderung Utara-Selatan di mana lalu lintas mengalir dari tingkat komputasi ke tingkat penyimpanan di seluruh batas Lapisan-3 (IP). Infrastruktur dengan konvergensi tinggi lebih cenderung Timur-Barat di mana sebagian besar lalu lintas tetap dalam batas Lapisan-2 (VLAN).
Penting
Sebaiknya semua node kluster di situs secara fisik terletak di rak yang sama dan terhubung ke switch top-of-rack (ToR) yang sama.
Catatan
Fungsionalitas kluster yang direntangkan hanya tersedia di Azure Stack HCI, versi 22H2.
Lalu lintas Utara-Selatan untuk Azure Stack HCI
Lalu lintas Utara-Selatan memiliki karakteristik sebagai berikut:
- Arus lalu lintas dari sakelar ToR ke tulang belakang atau dari tulang belakang ke sakelar ToR.
- Lalu lintas meninggalkan rak fisik atau melewati batas Lapisan-3 (IP).
- Termasuk manajemen (PowerShell, Windows Admin Center), komputasi (VM), dan lalu lintas kluster yang direntangkan antar situs.
- Menggunakan sakelar Ethernet untuk konektivitas ke jaringan fisik.
Lalu lintas Timur-Barat untuk Azure Stack HCI
Lalu lintas Timur-Barat memiliki karakteristik sebagai berikut:
- Lalu lintas tetap berada dalam sakelar ToR dan batas Lapisan-2 (VLAN).
- Termasuk lalu lintas penyimpanan atau lalu lintas Migrasi Langsung antara simpul dalam kluster yang sama dan (jika menggunakan kluster yang direntangkan) dalam situs yang sama.
- Dapat menggunakan switch Ethernet (dengan switch) atau koneksi langsung (tanpa switch), seperti yang dijelaskan dalam dua bagian berikutnya.
Menggunakan switch
Lalu lintas Utara-Selatan membutuhkan penggunaan switch. Selain menggunakan switch Ethernet yang mendukung protokol yang diperlukan untuk Azure Stack HCI, aspek yang paling penting adalah ukuran yang tepat dari struktur dasar jaringan.
Sangat penting untuk memahami bandwidth struktur dasar "non-blok" yang dapat didukung oleh switch Ethernet Anda dan bahwa Anda meminimalkan (atau sebaiknya menghapus) langganan berlebih jaringan.
Titik kemacetan umum dan langganan berlebih, seperti Multi-Chassis Link Aggregation Group yang digunakan untuk redundansi jalur, dapat dihilangkan melalui penggunaan subnet dan VLAN yang tepat. Lihat juga Persyaratan jaringan host.
Hubungi vendor jaringan atau tim dukungan jaringan Anda untuk memastikan ukuran switch jaringan Anda telah diatur dengan benar untuk beban kerja yang ingin Anda jalankan.
Menggunakan mode tanpa switch
Azure Stack HCI mendukung koneksi tanpa switch (langsung) untuk lalu lintas Timur-Barat untuk semua ukuran kluster selama setiap node dalam kluster memiliki koneksi redundan ke setiap node di kluster. Ini disebut koneksi "full-mesh".
| Pasangan antarmuka | Subnet | VLAN |
|---|---|---|
| vNIC host Mgmt | Khusus pelanggan | Khusus pelanggan |
| SMB01 | 192.168.71.x/24 | 711 |
| SMB02 | 192.168.72.x/24 | 712 |
| SMB03 | 192.168.73.x/24 | 713 |
Catatan
Manfaat penyebaran tanpa switch akan berkurang dengan kluster yang lebih besar dari tiga node karena tambahan jumlah adapter jaringan yang diperlukan.
Keuntungan koneksi tanpa switch
- Tidak perlu membeli switch untuk lalu lintas Timur-Barat. Switch diperlukan untuk lalu lintas Utara-Selatan. Hal ini dapat mengakibatkan biaya belanja modal (CAPEX) yang lebih rendah tetapi tergantung jumlah node dalam kluster.
- Karena tidak ada switch, konfigurasi terbatas pada host, sehingga dapat mengurangi potensi jumlah langkah konfigurasi yang diperlukan. Nilai ini berkurang saat ukuran kluster meningkat.
Kelemahan koneksi tanpa switch
- Diperlukan lebih banyak perencanaan untuk skema pengalamatan IP dan subnet.
- Hanya menyediakan akses penyimpanan lokal. Lalu lintas manajemen, lalu lintas VM, dan lalu lintas lainnya yang membutuhkan akses Utara-Selatan tidak dapat menggunakan adapter ini.
- Dengan semakin bertambahnya jumlah node dalam kluster, biaya adapter jaringan dapat melebihi biaya penggunaan switch jaringan.
- Tidak melakukan penskalaan dengan baik di atas kluster tiga node. Lebih banyak node memerlukan kabel dan konfigurasi tambahan yang dapat melampaui kompleksitas menggunakan switch.
- Ekspansi kluster rumit, membutuhkan perubahan konfigurasi perangkat keras dan perangkat lunak.
Langkah berikutnya
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk