Keandalan di Azure Data Factory

Azure Data Factory memungkinkan Anda membuat alur data yang fleksibel dan canggih untuk integrasi data tanpa server dan transformasi data. Sebagai layanan Azure, Data Factory menyediakan berbagai kemampuan untuk mendukung persyaratan keandalan Anda.

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 cara membuat Data Factory tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, dan pemadaman wilayah. Ini juga menjelaskan bagaimana Anda dapat menggunakan cadangan untuk memulihkan dari jenis masalah lain, dan menyoroti beberapa informasi utama tentang perjanjian tingkat layanan (SLA) Data Factory.

Nota

Saat mempertimbangkan keandalan pabrik data, Anda juga perlu mempertimbangkan keandalan penyimpanan data yang terhubung dengannya. Meningkatkan ketahanan pabrik data saja mungkin memiliki dampak terbatas jika penyimpanan data tidak sama-sama tangguh. Bergantung pada persyaratan ketahanan Anda, Anda mungkin perlu membuat perubahan konfigurasi di beberapa area. Untuk membantu memastikan bahwa penyimpanan data memenuhi persyaratan kelangsungan bisnis Anda, lihat dokumentasi dan panduan keandalan produk mereka.

Gambaran umum arsitektur keandalan

Data Factory terdiri dari beberapa komponen infrastruktur. Setiap komponen mendukung keandalan infrastruktur dengan berbagai cara.

Komponen Data Factory meliputi:

• Layanan Azure Data Factory inti, yang mengelola pemicu alur dan mengawasi koordinasi aktivitas alur. Layanan inti juga mengelola metadata untuk setiap komponen di pabrik data. Microsoft mengelola layanan inti.

• Runtime integrasi (IR), yang terhubung ke penyimpanan data dan melakukan aktivitas yang ditentukan dalam alur Anda. Ada berbagai jenis IR.

  • IR yang dikelola Microsoft, yang mencakup Azure IR dan IR Server Integration Services Azure-SQL (Azure-SSIS). Microsoft mengelola komponen yang membentuk runtime ini. Dalam beberapa skenario, Anda mengonfigurasi pengaturan yang memengaruhi ketahanan IR Anda.

  • Runtime integrasi yang dihost sendiri (SHIR). Microsoft menyediakan perangkat lunak yang dapat Anda jalankan pada infrastruktur komputasi Anda sendiri untuk melakukan beberapa bagian dari alur Data Factory Anda. Anda bertanggung jawab atas penyebaran dan pengelolaan sumber daya komputasi, dan untuk ketahanan sumber daya komputasi tersebut.

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.

Saat Anda menggunakan Data Factory, penting untuk mempersiapkan kesalahan sementara, terutama ketika Anda merancang alur dan aktivitas.

Idempotensi (konsep matematis atau komputasi di mana operasi dapat diterapkan berulang kali tanpa mengubah hasil setelah aplikasi pertama)

Aktivitas alur Anda harus idempotensi, yang berarti bahwa mereka dapat dijalankan kembali beberapa kali tanpa menyebabkan efek samping. Jika kesalahan sementara seperti kegagalan jaringan atau pemadaman zona ketersediaan terjadi, Data Factory mungkin menjalankan ulang aktivitas alur. Eksekusi ulang ini dapat membuat rekaman duplikat.

Untuk mencegah penyisipan rekaman duplikat karena kesalahan sementara, terapkan praktik terbaik berikut:

• Gunakan pengidentifikasi unik untuk setiap rekaman sebelum Anda menulis ke database. Pendekatan ini dapat membantu Anda menemukan dan menghilangkan rekaman duplikat.

• Gunakan strategi upsert untuk konektor yang mendukung upsert. Sebelum penyisipan rekaman duplikat terjadi, gunakan pendekatan ini untuk memeriksa apakah rekaman sudah ada. Jika memang ada, perbarui. Jika tidak ada, sisipkan. Misalnya, perintah SQL seperti MERGE atau ON DUPLICATE KEY UPDATE menggunakan pendekatan upsert ini.

• Gunakan strategi tindakan salin. Untuk informasi selengkapnya, lihat Verifikasi konsistensi data dalam aktivitas salin.

Kebijakan Pengulangan

Anda dapat menggunakan kebijakan coba lagi untuk mengonfigurasi bagian alur Anda untuk mencoba kembali jika ada masalah, seperti kesalahan sementara dalam sumber daya yang terhubung. Di Data Factory, Anda dapat mengonfigurasi kebijakan coba lagi pada jenis objek alur berikut:

• Pemicu jendela tumbling
• Aktivitas pelaksanaan

Untuk informasi selengkapnya tentang cara mengubah atau menonaktifkan kebijakan percobaan kembali untuk pemicu dan aktivitas pabrik data Anda, lihat Eksekusi dan pemicu alur.

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.

Data Factory mendukung redundansi zona, yang memberikan ketahanan terhadap kegagalan di zona ketersediaan.

Setiap bagian data factory mendukung redundansi zona:

• Layanan inti: Microsoft mengelola komponen dalam layanan Azure Data Factory inti dan menyebarkannya di seluruh zona ketersediaan.

  Namun, setelah kegagalan zona, Microsoft tidak menjamin status pemicu jendela tumbling.

• Irs: Dukungan redundansi zona tergantung pada jenis IR yang Anda gunakan.

  • Azure IR mendukung redundansi zona, dan Microsoft mengelola kemampuan ini.

    

  • An Azure-SSIS IR mengharuskan Anda untuk menyebarkan setidaknya dua node. Simpul-simpul ini secara otomatis dialokasikan ke zona-zona ketersediaan yang berbeda.

    Diagram berikut menunjukkan alur yang tahan terhadap kerusakan zona dan waktu proses integrasi Azure-SSIS dengan dua simpul, masing-masing diterapkan di zona berbeda.

    

  • SHIR memberi Anda tanggung jawab untuk menerapkan infrastruktur komputasi untuk menjalankan runtime. Anda dapat menyebarkan beberapa simpul, seperti komputer virtual individual (VM), dan mengonfigurasinya untuk ketersediaan tinggi. Anda kemudian dapat mendistribusikan simpul tersebut di beberapa zona ketersediaan. Untuk informasi selengkapnya, lihat Ketersediaan dan skalabilitas tinggi.

Persyaratan

Sumber daya Data Factory yang redundan zona dapat disebarkan di wilayah mana pun yang mendukung zona ketersediaan.

Biaya

• Layanan inti: Tidak ada biaya tambahan yang berlaku untuk redundansi zona.

• Irs: Biaya redundansi zona bervariasi tergantung pada jenis IR yang Anda gunakan.

  • Azure IR menyertakan redundansi zona tanpa biaya tambahan.

  • Sebuah Azure-SSIS IR mengharuskan Anda untuk menyebarkan setidaknya dua simpul-simpul untuk mencapai redundansi zona. Untuk informasi selengkapnya tentang bagaimana biaya setiap simpul dihitung, lihat Contoh harga: Menjalankan paket SSIS pada IR Azure-SSIS.

  • SHIR mengharuskan Anda untuk menyebarkan dan mengelola infrastruktur komputasi. Untuk mencapai ketahanan zona, Anda perlu menyebarkan sumber daya komputasi Anda di beberapa zona. Bergantung pada jumlah simpul yang Anda sebarkan dan cara Mengonfigurasinya, Anda mungkin dikenakan biaya tambahan dari layanan komputasi yang mendasar dan layanan pendukung lainnya. Tidak ada biaya tambahan untuk menjalankan SHIR pada beberapa simpul.

Mengonfigurasi dukungan zona ketersediaan

• Layanan inti: Tidak diperlukan konfigurasi. Layanan inti Data Factory secara otomatis mendukung redundansi zona.

• Irs:

  • Azure IR: Tidak diperlukan konfigurasi. Runtime integrasi Azure secara otomatis mengaktifkan redundansi zona.

  • An Azure-SSIS IR: Tidak diperlukan konfigurasi. IR Azure-SSIS secara otomatis mengaktifkan redundansi zona saat disebarkan dengan dua node atau lebih.

  • SHIR mengharuskan Anda mengonfigurasi ketahanan secara mandiri, termasuk menyebarkan simpul Anda di beberapa zona ketersediaan.

Perencanaan dan manajemen kapasitas

• Layanan inti: Layanan inti Data Factory diskalakan secara otomatis berdasarkan permintaan, dan Anda tidak perlu merencanakan atau mengelola kapasitas.

• Irs:

  • Azure IR mengalami skala otomatis berdasarkan permintaan, dan Anda tidak perlu merencanakan atau mengelola kapasitas.

  • Sebuah Azure-SSIS IR mengharuskan Anda untuk mengonfigurasi jumlah simpul yang digunakan. Untuk mempersiapkan kerusakan zona ketersediaan, pertimbangkan untuk menyediakan kapasitas lebih dari cukup pada runtime integrasi Anda. Provisi berlebihan memungkinkan solusi untuk mentolerir beberapa tingkat kehilangan kapasitas dan masih terus berfungsi tanpa penurunan performa. Untuk informasi selengkapnya, lihat Mengelola kapasitas dengan penyediaan berlebih.

  • SHIR mengharuskan Anda untuk mengonfigurasi kapasitas dan skala Anda sendiri. Pertimbangkan provisi berlebihan saat Anda menyebarkan SHIR.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika sumber daya Data Factory dikonfigurasi untuk redundansi zona dan semua zona ketersediaan beroperasi.

• Pengalihan lalu lintas antar zona: Selama operasi normal, Data Factory secara otomatis mendistribusikan aktivitas pipeline, pemicu, dan pekerjaan lainnya di antara instans sehat di setiap zona ketersediaan.

• Replikasi data antar zona: Secara umum, Data Factory adalah layanan stateless, sehingga tidak ada status yang perlu direplikasi antar zona.

  Namun, pemicu jendela tumbling berisi status, yang mungkin tidak sepenuhnya direplikasi antar zona.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika sumber daya Data Factory dikonfigurasi untuk redundansi wilayah dan ketika terjadi pemadaman wilayah ketersediaan.

• Deteksi dan respons: Platform Data Factory bertanggung jawab untuk mendeteksi kegagalan di zona ketersediaan dan merespons. Anda tidak perlu melakukan apa pun untuk memulai failover zona di alur Anda atau pada komponen-komponen lainnya.

• Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah. Anda juga dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

• Permintaan aktif: Semua pipeline dan pemicu yang sedang berlangsung akan terus berjalan, dan Anda tidak akan mengalami gangguan langsung akibat kegagalan zona. Namun, aktivitas yang sedang berlangsung selama kegagalan zona mungkin gagal dan dimulai ulang. Penting untuk merancang aktivitas agar bersifat idempoten, yang membantu mereka pulih dari kegagalan zona dan kesalahan lainnya. Untuk informasi selengkapnya, lihat Ketahanan terhadap kesalahan sementara.

• Waktu henti yang diharapkan: Tidak ada waktu henti yang diharapkan selama kegagalan zona.

• Kehilangan data yang diharapkan: Secara keseluruhan, Data Factory adalah layanan stateless, sehingga tidak ada kehilangan data yang diharapkan selama kegagalan zona.

  Namun, jika Anda menggunakan pemicu jendela tumbling, status pemicu mungkin hilang setelah kegagalan zona. Anda harus memulai ulang atau menjalankan kembali pemicu apa pun yang berjalan pada saat kegagalan zona.

Pemulihan Zona

Saat zona ketersediaan pulih, Data Factory secara otomatis beralih kembali ke zona asli. Anda tidak perlu melakukan apa pun untuk memulai failback zona di pipeline Anda atau komponen lainnya.

Namun, jika Anda menggunakan SHIR, Anda mungkin perlu memulai ulang sumber daya komputasi jika telah dihentikan.

Uji kegagalan zona

Untuk layanan inti, serta IR Azure dan IR Azure-SSIS, Data Factory mengelola perutean lalu lintas, failover, dan failback untuk sumber daya yang memiliki redundansi zona. Karena fitur ini dikelola sepenuhnya, Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan.

Untuk SHIR, Anda dapat menggunakan Azure Chaos Studio untuk mensimulasikan kegagalan zona ketersediaan pada Azure VM.

Ketahanan terhadap kegagalan di seluruh wilayah

Sumber daya Data Factory disebarkan ke dalam satu wilayah Azure. Jika wilayah menjadi tidak tersedia, layanan pengolahan data Anda juga tidak tersedia. Namun, ada pendekatan yang dapat Anda gunakan untuk membantu memastikan ketahanan terhadap pemadaman wilayah. Pendekatan ini bergantung pada apakah pabrik data berada di wilayah yang dipasangkan atau tidak berpasangan dan pada persyaratan dan konfigurasi spesifik Anda.

Failover yang dikelola Microsoft ke wilayah yang dipasangkan

Data Factory mendukung failover yang dikelola Microsoft untuk pabrik data di wilayah berpasangan, kecuali brasil Asia Selatan dan Tenggara. Dalam situasi yang tidak terduga terjadi kegagalan wilayah yang berkepanjangan, Microsoft dapat memulai failover regional dari instans Data Factory Anda.

Karena persyaratan residensi data di Brasil Selatan dan Asia Tenggara, data Data Factory hanya disimpan di wilayah lokal dengan menggunakan penyimpanan zona redundan Azure Storage. Untuk Asia Tenggara, semua data disimpan di Singapura. Untuk Brasil Selatan, semua data disimpan di Brasil.

Untuk pabrik data di wilayah yang tidak berpasangan, atau di Brasil Selatan atau Asia Tenggara, Microsoft tidak melakukan failover regional atas nama Anda.

Penting

Microsoft memicu failover yang dikelola Microsoft. Kemungkinan akan terjadi setelah penundaan yang signifikan dan dilakukan seoptimal mungkin. Ada juga beberapa pengecualian untuk proses ini. Anda mungkin mengalami kehilangan metadata dari pabrik data Anda. Failover sumber daya Data Factory mungkin terjadi pada satu waktu yang berbeda dari waktu failover layanan Azure lainnya.

Jika Anda harus tahan terhadap pemadaman wilayah, pertimbangkan untuk menggunakan salah satu solusi multi-wilayah kustom untuk ketahanan.

Failover IR

Untuk mempersiapkan failover, mungkin ada beberapa pertimbangan tambahan, tergantung pada integrasi runtime yang Anda gunakan.

• Anda dapat mengonfigurasi Azure IR untuk menentukan wilayah yang digunakan secara otomatis. Jika wilayah diatur ke penyelesaian otomatis dan ada pemadaman di wilayah utama, Azure IR secara otomatis melakukan failover ke wilayah yang dipasangkan. Failover ini tunduk pada batasan. Untuk mengonfigurasi wilayah Azure IR untuk implementasi atau pengiriman aktivitas Anda dalam penyiapan IR, atur wilayah ke auto resolve.

• Azure-SSIS IR failover dikelola secara terpisah dari failover yang dikelola oleh Microsoft pada pabrik data. Untuk informasi selengkapnya, lihat Solusi multi-wilayah kustom untuk ketahanan.

• SHIR berjalan pada infrastruktur yang Anda tanggung, sehingga failover yang dikelola Microsoft tidak berlaku untuk SHIR. Untuk informasi selengkapnya, lihat Solusi multi-wilayah kustom untuk ketahanan.

Konfigurasi ulang setelah failover

Setelah failover yang dikelola Microsoft selesai, Anda dapat mengakses alur Data Factory di wilayah yang dipasangkan. Namun, setelah failover selesai, Anda mungkin perlu melakukan beberapa konfigurasi ulang untuk IR atau komponen lainnya. Proses ini termasuk membuat ulang konfigurasi jaringan.

Solusi multi-wilayah kustom untuk ketahanan

Jika Anda memerlukan alur Anda untuk tahan terhadap pemadaman regional dan Anda memerlukan kontrol atas proses failover, pertimbangkan untuk menggunakan alur berbasis metadata.

• Siapkan kontrol sumber untuk Data Factory untuk melacak dan mengaudit perubahan apa pun pada metadata Anda. Anda dapat menggunakan pendekatan ini untuk mengakses file JSON metadata Anda untuk alur, himpunan data, layanan tertaut, dan pemicu. Data Factory mendukung berbagai jenis repositori Git, seperti Azure DevOps dan GitHub. Untuk informasi selengkapnya, lihat Kontrol sumber di Data Factory.

• Gunakan sistem integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD), seperti Azure DevOps, untuk mengelola metadata dan penyebaran alur Anda. Anda dapat menggunakan CI/CD untuk memulihkan operasi dengan cepat ke instans di wilayah lain. Jika wilayah tidak tersedia, Anda dapat menyediakan pabrik data baru secara manual atau melalui otomatisasi. Setelah pabrik data baru dibuat, Anda dapat memulihkan alur, himpunan data, dan layanan tertaut JSON dari repositori Git yang ada. Untuk informasi selengkapnya, lihat Kelangsungan bisnis dan pemulihan bencana (BCDR) untuk alur Data Factory dan Azure Synapse Analytics.

Tergantung pada IR yang Anda gunakan, mungkin ada pertimbangan lain.

• Sebuah Azure-SSIS IR menggunakan database yang disimpan di Azure SQL Database atau Azure SQL Managed Instance. Anda dapat mengonfigurasi replikasi geografis atau grup failover untuk database ini. Database Azure-SSIS terletak di wilayah Azure utama yang memiliki akses baca-tulis. Database terus direplikasi ke wilayah sekunder yang memiliki akses baca-saja. Jika wilayah utama tidak tersedia, failover akan terpicu, menyebabkan database utama dan sekunder bertukar peran.

  Anda juga dapat mengonfigurasi pasangan siaga ganda Azure SSIS IR yang bekerja secara sinkron dengan grup failover Azure SQL Database atau SQL Managed Instance.

  Untuk informasi lebih lanjut, silakan lihat Konfigurasi Azure-SSIS IR untuk BCDR.

• SHIR berjalan pada infrastruktur yang Anda kelola. Jika SHIR disebarkan ke Azure VM, Anda dapat menggunakan Azure Site Recovery untuk memicu failover VM ke wilayah lain.

Pencadangan dan pemulihan

Data Factory mendukung CI/CD melalui integrasi kontrol sumber, sehingga memungkinkan Anda mencadangkan metadata instans Data Factory. Alur CI/CD menyebarkan metadata ini dengan mulus ke lingkungan baru. Untuk informasi selengkapnya, lihat CI/CD di Data Factory.

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.

Data Factory menyediakan SLA ketersediaan terpisah untuk:

• Tingkat keberhasilan panggilan API yang Anda lakukan, seperti untuk mengelola pabrik data Anda.
• Jumlah putaran aktivitas yang mulai dieksekusi.

Pelaksanaan aktivitas diizinkan untuk ditunda secara singkat, dan mengharuskan semua dependensi untuk menjalankan tugas telah terpenuhi.

Konten terkait

• Keandalan di Azure