Document details

Emulating network applications with a software-defined networking architecture

Author(s): Vasco, Marcos André Alves

Date: 2013

Persistent ID: http://hdl.handle.net/10451/10010

Origin: Repositório da Universidade de Lisboa

Subject(s): Engenharia informática; Arquitectura, sistemas e redes de computadores; Teses de mestrado - 2013


Description

A arquitetura das redes de hoje não é suficiente para responder às necessidades empresariais e académicas correntes. A raiz do problema está na complexidade dos planos de controlo e de gestão (os protocolos e o software que coordenam os dispositivos de rede); em particular, devido ao forte acoplamento entre a lógica de decisão e a lógica inerente a um sistema distribuído. Esta complexidade deriva do fato de as redes não possuírem um paradigma de controlo geral, pois não providenciam nenhuma abstração para o seu controlo e gestão. Software-Defined Networking (SDN) é uma nova arquitetura de rede em que o controlo está desacoplado do reencaminhamento e é diretamente programável. São definidas três abstrações: abstração de encaminhamento, abstração de distribuição de estado, e uma abstração de gestão global. A abstração de encaminhamento permite que software de controlo (o controlador) possa comunicar com o plano de dados, através de uma Application Programming Interface (API) comum. A abstração de distribuição permite que os programas de controlo de rede não tenham de tratar da disseminação e coleção de estado; o controlador fornece uma framework que oferece às aplicações total controlo sobre a rede sem que estas tenham de se preocupar com a forma como as suas decisões se propagam na rede subjacente. Com a abstração de gestão global, as aplicações têm acesso a um modelo lógico da rede, podendo assim geri-la como um único switch lógico. O OpenFlow é uma das primeiras abstrações de encaminhamento em existência, e também a mais comum. É um padrão de comunicação entre o controlador e os dispositivos de rede que cria um ambiente geral de programação, generalizando o plano de dados. O OpenFlow opera nas tabelas de fluxos dos switches, de modo a providenciar um protocolo aberto para programar a tabela de fluxos em diferentes dispositivos. Um switch OpenFlow comunica com um controlador remoto usando a API OpenFlow, através de uma ligação segura. A tabela de fluxos destes switches OpenFlow é povoada com entradas do tipo cabeçalho; ações, de acordo com instruções fornecidas pelo controlador. O cabeçalho de um pacote que chega ao switch é comparado com os cabeçalhos das entradas na tabela de fluxos e, se houver uma correspondência, as ações correspondentes a essa entrada serão aplicadas ao pacote. As ações suportadas são do género: encaminhar os pacotes para uma certa porta, enviar para o controlador, ou descartar o pacote. Tipicamente, quando um switch não consegue encontrar uma correspondência entre um pacote e as entradas na sua tabela de fluxos, envia o pacote para o controlador. Os controladores providenciam uma abstração da distribuição de estado. Tal como os sistemas operativos facilitam o desenvolvimento de programas fornecendo acesso controlado a uma abstração de alto nível dos recursos de um computador (memória, processamento, etc.), os controladores são sistemas operativos de rede, que providenciam uma interface de programação uniforme e centralizada para observar e controlar a rede. A interface tem de ser suficientemente generalizada para permitir um amplo espectro de aplicações de gestão. O controlador não efetua a gestão da rede, as aplicações implementadas no controlador são responsáveis por esta gestão. O controlador apenas aplica as ações decididas pelas aplicações. Esta entidade diz-se ser logicamente centralizada pois para as camadas adjacentes esta é abstraída como tal. O controlador não tem de ser centralizado – pode ser implementado, por exemplo, de uma maneira distribuída. O importante aqui é que esta camada esconde a distribuição dos dispositivos de rede, e apresenta uma vista geral da rede para as aplicações. Numa arquitetura SDN, o plano de gestão é realizado pelas aplicações que correm no controlador, operando sobre uma abstração da rede. Para qualquer requisito de controlo que possa existir, podemos escrever uma aplicação que o resolve. Para o nosso trabalho, iremos construir um load balancer, uma aplicação que particiona tráfego por entre vários servidores replicados. Uma solução para aumentar a capacidade e disponibilidade de um serviço Web é ter múltiplos servidores trabalhando em conjunto como um único recurso. Neste tipo de arquitetura, os pedidos são encaminhados para um dos vários servidores, numa maneira transparente ao utilizador. Num esquema de load balancing baseado em dispatcher, um dispositivo de rede é colocado no ponto de entrada da rede, que recebe os pedidos e os distribui pelos servidores. Este dispositivo, tipicamente chamado de load balancer, age como um front-end para o grupo de servidores, e corre um algoritmo de escalonamento para decidir como distribuir a carga por entre os servidores. Soluções correntes para este esquema de load balancing são conseguidas através de hardware de rede que pode custar alguns milhares de dólares. Para além do mais, estas soluções implementam uma escolha de políticas de escalonamento rígida, com personalização limitada. Outra desvantagem das tecnologias correntes de load balancing é que estas permitem apenas particionar a carga por entre os servidores; não podendo portanto escolher o caminho que o tráfego toma até ao servidor. Assim, uma grande vantagem da nossa solução de load balancing usando SDN é que podemos escolher o caminho que o tráfego toma para chegar ao servidor. Iremos verificar neste trabalho que a performance do sistema aumenta quando fazemos escalonamento não só de servidores mas também de caminhos. Desenvolvemos uma aplicação que efetua load balancing em servidores conectados numa rede com a arquitetura SDN. A aplicação desenvolvida funciona como um módulo para o controlador POX. Este controlador funciona através de eventos: as aplicações registam-se como listeners de eventos específicos; o controlador faz raise a estes eventos, normalmente despoletado por algum acontecimento do plano de dados. Tipicamente, um switch que recebe um pacote cujo cabeçalho não corresponde a nenhuma entrada na sua tabela de fluxos, envia este pacote para o controlador. Esta ação despoleta o evento Packet In no controlador. A nossa aplicação de load balancing está à escuta desses eventos, que normalmente é despoletado pelo primeiro pacote de uma nova conexão. A aplicação escolhe o servidor que irá tratar deste pedido, escolhe o caminho por onde a comunicação se irá dar na rede, e instala regras nas tabelas de fluxos dos switches ao longo do caminho. Instala também regras nos mesmos switches para o caminho inverso que os pacotes de resposta irão tomar. Este Load Balancer para SDN vem equipado com cinco algoritmos para escolher o servidor e três algoritmos de escolha de caminho. Para escolha de servidor temos os algoritmos: Round Robin; Flow Connections e Server Connections – estes dois escolhem o servidor com menos conexões, diferindo no modo como esta informação é recolhida; Load – o servidor com menos carga no seu CPU é escolhido; e Response Time – o servidor que produz melhores tempos de resposta é selecionado. Os algoritmos de escolha de caminho são: Shortest Path – o caminho mais curto (com menor número de hops) é escolhido e em caso de empate escolhe-se sempre o de menor identificador; Equal-Cost Multi-Path – tal como Shortest Path, escolhe-se o menor caminho, mas caso haja mais do que um caminho mais curto, efetua round robin entre estes; e Path Delay – escolhe-se o caminho que tem o menor atraso. De modo a poder avaliar os vários algoritmos de balanceamento de carga, escolhemos o emulador Mininet Hi-Fi como ambiente de prototipagem. Este emulador, baseado nos containers do Linux, permite a rápida prototipagem de grandes redes usando apenas um computador. Cada nó da rede (host ou switch) é colocado num container, que providencia um ambiente virtual com o seu próprio namespace de rede. A rede virtual final obtém-se conectando estes containers entre si através de links Ethernet virtuais. Os emuladores de redes conseguem correr código real com tráfego interativo, e suportam topologias arbitrárias com um baixo custo. Além disso, o Mininet consegue emular redes que suportem o paradigma SDN. O Mininet Hi-Fi distingue-se dos demais emuladores pois providencia recursos para se obter fidelidade de desempenho. Esta é conseguida usando mecanismos de isolamento e provisão de recursos, e monitorizando a experiência para verificar se esta corre de uma maneira realista. Criou-se uma topologia baseada na topologia de rede fat-tree, com 4 servidores, 5 switches e 2 clientes. A experiência consistiu em ter os clientes a efetuarem um elevado número de pedidos aos servidores. Os servidores, ao receberem estes pedidos, efetuam processamento que impõe carga variada no seu CPU, de modo a simular pedidos diferentes. Os clientes registam o tempo de resposta de cada pedido. Todos estes valores foram agregados e apresentados em diagramas de caixa (boxplots). Esta experiência foi repetida com diferentes distribuições para a variação da carga da CPU e para diferentes configurações dos algoritmos. Para todas as situações, é visível uma melhoria significativa quando se efetua escalonamento de carga entre os vários caminhos disponíveis. Isto verifica-se independentemente do algoritmo de escolha de servidor. Concluímos, então, que uma solução em SDN consegue não só ser melhor em termos de desempenho, mas também sair mais em conta em relação a custos de equipamento.

Current network architectures are ill-suited to meet today’s enterprise and academic requirements. The problem lies in the complexity needed to control and manage the network. This complexity stems from the strong coupling between the control and data planes. A novel network paradigm, Software-Defined Networking (SDN), was proposed to alleviate this problem. The main idea is to decouple the control and data planes, allowing the network to be programmatically controlled. A key entity in SDN architectures is the controller. This logically centralized entity acts as a network operating system, providing applications with a uniform and centralized programming interface to the underlying network. In this Thesis we will develop an application that performs server load balancing in a Software-Defined Network. Today’s load balancers are high-priced devices that have limited customizability. Furthermore, they can only balance load between the servers, and are forced to use the path the network provides. In an SDN architecture, performing server load balancing does not require these expensive and inflexible devices. A low-cost load balancing solution can be designed, further enhanced with the ability to schedule load not only between servers, but also between paths. In addition, the centralized network control permitted in SDN allows the collection of updated link information to be used by the same logically centralized entity that makes forwarding decisions, which permits dynamic scheduling algorithms to decide on a best path for network traffic. We will show that such a solution outperforms ones which are oblivious to the path the traffic takes.

Tese de mestrado em Engenharia Informática, apresentada à Universidade de Lisboa, através da Faculdade de Ciências, 2013

Document Type Master thesis
Language English
Advisor(s) Ramos, Fernando; Bessani, Alysson Neves, 1978-
Contributor(s) Vasco, Marcos André Alves
facebook logo  linkedin logo  twitter logo 
mendeley logo

Related documents

No related documents