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.

Rekomendasi implementasi produksi untuk keandalan

Untuk beban kerja produksi, kami sarankan Anda mengikuti rekomendasi ini:

  • Sebarkan hub IoT Anda di wilayah yang mendukung redundansi zona untuk komponen komputasi dan data. Untuk informasi selengkapnya, lihat Persyaratan.
  • Terapkan pola retry yang sesuai di semua perangkat dan aplikasi yang berkomunikasi dengan IoT Hub.
  • Rancang logika koneksi ulang perangkat Anda untuk menangani kesalahan sementara dan failover layanan. Untuk informasi selengkapnya, lihat Mengelola koneksi ulang perangkat untuk membuat aplikasi tangguh.
  • Untuk penyebaran skala yang lebih besar, ikuti rekomendasi berikut:
    • Terapkan backoff eksponensial dan pola coba ulang berbasis jitter di perangkat dan aplikasi saat menyambungkan kembali ke IoT Hub, yang membantu menghindari lonjakan koneksi ulang selama failover pada sisi layanan atau keterlambatan jaringan.
    • Pahami IoT Hub kuota dan batas layanan serta rencanakan cara solusi Anda menanganinya. Dengan mempertimbangkan perilaku pembatasan sisi layanan, batas koneksi, dan pertimbangan unit throughput lebih awal, Anda dapat merancang solusi Anda untuk memungkinkan skalabilitas yang dapat diprediksi dan menghindari refaktor arsitektur saat armada Anda tumbuh. Untuk panduan tambahan, lihat IoT Hub penskalaan dan kuota.
    • Gunakan Azure IoT Hub bersama dengan Azure IoT Hub Device Provisioning Service (DPS). DPS memungkinkan onboarding dan alokasi perangkat yang aman dan tanpa sentuhan di satu atau beberapa hub. Bahkan jika Anda tidak mengantisipasi memiliki armada besar, dengan menggabungkan DPS dari awal, alur kerja manufaktur dan onboarding Anda dapat menskalakan tanpa memerlukan perubahan firmware atau infrastruktur nanti. Untuk informasi selengkapnya, lihat Menyebarkan solusi IoT dalam skala besar dengan DPS.
    • Pertimbangkan untuk menggunakan kebijakan alokasi DPS untuk mendistribusikan perangkat di beberapa instans IoT Hub untuk meningkatkan ketersediaan dan ketahanan wilayah. Pendekatan ini memungkinkan penskalaan horizontal kapasitas penyerapan, dan mendukung pertumbuhan armada di masa mendatang tanpa memerlukan provisi ulang perangkat.

Gambaran umum arsitektur keandalan

Saat membuat hub IoT, Anda menyebarkan sumber daya hub IoT yang menyertakan semua fungsionalitas yang diperlukan untuk mengelola dan berkomunikasi dengan perangkat Anda. Komponen utama hub IoT meliputi:

  • Registri identitas perangkat: Database yang menyimpan informasi tentang perangkat dan modul yang dapat tersambung ke hub IoT Anda. Setiap perangkat harus memiliki entri dalam registri identitas sebelum dapat tersambung. Untuk informasi selengkapnya, lihat Memahami registri identitas di hub IoT Anda.

  • Messaging components: IoT Hub menangani olahpesan dua arah antara perangkat dan aplikasi back-end Anda, termasuk telemetri perangkat-ke-cloud, perintah cloud-ke-perangkat, dan pemanggilan metode langsung.

  • Perangkat kembar: Dokumen JSON yang menyimpan informasi status perangkat, termasuk metadata, konfigurasi, dan kondisi. Perangkat dan aplikasi back-end dapat membaca dan memperbarui perangkat kembar.

Untuk tujuan keandalan, komponen IoT Hub dikategorikan ke dalam dua grup:

  • Komponen komputasi: Mengelola koneksi perangkat, mengautentikasi permintaan, merutekan pesan, dan memproses pemanggilan metode langsung. Komponen-komponen ini menentukan kemampuan IoT Hub untuk menerima dan memproses permintaan.

  • Komponen data: Simpan registri identitas perangkat, perangkat kembar, dan pesan perangkat ke cloud. Komponen-komponen ini menentukan ketersediaan dan durabilitas data.

Perbedaan ini penting karena wilayah yang berbeda mendukung berbagai jenis redundansi untuk komponen ini.

Integrasi dengan layanan lain

Anda dapat mengintegrasikan IoT Hub dengan Azure Device Registry. Jika Anda menggunakan pendekatan ini, tinjau Reliability di Azure Device Registry untuk memahami keandalan di kedua layanan.

Jika Anda menggunakan IoT Hub Device Provisioning Service (DPS) untuk provisi perangkat, keandalan solusi Anda juga bergantung pada DPS. Untuk informasi selengkapnya, lihat ketersediaan tinggi dan pemulihan bencana IoT Hub Device Provisioning Service.

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.

Untuk implementasi skala besar, praktik yang baik adalah menggunakan jitter acak pada percobaan ulang. Jitter membantu mendistribusikan beban di seluruh partisi hub dan mengurangi kemungkinan penghambatan selama peristiwa koneksi ulang skala besar.

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.

Ketika suatu wilayah mendukung dua jenis data layanan yang redundan dan penting secara zona - termasuk Registri Identitas Perangkat - data tersebut direplikasi secara sinkron di seluruh zona ketersediaan di wilayah tersebut. Akibatnya, jika terjadi kegagalan zona tunggal, tidak ada kehilangan data yang diharapkan, dan layanan secara otomatis mengalihkan konektivitas perangkat dan lalu lintas pesan ke zona yang sehat. Meskipun permintaan dalam penerbangan dapat terpengaruh secara sementara selama peristiwa failover, kelangsungan layanan dipertahankan dan logika coba lagi perangkat biasanya memastikan pemulihan.

Persyaratan

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

IoT Hub sumber daya secara otomatis mendukung redundansi zona saat disebarkan di wilayah 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 mendeteksi kegagalan di zona ketersediaan. Anda tidak perlu melakukan apa pun untuk memulai failover zona.
  • Notification: 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 waktu henti pada sumber daya IoT Hub Anda.

  • Pengalihan lalu lintas: Jika IoT Hub disebarkan di wilayah yang mendukung redundansi zona untuk komponen komputasi, IoT Hub mendeteksi hilangnya 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, Anda tidak perlu memvalidasi proses kegagalan zona ketersediaan atau memberikan masukan tambahan.

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. Meskipun IoT Hub mendukung replikasi data asinkron ke wilayah Azure yang dipasangkan untuk tujuan pemulihan bencana, tidak ada failover lintas wilayah bawaan untuk konektivitas perangkat.

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 merancang dan menerapkan strategi failover multiregion kustom, termasuk langkah-langkah berikut:

  • Menyediakan IoT Hub sekunder di wilayah Azure yang berbeda.
  • Menerapkan mekanisme pengalihan titik akhir untuk mengarahkan perangkat ke wilayah alternatif jika diperlukan. Misalnya, Anda dapat memprovisikan setiap perangkat di kedua hub sebelumnya, dan mengonfigurasi kedua string koneksi pada perangkat sehingga perangkat dapat beralih antar hub jika diperlukan.

failover yang dikelola Microsoft ke wilayah berpasangan

Jika sumber daya Anda berada di wilayah yang dipasangkan, data hub IoT Anda direplikasi ke wilayah yang dipasangkan. Pendekatan ini dimaksudkan untuk mendukung pemulihan bencana. Jika ada kegagalan wilayah di wilayah utama hub IoT Anda, Anda tidak perlu mengambil tindakan apa pun untuk memungkinkan konektivitas perangkat berlanjut di wilayah yang dipasangkan.

Jenis failover

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.

  • Microsoft-initiated failover: 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.

Persyaratan

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

Pertimbangan

Jangan gunakan failover yang diinisiasi pelanggan untuk memigrasikan hub Anda secara permanen 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 multiregion 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 multiregion 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, termasuk Device Identity Registry, 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.

    • Microsoft-initiated failover: Microsoft dapat memutuskan untuk melakukan failover jika wilayah 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.

    • Microsoft-initiated failover: Perkirakan waktu tidak aktif sekitar 2 hingga 26 jam, dari saat wilayah hilang hingga saat sumber daya tersedia di region 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 tidak terlalu kritis yang dapat menahan gangguan operasional sekitar satu hari, mungkin untuk bergantung pada opsi yang diinisiasi Microsoft untuk mencapai tujuan pemulihan bencana (DR) solusi IoT Anda secara keseluruhan.

    • Untuk kedua jenis failover, nama domain lengkap dari instans hub IoT tetap sama setelah failover, yang berarti 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 menyegarkan alamat IP hub IoT yang di-cache

  • Pengalihan lalu lintas: Selama proses failover, IoT Hub memperbarui record 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 yang kompatibel dari titik akhir peristiwa bawaan hub IoT Anda berubah setelah failover. Perubahan ini terjadi karena klien Azure Event Hubs tidak memiliki visibilitas ke dalam peristiwa IoT Hub.

    Saat Anda menerima pesan telemetri dari endpoint bawaan dengan menggunakan klien Event Hubs atau prosesor peristiwa host, 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 endpoint dan nama, Anda dapat menggunakan Azure portal atau .NET SDK.

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

    • SDK .NET: Untuk menggunakan string koneksi hub IoT untuk mendapatkan kembali titik akhir yang kompatibel dengan Event Hubs, gunakan contoh kode sample. 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 mungkin berubah selama failover yang diinisiasi oleh Microsoft atau 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 multiregion 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 multiregion. Dalam model ini, hub IoT utama dan back end solusi Anda terutama berjalan di satu wilayah Azure. Hub IoT sekunder dan backend disebarkan di wilayah Azure yang 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 pada akhirnya konsisten serta dari duplikasi atau pengiriman peristiwa yang tidak berurutan. 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. Untuk panduan implementasi, lihat pola Konsumen Idempotent.

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

Ketahanan terhadap pemeliharaan layanan

Microsoft secara teratur menerapkan pembaruan layanan dan melakukan pemeliharaan lainnya. Platform Azure menangani aktivitas ini secara otomatis, memastikan bahwa pemeliharaan mulus dan transparan bagi Anda. Tidak ada downtime yang diharapkan selama peristiwa pemeliharaan kecuali Anda menerima pemberitahuan tentang pemeliharaan terencana melalui Azure Service Health.

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.

Konten terkait

  • Last updated on