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.
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.
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.
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.
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.
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.
La Virtualización vTenant separa la estructura multi-tenant a nivel de recursos, red, identidad, log y operación.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.