Saltar al contenido principal
Multi-tenancy permite que un despliegue sirva contextos de institución independientes (tenants) y mantiene cada solicitud y sus datos dentro del ámbito del tenant autenticado. Lerian opera Lerian Cloud como un entorno multi-tenant. En BYOC, multi-tenancy está disponible solo para los productos y las habilitaciones que lo admiten. Un despliegue BYOC Single-Tenant es una configuración aparte. El alcance por tenant y la configuración son específicos de cada producto. Usa la guía de autenticación y configuración del producto que despliegas. No supongas que una variable de entorno, un claim de JWT o un comportamiento de API documentado para un producto se aplica a otro.

Autenticación y alcance de las solicitudes


Cada producto valida la identidad de quien llama y deriva su contexto de tenant según el contrato de autenticación de ese producto. La plataforma no define un claim tenantId universal ni un header de tenant universal para cada producto. Una integración de producto debe seguir el claim y el comportamiento de enrutamiento documentados de ese producto. No agregues un identificador de tenant a una solicitud a menos que ese producto lo requiera explícitamente.
Multi-tenancy es una capacidad operativa. Esto no significa que cada producto de Lerian tenga el mismo middleware de autenticación o la misma superficie de configuración.

Aislamiento del almacenamiento


  • dedicated: un tenant recibe una base de datos PostgreSQL dedicada.
  • shared: los tenants comparten una base de datos PostgreSQL y cada uno recibe un esquema dedicado.
La división entre base de datos y esquema es específica de PostgreSQL. Otros datastores usan sus propias reglas de enrutamiento y aprovisionamiento por modo. No deduzcas el comportamiento de esquemas de PostgreSQL para MongoDB o RabbitMQ. Elige el modo por servicio según la configuración admitida del servicio, las obligaciones regulatorias, la carga de trabajo esperada y los requisitos de recuperación.

Mover un tenant entre modos


Mover un tenant de almacenamiento compartido a dedicado es una migración planificada por el operador. La plataforma no tiene un workflow automático genérico para esto. Valida la ruta de migración del producto objetivo, los requisitos de consistencia de datos, la ventana de mantenimiento, el plan de backup y restauración, y el procedimiento de rollback antes de cambiar el modo de almacenamiento de un tenant. La identidad del tenant puede permanecer estable, pero no supongas que cada producto puede mover datos entre modos sin una migración específica de la implementación.

Operar cada modelo de despliegue


Lerian Cloud

Lerian opera la infraestructura multi-tenant. Sigue la documentación de API y de autenticación del producto. Tu token y el contrato de enrutamiento del producto determinan el ámbito de la solicitud.

BYOC Multi-Tenant

El operador configura los productos admitidos, los servicios de tenant, el modo de almacenamiento, los recursos subyacentes y la autenticación. Trata la referencia de configuración de cada producto como la fuente autorizada.

BYOC Single-Tenant o desarrollo local

Multi-tenancy no es automático. Los requisitos de autenticación dependen del producto y del entorno. Para Midaz, los despliegues de producción y multi-tenant requieren autenticación. Un despliegue single-tenant fuera de producción que esté permitido puede deshabilitarla.

Páginas relacionadas


Casos de uso

Cómo elegir el aislamiento de PostgreSQL dedicado o compartido.

Modelos de despliegue

Compara Lerian Cloud, BYOC Single-Tenant y las configuraciones BYOC Multi-Tenant admitidas.

Access Manager

Comprende los flujos de autenticación admitidos para los productos que despliegas.