Konektivitas zona pendaratan data satu wilayah

Zona pendaratan manajemen data, zona pendaratan data, dan semua layanan di dalamnya disiapkan di wilayah yang sama dalam penyiapan wilayah tunggal. Semua zona pendaratan berada dalam langganan hub konektivitas yang sama. Langganan ini menghosting sumber daya jaringan bersama, yang dapat mencakup appliance virtual jaringan (seperti firewall Azure), gateway ExpressRoute, gateway jaringan privat virtual (VPN), jaringan virtual hub, atau WAN virtual (hub vWAN).

Gambar 1: Koneksi ivitas Wilayah Tunggal.

Berdasarkan kemampuan Azure Networking Services saat ini, kami sarankan Anda menggunakan arsitektur jaringan bertaut. Anda harus menyiapkan peering Vnet antara:

• Hub Koneksi ivity dan Zona Manajemen Data
• Hub Koneksi ivity dan setiap Zona Pendaratan Data
• Zona Manajemen Data dan setiap Zona Pendaratan Data
• Setiap Zona Pendaratan Data

Artikel ini menjelaskan pro dan kontra dari setiap opsi arsitektur jaringan yang kami pertimbangkan untuk analitik skala cloud.

Bagian pertama dari artikel ini berfokus pada pola wilayah tunggal, di mana Zona Manajemen Data dan semua Zona Pendaratan Data dihosting di wilayah yang sama.

Setiap pola desain dievaluasi menggunakan kriteria berikut:

• Biaya
• Manajemen akses pengguna
• Manajemen layanan
• Bandwidth
• Latensi

Kami akan menganalisis setiap opsi desain dengan mempertimbangkan kasus penggunaan zona pendaratan lintas data berikut:

Catatan

Komputer virtual B (VM B) yang dihosting di zona pendaratan data B memuat himpunan data dari akun penyimpanan A yang dihosting di zona pendaratan data A. Kemudian VM B memproses himpunan data tersebut dan menyimpannya di Akun Penyimpanan B, yang dihosting di zona pendaratan data B.

Penting

Artikel ini dan artikel lain di bagian jaringan menguraikan unit lintas bisnis yang berbagi data. Namun, ini mungkin bukan strategi awal Anda dan Anda perlu memulai pada tingkat dasar terlebih dahulu.

Rancang jaringan Anda sehingga Anda akhirnya dapat menerapkan pengaturan yang direkomendasikan di antara zona pendaratan data. Pastikan Anda memiliki zona pendaratan manajemen data yang terhubung langsung ke zona pendaratan untuk tata kelola.

Arsitektur jaringan yang bertautan (disarankan)

Kami menyarankan agar Anda menggunakan arsitektur jala jaringan saat mengadopsi analitik skala cloud. Selain penyiapan desain jaringan hub dan spoke yang ada dalam penyewa Anda, Anda harus melakukan dua hal untuk menerapkan arsitektur jala jaringan:

• Tambahkan peering Vnet di antara semua Vnet zona pendaratan data.
• Tambahkan pasangan Vnet antara zona pendaratan manajemen data Anda dan semua zona pendaratan data.

Dalam skenario contoh kami, data yang dimuat dari Akun Penyimpanan A transit koneksi peering Vnet (2) disiapkan antara dua Vnet zona pendaratan data. Ini dimuat dan diproses oleh VM B ((3) dan (4)), lalu dikirim melalui Titik Akhir Privat lokal (5) untuk disimpan di Akun Penyimpanan B.

Dalam skenario ini, data tidak melewati hub Koneksi ivity. Ini tetap berada dalam Platform Data yang terdiri dari zona pendaratan manajemen data dan satu atau beberapa zona pendaratan data.

Gambar 2: Arsitektur Jaringan Bertaut.

Manajemen akses pengguna dalam arsitektur jaringan bertaut

Dalam desain arsitektur jaringan bertaut, tim aplikasi data hanya memerlukan dua hal untuk dapat membuat layanan baru (termasuk Titik Akhir Privat):

• Menulis akses ke grup sumber daya khusus mereka di zona pendaratan data
• Menggabungkan akses ke subnet yang ditunjuk

Dalam desain ini, tim aplikasi data dapat menyebarkan Titik Akhir Privat itu sendiri. Selama mereka memiliki hak akses yang diperlukan untuk menghubungkan Titik Akhir Privat ke subnet dalam spoke tertentu, tim Anda tidak memerlukan dukungan saat menyiapkan konektivitas yang diperlukan.

Ringkasan:

Manajemen layanan dalam arsitektur jaringan bertaut

Dalam desain arsitektur jaringan bertaut, tidak ada appliance virtual jaringan yang bertindak sebagai satu titik kegagalan atau pembatasan. Kurangnya himpunan data yang dikirim melalui hub Koneksi ivity mengurangi overhead tim platform Azure pusat Anda, asalkan Anda tidak perlu memperluas skala appliance virtual tersebut.

Ini menyiratkan bahwa tim platform Azure pusat tidak dapat lagi memeriksa dan mencatat semua lalu lintas yang dikirim di antara zona pendaratan data. Namun, analitik skala cloud adalah platform koheren yang mencakup beberapa langganan, yang memungkinkan skala dan mengatasi batasan tingkat platform, sehingga bukan kerugian.

Dengan semua sumber daya yang dihosting dalam satu langganan, tim platform Azure pusat Anda juga tidak lagi memeriksa semua data di pusat Koneksi ivity Hub. Anda masih dapat mengambil log jaringan dengan menggunakan Log Alur Kelompok Keamanan Jaringan. Anda dapat mengonsolidasikan dan menyimpan log tingkat aplikasi dan layanan lainnya dengan menggunakan Pengaturan Diagnostik khusus layanan.

Anda dapat mengambil semua log ini dalam skala besar dengan menggunakan definisi Azure Policy untuk pengaturan diagnostik.

Desain ini juga memungkinkan Anda membuat solusi DNS asli Azure berdasarkan Zona DNS Privat. Anda dapat mengotomatiskan siklus hidup DNS A-record melalui definisi Azure Policy untuk grup DNS privat.

Ringkasan:

Biaya arsitektur jaringan yang bertautan

Catatan

Saat mengakses titik akhir privat di seluruh jaringan yang di-peering, Anda hanya akan dikenakan biaya untuk titik akhir privat itu sendiri, bukan untuk peering VNet. Anda dapat membaca pernyataan resmi di FAQ: Bagaimana cara kerja penagihan saat mengakses titik akhir privat dari jaringan yang di-peering?.

Dalam desain jaringan ini, Anda hanya membayar untuk:

• Titik Akhir Privat Anda (per jam)
• Lalu lintas masuk dan keluar yang dikirim melalui Titik Akhir Privat Anda untuk memuat himpunan data mentah Anda (1) dan menyimpan himpunan data yang diproses (6)

Peering Vnet tidak akan dikenakan biaya (2), itulah sebabnya opsi ini memiliki biaya minimal.

Ringkasan:

Bandwidth dan latensi dalam arsitektur jaringan bertaut

Desain ini tidak memiliki batasan bandwidth atau latensi yang diketahui karena tidak ada appliance virtual jaringan yang membatasi throughput untuk pertukaran data zona pendaratan lintas datanya. Satu-satunya faktor pembatas desain adalah batas fisik pusat data kami (kecepatan kabel serat optik).

Ringkasan:

Ringkasan arsitektur jaringan yang bertautan

Jika Anda berencana untuk mengadopsi analitik skala cloud, kami sarankan Anda menggunakan desain jaringan bertaut. Jaringan bertaut menawarkan bandwidth maksimum dan latensi rendah dengan biaya minimal, namun tidak membuat kompromi mengenai manajemen akses pengguna atau pada lapisan DNS.

Jika Anda perlu menerapkan kebijakan jaringan lain dalam platform data, gunakan Kelompok Keamanan Jaringan daripada appliance virtual jaringan pusat.

Arsitektur hub dan spoke tradisional (tidak disarankan)

Desain arsitektur jaringan hub dan spoke adalah opsi yang paling jelas, dan yang telah diadopsi oleh banyak perusahaan. Di dalamnya, transitivitas jaringan disiapkan di hub Koneksi ivity untuk mengakses data di Akun Penyimpanan A dari VM B. Data melintasi dua peering Vnet ((2) dan (5)) dan appliance virtual jaringan yang dihosting di dalam Koneksi ivity Hub ((3) dan (4)). Kemudian data dimuat oleh komputer virtual (6) dan disimpan kembali ke Akun Penyimpanan B (8).

Gambar 3: Arsitektur hub dan spoke.

Manajemen akses pengguna di arsitektur hub dan spoke tradisional

Dalam desain hub dan spoke tradisional, tim aplikasi data hanya memerlukan dua hal bagi mereka untuk dapat membuat layanan baru (termasuk Titik Akhir Privat):

• Menulis akses ke grup sumber daya mereka di zona pendaratan data
• Menggabungkan akses ke subnet yang ditunjuk

Dalam desain ini, tim aplikasi data dapat menyebarkan Titik Akhir Privat itu sendiri. Selama mereka memiliki hak akses yang diperlukan untuk menghubungkan Titik Akhir Privat ke subnet dalam spoke tertentu, tim Anda tidak memerlukan dukungan saat menyiapkan konektivitas yang diperlukan.

Ringkasan:

Manajemen Layanan dalam arsitektur hub dan spoke tradisional

Desain jaringan ini terkenal dan konsisten dengan penyiapan jaringan sebagian besar organisasi yang ada. Ini membuat desain mudah dijelaskan dan diimplementasikan. Anda juga dapat menggunakan solusi DNS asli Azure terpusat dengan Zona DNS Privat untuk memberikan resolusi FQDN di dalam penyewa Azure Anda. Menggunakan Zona DNS Privat memungkinkan Anda mengotomatiskan siklus hidup DNS A-record melalui Kebijakan Azure.

Manfaat lain dari desain ini adalah bahwa lalu lintas dirutekan melalui appliance virtual jaringan pusat, sehingga lalu lintas jaringan yang dikirim dari satu Spoke ke spoke lainnya dapat dicatat dan diperiksa.

Salah satu kelemahan dari desain ini adalah tim Platform Azure pusat Anda harus mengelola Tabel Rute secara manual. Ini diperlukan untuk memastikan transitivitas antara Spoke, yang memungkinkan berbagi aset data di beberapa zona pendaratan data. Manajemen rute dapat menjadi kompleks dan rawan kesalahan dari waktu ke waktu dan harus dipertimbangkan di muka.

Kelemahan lain dari penyiapan jaringan ini adalah cara appliance virtual jaringan pusat Anda disiapkan. Appliance virtual jaringan berfungsi sebagai satu titik kegagalan dan dapat menyebabkan waktu henti serius di dalam platform data jika kegagalan terjadi. Selain itu, ketika ukuran himpunan data meningkat dalam platform data dan jumlah kasus penggunaan zona pendaratan lintas data meningkat, lebih banyak lalu lintas dikirim melalui appliance virtual jaringan pusat.

Seiring waktu, ini dapat mengakibatkan gigabyte atau bahkan terabyte data dikirim melalui instans pusat. Karena bandwidth appliance virtual jaringan yang ada sering dibatasi hanya pada throughput gigabyte satu atau dua digit, appliance virtual jaringan pusat dapat menjadi hambatan yang sangat membatasi arus lalu lintas antara zona pendaratan data dan membatasi berbagi aset data.

Satu-satunya cara untuk menghindari masalah ini adalah dengan menskalakan appliance virtual jaringan pusat Anda di beberapa instans, yang memiliki implikasi biaya utama untuk desain ini.

Ringkasan:

Biaya arsitektur hub dan spoke tradisional

Catatan

Saat mengakses titik akhir privat di seluruh jaringan yang di-peering, Anda hanya akan dikenakan biaya untuk titik akhir privat itu sendiri dan bukan untuk peering VNet. Anda dapat membaca pernyataan resmi di FAQ: Bagaimana cara kerja penagihan saat mengakses titik akhir privat dari jaringan yang di-peering?.

Untuk jaringan ini, Anda dikenakan biaya per jam untuk Titik Akhir Privat akun penyimpanan Anda. Anda juga dikenakan biaya untuk lalu lintas masuk dan keluar yang dikirim melalui Titik Akhir Privat untuk memuat himpunan data mentah (1) dan menyimpan himpunan data yang diproses (8).

Pelanggan Anda dikenakan biaya untuk masuk dan keluar dari satu peering Vnet (5). Seperti yang disebutkan sebelumnya, peering Vnet pertama tidak dikenakan biaya (2).

Anda akan berakhir dengan biaya appliance virtual jaringan pusat yang tinggi jika menggunakan desain jaringan ini ((3) dan (4)). Anda harus membeli lisensi tambahan dan menskalakan appliance virtual jaringan pusat berdasarkan permintaan atau membayar biaya yang diproses per gigabyte seperti yang dilakukan dengan Azure Firewall.

Ringkasan:

Bandwidth dan latensi dalam arsitektur hub dan spoke tradisional

Desain jaringan ini memiliki keterbatasan bandwidth yang serius. Appliance virtual jaringan pusat menjadi hambatan penting saat platform Anda tumbuh, yang membatasi kasus penggunaan zona pendaratan lintas data dan berbagi himpunan data. Ini juga kemungkinan membuat beberapa salinan himpunan data dari waktu ke waktu.

Desain ini juga sangat memengaruhi latensi, yang menjadi sangat penting dalam skenario analitik real time.

Ringkasan:

Ringkasan arsitektur hub dan spoke tradisional

Desain jaringan hub dan spoke ini memiliki manajemen akses dan beberapa manfaat manajemen layanan, tetapi karena keterbatasan penting manajemen layanan dan bandwidth dan latensi, kami tidak dapat merekomendasikan desain jaringan ini untuk kasus penggunaan zona pendaratan lintas data.

Arsitektur proyeksi Titik Akhir Privat (tidak disarankan)

Opsi desain lainnya adalah proyeksi Titik Akhir Privat di setiap zona pendaratan. Dalam desain ini, Titik Akhir Privat untuk Akun Penyimpanan A dibuat di setiap zona pendaratan. Ini mengarah ke Titik Akhir Privat pertama di zona pendaratan data A yang terhubung ke Vnet di zona pendaratan data A, Titik Akhir Privat kedua yang terhubung ke Vnet di zona pendaratan data B, dan sebagainya.

Hal yang sama berlaku untuk Akun Penyimpanan B, dan berpotensi untuk layanan lain di dalam zona pendaratan data. Jika kita menentukan jumlah zona pendaratan data sebagai n, maka kita berakhir dengan n Titik Akhir Privat untuk setidaknya semua akun penyimpanan dan kemungkinan layanan lain dalam zona pendaratan data juga. Ini menyebabkan peningkatan eksponensial dalam jumlah Titik Akhir Privat.

Gambar 4: Arsitektur proyeksi Titik Akhir Privat.

Karena semua Titik Akhir Privat dari layanan tertentu (misalnya, Akun Penyimpanan A) memiliki FQDN yang sama (seperti storageaccounta.privatelink.blob.core.windows.net), solusi ini menciptakan tantangan di lapisan DNS yang tidak dapat diselesaikan menggunakan Zona DNS Privat. Sebagai gantinya, Anda memerlukan solusi DNS kustom yang mampu menyelesaikan nama DNS berdasarkan asal/alamat IP pemohon. Ini memungkinkan Anda untuk membuat VMA terhubung ke Titik Akhir Privat yang terhubung ke Vnet di zona pendaratan data A, dan untuk membuat VM B terhubung ke Titik Akhir Privat yang terhubung ke Vnet di zona pendaratan data B. Anda dapat melakukan ini dengan penyiapan berbasis Windows Server, sedangkan Anda dapat mengotomatiskan siklus hidup DNS A-records melalui kombinasi Log Aktivitas dan Azure Functions.

Dalam penyiapan ini, Anda dapat memuat himpunan data mentah di Akun Penyimpanan A ke VM B dengan mengakses himpunan data melalui Titik Akhir Privat lokal (1). Setelah memuat dan memproses himpunan data ((2) dan (3)), Anda dapat menyimpannya di Akun Penyimpanan B dengan langsung mengakses Titik Akhir Privat lokal (4). Dalam skenario ini, data tidak boleh melintasi peering Vnet apa pun.

Manajemen akses pengguna dalam arsitektur proyeksi titik akhir privat

Pendekatan desain untuk manajemen akses pengguna ini mirip dengan arsitektur jaringan bertaut. Namun, dalam desain ini, Anda dapat memerlukan hak akses untuk zona pendaratan data lainnya, untuk membuat Titik Akhir Privat tidak hanya dalam zona pendaratan data dan Vnet yang ditunjuk tetapi juga di zona pendaratan data lainnya dan Vnet masing-masing.

Karena itu, tim aplikasi data Anda memerlukan tiga hal, bukan dua, untuk dapat membuat layanan baru itu sendiri:

• Menulis akses ke grup sumber daya di zona pendaratan data yang ditunjuk
• Menggabungkan akses ke subnet yang ditunjuk
• Akses ke grup sumber daya dan subnet di dalam semua zona pendaratan data lainnya untuk membuat Titik Akhir Privat lokal masing-masing

Desain jaringan ini meningkatkan kompleksitas di lapisan manajemen akses Anda karena tim aplikasi data Anda memerlukan izin di setiap zona pendaratan data tunggal. Desainnya juga bisa membingungkan dan menyebabkan RBAC yang tidak konsisten dari waktu ke waktu.

Jika tim zona pendaratan data dan tim aplikasi data tidak diberi hak akses yang diperlukan, masalah yang dijelaskan dalam arsitektur hub dan spoke tradisional (tidak disarankan) akan terjadi.

Ringkasan:

Manajemen layanan dalam arsitektur proyeksi titik akhir privat

Meskipun sekali lagi mirip dengan desain arsitektur jaringan bertaut, desain jaringan ini tidak memiliki manfaat dari tidak ada appliance virtual jaringan yang bertindak sebagai satu titik kegagalan atau throughput pembatasan. Ini juga mengurangi overhead manajemen untuk tim platform Azure pusat Anda dengan tidak mengirim himpunan data melalui hub Koneksi ivity, karena tidak perlu memperluas skala appliance virtual. Ini menyiratkan bahwa tim platform Azure pusat tidak dapat lagi memeriksa dan mencatat semua lalu lintas yang dikirim di antara zona pendaratan data. Namun, analitik skala cloud adalah platform koheren yang mencakup beberapa langganan, yang memungkinkan skala dan mengatasi batasan tingkat platform, sehingga bukan kerugian.

Dengan semua sumber daya yang dihosting dalam satu langganan, lalu lintas tidak diperiksa di pusat Koneksi ivity Hub. Anda masih dapat mengambil log jaringan dengan menggunakan log Alur Kelompok Keamanan Jaringan, dan Anda dapat mengonsolidasikan dan menyimpan log tingkat aplikasi dan layanan lainnya dengan menggunakan Pengaturan Diagnostik khusus layanan. Anda dapat mengambil semua log ini dalam skala besar dengan menggunakan Kebijakan Azure. Di sisi lain, ruang alamat jaringan yang diperlukan oleh platform data Anda meningkat karena peningkatan eksponensial dalam Titik Akhir Privat yang diperlukan, yang tidak optimal.

Kekhawatiran utama mengenai arsitektur jaringan ini adalah tantangan DNS yang disebutkan sebelumnya. Anda tidak dapat menggunakan solusi asli Azure dalam bentuk Zona DNS Privat, sehingga arsitektur ini memerlukan solusi pihak ketiga yang mampu menyelesaikan FQDNS berdasarkan asal/alamat IP pemohon. Anda juga harus mengembangkan dan memelihara alat dan alur kerja untuk mengotomatiskan catatan A DNS Privat, yang secara drastis meningkatkan overhead manajemen dibandingkan dengan solusi yang didorong Azure Policy yang diusulkan.

Anda dapat membuat infrastruktur DNS terdistribusi menggunakan zona DNS Privat, tetapi ini membuat pulau DNS, yang pada akhirnya menyebabkan masalah saat Anda mencoba mengakses layanan tautan privat yang dihosting di zona pendaratan lain dalam penyewa Anda. Oleh karena itu, desain ini bukan pilihan yang layak.

Ringkasan:

Biaya arsitektur proyeksi titik akhir privat

Catatan

Saat mengakses titik akhir privat di seluruh jaringan yang di-peering, Anda hanya akan dikenakan biaya untuk titik akhir privat itu sendiri dan bukan untuk peering VNet. Anda dapat membaca pernyataan resmi di FAQ: Bagaimana cara kerja penagihan saat mengakses titik akhir privat dari jaringan yang di-peering?.

Dalam desain jaringan ini, Anda hanya dikenakan biaya untuk Titik Akhir Privat (per jam) dan lalu lintas masuk dan keluar yang dikirim melalui Titik Akhir Privat tersebut untuk memuat himpunan data mentah (1) dan menyimpan himpunan data yang diproses (4). Namun, biaya tambahan harus diharapkan karena peningkatan eksponensial dalam jumlah Titik Akhir Privat platform data Anda. Karena Anda dikenakan biaya per jam, jumlah biaya tambahan sangat tergantung pada berapa banyak Titik Akhir Privat yang dibuat.

Ringkasan:

Bandwidth dan latensi dalam arsitektur proyeksi titik akhir privat

Desain ini tidak memiliki batasan bandwidth dan latensi yang diketahui karena tidak memiliki appliance virtual jaringan yang membatasi throughput untuk pertukaran data zona pendaratan lintas data. Satu-satunya faktor pembatas desain adalah batas fisik pusat data kami (kecepatan kabel serat optik).

Ringkasan:

Ringkasan arsitektur proyeksi Titik Akhir Privat

Pertumbuhan eksponensial Titik Akhir Privat dalam arsitektur jaringan ini dapat menyebabkan Anda kehilangan jejak Titik Akhir Privat mana yang digunakan untuk tujuan di lokasi mana. Anda juga dibatasi oleh masalah manajemen akses dan kompleksitas lapisan DNS. Karena masalah ini, kami tidak dapat merekomendasikan desain jaringan ini untuk kasus penggunaan zona pendaratan lintas data.

Titik Akhir Privat dalam arsitektur hub Koneksi ivity (tidak disarankan)

Opsi jaringan lain adalah menghosting Titik Akhir Privat di hub Koneksi ivity Anda dan menyambungkannya ke Hub Vnet. Dalam solusi ini, Anda menghosting satu Titik Akhir Privat untuk setiap layanan di Vnet perusahaan Anda. Karena arsitektur jaringan hub dan spoke yang ada di sebagian besar perusahaan, dan fakta bahwa hub Koneksi ivity Anda menghosting Titik Akhir Privat Anda dalam solusi ini, transitivitas tidak diperlukan. Peering Vnet antara Hub Koneksi ivity Anda dan zona pendaratan data memungkinkan akses langsung.

Data melintasi satu peering Vnet antara hub Koneksi ivity dan zona pendaratan data untuk memuat himpunan data yang disimpan di Akun Penyimpanan A di VM B. Setelah himpunan data dimuat dan diproses ((3) dan (4)), himpunan data melintasi peering Vnet yang sama untuk kedua kalinya (5) sebelum akhirnya disimpan di Akun Penyimpanan B melalui Titik Akhir Privat yang terhubung ke Hub Vnet (6).

Gambar 5: Titik Akhir Privat dalam arsitektur hub Koneksi ivity.

Manajemen akses pengguna dalam arsitektur hub Koneksi ivity

Dalam desain jaringan ini, tim zona pendaratan data dan tim aplikasi data Anda memerlukan dua hal untuk dapat menghubungkan Titik Akhir Privat ke Hub Vnet:

• Menulis izin ke grup sumber daya di langganan hub Koneksi ivity Anda
• Izin bergabung ke Hub Vnet

Hub Koneksi ivity Anda ditunjuk untuk tim platform Azure organisasi Anda dan didedikasikan untuk menghosting infrastruktur jaringan organisasi Anda yang diperlukan dan bersama (termasuk firewall, gateway, dan alat manajemen jaringan). Opsi jaringan ini membuat desain itu tidak konsisten, karena tidak mengikuti prinsip manajemen akses dari prinsip dasar Zona Pendaratan Skala Perusahaan. Oleh karena itu, sebagian besar tim platform Azure tidak akan menyetujui opsi desain ini.

Ringkasan:

Manajemen layanan dalam arsitektur hub Koneksi ivity

Meskipun mirip dengan desain arsitektur jaringan jala, desain ini tidak memiliki appliance virtual jaringan yang bertindak sebagai satu titik kegagalan atau throughput pembatasan. Ini juga mengurangi overhead manajemen untuk tim platform Azure pusat Anda dengan tidak mengirim himpunan data melalui hub Koneksi ivity, karena tidak perlu memperluas skala appliance virtual. Ini menyiratkan bahwa tim platform Azure pusat tidak dapat lagi memeriksa dan mencatat semua lalu lintas yang dikirim di antara zona pendaratan data. Namun, analitik skala cloud adalah platform koheren yang mencakup beberapa langganan, yang memungkinkan skala dan mengatasi batasan tingkat platform, sehingga bukan kerugian.

Dengan semua sumber daya yang dihosting dalam satu langganan, lalu lintas tidak diperiksa di pusat Koneksi ivity Hub. Anda masih dapat mengambil log jaringan dengan menggunakan log Alur Kelompok Keamanan Jaringan, dan Anda dapat mengonsolidasikan dan menyimpan log tingkat aplikasi dan layanan lainnya dengan menggunakan Pengaturan Diagnostik khusus layanan. Anda dapat mengambil semua log ini dalam skala besar dengan menggunakan Kebijakan Azure.

Desain ini juga memungkinkan Anda membuat solusi DNS asli Azure berdasarkan Zona DNS Privat, dan memungkinkan Anda mengotomatiskan siklus hidup DNS A-record melalui Kebijakan Azure.

Ringkasan:

biaya arsitektur Koneksi ivity Hub

Catatan

Saat mengakses titik akhir privat di seluruh jaringan yang di-peering, Anda hanya akan dikenakan biaya untuk titik akhir privat itu sendiri dan bukan untuk peering VNet. Anda dapat membaca pernyataan resmi di FAQ: Bagaimana cara kerja penagihan saat mengakses titik akhir privat dari jaringan yang di-peering?.

Dalam desain jaringan ini, Anda hanya dikenakan biaya untuk Titik Akhir Privat (per jam) dan lalu lintas masuk dan keluar yang dikirim melalui Titik Akhir Privat tersebut untuk memuat himpunan data mentah (1) dan menyimpan himpunan data yang diproses (6).

Ringkasan:

Bandwidth dan latensi dalam arsitektur hub Koneksi ivity

Desain ini tidak memiliki batasan bandwidth dan latensi yang diketahui karena tidak memiliki appliance virtual jaringan yang membatasi throughput untuk pertukaran data zona pendaratan lintas data. Satu-satunya faktor pembatas desain adalah batas fisik pusat data kami (kecepatan kabel serat optik).

Ringkasan:

Titik Akhir Privat dalam ringkasan arsitektur hub Koneksi ivity

Meskipun desain arsitektur jaringan ini memiliki beberapa manfaat, inkonsistensi manajemen akses yang disebutkan sebelumnya membuatnya menjadi subpar. Oleh karena itu, kami tidak dapat merekomendasikan pendekatan desain ini.

Kesimpulan konektivitas zona pendaratan data satu wilayah

Dari semua opsi arsitektur jaringan yang ditinjau dan pro dan kontra mereka, arsitektur jaringan bertaut adalah pemenang yang jelas. Ini memiliki manfaat luar biasa untuk throughput dan untuk biaya dan manajemen, itulah sebabnya kami sarankan Anda menggunakannya saat menyebarkan analitik skala cloud. Jaringan virtual spoke peering sebelumnya tidak umum, dan ini telah menyebabkan masalah dengan berbagi himpunan data di seluruh domain dan unit bisnis.

Anda dapat melihat analitik skala cloud sebagai solusi koheren yang mencakup beberapa langganan. Dalam satu penyiapan langganan, arus lalu lintas jaringan sama dengan alur dalam arsitektur jaringan bertaut. Dalam satu penyiapan langganan, pengguna kemungkinan besar akan mencapai batas dan kuota tingkat langganan platform, yang bertujuan untuk dihindari oleh analitik skala cloud.

Langkah berikutnya

• Zona pendaratan data lintas wilayah Koneksi ivity