Az Azure Virtual Machines alaparchitektúrája

Ez a cikk az Azure-beli virtuális gépeken üzembe helyezett számítási feladatok alapvető referenciaarchitektúráit ismerteti.

Az architektúra által feltételezett példa számítási feladat egy internetes többrétegű webalkalmazás, amely külön virtuális gépeken (virtuális gépeken) van üzembe helyezve. A virtuális gépek az Azure-beli virtuálisgép-méretezési csoportok üzembe helyezésének részeként vannak kiépítve. Ez az architektúra az alábbi forgatókönyvekhez használható:

• Privát alkalmazások. Ezek az alkalmazások magukban foglalják a belső üzletági alkalmazásokat vagy a kereskedelmi használatra nem használható megoldásokat.
• Nyilvános alkalmazások. Ezek az alkalmazások internetes alkalmazások. Ez az architektúra nem a nagy teljesítményű számítástechnika, a kritikus fontosságú számítási feladatok, a késés által nagy mértékben érintett alkalmazások vagy más speciális használati esetek esetében használható.

Az architektúra elsődleges fókusza nem az alkalmazás. Ez a cikk ehelyett útmutatást nyújt azoknak az infrastruktúra-összetevőknek a konfigurálásához és üzembe helyezéséhez, amelyekkel az alkalmazás együttműködik. Ezek az összetevők közé tartoznak a számítási, tárolási, hálózati és monitorozási összetevők.

Ez az architektúra kiindulópontként szolgál az infrastruktúra szolgáltatásként (IaaS) üzemeltetett számítási feladataihoz. Az adatszint szándékosan ki van zárva ebből az útmutatóból, hogy a számítási infrastruktúrára összpontosítson.

Cikkelrendezés

Architektúra	Tervezési döntés	Jól kiépítésű keretrendszer megközelítése
▪ Architektúradiagram ▪ Számítási feladatok erőforrásai ▪ Támogató erőforrások ▪ Felhasználói folyamatok	▪ Virtuálisgép-tervezési lehetőségek ▪ Lemezek ▪ Hálózati ▪ Ellenőrző ▪ Frissítéskezelés	▪ Megbízhatóság ▪ Biztonság ▪ Költségoptimalizálás

Architektúra

Töltse le az architektúra Visio-fájlját.

Ezekről az erőforrásokról további információt a Kapcsolódó erőforrások között található Azure-termékdokumentációban talál.

Összetevők

Ez az architektúra számos Azure-szolgáltatást tartalmaz a számítási feladatok erőforrásaihoz és a számítási feladatokat támogató erőforrásokhoz. Az egyes szolgáltatásokról és szerepköreikről a következő szakaszokban olvashat.

Számítási feladatok erőforrásai

• Az Azure Virtual Machines az alkalmazás számítási erőforrásaként szolgál, és a rendelkezésre állási zónák között van elosztva. Szemléltető célokra a Windows és a Linux rendszerű virtuális gépek kombinációját is használja a rendszer.

  Az Azure Virtual Machine Scale Sets rugalmas vezénylési módban a virtuális gépek kiépítésére és kezelésére szolgál.

  A mintaalkalmazás két szinten jeleníthető meg, amelyek mindegyike saját számítást igényel.

  • Az előtér futtatja a webkiszolgálót, és felhasználói kéréseket fogad.
  • A háttérrendszer egy másik webkiszolgálót futtat webes API-ként, amely egyetlen végpontot tesz elérhetővé, ahol az üzleti logika fut.

  Az előtérbeli virtuális gépekhez adatlemezek (Premium_LRS) vannak csatlakoztatva, amelyek felhasználhatók állapot nélküli alkalmazások üzembe helyezésére. A háttérbeli virtuális gépek a művelet részeként megőrzik az adatokat a helyi lemezek Premium_ZRS. Ez az elrendezés bővíthető egy adatbázisszinttel az állapot előtér- és háttérbeli számításból való tárolásához. Ez a szint az architektúra hatókörén kívül esik.

• Az Azure Virtual Network magánhálózatot biztosít az összes számítási feladat erőforrásához. A hálózat alhálózatokra van szegmentelve, amelyek elkülönítési határokként szolgálnak.

• Azure-alkalmazás átjáró az egyetlen bejövő pont, amely a kérelmeket az előtérbeli kiszolgálókra irányítja. A kiválasztott termékváltozat beépített Azure Web Application Firewallot (WAF) tartalmaz a további biztonság érdekében.

• A belső Azure Load Balancer az előtérbeli szintről a háttérkiszolgálókra irányítja a forgalmat.

• Az Azure Load Balancer Standard termékváltozata kimenő internetkapcsolatot biztosít a virtuális gépekhez három nyilvános IP-cím használatával.

• Az Azure Key Vault tárolja a végpontok közötti átviteli réteg biztonsági (TLS)-kommunikációhoz használt tanúsítványokat. Alkalmazáskulcsokhoz is használható.

Erőforrásokat támogató számítási feladatok

• Az Azure Bastion biztonságos protokollokon keresztül biztosít üzemeltetési hozzáférést a virtuális gépekhez.

• Az Application Insights naplókat és metrikákat gyűjt az alkalmazásból. Mivel az alkalmazás nem az architektúra középpontjában van, a rendszer nem mutatja be a naplógyűjtést az implementációban.

• A Log Analytics a monitorozási adatgyűjtő, amely naplókat és metrikákat gyűjt az Azure-erőforrásokból és az Application Insightsból. A munkaterület részeként kiépült egy tárfiók.

Felhasználói folyamatok

A számítási feladatok erőforrásait kétféle felhasználó használja: a számítási feladat felhasználója és az operátor. A felhasználók folyamatait az előző architektúradiagram mutatja.

Számítási feladat felhasználója

1. A felhasználó az Application Gateway nyilvános IP-címével fér hozzá a webhelyhez.

2. Az Application Gateway HTTPS-forgalmat fogad, adatokat fejt vissza egy külső tanúsítvány használatával a WAF-vizsgálathoz, és újra titkosítja azokat a belső helyettesítő tanúsítvány használatával az előtérben történő átvitelhez.

3. Az Application Gateway kiegyensúlyozza az előtérbeli virtuális gépek közötti forgalmat, és továbbítja a kérést egy előtérbeli virtuális gépnek.

4. A kiválasztott előtérbeli virtuális gép a terheléselosztó privát IP-címével kommunikál egy háttérbeli virtuális géppel, nem pedig az egyes virtuális gépek IP-címével. Ez a kommunikáció a belső helyettesítő tanúsítvány használatával is titkosítva van.

5. A háttérbeli virtuális gép a belső tanúsítvány használatával fejti vissza a kérést. Miután a háttér feldolgozta a kérést, visszaadja az eredményt az előtérnek, amely visszaadja az eredményt az application gatewaynek, és végül visszaadja az eredményt a felhasználónak.

Operátor

Az architektúra virtuális gépeihez szükség lehet az operátorok közvetlen hozzáférésére, de azt javasoljuk, hogy a távelérés automatizálással legyen minimalizálva, és a hozzáférés monitorozása is megtörténik. A hozzáférés hibajavítási helyzetekhez, hibaelhárításhoz vagy egy automatizált üzembe helyezési folyamat egy részéhez lehet. Ez az architektúra nem rendelkezik nyilvános IP-címeket a vezérlősík-hozzáféréshez. Az Azure Bastion kiszolgáló nélküli átjáróként működik, amely lehetővé teszi a virtuális gépek SSH-on vagy RDP-en keresztüli elérését. Ez a beállítás biztosítja a biztonságos és hatékony hozzáférés-kezelést.

1. Az operátor bejelentkezik az Azure Portalra vagy az Azure CLI-be.
2. Az operátor hozzáfér az Azure Bastion szolgáltatáshoz, és távolról csatlakozik a kívánt virtuális géphez.

Virtuálisgép-tervezési lehetőségek

Az SKU-k kiválasztásakor fontos, hogy legyen egy alapkonfigurációs teljesítményre vonatkozó elvárás. A döntéshozatali folyamatot számos jellemző befolyásolja, többek között a következők:

• Processzor-, memória- és lemezbemeneti/kimeneti műveletek másodpercenként (IOPS).
• Processzorarchitektúra.
• Operációs rendszer (OS) rendszerképének mérete.

Ha például olyan helyszíni környezetből migrál egy számítási feladatot, amely Intel processzorgépeket igényel, válassza az Intel processzorokat támogató virtuálisgép-termékváltozatokat.

A támogatott virtuálisgép-termékváltozatokról további információt az Azure-beli virtuális gépek méretei című témakörben talál.

Rendszerindítás

A virtuális gépeket gyakran aktiválni kell, ami egy folyamat, amelyben a virtuális gépek előkészítése és finomhangolása történik az alkalmazás futtatásához. Az általános rendszerindítási feladatok közé tartozik a tanúsítványok telepítése, a távelérés konfigurálása, a csomagok telepítése, az operációs rendszer konfigurációjának finomhangolása és keményítése, valamint az adatlemezek formázása és csatlakoztatása. Fontos, hogy a rendszerindítási folyamatot a lehető legnagyobb mértékben automatizálja, hogy az alkalmazás késedelem nélkül vagy manuális beavatkozás nélkül elinduljon a virtuális gépen. Íme az automatizálásra vonatkozó javaslatok:

• Virtuálisgép-bővítmények. Ezek a bővítmények Olyan Azure Resource Manager-objektumok, amelyeket az Infrastruktúra kódként (IaC) üzemelő példánya kezel. Így a rendszer minden hibát sikertelen üzembe helyezésként jelent, amelyen műveletet hajthat végre. Ha nincs bővítmény a rendszerindítási igényekhez, hozzon létre egyéni szkripteket. Javasoljuk, hogy futtassa a szkripteket az Azure Egyéni szkriptbővítményen keresztül.

  Íme néhány további bővítmény, amelyek a virtuális gépek funkcióinak automatikus telepítéséhez vagy konfigurálásához használhatók.

  • Az Azure Monitor Agent (AMA) összegyűjti a figyelési adatokat a vendég operációs rendszertől, és átadja azokat az Azure Monitornak.
  • Az Azure Custom Script Extension (Windows, Linux) 2. verziója letölti és futtatja a szkripteket azure-beli virtuális gépeken. Ez a bővítmény az üzembe helyezés utáni konfiguráció, a szoftvertelepítés vagy bármely más konfigurációs vagy felügyeleti feladat automatizálásához hasznos.
  • Az Azure Key Vault virtuálisgép-bővítmény (Windows, Linux) automatikusan frissíti a Key Vaultban tárolt tanúsítványokat a módosítások észlelésével és a megfelelő tanúsítványok telepítésével.
  • A virtuálisgép-méretezési csoportokkal rendelkező Application Health-bővítmény fontos, ha az Azure-beli virtuálisgép-méretezési csoportok automatikusan gördülő frissítéseket hajtanak végre. Az Azure az egyes példányok állapotfigyelésére támaszkodik a frissítésekhez. A bővítmény használatával monitorozhatja a méretezési csoportban lévő egyes példányok alkalmazásállapotát, és automatikus példányjavításokkal elvégezheti a példányjavításokat.
  • A Microsoft Entra ID és az OpenSSH (Windows, Linux) integrálható a Microsoft Entra-hitelesítéssel. Mostantól a Microsoft Entra ID-t használhatja alapszintű hitelesítési platformként, valamint egy hitelesítésszolgáltatót, a Microsoft Entra ID és az OpenSSH tanúsítványalapú hitelesítés használatával pedig SSH-t hozhat létre Linux rendszerű virtuális gépekre. Ez a funkció lehetővé teszi, hogy azure-beli szerepköralapú hozzáférés-vezérlési (RBAC) és feltételes hozzáférési szabályzatokkal kezelje a virtuális gépekhez való hozzáférést.

• Ügynökalapú konfiguráció. A Linux rendszerű virtuális gépek a cloud-init segítségével elérhető, egyszerű natív állapotkonfigurációt használhatnak különböző Azure-beli virtuálisgép-rendszerképeken. A konfiguráció meg van adva és verziószámozott az IaC-összetevőkkel. Másik módszer a saját konfigurációkezelési megoldás létrehozása. A legtöbb megoldás a rendszerindítás deklaratív első megközelítését követi, de támogatja az egyéni szkripteket a rugalmasság érdekében. A népszerű lehetőségek közé tartozik a Windows kívánt állapotkonfigurációja, a Linuxhoz készült Desired State Configuration, az Ansible, a Chef, a Puppet és mások. Ezek a konfigurációs megoldások mindegyike párosítható virtuálisgép-bővítményekkel a lehető legjobb élmény érdekében.

A referencia-implementációban az összes rendszerindítás virtuálisgép-bővítményeken és egyéni szkripteken keresztül történik, beleértve az adatlemezek formázásának és csatlakoztatásának automatizálására szolgáló egyéni szkriptet is.

Tekintse meg a jól megtervezett keretrendszert: RE:02 – Javaslatok az automatizálás tervezéséhez.

Virtuálisgép-kapcsolat

A virtuális gép és egy adott virtuális hálózat más eszközei közötti privát kommunikáció engedélyezéséhez a virtuális gép hálózati adaptere (NIC) a virtuális hálózat egyik alhálózatához csatlakozik. Ha több hálózati adaptert igényel a virtuális géphez, tudja, hogy az egyes virtuális gépek méretéhez maximális számú hálózati adapter van meghatározva.

Ha a számítási feladatnak alacsony késésű kommunikációra van szüksége a virtuális hálózatban lévő virtuális gépek között, fontolja meg a gyorsított hálózatkezelést, amelyet az Azure-beli virtuális gépek hálózati adapterei támogatnak. További információ: A gyorsított hálózatkezelés előnyei.

Virtuálisgép-méretezési csoportok rugalmas vezényléssel

A virtuális gépek rugalmas vezénylésű virtuálisgép-méretezési csoportok részeként vannak kiépítve. A virtuálisgép-méretezési csoportok olyan virtuális gépek logikai csoportosításai, amelyek az üzleti igények kielégítésére szolgálnak. A csoportosításban lévő virtuális gépek típusai lehetnek azonosak vagy eltérőek. Lehetővé teszik a gépek, hálózati adapterek és lemezek életciklusának kezelését szabványos Azure-beli virtuálisgép-API-k és parancsok használatával.

A rugalmas vezénylési mód megkönnyíti a nagy léptékű műveleteket, és segít a részletes skálázási döntések meghozatalában.

A tartalék tartomány konfigurációjára van szükség a fizikai hardverhibák, hálózati kimaradások vagy áramkimaradások hatásának korlátozásához. Méretezési csoportok esetén az Azure egyenletesen elosztja a példányokat a tartalék tartományok között, hogy egyetlen hardver- vagy infrastruktúraproblémával szemben ellenállóbbak le tudjanak-e.

Javasoljuk, hogy a maximális példányterjesztés érdekében kiterjessze a tartalék tartományfoglalást az Azure-ba, ezáltal növelve a rugalmasságot és a rendelkezésre állást.

Lemezek

Az operációs rendszer és az alkalmazás összetevőinek futtatásához a rendszer tárolólemezeket csatol a virtuális géphez. Fontolja meg a rövid élettartamú lemezek használatát az operációs rendszerhez és a felügyelt lemezeket az adattároláshoz.

Az Azure számos lehetőséget kínál a teljesítmény, a sokoldalúság és a költség szempontjából. Kezdje a Prémium SSD-vel a legtöbb éles számítási feladathoz. A választás a virtuálisgép-termékváltozattól függ. A Prémium SSD-t támogató termékváltozatok az erőforrás nevében tartalmaznak egy s-t, például Dsv4, de dv4 nem.

További információ a lemezbeállításokról olyan metrikákkal, mint a kapacitás, az IOPS és az átviteli sebesség, lásd : Lemeztípusok összehasonlítása.

A lemez kiválasztásakor vegye figyelembe a lemez jellemzőit és a teljesítményre vonatkozó elvárásokat.

• A virtuálisgép-termékváltozat korlátozásai. A lemezek a csatlakoztatott virtuális gépen belül működnek, amelyek IOPS- és átviteli sebességkorlátokkal rendelkeznek. Győződjön meg arról, hogy a lemez nem korlátozza a virtuális gép korlátait, és fordítva. Válassza ki az alkalmazás-összetevőt optimálisan futtató lemezméretet, teljesítményt és virtuálisgép-képességeket (mag, processzor, memória). Kerülje a túlterjedést, mert ez hatással van a költségekre.

• Konfigurációváltozások. A virtuális gépek futtatása közben módosíthatja a lemez teljesítményét és kapacitáskonfigurációit. Számos módosítás azonban igényelheti a lemeztartalom újraépítését és újraépítését, ami hatással van a számítási feladatok rendelkezésre állására. Ezért gondosan tervezze meg a lemez- és virtuálisgép-termékváltozat kiválasztását a rendelkezésre állási hatások és az újramunkálás minimalizálása érdekében.

• Rövid élettartamú operációsrendszer-lemezek. Operációsrendszer-lemezek kiosztása rövid élettartamú lemezekként. Felügyelt lemezeket csak akkor használjon, ha az operációsrendszer-fájlokat meg kell őrizni. Ne használjon rövid élettartamú lemezeket az alkalmazás összetevőinek és állapotának tárolásához.

  A rövid élettartamú operációsrendszer-lemezek kapacitása a kiválasztott virtuálisgép-termékváltozattól függ. Győződjön meg arról, hogy az operációs rendszer lemezmérete kisebb, mint a termékváltozat elérhető gyorsítótára vagy ideiglenes lemeze. A fennmaradó helyet ideiglenes tároláshoz használhatja.

• Lemezteljesítmény. A lemezterület csúcsterhelés alapján történő előzetes kiépítése gyakori, de a kihasználatlan erőforrásokhoz vezethet, mivel a legtöbb számítási feladat nem tartja fenn a csúcsterhelést.

  Figyelje a számítási feladatok használati mintáit, figyelje meg a kiugró vagy tartósan magas olvasási műveletet, és vegye figyelembe ezeket a mintákat a virtuális gép és a felügyelt lemez termékváltozatának kiválasztásában.

  Igény szerint módosíthatja a teljesítményt a teljesítményszintek módosításával vagy egyes felügyelt lemez-termékváltozatokban kínált kipukkasztási funkciók használatával.

  Bár a túlterjedés csökkenti a kipukkadás szükségességét, az kihasználatlan kapacitáshoz vezethet, amelyért fizetnie kell. Ideális esetben kombinálja mindkét funkciót az optimális eredmény érdekében.

• A számítási feladat gyorsítótárazásának finomhangolása. Konfigurálja az összes lemez gyorsítótár-beállításait az alkalmazásösszetevők használata alapján.

  A főként olvasási műveleteket végző összetevők nem igényelnek nagy lemezes tranzakciós konzisztenciát. Ezek az összetevők használhatják az írásvédett gyorsítótárazást. A nagy lemezes tranzakciós konzisztenciát igénylő írási nehéz összetevők gyorsítótárazása gyakran le van tiltva.

  Az olvasási-írási gyorsítótárazás adatvesztést okozhat, ha a virtuális gép összeomlik, és a legtöbb adatlemezes forgatókönyv esetében nem ajánlott.

Ebben az architektúrában:

• Az összes virtuális gép operációsrendszer-lemezei rövid élettartamúak, és a gyorsítótárlemezen találhatók.

  Az előtérben (Linux) és a háttérrendszerben (Windows Server) található számítási feladatok alkalmazása toleráns az egyes virtuális gépek hibáival szemben, és mindkettő kis méretű (körülbelül 30 GB) lemezképet használ. Az ilyen attribútumok lehetővé teszik számukra a virtuális gép helyi tárolója (gyorsítótárpartíció) részeként létrehozott rövid élettartamú operációsrendszer-lemezek használatát a távoli Azure Storage-erőforrásokba mentett állandó operációsrendszer-lemezek helyett. Ez a helyzet nem jár az operációsrendszer-lemezek tárolási költségével, és a teljesítmény javítása azáltal, hogy alacsonyabb késéseket biztosít, és csökkenti a virtuális gépek üzembe helyezésének idejét.

• Minden virtuális gép saját Prémium SSD P1 felügyelt lemezzel rendelkezik, amely a számítási feladathoz megfelelő alapkiosztott átviteli sebességet biztosít.

Hálózati elrendezés

Ez az architektúra egyetlen virtuális hálózaton helyezi üzembe a számítási feladatot. A hálózati vezérlők az architektúra jelentős részét képezik, és a Biztonság szakasz ismerteti.

Ez az elrendezés integrálható egy vállalati topológiával. Ez a példa a virtuális gépek alapkonfigurációs architektúrájában látható egy Azure-beli célzónában.

Virtuális hálózat

Az egyik kezdeti hálózati elrendezési döntés a hálózati címtartományhoz kapcsolódik. Tartsa szem előtt a kapacitástervezési fázis várható hálózati növekedését. A hálózatnak elég nagynak kell lennie a növekedés fenntartásához, ami további hálózatkezelési szerkezeteket igényelhet. A virtuális hálózatnak például rendelkeznie kell a kapacitással a skálázási műveletből eredő többi virtuális gép elhelyezéséhez.

Ezzel szemben a címtér méretének megfelelő mérete. A túlzottan nagy virtuális hálózat kihasználatlansághoz vezethet. Fontos megjegyezni, hogy a virtuális hálózat létrehozása után a címtartomány nem módosítható.

Ebben az architektúrában a címtér a /21 értékre van állítva, amely az előre jelzett növekedésen alapuló döntés.

Részkiosztási szempontok

A virtuális hálózaton belül az alhálózatok a funkciók és a biztonsági követelmények alapján vannak elosztva, az alábbiak szerint:

• Az application gateway üzemeltetésére szolgáló alhálózat, amely fordított proxyként szolgál. Az Application Gatewayhez dedikált alhálózat szükséges.
• A belső terheléselosztó üzemeltetésére szolgáló alhálózat a háttérbeli virtuális gépek felé irányuló forgalom elosztásához.
• Alhálózatok a számítási feladatok virtuális gépeinek üzemeltetéséhez, egy az előtérhez és egy a háttérrendszerhez. Ezek az alhálózatok az alkalmazás szintjei szerint jönnek létre.
• Az Azure Bastion-gazdagép alhálózata a számítási feladatok virtuális gépeihez való operatív hozzáférés megkönnyítése érdekében. Az Azure Bastion-gazdagépnek terv szerint dedikált alhálózatra van szüksége.
• Az Azure Private Linken keresztül más Azure-erőforrások eléréséhez létrehozott privát végpontok üzemeltetésére szolgáló alhálózat. Bár a dedikált alhálózatok nem kötelezőek ezekhez a végpontokhoz, javasoljuk őket.

A virtuális hálózatokhoz hasonlóan az alhálózatoknak megfelelő méretűnek kell lenniük. Előfordulhat például, hogy a rugalmas vezénylés által támogatott virtuális gépek maximális korlátját szeretné alkalmazni az alkalmazás skálázási igényeinek megfelelően. A számítási feladatok alhálózatainak képesnek kell lenniük a korlát elhelyezésére.

Egy másik megfontolandó használati eset a virtuálisgép-operációs rendszer frissítése, amely ideiglenes IP-címeket igényelhet. A jobb méretezés lehetővé teszi a kívánt szegmentálási szintet, ha gondoskodik arról, hogy a hasonló erőforrások csoportosítva legyenek, így a hálózati biztonsági csoportokon (NSG-ken) keresztül értelmezhető biztonsági szabályok alkalmazhatók az alhálózatok határaira. További információ: Biztonság: Szegmentálás.

Bejövő forgalom

A bejövő folyamatokhoz két nyilvános IP-cím használatos. Az egyik cím az Application Gatewayhez tartozik, amely fordított proxyként szolgál. A felhasználók ezzel a nyilvános IP-címmel csatlakoznak. A fordított proxy terhelése kiegyensúlyozza a virtuális gépek privát IP-címére bejövő forgalmat. A másik cím az Azure Bastionon keresztüli üzemeltetési hozzáférés.

Töltse le az architektúra Visio-fájlját.

Kimenő forgalom

Ez az architektúra standard termékváltozatú Load Balancert használ a virtuálisgép-példányokból definiált kimenő szabályokkal. A Load Balancer azért lett kiválasztva, mert zónaredundáns.

Töltse le az architektúra Visio-fájlját.

Ezzel a konfigurációval a terheléselosztó nyilvános IP-címével kimenő internetkapcsolatot biztosíthat a virtuális gépek számára. A kimenő szabályok lehetővé teszik a forráshálózati címfordítási (SNAT-) portok explicit meghatározását. A szabályok lehetővé teszik, hogy manuális portfoglalással skálázza és hangolja ezt a képességet. Az SNAT-port manuális kiosztása a háttérkészlet mérete és száma frontendIPConfigurations alapján segíthet elkerülni az SNAT-kimerülést.

Javasoljuk, hogy a háttérpéldányok maximális száma alapján foglalja le a portokat. Ha több példányt ad hozzá, mint amennyit a többi SNAT-port engedélyez, a virtuálisgép-méretezési csoportok skálázási műveletei blokkolhatók, vagy az új virtuális gépek nem kapnak elegendő SNAT-portot.

Példányonként számítsa ki a portokat a következő módon: Number of front-end IPs * 64K / Maximum number of back-end instances.

Más lehetőségek is használhatók, például az alhálózathoz csatolt Azure NAT Gateway-erőforrás üzembe helyezése. Egy másik lehetőség az Azure Firewall vagy egy másik hálózati virtuális berendezés használata egyéni felhasználó által megadott útvonallal (UDR) a következő ugrásként a tűzfalon. Ez a lehetőség az Azure-beli kezdőzónában lévő virtuális gépek alapkonfigurációs architektúrájában jelenik meg.

DNS feloldása

Az Azure DNS az összes megoldási használati eset alapvető szolgáltatása, például a számítási feladattal rendelkező virtuális gépekhez társított teljes tartománynevek (FQDN) feloldása. Ebben az architektúrában a virtuális gépek a virtuális hálózat konfigurációjában beállított DNS-értékeket használják, azaz az Azure DNS-t.

Az Azure-beli privát DNS-zónák a nevesített Private Link-erőforrások eléréséhez használt privát végpontokra irányuló kérések feloldására szolgálnak.

Figyelés

Ez az architektúra egy monitorozási vermet használ, amely elválasztva van a számítási feladat segédprogramjától. A fókusz elsősorban az adatforrásokra és a gyűjtési szempontokra összpontosít.

A metrikák és naplók különböző adatforrásokban jönnek létre, és megfigyelhetőségi megállapításokat biztosítanak különböző magasságokban:

• A mögöttes infrastruktúra és összetevők, például a virtuális gépek, a virtuális hálózatok és a tárolási szolgáltatások tekinthetők meg. Az Azure-platformnaplók információkat nyújtanak az Azure-platformon belüli műveletekről és tevékenységekről.

• Az alkalmazásszint betekintést nyújt a rendszeren futó alkalmazások teljesítményébe és viselkedésébe.

A Log Analytics-munkaterület az ajánlott monitorozási adatgyűjtő, amellyel naplókat és metrikákat gyűjthet az Azure-erőforrásokból és az Application Insightsból.

Ez a kép az alapkonfiguráció monitorozási vermét jeleníti meg az infrastruktúra és az alkalmazás adatainak gyűjtésére szolgáló összetevőkkel, az adatgyűjtőkkel és az elemzéshez és vizualizációhoz használható különböző használati eszközökkel. Az implementáció üzembe helyez néhány összetevőt, például az Application Insightst, a virtuális gépek rendszerindítási diagnosztikát és a Log Analyticset. Más összetevők is láthatók a bővíthetőségi lehetőségek, például az irányítópultok és a riasztások bemutatásához.

Töltse le az architektúra Visio-fájlját.

Infrastruktúraszintű monitorozás

Ez a táblázat az Azure Monitor által gyűjtött naplókra és metrikákra mutat. Az elérhető riasztások segítenek proaktív módon kezelni a problémákat, mielőtt azok hatással lennének a felhasználókra.

Azure-erőforrás	Metrikák és naplók	Riasztások
Application Gateway	Az Application Gateway metrikáinak és naplóinak leírása	Application Gateway-riasztások
Application Insights	Application Insights-metrikák és naplózási API	Application Insights-riasztások
Azure Bastion	Azure Bastion-metrikák
Key Vault	Key Vault-metrikák és naplók leírása	Key Vault-riasztások
Standard Load Balancer	Terheléselosztó naplói és metrikái	Load Balancer-riasztások
Nyilvános IP-cím	Nyilvános IP-címmetrikák és naplók leírása	Nyilvános IP-címmetrika-riasztások
Virtual Network	Virtuális hálózati metrikák és naplók referenciája	Virtuális hálózati riasztások
Virtuális gépek és virtuálisgép-méretezési csoportok	Virtuálisgép-metrikák és naplók referenciája	Virtuálisgép-riasztások és oktatóanyagok
Webalkalmazási tűzfal	Webalkalmazási tűzfal metrikái és naplóinak leírása	Webalkalmazási tűzfalra vonatkozó riasztások

A metrikák és naplók gyűjtésének költségeiről további információt a Log Analytics költségszámításai és beállításai, valamint a Log Analytics-munkaterület díjszabása című témakörben talál. A számítási feladat jellege, valamint az összegyűjtött metrikák és naplók gyakorisága és száma nagyban befolyásolja a metrika- és naplógyűjtés költségeit.

Virtual machines (Virtuális gépek)

Az Azure rendszerindítási diagnosztika lehetővé teszi a virtuális gépek állapotának megfigyelését a rendszerindítás során a soros naplóadatok és képernyőképek gyűjtésével. Ebben az architektúrában az adatok az Azure Portalon és az Azure CLI vm boot-diagnostics get-boot-log parancsán keresztül érhetők el. Az adatokat az Azure kezeli, és ön nem rendelkezik az alapul szolgáló tárolási erőforrással vagy hozzáféréssel. Ha azonban az üzleti követelmények további ellenőrzést igényelnek, saját tárfiókot is kiépítheti a rendszerindítási diagnosztikák tárolásához.

A virtuálisgép-elemzések hatékony módszert kínálnak a virtuális gépek és a méretezési csoportok monitorozására. Adatokat gyűjt a Log Analytics-munkaterületekről, és előre definiált munkafüzeteket biztosít a teljesítményadatok trendezéséhez. Ezek az adatok megtekinthetők virtuális gépenként, vagy összesíthetők több virtuális gépen.

Az Application Gateway és a belső terheléselosztó állapotadat-mintavételekkel észleli a virtuális gépek végpontállapotát a forgalom elküldése előtt.

Hálózat

Ebben az architektúrában a rendszer naplóadatokat gyűjt a folyamatban részt vevő hálózati összetevőkből. Ezek az összetevők közé tartozik az Application Gateway, a terheléselosztók és az Azure Bastion. Ezek közé tartoznak a hálózati biztonsági összetevők, például a virtuális hálózatok, az NSG-k, a nyilvános IP-címek és a Private Link.

felügyelt lemezek

A lemezmetrikák a számítási feladattól függenek, és a legfontosabb metrikák kombinációját igénylik. A monitorozásnak kombinálnia kell ezeket a perspektívákat az operációs rendszer vagy az alkalmazás átviteli sebességével kapcsolatos problémák elkülönítéséhez.

• Az Azure platform perspektívája azOkat a metrikákat jelöli, amelyek az Azure-szolgáltatást jelölik, függetlenül attól, hogy milyen számítási feladat kapcsolódik hozzá. A lemezteljesítmény-metrikák (IOPS és átviteli sebesség) egyenként vagy együttesen tekinthetők meg az összes virtuális géphez csatlakoztatott lemez esetében. A tároló I/O-kihasználtsági metrikáival hibaelhárítást vagy riasztást alkalmazhat a lehetséges lemezkorlátozással kapcsolatban. Ha a költségoptimalizáláshoz a kipukkadást használja, a kreditek százalékos metrikáinak figyelésével azonosíthatja a további optimalizálási lehetőségeket.

• A vendég operációs rendszer perspektívája azokat a metrikákat jelöli, amelyeket a számítási feladat operátora a mögöttes lemeztechnológiától függetlenül megtekint. A virtuálisgép-elemzések a csatlakoztatott lemezek legfontosabb metrikáihoz, például a felhasznált logikai lemezterülethez, valamint az operációsrendszer-kernelnek a lemez IOPS-ra és átviteli sebességre vonatkozó szempontjaihoz ajánlottak.

Alkalmazásszintű monitorozás

Annak ellenére, hogy a referencia-implementáció nem használja, az Application Insights alkalmazásteljesítmény-kezelésként (APM) van kiépítve bővíthetőségi célokra. Az Application Insights adatokat gyűjt egy alkalmazásból, és elküldi ezeket az adatokat a Log Analytics-munkaterületnek. Az adatokat a számítási feladatok alkalmazásából is megjelenítheti.

Az alkalmazásállapot-bővítmény a virtuális gépeken van üzembe helyezve a méretezési csoportban lévő egyes virtuálisgép-példányok bináris állapotának figyeléséhez, és szükség esetén a méretezési csoport automatikus példányjavításával elvégzi a példányok javítását. Ugyanazt a fájlt teszteli, mint az Application Gateway és a belső Azure Load Balancer állapottesztje, hogy ellenőrizze, hogy az alkalmazás válaszkész-e.

Frissítéskezelés

A virtuális gépeket rendszeresen frissíteni és javítani kell, hogy ne ronthassák a számítási feladat biztonsági helyzetét. Javasoljuk, hogy automatikus és rendszeres virtuálisgép-felméréseket biztosítsunk a javítások korai felderítéséhez és alkalmazásához.

Infrastruktúra-frissítések

Az Azure rendszeresen frissíti platformját a virtuális gépek gazdagépinfrastruktúra megbízhatóságának, teljesítményének és biztonságának javítása érdekében. Ezek a frissítések közé tartozik a szoftverösszetevők javítása az üzemeltetési környezetben, a hálózati összetevők frissítése vagy a hardver leszerelése stb. A frissítési folyamatról további információt az Azure-beli virtuális gépek karbantartása című témakörben talál.

Ha egy frissítés nem igényel újraindítást, a virtuális gép szünetel a gazdagép frissítésekor, vagy a virtuális gép élő áttelepítése egy már frissített gazdagépre. Ha a karbantartás újraindítást igényel, értesítést kap a tervezett karbantartásról. Az Azure emellett egy időkeretet is biztosít, amelyben az Ön kényelme érdekében megkezdheti a karbantartást. Az önkarbantartási időszakról és az elérhető beállítások konfigurálásáról további információt a tervezett karbantartási értesítések kezelése című témakörben talál.

Előfordulhat, hogy egyes számítási feladatok néhány másodpercig sem tolerálják a virtuális gépek lefagyását vagy leválasztását karbantartás céljából. Az összes karbantartási tevékenység, beleértve a hatástalan és az újraindítás nélküli frissítéseket is, a Karbantartási konfigurációk című témakörben olvashat bővebben. A karbantartási konfiguráció létrehozása lehetővé teszi, hogy kihagyja az összes platformfrissítést, és az ön kényelme érdekében alkalmazza a frissítéseket. Ha ez az egyéni konfiguráció be van állítva, az Azure kihagyja az összes nem hatásmentes frissítést, beleértve az újraindítás nélküli frissítéseket is. További információ: Platformfrissítések kezelése karbantartási konfigurációkkal

Operációs rendszer (OS) rendszerképeinek frissítései

Az operációsrendszer-frissítések során egy tesztelt, aranyszínű rendszerképet kell létrehoznia. Fontolja meg az Azure Shared Image Gallery és az Azure Compute Gallery használatát az egyéni rendszerképek közzétételéhez. Rendelkeznie kell egy olyan folyamattal, amely a példányok kötegeit folyamatosan frissíti minden alkalommal, amikor a közzétevő közzétesz egy új lemezképet.

A felület csökkentése érdekében vonja ki a virtuálisgép-rendszerképeket, mielőtt elérnék az élettartamukat.

Az automatizálási folyamatnak figyelembe kell vennie a többletkapacitással rendelkező túlterjedéseket.

Az Azure Update Management segítségével kezelheti a Windows- és Linux rendszerű virtuális gépek operációsrendszer-frissítéseit az Azure.Azure Update Managerben, amely egy SaaS-megoldást kínál a Windows és Linux rendszerű gépek szoftverfrissítéseinek kezelésére és szabályozására az Azure-ban, a helyszíni és a többfelhős környezetben.

Vendég operációs rendszer javítása

Az Azure-beli virtuális gépek biztosítják az automatikus virtuálisgép-vendégjavítás lehetőségét. Ha ez a szolgáltatás engedélyezve van, a rendszer rendszeresen kiértékeli a virtuális gépeket, és az elérhető javításokat besorolja. Javasoljuk, hogy az Értékelési mód engedélyezve legyen a függőben lévő javítások napi kiértékeléséhez. Igény szerinti felmérést azonban lehet végezni, amely nem váltja ki a javítások alkalmazását. Ha az értékelési mód nincs engedélyezve, manuálisan észlelheti a függőben lévő frissítéseket.

Csak a kritikus vagy biztonsági besorolású javítások lesznek automatikusan alkalmazva minden Azure-régióban. Más javításokat alkalmazó egyéni frissítéskezelési folyamatok definiálása.

A szabályozáshoz fontolja meg az operációsrendszer-rendszerkép automatikus javításának megkövetelését a virtuálisgép-méretezési csoportok Azure-szabályzatában.

Az automatikus javítások terhet róhatnak a rendszerre, és zavaróak lehetnek, mivel a virtuális gépek erőforrásokat használnak, és a frissítések során újraindulhatnak. A terheléskezeléshez a túlkiépítés ajánlott. Virtuális gépek üzembe helyezése különböző rendelkezésre állási zónákban az egyidejű frissítések elkerülése és a magas rendelkezésre állás érdekében zónánként legalább két példány fenntartása érdekében. Az ugyanabban a régióban lévő virtuális gépek különböző javításokat kaphatnak, amelyeket idővel egyeztetni kell.

Vegye figyelembe a túlterjedéssel járó költségekkel kapcsolatos kompromisszumot.

Az állapot-ellenőrzések az automatikus virtuálisgép-vendégjavítás részeként jelennek meg. Ezek az ellenőrzések ellenőrzik a sikeres javításalkalmazást, és észlelik a problémákat.

Ha vannak egyéni folyamatok a javítások alkalmazásához, használjon privát adattárakat a javításforrásokhoz. Így jobban szabályozhatja a javítások tesztelését, hogy a frissítés ne befolyásolja negatívan a teljesítményt vagy a biztonságot.

További információ: Azure-beli virtuális gépek automatikus virtuálisgép-vendégjavítása.

Megbízhatóság

Ez az architektúra a rendelkezésre állási zónákat használja alapvető elemként a megbízhatósági problémák kezeléséhez.

Ebben a beállításban az egyes virtuális gépek egyetlen zónához vannak kötve. Hiba esetén ezek a virtuális gépek könnyen lecserélhetők más virtuálisgép-példányokra a virtuálisgép-méretezési csoportok használatával.

Az architektúra minden más összetevője a következő:

• Zónaredundáns, ami azt jelenti, hogy több zónában replikálódnak a magas rendelkezésre állás érdekében, például Az Application Gateway vagy a nyilvános IP-címek.
• A zóna rugalmas, ami azt jelenti, hogy ellenállnak a zónahibáknak, például a Key Vaultnak.
• Régiónként vagy globálisan elérhető regionális vagy globális erőforrások, például a Microsoft Entra ID.

A számítási feladatok tervezésének megbízhatósági biztosítékokat kell tartalmaznia az alkalmazáskódban, az infrastruktúrában és a műveletekben. Az alábbi szakaszok néhány stratégiát mutatnak be, amelyek biztosítják, hogy a számítási feladatok rugalmasak legyenek a hibákkal szemben, és képesek legyenek helyreállni, ha az infrastruktúra szintjén leállások vannak.

Az architektúrában használt stratégiák az Azure Well-Architected Framework megbízhatósági tervezési felülvizsgálati ellenőrzőlistáján alapulnak. A szakaszok az ellenőrzőlista javaslataival vannak eljegyzve.

Mivel nincs üzembe helyezve alkalmazás, az alkalmazáskód rugalmassága meghaladja az architektúra hatókörét. Javasoljuk, hogy tekintse át az ellenőrzőlista összes javaslatát, és szükség esetén fogadja el őket a számítási feladatban.

A megbízhatósági garanciák rangsorolása felhasználói folyamatonként

A legtöbb kialakításban több felhasználói folyamat is létezik, amelyek mindegyike saját üzleti követelményekkel rendelkezik. Nem mindegyik folyamat igényel a legmagasabb szintű biztosítékokat, ezért megbízhatósági stratégiaként a szegmentálás ajánlott. Az egyes szegmensek egymástól függetlenül kezelhetők, biztosítva, hogy az egyik szegmens ne legyen hatással másokra, és hogy az egyes szinteken a megfelelő szintű rugalmasságot biztosítsuk. Ez a megközelítés rugalmassá teszi a rendszert is.

Ebben az architektúrában az alkalmazásszintek implementálják a szegmentálást. A rendszer külön méretezési csoportokat hoz létre az előtér- és háttérrétegekhez. Ez az elkülönítés lehetővé teszi az egyes szintek független skálázását, lehetővé téve a tervezési minták implementálását az adott követelmények alapján, többek között más előnyök mellett.

Tekintse meg a well-architected keretrendszert: RE:02 – Javaslatok a folyamatok azonosítására és minősítésére.

A lehetséges hibapontok azonosítása

Minden architektúra hajlamos a hibákra. A hibamód-elemzés gyakorlatával előre jelezheti a hibákat, és felkészülhet a kockázatcsökkentésekre. Íme néhány lehetséges hibapont ebben az architektúrában:

Összetevő	Kockázat	Valószínűség	Effektus/Kockázatcsökkentés/Megjegyzés	Szolgáltatáskimaradás
Microsoft Entra ID	Hibás konfiguráció	Közepes	Az ops-felhasználók nem tudnak bejelentkezni. Nincs alsóbb rétegbeli hatás. Az ügyfélszolgálat a konfigurációs problémát jelenti az identitáscsoportnak.	Egyik sem
Application Gateway	Hibás konfiguráció	Közepes	A helytelen konfigurációkat az üzembe helyezés során kell elkapni. Ha ezek a hibák egy konfigurációfrissítés során fordulnak elő, a DevOps csapatának vissza kell állítania a módosításokat. A v2 termékváltozatot használó legtöbb üzembe helyezés üzembe helyezése körülbelül 6 percet vesz igénybe. Az üzembe helyezés típusától függően azonban hosszabb időt is igénybe vehet. A több példányt tartalmazó rendelkezésre állási zónák üzembe helyezése például több mint 6 percet is igénybe vehet.	Teljes
Application Gateway	DDoS-támadás	Közepes	A fennakadás lehetősége. A Microsoft kezeli a DDoS (L3 és L4) védelmét. Az L7-támadások lehetséges hatásának kockázata.	Teljes
Virtual Machine Scale Sets	Szolgáltatáskimaradás	Alacsony	Lehetséges számítási feladatok leállása, ha vannak olyan nem megfelelő állapotú virtuálisgép-példányok, amelyek automatikus helyreállítást váltanak ki. A Szervizelés a Microsofttól függ.	Lehetséges kimaradás
Virtual Machine Scale Sets	Rendelkezésre állási zóna kimaradása	Alacsony	Nincs hatás. A méretezési csoportok zónaredundánsként vannak üzembe helyezve.	Egyik sem

Tekintse meg a well-architected keretrendszert: RE:03 – Javaslatok a hibamód-elemzés végrehajtásához.

Megbízhatósági célok

A tervezési döntések meghozatalához fontos kiszámítani a megbízhatósági célokat, például a számítási feladat összetett szolgáltatásiszint-célkitűzéseit (SLO-kat). Ez magában foglalja az architektúrában használt Azure-szolgáltatások által biztosított szolgáltatásiszint-szerződések (SLA-k) megértését. A számítási feladatokra vonatkozó SLO-k nem lehetnek magasabbak, mint az Azure által garantált SLA-k. Gondosan vizsgálja meg az egyes összetevőket a virtuális gépekről és azok függőségeiből, hálózatkezelési és tárolási lehetőségeiből.

Íme egy példaszámítás, amelyben a fő cél egy hozzávetőleges összetett SLO megadása. Bár ez egy durva iránymutatás, meg kell érkeznie valami hasonló. Nem szabad magasabb maximális összetett SLO-t kapnia ugyanahhoz a folyamathoz, hacsak nem módosítja az architektúrát.

Műveleti folyamat

Összetevő	SLO
Microsoft Entra ID	99,99%
Azure Bastion	99,95%

Összetett SLO: 99,94% | Állásidő évente: 0d 5h 15m 20s

Alkalmazásfelhasználói folyamat

Összetevő	SLO
Application Gateway	99,95%
Azure Load Balancer (belső)	99,99%
Előtérbeli virtuális gépek prémium szintű tárolással (összetett SLO)	99.70%
Háttérbeli virtuális gépek prémium szintű tárolással (összetett SLO)	99.70%

Összetett SLO: 99,34% | Állásidő évente: 2d 9h 42m 18s

Az előző példában a virtuális gépek megbízhatósága és a függőségek szerepelnek, például a virtuális gépekhez társított lemezek. A lemeztároláshoz társított SLA-k hatással vannak az általános megbízhatóságra.

Az összetett SLO kiszámításakor bizonyos kihívások merülnek fel. Fontos megjegyezni, hogy a különböző szolgáltatási szintek különböző SLA-kat tartalmazhatnak, és ezek gyakran tartalmaznak pénzügyileg támogatott garanciákat, amelyek megbízhatósági célokat határoznak meg. Végül előfordulhat, hogy az architektúra olyan összetevői is vannak, amelyekhez nincs meghatározva SLA. A hálózatkezelés szempontjából például a hálózati adapterek és a virtuális hálózatok nem rendelkeznek saját SLA-kkal.

Az üzleti követelményeket és azok céljait egyértelműen meg kell határozni, és figyelembe kell venni a számításban. Vegye figyelembe a szervezet által előírt szolgáltatási korlátokat és egyéb korlátozásokat. Az előfizetés más számítási feladatokkal való megosztása hatással lehet a virtuális gépek számára elérhető erőforrásokra. Előfordulhat, hogy a számítási feladat korlátozott számú magot használhat a virtuális gépek számára. Az előfizetés erőforrás-használatának megismerése segíthet a virtuális gépek hatékonyabb tervezésében.

Tekintse meg a well-architected keretrendszert: RE:04 – Javaslatok a megbízhatósági célok meghatározásához.

Redundancia

Ez az architektúra zónaredundanciát használ több összetevőhöz. Minden zóna egy vagy több adatközpontból áll, független energiaellátással, hűtéssel és hálózatkezeléssel. Ha a példányok külön zónákban futnak, az védi az alkalmazást az adatközpont hibáitól.

• A virtuálisgép-méretezési csoportok meghatározott számú példányt foglalnak le, és egyenletesen elosztják őket a rendelkezésre állási zónák és a tartalék tartományok között. Ez az eloszlás az ajánlott maximális szórási képességen keresztül érhető el. A virtuálisgép-példányok tartalék tartományok közötti terjesztése biztosítja, hogy az összes virtuális gép ne frissüljön egyszerre.

  Fontolja meg azt a forgatókönyvet, amelyben három rendelkezésre állási zóna van. Ha három példánya van, minden példány egy másik rendelkezésre állási zónához lesz lefoglalva, és egy másik tartalék tartományba kerül. Az Azure garantálja, hogy egyszerre csak egy tartalék tartomány frissül az egyes rendelkezésre állási zónákban. Előfordulhat azonban, hogy a virtuális gépeket üzemeltető mindhárom tartalék tartomány egyszerre frissül a három rendelkezésre állási zónában. Minden zóna és tartomány érintett. Ha minden zónában legalább két példány található, puffert biztosít a frissítések során.

• A felügyelt lemezek csak ugyanabban a régióban lévő virtuális géphez csatolhatók. A rendelkezésre állásuk általában befolyásolja a virtuális gép rendelkezésre állását. Az egyrégiós üzemelő példányok esetében a lemezek konfigurálhatók redundanciára, hogy ellenálljanak az zonális hibáknak. Ebben az architektúrában az adatlemezek zónaredundáns tárolást (ZRS) konfigurálnak a háttérbeli virtuális gépeken. A rendelkezésre állási zónák kihasználásához helyreállítási stratégia szükséges. A helyreállítási stratégia a megoldás ismételt üzembe helyezése. Ideális esetben előre kiépíteni a számítást alternatív rendelkezésre állási zónákban, készen arra, hogy helyreálljon egy zonális hibából.

• A zónaredundáns Application Gateway vagy a standard terheléselosztó egyetlen IP-címmel irányíthatja a forgalmat virtuális gépekre a zónák között, így a zónahibák esetén is folyamatosságot biztosít. Ezek a szolgáltatások állapottesztekkel ellenőrzik a virtuális gépek rendelkezésre állását. Mindaddig, amíg a régió egy zónája működőképes marad, az útválasztás a többi zónában előforduló esetleges hibák ellenére is folytatódik. A zónák közötti útválasztás azonban nagyobb késéssel járhat a zónán belüli útválasztáshoz képest.

  Az architektúrában használt összes nyilvános IP-cím zónaredundáns.

• Az Azure zónareziliens szolgáltatásokat kínál a jobb megbízhatóság érdekében, például a Key Vaulthoz.

• Az Azure globális erőforrásai mindig elérhetők, és szükség esetén átválthatnak egy másik régióra, például az alapvető identitásszolgáltatóra, a Microsoft Entra ID-ra.

Tekintse meg a jól megtervezett keretrendszert: RE:05 – Javaslatok a redundancia tervezéséhez.

Skálázási stratégia

A szolgáltatásszintek romlásának és hibáinak megelőzése érdekében gondoskodjon a megbízható skálázási műveletekről. A számítási feladat horizontális skálázása (horizontális felskálázás), függőleges (vertikális felskálázás) vagy mindkét megközelítés kombinációja. Az Azure Monitor Automatikus skálázás funkcióval elegendő erőforrást építhet ki az alkalmazás igényeinek kielégítéséhez anélkül, hogy a szükségesnél több kapacitást kellene kiosztani, és szükségtelen költségekkel kellene számolnia.

Az automatikus skálázás lehetővé teszi, hogy különböző profilokat definiáljon különböző eseménytípusok, például idő, ütemezés vagy metrikák alapján. A metrikákon alapuló profilok beépített metrikákat (gazdagépalapú) vagy részletesebb metrikákat (vendég virtuálisgép-metrikákat) használhatnak, amelyek gyűjtéséhez telepíteni kell az Azure Monitor Agentet. Minden profil a vertikális felskálázásra (növelésre) és a vertikális felskálázásra (csökkentésre) vonatkozó szabályokat tartalmaz. Fontolja meg az összes különböző skálázási forgatókönyv feltárását a tervezett profilok alapján, és értékelje ki azokat a lehetséges ciklusfeltételeket, amelyek ellentétes skálázási események sorozatát okozhatják. Az Azure Monitor úgy próbálja enyhíteni a helyzetet, hogy megvárja a lehűlési időszakot, mielőtt újra skálázható lenne.

Bár az Azure Virtual Machine Scale Sets rugalmas módban támogatja a heterogén környezeteket, több profil automatikus skálázása nem támogatott. Érdemes lehet különböző méretezési csoportokat létrehozni, hogy külön kezelje őket, ha több virtuális géppel szeretne automatikus skálázást használni.

A virtuálisgép-példányok létrehozásakor vagy törlésekor fontolja meg az egyéb szempontokat, például a rendszerindítást, a kecses leállításokat, a számítási feladat és annak összes függőségének telepítését, valamint a lemezkezelést.

Az állapotalapú számítási feladatok további felügyeletet igényelhetnek olyan felügyelt lemezek esetében, amelyeknek a számítási feladatpéldányon túl kell élnie. A számítási feladat tervezése az adatkezeléshez skálázási események alatt a számítási feladat adatainak konzisztenciája, szinkronizálása, replikációja és integritása érdekében. Ezekben a forgatókönyvekben érdemes lehet előre feltöltött lemezeket hozzáadni a méretezési csoportokhoz. Olyan használati esetekben, amikor a skálázás az adatok elérésekor szűk keresztmetszetek megelőzésére szolgál, tervezze meg a particionálást és a horizontális skálázást. További információkért tekintse meg az automatikus skálázás ajánlott eljárásait.

Tekintse meg a jól megtervezett keretrendszert: RE:06 – Javaslatok egy megbízható skálázási stratégia kialakításához.

Öngyógyítás és helyreállíthatóság

A virtuálisgép-méretezési csoportokban engedélyezve van az automatikus példányjavítás a virtuálisgép-hibák utáni helyreállítás automatizálásához. Az alkalmazásállapot-bővítmény a virtuális gépeken van üzembe helyezve, hogy támogassa a nem válaszoló virtuális gépek és alkalmazások észlelését. Ezekben a példányokban a javítási műveletek automatikusan aktiválódnak.

Tekintse meg a Well-Architected Frameworkt: Javaslatok az öngyógyításhoz és az önmegőrzéshez.

Biztonság

Ez az architektúra bemutatja az Azure Well-Architected Frameworkben megadott biztonsági terv felülvizsgálati ellenőrzőlistájában szereplő biztonsági garanciák némelyikét. A szakaszok az ellenőrzőlista javaslataival vannak eljegyzve.

A biztonság nem csak a technikai vezérlőkre vonatkozik. Javasoljuk, hogy kövesse a teljes ellenőrzőlistát a biztonsági pillér működési szempontjainak megértéséhez.

Szegmentálás

• Hálózati szegmentálás. A számítási feladatok erőforrásai egy virtuális hálózatba kerülnek, amely elkülönítést biztosít az internettől. A virtuális hálózaton belül az alhálózatok használhatók megbízhatósági határként. Az egy alhálózaton belüli tranzakciók kezeléséhez szükséges kapcsolódó erőforrások áthelyezése. Ebben az architektúrában a virtuális hálózat alhálózatokra van osztva az alkalmazás logikai csoportosítása és a számítási feladat részeként használt különböző Azure-szolgáltatások célja alapján.

  Az alhálózat szegmentálásának előnye, hogy biztonsági vezérlőket helyezhet el az alhálózaton bejövő és kimenő forgalmat vezérlő szegélyen, ezáltal korlátozva a számítási feladatok erőforrásaihoz való hozzáférést.

• Identitásszegmentáció. Különböző szerepkörök hozzárendelése különböző identitásokhoz, amelyek elegendő engedélyekkel rendelkeznek a feladatuk elvégzéséhez. Ez az architektúra a Microsoft Entra ID által felügyelt identitásokat használja az erőforrásokhoz való hozzáférés szegmentálására.

• Erőforrás-szegmentálás. Az alkalmazás szintjei külön méretezési csoportokba vannak szegmentálva, ami biztosítja, hogy az alkalmazásösszetevők ne legyennek egymás mellett.

Lásd: Well-Architected Framework: SE:04 – Javaslatok szegmentálási stratégia létrehozásához.

Identitás- és hozzáférés-kezelés

Javasoljuk, hogy a Microsoft Entra-azonosítót mind a felhasználók, mind a szolgáltatások hitelesítéséhez és engedélyezéséhez használja.

A virtuális gépekhez való hozzáféréshez egy felhasználói fiók szükséges, amelyet a Microsoft Entra ID-hitelesítés vezérel, és amelyet biztonsági csoportok biztosítanak. Ez az architektúra támogatja a Microsoft Entra ID hitelesítési bővítmény üzembe helyezését az összes virtuális gépen. Azt javasoljuk, hogy az emberi felhasználók használják a vállalati identitásaikat a szervezet Microsoft Entra ID-bérlőjében. Emellett győződjön meg arról, hogy a szolgáltatásnév-alapú hozzáférések nincsenek megosztva a függvények között.

A számítási feladatok erőforrásai, például a virtuális gépek, a hozzárendelt felügyelt identitások más erőforrásokhoz való használatával hitelesítik magukat. Ezek az identitások a Microsoft Entra ID szolgáltatásnév alapján automatikusan kezelhetők.

A Key Vault-bővítmények például olyan virtuális gépekre vannak telepítve, amelyek tanúsítványokkal indítják el a virtuális gépeket. Ebben az architektúrában a felhasználó által hozzárendelt felügyelt identitásokat az Application Gateway, az előtérbeli virtuális gépek és a háttérbeli virtuális gépek használják a Key Vault eléréséhez. Ezek a felügyelt identitások az üzembe helyezés során vannak konfigurálva, és a Key Vaulton való hitelesítéshez használatosak. A Key Vault hozzáférési szabályzatai úgy vannak konfigurálva, hogy csak az előző felügyelt identitásokból érkező kéréseket fogadják el.

Az alaparchitektúra a rendszer által hozzárendelt és a felhasználó által hozzárendelt felügyelt identitások kombinációját használja. Ezek az identitások a Microsoft Entra-azonosítót kell használniuk engedélyezési célokra más Azure-erőforrások elérésekor.

Tekintse meg a well-architected keretrendszert: SE:05 – Az identitás- és hozzáférés-kezelésre vonatkozó javaslatok.

Hálózati vezérlők

• Bejövő forgalom. A számítási feladatok virtuális gépei nincsenek közvetlenül kitéve a nyilvános internetnek. Minden virtuális gép rendelkezik egy privát IP-címmel. A számítási feladatok felhasználói az Application Gateway nyilvános IP-címével csatlakoznak.

  Az Application Gatewaybe integrált webalkalmazási tűzfal nagyobb biztonságot nyújt. Olyan szabályokkal rendelkezik, amelyek ellenőrzik a bejövő forgalmat, és megfelelő lépéseket tehetnek. A WAF nyomon követi az Open Web Application Security Project (OWASP) biztonsági réseit, amelyek megakadályozzák az ismert támadásokat.

• Kimenő forgalom. A kimenő forgalomra csak a virtuálisgép-alhálózatok kimenő NSG-szabályai vonatkoznak. Javasoljuk, hogy minden kimenő internetes forgalom egyetlen tűzfalon haladjon át. Ez a tűzfal általában egy szervezet által biztosított központi szolgáltatás. Ez a használati eset egy Azure-beli célzóna virtuálisgép-alapkonfigurációs architektúrájában jelenik meg.

• Kelet-nyugati forgalom. Az alhálózatok közötti forgalom részletes biztonsági szabályok alkalmazásával korlátozott.

  A hálózati biztonsági csoportok (NSG-k) az alhálózatok közötti forgalom korlátozására szolgálnak olyan paraméterek alapján, mint az IP-címtartomány, a portok és a protokollok. Az alkalmazásbiztonsági csoportok (ASG) előtérbeli és háttérbeli virtuális gépekre kerülnek. Ezek az NSG-k segítségével szűrik a virtuális gépekre érkező és onnan érkező forgalmat.

• Operatív forgalom. Javasoljuk, hogy a számítási feladatokhoz való biztonságos üzemeltetési hozzáférést az Azure Bastionon keresztül biztosítsa, ami szükségtelenné teszi a nyilvános IP-cím használatát. Ebben az architektúrában ez a kommunikáció SSH-kapcsolaton keresztül történik, és windowsos és Linux rendszerű virtuális gépek is támogatják. A Microsoft Entra ID mindkét típusú virtuális gép esetében integrálva van az SSH-val a megfelelő virtuálisgép-bővítmény használatával. Ez az integráció lehetővé teszi az operátor identitásának hitelesítését és engedélyezését a Microsoft Entra ID-val.

  Másik lehetőségként használjon egy külön virtuális gépet jump boxként, amelyet a saját alhálózatán helyez üzembe, ahol telepítheti a választott rendszergazdai és hibaelhárítási eszközöket. Az operátor az Azure Bastion-gazdagépen keresztül fér hozzá a jump boxhoz. Ezután bejelentkeznek a terheléselosztó mögötti virtuális gépekre a jump boxból.

  Ebben az architektúrában az operatív forgalom NSG-szabályokkal van védve a forgalom korlátozásához, és a virtuális gépeken engedélyezve van a just-in-time (JIT) virtuális gépek hozzáférése . A Felhőhöz készült Microsoft Defender ezen funkciója lehetővé teszi a kijelölt portokhoz való ideiglenes bejövő hozzáférést.

  A fokozott biztonság érdekében használja a Microsoft Entra Privileged Identity Management (PIM) szolgáltatást. A PIM a Microsoft Entra ID szolgáltatása, amely lehetővé teszi a szervezet fontos erőforrásaihoz való hozzáférés kezelését, ellenőrzését és monitorozását. A PIM időalapú és jóváhagyási alapú szerepkör-aktiválást biztosít a fontos erőforrások túlzott, szükségtelen vagy helytelen hozzáférési engedélyeinek kockázatának csökkentése érdekében.

• Privát kapcsolat a szolgáltatásként nyújtott platformmal (PaaS) kapcsolatos szolgáltatásokhoz. A virtuális gépek és a Key Vault közötti kommunikáció privát kapcsolaton keresztül történik. Ehhez a szolgáltatáshoz privát végpontok szükségesek, amelyek egy külön alhálózatban vannak elhelyezve.

• DDoS-védelem. Fontolja meg az Azure DDoS Protection engedélyezését az Application Gateway és az Azure Bastion Host által közzétett nyilvános IP-címeken a fenyegetések észleléséhez. A DDoS Protection riasztást, telemetriát és elemzést is biztosít a Monitoron keresztül. További információ: Azure DDoS Protection: Ajánlott eljárások és referenciaarchitektúrák.

Tekintse meg a well-architected keretrendszert: SE:06 – A hálózatkezelésre és a kapcsolatokra vonatkozó javaslatok.

Titkosítás

• Átvitt adatok. A felhasználók és az Application Gateway nyilvános IP-címe közötti felhasználói forgalom a külső tanúsítvány használatával van titkosítva. Az application gateway és az előtérbeli virtuális gépek, valamint az előtérbeli és a háttérbeli virtuális gépek közötti forgalom egy belső tanúsítvány használatával van titkosítva. Mindkét tanúsítvány a Key Vaultban van tárolva:

  • app.contoso.com: Az ügyfelek és az Application Gateway által a nyilvános internetes forgalom biztonságossá tételéhez használt külső tanúsítvány.
  • *.workload.contoso.com: Az infrastruktúra-összetevők által a belső forgalom biztonságossá tételéhez használt helyettesítő tanúsítvány.

• Inaktív adatok. A naplóadatok egy virtuális gépekhez csatlakoztatott felügyelt lemezen vannak tárolva. Ezek az adatok automatikusan titkosítva lesznek platform által biztosított titkosítással az Azure-ban.

Tekintse meg a well-architected keretrendszert: SE:07 – Az adattitkosításra vonatkozó javaslatok.

Titkos kódok kezelése

Töltse le az architektúra Visio-fájlját.

A Key Vault biztonságosan felügyeli a titkos kulcsokat, beleértve a TLS-tanúsítványokat is. Ebben az architektúrában a TLS-tanúsítványokat a Key Vault tárolja, és a kiépítési folyamat során az Application Gateway és a virtuális gépek felügyelt identitásai kérik le. A kezdeti beállítás után ezek az erőforrások csak a tanúsítványok frissítésekor férnek hozzá a Key Vaulthoz.

A virtuális gépek a Key Vault virtuálisgép-bővítmény használatával automatikusan frissítik a figyelt tanúsítványokat. Ha bármilyen módosítást észlel a helyi tanúsítványtárolóban, a bővítmény lekéri és telepíti a megfelelő tanúsítványokat a Key Vaultból. A bővítmény támogatja a PKCS #12 és A PEM tanúsítványtartalmat.

Lásd: Well-Architected Framework: SE:09 – Javaslatok az alkalmazás titkos kulcsainak védelmére.

Költségoptimalizálás

A számítási feladatokra vonatkozó követelményeket a költségkorlátok figyelembevételével kell teljesíteni. Az architektúrában használt stratégiák az Azure Well-Architected Framework költségoptimalizálási tervezési felülvizsgálati ellenőrzőlistáján alapulnak. Ez a szakasz a költségek optimalizálásának néhány lehetőségét ismerteti, és az ellenőrzőlista javaslataival van eljegyzve.

Összetevő költsége

Válassza ki a számítási feladathoz optimalizált virtuálisgép-rendszerképeket általános célú rendszerképek használata helyett. Ebben az architektúrában viszonylag kis méretű virtuálisgép-rendszerképek vannak kiválasztva Windows és Linux rendszeren is, amelyek mindegyike 30 GB. Kisebb rendszerképek esetén a lemezekkel rendelkező virtuálisgép-termékváltozatok is kisebbek, ami alacsonyabb költségeket, alacsonyabb erőforrás-felhasználást, valamint gyorsabb üzembe helyezést és rendszerindítási időt eredményez. A kisebb felület miatt az előny a fokozott biztonság.

A naplóforgatás méretkorlátokkal való implementálása egy másik költségmegtakarítási stratégia. Lehetővé teszi a kis adatlemezek használatát, ami alacsonyabb költségeket eredményezhet. Az architektúra megvalósítása 4 GB-os lemezeket használ.

A rövid élettartamú operációsrendszer-lemezek használata költségmegtakarításhoz és jobb teljesítményhez is vezethet. Ezeket a lemezeket úgy tervezték, hogy olyan virtuálisgép-erőforrásokat használjanak, amelyekért már fizet, mert a virtuális géppel kiépített gyorsítótárlemezre vannak telepítve. Kiküszöböli a hagyományos állandó lemezekhez kapcsolódó tárolási költségeket. Mivel ezek a lemezek ideiglenesek, a hosszú távú adattárolási költségek nem járnak költségekkel.

Tekintse meg a well-architected keretrendszert: CO:07 – Javaslatok az összetevők költségeinek optimalizálására.

Folyamat költsége

Válassza ki a számítási erőforrásokat a folyamat kritikussága alapján. A határozatlan hosszúságú folyamatok esetében érdemes lehet kihasználatlan virtuális gépeket használni a virtuálisgép-méretezési csoportok rugalmas vezénylési módjával. Ez a megközelítés hatékony lehet alacsony prioritású folyamatok alacsonyabb prioritású virtuális gépeken való üzemeltetéséhez. Ez a stratégia lehetővé teszi a költségoptimalizálást, miközben továbbra is megfelel a különböző folyamatok követelményeinek.

Tekintse meg a jól kiépítésű keretrendszert: CO:09 – Javaslatok a folyamatköltségek optimalizálására.

Skálázási költség

Ha a fő költségillesztő a példányok száma, költséghatékonyabb lehet a vertikális felskálázás a virtuális gépek méretének vagy teljesítményének növelésével. Ez a megközelítés több területen is költségmegtakarításhoz vezethet:

• Szoftverlicencelés. A nagyobb virtuális gépek több számítási feladatot képesek kezelni, ami csökkentheti a szükséges szoftverlicencek számát.
• Karbantartási idő: Kevesebb, nagyobb virtuális gép csökkentheti az üzemeltetési költségeket.
• Terheléselosztás: Kevesebb virtuális gép alacsonyabb terheléselosztási költségeket eredményezhet. Ebben az architektúrában például több terheléselosztási réteg is létezik, például az előtérben egy application gateway, középen pedig egy belső terheléselosztó. A terheléselosztási költségek növekednek, ha nagyobb számú példányt kell felügyelni.
• Lemeztároló. Ha vannak állapotalapú alkalmazások, több példányhoz több csatlakoztatott felügyelt lemezre van szükség, ami növeli a tárolási költségeket.

Tekintse meg a well-architected keretrendszert: CO:12 – Javaslatok a skálázási költségek optimalizálására.

Működési költségek

Az automatikus virtuálisgép-vendégjavítás csökkenti a manuális javítás és a kapcsolódó karbantartási költségek többletterhelését. Ez a művelet nemcsak a rendszer biztonságát teszi biztonságosabbá, hanem optimalizálja az erőforrás-lefoglalást is, hozzájárulva az általános költséghatékonysághoz.

Lásd: Well-Architected Framework: CO:13 – Javaslatok a személyzeti idő optimalizálására.

A forgatókönyv üzembe helyezése

Ennek a referenciaarchitektúrának egy üzemelő példánya elérhető a GitHubon.

Kapcsolódó erőforrások

Az egyes Azure-szolgáltatások részletes leírását a termékdokumentációban találja:

• Azure Virtual Machines
• Azure Virtual Machine Scale Sets
• Azure Virtual Network
• Azure-alkalmazás átjáró Standard_v2
• Azure Load Balancer
• Azure Key Vault
• Azure Bastion
• Application Insights
• Naplóelemzés

Következő lépés

Tekintse át az IaaS referenciaarchitektúráit, amelyek az adatszint beállításait mutatják be:

• Windows N szintű alkalmazás az Azure-beli SQL Server használatával