Ez a referenciaarchitektúra bemutatja, hogyan helyezhet üzembe virtuális gépeket (virtuális gépeket) és egy N szintű alkalmazáshoz konfigurált virtuális hálózatot az adatszinthez linuxos Apache Cassandra használatával.
Felépítés
Töltse le az architektúra Visio-fájlját.
Munkafolyamat
Az architektúra a következő összetevőket tartalmazza.
General
Erőforráscsoport. Az erőforráscsoportok az Azure-erőforrások csoportosítására szolgálnak, így azok az élettartam, a tulajdonos vagy más feltételek szerint kezelhetők.
Rendelkezésre állási zónák. A rendelkezésre állási zónák fizikai helyek egy Azure-régión belül. Minden zóna egy vagy több, független energiaellátással, hűtéssel és hálózatkezeléssel rendelkező adatközpontból áll. A virtuális gépek zónák közötti elhelyezésével az alkalmazás ellenállóbbá válik a zónán belüli hibákkal szemben.
Hálózatkezelés és terheléselosztás
Virtuális hálózat és alhálózatok. Minden Azure-beli virtuális gép egy olyan virtuális hálózatba van üzembe helyezve, amely alhálózatokra szegmentelhető. Hozzon létre egy külön alhálózatot minden egyes szinthez.
Application Gateway. Az Application Gateway egy 7. rétegbeli terheléselosztó. Ebben az architektúrában a HTTP-kéréseket a webes előtérre irányítja. Az Application Gateway egy webalkalmazási tűzfalat (WAF) is biztosít, amely megvédi az alkalmazást a gyakori biztonsági résektől és biztonsági résektől.
Terheléselosztók. Az Azure Standard Load Balancer használatával eloszthatja a hálózati forgalmat a webes szintről az üzleti szintre.
Hálózati biztonsági csoportok (NSG-k). Az NSG-k használatával korlátozhatja a virtuális hálózaton belüli hálózati forgalmat. Az itt látható háromrétegű architektúrában például az adatbázisszint nem fogadja el a webes előtérbeli forgalmat, csak az üzleti szintről és a felügyeleti alhálózatról.
DDoS Protection. Bár az Azure platform alapvető védelmet nyújt az elosztott szolgáltatásmegtagadási (DDoS) támadások ellen, javasoljuk az Azure DDoS Network Protection használatát, amely továbbfejlesztett DDoS-kockázatcsökkentési funkciókkal rendelkezik. Tekintse meg a biztonsági szempontokat.
Azure DNS. Az Azure DNS a DNS-tartományokhoz használható üzemeltetési szolgáltatás. A Microsoft Azure-infrastruktúrával biztosít névfeloldást. Ha tartományait az Azure-ban üzemelteti, DNS-rekordjait a többi Azure-szolgáltatáshoz is használt hitelesítő adatokkal, API-kkal, eszközökkel és számlázási információkkal kezelheti.
Virtual machines
Apache Cassandra-adatbázis. Magas rendelkezésre állást biztosít az adatszinten a replikáció és a feladatátvétel engedélyezésével.
OpsCenter. Helyezzen üzembe egy monitorozási megoldást, például a DataStax OpsCentert a Cassandra-fürt figyeléséhez.
Jumpbox. Más néven bástyagazdagép. A hálózaton található biztonságos virtuális gép, amelyet a rendszergazdák a többi virtuális géphez való kapcsolódásra használnak. A jumpbox olyan NSG-vel rendelkezik, amely csak a biztonságos elemek listáján szereplő nyilvános IP-címekről érkező távoli forgalmat engedélyezi. Az NSG-nek engedélyeznie kell a távoli asztali (RDP) forgalmat.
Javaslatok
Az Ön követelményei eltérhetnek az itt leírt architektúrától. Ezeket a javaslatokat tekintse kiindulópontnak.
Virtual machines
A virtuális gépek konfigurálásával kapcsolatos javaslatokért lásd : Linux rendszerű virtuális gép futtatása az Azure-ban.
Virtuális hálózat
A virtuális hálózat létrehozásakor határozza meg, hogy hány IP-cím szükséges az egyes alhálózatokban lévő erőforrásokhoz. Adjon meg egy alhálózati maszkot és egy olyan hálózati címtartományt, amely elég nagy a szükséges IP-címekhez ciDR-jelöléssel. Használjon a szabványos magánhálózati IP-címblokkokba eső címterületet. Ezek az IP-címblokkok a következők: 10.0.0.0/8, 172.16.0.0/12 és 192.168.0.0/16.
Válasszon ki egy olyan címtartományt, amely nem fedi egymást a helyszíni hálózattal, ha később be kell állítania egy átjárót a virtuális hálózat és a helyszíni hálózat között. A virtuális hálózat létrehozása után a címtartomány nem módosítható.
Az alhálózatokat a funkciók és a biztonsági követelmények szem előtt tartásával tervezze meg. Minden ugyanazon szinthez vagy szerepkörhöz tartozó virtuális gépnek egyazon alhálózaton kell lennie. Ez az alhálózat biztonsági korlátot is képezhet. A virtuális hálózatok és alhálózatok megtervezésével kapcsolatos további információkért lásd az Azure-beli virtuális hálózatok tervezésével és kialakításával foglalkozó témakört.
Application Gateway
Az Application Gateway konfigurálásával kapcsolatos információkért tekintse meg az Application Gateway konfigurációjának áttekintését.
Terheléselosztók
Ne tegye közzé a virtuális gépeket közvetlenül az interneten. Ehelyett adjon meg minden virtuális gépnek egy privát IP-címet. Az ügyfelek az Application Gatewayhez társított IP-címmel csatlakoznak.
Adja meg a terheléselosztó a virtuális gépek felé irányuló közvetlen hálózati forgalomra vonatkozó szabályait. Például a HTTP-forgalom engedélyezéséhez hozzon létre egy szabályt, amely hozzárendeli a 80-as portot az előtérbeli konfigurációból a háttércímkészletben található 80-as porthoz. Amikor egy ügyfél HTTP-kérelmet küld a 80-as port felé, a terheléselosztó kiválaszt egy háttérbeli IP-címet egy kivonatoló algoritmus használatával, amely tartalmazza a forrás IP-címét. Az ügyfélkérések az összes virtuális gépen el vannak osztva.
Network security groups
A szintek közötti forgalmat NSG-szabályokkal korlátozhatja. A fent látható háromrétegű architektúrában például a webes réteg nem kommunikál közvetlenül az adatbázisszinttel. Ennek kényszerítése érdekében az adatbázisszintnek blokkolnia kell a webes szint alhálózatáról érkező bejövő forgalmat.
- Tiltsa le a virtuális hálózatról érkező összes bejövő forgalmat. (A szabályban használja a
VIRTUAL_NETWORKcímkét.) - Engedélyezze a bejövő forgalmat az üzleti szintű alhálózatról.
- Engedélyezze a bejövő forgalmat magáról az adatbázisszintű alhálózatról. Ez a szabály lehetővé teszi az adatbázis virtuális gépei közötti kommunikációt, amely az adatbázis-replikációhoz és a feladatátvételhez szükséges.
- Engedélyezze az ssh-forgalmat (22-s port) a jumpbox alhálózatából. Ez lehetővé teszi, hogy a rendszergazdák csatlakozni tudjanak az adatbázisszinthez a jumpboxból.
Hozzon létre 2– 4. szabályt az első szabálynál magasabb prioritással, ezért felülbírálják.
Cassandra
Éles környezetben ajánlott a DataStax Enterprise használata, de ezek a javaslatok bármely Cassandra-kiadásra is vonatkoznak. További információk a DataStax futtatásáról az Azure-ban: A DataStax Enterprise üzembehelyezési útmutatója az Azure-hoz.
Konfigurálja a csomópontokat állvány-kompatibilis üzemmódban. Képezze le a tartalék tartományokat állványokra a cassandra-rackdc.properties fájlban.
A fürt előtt nincs szükség terheléselosztóra. Az ügyfél közvetlenül csatlakozik a fürt egyik csomópontjához.
Az architektúra üzembehelyezési szkriptjei névfeloldás használatával inicializálják a magcsomópontot a fürtön belüli kommunikációhoz (pletyka). A névfeloldás engedélyezéséhez az üzembe helyezés létrehoz egy Azure saját DNS zónát a Cassandra-csomópontok A rekordjaival. Az inicializálási parancsfájloktól függően előfordulhat, hogy használhatja inkább a statikus IP-címet.
Megjegyzés:
Az Azure saját DNS jelenleg nyilvános előzetes verzióban érhető el.
Jumpbox
Ne engedélyezze az ssh-hozzáférést a nyilvános internetről az alkalmazás számítási feladatát futtató virtuális gépekhez. Ehelyett ezeknek a virtuális gépeknek az összes ssh-hozzáférésének a jumpboxon keresztül kell érkeznie. A rendszergazda először bejelentkezik a jumpboxba, majd azon keresztül bejelentkezik a többi virtuális gépbe. A jumpbox lehetővé teszi az ssh-forgalmat az internetről, de csak ismert, biztonságos IP-címekről.
A jumpbox minimális teljesítménnyel rendelkezik, ezért válasszon egy kis méretű virtuális gépet. Hozzon létre egy nyilvános IP-címet a jumpbox számára. Helyezze a jumpboxot a többi virtuális géppel megegyező virtuális hálózatba, de egy külön felügyeleti alhálózaton legyen.
A jumpbox védelméhez adjon hozzá egy NSG-szabályt, amely csak nyilvános IP-címek biztonságos készletéből engedélyezi az ssh-kapcsolatokat. Konfigurálja a többi alhálózat NSG-jét, hogy engedélyezze a felügyeleti alhálózatról érkező ssh-forgalmat.
Considerations
Méretezhetőség
Méretezési csoportok
A webes és az üzleti szintek esetében fontolja meg a virtuálisgép-méretezési csoportok használatát ahelyett, hogy különálló virtuális gépeket helyez üzembe egy rendelkezésre állási csoportban. A méretezési csoportok megkönnyítik az azonos virtuális gépek halmazának üzembe helyezését és kezelését, valamint a virtuális gépek automatikus méretezését a teljesítménymetrikák alapján. Ahogy a terhelés növekszik a virtuális gépeken, a rendszer további virtuális gépeket ad a terheléselosztóhoz.
A méretezési csoportokban üzembe helyezett virtuális gépek konfigurálásának két alapvető módja van:
Bővítmények használatával konfigurálhatja a virtuális gépet az üzembe helyezés után. Ezzel a módszerrel az új virtuálisgép-példányok indítása több időt vehet igénybe, mint a bővítmények nélküli virtuális gépeké.
Üzembe helyezhet egy felügyelt lemezt egy egyéni rendszerképpel. Ez a módszer gyorsabban kivitelezhető. Ehhez azonban naprakészen kell tartania a képet.
További információ: Méretezési csoportok tervezési szempontjai.
Tipp.
Bármilyen automatikus méretezési megoldás használata esetén jóval előre tesztelje azt az éles környezetre jellemző mennyiségű számítási feladattal.
Előfizetés korlátai
Minden Azure-előfizetésre alapértelmezett korlátozások vonatkoznak. Ilyen például a régiónként alkalmazható virtuális gépek maximális száma. Támogatási kérelem kitöltésével megnövelheti ezt a korlátot. További információk: Az Azure-előfizetésekre és -szolgáltatásokra vonatkozó korlátozások, kvóták és megkötések.
Application Gateway
Az Application Gateway támogatja a rögzített kapacitásmódot vagy az automatikus skálázási módot. A rögzített kapacitású mód az olyan forgatókönyvek esetén hasznos, amelyek konzisztens és kiszámítható számítási feladatokat alkalmaznak. Fontolja meg az automatikus skálázási módot változó forgalommal rendelkező számítási feladatokhoz. További információ: Automatikus skálázás és zónaredundáns Application Gateway v2.
Teljesítmény hatékonysága
Az Azure-beli virtuális gépeken futó Cassandra legjobb teljesítményéhez tekintse meg az Apache Cassandra Azure-beli virtuális gépeken való futtatásával kapcsolatos javaslatokat.
Elérhetőség
A rendelkezésre állási zónák egyetlen régióban biztosítják a legjobb rugalmasságot. Ha még magasabb rendelkezésre állásra van szüksége, fontolja meg az alkalmazás replikálását két régióban.
Nem minden régió támogatja a rendelkezésre állási zónákat, és nem minden virtuálisgép-méret támogatott minden zónában. Futtassa a következő Azure CLI-parancsot az egyes virtuálisgép-méretek támogatott zónáinak régión belüli megkereséséhez:
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
Ha ezt az architektúrát olyan régióban helyezi üzembe, amely nem támogatja a rendelkezésre állási zónákat, helyezze az egyes szintek virtuális gépeit egy rendelkezésre állási csoportba. Az azonos rendelkezésre állású virtuális gépeket több fizikai kiszolgálóra, számítási állványra, tárolóegységre és hálózati kapcsolóra helyezik üzembe a redundancia érdekében. A méretezési csoportok automatikusan elhelyezési csoportokat használnak, amelyek implicit rendelkezésre állási csoportként működnek.
A rendelkezésre állási zónákban való üzembe helyezéskor használja az Azure Load Balancer standard termékváltozatát és az Application Gateway v2 termékváltozatát. Ezek az SKU-k támogatják a zónák közötti redundanciát. For more information, see:
- A Standard Load Balancer és a rendelkezésre állási zónák
- Automatikusan skálázó és zónaredundáns Application Gateway v2
- Hogyan támogatja az Application Gateway a magas rendelkezésre állást és a méretezhetőséget?
Egyetlen Application Gateway-üzembe helyezés az átjáró több példányát is futtathatja. Éles számítási feladatok esetén futtasson legalább két példányt.
Cassandra-fürt
A Cassandra-fürt esetében a feladatátvételi forgatókönyvek az alkalmazás által használt konzisztenciaszinttől és a replikák számától függenek. A Cassandra konzisztenciaszintjeit és használatát az adatkonzisztencia és a Cassandra konfigurálásával kapcsolatban olvassa el: Hány csomóponttal beszél a rendszer a Kvórum használatával? A Cassandra adatainak rendelkezésre állását az alkalmazás és a replikációs mechanizmus által használt konzisztenciaszint határozza meg. További információ a replikációról a Cassandrában: Adatok replikációja a NoSQL-adatbázisokban – Ismertetés.
Állapotminták
Az Application Gateway és a Load Balancer egyaránt állapottesztekkel figyeli a virtuálisgép-példányok rendelkezésre állását.
- Az Application Gateway mindig HTTP-mintavételt használ.
- A Load Balancer HTTP-t vagy TCP-t is tesztelhet. Ha egy virtuális gép HTTP-kiszolgálót futtat, használjon HTTP-mintavételt. Ellenkező esetben használja a TCP protokollt.
Ha egy mintavétel egy időtúllépési időszakon belül nem tud elérni egy példányt, az átjáró vagy a terheléselosztó leállítja a forgalom küldését az adott virtuális gépre. A mintavétel továbbra is ellenőrzi a virtuális gépet, és visszaadja a háttérkészletnek, ha a virtuális gép ismét elérhetővé válik.
A HTTP-mintavételek HTTP GET-kérést küldenek egy megadott elérési útra, és HTTP 200-választ figyelnek. Ez az elérési út lehet a gyökérútvonal ("/"), vagy egy állapotfigyelési végpont, amely egyéni logikát implementál az alkalmazás állapotának ellenőrzéséhez. A végpontnak engedélyeznie kell a névtelen HTTP-kérelmeket.
Az állapotadat-mintavételekkel kapcsolatos további információkért lásd:
Az állapotadat-mintavételi végpont tervezésével kapcsolatos szempontokért tekintse meg az Állapotvégpont monitorozási mintáját.
Költségoptimalizálás
Az Azure díjszabási kalkulátorával megbecsüli a költségeket. Íme néhány egyéb szempont.
Virtuálisgép-méretezési csoportok
A virtuálisgép-méretezési csoportok minden Linux rendszerű virtuálisgép-méretben elérhetők. Csak az üzembe helyezett Azure-beli virtuális gépekért, valamint a mögöttes infrastruktúra által felhasznált erőforrások (például a tárhely és a hálózat) után számítunk fel díjat. Magáért a Virtual Machine Scale Sets szolgáltatásért külön díjat nem számítunk fel.
Az önálló virtuális gépek díjszabási lehetőségeiért lásd a Linux rendszerű virtuális gépek díjszabását.
Terheléselosztók
Csak a konfigurált terheléselosztási és kimenő szabályok számáért kell fizetnie. A bejövő NAT-szabályok ingyenesek. Magához a Standard Load Balancerhez nem számítunk fel óradíjat, ha nincsenek beállítva szabályok.
További információért lásd a Microsoft Azure Well-Architected Framework költségekkel kapcsolatos részét.
Biztonság
A virtuális hálózatok forgalomelkülönítési határok az Azure-ban. Az egyik virtuális hálózat virtuális gépei nem tudnak közvetlenül kommunikálni egy másik virtuális hálózat virtuális gépeivel. Az azonos virtuális hálózatban elhelyezkedő virtuális gépek képesek a kommunikációra, hacsak hálózati biztonsági csoportokat (NSG-ket) nem hoz létre a forgalom korlátozására. További információ: A Microsoft felhőszolgáltatásai és hálózati biztonság.
A bejövő internetes forgalom esetében a terheléselosztó szabályai határozzák meg, milyen forgalom érheti el a háttérrendszert. A terheléselosztó szabályai azonban nem támogatják a biztonságos IP-címek listázását, ezért ha fel kíván venni bizonyos nyilvános IP-címeket a biztonságos címek listájára, adjon hálózati biztonsági csoportot az alhálózathoz.
DMZ. Érdemes lehet hozzáadnia egy hálózati virtuális berendezést (network virtual appliance, NVA), hogy DMZ-t lehessen létrehozni az internet és az Azure-beli virtuális hálózat között. Az NVA egy általános kifejezés egy olyan virtuális berendezésre, amely hálózatokhoz kapcsolódó feladatokat lát el, például gondoskodik a tűzfalról, a csomagvizsgálatról, a naplózásról és az egyéni útválasztásról. További információkért lásd a DMZ az Azure és az internet közötti implementálásával foglalkozó témakört.
Titkosítás. Titkosíthatja az inaktív bizalmas adatokat, és az Azure Key Vaulttal kezelheti az adatbázis titkosítási kulcsait. A Key Vault képes a hardveres biztonsági modulok (HSM-ek) titkosítási kulcsainak tárolására. Azt is javasoljuk, hogy az alkalmazás titkos kulcsait, például az adatbázis-kapcsolati sztring tárolja a Key Vaultban.
DDoS-védelem. Az Azure platform alapértelmezés szerint alapvető DDoS-védelmet biztosít. Ez az alapszintű védelem az Azure-infrastruktúra egészének védelmét célozza. Bár az alapszintű DDoS-védelem automatikusan engedélyezve van, javasoljuk az Azure DDoS Network Protection használatát. A Network Protection az alkalmazás hálózati forgalmi mintái alapján adaptív hangolással észleli a fenyegetéseket. Ez lehetővé teszi, hogy az infrastruktúraszintű DDoS-szabályzatok által észrevétlenül végrehajtott DDoS-támadásokkal szemben kockázatcsökkentéseket alkalmazzon. A Network Protection riasztást, telemetriát és elemzést is biztosít az Azure Monitoron keresztül. További információ: Azure DDoS Protection: Ajánlott eljárások és referenciaarchitektúrák.
Működés eredményessége
Mivel az architektúra összes fő erőforrása és függősége ugyanabban a virtuális hálózatban található, ugyanabban az alapszintű számítási feladatban vannak elkülönítve. Ez a tény megkönnyíti a számítási feladat adott erőforrásainak társítását egy DevOps-csapathoz, hogy a csapat önállóan felügyelhesse az erőforrások minden aspektusát. Ez az elkülönítés lehetővé teszi a DevOps Teams és -szolgáltatások számára a folyamatos integrációt és a folyamatos teljesítést (CI/CD).
Emellett különböző üzembehelyezési sablonokat is használhat, és integrálhatja őket az Azure DevOps Services szolgáltatással a különböző környezetek percek alatt történő kiépítéséhez, például az éles környezetek, például forgatókönyvek replikálásához vagy a tesztelési környezetek betöltéséhez, ha szükséges, költségmegtakarítással.
Ebben a forgatókönyvben a virtuális gépek virtuálisgép-bővítmények használatával vannak konfigurálva, mivel lehetővé teszik bizonyos további szoftverek, például az Apache Cassandra telepítését. Az egyéni szkriptbővítmény lehetővé teszi tetszőleges kód letöltését és végrehajtását egy virtuális gépen, lehetővé téve az Azure-beli virtuális gépek operációs rendszerének korlátlan testreszabását. A virtuálisgép-bővítmények telepítése és végrehajtása csak a virtuális gép létrehozásakor történik. Ez azt jelenti, hogy ha az operációs rendszer egy későbbi szakaszban helytelenül lesz konfigurálva, manuális beavatkozásra lesz szükség ahhoz, hogy visszaállítsa a megfelelő állapotba. A konfigurációkezelési eszközök a probléma megoldására használhatók.
Érdemes az Azure Monitor használatával elemezni és optimalizálni az infrastruktúra teljesítményét, valamint monitorozni és diagnosztizálni a hálózati problémákat a virtuális gépekre való bejelentkezés nélkül. Az alkalmazás Elemzések valójában az Azure Monitor egyik összetevője, amely gazdag metrikákat és naplókat biztosít a teljes Azure-környezet állapotának ellenőrzéséhez. Az Azure Monitor segít követni az infrastruktúra állapotát.
Győződjön meg arról, hogy nem csak az alkalmazáskódot támogató számítási elemeket, hanem az adatplatformot is figyeli, különösen az adatbázisait, mivel az alkalmazás adatszintjének alacsony teljesítménye súlyos következményekkel járhat.
Annak az Azure-környezetnek a teszteléséhez, ahol az alkalmazások futnak, verzióalapúnak kell lennie, és az alkalmazáskóddal azonos mechanizmusokkal kell üzembe helyezni, majd a DevOps tesztelési paradigmáival is tesztelhető és érvényesíthető.
További információt a Microsoft Azure Well-Architecture Framework Operatív kiválóság című szakaszában talál.