Home
Em ambientes que necessitam continuamente efetuar transferências de grandes volumes de dados em altas taxas de transferência, como ocorre em data centers, é fundamental o uso de redes de alta capacidade que suportem a carga de trabalho exigida. Ao projetar redes desse tipo, diversos desafios são enfrentados. O artigo intitulado "Jellyfish: Networking Data Centers Randomly"[1], publicado no USENIX NSDI'12, trata a respeito de um problema crucial, a expanssão incremental da rede. Em redes que possuem essa característica é possível adicionar servidores e capacidade de rede (novas midleboxes, links, etc.) de forma incremental a medida que as demandas surgem, por exemplo, novos usuários ou aplicações.
No momento da publicação desse artigo (em 2012), já haviam diversas pesquisas que exploravam estruturas especiais para topologias e roteamento em redes de data centers como, por exemplo, a Fat-Tree. No entanto, nenhuma das soluções abordavam o problema de expanssão incremental.
Embora a topologia Fat-Tree permita um certo nível de expanssão, para adicionar servidores é preciso substituir um grande número de elementos da rede e uma realizar extensiva configuração, o que pode tornar seu uso inviável ou pelo menos muito custoso (tanto em termos financeiros quanto operacional) em determinados casos.
A solução proposta pelos autores, denominada Jellyfish, é um novo método de interconexão de rede que adota uma topologia de grafo aleatório e possibilita naturalmente a expanssão incremental. No caso mais básico apresentado no trabalho, a rede possui switches com a mesma quantidade de portas e servidores, se tornando assim um grafo regular aleatório.
Todavia, ao empregar uma nova topologia, novos desafios podem surgir como o roteamento e o controle de congestionamento. Isso porque, parte da proposta é que a topologia ofereça uma grande diversidade de caminhos para os nós se conectarem. Essa característica torna a Jellyfish uma rede de alta capacidade, pois o objetivo é que os dados fluam de forma balanceada por diferentes caminhos, utilizando a capacidade total da rede (evitando o desperdício de recurso). Sendo assim, é preciso que o protocolo de roteamento seja capaz de identificar a maior quantidade possível de caminhos (usando o maior número de links, sem deixar links inutilizáveis) para que o protocolo de controle de congestinamento tenha uma variedade de caminhos disponíveis para encaminhar o tráfego de forma balanceada.
No intuito de apresentar algumas propriedades da Jellyfish, bem como comprovar alguns avanços providos pela mesma, são realizados diversos experimentos, muitos deles comparando a Jellyfish com a topologia Fat-Tree.
Dois experimentos foram reproduzidos neste repositório, sendo eles a Figura 9 e a Tabela 1. Ambos estão relacionados à capacidade da topologia.
A Figura 9 apresenta o comportamento de alguns protocolos de roteamento rodando em uma topologia Jellyfish. Os protocolos utilizados são o k-shortest-path com k=8 e o ECMP de 8 vias e até mesmo de 64. Com os resultados apresentados por essa figura é possível observar que o ECMP (com 8 ou 64 vias) não fornece uma diversidade interessante de caminhos em uma Jellyfish para que a maior capacidade possível da rede seja utilizada. De forma oposta, o k-shortest-path se mostrou ideal para a Jellyfish, já que aproveita melhor os links disponíveis.
Já a Tabela 1 faz um comparativo do funcionamento de protocolos de controle de congestionamento sendo implementados tanto em uma topologia Jellyfish quanto em uma Fat-Tree. Os protocolos comparados foram o TCP com 1 e 8 fluxos e o MPTCP com 8 subfluxos. Para ambos foram utilizadas tabelas de roteamento geradas pelo ECMP de 8 vias e também pelo k-shortest-path com k=8.
O Mininet foi escolhido como o simulador de redes, já que possui ampla documentação e um funcionamento estável. Por motivos de simplicidade e compatibilidade com o Mininet, python foi a linguagem de programação adotada para implementação.
Parte do código foi desenvolvido com base nos repositórios cs244-assignment2 e mininet-topology-simulation.
Partindo do princípio de que a Jellyfish pode ser representada como um grafo regular aleatório, foi usada uma biblioteca python denominada networkx, pois a mesma possibilita elaborar uma diversidade de grafos de forma trivial, além de prover muitas funções, como por exemplo, busca de menor caminho.
A abordagem para executar o experimento foi construir a Jellyfish como um grafo regular aleatório a partir de parâmetros passados por linha de comando a respeito das características da rede, como número de switches, conexões entre os switches e de quantidade de hosts.
Com o grafo gerado, foi obtido uma lista de adjacência dos nós e em seguida feito a contagem de caminhos com um algoritmo do ECMP e com k-shortest-path.
Finalmente, a Figura 9 foi gerada usando outra biblioteca python chamada matplotlib.
Um último, que pode ser considerado adicional (já que não faz parte do experimento da Figura 9) passo foi criar as tabelas de roteamento tanto do ECMP quanto do k-shortest-path. Essas tabelas seram utilizadas no próximo experimento.
Veja no README como executar o experimento.
Os resultados apresentados na Figura 9 dependem de três fatores:
- Número de switches
- Número de conexões entre switches
- Quantidade de hosts
Como os autores não mencionam exatamente os valores utilizados, uma bateria de testes foi realizada em busca de um resultado mais próximo possível do original, com o objetivo de tentar comprovar (ao menos visualmente) o comportamento da Jellyfish apresentado no artigo.
A figura a seguir apresenta o resultado mais aproximado obtido, usando 231 swicthes, com 12 interconexões cada, e 686 hosts.
Essa figura apenas representa em um formato de mais simples visualização os dados obtidos através da contagem feita pelos protocolos. Veja abaixo um pequeno trecho dos dados gerados.
('0', '2'): [['0', u'1', u'3', '2'], ['0', u'8', u'9', '2']], ('5', '8'): [['5', u'7', '8']]...
Analisando em detalhe esses dados foi possível observar que 1.525 links são utilizados por no máximo dois caminhos distintos com o ECMP de 8 vias. Isso significa que mais da metade dos links existentes estão sendo utilizados por apenas dois caminhos, ou seja, há um grande desperdício da capacidade da rede.
Já o k-shortest-paths (com k=8) mostrou um comportamento muito melhor, tendo em vista que o número de links utilizados por não mais que dois caminhos cai para 387.
Essa reprodução reafirma que o ECMP não gera uma diversidade suficiente para a Jellyfish, sendo uma melhor opção o k-shortest-path, condizendo com o que foi defendido pelos autores.
Para os experimentos dessa tabela foram utilizadas diferentes ferramentas para cada topologia.
No experimento anterior (Figura 9) a Jellyfish foi gerada como um grafo, e a partir deste foram obtidos os demais dados necessários. Dentre esse conteúdo estão a lista de adjacência e as tabelas de roteamento do ECMP e k-shortest-paths.
Desse modo, a abordagem desse experimento foi executar o pox e riplpox são passando como parâmetro na linha de comando a lista de adjacência e tabela de roteamento bem como as demais características da rede (topologia, número de switches, etc.).
O próximo passo foi gerar o script de comandos iperf para testar a rede.
Depois o Mininet é executado recebendo as características da rede juntamente com a lista de adjacência.
Com a rede iniciada basta apenas executar o script na CLI do Mininet e aguardar os resultados serem gravados em arquivos localizados em um diretóriio apropriado.
Para criar a rede Fat-Tree primeiro é iniciado um controlador pox informando as características da rede e que o roteamento deve ser encarregado pelo ECMP (já que a Tabela 1 só apresenta resultados da Fat-tree com ese protocolo).
Posteriormente é usado um código python similar ao da Jellifish para criar o script de testes com o iperf.
Por fim, o Mininet é iniciado, o script é executado e os dados de saída armazenados.
A seguir é apresentada a reprodução da Tabela 1 a partir dos experimentos.
| Congestion Control | Fat-Tree ECMP | Jellyfish ECMP | Jellyfish 8-shortest paths |
|---|---|---|---|
| TCP 1 flow | 83.43% | 79.79% | 62.21% |
| TCP 8 flows | 69.20% | 84.95% | 90.14% |
| MPTCP 8 subflows | -- | -- | -- |
Uma primeira observação é que a reprodução foi feita de forma parcial por conta de dificuldades encontradas ao executar o MPTCP (discutidas na sessão 3).
Outra divergência é que por conta de limitação de processamento computacional, os testes foram realizados com redes menores: 20 switches e 16 hosts.
De modo geral, os resultados mostram a superioridade da Jellyfish em relação à Fat-Tree. No entanto, alguns deles se diferem dos apresentados no artigo.
Um deles é da Fat-Tree com ECMP e 8 fluxos TCP, onde de 92.2% da tabela em [1] caiu para 69.20%. Curiosamente, ficando até mais baixo que o resultada da mesma topologia com TCP de 8 fluxos. A suspeita do ocorrido é que pelo fato do ambiente testado ser relativamente pequeno (poucos switches e hosts) os 8 fluxos do TCP não puderam ser bem aproveitados, pois não existiam caminhos (links) suficientes.
Apesar de algumas divergências, um dos principais resultados pode ser comprovado. A Jellyfish com o k-shortest-paths (k=8) e 8 fluxos TCP mostrou um comportamento muito semelhante à tabela original, já que em [1] o resultado foi 92.3% e na reprodução foi 90.14%.
Veja no README como executar o experimento.
Por conta de pouca experiência em redes SDN e com o Mininet, boa parte dos esforços foram concentrados em estudo de métodos de implementação de redes para o Mininet e testes de controlodores que fossem compatíveis com as topologias testadas.
Um desafio não vencido foi o uso MPTCP, já que o mesmo não faz parte, por exemplo, do kernel do sistema Linux. Algumas tentativas foram realizadas, mas todas sem sucesso.
Este reposítório apresenta uma abordagem para reproduzir alguns dos esperimentos feitos pelos criadores da Jellyfish, bem como os resultados obtidos.
Pode-se concluir que a Jellyfish possui muitas vantagens em relação a Fat-Tree quando implementada com protocolos de roteamento e controle de congestionamento adequado.
[1] Ankit Singla, Chi-Yao Hong, Lucian Popa, and P. Brighten Godfrey. 2011. Jellyfish: networking data centers, randomly. In Proceedings of the 3rd USENIX conference on Hot topics in cloud computing (HotCloud'11). USENIX Association, Berkeley, CA, USA, 12-12.