A Scalable, Commodity Data
Center Network Architecture
Mohamed Al-Fares Alexander Loukissas Amin Vahdat
MO809 - Tópicos em Sistemas Distribuídos Daniel de Souza Kamiya – RA 021486
Introdução
Duas opções de fabric para clusters de grande escala:
• Utilização de hardware e protocolos de comunicação
especializados (InfiniBand; Myrinet):
- Permitem clusters de milhares de nós e alta largura de
banda;
- Não usam peças commodity, sendo, portanto, mais caros;
- Não são compatíveis com aplicações TCP/IP.
• Utilização de switches e roteadores commodity para
interligar as máquinas do cluster:
- Infraestrutura com gerenciamento familiar;
- Largura de banda pouco escalável;
- Aumento da largura de banda produz aumento não linear
Projetar uma arquitetura de rede de data center que possua as seguintes características:
• Largura de banda escalável: servidores devem ser
capazes de se comunicar na velocidade da placa de rede.
• Economia de escala: utilização de switches Ethernet
baratos.
• Compatibilidade com tecnologias usuais: sistema deve
ser compatível com Ethernet e TCP/IP.
Topologia de Datacenter Atual
• Switches Edge: (48-288) portas GigE para conexão com os
servidores. Portas 10 GigE para conexão com a camada superior.
• Switches Aggregation e Core: (32-128) portas 10 GigE.
• Two tier (Core e Edge): 5K a 8K servidores.
• A velocidade do enlace para um nível mais alto não corresponde à soma de todos os enlaces de nível mais baixo.
• 5:1, hosts usarão somente 20% da banda.
• Multiplexação dos recursos de rede para reduzir a
quantidade de enlaces e equipamentos, sem
comprometer o desempenho da rede.
• Artifício utilizado para diminuição de custo.
• Para placas 1Gb/s, valores típicos de fator de
oversubscription são 2,5:1 (400 Mbps) e 8:1 (125Mbps).
• Fator 1:1 é possível, porém custo é proibitivo.
• Utilização máxima da rede entre pares de servidores requer o uso de árvores com múltiplas raízes (múltiplos switches core) e técnicas de múltiplos caminhos, tais como o algoritmo Equal-Cost Multi-Path (ECMP).
• ECMP realiza um balanceamento de carga estático se
caminhos de mesmo custo estiverem disponíveis.
• ECMP sozinho não é solução, pois não leva em conta a
velocidade do tráfego na tomada decisão.
• ECMP limita o número de múltiplos caminhos (8-16) e o
número de entradas nas tabelas de roteamento cresce bastante com o número de caminhos, aumentando o custo e latência da busca na tabela.
• Oversubscription reduz custos.
• O custo para um mesmo número de servidores reduz
com o aumento do fator de oversubscription.
• Fat-tree se mostrou promissora como uma arquitetura
escalável a um custo moderado.
• Topologia Fat-tree apresentou boa escalabilidade, o custo total caiu mais rapidamente e mais cedo
• Não houve necessidade de uplinks mais velozes na
topologia Fat-tree.
• Fat-tree é baseado no trabalho de Clos (Switches Telefônicos).
• Para K pods, cada um contendo duas camadas de K/2 switches e K
switches core.
• Metade das K portas dos switches das camada inferior ligam-se aos
servidores.
• A outra metade das K portas são ligadas aos switches superiores.
• K/2 portas dos switches superiores são ligadas aos switches core.
• Nesta arquitetura, no total podem ser conectados k3/4 servidores.
• Exemplo: –Para K = 4
–Temos 4 switches core
–Temos 2 switches de borda e 2 switches de agregação por pod, cada um com 4 portas.
–Cada switch de borda se liga a 2 hosts e as dois switches de agregação –Cada switch de agregação se liga a dois switches core..
• Todos os switches são idênticos, permitindo o uso de opções de baixo custo.
• É rearranjável e não-bloqueante.
• Existe algum conjunto de caminhos que irá saturar toda
a rede disponível entre hosts da topologia.
• Atingir uma taxa de oversubscription de 1:1 na prática
pode ser difícil devido a necessidade de prevenir a reordenação de pacotes TCP.
• Modificação na estrutura da tabela de roteamento.
• Atribuição de endereços IP aos hosts.
• Introdução do conceito de tabela de roteamento de dois
níveis (utilizada no roteamento multi-path).
• Classificação e escalonamento do tráfego (métodos
alternativos de roteamento multi-path).
• Tolerância a falhas.
• Motivações para mudanças no roteamento:
- OSPF utiliza-se da contagem de hop para sua métrica de
“shortestpath”(melhor caminho sempre é o mais curto).
- Na k-ésima Fat-tree existem (k/2)^2 “menores
caminhos” entre qualquer dois hosts de diferentes pods, porém somente um é o escolhido.
- Switches concentram o tráfego para uma subnet através
de uma única porta.
- Necessário desenvolver um roteamento que seja simples
e tire vantagem da estrutura da topologia.
• Solução: Uso de tabelas de roteamento de dois níveis para espalhar o tráfego baseando-se nos bits menos significativos do endereço IP de destino.
• Endereços IP são alocados no bloco 10.0.0.0/8.
• Pod switches:10.pod.switch.1 (esq p/ dir, baixo p/ cima)
pod: número do Pod [0, k-1]
switch: posição do switch no Pod [0, k-1]
• Core switch:10.k.j.i
j e i: coordenadas do switch na grade de switches core [1, (k/2)] (começando em cima e à esquerda)
• Servidores: 10.pod.switch.id (esq p/ dir)
id: posição do servidor na sub-rede [2, (k/2)+1]
Arquitetura: Roteamento 10.0.0.1 10.0.3.1 10.2.3.1 10.2.1.1 10.0.1.3 10.pod.switch.1 10.k.j.i 10.pod.switch.id
• Cada entrada da tabela primária (prefixo,porta) pode ter um ponteiro para uma tabela secundária (sufixo,porta) ou um número de porta de terminação.
• Uma tabela secundária pode ser apontada por mais de
um prefixo de primeiro nível.
• As entradas nas tabelas são estáticas, não mudam com o
comportamento do tráfego.
• Exemplos:
- IP destino 10.2.1.2: pacote enviado para porta 1.
- IP destino 10.3.0.3: pacote enviado para porta 3.
• As tabelas de roteamento de dois níveis podem ser implementadas em hardware usando memórias TCAM, reduzindo a latência de busca.
• CAM permite buscas paralelas em um único ciclo.
• TCAM permite o armazenamento de prefixos e sufixos,
pois utiliza bits 0, 1 e don’t care (X).
• Prefixos e sufixos indexam uma memória RAM que
armazena o endereço IP do próximo salto e a porta de saída.
Arquitetura: Two Level Routing Table
• É atribuído prefixos de terminação para sub-redes em um mesmo pod.
• Para comunicações inter-pods, os switches de um pod
possuem um prefixo padrão /0 com a tabela secundária coincidindo com os identificadores dos hosts (byte menos significativo do endereço IP de destino).
Arquitetura: Algoritmo de Roteamento
Algoritmo gerador da tabela de roteamento de switches de agregação.
• Cada switch core está conectado com todos os pods.
• Switches core possuem somente prefixos de terminação
/16, apontando para os pods de destino.
Algoritmo gerador da tabela de roteamento de switches core
• Previne o congestionamento local.
• A atribuição de tráfego a uma porta é realizada com base
no fluxo e não com base no host de destino.
• Um fluxo é definido como uma sequencia de pacotes com
a mesma origem, destino, portas, etc.
• Para os switches pod, todos os pacotes de um mesmo
fluxo são encaminhados para uma mesma porta de saída e periodicamente os fluxos são distribuídos para outras portas, promovendo uma distribuição mais uniforme dos fluxos nas diferentes portas.
• Previne o congestionamento global
• Gerenciamento de fluxo para evitar que grandes fluxos
compartilhem um mesmo link.
• Switches edge detectam qualquer fluxo de saída cujo
tamanho cresça além de um certo limite e enviam uma notificação sobre tais fluxos para o escalonador central.
• O escalonador central acompanha todos os grandes
fluxos ativos e tenta atribuí-los, se possível, para diferentes links.
• Caminhos redundantes estão presentes na Fat-tree podem ser utilizados para fornecer tolerância a falhas.
• Protocolo broadcast de falha permite que switches criem
rotas alternativas em caso de falha de link ou switches.
• Cada switch mantém uma sessão de detecção de
encaminhamento bidirecional (BFD) com seus vizinhos para determinar quando um link ou switch falhe.
• Link pode falhar entre switches das camadas inferior e
superior (intra-pod) e entre switches da camada superior e switches core.
• A falha em um switch da camada inferior levará a uma
desconexão. Necessário usar switches redundantes nas folhas.
Falha de link entre switches da camada superior e inferior:
• Tráfego de saída inter e intra-pod originado em um switch
da camada inferior: custo do link classificado como infinito. Nenhum novo fluxo é atribuído ao link. Outro switch da camada superior é escolhido.
• Tráfego intra-pod através de switch da camada superior:
switch notifica todos switches da camada inferior. Evitam utilizar portas notificadas para novos fluxos.
• Tráfego Inter-pod entrando no switch da camada superior:
switch comunica a todos os switches core conectados a ele sua incapacidade de realizar o tráfego. Switch core propaga informação aos switches de camada superior conectados a ele em outros pods. Switches de camada superior evitam o switch core afetado.
Falha de link entre camada superior e switch core:
• Tráfego inter-pod de saída: tabela de roteamento local
marca o link afetado como indisponível e escolhe localmente outro switch core.
• Tráfego inter-pod de entrada: switch core notifica todos
os outros switches da camada superior diretamente ligados a ele da sua incapacidade para transportar o tráfego. Switches da camada superior evitam o switch core afetado.
• Fat-tree:
Consumo de energia 56,6% menor Dissipação de calor 56,5% menor
• Valor calculado com base nas especificações dos
fabricantes. Medida a partir da implementação será realizada em trabalhos futuros.
• Foi construído um protótipo dos algoritmos de
roteamento com NetFPGA, contendo uma
implementação de um roteador IPv4 que usa TCAM.
• Para avaliações de maior escala, foi construído um
protótipo usando Click, um software que suporta a implementação de roteadores experimentais.
• Elementos implementados no Click Router Software
- TwoLevelTable: Inicializada com informações pré-configuradas.
- FlowClassifier: Distribui o tráfego igualmente entre as portas.
- FlowReporter + FlowScheduler: aloca grandes fluxos em caminhos distintos.
• Objetivo: medir a largura de banda da arquitetura.
• Comparado 4–port Fat-tree usando switches
TwoLevelTable, FlowClassifier, FlowScheduler contra sua árvore hierárquica com oversubscription 3.6:1
• Random: hosts se comunicam na rede com igual probabilidade;
• Stride(i): host(x) se comunica com host(x+i) mod 16;
• Staggered Prob (SubnetP,PodP): host se comunica com
outro host em sua subnet com probabilidade SubnetP, com outro host em seu pod com probabilidade PodP e com qualquer outro host com prob 1-SubnetP-PodP;
• Inter-pod Incoming: Pods se comunicam com diferentes
hosts em um mesmo pod, usando o mesmo sw core;
• Same-ID Outgoing: hosts em uma mesma subnet se
comunicam com diferentes hosts em qualquer lugar da rede, de forma que os hosts de destino possuam o mesmo byte ID.
• Uso da Rede:
Avaliação: Resultados
• Árvore tradicional: alto grau de saturação;
• Two-Level Table: melhor, mas falha pela natureza estática;
• Flow Classification: melhora devido ao comportamento
dinâmico, porém ainda imperfeito, pois só evita congestionamento local;
• Flow Scheduling apresentou melhor resultado, por possuir
• Aumento do número de cabos é desvantagem de Fat-tree.
• Solução proposta:
• Cada pod é composto por 12 racks com 48 máquinas cada um, e 48 switches GiE de 48 portas.
• Os 48 switches são colocados em um rack centralizado.
• Cabos move-se em conjuntos de 12 de pod para pod e em
conjuntos de 48 de racks para switches.
• Comprimento total de cabo é minimizado com os racks de
máquinas ao redor do rack de switches em duas dimensões.
• Muitas interconexões de processamento paralelo estão sendo organizadas como fat-tree, por exemplo: Thinking Machines e SGI.
• Myrinet:
- Também emprega topologia fat-tree;
- Popular para supercomputadores baseados em clusters;
- Vantagem: Baixa latência;
- Desvantagem: Hosts responsáveis pelo balanceamento de
carga.
• Infiniband:
- Popular para ambientes de computação de alta performance
- Largura de banca escalável;
- Também usa fat-tree;
- Restrição: Impõe sua própria camada de protocolo de rede.
• Largura de banda é o gargalo da escalabilidade em clusters de grande escala;
• As soluções existentes são caras e limitam o tamanho do
cluster;
• Fat-tree:
- Largura de banda escalável com custo significativamente
menor;
- Mantém compatibilidade com TCP/IP e Ethernet;
- Grande número de switches commodity podem substituir
switches high-end em data centers da mesma forma que clusters de PCs substituem supercomputadores;