Bagikan melalui


Keterandalan di Azure Databricks

Azure Databricks adalah data kolaboratif berbasis Apache Spark dan platform AI yang dioptimalkan untuk Microsoft Azure. Ini menyediakan lingkungan terpadu untuk beban kerja big data dan AI dan menggabungkan yang terbaik dari Databricks dan Azure untuk menyederhanakan rekayasa data, ilmu data, dan pembelajaran mesin.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan bagaimana Azure Databricks mempertahankan ketahanan terhadap berbagai potensi pemadaman dan masalah dan bagaimana Anda dapat mengonfigurasi ketahanan untuk memenuhi kebutuhan Anda. Panduan ini mencakup kesalahan sementara, pemadaman zona ketersediaan, pemadaman wilayah, dan pemeliharaan layanan. Artikel ini juga menjelaskan cara menggunakan cadangan untuk memulihkan dari masalah lain dan menyoroti informasi utama tentang perjanjian tingkat layanan (SLA) Azure Databricks.

Rekomendasi penyebaran produksi

Untuk mempelajari cara menyebarkan Azure Databricks untuk mendukung persyaratan keandalan solusi Anda dan bagaimana keandalan memengaruhi aspek lain dari arsitektur Anda, lihat Praktik terbaik arsitektur untuk Azure Databricks.

Gambaran umum arsitektur keandalan

Anda harus memahami keandalan setiap komponen utama di Azure Databricks:

  • Sarana kontrol adalah kumpulan layanan stateless yang mengelola metadata ruang kerja, akses pengguna, penjadwalan pekerjaan, dan manajemen kluster. Layanan ini didukung oleh database yang direplikasi di seluruh zona ketersediaan di wilayah yang didukung.

  • Akar Databricks File System (DBFS) adalah akun penyimpanan yang disediakan Azure Databricks secara otomatis saat Anda membuat ruang kerja Azure Databricks di akun cloud Anda. Kami menyarankan agar Anda tidak menyimpan data di root DBFS dan menonaktifkan akun penyimpanan ini jika memungkinkan.

  • Penyimpanan Unity Catalog menyertakan satu atau beberapa akun penyimpanan yang menyimpan data Unity Catalog Anda di akun cloud Anda. Untuk informasi selengkapnya, lihat Ringkasan Katalog Unity.

  • Bidang komputasi menjalankan beban kerja pemrosesan data dengan menggunakan kluster komputer virtual (VM). Bidang komputasi menangani kesalahan sementara dan secara otomatis menggantikan simpul yang gagal tanpa intervensi pengguna. Anda dapat memilih dari beberapa jenis sumber daya komputasi. Untuk informasi selengkapnya, lihat Komputasi.

    Ketersediaan ruang kerja tergantung pada ketersediaan sarana kontrol, tetapi kluster komputasi dapat terus memproses pekerjaan bahkan selama gangguan sarana kontrol.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Anda dapat mengontrol percobaan ulang tugas dalam Pekerjaan Lakeflow untuk membantu memulihkan dari kesalahan sementara.

Untuk aplikasi yang berjalan di Azure Databricks, terapkan logika coba lagi dengan backoff eksponensial saat Anda terhubung ke layanan eksternal atau layanan Azure, seperti Storage, Azure SQL Database, atau Azure Event Hubs. Databricks Runtime mencakup ketahanan bawaan untuk banyak layanan Azure, tetapi kode aplikasi Anda harus menangani kegagalan sementara khusus layanan.

Ketahanan terhadap kegagalan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Azure Databricks mendukung redundansi zona untuk setiap komponen:

  • Sarana kontrol: Di wilayah yang mendukung zona ketersediaan, sarana kontrol berjalan di beberapa zona ketersediaan. Sarana kontrol menangani kegagalan zona secara otomatis, dengan dampak minimal dan tidak diperlukan intervensi pengguna.

    Data ruang kerja sarana kontrol disimpan dalam database. Di wilayah yang mendukung zona ketersediaan, database direplikasi di beberapa zona di wilayah tersebut. Akun penyimpanan yang mengelola gambar Databricks Runtime juga redundan di wilayah tersebut. Semua wilayah memiliki akun penyimpanan sekunder yang digunakan saat akun penyimpanan utama tidak berfungsi.

  • Akar DBFS: Di wilayah yang mendukung zona ketersediaan, Anda dapat mengonfigurasi akun penyimpanan untuk Akar DBFS untuk menggunakan penyimpanan zona redundan (ZRS). Di wilayah berpasangan yang mendukung zona ketersediaan, Anda dapat secara opsional menggunakan penyimpanan geo-zona-redundan (GZRS).

  • Bidang komputasi: Databricks mendukung distribusi zona otomatis untuk sumber daya komputasi, yang berarti bahwa sumber daya Anda didistribusikan di beberapa zona ketersediaan. Distribusi ini membantu beban kerja produksi Anda mencapai ketahanan terhadap pemadaman zona.

    Saat Anda menggunakan komputasi tanpa server, Anda tidak secara eksplisit memilih zona untuk komputasi Anda. Databricks mengelola pemilihan zona VM dan penggantian VM yang mungkin hilang karena pemadaman zona.

Persyaratan

Untuk menggunakan dukungan zona ketersediaan di Azure Databricks, Anda memerlukan persyaratan berikut:

  • Dukungan wilayah: Dukungan zona ketersediaan Azure Databricks tersedia di semua wilayah Azure yang mendukung Azure Databricks dan menyediakan zona ketersediaan. Untuk daftar wilayah yang mendukung Azure Databricks, lihat Produk yang tersedia menurut wilayah. Untuk daftar lengkap wilayah yang mendukung zona ketersediaan, lihat Wilayah Azure yang mendukung zona ketersediaan.

  • Replikasi penyimpanan: Konfigurasikan akun penyimpanan ruang kerja untuk menggunakan ZRS atau GZRS (jika tersedia).

  • Kapasitas komputasi: Pastikan kapasitas komputasi yang memadai ada di beberapa zona di wilayah target Anda. Azure Databricks secara otomatis mendistribusikan simpul kluster di seluruh zona, tetapi Anda harus memverifikasi bahwa jenis instans yang Anda pilih tersedia di semua zona target.

Pertimbangan

Azure Databricks secara otomatis mendistribusikan node kluster di seluruh zona ketersediaan. Distribusi tergantung pada kapasitas yang tersedia di setiap zona. Selama periode permintaan tinggi, node kluster mungkin terkonsentrasi di lebih sedikit zona. Saat Anda menggunakan komputasi tanpa server, Azure Databricks mengelola pemilihan zona VM dan penggantian VM yang mungkin hilang karena pemadaman zona.

Biaya

Distribusi zona tidak memengaruhi biaya komputasi karena Anda membayar jumlah VM yang sama terlepas dari penempatan zona ketersediaannya. Untuk informasi selengkapnya, lihat Harga komputasi Azure Databricks.

Redundansi default untuk akun penyimpanan terkelola, atau akar DBFS, adalah penyimpanan geo-redundan (GRS). Mengubah ke ZRS atau GZRS dapat memengaruhi biaya penyimpanan Anda. Untuk informasi selengkapnya, lihat Harga Azure Blob Storage.

Mengonfigurasi dukungan zona ketersediaan

  • Sarana kontrol: Sarana kontrol secara otomatis mendukung redundansi zona di wilayah yang memiliki zona ketersediaan. Anda tidak perlu mengonfigurasi apa pun.

  • Akar DBFS: Anda dapat mengonfigurasi redundansi zona untuk penyimpanan akar DBFS saat membuat ruang kerja baru atau memodifikasi ruang kerja yang ada:

    • Buat ruang kerja baru dengan penyimpanan DBFS Root zona-redundan: Saat membuat ruang kerja Azure Databricks baru, Anda dapat secara opsional mengonfigurasi akun penyimpanan terkait untuk menggunakan ZRS atau GZRS alih-alih GRS default. Untuk informasi selengkapnya, lihat Mengubah opsi redundansi penyimpanan ruang kerja.

    • Aktifkan redundansi zona pada penyimpanan akar DBFS: Untuk ruang kerja yang ada, Anda dapat mengubah konfigurasi redundansi akun penyimpanan ruang kerja menjadi ZRS atau GZRS. Untuk informasi selengkapnya tentang cara mengaktifkan redundansi zona, lihat Mengubah pengaturan replikasi untuk akun penyimpanan.

  • Bidang komputasi: Node kluster didistribusikan secara otomatis di seluruh zona ketersediaan. Tidak diperlukan konfigurasi pelanggan untuk distribusi zona.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika ruang kerja dikonfigurasi dengan dukungan zona ketersediaan dan semua zona ketersediaan beroperasi.

  • Replikasi data antar zona: Replikasi data untuk penyimpanan ruang kerja terjadi secara sinkron di seluruh zona ketika akar DBFS menggunakan akun ZRS atau GZRS. Pendekatan ini memastikan konsistensi yang kuat dengan dampak performa minimal.

  • Perutean lalu lintas antar zona: Azure Databricks secara otomatis mendistribusikan node kluster di seluruh zona selama pembuatan kluster. Layanan menyeimbangkan beban komputasi di seluruh zona sambil mempertahankan lokalitas data untuk performa optimal.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika ruang kerja dikonfigurasi dengan dukungan zona ketersediaan dan ada pemadaman zona ketersediaan.

  • Deteksi dan respons: Microsoft secara otomatis mendeteksi kegagalan zona dan memulai prosedur respons. Anda tidak perlu mengambil tindakan apa pun untuk failover tingkat zona.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Tetapi Anda dapat menggunakan halaman status Azure Databricks untuk melihat gambaran umum semua layanan Inti Azure Databricks. Anda juga dapat berlangganan pembaruan status pada komponen layanan individual dan menerima pemberitahuan saat status layanan yang Anda berlangganan berubah.

  • Permintaan aktif: Kluster yang sedang berjalan mungkin kehilangan simpul di zona yang terpengaruh. Manajer kluster secara otomatis meminta simpul penggantian dari zona yang tersisa. Jika node driver hilang, kluster dan pekerjaan dimulai ulang sepenuhnya.

  • Kehilangan data yang diharapkan:

    • Sarana kontrol: Tidak mengharapkan kehilangan data selama pemadaman zona.

    • Akar DBFS: Data ruang kerja tetap tersedia jika menggunakan konfigurasi penyimpanan ZRS atau GZRS.

    • Bidang komputasi: Data yang di-cache pada VM bersifat ephemeral. Setiap data yang hilang dari VM selama kegagalan zona dipulihkan dari penyimpanan. Jika simpul driver hilang, pekerjaan dimulai ulang dan mengolah ulang hasilnya.

  • Waktu henti yang diharapkan:

    • Sarana kontrol: Sarana kontrol Databricks melakukan failover otomatis ke zona sehat dalam waktu sekitar 15 menit.

    • Akar DBFS: Tidak mengharapkan waktu henti untuk akun penyimpanan yang menggunakan ZRS atau GZRS.

    • Bidang komputasi: Jika simpul hilang karena VM mereka berada di zona ketersediaan yang terpengaruh, manajer kluster Azure meminta simpul pengganti dari penyedia komputasi Azure. Jika zona sehat yang tersisa memiliki kapasitas yang cukup untuk memenuhi permintaan, penyedia komputasi menarik simpul dari zona sehat untuk menggantikan node yang hilang. Proses ini mungkin memerlukan waktu beberapa menit.

      Jika simpul driver hilang karena kegagalan zona, seluruh kluster dimulai ulang, yang dapat menyebabkan waktu pemulihan yang lebih lama dibandingkan dengan kehilangan simpul pekerja. Rencanakan perilaku ini dalam strategi penjadwalan dan pemantauan pekerjaan Anda.

      Anda dapat menggunakan teknologi tanpa server atau kumpulan instansi untuk mengurangi waktu ini.

  • Pengalihan lalu lintas:

    • Sarana kontrol: Sarana kontrol Databricks melakukan failover otomatis ke zona sehat dalam waktu sekitar 15 menit.

    • Akar DBFS: Azure Storage secara otomatis mengalihkan permintaan ke kluster penyimpanan di zona sehat.

    • Bidang komputasi: Manajer kluster secara otomatis beralih ke simpul di zona sehat.

Pemulihan Zona

Saat zona ketersediaan yang gagal pulih, Azure Databricks secara otomatis melanjutkan operasi normal di semua zona. Manajer kluster mungkin menyeimbangkan distribusi node selama pembuatan node berikutnya, tetapi node yang ada terus berjalan di zona mereka yang sekarang hingga dihentikan.

Anda tidak perlu melakukan tindakan apa pun untuk operasi failback. Distribusi zona normal dilanjutkan untuk penyebaran kluster baru.

Uji kegagalan zona

Azure Databricks adalah layanan terkelola di mana Microsoft menangani failover zona secara otomatis dan melakukan uji penurunan zona secara teratur. Anda tidak perlu menguji skenario kegagalan zona untuk layanan itu sendiri.

Untuk aplikasi Anda yang berjalan di Azure Databricks, uji ketahanan pekerjaan dengan mensimulasikan kegagalan node driver dan memantau perilaku hidupkan ulang kluster. Validasi bahwa pekerjaan pemrosesan data Anda dapat menangani mulai ulang kluster dan melanjutkan dari titik pemeriksaan yang sesuai.

Ketahanan terhadap kegagalan di seluruh wilayah

Azure Databricks adalah layanan wilayah tunggal. Jika wilayah tidak tersedia, ruang kerja Anda juga tidak tersedia. Jika Anda memerlukan penyebaran multi-wilayah, lihat Pemulihan bencana Azure Databricks.

Solusi multi-wilayah kustom untuk ketahanan

Azure Databricks tidak menyediakan kemampuan multi-wilayah bawaan. Untuk perlindungan multi-wilayah yang komprehensif dari beban kerja analitik, Anda harus menerapkan pendekatan Anda sendiri.

Solusi multi-wilayah yang khas melibatkan dua ruang kerja atau lebih. Anda dapat memilih dari beberapa strategi, termasuk arsitektur aktif-pasif dan aktif-aktif.

Untuk memilih arsitektur, pertimbangkan faktor-faktor berikut:

  • Kekritisan beban kerja untuk bisnis Anda
  • Durasi potensi gangguan (jam atau mungkin sehari penuh)
  • Upaya yang diperlukan untuk membuat ruang kerja beroperasi penuh
  • Upaya yang diperlukan untuk memulihkan atau mengembalikan ke wilayah utama

Untuk beban kerja yang memerlukan perlindungan multi-wilayah, lihat Pemulihan bencana Azure Databricks.

Pencadangan dan pemulihan

Azure Databricks secara otomatis mencadangkan database sebagai bagian dari operasi terkelola dari layanan. Proses ini mencakup konten buku catatan, definisi pekerjaan, konfigurasi kluster, dan pengaturan kontrol akses.

Nota

Jika kegagalan zona terjadi, Azure Databricks tidak mengharapkan kehilangan data.

Kami sarankan Anda menyimpan data Anda di penyimpanan Unity Catalog. Anda dapat mereplikasi data melalui replikasi penyimpanan atau kloning delta.

Kemampuan pencadangan dan pemulihan pada tingkat ruang kerja tidak tersedia langsung. Rencanakan prosedur rekreasi ruang kerja yang mencakup memulihkan konfigurasi, pengguna, dan kontrol akses dari proses sinkronisasi Anda.

Ketahanan terhadap pemeliharaan layanan

Azure Databricks melakukan pemeliharaan platform otomatis untuk menerapkan pembaruan keamanan, menyebarkan fitur baru, dan meningkatkan keandalan layanan. Anda dapat mengonfigurasi jendela pemeliharaan untuk kluster Anda untuk mengurangi kemungkinan pemeliharaan yang memengaruhi beban kerja produksi Anda. Untuk informasi selengkapnya, lihat Pembaruan kluster otomatis.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.