Skip to main content

Изоляция многоарендных систем (Multi-Tenancy Isolation)

Ultimate Multisite: Multi-Tenancy 1.2.0 поддерживает изоляцию базы данных и файловой системы для каждого субсайта в рамках суверенных арендаторов. Это позволяет держать данные арендатора отдельными, сохраняя при этом настройку сети, выставление счетов и администрирование на уровне сети.

Стратегия изоляции (Isolation strategy)​

Используйте суверенную изоляцию для клиентов, которым требуется более сильное разделение данных, выделенное хранилище файловой системы или отдельная граница хоста.

Каждый суверенный арендатор должен иметь:

  • Выделенную базу данных арендатора или стратегию префикса базы данных, одобренную для хоста.
  • Выдельный корень файловой системы арендатора.
  • Запись в реестре арендаторов, которая сопоставляет сайт с его базой данных, корневым путем, именем хоста и моделью изоляции.
  • Результат проверки миграции перед тем, как арендатор будет считаться активным (live).

Привязка к хосту базы данных (Database host binding)​

Версия 1.2.0 меняет поведение по умолчанию для привязки к машине на одном сервере (same-machine host binding) для суверенных установок. Значения, такие как localhost, нормализуются так, чтобы Bedrock, FrankenPHP и контейнеризированные установки WordPress могли предоставлять и проверять разрешения относительно строки хоста, которую видит MySQL на самом деле.

При настройке суверенного арендатора:

  1. Установите хост базы данных на значение, требуемое средой выполнения (runtime) арендатора.
  2. Используйте localhost для установок с локальным сокетом (local socket installs), когда хост ожидает локальных подключений.
  3. Используйте 127.0.0.1 или имя сервиса хоста только тогда, когда сервер базы данных предоставляет привилегии этому хосту.
  4. Запустите проверку миграции после изменения привязки к хосту.

Если отчет о проверке показывает ошибки предоставления разрешений (grant failures), сравните разрешения пользователя в БД арендатора с настроенной привязкой к хосту. Пользователь, которому предоставлены права для user@localhost, отличается от [email protected] или user@%.

Корень файловой системы (Filesystem root)​

Коршуни кормидаи (tenant root) бояд мондастарост ва ташдикиҳо дар ҷараёни муофиқ бо оғози корӣ ва ташдикиҳо мустаҳкам бошад. Аз истифодаи маршрути муваққатии пайвастӣ (temporary mount paths) тавсия дода намешавад. Барои намоиши Bedrock-style, тасдиқ кунед, ки коршуни мондаст вазифаи WordPress ба коршуни веб-и WordPress-и интихобидашудаи мондастро нишон медиҳад, на танҳо коршуни лоиҳаро.

Тартиби таъмин (Provisioning order)​

Барои мондастони мустақилона нав, аз ин тартиб истифода баред:

  1. Эърори реестри мондастро созед.
  2. Базаи маълумоти мондаст ва истифодабаранди базаи маълумот (database user) созед.
  3. Схемаи мондастро оғози корӣ кунед (Bootstrap).
  4. Истифодабарандагони мондастро таъмин кунед.
  5. Равишҳои файзи мондастро тартиб диҳед (Configure tenant filesystem paths).
  6. Тасдиқи мигратсияро идора кунед (Run migration verification).
  7. Баъди тасдиқи муваффақат, маршрутиро ё DNS-ро тағйир диҳед.

Ин тартиб аз он пешӣ мегирад, ки мондастони ба таври қисми аз гирифтаи рафит (traffic) пеш аз омодашавии нависебанд (writer), истифодабарандагон ва файзи система бошад.

Джараёнҳои идоракунии муштариёни мустақилона (Sovereign customer management flows)​

Ultimate Multisite v2.13.0 амалҳои идоракунии муштариёнро дар ҳолати фаъоли карда шудани режим мустақилона (sovereign mode) ба сайт асосӣ мегирад. Мондаст ҳанӯз ҳам метавонад ҳамчун намоиши WordPress-и мустақилона кор кунад, аммо амалҳои рӯ ба рӯи муштариён, ки аз маълумоти бобии шабака (network billing), гирифтадан (membership) ё ҳисоби обрӯйшуда (shared account data) вобастаанд, бояд муштариёнро ба сайт асосӣ санҷанд, ба ҷои кӯшиш кардан барои иҷрои амал дар вақти корнии мондаст.

Дараҷаи дӯстӣ (main-site flow) ба инҳо мебошад:

  • Тасодики пиёла ва тағйироти сарфа (Checkout and plan changes).
  • Назари умумии ҳисоббандӣ ва амалҳои профили муштариён.
  • Тағйироти манзили бобии ҳисоббандӣ ва экранҳои идораи маблағгузорӣ (payment-management screens).
  • Назаруҳои инвой ва тартиби таърих маблағгузории пиёла (Invoice and payment-history views).
  • Амалҳои идораи сайт, ба монанди илова кардани сайтҳо ё нест кардани сайт.
  • Тағйири шаблон (Template switching).
  • Мувофиқ кардани домен ва тағйироти домени асосӣ (Domain mapping and primary-domain changes).

Когда клиент начинает одно из этих действий с суверенного арендатора (tenant), Ultimate Multisite строит соответствующий URL основного сайта и сохраняет исходного арендатора как целевой объект для возврата, когда это безопасно. Это позволяет клиентам завершить управляемое действие по сетевым записям, а затем вернуться в контекст арендатора, не дублируя при этом информацию о выставлении счетов или членстве в суверенной базе данных.

Для операторов практическое правило таково: страницы выставления счетов (billing), учетной записи (account), оформления заказа (checkout), счета (invoice), шаблона (template) и управления доменом (domain-management) должны оставаться доступными на основном сайте для суверенных сетей. Панели арендаторов могут ссылаться на эти страницы, но основной сайт остается источником истины для действия.