IoT Hub magas rendelkezésre állása és vészhelyreállítása
A rugalmas IoT-megoldások bevezetésének első lépéseként az építészeknek, fejlesztőknek és üzleti tulajdonosoknak meg kell határozniuk az általuk készített megoldások üzemidejű céljait. Ezek a célok elsősorban az egyes forgatókönyvek konkrét üzleti célkitűzései alapján határozhatók meg. Ebben az összefüggésben az Azure üzletmenet-folytonossági műszaki útmutatója egy általános keretrendszert ír le, amely segít az üzletmenet folytonosságának és vészhelyreállításának átgondolásában. Az Azure-alkalmazások vészhelyreállítása és magas rendelkezésre állása című dokumentum architektúra-útmutatást nyújt az Azure-alkalmazások magas rendelkezésre állási (HA) és vészhelyreállítási (DR) eléréséhez szükséges stratégiáihoz.
Ez a cikk az IoT Hub szolgáltatás által kínált HA- és DR-funkciókat ismerteti. A cikkben tárgyalt általános területek a következők:
- Régión belüli HA
- Régióközi dr.
- Régiók közötti HA elérése
Az IoT-megoldásokhoz meghatározott üzemidő-céloktól függően meg kell határoznia, hogy a cikkben ismertetett lehetőségek közül melyik felel meg a legjobban az üzleti céloknak. Ezen HA/DR-alternatívák IoT-megoldásba való beépítéséhez a következők közötti kompromisszumok gondos kiértékelése szükséges:
- A szükséges rugalmassági szint
- Megvalósítás és karbantartás összetettsége
- COGS-hatás
Régión belüli HA
Az IoT Hub szolgáltatás régión belüli HA-t biztosít a szolgáltatás szinte minden rétegében történő redundanciák implementálásával. Az IoT Hub szolgáltatás által közzétett SLA ezen redundanciák használatával érhető el. Az IoT-megoldás fejlesztői nem igényelnek további munkát ezeknek a HA-funkcióknak a kihasználásához. Bár az IoT Hub viszonylag magas üzemidő-garanciát nyújt, átmeneti hibák továbbra is várhatók, mint bármely elosztott számítástechnikai platform esetén. Ha még csak most kezdi el a megoldások felhőbe való migrálását egy helyszíni megoldásból, a fókusznak a "hibák közötti középidő" optimalizálásáról a "helyreállítás átlagos időpontjára" kell váltania. Más szóval az átmeneti hibákat normálnak kell tekinteni a felhővel való üzemeltetés során. Az átmeneti hibák kezeléséhez megfelelő újrapróbálkozási mintákat kell létrehozni a felhőalkalmazással interakcióba lépő összetevőkbe.
Rendelkezésreállási zónák
Az IoT Hub támogatja az Azure rendelkezésre állási zónákat. A rendelkezésre állási zóna egy magas rendelkezésre állású ajánlat, amely megvédi az alkalmazásokat és az adatokat az adatközpontok hibáitól. A rendelkezésre állási zónák támogatásával rendelkező régió három zónából áll, amelyek támogatják ezt a régiót. Minden zóna egy vagy több adatközpontot biztosít, mindegyik egyedi fizikai helyen, független energiaellátással, hűtéssel és hálózatkezeléssel. Ez a konfiguráció replikációt és redundanciát biztosít a régión belül.
A rendelkezésre állási zónák két előnyt biztosítanak: az adatok rugalmasságát és a zökkenőmentesebb üzembe helyezést.
Az adatrugalmasság abból ered, hogy a mögöttes tárolási szolgáltatásokat a rendelkezésre állási zónák által támogatott tárolóra cseréli. Az adatrugalmasság azért fontos az IoT-megoldások esetében, mert ezek a megoldások gyakran összetett, dinamikus és bizonytalan környezetekben működnek, ahol a hibák vagy a megszakítások jelentős következményekkel járhatnak. Függetlenül attól, hogy egy IoT-megoldás támogatja-e a gyártókörnyezetet, a kiskereskedelmi vagy éttermi környezetet, az egészségügyi rendszereket vagy az infrastruktúrát, az adatok rendelkezésre állása és minősége szükséges a hibák utáni helyreállításhoz, valamint a megbízható és konzisztens szolgáltatások biztosításához.
A zökkenőmentesebb üzembe helyezés abból ered, hogy a mögöttes adatközpont hardverét újabb, a rendelkezésre állási zónákat támogató hardverre cseréli. Ezek a hardverfejlesztések minimálisra csökkentik az eszköz leválasztásának és újracsatlakozásának, valamint az üzembe helyezéssel kapcsolatos egyéb leállásoknak az ügyfélre gyakorolt hatását. Az IoT Hub mérnöki csapata minden hónapban több frissítést helyez üzembe minden IoT Hubon, mind biztonsági okokból, mind a funkciók fejlesztése érdekében. A rendelkezésre állási zónák által támogatott hardverek 15 frissítési tartományra vannak felosztva, hogy minden frissítés zökkenőmentesebb legyen, és minimális hatással legyen a munkafolyamatokra. A frissítési tartományokról további információt a Rendelkezésre állási csoportok című témakörben talál.
Az IoT Hub rendelkezésre állási zónájának támogatása automatikusan engedélyezve van a következő Azure-régiókban létrehozott új IoT Hub-erőforrások esetében:
| Régió | Adatrugalmasság | Zökkenőmentesebb üzembe helyezés |
|---|---|---|
| Kelet-Ausztrália | 
|
|
| Dél-Brazília |
|
|
| Közép-Kanada |
|
|
| Közép-India | 
|
|
| Az USA középső régiója |
|
|
| USA keleti régiója |
|
|
| Közép-Franciaország |
|
|
| Középnyugat-Németország |
|
|
| Kelet-Japán |
|
|
| Dél-Korea középső régiója |
|
|
| Észak-Európa |
|
|
| Kelet-Norvégia |
|
|
| Közép-Katar |
|
|
| Usa déli régiója |
|
|
| Délkelet-Ázsia |
|
|
| Az Egyesült Királyság déli régiója |
|
|
| Nyugat-Európa |
|
|
| USA 2. nyugati régiója |
|
|
| USA 3. nyugati régiója |
|
|
Régióközi dr.
Előfordulhatnak olyan ritka helyzetek, amikor az adatközpontok áramkimaradás vagy egyéb fizikai eszközöket érintő hibák miatt hosszabb üzemkimaradást tapasztalnak. Ilyen események ritkán fordulnak elő, amelyek során a korábban ismertetett régión belüli HA-képesség nem mindig segít. Az IoT Hub több megoldást is kínál az ilyen kimaradások utáni helyreállításhoz.
Ilyen helyzetben az ügyfelek számára elérhető helyreállítási lehetőségek a Microsoft által kezdeményezett feladatátvétel és a manuális feladatátvétel. A kettő közötti alapvető különbség az, hogy a Microsoft kezdeményezi az előbbit, a felhasználó pedig az utóbbit. A manuális feladatátvétel a Microsoft által kezdeményezett feladatátvételi lehetőséghez képest alacsonyabb helyreállítási időkorlátot (RTO) biztosít. Az egyes lehetőségekkel kínált konkrét KPO-król a következő szakaszokban olvashat. Ha az IoT Hub elsődleges régióból történő feladatátvételének egyikét gyakorolja, a központ teljes mértékben működőképes lesz a megfelelő Azure geopáros régióban.
Mindkét feladatátvételi lehetőség a következő helyreállításipont-célkitűzéseket (RPO-kat) kínálja:
| Adattípus | Helyreállítási pont célkitűzései (RPO) |
|---|---|
| Identitásjegyzék | 0-5 perc adatvesztés |
| Ikereszköz-adatok | 0-5 perc adatvesztés |
| Felhőből eszközre irányuló üzenetek1 | 0-5 perc adatvesztés |
| 1. szülő- és eszközfeladat | 0-5 perc adatvesztés |
| Az eszközről a felhőbe irányuló üzenetek | Az összes olvasatlan üzenet elveszik |
| Felhőből eszközre irányuló visszajelzési üzenetek | Az összes olvasatlan üzenet elveszik |
1A felhőalapú üzenetek és a szülőfeladatok nem állíthatók helyre a manuális feladatátvétel részeként.
Miután az IoT Hub feladatátvételi művelete befejeződött, az eszközről és a háttéralkalmazásokból származó összes művelet várhatóan manuális beavatkozás nélkül is működni fog. Ez azt jelenti, hogy az eszközről a felhőbe irányuló üzeneteknek továbbra is működnie kell, és a teljes eszközregisztrációs adatbázis érintetlen. Az Event Griden keresztül kibocsátott események a korábban konfigurált előfizetés(ek)en keresztül használhatók fel mindaddig, amíg ezek az Event Grid-előfizetések továbbra is elérhetők maradnak. Az egyéni végpontokhoz nincs szükség további kezelésre.
Figyelemfelhívás
- A feladatátvétel után megváltozik az IoT Hub beépített eseményvégpontja event Hubs-kompatibilis neve és végpontja. Amikor telemetriai üzeneteket fogad a beépített végpontról az Event Hubs-ügyfél vagy az eseményfeldolgozó gazdagép használatával, a kapcsolat létrehozásához az IoT Hub kapcsolati sztring kell használnia. Ez biztosítja, hogy a háttéralkalmazások továbbra is működjenek anélkül, hogy manuális beavatkozásra van szükség a feladatátvétel után. Ha közvetlenül az alkalmazás Event Hub-kompatibilis nevét és végpontját használja, a műveletek folytatásához le kell kérnie az új Event Hub-kompatibilis végpontot a feladatátvétel után. További információkért lásd a manuális feladatátvételt és az Event Hubot.
- Ha az Azure Functions vagy az Azure Stream Analytics használatával csatlakoztatja a beépített események végpontját, előfordulhat, hogy újra kell indítania. Ennek az az oka, hogy a feladatátvétel során a korábbi eltolások már nem érvényesek.
- A tárolóba való útválasztáskor javasoljuk, hogy sorolja fel a blobokat vagy fájlokat, majd iterálja át őket, hogy az összes blobot vagy fájlt a partíció feltételezése nélkül olvashassa. A partíciótartomány a Microsoft által kezdeményezett feladatátvétel vagy manuális feladatátvétel során változhat. A Blobok listázása API-val számba vehet egy bloblistát, vagy listázhatja az ADLS Gen2 API-t a fájlok listájához. További információkért tekintse meg az Azure Storage-t útválasztási végpontként.
Microsoft által kezdeményezett feladatátvétel
A Microsoft által kezdeményezett feladatátvételt ritkán gyakorolja a Microsoft, hogy az érintett régióból a megfelelő földrajzilag párosított régióba az összes IoT Hubot feladatátvételre használja. Ez a folyamat egy alapértelmezett beállítás, és nem igényel beavatkozást a felhasználótól. A Microsoft fenntartja a jogot annak meghatározására, hogy mikor gyakorolja ezt a lehetőséget. Ez a mechanizmus nem tartalmaz felhasználói hozzájárulást a felhasználó központjának feladatátvétele előtt. A Microsoft által kezdeményezett feladatátvétel helyreállítási időkorlátja (RTO) 2–26 óra.
A nagy RTO azért van, mert a Microsoftnak el kell végeznie a feladatátvételi műveletet a régióban érintett összes ügyfél nevében. Ha egy kevésbé kritikus IoT-megoldást futtat, amely nagyjából egy napos állásidőt képes fenntartani, akkor nem baj, ha függőséget vállal ezzel a lehetőséggel, hogy megfeleljen az IoT-megoldás általános vészhelyreállítási céljainak. A futásidejű műveletek teljes üzemidejét a folyamat aktiválása után a "Helyreállítás ideje" című szakasz ismerteti.
Ezt a funkciót csak azok a felhasználók tilthatják le, amelyek IoT Hubokat helyeznek üzembe Brazília déli és délkelet-ázsiai (Szingapúr) régióiban. További információ: Vészhelyreállítás letiltása.
Feljegyzés
Az Azure IoT Hub nem tárolja vagy dolgozza fel az ügyféladatokat a szolgáltatáspéldány üzembe helyezéséhez használt földrajzi helyen kívül. További információ: Régiók közötti replikáció az Azure-ban.
Manuális feladatátvétel
Ha a Microsoft által kezdeményezett feladatátvételi RTO nem felel meg az üzleti üzemidő céljainak, fontolja meg a manuális feladatátvételt a feladatátvételi folyamat elindításához. Az ezt a beállítást használó RTO 10 perc és néhány óra között lehet. Az RTO jelenleg a feladatátvétel alatt álló IoT Hub-példányon regisztrált eszközök számának függvénye. A körülbelül 100 000 eszközt üzemeltető központ RTO-jának várhatóan 15 perc lesz a bálparkban. A futásidejű műveletek teljes üzemidejét a folyamat aktiválása után a "Helyreállítás ideje" című szakasz ismerteti.
A manuális feladatátvételi lehetőség mindig használható, függetlenül attól, hogy az elsődleges régió leáll-e vagy sem. Ezért ez a lehetőség a tervezett feladatátvételek végrehajtására is használható. A tervezett feladatátvételek egyik példája az időszakos feladatátvételi próbák végrehajtása. Az azonban óvatosságra int, hogy a tervezett feladatátvételi művelet állásidőt eredményez a központ számára a beállításhoz az RTO által meghatározott időszakra vonatkozóan, és a fenti RPO-tábla által meghatározott adatvesztést is eredményez. Érdemes lehet beállítani egy teszt IoT Hub-példányt, hogy rendszeresen gyakorolja a tervezett feladatátvételi lehetőséget, hogy megbízható legyen a teljes körű megoldások üzembe helyezési és futási lehetősége valós katasztrófa esetén.
A 2017. május 18. után létrehozott IoT Hubok esetében a manuális feladatátvétel további költségek nélkül elérhető
Részletes útmutatásért tekintse meg az oktatóanyagot: Manuális feladatátvétel végrehajtása IoT Hubon
Manuális feladatátvétel és Event Hubs
A manuális feladatátvétel után megváltozik az IoT Hub beépített eseményvégpontja event Hubs-kompatibilis neve és végpontja. Ennek az az oka, hogy az Event Hubs-ügyfél nem rendelkezik betekintéssel az IoT Hub-eseményekbe. Ugyanez vonatkozik más felhőalapú ügyfelekre is, például a Functionsre és az Azure Stream Analyticsre. A végpont és a név lekéréséhez használhatja az Azure Portalt vagy a .NET SDK-t.
A portál használata
Az Event Hub-kompatibilis végpont és az Event Hub-kompatibilis név lekéréséről a portál használatával kapcsolatos további információkért lásd : Csatlakozás a beépített végponthoz.
A .NET SDK használata
Az IoT Hub kapcsolati sztring az Event Hubs-kompatibilis végpont újrafoglalásához használjon egy, a következő helyen https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubstalálható mintát: . A példakód a kapcsolati sztring használja az új Event Hubs-végpont lekéréséhez és a kapcsolat újbóli létrehozásához. Telepítve kell lennie a Visual Studio-nak.
Tesztfúrások futtatása
Az éles környezetekben használt IoT Hubokon nem szabad tesztfúrásokat végezni.
Ne használjon manuális feladatátvételt az IoT Hub másik régióba való migrálásához
A manuális feladatátvétel nem használható mechanizmusként a központ végleges migrálásához az Azure geopáros régiói között. Feltéve, hogy az eszközök a központ elsődleges régiójához legközelebbi helyen találhatók, az IoT Hubon végzett műveletek késése akkor nő, ha a központ egy másodlagos régióba kerül át.
Feladat-visszavétel
A feladatátvételi művelet második aktiválásával vissza tud lépni a régi elsődleges régióba. Ha az eredeti feladatátvételi műveletet az eredeti elsődleges régió kiterjesztett leállása utáni helyreállításra hajtották végre, javasoljuk, hogy a központot a kimaradási helyzetből való helyreállítást követően térjen vissza az eredeti helyre.
Fontos
- A felhasználók naponta csak 2 sikeres feladatátvételi és 2 sikeres feladat-visszavételi műveletet hajthatnak végre.
- A feladatátvételi/feladat-visszavételi műveletek nem engedélyezettek. A műveletek között el kell telnie 1 órának.
Helyreállításhoz szükséges idő
Bár az IoT Hub-példány teljes tartományneve (és így a kapcsolati sztring) ugyanaz marad a feladatátvétel után is, a mögöttes IP-cím nem változik. Az IoT Hub-példányon végrehajtott futtatókörnyezeti műveletek teljes üzemideje a feladatátvételi folyamat után az alábbi függvény használatával fejezhető ki:
Helyreállítási idő = RTO [10 perc – 2 óra manuális feladatátvétel esetén | 2 –26 óra a Microsoft által kezdeményezett feladatátvétel esetén] + DNS-propagálási késleltetés + Az ügyfélalkalmazás által a gyorsítótárazott IoT Hub IP-címének frissítéséhez szükséges idő.
Fontos
Az IoT SDK-k nem gyorsítótárazják az IoT Hub IP-címét. Azt javasoljuk, hogy az SDK-kkal való felhasználói kód nem gyorsítótárazza az IoT Hub IP-címét.
Vészhelyreállítás letiltása
Az IoT Hub a Microsoft által kezdeményezett feladatátvételt és manuális feladatátvételt biztosítja úgy, hogy az adatokat az egyes IoT Hubok párosított régiójába replikálja. Egyes régiók esetében elkerülheti a régión kívüli adatreplikálást, ha letiltja a vészhelyreállítást egy IoT-központ létrehozásakor. A következő régiók támogatják ezt a funkciót:
- Dél-Brazília; párosított régió, USA déli középső régiója.
- Délkelet-Ázsia (Szingapúr); párosított régió, Kelet-Ázsia (Hongkong KKT).
Ha le szeretné tiltani a vészhelyreállítást a támogatott régiókban, győződjön meg arról, hogy a vészhelyreállítás engedélyezve van az IoT Hub létrehozásakor:
Akkor is letilthatja a vészhelyreállítást, ha ARM-sablonnal hoz létre egy IoT Hubot.
A feladatátvételi képesség nem lesz elérhető, ha letiltja az IoT Hub vészhelyreállítását.
IoT-központ létrehozásakor csak úgy tilthatja le a vészhelyreállítást, hogy elkerülje a párosított régión kívüli adatreplikálást Dél-Brazíliában vagy Délkelet-Ázsiában. Ha úgy szeretné konfigurálni a meglévő IoT Hubot, hogy letiltsa a vészhelyreállítást, létre kell hoznia egy új IoT Hubot, amely letiltotta a vészhelyreállítást, és manuálisan migrálja a meglévő IoT Hubot. Útmutatásért tekintse meg az IoT Hub migrálását ismertető témakört.
Régiók közötti HA elérése
Ha az üzleti üzemidő céljait nem teljesíti a Microsoft által kezdeményezett feladatátvételi vagy manuális feladatátvételi lehetőségek által biztosított RTO, érdemes megfontolnia egy eszközenkénti automatikus, régiók közötti feladatátvételi mechanizmus implementálását. Az üzembehelyezési topológiák teljes kezelése az IoT-megoldásokban kívül esik a jelen cikk hatókörén. A cikk a magas rendelkezésre állás és a vészhelyreállítás regionális feladatátvételi üzemi modelljét ismerteti.
Regionális feladatátvételi modellben a megoldás háttérrendszere elsősorban egy adatközpontban fut. A másodlagos IoT Hub és a háttérrendszer egy másik adatközpontban van üzembe helyezve. Ha az elsődleges régióban lévő IoT Hub kimaradásban szenved, vagy az eszköz és az elsődleges régió közötti hálózati kapcsolat megszakad, az eszközök másodlagos szolgáltatásvégpontot használnak. A megoldás rendelkezésre állását úgy javíthatja, hogy egy régiók közötti feladatátvételi modellt implementál ahelyett, hogy egyetlen régión belül maradna.
A regionális feladatátvételi modell IoT Hubbal való implementálásához magas szinten a következő lépéseket kell elvégeznie:
Másodlagos IoT Hub és eszköz-útválasztási logika: Ha az elsődleges régió szolgáltatása megszakad, az eszközöknek csatlakozniuk kell a másodlagos régióhoz. Tekintettel a legtöbb érintett szolgáltatás állapotérzékeny jellegére, a megoldásgazdák gyakran aktiválják a régiók közötti feladatátvételi folyamatot. Az új végpont eszközökkel való kommunikációjának legjobb módja az, ha rendszeresen ellenőrzik az aktuális aktív végpontot egy concierge szolgáltatással. A concierge szolgáltatás lehet egy webalkalmazás, amely DNS-átirányítási technikákkal replikált és elérhető marad (például az Azure Traffic Manager használatával).
Feljegyzés
Az IoT Hub szolgáltatás nem támogatott végponttípus az Azure Traffic Managerben. A javaslat az, hogy integrálja a javasolt concierge szolgáltatást az Azure Traffic Managerrel a végpontállapot-mintavételi API implementálásával.
Identitásregisztrációs adatbázis replikációja: A másodlagos IoT Hubnak tartalmaznia kell a megoldáshoz csatlakozni képes összes eszközidentitást. A megoldásnak meg kell őriznie az eszközidentitások georeplikált biztonsági mentéseit, és fel kell töltenie őket a másodlagos IoT Hubra, mielőtt átváltana az eszközök aktív végpontjára. Az IoT Hub eszközidentitás-exportálási funkciója ebben a környezetben hasznos. További információ: IoT Hub fejlesztői útmutató – identitásjegyzék.
Egyesítési logika: Amikor az elsődleges régió ismét elérhetővé válik, a másodlagos helyen létrehozott összes állapotot és adatot vissza kell telepíteni az elsődleges régióba. Ezek az állapotok és adatok többnyire az eszközidentitásokhoz és az alkalmazás metaadataihoz kapcsolódnak, amelyeket egyesíteni kell az elsődleges IoT Hubbal és az elsődleges régió bármely más alkalmazásspecifikus tárolójával.
A lépés egyszerűsítése érdekében idempotens műveleteket kell használnia. Az idempotens műveletek minimalizálják az események végleges konzisztens eloszlásából, valamint az események ismétlődéséből vagy rendelésen kívüli kézbesítéséből származó mellékhatásokat. Emellett az alkalmazáslogikát úgy kell megtervezni, hogy elviselje a lehetséges inkonzisztenciákat vagy kissé elavult állapotot. Ez a helyzet a helyreállítási pont célkitűzései (RPO) alapján a rendszer gyógyulásához szükséges többletidő miatt fordulhat elő.
Válassza ki a megfelelő HA/DR lehetőséget
Az alábbiakban összefoglaljuk a cikkben bemutatott HA/DR beállításokat, amelyek hivatkozási keretként használhatók a megoldáshoz megfelelő beállítás kiválasztásához.
| HA/DR beállítás | RTO | RPO | Manuális beavatkozást igényel? | A megvalósítás összetettsége | Költséghatás |
|---|---|---|---|---|---|
| Microsoft által kezdeményezett feladatátvétel | 2-26 óra | Tekintse meg a fenti RPO-táblát | Nem | Egyik sem | Egyik sem |
| Manuális feladatátvétel | 10 perc – 2 óra | Tekintse meg a fenti RPO-táblát | Igen | Nagyon alacsony. Ezt a műveletet csak a portálról kell aktiválnia. | Egyik sem |
| Régiók közötti HA | < 1 perc | Az egyéni HA-megoldás replikációs gyakoriságától függ | Nem | Magas | > 1x az 1 IoT Hub költsége |