Modele dzierżawy dla rozwiązania wielodzierżawnego

Istnieje wiele sposobów podejścia do pracy z tenantami w swoim rozwiązaniu. Twoje podejście zależy od tego, czy oraz w jaki sposób udostępniasz zasoby między dzierżawcami. Intuicyjnie możesz unikać udostępniania jakichkolwiek zasobów, ale takie podejście szybko staje się kosztowne wraz z rozwojem firmy i przyjmowaniem większej liczby najemców.

Podczas rozważania różnych modeli wielodostępności warto najpierw zastanowić się, jak definiujesz najemców w swojej organizacji, jakie są Twoje czynniki motywacyjne biznesowe oraz jak planujesz skalowanie swojego rozwiązania. Ten artykuł zawiera wskazówki ułatwiające osobom podejmującym decyzje techniczne ocenę modeli dzierżawy i ich kompromisów.

Zdefiniuj dzierżawcę

Najpierw należy zdefiniować tenant dla twojej organizacji. Zastanów się, kim jest Twój klient lub kto otrzymuje Twoje usługi. Istnieją dwa typowe modele:

• Firma-firma (B2B): Jeśli Twoimi klientami są inne organizacje, prawdopodobnie przypisujesz dzierżawy do tych klientów. Należy jednak rozważyć, czy klienci mają działy, takie jak zespoły lub działy, oraz czy mają obecność w wielu krajach lub regionach. Może być konieczne przypisanie jednego klienta do wielu dzierżawców, jeśli dla tych podgrup obowiązują różne wymagania. Podobnie klient może chcieć utrzymać dwa wystąpienia usługi, aby utrzymać oddzielenie środowisk programistycznych i produkcyjnych. Pojedynczy najemca zazwyczaj ma wielu użytkowników. Na przykład wszyscy pracownicy klienta są użytkownikami w ramach jednej dzierżawy.

• Biznes dla konsumenta (B2C): Jeśli klientami są konsumenci, często trudniej jest powiązać klientów, najemców i użytkowników. W niektórych scenariuszach każdy odbiorca może być odrębnym dzierżawcą. Należy jednak rozważyć, czy rozwiązanie może być używane przez rodziny, grupy znajomych, kluby, stowarzyszenia lub inne grupy, które mogą wymagać dostępu do danych i zarządzania nimi. Na przykład serwis strumieniowego przesyłania muzyki może obsługiwać zarówno użytkowników indywidualnych, jak i rodziny, i może traktować każdy z tych typów kont inaczej, gdy rozdziela je na tenanty.

Definicja tenant wpływa na niektóre kwestie, które należy uwzględnić lub podkreślić podczas projektowania architektury rozwiązania. Rozważmy na przykład następujące typy dzierżaw:

• Jeśli twoimi najemcami są poszczególne osoby lub rodziny, może być konieczne rozważenie, jak obsługujesz dane osobowe oraz przepisów dotyczących suwerenności danych w każdej jurysdykcji, w której działasz.

• Jeśli Dzierżawcy są firmami, może być konieczne pamiętanie o wymaganiach klientów dotyczących zgodności z przepisami i izolacji ich danych. Upewnij się, że spełniasz określony cel poziomu usług (SLO), taki jak czas pracy lub dostępność usługi.

Podejmowanie decyzji o tym, który model ma być używany

Wybór modelu dzierżawy nie jest tylko decyzją techniczną. Jest to również decyzja komercyjna. Należy wziąć pod uwagę następujące pytania:

• Cele biznesowe: Zastanów się, czy zmniejszenie kosztów dla każdego najemcy, czy maksymalizacja doświadczenia najemcy jest bardziej zbieżne z celami strategicznymi.

• Zgodność: Zastanów się, czy klienci zaakceptują wszystkie formy multitenancji. W jaki sposób każdy model wielodostępności wpływa na Twoje wymagania dotyczące zgodności lub wymagania dotyczące zgodności klientów?

• Skala: Zastanów się, czy rozwiązanie jednolokatorskie może się skalować do przyszłych aspiracji wzrostu.

• Automatyzacja: Zastanów się nad rozmiarem zespołu operacyjnego i ilością zarządzania infrastrukturą, którą można zautomatyzować.

• Umowy dotyczące poziomu usług (SLA): Zastanów się, czy klienci oczekują spełnienia SLA, czy też masz cele SLO, które realizujesz.

Jeśli oczekujesz, że Twoja firma będzie rozwijać się tak, by obsługiwać dużą liczbę klientów, ważne jest wdrożenie współdzielonej infrastruktury. W przeciwnym razie trzeba utrzymywać dużą i rosnącą flotę wystąpień zasobów. Wdrażanie poszczególnych zasobów platformy Azure dla każdego klienta prawdopodobnie nie jest wykonalne, chyba że aprowizujesz i używasz dedykowanej subskrypcji dla każdego tenant. Jeśli współużytkujesz tę samą subskrypcję platformy Azure w wielu dzierżawach, mogą być stosowane limity przydziałów zasobów i limity zasobów platformy Azure , a koszty operacyjne wdrażania i ponownego konfigurowania tych zasobów rosną wraz z każdym nowym klientem.

Z kolei, jeśli oczekujesz, że Twoja firma będzie miała niewielu klientów, warto rozważyć użycie zasobów dedykowanych pojedynczemu klientowi, przypisanych każdemu klientowi. Ponadto, jeśli wymagania klientów w zakresie izolacji są wysokie, właściwym rozwiązaniem może być infrastruktura dedykowana jednemu klientowi, mimo że jest ona bardziej kosztowna.

Dzierżawcy i wdrożenia

Następnie należy określić, czy trzeba rozróżniać między logicznymi dzierżawcami a wdrożeniami.

Rozważmy na przykład usługę przesyłania strumieniowego muzyki. Początkowo możesz utworzyć rozwiązanie, które może łatwo obsługiwać tysiące użytkowników, a nawet dziesiątki tysięcy użytkowników. Jednak w miarę rozwoju organizacji może się okazać, że konieczne może być zduplikowanie rozwiązania lub niektórych jego składników w celu skalowania do nowego zapotrzebowania klientów. Aby wykonać to zadanie, należy określić, jak przypisać określonych klientów do określonych wystąpień rozwiązania. Możesz przypisywać klientów losowo, geograficznie lub przez wypełnienie pojedynczego wystąpienia, a następnie uruchomienie kolejnego, znane również jako „bin packing”. Jednak prawdopodobnie musisz zachować rekord klientów i infrastruktury, w której znajdują się ich dane i aplikacje, aby można było kierować ruch do właściwej lokalizacji. W tym przykładzie możesz reprezentować każdego klienta jako oddzielnego najemcę i przypisywać użytkowników do wdrożenia zawierającego ich dane. To podejście tworzy relację jeden do wielu między najemcami a wdrożeniami, a najemców można przenosić między wdrożeniami według własnego uznania.

Z kolei rozważmy firmę, która tworzy oprogramowanie w chmurze dla firm prawnych. Klienci mogą nalegać na posiadanie własnej dedykowanej infrastruktury w celu zachowania zgodności z wymaganiami prawnymi. W związku z tym trzeba być przygotowanym na to, by od samego początku wdrażać wiele różnych instancji rozwiązania i nimi zarządzać. W tym przykładzie wdrożenie zawsze zawiera jednego dzierżawcę, a każdy dzierżawca jest przypisany do własnego, dedykowanego wdrożenia.

Kluczową różnicą między dzierżawami i wdrożeniami jest sposób wymuszania izolacji. Gdy wielu klientów współdzieli jedno wdrożenie (zestaw zasobów infrastruktury), zwykle korzystasz z kodu aplikacji i identyfikatora klienta przechowywanego w bazie danych, aby oddzielać dane poszczególnych klientów. Jeśli dzierżawcy mają własne dedykowane wdrożenia i infrastrukturę, może być mniej istotne, aby kod uwzględniał środowisko wielodostępne.

Wdrożenia są czasami określane jako supertenants lub stamps.

Po otrzymaniu żądania dotyczącego określonego najemcy, należy przypisać je do wdrożenia, które przechowuje dane tego najemcy, jak pokazano na poniższym diagramie.

Diagram jest podzielony na trzy główne sekcje: dzierżawcy, twoje rozwiązanie oraz identyfikator dzierżawy i identyfikator wdrożenia. Strzałki wskazują z najemców A, B, C i D do pola z etykietą mapowania najemców w sekcji rozwiązań. Ta sekcja zawiera również serwer internetowy i bazę danych na potrzeby wdrożenia 1 i wdrożenia 2. Kolejna strzałka wskazuje z pola mapowania dzierżawcy do sekcji zawierającej identyfikatory dzierżawy i wdrożenia. Najemnicy A i B mają id wdrożenia 1, a najemnicy C i D mają id wdrożenia 2.

Aby uzyskać więcej informacji, zobacz Mapowanie żądań do dzierżawców.

Izolacja najemców

Jednym z najważniejszych czynników w projektowaniu architektury wielodostępnej jest poziom izolacji wymagany przez każdego najemcę. Izolacja może odwoływać się do następujących konfiguracji:

• Posiadanie wspólnej infrastruktury, obejmującej oddzielne wystąpienia aplikacji i oddzielne bazy danych dla każdego klienta.

• Współdzielenie niektórych wspólnych zasobów przy jednoczesnym utrzymywaniu pozostałych zasobów oddzielnie dla każdego dzierżawcy.

• Przechowywanie danych w oddzielnej infrastrukturze fizycznej. W chmurze ta konfiguracja może wymagać oddzielnych zasobów Azure dla każdego dzierżawcy. W skrajnych scenariuszach może nawet wymagać wdrożenia oddzielnej infrastruktury fizycznej przy użyciu dedykowanych hostów.

Zamiast postrzegać izolację jako właściwość dyskretną, rozważ ją jako spektrum. Możesz wdrożyć składniki architektury, które są bardziej izolowane lub mniej odizolowane niż inne składniki w tej samej architekturze, w zależności od wymagań. Na poniższym diagramie przedstawiono kontinuum izolacji:

Diagram przedstawia strzałkę ze w pełni odizolowanej (nic nieudostępnionej) do całkowicie udostępnionej (wszystko udostępnionej). Po w pełni odizolowanej stronie niebieskie pola zawierają oddzielną moc obliczeniową, oddzielne bazy danych, oddzielne sieci i oddzielne nazwy domen. W środku strzałki zielone pola zawierają wspólną moc obliczeniową, współdzieloną sieć i współdzielone nazwy domen. Niebieskie pole zawiera oddzielne bazy danych. Po stronie w pełni udostępnionej zielone pola zawierają udostępnione zasoby obliczeniowe, udostępnioną bazę danych, udostępnioną sieć i udostępnione nazwy domen.

Poziom izolacji wpływa na wiele aspektów architektury:

• Bezpieczeństwo: W przypadku udostępniania infrastruktury między wieloma najemcami, należy zadbać o to, aby nie uzyskiwać dostępu do danych jednego najemcy podczas udzielania odpowiedzi innemu. Potrzebujesz solidnych podstaw dla strategii zarządzania tożsamościami i musisz uwzględnić w procesie autoryzacji zarówno tożsamość dzierżawcy, jak i użytkownika.

• Koszt: Wspólna infrastruktura pozwala na korzystanie przez wielu najemców, co obniża koszty.

• Wydajność: Jeśli udostępniasz infrastrukturę, wydajność systemu może ulec pogorszeniu, ponieważ coraz więcej klientów korzysta z niej, ponieważ zasoby mogą być zużywane szybciej. Najemcy, którzy mają nietypowe wzorce użycia, mogą nasilić problemy z wydajnością.

• Niezawodność: Jeśli używasz jednego zestawu współdzielonej infrastruktury, problem z jednym składnikiem może spowodować awarię dla wszystkich klientów.

• Reagowanie na potrzeby poszczególnych dzierżawców: Gdy wdrażasz infrastrukturę dedykowaną dla jednego dzierżawcy, możliwe jest dostosowanie konfiguracji zasobów do wymagań tego konkretnego dzierżawcy. Możesz nawet rozważyć tę możliwość w modelu cenowym, aby umożliwić klientom płacenie więcej za izolowane wdrożenia.

Architektura rozwiązania może mieć wpływ na dostępne opcje izolacji. Rozważmy na przykład architekturę rozwiązania trójwarstwowego:

• Warstwa interfejsu użytkownika może być udostępnioną wielodostępną aplikacją internetową. Wszyscy użytkownicy uzyskują dostęp do jednej nazwy hosta.

• Warstwa środkowa może pełnić funkcję wspólnej warstwy aplikacji, która posiada współdzielone kolejki komunikatów.

• Warstwa danych może składać się z izolowanych baz danych, tabel lub kontenerów obiektów blob.

Dla każdej warstwy można używać różnych poziomów izolacji. Przy podejmowaniu decyzji o tym, co udostępniać, a co izolować, należy wziąć pod uwagę kilka czynników, w tym koszt, złożoność, wymagania klientów oraz liczbę zasobów, które można wdrożyć przed osiągnięciem limitów i kwot platformy Azure.

Typowe modele dzierżawy

Po ustaleniu wymagań należy je ocenić pod kątem niektórych typowych modeli dzierżawy i odpowiednich wzorców wdrażania.

Zautomatyzowane wdrożenia jednodzierżawne

W zautomatyzowanym modelu wdrażania dla jednego dzierżawcy wdrażasz odpowiedni zestaw infrastruktury dla każdego najemcy, jak pokazano w poniższym przykładzie:

Diagram jest podzielony na trzy sekcje: jedną dla dzierżawy A, jedną dla dzierżawy B i jedną dla dzierżawy C. Strzałka wskazuje z dzierżawy A do pola z etykietą Wdrożenie A. To pole zawiera serwer internetowy dla dzierżawy A. Kolejna strzałka wskazuje z dzierżawy B na pole z etykietą Wdrożenie B. To pole zawiera serwer internetowy dla dzierżawy B. Kolejna strzałka wskazuje z dzierżawy C na pole z etykietą Wdrożenie C. To pole zawiera serwer internetowy dla dzierżawy C.

Twoja aplikacja odpowiada za inicjowanie i koordynowanie wdrażania zasobów każdego dzierżawcy. Zazwyczaj rozwiązania korzystające z tego modelu używają infrastruktury jako kodu lub interfejsów API usługi Azure Resource Manager w szerokim zakresie. Możesz użyć tego podejścia, jeśli musisz aprowizować całkowicie oddzielne infrastruktury dla każdego z klientów. Rozważ zastosowanie wzorca Deployment Stamps podczas planowania wdrożenia.

Korzyści: Kluczową zaletą tego podejścia jest to, że dane dla każdej dzierżawy są izolowane, co zmniejsza ryzyko przypadkowego wycieku. Ochrona ta może być ważna dla klientów, którzy mają wysokie koszty związane ze zgodnością z przepisami. Ponadto najemcy raczej nie wpłyną na wydajność systemu, znany również jako problem hałaśliwego sąsiada. Aktualizacje i zmiany można wdrażać stopniowo w różnych dzierżawach, co zmniejsza prawdopodobieństwo awarii całego systemu.

Ryzyka: W przypadku korzystania z tego podejścia efektywność kosztowa jest niska, ponieważ nie współużytkujesz infrastruktury między dzierżawami. Jeśli jedna dzierżawa wymaga określonego kosztu infrastruktury, prawdopodobnie 100 dzierżaw wymaga 100 razy tego kosztu. Ponadto ciągła konserwacja, na przykład stosowanie nowej konfiguracji lub aktualizacji oprogramowania, może być czasochłonna. Rozważ zautomatyzowanie procesów operacyjnych i rozważ stopniowe stosowanie zmian w środowiskach. Należy również rozważyć inne operacje obejmujące wiele wdrożeń, takie jak raportowanie i analiza całej floty. Zaplanuj sposób wykonywania zapytań dotyczących danych w wielu wdrożeniach i manipulowania nimi.

W pełni wielodzierżawne wdrożenia

W odwrotnej skrajności można rozważyć w pełni wielodostępne wdrożenie, w którym wszystkie składniki są współużytkowane. Masz tylko jeden zestaw infrastruktury do wdrożenia i utrzymania, z którego korzystają wszyscy dzierżawcy, jak pokazano na poniższym diagramie:

Na tym diagramie strzałki wskazują pola oznaczone etykietą Tenant A, Tenant B i Tenant C do pola oznaczonego jako zasoby udostępnione. Tamto pudełko zawiera serwer WWW dla najemców A, B i C.

Korzyści: Ten model jest atrakcyjny, ponieważ rozwiązanie, które ma udostępnione składniki, jest tańsze niż korzystanie z osobnych zasobów dla każdego dzierżawcy. Nawet jeśli musisz wdrożyć wyższe warstwy lub wyższe jednostki SKU zasobów, aby sprostać zwiększonemu obciążeniu, całkowity koszt wdrożenia jest często nadal niższy niż koszt zestawu zasobów dedykowanych jednemu dzierżawcy. Ponadto, jeśli użytkownik lub firma najemca musi przenieść swoje dane do innej dzierżawy, możliwe może być zaktualizowanie identyfikatorów dzierżawy i kluczy, i może nie być konieczne migrowanie danych między dwoma oddzielnymi wdrożeniami.

Ryzyka:

• Pamiętaj, aby oddzielać dane każdego dzierżawcy i nie dopuścić do wycieku danych między dzierżawcami. Może być konieczne zarządzanie danymi fragmentowania. Może być również konieczne rozważenie wpływu, jaki mogą mieć poszczególni najemcy na cały system. Jeśli na przykład duży klient spróbuje wykonać obciążające zapytanie lub operację, może to wpłynąć na innych klientów.

• Określ, jak śledzić i kojarzyć koszty platformy Azure z dzierżawami, jeśli te informacje są dla Ciebie ważne.

• Konserwację można uprościć przy użyciu jednego wdrożenia, ponieważ trzeba zaktualizować tylko jeden zestaw zasobów. Jednak często jest to bardziej ryzykowne, ponieważ zmiany mogą mieć wpływ na całą bazę klientów.

• Może być również konieczne rozważenie skali. Bardziej prawdopodobne jest osiągnięcie limitów skalowania zasobów platformy Azure w przypadku udostępnionego zestawu infrastruktury. Jeśli na przykład używasz konta magazynu w ramach rozwiązania, w miarę zwiększania skali liczba żądań do tego konta magazynu może osiągnąć limit możliwości obsługi konta magazynu. Aby uniknąć osiągnięcia limitu przydziału zasobów, można wdrożyć pulę wielu wystąpień zasobów, takich jak wiele klastrów usługi AKS lub kont magazynu. Możesz nawet rozważyć rozmieszczenie dzierżawców między zasobami wdrażanymi w wielu subskrypcjach platformy Azure.

• Prawdopodobnie istnieje ograniczenie do tego, jak daleko można skalować pojedyncze wdrożenie, a koszty skalowania mogą wzrosnąć nieliniowo. Jeśli na przykład masz pojedynczą udostępnioną bazę danych uruchomioną na dużą skalę, możesz wyczerpać jego przepływność i płacić coraz częściej za zwiększoną przepływność, aby nadążyć za zapotrzebowaniem.

Wdrożenia partycjonowane pionowo

Nie musisz wybierać jednej z skrajności tych skali. Zamiast tego możesz podzielić najemców w pionie, przyjmując następujące podejście:

• Użyj kombinacji wdrożeń jednodostępnych i wielodostępnych. Na przykład możesz mieć większość danych i warstw aplikacji swoich klientów w multitenantowych infrastrukturach, ale wdrażasz infrastrukturę jednostanową dla klientów, którzy wymagają wyższej wydajności lub izolacji danych.

• Wdróż wiele instancji rozwiązania w różnych lokalizacjach geograficznych i przypisz każdego dzierżawcę do konkretnego wdrożenia. Takie podejście jest skuteczne w przypadku dzierżaw w różnych lokalizacjach geograficznych.

Oto przykład ilustrujący wdrożenie współdzielone dla niektórych dzierżawców oraz wdrożenie dla jednego dzierżawcy dla innego dzierżawcy:

Na tym diagramie strzałki wskazują od Najemcy A i Najemcy B do pola z napisem Wdrożenie 1. To pole zawiera serwer WWW dla dzierżawców A i B. Kolejna strzałka wskazuje od dzierżawcy C na pole z etykietą Wdrożenie 2. To pudełko zawiera serwer webowy dla Najemcy C.

Korzyści: Ponieważ nadal udostępniasz część swojej infrastruktury, możesz uzyskać pewne korzyści kosztowe z wykorzystywania współdzielonych środowisk wielodostępnych. Możesz wdrożyć tańsze zasoby udostępnione dla określonych klientów, takich jak klienci, którzy oceniają usługę, korzystając z wersji próbnej. Możesz nawet obciążać klientów wyższą stawką za korzystanie z wdrożenia z jednym dzierżawcą, co ułatwia odzyskanie niektórych kosztów.

Ryzyka: Baza kodu musi być zaprojektowana tak, aby obsługiwała wdrożenia wielodostępne i jednodostępne. Jeśli planujesz zezwolić na migrację między wdrożeniami, trzeba uwzględnić sposób migracji klientów z wdrożenia wielodostępnego do własnego wdrożenia jednodostępnego. Musisz również wiedzieć, którzy z Twoich najemców są objęci każdym wdrożeniem, aby przekazać informacje o problemach z systemem lub aktualizacjach do odpowiednich klientów.

Wdrożenia partycjonowane poziomo

Możesz również horyzontalnie partycjonować swoje wdrożenia. W ramach wdrożenia poziomego niektóre komponenty są współdzielone, ale inne są utrzymywane we wdrożeniach jednodzierżawnych. Można na przykład utworzyć pojedynczą warstwę aplikacji, a następnie wdrożyć poszczególne bazy danych dla każdej dzierżawy, jak pokazano na poniższym diagramie:

Na tym diagramie strzałki wskazują pola oznaczone etykietą Najemca A, Najemca B i Najemca C do pola, które zawiera serwer sieciowy współdzielony przez najemców A, B i C.

Korzyści: Wdrożenia partycjonowane w poziomie mogą pomóc rozwiązać problem z hałaśliwym sąsiadem. Jeśli stwierdzisz, że pewne komponenty powodują większość obciążenia systemu, możesz wdrożyć oddzielne komponenty dla każdego najemcy. Na przykład bazy danych mogą pochłaniać większość obciążenia systemu, ponieważ obciążenie zapytania jest wysokie. Jeśli pojedynczy dzierżawca wysyła dużą liczbę żądań do rozwiązania, wydajność bazy danych może ucierpieć, ale bazy danych innych dzierżawców i współużytkowane składniki, takie jak warstwa aplikacji, pozostają bez zmian.

Ryzyka: W przypadku wdrożenia partycjonowanego w poziomie nadal należy wziąć pod uwagę automatyczne wdrażanie elementów i zarządzanie nimi, zwłaszcza elementy używane przez jednego najemcę.

Testowanie modelu izolacji

Niezależnie od wybranego modelu izolacji należy przetestować rozwiązanie, aby sprawdzić, czy dane jednej dzierżawy nie zostaną przypadkowo ujawnione innemu najemcy i że wszelkie wyniki, na przykład hałaśliwego sąsiada, są akceptowalne. Rozważ użycie usługi Azure Chaos Studio , aby celowo wprowadzać błędy, które symulują awarie w świecie rzeczywistym i sprawdzają odporność rozwiązania nawet wtedy, gdy składniki działają nieprawidłowo.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure

Inni współautorzy:

• Chad Kittel | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
• Paolo Salvatori | Główny inżynier klienta, FastTrack dla Platformy Azure
• Arsen Vladimirskiy | Główny inżynier ds. klientów, FastTrack dla Azure

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następny krok

Weź pod uwagę cykl życia najemców.