Redes de Data Center com filtro de Bloom nos pacotesCarlos A. B. Macapuna , Christian Esteve Rothenberg , Maurício F. Magalhães (Orientador)

Departamento de Engenharia de Computação e Automação Industrial (DCA)Faculdade de Engenharia Elétrica e de Computação (FEEC)

Universidade Estadual de Campinas (Unicamp)

{macapuna, chesteve, mauricio}@dca.fee.unicamp.br

Abstract – This paper describes a networking approach for cloud data centers architectures based on a noveluse of in-packet Bloom filters to encode randomized network paths. We present the design principles and testbedimplementation of a data center architecture governed by Rack Managers, which are responsible to transparentlyprovide the networking and support functions to cost-efficiently operate the DC network. We evaluate the proposalin terms of state requirements, our claims of false-positive-free forwarding, and the load balancing capabilities.

1. Introdução

Com o advento de serviços em nuvem para Inter-net, o suporte às redes dedata center(DCN - datacenter networks) tornou-se um assunto de intensapesquisa para aumentar sua escala, desempenho erelação custo-eficiência [3]. A fim de cumprir es-sas metas, sem comprometer a qualidade do serviço,inovações são solicitadas em muitas áreas do ambi-ente dedata center, incluindo a própria infraestru-tura de hospedagem (por exemplo, eficiência ener-gética, fiação, acondicionamento) e a engenharia derede (roteamento, virtualização, monitoramento).

Pesquisas recentes em re-arquitetura dedata centertêm estimulado projetos inovadores parainterligar servidores, incluindo encaminhamentobaseado na posição de pseudo endereço MAC [7],topologiasfat-tree [1], ou balanceamento de cargausando uma camada 2 virtual [2].

Neste trabalho, descrevemos o encaminha-mento utilizando filtro de Bloom nos pacotes, umaproposta DCN motivada por mudanças na rede eimpulsionado pelo baixo custo dosswitchescomum substrato de programabilidade (OpenFlow [6]).Nosso projeto empresta algumas características deuma nova geração de DCN, por exemplo, a incor-poração de controladores logicamente centralizados(4D [4]).

Basicamente, a ideia é interligar qualquerpar de nós conectados dentro da DCN através de co-dificação da rota na origem em um filtro de Bloom,adicionado nos campos MAC Ethernet. Os obje-tivos do projeto incluem a conservação da semân-tica IP e eliminação de falsos-positivos explorandoos múltiplos caminhos disponíveis. A solução pro-posta permite uma melhor utilização do espaço de96-bits de origem e destino dos campos MAC, evi-tando, assim, o encapsulamento e, ao mesmo tempo,

conserva a boa propriedade deplug and playdo en-dereçamento Ethernet.

O resto do artigo está organizado da se-guinte forma: a Seção 2 introduz informações rela-cionadas à lógica sobre a arquitetura DCN; a Seção3 apresenta os princípios de projeto adotados para anossa solução e descreve os principais blocos funci-onais; na Seção 4 detalhamos a implementação doprotótipo e do ambiente de testes; a Seção 5 avaliaa proposta em termos de requisitos e estado de rede,falsos positivos, e capacidades de balanceamento decarga e, finalmente, a Seção 5 conclui o artigo.

2. Arquitetura do Data Center

O data center, como uma rede de interconexão pararealizar tarefas de processamento distribuído, temtrês principais elementos dominantes que determi-nam o seu desempenho: (1) a arquitetura de rede,(2) o esquema de roteamento, e (3) a topologia deinterconexão. Nesta seção, descrevemos a estraté-gia adotada para resolver (1) e (2) e que pode ser re-sumida como uma abordagem separação identifica-dor/localizador, onde os endereços IP atuam apenascomo identificadores, e o roteamento é fornecidopelo encaminhamento baseado em filtro de Bloomnos pacotes. Quanto a (3), assumimos uma topo-logia em 3 camadas, uma inferior deswitchesToR(Top Of Rack), uma camada intermediária deswit-chesde agregação (AGGR), e uma camada superiordeswitchesCORE (ver Fig. 1).

Figura 1. Arquitetura fat tree de 3 camadas.

2.1. Princípios de projeto

Com base na proposta de arquitetura dedata center,nossos princípios de projeto são:

Separação identificador/localizador: Adivisão entre identificador e localizador possui umpapel fundamental para permitir o compartilha-mento de recursos dos serviços com endereçamentoIP. O IP é usado para identificar servidores físicos(e virtuais) dentro do DC, ou seja, não são impostasrestrições de como os endereços são atribuídos ouutilizados para acesso externo (Internet), tornando-os não significativos para o roteamento de pacotes.

Rota na origem: Aproveitando o pequenodiâmetro das topologias de redes dedata center,nossa abordagem utiliza o esquema de rota na ori-gem (strict source routing). O roteamento nas to-pologias DCN em 3 camadas é bastante simplifi-cado, ou seja, qualquer rota entre dois ToRs, temuma trajetória ascendente em direção a umswitchCORE e, em seguida, uma trajetória na direçãodo ToR destino, ambas passam pelosswitchesin-termediários (AGGR). O encaminhamento é base-ado em filtro de Bloom nos pacotes (iBF -in-packet Bloom filter) contendo apenas três elemen-tos, nomeados de identificadoresBloomed MAC(〈COREi, AGGRdown, T oRdst〉) de switches. OToR de origem calcula as rotas e envia para o AGGRmais próximo, com isso, três decisões são realizadasutilizando o iBF.

Diretório centralizado e controle de rededireto: Utilizamos a filosofia 4D [4] que simplificao plano de dados e centraliza o plano de controle.Introduzimos o Gerenciador deRack(RM) para to-mar as decisões de roteamento e inserir as entradasdos fluxos nosswitchesprogramáveis.

Balanceamento de carga:A abordagempara fornecer o balanceamento de cargas é baseadano encaminhamento aleatório (oblivious routing). ORM é responsável pela seleção aleatória dos cami-nhos até o ToR destino.

2.2. Encaminhamento com identificadoresBloomed MAC

A originalidade, no caso, está associada à tomada dedecisão nosswitchesAGRR e CORE. Inicialmente,as tabelas de encaminhamento estão vazias. Apósa descoberta da topologia, as tabelas são preenchi-das com uma entrada de fluxo para cadaswitchvi-

zinho detectado. No lugar da tradicional combina-ção exata dos campos MAC, cada entrada de fluxocontém uma máscara de 96-bits gerada a partir dek funções de espalhamento (hashing) sobre o ende-reço MAC interno doswitchvizinho. UmID Bloo-med MACé um vetor de 96-bits onde apenask bitssão definidos com o valor igual a 1, como resultadoda aplicação dask funções dehashing. Na chegadado pacote, apenas os 1s de cadaID Bloomed MACsão verificados quanto à presença nos campos MACEthernet (origem e destino) utilizados para transpor-tar a rota na origem codificada no iBF. No caso detodos os 1s doID Bloomed MACcorresponderemaos 1s definidos no iBF, o pacote é encaminhadopara a interface correspondente.

2.3. Protocolo de descoberta

Uma questão não trivial é a descoberta da topolo-gia da árvore e o papel de cadaswitch(isto é, ToR,AGGR ou CORE). Este conhecimento da topologiaé um pré-requisito para viabilizar o roteamento naorigem o que, além de reduzir os esforços operaci-onais, permite o encaminhamento correto e otimi-zado dos pacotes. Para este fim, criamos um pro-tocolo (Role Discovery Protocol) que automatiza ainferência da árvore deswitches, adicionando umaextensão no protocolo de descoberta LLDP. Nossoprotocolo é bastante simples e requer apenas a iden-tificação da camada em que oswitchestá situado.

3. Implementação e testbed do protótipo

A implementação do mecanismo de transmissãoiBF é baseada emswitchesOpenFlow [6], enquantoo RM é implementado como uma aplicação adici-onada ao controlador NOX [5]. A seguir, descre-vemos as principais questões relacionadas à imple-mentação do protótipo e do ambiente de testes.

3.1. OpenFlow

Um switch OpenFlow (OF) separa o encaminha-mento de pacotes rápido (plano de dados) do nívelde decisões de encaminhamento (plano de controle)de um roteador ouswitch. Embora parte do plano dedados ainda encontre-se residente noswitche exe-cute sobre o mesmo hardware (portas lógicas, me-mória), as decisões de manipulação de pacotes emalto-nível são movidas para um controlador sepa-rado. Dispositivos com OF habilitado e o(s) respec-tivo(s) controlador(eres) comunicam-se através do

protocolo OF (OFP -Open Flow Protocol), que de-fine mensagens comopacket-received, send-packet-out, modify-forwarding-tableeget-stats.

O aspecto principal do OF é definiruma interface de captação na forma de umatabela de fluxos, com entradas que contêmum conjunto de campos de pacote que com-bina uma tupla formada por 10 elementos:〈inport, Ethsrc, Ethdst, V LAN, EthType, IPproto,

IPsrc, IPdst, TCPsrc, TCPdst〉, e uma lista de açõessuportadas em hardware como, por exemplo, enca-minhar para uma porta, encapsular e transmitir parao controlador ou descartar o pacote. A fim de apoiaro encaminhamento com base no iBF, apenas umapequena alteração foi necessária na implementaçãodo OpenFlow (v. 0.89rev2).

3.2. Gerenciador de Rack (RM)O RM (Rack Manager) atua como um controladorde switchese a sua implementação é instanciadaatravés de um aplicativo que executa no contextodo controlador NOX [5]. O NOX está disponívelgratuitamente traduzindo-se em um importantefra-meworkpara construir novas aplicações para intera-ção com os dispositivos que possuem o OF habili-tado. Em poucas palavras, a interface de programa-ção do NOX é construída sobre os eventos, seja porcomponentes principais do NOX (core), ou defini-das por usuários, e gerenciados diretamente a par-tir de mensagens OF comopacket-in, switchjoin, switch leave, etc.

3.3. Ambiente de Teste (Testbed)O ambiente de teste é composto por 5 nós físicos,um deles hospeda o controlador NOX com o com-ponente RM e os 4 restantes são compartilhados,cada um, por 9 máquinas virtuais: 5 instâncias deOF switchese 4 nós finais. A Figura 2 mostra otestbed, onde as linhas sólidas representam ligaçõesdiretas entre as máquinas virtuais e as linhas trace-jadas representam as conexões entre as máquinasvirtuais de diferentes máquinas físicas. A topolo-gia em cada máquina física é configurada com oOpenFlowVMS, o qual dispõe de um conjunto útilde scripts para automatizar a criação de máquinasvirtuais em rede utilizando o QEMU.Scriptsadi-cionais foram desenvolvidos para distribuir o am-biente em diferentes máquinas físicas usando co-nexões SSH eswitchesvirtuais desprovidos de in-teligência e baseados no VDE (Virtual Distributed

Ethernet). O conjunto descriptsdesenvolvido nestetrabalho permite definir rapidamente uma topologiae automatizar a iniciação dos nós virtuais e do OFswitch, incluindo a configuração de IP, a criação dedata path, a iniciação do módulo OFP e conexão aocontrolador.

Figura 2. Ambiente de teste.

4. AvaliaçãoDepois de validar a implementação do protótipoatravés da verificação da conectividade total entre oconjunto de servidores (16 VMs), a próxima questãoé avaliar o encaminhamento baseado no iBF em ter-mos dos seguintes itens: (i) custo das informaçõesde estado, (ii) os potenciais efeitos de falsos positi-vos, e (iii) a capacidade de balanceamento de carga.Devido às limitações de um ambiente virtualizado,os aspectos de desempenho não são considerados.

4.1. Análise do EstadoA configuração de rede é uma topologia em 3 cama-das, com ToRs conectados a 2 servidores e dois AG-GRs. Asp1 portas (p.e,p1=4) do AGGRs são usa-dos para conectar-se ap1/2 ToRs ep1/2 COREs.Em consonância com a literatura, assumimos umamédia de 10 fluxos simultâneos por servidor (5 su-bindo e 5 descendo). Devido ao roteamento baseadona origem, nossa implemantação requer um estadomínimo nos COREs e AGGRs, ou seja, apenas umaentrada por interface (vizinho). Além disso, a esca-labilidade no DCN não tem impacto sobre o númerode entradas de fluxo nosswitches, que é constante eigual ao número de vizinhos.

4.2. Falsos positivosAvaliou-se o desempenho de falso positivo em fil-tro de Bloom de 96-bits quando se observa apenas

3 elementos, chamados de três endereçosBloomedMAC, que representam um caminho na rede na to-pologia DCN. A estimativa normalmente utilizadapara a probabilidade de falso positivo de um filtrode Bloom de tamanhom, inserido comn elemen-tos, com número dek funçõeshashé:

pk

=

[

1 −

(

1 −

1

m

)k∗n]k

(1)

Temos que avaliar a viabilidade e a efici-ência da nossa escolha de projeto para evitar fal-sos positivos, com base em descartar candidatos iBFpropensos a falsos positivos antes da sua utiliza-ção. A nossa tese é que, dada a baixafpr (falsepositive rate) de um iBF de 96-bits, há uma abun-dância de caminhos livres de falsos positivos en-tre quaisquer ToRs. A partir da teoria de filtros deBloom, existe um número ideal de funções dehash(kopt = ln2 ∗ m/n, comm = 96, n = 3) que mi-nimiza a probabilidade de falsos positivos que, nonosso caso, seria até 22 funções dehashing. Emnossa configuração prática, porém, o menorfpr foiobtido parak em torno de 7.

4.3. Balanceamento de carga

Dada uma matriz de tráfego (TM), o objetivo é ava-liar como o tráfego é espalhado entre os enlacesdisponíveis. Comparamos a utilização do enlaceda nossa implementação com uma execução sim-plificada doSpanning Tree Protocol(STP) sobre amesma topologia. Usamos ITG como gerador detráfego, configurado com fluxos de TCP com du-ração de 10s, com tamanhos de carga exponencial-mente distribuídos em torno de 850 bytes. Estes pa-râmetros são adequados para a maioria dos tráfegosDCN. A Figura 3 mostra a utilização normalizadaapós a repetição de dez experimentos. Como espe-rado, na STP as ligações de rede são muito utiliza-das, enquanto o tráfego com iBF espalha adequada-mente, com a utilização máxima e mínima normali-zada de qualquer ligação desviando apenas cerca de20% do valor ideal, ou seja, 1.

5. Conclusões

Apresentamos uma arquitetura de rede dedata cen-ter com base em uma simples camada de plano dedados sob o IP, que encaminha pacotes baseado no

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1 1.2 1.4

Per

cent

ile r

ank

Normalized link utilization

SiBF naive STP

Figura 3. Testes.

conteúdo de um filtro de Bloom nos pacotes. A pro-posta DCN apresenta muitas características atraen-tes como, por exemplo, não exigir qualquer modifi-cação nos nós finais, reutilizando o cabeçalho do pa-cote Ethernet, e um controle preciso sobre as rotasdos pacotes nodata center. A avaliação sobre umaimplementação de teste virtualizado em pequena es-cala, não só oferece uma prova de conceito, mastambém lança luz sobre a capacidade de fornecerbalanceamento de carga com iBFs. Em implementa-ções futura, o protótipo será melhorado (por exem-plo, para lidar com casos de falha) e estendido comcaracterísticas adicionais, como gerenciamento debanco de dados distribuídos.

Referências[1] Mohammad Al-Fares, Alexander Loukissas, and Amin

Vahdat. A scalable, commodity data center network ar-chitecture.SIGCOMM CCR, 38(4):63–74, 2008.

[2] Albert Greenberg, James Hamilton, Navendu Jain, Sri-kanth Kandula, Changhoon Kim, Parantap Lahiri, DavidMaltz, Parveen Patel, and Sudipta Sengupta. Vl2: a sca-lable and flexible data center network.SIGCOMM CCR,2009.

[3] Albert Greenberg, James Hamilton, David Maltz, and Par-veen Patel. The cost of a cloud: research problems in datacenter networks.SIGCOMM CCR, 2009.

[4] Albert Greenberg, Gisli Hjalmtysson, David Maltz, AndyMyers, Jennifer Rexford, Geoffrey Xie, Hong Yan, Ji-bin Zhan, and Hui Zhang. A clean slate 4d approach tonetwork control and management.SIGCOMM CCR, 2005.

[5] Natasha Gude, Teemu Koponen, Justin Pettit, Ben Pfaff,Martín Casado, Nick McKeown, and Scott Shenker. Nox:towards an operating system for networks.SIGCOMMCCR, 2008.

[6] Nick McKeown, Tom Anderson, Hari Balakrishnan, GuruParulkar, Larry Peterson, Jennifer Rexford, Scott Shenker,and Jonathan Turner. Openflow: enabling innovation incampus networks.SIGCOMM CCR, 2008.

[7] Radhika Mysore, Andreas Pamboris, Nathan Farrington,Nelson Huang, Pardis Miri, Sivasankar Radhakrishnan, Vi-kram Subramanya, and Amin Vahdat. Portland: a scalablefault-tolerant layer 2 data center network fabric. InSIG-COMM ’09: ACM SIGCOMM 2009 conference on Datacommunication, 2009.