Consistent and fault-tolerant SDN controller

Detalhes bibliográficos
Autor(a) principal: Mantas, André Alexandre Lourenço
Data de Publicação: 2016
Tipo de documento: Dissertação
Idioma: eng
Título da fonte: Repositório Científico de Acesso Aberto de Portugal (Repositórios Cientìficos)
Texto Completo: http://hdl.handle.net/10451/25165
Resumo: Tese de mestrado, Segurança Informática, Universidade de Lisboa, Faculdade de Ciências, 2016
id RCAP_ee76d76aa126a7b11bf08dce76149bf2
oai_identifier_str oai:repositorio.ul.pt:10451/25165
network_acronym_str RCAP
network_name_str Repositório Científico de Acesso Aberto de Portugal (Repositórios Cientìficos)
repository_id_str 7160
spelling Consistent and fault-tolerant SDN controllerRedes definidas por softwareTolerância a falhasCoerência forteOpenFlowTeses de mestrado - 2016Departamento de InformáticaTese de mestrado, Segurança Informática, Universidade de Lisboa, Faculdade de Ciências, 2016O conceito de Software-Defined Networkings (SDNs) acaba com o acoplamento que existe nas redes tradicionais entre o plano de controlo e o plano de dados. Este desacoplamento facilita o desenvolvimento de aplicações inovadoras e flexíveis para gerir, monitorizar e programar as redes. Em SDN, as aplicações usam uma visão da rede logicamente centralizada, fornecida por controladores que programam remotamente os switches na rede. Se esta visão da rede não for coerente com o verdadeiro estado da rede, as aplicações vão executar sobre um estado desatualizado e produzir resultados incorretos. Isto pode degradar significativamente o desempenho da rede e gerar problemas como criação de loops ou falhas de segurança. Como em qualquer sistema em produção, falhas em componentes devem ser expectáveis. Desta forma, ´e importante que o plano de controlo seja capaz de manter uma visão coerente da rede mesmo na presença de falhas nos controladores ou nas ligações. Para isto, a visão da rede tem que estar replicada de forma coerente entre vários controladores para que a falha de um não comprometa a disponibilidade do sistema. Adicionalmente, o estado mantido pelos switches tem que ser tratado de forma coerente, o que ´e particularmente difícil na presença de falhas. Este trabalho propõe um plano de controlo SDN resiliente que permita a aplicações de rede inalteradas correr num ambiente tolerante a falhas e coerente (tanto a nível do estado do controlador como dos switches). Para conseguir o ambiente tolerante a falhas, os controladores devem replicar (de forma transparente) entre si os eventos recebidos antes que estes sejam entregues às aplicações de rede. Para conseguir um sistema coerente, a ideia principal ´e fazer com que os controladores processem as mensagens de controlo (incluindo enviar comandos aos switches) transaccionalmente, exatamente uma vez, e pela mesma ordem total. Esta ordem total ´e decidida por um dos controladores, o líder, que também ´e o controlador responsável por replicar os eventos pelos outros controladores e por enviar os comandos para os switches. Desta forma todos os controladores chegarão ao mesmo estado interno, o que faz com que tenham a mesma visão da rede e possam gerir os switches no caso de o controlador líder falhar. Atualmente existe apenas um controlador para SDN que utiliza estes mecanismos e que oferece as garantias de tolerância a falhas e coerência referidas, o Ravana. No entanto, o Ravana requer que sejam feitas modificações aos switches de rede e ao protocolo usado entre os controladores e os switches (i.e., o protocolo OpenFlow) como parte da sua implementação. Especificamente, o Ravana requer que: Os switches mantenham dois buffers locais, um para eventos que enviam aos controladores e outro para comandos que recebem destes; O protocolo OpenFlow seja alterado para adicionar duas mensagens novas de confirmação (controlador confirma a receção de eventos e switch confirma a receção de comandos) e duas mensagens novas para a limpeza dos buffers mantidos pelos switches (enviadas pelos controladores). Estes requisitos tornam a adoção do Ravana em sistemas reais problemática, pois não existem switches com estas características nem é expectável que o protocolo OpenFlow seja alterado no futuro próximo de acordo com as modificações requeridas pelo Ravana. Com estas limitações em mente, desenvolvemos o Rama, um controlador para SDN que oferece as mesmas garantias de tolerância a falhas e coerˆencia que o Ravana mas que não requer modificações aos switches nem ao protocolo OpenFlow. O protocolo do Rama utiliza técnicas inovadoras para cumprir estes objetivos. Enquanto no Ravana cada switch apenas envia os eventos para o líder atual (e guarda o evento num buffer para o caso de ser preciso reenviar para o novo master), no Rama os switches enviam os seus eventos para todos os controladores. Para isto, fazemos uso do protocolo OpenFlow para definir os tipos de mensagens que os switches devem enviar para cada controlador (por exemplo, definindo os controladores como estando no papel equals). Isto permite que os controladores se possam coordenar entre si para não processar o mesmo evento mais que uma vez e, mais importante ainda, para que nenhum evento seja perdido sem depender do reenvio do evento pelo switch (como todos os controladores recebem o evento, basta que um não falhe para o evento não se perder). De seguida, o controlador líder replica o evento para os outros controladores (obedecendo a uma ordem total) e entrega-o às suas aplicações de rede. Estas aplicações vão gerar comandos para serem enviados para os switches. Aqui entra outro aspeto diferenciador entre o Rama e o Ravana. Enquanto no Ravana o líder simplesmente envia o comando a contar que, em caso de falha, o switch seja capaz de filtrar comandos repetidos, o Rama usa um novo mecanismo introduzido no OpenFlows (OFs) 1.4 os Bundles (ou grupos) para garantir que os switches apenas processam cada comando uma única vez. Os bundles permitem aos controladores enviar vários comandos para um grupo mantido pelo switch e de seguida dizer-lhe para processar todos os comandos nesse grupo de forma atómica. Ao fazer isto, o switch, de acordo com o protocolo OFs, tem que enviar uma mensagem de volta ao controlador a confirmar que aquele grupo de comandos foi completamente processado. Esta confirmação diz ao controlador líder que mais nenhum controlador pode voltar a enviar os comandos para aquele evento. Porém, como o líder pode falhar sem avisar os outros controladores que recebeu esta confirmação, não é trivial atingir este propósito. Para resolver este problema, propomos um mecanismo adicional (já que não é possível programar o switch para enviar esta confirmação para todos os controladores): adicionamos uma mensagem do tipo PacketOut ao grupo mantido pelo switch que tenha como destino todos os controladores. Desta forma, quando o switch processa o grupo, o líder recebe a confirmação normal, indicativa de o grupo estar processado, e os outros controladores recebem uma mensagem com o conteúdo definido pelo líder (por exemplo, o identificador do evento). Estes dois mecanismos, quando usados em conjunto enviar eventos para todos os controladores e enviar comandos usando bundles permitem ao Rama oferecer as mesmas garantias de coerˆencia que o Ravana mas sem alterar os switches nem o protocolo OFs. O Rama foi desenvolvido tendo como base o Floodlight, um controlador SDN modular, open source, escrito em Java e com uma comunidade ativa. No Floodlight, aplicações de rede (e.g., balanceador de carga, firewall) podem ser integradas como módulos num núcleo bem definido que implementa abstrações de rede comuns (e.g., topologia da rede, descoberta e gestão de caminhos na rede) e oferece uma interface que torna fácil enviar e receber mensagens aos switches na rede. Para tratar as mensagens vindas dos switches de rede, o Floodlight usa um processamento em forma de encadeamento (pipeline), onde cada módulo processa a mensagem (i.e., atualizar o seu estado e possivelmente enviar comandos para programar o switch em conformidade com a situação) um após o outro. Cada módulo pode ainda definir relações de ordem com outros módulos (i.e., se este módulo deve receber mensagens antes ou depois de outros módulos) e, quando recebe a mensagem, decidir se o processamento da mesma pelos outros módulos deve continuar ou parar. No desenvolvimento do Rama decidimos usar o ZooKeepers (ZKs) para fazer a coordenação entre os controladores pela sua confiabilidade, simplicidade e ampla utilização. O ZK da Apache pode ser visto como um serviço de coordenação centralizado que expõe um conjunto de primitivas (e.g., gestão de nomes, gestão de configurações, sincronização, serviços de grupo) a ser utilizado por aplicações distribuídas de forma a que estas não tenham que reimplementar as primitivas de cada vez que são necessárias. As características principais do ZK são: alto desempenho, alta disponibilidade, acesso estritamente ordenado e o uso de um modelo de dados hierárquico semelhante a um sistema de ficheiros. O Rama usa o ZooKeeper para: Gestão de membros: saber que controladores estão ativos, detetar falhas de controladores e realizar eleição de líder no caso de falha do líder atual. Para isto usamos o mecanismo de nós temporários que são criados por cada controlador e apagados pelo ZK quando a ligação deste com algum controlador é terminada (e.g., por timeout). Replicação de eventos: o líder armazena um ou mais eventos em nós numa pasta observada pelas outras réplicas de forma a que estas sigam a ordem definida pelo líder e saibam em que estado ele se encontra. Adicionalmente, também é mantida a informação de que eventos já estão processados pelos switches (i.e., o líder já enviou os comandos para o evento). Para a fase de avaliação, usamos uma versão modificada do Cbench a ferramenta usada para medir o desempenho de controladores OpenFlow de forma a suportar bundles. Com as nossas experiências demonstramos que, embora o Rama atinja níveis de desempenho aceitáveis (cerca de 28 mil respostas por segundo) ainda fica um pouco atrás do Ravana (40 mil respostas por segundo). Esta diferença é devida ao custo adicional que o Rama incorre de modo a não modificar os switches nem o protocolo OpenFlow. Nomeadamente, o uso de bundles leva ao envio de mensagens adicionais para os switches (envio de quatro mensagens contra uma do Ravana para responder a um evento), o que em conjunto com a replicação e ordenação dos eventos reduz um pouco o desempenho do sistema em geral. Desta nossa proposta resultam várias contribuições, incluindo um poster aceite na conferência NSDI’16, contribuições para o deliverable 4.2 do projecto H2020 SUPERCLOUD, e ainda contribuições para projetos externos: Floodlight: contribuições para o controlador Floodlight relacionadas com o tratamento de bundles e outros melhoramentos. OpenvSwitch: contribuição para aceitar e tratar mensagens do tipo PacketOut dentro de bundles. Previamente estas mensagens eram rejeitadas Cbench: modificação da ferramenta Cbench que avalia o desempenho dos controladores OpenFlow para aceitar e tratar mensagens relacionadas com bundles.The concept of Software-Defined Networking (SDN) breaks the coupling in traditional networks between the control and data planes. This decoupling allows the development of innovative and flexible applications to manage, monitor, and program the network. In SDN, applications use a logically centralized network view, provided by the controllers, to remotely program switches in the network. If this network view is not consistent with the actual state of the network, applications will operate on a stale state and produce incorrect outputs. This can significantly degrade the network performance (e.g., packets can be forwarded through a failed link) and create problems such as network loops or security failures. As in any system in production, component failures must be the rule and not the exception. Thus, it is important that the control plane is able to maintain a consistent network view in the presence of failures in both controllers and links. Therefore, the network view must be consistently replicated across several controller replicas so that the failure of one controller does not compromise the entire control plane. Additionally, to ensure a correct system, the state maintained by switches must be handled in a consistent way, which is particularly difficult in the presence of failures. This work proposes a resilient SDN control plane that allows modification-free applications to run in a fault-tolerant and consistent environment (in both controllers and switches state). To achieve the fault-tolerant environment, controllers must replicate (transparently) the received events among themselves before these are delivered to the network applications. For the consistent environment, the main idea is that controllers process control messages transactionally, exactly once, achieving a correct and consistent operation of both controllers and switches, even if some of them fail. The two main techniques used are instructing switches to send events to all controllers, which coordinate to ensure exactly once event processing, and using OpenFlow Bundles as the acknowledgement mechanism used by controllers to process commands on switches exactly once. The differentiating factor and novelty over existing works is the fact that the consistency guarantees our proposal assures, in a fault-tolerant SDN environment, do not require modifications to neither switches nor to the OpenFlow protocol.Ramos, Fernando Manuel ValenteRepositório da Universidade de LisboaMantas, André Alexandre Lourenço2016-11-30T10:52:43Z201620162016-01-01T00:00:00Zinfo:eu-repo/semantics/publishedVersioninfo:eu-repo/semantics/masterThesisapplication/pdfhttp://hdl.handle.net/10451/25165TID:201340810enginfo:eu-repo/semantics/openAccessreponame:Repositório Científico de Acesso Aberto de Portugal (Repositórios Cientìficos)instname:Agência para a Sociedade do Conhecimento (UMIC) - FCT - Sociedade da Informaçãoinstacron:RCAAP2023-11-08T16:14:29Zoai:repositorio.ul.pt:10451/25165Portal AgregadorONGhttps://www.rcaap.pt/oai/openaireopendoar:71602024-03-19T21:42:08.980218Repositório Científico de Acesso Aberto de Portugal (Repositórios Cientìficos) - Agência para a Sociedade do Conhecimento (UMIC) - FCT - Sociedade da Informaçãofalse
dc.title.none.fl_str_mv Consistent and fault-tolerant SDN controller
title Consistent and fault-tolerant SDN controller
spellingShingle Consistent and fault-tolerant SDN controller
Mantas, André Alexandre Lourenço
Redes definidas por software
Tolerância a falhas
Coerência forte
OpenFlow
Teses de mestrado - 2016
Departamento de Informática
title_short Consistent and fault-tolerant SDN controller
title_full Consistent and fault-tolerant SDN controller
title_fullStr Consistent and fault-tolerant SDN controller
title_full_unstemmed Consistent and fault-tolerant SDN controller
title_sort Consistent and fault-tolerant SDN controller
author Mantas, André Alexandre Lourenço
author_facet Mantas, André Alexandre Lourenço
author_role author
dc.contributor.none.fl_str_mv Ramos, Fernando Manuel Valente
Repositório da Universidade de Lisboa
dc.contributor.author.fl_str_mv Mantas, André Alexandre Lourenço
dc.subject.por.fl_str_mv Redes definidas por software
Tolerância a falhas
Coerência forte
OpenFlow
Teses de mestrado - 2016
Departamento de Informática
topic Redes definidas por software
Tolerância a falhas
Coerência forte
OpenFlow
Teses de mestrado - 2016
Departamento de Informática
description Tese de mestrado, Segurança Informática, Universidade de Lisboa, Faculdade de Ciências, 2016
publishDate 2016
dc.date.none.fl_str_mv 2016-11-30T10:52:43Z
2016
2016
2016-01-01T00:00:00Z
dc.type.status.fl_str_mv info:eu-repo/semantics/publishedVersion
dc.type.driver.fl_str_mv info:eu-repo/semantics/masterThesis
format masterThesis
status_str publishedVersion
dc.identifier.uri.fl_str_mv http://hdl.handle.net/10451/25165
TID:201340810
url http://hdl.handle.net/10451/25165
identifier_str_mv TID:201340810
dc.language.iso.fl_str_mv eng
language eng
dc.rights.driver.fl_str_mv info:eu-repo/semantics/openAccess
eu_rights_str_mv openAccess
dc.format.none.fl_str_mv application/pdf
dc.source.none.fl_str_mv reponame:Repositório Científico de Acesso Aberto de Portugal (Repositórios Cientìficos)
instname:Agência para a Sociedade do Conhecimento (UMIC) - FCT - Sociedade da Informação
instacron:RCAAP
instname_str Agência para a Sociedade do Conhecimento (UMIC) - FCT - Sociedade da Informação
instacron_str RCAAP
institution RCAAP
reponame_str Repositório Científico de Acesso Aberto de Portugal (Repositórios Cientìficos)
collection Repositório Científico de Acesso Aberto de Portugal (Repositórios Cientìficos)
repository.name.fl_str_mv Repositório Científico de Acesso Aberto de Portugal (Repositórios Cientìficos) - Agência para a Sociedade do Conhecimento (UMIC) - FCT - Sociedade da Informação
repository.mail.fl_str_mv
_version_ 1799134335426625536

Registros relacionados