Projeto de Desenvolvimento em OpenFlow

Transcrição

1 Projeto de Desenvolvimento em OpenFlow Prof. Cesar Marcondes 1 o Semestre 2011 Projeto - Balanceador de Carga March 19, Projeto - Balanceador de Carga O balanceamento de carga é uma técnica para distribuir uniformemente a carga de trabalho entre: dois ou mais computadores, links de rede, processadores, discos rígidos, ou outros recursos, a fim de obter a utilização ótima dos recursos, maximizar a vazão, minimizar o tempo de resposta e evitar sobrecarga no sistema. Hoje em dia, o balanceamento de carga é um serviço predominante em quase todas as escalas na Internet; ela é fundamental para execução de aplicativos em redes de datacenter, tais como as do Google, ou em redes de distribuição de conteúdo de larga escala, como Akamai, e em redes corporativas consistindo de múltiplos campus como na HP. Se assumirmos o balanceamento de carga em redes de larga escala, uma forma para equilibrar a carga é distribuir a carga através da manipulação das solicitações de DNS e suas respostas. Outra maneira comum de implementar balanceamento de carga é implantar equipamentos personalizados, e caros chamados load-balancers. Estes são implantados no ponto de entrada de uma rede. Eles recebem solicitações de clientes e distribuem essas requisições em um conjunto de servidores replicados. Após ter feito o curso de Redes (com o tutorial de OpenFlow) você vai acabar descobrindo que os métodos acima não são bons o suficiente. (por que? único ponto centralizado de distribuição?) Você decide provar ao resto do mundo que existem maneiras melhores (e mais baratas) de balancear a carga dentro de uma rede. Baseando-se na observação de que o balanceamento de carga é basicamente um roteamento inteligente, você deve iniciar o projeto BalanceTheLoad, que irá transformar as redes existentes em um sistema distribuído de balanceamento de carga, sem a necessidade de nenhum hardware especial nem de truques de DNS. 1

2 2 Detalhando o Projeto Neste projeto, usaremos o OpenFlow como uma plataforma para realizar roteamento de rede, a nível de fluxo com ajuste fino. Para simplificar o sistema, iremos desenvolver apenas um balanceamento de carga do tipo round-robin. Nós estamos particularmente interessados em balanceamento de carga HTTP. Nós eliminaremos todo o tráfego ARP através da instalação manual de entradas de ARP-cache estáticas no cliente e nos servidores, portanto, há apenas o tráfego HTTP voltando-e-vem na rede. Vamos construir gradualmente um setup contendo um cliente único e vários servidores. Todos os servidores serão visto como um (único) endereço IP pelo cliente, mas a rede irá distribuir a carga por meio de caminhos e servidores (replicados). 2.1 Configuração de Rede Vamos usar o framework Mininet para emular uma rede de médio porte rodando dentro de uma única máquina virtual. 2.2 Controlador Você tem a opção de escolher um dos dois controladores - ou o controlador NOX baseado em Python e C++ ou o controlador Beacon baseado em Java. O projeto é dividido em 3 etapas. 3 Etapa 1: Fazendo HTTP request/response funcionar no OpenFlow Esta primeira configuração consiste de um único cliente e um único servidor interligados por um único switch OpenFlow. O servidor tem um endereço IP único assim como um apelido IP (isso será comum a todos os servidores replicados nas etapas futuras). O cliente conhece um único servidor, que possui esse apelido IP (alias IP). Em nossas configurações esse alias IP será definido como O cliente tem uma ARP-entry fazendo o mapeamento do alias IP para o endereço MAC FF: FF: FF: FF: FF: FF. Nesta parte, você terá que 2

3 colocar a funcionalidade básica do controlador no lugar. Ou seja, para cada solicitação de entrada (packet-in), voce deve instalar uma entrada de tabela de fluxo que executa as seguintes ações, nessa ordem: Reescrever o endereço MAC destino (FF...) com o endereço MAC real do servidor Fazer o pacote sair pela porta na qual o servidor está conectado. Da mesma forma, instale a entrada na tabela de fluxo para a resposta correspondente no caminho inverso. Observe que você não precisa adicionar a ação substituir o endereço MAC para este caso. Você vai achar o módulo de topologia útil para esta etapa. 4 Etapa 2: Fazendo Balanceamento de Carga entre Servidores Nós iremos construir baseado nos passos anteriores um balanceador de carga para as solicitações recebidas serem distribuídas entre vários servidores. A figura mostra uma instalação com um cliente e três servidores, interconectados por um único switch OpenFlow. Nesta etapa, você vai estender a funcionalidade do controlador para escolher os servidores de uma maneira round-robin. Observe que as ações para a tabela de fluxos permanecem as mesmas. Somente a porta de saída da segunda ação vai mudar dependendo do servidor selecionado. 3

4 5 Etapa 3: Fazendo o Balanceamento de Carga entre os Servidores e os Caminhos de Rede Nesta etapa, nós vamos estender ainda mais a funcionalidade do nosso controlador para fazer balanceamento de carga entre os servidores e os caminhos de rede disponíveis. Para ter caminhos de rede para escolher, nós usaremos uma topologia de rede um pouco mais complexa, como mostrado na figura. Esta topologia é muito popular em empresas e redes de datacenter. A topologia é constituída por três camadas de switches - um switch core na parte superior, uma camada de switches de agregação no meio, e uma camada de switches de acesso na parte inferior. Na nossa configuração, o cliente está ligado a camada de núcleo e os servidores estão conectados aos switches de acesso. É fácil observar que, para uma topologia com N switches de agregação, existem N caminhos disjuntos para cada servidor a partir do cliente. No exemplo acima, temos 2 switches de agregação e portanto 2 caminhos disjuntos (sem usar o mesmo caminho) para cada servidor. Core-Aggr1-Access1-Servidor1, Core-Aggr2-Access1-Servidor1 e assim por diante. Nesta etapa, você vai balancear a carga das requisições de entrada assim como fez nas etapas anteriores, mas com as seguintes extensões: É preciso instalar entradas nas tabelas de fluxo para o caminho completo para rotear a requisição, ou seja, não somente em um switch. Observe que a ação de reescrita do endereço MAC deve ser instalada apenas no primeiro switch no caminho. Escolher os servidores em rodizio (round-robin). Para cada servidor, também escolher caminhos para aquele servidor de uma maneira em rodizio (round-robin). Você deve escolher o mesmo caminho para tanto a solicitação quanto a resposta correspondente. Nos testes, será possível aumentar o tamanho dessa rede, portanto você pode assumir o seguinte sobre a topologia: 4

5 O switch core está ligado a todos os switches de agregação. Cada switch de agregação está ligado a todos os switches de acesso. O cliente está localizado no switch core. Os servidores estão localizados nos switches de acesso. Portanto, o número de switches de agregação, switches de acesso e servidores pode variar, e seu balanceador deve ser robusto o bastante para diferentes tamanhos. Então, o que significa fazer o balanceamento de carga usando (roundrobin) entre os servidores e os caminhos? Você deve ter percebido que para um determinado servidor, a escolha do switch de agregação unicamente determina o caminho até este servidor. Portanto, suponhamos que existam N servidores e M switches de agregação (ou seja, M caminhos para cada servidor) na rede. Para os primeiros N pedidos (para N servidores), você tem que escolher os trajetos que vão através do switch de agregação 1 com seleção round-robin. Para os próximos N pedidos, você deve escolher trajetos que vão através do switch de agregação 2, e assim por diante. Dessa maneira, você estará fazendo ao mesmo tempo balanceamento de carga e de caminhos da rede. A ordem dos servidores e dos switches de agregação (ou seja, aquilo que eu quis dizer com switch de agregação 1 ou switch de agregação 2) pode ser arbitrária, mas deve ser coerente, enquanto o seu controlador estiver rodando. Para simplificar ainda mais o desenvolvimento da aplicação, sub-dividimos a Etapa 3 em duas partes. Etapa 3a - O Cérebro 1. Ler e imprimir a topologia. 2. Selecione as tuplas <servidor, switch de agregação> corretamente. 3. Criar e imprimir uma rota para uma determinada tupla <servidor, switch de agregação> Etapa 3b - Os Músculos 1. Descarregar as entradas das tabelas de fluxo no caminho forward (cliente -> servidor) 2. Descarregar as entradas das tabelas de fluxo no caminho reverso (servidor -> cliente) 3. Fazer funcionar o primeiro request 4. Fazer funcionar para a segunda request e todas as subseqüentes 5. Ter certeza que a implementação passou em todos os testes. 5

6 Observações Importantes Diferenciação entre as requisições - Quando estava desenvolvendo o switch, voce usou o endereço MAC origem e destino para diferenciar os vários fluxos de L2. Neste exercício estamos lidando com solicitações e respostas HTTP, que são fluxos de L4. Isso significa que você terá que instalar entradas de tabela de fluxo com correspondências exatas (ou seja, fazendo match dos campos de L2 até L4). Dado que contamos com apenas um cliente, e que todos os servidores compartilham o mesmo endereço IP ( ) e atendem as solicitações na mesma porta TCP (80), o principal atributo que diferencia os fluxos pertencentes a diferentes solicitações do cliente é a porta TCP do cliente, porta essa que muda para cada requisição (pelo menos dentro da duração de tempo que o nosso sistema opera). Diferenciação entre os caminhos - Na etapa 3 é esperado que você também faça o balanceamento de carga entre diversos caminhos. Portanto, para a topologia hierárquica do passo 3, é importante notar que para um determinado servidor, escolher uma única switch de agregação determina unicamente o caminho. Portanto, balancear o caminho é o mesmo que escolher o switch de agregação. (Dica: Esta é a informação que você precisa armazenar nos seus registros). Soft State vs Hard State - As entradas de fluxo que você instala nos switches OpenFlow são consideradas soft state. Não existe nenhum garantia de tempo estrita sobre quando exatamente essas entradas serão realmente instaladas dentro do datapath do switch. Essas entradas também podem expirar se não tiver nenhum tráfego passado por elas por um pré-determinado período de timeout. Isto significa que o Controlador deve lembrar o que ele pretendia fazer com uma requisição particular (fluxo). Em outras palavras, o controlador deve manter uma tabela de hard-state. Isso é particularmente importante quando você instala entradas de fluxos ao longo de um caminhos de multiplos switches. 6 Um Exemplo Considere uma rede com 2 switches, conforme mostrado na figura. 6

7 A requisição do cliente entra pelo switch-1 e causa um evento Packet-in no seu controlador. Vamos dizer que seu controlador decide enviar a requisição para o server-1, e portanto instala as entradas apropriadas nas tabelas de fluxos dos switch-1 e switch-2. Agora, suponhamos que a requisição entra no switch-2 antes daquela entrada na tabela de fluxo ser instalada no switch-2, fazendo com que seja gerado outro evento Packet-in (no switch-2, como isso acontece?). O seu controlador deveria então se lembrar que essa requisição está indo para o server-1 (e não para o server-2) e reinstalar as entradas apropriadas da tabela de fluxo no switch-2. A seguinte é uma possível seqüência de passos que você pode seguir para implementar a sua solução: Para cada evento Packet-In: Ignorar todos os pacotes não-ip. Verifique se o evento Packet-In foi causado por um soft-state faltante. Se sim, usar o seu hard-state para reinstalar o soft-state faltante, e retornar. Caso contrário Encontre o próximo servidor apropriado. Encontre o próximo caminho apropriado para o servidor. Armazenar a escolha (servidor, caminho) no hard-state. Instalar entradas de tabela de fluxo em todos os switches ao longo daquele caminho (lembre-se: reescrever o MAC no primeiro switch do caminho cliente-servidor, e não reescrever o MAC no caminho servidor-cliente) Obviamente, fique a vontade de escolher outras maneiras de implementar a sua solução. Algumas coisas para se pensar: Como armazenar o meu hard-state? Qual estrutura de dados devo usar? Como faço para armazenar informações da topologia de uma forma útil? 7

8 7 O Que Tem no Pacote? Máquina Virtual Linux e NOX. Voce pode usar a mesma imagem de MV que voce usou no exercício de criação de um switch. Código Esqueleto para NOX e Beacon do Módulo de Balanceamento de Carga. Scripts para configuração das topologias de rede e geração das requisições para cada uma das 3 Etapas acima. Scripts para verificar se esta correta a funcionalidade do controlador. 7.1 Configurando o Sistema Fazer Download dos Scripts de Configuração e Testes: Dentro da MV, a partir da sua pasta home, execute o seguinte comando: git clone git://openflow.org/cs244-pa2.git 8 Passos Para Trabalhar com NOX Python/C++ Atualização e recompilar NOX: Dentro da máquina virtual, execute o seguinte: cd /nox Faça Commit das alterações do exercício Desenvolvendo Switch, se houver. git status Verifique se existem alterações pendentes (mais provavelmente no arquivo... pytutorial.py). Efetivar as mudanças com o comando. git commit -a -m Switch Tenha certeza que seu diretório está limpo: git status git pull rebase cd build make clean cd.../boot.sh cd build 8

9 ../configure with-python=yes make -j2 Isso pode levar algum tempo para compilar, mas é só feito uma vez. pode ignorar estes passos se você estiver desenvolvendo com Beacon. Você 8.1 Desenvolvimento com o NOX No código do Controlador, criamos um módulo esqueleto chamado loadbalancer. O módulo está na pasta /nox/src/nox/netapps. O módulo consiste em um único arquivo python - loadbalancer.py. Todo o seu código deve ficar dentro do arquivo loadbalancer.py. Além da classe principal (loadbalancer), o módulo tem 2 outras classes auxiliares - ServerLoc e Topology. ServerLoc tem um código que lê as informações de localização do servidor e do cliente e fornece como resultado sob a forma de um dicionário Python. A classe Topologia fornece informações de topologia. Usando a Classe Topology, essa classe oferece algumas funções úteis: get datapaths( ) - retorna os identificadores de datapath (dpids) de todos os switches da rede. get neighbors(dpid) - retorna a lista dos dpids de todos os vizinhos de um determinado switch. get outlinks(dst, src) - Se dois switches (src e dst) estiverem conectados, ele retorna uma tupla de 2 elementos correspondente ao par de portas que os dois switches estão conectados por esse enlace. Caso contrário, devolve None. is internal(dp, port) - retorna Verdadeiro se a porta é interna à rede (ligada a outro switch), senão Falso. Aqui estão alguns outros arquivos de código fonte que você pode achar útil para esse exercício: NOX Python API: nox/src/nox/lib/core.py Exemplo de Uso da API: nox/src/nox/netapps/routing/samplerouting.py Exemplos de Uso da API: nox/src/nox/coreapps/examples/ Observações: Tenha certeza de iniciar o Controlador quando for solicitado pelo script de inicialização do Mininet O script pa2.py automaticamente mata quaisquer instancias de NOX após cada experimento. Não se preocupe se o controlador NOX finalizar após finalizar cada teste sucessivo. 9

10 9 Passos Para Trabalhar com Beacon/Java Em sua máquina física (host), faça cd para um diretório projeto-beacon. Confirmar as alterações do Switch (exercício anterior), se houver. git status Verifique se existem alterações pendentes (mais provavelmente no arquivo... Tutorial.java). Efetivar as mudanças com o comando. git commit -a -m Switch Tenha certeza que seu diretório está limpo: git status git pull rebase No Eclipse, selecione todos os módulos e clique em Refresh. Você pode ignorar esta etapa se você estiver desenvolvendo em NOX. 10 Desenvolvimento com Beacon No código do Controlador, criamos um módulo esqueleto chamado net.beaconcontroller.loadbalancer. O módulo consiste de um único arquivo Java - LoadBalancer.java. Todo o seu código deve ficar dentro do arquivo LoadBalancer.java. Além da classe principal (LoadBalancer), o módulo tem 2 outras classes auxiliares - ServerLoc e Topology. ServerLoc tem um código que lê as informações de localização do servidor e do cliente e fornece como resultado sob a forma de um hashmap. A classe Topologia fornece informações de topologia. Usando a Classe Topology, essa classe oferece algumas funções úteis: getdatapaths( ) - retorna os identificadores de datapath (dpids) de todos os switches da rede. getneighbors(dpid) - retorna a lista dos dpids de todos os vizinhos de um determinado switch. getoutlinks(dst, src) - Se dois switches (src e dst) estiverem conectados, ele retorna um Vector correspondente ao par de portas que os dois switches estão conectados por esse enlace. Caso contrário, devolve null. isinternal(dp, port) - retorna Verdadeiro se a porta é interna à rede (ligada a outro switch), senão Falso. Observações: 10

11 Tenha certeza de iniciar o Controlador quando for solicitado pelo script de inicialização do Mininet O Controlador Beacon precisa se comunicar com o script pa2.py para obter a informação de topologia. A variável MININET IP armazena o endereço IP da interface eth1 da Máquina Virtual (onde o script pa2.py executa). Voce pode ter que mudar essa variável para o seu setup. 11 Atualizando o Framework Mininet Dentro da máquina virtual, execute o seguinte comando: cd /mininet git pull rebase sudo make install 12 Testando o seu Código O principal script de configuração e teste é chamado pa2.py. Certifique-se de executá-lo dentro da sua pasta. cd /loadbalancer Para saber mais sobre todas as opções disponíveis, digite: sudo python pa2.py -h A seguir segue uma breve descrição das opções: -h, help: mostra essa mensagem de ajuda e sai -i CONTROLLER ADDR, interface=controller ADDR: CONTROLLER PORT: onde IP:porta é o endereço que o controlador está na escuta (padrão é :6633) -s STEP, step=step: Executa a Etapa apropriada. Step deve ser um valor entre [0-3]. Onde o valor entre 1 e 3, executa testes de uma determinada etapa. Enquanto que o valor de 0 executa todas as três etapas em seqüência. -r, run: Gera tráfego web para testar a sua solução -t, test: Testa a sua solução (executando testes públicos) -v, verbose: Enviar saída detalhada para stderr. Você pode escolher para redirecionar essa saída detalhada para um arquivo diferente, usando 2 /path/to/file. 11

12 12.1 Exemplos de Uso do Script de Teste Para executar testes da Etapa-1 com Tráfego Web gerado automaticamente: sudo python pa2.py -s 1 -r Para executar testes da Etapa-1 com o Controlador Beacon executando na máquina física (host): sudo python pa2.py -s 1 -i :6633 Para executar testes da Etapa-2 via Console Mininet: sudo python pa2.py -s 2 Para executar testes públicos de Todas as 3 Etapas: sudo python pa2.py -s 0 -t 12.2 Debugando com a Console (CLI) Se você quiser debugar o sistema usando o console do Mininet (CLI), faça o seguinte: Execute pa2.py sem as opções -t ou -r. Mininet. Isto irá ativar a console do Execute o código de cliente web no próprio nó cliente. <client name>./client/client.py 2 1 <no. of requests> A saída do cliente será anexada ao /tmp/time log.txt. Digite quit quando tiver terminado Entendendo a Saída do Cliente Web O script do cliente web (client/client.py) gera os resultados no arquivo de saída /tmp/time log.txt. Cada linha de saída corresponde a uma requisição HTTP feita pelo cliente. Essas linhas são constituídas pelos seguintes 4 campos: [time of request] [server name] [server MAC address] [response time] Se algum dos campos tiver o valor Unknown, provavelmente significa que a requisição não obteve a resposta correta. Outro ponto importante é que as requisições normalmente recebem timeout após cerca de 21 segundos. Se você estiver vendo valores próximo a esse no campo tempo de resposta, é bem provável que a requisição sofreu um timeout. 12

13 12.4 Composição da Nota A nota será baseada na correta execução dos testes e na qualidade do código fonte. O mesmo script que foi fornecido para testes públicos (pa2.py) também será usado para dar a nota, além de testes próprios desenvolvidos pelo instrutor. Segue a distribuição de pontos (10 pontos) em função das várias partes: Etapa 1: 1 ponto Etapa 2: 3 pontos Etapa 3: 3 pontos Testes Privados: 2 pontos Qualidade de Código: 1 ponto A submissão do projeto será feito através do Moodle. 13