Hacer solo una separación de carpetas en un entorno multi-tenant no es aislamiento real.
En entornos de MSP y proveedores de servicios, usar un appliance separado para cada cliente es costoso, difícil de gestionar e ineficiente en términos de capacidad. Pero ejecutar todos los clientes en un único dispositivo solo con una separación por nombre o carpeta tampoco es suficiente. Si los límites de tráfico, log, red, recursos y permisos no se separan con claridad, los tenants pueden afectarse entre sí.
En entornos que requieren cumplimiento, esta separación se vuelve aún más crítica. Si distintos alcances de seguridad como PCI, datos sanitarios o clasificación gubernamental van a funcionar sobre el mismo recurso físico, debe poder demostrarse a qué recursos, a qué red y a qué logs puede acceder cada tenant. Solo el etiquetado por software no basta para dar confianza en la mayoría de los escenarios.
En las estructuras multi-tenant, el consumo de recursos también genera riesgo operativo. El número de conexiones de un tenant, su intensidad de tráfico, su volumen de log o una configuración errónea no deben afectar el rendimiento de los demás tenants. Por eso, los límites de CPU, memoria, disco, interfaz de red y flujo deben planificarse a nivel de tenant.
El enfoque correcto es tratar cada tenant como una zona de trabajo separada; separar los recursos, la red, el log, la auditoría y los permisos de gestión según el límite del tenant. El aislamiento de tenants debe aplicarse no solo a nivel de UI, sino también en el plano de tráfico y recursos.
La Virtualización vTenant de TR7 ofrece este modelo: al ejecutar múltiples tenants sobre un único TR7, hace gestionables por separado los límites de recursos, red y operación.
Nuestro enfoque
La arquitectura vTenant de TR7 se construye con un enfoque de espacio de trabajo independiente por tenant, recursos de red asignados, contexto de tráfico aislado y cuota de recursos.
Cada tenant se trata como una zona de trabajo separada
vTenant es un espacio de trabajo independiente con su propio límite de gestión y tráfico dentro de un único dispositivo. Cada tenant puede usar sus propios servicios, contexto de red, logs y ajustes de recursos de forma separada de los demás tenants.
Se proporciona una interfaz de red y un espacio de tráfico separados por tenant
Las interfaces físicas se pueden compartir entre los tenants con funciones virtuales o estructuras de slot asignadas a cada tenant. Así, cada tenant recibe tráfico a través de su propia superficie de red y no se mezcla con el tráfico de otros tenants.
El contexto de red se separa a nivel de tenant
Cada tenant puede tener su propio contexto de IP, route, firewall e interfaz. Los mismos rangos de IP se pueden usar en distintos tenants sin colisión, y el tráfico se evalúa según el límite del tenant.
Los límites de CPU, memoria, disco y flujo se asignan por tenant
Para cada tenant se pueden planificar núcleos de procesador, memoria, espacio de disco y límites de conexión/flujo. Este modelo reduce que el consumo de recursos de un tenant afecte a los demás tenants.
Capacidades
La Virtualización vTenant separa la estructura multi-tenant a nivel de recursos, red, identidad, log y operación.
El espacio de trabajo independiente por tenant proporciona aislamiento multi-cliente
Cada vTenant se gestiona como un espacio de trabajo separado. Las estructuras de vService, certificado, regla, red y log definidas dentro del tenant permanecen dentro de sus propios límites. Los MSP y proveedores de servicios pueden ejecutar distintos clientes lado a lado sobre el mismo TR7. Este modelo reduce el número de dispositivos físicos mientras mantiene el aislamiento operativo.
El ciclo de vida del tenant cubre los flujos de arranque, parada y reinicio
Cada tenant se puede gestionar con un comportamiento de ciclo de vida separado. El tenant se puede arrancar, parar, reiniciar o configurar con un comportamiento de arranque automático. Esto asegura que, mientras se hace mantenimiento sobre un tenant, los demás tenants no se vean afectados. Los equipos de operaciones pueden ejecutar ventanas de mantenimiento por cliente o por entorno.
Una porción de ancho de banda por inquilino, presente en todo momento
Al inquilino se le da una parte fija de la capacidad del equipo, descontada del total del dispositivo al crearlo, y la aplicación ocurre en el propio equipo y no en una hoja de cálculo. La parte deliberadamente no es work-conserving: el ancho de banda de un inquilino inactivo no se presta al vecino cargado, así que lo que vendió está disponible en el segundo en que el cliente lo pide — predictibilidad antes que utilización. El tráfico se pauta en vez de descartarse: un inquilino en su techo se ralentiza en lugar de perder paquetes.
La asignación de núcleos de CPU por tenant reduce el ruido de recursos
TR7 puede planificar los núcleos de CPU asignables a los tenants teniendo en cuenta los núcleos reservados para el host. A los tenants críticos se les pueden asignar más recursos de procesador, y los tenants de baja intensidad se pueden ejecutar con recursos más limitados. Esto reduce que el tráfico intenso de un cliente afecte el plano de control de los demás tenants. La gestión de recursos pasa a formar parte de la planificación de capacidad.
El espacio de disco por tenant refuerza la separación de datos y logs
Para cada tenant se puede reservar un disco de trabajo separado y un espacio de datos en bruto. Se puede empezar con valores por defecto y planificar por tenant a medida que crece la necesidad. Los logs, informes, configuración y datos temporales se mantienen dentro del límite del tenant. Esta estructura es importante para el cumplimiento y la separación operativa de datos.
La asignación de interfaz asistida por hardware separa el tráfico de los tenants
Desde las interfaces de red físicas se pueden asignar funciones virtuales a los tenants. Cada tenant recibe y envía tráfico a través de su propio slot de interfaz. Este enfoque proporciona una separación de tráfico más fuerte que el etiquetado por software. En los tenants de alta intensidad, el rendimiento y el aislamiento se mantienen juntos.
El control de trust y spoof de interfaz gestiona el comportamiento de red del tenant
En las interfaces asignadas al tenant se pueden gestionar los ajustes de control de confianza y spoof. Esto asegura que el tenant use su propio comportamiento de MAC y tráfico dentro de los límites esperados. Especialmente en redes multi-tenant, los comportamientos de dirección erróneos o en colisión se controlan de forma temprana. La seguridad de red pasa a ser parte natural del límite del tenant.
El modelo de prefijo MAC y slot evita la colisión de direcciones
TR7 puede generar direcciones MAC únicas para las interfaces de tenant con la estructura de macprefix y slot. Este modelo combina un prefijo de 3 bytes con la información de tenant/slot para proporcionar un direccionamiento ordenado. Cuando se definen numerosos tenants e interfaces sobre el mismo dispositivo, el riesgo de colisión disminuye. El equipo de red sigue las interfaces de tenant de forma más legible.
El campo de bits de zona e interfaz proporciona una planificación de tenants escalable
TR7 planifica la capacidad de tenants e interfaces con los campos de bits de device, zone e interface. El campo de zona de 6 bits ofrece un modelo de direccionamiento de hasta 64 tenants, y el campo de interface de 5 bits de hasta 32 interfaces por tenant. Esta estructura proporciona un escalado ordenado en instalaciones grandes de MSP y multi-entorno. El crecimiento del tenant se vincula desde el principio a un modelo de capacidad previsible.
El contexto de red separado soporta el aislamiento de route y firewall
Cada tenant puede tener su propia vista de IP, route, firewall e interfaz. Los mismos rangos de IP privadas se pueden usar en distintos tenants sin colisión. Esto reduce el clásico problema de colisión de direcciones RFC1918 en entornos multi-cliente. El tráfico se evalúa en el contexto del tenant y no se mezcla con el espacio de red equivocado.
La visibilidad de log y auditoría por tenant reduce la fuga de datos
El flujo de log y auditoría de cada tenant se puede tratar por separado. Los registros operativos de un tenant no son visibles para otro tenant. Esta separación es de importancia crítica en los procesos de privacidad del cliente, cumplimiento e investigación de incidentes. A nivel de gestión central, los usuarios autorizados pueden hacer reporting por tenant.
La ejecución de comandos internos soporta el ciclo de vida del tenant y las operaciones de diagnóstico
Con el envío controlado de comandos al interior del tenant se pueden ejecutar operaciones de ciclo de vida, salud y diagnóstico. Esto permite ejecutar operaciones sin afectar todo el dispositivo al investigar problemas o hacer mantenimiento específicos del tenant. Los permisos de comando se pueden limitar con RBAC y auditoría. Los equipos de soporte hacen diagnósticos más rápidos en el contexto del tenant.
La gestión central y el RBAC hacen auditable la visibilidad del tenant
El lado de Central Management puede ver y gestionar los tenants de forma agrupada. Con RBAC se puede limitar qué tenant puede ver o modificar cada usuario. En escenarios de MSP se puede hacer una separación de permisos por cliente. La facilidad de gestión y la privacidad del tenant se mantienen dentro del mismo modelo.
Profundidad operativa
La operación de vTenant se ejecuta junto con los valores de disco por defecto, la planificación de CPU, los campos de bits, el modelo de IP de gestión, la asignación de interfaz y la generación de direcciones MAC.
Plan de disco por defecto
Para cada tenant se puede definir un disco de trabajo por defecto y un espacio de datos en bruto. La instalación rápida se hace sobre valores iniciales por defecto de 20 GB para el disco de trabajo y 30 GB para el espacio de datos en bruto; la capacidad se puede aumentar según la intensidad de producción. El volumen de log e informes debe tenerse en cuenta por separado en la planificación de disco.
Cuenta de recursos de CPU
Restando la reserva apartada para el host del número total de núcleos, se forma un pool de núcleos asignables a los tenants. A los tenants críticos se les pueden asignar más núcleos. Este modelo combina el aislamiento de recursos con la planificación de capacidad.
Capacidad del campo de bits
Los campos de bits de device, zone e interface forman un modelo de direccionamiento de 12 bits en total. El campo de zona de 6 bits proporciona una capacidad de 64 tenants, y el campo de interface de 5 bits una capacidad de 32 interfaces por tenant. Estos valores aclaran el plan de escala en instalaciones grandes.
IP de gestión del tenant
Para cada tenant se puede generar una IP local con fines de gestión. Esta IP se puede usar en los flujos de ciclo de vida, salud y gestión interna del tenant. El tráfico de gestión debe tratarse por separado del tráfico de datos del tenant.
Modelo de slot de interfaz
En las interfaces asignadas al tenant se puede mantener información como slot, número de VF, espacio MAC y MTU. Este modelo asegura que los recursos de red físicos se distribuyan de forma ordenada entre los tenants. Al cambiar el plan de slots, el impacto en la red debe evaluarse con cuidado.
Generación de prefijo MAC
Añadiendo la información de tenant y slot sobre un macprefix de 3 bytes se pueden generar direcciones MAC únicas. Esta estructura reduce la colisión de direcciones y facilita el seguimiento de a qué tenant pertenece cada interfaz. Proporciona legibilidad para la operación de red.
En qué escenarios se usa
Múltiples clientes sobre un único TR7 en un entorno de MSP
Un proveedor de servicios puede ejecutar 30 clientes como vTenants separados. Cada cliente tiene su propio espacio de red, log, regla y recursos; la operación se simplifica sobre un único dispositivo.
Separar el alcance PCI por tenant en banca
El tenant que procesa datos de tarjeta y el tenant de tráfico web corporativo pueden funcionar como espacios de trabajo separados sobre el mismo TR7. La separación de recursos, red y auditoría refuerza la prueba de cumplimiento.
Ejecutar entornos de dev y prod aislados en salud
Las organizaciones sanitarias pueden mantener el tráfico de test, desarrollo y producción en tenants separados. Los datos de pacientes de prod y el tráfico de desarrollo se separan entre sí mientras se gestionan desde el mismo panel de operación.
Separar servicios clasificados y abiertos en el sector público
Las instituciones públicas pueden ejecutar servicios de distinto nivel de seguridad en tenants separados. La red, el log y los permisos de acceso se separan por tenant, reduciendo el riesgo de acceso indebido.
Instalación de triple entorno test, staging y producción
Sobre el mismo TR7 se pueden crear tenants de test, staging y producción. Los cambios de aplicación se validan con un comportamiento ADC/WAAP similar antes de llevarse a producción.
Preguntas frecuentes
¿Cuál es la diferencia entre vTenant y la multi-tenancy por software clásica?
¿Cuántos tenants se pueden ejecutar al mismo tiempo?
¿Es obligatoria una interfaz de red separada para cada tenant?
¿El mantenimiento de un tenant afecta a los demás tenants?
¿Cómo funciona la separación de log y auditoría de vTenant?
¿Cómo funciona vTenant con Central Management?
Monte su entorno multi-tenant con un único TR7
Estructura de tenants para entornos de MSP, banca, salud y sector público con aislamiento de recursos, red y operación. Hagamos una demostración en vivo en su propia instalación.