Relatorio Final

Universidade Federal do Espírito Santo
Programa Institucional de Iniciação Científica

Relatório Final de Pesquisa
Ciências Exatas e da Terra
Avaliação do uso do OpenFlow na recuperação de falhas em

Data Centers centrados nos servidores
Identificação:
Grande área do CNPq.: CIÊNCIA DA COMPUTAÇÃO
Área do CNPq: SISTEMAS DE COMPUTAÇÃO
Título do Projeto: Avaliação do uso do OpenFlow na recuperação de falhas em
Datacenters centrados nos servidores
Professor Orientador: RODOLFO DA SILVA VILLAÇA
Estudante PIBIC/PIVIC: PHILLIPI DE OLIVEIRA GIOBINI
Resumo: Em Data Centers centrados em servidores, estes não somente participam no processamento dos
dados, mas também no encaminhamento do tráfego de rede. Em geral os servidores são organizados em
uma topologia conhecida como hipercubo, onde o encaminhamento é feito através de simples operações
de ou-exclusivo (XOR). Se por um lado essa simplicidade contribui para o aumento da vazão e
diminuição da latência, por outro o encaminhamento só funciona caso o hipercubo esteja completo, ou
seja, na inexistência de falhas de nó ou enlace. Este trabalho se propõe a investigar uma alternativa,
baseada na tecnologia OpenFlow, para o tratamento de falhas em hipercubos. Espera-se, como resultado
deste projeto que, em caso de ocorrência de uma falha, um controlador SDN seja notificado e modifique
a forma de encaminhamento dos nós afetados por essa falha, calcule rotas alternativas e instale novas
regras de encaminhamento, garantindo a entrega das mensagens no Data Center.
Palavras chave: Data Center, XOR, OpenFlow, Roteamento, SDN.
1 – Introdução
Data Centers são bastante utilizados no processamento e armazenamento de grandes volumes de
dados e, em função disso, existem diversas arquiteturas para a montagem da sua infraestrutura, são
exemplos: Dcell [1], BCube [2], Al-Fares et al. [3]. Dentre essas arquiteturas destacam-se os Data
Centers centrados nos servidores (server-centric). A característica mais importante dos Data Centers
centrados nos servidores é que os elementos de rede (switches, por exemplo) não estão envolvidos
diretamente nas decisões de encaminhamento de tráfego de rede. Eles simplesmente fornecem conexões
entre os servidores, e estes sim, são os responsáveis por todas as decisões de encaminhamento no interior
do Data Center. Nesse contexto, equipamentos de rede de baixo custo (COTS, ou Commodity Off-the-
Shelf), podem ser utilizados na montagem da infraestrutura ou até mesmo ligações diretas entre os
servidores podem ser estabelecidas.
Uma topologia de interligação dos servidores bastante comum nas arquiteturas de Data Center
centrados nos servidores é o hipercubo [4]. Em um hipercubo cada servidor (que também pode ser
chamado de um nó na rede do Data Center) possui um identificador único de n-bits e n interfaces de rede,
que o interliga a outros n servidores, que serão os seus vizinhos no Data Center. A restrição na escolha
desses vizinhos é tal que cada servidor só poderá ter como vizinhos outros servidores cuja distância de
Hamming (D_h) entre seus identificadores é igual a 1, conforme Figura 1.
1
Figura 1 – Hipercubo com três (n = 3) dimensões.
Essa restrição facilita o processo de encaminhamento de tráfego no interior do Data Center, onde
basta uma simples operação de XOR para determinação da interface de saída para a qual os pacotes
deverão ser encaminhados a fim de alcançarem o seu destino.
Por exemplo, considere o cenário da Figura 1. Imagine que o nó 010 deseja enviar uma
mensagem para o nó de destino 001. O nó de origem conhece o identificador do nó de destino, então
efetua a operação XOR. A decisão de roteamento (d) entre os nós 010 (src) e 001 (dst) é representada pela
Equação a seguir:
d = src  dst (Equação 1)
onde  corresponde à operação XOR. O resultado desta operação será 011 onde o primeiro bit 1 (menos
significativo) representa o eixo x, o segundo bit 1 representa o eixo y e o terceiro bit 0 (mais significativo)
representa o eixo z. Temos então dois caminhos de menor custo disponíveis até o destino desejado: um no
eixo x e outro no eixo y, cujos bits são iguais a 1. Isso quer dizer que encaminhar a mensagem nas
direções x ou y resultará em caminhos de custo igual. Em geral, sorteia-se aleatoriamente um próximo
para dar seguimento ao encaminhamento da mensagem até o seu destino final, 001. Dentre essas duas
possibilidades, selecionando-se por exemplo o caminho do eixo x a mensagem é transmitida para o nó
011. Por sua vez, o nó 011 recebe e efetua novamente a operação da Equação 1, com src=011 e como
resultado temos 010. Como o único bit igual a 1 corresponde ao eixo y a mensagem é encaminhada por
esse eixo chegando ao destino com o menor custo possível.
Embora o encaminhamento baseado em operações XOR seja bastante eficiente [5, 6], o mesmo
só funciona em situações onde os hipercubos virtuais estão completos, ou seja, na ausência de falhas de
nós ou de enlaces no Data Center. Na ocorrência de uma falha o resultado da operação XOR poderá
indicar uma interface de saída que leve o pacote a um nó inoperante ou a um enlace indisponível, o que
irá ocasionar perda de pacotes e quebra da completa conectividade entre os nós do Data Center enquanto
a falha estiver presente.
Devido a isso, torna-se necessário a proposição de soluções capazes de lidar com esse problema,
e este projeto se propõe a apresentar uma abordagem baseada em Redes Definidas por Software (SDN, ou
Software Defined Networking), especificamente no protocolo OpenFlow [7], para garantir o
encaminhamento de tráfego em Data Centers centrados nos servidores ligados na topologia de hipercubo.
2
Em [8] foi apresentada uma solução, denominada FlexForward, capaz de alterar dinamicamente a forma
de encaminhamento dos nós de um Data Center em função de mensagens de controle do protocolo
OpenFlow. No FlexForward todos os nós estão ligados a um plano de controle baseado no protocolo
OpenFlow.
Na ocorrência de uma falha de enlace (ou na indisponibilidade de um nó) o controlador é
avisado, reconstrói o grafo de conectividade, calcula rotas entre todas os possíveis origens e destinos para
os nós afetados por essa falha, envia mensagens de modificação das tabelas do protocolo OpenFlow e
altera a forma de encaminhamento dos nós, garantindo-se assim a conectividade mesmo durante o período
de restauração da falha.
2 – Objetivos
Sabendo-se que a topologia de hipercubo é bastante utilizada em Data Centers capazes de
armazenar e processar grandes volumes de dados, devido à simplicidade e baixa latência no
encaminhamento de pacotes na rede, o objetivo principal deste trabalho de Iniciação Científica é
implementar uma solução simples, baseada no protocolo OpenFlow, para o problema da conectividade em
hipercubos incompletos.
3 – Metodologia
Mininet [9] é um emulador de rede, que cria uma rede de hosts virtuais, switches, controladores e
links. Executa software de rede padrão do Linux, e seus switches suportam OpenFlow [10] para o
encaminhamento personalizado e altamente flexível em Redes Definidas Por Software.
Para controlar e gerenciar todos os dispositivos emulados, o Mininet fornece uma CLI
(Command Line Interface) conhecedora de toda a rede, ou seja, através de um único console, pode-se
controlar todos os dispositivos emulados. Outra grande vantagem desse emulador é a facilidade de criação
de topologias customizadas através de uma API (Application Programming Interface) para programação
em Python, que foi amplamente utilizada para execução dos algoritmos deste trabalho.
O Controlador utilizado foi o Ryu [11], por ser uma plataforma aberta que suporta as versões
mais recentes do protocolo OpenFlow. Em geral, o controlador SDN é o "cérebro" do ambiente SDN,
gerenciando o envio de pacotes e tratamento de eventos entre switches e roteadores compatíveis. No
desenvolvimento desta aplicação, realizamos uma divisão das atividades em módulos [12] (plano de
controle), onde cada um responsável por uma determinada etapa na construção das regras de fluxo,
partindo desde a manipulação das mensagens de falha até a geração das regras de modificação que serão
instaladas em cada um dos nós no hipercubo. Portanto, os módulos ficaram divididos da seguinte forma:
• 1) Recepção das Mensagens;
• 2) Tratamento dos Eventos;
• 3) Representação Topológica e Cálculo das Rotas e;
• 4) Instalação das regras de encaminhamento, identificado na Figura 2.
3
Figura 2: Estrutura da Aplicação.
No módulo Recepção das Mensagens o controlador deverá, primeiramente, identificar o tipo de

mensagem que foi encaminhado para o controlador. Somente mensagens referentes às falhas e restauração
dos enlaces ou nós do hipercubo serão tratadas por este módulo. Para o caso de recebimento de
mensagens ou eventos relacionados ao plano de dados (falha de enlace ou nó), a aplicação encaminhará
esta mensagem para tratamento no módulo Tratamento de Eventos.
Assim que a aplicação interceptar os pacotes de ARP e encaminhar para a aplicação de ARP
Proxy, o módulo em questão interpretará as mensagens de ARP Request para em seguida enviar uma
mensagem de ARP Reply utilizando o mecanismo de Packet-Out presente no Openflow [13]. Este
mecanismo permite o envio de pacotes utilizando uma porta espec ıı
fica do nó controlado, pois as
mensagens de Packet-Out contém o pacote completo e a sua respectiva ação, que pode ser o
encaminhamento por uma determinada porta.
O módulo de Tratamento de Eventos basicamente irá identificar o(s) nó(s) ou enlace(s) afetados
a partir das mensagens de falha recebidos no plano de controle. Uma vez identificados o(s) nó(s) ou
enlace(s) defeituoso(s), essa identificação será encaminhada para o módulo Representação Topológica e
Cálculo de Rotas.
No caso de falha em algum nó ou enlace, assim que ocorrer a detecção do evento correspondente
a aplicação deverá identificar e atualizar a mudança topológica ocorrida no grafo. Em seguida, as rotas
deverão ser recalculadas, baseando-se no algoritmo de Dijkstra. Através do módulo de Instalação das
Regras são geradas mensagens de Flow-Mod para todos os nós afetados pela falha.
3.1 – Construção do Hipercubo e NetworkX

Em teoria dos grafos, um grafo hipercubo [14] é um grafo regular com 2^n vértices, que
correspondem a um subconjunto de n elementos, como foi apresentado na Figura 1. Um dos desafios
deste trabalho, após o estudo de grafos, foi desenvolver um algoritmo, que é executado durante a
inicialização (boot), e nos casos de falha do Hipercubo. Sua principal tarefa é verificar se a ligação entre
as interfaces de cada nó simulado no mininet respeita as propriedades de um hipercubo.
4
Até onde foi possível pesquisar, quase não se encontra trabalhos que explique um método de
criação e distribuição dos dos ID’s. O melhor encontrado, funciona com árvore de caminhos mínimos,
que consegue distribuir os ID’s por tentativa e erro, o que o torna ineficiente com um hipercubo de
grandes dimensões. O que mais se encontra, é hipercubos de dimensões pequenas, que podem ser feitos
geometricamente, sem muita dificuldade.
Após um estudo, e muitos esboços manuais de grafos a respeito do problema, foi possível
perceber que ao representar o grafo do hipercubo por matriz de adjacência, seguindo determinadas regras,
a matriz resultante começou a formar padrões interessantes, fundamentais na construção do algoritmo.
Uma matriz de adjacência [15] é uma das formas de se representar um grafo. Dado um grafo G com n
vértices, podemos representá-lo em uma matriz nxn A(G)=[aij] (ou simplesmente A). Para representarmos
um grafo não direcionado, simples e sem pesos nas arestas, basta que as entradas aij da matriz A
contenham 1 se Vi e Vj são adjacentes e 0 caso contrário.
Por hora, vamos considerar que o ID de cada vértices é sua coordenada, e que cada dimensão
dessa coordenada varia apenas entre bits 0 e 1. Na próxima seção, trataremos como um ID de fato, mas
aqui tornará mais facil para uma compreensão geométrica do problema.
Vamos analisar o quadrado apresentado na Figura 3(a). As coordenadas dos vértices estão
distribuidas respeitando as propriedades do plano cartesiano. Seus vértices, numerados de 1 a 4, estão
distribuidos com base na tabela verdade da Figura 3(b). A tabela tem como entrada as coordenas xy dos
vértices na ordem invertida, e na coluna de saída (V) a numeração sequencial dos vértices. A inversão das
coordenadas preserva a sequencia binária de entrada da tabela verdade, enquanto que a distribuição
sequencial na coluna de saída (V) preserva a distância de Hamming entre os vértices adjacentes. A Figura
3(c) apresenta a matriz de adjacência formada pela ligação dos vértices na Figura 3(a). A ligação entre os
vértices iguais (quando i=j) não é feita, pois estamos interessados apenas nos vizinhos daquele vértice. A
matriz ainda não nos revela muitas informações, mas é importante compreendê-la, pois faz parte da base
de uma recursão.
Y X V
0 0 1
0 1 2
1 0 3
1 1 4
(a) (b) (c)

Figura 3: Modelo 2D com Tabela Verdade e Matriz de Adjacência.
A Figura 4(a) apresenta um cubo, com vértices numerados de 1 a 8. De forma análoga ao

quadrado, com a adição da coordenada z, a Figura 4(b) apresenta a tabela verdade do cubo. Sua entrada
possui as coordenadas dos vértices xyz invertidas, e da mesma forma, a distribuição sequencial na saída
(V) preserva a distância de Hamming entre os vértices adjacentes. O propósito de distribuir a numeração
usando essa configuração de tabela verdade, passa a fica mais claro quando analisamos a matriz de
adjacência correspondente, apresentada na figura 4(c). Repare que o 4º quadrante da matriz possui o
5
mesmo padrão de conexões do 2º quadrante, enquanto que o 1º e 3º quadrantes possuem uma matriz
identidade. A função dessas matrizes identidades é conectar os dois quadrados, através dos seus vértices
correspondentes com uma terceira dimensão, formando um cubo. Por exemplo, os vértices 1 e 5 da Figura
4(a) são correspondentes, e interligados pela dimensão z.
Z Y X V
0 0 0 1
0 0 1 2
0 1 0 3
0 1 1 4
1 0 0 5
1 0 1 6
1 1 0 7
1 1 1 8
(a) (b) (c)

Figura 4: Modelo 3D com Tabela Verdade e Matriz de Adjacência.
A figura 5(a) apresenta um hipercubo de quatro dimensões. A tabela verdade funciona

exatamente da mesma forma dos casos anteriores, apenas com a adição de uma quarta coordenada. Por
exemplo, o vértice 1 tem coordenadas (0,0,0,0), 9 => (1,0,0,0), 8 => (0,1,1,1) e 16 => (1,1,1,1). A figura
5(b) apresenta a matriz de adjacência correspondente, onde já se torna possível observar alguns padrões
interessantes. O hipercubo de quatro dimensões, é basicamente dois cubos, representados na matriz pelos
quadrantes 2 e 4, que são padrões já conhecidos do passo anterior. O que muda é a quarta dimensão
conectando os vértices correspondentes de cada cubo, novamente através de duas matrizes identidades
nos quadrantes 1 e 3. A recursão fica mais evidente nesse passo.
(a) (b)
Figura 5: Modelo 4D e Matriz de Adjacência.
A Figura 6(a) apresenta um hipercubo de 5 dimensões, onde ainda é possível representá-lo de uma
maneira pouco abstrata. Aqui novamente temos a adição de mais uma dimensão. Se observar atentamente
a figura, é possível perceber que, para formar este hipercubo, une-se os vértices correspondentes dos dois
hipercubos de 4 dimensões, através da quinta dimensão. A Figura 6(b) apresenta a matriz correspondente,
onde nos quadrantes 2 e 4, vemos o hipercubo de quatro dimensões sendo conectados pelos quadrantes 1
e 3, através das matrizes identidades.
6
(a) (b)
Figura 6: Modelo 5D e Matriz de Adjacência.
Usando essa representação por matrizes de adjacência, de forma recursiva, podemos criar um
hipercubo tão grande quanto precisarmos, de uma maneira rápida e eficiente. Não é preciso fazer o
desenho e nem a tabela verdade para monta-lo. Por exemplo, usando a matriz da Figura 6(b), onde temos
um hipercubo de 5 dimensões (2^5 = 32 nós), basta fazermos uma contagem binária de 5 bits e atribuir de
forma sequencial a cada nó. Então, o ID do nó 1 => 00000, do nó 2=>00001, …, do nó 32=>11111.
Exemplos de verificação entre nós adjacentes:
• 16=>01111 e 32=>11111, temos que 01111  11111 = 10000.
• 4=>00011 e 12=>01011, temos que 00011  01011 = 01000.
• 11=>01010 e 27=>11010, temos que 01010  11010 = 10000.

Com esse conhecimento adquirido, foi desenvolvido um algoritmo na linguagem python,
juntamente com a biblioteca NetworkX [16]. O algoritmo cria a matriz de acordo com a dimensão
desejada, insere os vértices e atributos (ID’s) no NetworkX, e percorre cada linha da matriz inserindo as
arestas entre os vértices, parar criar o um objeto (grafo) hipercubo. Esse objeto é instanciado pelo mininet,
onde então é criada a topologia. Algumas observações sobre esse método estão descritas na seção
Resultados.
3.2 – Dristribuição de ID’s

Além de gerar o hipercubo, a matriz de adjacência serve também para verificar falhas de
conectividade no hipercubo e distribuição dos ID’s, obedecendo a distância de Hamming. Se não foi
possível fazer uma distribuição de ID’s, então o hipercubo possui falhas, ou vice-versa.
Este algoritmo pode ser usado em casos onde o controlador desconhece a ligação física,
descobrindo as ligações através de um FLOOD (inundação de pacotes) de forma controlada, ou seja, o(s)
nó(s) já inundado(s) e conhecido(s) pelo controlador não fazem FLOOD. No fim do processo, é esperado
7
que o controlador conheça todos os nós, e seus vizinhos, para que o algoritmo identifique falhas ou
distribua seus ID’s. Também é usado para verificar quando ocorre algum evento, seja ele queda ou
reestabelecimento de alguma aresta no grafo do hipercubo do NetworkX, para determinar se os pacotes
serão encaminhados via XOR, ou da forma convencional por tabelas de roteamento.
Vamos considerar o hipercubo de quatro dimensões apresentado na Figura 7(a). Neste exemplo,
os nós estão identificados com letras para não serem confundidos com os números da matriz de
adjacência, e estão distribuidas de forma aleatória. Após o FLOOD, o controlador tem algo semelhante ao
apresentado na Figura 7(b), uma lista de nós com seus respectivos vizinhos (listagem de vizinhança).
A => [B, F, N, P] I => [B, F, H, M]

B => [A, I, J, K] J => [B, C, H, P]
C => [D, J, K, L] K => [C, E, H, M]
D => [C, E, N, P] L => [B, C, M, N]
E => [D, G, K, O] M => [I, K, L, O]
F => [A, G, I, O] N => [A, D, L, O]
G => [E, F, H, P] O => [E, F, M, N]
H => [G, I, J, K] P => [A, D, G, J]
(a) (b)
Figura 7: Hipercubo de 4 dimensões, sem distribuição de ID’s
Para essa distribuição de ID’s, consideramos a matriz da Figura 5(b), que deve ser da mesma
dimensão do hipercubo (ordem 4). O primeiro passo do algoritmo é obtermos a primeira linha da figura
5(b), e inserir em um vetor de tamanho 2^4 = 16 posições, da seguinte forma:
A B F N P
O primeiro nó de uma listagem de vizinhança é inserido no vetor de tal forma que, a identificação do nó
ocupa a 1ª posição do vetor (neste caso, o “A”), e seus vizinhos são colocados no vetor acima de acordo
com a primeira linha da matriz da figura 5(b), nas posições correspondentes marcadas com 1, ou seja, as
posições 2, 3, 5 e 9, que estão ocupadas por “B”, “F”, “N”, “P”, respectivamente. Neste passo, não é
necessário se preocupar com a ordem de “B”, “F”, “N”, e “P”, desde que o “A” esteja na primeira posição
e os elementos ocupem as posições mencionadas.
Vamos preencher a quarta posição do vetor, que se encontra em branco. Precisamos colocar um
nó ali que tenha o “B” e “F” como vizinhos, e que ainda não está no vetor. Analisando a Figura 7(b),
verificamos que o “I” atende os requisitos. Inserindo no vetor, temos:
A B F I N P
Vamos preecher a sexta posição. Recorrendo novamente a matriz da Figura 5(b), vamos precisar da sexta
linha. Da sexta linha, temos que 6 => [2, 5, 8, 14], onde vamos usar esses vizinhos do “6” para fazer uma
correspondência de posições do nosso vetor acima. O elemento 2, corresponde ao “B” (2ª posição), o
elemento 5 corresponde ao “N” (5ª posição), e as posições 8º e 14º do vetor estão vazias, portanto são
ignoradas. Agora temos que encontrar na Figura 7(b) novamente, um nó que tenha o “B” e “N” como
vizinhos, e que ainda não estão no vetor. Verificamos que o “L” atende aos requisitos, então preencherá a
sexta posição. Inserindo no vetor, temos:
A B F I N L P
8
Da mesma forma, vamos preencher a sétima posição do vetor. Da matriz, temos que 7 => [3, 5, 8, 15]. Do
nosso vetor, temos que “F” ocupa a 3ª posição e “N” a 5ª posição (8ª e 15ª posição vazias, então
ignoramos). Então, o elemento que possui “F” e “N” como vizinhos e ainda não está no vetor, é o “O”.
A B F I N L O P
Da mesma forma para a oitava posição, da matriz temos que 8 => [4, 6, 7, 16], então, do vetor temos “I”
(4ª posição), “L” (6ª posição), “O” (7ª posição) e o 16º elemento está em branco. Então, o elemento que
possui “I”, “L” e “O” como vizinhos, de acordo com a Figura 7(b), é o elemento “M”. Inserindo, temos:
A B F I N L O M P
Executando exatamente o mesmo algoritmo para todas as posições em branco, da esquerda para direita,
de forma sequencial (sem pular posições), obtemos o vetor:
A B F I N L O M P J G H D C E K
Se, em algum dos passos não for possível encontrar TODOS os elementos que um nó o possua como
vizinho, por exemplo, alguém que possua “X”, “Y” e “Z” como vizinho, e nenhum vértice corresponder
com os três elementos, então não é um hipercubo (existe falha em algum link). Caso contrário, da mesma
forma que na construção do hipercubo, basta fazer uma contagem binária de n=4 bits, e distribuir essa
contagem de forma sequencial ao vetor, tornando-se o ID de cada nó.
A B F I N L O M P J G H D C E K
0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
Substituindo as letras pelos ID’s, todos os vértices adjacentes da Figura 7(a) terão distância de Hamming
igual a 1. Esse algoritmo pode ser usado para cubos de qualquer ordem. É claro que, conforme aumenta a
dimensão, a quantidade de buscas do algoritmo aumenta de forma exponencial. Sua performance será
mostrada na seção resultados.
3.3 – Plano de Dados e Verificação de Falhas

Em um hipercubo completo, a decisão de encaminhamento é feita simplesmente baseando-se em
operações XOR. O plano de dados ou plano de encaminhamento em uma Rede Definida por Software tem
como função central o encaminhamento de pacotes, isto é, escoar o tráfego da rede. Logo, o plano de
dados passa a ser representado pelos equipamentos de rede, sejam eles físicos ou virtuais, que possuam a
capacidade de encaminhar pacotes. A Figura 8 exemplifica uma topologia mínina, de grau 3 (três), a qual
interliga oito nós e cada um deles está interligado ao nó controlador no Plano de Controle.
Em uma rede com Openflow, utilizamos uma identificação exclusiva para cada plano de dados
(ou nó), denominada de DPID (DataPath IDentification) [12], que inicia sua identificação a partir do
valor 1 (um). No caso da topologia hipercubo com grau três, a identificação de cada nó no controlador
estará no intervalo de 1 a 8. Como a identificação em uma rede com encaminhamento XOR é iniciada
pelo valor 0 (zero) e, no caso de uma rede hipercubo com grau 3, o valor final será 7, a aplicação do
controlador deverá mapear estes endereços do hipercubo utilizados anteriormente pelo encaminhamento
XOR com os endereços correspondentes ao DPID de cada nó.
9
Figura 8: Topologia hipercubo com as rotas de encaminhamento.
Conforme podemos observar na Figura 8, para realizar a comunicação do nó H1 com o nó H8, o

controlador deverá instalar regras de fluxo baseando-se nos endereços de destino do hipercubo e, como
ação, o fluxo deverá ser encaminhado para uma determinada porta de saıı
da ( OF_OUTPUT). Vejamos,
como exemplo, a regra instalada no nó 0 (DPID 1): match: dl dst: 00:00:00:07:00:01, actions: OUTPUT
2. Neste exemplo o nó 0 irá encaminhar os pacotes para a interface 2 quando o MAC Address de destino
for 00:00:00:07:00:01, que está atrelado ao nó 7 (DPID 8). O final do endereço MAC (00:01), é usado
para identificação do hipercubo [12].
Diante da ocorrência de falhas na topologia hipercubo, torna-se necessário um mecanisno que
detecte e crie alternativas de encaminhamento, pois as operações XOR não atendem a esse propósito. O
módulo de Tratamento de Eventos basicamente irá identificar o(s) nó(s) ou enlace(s) afetados a partir das
mensagens de falha, através de um evento OpenFlow informando falha em algum determinado enlace ou
nó, recebido no plano de controle. Uma vez identificados o(s) nó(s) ou enlace(s) defeituoso(s), essa
identificação será encaminhada para o módulo Representação Topológica e Cálculo de Rotas, que possui
duas funções específicas agrupadas em um mesmo módulo.
Através da função de Representação Topológica tem-se uma visão do grafo associado ao
hipercubo. Ao ser identificado o(s) nó(s) ou enlace(s) defeituoso(s) a função de representação topológica
modificará a representação do grafo do hipercubo no NetworkX, removendo ou adicionando nós ou
arestas.
Depois da modificação do grafo causada por algum evento de falha em algum enlace ou nó, a
função de Cálculo das Rotas determinará as novas rotas para os nós afetados por essa falha. No cálculo
das rotas, utilizamos o algoritmo de Djikstra (Shortest Path) responsável pelo cálculo das rotas
alternativas de menor caminho no cubo incompleto. Essas novas rotas serão encaminhadas para o módulo
Instalação das Regras que será responsável pela geração das regras de Flow-Mod [13] a serem enviadas
aos nós afetados. Como as tabelas de encaminhamento de cada nó possuem todos os possíveis destinos da
rede, causa impacto negativo em um hipercubo com muitas dimensões.
4 – Resultados
10
Foi utilizado como ambiente de emulação o Mininet 2.2.0, por ter suporte ao OpenFlow 1.3. Em
conjunto, como máquina de encaminhamento (software switch) foi utilizado o Open vSwitch [9] na
versão 2.3. Como descrito no início da metodologia, o controlador utilizado foi o Ryu, e os algoritmos
desenvolvidos na linguagem Python. Os testes foram realizados no Laboratório de Redes e
Telecomunicações do CEUNES, onde a máquina virtual do mininet foi executada em uma máquina com
processador Intel Core i7 (3ª Ger.), com 32 GB de RAM, sobre o Ubuntu 16.04 LTS.
Para resultados precisos, cada experimento foi repetido 50 vezes (5 repetições para hipercubos
acima de 15 dimensões, devido a demora). Os tempos mostrados nos resultados a seguir, são médias
aritméticas. Os resultados também não consideram o tempo de FLOOD (inundação controlada de pacotes
para descoberta de nós), apenas o tempo que ação levou para ser processada no plano de controle
(Controlador).
O gráfico da Figura 8(a) apresenta o tempo gasto para a criação do grafo do Hipercubo no
NetworkX, de acordo com a quantidade de dimensões. A tabela da Figura 8(b) apresenta com mais
precisão os valores do gráfico. Como pode ser observado no gráfico, a curva de tempo tem um
comportamento exponencial (quanto mais dimensões, mais tempo gasto).
Dimensão Qnt. Vértices Tempo Méd. Criação
3 8 0,190 ms
4 16 0,194 ms
5 32 0,205 ms
6 64 0,217 ms
7 128 0,452 ms
8 256 0,802 ms
9 512 1,394 ms
10 1024 2,702 ms
11 2048 6,384 ms
12 4096 12,988 ms
13 8192 27,847 ms
14 16384 57,446 ms
15 32768 119,62 ms
16 65536 521,292 ms
17 131072 527,755 ms
18 262144 1129,605 ms
(a) (b)
Figura 8: Tempo Médio de Criação do Hipercubo.
O algoritmo de criação do hipercubo sofreu algumas modificações. Sua primeira versão

funcionava de forma recursiva, criando toda a matriz de adjacência. Apesar de ser relativamente simples
criar hipercubos dessa forma, o algoritmo fazia um consumo excessivo de memória RAM. Sua segunda
versão, ao invés de criar toda a matriz na memória, recria apenas um vetor de adjacência para cada nó,
percorre e adiciona as arestas no NetworkX, recria o próximo vetor e insere, e assim por diante,
eliminando o problema. O comparativo de consumo de memória entre a primeira e segunda versão é
apresentado na Tabela 1.
Dimensão Qnt. Vértices Matriz Adjacência Vetor Adjacência
3 8 64 B 8B
4 16 256 B 16 B
5 32 1 KB 32 B
6 64 4 KB 64 B
7 128 16 KB 128 B
8 256 64 KB 256 B
9 512 256 KB 512 B
10 1024 1 MB 1 KB
11
11 2048 4 MB 2 KB
12 4096 16 MB 4 KB
13 8192 64 MB 8 KB
14 16384 256 MB 16 KB
15 32768 1 GB 32 KB
16 65536 4 GB 64 KB
17 131072 16 GB 128 KB
18 262144 64 GB 256 KB
Tabela 1: Comparativo de consumo de RAM entre Matriz e Vetor de Adjacência.
O gráfico da Figura 9(a) apresenta o tempo gasto na verificação de falhas do grafo modificado
do NetworkX, de acordo com a quantidade de dimensões. Toda vez que um ou mais links são
reestabelecidos, a função de Cálculo das Rotas precisa verificar se o hipercubo está completo. Quanto
mais dimensões, mais custosa a verificação se torna. A tabela da figura 9(b) apresenta com mais precisão
os valores do gráfico.
Dimensão Qnt. Nós Tempo Méd. Verificação

3 8 0,211 ms
4 16 0,257 ms
5 32 0,372 ms
6 64 0,476 ms
7 128 0,855 ms
8 256 2,147 ms
9 512 4,124 ms
10 1024 10,031 ms
11 2048 28,962 ms
12 4096 79,125 ms
13 8192 240,932 ms
14 16384 795,057 ms
15 32768 963,612 ms
16 65536 14,841 s
17 131072 85,562 s
18 262144 374,231 s
(a) (b)
Figura 9: Tempo Médio de Verificação de Falhas no Grafo
O gráfico da Figura 10(a) apresenta a quantidade de buscas que a função de verificação de falhas
precisa fazer para cada dimensão do hipercubo. Essas são as buscas descritas na seção 3.2, onde o
algoritmo precisa encontrar qual nó possui determinados elementos como vizinho. A quantidade de
buscas aumenta exponencialmente conforme a quantidade de dimensões. A tabela da figura 10(b)
apresenta com mais precisão os valores do gráfico.
Dimensão Qnt. Nós Qnt. Buscas
3 8 15
4 16 52
5 32 135
6 64 306
7 128 651
8 256 1352
9 512 2799
10 1024 5830
11 2048 12243
12 4096 25884
13 8192 54951
14 16384 116858
15 32768 248475
16 65536 527632
17 131072 1118175
18 262144 2364174
(a) (b)
12
Figura 10: Quantidades de Buscas por Verificação
Caso seja encontrado falhas no grafo do hipercubo, a função de Representação Topológica

removerá as falhas e usará o Algoritmo de Dijkstra (Shortest Path) para calcular a menor rota entre os nós
do hipercubo incompleto. Essas novas rotas serão encaminhadas para o módulo Instalação das Regras que
será responsável pelo envio aos nós afetados. Cada nó passa a ter todos os destinos possíveis, causando
um grande impacto na recuperação de falhas em cubos de grandes dimensões. O gráfico da Figura 11(a)
apresenta o tempo de recuperação entre falhas, de acordo com a quantidade dimensões. A tabela da figura
11(b) apresenta com mais precisão os valores do gráfico. Esse experimento foi realizado até a 12ª
dimensão, devido sua morosidade. Na 13ª Dimensão, o tempo gasto foi superior a 1 hora.
Dimensão Quant. Nós Tempo Méd. Instalação

3 8 0,099 ms
4 16 0,559 ms
5 32 1,225 ms
6 64 7,108 ms
7 128 36,867 ms
8 256 222,436 ms
9 512 1,500 s
10 1024 11,006 s
11 2048 83,742 s
12 4096 645,017 s
13 8192 > 1h
(a) (b)
Figura 11: Tempo Médio de Instalação das Tabelas.
Com base nos dados anteriores, a Tabela 2 apresenta o tempo total de recuperação de falhas.
Caso haja falhas simultâneas, a função de Representação Topológica e o módulo Instalação das Regras
irão tratar essas falhas obedecendo uma fila, ou seja, o tempo será multiplicado de acordo com a
quantidade de falhas, de acordo com o tamanho do hipercubo. Durante o tempo de recuperação, pacotes
que utilizam rotas com falha(s) via operação XOR serão perdidos, até que as novas tabelas de roteamento
sejam instaladas, recuperando a conectividade.
Dimensão Qnt. Nós Tempo Méd. Verificação Tempo Méd. Instalação Tempo Méd. Recuperação Falhas
3 8 0,211 ms 0,099 ms 0,31 ms
4 16 0,257 ms 0,559 ms 0,816 ms
5 32 0,372 ms 1,225 ms 1,597 ms
6 64 0,476 ms 7,108 ms 7,584 ms
7 128 0,855 ms 36,867 ms 37,772 ms
8 256 2,147 ms 222,436 ms 224,583 ms
9 512 4,124 ms 1,500 s 1,504 s
10 1024 10,031 ms 11,006 s 11,007 s
11 2048 28,962 ms 83,742 s 83,771 s
12 4096 79,125 ms 645,017 s 645,096 s
Tabela 2: Tempo total gasto na recuperação de uma falha.
5 – Discussão e Conclusões
Este relatório apresentou os resultados de uma avaliação de desempenho de uma solução baseada
no protocolo OpenFlow para garantir conectividade em hipercubos incompletos, uma topologia
13
tradicional em Data Centers centrados nos servidores. Para validação da proposta foi implementado um
protótipo experimental com uso do Mininet, controlador Ryu e OpenFlow 1.3.
A solução apresentada está longe de ser uma solução definitiva, mas atende bem em casos onde
são utilizadas poucas dimensões. Em trabalhos relacionados [12], existem métodos de compactação de
tabelas para os casos de falhas, solução que reduz, em alguns casos, em mais de 99% a quantidade de
entradas nas tabelas de encaminhamento e uniformiza a distribuição dos fluxos, em uma comunicação de
todos para todos, em 100% dos enlaces, ambos no plano de dados. Faz parte de uma dissertação de
mestrado, e está fora do escopo deste trabalho.
Mesmo em ambientes emulados, há alguma perda de conectividade até que se detecte a falha e
seja feita a instalação de rotas alternativas nos nós do hipercubo. Após isso, a conectividade é restaurada e
pode-se afirmar que o tempo de instalação das rotas alternativas é pequeno, em geral menor do que o
tempo de restauração da falha de um nó ou enlace, que pode ser da ordem de minutos ou horas.
Foram notadas instabilidades no mininet com após um tempo de funcionamento com hipercubos
grandes. Ao fim de cada teste, toda a topologia era reiniciada por completo. Grande toda ou parte da
literatura sobre SDN e OpenFlow, se encontra em lingua estrangeira.
6 – Referências Bibliográficas
[1] Guo, C., Wu, H., Tan, K., Shi, L., Zhang, Y., and Lu, S. (2008). Dcell: A scalable and fault-tolerant
network structure for data centers. SIGCOMM Computer Communications Review, 38(4):75–86.
[2] Guo, C., Lu, G., Li, D., Wu, H., Zhang, X., Shi, Y., Tian, C., Zhang, Y., and Lu, S. (2009). BCube: A
High Performance, Server-Centric Network Architecture for Modular Data Centers. SIGCOMM
Computer Communications Review, 39(4):63–74.
[3] Al-Fares, M., Loukissas, A., and Vahdat, A. (2008). A scalable, commodity data center network
architecture. SIGCOMM Computer Communications Review, 38(4):63–74.
[4] Saad, Y. and Schultz, M. H. (1989). Data communication in hypercubes. Journal of Parallel and
Distributed Computing, 6(1):115 – 135.
[5] Performance analysis of k-ary n-cube interconnection networks. IEEE Transactions on Computers,
39(6):775–785.
[6] Fujiwara, I., Koibuchi, M., Matsutani, H., and Casanova, H. (2014). Skywalk: A topology for hpc
networks with low-delay switches. In Proceedings of the 2014 IEEE 28th International Parallel and
Distributed Processing Symposium, IPDPS ’14, pages 263–272, Washington, DC, USA. IEEE
Computer Society.
[7] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S.,
andTurner, J. (2008). Openflow: Enabling innovation in campus networks. SIGCOMM Computer
Communications Review, 38(2):69–74.
[8] Vencioneck, R., Vassoler, G., Martinello, M., Ribeiro, M., and Marcondes, C. (2014). Flexforward:
Enabling an sdn manageable forwarding engine in open vswitch. In Network and Service
Management (CNSM), 2014 10th International Conference on, pages 296–299.
14
[9] Brandon Heller Reproducible network research with high-fidelity emulation Ph.D. Thesis, Stanford
University, 2013.
[10] Ben Pfaff, Justin Pettit, Teemu Koponen, Ethan Jackson, Andy Zhou, Jarno Rajahalme, Jesse Gross,
Alex Wang, Joe Stringer, Pravin Shelar, Keith Amidon,Martin Casado (2015). The Design and
Implementation of Open vSwitch. 12th USENIX Symposium on Networked Systems Design and
Implementation (NSDI 15). pages 117-130.
[11] Ryu. Build SDN Agilely. Website. “https://osrg.github.io/ryu/”.
[12] DE LIMA, Dione S. A. Uma Abordagem OpenFlow para Tratamento de Falhas na Topologia
Hipercubo com Compactação de Tabelas de Encaminhamento. 2016. 72 f - Universidade Federal do
Espírito Santo. Vitória – ES. 2016.
[13] ONF, O. N. F. (2012). Openflow switch specification version 1.3.0 (wire protocol 0x04). Website.
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-
specifications/openflow/openflow-spec-v1.3.0.pdf.
[14] Harary, F.; Hayes, J. P.; Wu, H.J. (1988), «A survey of the theory of hypercube graphs», Computers
& Mathematics with Applications.
[15] CHARTRAND, G., LESNIAK, L. Graphs & Digraphs. Editora CRC Press, 2004.
[16] NetworkX. High-productivity software for complex networks. Website.
“https://networkx.github.io/”.
15

Relatorio Final

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Relatorio Final

Transféré par

Droits d'auteur :

Formats disponibles

Universidade Federal do Espírito Santo

Programa Institucional de Iniciação Científica

Avaliação do uso do OpenFlow na recuperação de falhas em

Palavras chave: Data Center, XOR, OpenFlow, Roteamento, SDN.

Figura 1 – Hipercubo com três (n = 3) dimensões.

Figura 2: Estrutura da Aplicação.

No módulo Recepção das Mensagens o controlador deverá, primeiramente, identificar o tipo de

3.1 – Construção do Hipercubo e NetworkX

(a) (b) (c)

A Figura 4(a) apresenta um cubo, com vértices numerados de 1 a 8. De forma análoga ao

(a) (b) (c)

A figura 5(a) apresenta um hipercubo de quatro dimensões. A tabela verdade funciona

• 4=>00011 e 12=>01011, temos que 00011  01011 = 01000.

• 11=>01010 e 27=>11010, temos que 01010  11010 = 10000.

3.2 – Dristribuição de ID’s

A => [B, F, N, P] I => [B, F, H, M]

3.3 – Plano de Dados e Verificação de Falhas

Figura 8: Topologia hipercubo com as rotas de encaminhamento.

Conforme podemos observar na Figura 8, para realizar a comunicação do nó H1 com o nó H8, o

O algoritmo de criação do hipercubo sofreu algumas modificações. Sua primeira versão

Dimensão Qnt. Nós Tempo Méd. Verificação

Figura 10: Quantidades de Buscas por Verificação

Caso seja encontrado falhas no grafo do hipercubo, a função de Representação Topológica

Dimensão Quant. Nós Tempo Méd. Instalação

Vous aimerez peut-être aussi