Explicação passo a passo do balanceamento de carga vivoGateway (VGW)

Autor: Equipe de Operações da Vivo Internet - Duan Chengping

Em cenários de negócios de grande porte, não é mais possível fornecer serviços por meio de uma única máquina, o que leva à necessidade de balanceamento de carga. Para atender a carga adequada e confiável, este artigo partirá de requisitos básicos simples, passo a passo e explicará como construir uma plataforma de balanceamento de carga.

1. Como garantir que sua empresa seja confiável

Pense em uma pergunta: suponha que você tenha 10 servidores que fornecem o mesmo serviço para o mundo externo, como você garante que esses 10 servidores possam lidar com solicitações externas de forma estável?

Pode haver muitas soluções aqui , mas essencialmente todas lidam com os dois problemas a seguir:

① Para qual servidor a solicitação do cliente deve ser alocada?

② No caso de algum dos servidores falhar, como isolar os servidores com falha?

Problema 1.  Se o tratamento não for bom, alguns dos 10 servidores podem estar famintos, e nenhuma requisição do cliente é alocada ou alocada muito pouco, enquanto a outra parte vem processando um grande número de requisições, resultando em sobrecarga.

Se o problema ②  não for tratado adequadamente, a disponibilidade (A) no princípio CAP pode não ser garantida, a menos que o sistema não exija A.

Para resolver os problemas acima, você deve implementar um conjunto de controladores que possam agendar solicitações de negócios e gerenciar servidores de negócios. Infelizmente, esse controlador costuma ser o gargalo de todo o sistema na maioria dos casos. Porque se o sistema de controle não for a fundo no cliente, ele deve contar com um mecanismo centralizado de tomada de decisão, que deve carregar todas as solicitações do cliente. Neste momento, deve-se considerar a redundância e o isolamento de falhas do controlador, que se torna interminável.

2. Isolamento de negócios e controle

Então, como resolver os problemas acima?

Ou seja, as coisas profissionais são deixadas para plataformas profissionais, ou seja, precisamos de balanceamento de carga independente para fornecer soluções para os dois pontos acima.

Para o cliente, toda vez que um site for solicitado, ele acabará se transformando em uma solicitação de um determinado IP. Assim, desde que possamos controlar o endereço IP acessado pelo cliente, podemos controlar em qual servidor back-end a requisição deve cair, de forma a obter o efeito de agendamento.É isso que o DNS está fazendo. Ou sequestre todo o tráfego de solicitação do cliente e redistribua as solicitações de tráfego para o servidor de back-end. Este é o método de processamento do Nginx, LVS, etc.

Figura 1. Diagrama esquemático do efeito do balanceamento de carga por meio do DNS

Figura 2. Diagrama esquemático do efeito do balanceamento de carga por meio do LVS/Nginx

Esses dois métodos podem alcançar o efeito de balanceamento de carga. Mas há um problema sério aqui. Serviços como DNS, Nginx e LVS não podem fornecer serviços em uma única máquina na era da Internet. Eles são todos agrupados (isto é, compostos por N servidores), portanto, a confiabilidade e a estabilidade desses clusters E como garantir isso?

O DNS é o principal responsável pela resolução de nomes de domínio e tem um certo efeito de balanceamento de carga, mas o efeito de carga geralmente é muito ruim, portanto, não é a principal consideração. O Nginx fornece balanceamento de carga da Camada 7, contando principalmente com nomes de domínio para diferenciação e carga de negócios. LVS é um balanceamento de carga de camada 4, contando principalmente com protocolo TCP/UDP, endereço IP, porta TCP/UDP para distinguir serviços e cargas.

Para resolver o balanceamento de carga e a confiabilidade dos clusters do balanceador de carga, como Nginx e LVS, podemos fazer as seguintes soluções simples :

1. A carga e a confiabilidade do servidor de negócios são garantidas pelo Nginx;

2. A carga e a confiabilidade do Nginx são garantidas pelo LVS.

A solução acima segue a lógica do negócio <-- carga da camada 7 <-- carga da camada 4 e, na verdade , implementa carga de dois níveis na camada de aplicação <-- camada de transporte no modelo de camadas de rede . Pode-se ver que esta solução realmente usa outra camada de balanceamento de carga para resolver os problemas de carga e confiabilidade da camada atual. No entanto, ainda existem problemas com esta solução. A carga e a confiabilidade da camada de negócios e do cluster Nginx são garantidas, mas e a confiabilidade da camada de cluster LVS?

Uma vez que temos dois níveis de carga na camada de aplicação <-- camada de transporte <-- a camada de rede modelo , é possível atingir uma carga de três níveis da camada de aplicação <-- camada de transporte <-- a camada de rede ? Felizmente, com base no roteamento IP, os dispositivos de rede (switches, roteadores) naturalmente têm a função de balanceamento de carga da camada de rede.

Neste ponto, podemos implementar toda a cadeia de balanceamento de carga: business <-- carga da camada 7 (Nginx) <-- carga da camada 4 (LVS) <-- carga da camada 3 (NetworkDevices) ;

Pode-se ver a partir disso que, para garantir que todo o sistema de balanceamento de carga seja eficaz e confiável, ele deve ser construído a partir da camada de rede. Serviços de alto nível podem fornecer cargas para serviços de baixo nível. Comparado com o negócio de baixo nível, o negócio de alto nível pode ser considerado como o plano de controle do negócio de baixo nível, que pode ser implementado e gerenciado por uma equipe profissional. realização do próprio negócio.

Figura 3. Correspondência entre o modelo de rede de 7 camadas e LVS e Nginx

Descrição do modelo de 7 camadas da rede:

7. Camada de aplicativo:  suporta aplicativos de rede. Os protocolos de aplicativo são apenas uma parte dos aplicativos de rede. Processos executados em diferentes hosts usam protocolos de camada de aplicativo para se comunicar. Os principais protocolos são: HTTP, FTP, Telnet, SMTP, POP3, etc.

6. Camada de apresentação:  representação de dados, segurança e compactação. (Na prática, esta camada foi mesclada na camada de aplicação)

5. Camada de sessão:  estabelece, gerencia e encerra sessões. (Na prática, esta camada foi mesclada na camada de aplicação)

4. Camada de transporte:  responsável por fornecer serviços de transmissão de dados entre programas aplicativos para origens e destinos.Esta camada define principalmente dois protocolos de transporte, o Transmission Control Protocol (TCP) e o User Datagram Protocol (UDP).

3. Camada de rede:  Responsável por enviar datagramas de forma independente da origem ao destino, resolvendo principalmente problemas como roteamento, controle de congestionamento e interconexão de rede.

2. Camada de enlace de dados:  responsável por encapsular datagramas IP em formatos de quadros adequados para transmissão na rede física e transmiti-los, ou desencapsular quadros recebidos da rede física, retirar datagramas IP e entregá-los à camada de rede.

1. Camada física:  Responsável pela transmissão do fluxo de bits entre os nós, ou seja, responsável pela transmissão física. O protocolo nesta camada está relacionado tanto ao link quanto ao meio de transmissão.

3. Como implementar o balanceamento de carga da Camada 4

Conforme mencionado acima, a carga da Camada 3 é fornecida naturalmente pelo equipamento de rede, mas no uso real ela é fortemente acoplada à carga da Camada 4 e geralmente não fornece serviços de forma independente. A carga da Camada 4 pode fornecer serviços diretamente para a camada de negócios sem depender da carga da Camada 7 (a carga da Camada 7 é principalmente para serviços como HTTP/HTTPS), então nos concentramos principalmente na carga da Camada 4 aqui .

3.1 Como encaminhar o tráfego

Para alcançar o balanceamento de carga, a implicação é realizar o redirecionamento do tráfego, portanto, o primeiro problema a ser resolvido é como encaminhar o tráfego.

4 problemas para resolver:

① Como atrair o tráfego do cliente para o balanceador de carga?

② Como o balanceador de carga seleciona um servidor de back-end adequado?

③ Como o balanceador de carga envia os dados da solicitação para o servidor de back-end?

④ Como o servidor back-end responde aos dados solicitados?

Para ①,

A solução é muito simples, fornecer um lote de servidores back-end com um endereço IP independente, que chamamos de IP Virtual (também conhecido como VIP). Todos os clientes não precisam acessar diretamente o endereço IP de back-end, mas, em vez disso, acessar o VIP. Para o cliente, equivale a bloquear o backend.

Para ②,

Considerando a versatilidade do balanceamento de carga de baixo nível, estratégias de carga complexas geralmente não são implementadas. Soluções como RR (round robin) e WRR (round robin com peso) são mais adequadas e podem atender aos requisitos da maioria dos cenários.

Para ③,

A escolha aqui geralmente afetará a escolha de ④. Idealmente, esperamos que os dados da solicitação do cliente sejam enviados intactos para o back-end, de modo a evitar que o pacote de dados seja modificado. No modelo de camadas de rede de sete camadas acima mencionado, o encaminhamento da camada de enlace de dados pode ser alcançado sem afetar o conteúdo dos pacotes de dados da camada superior, portanto, pode ser encaminhado sem modificar os dados solicitados pelo cliente. Isso é o que a rede geralmente chama de encaminhamento de Camada 2 (camada de enlace de dados, a segunda camada no modelo de rede de sete camadas), que depende do endereço MAC da placa de rede para encaminhar dados.

Portanto, é viável supor que o pacote de dados de solicitação do cliente seja empacotado como um pedaço de dados do aplicativo e enviado ao servidor de back-end? Este método equivale a estabelecer um túnel entre o balanceador de carga e o back-end, e transmitir os dados da requisição do cliente no meio do túnel, para que também possa atender a demanda.

Dentre as duas soluções acima, a solução que depende do encaminhamento da camada de enlace de dados é chamada de Direct Route (Rota Direta) , ou seja, modo DR ; a outra solução que requer um túnel é chamada de modo Tunnel . O modo DR tem uma desvantagem, porque dependendo do encaminhamento de endereço MAC, o servidor back-end e o balanceador de carga devem estar na mesma sub-rede (não pode ser considerado estritamente como o mesmo segmento de rede), o que leva ao fato de que apenas o mesmo sub-rede como o balanceador de carga Os servidores na rede podem ser acessados ​​e não há oportunidade de usar o balanceamento de carga se eles não estiverem na mesma sub-rede. Obviamente, isso é impossível para atender aos negócios atuais em grande escala. O modo Tunnel também tem desvantagens: como o encaminhamento de dados depende do túnel, um túnel deve ser estabelecido entre o servidor back-end e o balanceador de carga. Como garantir que diferentes funcionários de negócios possam configurar corretamente o túnel no servidor e monitorar a operação normal do túnel é muito difícil. É necessária uma plataforma de gerenciamento completa, o que significa que o custo de gerenciamento é muito alto.

Figura 4. Diagrama esquemático de encaminhamento no modo DR, o tráfego de resposta não passará pelo balanceador de carga

Figura 5. Diagrama esquemático do encaminhamento do modo de túnel. Como o DR, o tráfego de resposta não passará pelo balanceador de carga

Como nenhum deles é ideal, existe alguma outra solução?

O que esperamos é que o servidor back-end não perceba a existência de balanceamento de carga no front-end, e o serviço pode ser colocado em qualquer lugar sem nenhuma configuração excessiva. Como é impossível transmitir o pacote de dados do cliente intacto, faça o proxy da solicitação do cliente. Ou seja, a tradução do endereço IP é realizada no IP de origem e no IP de destino dos pacotes de dados enviados pelo cliente.

Em detalhes, depois de receber a solicitação do cliente A, o balanceador de carga inicia a mesma solicitação para o servidor de back-end na função do cliente. A carga útil da solicitação vem da carga útil da solicitação do cliente A, o que garante que os dados da solicitação sejam consistente.

Neste ponto, o balanceador de carga equivale a iniciar uma nova conexão (diferente da conexão iniciada pelo cliente A), e a nova conexão usará o endereço IP do balanceador de carga (chamado LocalIP) como endereço de origem para contatar diretamente o comunicação IP do servidor back-end.

Quando o back-end retorna dados ao balanceador de carga, os dados são retornados ao cliente A por meio da conexão do cliente A. Todo o processo envolve duas conexões, correspondentes a duas traduções de endereços IP,

• Tempo de solicitação: CIP→VIP, convertido para LocalIP→IP do servidor backend, 

• Tempo de retorno dos dados: IP do servidor back-end → LocalIP, convertido para VIP → CIP.

O processo de encaminhamento de dados do cliente é totalmente baseado no endereço IP em vez do endereço MAC. Desde que a rede seja acessível, os dados podem ser transmitidos sem problemas entre o cliente e o back-end.

Figura 6. Modo de encaminhamento FULLNAT

A solução acima é chamada de modo de encaminhamento FULLNAT , ou seja, duas traduções de endereço são realizadas. Obviamente, esse método é bastante simples, não requer nenhum ajuste no servidor de back-end e não limita onde o back-end é implantado. Mas também há um problema óbvio, ou seja, todas as solicitações vistas pelo back-end vêm do balanceador de carga e as informações do IP do cliente real são completamente invisíveis, o que equivale a bloquear o cliente real. Felizmente, a grande maioria dos aplicativos no data center não precisa saber as informações de endereço IP do cliente real. Mesmo que as informações de IP do cliente real sejam necessárias, o balanceador de carga pode carregar essa parte das informações no TCP/UDP dados de protocolo, por meio de Instalar determinados plug-ins conforme necessário.

Com base nas soluções acima, o modo FULLNAT é o melhor para nosso cenário de negócios (ambiente não virtualizado).

Como pretendemos usar o modo FULLNAT , não há dificuldade em resolver ④, pois o balanceador de carga atua indiretamente como o cliente, e todos os dados de back-end devem ser encaminhados para o balanceador de carga e, em seguida, enviados para o cliente real pelo final do balanceador de carga.

Tabela 1: Análise das vantagens e desvantagens entre os vários modais

3.2 Como eliminar servidores back-end anormais

O balanceamento de carga geralmente fornece um mecanismo de detecção de verificação de integridade para o back-end, para que os endereços IP anormais do back-end possam ser rapidamente eliminados. Idealmente, a detecção baseada em semântica é a melhor e pode detectar com mais eficiência se o back-end é anormal. Mas este método vai trazer muito consumo de recursos, especialmente quando o back-end é enorme, isso não é particularmente grave, o mais grave é que o back-end pode executar muitos tipos de HTTP, DNS, Mysql, Redis, etc. configurações são muito diversas e muito complexas. A combinação dos dois problemas torna a verificação de integridade muito complicada, que ocupará muitos recursos originalmente usados ​​para encaminhar dados, e o custo de gerenciamento é muito alto. Portanto, é necessário um método simples e eficaz, já que se trata de uma carga da Camada 4, não identificamos qual é o negócio upstream, mas apenas prestamos atenção se a porta TCP ou UDP é alcançável. O trabalho de identificar o negócio da camada superior é entregue à carga de 7 camadas do tipo Nginx.

Portanto, desde que você verifique regularmente se todas as portas TCP/UDP de back-end estão abertas, o serviço de back-end é considerado normal se estiver aberto e o serviço é considerado anormal se não estiver aberto.

Então, como detectá-lo? Como é apenas para julgar se a porta TCP está normalmente aberta, basta tentar estabelecer uma conexão TCP.Se o estabelecimento for bem-sucedido, indica que a porta está normalmente aberta. Mas para o UDP, porque o UDP não tem conexão, não há como criar uma nova conexão, mas também pode atingir o objetivo de detecção enviando dados diretamente. Ou seja, envie um dado diretamente, supondo que a porta UDP esteja normalmente aberta, de modo que o back-end geralmente não responda. Se a porta não estiver aberta, o sistema operacional retornará um status de porta icmp inacessível, que pode ser usado para determinar se a porta está inacessível. Mas há um problema: se o pacote de detecção UDP contiver uma carga útil, isso pode fazer com que o back-end pense que são dados comerciais e receba dados irrelevantes.

3.3 Como implementar o isolamento de falhas do balanceador de carga

Como dissemos anteriormente, o balanceamento de carga da Camada 4 depende do balanceamento da camada de rede para garantir que a carga entre os balanceadores de carga da Camada 4 seja balanceada, portanto, o isolamento de falha dos balanceadores de carga depende da camada de rede.

Como fazer isso?

Na verdade, dependemos do roteamento para balanceamento de carga na camada de rede. Cada servidor no cluster de balanceamento de carga notifica o mesmo endereço VIP para o dispositivo de rede (switch ou roteador) por meio do protocolo de roteamento BGP, e o dispositivo de rede recebe o mesmo VIP Se um VIP vier de servidores diferentes, uma rota de custo igual (ECMP) será formada e a implicação é formar o balanceamento de carga. Portanto, se quisermos isolar um determinado balanceador de carga, basta revogar o VIP emitido pelo protocolo de roteamento BGP no servidor, para que o switch upstream pense que o servidor foi isolado e não enviará mais dados para o correspondente servidor. no dispositivo.

Figura 7. Isolamento de falhas por retirada de rotas VIP

Até agora, implementamos um modelo de arquitetura de balanceamento de carga baseado em FULLNAT, que depende principalmente de portas de protocolo de camada 3 para verificações de integridade e realiza transceptores VIP por meio de encaixe de dispositivo de rede e BGP.

4. Implementação do VGW

Com base na arquitetura de carga de 4 camadas mencionada acima, construímos o VGW (vivo Gateway), que fornece principalmente serviços de balanceamento de carga de 4 camadas para serviços de intranet e extranet. A seguir, explicaremos a arquitetura lógica, a arquitetura física, a garantia de redundância e como melhorar o desempenho do encaminhamento de gerenciamento.

4.1 Componentes VGW

A função principal do VGW é o balanceamento complexo e também possui funções como verificação de integridade e drenagem de negócios. Portanto, os componentes que compõem o VGW são principalmente o módulo de encaminhamento de balanceamento de carga principal, o módulo de verificação de integridade e o módulo de controle de roteamento.

1. Módulo de encaminhamento de balanceamento de carga: responsável principalmente pelo cálculo de carga e encaminhamento de dados;

2. Módulo de verificação de integridade: principalmente responsável por detectar o status disponível do back-end (RealServer) e limpar o back-end indisponível a tempo ou restaurar o back-end disponível;

3. Módulo de controle de roteamento: executa principalmente liberação e drenagem de VIP e isola servidores VGW anormais.

4.2 Esquema de Arquitetura Lógica

Para facilitar o entendimento, chamamos o link do cliente ao VGW de rede externa (External), e o link do VGW ao backend (RealServer) é mais complexo que a rede interna (Internal). Em termos de arquitetura lógica, a função do VGW é muito simples, que é distribuir uniformemente as solicitações externas de negócios para o RealServer interno.

Figura 8. Diagrama lógico do VGW

4.3 Esquema de Arquitetura Física

Em termos de arquitetura física, existem algumas diferenças entre o VGW que fornece a rede interna e o VGW que fornece a rede externa.

O cluster VGW de rede externa usa pelo menos duas placas de rede, que são conectadas respectivamente aos dispositivos de rede no lado da rede externa e aos dispositivos de rede no lado da rede interna. Para o servidor VGW, duas portas de rede estendem dois links, semelhante a um par de braços humanos, portanto, esse modo é chamado de modo de braço duplo e um pacote de dados passa apenas uma vez por uma única placa de rede do servidor VGW.

Figura 9. Diagrama físico da rede externa VGW

O VGW da rede interna é diferente da rede externa, e o VGW da rede interna usa apenas uma placa de rede para se conectar diretamente ao equipamento de rede do lado da rede interna. Correspondentemente, esse método é chamado de modo de braço único. Um pacote de dados precisa primeiro entrar de apenas uma placa de rede, depois sair da placa de rede e finalmente encaminhá-lo para fora, passando pela placa de rede duas vezes no total.

Figura 10. Diagrama físico da intranet VGW

4.4 Modelo de Negócios Existente da VGW

Como dissemos anteriormente, o balanceamento de carga pode fornecer um nível mais alto de balanceamento de carga para cargas da Camada 7.

• Atualmente, o maior tráfego de negócios da VGW vem do tráfego da plataforma de acesso de 7 camadas (ou seja, Nginx), e o Nginx basicamente carrega a maior parte do core business da empresa.

• Claro, Nginx não pode suportar todos os tipos de serviços. Camada 7 Nginx não suporta o tipo de tráfego não-HTTP construído diretamente sobre TCP e UDP. Tais serviços são encaminhados diretamente para o servidor de serviço por VGW, sem outros links no meio. , como Kafka, Mysql, etc.

• Outra parte do negócio é que os usuários construíram várias plataformas de proxy, semelhantes ao Nginx, etc., mas o VGW também fornece balanceamento de carga de Camada 4 para eles.

Figura 11. Diagrama do modelo de negócios VGW

4.5 Garantia de Redundância VGW

Para melhorar a usabilidade, quais riscos devem ser considerados? Todos naturalmente consideram cenários como falha de servidor e falha de processo. No entanto, mais precisa ser considerado no cenário VGW, porque todo o sistema VGW inclui links, dispositivos de rede, servidores, processos e assim por diante. E não podemos apenas considerar o cenário simples de inatividade do dispositivo. Na verdade, a situação mais problemática é que qualquer um dos dispositivos mencionados acima não caia, mas encaminha de forma anormal.

Portanto, monitorar se o encaminhamento do serviço VGW é normal é o primeiro passo. Estabelecemos regularmente conexões com VIPs por meio de nós de detecção implantados em diferentes salas de computadores e regiões e usamos a taxa de falha de conexão como padrão para medir se o VGW está normal. Na verdade, esse monitoramento equivale a detectar se os links e o encaminhamento de todos os links que envolvem o VGW estão bons.

O monitoramento acima abrange a detecção em nível de cluster. Claro, também estabelecemos outro monitoramento mais refinado para encontrar problemas específicos.

Depois de monitorar os dados em primeira mão, podemos fornecer recursos de tratamento de falhas no nível do servidor e no nível do cluster.

1. O VGW isola automaticamente as paradas diretas de todos os níveis de equipamentos;

2. Todas as anormalidades no nível do link, algumas das quais podem ser isoladas automaticamente;

3. Todas as exceções em nível de processo podem ser isoladas automaticamente;

4. Para outras anormalidades que não sejam falhas completas, é necessária intervenção manual para isolá-las.

O isolamento de falhas no nível do servidor significa que alguns servidores VGW cancelarão a liberação do VIP por meio do ajuste de rota, de modo a atingir o objetivo do isolamento;

O isolamento de falhas no nível do cluster é cancelar a publicação do VIP de todo o cluster VGW, para que o tráfego seja automaticamente desenhado pelo cluster em espera e o cluster em espera assuma todo o tráfego de negócios.

Figura 12. Isolamento de falhas no nível do servidor e do link

Figura 13. Isolamento de falhas no nível do cluster

4.6 Como melhorar o desempenho do VGW

À medida que o volume de negócios se torna cada vez maior, um único VGW precisa receber quase um milhão de solicitações QPS e, ao mesmo tempo, atingir uma capacidade de processamento de pacotes de mais de 500 W/s. Obviamente, os servidores em geral não conseguem atingir um número tão grande de solicitações e velocidades de processamento de pacotes.A principal razão é o mecanismo de processamento de rede do Linux. Todos os pacotes de dados da rede devem passar pelo kernel do Linux. Após a placa de rede receber os pacotes de dados, ela deve enviar uma interrupção para a UCP, que será processada pela UCP no kernel, e então uma cópia será copiada para o aplicativo programa. O envio de dados também precisa ser processado pelo kernel. Interrupções frequentes e constante cópia de dados entre o espaço do usuário e o espaço do kernel levam a um grande consumo de tempo de CPU no processamento de dados da rede. Quanto maior a taxa de pacotes, pior o desempenho. Claro, existem outros problemas, como falta de cache, consumo de cópia de dados entre CPUs e assim por diante.

É fácil pensar aqui, o trabalho sujo feito pela CPU acima pode ser jogado para a placa de rede para fazê-lo, e a CPU só pode processar dados de negócios. Atualmente, muitas soluções são baseadas nessa ideia: a solução de hardware inclui placas de rede inteligentes e a solução de software puro atualmente usa DPDK (Intel Data Plane Development Kit). Obviamente, o custo da placa de rede inteligente será alto, e ainda está em fase de desenvolvimento, e o aplicativo tem um certo custo. O software DPDK puro é muito melhor em termos de custo e capacidade de controle. Escolhemos o DPDK como o componente subjacente de encaminhamento de pacotes (na verdade, um desenvolvimento secundário baseado no DPVS de código aberto da iQIYI).

O DPDK intercepta principalmente o processo de processamento de pacotes do kernel e envia diretamente os pacotes de dados do usuário para o programa aplicativo, em vez de serem processados ​​pelo kernel. Ao mesmo tempo, o comportamento de depender da interrupção da placa de rede para processar dados é descartado e o método de pesquisa é usado para ler os dados da placa de rede, de modo a atingir o objetivo de reduzir a interrupção da CPU. Obviamente, a afinidade da CPU também é usada e uma CPU fixa é usada para processar os dados da placa de rede, reduzindo o consumo de troca de processo. Além disso, existem muitas tecnologias de otimização sobre Cache e memória. Em geral, a velocidade de processamento de pacotes da placa de rede do servidor pode atingir dezenas de milhões de PPS, o que melhora muito a capacidade de processamento de pacotes da placa de rede e pode aumentar o CPS (número de novas conexões por segundo) do servidor. Atualmente, podemos atingir capacidade de processamento de negócios de 100w+ CPS e 1200w+PPS sob a placa de rede 100G (resultados de teste em condições limitadas, não em valores teóricos).

Figura 14. A ferramenta subjacente DPVS (DPDK+LVS) usada pelo VGW compara o desempenho de várias soluções de balanceamento de carga existentes

V. Resumo

Por meio das explicações acima, deduzimos gradualmente um conjunto de soluções de balanceamento de carga viáveis ​​a partir de um requisito de confiabilidade de negócios e, combinado com as necessidades reais da vivo, implementamos nossa plataforma de acesso de balanceamento de carga VGW. Obviamente, o esquema de balanceamento de carga atual é o resultado de muitas compensações e é impossível ser perfeito. Ao mesmo tempo, também enfrentaremos o problema do suporte a novos protocolos de negócios no futuro, bem como o conflito entre o modelo de negócios descentralizado do data center e o controle centralizado do balanceamento de carga. Mas a tecnologia vem avançando, mas sempre haverá uma solução adequada!

{{o.name}}

{{m.name}}