Istnieje wiele sposobów, aby rozważyć, jak pracować z dzierżawami w rozwiązaniu. Wybór podejścia zależy od tego, czy i jak udostępniasz zasoby między dzierżawami. Intuicyjnie możesz uniknąć udostępniania wszelkich zasobów, ale takie podejście szybko staje się kosztowne w miarę skalowania firmy i dołączania większej liczby dzierżaw.
Jeśli wziąć pod uwagę różne modele wielodostępności, warto najpierw wziąć pod uwagę sposób definiowania dzierżaw dla organizacji, czynników biznesowych i planowania skalowania rozwiązania. Ten artykuł zawiera wskazówki ułatwiające osobom podejmującym decyzje techniczne ocenę modeli najmu i ich kompromisów.
Definiowanie dzierżawy
Najpierw należy zdefiniować dzierżawę dla organizacji. Zastanów się, kim jest Twój klient. Innymi słowy, kim świadczysz usługi? Istnieją dwa typowe modele:
- Firma-firma (B2B). Jeśli twoi klienci są innymi organizacjami, prawdopodobnie zamapujesz dzierżawy na tych klientów. Należy jednak rozważyć, czy klienci mają działy (zespoły lub działy) oraz czy mają obecność w wielu krajach/regionach. Może być konieczne mapowania pojedynczego klienta na wiele dzierżaw, jeśli istnieją różne wymagania dla tych podgrup. Podobnie klient może chcieć zachować dwa wystąpienia usługi, aby zachować oddzielone od siebie środowiska programistyczne i produkcyjne. Ogólnie rzecz biorąc, jedna dzierżawa ma wielu użytkowników. Na przykład wszyscy pracownicy klienta będą użytkownikami w ramach jednej dzierżawy.
- Firma-odbiorca (B2C). Jeśli klienci są konsumentami, często bardziej skomplikowane jest powiązanie klientów, dzierżaw i użytkowników. W niektórych scenariuszach każdy użytkownik może być oddzielną dzierżawą. Należy jednak rozważyć, czy twoje 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 usługa przesyłania strumieniowego muzyki może obsługiwać zarówno poszczególnych użytkowników, jak i rodzin, i może traktować każdy z tych typów kont inaczej, gdy oddziela je do dzierżaw.
Definicja dzierżawy będzie mieć wpływ na niektóre elementy, które należy wziąć pod uwagę lub podkreślić podczas tworzenia architektury rozwiązania. Rozważmy na przykład następujące typy dzierżaw:
- Jeśli Dzierżawcy są osobami lub rodzinami, może być szczególnie zaniepokojony sposobem obsługi danych osobowych oraz przepisami dotyczącymi suwerenności danych w każdej jurysdykcji, którą obsługujesz.
- Jeśli dzierżawcy są firmami, może być konieczne pamiętanie o wymaganiach klientów dotyczących zgodności z przepisami, izolacji danych i upewnieniu się, że spełniasz określony cel poziomu usług (SLO), na przykład czas pracy lub dostępność usług.
Jak zdecydować, 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:
- Jakie są cele biznesowe?
- Czy klienci będą akceptować wszystkie formy wielodostępności? Jak każdy model wielodostępności ma wpływ na wymagania dotyczące zgodności lub wymagania dotyczące zgodności klienta?
- Czy rozwiązanie z jedną dzierżawą będzie skalowane do przyszłych aspiracji wzrostu?
- Jak duży jest twój zespół operacyjny i ile zarządzania infrastrukturą można zautomatyzować?
- Czy klienci oczekują, że spełnisz umowy dotyczące poziomu usług (SLA), czy masz umowy SLA, dla których dążysz?
Jeśli oczekujesz, że twoja firma będzie skalować do dużej liczby klientów, ważne jest wdrożenie udostępnionej infrastruktury. W przeciwnym razie konieczne będzie utrzymanie dużej i rosnącej floty wystąpień. Wdrażanie poszczególnych zasobów platformy Azure dla każdego klienta może być niezrównane, chyba że aprowizacja i użycie dedykowanej subskrypcji dla każdej dzierżawy. Jeśli współużytkujesz tę samą subskrypcję platformy Azure w wielu dzierżawach, przydziały zasobów platformy Azure i limity mogą zacząć obowiązywać, a koszty operacyjne wdrażania i ponownego konfigurowania tych zasobów zwiększają się wraz z każdym nowym klientem.
Z drugiej strony, jeśli spodziewasz się, że twoja firma będzie miała tylko kilku klientów, warto rozważyć użycie zasobów z jedną dzierżawą przeznaczonych dla każdego klienta. Ponadto jeśli wymagania dotyczące izolacji klientów są wysokie, może być odpowiednia infrastruktura z jedną dzierżawą.
Dzierżawy i wdrożenia
Następnie należy określić, co oznacza dzierżawa dla konkretnego rozwiązania i czy należy odróżnić dzierżawy logiczne i wdrożenia.
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 (a nawet dziesiątki tysięcy) użytkowników. W miarę rozwoju możesz jednak stwierdzić, że konieczne jest zduplikowanie rozwiązania lub niektórych jego składników w celu skalowania do nowego zapotrzebowania klientów. Oznacza to, że musisz określić sposób przypisywania określonych klientów do określonych wystąpień rozwiązania. Możesz przypisać klientów losowo lub geograficznie albo wypełniając pojedyncze wystąpienie, a następnie uruchamiając inne. Jednak prawdopodobnie musisz zachować rekord klientów i infrastrukturę, w której są dostępne ich dane i aplikacje, aby można było kierować ruch do odpowiedniej infrastruktury. W tym przykładzie możesz reprezentować każdego klienta jako oddzielną dzierżawę, a następnie mapować użytkowników na wdrożenie zawierające ich dane. Istnieje mapowanie jeden do wielu między dzierżawami i wdrożeniami, a dzierżawy można przenosić między wdrożeniami według własnego uznania.
Z kolei należy wziąć pod uwagę firmę, która tworzy oprogramowanie w chmurze dla firm prawnych. Klienci mogą nalegać na posiadanie własnej dedykowanej infrastruktury w celu zachowania standardów zgodności. W związku z tym należy przygotować się do wdrożenia wielu różnych wystąpień rozwiązania i zarządzania nimi od samego początku. W tym przykładzie wdrożenie zawsze zawiera jedną dzierżawę, a dzierżawa jest mapowana na własne dedykowane wdrożenie.
Kluczową różnicą między dzierżawami i wdrożeniami jest sposób wymuszania izolacji. Gdy wiele dzierżaw współużytkuje jedno wdrożenie (zestaw infrastruktury), zazwyczaj polega się na kodzie aplikacji i identyfikatorze dzierżawy, który znajduje się w bazie danych, aby zachować oddzielne dane każdej dzierżawy. Jeśli masz dzierżawy z własnymi dedykowanymi wdrożeniami, mają własną infrastrukturę, dlatego może być mniej ważne, aby kod wiedział, że działa w środowisku wielodostępnym.
Wdrożenia są czasami nazywane supertenantami lub sygnaturami.
Po otrzymaniu żądania dla określonej dzierżawy należy zamapować je na wdrożenie zawierające dane tej dzierżawy, jak pokazano poniżej:
Izolacja dzierżawy
Jednym z największych zagadnień związanych z projektowaniem architektury wielodostępnej jest poziom izolacji, którego potrzebuje każda dzierżawa. Izolacja może oznaczać różne rzeczy:
- Posiadanie pojedynczej udostępnionej infrastruktury z oddzielnymi wystąpieniami aplikacji i oddzielnymi bazami danych dla każdej dzierżawy.
- Udostępnianie niektórych typowych zasobów, ale przechowywanie innych zasobów oddzielnie dla każdej dzierżawy.
- Przechowywanie danych w oddzielnej infrastrukturze fizycznej. W chmurze ta konfiguracja może wymagać oddzielnych zasobów platformy Azure dla każdej dzierżawy. Może to nawet oznaczać wdrażanie oddzielnej infrastruktury fizycznej przy użyciu dedykowanych hostów.
Zamiast myśleć o izolacji jako dyskretnej właściwości, należy myśleć o tym jako o kontinuum. Składniki architektury, które są mniej lub bardziej izolowane niż inne składniki w tej samej architekturze, można wdrażać w zależności od wymagań. Na poniższym diagramie przedstawiono kontinuum izolacji:
Poziom izolacji ma wpływ na wiele aspektów architektury, w tym następujące:
- Zabezpieczenia. W przypadku udostępniania infrastruktury między wieloma dzierżawami należy zachować szczególną ostrożność, aby nie uzyskiwać dostępu do danych z jednej dzierżawy po powrocie odpowiedzi do innej. Potrzebujesz silnej podstawy strategii tożsamości i musisz wziąć pod uwagę zarówno tożsamość dzierżawy, jak i użytkownika w procesie autoryzacji.
- Koszty. Współużytkowana infrastruktura może być używana przez wiele dzierżaw, więc jest tańsza.
- Wydajność. Jeśli współużytkujesz infrastrukturę, wydajność systemu może ucierpieć w miarę korzystania z niej większej liczby klientów, ponieważ zasoby mogą być zużywane szybciej.
- Niezawodność. Jeśli używasz jednego zestawu udostępnionej infrastruktury, problem ze składnikami jednej dzierżawy może spowodować awarię dla wszystkich użytkowników.
- Czas odpowiedzi na potrzeby poszczególnych dzierżaw. Podczas wdrażania infrastruktury dedykowanej dla jednej dzierżawy można dostosować konfigurację zasobów do wymagań tej dzierżawy. Możesz nawet rozważyć tę funkcję w modelu cenowym, dzięki czemu klienci będą płacić więcej za wdrożenia izolowane.
Architektura rozwiązania może wpływać 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ą, a wszyscy dzierżawcy uzyskują dostęp do pojedynczej nazwy hosta.
- Warstwa środkowa może być warstwą aplikacji współużytkowanej z udostępnionymi kolejkami komunikatów.
- Warstwę danych można odizolować od baz danych, tabel lub kontenerów obiektów blob.
Możesz rozważyć użycie różnych poziomów izolacji w każdej warstwie. Należy podjąć decyzję o tym, co jest udostępniane i co jest odizolowane od wielu zagadnień, w tym kosztów, złożoności, wymagań klientów i liczby zasobów, które można wdrożyć przed osiągnięciem limitów przydziałów i limitów 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 z jedną dzierżawą
W zautomatyzowanym modelu wdrażania z jedną dzierżawą wdrażasz dedykowany zestaw infrastruktury dla każdej dzierżawy, jak pokazano w tym przykładzie:
Aplikacja jest odpowiedzialna za inicjowanie i koordynowanie wdrażania zasobów każdej dzierżawy. Zazwyczaj rozwiązania korzystające z tego modelu używają infrastruktury jako kodu (IaC) 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. Podczas planowania wdrożenia należy wziąć pod uwagę wzorzec sygnatur wdrażania .
Korzyści: Kluczową zaletą tego podejścia jest to, że dane dla każdej dzierżawy są izolowane, co zmniejsza ryzyko przypadkowego wycieku. To zabezpieczenie może być ważne dla niektórych klientów, którzy mają wysokie obciążenie związane ze zgodnością z przepisami. Ponadto dzierżawy są mało prawdopodobne, aby wpływać na wydajność systemu nawzajem, problem, który jest czasami nazywany głośnym problemem sąsiada . Aktualizacje i zmiany można wdrażać stopniowo w różnych dzierżawach, co zmniejsza prawdopodobieństwo awarii całego systemu.
Ryzyka: Jeśli korzystasz z tego podejścia, efektywność kosztowa jest niska, ponieważ nie udostępniasz infrastruktury dzierżawcom. Jeśli jedna dzierżawa wymaga pewnego kosztu infrastruktury, 100 dzierżaw prawdopodobnie wymaga 100 razy tego kosztu. Ponadto ciągła konserwacja (na przykład stosowanie nowej konfiguracji lub aktualizacji oprogramowania) prawdopodobnie będzie czasochłonna. Rozważ automatyzację 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 w całej infrastrukturze. Podobnie należy zaplanować sposób wykonywania zapytań i manipulowania danymi w wielu wdrożeniach.
Wdrożenia w pełni wielodostępne
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 konserwacji, a wszystkie dzierżawy go używają, jak pokazano na poniższym diagramie:
Korzyści: Ten model jest atrakcyjny, ponieważ rozwiązanie z udostępnionymi składnikami jest tańsze. Nawet jeśli musisz wdrożyć wyższe warstwy lub jednostki SKU zasobów, ogólny koszt wdrożenia jest często nadal niższy niż koszt zestawu zasobów z jedną dzierżawą. Ponadto jeśli użytkownik lub dzierżawa musi przenieść swoje dane do innej dzierżawy, może być możliwe zaktualizowanie identyfikatorów i kluczy dzierżawy i nie trzeba migrować danych między dwoma oddzielnymi wdrożeniami.
Ryzyka:
Pamiętaj, aby oddzielić dane dla każdej dzierżawy i nie wyciekaj danych między dzierżawami. Może być konieczne zarządzanie danymi fragmentowania. Ponadto może być konieczne zaniepokojenie skutkami, jakie mogą mieć poszczególne dzierżawy w całym systemie. Jeśli na przykład duża dzierżawa próbuje wykonać duże zapytanie lub operację, może to mieć wpływ na inne dzierżawy.
Określ, jak śledzić i kojarzyć koszty platformy Azure z dzierżawami, jeśli jest to dla Ciebie ważne.
Konserwacja może być prostsza w przypadku pojedynczego wdrożenia, ponieważ wystarczy 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 skalowania. 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żesz rozważyć wdrożenie wielu wystąpień zasobów (na przykład wielu klastrów usługi AKS lub kont magazynu). Możesz nawet rozważyć dystrybucję dzierżaw między zasobami wdrażanych w wielu subskrypcjach platformy Azure.
Prawdopodobnie istnieje ograniczenie do tego, jak daleko można skalować pojedyncze wdrożenie, a koszty tego mogą wzrosnąć nieliniowo. Jeśli na przykład masz pojedynczą udostępnioną bazę danych, po uruchomieniu na bardzo dużą skalę możesz wyczerpać jego przepływność i płacić coraz więcej za zwiększoną przepływność, aby nadążyć za zapotrzebowaniem.
Wdrożenia partycjonowane w pionie
Nie musisz wybierać jednej z skrajności tych skali. Zamiast tego można rozważyć partycjonowanie w pionie dzierżaw, stosując następujące podejście:
- Użyj kombinacji wdrożeń jednodostępnych i wielodostępnych. Możesz na przykład mieć większość warstw danych i aplikacji klientów w infrastrukturze wielodostępnej, ale wdrażać infrastrukturę z jedną dzierżawą dla klientów, którzy wymagają wyższej wydajności lub izolacji danych.
- Wdróż wiele wystąpień rozwiązania geograficznie i zamapuj każdą dzierżawę na określone wdrożenie. Takie podejście jest szczególnie skuteczne w przypadku dzierżaw w różnych lokalizacjach geograficznych.
Oto przykład przedstawiający wdrożenie udostępnione dla niektórych dzierżaw i wdrożenie z jedną dzierżawą dla innego:
Korzyści: Ponieważ nadal udostępniasz infrastrukturę, możesz uzyskać niektóre korzyści wynikające z używania współużytkowanych wdrożeń wielodostępnych. Możesz wdrożyć tańsze zasoby udostępnione dla niektórych klientów, takich jak klienci oceniający usługę przy użyciu wersji próbnej. Możesz nawet rozliczać klientów wyższą stawkę, aby korzystać z wdrożenia z jedną dzierżawą, co powoduje ponowne wykorzystanie niektórych kosztów.
Ryzyka: Baza kodu prawdopodobnie będzie musiała być zaprojektowana pod kątem obsługi wdrożeń wielodostępnych i wdrożeń z jedną dzierżawą. Jeśli planujesz zezwolić na migrację między infrastrukturami, należy wziąć pod uwagę sposób migrowania klientów z wdrożenia wielodostępnego do własnego wdrożenia z jedną dzierżawą. Musisz również wiedzieć, które dzierżawy znajdują się w każdym wdrożeniu, aby móc komunikować się z informacjami o problemach z systemem lub uaktualnieniach do odpowiednich klientów.
Wdrożenia partycjonowane w poziomie
Możesz również rozważyć partycjonowanie poziome wdrożeń. W przypadku wdrożenia w poziomie masz pewne składniki udostępnione, ale utrzymujesz inne składniki z wdrożeniami z jedną dzierżawą. 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:
Korzyści: Wdrożenia partycjonowane w poziomie mogą pomóc w rozwiązaniu problemu z hałaśliwym sąsiadem, jeśli zidentyfikujesz, że większość obciążenia systemu jest spowodowana przez określone składniki, które można wdrożyć oddzielnie dla każdej dzierżawy. Na przykład bazy danych mogą pochłaniać większość obciążenia systemu, ponieważ obciążenie zapytania jest wysokie. Jeśli jedna dzierżawa wysyła dużą liczbę żądań do rozwiązania, wydajność bazy danych może być negatywnie dotknięta, ale bazy danych innych dzierżaw (i składniki udostępnione, takie jak warstwa aplikacji), pozostaną nienaruszone.
Ryzyka: W przypadku wdrożenia partycjonowanego w poziomie nadal należy wziąć pod uwagę automatyczne wdrażanie składników i zarządzanie nimi, zwłaszcza składniki używane przez jedną dzierżawę.
Testowanie modelu izolacji
Niezależnie od wybranego modelu izolacji należy przetestować rozwiązanie, aby sprawdzić, czy dane jednej dzierżawy nie zostały przypadkowo ujawnione do innego i że wszelkie hałaśliwy efekt sąsiada jest akceptowalny . Rozważ użycie narzędzia Azure Chaos Studio , aby celowo wprowadzić błędy, które symulują rzeczywiste awarie i sprawdzają odporność rozwiązania nawet wtedy, gdy składniki działają nieprawidłowo.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Został pierwotnie napisany przez następujących współautorów.
Główny autor:
- John Downs | Główny inżynier klienta, fasttrack dla platformy Azure
Inni współautorzy:
- Chad Kittel | Główny inżynier oprogramowania
- Paolo Salvatori | Główny inżynier klienta, fasttrack dla platformy Azure
- Arsen Władimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure
Aby wyświetlić niepublice profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
Weź pod uwagę cykl życia dzierżaw