Ketersediaan tinggi IoT Hub dan pemulihan bencana
Sebagai langkah pertama menuju penerapan solusi IoT yang tangguh, arsitek, pengembang, dan pemilik bisnis harus menentukan sasaran waktu aktif untuk solusi yang dibangun. Sasaran tersebut dapat ditentukan terutama berdasarkan tujuan bisnis spesifik untuk setiap skenario. Dalam konteks ini, artikel Panduan Teknis Kelangsungan Bisnis Azure menjelaskan kerangka kerja umum untuk membantu Anda memikirkan kelangsungan bisnis dan pemulihan bencana. Makalah Pemulihan bencana dan ketersediaan tinggi untuk aplikasi Azure memberikan panduan arsitektur tentang strategi aplikasi Azure untuk mencapai Ketersediaan Tinggi (HA) dan Pemulihan Bencana (DR).
Artikel ini membahas fitur HA dan DR yang ditawarkan secara khusus oleh layanan IoT Hub. Area luas yang dibahas dalam artikel ini adalah:
- HA intra-wilayah
- DR lintas wilayah
- Mencapai HA lintas wilayah
Bergantung pada tujuan waktu aktif yang Anda tentukan untuk solusi IoT Anda, Anda harus menentukan opsi mana yang diuraikan dalam artikel ini yang paling sesuai dengan tujuan bisnis Anda. Memasukkan salah satu alternatif HA/DR ini ke dalam solusi IoT Anda memerlukan evaluasi yang cermat terhadap pertukaran antara:
- Tingkat ketahanan yang Anda butuhkan
- Kompleksitas pemeliharaan dan implementasi
- Dampak COGS
HA intra-wilayah
Layanan IoT Hub menyediakan HA intra-wilayah dengan menerapkan redundansi di hampir semua lapisan layanan. SLA yang diterbitkan oleh layanan IoT Hub dicapai dengan memanfaatkan redundansi tersebut. Tidak ada pekerjaan tambahan yang diperlukan oleh pengembang solusi IoT untuk memanfaatkan fitur HA ini. Meskipun IoT Hub menawarkan jaminan waktu aktif yang cukup tinggi, kegagalan sementara masih dapat diharapkan seperti halnya platform komputasi terdistribusi. Jika Anda baru mulai memigrasikan solusi ke cloud dari solusi lokal, fokus Anda perlu beralih dari mengoptimalkan "waktu rata-rata di antara kegagalan" menjadi "waktu rata-rata untuk pemulihan". Dengan kata lain, kegagalan sementara harus dianggap normal saat beroperasi dengan cloud dalam campuran. Pola coba lagi yang sesuai harus dibangun ke komponen yang berinteraksi dengan aplikasi cloud untuk menangani kegagalan sementara.
Zona ketersediaan
IoT Hub mendukung zona ketersediaan Azure. Zona ketersediaan adalah penawaran ketersediaan tinggi yang melindungi aplikasi dan data Anda dari kegagalan pusat data. Wilayah dengan dukungan zona ketersediaan terdiri dari tiga zona yang mendukung wilayah tersebut. Setiap zona menyediakan satu atau beberapa pusat data, masing-masing di lokasi fisik yang unik dengan daya, pendinginan, dan jaringan independen. Konfigurasi ini menyediakan replikasi dan redundansi dalam wilayah.
Zona ketersediaan memberikan dua keuntungan: ketahanan data dan penyebaran yang lebih lancar.
Ketahanan data berasal dari mengganti layanan penyimpanan yang mendasarinya dengan penyimpanan yang didukung zona ketersediaan. Ketahanan data penting untuk solusi IoT karena solusi ini sering beroperasi di lingkungan yang kompleks, dinamis, dan tidak pasti di mana kegagalan atau gangguan dapat memiliki konsekuensi yang signifikan. Apakah solusi IoT mendukung lantai manufaktur, lingkungan ritel atau restoran, sistem layanan kesehatan, atau infrastruktur, ketersediaan dan kualitas data diperlukan untuk pulih dari kegagalan dan untuk memberikan layanan yang andal dan konsisten.
Penyebaran yang lebih lancar berasal dari mengganti perangkat keras pusat data yang mendasarinya dengan perangkat keras yang lebih baru yang mendukung zona ketersediaan. Peningkatan perangkat keras ini meminimalkan dampak pelanggan dari pemutusan dan koneksi ulang perangkat serta waktu henti terkait penyebaran lainnya. Tim teknik IoT Hub menyebarkan beberapa pembaruan untuk setiap hub IoT setiap bulan, karena alasan keamanan dan untuk memberikan peningkatan fitur. Perangkat keras yang didukung zona ketersediaan dibagi menjadi 15 domain pembaruan sehingga setiap pembaruan berjalan lebih lancar, dengan dampak minimal pada alur kerja Anda. Untuk informasi selengkapnya tentang domain pembaruan, lihat Set ketersediaan.
Dukungan zona ketersediaan untuk IoT Hub diaktifkan secara otomatis untuk sumber daya IoT Hub baru yang dibuat di wilayah Azure berikut:
| Wilayah | Ketahanan data | Penyebaran yang lebih lancar |
|---|---|---|
| Australia Timur | 
|
|
| Brasil Selatan |
|
|
| Kanada Tengah |
|
|
| India Tengah | 
|
|
| US Tengah |
|
|
| US Timur |
|
|
| Prancis Tengah |
|
|
| Jerman Barat Tengah |
|
|
| Jepang Timur |
|
|
| Korea Tengah |
|
|
| Eropa Utara |
|
|
| Norwegia Timur |
|
|
| Qatar Tengah |
|
|
| US Selatan |
|
|
| Asia Tenggara |
|
|
| UK Selatan |
|
|
| Eropa Barat |
|
|
| US Barat 2 |
|
|
| AS Barat 3 |
|
|
DR lintas wilayah
Mungkin ada beberapa situasi yang jarang terjadi saat pusat data mengalami pemadaman yang berkepanjangan karena kegagalan daya atau kegagalan lain yang melibatkan aset fisik. Peristiwa seperti itu jarang terjadi di mana kemampuan HA intra wilayah yang dijelaskan sebelumnya mungkin tidak selalu membantu. IoT Hub menyediakan beberapa solusi untuk memulihkan dari pemadaman yang diperpanjang tersebut.
Opsi pemulihan yang tersedia untuk pelanggan dalam situasi seperti tersebut adalah kegagalan yang dimulai Microsoft dan failover manual. Perbedaan mendasar antara keduanya adalah bahwa Microsoft memulai yang pertama dan pengguna memulai yang terakhir. Selain itu, failover manual memberikan tujuan waktu pemulihan (RTO) yang lebih rendah dibandingkan dengan opsi kegagalan yang dimulai Microsoft. RTO tertentu yang ditawarkan dengan setiap opsi dibahas di bagian berikut. Saat salah satu dari opsi ini untuk melakukan kegagalan hub IoT dari region utamanya dijalankan, hub menjadi berfungsi penuh di region yang dipasangkan secara geografis Azure yang sesuai.
Kedua opsi kegagalan ini menawarkan tujuan titik pemulihan (RPO) berikut:
| Jenis Data | Tujuan titik pemulihan (RPO) |
|---|---|
| Registri identitas | 0-5 menit kehilangan data |
| Perangkat data kembar | 0-5 menit kehilangan data |
| Pesan cloud-ke-perangkat1 | 0-5 menit kehilangan data |
| Pekerjaan induk1 dan perangkat | 0-5 menit kehilangan data |
| Pesan perangkat ke cloud | Semua pesan yang belum dibaca hilang |
| Pesan umpan balik cloud-ke-perangkat | Semua pesan yang belum dibaca hilang |
1Pesan cloud-ke-perangkat dan pekerjaan induk tidak dipulihkan sebagai bagian dari failover manual.
Setelah operasi kegagalan untuk hub IoT selesai, semua operasi dari perangkat dan aplikasi terbelakang diharapkan untuk terus bekerja tanpa memerlukan intervensi manual. Ini berarti bahwa pesan perangkat-ke-cloud Anda akan terus berfungsi, dan seluruh registri perangkat tetap utuh. Peristiwa yang dikeluarkan melalui Event Grid dapat dikonsumsi melalui langganan yang sama yang dikonfigurasi sebelumnya selama langganan Event Grid tersebut terus tersedia. Tidak ada penanganan tambahan yang diperlukan untuk titik akhir kustom.
Perhatian
- Nama dan titik akhir yang kompatibel dengan Azure Event Hubs dari titik akhir peristiwa bawaan IoT Hub berubah setelah failover. Saat menerima pesan telemetri dari titik akhir bawaan menggunakan klien Azure Event Hubs atau host prosesor peristiwa, Anda harus menggunakan hub IoT string koneksi untuk membuat koneksi. Ini memastikan bahwa aplikasi terbelakang Anda terus bekerja tanpa memerlukan intervensi manual pasca kegagalan. Jika Anda menggunakan nama dan titik akhir yang kompatibel dengan Hub Peristiwa di aplikasi Anda secara langsung, Anda harus mengambil titik akhir yang kompatibel dengan Hub Peristiwa setelah kegagalan untuk melanjutkan operasi. Untuk informasi lebih lanjut, lihat Failover manual dan Pusat Aktivitas.
- Jika Anda menggunakan Azure Functions atau Azure Stream Analytics untuk menghubungkan titik akhir Peristiwa bawaan, Anda mungkin perlu melakukan Hidupkan Ulang. Ini karena selama kegagalan offset sebelumnya tidak lagi valid.
- Saat merutekan ke penyimpanan, sebaiknya membuat daftar blob atau file dan kemudian mengulanginya, untuk memastikan semua blob atau file dibaca tanpa membuat asumsi partisi. Rentang partisi berpotensi berubah selama kegagalan yang dimulai Microsoft atau failover manual. Anda dapat menggunakan Daftar API Blob untuk menghitung daftar blob atau Daftar ADLS Gen2 API untuk daftar file. Untuk mempelajari selengkapnya, lihat Azure Storage sebagai titik akhir perutean.
Kegagalan yang dimulai Microsoft
Failover yang dimulai Microsoft dilakukan oleh Microsoft dalam situasi yang jarang terjadi untuk mengalihkan semua hub IoT dari wilayah yang terpengaruh ke wilayah yang dipasangkan secara geografis yang sesuai. Proses ini adalah opsi default dan tidak memerlukan intervensi dari pengguna. Microsoft berhak untuk menentukan kapan opsi ini akan dilaksanakan. Mekanisme ini tidak melibatkan persetujuan pengguna sebelum hub pengguna gagal. Kegagalan yang dimulai Microsoft memiliki tujuan waktu pemulihan (RTO) 2-26 jam.
RTO besar dikarenakan Microsoft harus melakukan operasi kegagalan atas nama semua pelanggan yang terpengaruh di wilayah tersebut. Jika Anda menjalankan solusi IoT yang kurang penting yang dapat mempertahankan waktu henti kira-kira sehari, tidak masalah bagi Anda untuk mengambil dependensi pada opsi ini untuk memenuhi tujuan pemulihan bencana secara keseluruhan untuk solusi IoT Anda. Total waktu untuk operasi runtime bahasa umum menjadi beroperasi penuh setelah proses ini dipicu, dijelaskan di bagian "Waktu untuk memulihkan".
Hanya pengguna yang menyebarkan hub IoT ke wilayah Brasil Selatan dan Asia Tenggara (Singapura) yang dapat menolak fitur ini. Untuk informasi selengkapnya, lihat Menonaktifkan pemulihan bencana.
Catatan
Azure IoT Hub tidak menyimpan atau memproses data pelanggan di luar geografi tempat Anda menyebarkan instans layanan. Untuk informasi selengkapnya, lihat Replikasi lintas wilayah di Azure.
Failover manual
Jika sasaran waktu aktif bisnis Anda tidak dipenuhi oleh RTO yang disediakan oleh kegagalan yang dimulai oleh Microsoft, pertimbangkan untuk menggunakan failover manual untuk memicu sendiri proses kegagalan. RTO yang menggunakan opsi ini bisa berkisar antara 10 menit hingga beberapa jam. RTO saat ini merupakan fungsi dari jumlah perangkat yang terdaftar terhadap instans hub IoT yang gagal. Anda dapat mengharapkan RTO untuk hub yang meng-hosting sekitar 100.000 perangkat berada di rata-rata 15 menit. Total waktu untuk operasi runtime bahasa umum menjadi beroperasi penuh setelah proses ini dipicu, dijelaskan di bagian "Waktu untuk memulihkan".
Opsi failover manual selalu tersedia untuk digunakan terlepas dari apakah region utama mengalami waktu henti atau tidak. Oleh karena itu, opsi ini berpotensi digunakan untuk melakukan kegagalan yang direncanakan. Salah satu contoh penggunaan kegagalan yang direncanakan adalah dengan melakukan latihan kegagalan secara berkala. Sebuah kata peringatan adalah bahwa operasi kegagalan yang direncanakan menghasilkan waktu henti untuk hub untuk periode yang ditentukan oleh RTO untuk opsi ini, dan juga menghasilkan kehilangan data seperti yang ditentukan oleh tabel RPO di atas. Anda dapat mempertimbangkan untuk menyiapkan instans hub IoT pengujian untuk menggunakan opsi kegagalan yang direncanakan secara berkala untuk mendapatkan keyakinan pada kemampuan Anda untuk mendapatkan solusi menyeluruh dan berjalan saat bencana nyata terjadi.
Failover manual tersedia tanpa biaya tambahan untuk hub IoT yang dibuat setelah 18 Mei 2017
Untuk petunjuk langkah demi langkah, lihat Tutorial: Melakukan failover manual untuk hub IoT
Failover manual dan Azure Event Hubs
Nama dan titik akhir yang kompatibel dengan Event Hubs dari titik akhir peristiwa bawaan IoT Hub berubah setelah failover manual. Ini karena klien Azure Event Hubs tidak memiliki visibilitas ke dalam peristiwa IoT Hub. Hal yang sama berlaku untuk klien berbasis cloud lainnya seperti Functions dan Azure Stream Analytics. Untuk mengambil titik akhir dan nama, Anda dapat menggunakan portal Azure atau .NET SDK.
Menggunakan portal
Untuk informasi selengkapnya tentang menggunakan portal untuk mengambil titik akhir yang kompatibel dengan Pusat Aktivitas dan nama yang kompatibel dengan Pusat Aktivitas, lihat Koneksi ke titik akhir bawaan.
Menggunakan .NET SDK
Untuk menggunakan IoT Hub string koneksi untuk merebut kembali titik akhir yang kompatibel dengan Azure Event Hubs, gunakan sampel yang terletak di https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs. Contoh kode menggunakan string koneksi untuk mendapatkan titik akhir Azure Event Hubs baru dan membuat ulang koneksi. Anda harus menginstal Visual Studio.
Menjalankan latihan pengujian
Latihan pengujian tidak boleh dilakukan di hub IoT yang digunakan di lingkungan produksi Anda.
Jangan gunakan failover manual untuk memigrasikan hub IoT ke wilayah lain
Failover manual tidak boleh digunakan sebagai mekanisme untuk memigrasikan hub Anda secara permanen di antara wilayah yang dipasangkan dengan geo Azure. Dengan asumsi bahwa perangkat terletak paling dekat dengan wilayah utama hub, latensi untuk operasi yang dilakukan terhadap hub IoT akan meningkat ketika hub gagal ke wilayah sekunder.
Gagal kembali
Anda dapat melakukan failback ke wilayah utama lama dengan memicu tindakan failover untuk kedua kalinya. Jika operasi kegagalan asli dilakukan untuk memulihkan dari pemadaman yang diperpanjang di wilayah utama asli, sebaiknya hub harus gagal kembali ke lokasi asli setelah lokasi tersebut pulih dari situasi pemadaman.
Penting
- Pengguna hanya diperbolehkan untuk melakukan 2 kegagalan yang berhasil dan 2 operasi failback yang berhasil per hari.
- Operasi kegagalan/failback bolak-balik tidak diperbolehkan. Anda harus menunggu selama 1 jam di antara operasi ini.
Waktu untuk memulihkan
Sementara FQDN (dan oleh karena itu string koneksi) instans hub IoT tetap menjadi failover pasca yang sama, alamat IP yang mendasar memang berubah. Waktu untuk operasi runtime yang dilakukan terhadap instans hub IoT Anda agar beroperasi penuh setelah proses failover dapat diekspresikan menggunakan fungsi berikut:
Waktu pemulihan = RTO [10 menit - 2 jam untuk failover manual | 2 - 26 jam untuk kegagalan yang dimulai Microsoft] + Penundaan propagasi DNS + Waktu yang dibutuhkan oleh aplikasi klien untuk me-refresh semua alamat IP IoT Hub yang di-cache.
Penting
SDK IoT tidak menyimpan alamat IP hub IoT. Sebaiknya kode pengguna yang berinteraksi dengan SDK tidak boleh men-cache alamat IP hub IoT.
Mengaktifkan pemulihan bencana
IoT Hub menyediakan Failover Microsoft-Initiated dan Failover Manual dengan mereplikasi data ke wilayah yang dipasangkan untuk setiap hub IoT. Untuk beberapa wilayah, Anda dapat menghindari replikasi data di luar wilayah dengan menonaktifkan pemulihan bencana saat membuat hub IoT. Wilayah berikut mendukung fitur ini:
- Brasil Selatan; wilayah berpasangan, US Tengah Selatan.
- Asia Tenggara (Singapura); wilayah berpasangan, Asia Timur (Hong Kong SAR).
Untuk menonaktifkan pemulihan bencana di wilayah yang didukung, pastikan pemulihan Bencana diaktifkan tidak dipilih saat Anda membuat hub IoT Anda:
Anda juga dapat menonaktifkan pemulihan bencana saat membuat hub IoT menggunakan templat Azure Resource Manager.
Kemampuan failover tidak akan tersedia jika Anda menonaktifkan pemulihan bencana untuk hub IoT.
Anda hanya dapat menonaktifkan pemulihan bencana untuk menghindari replikasi data di luar wilayah yang dipasangkan di Brasil Selatan atau Asia Tenggara saat Anda membuat hub IoT. Jika Anda ingin mengonfigurasi hub IoT yang ada untuk menonaktifkan pemulihan bencana, Anda perlu membuat hub IoT baru dengan pemulihan bencana dinonaktifkan dan memigrasikan hub IoT yang ada secara manual. Untuk panduan, lihat Cara memigrasikan hub IoT.
Mencapai HA lintas wilayah
Jika sasaran waktu aktif bisnis Anda tidak dipenuhi oleh RTO yang disediakan oleh opsi kegagalan yang dimulai Microsoft atau failover manual, Anda harus mempertimbangkan untuk menerapkan mekanisme kegagalan lintas wilayah otomatis per perangkat. Perlakuan lengkap topologi penyebaran dalam solusi IoT berada di luar cakupan artikel ini. Artikel ini membahas model penyebaran failover regional untuk ketersediaan tinggi dan pemulihan bencana.
Dalam model kegagalan regional, ujung belakang solusi berjalan terutama di satu lokasi pusat data. Hub IoT sekunder dan ujung belakang disebarkan di lokasi pusat data lain. Jika hub IoT di wilayah utama mengalami pemadaman atau konektivitas jaringan dari perangkat ke wilayah utama terputus, perangkat menggunakan titik akhir layanan sekunder. Anda dapat meningkatkan ketersediaan solusi dengan menerapkan model kegagalan lintas wilayah daripada tetap berada dalam satu wilayah.
Pada tingkat tinggi, untuk menerapkan model kegagalan 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. Mengingat sifat sadar status dari sebagian besar layanan yang terlibat, admin solusi biasanya memicu proses kegagalan antar-wilayah. Cara terbaik untuk mengomunikasikan titik akhir baru ke perangkat, sambil mempertahankan kontrol proses, adalah dengan memintanya secara teratur memeriksa layanan pramutamu untuk titik akhir aktif saat ini. Layanan pramutamu dapat berupa aplikasi web yang direplikasi dan tetap dapat dijangkau menggunakan teknik pengalihan DNS (misalnya, menggunakan Azure Traffic Manager).
Catatan
Layanan hub IoT bukan jenis titik akhir yang didukung di Azure Traffic Manager. Rekomendasinya adalah untuk mengintegrasikan layanan pramutamu yang diusulkan dengan manajer lalu lintas Azure dengan membuatnya mengimplementasikan API probe kesehatan titik akhir.
Replikasi registri identitas: Agar dapat digunakan, hub IoT sekunder harus berisi semua identitas perangkat yang dapat tersambung ke solusi. Solusinya harus menyimpan cadangan identitas perangkat yang direplikasi secara geografis, dan mengunggahnya ke Azure IoT hub sekunder sebelum mengalihkan titik akhir aktif untuk perangkat. Fungsionalitas ekspor identitas perangkat Azure IoT Hub berguna dalam konteks ini. Untuk informasi selengkapnya, lihat Panduan pengembang IoT Hub - registri identitas.
Logika penggabungan: Saat wilayah utama tersedia kembali, semua status dan data yang telah dibuat di situs 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, Anda harus menggunakan operasi idempoten. Operasi idempoten meminimalkan efek samping dari distribusi peristiwa yang konsisten pada akhirnya, dan dari duplikat atau pengiriman peristiwa yang rusak. Selain itu, logika aplikasi harus dirancang untuk menoleransi potensi inkonsistensi atau status yang sedikit kedaluwarsa. Situasi ini dapat terjadi karena waktu tambahan yang diperlukan sistem untuk sembuh berdasarkan tujuan titik pemulihan (RPO).
Memilih opsi HA/DR yang tepat
Berikut ringkasan opsi HA/DR yang disajikan dalam artikel ini yang dapat digunakan sebagai kerangka acuan untuk memilih opsi yang tepat yang sesuai untuk solusi Anda.
| Opsi HA/DR | RTO | RPO | Memerlukan intervensi manual? | Kompleksitas implementasi | Dampak biaya |
|---|---|---|---|---|---|
| Kegagalan yang dimulai Microsoft | 2 - 26 jam | Lihat tabel RPO di atas | No | Tidak | Tidak |
| Failover manual | 10 menit - 2 jam | Lihat tabel RPO di atas | Ya | Sangat rendah. Anda hanya perlu memicu operasi ini dari portal. | Tidak |
| HA lintas wilayah | < 1 menit | Tergantung pada frekuensi replikasi solusi HA kustom Anda | No | Sangat Penting | > 1x biaya 1 hub ioT |