Seção: Tutoriais Infraestrutura
|
|
||
Nesta seção são apresentadas questões mais específicas do projeto e da implementação de serviços IaaS em operadoras de telecomunicações. Para tanto, definem-se os principais requisitos que um provedor IaaS deve atender, qual a arquitetura funcional de um provedor IaaS e, em seguida, qual a infraestrutura de rede necessária e como essa nuvem é operacionalizada.
Principais Requisitos
As características essenciais da computação em nuvem e dos modelos de serviço exigem que os provedores de serviços atendam alguns requisitos a fim de que os usuários possam usufruir plenamente da experiência na nuvem. A definição desses requisitos terá impacto em decisões arquiteturais no projeto de implementação de IaaS em um provedor de serviços.
Para cada modelo de serviço, diferentes requisitos devem ser atendidos. Como proposto por Rimal (Rimal, Jukan, Katsaros, & Goeleven, 2011), os principais requisitos que devem ser atendidos pelos provedores de serviços de IaaS são:
Arquiteturas da Nuvem
Genericamente, a Nuvem pode ser considerada como um grande datacenter que provê capacidade para elasticidade, recursos sob demanda e faturamento baseado na quantidade de uso (Sridhar, 2009). A arquitetura de um datacenter geralmente segue a arquitetura canônica ilustrada pela figura 3 (Benson, Akella, & Maltz, 2010). Nessa arquitetura, composta de três camadas, os servidores estão conectados a switches – chamados de switch Top of Rack (TOR), que conectam os servidores à estrutura de rede do datacenter. Os switches TOR, por sua vez, estão conectados por um ou mais links a um switch de agregação – chamado de switch End of Row (EOR). Os switches EOR são utilizados para conectividade entre servidores de diferentes racks. Os switches da camada de agregação são, então, conectados a roteadores (ou mesmo switches) para conectividade com o ambiente externo ao datacenter.
Figura 3: Arquitetura canônica de datacenters
Apesar dessa topologia canônica, a escolha da topologia de rede e do tipo de interconectividade entre os servidores depende dos requisitos que devem ser atendidos pelo datacenter. Empresas, provedores de serviço e fabricantes de equipamentos seguem algumas diretrizes sobre onde usar comutação (protocolos de camada 2 – L2) ou roteamento (protocolos de camada 3 – L3) em suas redes (Sridhar, 2009). Atualmente, existem três abordagens principais para redes que provêm IaaS: abordagem L2, abordagem L3 e a abordagem L2oL3 (virtualização de redes, “L2 over L3”).
Projetos de rede de camada 3 (L3) têm como principal característica sua escalabilidade (a Internet, por exemplo, é baseada no protocolo IP, de camada 3). Por outro lado, projetos de camada 2 (L2) têm vários problemas de escalabilidade (Tu, 2011), entretanto são menos complexos que os de camada 3. A maioria dos datacenters empresariais seguem princípios de projeto L2, enquanto a maioria dos provedores de Internet (ISP) e grandes datacenters usam o modelo L3 (CloudScaling, 2010).
Datacenter L2
O protocolo de camada 2 Ethernet é atualmente uma das tecnologias de redes locais em diversos ambientes, incluindo redes empresariais, acadêmicas e datacenters (Tu, 2011). Sua principal característica é a facilidade de configuração e entendimento do funcionamento. Em um ambiente Ethernet, cada dispositivo tem um endereço global único. Ao mover um dispositivo para um local físico diferente, dentro da mesma rede, o endereço Ethernet indicará onde o dispositivo pode ser encontrado. Ou seja, o endereço IP (Internet Protocol) não precisa ser alterado. Por consequência, os switches devem manter uma tabela de encaminhamento para todos os dispositivos da rede.
Uma característica importante do protocolo Ethernet é o uso de broadcasting. Os protocolos Address Resolution Protocol (ARP) (Plummer, 1982) e Dynamic Host Configuration Protocol (DHCP) (Droms, 1997), por exemplo, utilizam pacotes broadcast para descobrir o endereço IP de destino e obter as configurações de endereço IP, respectivamente.
A necessidade de manter as informações sobre a localização de todos os dispositivos na rede e a utilização do modelo broadcast em alguns serviços limitam a escalabilidade do protocolo Ethernet. Para lidar com esse problema de escalabilidade, uma solução é dividir a rede em diversos domínios L2 e interconectá-los utilizando um roteador IP (L3), que também é utilizado para conexão com a Internet. A figura 4 ilustra essa topologia.
Figura 4: Arquitetura de um datacenter L2
Em cada domínio L2 dessa topologia, todos os dispositivos aparentam ser locais, ou seja, o switch TOR e os switches virtuais são transparentes para as máquinas virtuais. Isso significa que não é necessária nenhuma configuração ao mover uma máquina virtual entre servidores localizados racks diferentes, mas no mesmo domínio L2.
A existência de loops em uma topologia L2 pode gerar um problema chamado tempestade de broadcast e que o protocolo Spanning Tree Protocol (STP) tenta resolver. Entretanto, como o STP bloqueia links para evitar os loops, técnicas de balanceamento de carga, como o Equal Cost Multi-Pathing (ECMP) (Thaler & Hopps, 2000), não podem ser utilizadas e a maior parte do tráfego seguirá o caminho mais longo dentro da árvore gerada pelo STP.
Apesar dos problemas, grandes provedores de serviços em nuvem tentam utilizar redes L2 para prover serviços em nuvem, provendo uma rede L2 virtual para cada cliente, o que não resolve os problemas de escalabilidade (CloudScaling, 2010).
Datacenter L3
A principal característica de redes L3 é a sua capacidade de operar em grande escala. A Internet é uma prova da escalabilidade de redes L3. Essa capacidade se dá por características como agregação de rotas, esquema de endereçamento hierárquico e armazenamento somente do que é necessário para decidir se o destino dos dados é local ou remoto. Desta maneira, cada elemento em uma rede L3 pode tomar decisões relativamente simples dentro de um pequeno conjunto de dados. Enquanto isso, os elementos em redes L2 necessitam ter conhecimento de todos os elementos que fazem parte da rede. A figura 5 ilustra como redes L3 funcionam como datacenters na nuvem (CloudScaling, 2010). Cada nó na infraestrutura pode agir de duas formas: como um roteador e tem informação necessária somente para tomar decisões de roteamento local; ou, se necessário, repassando os dados para a próxima camada.
Figura 5: Arquitetura de um datacenter L3
Nessa arquitetura, cada servidor virtual está diretamente conectado apenas ao seu default gateway – neste caso, o próprio nó (servidor) físico, que contém um roteador virtual – e cada servidor virtual tem sua rede L2 exclusiva onde nenhum outro servidor virtual pode coexistir. Por este fato, o tráfego broadcast torna-se impossível e aplicações que fazem suposições sobre outros servidores localizados no mesmo domínio L2 podem não funcionar corretamente.
A agregação de rotas permite que redes L3 sejam escaláveis. Na figura 5, por exemplo, os roteadores do núcleo têm rotas para apenas um reduzido número de redes que apontam para a próxima camada (camada de agregação). Os roteadores de agregação têm informações sobre as redes em cada rack que apontam para o switch TOR, mas possivelmente não sabem onde cada servidor virtual está localizado dentro de cada rack. E os switches TOR, finalmente, têm a informação sobre qual servidor possui as redes onde estão localizados os servidores virtuais.
Redes L3 também permitem o uso de balanceamento de carga com ECMP, que habilita o uso de múltiplos caminhos simultaneamente entre dois pontos, permitindo o uso mais eficiente da rede. Além disso, redes L3 geralmente utilizam protocolos de roteamento – como o Open Shortest Path First (OSPF) (Moy, 1998) e o Intermediate System to Intermediate System (IS-IS) (Oran, 1990) – baseados no algoritmo Shortest Path First (SPF) (Dijkstra, 1959), o que significa que os dados percorrerão sempre o caminho mais curto até o seu destino, aumentando também a eficiência da rede.
A principal desvantagem das redes L3 é o fato de que, diferentemente das redes L2, não é possível mover um dispositivo de uma rede L3 para outra sem necessidade de fazer alterações de configuração. Mover um servidor de lugar implica mudar seu endereço IP para um endereço da nova rede.
Datacenter L2oL3
As abordagens de virtualização de redes tentam unir as abordagem L2 e L3. Essas abordagens tentam superar os problemas de escalabilidade de redes L2 criando redes L2 virtuais sobre uma infraestrutura L3. Dessa maneira, os clientes podem ter quantas redes L2 quiserem e interconectadas à sua maneira, enquanto a infraestrutura física segue uma abordagem L3.
A figura 6 ilustra a topologia de um datacenter com virtualização de redes. Uma máquina virtual (VM) pode ter conectividade L2 com outra VM localizada em um servidor físico diferente utilizando um túnel sobre a rede L3, criando assim um domínio Ethernet virtualizado.
Figura 6: Arquitetura de um datacenter L2oL3
Por ser uma tecnologia recente, ainda não existe um padrão utilizado e existe uma variedade de maneiras de implementar virtualização nos datacenters como, por exemplo, Network Virtualization using Generic Routing Encapsulation (NVGRE) (Sridharan, et al., 2011), Virtual Distributed Ethernet (VDE) (Davoli, 2004), OpenFlow (McKeown, et al., 2008) e Virtual eXtensible LAN (VXLAN) (Mahalingam, et al., 2002).
A Nuvem Telecom
As operadoras de telecomunicações possuem uma vantagem natural em relação a outros provedores de serviços: a rede. A capilaridade das redes das operadoras permite que os datacenters possam ser distribuídos geograficamente e, assim, criar vantagens competitivas ao oferecer melhores qualidades de serviços, latência e largura de banda. A figura 7 ilustra uma arquitetura em que as operadoras podem potencializar suas redes para se tornarem plataformas diferenciais no mercado de computação em nuvem. A arquitetura tem como princípio a combinação das infraestruturas de rede e processamento de um datacenter para interagir perfeitamente com as redes de serviço ópticas e de pacotes das operadoras.
Figura 7: Nuvem Telecom [adaptado de (Alcatel-Lucent; Hewlett-Packard, 2011)]
Essa arquitetura permite que as operadoras ofereçam seus serviços a partir de datacenters centrais ou distribuídos, baseando-se no modelo econômico com o melhor custo-benefício. Ao distribuir seus datacenters, a operadora pode escolher prover determinados serviços a partir de um lugar mais próximo dos clientes. Devido a essa proximidade, datacenters distribuídos têm perfis de latência mais baixos por aplicação e por serviço do que os que são oferecidos de maneira centralizada, longe dos clientes. Aplicações como desktops virtuais, jogos online e distribuição de vídeo são intrinsecamente afetadas pela latência da rede e podem consumir grande porcentagem dos recursos da rede com o crescimento do número de usuários; datacenters distribuídos ajudam a diminuir esse impacto na rede.
Uma camada de gerenciamento, que combina os controles de rede, armazenamento, processamento e aplicações, torna-se necessária para automatizar e otimizar a distribuição de recursos e qualidade de experiência (QoE) dos usuários e realizar o monitoramento e gerenciamento da latência e largura de banda dos serviços.
A arquitetura do datacenter é dividida em blocos de processamento. Cada bloco contém elementos típicos de um datacenter com elementos de processamento, armazenamento e rede. Os blocos podem ser ajustados em relação à capacidade para se adaptarem aos ambientes onde serão instalados, seja um pequeno datacenter regional ou um datacenter centralizado com maior capacidade. Os blocos de processamento seguem a infraestrutura ilustrada pela figura 8.
Figura 8: Bloco de processamento [adaptado de (Alcatel-Lucent; Hewlett-Packard, 2011)]
Cada bloco é dividido em quatro camadas funcionais: processamento e dados, acesso, núcleo e interconexão de datacenter. As três primeiras camadas focam em operações intra-datacenter. O último bloco consiste de roteadores para realizar a comunicação entre datacenters (blocos de processamento) e também realizar a conexão das VPNs dos clientes com os serviços oferecidos pelo datacenter.
|