A new approach to detecting failures in distributed systems

textFault-tolerant distributed systems often handle failures in two steps: first, detect the failure and, second, take some recovery action. A common approach to detecting failures is end-to-end timeouts, but using timeouts brings problems. First, timeouts are inaccurate: just because a process is unresponsive does not mean that process has failed. Second, choosing a timeout is hard: short timeouts can exacerbate the problem of inaccuracy, and long timeouts can make the system wait unnecessarily. In fact, a good timeout value—one that balances the choice between accuracy and speed—may not even exist, owing to the variance in a system’s end-to-end delays. ƃis dissertation posits a new approach to detecting failures in distributed systems: use information about failures that is local to each component, e.g., the contents of an OS’s process table. We call such information inside information, and use it as the basis in the design and implementation of three failure reporting services for data center applications, which we call Falcon, Albatross, and Pigeon. Falcon deploys a network of software modules to gather inside information in the system, and it guarantees that it never reports a working process as crashed by sometimes terminating unresponsive components. ƃis choice helps applications by making reports of failure reliable, meaning that applications can treat them as ground truth. Unfortunately, Falcon cannot handle network failures because guaranteeing that a process has crashed requires network communication; we address this problem in Albatross and Pigeon. Instead of killing, Albatross blocks suspected processes from using the network, allowing applications to make progress during network partitions. Pigeon renounces interference altogether, and reports inside information to applications directly and with more detail to help applications make better recovery decisions. By using these services, applications can improve their recovery from failures both quantitatively and qualitatively. Quantitatively, these services reduce detection time by one to two orders of magnitude over the end-to-end timeouts commonly used by data center applications, thereby reducing the unavailability caused by failures. Qualitatively, these services provide more specific information about failures, which can reduce the logic required for recovery and can help applications better decide when recovery is not necessary.Computer Science

Consistent and fault-tolerant SDN controller

Tese 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

Past Before Future: A Comprehensive Review on Software Defined Networks Road Map

Software Defined Networking (SDN) is a paradigm that moves out the network switch2019;s control plane (routing protocols) from the switch and leaves only the data plane (user traffic) inside the switch. Since the control plane has been decoupled from hardware and given to a logically centralized software application called a controller; network devices become simple packet forwarding devices that can be programmed via open interfaces. The SDN2019;s concepts: decoupled control logic and programmable networks provide a range of benefits for management process and has gained significant attention from both academia and industry. Since the SDN field is growing very fast, it is an active research area. This review paper discusses the state of art in SDN, with a historic perspective of the field by describing the SDN paradigm, architecture and deployments in detail