Keandalan di Azure Data Factory

Artikel ini menjelaskan dukungan keandalan di Azure Data Factory. Ini mencakup ketahanan intra-regional melalui zona ketersediaan dan penyebaran multi-wilayah.

Keandalan adalah tanggung jawab bersama antara Anda dan Microsoft. Anda dapat menggunakan panduan ini untuk menentukan opsi keandalan mana yang memenuhi tujuan bisnis dan tujuan waktu aktif spesifik Anda.

Anda dapat menggunakan Data Factory untuk membuat alur data yang fleksibel dan kuat untuk integrasi data tanpa server dan transformasi data. Akibatnya, ketika Anda menentukan rencana kelangsungan bisnis Anda untuk keandalan, Anda perlu mempertimbangkan persyaratan keandalan dan panduan untuk:

• Pipeline Data Factory.

• Runtime integrasi (IR), yang terhubung ke sumber data dan melaksanakan aktivitas yang ditentukan dalam pipeline Anda.

• Penyimpanan data yang tersambung ke pabrik data. 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 (IRs), yang melakukan aktivitas tertentu dalam rangkaian. 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.

Kesalahan sementara

Gangguan sementara adalah kegagalan yang sesekali terjadi pada 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 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.

Dukungan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik di setiap 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. Bagian ini menjelaskan bagaimana setiap bagian dari layanan Data Factory mendukung redundansi zona.

Wilayah yang didukung

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

Pertimbangan

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

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.

• 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.

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.

Operasi normal

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.

Pengalaman penutupan zona

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.

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 Kesalahan sementara.

Pemulihan

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.

Pengujian 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.

Dukungan multi-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 pendekatan multi-wilayah alternatif.

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 Pendekatan multi-wilayah alternatif.

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

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.

Pendekatan multi-wilayah alternatif

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 Azure Data Factory menjelaskan ketersediaan layanan yang diharapkan. Perjanjian ini juga menjelaskan kondisi yang harus dipenuhi untuk mencapai harapan ini. Untuk memahami kondisi ini, pastikan Anda meninjau Perjanjian Tingkat Layanan (SLA) untuk Layanan Online.

Konten terkait

• Keandalan di Azure