Após muitos anos de discussões e provas de conceito, a virtualização de funções de rede (NFV) está agora deixando a fase conceitual e avançando para a fase de implementação.
Alguns provedores de serviços começaram a implantar plataformas de infraestrutura de NFV, enquanto alguns deles já viabilizaram seus primeiros casos de uso e aplicações com suporte a NFV nessas plataformas.
A virtualização do núcleo de pacotes evoluído (EPC) e da LAN Gi é um desses casos de uso que atualmente conta com grande adesão do setor.
Ao implantar uma Gi LAN virtual, há duas questões fundamentais que precisam ser respondidas. A primeira diz respeito à consolidação: devemos consolidar várias funções da Gi LAN em uma única função de rede virtual (VNF) ou decompor completamente a arquitetura da Gi LAN em várias VNFs distintas?
A segunda questão diz respeito à escalabilidade. Como podemos escalar essa arquitetura de forma eficaz, considerando que uma única máquina virtual pode não ter capacidade suficiente para processar a carga de trabalho da Gi LAN?
Para proteger e monetizar suas redes, as operadoras de telefonia móvel vêm implantando diversas tecnologias na LAN Gi, incluindo, entre outras, otimização de TCP, otimização de vídeo, enriquecimento de cabeçalhos, inspeção profunda de pacotes, firewall Gi e NAT de nível de operadora (CGNAT).
Historicamente, muitas dessas funções eram implementadas em plataformas distintas, muitas vezes de fornecedores diferentes. Nos últimos anos, as operadoras de telefonia móvel vêm consolidando e simplificando sua arquitetura de LAN Gi.
Por meio da consolidação, as operadoras de telefonia móvel conseguiram reduzir significativamente o custo total de propriedade. Ao migrar essa arquitetura para uma plataforma NFV — que utiliza hardware comercial de prateleira —, pode haver a tentação de começar a decompor a arquitetura em diferentes VNFs independentes, cada uma dedicada a uma única função.
Essa arquitetura decomposta certamente faz sentido se cada uma das diferentes funções da LAN Gi for aplicável 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 Políticas e Regras de Cobrança (PCRF), um mecanismo inteligente de classificação de serviços localizado na entrada da LAN Gi pode determinar quais fluxos precisam ser direcionados e/ou encadeados a funções específicas implantadas como VNFs separadas. Assim, essas VNFs precisarão processar apenas o tráfego sobre o qual devem atuar, o que resulta em uma distribuição muito eficiente do tráfego entre todas as VNFs.
No entanto, se as funções da LAN Gi precisarem ser aplicadas a quase todo o tráfego, essa decomposição de funções não agregará valor algum. Tomemos como exemplos a otimização de TCP e os firewalls Gi. Quase todo o tráfego da LAN Gi precisa ser processado por essas duas funções; portanto, consolidá-las em uma única VNF proporciona ganhos de eficiência semelhantes aos de uma implantação física.
De fato, não há necessidade de um classificador de serviços inteligente para selecionar uma VNF, nem de fazer o tráfego entrar e sair repetidamente da camada SDN para passar de uma VNF para a seguinte. Além disso, adicionar uma função de firewall a uma função de otimização de TCP gera pouquíssima sobrecarga de CPU, portanto, o valor da consolidação continua válido em um ambiente de NFV.
Outro desafio é como lidar com fluxos de trabalho maiores do que uma única VNF é capaz de processar. Alguns fornecedores adotaram a abordagem de permitir que uma VNF seja composta por várias máquinas virtuais (VMs). A maioria das funções na LAN Gi consiste em operações com estado, o que significa que o tráfego de entrada e de saída dos mesmos fluxos precisa ser processado na mesma VM. Consequentemente, se o tráfego de saída chegar a uma VM diferente daquela que processou o tráfego de entrada, será necessária a comunicação entre VMs para encaminhar o tráfego de volta à VM correta. Isso obviamente resultará em degradação do desempenho.
Na F5, escolhemos a abordagem na qual uma VNF é sempre implantada como uma única VM, e o dimensionamento horizontal da arquitetura para várias VMs passa a ser um fator externo de projeto. Há diferentes técnicas de dimensionamento horizontal disponíveis, desde as mais simples até as mais avançadas.
Uma arquitetura de expansão horizontal muito simples baseia-se no hashing de tráfego por IP entre as diferentes VMs, como no roteamento de múltiplos caminhos de mesmo custo (ECMP). No entanto, essa técnica apresenta várias desvantagens e é inviável para a maioria dos casos de uso na LAN Gi. Abordagens baseadas em SDN para controlar a distribuição do tráfego podem evitar algumas dessas limitações do ECMP, mas os recursos ainda seriam um tanto limitados e dependeriam muito da solução de SDN escolhida.
De longe, a abordagem mais flexível e avançada para expandir horizontalmente qualquer função da Gi LAN, de forma totalmente independente da rede subjacente e/ou da SDN, é oferecida por um balanceador de carga sem estado baseado em software (que também é implantado como VMs). O fato de não manter estado permite que ele seja expandido horizontalmente de forma quase ilimitada, pois é possível adicionar mais VMs para o balanceamento de carga sem estado sem comprometer a consistência da distribuição do tráfego entre as VMs que fornecem as funções da Gi LAN.
Com base no exposto acima, acreditamos ser muito importante que qualquer operadora de telefonia móvel avalie cuidadosamente tanto os aspectos de consolidação quanto os de expansão horizontal ao migrar sua arquitetura de Gi LAN da camada física para a virtual.
Sobre o autor
Publicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...