Pertimbangan perencanaan integrasi pusat data untuk sistem terintegrasi Azure Stack Hub
Jika Anda tertarik dengan sistem terintegrasi Azure Stack Hub, Anda harus terlebih dahulu memahami beberapa pertimbangan perencanaan utama seputar penyebaran, dan bagaimana sistem tersebut bisa sesuai dengan pusat data Anda. Artikel ini memberikan gambaran umum tingkat tinggi tentang pertimbangan ini untuk membantu Anda membuat keputusan penting terkait infrastruktur untuk sistem terintegrasi Azure Stack Hub Anda. Pemahaman tentang pertimbangan ini membantu saat bekerja dengan vendor perangkat keras OEM Anda saat mereka menyebarkan Azure Stack Hub ke pusat data Anda.
Catatan
Sistem terintegrasi Azure Stack Hub hanya dapat dibeli dari vendor perangkat keras resmi.
Untuk menyebarkan Azure Stack Hub, Anda perlu memberikan informasi perencanaan kepada penyedia solusi Anda sebelum penyebaran dimulai agar proses berjalan dengan cepat dan lancar. Informasi yang dibutuhkan berkisar di seluruh jaringan, keamanan, dan informasi identitas dengan banyak keputusan penting yang mungkin memerlukan pengetahuan dari berbagai bidang dan pengambil keputusan. Anda memerlukan orang-orang dari berbagai tim di organisasi Anda untuk memastikan bahwa Anda sudah memiliki semua informasi yang diperlukan sebelum penyebaran. Berdiskusi dengan vendor perangkat keras Anda sambil mengumpulkan informasi ini dapat membantu karena mereka mungkin memiliki saran yang bermanfaat.
Saat meneliti dan mengumpulkan informasi yang diperlukan, Anda mungkin perlu membuat beberapa perubahan konfigurasi pra-penyebaran ke lingkungan jaringan Anda. Perubahan ini dapat mencakup pemesanan ruang alamat IP untuk solusi Azure Stack Hub serta mengonfigurasi router, sakelar, dan firewall Anda untuk mempersiapkan konektivitas ke pengalih solusi Azure Stack Hub yang baru. Pastikan ahli bidang studi sudah disiapkan untuk membantu Anda dengan perencanaan Anda.
Pertimbangan perencanaan kapasitas
Saat mengevaluasi solusi Azure Stack Hub untuk akuisisi, Anda membuat pilihan konfigurasi perangkat keras yang berdampak langsung terhadap kapasitas keseluruhan solusi Azure Stack Hub. Ini termasuk pilihan klasik CPU, kepadatan memori, konfigurasi penyimpanan, dan skala solusi keseluruhan (misalnya, jumlah server). Tidak seperti solusi virtualisasi tradisional, aritmatika sederhana dari komponen-komponen ini yang digunakan untuk menentukan kapasitas yang dapat digunakan tidak berlaku. Alasan pertama adalah karena Azure Stack Hub dirancang untuk menjadi host komponen infrastruktur atau manajemen dalam solusi itu sendiri. Alasan kedua adalah karena beberapa kapasitas solusi dicadangkan untuk mendukung ketahanan dengan memperbarui perangkat lunak solusi dengan cara yang meminimalkan gangguan beban kerja penyewa.
Spreadsheet perencana kapasitas Azure Stack Hub membantu Anda membuat keputusan yang tepat untuk merencanakan kapasitas dengan dua cara. Yang pertama adalah dengan memilih penawaran perangkat keras dan mencoba menyesuaikan berbagai kombinasi sumber daya. Yang kedua adalah dengan menentukan beban kerja yang dimaksudkan untuk dijalankan oleh Azure Stack Hub untuk menampilkan SKU perangkat keras yang tersedia yang dapat mendukungnya. Akhirnya, spreadsheet dimaksudkan sebagai panduan untuk membantu dalam membuat keputusan yang terkait dengan perencanaan dan konfigurasi Azure Stack Hub.
Spreadsheet tidak dimaksudkan sebagai pengganti penyelidikan dan analisis Anda sendiri. Microsoft tidak membuat pernyataan atau jaminan, tersurat maupun tersirat, sehubungan dengan informasi yang diberikan dalam spreadsheet.
Pertimbangan manajemen
Azure Stack Hub adalah sistem tertutup, di mana infrastrukturnya dikunci baik dari perspektif izin dan jaringan. Daftar kontrol akses (ACL) jaringan diterapkan untuk memblokir semua lalu lintas masuk yang tidak sah dan semua komunikasi yang tidak perlu antara komponen infrastruktur. Sistem ini mencegah pengguna yang tidak sah untuk mengakses sistem.
Untuk manajemen dan operasi harian, tidak ada akses admin yang tidak terbatas ke infrastruktur. Operator Azure Stack Hub harus mengelola sistem melalui portal administrator atau melalui Azure Resource Manager (melalui PowerShell atau REST API). Tidak ada akses ke sistem oleh alat manajemen lain seperti Hyper-V Manager atau Failover Cluster Manager. Untuk membantu melindungi sistem, perangkat lunak pihak ketiga (misalnya, agen) tidak dapat dipasang di dalam komponen infrastruktur Azure Stack Hub. Interoperabilitas dengan perangkat lunak manajemen dan keamanan eksternal terjadi melalui PowerShell atau REST API.
Hubungi Dukungan Microsoft saat Anda memerlukan tingkat akses yang lebih tinggi untuk memecahkan masalah yang tidak diselesaikan melalui langkah mediasi peringatan. Melalui dukungan, terdapat metode untuk menyediakan akses admin penuh sementara ke sistem untuk operasi tingkat lanjut.
Pertimbangan identitas
Memilih idP
Anda harus mempertimbangkan IdP mana yang ingin Anda gunakan untuk penyebaran Azure Stack Hub, baik ID Microsoft Entra atau LAYANAN Federasi Direktori Aktif. Anda tidak dapat mengganti penyedia identitas setelah penyebaran tanpa penyebaran ulang sistem penuh. Jika Anda tidak memiliki akun Microsoft Entra dan menggunakan akun yang diberikan kepada Anda oleh Penyedia Solusi Cloud, dan jika Anda memutuskan untuk beralih penyedia dan menggunakan akun Microsoft Entra yang berbeda, Anda harus menghubungi penyedia solusi Anda untuk menyebarkan ulang solusi untuk Anda dengan biaya Anda.
Pilihan IdP Anda tidak berpengaruh pada mesin virtual (VM) penyewa, sistem identitas, akun yang mereka gunakan, atau apakah mereka dapat bergabung dengan domain Active Directory, dan sebagainya. Hal-hal ini terpisah.
Anda dapat menyebarkan beberapa sistem Azure Stack Hub dengan penyewa Microsoft Entra atau Direktori Aktif yang sama.
Integrasi Active Directory Federation Services dan Graph
Jika Anda memilih untuk menyebarkan Azure Stack Hub menggunakan Active Directory Federation Services sebagai IdP, Anda harus mengintegrasikan instans Active Directory Federation Services di Azure Stack Hub dengan instans Active Directory Federation Services yang ada melalui kepercayaan federasi. Integrasi ini memungkinkan identitas di hutan Active Directory yang ada untuk mengautentikasi dengan sumber daya di Azure Stack Hub.
Anda juga dapat mengintegrasikan layanan Grafik di Azure Stack Hub dengan Active Directory yang ada. Integrasi ini memungkinkan Anda mengelola Kontrol Akses Berbasis Peran (RBAC) di Azure Stack Hub. Saat akses ke sumber daya didelegasikan, komponen Graph mencari akun pengguna di forest Active Directory yang ada menggunakan protokol LDAP.
Diagram berikut menunjukkan arus lalu lintas AD FS dan Grafik terintegrasi.
Model lisensi
Anda harus memutuskan model lisensi mana yang ingin Anda gunakan. Opsi yang tersedia bergantung pada apakah Anda menyebarkan Azure Stack Hub yang terhubung ke internet:
- Untuk penyebaran tersambung, Anda dapat memilih lisensi bayar sesuai penggunaan atau berbasis kapasitas. Bayar sesuai penggunaan memerlukan koneksi ke Azure untuk melaporkan penggunaan, yang kemudian ditagih melalui perdagangan Azure.
- Hanya lisensi berbasis kapasitas yang didukung jika Anda menyebarkan terputus dari internet.
Untuk informasi selengkapnya tentang model lisensi, lihat Pengemasan dan harga Microsoft Azure Stack Hub.
Keputusan penamaan
Anda harus memikirkan cara Anda merencanakan namespace layanan Azure Stack Hub Anda, terutama nama wilayah dan nama domain eksternal. Nama domain yang sepenuhnya memenuhi syarat (FQDN) eksternal dari penyebaran Azure Stack Hub Anda untuk titik akhir yang tersedia bagi publik adalah kombinasi dari dua nama ini: <wilayah>.<fqdn>. Misalnya, east.cloud.fabrikam.com. Dalam contoh ini, portal Azure Stack Hub akan tersedia di URL berikut:
https://portal.east.cloud.fabrikam.comhttps://adminportal.east.cloud.fabrikam.com
Penting
Nama wilayah yang Anda pilih untuk penyebaran Azure Stack Hub harus unik dan akan muncul di alamat portal.
Tabel berikut merangkum keputusan penamaan domain ini.
| Nama | Deskripsi |
|---|---|
| Nama wilayah | Nama wilayah Azure Stack Hub pertama Anda. Nama ini digunakan sebagai bagian dari FQDN untuk alamat IP virtual publik (VIP) yang dikelola Azure Stack Hub. Biasanya, nama wilayah akan menjadi pengidentifikasi lokasi fisik seperti lokasi pusat data. Nama wilayah hanya boleh terdiri dari huruf dan angka antara 0-9. Tidak ada karakter khusus (seperti -, #, dan seterusnya) yang diperbolehkan. |
| Nama domain eksternal | Nama zona Sistem Nama Domain (DNS) untuk titik akhir dengan VIP eksternal. Digunakan di FQDN untuk VIP publik ini. |
| Nama domain privat (internal) | Nama domain (dan zona DNS internal) yang dibuat di Azure Stack Hub untuk manajemen infrastruktur. |
Persyaratan sertifikat
Untuk penyebaran, Anda harus memberikan sertifikat Secure Sockets Layer (SSL) untuk titik akhir yang dapat diakses publik. Pada tingkat tinggi, sertifikat memiliki persyaratan berikut:
- Anda dapat menggunakan satu sertifikat karakter kartubebas atau Anda dapat menggunakan serangkaian sertifikat khusus, lalu menggunakan karakter pengganti hanya untuk titik akhir seperti penyimpanan dan Key Vault.
- Sertifikat dapat diterbitkan oleh otoritas sertifikat (CA) tepercaya publik atau CA yang dikelola pelanggan.
Untuk informasi selengkapnya tentang sertifikat PKI apa yang diperlukan untuk menyebarkan Azure Stack Hub, dan cara mendapatkannya, lihat, Persyaratan sertifikat Infrastruktur Kunci Umum Azure Stack Hub.
Penting
Informasi sertifikat PKI yang diberikan harus digunakan sebagai pedoman umum. Sebelum Anda memperoleh sertifikat PKI apa pun untuk Azure Stack Hub, bekerjalah dengan mitra perangkat keras OEM Anda. Mereka akan memberikan panduan dan persyaratan sertifikat yang lebih mendetail.
Sinkronisasi waktu
Anda harus memilih server waktu tertentu yang digunakan untuk menyinkronkan Azure Stack Hub. Sinkronisasi waktu sangat penting untuk Azure Stack Hub dan peran infrastrukturnya karena digunakan untuk menghasilkan tiket Kerberos. Tiket Kerberos digunakan untuk mengautentikasi layanan internal satu sama lain.
Anda harus menentukan IP untuk server sinkronisasi waktu. Meskipun sebagian besar komponen dalam infrastruktur dapat menyelesaikan URL, beberapa yang lain hanya mendukung alamat IP. Jika Anda menggunakan opsi penyebaran terputus, Anda harus menentukan server waktu di jaringan perusahaan yang pasti dapat Anda capai dari jaringan infrastruktur di Azure Stack Hub.
Penting
Jika server waktu Anda bukan merupakan server NTP berbasis Windows, Anda perlu menambahkan ,0x8 akhir alamat IP. Contohnya:10.1.1.123,0x8
Menghubungkan Azure Stack Hub ke Azure
Untuk skenario cloud hibrida, Anda harus merencanakan bagaimana Anda ingin menghubungkan Azure Stack Hub ke Azure. Ada dua metode yang didukung untuk menghubungkan jaringan virtual di Azure Stack Hub ke jaringan virtual di Azure:
Situs-ke-situs: Koneksi jaringan privat virtual (VPN) melalui IPsec (IKE v1 dan IKE v2). Jenis koneksi ini memerlukan perangkat VPN atau Routing and Remote Access Service (RRAS). Untuk informasi selengkapnya tentang VPN gateway di Azure, lihat Tentang VPN Gateway. Komunikasi melalui terowongan ini dienkripsi dan aman. Namun, bandwidth dibatasi oleh throughput maksimum terowongan (100-200 Mbps).
NAT keluar: Secara default, semua mesin virtual di Azure Stack Hub akan memiliki konektivitas ke jaringan eksternal melalui NAT keluar. Setiap jaringan virtual yang dibuat di Azure Stack Hub mendapatkan alamat IP publik yang ditetapkan untuknya. Baik mesin virtual yang secara langsung ditetapkan dengan alamat IP publik atau berada di belakang penyeimbang beban dengan alamat IP publik, mesin tersebut akan memiliki akses keluar melalui NAT keluar menggunakan VIP dari jaringan virtual. Metode ini hanya berfungsi untuk komunikasi yang dimulai oleh mesin virtual dan ditujukan untuk jaringan eksternal (baik internet atau intranet). Metode ini tidak dapat digunakan untuk berkomunikasi dengan mesin virtual dari luar.
Opsi konektivitas hibrida
Untuk konektivitas hibrida, penting untuk mempertimbangkan jenis penyebaran yang ingin Anda tawarkan dan tempat penyebarannya. Anda harus mempertimbangkan apakah Anda perlu mengisolasi lalu lintas jaringan per penyewa, dan apakah Anda akan memiliki penyebaran intranet atau internet.
Azure Stack Hub penyewa tunggal: Penyebaran Azure Stack Hub yang terlihat, setidaknya dari perspektif jaringan, seolah-olah itu adalah satu penyewa. Mungkin ada banyak langganan penyewa, tetapi seperti layanan intranet lainnya, semua lalu lintas berjalan melalui jaringan yang sama. Lalu lintas jaringan dari satu langganan berjalan melalui koneksi jaringan yang sama dengan langganan lain dan tidak perlu diisolasi melalui terowongan terenkripsi.
Azure Stack Hub multi-penyewa: Penyebaran Azure Stack Hub tempat setiap lalu lintas langganan penyewa yang terikat untuk jaringan yang berada di luar Azure Stack Hub harus diisolasi dari lalu lintas jaringan penyewa lain.
Penyebaran intranet: Penyebaran Azure Stack Hub yang berada di intranet perusahaan, biasanya di ruang alamat IP privat dan di belakang satu atau beberapa firewall. Alamat IP publik tidak benar-benar publik karena tidak dapat dirutekan secara langsung melalui internet publik.
Penyebaran internet: Penyebaran Azure Stack Hub yang terhubung ke internet publik dan menggunakan alamat IP publik yang dapat dirutekan ke internet untuk rentang VIP publik. Penyebaran masih dapat dilakukan di belakang firewall, tetapi jangkauan VIP publik dapat langsung dijangkau dari internet publik dan Azure.
Tabel berikut merangkum skenario konektivitas hibrid dengan pro, kontra, dan kasus penggunaan.
| Skenario | Metode Konektivitas | Pro | Kontra | Cocok Untuk |
|---|---|---|---|---|
| Penyewa tunggal Azure Stack Hub, penyebaran intranet | NAT keluar | Bandwidth yang lebih baik untuk transfer yang lebih cepat. Sederhana untuk diterapkan; tidak diperlukan gateway. | Lalu lintas tidak dienkripsi; tidak ada isolasi atau enkripsi di luar tumpukan. | Penyebaran perusahaan tempat semua penyewa saling percaya. Perusahaan yang memiliki sirkuit Azure ExpressRoute ke Azure. |
| Azure Stack Hub multi-penyewa, penyebaran intranet | VPN situs ke situs | Lalu lintas dari penyewa VNet ke tujuan aman. | Bandwidth dibatasi oleh terowongan VPN situs-ke-situs. Memerlukan gateway di jaringan virtual dan perangkat VPN di jaringan tujuan. |
Penyebaran perusahaan tempat beberapa lalu lintas penyewa harus diamankan dari penyewa lain. |
| Penyewa tunggal Azure Stack Hub, penyebaran internet | NAT keluar | Bandwidth yang lebih baik untuk transfer yang lebih cepat. | Lalu lintas tidak dienkripsi; tidak ada isolasi atau enkripsi di luar tumpukan. | Skenario hosting saat penyewa mendapatkan penerapan Azure Stack Hub mereka sendiri dan sirkuit khusus untuk lingkungan Azure Stack Hub. Misalnya, ExpressRoute dan Multiprotocol Label Switching (MPLS). |
| Azure Stack Hub multi-penyewa, penyebaran internet | VPN situs ke situs | Lalu lintas dari penyewa VNet ke tujuan aman. | Bandwidth dibatasi oleh terowongan VPN situs-ke-situs. Memerlukan gateway di jaringan virtual dan perangkat VPN di jaringan tujuan. |
Skenario hosting saat penyedia ingin menawarkan cloud multi-penyewa, di mana penyewa tidak saling percaya dan lalu lintas harus dienkripsi. |
Menggunakan ExpressRoute
Anda dapat menghubungkan Azure Stack Hub ke Azure melalui ExpressRoute untuk skenario intranet penyewa tunggal dan multi-penyewa. Anda akan memerlukan sirkuit ExpressRoute yang disediakan melalui penyedia konektivitas.
Diagram berikut menunjukkan ExpressRoute untuk skenario penyewa tunggal (dengan "koneksi Pelanggan" adalah sirkuit ExpressRoute).
Diagram berikut menunjukkan ExpressRoute untuk skenario multi-penyewa.
Pemantauan eksternal
Untuk mendapatkan satu tampilan semua peringatan dari penyebaran dan perangkat Azure Stack Hub Anda, dan untuk mengintegrasikan peringatan ke dalam alur kerja Manajemen Layanan IT yang ada untuk tiket, Anda dapat mengintegrasikan Azure Stack Hub dengan solusi pemantauan pusat data eksternal.
Disertakan dengan solusi Azure Stack Hub, host siklus hidup perangkat keras adalah komputer di luar Azure Stack Hub yang menjalankan alat manajemen yang disediakan vendor OEM untuk perangkat keras. Anda dapat menggunakan alat ini atau solusi lain yang terintegrasi langsung dengan solusi pemantauan yang ada di pusat data Anda.
Tabel berikut merangkum daftar opsi yang tersedia saat ini.
| Area | Solusi Pemantauan Eksternal |
|---|---|
| Perangkat lunak Azure Stack Hub |
Paket Manajemen Azure Stack Hub untuk Manajer Operasi Plug-in Nagios Panggilan API berbasis REST |
| Server fisik (BMC melalui IPMI) | Perangkat keras OEM - Paket manajemen vendor Manajer Operasi Solusi yang disediakan vendor perangkat keras OEM Plug-in Nagios vendor perangkat keras. Solusi pemantauan yang didukung mitra OEM (termasuk) |
| Perangkat jaringan (SNMP) | Penemuan perangkat jaringan Manajer Operasi Solusi yang disediakan vendor perangkat keras OEM Plug-in sakelar Nagios |
| Pemantauan kesehatan langganan penyewa | Paket Manajemen Pusat Sistem untuk Windows Azure |
Perhatikan persyaratan berikut:
- Solusi yang Anda gunakan harus tanpa agen. Anda tidak dapat menginstal agen pihak ketiga di dalam komponen Azure Stack Hub.
- Jika Anda ingin menggunakan Manajer Operasi Pusat Sistem, Manajer Operasi 2012 R2 atau Manajer Operasi 2016 diperlukan.
Pencadangan dan pemulihan dari bencana
Perencanaan untuk pencadangan dan pemulihan bencana melibatkan perencanaan untuk infrastruktur Azure Stack Hub yang mendasarinya yang menjadi host mesin virtual infrastruktur sebagai layanan dan layanan PaaS, dan untuk aplikasi dan data penyewa. Rencanakan hal-hal ini secara terpisah.
Melindungi komponen infrastruktur
Anda dapat mencadangkan komponen infrastruktur Azure Stack Hub ke berbagi SMB yang Anda tentukan:
- Anda memerlukan berbagi file SMB eksternal di server file berbasis Windows yang ada atau perangkat pihak ketiga.
- Gunakan bagian yang sama ini untuk pencadangan pengalihan jaringan dan host siklus hidup perangkat keras. Vendor perangkat keras OEM Anda akan membantu memberikan panduan untuk pencadangan dan pemulihan komponen-komponen ini karena hal ini berada di luar Azure Stack Hub. Anda bertanggung jawab untuk menjalankan alur kerja cadangan berdasarkan rekomendasi vendor OEM.
Jika kehilangan data besar terjadi, Anda dapat menggunakan cadangan infrastruktur untuk melakukan reseed data penyebaran seperti:
- Input dan pengidentifikasi penyebaran
- Akun layanan
- Sertifikat akar CA
- Sumber daya gabungan (dalam penyebaran terputus)
- Paket, penawaran, langganan, dan kuota
- Kebijakan RBAC dan penetapan peran
- Rahasia Key Vault
Peringatan
Secara default stempel Azure Stack Hub Anda dikonfigurasi hanya dengan satu akun CloudAdmin. Tidak ada opsi pemulihan jika kredensial akun hilang, disusupi, atau dikunci. Anda akan kehilangan akses ke titik akhir istimewa dan sumber daya lainnya.
Anda sangat disarankan untuk membuat akun CloudAdmin tambahan, untuk menghindari pemindahan stempel Anda dengan biaya sendiri. Pastikan Anda mendokumentasikan kredensial ini berdasarkan pedoman perusahaan Anda.
Lindungi aplikasi penyewa di mesin virtual infrastruktur sebagai layanan
Azure Stack Hub tidak mencadangkan aplikasi dan data penyewa. Anda harus merencanakan perlindungan pencadangan dan pemulihan bencana ke target di luar Azure Stack Hub. Perlindungan penyewa adalah aktivitas yang digerakkan oleh penyewa. Untuk mesin virtual infrastruktur sebagai layanan, penyewa dapat menggunakan teknologi in-guest untuk melindungi folder file, data aplikasi, dan status sistem. Namun, sebagai perusahaan atau penyedia layanan, Anda mungkin ingin menawarkan solusi pencadangan dan pemulihan di pusat data yang sama atau secara eksternal di cloud.
Untuk mencadangkan mesin virtual infrastruktur sebagai layanan Linux atau Windows, Anda harus menggunakan produk cadangan dengan akses ke sistem operasi tamu untuk melindungi file, folder, status sistem operasi, dan data aplikasi. Anda dapat menggunakan Azure Backup, System Center Datacenter Protection Manager, atau produk pihak ketiga yang didukung.
Untuk mereplikasi data ke lokasi sekunder dan mengatur failover aplikasi jika terjadi bencana, Anda dapat menggunakan Azure Site Recovery atau produk pihak ketiga yang didukung. Selain itu, aplikasi yang mendukung replikasi asli, seperti Microsoft SQL Server, dapat mereplikasi data ke lokasi lain tempat aplikasi berjalan.
Pelajari lebih lanjut
- Untuk informasi mengenai kasus penggunaan, pembelian, mitra, dan vendor perangkat keras OEM, lihat halaman produk Azure Stack Hub.
- Untuk informasi mengenai peta jalan dan ketersediaan geografis sistem terintegrasi Azure Stack Hub, lihat laporan resmi: Azure Stack Hub: Ekstensi Azure.