Dane są często uważane za najbardziej cenną część rozwiązania, ponieważ reprezentują Twoje — i klientów — cenne informacje biznesowe. Dlatego ważne jest, aby dokładnie zarządzać danymi. Podczas planowania magazynu lub składników danych dla systemu wielodostępnego należy zdecydować o podejściu do udostępniania lub izolowania danych dzierżawców.
W tym artykule przedstawiono wskazówki dotyczące kluczowych zagadnień i wymagań, które są niezbędne dla architektów rozwiązań podczas podejmowania decyzji o podejściu do przechowywania danych w systemie wielodostępnym. Następnie sugerujemy kilka typowych wzorców stosowania wielodostępności do usług magazynowania i danych, a niektóre antywzorzec, aby uniknąć. Na koniec udostępniamy ukierunkowane wskazówki dotyczące niektórych konkretnych sytuacji.
Kluczowe zagadnienia i wymagania
Ważne jest, aby wziąć pod uwagę podejścia używane do magazynowania i usług danych z wielu perspektyw, w tym filarów platformy Azure Well-Architected Framework.
Skaluj
Podczas pracy z usługami, które przechowują dane, należy wziąć pod uwagę liczbę posiadanych dzierżaw oraz ilość przechowywanych danych. Jeśli masz niewielką liczbę dzierżaw (takich jak pięć lub mniej) i przechowujesz małe ilości danych dla każdej dzierżawy, prawdopodobnie będzie to zmarnowana próba zaplanowania wysoce skalowalnego podejścia do magazynowania danych lub utworzenia w pełni zautomatyzowanego podejścia do zarządzania zasobami danych. Jednak wraz z rozwojem coraz częściej korzystasz z jasnej strategii skalowania danych i zasobów magazynu oraz stosowania automatyzacji do zarządzania nimi. Jeśli masz co najmniej 50 dzierżaw lub planujesz osiągnąć ten poziom skalowania, szczególnie ważne jest zaprojektowanie podejścia do danych i magazynowania przy użyciu skalowania jako kluczowego zagadnienia.
Rozważ zakres, w jakim planujesz skalowanie, i jasno zaplanuj podejście architektury magazynu danych, aby osiągnąć ten poziom skali.
Przewidywalność wydajności
Wielodostępne usługi danych i magazynowania są szczególnie podatne na problem z hałaśliwym sąsiadem. Ważne jest, aby wziąć pod uwagę, czy dzierżawcy mogą wpływać na wydajność siebie nawzajem. Czy na przykład dzierżawcy mają nakładające się szczyty w ich wzorcach użycia w czasie? Czy wszyscy klienci korzystają z rozwiązania w tym samym czasie każdego dnia lub czy żądania są dystrybuowane równomiernie? Te czynniki będą mieć wpływ na poziom izolacji, dla którego należy zaprojektować, ilość zasobów, które należy aprowizować, oraz stopień, w jakim zasoby mogą być współużytkowane przez dzierżawców.
Ważne jest, aby w ramach tej decyzji wziąć pod uwagę limity przydziału zasobów i żądań platformy Azure. Załóżmy na przykład, że wdrożysz pojedyncze konto magazynu zawierające wszystkie dane dzierżawy. Jeśli przekroczysz określoną liczbę operacji magazynowania na sekundę, usługa Azure Storage odrzuci żądania aplikacji, a wszystkie dzierżawy będą mieć wpływ. Jest to nazywane zachowaniem ograniczania przepustowości. Ważne jest, aby monitorować żądania ograniczone. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące ponawiania prób dla usług platformy Azure.
Izolacja danych
Podczas projektowania rozwiązania, które zawiera wielodostępne usługi danych, zazwyczaj istnieją różne opcje i poziomy izolacji danych, z których każdy ma własne korzyści i kompromisy. Na przykład:
- W przypadku korzystania z usługi Azure Cosmos DB można wdrożyć oddzielne kontenery dla każdej dzierżawy, a także udostępniać bazy danych i konta między wieloma dzierżawami. Alternatywnie można rozważyć wdrożenie różnych baz danych, a nawet kont dla każdej dzierżawy, w zależności od wymaganego poziomu izolacji.
- W przypadku korzystania z usługi Azure Storage dla danych obiektów blob można wdrożyć oddzielne kontenery obiektów blob dla każdej dzierżawy lub wdrożyć oddzielne konta magazynu.
- W przypadku korzystania z usługi Azure SQL można użyć oddzielnych tabel w udostępnionych bazach danych lub wdrożyć oddzielne bazy danych lub serwery dla każdej dzierżawy.
- We wszystkich usługach platformy Azure możesz rozważyć wdrożenie zasobów w ramach jednej udostępnionej subskrypcji platformy Azure lub użyć wielu subskrypcji platformy Azure — być może nawet jednej na dzierżawę.
Nie ma jednego rozwiązania, które działa w każdej sytuacji. Wybrana opcja zależy od wielu czynników i wymagań dzierżaw. Jeśli na przykład dzierżawcy muszą spełniać określone standardy zgodności lub przepisów, może być konieczne zastosowanie wyższego poziomu izolacji. Podobnie może istnieć wymagania handlowe dotyczące fizycznego izolowania danych klientów lub może być konieczne wymuszenie izolacji, aby uniknąć problemu Hałaśliwego sąsiada. Ponadto jeśli dzierżawcy muszą używać własnych kluczy szyfrowania, mają indywidualne zasady tworzenia kopii zapasowych i przywracania lub muszą mieć swoje dane przechowywane w różnych lokalizacjach geograficznych, może być konieczne odizolowanie ich od innych dzierżaw lub grupowanie ich z dzierżawami, które mają podobne zasady.
Złożoność implementacji
Ważne jest, aby wziąć pod uwagę złożoność implementacji. Dobrym rozwiązaniem jest zapewnienie możliwie najprostszej architektury, a jednocześnie spełnianie wymagań. Unikaj zatwierdzania architektury, która będzie coraz bardziej złożona podczas skalowania, lub architektury, która nie ma zasobów ani wiedzy fachowej do opracowywania i konserwacji.
Podobnie, jeśli rozwiązanie nie musi być skalowane do dużej liczby dzierżaw lub jeśli nie masz obaw dotyczących wydajności lub izolacji danych, lepiej zachować proste rozwiązanie i uniknąć niepotrzebnej złożoności.
Szczególnym problemem dla wielodostępnych rozwiązań danych jest poziom dostosowywania, który obsługujesz. Na przykład czy dzierżawa może rozszerzyć model danych lub zastosować niestandardowe reguły danych? Upewnij się, że projektujesz to wymaganie z góry. Unikaj tworzenia rozwidleń lub udostępniania infrastruktury niestandardowej dla poszczególnych dzierżaw. Dostosowana infrastruktura hamuje możliwość skalowania, testowania rozwiązania i wdrażania aktualizacji. Zamiast tego rozważ użycie flag funkcji i innych form konfiguracji dzierżawy.
Złożoność zarządzania i operacji
Zastanów się, jak planujesz obsługiwać rozwiązanie i jak podejście wielodostępności wpływa na operacje i procesy. Na przykład:
- Zarządzanie: rozważ operacje zarządzania między dzierżawami, takie jak regularne działania konserwacyjne. Jeśli używasz wielu kont, serwerów lub baz danych, jak zainicjujesz i będziesz monitorować operacje dla każdej dzierżawy?
- Monitorowanie i pomiary: jeśli monitorujesz lub oceniasz dzierżawy, rozważ sposób raportowania metryk rozwiązania i czy można je łatwo połączyć z dzierżawą, która wyzwoliła żądanie.
- Raportowanie: raportowanie danych z różnych izolowanych dzierżaw może wymagać, aby każda dzierżawa publikuje dane w scentralizowanym magazynie danych, zamiast uruchamiać zapytania dla każdej bazy danych osobno, a następnie agregować wyniki.
- Aktualizacje schematu: jeśli używasz bazy danych, która wymusza schemat, zaplanuj sposób wdrażania aktualizacji schematu w obrębie majątku. Zastanów się, w jaki sposób aplikacja wie, której wersji schematu używać dla zapytań bazy danych określonej dzierżawy.
- Wymagania: Należy wziąć pod uwagę wymagania dotyczące wysokiej dostępności dzierżawy (na przykład umowy dotyczące poziomu usług w czasie pracy lub umowy SLA) oraz wymagania dotyczące odzyskiwania po awarii (na przykład cele czasu odzyskiwania lub cele punktu odzyskiwania oraz cele punktu odzyskiwania lub cele punktu odzyskiwania). Jeśli dzierżawy mają różne oczekiwania, czy będzie można spełnić wymagania każdej dzierżawy?
- Migracja: Jak przeprowadzić migrację dzierżaw, jeśli będą musieli przejść do innego typu usługi, innego wdrożenia lub innego regionu?
Koszt
Ogólnie rzecz biorąc, im większa gęstość dzierżaw w infrastrukturze wdrażania, tym niższy koszt aprowizacji tej infrastruktury. Jednak współdzielona infrastruktura zwiększa prawdopodobieństwo problemów, takich jak problem Noisy Neighbor, więc należy dokładnie rozważyć kompromisy.
Podejścia i wzorce do rozważenia
Kilka wzorców projektowych z Centrum architektury platformy Azure ma znaczenie dla wielodostępnych usług magazynowania i danych. Możesz konsekwentnie podążać za jednym wzorcem. Możesz też rozważyć mieszanie i dopasowywanie wzorców. Na przykład możesz użyć wielodostępnej bazy danych dla większości dzierżaw, ale wdrożyć sygnatury z jedną dzierżawą dla dzierżaw, którzy płacą więcej lub którzy mają nietypowe wymagania. Podobnie często dobrym rozwiązaniem jest skalowanie przy użyciu sygnatur wdrażania, nawet jeśli używasz wielodostępnej bazy danych lub baz danych podzielonych na fragmenty w ramach sygnatury.
Wzorzec sygnatur wdrażania
Aby uzyskać więcej informacji na temat sposobu użycia wzorca sygnatur wdrożenia do obsługi rozwiązania wielodostępnego, zobacz Omówienie.
Udostępnione wielodostępne bazy danych i magazyny plików
Możesz rozważyć wdrożenie udostępnionej wielodostępnej bazy danych, konta magazynu lub udziału plików oraz udostępnienie jej we wszystkich dzierżawach.
Takie podejście zapewnia najwyższą gęstość dzierżawców w infrastrukturze, więc ma tendencję do najniższego kosztu każdego podejścia. Często zmniejsza to obciążenie związane z zarządzaniem, ponieważ istnieje pojedyncza baza danych lub zasób do zarządzania, tworzenia kopii zapasowych i zabezpieczania.
Jednak podczas pracy z udostępnioną infrastrukturą należy wziąć pod uwagę kilka zastrzeżeń:
- Limity skalowania: w przypadku polegania na jednym zasobie należy wziąć pod uwagę obsługiwaną skalę i limity tego zasobu. Na przykład maksymalny rozmiar jednej bazy danych lub magazynu plików lub maksymalne limity przepływności ostatecznie staną się twardym blokiem, jeśli architektura opiera się na pojedynczej bazie danych. Przed wybraniem tego wzorca należy dokładnie rozważyć maksymalną skalę, którą należy osiągnąć, i porównać ją z bieżącymi i przyszłymi limitami.
- Hałaśli sąsiedzi: Problem z hałaśliwym sąsiadem może stać się czynnikiem, zwłaszcza jeśli masz dzierżawy, które są szczególnie zajęte lub generują wyższe obciążenia niż inne. Rozważ zastosowanie wzorca ograniczania przepustowości lub wzorca ograniczania szybkości w celu ograniczenia tych skutków.
- Monitorowanie każdej dzierżawy: może być trudno monitorować działanie i mierzyć zużycie dla jednej dzierżawy. Niektóre usługi, takie jak Azure Cosmos DB, zapewniają raportowanie użycia zasobów dla każdego żądania, dzięki czemu te informacje można śledzić w celu mierzenia zużycia dla każdej dzierżawy. Inne usługi nie zapewniają tego samego poziomu szczegółowości. Na przykład metryki usługi Azure Files dotyczące pojemności plików są dostępne dla wymiaru udziału plików i tylko wtedy, gdy używasz udziałów w warstwie Premium. Jednak warstwa Standardowa zapewnia metryki tylko na poziomie konta magazynu.
- Wymagania dotyczące dzierżawy: Dzierżawy mogą mieć różne wymagania dotyczące zabezpieczeń, kopii zapasowych, dostępności lub lokalizacji magazynu. Jeśli nie są one zgodne z konfiguracją pojedynczego zasobu, być może nie będzie można ich uwzględnić.
- Dostosowywanie schematu: w przypadku pracy z relacyjną bazą danych lub inną sytuacją, w której schemat danych jest ważny, dostosowanie schematu na poziomie dzierżawy jest trudne.
Sharding pattern (Wzorzec fragmentowania)
Wzorzec fragmentowania obejmuje wdrażanie wielu oddzielnych baz danych nazywanych fragmentami, które zawierają co najmniej jedno dane dzierżawy. W przeciwieństwie do sygnatur wdrażania fragmenty nie oznaczają, że cała infrastruktura jest duplikowana. Możesz fragmentować bazy danych bez duplikowania lub fragmentowania innego infrastruktury w rozwiązaniu.
Dzielenie na fragmenty jest ściśle związane z partycjonowaniem, a terminy są często używane zamiennie. Zapoznaj się ze wskazówkami dotyczącymi partycjonowania danych poziomych, pionowych i funkcjonalnych.
Wzorzec fragmentowania może być skalowany do bardzo dużej liczby dzierżaw. Ponadto w zależności od obciążenia może być możliwe osiągnięcie wysokiej gęstości dzierżaw do fragmentów, dzięki czemu koszt może być atrakcyjny. Wzorzec fragmentowania może również służyć do obsługi limitów przydziałów, limitów i ograniczeń subskrypcji i usług platformy Azure.
Niektóre magazyny danych, takie jak Azure Cosmos DB, zapewniają natywną obsługę fragmentowania lub partycjonowania. Podczas pracy z innymi rozwiązaniami, takimi jak usługa Azure SQL, może być bardziej złożona w celu utworzenia infrastruktury fragmentowania i kierowania żądań do poprawnego fragmentu dla danej dzierżawy.
Fragmentowanie utrudnia również obsługę różnic w konfiguracji na poziomie dzierżawy i umożliwienie klientom udostępniania własnych kluczy szyfrowania.
Wielodostępna aplikacja z dedykowanymi bazami danych dla każdej dzierżawy
Innym typowym podejściem jest wdrożenie pojedynczej wielodostępnej aplikacji z dedykowanymi bazami danych dla każdej dzierżawy.
W tym modelu dane każdej dzierżawy są odizolowane od innych i mogą być w stanie obsługiwać pewien stopień dostosowywania dla każdej dzierżawy.
Ponieważ aprowizujesz dedykowane zasoby danych dla każdej dzierżawy, koszt tego podejścia może być wyższy niż modele hostingu współużytkowanego. Jednak platforma Azure oferuje kilka opcji, które można wziąć pod uwagę, aby udostępnić koszt hostowania poszczególnych zasobów danych w wielu dzierżawach. Na przykład podczas pracy z usługą Azure SQL można rozważyć elastyczne pule. W przypadku usługi Azure Cosmos DB można aprowizować przepływność dla bazy danych , a przepływność jest współdzielona między kontenerami w tej bazie danych, chociaż takie podejście nie jest odpowiednie, gdy potrzebujesz gwarantowanej wydajności dla każdego kontenera.
W tym podejściu, ponieważ tylko składniki danych są wdrażane indywidualnie dla każdej dzierżawy, prawdopodobnie można osiągnąć wysoką gęstość dla innych składników w rozwiązaniu i zmniejszyć koszt tych składników.
Ważne jest, aby podczas aprowizacji baz danych dla każdej dzierżawy używać metod wdrażania automatycznego.
Wzorzec geode
Wzorzec geode został zaprojektowany specjalnie dla rozwiązań rozproszonych geograficznie, w tym rozwiązań wielodostępnych. Obsługuje wysokie obciążenie i wysoki poziom odporności. Jeśli zaimplementujesz wzorzec geode, warstwa danych musi mieć możliwość replikowania danych między regionami geograficznymi i powinna obsługiwać zapisy w wielu lokalizacjach geograficznych.
Usługa Azure Cosmos DB udostępnia operacje zapisu w wielu regionach w celu obsługi tego wzorca, a usługa Cassandra obsługuje klastry z wieloma regionami. Inne usługi danych zazwyczaj nie mogą obsługiwać tego wzorca bez znaczącego dostosowania.
Antywzorzecy, aby uniknąć
Podczas tworzenia wielodostępnych usług danych ważne jest, aby uniknąć sytuacji, które hamują możliwość skalowania.
W przypadku relacyjnych baz danych należą do nich:
- Izolacja oparta na tabelach. Podczas pracy w jednej bazie danych unikaj tworzenia poszczególnych tabel dla każdej dzierżawy. Pojedyncza baza danych nie będzie mogła obsługiwać bardzo dużej liczby dzierżaw podczas korzystania z tego podejścia i coraz trudniej jest wykonywać zapytania o dane, zarządzać nimi i aktualizować. Zamiast tego rozważ użycie pojedynczego zestawu tabel wielodostępnych z kolumną identyfikatora dzierżawy. Alternatywnie możesz użyć jednego z opisanych powyżej wzorców, aby wdrożyć oddzielne bazy danych dla każdej dzierżawy.
- Dostosowywanie dzierżawy na poziomie kolumny. Unikaj aktualizacji schematu, które mają zastosowanie tylko do jednej dzierżawy. Załóżmy na przykład, że masz pojedynczą wielodostępną bazę danych. Unikaj dodawania nowej kolumny, aby spełnić wymagania określonej dzierżawy. Może to być akceptowalne w przypadku niewielkiej liczby dostosowań, ale szybko stanie się to niezarządzane, gdy masz dużą liczbę dostosowań do rozważenia. Zamiast tego rozważ zmianę modelu danych w celu śledzenia niestandardowych danych dla każdej dzierżawy w dedykowanej tabeli.
- Ręczne zmiany schematu. Unikaj ręcznego aktualizowania schematu bazy danych, nawet jeśli masz tylko jedną udostępnioną bazę danych. Łatwo jest utracić śledzenie zastosowanych aktualizacji, a jeśli trzeba skalować w poziomie do większej liczby baz danych, trudno jest zidentyfikować prawidłowy schemat do zastosowania. Zamiast tego skompiluj zautomatyzowany potok, aby wdrożyć zmiany schematu i konsekwentnie go używać. Śledź wersję schematu używaną dla każdej dzierżawy w dedykowanej bazie danych lub tabeli odnośników.
- Zależności wersji. Unikaj zależności aplikacji od pojedynczej wersji schematu bazy danych. W miarę skalowania może być konieczne zastosowanie aktualizacji schematu w różnym czasie dla różnych dzierżaw. Zamiast tego upewnij się, że wersja aplikacji jest do tyłu zgodna z co najmniej jedną wersją schematu, i unikaj destrukcyjnych aktualizacji schematu.
Bazy danych
Istnieją pewne funkcje, które mogą być przydatne w przypadku wielodostępności. Nie są one jednak dostępne we wszystkich usługach bazy danych. Zastanów się, czy są one potrzebne, gdy zdecydujesz się na usługę do użycia w danym scenariuszu:
- Zabezpieczenia na poziomie wiersza mogą zapewnić izolację zabezpieczeń dla danych określonych dzierżaw w udostępnionej wielodostępnej bazie danych. Ta funkcja jest dostępna w usługach Azure SQL i Postgres Flex, ale nie jest dostępna w innych bazach danych, takich jak MySQL lub Azure Cosmos DB.
- Szyfrowanie na poziomie dzierżawy może być wymagane do obsługi dzierżaw, które udostępniają własne klucze szyfrowania dla swoich danych. Ta funkcja jest dostępna w usłudze Azure SQL w ramach funkcji Always Encrypted. Usługa Azure Cosmos DB udostępnia klucze zarządzane przez klienta na poziomie konta, a także obsługuje funkcję Always Encrypted.
- Buforowanie zasobów umożliwia udostępnianie zasobów i kosztów między wieloma bazami danych lub kontenerami. Ta funkcja jest dostępna w elastycznych pulach i wystąpieniach zarządzanych usługi Azure SQL oraz w przepływności bazy danych usługi Azure Cosmos DB, chociaż każda opcja ma ograniczenia, o których należy pamiętać.
- Partycjonowanie i partycjonowanie ma silniejszą natywną obsługę niektórych usług niż inne. Ta funkcja jest dostępna w usłudze Azure Cosmos DB przy użyciu partycjonowania logicznego i fizycznego. Chociaż usługa Azure SQL nie obsługuje natywnie fragmentowania, udostępnia narzędzia fragmentowania do obsługi tego typu architektury.
Ponadto podczas pracy z relacyjnymi bazami danych lub innymi bazami danych opartymi na schemacie należy rozważyć, gdzie powinien zostać wyzwolony proces uaktualniania schematu, gdy utrzymujesz flotę baz danych. W małej infrastrukturze baz danych można rozważyć użycie potoku wdrażania w celu wdrożenia zmian schematu. Wraz ze wzrostem liczby baz danych lepszym rozwiązaniem może być wykrycie wersji schematu dla określonej bazy danych i zainicjowanie procesu uaktualniania.
Magazyn plików i obiektów blob
Rozważmy podejście używane do izolowania danych na koncie magazynu. Możesz na przykład wdrożyć oddzielne konta magazynu dla każdej dzierżawy lub udostępnić konta magazynu i wdrożyć poszczególne kontenery. Alternatywnie możesz utworzyć udostępnione kontenery obiektów blob, a następnie użyć ścieżki obiektu blob do oddzielenia danych dla każdej dzierżawy. Rozważ limity i limity przydziału subskrypcji platformy Azure, a następnie starannie zaplanuj wzrost, aby zapewnić skalowanie zasobów platformy Azure w celu zapewnienia obsługi przyszłych potrzeb.
Jeśli używasz kontenerów udostępnionych, należy dokładnie zaplanować strategię uwierzytelniania i autoryzacji, aby upewnić się, że dzierżawcy nie będą mogli uzyskiwać dostępu do danych. Podczas zapewniania klientom dostępu do zasobów usługi Azure Storage należy wziąć pod uwagę wzorzec klucza valet.
Alokacja kosztu
Zastanów się, jak zmierzysz zużycie i przydzielisz koszty dzierżawcom na potrzeby korzystania z udostępnionych usług danych. Jeśli to możliwe, należy użyć wbudowanych metryk zamiast obliczać własne. Jednak w przypadku udostępnionej infrastruktury trudno jest podzielić dane telemetryczne dla poszczególnych dzierżaw i może być konieczne rozważenie pomiaru niestandardowego na poziomie aplikacji.
Ogólnie rzecz biorąc, usługi natywne dla chmury, takie jak Azure Cosmos DB i Azure Blob Storage, zapewniają bardziej szczegółowe metryki do śledzenia i modelowania użycia dla określonej dzierżawy. Na przykład usługa Azure Cosmos DB zapewnia zużytą przepływność dla każdego żądania i odpowiedzi.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- John Downs | Główny inżynier oprogramowania
Inni współautorzy:
- Paul Burpo | Główny inżynier klienta, fasttrack dla platformy Azure
- Daniel Scott-Raynsford | Partner TechnologyStrateg
- Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
Aby uzyskać więcej informacji na temat wielodostępności i określonych usług platformy Azure, zobacz: