Obsługa rosnącej liczby najemców w architekturze baz danych wielu dzierżawców

Obsługa niewielkiej liczby klientów (dzierżawców) na wspólnym serwerze z osobnymi bazami danych dla każdego wystąpienia aplikacji każdego dzierżawcy jest stosunkowo prosta i zwykle jest to właściwy sposób. Obecnie patrzę na architekturę aplikacji, w której każdy dzierżawca ma własną instancję bazy danych.

Problem polega jednak na tym, że ta aplikacja będzie miała dużą liczbę najemców (5000–10 000) i znaczną liczbę użytkowników, być może 2000 na jednego najemcę. Będziemy musieli wspierać rozwój systemu przez kilku najemców co tydzień.

Ponadto wszystkim najemcom i ich użytkownikom zostanie przedstawiony wspólny proces logowania (tzn. Każdy najemca nie może mieć własnego adresu URL). Aby to zrobić, potrzebuję scentralizowanego procesu logowania i środków do dynamicznego dodawania baz danych do systemu i rejestrowania użytkowników.

• W jaki sposób można skutecznie zautomatyzować proces rejestracji i tworzenia bazy danych?

• Czy proces tworzenia i rejestrowania baz danych najemców w systemie może powodować problemy z wydajnością lub blokowaniem. Jeśli uważasz, że może to być problem, czy ktoś może zasugerować sposoby jego złagodzenia?

• Jak zarządzać centralnym uwierzytelnianiem w taki sposób, aby dane uwierzytelniające użytkownika były powiązane z bazą danych konkretnego najemcy, ale użytkownik może zalogować się za pośrednictwem wspólnej strony (tj. Za pośrednictwem tego samego adresu URL logowania, ale ich aplikacja domowa będzie znajdować się w bazie danych konkretnego najemcy ). Najemcy będą musieli zachować własne loginy i uprawnienia, ale centralny system logowania musi o nich wiedzieć. Czy ktoś może zasugerować sposób na zrobienie tego?

• Jeśli muszę „skalować” poprzez dodanie wielu serwerów baz danych, czy ktoś może zasugerować, z jakimi problemami mogę sobie poradzić w zarządzaniu tożsamościami użytkowników na różnych serwerach (personifikacja itp.) Oraz w jaki sposób można je rozwiązać?

W dolnej części (500 najemców / 10000 użytkowników) tak to zrobiłem. Po pierwsze, masz „kontrolną” bazę danych, która jest globalna, centralna i zawiera wszystkie informacje o najemcach i użytkownikach (naprawdę nie sądzę, że chcesz zarządzać nimi jako logowaniami uwierzytelniającymi SQL). Wyobraź sobie więc bazę danych o nazwie „Sterowanie” z następującymi tabelami:

CREATE TABLE dbo.Instances
(
  InstanceID INT PRIMARY KEY,
  Connection VARCHAR(255)
  --, ...
);

INSERT dbo.Instances SELECT 1, 'PROD1\Instance1';
INSERT dbo.Instances SELECT 1, 'PROD2\Instance1';
-- ...

CREATE TABLE dbo.Tenants
(
  TenantID INT PRIMARY KEY,
  Name NVARCHAR(255) NOT NULL UNIQUE,
  InstanceID INT -- Foreign key tells which instance this tenant's DB is on
  --, ...
);

INSERT dbo.Tenants SELECT 1, 'MyTenant', 1;
-- ...

CREATE TABLE dbo.Users
(
  UserID INT PRIMARY KEY,
  Username VARCHAR(320) NOT NULL UNIQUE,
  PasswordHash VARBINARY(64), -- because you never store plain text, right?
  TenantID INT -- foreign key
  --, ...
);

INSERT dbo.Users SELECT 1, 'foo@bar.com', 0x43..., 1;

W naszym przypadku, gdy dodaliśmy nowego dzierżawę, zbudowalibyśmy bazę danych dynamicznie, ale nie wtedy, gdy administrator kliknął OK w interfejsie użytkownika ... mieliśmy zadanie w tle, które co 5 minut ściągało nowe bazy danych z kolejki, ustaw model na single_user , a następnie utworzył szeregowo każdą nową bazę danych. Zrobiliśmy to, aby (a) uniemożliwić administratorowi czekanie na utworzenie bazy danych oraz (b) aby uniknąć dwóch użytkowników administujących próbujących jednocześnie utworzyć bazę danych lub w inny sposób pozbawionych możliwości zablokowania modelu (wymagane podczas tworzenia nowej bazy danych ).

Bazy danych zostały utworzone przy użyciu schematu nazw, w Tenant000000xxktórym są xxreprezentowane Tenants.TenantID. To sprawiło, że prace konserwacyjne dość łatwe, zamiast wszystkich rodzajów baz danych o nazwie BurgerKing, McDonalds, KFCitp Nie, że byliśmy w fast food, tylko przy użyciu tego jako przykład.

Powodem, dla którego nie przydzieliliśmy wstępnie tysięcy baz danych, jak sugeruje komentarz, jest to, że nasi administratorzy zwykle mieli pojęcie o tym, jak duży stanie się najemca, czy mają wysoki priorytet itp. Więc mieli podstawowe opcje w interfejsie użytkownika, które dyktuje ich początkowy rozmiar i ustawienia autogrowth, do którego podsystemu dyskowego trafią ich pliki danych / dziennika, ustawienia odzyskiwania, harmonogram tworzenia kopii zapasowych, a nawet inteligentne informacje o tym, w której instancji należy wdrożyć bazę danych, aby jak najlepiej zrównoważyć wykorzystanie ( chociaż nasi administratorzy mogą to zmienić). Po utworzeniu bazy danych tabela dzierżawy została zaktualizowana o wybraną instancję, dla dzierżawcy utworzono administratora, a nasi administratorzy otrzymali e-mailem poświadczenia, aby przekazać je nowemu dzierżawcy.

Jeśli korzystasz z jednego punktu wejścia, nie jest możliwe zezwolenie, aby wielu najemców posiadało użytkowników o tej samej nazwie użytkownika. Zdecydowaliśmy się na użycie adresu e-mail, który - jeśli wszyscy użytkownicy pracują dla firmy i korzystają z firmowego adresu e-mail - powinien być w porządku. Chociaż nasze rozwiązanie w końcu stało się bardziej złożone z dwóch powodów:

1. Mieliśmy konsultantów, którzy pracowali dla więcej niż jednego z naszych klientów i potrzebowaliśmy dostępu do wielu
2. Mieliśmy najemców, którzy sami faktycznie składali się z wielu najemców

W rezultacie powstała TenantUserstabela, która pozwoliła powiązać jednego użytkownika z wieloma najemcami.

Początkowo, gdy użytkownik się loguje, aplikacja zna parametry połączenia tylko dla sterującej bazy danych. Gdy logowanie się powiedzie, może zbudować ciąg połączenia na podstawie znalezionych informacji. Na przykład

SELECT i.Connection
  FROM dbo.Instances AS i
  INNER JOIN dbo.Tenants AS t
  ON i.InstanceID = t.InstanceID
  INNER JOIN dbo.TenantUsers AS u
  ON i.TenantID = u.TenantID
  WHERE u.UserID = @UserID;

Teraz aplikacja może połączyć się z bazą danych użytkownika (każdy użytkownik ma domyślnego najemcę) lub użytkownik może wybrać jednego z najemców, do których ma dostęp. Aplikacja po prostu pobierałaby nowy ciąg połączenia i przekierowywała na stronę główną dla tego najemcy.

Jeśli przejdziesz do proponowanego obszaru użytkownika 10 MM, na pewno będziesz potrzebować go lepiej zbalansować. Możesz stowarzyszyć aplikację, aby miała różne punkty wejścia łączące się z różnymi kontrolnymi bazami danych. Jeśli podasz każdemu lokatorowi subdomenę (np. TenantName.YourApplicationDomain.com), możesz to zrobić za kulisami za pomocą DNS / routingu bez przerywania ich, gdy będziesz potrzebować dalszego skalowania.

Jest o wiele więcej - jak @Darin, drapię tylko powierzchnię. Daj mi znać, jeśli potrzebujesz bezpłatnej konsultacji. :-)

Masz całkiem interesujący projekt. Nigdy bezpośrednio nie widziałem, żeby ktoś próbował wdrożyć coś tak dużego, przynajmniej na SQL Server. Im więcej czytam Twojego posta, tym więcej pytań napotykam ...

Najgorszy scenariusz z punktu widzenia infrastruktury (który w rzeczywistości jest najlepszym scenariuszem z perspektywy biznesowej), potrzebujesz 10 tys. Baz danych razy 2 tys. Użytkowników. To 20 000 000 użytkowników. Nie odniesiesz sukcesu w zarządzaniu logowaniami 20 M SQL Server. IMO. Tylko ich liczba, zajmująca się przenoszeniem ich z serwera na serwer, uważaniem na kolizje identyfikatorów i niedopasowane identyfikatory, a także nie jestem pewien, jak SQL Server zachowałby się z 20 milionami wierszy w sys.server_principals. Ponadto Twoja aplikacja internetowa prawdopodobnie będzie chciała połączyć się jako pojedynczy lub bardzo mała liczba użytkowników. Usługi IIS nie mogą pulować połączeń, chyba że ich ciągi DSN są identyczne. Jednym z atrybutów ciągu DSN jest nazwa użytkownika. Różni użytkownicy oznaczają brak puli.

Będziesz musiał stworzyć własny schemat poświadczeń użytkownika. Musi być w stanie dowiedzieć się, do którego dzierżawy należy użytkownik, a następnie kod internetowy będzie musiał wybrać odpowiednią bazę danych. To, że metadane użytkownika są krytyczne, będą musiały gdzieś być przechowywane, będą musiały być klastrowane lub dublowane, będą musiały być szybkie i będą musiały być dobrze chronione (z punktu widzenia bezpieczeństwa. IOW, szyfruj.). Zakładając, że SQL jest tu nawet dobrym pomysłem, trzymałbym tę bazę danych z dala od instancji dzierżawców serwerów. Pomaga to z punktu widzenia bezpieczeństwa i z punktu widzenia ładowania, choć zgaduję, że po zatwierdzeniu użytkowników i skierowaniu aplikacji internetowej do poprawnej bazy danych w innej instancji nie będzie więcej zapytań dotyczących metadanych tego użytkownika związanych z tym użytkownik.

Szybkie pytanie: czy dwóch różnych użytkowników należących do dwóch różnych najemców powinno mieć taką samą nazwę użytkownika?

Kolejne szybkie pytanie: jeśli powiem ci, że pracuję dla FuBar, Inc., skąd to wiesz? Czy FuBar dostarczy ci listę użytkowników, a ty zwrócisz im listę nazwisk użytkowników, czy też zamierzają samodzielnie się zaopatrywać?

Będziesz musiał przejść do wielu instancji. Jeśli nawet niewielka część tych użytkowników zdecyduje się na natychmiastowe uruchomienie aplikacji, jedna instancja stopi się. Nie będzie mieć wystarczającej liczby wątków roboczych, aby uruchomić wszystkie te żądania naraz. Jeśli tylko 1000 użytkowników uderzy w Twoje wystąpienie w tym samym czasie, prawdopodobnie zabraknie wątków roboczych, a żądanie zacznie się gromadzić i czekać. Widziałem, jak to się dzieje; najbliższym objawem jest to, że nowe połączenia nie będą mogły zalogować się do instancji, ponieważ nie ma dostępnych wątków roboczych do ich obsługi. Jeśli jest to bardzo krótkotrwałe zachowanie, aplikacja może przetrwać. Jeśli nie, lub Twoja aplikacja jest wybredna, użytkownicy otrzymają błędy.

Nawet jeśli nie będziesz mieć wielu najemców, powinieneś zacząć myśleć o przyszłości i automatyzacji, ponieważ gdy zobaczysz, że twój serwer jest zawieszony i jest 10 nowych najemców do wprowadzenia do Internetu, jest o wiele za późno, a twoje usługi (i Twoi klienci i Twoi przyszli klienci będą cierpieć, dopóki nie rozwiążesz problemu.

Będziesz potrzebować sposobu na przenoszenie baz danych, od przeciążonych serwerów do lekko obciążonych (lub nowych) serwerów. To, czy możesz uzyskać okno przestoju, będzie zależeć od Twojej umowy SLA.

Czy udostępniasz konkretną aplikację, taką jak SalesForce, czy te bazy danych to tylko kontenery na wszystko, co chcą najemcy?

Jak duże są bazy danych? Jeśli nie są bardzo duże, możesz po prostu przywrócić z pliku kopii zapasowej, który zawiera szablon. (Nie różni się to znacznie od tego, co robi baza danych modelu, ale nie widziałem, aby ktoś naprawdę dobrze korzystał z modelu od czasów, gdy korzystałem z SQL 6.5.) Po przywróceniu szablonu do nowej nazwy bazy danych, możesz następnie dostosuj nową bazę danych do potrzeb konkretnego najemcy. Oczywiście nie można dokonać personalizacji przed wynajęciem najemcy. Jeśli baza danych jest duża, możesz wykonać tę samą podstawową procedurę, chyba że przywrócisz wcześniej, zanim jakikolwiek nowy najemca zajmie miejsce. Możesz przechowywać kilka takich baz danych, może jedną na instancję. Jeśli trzymasz ich zbyt wiele, może to zmusić Cię do zakupu większej ilości sprzętu i / lub pamięci masowej niż potrzebujesz,

Jeśli to Twoja aplikacja, jak zamierzasz obsługiwać aktualizacje schematów? Jak zamierzasz utrzymywać wersje bazy danych prosto z wersjami kodu, jeśli używasz jednego adresu URL, który dostaje się do Twojej aplikacji internetowej?

Jak wykrywać i niszczyć bazy danych, które nie są już używane? Czy czekasz, aż twoja grupa A / R powie, że ktoś nie zapłacił rachunku przez trzy miesiące?

Jeśli dzierżawcy zarządzają uprawnieniami, oznacza to, że rozumieją wewnętrzne działanie aplikacji lub że aplikacja ma bardzo prostą strukturę ról. Korzystając z czegoś takiego jak Blogger jako przykładu, użytkownicy mogą (czytać posty), (czytać posty i komentować), (... i tworzyć posty), (... i edytować posty innych), (... i mogą resetować hasła innych użytkowników) lub (... i cokolwiek). Posiadanie roli dla każdego z tych różnych zestawów praw i przypisywanie użytkownika do jednej lub innej roli nie powinno być zbyt trudne, ale nie chcesz, aby aplikacja uruchamiała instrukcje „GRANT”. Uważaj na role, które mają hierarchię i zależą od dziedziczenia, może to być mylące. Jeśli promujesz lub degradujesz użytkownika, powiedziałbym, że wyciągnij go ze wszystkich powiązanych ról, a następnie dodaj z powrotem do jednej roli, której potrzebują. O,

Myślę, że tylko podrapałem tutaj powierzchnię, a ten post jest już za długi. To, czego naprawdę potrzebujesz, to książka lub przynajmniej dokument od kogoś, kto to zrobił. Większość z nich nie będzie mówić, jeśli uznają to za przewagę konkurencyjną.