Keandalan dalam Azure IoT Hub

Azure IoT Hub adalah layanan terkelola yang dihosting di cloud yang bertindak sebagai hub pesan pusat untuk komunikasi antara aplikasi IoT dan perangkat terlampirnya.

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 IoT Hub 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) IoT Hub.

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.

IoT Hub memberikan jaminan waktu aktif yang cukup tinggi, tetapi kegagalan sementara dapat terjadi di platform komputasi terdistribusi apa pun. Untuk menangani kegagalan sementara, bangun pola coba lagi yang sesuai dalam komponen yang berinteraksi dengan aplikasi cloud.

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.

IoT Hub mendukung dua jenis dukungan zona ketersediaan yang berbeda:

• Redundansi zona untuk data, yang secara otomatis mereplikasi data antara beberapa zona ketersediaan untuk komponen penyimpanan dasar yang menyimpan registri identitas perangkat dan pesan perangkat-ke-cloud.

• Redundansi zona untuk komputasi, yang memberikan ketahanan pada komponen yang bertanggung jawab untuk mengelola perangkat dan mengatur jalur pesan.

Dukungan wilayah

Jenis dukungan zona ketersediaan untuk hub IoT Anda bergantung pada wilayah tempatnya disebarkan.

Wilayah	Redundansi zona untuk data	Redundansi zona untuk komputasi
Australia Timur	Yes	Yes
Brasil Selatan	Yes	Yes
Kanada Tengah	Yes	Yes
India Tengah	Tidak	Yes
US Tengah	Yes	Yes
US Timur	Tidak	Yes
Prancis Tengah	Yes	Yes
Jerman Barat Tengah	Yes	Yes
Jepang Timur	Yes	Yes
Korea Tengah	Tidak	Yes
Eropa Utara	Yes	Yes
Norwegia Timur	Tidak	Yes
Qatar Tengah	Tidak	Yes
US Tengah Selatan	Tidak	Yes
Asia Tenggara	Yes	Yes
UK Selatan	Yes	Yes
Eropa Barat	Tidak	Yes
Barat AS 2	Yes	Yes
Barat AS 3	Tidak	Yes

Hub IoT yang Anda buat di wilayah yang tidak ada dalam daftar ini tidak tahan terhadap pemadaman zona.

Biaya

Tidak ada biaya tambahan untuk redundansi zona dengan IoT Hub.

Mengonfigurasi dukungan zona ketersediaan

Sumber daya IoT Hub secara otomatis mendukung redundansi zona ketika diterapkan di wilayah yang didukung . Tidak diperlukan konfigurasi lainnya.

Perilaku ketika semua zona sehat

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

• Replikasi data antar zona: Saat hub IoT Anda disebarkan di wilayah yang mendukung redundansi zona untuk data, perubahan data direplikasi antar zona ketersediaan secara otomatis. Replikasi terjadi secara sinkron.

• Perutean lalu lintas antar zona: Saat hub IoT Anda disebarkan di wilayah yang mendukung redundansi zona untuk komponen komputasi, permintaan dirutekan ke instans utama layanan di salah satu zona ketersediaan. Azure memilih instans aktif dan zona secara otomatis.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika sumber daya IoT Hub dikonfigurasi untuk redundansi zona dan ada pemadaman zona ketersediaan.

• Deteksi dan respons: Layanan IoT Hub bertanggung jawab untuk mendeteksi kegagalan di zona ketersediaan. Anda tidak perlu melakukan apa pun untuk memulai failover zona.

• 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 keseluruhan layanan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

• Permintaan aktif: Selama kegagalan zona, permintaan aktif mungkin dihilangkan. Klien dan perangkat Anda harus memiliki logika coba lagi yang memadai yang diterapkan untuk menangani kesalahan sementara.

• Kehilangan data yang diharapkan: Saat hub IoT Anda disebarkan di wilayah yang mendukung redundansi zona untuk data, kegagalan zona tidak boleh menyebabkan kehilangan data.

• Expected downtime: Saat IoT hub Anda disebarkan di wilayah yang mendukung redundansi zona untuk komponen komputasi dan data, kegagalan zona seharusnya tidak menyebabkan keterhentian layanan pada sumber daya IoT Hub Anda.

• Pengalihan lalu lintas: Saat hub IoT Anda disebarkan di wilayah yang mendukung redundansi zona untuk komponen komputasi, IoT Hub mendeteksi hilangnya koneksi zona. Kemudian, setiap permintaan baru secara otomatis dialihkan ke instans utama layanan baru di salah satu zona ketersediaan sehat.

Pemulihan Zona

Saat zona ketersediaan pulih, IoT Hub secara otomatis memulihkan instans di zona ketersediaan dan mengalihkan lalu lintas antara instans Anda seperti biasa.

Uji kegagalan zona

Karena IoT Hub sepenuhnya mengelola perutean lalu lintas, failover, dan failback untuk kegagalan zona ketersediaan, Anda tidak perlu memvalidasi proses kegagalan zona ketersediaan atau memberikan input lebih lanjut.

Ketahanan terhadap kegagalan di seluruh wilayah

IoT Hub adalah layanan satu wilayah. Jika wilayah menjadi tidak tersedia, sumber daya IoT Hub Anda juga tidak tersedia.

Namun, jika sumber daya Anda berada di wilayah yang dipasangkan, data hub IoT Anda direplikasi ke wilayah yang dipasangkan.

Hub IoT Anda mungkin beralih ke wilayah yang dipasangkan dalam skenario berikut:

• Failover yang dimulai pelanggan: Anda dapat memicu failover manual ke wilayah pasangannya sendiri, apakah wilayah tersebut mengalami gangguan atau tidak. Anda dapat menggunakan pendekatan ini untuk melakukan failover dan latihan yang direncanakan.

• Failover yang dimulai Microsoft: Jika wilayah hilang, Microsoft dapat memulai failover hub IoT ke wilayah yang dipasangkan. Namun, Microsoft tidak mungkin memulai failover kecuali setelah penundaan yang signifikan dan berdasarkan upaya terbaik. Failover sumber daya IoT Hub mungkin terjadi pada waktu yang berbeda dari failover layanan Azure lainnya. Proses ini adalah opsi default dan tidak memerlukan intervensi dari Anda.

Jika sumber daya berada di wilayah yang tidak berpasangan, Microsoft tidak mereplikasi konfigurasi dan data di seluruh wilayah, dan tidak ada failover lintas wilayah bawaan. Namun, Anda dapat menyebarkan sumber daya terpisah ke beberapa wilayah. Dalam skenario ini, Anda bertanggung jawab untuk mengelola replikasi, distribusi lalu lintas, dan failover.

Jika hub IoT Anda berada di wilayah yang tidak berpasangan, atau jika perilaku replikasi dan failover default tidak memenuhi kebutuhan Anda, Anda dapat menggunakan solusi multi-wilayah kustom untuk ketahanan guna merencanakan dan memulai failover.

Persyaratan

• Dukungan wilayah: Replikasi dan failover default hanya didukung di wilayah berpasangan.
• Opsi replikasi wilayah berpasangan dan failover tersedia untuk semua tingkatan IoT Hub.

Pertimbangan

Jangan gunakan failover yang diinisiasi oleh pelanggan untuk memindahkan hub Anda secara permanen di antara wilayah Azure yang dipasangkan. Umumnya, perangkat terletak dekat dengan wilayah utama hub. Jika Anda memindahkan hub ke wilayah sekunder, latensi akan meningkat untuk operasi antara perangkat dan hub IoT di lokasi sekunder.

Biaya

Untuk hub di wilayah yang dipasangkan, tidak ada biaya tambahan untuk replikasi atau failover data lintas wilayah.

Jika hub IoT Anda berada di wilayah yang tidak berpasangan, lihat Solusi multi-wilayah kustom untuk ketahanan untuk informasi biaya yang mungkin.

Mengonfigurasi replikasi dan mempersiapkan failover

Secara default, replikasi data lintas wilayah secara otomatis dikonfigurasi saat Anda membuat hub IoT di wilayah berpasangan. Proses ini adalah opsi default dan tidak memerlukan intervensi dari Anda. Di wilayah kecuali Brasil Selatan dan Asia Tenggara (Singapura), data pelanggan Anda tidak disimpan atau diproses di luar geografi tempat Anda menyebarkan instans layanan.

Jika hub IoT Anda berada di wilayah Brasil Selatan atau Asia Tenggara (Singapura), Anda dapat menonaktifkan replikasi data dan menolak failover. Untuk informasi selengkapnya, lihat Menonaktifkan pemulihan bencana (DR).

Jika hub IoT Anda berada di wilayah yang tidak berpasangan, Anda perlu merencanakan pendekatan replikasi dan failover lintas wilayah Anda sendiri. Untuk informasi selengkapnya, lihat Solusi multi-wilayah kustom untuk ketahanan.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang dapat diharapkan ketika sebuah hub IoT dikonfigurasi untuk replikasi lintas wilayah dan gagal berfungsi, sementara wilayah utama tetap beroperasi.

• Replikasi data antar wilayah: Data direplikasi secara otomatis ke wilayah yang dipasangkan. Replikasi terjadi secara asinkron, yang berarti bahwa beberapa kehilangan data diharapkan jika kegagalan terjadi. Tidak ada replikasi data antar wilayah untuk hub IoT di wilayah yang tidak berpasangan.

• Perutean lalu lintas antar wilayah: Dalam operasi normal, lalu lintas hanya mengalir ke wilayah utama.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika hub IoT dikonfigurasi untuk replikasi lintas wilayah dan failover dan ada pemadaman di wilayah utama.

• Deteksi dan respons: Tanggung jawab untuk mendeteksi dan merespons pemadaman di wilayah utama dapat bervariasi.

  • Failover yang diinisiasi oleh pelanggan: Anda bertanggung jawab untuk mendeteksi kehilangan region dan memutuskan kapan untuk melakukan failover. Untuk informasi selengkapnya tentang cara melakukan failover yang diinisiasi oleh pelanggan antara wilayah yang dipasangkan, lihat Melakukan failover manual untuk hub IoT.

    Ada pembatasan terkait seberapa sering Anda dapat melakukan alih fungsi atau mengembalikan fungsi yang dilakukan oleh pelanggan.

    • Pengguna diizinkan untuk melakukan dua operasi failover yang berhasil dan dua operasi failback yang berhasil per hari.

    • Operasi failover atau failback berturut-turut tidak diizinkan. Anda harus menunggu satu jam di antara operasi ini.

  • Failover yang dilakukan Microsoft: Microsoft dapat memutuskan untuk melakukan failover jika region utama hilang. Proses ini dapat memakan waktu beberapa jam setelah hilangnya wilayah utama, atau bahkan lebih lama dalam beberapa skenario. Failover sumber daya IoT Hub mungkin tidak terjadi pada saat yang sama dengan layanan Azure lainnya.

• Permintaan aktif: Setiap permintaan yang diproses wilayah utama selama failover kemungkinan akan hilang. Klien harus mencoba kembali permintaan setelah failover selesai.

• Kehilangan data yang diharapkan: Untuk wilayah yang dipasangkan, data direplikasi secara asinkron ke wilayah yang dipasangkan. Akibatnya, beberapa kehilangan data kemungkinan terjadi setelah pemulihan sistem. Proses ini berlaku untuk failover yang dikelola Microsoft dan dikelola pelanggan. Tabel berikut menguraikan tujuan titik pemulihan (RPO), atau kehilangan data yang diharapkan, dari setiap jenis data yang disimpan hub IoT.

  Jenis data	RPO
  Registri identitas	Kehilangan data selama 0-5 menit
  Data kembar perangkat	Kehilangan data selama 0-5 menit
  Pesan cloud-ke-perangkat 1	Kehilangan data selama 0-5 menit
  Pekerjaan induk 1 dan pekerjaan perangkat	Kehilangan data selama 0-5 menit
  Pesan perangkat ke cloud	Semua pesan yang belum dibaca hilang
  Pesan umpan balik dari cloud ke perangkat	Semua pesan yang belum dibaca hilang

  1 Pesan cloud ke perangkat dan pekerjaan induk tidak dipulihkan dalam failover yang diprakarsai oleh pelanggan.

• Waktu henti yang diharapkan: Waktu henti yang diharapkan selama failover wilayah tergantung pada jenis failover.

  • Failover yang dimulai oleh pelanggan: Harapkan sekitar 10 menit hingga 2 jam waktu henti dari saat wilayah hilang hingga sumber daya operasional di wilayah yang dipasangkan. Jumlah perangkat yang terdaftar pada instans hub IoT dalam proses failover memengaruhi waktu pemulihan sistem. Anda dapat mengharapkan waktu pemulihan untuk hub yang menghosting sekitar 100.000 perangkat sekitar 15 menit.

  • Failover yang dimulai oleh Microsoft: Perkirakan sekitar 2 hingga 26 jam waktu henti dari saat wilayah tidak tersedia hingga sumber daya tersedia di wilayah yang dipasangkan.

    Jumlah waktu pemulihan yang tinggi adalah karena Microsoft harus melakukan operasi failover atas nama semua pelanggan yang terpengaruh di wilayah tersebut. Untuk sistem penting, Anda harus menggunakan failover yang dipicu oleh pelanggan untuk mengurangi waktu henti. Namun, jika Anda menjalankan solusi IoT yang kurang penting yang dapat mempertahankan waktu tidak aktif sekitar satu hari, mungkin untuk bergantung pada opsi yang diprakarsai oleh Microsoft untuk memenuhi tujuan pemulihan bencana keseluruhan untuk solusi IoT Anda.

  • Untuk kedua jenis failover, nama domain yang sepenuhnya memenuhi syarat dari instans hub IoT tetap sama setelah failover, yang berarti bahwa string koneksi juga tetap sama. Namun, karena alamat IP yang mendasar berubah, klien harus menunggu catatan Sistem Nama Domain (DNS) diperbarui sebelum mengakses hub IoT setelah failover.

    Penting

    SDK IoT Hub tidak menyimpan alamat IP IoT hub. Kode pengguna yang berinteraksi dengan SDK juga tidak boleh menyimpan alamat IP hub IoT.

    Karena faktor-faktor ini, waktu untuk operasi runtime yang dilakukan terhadap instans hub IoT Anda menjadi beroperasi penuh setelah proses failover dapat diekspresikan dengan menggunakan fungsi berikut:

    Waktu untuk memulihkan = RTO [10 menit hingga 2 jam untuk failover yang dimulai pelanggan atau 2 hingga 26 jam untuk failover yang dimulai Microsoft] + Penundaan penyebaran DNS + Waktu yang diperlukan aplikasi klien untuk me-refresh alamat IP hub IoT yang di-cache

• Traffic rerouting: Selama proses failover, IoT Hub memperbarui catatan DNS untuk menunjuk ke wilayah yang dipasangkan. Semua permintaan berikutnya dikirim ke wilayah yang dipasangkan.

  Setelah operasi failover untuk hub IoT selesai, semua operasi dari perangkat dan aplikasi back-end diharapkan untuk terus bekerja tanpa memerlukan intervensi manual. Kelangsungan ini memastikan bahwa pesan perangkat-ke-cloud Anda terus berfungsi, dan seluruh registri perangkat utuh. Jika Anda memancarkan peristiwa melalui Azure Event Grid, peristiwa tersebut dapat digunakan melalui langganan yang sama dengan yang Anda konfigurasi sebelumnya selama langganan Event Grid tersebut terus tersedia. Tidak diperlukan penanganan lebih lanjut untuk titik akhir kustom.

Konfigurasi setelah failover diperlukan

Bergantung pada tempat Anda merutekan pesan hub IoT, Anda mungkin perlu melakukan langkah tambahan setelah failover selesai.

• Azure Event Hubs: Nama dan titik akhir peristiwa internal hub IoT Anda berubah setelah pindah alih. Perubahan ini terjadi karena klien Azure Event Hubs tidak memiliki visibilitas ke dalam peristiwa IoT Hub.

  Saat Anda menerima pesan telemetri dari endpoint bawaan menggunakan klien Event Hubs atau pengolah acara, gunakan string koneksi hub IoT untuk membuat koneksi. Pendekatan ini memastikan bahwa aplikasi back-end Anda terus berfungsi tanpa memerlukan intervensi manual setelah failover.

  Jika Anda menggunakan nama dan titik akhir yang kompatibel dengan Event Hubs di aplikasi Anda secara langsung, Anda perlu mengambil titik akhir yang kompatibel dengan Event Hubs baru setelah failover untuk melanjutkan operasi. Untuk mengambil titik akhir dan nama, Anda dapat menggunakan portal Azure atau SDK .NET:

  • Azure Portal: Untuk informasi selengkapnya tentang cara menggunakan portal untuk mengambil titik akhir dan nama yang kompatibel dengan Event Hubs, lihat bagian Hubungkan ke titik akhir bawaan.

  • SDK .NET: Untuk menggunakan string koneksi hub IoT untuk memulihkan titik akhir yang kompatibel dengan Azure Event Hubs, gunakan kode contoh. Contoh kode ini menggunakan string koneksi untuk mendapatkan titik akhir Azure Event Hubs baru dan membuat ulang koneksi. Anda harus menginstal Visual Studio.

• Azure Functions dan Azure Stream Analytics: Jika Anda menggunakan Azure Functions atau Stream Analytics untuk menyambungkan ke titik akhir peristiwa bawaan, Anda harus memperbarui titik akhir Azure Event Hubs tempat fungsi atau pekerjaan tersambung, mengikuti proses yang sama yang diuraikan dalam poin sebelumnya. Kemudian lakukan tindakan Mulai Ulang karena setiap offset aliran peristiwa menjadi tidak valid setelah failover.

• Azure Storage: Saat perutean ke Azure Storage, cantumkan blob atau file terlebih dahulu. Kemudian lakukan iterasi pada mereka untuk memastikan bahwa semua blob atau file dibaca tanpa mengasumsikan adanya partisi. Rentang partisi berpotensi berubah selama failover yang dimulai oleh Microsoft atau yang dimulai oleh pelanggan. Anda dapat menggunakan List Blobs API untuk menghitung daftar blob atau List Azure Data Lake Storage API untuk daftar file. Untuk informasi selengkapnya, lihat Azure Storage sebagai titik akhir perutean.

Pemulihan wilayah

Untuk melakukan failback ke wilayah utama, Anda dapat memicu tindakan failover secara manual untuk kedua kalinya. Penting untuk mengingat pembatasan berapa kali Anda dapat melakukan failover.

Jika operasi failover asli dilakukan untuk memulihkan dari pemadaman yang berkepanjangan di wilayah utama asli, lakukan pemulihan ke wilayah utama setelah wilayah utama pulih dari pemadaman.

Pengujian untuk mendeteksi kegagalan wilayah

Untuk mensimulasikan kegagalan selama pemadaman wilayah, Anda dapat memicu failover manual hub IoT Anda. Namun, karena failover regional menyebabkan waktu henti dan kehilangan data, Anda hanya boleh melakukan pengujian failover di lingkungan nonproduksi. Untuk informasi selengkapnya, lihat Perilaku selama kegagalan wilayah. Pertimbangkan untuk menyiapkan instans IoT Hub pengujian untuk memulai opsi failover yang direncanakan secara berkala. Pengujian berkala dapat membantu Anda membangun keyakinan pada kemampuan Anda untuk memulihkan dan mengoperasikan solusi end-to-end Anda secara efektif ketika bencana nyata terjadi.

Solusi multi-wilayah kustom untuk ketahanan

Kemampuan failover lintas wilayah IoT Hub tidak cocok untuk skenario berikut:

• Hub IoT Anda berada di wilayah yang tidak berpairan.

• Tujuan waktu aktif bisnis Anda tidak terpenuhi oleh waktu pemulihan atau kehilangan data yang disediakan oleh opsi failover bawaan.

• Anda perlu melakukan failover ke wilayah yang bukan pasangan wilayah utama Anda.

Anda dapat merancang solusi failover lintas wilayah yang disesuaikan dengan setiap perangkat individual. Perawatan lengkap topologi penyebaran dalam solusi IoT berada di luar cakupan artikel ini, tetapi Anda dapat mempertimbangkan model penyebaran multi-wilayah. Dalam model ini, hub IoT utama dan back end solusi Anda terutama berjalan di satu wilayah Azure. Hub IoT sekunder dan back end disebarkan di wilayah Azure lain. Jika hub IoT di wilayah utama mengalami pemadaman atau konektivitas jaringan dari perangkat ke wilayah utama terganggu, perangkat menggunakan titik akhir layanan sekunder.

• Waktu henti yang diharapkan: Pendekatan ini memiliki waktu henti kurang dari satu menit tetapi dapat menjadi kompleks untuk diterapkan.

• Kehilangan data yang diharapkan: Jumlah kehilangan data tergantung pada penyimpanan data tertentu yang Anda gunakan dan cara Anda mengonfigurasi replikasi geografis di antara mereka.

• Biaya: Pendekatan ini mengharuskan Anda untuk menyediakan setidaknya satu hub IoT tambahan, yang meningkatkan biaya keseluruhan Anda.

Pada tingkat tinggi, untuk menerapkan model failover regional dengan IoT Hub, Anda perlu mengambil langkah-langkah berikut:

• Hub IoT sekunder dan logika perutean perangkat: Jika layanan di wilayah utama Anda terganggu, perangkat harus mulai tersambung ke wilayah sekunder Anda. Karena sifat sadar status dari sebagian besar layanan yang terlibat, administrator solusi biasanya memicu proses failover antar-wilayah secara manual. Cara terbaik untuk mengomunikasikan titik akhir baru ke perangkat sambil mempertahankan kontrol atas prosesnya adalah dengan meminta mereka memeriksa layanan pramutamu secara teratur untuk titik akhir aktif saat ini. Layanan pramutamu dapat menjadi aplikasi web yang direplikasi dan terus dapat dijangkau dengan menggunakan teknik pengalihan DNS, seperti Azure Traffic Manager.

  Nota

  Traffic Manager tidak memiliki dukungan bawaan untuk IoT Hub. Anda dapat mengonfigurasi titik akhir Traffic Manager kustom untuk setiap hub IoT. Konfigurasikan probe kesehatan untuk titik akhir Traffic Manager agar menggunakan titik akhir dari hub IoT.

• Replikasi registri identitas: Agar dapat digunakan, hub IoT sekunder harus berisi semua identitas perangkat yang dapat terhubung ke solusi. Solusinya harus menyimpan cadangan identitas perangkat yang direplikasi secara geografis dan mengunggahnya ke hub IoT sekunder sebelum mengalihkan titik akhir aktif untuk perangkat. Fungsionalitas ekspor identitas perangkat IoT Hub berguna dalam konteks ini. Untuk informasi selengkapnya, lihat Memahami registri identitas di hub IoT Anda.

• Gabungkan logika: Ketika wilayah utama tersedia lagi, semua status dan data yang dibuat di wilayah sekunder harus dimigrasikan kembali ke wilayah utama. Status dan data ini sebagian besar terkait dengan identitas perangkat dan metadata aplikasi, yang harus digabungkan dengan hub IoT utama dan penyimpanan khusus aplikasi lainnya di wilayah utama.

  Untuk menyederhanakan langkah ini, gunakan operasi idempotensi . Operasi idempoten meminimalkan efek samping dari distribusi peristiwa yang konsisten dalam akhirnya, serta dari duplikat atau pengiriman peristiwa yang tidak sesuai urutan. Selain itu, logika aplikasi harus dirancang untuk mentolerir potensi inkonsistensi atau status yang sedikit kedaluarsa. Skenario ini dapat terjadi karena waktu tambahan yang diperlukan sistem untuk pemulihan berdasarkan RPO.

Pencadangan dan pemulihan

Layanan IoT Hub memungkinkan operasi ekspor massal, yang memungkinkan Anda mengekspor seluruh registri identitas IoT hub. Data ini ditransfer ke kontainer blob Azure Storage dengan menggunakan tanda tangan akses bersama. Metode ini mengaktifkan Anda membuat cadangan informasi perangkat yang andal dalam kontainer blob yang Anda kontrol. Untuk informasi selengkapnya, lihat Impor dan ekspor identitas perangkat IoT Hub secara massal.

Anda juga dapat mengekspor templat Azure Resource Manager hub IoT (templat ARM) yang ada untuk membuat cadangan konfigurasi hub IoT. Untuk informasi selengkapnya, lihat Memigrasikan hub IoT secara manual dengan menggunakan templat ARM.

Untuk sebagian besar solusi, Anda tidak boleh mengandalkan cadangan secara eksklusif. Sebagai gantinya, gunakan kemampuan lain yang dijelaskan dalam panduan ini untuk mendukung persyaratan ketahanan Anda. Namun, pencadangan melindungi dari beberapa risiko yang tidak dapat dicegah oleh pendekatan lain. Untuk informasi selengkapnya, lihat Apa itu redundansi, replikasi, dan cadangan?.

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 Perjanjian Tingkat Layanan untuk layanan online.

Konten terkait

• Reliabilitas dalam Azure
• Skalabilitas solusi IoT, ketersediaan tinggi, dan DR