Pemulihan dari bencana

Pola pemulihan bencana yang jelas sangat penting untuk platform analitik data cloud asli seperti Azure Databricks. Sangat penting bahwa tim data Anda dapat menggunakan platform Azure Databricks bahkan dalam kasus langka pemadaman penyedia layanan cloud di seluruh layanan regional, baik yang disebabkan oleh bencana regional seperti badai atau gempa bumi, atau sumber lainnya.

Azure Databricks sering menjadi bagian inti dari ekosistem data keseluruhan yang mencakup banyak layanan, termasuk layanan penyerapan data hulu (batch/streaming), penyimpanan asli cloud seperti ADLS gen2 (untuk ruang kerja yang dibuat sebelum 6 Maret 2023, Azure Blob Storage), alat dan layanan hilir seperti aplikasi kecerdasan bisnis, dan alat orkestrasi. Beberapa kasus penggunaan Anda mungkin sangat sensitif terhadap penghentian di seluruh layanan regional.

Artikel ini menjelaskan konsep dan praktik terbaik untuk solusi pemulihan bencana antarregional yang sukses untuk platform Databricks.

Jaminan ketersediaan tinggi di dalam wilayah

Meskipun topik lainnya berfokus pada implementasi pemulihan bencana lintas wilayah, penting untuk memahami jaminan ketersediaan tinggi yang disediakan Azure Databricks di dalam satu wilayah. Jaminan ketersediaan tinggi di dalam wilayah mencakup komponen berikut:

Ketersediaan sarana kontrol Azure Databricks

• Sebagian besar layanan sarana kontrol berjalan pada kluster Kubernetes, dan akan menangani kehilangan VM di AZ tertentu secara otomatis.
• Data ruang kerja disimpan dalam database dengan penyimpanan premium, direplikasi di seluruh wilayah. Penyimpanan database (server tunggal) tidak direplikasi di berbagai AZ atau wilayah. Jika pemadaman zona berdampak pada penyimpanan database, database dipulihkan dengan memunculkan instans baru dari cadangan.
• Akun penyimpanan yang digunakan untuk menyajikan gambar DBR juga berlebihan di dalam wilayah, dan semua wilayah memiliki akun penyimpanan sekunder yang digunakan saat primer tidak berfungsi. Lihat Wilayah Azure Databricks.
• Secara umum, fungsionalitas sarana kontrol harus dipulihkan dalam ~15 menit setelah zona ketersediaan pulih.

Ketersediaan bidang komputasi

• Ketersediaan ruang kerja tergantung pada ketersediaan sarana kontrol (seperti yang dijelaskan di atas).
• Data di DBFS Root tidak terpengaruh jika akun penyimpanan untuk DBFS Root dikonfigurasi dengan ZRS atau GZRS (defaultnya adalah GRS).
• Simpul untuk kluster ditarik dari zona ketersediaan yang berbeda dengan meminta simpul dari penyedia komputasi Azure (dengan asumsi kapasitas yang cukup di zona yang tersisa untuk memenuhi permintaan). Jika node hilang, manajer kluster meminta node penggantian dari penyedia komputasi Azure, yang menariknya dari AZ yang tersedia. Satu-satunya pengecualian adalah ketika simpul driver hilang. Dalam hal ini, pekerjaan atau manajer kluster memulai ulang mereka.

Gambaran umum pemulihan bencana

Pemulihan bencana melibatkan serangkaian kebijakan, alat, dan prosedur yang memungkinkan pemulihan atau kelanjutan infrastruktur dan sistem teknologi vital setelah bencana alam atau yang disebabkan oleh manusia. Layanan cloud besar seperti Azure melayani banyak pelanggan dan memiliki pelindung bawaan terhadap satu kegagalan. Misalnya, suatu wilayah adalah sekelompok bangunan yang tersambung ke sumber daya yang berbeda untuk menjamin bahwa kehilangan daya tunggal tidak akan menonaktifkan suatu wilayah. Namun, kegagalan wilayah cloud dapat terjadi, dan tingkat gangguan serta dampaknya terhadap organisasi Anda dapat beragam.

Sebelum menerapkan rencana pemulihan bencana, penting untuk memahami perbedaan antara pemulihan bencana (DR) dan high availability (HA).

High availability adalah karakteristik ketahanan dari suatu sistem. High availability memastikan tingkat minimum performa operasional yang biasanya didefinisikan dalam hal persentase waktu aktif atau waktu aktif yang konsisten. High availability siap diterapkan (di wilayah yang sama dengan sistem prime rAnda) dengan merancangnya sebagai fitur dari sistem primer. Misalnya, layanan cloud seperti Azure memiliki layanan ketersediaan tinggi seperti ADLS gen2 (untuk ruang kerja yang dibuat sebelum 6 Maret 2023, Azure Blob Storage). High availability tidak memerlukan persiapan eksplisit yang signifikan dari pelanggan Azure Databricks.

Sebaliknya, rencana pemulihan bencana membutuhkan keputusan dan solusi yang bekerja untuk organisasi tertentu untuk menangani penghentian regional yang lebih besar untuk sistem penting. Artikel ini membahas terminologi pemulihan bencana umum, solusi umum, dan beberapa praktik terbaik untuk rencana pemulihan bencana dengan Azure Databricks.

Terminologi

Terminologi wilayah

Artikel ini menggunakan definisi berikut untuk wilayah:

• Wilayah primer: Wilayah geografis tempat pengguna menjalankan beban kerja analitik data interaktif dan otomatis harian tipikal.

• Wilayah sekunder: Wilayah geografis tempat tim TI memindahkan beban kerja analitik data sementara selama penghentian di wilayah primer.

• Penyimpanan geo-redundan: Azure memiliki penyimpanan geo-redundan di seluruh wilayah untuk penyimpanan yang dipertahankan menggunakan proses replikasi penyimpanan asinkron.

  Penting

  Untuk proses pemulihan bencana, Databricks menyarankan agar Anda tidak mengandalkan penyimpanan geo-redundan untuk duplikasi data lintas wilayah seperti ADLS gen2 Anda (untuk ruang kerja yang dibuat sebelum 6 Maret 2023, Azure Blob Storage) yang dibuat Azure Databricks untuk setiap ruang kerja di langganan Azure Anda. Secara umum, gunakan Deep Clone untuk Tabel Delta dan konversikan data ke format Delta untuk menggunakan Deep Clone jika memungkinkan untuk format data lainnya.

Terminologi status penyebaran

Artikel ini menggunakan definisi status penyebaran berikut:

• Penyebaran aktif: Pengguna dapat terhubung ke penyebaran aktif ruang kerja Azure Databricks dan menjalankan beban kerja. Pekerjaan dijadwalkan secara berkala menggunakan penjadwal Azure Databricks atau mekanisme lainnya. Aliran juga dapat dijalankan pada penyebaran ini. Beberapa dokumen mungkin menyebut penyebaran aktif sebagai penyebaran hot.

• Penyebaran pasif: Proses tidak berjalan pada penyebaran pasif. Tim TI dapat menyiapkan prosedur otomatis untuk menyebarkan kode, konfigurasi, dan objek Azure Databricks lainnya ke penyebaran pasif. Penyebaran menjadi aktif hanya jika penyebaran aktif saat ini sedang tidak berfungsi. Beberapa dokumen mungkin menyebut penyebaran pasif sebagai penyebaran cool.

  Penting

  Suatu proyek secara opsional dapat menyertakan beberapa penyebaran pasif di berbagai wilayah guna memberikan opsi tambahan untuk menyelesaikan penghentian regional.

Secara umum, sebuah tim hanya memiliki satu penyebaran aktif pada satu waktu, yang disebut strategi pemulihan bencana aktif-pasif. Ada strategi solusi pemulihan bencana yang kurang umum yang disebut aktif-aktif, yaitu ada dua penyebaran aktif simultan.

Terminologi industri pemulihan bencana

Ada dua istilah industri penting yang harus Anda pahami dan definisikan untuk tim Anda:

• Tujuan titik pemulihan: Tujuan titik pemulihan (RPO) adalah periode target maksimum untuk data (transaksi) dapat hilang dari layanan TI karena insiden parah. Penyebaran Azure Databricks Anda tidak menyimpan data pelanggan utama. Itu disimpan dalam sistem terpisah seperti ADLS gen2 (untuk ruang kerja yang dibuat sebelum 6 Maret 2023, Azure Blob Storage) atau sumber data lainnya di bawah kontrol Anda. Sarana kontrol Azure Databricks menyimpan beberapa objek sebagian atau seluruhnya, seperti pekerjaan dan buku catatan. Untuk Azure Databricks, RPO didefinisikan sebagai periode target maksimum untuk objek seperti perubahan pekerjaan dan buku catatan dapat hilang. Selain itu, Anda bertanggung jawab untuk mendefinisikan RPO untuk data pelanggan Anda sendiri di ADLS gen2 (untuk ruang kerja yang dibuat sebelum 6 Maret 2023, Azure Blob Storage) atau sumber data lainnya di bawah kendali Anda.

• Tujuan waktu pemulihan: Tujuan waktu pemulihan (RTO) adalah durasi waktu yang ditargetkan dan tingkat layanan untuk proses bisnis harus dipulihkan setelah bencana.

  

Pemulihan bencana dan kerusakan data

Solusi pemulihan bencana tidak mengurangi kerusakan data. Data yang rusak di wilayah primer direplikasi dari wilayah primer ke wilayah sekunder dan yang rusak di kedua wilayah. Ada cara lain untuk mengurangi kegagalan semacam ini, misalnya Perjalanan Waktu Delta.

Alur kerja pemulihan tipikal

Skenario pemulihan bencana Azure Databricks biasanya dimainkan dengan cara berikut:

1. Kegagalan terjadi dalam layanan penting yang Anda gunakan di wilayah primer. Kegagalan ini dapat berupa layanan sumber data atau jaringan yang memengaruhi penyebaran Azure Databricks.

2. Anda menyelidiki situasi dengan penyedia cloud.

3. Jika Anda menyimpulkan bahwa perusahaan tidak dapat menunggu hingga masalah diperbaiki di wilayah primer, Anda dapat memutuskan bahwa Anda perlu melakukan failover ke wilayah sekunder.

4. Pastikan bahwa masalah yang sama tidak memengaruhi wilayah sekunder juga.

5. Melakukan failover ke wilayah sekunder.

   1. Hentikan semua aktivitas di ruang kerja. Pengguna menghentikan beban kerja. Pengguna atau administrator diinstruksikan untuk membuat file cadangan perubahan terbaru jika memungkinkan. Pekerjaan ditutup jika belum gagal akibat penghentian.
   2. Mulai prosedur pemulihan di wilayah sekunder. Prosedur pemulihan memperbarui perutean serta penggantian nama koneksi dan lalu lintas ke wilayah sekunder.
   3. Setelah pengujian, nyatakan operasional wilayah sekunder. Beban kerja produksi sekarang dapat dilanjutkan. Pengguna dapat masuk ke penyebaran yang saat ini aktif. Anda dapat mencoba kembali pekerjaan yang dijadwalkan atau tertunda.

   Untuk langkah-langkah terperinci dalam konteks Azure Databricks, lihat Uji failover.

6. Dalam beberapa kasus, masalah di wilayah primer dikurangi dan Anda mengonfirmasi fakta ini.

7. Pulihkan (failback) ke wilayah primer Anda.

   1. Hentikan semua pekerjaan di wilayah sekunder.
   2. Mulai prosedur pemulihan di wilayah primer. Prosedur pemulihan menangani perutean serta penggantian nama koneksi dan lalu lintas kembali ke wilayah primer.
   3. Replikasi data kembali ke wilayah primer sesuai kebutuhan. Untuk mengurangi kompleksitas, mungkin juga meminimalkan jumlah data yang perlu direplikasi. Misalnya, jika beberapa pekerjaan bersifat baca-saja saat dijalankan dalam penyebaran sekunder, Anda mungkin tidak perlu mereplikasi data tersebut kembali ke penyebaran primer di wilayah primer. Namun, Anda mungkin memiliki satu pekerjaan produksi yang perlu dijalankan dan mungkin memerlukan replikasi data kembali ke wilayah primer.
   4. Uji penyebaran di wilayah primer.
   5. Nyatakan operasional wilayah primer Anda dan nyatakan bahwa itu adalah penyebaran aktif Anda. Lanjutkan beban kerja produksi.

   Untuk informasi selengkapnya tentang pemulihan ke wilayah primer, lihat Pemulihan pengujian (failback).

Penting

Selama langkah-langkah ini, beberapa kehilangan data dapat terjadi. Organisasi Anda harus menentukan berapa banyak kehilangan data yang dapat diterima dan apa yang dapat Anda lakukan untuk mengurangi kehilangan ini.

Langkah 1: Memahami kebutuhan bisnis Anda

Langkah pertama adalah menentukan dan memahami kebutuhan bisnis Anda. Tentukan layanan data mana yang penting dan apa RPO dan RTO yang diharapkan.

Kumpulkan keterangan mengenai toleransi dunia nyata untuk setiap sistem, dan ingat bahwa failover dan failback pemulihan bencana bisa mahal dan menimbulkan risiko lain. Risiko lain mungkin meliputi kerusakan data, duplikasi data jika Anda menuliskan ke lokasi penyimpanan yang salah, serta pengguna yang masuk dan membuat perubahan di tempat yang salah.

Memetakan semua titik integrasi Azure Databricks yang memengaruhi bisnis:

• Apakah solusi pemulihan bencana perlu mengakomodasi proses interaktif, proses otomatis, atau keduanya?
• Layanan data apa yang Anda gunakan? Beberapa mungkin lokal.
• Bagaimana data input sampai ke cloud?
• Siapa yang menggunakan data ini? Proses apa yang menggunakannya di hilir?
• Apakah ada integrasi pihak ketiga yang perlu diwaspadai untuk perubahan pemulihan bencana?

Menentukan alat atau strategi komunikasi yang dapat mendukung rencana pemulihan bencana:

• Alat apa yang akan Anda gunakan untuk mengubah konfigurasi jaringan dengan cepat?
• Dapatkah Anda menjelaskan konfigurasi Anda dan membuatnya modular untuk mengakomodasi solusi pemulihan bencana dengan cara yang alami dan dapat dipertahankan?
• Alat dan saluran komunikasi apa yang akan memberi tahu tim internal dan pihak ketiga (integrasi, konsumen hilir) tentang perubahan failover dan failback pemulihan bencana? Dan bagaimana Anda akan mengonfirmasi pernyataan mereka?
• Alat atau dukungan khusus apa yang akan diperlukan?
• Layanan apa yang disiapkan jika ada yang akan dinonaktifkan hingga pemulihan total?

Langkah 2: Memilih proses yang memenuhi kebutuhan bisnis

Solusi Anda harus mereplikasi data yang benar di sarana kontrol, sarana komputasi, dan sumber data. Ruang kerja redundan untuk pemulihan bencana harus memetakan ke sarana kontrol yang berbeda di berbagai wilayah. Anda harus memastikan data tersebut tetap sinkron secara berkala menggunakan solusi berbasis skrip, baik alat sinkronisasi atau alur kerja CI/CD. Tidak perlu menyinkronkan data dari dalam jaringan sarana komputasi itu sendiri, seperti dari pekerja Databricks Runtime.

Jika menggunakan fitur injeksi VNet (tidak tersedia pada semua jenis langganan dan penyebaran), Anda dapat menyebarkan jaringan tersebut secara konsisten di kedua wilayah menggunakan alat berbasis templat seperti Terraform.

Selain itu, Anda perlu memastikan bahwa sumber data direplikasi sesuai kebutuhan di seluruh wilayah.

Praktik terbaik umum

Praktik terbaik umum untuk keberhasilan rencana pemulihan bencana meliputi:

1. Pahami proses mana yang penting untuk bisnis dan harus berjalan dalam pemulihan bencana.

2. Identifikasi dengan jelas layanan mana yang terlibat, data mana yang sedang diproses, bagaimana aliran datanya, dan di mana penyimpanannya

3. Isolasi layanan dan data sebanyak mungkin. Misalnya, buat kontainer penyimpanan cloud khusus untuk data pemulihan bencana atau pindahkan objek Azure Databricks yang diperlukan selama bencana ke ruang kerja terpisah.

4. Anda bertanggung jawab untuk menjaga integritas antara penyebaran primer dan sekunder terhadap objek lain yang tidak disimpan di Sarana Kontrol Databricks.

   Peringatan

   Ini adalah praktik terbaik untuk tidak menyimpan data di ADLS gen2 akar (untuk ruang kerja yang dibuat sebelum 6 Maret 2023, Azure Blob Storage) yang digunakan untuk akses root DBFS untuk ruang kerja. Penyimpanan akar DBFS tersebut tidak didukung untuk data pelanggan produksi. Databricks juga merekomendasikan untuk tidak menyimpan pustaka, file konfigurasi, atau skrip init di lokasi ini.

5. Untuk sumber data, jika memungkinkan, sebaiknya Anda menggunakan alat Azure asli terhadap replikasi dan redundansi untuk mereplikasi data ke wilayah pemulihan bencana.

Pilih strategi solusi pemulihan

Solusi pemulihan bencana biasanya melibatkan dua (atau mungkin lebih) ruang kerja. Ada beberapa strategi yang dapat Anda pilih. Pertimbangkan potensi lamanya gangguan (beberapa jam atau bahkan mungkin sehari), upaya untuk memastikan bahwa ruang kerja beroperasi penuh, dan upaya untuk memulihkan (failback) ke wilayah primer.

Strategi solusi aktif-pasif

Solusi aktif-pasif adalah solusi yang paling umum dan termudah, dan jenis solusi ini adalah fokus artikel ini. Solusi aktif-pasif menyinkronkan perubahan data dan objek dari penyebaran aktif ke penyebaran pasif. Jika mau, Anda dapat menjalankan beberapa penyebaran pasif di berbagai wilayah, tetapi artikel ini berfokus pada pendekatan penyebaran pasif tunggal. Selama peristiwa pemulihan bencana, penyebaran pasif di wilayah sekunder menjadi penyebaran aktif Anda.

Ada dua varian utama untuk strategi ini:

• Solusi terpadu (dari segi perusahaan): Serangkaian penyebaran aktif dan pasif yang mendukung seluruh organisasi.
• Solusi berdasarkan departemen atau proyek: Setiap departemen atau domain proyek mempertahankan solusi pemulihan bencana terpisah. Beberapa organisasi ingin memisahkan detail pemulihan bencana di antara departemen serta menggunakan wilayah primer dan sekunder yang berbeda untuk setiap tim berdasarkan kebutuhan unik masing-masing tim.

Ada varian lain, seperti menggunakan penyebaran pasif untuk kasus penggunaan baca-saja. Jika Anda memiliki beban kerja yang bersifat baca-saja, misalnya kueri pengguna, kueri tersebut dapat berjalan pada solusi pasif kapan saja jika tidak mengubah data atau objek Azure Databricks seperti buku catatan atau pekerjaan.

Strategi solusi aktif-aktif

Dalam solusi aktif-aktif, Anda menjalankan semua proses data di kedua wilayah setiap saat secara paralel. Tim operasi Anda harus memastikan bahwa proses data seperti pekerjaan ditandai sebagai selesai hanya jika berhasil selesai di kedua wilayah. Objek tidak dapat diubah selama produksi dan harus mengikuti promosi CI/CD yang ketat sejak pengembangan/penahapan hingga produksi.

Solusi aktif-aktif adalah strategi yang paling kompleks, dan karena pekerjaan berjalan di kedua wilayah, ada biaya tambahan.

Sama seperti strategi aktif-pasif, Anda dapat menerapkan solusi ini sebagai solusi organisasi terpadu atau berdasarkan departemen.

Anda mungkin tidak memerlukan ruang kerja yang setara di sistem sekunder untuk semua ruang kerja, tergantung pada alur kerja Anda. Misalnya, ruang kerja pengembangan atau penahapan mungkin tidak memerlukan duplikasi. Dengan alur pengembangan yang dirancang dengan baik, Anda mungkin dapat merekonstruksi ruang kerja tersebut dengan mudah jika diperlukan.

Memilih alat

Ada dua pendekatan utama terhadap alat untuk menjaga data semirip mungkin antara ruang kerja di wilayah primer dan sekunder:

• Klien sinkronisasi yang menyalin dari primer ke sekunder: Klien sinkronisasi mengirim data produksi dan aset dari wilayah primer ke wilayah sekunder. Ini biasanya berjalan secara terjadwal.
• Alat CI/CD untuk penyebaran paralel: Untuk kode produksi dan aset, gunakan alat CI/CD yang mendorong perubahan pada sistem produksi secara simultan ke kedua wilayah. Misalnya, saat mendorong kode dan aset dari penahapan/pengembangan ke produksi, sistem CI/CD membuatnya tersedia di kedua wilayah secara bersamaan. Ide intinya adalah memperlakukan semua artefak di ruang kerja Azure Databricks sebagai infrastruktur sebagai kode. Sebagian besar artefak dapat disebarkan bersama ke ruang kerja primer dan sekunder, sementara beberapa artefak mungkin perlu disebarkan hanya setelah peristiwa pemulihan bencana. Untuk alat, lihat Skrip, sampel, dan prototipe automasi.

Diagram berikut membedakan kedua pendekatan tersebut.

Tergantung pada kebutuhan, Anda dapat menggabungkan kedua pendekatan tersebut. Misalnya, gunakan CI/CD untuk kode sumber buku catatan tetapi gunakan sinkronisasi untuk konfigurasi seperti kumpulan dan kontrol akses.

Tabel berikut menjelaskan cara menangani berbagai jenis data dengan setiap opsi alat.

Deskripsi	Cara menangani dengan alat CI/CD	Cara menangani dengan alat sinkronisasi
Kode sumber: hasil ekspor sumber buku catatan dan kode sumber untuk pustaka di dalam paket	Sebarkan keduanya secara bersamaan ke primer dan sekunder.	Sinkronkan kode sumber dari primer ke sekunder.
Pengguna dan grup	Kelola metadata sebagai konfigurasi di Git. Jika tidak, gunakan IdP yang sama untuk kedua ruang kerja. Sebarkan data grup dan pengguna secara bersamaan pada penyebaran primer dan sekunder.	Gunakan SCIM atau automasi lainnya untuk kedua wilayah. Pembuatan manual tidak disarankan, tetapi jika digunakan, harus dilakukan terhadap keduanya secara bersamaan. Jika Anda menggunakan penyiapan manual, buat proses otomatis terjadwal untuk membandingkan daftar pengguna dan grup di antara dua penyebaran.
Konfigurasi kumpulan	Dapat berupa templat di Git. Sebarkan secara bersamaan ke primer dan sekunder. Namun, min_idle_instances di sekunder harus nol hingga peristiwa pemulihan bencana.	Kumpulan dibuat dengan min_idle_instances apa pun saat disinkronkan ke ruang kerja sekunder menggunakan API atau CLI.
Konfigurasi pekerjaan	Dapat berupa templat di Git. Untuk penyebaran primer, sebarkan definisi kerja apa adanya. Untuk penyebaran sekunder, sebarkan pekerjaan dan atur konkurensi ke nol. Tindakan ini akan menonaktifkan pekerjaan dalam penyebaran ini dan mencegah eksekusi tambahan. Ubah nilai konkurensi setelah penyebaran sekunder menjadi aktif.	Jika pekerjaan berjalan pada kluster <interactive> yang ada karena suatu alasan, maka klien sinkronisasi perlu memetakan ke cluster_id yang sesuai di ruang kerja sekunder.
Daftar kontrol akses (ACL)	Dapat berupa templat di Git. Sebarkan secara bersamaan ke penyebaran primer dan sekunder untuk buku catatan, folder, dan kluster. Namun, simpan data pekerjaan hingga peristiwa pemulihan bencana.	API Izin dapat mengatur kontrol akses untuk kluster, pekerjaan, kumpulan, notebook, dan folder. Klien sinkronisasi perlu memetakan ke ID objek yang sesuai untuk setiap objek di ruang kerja sekunder. Databricks merekomendasikan untuk membuat peta ID objek dari ruang kerja primer ke sekunder seraya menyinkronkan objek tersebut sebelum mereplikasi kontrol akses.
Pustaka	Sertakan dalam kode sumber dan templat kluster/pekerjaan.	Sinkronkan pustaka kustom dari repositori terpusat, DBFS, atau penyimpanan cloud (dapat dipasang).
Skrip init cluster	Sertakan dalam kode sumber, jika ingin.	Untuk sinkronisasi yang lebih sederhana, simpan skrip init di ruang kerja primer dalam folder umum atau dalam serangkaian kecil folder jika memungkinkan.
Titik pemasangan	Sertakan dalam kode sumber jika dibuat hanya melalui pekerjaan berbasis buku catatan atau API Perintah.	Gunakan pekerjaan, yang dapat dijalankan sebagai aktivitas Azure Data Factory (ADF). Perhatikan bahwa titik akhir penyimpanan mungkin berubah, mengingat ruang kerja akan berada di wilayah yang berbeda. Ini sangat bergantung pada strategi pemulihan bencana data Anda juga.
Metadata tabel	Sertakan dengan kode sumber jika dibuat hanya melalui pekerjaan berbasis buku catatan atau API Perintah. Ini berlaku untuk metastore Azure Databricks internal atau metastore yang dikonfigurasi eksternal.	Bandingkan definisi metadata di antara metastore menggunakan Spark Catalog API atau Tampilkan Buat Tabel melalui buku catatan atau skrip. Perhatikan bahwa tabel untuk penyimpanan yang mendasarinya dapat berbasis wilayah dan akan berbeda di antara instans metastore.
Rahasia	Sertakan dalam kode sumber jika dibuat hanya melalui API Perintah. Perhatikan bahwa beberapa konten rahasia mungkin perlu diubah di antara primer dan sekunder.	Rahasia dibuat di kedua ruang kerja melalui API. Perhatikan bahwa beberapa konten rahasia mungkin perlu diubah di antara primer dan sekunder.
Konfigurasi klaster	Dapat berupa templat di Git. Sebarkan secara bersamaan ke penyebaran primer dan sekunder, meskipun penyebaran sekunder harus dihentikan hingga peristiwa pemulihan bencana.	Kluster dibuat setelah disinkronkan ke ruang kerja sekunder menggunakan API atau CLI. Kluster tersebut dapat diakhiri secara eksplisit jika Anda mau, tergantung pada pengaturan penghentian otomatis.
Izin buku catatan, pekerjaan, dan folder	Dapat berupa templat di Git. Sebarkan secara bersamaan ke penyebaran primer dan sekunder.	Replikasi menggunakan API Izin.

Pilih wilayah dan beberapa ruang kerja sekunder

Anda memerlukan kontrol penuh atas pemicu pemulihan bencana. Anda dapat memutuskan untuk memicunya kapan saja atau dengan alasan apa pun. Anda harus bertanggung jawab atas stabilisasi pemulihan bencana sebelum dapat memulai ulang mode failback operasi (produksi normal). Biasanya ini berarti Anda perlu membuat beberapa ruang kerja Azure Databricks untuk menyediakan kebutuhan produksi dan pemulihan bencana, dan memilih wilayah failover sekunder.

Di Azure, periksa replikasi data Anda serta ketersediaan jenis produk dan VM.

Langkah 3: Menyiapkan ruang kerja dan melakukan penyalinan satu kali

Jika ruang kerja sudah dalam proses produksi, biasanya operasi penyalinan satu kali akan dijalankan untuk menyinkronkan penyebaran pasif dengan penyebaran aktif. Penyalinan satu kali ini melibatkan hal-hal berikut:

• Replikasi data: Mereplikasi menggunakan solusi replikasi cloud atau operasi Delta Deep Clone.
• Pembuatan token: Gunakan pembuatan token untuk mengotomatiskan replikasi dan beban kerja di masa mendatang.
• Replikasi ruang kerja: Gunakan replikasi ruang kerja menggunakan metode yang dijelaskan di Langkah 4: Menyiapkan sumber data.
• Validasi ruang kerja: - Lakukan pengujian untuk memastikan bahwa ruang kerja dan proses dapat dijalankan dengan efektif dan memberikan hasil yang diharapkan.

Setelah operasi penyalinan satu kali awal, tindakan penyalinan dan sinkronisasi berikutnya menjadi lebih cepat dan setiap pengelogan dari alat Anda juga merupakan log dari apa yang berubah dan kapan berubahnya.

Step 4: Menyiapkan sumber data

Azure Databricks dapat memproses berbagai macam sumber data menggunakan pemrosesan batch atau aliran.

Pemrosesan batch dari sumber data

Ketika data diproses dalam batch, data biasanya berada di sumber data yang dapat direplikasi dengan mudah atau dikirim ke wilayah lain.

Misalnya, data mungkin diunggah secara teratur ke lokasi penyimpanan cloud. Dalam mode pemulihan bencana untuk wilayah sekunder Anda, pastikan file akan diunggah ke penyimpanan wilayah sekunder Anda. Beban kerja harus membaca penyimpanan wilayah sekunder dan menuliskan ke penyimpanan wilayah sekunder.

Aliran

Memproses aliran adalah tantangan yang lebih besar. Data streaming dapat diserap dari berbagai sumber dan diproses serta dikirim ke solusi streaming:

• Antrean pesan seperti Kafka
• Aliran pengambilan data perubahan database
• Pemrosesan berkelanjutan berbasis file
• Pemrosesan terjadwal berbasis file, juga dikenal sebagai pemicu sekali

Dalam semua kasus tersebut, Anda harus mengonfigurasi sumber data untuk menangani mode pemulihan bencana dan menggunakan penyebaran sekunder di wilayah sekunder.

Penulis aliran menyimpan titik pemeriksaan dengan informasi tentang data yang telah diproses. Titik pemeriksaan ini dapat berisi lokasi data (biasanya penyimpanan cloud) yang harus diubah ke lokasi baru untuk memastikan keberhasilan memulai ulang aliran. Misalnya, subfolder source dalam titik pemeriksaan mungkin menyimpan folder cloud berbasis file.

Titik pemeriksaan ini harus direplikasi pada waktu yang tepat. Pertimbangkan sinkronisasi interval titik pemeriksaan dengan solusi replikasi cloud baru.

Pembaruan titik pemeriksaan adalah fungsi penulis dan oleh karena itu berlaku untuk penyerapan aliran atau pemrosesan dan penyimpanan pada sumber streaming lain.

Untuk beban kerja streaming, pastikan bahwa titik pemeriksaan dikonfigurasi dalam penyimpanan terkelola pelanggan sehingga dapat direplikasi ke wilayah sekunder untuk dimulainya kembali beban kerja dari titik kegagalan terakhir. Anda juga dapat memilih untuk menjalankan proses streaming sekunder secara paralel dengan proses primer.

Langkah 5: Menerapkan dan menguji solusi

Uji penyiapan pemulihan bencana secara berkala untuk memastikannya berfungsi dengan benar. Solusi pemulihan bencana menjadi tidak bernilai jika Anda tidak dapat menggunakannya saat membutuhkannya. Beberapa perusahaan beralih antarwilayah setiap beberapa bulan. Beralih wilayah pada jadwal teratur menguji asumsi dan proses Anda, dan memastikan bahwa wilayah tersebut memenuhi kebutuhan pemulihan Anda. Ini juga memastikan bahwa organisasi Anda terbiasa dengan kebijakan dan prosedur untuk keadaan darurat.

Penting

Uji solusi pemulihan bencana Anda secara teratur dalam kondisi dunia nyata.

Jika Anda menemukan bahwa Anda kehilangan objek atau templat dan masih perlu bergantung pada informasi yang disimpan di ruang kerja primer, ubah rencana Anda untuk menghapus hambatan tersebut, replikasi informasi ini dalam sistem sekunder, atau membuatnya tersedia dengan cara lain.

Uji setiap perubahan organisasi yang diperlukan untuk proses Anda dan konfigurasi secara umum. Rencana pemulihan bencana memengaruhi alur penyebaran Anda, dan penting bagi tim Anda untuk mengetahui apa yang perlu tetap sinkron. Setelah menyiapkan ruang kerja pemulihan bencana, pastikan infrastruktur (manual atau kode), pekerjaan, buku catatan, pustaka, dan objek ruang kerja lainnya tersedia di wilayah sekunder Anda.

Diskusikan dengan tim Anda mengenai cara memperluas proses kerja standar dan alur konfigurasi untuk menyebarkan perubahan ke semua ruang kerja. Kelola identitas pengguna di semua ruang kerja. Ingatlah untuk mengonfigurasi alat seperti automasi pekerjaan dan pemantauan ruang kerja baru.

Rencanakan dan uji perubahan pada alat konfigurasi:

• Penyerapan: Pahami tempat sumber data Anda berada dan tempat sumber tersebut mendapatkan datanya. Jika memungkinkan, buat parameter sumber dan pastikan Anda memiliki templat konfigurasi terpisah untuk bekerja dengan penyebaran sekunder dan wilayah sekunder. Siapkan rencana untuk failover dan uji semua asumsi.
• Perubahan eksekusi: Jika memiliki penjadwal untuk memicu pekerjaan atau tindakan lain, Anda mungkin perlu mengonfigurasi penjadwal terpisah yang berfungsi dengan penyebaran sekunder atau sumber datanya. Siapkan rencana untuk failover dan uji semua asumsi.
• Konektivitas interaktif: Pertimbangkan bagaimana konfigurasi, autentikasi, dan koneksi jaringan mungkin dipengaruhi oleh gangguan regional untuk penggunaan REST API, alat CLI, atau layanan lain seperti JDBC/ODBC. Siapkan rencana untuk failover dan uji semua asumsi.
• Perubahan automasi: Untuk semua alat automasi, siapkan rencana failover dan uji semua asumsi.
• Output: Untuk alat apa pun yang menghasilkan data atau log output, siapkan rencana failover dan uji semua asumsi.

Pengujian failover

Pemulihan bencana dapat dipicu oleh berbagai skenario. Bisa jadi oleh kerusakan tiba-tiba. Beberapa fungsi inti mungkin tidak berfungsi, termasuk jaringan cloud, penyimpanan cloud, atau layanan inti lainnya. Anda tidak dapat mematikan sistem dengan baik seperti biasa dan harus memulihkannya. Namun, prosesnya dapat dipicu oleh penonaktifan atau penghentian yang direncanakan, atau bahkan dengan beralihnya penyebaran aktif Anda secara berkala di antara dua wilayah.

Saat Anda menguji failover, sambungkan ke sistem dan jalankan proses mematikan. Pastikan semua pekerjaan telah selesai dan kluster diakhiri.

Klien sinkronisasi (atau alat CI/CD) dapat mereplikasi objek dan sumber daya Azure Databricks yang relevan ke ruang kerja sekunder. Untuk mengaktifkan ruang kerja sekunder, proses Anda mungkin meliputi beberapa atau semua hal berikut:

1. Jalankan pengujian untuk mengonfirmasi bahwa platform tersebut terbaru.
2. Nonaktifkan kumpulan dan kluster di wilayah primer sehingga jika layanan yang gagal kembali online, wilayah primer tidak mulai memproses data baru.
3. Proses pemulihan:
   1. Periksa tanggal data yang disinkronkan terbaru. Lihat Terminologi industri pemulihan bencana. Detail langkah ini beragam berdasarkan cara Anda menyinkronkan data dan kebutuhan unik bisnis Anda.
   2. Stabilkan sumber data Anda dan pastikan semuanya tersedia. Sertakan semua sumber data eksternal, seperti Azure Cloud SQL, serta Delta Lake, Parquet, atau file lainnya.
   3. Temukan titik pemulihan streaming Anda. Siapkan proses untuk memulai kembali dari sana dan siapkan proses untuk mengidentifikasi dan menghilangkan duplikat potensial (Delta Lake akan lebih memudahkannya).
   4. Selesaikan proses aliran data dan beri tahu pengguna.
4. Mulai kumpulan yang relevan (atau tingkatkan min_idle_instances ke jumlah yang relevan).
5. Mulai kluster yang relevan (jika tidak diakhiri).
6. Ubah eksekusi bersamaan untuk pekerjaan dan jalankan pekerjaan yang relevan. Ini bisa jadi eksekusi satu kali atau eksekusi berkala.
7. Untuk alat luar apa pun yang menggunakan URL atau nama domain untuk ruang kerja Azure Databricks Anda, perbarui konfigurasi untuk memperhitungkan sarana kontrol baru. Misalnya, perbarui URL untuk REST API dan koneksi JDBC/ODBC. URL tampilan pelanggan untuk aplikasi web Azure Databricks akan berubah jika sarana kontrol berubah, jadi beri tahu pengguna organisasi Anda mengenai URL baru.

Pemulihan pengujian (failback)

Failback lebih mudah dikontrol dan dapat dilakukan di jendela pemeliharaan. Rencana ini dapat mencakup beberapa atau semua hal berikut:

1. Dapatkan konfirmasi bahwa wilayah primer dipulihkan.
2. Nonaktifkan kumpulan dan kluster di wilayah sekunder sehingga tidak akan memulai pemrosesan data baru.
3. Sinkronkan aset baru atau yang diubah di ruang kerja sekunder kembali ke penyebaran primer. Bergantung pada desain skrip failover Anda, Anda mungkin dapat menjalankan skrip yang sama untuk menyinkronkan objek dari wilayah sekunder (pemulihan bencana) ke wilayah (produksi) primer.
4. Sinkronkan pembaruan data baru kembali ke penyebaran primer. Anda dapat menggunakan jejak audit log dan tabel Delta untuk memastikan tidak ada data yang hilang.
5. Matikan semua beban kerja di wilayah pemulihan bencana.
6. Ubah URL pekerjaan dan pengguna ke wilayah primer.
7. Jalankan pengujian untuk mengonfirmasi bahwa platform tersebut terbaru.
8. Mulai kumpulan yang relevan (atau tingkatkan min_idle_instances ke jumlah yang relevan).
9. Mulai kluster yang relevan (jika tidak diakhiri).
10. Ubah eksekusi bersamaan untuk pekerjaan, dan jalankan pekerjaan yang relevan. Ini bisa jadi eksekusi satu kali atau eksekusi berkala.
11. Sesuai kebutuhan, siapkan wilayah sekunder lagi untuk pemulihan bencana di masa mendatang.

Skrip, sampel, dan prototipe automasi

Skrip automasi yang perlu dipertimbangkan untuk proyek pemulihan bencana:

• Databricks merekomendasikan agar Anda menggunakan Penyedia Databricks Terraform untuk membantu mengembangkan proses sinkronisasi Anda sendiri.
• Lihat juga Alat Migrasi Ruang Kerja Databricks untuk skrip sampel dan prototipe. Selain objek Azure Databricks, replikasi alur Azure Data Factory yang relevan sehingga akan merujuk ke layanan tertaut yang dipetakan ke ruang kerja sekunder.
• Proyek Databricks Sync (DBSync) adalah alat sinkronisasi objek yang mencadangkan, memulihkan, dan menyinkronkan ruang kerja Databricks.