Resiliência do controle em SDN Migrando Tarefas e Funções

Transcrição

1 Resiliência do controle em SDN Migrando Tarefas e Funções Thiago Druciaki Casagrande 1 1 Departamento de Informática Universidade Federal do Paraná (UFPR) Curitiba PR Brasil Resumo. Nos últimos anos houve uma atenção especial, tanto pela indústria como pela pesquisa acadêmica, na área de redes definidas por software (SDN, do inglês Software Defined Networks). O Openflow [McKeown et al. 2008], que é uma implementação de SDN, ja é largamente utilizado em datacenters e vem sendo utilizado em estudos de casos para as mais diversas tecnologias de rede. Este trabalho propõe a migração de tarefas de controle entre os nós da rede a fim de aumentar sua resiliência. O passo chave para definir, quando e para onde os serviços de controle devem migrar, é a identificação de fatores de risco. Este trabalho será focado em enlaces críticos e a possível emulação de fatores de energia dos nós. 1. Introdução As redes definidas por software são compostas básicamente por nós e pelo controlador. Nós são dispositivos que se inter-conectam. Idealmente todos os nós se comportam como switches, recebendo e encaminhando pacotes da rede. Devem ser capazes de atender e requisitar solicitações ao controlador para definir o próprio comportamento diante do tráfego que por ele passa. O controlador é a entidade responsável por conhecer a rede a fim de definir como os dados devem ser encaminhados por entre os nós. Neste trabalho será assumido que todos os nós possuem a capacidade de assumir o papel de controlador. O controlador pode se comportar de duas formas. Reativa, atuando sobre os nós conforme o tráfego ou mudanças na topologia. Proativa, onde atua sobre os nós sem que estes tenham necessariamente recebido algum dado. Esforços acadêmicos tais como [Biswas et al. 1998, Merwe et al. 1997, Smith et al. 1999] e da IETF [Salim et al. 2003, Yang et al. 2004] tornaram possível a separação da rede em dois planos distintos, são eles: plano de dados e o plano de controle. O tráfego dos dados na rede, que passam e são encaminhados através dos nós, se localiza no plano de dados, enquanto que o plano de controle é por onde os nós e o controlador trocam mensagens a fim de definir o comportamento dos nós e da rede como um todo. Nada impede que os planos utilizem um mesmo meio e canal para comunicação, porém é comum que estes sejam distintos, por questões de segurança e para que o controle não esteja sujeito às variações da rede de dados. A arquitetura de uma rede definida por software é representada na figura 1. As fronteiras em relação ao controlador são: south boundary - trata da comunicação entre controlador e nós; utiliza alguma API para envio dos dados (i.e [McKeown et al. 2008])

2 north boundary - trata da comunicação entre controlador e as aplicações de rede, tais como virtualização de serviços de rede, gerência de serviço de nuvem (i.e Openstack, Opencloud) east-west boundary - trata da comunicação entre controladores de uma rede Figure 1. Arquitetura de redes definidas por software 2. Trabalhos Relacionados Assegurar o acesso dos nós ao controlador é essencial para o funcionamento das redes definidas por software. Nesta direção existem diversos trabalhos na literatura, utilizando diferentes abordagens para a existência desta garantia. Em pesquisa na literatura apenas [Liu et al. 2013] utiliza mecanismos no plano de dados para garantir a conectividade. Outros trabalhos abordam questões no plano de controle, tal qual a distribuição, hierarquização ou até mesmo a localização dos controladores na rede. Em [Zhang et al. 2011] é feita a afirmação: quanto maior for o número de controladores na rede, maior é a resiliência desta. Além da avaliação do impacto da quantidade de controladores este trabalho faz uma análise de dois algoritmos (glutão e cortemínimo) para posicionamento dos controladores. Avaliando a quantidade máxima de enlaces ou nós que podem falhar sem comprometer o acesso do resto da rede aos controladores. O controle de forma distribuída é proposto em [Koponen et al. 2010], onde a plataforma Onix provê uma API para programação do comportamento da rede enquanto se responsabiliza por disseminar por entre seus elementos o estado da rede. O Hyperflow ([Tootoonchian and Ganjali 2010]) busca garantir a sincronia entre controladores espalhados pela rede através de uma abordagem orientada a eventos - suportando um limite de 1000 eventos por segundos. Alguns trabalhos ([Yu et al. 2010], [A. et al. 2013]) utilizam uma abordagem híbrida em relação aos controladores da rede. Existe um módulo que roda dentro dos

3 nós em [A. et al. 2013] a fim de fazer leituras de um deamon OLSR a fim de escrever as flow-entries na ausência do acesso ao controlador - mimetizando o comportamento do protocolo OLSR. Com o Difane, os controladores ficam responsáveis por delegar aos nós as regras necessárias para o correto funcionamento da rede, evitando o overhead de comunicação e a latência decorrentes do packet-in - que é o pacote que o nó envia ao controlador ao receber algum tráfego e que não possui regras intaladas para tratá-lo. 3. Proposta Este trabalho propõe a possibilidade de migrar o serviço de controle da rede. A idéia é que esta migração ocorra quando o controlador detectar que a rede depende da falha em um enlace para se fragmentar. A fim de evitar que parte da rede perca o acesso ao controlador devido à fragmentação, o controlador transmite via plano de controle o software a um outro nó, que pertença à parte da rede que seria fragmentada e sem acesso ao controlador (no caso de falha do enlace crítico em questão). Neste trabalho o controle será feito in-bound, o que significa que o plano de controle e o de dados compartilharão as mesmas interfaces dos nós da rede. Para validar o funcionamento do controlador, serão enviados pings - pacotes ICMP - entre os hosts, que deverão enviar o packet-in ao controlador e este deve responder, resultando em uma nova entrada na tabela de fluxos do host em questão Ferramentas Os nós da rede serão ambientes virtualizados, utilizando VirtualBox ([Vir ]) para rodar as instâncias necessarias do simulador mininet ([Lantz et al. 2010]). Como controlador Openflow será utilizado o POX ([POX ]). Um pequeno programa em python será inserido em cada nó da rede, para que a comunicação no plano de controle, com o serviço de migração, funcione corretamente. A validação das entradas (flow-entries) na tabela de roteamento (flow-table) será feita através do envio de dados (pacotes ICMP), que serão farejados (sniffing) pelo tcpdump Análise da Rede A princípio a detecção da topologia da rede por parte do controlador não faz parte do escopo deste trabalho. Entre as bibliotecas em python encontradas, que oferecem funções para tratar grafos, optou-se pela graph-tool ([Gra ]). Além de uma extensa API para executar diversos algoritmos sobre grafos, parte destes são escritos em C++, provendo maior eficiência na execução dos mesmos. Diversas maneiras de dar entrada do grafo na Graph-tool são possíveis (ex: DOT, GML, GraphML). A detecção dos enlaces críticos será feita através da função de corte mínimo (graph tool.flow.min cut(g, weight)). Quando o peso do corte mínimo estiver no limite estipulado (uma aresta), os mecanismos de migração propostos neste trabalho devem ser ativados. Com o mapa de propriedades da partição (retornado pela função), inicia-se a transferência do software presente no controlador para um nó no possível novo componente (caso o enlace em questão venha a falhar). Sendo V o número de vértices (nós) e E as arestas (enlaces) - a complexidade desta análise é O(VE+V2logV), ja que [Stoer and Wagner 1997] é o algoritmo de corte mínimo utilizado.

4 3.3. Cenários A composição dos cenários que serão analisados está representado na Figura 2, definidos como cenários A e B. A fim de validar o funcionamento, tanto da detecção dos enlaces críticos como da migração dos serviços de controle, o cenário A apresenta dois nós conectados por dois enlaces - no caso de falha em algum destes o controlador deve iniciar o processo de migração. Figure 2. Cenários O cenário B representa a internet2, a fim de validar um cenário real. Após a implementação dos módulos propostos, dados serão coletados das simulações realizadas Cronograma Tarefa 03/11 10/11 17/11 24/11 27/11 Ambiente de Simulação X Módulo de migração no POX X X Avaliação dos cenários X X Escrita - Fase 3 X X References Graph-tool. - acessado em 24/10/2014. Pox. - acessado em 24/10/2014. Virtual box. - acessado em 24/10/2014. A., D., C., P., S., S., and N., B.-M. (2013). Wireless mesh software defined networks (wmsdn). Wireless and Mobile Computing, Networking and Communications (WiMob), 2013 IEEE 9th International Conference on, pages Biswas, J., Kent Ridge Digital Labs., S., Lazar, A., Huard, J.-F., Lim, K., Mahjoub, S., Pau, L.-F., Suzuki, M., Torstensson, S., Wang, W., and Weinsten, S. (1998). The ieee p1520 standards initiative for programmable network interfaces. Communication Magazine, IEEE, 36: Koponen, T., Casado, M., Gude, N., Stribling, J., Poutievski, L., Zhu, M., Ramanathan, R., Iwata, Y., Inoue, H., Hama, T., and Shenker, S. (2010). Onix: A distributed control platform for large-scale production networks. In USENIX Conference on Operating Systems Design and Implementation, pages 1 6. USENIX Association.

5 Lantz, B., Heller, B., and McKeown, N. (2010). A network in a laptop: Rapid prototyping for software-defined networks. In Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks, Hotnets-IX, pages 19:1 19:6, New York, NY, USA. ACM. Liu, J., Panda, A., Singla, A., Godfrey, B., Schapira, M., and Shenker, S. (2013). Ensuring connectivity via data plane mechanisms. In Proceedings of the 10th USENIX Conference on Networked Systems Design and Implementation, pages , Berkeley, CA, USA. USENIX Association. McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and Turner, J. (2008). Openflow: Enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38(2): Merwe, J. E. V. D., Rooney, S., Leslie, I. M., and Crosby, S. A. (1997). The tempest - a practical framework for network programmability. IEEE Network, 12: Salim, J., Khosravi, H., Kleen, A., and Kuznetsov, A. (2003). Linux Netlink as an IP Services Protocol. RFC 3549 (Informational). Smith, J. M., Calvert, K. L., Murphy, S. L., Orman, H. K., and Peterson, L. L. (1999). Activating networks: A progress report. IEEE Computer, 32(4): Stoer, M. and Wagner, F. (1997). A simple min-cut algorithm. J. ACM, 44(4): Tootoonchian, A. and Ganjali, Y. (2010). Hyperflow: A distributed control plane for openflow. In Internet Network Management Conference on Research on Enterprise Networking, pages 3 3. USENIX Association. Yang, L., Dantu, R., Anderson, T., and Gopal, R. (2004). Forwarding and Control Element Separation (ForCES) Framework. RFC 3746 (Informational). Yu, M., Rexford, J., Freedman, M. J., and Wang, J. (2010). Scalable flow-based networking with difane. SIGCOMM Comput. Commun. Rev., 41(4). Zhang, Y., Beheshti, N., and Tatipamula, M. (2011). On resilience of split-architecture networks. In IEEE Global Telecommunications Conference, pages 1 6.