Az adatokat gyakran a megoldások legértékesebb részének tekintik, mivel azok az Ön - és ügyfelei - értékes üzleti adatait képviselik. Ezért fontos, hogy gondosan kezelje az adatokat. A több-bérlős rendszerek tárolási vagy adatösszetevőinek tervezésekor a bérlők adatainak megosztására vagy elkülönítésére vonatkozó megközelítést kell választania.
Ebben a cikkben útmutatást nyújtunk a megoldástervezők számára nélkülözhetetlen legfontosabb szempontokról és követelményekről, amikor az adatok több-bérlős rendszerben való tárolásának megközelítéséről döntenek. Ezután javasolunk néhány gyakori mintát a több-bérlős tárolás és az adatszolgáltatások alkalmazásához, valamint néhány antipatterns elkerüléséhez. Végül célzott útmutatást adunk bizonyos helyzetekhez.
Főbb szempontok és követelmények
Fontos, hogy több szempontból is figyelembe vegye a tárolási és adatszolgáltatásokhoz használt megközelítéseket, amelyek nagyjából igazodnak az Azure Well-Architected Framework alappilléreihez.
Méretezés
Amikor az adatokat tároló szolgáltatásokkal dolgozik, figyelembe kell vennie a bérlők számát és a tárolt adatok mennyiségét. Ha kis számú bérlővel rendelkezik (például öt vagy kevesebb), és kis mennyiségű adatot tárol minden bérlőhöz, akkor valószínűleg feleslegesen tervezhet nagy mértékben méretezhető adattárolási megközelítést, vagy teljesen automatizált megközelítést hozhat létre az adaterőforrások kezeléséhez. A növekedéssel azonban egyre jobban kihasználhatja, hogy egyértelmű stratégiával skálázhatja az adatokat és a tárolási erőforrásokat, és automatizálhatja a felügyeletet. Ha 50 bérlővel vagy annál több bérlővel rendelkezik, vagy ha ezt a skálázási szintet szeretné elérni, akkor különösen fontos az adatok és a tárterület megközelítésének megtervezése, a skálázás kulcsfontosságú szempontként.
Fontolja meg, hogy milyen mértékben tervezi a skálázást, és egyértelműen tervezze meg az adattárolási architektúra megközelítését, hogy megfeleljen az adott méretezési szintnek.
A teljesítmény kiszámíthatósága
A több-bérlős adat- és tárolási szolgáltatások különösen érzékenyek a Zajos szomszéd problémára. Fontos megfontolni, hogy a bérlők befolyásolhatják-e egymás teljesítményét. A bérlők például átfedésben vannak a használati mintájukban az idő függvényében? Minden ügyfél naponta egyszerre használja a megoldást, vagy egyenletesen oszlanak el a kérelmek? Ezek a tényezők hatással lesznek a tervezéshez szükséges elkülönítés szintjére, a kiépíteni kívánt erőforrások mennyiségére, valamint arra, hogy milyen mértékben oszthatók meg az erőforrások a bérlők között.
Fontos figyelembe venni az Azure erőforrását, és kvótákat igényelni ennek a döntésnek a részeként. Tegyük fel például, hogy egyetlen tárfiókot helyez üzembe, amely tartalmazza a bérlő összes adatát. Ha másodpercenként túllép egy adott számú tárolási műveletet, az Azure Storage elutasítja az alkalmazás kéréseit, és az összes bérlőre hatással lesz. Ezt szabályozási viselkedésnek nevezzük. Fontos, hogy figyelje a szabályozott kérelmeket. További információ: Újrapróbálkozás az Azure-szolgáltatásokhoz.
Az adatok elkülönítését
A több-bérlős adatszolgáltatásokat tartalmazó megoldások tervezésekor általában különböző lehetőségek és szintű adatelkülönítések állnak rendelkezésre, amelyek mindegyike saját előnyökkel és kompromisszumokkal rendelkezik. Például:
- Az Azure Cosmos DB használatakor minden bérlőhöz külön tárolókat helyezhet üzembe, és adatbázisokat és fiókokat oszthat meg több bérlő között. Másik lehetőségként érdemes lehet különböző adatbázisokat vagy akár fiókokat üzembe helyezni az egyes bérlők számára a szükséges elkülönítési szinttől függően.
- Ha az Azure Storage-t blobadatokhoz használja, minden bérlőhöz külön blobtárolókat helyezhet üzembe, vagy külön tárfiókokat is üzembe helyezhet.
- Az Azure SQL használatakor külön táblákat használhat megosztott adatbázisokban, vagy külön adatbázisokat vagy kiszolgálókat helyezhet üzembe minden bérlőhöz.
- Minden Azure-szolgáltatásban megfontolhatja az erőforrások egyetlen megosztott Azure-előfizetésen belüli üzembe helyezését, vagy több Azure-előfizetést is használhat – bérlőnként akár egyet is.
Nincs egyetlen megoldás, amely minden helyzetben működik. A választott beállítás számos tényezőtől és a bérlők követelményeitől függ. Ha például a bérlőknek meg kell felelniük bizonyos megfelelőségi vagy szabályozási szabványoknak, előfordulhat, hogy magasabb szintű elkülönítést kell alkalmazniuk. Hasonlóképpen előfordulhat, hogy kereskedelmi követelmények vonatkoznak az ügyfelek adatainak fizikai elkülönítésére, vagy szükség lehet az elkülönítés kényszerítésére a zajos szomszéd probléma elkerülése érdekében. Ezenkívül ha a bérlőknek saját titkosítási kulcsokat kell használniuk, egyéni biztonsági mentési és visszaállítási szabályzatokkal kell rendelkezniük, vagy különböző földrajzi helyeken kell tárolniuk az adataikat, előfordulhat, hogy el kell különíteni őket más bérlőktől, vagy csoportosítania kell őket hasonló szabályzatokkal rendelkező bérlőkkel.
A megvalósítás összetettsége
Fontos figyelembe venni a megvalósítás összetettségét. Célszerű az architektúrát a lehető legegyszerűbben tartani, miközben továbbra is megfelel a követelményeknek. Ne kötelezze el magát olyan architektúra mellett, amely skálázáskor egyre összetettebb lesz, vagy olyan architektúrára, amely nem rendelkezik a fejlesztéshez és karbantartáshoz szükséges erőforrásokkal vagy szakértelemmel.
Hasonlóképpen, ha a megoldásnak nem kell nagy számú bérlőre skáláznia, vagy ha nincs aggálya a teljesítmény vagy az adatelkülönítés körül, akkor jobb, ha a megoldást egyszerűnek tartja, és elkerüli a szükségtelen összetettséget.
A több-bérlős adatmegoldások esetében különösen fontos a támogatott testreszabási szint. Kiterjesztheti például egy bérlő az adatmodellt, vagy alkalmazhat egyéni adatszabályokat? Győződjön meg arról, hogy előre megtervezi ezt a követelményt. Kerülje az elágaztatást vagy az egyéni infrastruktúra biztosítását az egyes bérlők számára. A testreszabott infrastruktúra megakadályozza a skálázást, a megoldás tesztelését és a frissítések üzembe helyezését. Ehelyett fontolja meg a funkciójelzők és a bérlőkonfiguráció egyéb formáinak használatát.
A felügyelet és a műveletek összetettsége
Gondolja át, hogyan tervezi a megoldás üzemeltetését, és hogy a több-bérlős megközelítés hogyan befolyásolja a műveleteket és a folyamatokat. Például:
- Felügyelet: Fontolja meg a bérlők közötti felügyeleti műveleteket, például a rendszeres karbantartási tevékenységeket. Ha több fiókot, kiszolgálót vagy adatbázist használ, hogyan fogja kezdeményezni és figyelni az egyes bérlők műveleteit?
- Monitorozás és mérés: Ha figyeli vagy méri a bérlőket, gondolja át, hogyan jelent a megoldás metrikákat, és hogy könnyen összekapcsolhatók-e a kérést kiváltó bérlőhöz.
- Jelentéskészítés: Az izolált bérlők adatainak jelentéséhez szükség lehet arra, hogy minden bérlő egy központi adattárházban tegye közzé az adatokat ahelyett, hogy lekérdezéseket futtatna az egyes adatbázisokon egyenként, majd összesíthetné az eredményeket.
- Sémafrissítések: Ha sémát kényszerítő adatbázist használ, tervezze meg, hogyan fogja üzembe helyezni a sémafrissítéseket a birtokában. Gondolja át, hogyan tudja az alkalmazás, hogy melyik sémaverziót használja egy adott bérlő adatbázis-lekérdezéseihez.
- Követelmények: Vegye figyelembe a bérlők magas rendelkezésre állási követelményeit (például az üzemidő szolgáltatásiszint-szerződéseit vagy az SLA-kat) és a vészhelyreállítási követelményeket (például a helyreállítási idő célkitűzéseit, a KPO-kat és a helyreállítási pont célkitűzéseit vagy az RRP-ket). Ha a bérlők eltérő elvárásokat támasztanak, meg tudja felelni az egyes bérlők követelményeinek?
- Migrálás: Hogyan migrálja a bérlőket, ha más típusú szolgáltatásra, másik üzembe helyezésre vagy másik régióra kell áttelepíteniük őket?
Költség
Általában minél nagyobb a bérlők sűrűsége az üzembehelyezési infrastruktúrában, annál alacsonyabb az infrastruktúra kiépítésének költsége. A megosztott infrastruktúra azonban növeli az olyan problémák valószínűségét, mint a Zajos szomszéd probléma, ezért gondosan fontolja meg a kompromisszumokat.
Megfontolandó megközelítések és minták
Az Azure Architecture Center számos tervezési mintája fontos a több-bérlős tárolás és az adatszolgáltatások szempontjából. Dönthet úgy, hogy következetesen követ egy mintát. Vagy megfontolhatja a keverést és a minták egyeztetését. Használhat például több-bérlős adatbázist a bérlők többségéhez, de egy-bérlős bélyegeket helyezhet üzembe azoknak a bérlőknek, akik többet fizetnek, vagy szokatlan követelményekkel rendelkeznek. Hasonlóképpen, gyakran ajánlott skálázni üzembehelyezési bélyegek használatával, még akkor is, ha több-bérlős adatbázist vagy skálázott adatbázist használ egy bélyegen belül.
Üzembehelyezési bélyegek mintája
Ha többet szeretne megtudni arról, hogy a Központi telepítési bélyegek minta hogyan használható a több-bérlős megoldások támogatásához, tekintse meg az Áttekintést.
Megosztott több-bérlős adatbázisok és fájltárolók
Érdemes lehet egy megosztott több-bérlős adatbázist, tárfiókot vagy fájlmegosztást üzembe helyezni, és megosztani az összes bérlőn.
Ez a megközelítés biztosítja a bérlők legnagyobb sűrűségét az infrastruktúrához, ezért általában minden megközelítés legalacsonyabb költségén jár. Emellett gyakran csökkenti a felügyeleti többletterhelést is, mivel egyetlen adatbázis vagy erőforrás felügyelheti, biztonsági mentést és biztonságossá teheti.
Ha azonban megosztott infrastruktúrával dolgozik, több szempontot is figyelembe kell vennie:
- Méretezési korlátok: Ha egyetlen erőforrásra támaszkodik, vegye figyelembe az erőforrás támogatott skálázását és korlátait. Például egy adatbázis vagy fájltároló maximális mérete vagy a maximális átviteli sebességkorlátok végül kemény blokkolóvá válnak, ha az architektúra egyetlen adatbázisra támaszkodik. A minta kiválasztása előtt gondosan gondolja át, hogy milyen maximális méretet kell elérnie, és hasonlítsa össze a jelenlegi és a jövőbeli korlátokkal.
- Zajos szomszédok: A zajos szomszéd probléma tényezővé válhat, különösen akkor, ha olyan bérlői vannak, amelyek különösen elfoglaltak, vagy magasabb számítási feladatokat hoznak létre, mint mások. Figyelembe véve a szabályozási mintát vagy a sebességkorlátozási mintát a hatások enyhítésére.
- Az egyes bérlők monitorozása: Előfordulhat, hogy nehézségekbe ütközik a tevékenység monitorozása és egy bérlő fogyasztásának mérése. Egyes szolgáltatások, például az Azure Cosmos DB, minden kéréshez jelentést nyújtanak az erőforrás-használatról, így ezek az információk nyomon követhetők az egyes bérlők fogyasztásának méréséhez. Más szolgáltatások nem biztosítják ugyanazt a részletességi szintet. A fájlkapacitásHoz tartozó Azure Files-metrikák például fájlmegosztási dimenziónként érhetők el, csak prémium szintű megosztások használatakor. A standard szint azonban csak a tárfiók szintjén biztosítja a metrikákat.
- Bérlői követelmények: A bérlőknek eltérő biztonsági, biztonsági mentési, rendelkezésre állási vagy tárolási követelményeket kell kielégíteniük. Ha ezek nem felelnek meg az önálló erőforrás konfigurációjának, előfordulhat, hogy nem tudja őket elszállásolni.
- Séma testreszabása: Ha relációs adatbázissal dolgozik, vagy ha az adatok sémája fontos, akkor a bérlőszintű séma testreszabása nehéz.
Horizontális particionálási minta
A horizontális skálázási minta magában foglalja több különálló adatbázis, úgynevezett szegmensek üzembe helyezését, amelyek mindegyike egy vagy több bérlő adatait tartalmazza. Az üzembehelyezési bélyegekkel ellentétben a szegmensek nem azt jelentik, hogy a teljes infrastruktúra duplikálva van. Előfordulhat, hogy a megoldás más infrastruktúráinak duplikálása vagy szilánkolása nélkül is szilánkosíthatja az adatbázisokat.
A horizontális skálázás szorosan kapcsolódik a particionáláshoz, és a kifejezéseket gyakran felcserélhetően használják. Vegye figyelembe a horizontális, függőleges és funkcionális adatparticionálási útmutatót.
A horizontális skálázási minta nagy számú bérlőre méretezhető. Emellett a számítási feladattól függően előfordulhat, hogy a bérlők nagy sűrűségű szegmenseket tudnak létrehozni, így a költségek vonzóak lehetnek. A horizontális skálázási minta az Azure-előfizetések és szolgáltatáskvóták, korlátok és korlátozások kezelésére is használható.
Egyes adattárak, például az Azure Cosmos DB natív támogatást nyújtanak a horizontális skálázáshoz vagy particionáláshoz. Ha más megoldásokkal, például az Azure SQL-sel dolgozik, összetettebb lehet egy horizontálisan skálázási infrastruktúra létrehozása és a kérések megfelelő szegmensbe irányítása egy adott bérlő számára.
A horizontális skálázás emellett megnehezíti a bérlői szintű konfigurációs különbségek támogatását, és lehetővé teszi az ügyfelek számára, hogy saját titkosítási kulcsokat adjanak meg.
Több-bérlős alkalmazás dedikált adatbázisokkal minden bérlőhöz
Egy másik gyakori módszer egy több-bérlős alkalmazás üzembe helyezése, az egyes bérlők számára dedikált adatbázisokkal.
Ebben a modellben az egyes bérlők adatai el vannak különítve a többitől, és bizonyos fokú testreszabást is támogathat az egyes bérlők esetében.
Mivel minden bérlőhöz dedikált adaterőforrásokat épít ki, ennek a megközelítésnek a költsége magasabb lehet, mint a megosztott üzemeltetési modellek. Az Azure azonban számos lehetőséget kínál, amelyek segítségével megoszthatja az egyes adaterőforrások üzemeltetésének költségeit több bérlő között. Ha például az Azure SQL-vel dolgozik, megfontolhatja a rugalmas készletek használatát. Az Azure Cosmos DB-ben kiépítheti az adatbázis átviteli sebességét, és az átviteli sebesség meg van osztva az adatbázisban lévő tárolók között, bár ez a megközelítés nem megfelelő, ha minden tárolóhoz garantált teljesítményre van szüksége.
Ebben a megközelítésben, mivel csak az adatösszetevők vannak egyenként üzembe helyezve az egyes bérlők esetében, valószínűleg nagy sűrűséget érhet el a megoldás többi összetevőjéhez, és csökkentheti ezeknek az összetevőknek a költségeit.
Az egyes bérlők adatbázisainak kiépítésekor fontos, hogy automatizált üzembe helyezési módszereket használjon.
Geodéziai minta
A Geode-minta kifejezetten földrajzilag elosztott megoldásokhoz készült, beleértve a több-bérlős megoldásokat is. Támogatja a magas terhelést és a magas rugalmasságot. A Geode-minta implementálásához az adatszintnek képesnek kell lennie az adatok földrajzi régiók közötti replikálására, és támogatnia kell a többföldrajzos írást.
Az Azure Cosmos DB több főkiszolgálós írásokat biztosít a minta támogatásához, a Cassandra pedig többrégiós fürtöket támogat. Más adatszolgáltatások általában nem támogatják ezt a mintát jelentős testreszabás nélkül.
Antipatterns kerülni
Több-bérlős adatszolgáltatások létrehozásakor fontos elkerülni azokat a helyzeteket, amelyek gátolják a skálázást.
A relációs adatbázisok esetében ezek a következők:
- Táblaalapú elkülönítés. Ha egyetlen adatbázisban dolgozik, ne hozzon létre külön táblákat az egyes bérlőkhöz. Ha ezt a módszert használja, egyetlen adatbázis nem fogja tudni támogatni a bérlők nagy számát, és egyre nehezebb lesz az adatok lekérdezése, kezelése és frissítése. Ehelyett fontolja meg több-bérlős táblák egyetlen készletének használatát bérlőazonosító oszlopmal. Másik lehetőségként használhatja a fent leírt minták egyikét, hogy külön adatbázisokat helyezzen üzembe az egyes bérlők számára.
- Oszlopszintű bérlő testreszabása. Kerülje az olyan sémafrissítések alkalmazását, amelyek csak egyetlen bérlőre vonatkoznak. Tegyük fel például, hogy egyetlen több-bérlős adatbázissal rendelkezik. Ne adjon hozzá új oszlopot, hogy megfeleljen egy adott bérlő követelményeinek. Kis számú testreszabás esetén elfogadható, de ez gyorsan kezelhetetlenné válik, ha sok testreszabást kell figyelembe vennie. Ehelyett fontolja meg az adatmodell felülvizsgálatát, hogy nyomon kövesse az egyes bérlők egyéni adatait egy dedikált táblában.
- Manuális sémamódosítások. Kerülje az adatbázisséma manuális frissítését, még akkor is, ha csak egyetlen megosztott adatbázissal rendelkezik. Könnyen elveszítheti az alkalmazott frissítések nyomon követését, és ha több adatbázisra van szüksége, nehéz azonosítani a megfelelő sémát. Ehelyett hozzon létre egy automatizált folyamatot a sémamódosítások üzembe helyezéséhez, és használja következetesen. Nyomon követheti a dedikált adatbázisban vagy keresési táblában lévő összes bérlőhöz használt sémaverziót.
- Verziófüggőségek. Kerülje, hogy az alkalmazás függőséget vállaljon az adatbázisséma egyetlen verziójától. Skálázáskor előfordulhat, hogy különböző bérlők esetében különböző időpontokban kell sémafrissítéseket alkalmaznia. Ehelyett győződjön meg arról, hogy az alkalmazás verziója visszamenőlegesen kompatibilis legalább egy sémaverzióval, és kerülje a romboló sémafrissítéseket.
Adatbázisok
Vannak olyan funkciók, amelyek hasznosak lehetnek a több-bérlős alkalmazásokhoz. Ezek azonban nem minden adatbázis-szolgáltatásban érhetők el. Fontolja meg, hogy szüksége van-e ezekre, amikor úgy dönt, hogy a szolgáltatást a forgatókönyvéhez használja:
- A sorszintű biztonság biztonsági elkülönítést biztosíthat egy megosztott több-bérlős adatbázisban lévő egyes bérlők adataihoz. Ez a funkció az Azure SQL-ben és a Postgres Flexben érhető el, de más adatbázisokban, például a MySQL-ben vagy az Azure Cosmos DB-ben nem érhető el.
- Előfordulhat, hogy bérlőszintű titkosításra van szükség az adatokhoz saját titkosítási kulcsokat biztosító bérlők támogatásához. Ez a funkció az Azure SQL-ben az Always Encrypted részeként érhető el. Az Azure Cosmos DB ügyfél által felügyelt kulcsokat biztosít a fiók szintjén, és támogatja az Always Encrypted szolgáltatást is.
- Az erőforráskészletezés lehetővé teszi az erőforrások és a költségek megosztását több adatbázis vagy tároló között. Ez a funkció az Azure SQL rugalmas készleteiben és felügyelt példányaiban , valamint az Azure Cosmos DB-adatbázis átviteli sebességében érhető el, bár minden beállításnak vannak korlátai, amiről tudnia kell.
- A horizontális skálázás és particionálás egyes szolgáltatásokban erősebb natív támogatást nyújt, mint mások. Ez a funkció az Azure Cosmos DB-ben, annak logikai és fizikai particionálásával, valamint a PostgreSQL Rugalmas skálázásban érhető el. Bár az Azure SQL natív módon nem támogatja a horizontális skálázást, skálázási eszközöket biztosít az ilyen típusú architektúra támogatásához.
Emellett ha relációs adatbázisokkal vagy más sémaalapú adatbázisokkal dolgozik, fontolja meg, hogy hol kell aktiválni a sémafrissítési folyamatot, amikor adatbázis-flottát tart fenn. Az adatbázisok kis része esetén érdemes lehet üzembe helyezési folyamatot használni a sémamódosítások üzembe helyezéséhez. A növekedés során jobb lehet, ha az alkalmazásszint észleli egy adott adatbázis sémaverzióját, és elindítja a frissítési folyamatot.
Fájl- és blobtároló
Fontolja meg a tárfiókon belüli adatok elkülönítésére használt módszert. Előfordulhat például, hogy minden bérlőhöz külön tárfiókokat helyez üzembe, vagy megoszthatja a tárfiókokat, és egyes tárolókat helyezhet üzembe. Másik lehetőségként létrehozhat megosztott blobtárolókat, majd a blob elérési útján elkülönítheti az egyes bérlők adatait. Fontolja meg az Azure-előfizetések korlátait és kvótáit, és gondosan tervezze meg a növekedést, hogy az Azure-erőforrások mérete megfeleljen a jövőbeli igényeknek.
Megosztott tárolók használata esetén gondosan tervezze meg a hitelesítési és engedélyezési stratégiát, hogy a bérlők ne férhessenek hozzá egymás adataihoz. Vegye figyelembe a Valet-kulcs mintáját, amikor hozzáférést biztosít az ügyfeleknek az Azure Storage-erőforrásokhoz.
Költséglefoglalás
Gondolja át, hogyan fogja mérni a használatot, és hogyan oszthatja ki a költségeket a bérlőknek a megosztott adatszolgáltatások használatához. Amikor csak lehetséges, a saját számítása helyett használjon beépített metrikákat. A megosztott infrastruktúrával azonban nehéz lesz felosztani a telemetriát az egyes bérlők számára, és érdemes megfontolni az alkalmazásszintű egyéni mérést.
A natív felhőszolgáltatások, például az Azure Cosmos DB és az Azure Blob Storage általában részletesebb metrikákat biztosítanak egy adott bérlő használati adatainak nyomon követéséhez és modellezéséhez. Az Azure Cosmos DB például minden kéréshez és válaszhoz biztosítja a felhasznált átviteli sebességet.
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:
- Paul Burpo | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
- Daniel Scott-Raynsford | Partnertechnológiai stratéga
- 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.
További lépések
További információ a több-bérlős és az egyes Azure-szolgáltatásokról: