Em ambientes de MSP e provedor de serviços, usar um appliance separado para cada cliente é caro, difícil de gerenciar e ineficiente em termos de capacidade. No entanto, rodar todos os clientes em um único appliance apenas com separação por nome ou pasta também não basta. Se os limites de tráfego, log, rede, recursos e permissões não forem nitidamente separados, os tenants podem afetar uns aos outros.
Em ambientes que exigem conformidade, essa separação torna-se ainda mais crítica. Se diferentes escopos de segurança, como PCI, dados de saúde ou classificação do setor público, vão rodar sobre o mesmo recurso físico, deve ser comprovável a quais recursos, a qual rede e a quais logs cada tenant pode acessar. A mera marcação por software não basta para dar confiança na maioria dos cenários.
Em estruturas multi-tenant, o consumo de recursos também gera risco operacional. O número de conexões, a intensidade de tráfego, o volume de logs ou uma configuração incorreta de um tenant não devem afetar o desempenho dos outros tenants. Por isso, os limites de CPU, memória, disco, interface de rede e fluxo devem ser planejados no nível do tenant.
A abordagem correta é tratar cada tenant como uma zona de trabalho separada; separar recursos, rede, log, auditoria e permissões de gerenciamento conforme o limite do tenant. O isolamento de tenant deve ser aplicado não apenas no nível da interface de usuário, mas também no plano de tráfego e de recursos.
A Virtualização vTenant da TR7 oferece este modelo: ao executar vários tenants em um único TR7, torna gerenciáveis separadamente os limites de recursos, rede e operação.
A arquitetura vTenant da TR7 é construída com a abordagem de espaço de trabalho independente por tenant, recursos de rede atribuídos, contexto de tráfego isolado e cota de recursos.
O vTenant é um espaço de trabalho independente com limite de gerenciamento e de tráfego separado dentro de um único appliance. Cada tenant pode usar seus próprios serviços, contexto de rede, logs e configurações de recursos de forma separada dos demais tenants.
As interfaces físicas podem ser compartilhadas com funções virtuais ou estruturas de slot atribuídas aos tenants. Assim, cada tenant recebe tráfego por sua própria superfície de rede e não se mistura com o tráfego de outros tenants.
Cada tenant pode ter seu próprio contexto de IP, rota, firewall e interface. As mesmas faixas de IP podem ser usadas em tenants diferentes sem conflito, e o tráfego é avaliado conforme o limite do tenant.
Para cada tenant podem ser planejados núcleos de processador, memória, espaço em disco e limites de conexão/fluxo. Este modelo reduz a possibilidade de o consumo de recursos de um tenant afetar os demais tenants.
A Virtualização vTenant separa a estrutura multi-tenant nos níveis de recursos, rede, identidade, log e operação.
Cada vTenant é gerenciado como um espaço de trabalho separado. As estruturas de vService, certificado, regra, rede e log definidas dentro do tenant permanecem dentro de seus próprios limites. MSPs e provedores de serviços podem rodar clientes diferentes lado a lado no mesmo TR7. Este modelo reduz o número de appliances físicos enquanto preserva o isolamento operacional.
Cada tenant pode ser gerenciado com comportamento de ciclo de vida separado. O tenant pode ser iniciado, parado, reiniciado ou configurado com comportamento de inicialização automática. Isso garante que, durante a manutenção de um tenant, os demais tenants não sejam afetados. As equipes de operação podem executar janelas de manutenção por cliente ou por ambiente.
A TR7 pode planejar núcleos de CPU atribuíveis aos tenants levando em conta os núcleos reservados ao host. Mais recursos de processador podem ser alocados a tenants críticos, e tenants de baixa intensidade podem rodar com recursos mais limitados. Isso reduz a possibilidade de o tráfego intenso de um cliente afetar o plano de controle dos demais tenants. A gestão de recursos torna-se parte do planejamento de capacidade.
Para cada tenant pode ser alocado um disco de trabalho e um espaço de dados brutos separados. Pode-se começar a partir de valores padrão e fazer o planejamento por tenant à medida que a necessidade aumenta. Logs, relatórios, configuração e dados temporários são mantidos dentro do limite do tenant. Esta estrutura é importante para a conformidade e a separação operacional de dados.
A partir das interfaces de rede físicas podem ser atribuídas funções virtuais aos tenants. Cada tenant recebe e envia tráfego por seu próprio slot de interface. Esta abordagem proporciona uma separação de tráfego mais forte do que a marcação por software. Em tenants de alta intensidade, o desempenho e o isolamento são preservados em conjunto.
Nas interfaces atribuídas ao tenant podem ser gerenciadas as configurações de confiança e de controle de spoof. Isso garante que o tenant use seu próprio comportamento de MAC e de tráfego dentro dos limites esperados. Especialmente em redes multi-tenant, comportamentos de endereço incorretos ou conflitantes são controlados precocemente. A segurança de rede torna-se parte natural do limite do tenant.
A TR7 pode gerar endereços MAC únicos para as interfaces de tenant com a estrutura de macprefix e slot. Este modelo combina um prefixo de 3 bytes com a informação de tenant/slot para proporcionar um endereçamento ordenado. Quando um grande número de tenants e interfaces é definido no mesmo appliance, o risco de conflito diminui. A equipe de rede acompanha as interfaces de tenant de forma mais legível.
A TR7 planeja a capacidade de tenant e de interface com os campos de bits de device, zone e interface. Um campo de zone de 6 bits oferece um modelo de endereçamento de até 64 tenants, e um campo de interface de 5 bits, de até 32 interfaces por tenant. Esta estrutura proporciona um escalonamento ordenado em grandes instalações de MSP e de múltiplos ambientes. O crescimento de tenant é vinculado a um modelo de capacidade previsível desde o início.
Cada tenant pode ter sua própria visão de IP, rota, firewall e interface. As mesmas faixas de IP privadas podem ser usadas em tenants diferentes sem conflito. Isso reduz o clássico problema de conflito de endereços RFC1918 em ambientes multicliente. O tráfego é avaliado no contexto do tenant e não se mistura à zona de rede errada.
O fluxo de log e auditoria de cada tenant pode ser tratado separadamente. Os registros operacionais de um tenant não são vistos por outro tenant. Esta separação é de importância crítica para a privacidade do cliente, a conformidade e os processos de investigação de incidentes. No nível do gerenciamento central, usuários autorizados podem fazer relatórios por tenant.
Com o envio controlado de comandos para dentro do tenant podem ser executadas operações de ciclo de vida, saúde e diagnóstico. Isso permite executar operações de investigação ou manutenção específicas do tenant sem afetar todo o appliance. As permissões de comando podem ser restringidas com RBAC e auditoria. As equipes de suporte fazem o diagnóstico mais rapidamente no contexto do tenant.
O lado do Central Management pode ver e gerenciar os tenants de forma agregada. Com o RBAC pode ser restringido qual tenant cada usuário pode ver ou alterar. Em cenários de MSP, pode ser feita a separação de permissões por cliente. A facilidade de gerenciamento e a privacidade do tenant são preservadas dentro do mesmo modelo.
A operação do vTenant é conduzida junto com os valores padrão de disco, o planejamento de CPU, os campos de bits, o modelo de IP de gerenciamento, a atribuição de interface e a geração de endereços MAC.
Para cada tenant pode ser definido um disco de trabalho e um espaço de dados brutos padrão. A instalação rápida é feita a partir de valores iniciais padrão de 20 GB para o disco de trabalho e 30 GB para o espaço de dados brutos; a capacidade pode ser aumentada conforme a intensidade de produção. O volume de logs e relatórios deve ser considerado separadamente no planejamento de disco.
A partir do número total de núcleos, descontando a reserva alocada ao host, é criado um pool de núcleos atribuíveis aos tenants. Mais núcleos podem ser atribuídos a tenants críticos. Este modelo combina o isolamento de recursos com o planejamento de capacidade.
Os campos de bits de device, zone e interface formam um modelo de endereçamento de 12 bits no total. Um campo de zone de 6 bits proporciona capacidade de 64 tenants, e um campo de interface de 5 bits, capacidade de 32 interfaces por tenant. Esses valores esclarecem o plano de escala em grandes instalações.
Para cada tenant pode ser gerado um IP local para fins de gerenciamento. Esse IP pode ser usado nos fluxos de ciclo de vida, saúde e gerenciamento interno do tenant. O tráfego de gerenciamento deve ser tratado separadamente do tráfego de dados do tenant.
Nas interfaces atribuídas ao tenant podem ser mantidas informações como slot, número de VFs, espaço MAC e MTU. Este modelo permite distribuir os recursos de rede físicos aos tenants de forma ordenada. Ao alterar o plano de slot, o impacto na rede deve ser avaliado com cuidado.
Sobre o macprefix de 3 bytes, acrescentando a informação de tenant e slot, podem ser gerados endereços MAC únicos. Esta estrutura reduz o conflito de endereços e facilita rastrear a qual tenant cada interface pertence. Proporciona legibilidade para a operação de rede.
O provedor de serviços pode rodar 30 clientes como vTenants separados. Cada cliente tem seu próprio espaço de rede, log, regra e recursos; a operação se simplifica em um único appliance.
O tenant que processa dados de cartão e o tenant de tráfego web corporativo podem rodar como espaços de trabalho separados no mesmo TR7. A separação de recursos, rede e auditoria fortalece a evidência de conformidade.
As instituições de saúde podem manter o tráfego de teste, desenvolvimento e produção em tenants separados. Os dados de pacientes de produção e o tráfego de desenvolvimento são gerenciados a partir do mesmo painel de operação, mas separados entre si.
As instituições públicas podem rodar serviços de diferentes níveis de segurança em tenants separados. A rede, os logs e as permissões de acesso são separados por tenant, reduzindo o risco de acesso indevido.
No mesmo TR7 podem ser criados tenants de teste, staging e produção. As alterações de aplicação são validadas com comportamento semelhante de ADC/WAAP antes de irem para produção.
Estrutura de tenant para ambientes de MSP, bancário, de saúde e do setor público com isolamento de recursos, rede e operação. Façamos uma demonstração ao vivo na sua própria instalação.