Menyebarkan Azure Databricks di Azure Virtual Network (Injeksi VNet)

Artikel ini menjelaskan cara menyebarkan ruang kerja Azure Databricks di jaringan virtual Azure Anda sendiri, juga dikenal sebagai injeksi VNet.

Kustomisasi jaringan dengan injeksi VNet

Penyebaran default Azure Databricks adalah layanan terkelola penuh di Azure. Jaringan virtual Azure (VNet) disebarkan ke grup sumber daya terkunci. Semua sumber daya sarana komputasi klasik dikaitkan dengan VNet tersebut. Jika Anda memerlukan kustomisasi jaringan, Anda dapat menyebarkan sumber daya sarana komputasi klasik Azure Databricks di jaringan virtual Anda sendiri. Ini memungkinkan Anda untuk:

Menyebarkan sumber daya bidang komputasi klasik Azure Databricks ke VNet Anda sendiri juga memungkinkan Anda memanfaatkan rentang CIDR yang fleksibel. Untuk VNet, Anda dapat menggunakan ukuran /16-/24rentang CIDR . Untuk subnet, gunakan rentang IP sekucil /26.

Penting

Anda tidak dapat mengganti VNet untuk ruang kerja yang sudah ada. Jika ruang kerja Anda saat ini tidak dapat mengakomodasi jumlah node kluster aktif yang diperlukan, sebaiknya buat ruang kerja lain di VNet yang lebih besar. Ikuti langkah-langkah migrasi mendetail ini untuk menyalin sumber daya (notebook, konfigurasi kluster, pekerjaan) dari ruang kerja lama ke yang baru.

Persyaratan jaringan virtual

VNet tempat Anda menyebarkan ruang kerja Azure Databricks Anda harus memenuhi persyaratan berikut:

  • Wilayah: VNet harus berada di wilayah dan langganan yang sama dengan ruang kerja Azure Databricks.
  • Langganan: VNet harus berada dalam langganan yang sama dengan ruang kerja Azure Databricks.
  • Ruang alamat: Blok CIDR antara /16 dan /24 untuk VNet dan blok CIDR hingga /26 untuk dua subnet: subnet kontainer dan subnet host. Untuk panduan tentang node kluster maksimum berdasarkan ukuran VNet Anda dan subnetnya, lihat Ruang alamat dan node cluster maksimum.
  • Subnet: VNet harus menyertakan dua subnet yang didedikasikan untuk ruang kerja Azure Databricks Anda: subnet kontainer (kadang-kadang disebut subnet pribadi) dan subnet host (kadang-kadang disebut subnet publik). Saat Anda menyebarkan ruang kerja menggunakan konektivitas kluster yang aman, subnet kontainer dan subnet host menggunakan IP privat. Anda tidak dapat berbagi subnet di seluruh ruang kerja atau menyebarkan sumber daya Azure lainnya di subnet yang digunakan oleh ruang kerja Azure Databricks Anda. Untuk panduan tentang node kluster maksimum berdasarkan ukuran VNet Anda dan subnetnya, lihat Ruang alamat dan node cluster maksimum.

Ruang alamat dan node kluster maksimum

Ruang kerja dengan jaringan virtual yang lebih kecil dapat kehabisan alamat IP (ruang jaringan) lebih cepat daripada ruang kerja dengan jaringan virtual yang lebih besar. Gunakan blok CIDR antara /16 dan /24 untuk VNet dan blok CIDR hingga /26 untuk dua subnet (subnet kontainer dan subnet host). Anda dapat membuat blok CIDR hingga /28 subnet Anda, namun Databricks tidak merekomendasikan subnet yang lebih kecil dari /26.

Rentang CIDR untuk ruang alamat VNet Anda memengaruhi jumlah maksimum node kluster yang dapat digunakan ruang kerja Anda.

Ruang kerja Azure Databricks memerlukan dua subnet di VNet: subnet kontainer dan subnet host. Azure memesan lima IP di setiap subnet. Azure Databricks memerlukan dua IP untuk setiap node kluster: satu alamat IP untuk host di subnet host dan satu alamat IP untuk kontainer di subnet kontainer.

  • Anda mungkin tidak ingin menggunakan semua ruang alamat VNet Anda. Misalnya, Anda mungkin ingin membuat beberapa ruang kerja dalam satu VNet. Karena Anda tidak dapat berbagi subnet di seluruh ruang kerja, Anda mungkin ingin subnet yang tidak menggunakan total ruang alamat VNet.
  • Anda harus mengalokasikan ruang alamat untuk dua subnet baru yang berada dalam ruang alamat VNet dan tidak tumpang-tindih dengan ruang alamat subnet saat ini atau masa depan di VNet tersebut.

Tabel berikut menunjukkan ukuran subnet maksimum berdasarkan ukuran jaringan. Tabel ini mengasumsikan tidak ada subnet tambahan yang memakan ruang alamat. Gunakan subnet yang lebih kecil jika Anda memiliki subnet yang sudah ada sebelumnya atau jika Anda ingin mencadangkan ruang alamat untuk subnet lain:

Ruang alamat VNET (CIDR) Ukuran subnet maximum Azure Databricks (CIDR) dengan asumsi tidak ada subnet lain
/16 /17
/17 /18
/18 /19
/20 /21
/21 /22
/22 /23
/23 /24
/24 /25

Untuk menemukan node kluster maksimum berdasarkan ukuran subnet, gunakan tabel berikut. Alamat IP per kolom subnet mencakup lima alamat IP yang dipesan Azure. Kolom paling kanan menunjukkan jumlah node kluster yang dapat berjalan secara bersamaan di ruang kerja yang disediakan dengan subnet sebesar itu.

Ukuran subnet (CIDR) Alamat IP per subnet Node kluster Azure Databricks maksimum
/17 32768 32763
/18 16384 16379
/19 8192 8187
/20 4096 4091
/21 2048 2043
/22 1024 1019
/23 512 507
/24 256 251
/25 128 123
/26 64 59

Alamat IP keluar saat menggunakan konektivitas kluster yang aman

Jika Anda mengaktifkan konektivitas kluster aman di ruang kerja Anda yang menggunakan injeksi VNet, Databricks menyarankan agar ruang kerja Anda memiliki IP publik keluar yang stabil.

Alamat IP publik keluar yang stabil berguna karena Anda dapat menambahkannya ke daftar izin eksternal. Misalnya, untuk menyambungkan dari Azure Databricks ke Salesforce dengan alamat IP keluar yang stabil.

Peringatan

Microsoft mengumumkan bahwa pada 30 September 2025, konektivitas akses keluar default untuk komputer virtual di Azure akan dihentikan. Lihat pengumuman ini. Ini berarti bahwa ruang kerja Azure Databricks yang menggunakan akses keluar default daripada IP publik keluar yang stabil mungkin tidak terus berfungsi setelah tanggal tersebut. Databricks merekomendasikan agar Anda menambahkan metode keluar eksplisit untuk ruang kerja Anda sebelum tanggal tersebut.

Untuk mengonfigurasi IP publik keluar yang stabil, lihat Keluar dengan injeksi VNet

Sumber daya dan peering bersama

Jika sumber daya jaringan bersama seperti DNS diperlukan, Databricks sangat menyarankan Anda mengikuti praktik terbaik Azure untuk model hub dan spoke. Gunakan peering VNet untuk memperluas ruang IP privat VNet ruang kerja ke hub sambil menjaga spoke terisolasi satu sama lain.

Jika Anda memiliki sumber daya lain di VNet atau menggunakan peering, Databricks sangat menyarankan agar Anda menambahkan aturan Tolak ke grup keamanan jaringan (NSG) yang dilampirkan ke jaringan dan subnet lain yang berada di VNet yang sama atau di-peering ke VNet tersebut. Tambahkan aturan Tolak untuk koneksi untuk koneksi masuk dan keluar sehingga membatasi koneksi ke dan dari sumber daya komputasi Azure Databricks. Jika kluster Anda memerlukan akses ke sumber daya di jaringan, tambahkan aturan untuk hanya mengizinkan jumlah akses minimal yang diperlukan untuk memenuhi persyaratan.

Untuk informasi terkait, lihat Aturan grup keamanan jaringan.

Buat ruang kerja Azure Databricks dari portal Azure

Bagian ini menjelaskan cara membuat ruang kerja Azure Databricks di portal Azure dan menyebarkannya di VNet Anda sendiri yang sudah ada. Azure Databricks memperbarui VNet dengan dua subnet baru jika belum ada menggunakan rentang CIDR yang Anda tentukan. Layanan ini juga memperbarui subnet dengan grup keamanan jaringan baru, mengonfigurasi aturan masuk dan keluar, dan akhirnya menyebarkan ruang kerja ke VNet yang diperbarui. Untuk kontrol lebih besar atas konfigurasi VNet, gunakan templat Azure-Databricks-supplied Azure Resource Manager (ARM) alih-alih portal. Misalnya, gunakan grup keamanan jaringan yang ada atau buat aturan keamanan Anda sendiri. Lihat Konfigurasi tingkat lanjut menggunakan template Azure Resource Manager.

Pengguna yang membuat ruang kerja harus diberi peran kontributor Jaringan ke Virtual Network yang sesuai, atau peran kustom yang diberi Microsoft.Network/virtualNetworks/subnets/join/action izin dan Microsoft.Network/virtualNetworks/subnets/write .

Anda harus mengonfigurasi VNet tempat Anda akan menyebarkan ruang kerja Azure Databricks. Anda dapat menggunakan VNet yang sudah ada atau membuat yang baru, tetapi VNet harus berada di wilayah yang sama dan langganan yang sama dengan ruang kerja Azure Databricks yang ingin Anda buat. VNet harus berukuran dengan rentang CIDR antara /16 dan /24. Untuk mengetahui informasi lebih lanjut, lihat Persyaratan jaringan virtual.

Gunakan subnet yang ada atau tentukan nama dan rentang IP untuk subnet baru saat Anda mengonfigurasi ruang kerja Anda.

  1. Di portal Microsoft Azure, pilih + Buat sumber daya> Analitik >Azure Databricks atau cari Azure Databricks dan klik Buat atau + Tambah untuk meluncurkan dialog Layanan Azure Databricks.

  2. Ikuti langkah-langkah konfigurasi yang dijelaskan di Buat ruang kerja Azure Databricks di mulai cepat VNet Anda sendiri.

  3. Di tab Jaringan, pilih VNet yang ingin Anda gunakan di bidang Jaringan virtual.

    Penting

    Jika Anda tidak melihat nama jaringan di pemilih, konfirmasikan bahwa wilayah Azure yang Anda tentukan untuk ruang kerja cocok dengan wilayah Azure dari VNet yang diinginkan.

    Pilih jaringan virtual

  4. Beri nama subnet Anda dan berikan rentang CIDR dalam blok hingga ukuran /26. Untuk panduan tentang node kluster maksimum berdasarkan ukuran VNet Anda dan subnetnya, lihat Ruang alamat dan node cluster maksimum. Rentang CIDR subnet tidak dapat diubah setelah ruang kerja disebarkan.

    • Untuk menentukan subnet yang ada, tentukan nama yang tepat dari subnet yang ada. Saat menggunakan subnet yang ada, atur juga rentang IP dalam formulir pembuatan ruang kerja agar benar-benar sesuai dengan rentang IP dari subnet yang ada.
    • Untuk membuat subnet baru, tentukan nama subnet yang belum ada di VNet tersebut. Subnet dibuat dengan rentang IP yang ditentukan. Anda harus menentukan rentang IP dalam rentang IP VNet Anda dan belum dialokasikan ke subnet yang ada.

    Azure Databricks mengharuskan nama subnet tidak lebih dari 80 karakter.

    Subnet mendapatkan aturan grup keamanan jaringan terkait yang menyertakan aturan untuk mengizinkan komunikasi kluster-internal. Azure Databricks memiliki izin yang didelegasikan untuk memperbarui kedua subnet melalui Microsoft.Databricks/workspaces penyedia sumber daya. Izin ini hanya berlaku untuk aturan grup keamanan jaringan yang disyaratkan oleh Azure Databricks, bukan pada aturan grup keamanan jaringan lain yang Anda tambahkan atau ke aturan grup keamanan jaringan default yang disertakan dengan semua grup keamanan jaringan.

  5. Klik Buat untuk menyebarkan ruang kerja Azure Databricks ke VNet.

Konfigurasi tingkat lanjut menggunakan template Azure Resource Manager

Untuk kontrol lebih lanjut atas konfigurasi VNet, gunakan templat Azure Resource Manager (ARM) berikut alih-alih konfigurasi VNet otomatis berbasis UI portal dan penyebaran ruang kerja. Misalnya, gunakan subnet yang ada, grup keamanan jaringan yang ada, atau tambahkan aturan keamanan Anda sendiri.

Jika Anda menggunakan template Azure Resource Manager kustom atau Template Ruang Kerja untuk Azure Databricks Vnet Injection untuk menyebarkan ruang kerja ke VNet yang ada, Anda harus membuat subnet host dan kontainer, melampirkan grup keamanan jaringan ke setiap subnet, dan mendelegasikan subnet Microsoft.Databricks/workspaces penyedia sumber sebelum menyebarkan ruang kerja. Anda harus memisahkan pasangan subnet untuk setiap ruang kerja yang Anda sebarkan.

Template Lengkap

Untuk membuat ruang kerja VNet dan Azure Databricks menggunakan satu template, gunakan Template Lengkap untuk Azure Databricks Vnet Injected Workspaces.

Template jaringan virtual

Untuk membuat VNet dengan subnet yang tepat menggunakan template, gunakan Template VNet untuk Databricks Vnet Injection.

Template ruang kerja Azure Databricks

Untuk menyebarkan ruang kerja Azure Databricks ke VNet yang sudah ada dengan template, gunakan Template Ruang Kerja untuk Azure Databricks Vnet Injection.

Template ruang kerja memungkinkan Anda menentukan VNet yang ada dan menggunakan subnet yang ada:

  • Anda harus memisahkan pasangan subnet host/kontainer untuk setiap ruang kerja yang Anda sebarkan. Tidak didukung untuk berbagi subnet di seluruh ruang kerja atau menyebarkan sumber daya Azure lainnya di subnet yang digunakan oleh ruang kerja Azure Databricks Anda.
  • Subnet host dan kontainer VNet Anda harus memiliki kelompok keamanan jaringan yang dilampirkan dan harus didelegasikan ke Microsoft.Databricks/workspaces layanan sebelum Anda menggunakan template Azure Resource Manager ini untuk menyebarkan ruang kerja.
  • Untuk membuat VNet dengan subnet yang didelegasikan dengan benar, gunakan Template VNet untuk Databricks VNet Injection.
  • Untuk menggunakan VNet yang ada saat Anda belum mendelegasikan subnet host dan kontainer, lihat Menambahkan atau menghapus delegasi subnet.

Aturan kelompok keamanan jaringan

Tabel berikut menampilkan aturan kelompok keamanan jaringan saat ini yang digunakan oleh Azure Databricks. Jika Azure Databricks perlu menambahkan aturan atau mengubah cakupan aturan yang ada dalam daftar ini, Anda akan menerima pemberitahuan terlebih dahulu. Artikel ini dan tabel akan diperbarui setiap kali modifikasi seperti itu terjadi.

Bagaimana Azure Databricks mengelola aturan kelompok keamanan jaringan

Aturan NSG yang tercantum di bagian berikut mewakili yang disediakan dan dikelola secara otomatis oleh Azure Databricks di NSG Anda, berdasarkan delegasi subnet host dan kontainer VNet Anda ke Microsoft.Databricks/workspaces layanan. Anda tidak memiliki izin untuk memperbarui atau menghapus aturan NSG ini dan upaya apa pun untuk melakukannya diblokir oleh delegasi subnet. Azure Databricks harus memiliki aturan ini untuk memastikan bahwa Microsoft dapat mengoperasikan dan mendukung layanan Azure Databricks dengan andal di VNet Anda.

Beberapa aturan NSG ini memiliki VirtualNetwork yang ditetapkan sebagai sumber dan tujuan. Ini telah diimplementasikan untuk menyederhanakan desain tanpa adanya tag layanan tingkat subnet di Azure. Semua kluster dilindungi oleh lapisan kedua kebijakan jaringan secara internal, sehingga kluster A tidak dapat tersambung ke kluster B di ruang kerja yang sama. Hal ini juga berlaku di beberapa ruang kerja jika ruang kerja Anda disebarkan ke dalam sepasang subnet yang berbeda di VNet yang dikelola pelanggan yang sama.

Penting

Databricks sangat menyarankan Agar Anda menambahkan aturan Tolak ke kelompok keamanan jaringan (NSG) yang dilampirkan ke jaringan dan subnet lain yang berada di VNet yang sama atau di-peering ke VNet tersebut. Tambahkan aturan Tolak untuk koneksi untuk koneksi masuk dan keluar sehingga membatasi koneksi ke dan dari sumber daya komputasi Azure Databricks. Jika kluster Anda memerlukan akses ke sumber daya di jaringan, tambahkan aturan untuk hanya mengizinkan jumlah akses minimal yang diperlukan untuk memenuhi persyaratan.

Aturan grup keamanan jaringan untuk ruang kerja

Informasi di bagian ini hanya berlaku bagi ruang kerja Azure Databricks yang dibuat setelah 13 Januari 2020. Jika ruang kerja Anda dibuat sebelum rilis konektivitas kluster yang aman (SCC) pada 13 Januari 2020, harap lihat tabel berikut.

Tabel ini mencantumkan aturan grup keamanan jaringan untuk ruang kerja dan menyertakan dua aturan grup keamanan masuk yang hanya disertakan jika konektivitas kluster aman (SCC) dinonaktifkan.

Arah Protokol Sumber Port sumber Tujuan Port Dest Terpakai
Masuk Apa pun JaringanVirtual Apa pun JaringanVirtual Mana pun Default
Masuk TCP AzureDatabricks (tag layanan)
Hanya jika SCC dinonaktifkan
Apa pun JaringanVirtual 22 IP Publik
Masuk TCP AzureDatabricks (tag layanan)
Hanya jika SCC dinonaktifkan
Apa pun JaringanVirtual 5557 IP Publik
Keluar TCP JaringanVirtual Mana pun AzureDatabricks (tag layanan) 443, 3306, 8443-8451 Default
Keluar TCP JaringanVirtual Mana pun SQL 3306 Default
Keluar TCP JaringanVirtual Mana pun Penyimpanan 443 Default
Keluar Apa pun JaringanVirtual Apa pun JaringanVirtual Mana pun Default
Keluar TCP JaringanVirtual Mana pun EventHub 9093 Default

Catatan

Jika Anda membatasi aturan keluar, Databricks menyarankan agar Anda membuka port 111 dan 2049 untuk mengaktifkan penginstalan pustaka tertentu.

Penting

Azure Databricks adalah layanan pihak pertama Microsoft Azure yang disebarkan pada infrastruktur Global Azure Public Cloud. Semua komunikasi antara komponen layanan, termasuk antara IP publik di sarana kontrol dan bidang komputasi pelanggan, tetap berada dalam backbone jaringan Microsoft Azure. Lihat juga Jaringan Microsoft global.

Pemecahan masalah

Kesalahan membuat ruang kerja

Subnet <subnet-id> memerlukan salah satu delegasi berikut [Microsoft.Databricks/workspaces] untuk merujuk tautan asosiasi layanan

Kemungkinan penyebab: Anda membuat ruang kerja di VNet yang subnet host dan kontainernya belum didelegasikan ke Microsoft.Databricks/workspaces layanan. Setiap subnet harus memiliki grup keamanan jaringan yang terlampir dan harus didelegasikan dengan benar. Lihat Persyaratan jaringan virtual untuk informasi selengkapnya.

Subnet <subnet-id> sudah digunakan oleh ruang kerja <workspace-id>

Kemungkinan penyebab: Anda membuat ruang kerja di VNet dengan subnet host dan kontainer yang sudah digunakan oleh ruang kerja Azure Databricks yang sudah ada. Anda tidak dapat membagikan beberapa ruang kerja di satu subnet. Anda harus memiliki sepasang subnet host dan kontainer baru untuk setiap ruang kerja yang Anda sebarkan.

Pemecahan Masalah

Instans yang Tidak Dapat Dijangkau: Sumber daya tidak dapat terjangkau melalui SSH.

Kemungkinan penyebab: lalu lintas dari sarana kontrol ke pekerja telah diblokir. Jika Anda melakukan penyebaran ke VNet yang ada yang terhubung ke jaringan lokal Anda, ulas pengaturan Anda menggunakan informasi yang disediakan di Menyambungkan ruang kerja Azure Databricks Anda ke jaringan lokal Anda.

Kegagalan Peluncuran Tidak Terduga: Kesalahan tidak terduka ditemukan saat menyiapkan kluster. Coba lagi dan hubungi Azure Databricks jika masalah terus berlanjut. Pesan kesalahan internal: Timeout while placing node.

Kemungkinan penyebab: lalu lintas dari pekerja ke titik akhir Azure Storage diblokir. Jika Anda menggunakan server DNS kustom, periksa juga status server DNS di VNet Anda.

Kegagalan Peluncuran Penyedia Cloud: Kesalahan penyedia cloud ditemukan saat menyiapkan kluster. Lihat panduan Azure Databricks untuk informasi selengkapnya. Kode galat Azure: AuthorizationFailed/InvalidResourceReference.

Kemungkinan penyebab: VNet atau subnet tidak ada lagi. Pastikan VNet dan subnet ada.

Kluster diakhiri. Alasan: Spark Startup Failure: Spark tidak dapat dimulai tepat waktu. Masalah ini dapat disebabkan oleh metastore Hive yang tidak berfungsi, konfigurasi Spark yang tidak valid, atau skrip init yang tidak berfungsi. Lihat log driver Spark untuk memecahkan masalah ini, dan hubungi Databricks jika masalah masih berlanjut. Pesan kesalahan internal: Spark failed to start: Driver failed to start in time.

Kemungkinan penyebab: Kontainer tidak dapat berbicara dengan instans hosting atau akun penyimpanan DBFS. Perbaiki hal ini dengan menambahkan rute kustom ke subnet untuk akun penyimpanan DBFS dengan Internet sebagai hop berikutnya.