Virtualizando a Gi LAN – O que fazer e o que não fazer
Após muitos anos de discussões e provas de conceitos, a virtualização de funções de rede (NFV) está agora passando do estágio conceitual para o estágio de realização.
Alguns provedores de serviços começaram a implementar plataformas de infraestrutura NFV, enquanto alguns deles já habilitaram seus primeiros casos de uso e aplicativos habilitados para NFV nessas plataformas.
A virtualização do núcleo de pacotes evoluído (EPC) e da Gi LAN é um desses casos de uso que tem muita força no setor no momento.
Ao implantar uma Gi LAN virtual, há duas questões fundamentais que precisam ser respondidas. A primeira pergunta é sobre consolidação: consolidamos várias funções da Gi LAN em uma única função de rede virtual (VNF) ou decompomos completamente a arquitetura da Gi LAN em muitas VNFs discretas?
A segunda questão é sobre escala. Como podemos dimensionar efetivamente essa arquitetura, já que uma única máquina virtual pode não fornecer capacidade suficiente para lidar com a carga de trabalho da Gi LAN?
Para proteger e monetizar suas redes, as operadoras de telefonia móvel têm implantado muitas tecnologias diferentes na Gi LAN, incluindo, mas não se limitando a otimização de TCP, otimização de vídeo, enriquecimento de cabeçalho, inspeção profunda de pacotes, firewall Gi e NAT de nível de operadora (CGNAT).
Historicamente, muitas dessas funções foram implantadas em diferentes plataformas, geralmente de fornecedores diferentes. Nos últimos anos, as operadoras de telefonia móvel vêm consolidando e simplificando sua arquitetura Gi LAN.
Por meio da consolidação, as operadoras de telefonia móvel conseguiram reduzir significativamente seu custo total de propriedade. Ao migrar essa arquitetura para uma plataforma NFV – que depende de hardware comum pronto para uso – pode haver a tentação de começar a decompor a arquitetura em diferentes VNFs discretos, cada um dedicado a uma única função.
Essa arquitetura decomposta certamente faz sentido se as diferentes funções da Gi LAN forem aplicáveis a um subconjunto muito específico de fluxos. Com base em políticas de negócios por meio da interação com uma Função de Regras de Política e Cobrança (PCRF), um mecanismo de classificação de serviço inteligente que ficaria na entrada da Gi LAN pode determinar quais fluxos precisam ser direcionados e/ou encadeados para funções específicas que são implantadas como VNFs separadas. Essas VNFs terão então que processar apenas o tráfego necessário para agir, o que resulta em uma distribuição muito eficiente do tráfego entre todas as VNFs.
Entretanto, se as funções Gi LAN precisam ser aplicadas a quase todo o tráfego, essa decomposição de funções não traz nenhum valor. Tomemos como exemplos a otimização de TCP e firewalls Gi. Quase todo o tráfego Gi LAN precisa ser processado por essas duas funções, portanto, consolidá-las em um único VNF resulta em ganhos de eficiência semelhantes a uma implantação física.
De fato, não há necessidade de um classificador de serviço inteligente aqui para fazer uma seleção de VNF e não há nenhuma conexão de entrada e saída da camada SDN para obter tráfego de um VNF para o outro. Além disso, adicionar uma função de firewall sobre uma função de otimização de TCP adiciona muito pouca sobrecarga de CPU, então o valor da consolidação ainda se aplica em um ambiente NFV .
Outro desafio é como lidar com fluxos de trabalho maiores do que um único VNF pode suportar. Alguns fornecedores adotaram a abordagem de permitir que uma VNF consista em muitas máquinas virtuais (VMs). A maioria das funções na Gi LAN são operações com estado, o que significa que o tráfego de entrada e saída para os mesmos fluxos precisam ser processados na mesma VM. Como resultado, se o tráfego de saída chegar em uma VM diferente que processou o tráfego de entrada, a comunicação entre VMs será necessária para que o tráfego retorne à VM correta. Isso obviamente resultará em degradação do desempenho.
Na F5, escolhemos a abordagem pela qual uma VNF é sempre implantada como uma única VM e o dimensionamento da arquitetura para múltiplas VMs se torna um fator de design externo. Existem diferentes técnicas de expansão disponíveis, desde as mais simples até as mais avançadas.
Uma arquitetura de expansão muito simples é baseada no hash de tráfego baseado em IP entre diferentes VMs, como o multicaminho de custo igual (ECMP). No entanto, essa técnica tem várias desvantagens e é impraticável para a maioria dos casos de uso na Gi LAN. Abordagens baseadas em SDN para controlar a distribuição de tráfego podem evitar algumas dessas limitações do ECMP, mas os recursos ainda seriam um tanto limitados e dependem muito do player SDN escolhido.
De longe, a abordagem mais flexível e avançada para dimensionar qualquer função Gi LAN que seja totalmente independente da rede subjacente e/ou SDN é fornecida por um balanceador de carga baseado em software sem estado (que também é implantado como VMs). O fato de ser sem estado permite que ele seja dimensionado quase indefinidamente, pois mais VMs para balanceamento de carga sem estado podem ser adicionadas sem perder a consistência de como o tráfego é distribuído entre as VMs que fornecem as funções de Gi LAN.
Com base no exposto acima, acreditamos que é muito importante para qualquer operadora de telefonia móvel pensar cuidadosamente sobre os aspectos de consolidação e expansão ao migrar sua arquitetura Gi LAN da camada física para a virtual.