Számos módon mérlegelheti, hogyan dolgozhat a bérlőkkel a megoldásban. Az Ön által választott megközelítés jelentősen függ attól, hogy megosztja-e az erőforrásokat a bérlők között, és hogyan. Intuitív módon előfordulhat, hogy el szeretné kerülni az erőforrások megosztását , de ez a megközelítés gyorsan költségessé válik az üzleti skálázás és a további bérlők előkészítésekor.
Ha figyelembe veszi a több-bérlős modelleket, érdemes először figyelembe vennie, hogyan határozza meg a bérlőket a szervezet számára, mik az üzleti illesztőprogramok, és hogyan tervezi skálázni a megoldást. Ez a cikk útmutatást nyújt a műszaki döntéshozóknak a bérlői modellek és azok kompromisszumainak értékeléséhez.
Bérlő definiálása
Először meg kell határoznia egy bérlőt a szervezet számára. Gondolja át, hogy ki az ügyfele. Más szóval, kinek nyújtja a szolgáltatásait? Két gyakori modell létezik:
- Vállalatoknak (B2B). Ha az ügyfelek más szervezetek, akkor valószínű, hogy leképezi a bérlőket ezekre az ügyfelekre. Fontolja meg azonban, hogy az ügyfelek rendelkeznek-e részlegekkel (csapatokkal vagy részlegekkel), és hogy több országban/régióban is jelen vannak-e. Előfordulhat, hogy egyetlen ügyfelet több bérlőhöz kell hozzárendelnie, ha ezekre az alcsoportokra különböző követelmények vonatkoznak. Hasonlóképpen előfordulhat, hogy az ügyfél a szolgáltatás két példányát szeretné fenntartani, hogy a fejlesztési és éles környezeteik elkülönüljenek egymástól. Általában egyetlen bérlő több felhasználóval rendelkezik. Az ügyfél összes alkalmazottja például egyetlen bérlőn belül lesznek felhasználók.
- Vállalatoktól a fogyasztókig (B2C). Ha az ügyfelek fogyasztók, gyakran bonyolultabb az ügyfelek, a bérlők és a felhasználók összekapcsolása. Bizonyos esetekben az egyes fogyasztók külön bérlők lehetnek. Fontolja meg azonban, hogy a megoldást használhatják-e családok, baráti csoportok, klubok, egyesületek vagy más csoportok, amelyeknek együtt kell hozzáférniük és kezelniük az adataikat. Egy zenestreamelési szolgáltatás például az egyes felhasználókat és családokat is támogathatja, és az egyes fióktípusokat eltérően kezelheti, ha bérlőkre bontja őket.
A bérlő definíciója hatással lesz néhány olyan dologra, amelyet figyelembe kell vennie vagy hangsúlyoznia kell a megoldás létrehozásakor. Vegyük például az alábbi bérlőtípusokat:
- Ha a bérlők egyéni személyek vagy családok, akkor lehet, hogy különösen aggódnia kell a személyes adatok kezelésével, valamint az egyes joghatóságokon belüli, az adatok szuverenitására vonatkozó jogszabályokkal kapcsolatban.
- Ha a bérlők üzleti jellegűek, előfordulhat, hogy figyelembe kell vennie az ügyfelek jogszabályi megfelelőségre vonatkozó követelményeit, az adataik elkülönítését, és gondoskodnia kell arról, hogy megfeleljen egy meghatározott szolgáltatásiszint-célkitűzésnek (SLO), például az üzemidőnek vagy a szolgáltatás rendelkezésre állásának.
Hogyan dönti el, hogy melyik modellt használja?
A bérlői modell kiválasztása nem csupán technikai döntés. Ez egy kereskedelmi döntés is. Az alábbihoz hasonló kérdéseket kell figyelembe vennie:
- Mik az üzleti céljai?
- Az ügyfelek elfogadják a több-bérlősség minden formáját? Hogyan befolyásolják az egyes több-bérlős modellek a megfelelőségi követelményeket vagy az ügyfél megfelelőségi követelményeit?
- Egy egybérlős megoldás skálázható a jövőbeli növekedési törekvésekhez?
- Mekkora az üzemeltetési csapat, és mekkora az infrastruktúra-kezelés automatizálható?
- Elvárják az ügyfelek, hogy teljesítsen szolgáltatási szintű szerződéseket (SLA-kat), vagy rendelkezik olyan SLO-kkal, amelyekre ön törekszik?
Ha arra számít, hogy vállalata nagy számú ügyfélre skáláz, fontos a megosztott infrastruktúra üzembe helyezése. Ellenkező esetben a példányok nagy és növekvő flottáját kell fenntartania. Az egyes azure-erőforrások üzembe helyezése az egyes ügyfelek számára valószínűleg nem fenntartható, kivéve, ha minden bérlőhöz külön előfizetést épít ki és használ. Ha ugyanazt az Azure-előfizetést több bérlőn is megosztja, az Azure-erőforráskvóták és -korlátozások alkalmazása elkezdődhet, és az erőforrások üzembe helyezésének és újrakonfigurálásához szükséges üzemeltetési költségek minden új ügyfélnél megnőnek.
Ezzel szemben, ha arra számít, hogy a vállalat csak néhány ügyféllel rendelkezik, érdemes lehet egy bérlős erőforrásokat használni, amelyek minden ügyfél számára dedikáltak. Emellett, ha az ügyfelek elkülönítési követelményei magasak, egy bérlős infrastruktúra is megfelelő lehet.
Bérlők és üzemelő példányok
Ezután meg kell határoznia, hogy mit jelent a bérlő az adott megoldáshoz, és meg kell-e különböztetnie a logikai bérlőket és az üzembe helyezéseket.
Vegyük például egy zenestreamelési szolgáltatást. Kezdetben olyan megoldást hozhat létre, amely több ezer felhasználót (vagy akár több tízezer felhasználót) képes kezelni. A növekedés folytatása során azonban előfordulhat, hogy meg kell duplikálnia a megoldást vagy annak egyes összetevőit az új ügyféligényre való skálázáshoz. Ez azt jelenti, hogy meg kell határoznia, hogyan rendelhet hozzá adott ügyfeleket a megoldás adott példányaihoz. Előfordulhat, hogy az ügyfeleket véletlenszerűen vagy földrajzilag rendeli hozzá, vagy egy példány kitöltésével, majd egy másik példány elindításával. Azonban valószínűleg nyilván kell tartania az ügyfeleket, és hogy milyen infrastruktúrán érhetők el adataik és alkalmazásaik, hogy a forgalmat a megfelelő infrastruktúrába irányíthassa. Ebben a példában minden ügyfelet külön bérlőként jelölhet, majd leképezheti a felhasználókat az adatokat tartalmazó üzembe helyezésre. Egy-a-többhöz leképezéssel rendelkezik a bérlők és az üzemelő példányok között, és saját belátása szerint áthelyezheti a bérlőket az üzemelő példányok között.
Ezzel szemben érdemes lehet egy olyan vállalatot is figyelembe venni, amely felhőszoftvereket hoz létre a jogi cégek számára. Előfordulhat, hogy az ügyfelek ragaszkodnak a saját dedikált infrastruktúrájukhoz a megfelelőségi szabványok fenntartása érdekében. Ezért a kezdetektől fel kell készülnie a megoldás számos különböző példányának üzembe helyezésére és kezelésére. Ebben a példában az üzemelő példányok mindig egyetlen bérlőt tartalmaznak, a bérlők pedig a saját dedikált üzemelő példányukhoz lesznek leképezve.
A bérlők és az üzemelő példányok közötti fő különbség az elkülönítés kényszerítése. Ha több bérlő osztozik egyetlen üzemelő példányon (egy infrastruktúra-készleten), általában az alkalmazáskódra és egy adatbázisban található bérlőazonosítóra támaszkodik, hogy az egyes bérlők adatai külön maradjanak. Ha a bérlők saját dedikált üzemelő példányokkal rendelkeznek, a saját infrastruktúrájukkal rendelkeznek, így kevésbé fontos, hogy a kód tisztában legyen azzal, hogy több-bérlős környezetben működik.
Az üzemelő példányokat néha felügyelőknek vagy bélyegeknek is nevezik.
Amikor egy adott bérlőre vonatkozó kérelmet kap, le kell képeznie azt a bérlő adatait tartalmazó üzemelő példányra, az itt látható módon:
Bérlők elkülönítése
A több-bérlős architektúra kialakításának egyik legnagyobb szempontja az egyes bérlők által igényelt elkülönítési szint. Az elkülönítés különböző dolgokat jelenthet:
- Egyetlen megosztott infrastruktúrával rendelkezik, amely az alkalmazás különálló példányaival és az egyes bérlőkhöz tartozó különálló adatbázisokkal rendelkezik.
- Egyes gyakori erőforrások megosztása, de a többi erőforrás külön tartása az egyes bérlők számára.
- Adatok megőrzése külön fizikai infrastruktúrán. A felhőben ez a konfiguráció minden bérlőhöz külön Azure-erőforrásokat igényelhet. Akár külön fizikai infrastruktúra üzembe helyezését is jelentheti dedikált gazdagépek használatával.
Ahelyett, hogy különálló tulajdonságként tekintenél az elkülönítésre, úgy kell gondolnod rá, mint egy continuumra. Az architektúra olyan összetevőit is üzembe helyezheti, amelyek többé-kevésbé elszigeteltek, mint ugyanazon architektúra más összetevői, a követelményektől függően. Az alábbi ábra az elkülönítés kontinuumát mutatja be:
Az elkülönítés szintje az architektúra számos aspektusát érinti, többek között a következőket:
- Biztonság Ha több bérlő között oszt meg infrastruktúrát, különösen ügyeljen arra, hogy ne férhessen hozzá az egyik bérlő adataihoz, amikor válaszokat ad vissza egy másiknak. Erős alapra van szüksége az identitásstratégiához, és figyelembe kell vennie a bérlői és a felhasználói identitást is az engedélyezési folyamat során.
- Költségek. A megosztott infrastruktúrát több bérlő is használhatja, így kevésbé költséges.
- Teljesítmény. Ha megosztja az infrastruktúrát, a rendszer teljesítménye szenvedhet, mivel több ügyfél használja, mert az erőforrások gyorsabban lesznek felhasználva.
- Megbízhatóság. Ha egyetlen megosztott infrastruktúrát használ, az egyik bérlő összetevőivel kapcsolatos probléma mindenki számára kimaradáshoz vezethet.
- Válaszkészség az egyes bérlői igényekre. Ha egy bérlő számára dedikált infrastruktúrát helyez üzembe, előfordulhat, hogy az erőforrások konfigurációját az adott bérlő igényeihez igazítja. Akár a díjszabási modellben is megfontolhatja ezt a képességet, így az ügyfelek többet fizethetnek az elkülönített üzemelő példányokért.
A megoldásarchitektúra befolyásolhatja a rendelkezésre álló elkülönítési lehetőségeket. Vegyük például egy háromrétegű megoldásarchitektúrát:
- Előfordulhat, hogy a felhasználói felület szintje egy megosztott több-bérlős webalkalmazás, amelynek minden bérlője egyetlen gazdagépnevet ér el.
- A középső réteg egy megosztott alkalmazásréteg lehet, megosztott üzenetsorokkal.
- Az adatszint különálló adatbázisok, táblák vagy blobtárolók lehetnek.
Érdemes lehet különböző elkülönítési szinteket használni az egyes szinteken. A megosztott tartalmakról és az elkülönített szolgáltatásokról számos szempont alapján kell döntenie, beleértve a költségeket, az összetettségeket, az ügyfelek igényeit és az Üzembe helyezhető erőforrások számát az Azure-kvóták és korlátok elérése előtt.
Gyakori bérlői modellek
Miután meghatározta a követelményeket, értékelje ki őket néhány gyakori bérlői modell és a megfelelő üzembehelyezési minták alapján.
Automatizált egybérlős üzemelő példányok
Egy automatizált egybérlős üzembehelyezési modellben minden bérlőhöz külön infrastruktúra-készletet helyez üzembe, az alábbi példában látható módon:
Az alkalmazás felelős az egyes bérlői erőforrások üzembe helyezésének kezdeményezéséért és koordinálásáért. Az ezt a modellt használó megoldások általában az infrastruktúrát használják kódként (IaC) vagy az Azure Resource Manager API-kat. Ezt a módszert akkor használhatja, ha minden ügyfél számára teljesen különálló infrastruktúrát kell kiépítenie. Az üzembe helyezés megtervezésekor vegye figyelembe az Üzembe helyezési bélyegek mintát .
Előnyök: Ennek a megközelítésnek az egyik fő előnye, hogy az egyes bérlők adatai elkülönítve lesznek, ami csökkenti a véletlen szivárgás kockázatát. Ez a védelem fontos lehet néhány olyan ügyfél számára, aki magas szabályozási megfelelőségi többletterheléssel rendelkezik. Emellett a bérlők valószínűleg nem befolyásolják egymás rendszerteljesítményét, ezt a problémát néha zajos szomszéd problémának is nevezik. Frissítések és módosításokat fokozatosan lehet végrehajtani a bérlők között, ami csökkenti a rendszerszintű kimaradás valószínűségét.
Kockázatok: Ha ezt a módszert használja, a költséghatékonyság alacsony, mert nem osztja meg az infrastruktúrát a bérlők között. Ha egy bérlőnek bizonyos infrastrukturális költségekre van szüksége, 100 bérlőnek valószínűleg a költség 100-szorosára van szüksége. Emellett a folyamatos karbantartás (például új konfiguráció vagy szoftverfrissítések alkalmazása) valószínűleg időigényes lesz. Fontolja meg az üzemeltetési folyamatok automatizálását, és fontolja meg a módosítások fokozatos alkalmazását a környezeteken keresztül. Egyéb üzembehelyezési műveleteket is érdemes megfontolnia, például a teljes tulajdonban lévő jelentéskészítést és elemzést. Hasonlóképpen, mindenképpen tervezze meg, hogyan kérdezhet le és kezelhet adatokat több üzemelő példányban.
Teljes mértékben több-bérlős üzemelő példányok
Ellenkező esetben egy teljesen több-bérlős üzembe helyezést is figyelembe vehet, ahol az összes összetevő meg van osztva. Csak egy infrastruktúrával rendelkezik az üzembe helyezéshez és karbantartáshoz, és az összes bérlő használja azt az alábbi ábrán látható módon:
Előnyök: Ez a modell azért vonzó, mert a megosztott összetevőkkel rendelkező megoldások üzemeltetése kevésbé költséges. Még ha magasabb szintű vagy erőforrás-termékváltozatokat is üzembe kell helyeznie, a teljes üzembehelyezési költség gyakran még mindig alacsonyabb, mint az egybérlős erőforrások egy készletének költsége. Emellett ha egy felhasználónak vagy bérlőnek át kell helyeznie az adatait egy másik bérlőbe, előfordulhat, hogy frissítheti a bérlőazonosítókat és a kulcsokat, és előfordulhat, hogy nem kell adatokat migrálnia két különálló üzemelő példány között.
Kockázatok:
Mindenképpen különítse el az egyes bérlők adatait, és ne szivárogtassa ki az adatokat a bérlők között. Előfordulhat, hogy horizontálisan skálázási adatokat kell kezelnie. Emellett előfordulhat, hogy az egyes bérlőknek a teljes rendszerre gyakorolt hatásai miatt is aggódnia kell. Ha például egy nagy bérlő nehéz lekérdezést vagy műveletet próbál végrehajtani, az más bérlőket is érinthet.
Határozza meg, hogyan követheti nyomon és társíthatja azure-költségeit a bérlőkhöz, ha ez fontos Önnek.
A karbantartás egyszerűbb lehet egyetlen üzemelő példány esetén, mert csak egy erőforráskészletet kell frissítenie. Ez azonban gyakran kockázatosabb is, mert a módosítások hatással lehetnek a teljes ügyfélkörre.
Előfordulhat, hogy a skálázást is figyelembe kell vennie. Nagyobb valószínűséggel éri el az Azure erőforrás-méretezési korlátait , ha megosztott infrastruktúrakészlettel rendelkezik. Ha például a megoldás részeként tárfiókot használ, a méret növekedésével a tárfiókra irányuló kérések száma elérheti a tárfiók által kezelhető korlátot. Az erőforráskvótakorlát elérésének elkerülése érdekében fontolja meg az erőforrások több példányának (például több AKS-fürt vagy tárfiók) üzembe helyezését. Akár több Azure-előfizetésben üzembe helyezhető erőforrások között is eloszthatja a bérlőket.
Valószínűleg korlátozva van, hogy milyen messzire skálázhat egy üzembe helyezést, és ennek költségei nem lineárisan növekedhetnek. Ha például egyetlen megosztott adatbázissal rendelkezik, amikor nagyon nagy léptékben fut, előfordulhat, hogy kimeríti az átviteli sebességet, és egyre többet kell fizetnie a megnövekedett átviteli sebességért, hogy lépést tartson az igényeivel.
Függőlegesen particionált üzemelő példányok
Nem kell a mérlegek egyik végletét választania. Ehelyett fontolja meg a bérlők vertikális particionálását a következő megközelítéssel:
- Használja az egybérlős és a több-bérlős üzemelő példányok kombinációját. Előfordulhat például, hogy az ügyfelek legtöbb adat- és alkalmazásszintje több-bérlős infrastruktúrákon van, de egybérlős infrastruktúrát helyez üzembe a nagyobb teljesítményt vagy adatelkülönítést igénylő ügyfelek számára.
- Helyezze üzembe a megoldás több példányát földrajzilag, és képezheti le az egyes bérlőket egy adott üzembe helyezésre. Ez a megközelítés különösen akkor hatékony, ha a bérlők különböző földrajzi helyeken vannak.
Íme egy példa, amely egy megosztott üzembe helyezést mutat be egyes bérlők esetében, és egy egy-bérlős üzembe helyezést egy másikhoz:
Előnyök: Mivel továbbra is megosztja az infrastruktúrát, a megosztott több-bérlős üzemelő példányok használatának néhány költségelőnyét élvezheti. Olcsóbb megosztott erőforrásokat helyezhet üzembe bizonyos ügyfelek számára, például azokat az ügyfeleket, akik próbaverzióval értékelik a szolgáltatást. Akár magasabb díjakat is kiszámlázhat az ügyfeleknek az egybérlős üzemelő példányok használatához, így meg kell fizetnie a költségek egy részét.
Kockázatok: A kódbázist valószínűleg úgy kell megtervezni, hogy támogassa a több-bérlős és az egybérlős üzemelő példányokat is. Ha azt tervezi, hogy engedélyezi az infrastruktúra közötti migrálást, meg kell fontolnia, hogyan migrálhatja az ügyfeleket egy több-bérlős üzemelő példányból a saját egybérlős üzemelő példányukba. Azt is tudnia kell, hogy a bérlők közül melyik található az egyes üzemelő példányokon, hogy a rendszerproblémákkal vagy a frissítésekkel kapcsolatos információkat közölhesse az érintett ügyfelekkel.
Horizontálisan particionált üzemelő példányok
Megfontolhatja az üzemelő példányok horizontális particionálását is. Vízszintes üzembe helyezés esetén rendelkezik néhány megosztott összetevővel, de más összetevőket is fenntart egybérlős üzemelő példányokkal. Létrehozhat például egyetlen alkalmazásszintet, majd üzembe helyezheti az egyes bérlőkhöz tartozó különálló adatbázisokat az alábbi ábrán látható módon:
Előnyök: A horizontálisan particionált üzemelő példányok segíthetnek elhárítani a zajos szomszédokkal kapcsolatos problémákat, ha azt állapítja meg, hogy a rendszer terhelésének nagy részét az egyes bérlőkhöz külön üzembe helyezhető összetevők okozzák. Előfordulhat például, hogy az adatbázisok elnyelik a rendszer terhelésének nagy részét, mert a lekérdezési terhelés magas. Ha egyetlen bérlő nagyszámú kérést küld a megoldásnak, előfordulhat, hogy az adatbázis teljesítménye negatívan hat, de más bérlők adatbázisai (és a megosztott összetevők, például az alkalmazásszint) nem lesznek hatással.
Kockázatok: Vízszintesen particionált üzembe helyezés esetén továbbra is figyelembe kell vennie az összetevők automatizált üzembe helyezését és kezelését, különösen az egyetlen bérlő által használt összetevőket.
Az elkülönítési modell tesztelése
Bármelyik elkülönítési modellt választja, mindenképpen tesztelje a megoldást annak ellenőrzéséhez, hogy az egyik bérlő adatai véletlenül kiszivárogtak-e egy másikba, és hogy a zajos szomszédhatások elfogadhatók-e. Fontolja meg az Azure Chaos Studio használatát, hogy szándékosan olyan hibákat vezessen be, amelyek valós kimaradásokat szimulálnak, és ellenőrizze a megoldás rugalmasságát még akkor is, ha az összetevők meghibásodnak.
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ő:
- John Downs | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
Egyéb közreműködők:
- Chad Kittel | Vezető szoftvermérnök
- Paolo Salvatori | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
- Arsen Vladimirskiy | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.
Következő lépések
Fontolja meg a bérlők életciklusát