Víceklientská architektura a Azure Storage
Azure Storage je základní služba používaná téměř ve všech řešeních. Víceklientová řešení často používají Azure Storage pro úložiště objektů blob, souborů, front a tabulek. Na této stránce popisujeme některé funkce služby Azure Storage, které jsou užitečné pro víceklientských řešení, a poté poskytujeme odkazy na pokyny, které vám můžou pomoct při plánování používání Azure Storage.
Funkce Služby Azure Storage, které podporují víceklientské prostředí
Azure Storage obsahuje řadu funkcí, které podporují víceklientské prostředí.
Sdílené přístupové podpisy
Při práci se službou Azure Storage z klientské aplikace je důležité zvážit, jestli se mají požadavky klientů odesílat prostřednictvím jiné komponenty, kterou řídíte, jako je síť pro doručování obsahu nebo rozhraní API, nebo jestli se má klient připojit přímo k vašemu účtu úložiště. Můžou existovat dobré důvody k odesílání požadavků prostřednictvím jiné komponenty, včetně ukládání dat do mezipaměti na okraji sítě. V některých situacích je ale výhodné, aby se koncové body klienta připojily přímo ke službě Azure Storage a stáhly nebo nahrály data. Toto připojení vám pomůže zlepšit výkon vašeho řešení, zejména při práci s velkými objekty blob nebo velkým počtem souborů. Snižuje také zatížení back-endových aplikací a serverů a snižuje počet segmentů směrování sítě. Sdílený přístupový podpis (SAS) umožňuje bezpečně poskytovat klientským aplikacím přístup k objektům ve službě Azure Storage.
Sdílené přístupové podpisy lze použít k omezení rozsahu operací, které může klient provádět, a objektů, se kterými můžou provádět operace. Pokud máte například sdílený účet úložiště pro všechny tenanty a uložíte všechna data tenanta A do kontejneru objektů blob s názvem tenanta
, můžete vytvořit SAS, který uživatelům tenanta A umožňuje přístup k ho kontejneru jenom uživatelům tenanta A. Další informace najdete v tématu Modely izolace k prozkoumání přístupů, které můžete použít k izolaci dat tenantů v účtu úložiště.
Model Valet Key je užitečný jako způsob, jak vydat omezené a omezené sdílené přístupové podpisy z aplikační vrstvy. Předpokládejme například, že máte aplikaci s více tenanty, která umožňuje uživatelům nahrávat videa. Vaše rozhraní API nebo aplikační vrstva můžou ověřovat klienta pomocí vlastního systému ověřování. Potom můžete klientovi poskytnout SAS, který mu umožní nahrát videosoubor do zadaného objektu blob do kontejneru a cesty k objektu blob, který zadáte. Klient pak soubor nahraje přímo do účtu úložiště, aby se zabránilo dodatečné šířce pásma a zatížení vašeho rozhraní API. Pokud se pokusí číst data z kontejneru objektů blob nebo pokud se pokusí zapsat data do jiné části kontejneru do jiného kontejneru v účtu úložiště, Azure Storage požadavek zablokuje. Platnost podpisu vyprší po konfigurovatelném časovém období.
Uložené zásady přístupu rozšiřují funkce SAS, které umožňují definovat jednu zásadu, kterou je možné použít při vydávání více sdílených přístupových podpisů.
Řízení přístupu na základě identit
Azure Storage také poskytuje řízení přístupu na základě identit pomocí MICROSOFT Entra ID. Tato funkce také umožňuje používat řízení přístupu na základě atributů, které poskytuje jemně odstupňovaný přístup k cestám k objektům blob nebo k objektům blob, které byly označené určitým ID tenanta.
Správa životního cyklu
Při použití úložiště objektů blob ve víceklientských řešeních můžou tenanti vyžadovat různé zásady pro uchovávání dat. Při ukládání velkých objemů dat můžete také chtít nakonfigurovat data pro konkrétního tenanta, aby se automaticky přesunula na studenou nebo archivní úroveň úložiště pro účely optimalizace nákladů.
Zvažte použití zásad správy životního cyklu k nastavení životního cyklu pro všechny tenanty nebo pro podmnožinu tenantů. Zásady správy životního cyklu se dají použít na kontejnery objektů blob nebo na podmnožinu objektů blob v rámci kontejneru. Počet pravidel, která můžete zadat v zásadách správy životního cyklu, ale platí omezení. Ujistěte se, že plánujete a otestujete použití této funkce ve víceklientských prostředích, a pokud překročíte limity, zvažte nasazení více účtů úložiště.
Neměnné úložiště
Když nakonfigurujete neměnné úložiště objektů blob v kontejnerech úložiště pomocí zásad uchovávání informací podle času, Azure Storage zabrání odstranění nebo úpravám dat před zadaným časem. Prevence se vynucuje na úrovni účtu úložiště a vztahuje se na všechny uživatele. I správci vaší organizace nemůžou odstranit neměnná data.
Neměnné úložiště může být užitečné při práci s tenanty, kteří mají zákonné požadavky nebo požadavky na dodržování předpisů pro údržbu dat nebo záznamů. Měli byste ale zvážit, jak se tato funkce používá v kontextu životního cyklu vašeho tenanta. Pokud jsou například tenanti přepojeni a požadují odstranění svých dat, možná nebudete moct splnit své požadavky. Pokud pro data tenantů používáte neměnné úložiště, zvažte, jak tento problém vyřešit ve svých podmínkách služby.
Kopie na straně serveru
V systému s více tenanty je někdy potřeba přesunout data z jednoho účtu úložiště do jiného. Pokud například přesunete tenanta mezi razítky nasazení nebo znovu vyrovnáte horizontálně dělenou sadu účtů úložiště, musíte zkopírovat nebo přesunout data konkrétního tenanta. Při práci s velkými objemy dat je vhodné použít rozhraní API pro kopírování na straně serveru a zkrátit dobu potřebnou k migraci dat.
Nástroj AzCopy je aplikace, kterou můžete spustit z vlastního počítače nebo z virtuálního počítače ke správě procesu kopírování. AzCopy je kompatibilní s funkcí kopírování na straně serveru a poskytuje skriptovatelné rozhraní příkazového řádku, které můžete spouštět z vlastních řešení. Nástroj AzCopy je také užitečný pro nahrávání a stahování velkých objemů dat.
Pokud potřebujete použít rozhraní API pro kopírování na straně serveru přímo z kódu, zvažte použití rozhraní URL Put Block From URL API, Put Page From URL API, Append Block From URL API a Copy Blob From URL API při práci s menšími objekty blob.
Replikace objektů
Funkce replikace objektů automaticky replikuje data mezi zdrojovým a cílovým účtem úložiště. Replikace objektů je asynchronní. V řešení s více tenanty může být tato funkce užitečná, když potřebujete průběžně replikovat data mezi razítky nasazení nebo v implementaci modelu Geode.
Šifrování
Azure Storage umožňuje poskytovat šifrovací klíče pro vaše data. Ve víceklientských řešeních zvažte kombinaci této funkce s obory šifrování, které umožňují definovat různé šifrovací klíče pro různé tenanty, i když jsou jejich data uložená ve stejném účtu úložiště. Pomocí těchto funkcí můžete také klientům poskytnout kontrolu nad jejich vlastními daty. Pokud potřebují deaktivovat svůj účet, pak odstraněním šifrovacího klíče zajistíte, že jejich data už nebudou přístupná.
Sledování
Při práci s víceklientské řešení zvažte, jestli potřebujete měřit spotřebu pro každého tenanta a definovat konkrétní metriky, které potřebujete sledovat, například množství úložiště používaného pro každého tenanta (kapacitu) nebo počet operací provedených pro data každého tenanta. Přidělení nákladů můžete také použít ke sledování nákladů na využití jednotlivých tenantů a povolení zpětného účtování napříč několika předplatnými.
Azure Storage poskytuje integrované možnosti monitorování. Je důležité zvážit služby, které budete používat v rámci účtu Azure Storage. Když například pracujete s objekty blob, můžete zobrazit celkovou kapacitu účtu úložiště, ale ne jeden kontejner. Naproti tomu při práci se sdílenými složkami je možné zobrazit kapacitu pro každou sdílenou složku, ale ne pro každou složku.
Můžete také protokolovat všechny požadavky provedené ve službě Azure Storage a pak tyto protokoly agregovat a analyzovat. Tento přístup poskytuje větší flexibilitu při agregaci a seskupení dat pro každého tenanta. V řešeních, která vytvářejí velké objemy požadavků na Azure Storage, je ale důležité zvážit, jestli výhoda, kterou z tohoto přístupu získáte, zdůvodňuje náklady spojené se zachytáváním a zpracováním těchto protokolů.
Inventář služby Azure Storage poskytuje další přístup k měření celkové velikosti kontejneru objektů blob.
Modely izolace
Při práci s víceklientovým systémem pomocí Služby Azure Storage musíte rozhodnout o úrovni izolace, kterou chcete použít. Azure Storage podporuje několik modelů izolace.
Účty úložiště na tenanta
Nejsilnější úrovní izolace je nasazení vyhrazeného účtu úložiště pro tenanta. Tím zajistíte, že jsou všechny klíče úložiště izolované a lze je nezávisle otočit. Tento přístup umožňuje škálovat řešení, abyste se vyhnuli limitům a kvótám, které platí pro každý účet úložiště, ale musíte zvážit také maximální počet účtů úložiště, které je možné nasadit do jednoho předplatného Azure.
Poznámka:
Azure Storage má mnoho kvót a omezení, které byste měli zvážit při výběru modelu izolace. Patří sem limity služeb Azure, cíle škálovatelnosti a cíle škálovatelnosti pro poskytovatele prostředků Azure Storage.
Každá komponenta Azure Storage navíc poskytuje další možnosti izolace tenanta.
Modely izolace úložiště objektů blob
Následující tabulka shrnuje rozdíly mezi hlavními modely izolace tenantů pro objekty blob služby Azure Storage:
Situace | Sdílené kontejnery objektů blob | Kontejnery objektů blob na tenanta | Účty úložiště na tenanta |
---|---|---|---|
Izolace dat | Nízká střední. Použití cest k identifikaci dat jednotlivých tenantů nebo hierarchických oborů názvů | Střední. Použití adres URL SAS s vymezeným kontejnerem k podpoře izolace zabezpečení | Vysoká |
Izolace výkonu | Nízká | Nízká. Většina kvót a omezení se vztahuje na celý účet úložiště. | Vysoká |
Složitost nasazení | Nízká | Střední | Vysoká |
Provozní složitost | Nízká | Střední | Vysoká |
Ukázkový scénář | Ukládání malého počtu objektů blob na tenanta | Vystavení adres URL SAS s vymezeným tenantem | Samostatné razítka nasazení pro každého tenanta |
Sdílené kontejnery objektů blob
Při práci s úložištěm objektů blob se můžete rozhodnout použít sdílený kontejner objektů blob a pak můžete použít cesty k objektům blob k oddělení dat pro každého tenanta:
ID tenanta | Příklad cesty k objektu blob |
---|---|
tenant-a |
https://contoso.blob.core.windows.net/sharedcontainer/tenant-a/blob1.mp4 |
tenant-b |
https://contoso.blob.core.windows.net/sharedcontainer/tenant-b/blob2.mp4 |
I když je tento přístup jednoduchý k implementaci, v mnoha scénářích cesty k objektům blob neposkytují dostatečnou izolaci napříč tenanty. Důvodem je to, že úložiště objektů blob neposkytuje koncept adresářů nebo složek. To znamená, že nemůžete přiřadit přístup ke všem objektům blob v zadané cestě. Azure Storage ale nabízí možnost vypsat (výčet) objektů blob, které začínají zadanou předponou, což může být užitečné při práci se sdílenými kontejnery objektů blob a nevyžaduje řízení přístupu na úrovni adresáře.
Funkce hierarchického oboru názvů služby Azure Storage poskytuje možnost mít silnější koncept adresáře nebo složky, včetně řízení přístupu specifického pro adresář. To může být užitečné v některých scénářích s více tenanty, ve kterých máte sdílené kontejnery objektů blob, ale chcete udělit přístup k datům jednoho tenanta.
V některých víceklientských řešeních možná budete muset uložit jenom jeden objekt blob nebo sadu objektů blob pro každého tenanta, například ikony tenanta pro přizpůsobení uživatelského rozhraní. V těchto scénářích může stačit jeden sdílený kontejner objektů blob. Jako název objektu blob můžete použít identifikátor tenanta a pak místo vytvoření výčtu cesty k objektu blob přečíst konkrétní objekt blob.
Při práci se sdílenými kontejnery zvažte, jestli potřebujete sledovat data a využití služby Azure Storage pro každého tenanta a naplánovat přístup k tomu. Další informace najdete v tématu Monitorování .
Kontejnery objektů blob na tenanta
Jednotlivé kontejnery objektů blob můžete vytvořit pro každého tenanta v rámci jednoho účtu úložiště. Počet kontejnerů objektů blob, které můžete vytvořit v rámci účtu úložiště, není nijak omezený.
Vytvořením kontejnerů pro každého tenanta můžete ke správě přístupu pro data jednotlivých tenantů použít řízení přístupu ke službě Azure Storage, včetně SAS. Kapacitu, kterou každý kontejner používá, můžete také snadno monitorovat.
Modely izolace úložiště souborů
Následující tabulka shrnuje rozdíly mezi hlavními modely izolace tenantů pro soubory Azure Storage:
Situace | Sdílené sdílené složky | Sdílené složky na tenanta | Účty úložiště na tenanta |
---|---|---|---|
Izolace dat | Střední-vysoká. Použití autorizačních pravidel pro soubory a adresáře specifické pro tenanty | Střední-vysoká | Vysoká |
Izolace výkonu | Nízká | Nízká střední. Většina kvót a omezení se vztahuje na celý účet úložiště, ale nastavte kvóty velikosti na úrovni jednotlivých sdílených složek. | Vysoká |
Složitost nasazení | Nízká | Střední | Vysoká |
Provozní složitost | Nízká | Střední | Vysoká |
Ukázkový scénář | Aplikace řídí veškerý přístup k souborům. | Tenanti přistupují k vlastním souborům | Samostatné razítka nasazení pro každého tenanta |
Sdílené sdílené složky
Při práci se sdílenými složkami se můžete rozhodnout použít sdílenou sdílenou složku a pak můžete použít cesty k souborům k oddělení dat pro každého tenanta:
ID tenanta | Příklad cesty k souboru |
---|---|
tenant-a |
https://contoso.file.core.windows.net/share/tenant-a/blob1.mp4 |
tenant-b |
https://contoso.file.core.windows.net/share/tenant-b/blob2.mp4 |
Pokud používáte aplikaci, která může komunikovat pomocí protokolu SMB (Server Message Block) a používáte Doména služby Active Directory Services buď místně, nebo v Azure, podporují sdílené složky autorizaci na úrovni sdílené složky i adresáře nebo souboru.
V jiných scénářích zvažte použití SAS k udělení přístupu ke konkrétním sdíleným složkám nebo souborům. Když používáte SAS, nemůžete udělit přístup k adresářům.
Při práci se sdílenými sdílenými složkami zvažte, jestli potřebujete sledovat data a využití služby Azure Storage pro každého tenanta a pak naplánovat přístup (podle potřeby). Další informace najdete v tématu Monitorování .
Sdílené složky na tenanta
Pro každého tenanta můžete vytvořit jednotlivé sdílené složky v rámci jednoho účtu úložiště. Počet sdílenýchsch
Vytvořením sdílených složek pro každého tenanta můžete ke správě přístupu pro data každého tenanta použít řízení přístupu ke službě Azure Storage, včetně SAS. Kapacitu, kterou každá sdílená složka používá, můžete také snadno monitorovat.
Modely izolace úložiště tabulek
Následující tabulka shrnuje rozdíly mezi hlavními modely izolace tenantů pro tabulky Azure Storage:
Situace | Sdílené tabulky s klíči oddílů na tenanta | Tabulky na tenanta | Účty úložiště na tenanta |
---|---|---|---|
Izolace dat | Nízká. Aplikace vynucuje izolaci. | Nízká střední | Vysoká |
Izolace výkonu | Nízká | Nízká. Většina kvót a omezení se vztahuje na celý účet úložiště. | Vysoká |
Složitost nasazení | Nízká | Střední | Vysoká |
Provozní složitost | Nízká | Střední | Vysoká |
Ukázkový scénář | Velké víceklientové řešení se sdílenou aplikační vrstvou | Vystavení adres URL SAS s vymezeným tenantem | Samostatné razítka nasazení pro každého tenanta |
Sdílené tabulky s klíči oddílů na tenanta
Při použití úložiště tabulek s jednou sdílenou tabulkou můžete zvážit použití integrované podpory pro dělení. Každá entita musí obsahovat klíč oddílu. Identifikátor tenanta je často dobrou volbou pro klíč oddílu.
Sdílené přístupové podpisy a zásady umožňují zadat rozsah klíčů oddílu a Azure Storage zajišťuje, aby požadavky obsahující podpis mohly přistupovat pouze k zadaným rozsahům klíčů oddílu. To vám umožní implementovat model Valet Key, který umožňuje nedůvěryhodným klientům přístup k oddílu jednoho tenanta, aniž by to ovlivnilo ostatní tenanty.
U vysoce škálovaných aplikací zvažte maximální propustnost každého oddílu tabulky a účtu úložiště.
Tabulky na tenanta
Jednotlivé tabulky můžete vytvořit pro každého tenanta v rámci jednoho účtu úložiště. Počet tabulek, které můžete vytvořit v rámci účtu úložiště, není nijak omezený.
Vytvořením tabulek pro každého tenanta můžete ke správě přístupu pro data jednotlivých tenantů použít řízení přístupu ke službě Azure Storage, včetně SAS.
Modely izolace služby Queue Storage
Následující tabulka shrnuje rozdíly mezi hlavními modely izolace tenantů pro fronty Azure Storage:
Situace | Sdílené fronty | Fronty na tenanta | Účty úložiště na tenanta |
---|---|---|---|
Izolace dat | Nízká | Nízká střední | Vysoká |
Izolace výkonu | Nízká | Nízká. Většina kvót a omezení se vztahuje na celý účet úložiště. | Vysoká |
Složitost nasazení | Nízká | Střední | Vysoká |
Provozní složitost | Nízká | Střední | Vysoká |
Ukázkový scénář | Velké víceklientové řešení se sdílenou aplikační vrstvou | Vystavení adres URL SAS s vymezeným tenantem | Samostatné razítka nasazení pro každého tenanta |
Sdílené fronty
Pokud se rozhodnete sdílet frontu, zvažte kvóty a limity, které platí. V řešeních s velkým objemem požadavků zvažte, jestli je dostatečná cílová propustnost 2 000 zpráv za sekundu.
Fronty neposkytují dělení na oddíly ani podřadné fronty, takže se můžou prolínat data pro všechny tenanty.
Fronty na tenanta
Jednotlivé fronty můžete vytvořit pro každého tenanta v rámci jednoho účtu úložiště. Počet front, které můžete vytvořit v rámci účtu úložiště, není nijak omezený.
Vytvořením front pro každého tenanta můžete ke správě přístupu pro data jednotlivých tenantů použít řízení přístupu ke službě Azure Storage, včetně SAS.
Když dynamicky vytváříte fronty pro každého tenanta, zvažte, jak bude vaše aplikační vrstva využívat zprávy z fronty každého tenanta. V pokročilejších scénářích zvažte použití služby Azure Service Bus, která podporuje funkce, jako jsou témata a odběry, relace a automatické přeposílání zpráv, což může být užitečné ve víceklientských řešeních.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- John Downs | Hlavní softwarový inženýr
Další přispěvatelé:
- Dr. Christian Geuer-Pollmann | Hlavní zákaznický inženýr, FastTrack pro Azure
- Patrick Horn | Vedoucí manažer zákaznického inženýrství, FastTrack pro Azure
- Ben Hummerstone | Hlavní zákaznický inženýr, FastTrack pro Azure
- Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure
- Vic Perdana | Architekt cloudových řešení, Azure ISV
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
Projděte si přístupy k úložišti a datům pro víceklientské prostředí.