Обробка зростаючої кількості орендарів у архітектурі баз даних багатьох орендарів

Обробка скромної кількості клієнтів (орендарів) на загальному сервері з окремими базами даних для кожного екземпляра програми орендаря є відносно простою і зазвичай це правильний спосіб зробити це. В даний час я розглядаю архітектуру програми, де кожен орендар має власний екземпляр бази даних.

Однак проблема полягає в тому, що цей додаток матиме велику кількість орендарів (5000-10000) зі значною кількістю користувачів, можливо 2000 для одного орендаря. Нам потрібно буде підтримувати зростання системи декількома орендарями щотижня.

Крім того, всі орендарі та їх користувачі матимуть загальний процес входу (тобто кожен орендар не може мати власну URL-адресу). Для цього мені потрібен централізований процес входу та засіб для динамічного додавання баз даних до системи та реєстрації користувачів.

• Як міг бути надійно автоматизований процес реєстрації та створення бази даних?

• Чи може процес створення та реєстрації баз даних орендарів у системі спричинити продуктивність чи блокування. Якщо ви думаєте, що це може бути проблемою, чи може хтось запропонувати способи її пом'якшення?

• Як я можу керувати централізованою автентифікацією таким чином, щоб облікові дані користувачів були пов’язані з базою даних конкретного орендаря, але користувач може увійти через загальну сторінку (тобто все через ту саму URL-адресу входу, але їх домашня програма буде знаходитися в певній базі даних орендатора ). Орендарі повинні мати можливість підтримувати власні входи та дозволи, але центральна система входу повинна знати про них. Хтось може запропонувати спосіб це зробити?

• Якщо мені потрібно «розширити масштаб», додавши кілька серверів баз даних, чи може хто-небудь підказати, з якими проблемами я можу мати справу при керуванні ідентифікаторами користувачів на серверах (видання себе тощо) та яким чином пом'якшити ці проблеми?

У нижньому кінці (500 орендарів / 10000 користувачів) ось так я це зробив. По-перше, у вас є "контрольна" база даних, яка є глобальною, центральною і містить всю інформацію про орендарів та користувачів (я дійсно не думаю, що ви хочете керувати ними як реєстраційними системами SQL). Тож уявіть базу даних під назвою "Управління" з такими таблицями:

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;

У нашому випадку, коли ми додали нового орендаря, ми будемо динамічно створювати базу даних, але не тоді, коли користувач адміністратора натискав ОК в інтерфейсі користувача ... у нас було фонове завдання, яке витягувало нові бази даних з черги кожні 5 хвилин, встановлювало модель на single_user , а потім створювали кожну нову базу даних послідовно. Ми зробили це, щоб (а) не допустити, щоб користувач адміністратора чекав на створення бази даних, і (b) щоб уникнути двох користувачів адміністратора, які намагаються створити базу даних одночасно або іншим чином позбавили можливості блокування моделі (необхідна при створенні нової бази даних ).

Бази даних були створені за схемою імен, Tenant000000xxде вони xxпредставлені Tenants.TenantID. Це зробило роботу по обслуговуванню досить легко, замість того , щоб всі види баз даних по імені BurgerKing, McDonalds, і KFCт.д. Не те , щоб ми були в фаст - фуд, просто використовуючи його в якості прикладу.

Причиною того, що ми не виділили тисячі баз даних, як було запропоновано в коментарі, - це те, що користувачі нашого адміністратора, як правило, мали уявлення про те, наскільки великим стане орендар, чи вони мають високий пріоритет, і т. Д. Тому вони мали основний вибір у користувальницькому інтерфейсі: буде диктувати їх початковий розмір та параметри автоматичного зростання, на який диск підсистеми будуть переходити їхні дані / файли журналу, їх налаштування відновлення, графік резервного копіювання, щоб відключитись, і навіть розумно визначити, до якого екземпляру розгорнути базу даних, щоб найкраще збалансувати використання ( хоча наші адміністратори могли це перекрити). Після створення бази даних таблицю орендарів було оновлено обраним екземпляром, для орендаря був створений користувач адміністратора, а нашим адміністраторам було надіслано електронні дані для передачі нового орендатору.

Якщо ви використовуєте єдину точку входу, неможливо дозволити кільком орендарям мати користувачів з одним і тим же ім'ям користувача. Ми вирішили використовувати адресу електронної пошти, яка - якщо всі користувачі працюють у компанії та використовують їх корпоративну електронну адресу - має бути добре. Хоча наше рішення з часом стало складнішим з двох причин:

1. У нас були консультанти, які працювали на більш ніж одного з наших клієнтів і потребували доступу до декількох
2. У нас були орендарі, які насправді складалися з кількох орендарів

Отже, ми закінчили TenantUsersтаблицю, яка дозволила одному користувачеві асоціюватися з кількома орендарями.

Спочатку, коли користувач увійде в систему, додаток буде знати рядок підключення лише для бази даних керування. Коли логін успішний, він може побудувати рядок з'єднання на основі знайденої інформації. Напр

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;

Тепер додаток може підключитися до бази даних користувача (кожен користувач мав орендаря за замовчуванням ) або користувач міг вибрати один із орендарів, до яких вони могли отримати доступ. Потім програма просто отримає новий рядок підключення та перенаправить на головну сторінку цього орендаря.

Якщо ви потрапите в запропоновану вами область користування 10 мм, вам, безумовно, знадобиться, щоб це було краще збалансовано. Ви можете федерацію програми, щоб вони мали різні точки входу, що з'єднуються з різними базами даних управління. Якщо ви надаєте кожному орендареві субдомен (наприклад, TenantName.YourApplicationDomain.com), ви можете це робити за кадром за допомогою DNS / маршрутизації, не перебиваючи їх, коли вам потрібно масштабувати далі.

Тут є набагато більше - на кшталт @Darin, я тут лише дряпаю поверхню. Повідомте мене, якщо вам потрібна безкоштовна консультація. :-)

У вас є досить цікавий проект. Я ніколи прямо не бачив, щоб хтось намагався реалізувати щось таке велике, принаймні на SQL Server. Чим більше я читаю твій пост, тим більше питань виникає ...

Найгірший інфраструктурний сценарій (що насправді найкращий сценарій для бізнесу), вам потрібно 10К баз даних, що користуються 2 к. Користувачів. Це 20 000 000 користувачів. Ви не будете успішними у спробах керувати 20 M входами на SQL Server. ІМО. Якраз їхня кількість, що стосується переміщення їх з сервера на сервер, спостереження за зіткненнями ID та невідповідними ідентифікаторами, плюс я не впевнений, як би поводився SQL Server із 20-ми рядками в sys.server_principals. Крім того, ваш веб-додаток, ймовірно, захоче підключитися як окрема або дуже мала кількість користувачів. IIS не може з'єднати з'єднання, якщо їхні рядки DSN не однакові. Одним з атрибутів рядка DSN є ім'я користувача. Різні користувачі означають відсутність об'єднання.

Вам знадобиться розгорнути власну схему облікових даних користувачів. Потрібно мати можливість з'ясувати, до якого орендаря належить користувач, і тоді для вашого веб-коду потрібно буде вибрати належну базу даних. Ці метадані користувача є критичними, їх потрібно буде десь зберігати, їх потрібно буде кластеризувати або відобразити в дзеркалі, потрібно буде бути швидкими, і вони повинні бути добре захищені (з точки зору безпеки. IOW, зашифруйте його.). Якщо припустити, що SQL - це навіть гарна ідея, я б утримав цю базу даних від випадків, коли орендарі серверів. Це допомагає з точки зору безпеки та з точки зору навантаження, хоча я б здогадався, що після того, як користувачі перевіряються і веб-додаток керується правильною базою даних в іншому екземплярі, більше не буде запитів щодо цих метаданих користувачів, пов'язаних з цим. користувач.

Швидке запитання: чи слід дозволити двом різним користувачам, які належать до двох орендарів, мати одне ім’я користувача?

Ще одне швидке запитання: якщо я скажу вам, що працюю в FuBar, Inc., то як ви це знаєте? FuBar збирається надати вам список користувачів, а ви повернете їм список імен користувачів або вони збираються самостійно надавати?

Вам потрібно буде перейти в багато примірників. Якщо навіть частина цих користувачів вирішить потрапити на програму відразу, один екземпляр розтане. У ньому не буде достатньо робочих ниток, щоб одразу запустити всі ці запити. Якщо одночасно потрапляє лише 1000 користувачів, то, ймовірно, не вистачить робочих ниток, і запит почне складатись і чекати. Я бачив, як це відбувається; Найближчим симптомом є те, що нові з'єднання не зможуть увійти в екземпляр, оскільки немає доступних робочих потоків для їх обслуговування. Якщо це дуже короткотривала поведінка, ваш додаток може вижити. Якщо ні, або ваш додаток суєтний, користувачі отримають помилки.

Навіть якщо у вас не буде багато орендарів, ви повинні почати думати про майбутнє та автоматизацію, тому що, коли ви побачите, що ваш сервер завалений і з’являється 10 нових орендарів, щоб вивести в Інтернет, це вже дуже пізно і ваша послуга (і ваші клієнти та ваші найближчі колишні клієнти будуть страждати, поки ви не напишете вихід із проблеми.

Вам знадобиться спосіб переміщення баз даних, від перевантажених серверів до слабо завантажених (або нових) серверів. Від того, чи зможете ви отримати вільний час простою, буде залежати від вашої угоди про рівень обслуговування.

Ви надаєте конкретну програму, наприклад SalesForce, або ці бази даних є лише контейнерами для того, що хочуть розмістити ваші орендарі?

Наскільки великі бази даних? Якщо вони не дуже великі, ви можете просто відновити з файлу резервної копії, який надає шаблон. (Це не сильно відрізняється від того, що робить база даних моделей, але я ще не бачив, щоб хтось справді використовував модель по-хорошому з моїх днів з SQL 6.5.) Після відновлення шаблону до нового імені бази даних, ви могли б потім налаштуйте нову базу даних за потребою конкретного орендаря. Ви, очевидно, не можете виконати налаштування перед тим, як придбати орендаря. Якщо база даних велика, ви можете дотримуватися тієї ж основної процедури, за винятком того, як відновлення виконуєте достроково, перш ніж будь-який новий орендар потребує місця. Ви можете тримати кілька таких баз даних, можливо, одну на примірник. Якщо ви будете тримати занадто багато навколо, це змусить вас придбати більше обладнання та / або сховища, ніж вам потрібно,

Якщо це ваш власний додаток, як ви збираєтеся обробляти оновлення схем? Як ви збираєтеся підтримувати версії бази даних прямо з версіями коду, якщо ви використовуєте одну URL-адресу, яка потрапляє у ваш веб-додаток?

Як виявити та знищити бази даних, які вже не використовуються? Ви чекаєте, поки ваша група A / R скаже, що хтось не сплатив їх рахунок протягом трьох місяців?

Якщо орендарі керують дозволами, це означає, що вони мають певне розуміння внутрішнього функціонування програми або що ваша програма має дуже просту структуру ролей. Використовуючи щось на зразок Blogger як приблизний приклад, користувачі можуть (читати публікації), (читати публікації та робити коментарі), (... і створювати публікації), (... та редагувати публікації інших), (... та можуть скинути паролі інших користувачів) або (... і що завгодно). Визначення ролі для кожного з цих різних наборів прав та привласнення користувача до тієї чи іншої ролі не повинно бути надто важким, але ви не хочете, щоб ваш додаток працював із заявами "GRANT". Слідкуйте за ролями, які мають ієрархію і залежать від спадщини, це може стати заплутаним. Якщо ви рекламуєте або демонструєте користувача, я б сказав, витягніть їх із усіх пов’язаних ролей, а потім додайте їх до тієї ролі, яка їм потрібна. О,

Я думаю, що тут я лише подряпав поверхню, і ця посада вже занадто довга. Те, що вам справді потрібно, - це книга або хоча б довідка від того, хто це зробив. Більшість із цих хлопців не будуть розмовляти, якщо вони вважають це конкурентною перевагою.