Bagikan melalui


Pemulihan bencana wilayah untuk kluster Azure Databricks

Artikel ini menjelaskan arsitektur pemulihan bencana yang berguna untuk kluster Azure Databricks, dan langkah-langkah untuk mencapai desain tersebut.

Arsitektur Azure Databricks

Saat Anda membuat ruang kerja Azure Databricks dari portal Azure, aplikasi terkelola disebarkan sebagai sumber daya Azure di langganan Anda, di wilayah Azure yang dipilih (misalnya, AS Barat). Alat ini disebarkan di Azure Virtual Network dengan Network Security Group dan akun Azure Storage, yang tersedia di langganan Anda. Jaringan virtual menyediakan keamanan tingkat perimeter ke ruang kerja Databricks, dan dilindungi melalui kelompok keamanan jaringan. Dalam ruang kerja, Anda membuat kluster Databricks dengan menyediakan jenis VM pekerja dan driver dan versi runtime Databricks. Data yang bertahan tersedia di akun penyimpanan Anda. Setelah kluster dibuat, Anda dapat menjalankan pekerjaan melalui notebook, REST API, atau titik akhir ODBC/JDBC, dengan melampirkannya ke kluster tertentu.

Bidang kontrol Databricks mengelola dan memantau lingkungan ruang kerja Databricks. Setiap operasi manajemen, seperti membuat kluster, akan dimulai dari sarana kontrol. Semua metadata, seperti pekerjaan terjadwal, disimpan dalam Azure Database, dan cadangan database secara otomatis direplikasi secara geografis untuk ke wilayah berpasangan tempatnya diterapkan.

Arsitektur Databricks

Salah satu keuntungan dari arsitektur ini adalah pengguna dapat menghubungkan Azure Databricks ke sumber daya penyimpanan apa pun di akun mereka. Manfaat utama adalah bahwa komputasi (Azure Databricks) dan penyimpanan dapat diskalakan secara terpisah satu sama lain.

Cara membuat topologi pemulihan bencana wilayah

Dalam deskripsi arsitektur sebelumnya, ada sejumlah komponen yang digunakan untuk alur Big Data dengan Azure Databricks: Azure Storage, Azure Database, dan sumber data lainnya. Azure Databricks adalah komputasi untuk alur Big Data. Sifatnya sementara, yang berarti bahwa saat data Anda masih tersedia di Azure Storage, komputasi (kluster Azure Databricks) dapat dihentikan untuk menghindari membayar komputasi saat Anda tidak membutuhkannya. Komputasi (Azure Databricks) dan sumber penyimpanan harus berada di wilayah yang sama sehingga pekerjaan tidak mengalami latensi tinggi.

Untuk membuat topologi pemulihan bencana regional Anda sendiri, ikuti persyaratan berikut:

  1. Sediakan beberapa ruang kerja Azure Databricks di wilayah Azure terpisah. Misalnya, buat ruang kerja Azure Databricks utama di US Timur. Buat ruang kerja Azure Databricks pemulihan-bencana sekunder di wilayah terpisah, seperti US Barat. Untuk daftar wilayah Azure yang dipasangkan, lihat Replikasi lintas wilayah. Untuk detail tentang wilayah Azure Databricks, lihat Wilayah yang didukung.

  2. Menggunakan Penyimpanan geo redundan. Secara default, data yang terkait dengan Azure Databricks disimpan dalam Azure Storage dan hasil dari pekerjaan Databricks disimpan di Azure Blob Storage, sehingga data yang diproses tetap ada dan sangat tersedia setelah kluster dihapus. Penyimpanan kluster dan penyimpanan pekerjaan berada di zona ketersediaan yang sama. Untuk melindungi dari ketidaktersediaan regional, ruang kerja Azure Databricks menggunakan penyimpanan geo-redundan secara default. Dengan penyimpanan geo-redundan, data direplikasi ke wilayah berpasangan Azure. Databricks merekomendasikan agar Anda membiarkan penyimpanan geo-redundan tetap default, tetapi jika Anda perlu menggunakan penyimpanan-redundan secara lokal, Anda dapat mengatur storageAccountSkuName ke Standard_LRS di templat ARM untuk ruang kerja tersebut.

  3. Setelah wilayah sekunder dibuat, Anda harus memindahkan pengguna, folder pengguna, notebook, konfigurasi kluster, konfigurasi pekerjaan, pustaka, penyimpanan, skrip init, dan mengonfigurasi ulang kontrol akses. Detail tambahan diuraikan di bagian berikut.

Bencana regional

Untuk mempersiapkan bencana regional, Anda perlu secara eksplisit mempertahankan kumpulan ruang kerja Azure Databricks lain di wilayah sekunder. Lihat Pemulihan bencana.

Alat kami yang direkomendasikan untuk pemulihan bencana terutama Terraform (untuk replikasi Infra) dan Delta Deep Clone (untuk Replikasi data).

Langkah migrasi terperinci

  1. Menyiapkan antarmuka baris perintah Databricks di komputer Anda

    Artikel ini menunjukkan sejumlah contoh kode yang menggunakan antarmuka baris perintah untuk sebagian besar langkah otomatis, karena ini adalah pembungkus yang mudah digunakan pengguna melalui Azure Databricks REST API.

    Sebelum melakukan langkah-langkah migrasi apa pun, instal databricks-cli di komputer desktop Anda atau mesin virtual tempat Anda berencana melakukan pekerjaan tersebut. Untuk informasi selengkapnya, lihat Instal Databrick CLI

    pip install databricks-cli
    

    Catatan

    Setiap skrip python yang disediakan dalam artikel ini diharapkan bekerja dengan Python 2.7+ < 3.x.

  2. Mengonfigurasi dua profil.

    Konfigurasikan satu profil untuk ruang kerja utama, dan yang lainnya untuk ruang kerja sekunder:

    databricks configure --profile primary --token
    databricks configure --profile secondary --token
    

    Blok kode dalam artikel ini beralih antar profil di setiap langkah berikutnya menggunakan perintah ruang kerja yang sesuai. Pastikan bahwa nama-nama profil yang Anda buat diganti ke dalam setiap blok kode.

    EXPORT_PROFILE = "primary"
    IMPORT_PROFILE = "secondary"
    

    Anda dapat beralih secara manual di baris perintah jika diperlukan:

    databricks workspace ls --profile primary
    databricks workspace ls --profile secondary
    
  3. Memigrasikan pengguna ID Microsoft Entra (sebelumnya Azure Active Directory)

    Tambahkan pengguna MICROSOFT Entra ID (sebelumnya Azure Active Directory) yang sama secara manual ke ruang kerja sekunder yang ada di ruang kerja utama.

  4. Memigrasikan folder pengguna dan notebook

    Gunakan kode python berikut untuk memigrasikan lingkungan pengguna sandbox, yang mencakup struktur folder bertumpuk dan notebook per pengguna.

    Catatan

    Pustaka tidak disalin dalam langkah ini, karena API yang mendasarinya tidak mendukun.

    Salin dan simpan skrip python berikut ke file, dan jalankan di baris perintah Databricks Anda. Contohnya,python scriptname.py.

    import sys
    import os
    import subprocess
    from subprocess import call, check_output
    
    EXPORT_PROFILE = "primary"
    IMPORT_PROFILE = "secondary"
    
    # Get a list of all users
    user_list_out = check_output(["databricks", "workspace", "ls", "/Users", "--profile", EXPORT_PROFILE])
    user_list = (user_list_out.decode(encoding="utf-8")).splitlines()
    
    print (user_list)
    
    # Export sandboxed environment(folders, notebooks) for each user and import into new workspace.
    #Libraries are not included with these APIs / commands.
    
    for user in user_list:
      #print("Trying to migrate workspace for user ".decode() + user)
      print (("Trying to migrate workspace for user ") + user)
    
      subprocess.call(str("mkdir -p ") + str(user), shell = True)
      export_exit_status = call("databricks workspace export_dir /Users/" + str(user) + " ./" + str(user) + " --profile " + EXPORT_PROFILE, shell = True)
    
      if export_exit_status==0:
        print ("Export Success")
        import_exit_status = call("databricks workspace import_dir ./" + str(user) + " /Users/" + str(user) + " --profile " + IMPORT_PROFILE, shell=True)
        if import_exit_status==0:
          print ("Import Success")
        else:
          print ("Import Failure")
      else:
        print ("Export Failure")
    print ("All done")
    
  5. Memigrasikan konfigurasi kluster

    Setelah notebook dimigrasikan, Anda bisa juga memigrasikan konfigurasi kluster ke ruang kerja baru. Proses ini merupakan langkah hampir sepenuhnya otomatis menggunakan databricks-cli, kecuali jika Anda ingin melakukan migrasi konfigurasi kluster secara selektif, daripada secara total.

    Catatan

    Sayangnya tidak ada titik akhir konfigurasi kluster, dan skrip ini mencoba membuat setiap kluster secara langsung. Jika tidak ada cukup core yang tersedia di langganan Anda, pembuatan kluster bisa gagal. Kegagalan dapat diabaikan, selama konfigurasinya berhasil ditransfer.

    Skrip yang disediakan mencetak pemetaan dari ID kluster lama ke yang baru, yang dapat digunakan untuk migrasi pekerjaan nanti (untuk pekerjaan yang dikonfigurasi untuk menggunakan kluster yang ada).

    Salin dan simpan skrip python berikut ke file, dan jalankan di baris perintah Databricks Anda. Contohnya,python scriptname.py.

    import sys
    import os
    import subprocess
    import json
    from subprocess import call, check_output
    
    EXPORT_PROFILE = "primary"
    IMPORT_PROFILE = "secondary"
    
    # Get all clusters info from old workspace
    clusters_out = check_output(["databricks", "clusters", "list",    "--profile", EXPORT_PROFILE])
    clusters_info_list = str(clusters_out.decode(encoding="utf-8")).   splitlines()
    print("Printting Cluster info List")
    print(clusters_info_list)
    
    # Create a list of all cluster ids
    clusters_list = []
    ##for cluster_info in clusters_info_list: clusters_list.append   (cluster_info.split(None, 1)[0])
    
    for cluster_info in clusters_info_list:
       if cluster_info != '':
          clusters_list.append(cluster_info.split(None, 1)[0])
    
    # Optionally filter cluster ids out manually, so as to create only required ones in new workspace
    
    # Create a list of mandatory / optional create request elements
    cluster_req_elems = ["num_workers","autoscale","cluster_name","spark_version","spark_conf","node_type_id","driver_node_type_id","custom_tags","cluster_log_conf","spark_env_vars","autotermination_minutes","enable_elastic_disk"]
    print("Printing Cluster element List")
    print (cluster_req_elems)
    print(str(len(clusters_list)) + " clusters found in the primary site" )
    
    print ("---------------------------------------------------------")
    # Try creating all / selected clusters in new workspace with same config as in old one.
    cluster_old_new_mappings = {}
    i = 0
    for cluster in clusters_list:
       i += 1
       print("Checking cluster " + str(i) + "/" + str(len(clusters_list)) + " : " +str(cluster))
       cluster_get_out_f = check_output(["databricks", "clusters", "get", "--cluster-id", str(cluster), "--profile", EXPORT_PROFILE])
       cluster_get_out=str(cluster_get_out_f.decode(encoding="utf-8"))
       print ("Got cluster config from old workspace")
       print (cluster_get_out)
        # Remove extra content from the config, as we need to build create request with allowed elements only
       cluster_req_json = json.loads(cluster_get_out)
       cluster_json_keys = cluster_req_json.keys()
    
       #Don't migrate Job clusters
       if cluster_req_json['cluster_source'] == u'JOB' :
          print ("Skipping this cluster as it is a Job cluster : " + cluster_req_json['cluster_id'] )
          print ("---------------------------------------------------------")
          continue
    
          #cluster_req_json.pop(key, None)
          for key in cluster_json_keys:
            if key not in cluster_req_elems:
             print (cluster_req_json)
             #cluster_del_item=cluster_json_keys .keys()
             cluster_req_json.popitem(key, None)
    
       # Create the cluster, and store the mapping from old to new cluster ids
    
       #Create a temp file to store the current cluster info as JSON
       strCurrentClusterFile = "tmp_cluster_info.json"
    
       #delete the temp file if exists
       if os.path.exists(strCurrentClusterFile) :
          os.remove(strCurrentClusterFile)
    
       fClusterJSONtmp = open(strCurrentClusterFile,"w+")
       fClusterJSONtmp.write(json.dumps(cluster_req_json))
       fClusterJSONtmp.close()
    
       #cluster_create_out = check_output(["databricks", "clusters", "create", "--json", json.dumps(cluster_req_json), "--profile", IMPORT_PROFILE])
       cluster_create_out = check_output(["databricks", "clusters", "create", "--json-file", strCurrentClusterFile , "--profile", IMPORT_PROFILE])
       cluster_create_out_json = json.loads(cluster_create_out)
       cluster_old_new_mappings[cluster] = cluster_create_out_json['cluster_id']
    
       print ("Cluster create request sent to secondary site workspace successfully")
       print ("---------------------------------------------------------")
    
       #delete the temp file if exists
       if os.path.exists(strCurrentClusterFile) :
          os.remove(strCurrentClusterFile)
    
    print ("Cluster mappings: " + json.dumps(cluster_old_new_mappings))
    print ("All done")
    print ("P.S. : Please note that all the new clusters in your secondary site are being started now!")
    print ("       If you won't use those new clusters at the moment, please don't forget terminating your new clusters to avoid charges")
    
  6. Memigrasikan konfigurasi pekerjaan

    Jika Anda memigrasikan konfigurasi kluster pada langkah sebelumnya, Anda dapat memilih untuk memigrasikan konfigurasi pekerjaan ke ruang kerja baru. Ini adalah langkah yang sepenuhnya otomatis menggunakan databricks-cli, kecuali jika Anda ingin melakukan migrasi konfigurasi pekerjaan selektif daripada melakukannya untuk semua pekerjaan.

    Catatan

    Konfigurasi untuk pekerjaan terjadwal juga berisi informasi "jadwal" , jadi secara default itu akan mulai bekerja sesuai waktu yang dikonfigurasi segera setelah dimigrasikan. Oleh karena itu, blok kode berikut menghapus informasi jadwal apa pun selama migrasi (untuk menghindari operasi duplikat di ruang kerja lama dan baru). Konfigurasikan jadwal untuk pekerjaan tersebut setelah Anda siap untuk pergantian ruang kerja.

    Konfigurasi pekerjaan memerlukan pengaturan untuk kluster baru atau yang sudah ada. Jika menggunakan kluster yang ada, skrip /kode di bawah ini akan mencoba mengganti ID kluster lama dengan ID kluster baru.

    Salin dan simpan skrip python berikut ke file. Ganti nilai untuk old_cluster_id dan new_cluster_id, dengan output dari migrasi kluster yang dilakukan pada langkah sebelumnya. Jalankan di baris perintah databricks-cli Anda, misalnya, python scriptname.py.

    import sys
    import os
    import subprocess
    import json
    from subprocess import call, check_output
    
    
    EXPORT_PROFILE = "primary"
    IMPORT_PROFILE = "secondary"
    
    # Please replace the old to new cluster id mappings from cluster migration output
    cluster_old_new_mappings = {"0227-120427-tryst214": "0229-032632-paper88"}
    
    # Get all jobs info from old workspace
    try:
      jobs_out = check_output(["databricks", "jobs", "list", "--profile", EXPORT_PROFILE])
      jobs_info_list = jobs_out.splitlines()
    except:
      print("No jobs to migrate")
      sys.exit(0)
    
    # Create a list of all job ids
    jobs_list = []
    for jobs_info in jobs_info_list:
      jobs_list.append(jobs_info.split(None, 1)[0])
    
    # Optionally filter job ids out manually, so as to create only required ones in new workspace
    
    # Create each job in the new workspace based on corresponding settings in the old workspace
    
    for job in jobs_list:
      print("Trying to migrate ") + job
    
      job_get_out = check_output(["databricks", "jobs", "get", "--job-id", job, "--profile", EXPORT_PROFILE])
      print("Got job config from old workspace")
    
      job_req_json = json.loads(job_get_out)
      job_req_settings_json = job_req_json['settings']
    
      # Remove schedule information so job doesn't start before proper cutover
      job_req_settings_json.pop('schedule', None)
    
      # Replace old cluster id with new cluster id, if job configured to run against an existing cluster
      if 'existing_cluster_id' in job_req_settings_json:
        if job_req_settings_json['existing_cluster_id'] in cluster_old_new_mappings:
          job_req_settings_json['existing_cluster_id'] = cluster_old_new_mappings[job_req_settings_json['existing_cluster_id']]
        else:
          print("Mapping not available for old cluster id ") + job_req_settings_json['existing_cluster_id']
          continue
    
      call(["databricks", "jobs", "create", "--json", json.dumps(job_req_settings_json), "--profile", IMPORT_PROFILE])
      print("Sent job create request to new workspace successfully")
    
    print("All done")
    
  7. Memigrasikan pustaka

    Saat ini tidak ada cara langsung untuk memigrasikan pustaka dari satu ruang kerja ke ruang kerja lainnya. Sebagai gantinya, instal ulang pustaka tersebut ke ruang kerja baru secara manual. Bisa dibuat otomatis menggunakan kombinasi DBFS CLI untuk mengunggah pustaka kustom ke ruang kerja dan Libraries CLI.

  8. Migrasikan dudukan penyimpanan blob Azure dan Azure Data Lake Storage

    Lepaskan semua titik pemasangan Azure Blob storage dan Azure Data Lake Storage (Gen 2) secara manual menggunakan solusi berbasis notebook. Sumber daya penyimpanan akan dipasang di ruang kerja utama, dan harus diulang di ruang kerja sekunder. Tidak ada API eksternal untuk dudukan.

  9. Migrate skrip init kluster

    Skrip inisialisasi kluster apa pun dapat dimigrasikan dari ruang kerja lama ke ruang kerja baru menggunakan DBFS CLI. Pertama, salin skrip yang diperlukan dari dbfs:/dat abricks/init/.. ke desktop lokal atau mesin virtual Anda. Selanjutnya, salin skrip tersebut ke ruang kerja baru di jalur yang sama.

    // Primary to local
    dbfs cp -r dbfs:/databricks/init ./old-ws-init-scripts --profile primary
    
    // Local to Secondary workspace
    dbfs cp -r old-ws-init-scripts dbfs:/databricks/init --profile secondary
    
  10. Konfigurasi ulang dan aplikasikan kembali kontrol akses secara manual.

    Jika ruang kerja utama yang ada dikonfigurasi untuk menggunakan tingkat Premium atau Enterprise (SKU), kemungkinan Anda juga menggunakan fitur Kontrol Akses.

    Jika Anda menggunakan fitur Microsoft Azure Access Control Service, secara manual terapkan ulang kontrol akses ke sumber daya (Notebook, Kluster, Pekerjaan, Tabel).

Pemulihan bencana untuk ekosistem Azure Anda

Jika Anda menggunakan layanan Azure lainnya, pastikan untuk menerapkan praktik terbaik pemulihan bencana untuk layanan tersebut juga. Misalnya, jika Anda memilih untuk menggunakan instans metastore Apache Hive eksternal, Anda harus mempertimbangkan pemulihan bencana untuk Azure SQL Database, Azure HDInsight, dan/atau Azure Database for MySQL. Untuk informasi umum tentang pemulihan bencana, lihat Pemulihan bencana untuk aplikasi Azure.

Langkah berikutnya

Untuk informasi selengkapnya, lihat Dokumentasi Azure Databricks.