INSTITUTO DE COMPUTAÇÃO
Luís Guilherme Cordiolli Russi
Um Modelo de Gerenciador de Redes Virtuais para
Arcabouços de Processamento de
Big Data em Nuvens
Privadas e Híbridas
CAMPINAS
2017
Um Modelo de Gerenciador de Redes Virtuais para Arcabouços
de Processamento de Big Data em Nuvens Privadas e Híbridas
Dissertação apresentada ao Instituto de Computação da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestre em Ciência da Computação.
Orientador: Prof. Dr. Edmundo Roberto Mauro Madeira
Este exemplar corresponde à versão final da Dissertação defendida por Luís Guilherme Cordiolli Russi e orientada pelo Prof. Dr. Edmundo Roberto Mauro Madeira.
CAMPINAS
2017
Ficha catalográfica
Universidade Estadual de Campinas
Biblioteca do Instituto de Matemática, Estatística e Computação Científica Ana Regina Machado - CRB 8/5467
Russi, Luís Guilherme Cordiolli,
R92m RusUm modelo de gerenciador de redes virtuais para arcabouços de processamento de big data em nuvens privadas e híbridas / Luís Guilherme Cordiolli Russi. – Campinas, SP : [s.n.], 2017.
RusOrientador: Edmundo Roberto Mauro Madeira.
RusDissertação (mestrado) – Universidade Estadual de Campinas, Instituto de Computação.
Rus1. Computação em nuvem. 2. Virtualização de redes. 3. Redes de
computadores - Gerência. 4. Big data. 5. Processamento eletrônico de dados. I. Madeira, Edmundo Roberto Mauro,1958-. II. Universidade Estadual de Campinas. Instituto de Computação. III. Título.
Informações para Biblioteca Digital
Título em outro idioma: A virtual network management model for big data processing
frameworks in private and hybrid clouds
Palavras-chave em inglês:
Cloud computing
Networking virtualization Network management Big data
Electronic data processing
Área de concentração: Ciência da Computação Titulação: Mestre em Ciência da Computação Banca examinadora:
Edmundo Roberto Mauro Madeira [Orientador] Luiz Fernando Bittencourt
Bruno Richard Schulze
Data de defesa: 14-07-2017
Programa de Pós-Graduação: Ciência da Computação
INSTITUTO DE COMPUTAÇÃO
Luís Guilherme Cordiolli Russi
Um Modelo de Gerenciador de Redes Virtuais para Arcabouços
de Processamento de Big Data em Nuvens Privadas e Híbridas
Banca Examinadora:
• Prof. Dr. Edmundo Roberto Mauro Madeira Universidade Estadual de Campinas
• Prof. Dr. Luiz Fernando Bittencourt Universidade Estadual de Campinas • Dr. Bruno Richard Schulze
Laboratório Nacional de Computação Científica
A ata da defesa com as respectivas assinaturas dos membros da banca encontra-se no processo de vida acadêmica do aluno.
Aos meus pais e irmão, pelo amor, amizade, incentivo e apoio.
À Vanessa, pelo companheirismo de antes e durante toda esta jornada.
Ao meu orientador prof. Dr. Edmundo, pela oportunidade e ajuda na elaboração deste trabalho, também pelo suporte, correções, incentivos e toda confiança.
Aos amigos e colegas pela boa companhia e ajudas prestadas.
Às instituições e órgãos de fomento que proporcionaram todo corpo docente e equipa-mentos para a realização dos estudos, desenvolviequipa-mentos, testes e execuções.
Os arcabouços de processamento de big data proveem análise e tratamento de arquivos de maneira mais rápida e eficiente, enquanto as plataformas de nuvens possibilitam a alocação de recursos virtuais para que os usuários possam utilizá-los. Combinar recursos de nuvens para realizar execuções de aplicações dos arcabouços de processamento de big data demanda a realização de tarefas com um certo grau de complexidade, como a criação e a definição das redes virtuais responsáveis pela comunicação das máquinas virtuais da nuvem que irão permitir que as aplicações executem seus processamentos. Além de facilitar o processo de criação, o modelo proposto por nós nesta dissertação permite alocar larguras de banda mínima, modificar e remover redes virtuais, enquanto analisa o consumo dos recursos para criação, modificação e definição de largura de banda das redes virtuais da plataforma de nuvem, visando a melhor utilização dos recursos de redes virtuais.
Big data processing frameworks allow to analyze and process data files in an effective and faster manner, while cloud computing platforms allow to allocate virtual resources for users utilization. Combining cloud resources to perform application executions of big data processing frameworks demands to accomplish a certain set of complex tasks, such as the creation and definition of the virtual networks that are responsible to perform the communication between virtual machines that will allow applications to execute their processings in the cloud. Besides making the creation process easier, the model proposed by us in this dissertation allows to allocate minimum bandwidth, modify and remove virtual networks, as well as analyze the resources consumption to create, modify, and define the bandwidth for the virtual networks inside the cloud platform, aiming at the better resources utilization of the virtual networks.
2.1 Visão geral da virtualização de recursos para uma nuvem. . . 14
2.2 Arquitetura de Redes definidas por Software (Adaptado de [15]). . . 16
2.3 Processo de comparação dos pacotes na tabela OpenFlow. . . 18
2.4 Caminho de um pacote pela rede OpenFlow. . . 18
2.5 Switch OpenFlow. . . 19
2.6 Arquitetura do controlador de rede Ryu (Adaptado de [3]). . . 19
2.7 Design do Map/Reduce (Adaptado de [55]). . . 20
2.8 Design do Spark (Adaptado de [16]). . . 21
2.9 Arquitetura do Spark. . . 22
2.10 Arquitetura do HPAT. Adaptado de [50]. . . 23
2.11 Arquitetura do OpenStack (Obtido de [21]). . . 24
4.1 Sistemas operacionais das nuvens privada e híbrida com o Virtual Networ-king Manager. . . 30
4.2 Plataformas de nuvem com o modelo de gerenciador de redes virtuais para arcabouços de processamento de big data, Virtual Networking Manager. . . 32
4.3 Diagrama do modelo Map/Reduce. . . 33
4.4 Modelo para gerência de arcabouços de processamento de big data. . . 34
4.5 Modelo do Gerenciador de Redes Virtuais (Virtual Networking Manager ). . 37
5.1 Arquitetura do Gerenciador de Redes Virtuais (Virtual Networking Mana-ger ). . . 39
5.2 Integração do gerenciador de redes virtuais para arcabouços de processa-mento de big data com o OpenStack. . . 41
6.1 Fluxograma de criação de uma nova rede virtual. . . 46
6.2 Fluxograma de alteração da largura de banda de uma rede virtual. . . 49
6.3 Fluxograma de alteração da configuração de uma rede virtual. . . 50
6.4 Fluxograma de remoção de uma rede virtual. . . 51
7.1 Protótipo das nuvens privada e híbrida. . . 53
7.2 Tempos médios de execução da aplicação de contagem de palavras word count no Hadoop e no Spark na nuvem híbrida. . . 57
2.1 Componentes de uma entrada de fluxo na tabela de fluxo. . . 17
3.1 Tabela das características dos trabalhos relacionados. . . 27
5.1 Características da rede gerenciada por QoS. . . 43
7.1 Recursos físicos do cenário de testes da nuvem privada. . . 54
7.2 Recursos físicos do cenário de testes da nuvem pública. . . 54
7.3 Máquinas Virtuais do Cenário de Testes. . . 54
7.4 Tempos médios de cópia (aproximado) dos arquivos para o HDFS (em minutos). . . 56
7.5 Tempos médio de execução (aproximados) da aplicação de contagem de palavras (word count ) para Hadoop e Spark (em minutos). . . 57
7.6 Tempos médio de execução (aproximados) da aplicação de cálculo do Pi para Spark e HPAT (em segundos). . . 59
7.7 Tempos médio de execução (aproximados) da aplicação de análise de re-gressão (logistic regression) para Spark e HPAT (em segundos). . . 59
7.8 Taxas de transferência e recebimento máxima e mínima de uma rede virtual sem largura de banda mínima definida pelo VNM para comunicação entre VMs de um cluster na nuvem híbrida. . . 60
7.9 Taxas de transferência e recebimento máxima e mínima de uma rede virtual sem largura de banda mínima definida pelo VNM para comunicação entre VMs de dois clusters diferentes. . . 61
7.10 Taxas de transferência e recebimento máxima e mínima de uma rede virtual com largura de banda mínima definida pelo VNM para comunicação entre VMs de um cluster. . . 62
7.11 Taxas de transferência e recebimento máxima e mínima de duas redes vir-tuais com largura de banda mínima definida pelo VNM para comunicação entre VMs de dois clusters. . . 63
7.12 Taxas de transferência e recebimento máxima e mínima de duas redes vir-tuais com largura de banda mínima definida pelo VNM para comunicação entre VMs de dois clusters sem extrapolar o limite máximo de banda dis-ponível na rede física. . . 64
1 Introdução 12
2 Conceitos Básicos 14
2.1 Computação em nuvem . . . 14
2.2 Redes definidas por softwares . . . 16
2.3 OpenFlow . . . 17
2.4 Ryu . . . 18
2.5 Map/Reduce . . . 20
2.6 Hadoop . . . 20
2.7 Spark . . . 21
2.8 High Performance Analytics Toolkit (HPAT) . . . 22
2.9 OpenStack . . . 23
3 Trabalhos relacionados 25 4 Modelo do Gerenciador de Redes Virtuais 28 4.1 Arcabouços de Processamento de Big Data . . . 31
4.2 Integração entre nuvem e arcabouços de processamento de big data . . . . 32
4.3 O Virtual Networking Manager . . . 35
5 Arquitetura do Gerenciador de Redes Virtuais 38 5.1 Integração dos componentes do Virtual Networking Manager com a plata-forma da nuvem . . . 40
5.2 Aprovisionamento da largura de banda para redes públicas . . . 42
5.3 Políticas de qualidade de serviço . . . 42
5.4 Políticas de qualidade de serviços aplicadas pelo NBA . . . 43
6 Estudos de Caso 44 6.1 Componentes . . . 44
6.2 Cenários . . . 46
7 Protótipo e Análise de Resultados 52 7.1 Ambientes de execução . . . 52
7.2 Experimentos comparando execuções entre Hadoop e Spark . . . 55
7.3 Experimentos comparando execuções entre Spark e HPAT . . . 58
7.4 Comportamento das redes virtuais com aplicação da qualidade de serviço de largura de banda . . . 59
Introdução
Hoje em dia, cada vez mais dados são gerados na Internet. Estima-se que a quantidade de dados criados e copiados dobra de tamanho a cada dois anos e, por volta do ano de 2020, a quantidade de dados criados e copiados poderá chegar a 44 zettabytes (ou 44 trilhões de gigabytes) [4][26][31]. A quantidade de informações geradas muitas vezes ultrapassa a capacidade humana de análise de informações, levando ao surgimento de aplicações que permitam analisar e tratar grandes quantidades de dados de maneira rápida e eficiente utilizando recursos computacionais.
Os arcabouços de processamento de big data permitem analisar arquivos de dados estruturados e não estruturados. As atribuições de um arquivo de big data vão muito além do seu tamanho. Além das denominações de estruturado e não estruturado, há também os quatro "Vs", onde as informações são classificadas pelas características de volume, variedade, velocidade e veracidade. Essas características ajudam a definir a qual tratamento as informações podem ser submetidas, bem como qual aplicação pode ser usada na ajuda para prover uma melhor utilização das informações contidas nesses dados que, eventualmente, podem levar a uma melhor geração de receitas [56].
As aplicações utilizadas nesta dissertação para as análises de big data foram o Hadoop [51][19], o Spark [17] e o HPAT [50].
Devido à grande quantidade de informações e à vasta quantidade de aplicações que, de alguma maneira, permitem analisar e tratar essas informações para serem melhor utilizadas, muitas vezes torna-se necessária a utilização de uma plataforma que permita criar e gerenciar de maneira inteligente a infraestrutura e os sistemas utilizados para realizar as análises e tratamentos das informações, que podem ser geradas em grandes volumes e variedades, em alta velocidade.
As plataformas de nuvem computacional são plataformas que permitem a um admi-nistrador ou usuário aprovisionar e gerenciar recursos de computação, redes e armazena-mento de maneira rápida e efetiva. As plataformas de nuvem privada são implantadas para suprir as necessidades de empresas e universidades que desejam manter o controle dos dados, acessos e gerencia da plataforma de nuvem. Contudo, os recursos físicos dessas nuvens são limitados e, eventualmente é necessário adicionar mais recursos. As platafor-mas de nuvens híbridas são formadas pela combinação de recursos dessas nuvens privadas com recursos de nuvens públicas. Os recursos das nuvens públicas podem ser adquiridos por demanda, pelo modelo pay-per-use e combinados com a nuvem privada para suprir
sua eventual necessidade de mais recursos [39]. Apesar de todas as facilidades, combinar os recursos das nuvens privadas com os recursos das nuvens públicas não é uma tarefa simples, mesmo que algumas plataformas de nuvem forneçam funcionalidades para ad-ministradores ou usuários, elas não são completamente automatizadas e demandam um maior grau de conhecimento.
Algumas dificuldades encontradas ao aprovisionar e alocar recursos, configurar hosts, redes e armazenamentos virtuais, configurar aplicações e executar o processo de análise e tratamento de dados, podem levar a uma subutilização dos recursos disponíveis na plataforma de nuvem.
Muitas vezes, universidades e empresas podem preferir implantar a sua própria nuvem, seja pelo controle dos dados que elas possuem, custos, recursos físicos existentes, pesquisas, ou qualquer outra necessidade que leve a implantar uma nuvem privada dentro de suas dependências.
Eventualmente, a nuvem privada pode não possuir recursos físicos suficientes para atender alguma demanda momentânea, fazendo-se necessário alugar algumas máquinas virtuais de uma nuvem pública. Entretanto, somente alugar e obter a disponibilidade de recursos em uma nuvem pública não garantem a devida comunicação entre as má-quinas virtuais na nuvem privada com as mámá-quinas virtuais na nuvem pública, tornando indispensável a realização de configurações (algumas complexas) para tornar possível a comunicação entre essas máquinas virtuais.
Como parte de uma ferramenta que realiza o aprovisionamento e configuração de clusters virtuais de maneira automatizada em nuvens híbridas [44], preparando um deter-minado cluster virtual localizado na nuvem privada para se comunicar e utilizar recursos computacionais locados de uma nuvem pública, nosso trabalho apresenta um modelo de gerenciador de redes virtuais para arcabouços de processamento de big data em nuvens privadas e híbridas.
A contribuição desta dissertação é o projeto e o desenvolvimento de um modelo de gerenciador de redes virtuais para arcabouços de processamento de big data em nuvens privadas e híbridas. Este modelo também gerencia recursos de qualidade de serviço para alocação de largura de banda mínima nas redes virtuais.
O modelo é composto por um gerente de redes virtuais que permite melhor empregar os recursos das redes virtuais para aplicações de big data, gerenciando recursos de maneira automatizada, possibilitando uma melhor utilização dos recursos da nuvem.
Nosso trabalho está estruturado da seguinte maneira: os conceitos básicos necessários para o melhor entendimento do nosso modelo encontram-se no Capítulo 2; os trabalhos relacionados estão no Capítulo 3; o modelo por nós proposto é descrito no Capítulo 4; a arquitetura implantada para a validação do nosso modelo é descrita no Capítulo 5; os estudos de casos considerados no nosso modelo são descritos no Capítulo 6; os resultados das execuções dos nossos testes na arquitetura são apresentados no Capítulo 7; e, finalmente, no Capítulo 8 nós apresentamos nossas conclusões e trabalhos futuros.
Conceitos Básicos
Este capítulo é composto pelos conceitos básicos necessários para um melhor entendimento do nosso trabalho. As seções a seguir descrevem: Computação em nuvem (2.1); Redes definidas por software (2.2); OpenFlow (2.3); Ryu (2.4); Map/Reduce (2.5); Hadoop (2.6); Spark (2.7); High Performance Analytics Toolkit (2.8); e OpenStack (2.9).
2.1
Computação em nuvem
Na literatura, a computação em nuvem (Figura 2.1) é definida como um modelo de re-cursos ubíquos configuráveis sob demanda. Tais rere-cursos são redes, servidores, discos de armazenamento, aplicações e serviços, podendo ser provisionados rapidamente [39].
Datacenter Internet
Figura 2.1: Visão geral da virtualização de recursos para uma nuvem.
O modelo da nuvem é composto por modelos de serviços e de desenvolvimento. Os modelos de serviços são:
• Software como um Serviço (SaaS): Fornece aos usuários da nuvem a capacidade de utilizar aplicações que estão em execução dentro da infraestrutura da nuvem. Aplicações como, por exemplo, emails online, são normalmente acessadas através de um navegador web. Neste modelo, os usuários não gerenciam ou controlam a infraestrutura da nuvem.
• Plataforma como um Serviço (PaaS): Fornece aos usuários da nuvem ferramentas de desenvolvimento de bibliotecas, linguagens de programação e serviços. Como no modelo anterior, os usuários também não possuem a capacidade de gerenciar ou controlar a infraestrutura da nuvem.
• Infraestrutura como um Serviço (IaaS): Permite que os usuários da nuvem provisio-nem processamento, armazenamento, redes e outros recursos de computação, o que inclui sistemas operacionais e aplicações. Neste modelo, os usuários não gerenciam ou controlam a infraestrutura física da nuvem, porém podem controlar recursos de computação virtuais descritos.
Os modelos de desenvolvimento são:
• Nuvem Privada: A infraestrutura da nuvem é provisionada para uso exclusivo de uma única organização. Ela deve ser gerenciada e operada pela organização que faz uso da nuvem.
• Nuvem Comunitária: O aprovisionamento da infraestrutura da nuvem é feito para uso exclusivo de organizações que compartilham interesses. Ela deve ser gerenciada e operada por uma (ou mais) organizações que compõem a comunidade.
• Nuvem Pública: Neste modelo, a infraestrutura da nuvem é provisionada para utili-zação aberta ao público. São normalmente gerenciadas por empresas vendedoras de serviços de nuvens, universidades, organizações governamentais, ou uma combinação delas.
• Nuvem Híbrida: A composição da infraestrutura da nuvem híbrida é feita por duas ou mais infraestruturas distintas (privada, comunitária ou pública) que continuam como entidades únicas, mas são unidas por tecnologias padronizadas ou proprietárias que possibilitam a portabilidade de aplicações e dados.
O sistema operacional da nuvem pode possuir cinco características:
• Serviços sob demanda: Um usuário pode provisionar recursos computacionais tais como tempo de servidores e armazenamento, quando necessário automaticamente, sem requerer a interação com um humano em cada provedor de serviços.
• Amplo acesso à rede: Os recursos são disponíveis através da rede e acessados por mecanismos heterogêneos por meio de plataformas comuns.
• Pacote de recursos: O provedor dos recursos computacionais possui um pacote de recursos capaz de servir vários usuários (consumidores) em um modelo de loca-ção múltipla, com diferentes recursos físicos e virtuais dinamicamente fornecidos de acordo com a demanda do usuário.
• Elasticidade rápida: Recursos podem ser elasticamente provisionados e liberados. Frequentemente, os recursos disponíveis para o aprovisionamento parecem ilimitados aos olhos do usuário, uma vez que a elasticidade permite a utilização em grandes quantidades a qualquer momento.
• Serviço medido: Os recursos do sistema da nuvem são controlados através do modelo pay-per-use (pague pelo uso, em tradução direta), permitindo que o usuário possa monitorar o seu consumo de recursos, fornecendo transparência para provedor e consumidor.
2.2
Redes definidas por softwares
Uma rede definida por software (tradução direta de Software Defined Network ) é um paradigma de arquitetura dinâmica de rede, gerenciável, de bom custo-benefício e adap-tável. É ideal para aplicações dinâmicas e que necessitam de alta largura de banda. A arquitetura é caracterizada por separar o plano de controle do plano de encaminhamento em dispositivos de encaminhamento de dados da rede [15][40].
A Figura 2.2 ilustra a arquitetura de uma rede definida por software.
Application Layer Business Applications Control Layer Network Services Network Services Infrastructure Layer Southbound Interface Northbound Interface Programmable Open APIs
Figura 2.2: Arquitetura de Redes definidas por Software (Adaptado de [15]). O plano de controle (Control Layer na Figura 2.2), muitas vezes denominado como o sistema operacional da rede, controla todo o estado da rede de um ponto centralizado. Para realizar esse controle sobre a rede, é necessária a utilização de um controlador de rede. Existem vários controladores de rede na literatura como, por exemplo, Ryu [3], Opendaylight [8], Floodlight [5], NOX [7], POX [13], entre outros [45].
A camada do plano de controle se comunica com duas interfaces, a Northbound e a Southbound. A interface Northbound permite que o controlador de rede implemente uma interface para que aplicações orquestrem e monitorem o funcionamento do controlador de rede. A interface Southbound provê especificações para o protocolo OpenFlow, permitindo a comunicação entre o controlador de rede e os recursos da rede, tanto físicos quanto virtuais (localizados na camada Infrastructure Layer na Figura 2.2).
O plano de encaminhamento de dados da rede é mantido separado, utilizando os equipamentos de roteamento existentes, que passam a obedecer a inteligência adicionada pelo controlador (plano de controle).
Esse paradigma possibilita ao administrador da rede configurar seus equipamentos de rede diretamente do controlador e em um local centralizado, obtendo uma maior flexibili-dade nas redes, além de permitir controle de acesso, virtualização de redes, gerenciamento de energia e a criação de novos protótipos de rede.
2.3
OpenFlow
O protocolo OpenFlow [38] foi proposto com o intuito de ajudar a estender a programa-bilidade dos recursos de switches.
Na arquitetura do protocolo (Figura 2.5), o dispositivo de encaminhamento (também conhecido como switch OpenFlow ) contém uma ou mais tabelas de fluxos, um grupo de tabelas e uma camada que se comunica diretamente com um controlador, através do protocolo OpenFlow.
As tabelas de fluxos (Tabela 2.1) são compostas pelas entradas de fluxos, onde cada uma determina como os pacotes, pertencentes a um determinado fluxo, serão processados e transmitidos. As entradas de fluxos são tipicamente compostas de:
• regras compatíveis, utilizadas para os pacotes recebidos,
• contadores, para coletar estatísticas de um fluxo em particular,
• conjunto de instruções (ou ações) para serem aplicadas sobre uma compatibilidade, direcionando o manuseio dos pacotes compatíveis.
Match fields Priority Counters Instructions Timeouts Cookie
Tabela 2.1: Componentes de uma entrada de fluxo na tabela de fluxo.
Dentro de cada tabela, as entradas são comparadas com pacotes na ordem de prio-ridade. Como exibido na Figura 2.3, um pacote recém chegado é primeiro comparado contra a primeira tabela, se houver uma entrada compatível, as instruções nessa entrada são realizadas, como por exemplo, encaminhar o pacote para um determinado destino passando por um determinado caminho na rede (Figura 2.4). Se um pacote não for com-patível, então a tabela de pacotes não compatíveis especifica como processar pacotes que não correspondem com outras entradas de fluxos na tabela de fluxos e pode, por exemplo, enviar os pacotes para o controlador, descartar os pacotes ou direcionar os pacotes para uma tabela na sequencia.
O grupo de tabelas (Group table na Figura 2.5) possui a habilidade de adicionar um conjunto de ações (set, pop ou output ) em múltiplos caminhos de grupos de portas.
Packet in Ingress port Action set = {} Table 0 Table 1 Packet + Ingress port + metadata Action set = {} Table n Execute Action Set Packet Action set = {} Packet out OpenFlow switch
Figura 2.3: Processo de comparação dos pacotes na tabela OpenFlow.
Packet SDN
Controller
Packet
Figura 2.4: Caminho de um pacote pela rede OpenFlow.
O canal OpenFlow (OpenFlow channel na Figura 2.5) é a interface entre um Switch OpenFlow e um controlador de rede, eles se comunicam por meio da Southbound interface (como descrito na seção 2.4 do controlador de redes Ryu).
2.4
Ryu
O Ryu é um framework baseado em componente para uma rede definida por software [3]. Ele provê componentes com uma API que permite aos desenvolvedores criarem novas redes de gerência e controle inteligente para aplicações e suporte a vários protocolos para gerenciar dispositivos de rede, tais como o OpenFlow (nas versões 1.0, 1.2, 1.3, 1.4 e 1.5), Netconf e OF-config.
Os componentes do Ryu formam a arquitetura exibida na Figura 2.6. Ele provê isolamento de redes, roteamento de pacotes de camada 2 (layer 2 switch), descoberta de topologia, firewall e rastreamento de pacotes.
Group table OpenFlow channel Flow table Flow table Controller OpenFlow protocol
Figura 2.5: Switch OpenFlow.
Application Layer Cloud Orchestrator
Control Layer Ryu
Infrastructure Layer Southbound Interface REST API REST API REST API Northbound Interface OpenFlow Switch
Figura 2.6: Arquitetura do controlador de rede Ryu (Adaptado de [3]).
O Ryu é o componente da camada de controle em uma rede definida por software, descrita na Seção 2.2 (Control Layer na Figura 2.2). Na sua interface Southbound, ele se comunica com o protocolo OpenFlow para o envio das requisições para o OpenFlow Switch. Já na interface Northbound, ele se comunica com as REST APIs para atender as requisições que chegam do orquestrador, implementado por exemplo, por um controlador
de redes de um sistema operacional de nuvem.
2.5
Map/Reduce
No modelo de programação do Map/Reduce (Figura 2.7), um conjunto no formato de pares chave/valor é fornecido como entrada e a saída produz um conjunto de chave/valor [27].
A função Map recebe um par de chave/valor na entrada e produz um conjunto mediário de pares chave/valor. A biblioteca Map/Reduce agrupa todos os valores inter-mediários associados com a mesma chave intermediária e os encaminha para a função de Reduce.
A função de Reduce recebe uma chave intermediária e um conjunto de valores para aquela chave. A função então agrupa esses valores para montar um conjunto de valores possivelmente menor. Tipicamente, uma saída produzida pela função de Reduce, contém um valor ou zero. Map Map Map Map Map Input Shuffle Phase Reduce Reduce Output Output Master Map
Phase Worker Master
HDFS
Figura 2.7: Design do Map/Reduce (Adaptado de [55]).
2.6
Hadoop
O Hadoop é um framework que provê suporte a processamento distribuído para a análise e processamento de grandes conjuntos de dados utilizando Map/Reduce [51][19][47]. Uti-lizando um sistema de arquivos distribuído (Hadoop Distributed File System ou HDFS ), tais conjuntos de dados são distribuídos através de cluters de computadores por modelos de programação simples.
O Hadoop foi desenvolvido para escalar de simples servidores para centenas de máqui-nas, tendo como base o sistema de arquivos distribuído, cada local oferecendo trabalhos
de computação e armazenamento para os dados compartilhados. A Figura 2.7 ilustra o framework, que é composto por:
• um nó mestre (master node) que recebe os arquivos de entrada (input ) a serem armazenados no HDFS e enviados aos nós escravos (worker nodes) na fase de Map. • vários nós escravos que recebem pedaços de um dos arquivos de entrada (chunks) da fase Map a serem tratados que, após o tratamento (fase Shuffle), são enviados ao nó mestre (fase Reduce).
Após esse processo, um arquivo contento a saída (output ) para cada um dos arquivos tratados é gerado no sistema de arquivos distribuído do Hadoop (HDFS ) dentro do nó mestre.
2.7
Spark
O Spark provê uma abstração de programação que permite que requisições executem até cem vezes mais rápidas em dados e implementações existentes. Ele também provê capacidades computacionais armazenadas em memória, distribuindo modelos de execução que suportam uma variedade de aplicações, facilitando o desenvolvimento de aplicações em Java, Scala e Python [17] [54].
As aplicações Spark são executadas como conjuntos de processos independentes e co-ordenadas pelo objeto Spark context (chamado de Driver program) em um cluster (Figura 2.8). Para executar as aplicações em um cluster, o Spark context pode se conectar com vários tipos de gerentes de cluster (Cluster manager ), o qual aloca recursos para as apli-cações. Uma vez conectado, o Spark obtém os executores nos nós de um cluster para os processos que realizam as computações e armazenarem os dados da aplicação. Em seguida, ele envia o código da aplicação (definido por um pacote JAR ou Python) para os executores (Executor ). Por fim, o Spark context envia tarefas (Task ) para os executores processarem. Driver program Spark context Worker node Executor Task Task Cache Worker node Executor Task Task Cache Cluster manager
Figura 2.8: Design do Spark (Adaptado de [16]).
Atualmente, várias empresas utilizam o Spark em produção [14] e a Figura 2.9 exibe os componentes mais comuns utilizados com base no Spark :
• Spark SQL provê uma linguagem para manipular DataFrames em Scala, Java ou Python. Um DataFrames suporta dados estruturados e semi-estruturados. Ele também provê suporte à linguagem SQL;
• Spark Streaming utiliza o rápido escalonamento do núcleo do Spark para realizar análises em streaming. Ele distribui os dados em pequenos lotes e realiza transfor-mações dos lotes de dados para o sistema de arquivos distribuído;
• MLlib (Machine Learning) é um framework distribuído de aprendizado de máquina que utiliza o núcleo do Spark. Por processar os dados em memória, ele é até nove vezes mais rápido do que uma implementação baseada em processar dados armaze-nados em disco;
• GraphX (Graphics) é um framework distribuído para processamentos gráficos imu-táveis utilizando o sistema de arquivos distribuído.
Apache Spark Spark SQL Spark Streaming MLlib (Machine Learning) GraphX (Graphics)
Figura 2.9: Arquitetura do Spark.
2.8
High Performance Analytics Toolkit (HPAT)
HPAT é um framework baseado em compilador para análise de big data em clusters de larga escala que paraleliza e escala automaticamente programas de análise em alto nível. O HPAT possui como objetivo paralelizar de maneira automática tarefas de análise comuns tais como consulta de dados em paralelo e algoritmos de aprendizado de máquina [50].
Utilizando como base de paralelismo o padrão map/reduce, o framework busca encon-trar um auto-paralelismo que não viole suas semânticas de alto nível, em que cada matriz de conjunto de dados é distribuída em blocos ou replicada para todos os processos que compõem o cluster em execução para o processo de análise dos dados.
O HPAT utiliza um pacote de ferramentas de compilação provido pela linguagem de programação Julia [35]. A Figura 2.10 exibe o processo de compilação do HPAT. As representações em vermelho exibem os componentes do HPAT. O componente Macro-Pass traduz as extensões do HPAT em chamadas de funções e tipo de anotações para serem compilados pela linguagem Julia. O compilador da linguagem Julia então realiza
as próximas traduções necessárias em tipos de funções intermediárias. O componente Domain-Pass transforma as extensões do HPAT em uma forma mais propícia de otimiza-ção para os componentes Domain-IR e Parallel-IR. Esses componentes são providos pelo pacote de aceleração paralela da linguagem Julia. O componente Domain-IR identifica os operadores nas representações intermediárias nas quais são paralelizáveis. O componente Parallel-IR recebe diferentes tipos de operadores paralelos encontrados pelo Domain-IR e os transforma em representações comuns chamadas de parfor, que representa um loop for aninhado nos quais as iterações podem ser realizadas em paralelo, e os realiza fusões e outras otimizações nas funções intermediárias. O componente Distributed-Pass parti-ciona os arrays e os parfors para execução distribuída em memória e gera as chamadas de comunicação. Então, o componente HPAT Code Generation tira proveito de vários ganchos fornecidos pelo componente CGen para gerar o código em C++.
Julia source Macro-Pass Julia compiler Domain-Pass
Domain IR Parallel IR Distributed-Pass CGen
HPAT Code Generation MPI/C++ source Backend Compiler (ICC/GCC)
Figura 2.10: Arquitetura do HPAT. Adaptado de [50].
2.9
OpenStack
O OpenStack é um sistema operacional de código aberto para nuvens computacionais. Com ele é possível criar e controlar recursos computacionais, de armazenamento e de rede que irão compor um modelo de desenvolvimento de nuvem privada ou pública [21].
Seus principais componentes (Figura 2.11) são:
• Compute: Os recursos computacionais são acessíveis para administradores e usuários através de interfaces web e, para desenvolvedores, através de APIs. A arquitetura computacional é desenhada para escalar horizontalmente em um hardware comum; • Networking: Fornece uma API para administradores e desenvolvedores criarem recursos de redes e roteadores virtuais para os usuários da nuvem. Tais recursos de redes e roteadores virtuais podem ser utilizados de forma comum ou privada pelos usuários da nuvem;
• Storage: Recurso de armazenamento de dados escalável. Provê uma API totalmente distribuída que permite que os recursos de armazenamento possam ser integrados diretamente em aplicações utilizadas na nuvem, utilizados para backup ou retenção de dados.
Figura 2.11: Arquitetura do OpenStack (Obtido de [21]).
Neutron
Neutron é um componente do OpenStack que provê redes como um serviço (networking as a service) entre interfaces de redes [20].
Ele fornece uma API aos usuários da nuvem que permite: • construir topologias de redes simples e complexas, • configurar políticas de rede avançadas na nuvem,
• adicionar plugins que introduzem capacidades avançadas de redes (como o tunela-mento de camada dois em camada três e garantias de qualidade de serviço),
• construir serviços avançados de redes (como firewall e controle de carga) e adicioná-los a redes de usuários da nuvem,
• manusear redes através de uma página web (como criação e remoção de sub-redes, iniciar uma máquina virtual em uma rede específica).
Trabalhos relacionados
Neste capítulo descrevemos alguns trabalhos que são relacionados ao nosso. Incluímos um breve resumo de cada um, apresentando as principais características na Tabela 3.1.
Telenyk e outros em An Approach to Software Defined Cloud Infrastructure Manage-ment [48] descrevem uma arquitetura baseada em software para gerenciar a infraestrutura de uma nuvem, alocando máquinas virtuais de maneira efetiva no hardware que compõe a nuvem. A arquitetura proposta também possui uma implementação de acordos de níveis de serviço para a utilização do hardware da nuvem, realizando a medição do hardware para prover a criação das VMs.
Nelson da Fonseca e Raouf Boutaba no capítulo Cloud Architectures, Networks, Servi-ces and Management [23], do livro Cloud ServiServi-ces, Networking, and Management, descre-vem os conceitos para computação em nudescre-vem e apontam os desafios relacionados a esse paradigma. Dentre os desafios citados, eles apontam a virtualização na nuvem, garantia de recursos em redes de data centers, relevantes padronizações, OpenFlow e SDN para nuvens. A virtualização em nuvem é a principal tecnologia de uma nuvem computacional, não só a virtualização de recursos computacionais, mas também a virtualização de recur-sos de redes, como diferentes redes virtuais para os vários usuários da nuvem. As redes em data centers e padronizações relevantes direcionam para a necessidade da manutenção de requerimentos como largura de banda, jitter, atraso e perda de pacotes. OpenFlow e SDN para nuvens introduzem uma maior complexidade na plataforma da nuvem, porém possibilita uma maior disponibilidade e aplicação de métodos de gerencia avançados.
Wang e outros em A survey on data center networking for cloud computing [52] apre-sentam um survey de redes virtuais em data centers apontando os desafios que as redes virtuais enfrentam quando arquivos de big data trafegam pelas redes de nuvens privadas, públicas e híbridas. Os autores também descrevem duas possíveis direções para a im-plementação das topologias de redes de data centers, uma na qual o design da rede seja economicamente viável para permitir escalabilidade e a outra é desenvolvendo técnicas que permitam vencer os desafios dentro da topologia existente.
Thaha e outros em Data Location Aware Scheduling for Virtual Hadoop Cluster De-ployment on Private Cloud Computing Environment [49] apresentam uma investigação sobre os efeitos da localização de dados em instalações do Hadoop na nuvem. A análise de desempenho conduzida identifica a latência da rede como um dos principais fatores que impactam o desempenho de clusters Hadoop na nuvem e um escalonador baseado na
localidade dos dados é proposto.
Jammal e outros em Software defined networking: State of the art and research chal-lenges [34] apresentam os desafios das redes definidas por software juntamente com a computação em nuvem. Os desafios descritos vão desde a alta disponibilidade para apli-cações web, passando por segurança e engenharia de tráfego, até o aprovisionamento, configuração e gerencia das redes virtuais.
Lin e outros em Log Analysis in Cloud Computing Environment with Hadoop and Spark [37] propõem uma plataforma de nuvem privada para a análise de desempenho comparativa entre as aplicações Hadoop e Spark. Eles apresentam experimentos imple-mentados em Kmeans e em PageRank e validam que o desempenho do Spark é superior ao do Hadoop para esses experimentos.
Ding e outros em An Overview on Cloud Computing Platform Spark for Human Ge-nome Mining [28] comparam a eficiência entre o Hadoop e o Spark apontando a alta latência como o principal ponto fraco do Hadoop. Eles também consideram que os pes-quisadores da área biomédica ainda lançam para a plataforma de nuvem um olhar cético, porém os autores afirmam que a plataforma de nuvem, juntamente como o Spark, é a maneira mais efetiva para resolver o problema genético.
Shyam e outros em Apache Spark a Big Data Analytics Platform for Smart Grid [41] apresentam testes de desempenho e estabilidade em execuções com Spark em uma grade computacional, na qual pode prover melhor monitoramento e controle para as execuções de análises em grandes massas de dados na aplicação.
Fazio e outros em Big Data Storage in the Cloud for Smart Environment Monitoring [32] propõem um sistema de armazenamento híbrido para otimizar tarefas de gerenci-amento de dados em sistemas de dados orientados a documento e objetos na nuvem. Desenvolvido em um ambiente de nuvem capaz de oferecer serviço de armazenamento transparente para usuários finais que não possuem conhecimento nas diferentes tecnolo-gias envolvidas.
No nosso trabalho (Um Modelo de Gerenciador de Redes Virtuais para Arcabouços de Processamento de Big Data em Nuvens Privadas e Híbridas) desenvolvemos um modelo para gerenciar redes virtuais para arcabouços de processamento de big data em nuvens privadas e híbridas. Nosso modelo provê qualidade de serviço para determinar a largura de banda mínima das redes virtuais existentes na plataforma de nuvem privada, permitindo uma melhor utilização dos recursos limitados de rede. Além disso, nosso modelo também prepara e configura uma conexão com a plataforma de nuvem pública para permitir co-municação segura entre as máquinas virtuais que compõem clusters para os arcabouços de processamento de big data Hadoop, Spark e HPAT. Tal comunicação é essencial para a existência da nuvem híbrida na realização das execuções das aplicações dos arcabouços de processamento de big data.
A Tabela 3.1 apresenta as características que os trabalhos relacionados possuem (ou não), que são Computação em Nuvem (Cloud Computing), Virtualização de Redes (Networ-king Virtualization), Gerenciamento de Redes (Networ(Networ-king Management ), Aplicações para big data Hadoop, Spark e HPAT.
Tabela 3.1: Tabela das características dos trabalhos relacionados. Trabalho Cloud Compu-ting Networking Virtualiza-tion Networking Manage-ment
Hadoop Spark HPAT
S. Telenyk [48] S S S N N N Nelson L. S. da Fonseca [23] S S S N N N Wang B. [52] S S S N N N A. F. Thaha [49] S S N N N N Jammal M. [34] S S S N N N X. Lin [37] S S N S S N D. Ding [28] S S N S S N Shyam R. [41] N S N S S N Fazio M. [32] S S N S N N Nosso trabalho S S S S S S
Modelo de Gerência de Redes Virtuais
para Arcabouços de Processamento de
Big Data
em Nuvens Privadas e
Híbridas
A contribuição da dissertação dá-se pela criação de um gerenciador de redes virtuais (Virtual Networking Manager ) para arcabouços de processamento de big data em nuvens privadas e híbridas. Ele permite gerenciar redes virtuais dentro de uma plataforma de nuvem de maneira automatizada. Sua composição e funcionalidade são descritas nos capítulos de Modelo (4) e Arquitetura (5).
Este capítulo descreve o modelo proposto, as aplicações utilizadas para validar o mo-delo, a integração entre nuvem e aplicação, além do Virtual Networking Manager propri-amente dito.
Modelo para gerenciar redes virtuais para arcabouços de
processamento de
big data em nuvens privadas e
híbri-das
O modelo proposto possibilita gerenciar redes virtuais. Podendo operar tanto em pla-taformas de nuvens privadas (Figura 4.1a) quanto em plapla-taformas de nuvens híbridas (Figura 4.1b), tais redes virtuais se beneficiarão da gerência para criação, remoção, mo-dificação e análise.
O Virtual Networking Manager (VNM ) é parte de um modelo que independe do sistema operacional da nuvem. Desenvolvido para realizar o gerenciamento de redes em nuvens privadas e híbridas, ele é responsável pela criação das redes e roteadores virtuais da plataforma de nuvem para atender conjuntos de máquinas virtuais instanciadas nessas nuvens.
O VNM facilita a criação de redes virtuais privadas e públicas, conjuntos de IPs e roteadores virtuais, tornando tais processos simples e transparentes para o usuário da plataforma de nuvem. Além disso, o VNM possui ferramentas capazes de gerenciar re-cursos de redes como largura de banda e disponibilidade de rere-cursos, permitindo que tais
recursos sejam melhor aproveitados dentro do ambiente da nuvem.
O sistema operacional da nuvem privada, apresentado na Figura 4.1a, é composto por um portal web ao qual o usuário acessa a plataforma da nuvem e realiza requisições para a criação de máquinas virtuais, discos de armazenamento virtuais, redes virtuais e chaves de segurança.
Uma requisição contendo a descrição dos requisitos do usuário é enviada para o fra-mework da nuvem privada, que procede com a comunicação com os componentes Cloud Compute, Virtual Networking Manager (em conjunto com o componente Cloud Network ) e Cloud Storage. Cada componente recebe então uma requisição de sua competência para a reserva de recursos computacionais, redes virtuais e volumes virtuais.
O Virtual Networking Manager cuida da criação, remoção e modificação das redes virtuais, roteadores virtuais, conjuntos de IPs, larguras de banda e regras. O componente Cloud Compute é responsável pela criação, remoção e modificação das máquinas virtuais que serão alocadas na plataforma de nuvem. A criação dos discos de armazenamento virtuais é feita pelo componente Cloud Storage.
Ao receber a requisição do portal da web, o sistema operacional da nuvem privada repassa o pedido para os componentes de forma coordenada. A interação dos componentes dá-se da seguinte maneira:
1. O Virtual Networking Manager recebe o pedido de criação da rede virtual e seus componentes (roteador, conjunto de IPs, largura de banda e regras de rede) do sistema operacional da nuvem privada. O VNM analisa os recursos disponíveis e, então, se comunica com o componente Cloud Network para procederem com a criação e configuração da rede virtual e seus componentes e repassa a informação da conclusão do processo ao Cloud Compute da nuvem privada;
2. Após a criação da rede, o framework requisita a criação dos volumes virtuais para o Cloud Storage, que informa ao framework da nuvem privada a conclusão do processo; 3. O framework da nuvem privada, então, se comunica com o componente Cloud Com-pute, que obtém as informações necessárias dos componentes Virtual Networking Manager e Cloud Storage e realiza a criação das máquinas virtuais.
4. Ao término da utilização das máquinas virtuais, o framework da nuvem privada dispara uma requisição para os componentes que irão proceder com a remoção das máquinas, volumes e redes virtuais. O Cloud Compute procede com a remoção das máquinas virtuais, o VNM envia ao componente Cloud Network o processo para remoção da rede, roteador e portas virtuais, e o componente Cloud Storage procede com a remoção dos discos virtuais.
A Figura 4.1b representa a junção da nuvem privada com a nuvem pública, compondo a nuvem híbrida.
Nesse cenário o framework possui a possibilidade de alocar recursos na nuvem pública, quando necessário, para a execução das aplicações de big data que requerem mais recursos dos que podem ser fornecidos pela nuvem privada.
WEB CLOUD PORTAL (WCP) Cloud Storage VM VM VM Virtual Networking Manager (VNM) Cloud Compute
Private Cloud System
Cloud Network
(a) Nuvem privada.
WEB CLOUD PORTAL (WCP) Cloud Storage VM VM VM Virtual Networking Manager (VNM) Cloud Compute
Private Cloud System VM
VM Public Cloud System
Cloud Network
Cloud Engine
(b) Nuvem híbrida.
Figura 4.1: Sistemas operacionais das nuvens privada e híbrida com o Virtual Networking Manager.
Além de gerenciar os recursos utilizados na nuvem privada, o framework gerencia as requisições para as criações dos recursos virtuais na nuvem pública comunicando direta-mente com a Cloud Engine da nuvem pública. A Cloud Engine da nuvem pública pode ser composta pelas plataformas de nuvem pública como a AWS da Amazon, a Google Cloud Platform ou a Azure da Microsoft.
O Virtual Networking Manager (VNM ) recebe a requisição do framework para a criação e configuração da rede virtual que será responsável pela comunicação entre as máquinas virtuais da nuvem privada e as máquinas virtuais da nuvem pública.
4.1
Arcabouços de Processamento de
Big Data
Para compor a validação do nosso gerente, além da plataforma de nuvem, iremos utili-zar três arcabouços de processamento de big data que permitem trabalhar em clusters computacionais.
A Figura 4.2 exibe, de maneira geral, como os arcabouços de processamento de big data Hadoop, Spark e HPAT estão dispostos dentro da plataforma de nuvem.
Na base, nós temos as plataformas das nuvens privada e pública, que irão compor a nuvem híbrida. Localizados logo acima, estão as representações dos componentes da nuvem Compute, Networking e Storage, que são os componentes existentes dentro de uma plataforma de nuvem.
Acima do componente de rede (Networking), está localizado o Virtual Networking Ma-nager (VNM ), que gerencia a criação dos recursos de rede que permitirão a comunicação entre as máquinas virtuais hospedadas dentro das plataformas de nuvem.
As representações Hadoop VMs, Spark VMs e HPAT VMs simbolizam as máquinas virtuais que irão executar os arcabouços de processamento de big data, representados por Hadoop, Spark e HPAT. As máquinas virtuais com os arcabouços de processamento Ha-doop e Spark estão conectadas ao sistema de armazenamento distribuído do HaHa-doop, o Hadoop Distributed File System (HDFS ). O arcabouço de processamento HPAT é conec-tado ao sistema de compartilhamento de arquivos padrão do Linux.
O primeiro arcabouço de processamento, o Hadoop [47], utiliza o modelo Map/Reduce [27]. A máquina virtual Master, que está conectada ao sistema de arquivos distribuído do Hadoop (HDFS ), recebe um conjunto de pares chave/valor como entrada, envia para as máquinas virtuais Workers que produzem valores intermediários de pares chave/valor e, ao final da execução, são agrupados na fase de Reduce. (Figura 4.3).
Para armazenar os dados de entrada e saída, o Hadoop utiliza um sistema de arquivos chamado Hadoop Distributed File System (HDFS). O HDFS provê uma API que expõe a localização dos blocos de arquivos. Essa exposição permite que aplicações baseadas no modelo Map/Reduce agendem tarefas diretamente para a localidade dos dados. O HDFS também permite que uma aplicação determine um fator de replicação para um determinado arquivo. Por padrão, o fator de replicação de um arquivo é três. Para arquivos críticos ou arquivos nos quais o acesso é mais frequente, possuir um fator de replicação elevado melhora a tolerância a falhas e aumenta a frequência das leituras.
en-Private Cloud System / Plubic Cloud System Compute Storage
Spark Hadoop
Hadoop VMs / Spark VMs / HPAT VMs
Hadoop Distributed File System Hadoop Distributed File System Virtual Networking Manager Networking HPAT Linux File System
Figura 4.2: Plataformas de nuvem com o modelo de gerenciador de redes virtuais para arcabouços de processamento de big data, Virtual Networking Manager.
quanto provê propriedades de escalabilidade e tolerância a falhas. O Spark fornece duas principais abstrações para programação paralela: conjuntos de dados resilientes distribuí-dos (em inglês RDD ) e operações paralelas nesses conjuntos de dadistribuí-dos (invocado através da passagem de uma função aplicada no conjunto de dados). O RDD é uma coleção de objetos particionados através de um conjunto de máquinas que pode ser reconstruído se uma partição for perdida.
O terceiro arcabouço de processamento, o HPAT é baseado em compilador para ana-lisar big data em clusters. O HPAT paraleliza e escala automaticamente programas de análise em alto nível como consulta de dados em paralelo e algoritmos de aprendizado de máquina, tendo como principal característica contornar o padrão de paralelismo do Map/Reduce praticado pelo Hadoop e Spark, na qual há a necessidade de utilizar o HDFS.
4.2
Integração entre nuvem e arcabouços de
processa-mento de
big data
Além da boa integração com o componente de rede da nuvem (Cloud Network ), o VNM foi desenvolvido para também compor um modelo responsável pela orquestração de arca-bouços de processamento de big data em nuvens híbridas.
O modelo ao qual o VNM faz parte (Figura 4.4) é composto por um portal web para submissões, um mecanismo de orquestração e um executor de serviços [44].
O portal web (WCP ) é a porta de entrada do usuário da nuvem. É onde ele informa a quantidade de máquinas virtuais desejadas, o tamanho do disco virtual a ser criado para armazenar os dados carregados e os resultados que serão trabalhados nas máquinas virtuais, chaves de segurança para acesso às máquinas virtuais e dispositivos de arma-zenamento, imagens dos sistemas operacionais e configurações de rede. Após escolher propriamente as opções, o usuário envia o comando para a efetivação do processo de cria-ção do ambiente composto por máquinas virtuais, dispositivos de armazenamento, chaves
Master Worker 1 Worker 2 Worker 3 Worker n Worker 1 Worker 2 Worker 3 Worker n Master Map Shuffle Reduce
Figura 4.3: Diagrama do modelo Map/Reduce.
de segurança, sistemas operacionais e redes virtuais.
O mecanismo de orquestração (OE ), adicionado pelo WCP, prepara a área de trabalho no disco de armazenamento da nuvem privada, cria uma instância do executor de serviços (ESI ) já associado com a área de trabalho recém criada no disco de armazenamento e aciona o ESI para gerenciar a execução dos arcabouços de processamento de big data. A execução ocorre de maneira assíncrona, permitindo que o OE atenda novas submissões. Quando o OE é notificado, pelo ESI, que um processo foi terminado, essa instância é deletada, os arquivos resultantes são copiados do disco de armazenamento da nuvem para a área de trabalho do usuário e o portal web notifica o usuário que o processo está completo.
O executor de serviços (ES ) utiliza um conceito de fábrica de serviços. O OE utiliza a fábrica para criar a instância do executor de serviços responsável pela execução do arca-bouço de processamento de big data. O ESI interage com a nuvem privada monitorando o sistema e checando se é necessária a contratação de recursos extras da nuvem pública. Após o ESI decidir de onde os recursos serão obtidos, uma máquina virtual contendo o nó mestre (HM Scheduler ) do arcabouço de processamento de big data é criada, o processo para adicionar os arquivos necessários no sistema de arquivos da aplicação é executado, as máquinas virtuais contendo os nós escravos (HW ) do arcabouço de processamento de big data são criadas, os arquivos de controle que constituem o cluster são preparados e o cluster criado e, por fim, a execução do arcabouço de processamento de big data é iniciada.
Com o término da execução do arcabouço de processamento de big data, as máqui-nas virtuais da nuvem pública, caso criadas, são imediatamente removidas, os arquivos resultantes são copiados do sistema de arquivos do arcabouço de processamento de big data para o espaço de armazenamento acessível pelo OE, as máquinas virtuais da
WEB CLOUD PORTAL (WCP)
Hadoop as a Service (HaaS)
Orc hestrat ion Engine (OE) Executation Service (ES) Cloud Storage HW HW HW Virtual Networking Manager (VNM) Cloud Compute HM Scheduler Pri vate Cloud System
HW
HW Public Cloud System
Cloud Network
Cloud Engine
Figura 4.4: Modelo para gerência de arcabouços de processamento de big data.
vem privada são removidas e o OE é notificado de que o processo chegou ao fim. Além disso, o ES monitora o processamento considerando o tempo gasto na criação de todas as máquinas virtuais em todos os domínios, o tempo de preparação dos dados no sistema de armazenamento do arcabouço de processamento de big data, o tempo de execução e o tempo gasto na remoção do cluster de máquinas virtuais. Essas mudanças são informadas ao OE que, por sua vez, atualiza um repositório no disco de armazenamento da nuvem. Tal informação pode ser utilizada por escalonadores para escolher os recursos adequados para cada tipo de arcabouço de processamento de big data.
Para mover facilmente entre múltiplos domínios, é definido um modelo para configu-ração de domínios que pode ser implementado em arquivos do repositório no dispositivo de armazenamento da nuvem, gerenciado pelo OE. Nesse modelo, cada domínio deve ser identificado por atributos e classes. Os atributos de domínio são: o nome, o tipo (public-cloud, private(public-cloud, etc), o modelo de negócio (PaaS, IaaS, SaaS ), o provedor, o servidor
de endereços (DNS ), o gateway, etc.
As classes de domínio identificam classes de hosts (tipo de capacidade de CPU, me-mória, número de núcleos, etc), descrevem as imagens e identificam as configurações das máquinas virtuais, isso é, devem conter todas as informações para criar uma máquina virtual de maneira correta.
4.3
O
Virtual Networking Manager
O Virtual Networking Manager (VNM ) (Figura 4.5) é responsável pela gerência dos re-cursos das redes virtuais do sistema da nuvem, comunicando-se diretamente com seus componentes.
Os componentes do sistema da nuvem que o VNM se comunica são:
• Computing: responsável pelo aprovisionamento dos recursos físicos para a criação de máquinas virtuais e pela comunicação com o componente de networking para solicitar recursos de redes virtuais.
• Networking: responsável pela criação, modificação e remoção das redes e roteadores virtuais do sistema da nuvem.
Os componentes internos do Virtual Networking Manager (VNM ) são:
• Virtual Networking Resource Manager (VNRM ): é o componente responsável pela análise dos recursos de redes disponíveis na nuvem privada e por avaliar se é possível atender a requisição para a criação de uma rede virtual.
• Networking Allocation Manager (NAM ): é o componente responsável por receber as requisições de criação, modificação e remoção das redes virtuais do VNRM e realizar a comunicação com o componente de redes da plataforma de nuvem. • Networking Bandwidth Allocator (NBA): é o componente responsável por definir
a largura de banda das redes virtuais, atendendo as requisições para realizar as definições de largura de banda durante a criação ou modificação das redes virtuais. • Traffic Monitor (TM ): é o componente responsável por realizar o monitoramento dos recursos de redes virtuais em utilização na nuvem privada. A informação com os recursos é fornecida pelo VNRM.
Quando o processo para a criação de um cluster de máquinas virtuais é iniciado pelo ESI, ele se comunica com o VNM que fala diretamente com os componentes de rede do sistema da nuvem de maneira automatizada, sem a necessidade da intervenção do usuário. Antes de realizar a criação de uma rede virtual, o componente do VNM, Virtual Networking Resource Manager (VNRM), analisa os recursos de redes disponíveis na nuvem e avalia se é possível atender a requisição para a criação de uma nova rede. Caso haja recursos físicos disponíveis, ele se comunica com o Networking Allocation Manager (NAM) que envia a requisição para o componente Cloud Network que cria a rede virtual privada,
o roteador virtual e vincula uma conexão desse roteador virtual com a rede externa da nuvem. Criada a rede e o roteador virtuais, o NAM repassa a informação para o VNRM que armazena as informações para utilizações futuras e repassa ao ESI o estado sucesso na criação.
Após a criação da rede virtual e a vinculação do roteador virtual com a rede externa da nuvem com sucesso, o NAM faz uma requisição ao Networking Bandwidth Allocator (NBA) para alocação da largura de banda necessária para a nova rede virtual privada. Ao término desse processo, o VNRM informa os endereços da rede virtual (IPs) para o componente Cloud Compute realizar a alocação em cada máquina virtual.
Caso não haja recursos suficientes para a alocação da largura de banda requisitada, o VNRM aborta o processo e envia ao ESI a largura de banda atual disponível que, por sua vez, transmite a informação ao WCP que exibe para o usuário que a largura de banda requisitada não está disponível e sugere uma nova largura de banda para o usuário, baseada na informação do VNRM. Se o usuário aceitar a nova largura de banda proposta, o processo de criação é continuado, caso contrário, o processo é finalizado e a criação não é realizada.
O ESI então se comunica com o HM Scheduler, que é a máquina virtual do cluster rotulada como nó Mestre (Master ) do arcabouço de processamento de big data. O HM Scheduler é ligado ao volume de disco virtual que contém os arquivos a serem analisados pelo arcabouço de processamento de big data pelo modelo Map/Reduce do Hadoop e pelo Spark ou pelo sistema de compartilhamento de dados do Linux. Ele também conhece a topologia dos nós Escravos (Workers), a situação dos nós durante o mapeamento e o processamento dos trabalhos.
Durante o processo de utilização da rede virtual, o Traffic Monitor (TM) coleta in-formações de uso de cada rede virtual (com um intervalo de 60 segundos) e as fornece ao VNRM, permitindo uma melhor utilização dos recursos de redes virtuais da nuvem.
Executation Service (ES) Virtual Networking Resource Manager (VNRM)
Compute Networking Storage
Virt ual Networking Man ager (VNM)
Networ kin g Allocat ion Man ager (NAM )
Networ kin g Bandwidth Allocat or (NBA)
Traffic Monitor (TM)
Private Cloud System
Compute Networking Storage
Public Cloud System
Arquitetura do Gerenciador de Redes
Virtuais para Arcabouços de
Processamento de Big Data em Nuvens
Privadas e Híbridas
Neste capítulo iremos descrever a arquitetura implementada para a validação do nosso trabalho. Apresentaremos as plataformas de nuvens (privada e pública) que integram o modelo proposto no Capítulo 4 e o motivo de utilizá-las, o protocolo de rede para as redes virtuais, o controlador de redes virtuais e algumas políticas de qualidade de serviços.
Baseado no modelo proposto no Capítulo 4, nosso trabalho possui uma arquitetura desenvolvida em uma nuvem híbrida composta por uma nuvem privada baseada no sistema operacional de nuvens OpenStack [10], uma nuvem pública construída na plataforma para pesquisas científicas CloudLab [42], o protocolo de redes OpenFlow [38], o controlador de redes virtuais Ryu [3] e os arcabouços de processamento de big data Hadoop [51][19], Spark [17] e High Performance Analytics Toolkit [50].
A escolha do OpenStack foi baseada em sua utilização pela comunidade científica, engajamento de grandes empresas e constante evolução de sua plataforma operacional [2][53][25]. A constante evolução do OpenStack provê mais de uma versão com atualizações de funcionalidades e correções de bugs lançadas a cada ano (atualmente duas) [11].
Composto por vários componentes, o OpenStack possui um componente responsável pelas redes virtuais da nuvem. Chamado de Neutron [6], ele fornece uma API que permite a construção de topologias de redes, compostas pelas camadas 2 e 3 como: MAC, IPv4, IPv6, TCP, UDP, ICMP, entre outros.
O Neutron também possibilita a implementação de qualidades de serviços para redes (QoS ) tais como controle de fluxo e largura de banda na forma de recursos adicionais para os usuários finais da nuvem.
Com as possibilidades de integração que a API do Neutron nos permite, nós adicio-namos o protocolo OpenFlow [38] juntamente com um controlador de redes definidas por software (SDN). O controlador SDN foi escolhido com base na maturidade dos diversos controladores encontrados na literatura [36]. Além da maturidade, também avaliamos sua compatibilidade com o OpenStack e sua utilização perante a comunidade científica.
O CloudLab é um projeto para construção de nuvens voltado para a comunidade acadêmica e científica [42]. Parte de um ambiente que inclui projetos como GENI [30] e Emulab [33], ele provê acesso à hardwares e controle sobre um conjunto substancial de recursos de computação, armazenamento e redes.
O protocolo OpenFlow nos permite adicionar uma maior inteligência nas redes e con-troladores virtuais da nuvem, ao mesmo tempo que a adição do controlador SDN nos permite monitorar e gerenciar os recursos das redes como a largura de banda, tráfego dos pacotes e mudanças na topologia de um cluster de máquinas virtuais.
O controlador SDN escolhido é chamado Ryu [3]. Desenvolvido em Python, ele é um framework para redes definidas por software que provê uma API para gerenciamento de redes. O Ryu é descrito com mais detalhes na seção de conceitos básicos.
A Figura 5.1 ilustra o diagrama da arquitetura implantada para este trabalho.
Executation Service (ES) Virtual Networking Resource Manager (VNRM)
Nova Neutron Cinder/Swift
Virt ual Networking Man ager (VNM )
Networ kin g Allocat ion Man ager (NAM )
Networ kin g Bandwidth Allocat or (NBA)
Traffic Monitor (TM)
Private Cloud System
Ryu
Public Cloud System
Nova Neutron Cinder/ Swift
Figura 5.1: Arquitetura do Gerenciador de Redes Virtuais (Virtual Networking Manager ).
5.1
Integração dos componentes do
Virtual
Networ-king Manager com a plataforma da nuvem
Com base no modelo do Capítulo 4, os componentes do Virtual Networking Manager se comunicam com a plataforma da nuvem da seguinte forma.
O Virtual Networking Resource Manager (VNRM) se comunica diretamente com o componente de rede da plataforma de nuvem, o Neutron. Por sua vez, o Neutron se comunica com o Ryu, o controlador de redes virtuais. Na fase inicial da descoberta dos recursos de rede da nuvem, a comunicação é feita para obter a topologia de rede, a rota entre os roteadores virtuais e a largura de banda das redes física e virtuais.
O VNRM mantém informações das redes física e virtuais da plataforma da nuvem, dos roteadores virtuais e da largura de banda das redes virtuais. O Neutron se comunica diretamente com o protocolo OpenFlow, que realizará o encaminhamento dos pacotes pelas redes e roteadores virtuais. Caso alguma mudança aconteça na topologia de uma rede existente, ou uma nova rede seja criada, o VNRM atualiza suas informações, o Neutron aplica as alterações e o Ryu obtém e processa as informações necessárias para atualizar suas tabelas de roteamento.
Como descrito na seção 4.3 do Modelo para Gerenciar Redes Virtuais para Arcabouços de Processamento de Big Data, o VNRM é o componente responsável pelo monitoramento dos recursos físicos da nuvem e do gerenciamento dos recursos que serão utilizados pelo Networking Allocation Manager (NAM) para a criação das redes e roteadores virtuais na nuvem privada. Além disso, ele também utiliza informações das redes virtuais existentes na nuvem privada providas pelo Traffic Monitor (TM) e pelo Networking Bandwidth Allocator (NBA) para aprimorar a utilização das redes virtuais e permitir um melhor desempenho.
Para realizar a criação das redes virtuais na nuvem privada, as informações necessá-rias são fornecidas pela instância do Execution Service (ESI). O VNRM, que já possui informações dos recursos físicos da nuvem, passa a requisição para o NAM que se co-munica com o Neutron. O Neutron então envia a requisição para o agente Layer 3 (L3 agent) para dar inicio ao processo de reserva e criação da rede virtual com a faixa de IPs necessária, a criação do roteador virtual e alocações de suas portas, conforme solicitado pelos componentes do VNM.
Realizada a criação da rede e roteador virtuais na nuvem privada, da definição da faixa de IPs e alocações de portas do roteador virtual, o NAM informa o estado do processo ao NBA que faz a requisição da definição da largura de banda da rede virtual recém criada para o Neutron, que utiliza seu agente de qualidade de serviço (QoS agent) para proceder com a alocação da banda. Feita a alocação da largura de banda para a nova rede virtual, o NAM é informado e, por sua vez, libera a informação dos endereços de rede que serão alocados às máquinas virtuais no processo de criação para o ESI. O ESI então envia a requisição ao Nova que adiciona (attach) os IPs nas máquinas virtuais e inicia o processo de aprovisionamento do cluster.
A Figura 5.2 exibe a integração do gerenciador de redes virtuais para arcabouços de processamento de big data com o OpenStack.
WEB CLOUD PORTAL (WCP)
Hadoop as a Service (HaaS)
Orc hestrat ion Engine (OE) Executation Service (ES) Cinder/ Swift HW HW HW Virtual Networking Manager (VNM) Nova HM Scheduler Pri vate Cloud System
HW
HW Public Cloud System
Neutron
OpenStack Engine
Figura 5.2: Integração do gerenciador de redes virtuais para arcabouços de processamento de big data com o OpenStack.
Durante a utilização da rede virtual, o Traffic Monitor (TM ) realiza o monitoramento dos recursos da rede virtual em questão de tempos em tempos (no processo de criação de uma nova rede ou de modificação de uma rede) e repassa as informações para o VNRM, que se mantém atualizado sobre os recursos físicos e virtuais da nuvem.
Após o término da execução dos trabalhos no cluster, no momento do processo de remoção das máquinas virtuais, a rede e o roteador virtual também são removidos e o VNRM é notificado para realizar a atualização das informações referentes aos recursos físicos da nuvem para atender novas requisições para redes virtuais.
