Szerkesztés

Magas rendelkezésre állási és vészhelyreállítási forgatókönyvek IaaS-alkalmazásokhoz

Azure Site Recovery
Azure Virtual Machines
Azure Disk Storage

Ez a cikk egy döntési fát, valamint példákat mutat be a magas rendelkezésre állású (HA) és vészhelyreállítási (DR) lehetőségekre a többszolgáltatásos infrastruktúra -as-a-service (IaaS) alkalmazások Azure-ban történő üzembe helyezésekor.

Architektúra

Ez az ábra a magas rendelkezésre állású döntési fát mutatja be.

Munkafolyamat

A rendelkezésre állási csoportok (AS-ek) a virtuális gépek redundanciáit és rendelkezésre állását biztosítják az adatközpontokban azáltal, hogy virtuális gépeket osztanak szét több elkülönített hardvercsomópont között. A virtuális gépek egy részhalmaza a tervezett vagy nem tervezett állásidő alatt is fut, így a teljes alkalmazás elérhető és működőképes marad.

A rendelkezésre állási zónák (AZ-k) olyan egyedi fizikai helyek, amelyek egy Azure-régióban lévő adatközpontokra terjednek ki. Mindegyik AZ egy vagy több olyan adatközponthoz fér hozzá, amely független energiaellátással, hűtéssel és hálózatkezeléssel rendelkezik, és mindegyik AZ-kompatibilis Azure-régió legalább három különálló AZ-sel rendelkezik. Az AZ-k régión belüli fizikai elkülönítése megvédi az üzembe helyezett virtuális gépeket az adatközpont meghibásodásától.

A döntési folyamatábra azt az elvet tükrözi, hogy a HA-alkalmazásoknak lehetőség szerint AZ-eket kell használniuk. A zónák közötti, így adatközpontok közötti HA 99,99%-os SLA-t biztosít > az adatközpontok meghibásodásával szembeni rugalmasság miatt.

A különböző alkalmazásszintekhez tartozó AS-k és AZ-k nem garantáltan ugyanabban az adatközpontban találhatók. Ha az alkalmazás késése elsődleges szempont, a szolgáltatásokat egyetlen adatközpontban kell elhelyeznie a közelségi elhelyezési csoportok (PPG-k) és az AZ-k és az AS-ek használatával.

Összetevők

Alternatívák

  • Ha az alkalmazás natív módon tudja replikálni az adatokat, a regionális dr. helyett használhat gyakori /hideg készenléti kiszolgálókat, például csak dr. egy kiterjesztett fürtöt. Ez az alternatíva nem részletezi a példákat, de bármelyik megoldáshoz hozzáadható. Vegye figyelembe, hogy a régiók közötti replikáció aszinkron, és némi adatvesztés várható.

    Másik lehetőségként, ha saját adatreplikációs technológiával rendelkezik, használhatja egy másodlagos régión belüli zóna létrehozására a dr. A számítási feladatok régiójától függően az Azure Site Recovery használatával is replikálhat elemeket egy másik zónába, ellenőrizheti a regionális rendelkezésre állást, és erről a funkcióról az Azure-beli virtuális gépek zóna-vészhelyreállításának engedélyezése című témakörben olvashat bővebben.

  • A többrégiós HA lehetséges, de globális terheléselosztót igényel, például a Front Doort vagy a Traffic Managert. További információ: N szintű alkalmazás futtatása több Azure-régióban a magas rendelkezésre állás érdekében.

Forgatókönyv részletei

A több- vagy nszintű architektúrák gyakoriak a hagyományos helyszíni alkalmazásokban, így természetes választás a helyszíni alkalmazások felhőbe való migrálásához, vagy a helyszíni és a felhőbeli alkalmazások fejlesztéséhez. Az N szintű architektúrák általában logikai rétegekre és fizikai rétegekre osztott IaaS-alkalmazásokként vannak implementálva, felső webes vagy bemutatószinttel, középvállalati szinttel és adatszinttel.

Az N szintű IaaS-alkalmazásokban minden szint külön virtuális gépeken fut. A webes és az üzleti szintek állapot nélküliek, ami azt jelenti, hogy a réteg bármely virtuális gépe képes kezelni az adott rétegre vonatkozó kéréseket. Az adatszint egy replikált adatbázis, objektumtároló vagy fájltároló. Minden szinten több virtuális gép biztosít rugalmasságot, ha egy virtuális gép meghibásodik, és a terheléselosztók a virtuális gépek között terjesztik a kéréseket.

A rétegek vertikális felskálázásához további virtuális gépeket adhat hozzá a készletekhez, és virtuálisgép-méretezési csoportokkal automatikusan felskálázhatja az azonos virtuális gépeket. Mivel terheléselosztókat használ, az alkalmazások üzemidejét nem befolyásolva skálázhatja fel a szinteket.

Ha egy IaaS-alkalmazás szolgáltatásiszint-szerződése (SLA) 99%-os rendelkezésre állást igényel>, a virtuális gépeket rendelkezésre állási csoportokba, rendelkezésre állási zónákba és közelségi elhelyezési csoportokba helyezheti, hogy magas rendelkezésre állást konfiguráljon az alkalmazás számára. A választott HA- és DR-megoldások a szükséges SLA-tól, késési szempontoktól és regionális DR-követelményektől függnek.

Lehetséges használati esetek

  • N szintű alkalmazás migrálása a helyszínről a felhőbe.
  • N szintű alkalmazás üzembe helyezése a helyszínen és a felhőben is.
  • Magas rendelkezésre állás és vészhelyreállítás konfigurálása IaaS-alkalmazásokhoz.

Ez a megoldás bármely iparágban használható, beleértve a következő forgatókönyveket:

  • Közszférabeli alkalmazások
  • Banki (pénzügyi iparág)
  • Egészségügy

Megfontolások

  • Az AZ-k nem minden Azure-régióban érhetők el.

  • A megoldás létrehozása előtt döntse el, hogy melyik üzembe helyezési lehetőséget szeretné használni. Bár lehetséges, nem könnyű az egyik lehetőségről a másikra váltani az üzembe helyezés után. Törölnie kell a virtuális gépeket, és újra létre kell hoznia őket a mögöttes felügyelt lemezekről, ami egy folyamat.

  • Győződjön meg arról, hogy megfeleltetheti az alkalmazást a kiválasztott megoldásnak. Számos alkalmazásréteg rugalmassági mintája és kialakítása kívül esik a döntési fa hatókörén.

  • Három forgatókönyv vezethet az Azure-beli virtuális gépek újraindításához: nem tervezett hardverkarbantartás, váratlan állásidő és tervezett karbantartás. Ezekről az eseményekről és a hatásuk csökkentésére vonatkozó ajánlott HA-eljárásokról további információt a virtuális gépek újraindításának, karbantartásának és állásidejéről szóló cikkben talál.

Önálló virtuális gépek

Ha egy alkalmazás nem igényel > 99,9%-os rendelkezésre állást, nem kell konfigurálnia a HA-hoz, és egyetlen virtuális gépet is üzembe helyezhet. A virtuálisgép-méretezési csoportok használatával automatikusan felskálázhatja az azonos virtuális gépeket. Egyetlen virtuális gép üzembe helyezése zóna megadása nélkül, így az egész régióban el van osztva. Ezek az alkalmazások 99,9%-os SLA-val rendelkeznek, ha Azure Premium SSD-lemezeket használ.

Az önálló virtuális gépek az összes Azure-adatközpontba beépített alapértelmezett szolgáltatásjavítási funkciót használják. Kiszámítható hibák esetén ez a funkció általában élő áttelepítést használ, de kiszámíthatatlan események esetén előfordulhat, hogy a virtuális gépek újraindulnak vagy elérhetetlenné válik.

Magas szintű rendelkezésre állás

Ha az alkalmazáshoz 99,9%-os SLA > szükséges, tervezd meg az alkalmazást a HA-hoz. Ha lehetséges, használja az AZ-eket, mert az adatközpont hibatűrését biztosítják. Az AZ-k helyett AS-eket használhat, de az ASs használata 99,99%-ról 99,95%-ra csökkenti a rendelkezésre állást, mivel az AS-k nem tudják elviselni az adatközpontok meghibásodását.

Az AZ-k számos fürtözött alkalmazásforgatókönyvhez alkalmasak, beleértve az AlwaysOn SQL-fürtöket is, amelyek aktív-aktív, aktív-passzív vagy mindkét HA-szint kombinációját használják az egyes szinteken, gyors feladatátvétellel. A szinkron replikáció bármely Adatbázis-kezelő rendszer (DBMS) csomópont között lehetséges, mivel a többsávos hálózat alacsony késése miatt. A zónák közötti elosztott fürtkonfigurációt is futtathatja, amely nagyobb késéssel rendelkezik, és támogatja az aszinkron replikációt.

Ha virtuálisgép-alapú fürtválasztót (például fájlmegosztási tanúsítót) szeretne használni, helyezze a harmadik AZ-be, hogy a kvórum ne vesszon el, ha egy zóna meghibásodik. Másik lehetőségként használhat egy felhőalapú tanúsítót egy másik régióban.

Az AZ összes virtuális gépe egyetlen tartalék tartományban (FD) és frissítési tartományban (UD) található, ami azt jelenti, hogy közös áramforrással és hálózati kapcsolóval rendelkeznek, és egyszerre újraindíthatók. Ha különböző AZ-k között hoz létre virtuális gépeket, a virtuális gépek hatékonyan oszlanak el a különböző FD-k és -UD-k között, így nem minden meghibásodik, vagy egyszerre lesznek újraindítva. Ha redundáns zónán belüli virtuális gépeket és zónák közötti virtuális gépeket szeretne használni, a zónán belüli virtuális gépeket a PPG-kben kell elhelyeznie az AS-ben, hogy ne legyenek egyszerre újraindulva. Még a jelenleg nem redundáns egypéldányos virtuálisgép-számítási feladatok esetében is használhatja a PPG-k AS-eit a jövőbeli növekedés és rugalmasság érdekében.

A virtuálisgép-méretezési csoportok AZ-ekben való üzembe helyezéséhez fontolja meg a jelenleg nyilvános előzetes verzióban elérhető Orchestration módot, amely lehetővé teszi az FD-k és az AZ-k kombinálását.

A zónán belüli PPG-kkel rendelkező AZ-k az Egyik legalacsonyabb hálózati késést teszik lehetővé az Azure-ban, és a több adatközpont rugalmassága miatt legalább 99,99%-os SLA-t. Ha lehetséges, gyorsított hálózatkezelést használhat a virtuális gépeken.

Ez a megoldás olyan forgatókönyvet jelenthet, amelyben az egyik zónában lévő virtuális gépen futó szolgáltatásnak egy másik zónában lévő szolgáltatással kell együttműködnie. Előfordulhat például, hogy egy aktív-aktív webes réteg és egy aktív-passzív adatbázisszint van a zónák között. Egyes kérések zónákon haladnak át, ami késést eredményez. Bár a zónák közötti késés továbbra is nagyon alacsony, ha a lehető legkisebb késést kell biztosítania, tartsa meg az alkalmazásszintek közötti hálózati kommunikációt egy zónán belül.

Késési szempontok

A hálózati késés többek között az üzembe helyezett virtuális gépek fizikai távolságától függ. Ha egy alkalmazás nagyon alacsony késést igényel a rétegek között, üzembe helyezheti egyetlen adatközpontban, az egyes szintekhez tartozó AS-ekkel rendelkező PPG használatával. Ha lehetséges, használjon gyorsított hálózatkezelést a virtuális gépeken. Ez a forgatókönyv az Egyik legalacsonyabb hálózati késést teszi lehetővé az Azure-ban, és egy 99,95%-os SLA-t.

Az alábbi eszközökkel jobb betekintést nyerhet a különböző forgatókönyvek késési feltételeibe:

  • A virtuális gépek közötti késés teszteléséhez lásd : Virtuálisgép-hálózat késésének tesztelése.
  • A zónák közötti késés teszteléséhez használja az AvZone-Latency-Test elemet. Ez a teszt segít meghatározni, hogy mely logikai zónák rendelkeznek a legalacsonyabb késéssel az előfizetéshez.
  • Az Azure-régiók közötti késés teszteléséhez használja http://www.azurespeed.com/a . Ez a rendszeresen frissített eszköz akkor lehet hasznos, ha a régiók közötti aszinkron replikációt fontolgatja.

Vészhelyreállítás

A DR szempontjai közé tartozik a rendelkezésre állás, az alkalmazás kifogástalan állapotban való működésének képessége, valamint az adatok tartóssága, az adatok megőrzése katasztrófa esetén.

A HA feladatátvételnek gyorsnak kell lennie, adatvesztés nélkül, és nagyon korlátozott hatással kell lennie a szolgáltatásra. Ezzel szemben a hagyományos DR-feladatátvétel hosszabb helyreállítási időkorláttal (RTO) és helyreállításipont-célkitűzéssel (RPO) rendelkezhet, és aszinkron módon lehetséges adatvesztéssel jár.

A rendelkezésre állási zónákat a magas rendelkezésre álláshoz és a vészhelyreállításhoz is kihasználhatja, ha egy másik rendelkezésre állási zónát használ a vészhelyreállítási megoldáshoz. A rendelkezésre állási zónák elég közel vannak ahhoz, hogy alacsony késésű kapcsolatok legyenek más rendelkezésre állási zónákkal (2 m-nél kisebb utazási késés). Ezek azonban elég messze vannak egymástól, hogy csökkenjen annak a valószínűsége, hogy a helyi kimaradások vagy az időjárás több rendelkezésre állási zónát is érinthet. Kritikus fontosságú számítási feladatok esetén érdemes megfontolni egy olyan megoldást, amely több régiót használ több rendelkezésre állási zónán kívül.

Az Azure Site Recovery lehetővé teszi, hogy virtuális gépeket replikáljon egy másik Azure-régióba a regionális vészhelyreállítás és az üzletmenet folytonossága érdekében. Az Azure Site Recovery használatával helyreállíthatja az alkalmazásokat forrásrégiók kimaradása esetén, vagy rendszeres vészhelyreállítási próbákat végezhet, hogy megfeleljen a megfelelőségi követelményeknek.

Ha az alkalmazás támogatja az Azure Site Recoveryt, regionális dr. megoldást biztosíthat a fokozott védelem érdekében, ha az alkalmazás kritikussága megköveteli. A zónák közötti, adatközpontok közötti HA azonban önmagában elegendő védelmet jelenthet, mivel ha egy alkalmazás teljes mértékben ellenáll az adatközpontok meghibásodásának, akkor nem szabad leállást vagy adatvesztést okoznia.

Költségoptimalizálás

Az AZ-ben üzembe helyezett virtuális gépeknek nincs további költsége. Előfordulhat, hogy további, az AZ virtuális gépek közötti adatátviteli díjak is felmerülhetnek. További információ: Sávszélesség díjszabása oldal.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

Következő lépések