Criando uma nuvem empresarial com a F5 e a IBM

Introdução

Segundo algumas estimativas, a nuvem empresarial — também conhecida como nuvem privada — está sendo adotada mais rapidamente do que a nuvem pública. A consultoria empresarial Accenture estima que a adoção da nuvem privada pelas empresas chegará a 77% até o final de 2011.¹  Grande parte desse rápido movimento para criar uma infraestrutura local ágil decorre da necessidade dos departamentos de TI de empresas de todos os portes de manter internamente o controle e o gerenciamento tanto da infraestrutura quanto dos dados.

Uma vez tomada a decisão de adotar uma infraestrutura de nuvem, a escolha entre uma nuvem interna/privada e uma externa/pública se resume a uma análise de custo, risco e valor. Uma nuvem pública geralmente oferece uma abordagem flexível e a maior economia de custos; no entanto, ela apresenta riscos relacionados à segurança, aos acordos de nível de serviço (SLAs), à disponibilidade e ao gerenciamento. A TI pode aproveitar uma escalabilidade praticamente ilimitada com baixo custo inicial, mas abre mão do controle. Migrar de um data center tradicional, local ou hospedado, para uma nuvem pública externa é basicamente como colocar todo o seu data center nas mãos de terceiros.

Com uma nuvem empresarial, a TI tem o nível de controle necessário e evita os riscos associados a uma nuvem pública; no entanto, a implantação de uma nuvem privada é mais cara, exige níveis adicionais de conhecimento e especialização da equipe e aumenta a complexidade do data center local. A infraestrutura de nuvem empresarial pode ser dimensionada conforme necessário e oferece provisionamento dinâmico e agilidade, mas essa escalabilidade e esse controle geralmente implicam um custo inicial mais alto.

Juntas, a F5 Networks® e a IBM desenvolveram uma arquitetura de referência para a nuvem empresarial que reduz muitos dos desafios associados à complexidade. Ela incorpora ao ambiente local muitos dos componentes de arquitetura e escalabilidade de uma nuvem pública, reduzindo significativamente o custo de criação de um sistema interno fragmentado. Ao predefinir os componentes necessários e descrever como eles funcionam em conjunto, a F5 e a IBM criaram uma infraestrutura de nuvem empresarial completa, dinâmica e ágil.

Fluxo de trabalho

O elemento mais importante de um sistema de provisionamento sob demanda é a capacidade de tomar decisões e agir com base em eventos. Um evento em algum ponto do sistema gera um alerta ou uma mensagem, que é recebida por um componente (seja um componente inscrito no barramento de mensagens ou acionado diretamente por meio de uma chamada de API), que então age com base nessa mensagem. O fluxo de trabalho é o processo e a ordem em que os componentes agem com base nas mensagens do sistema.

Em uma nuvem corporativa, o fluxo de trabalho normalmente é dividido entre os componentes de provisionamento que solicitam ou liberam recursos e as etapas necessárias para gerenciar a alocação desses recursos. Quando uma máquina virtual (VM) precisa de recursos adicionais de CPU, um fluxo de trabalho é iniciado para determinar de onde virão esses recursos, iniciar uma nova VM, alocar um endereço IP e assim por diante.

Arquitetura do fluxo de trabalho

A arquitetura de nuvem empresarial da F5 e da IBM baseia-se em dois princípios fundamentais:

1. Há um barramento de mensagens centralizado usado para transportar mensagens de notificação de eventos, e todos os componentes que precisam agir em resposta a eventos estão conectados a esse barramento.
   

Arquitetura de referência em nuvem.

Além desses dois princípios, a arquitetura de referência da F5 e da IBM é extremamente flexível, o que significa que pode se adequar a qualquer arquitetura existente de data center ou nuvem. Se já houver um mecanismo de orquestração para gerenciar a implantação de máquinas virtuais, por exemplo, essa arquitetura de referência poderá ser adaptada para utilizar o mecanismo existente. Um equívoco comum em relação à criação de uma nuvem empresarial é acreditar que toda a infraestrutura precisa ser substituída; a solução da F5 e da IBM foi criada para se integrar aos componentes existentes em todas as etapas possíveis.

Componentes do fluxo de trabalho

Independentemente de quais componentes já existam e quais sejam novos, o fluxo de trabalho da nuvem empresarial é composto por componentes específicos que executam tarefas específicas. Todo o sistema de nuvem é formado por esses componentes individuais, que trabalham em conjunto para fornecer a infraestrutura de nuvem completa. Essa infraestrutura é operada e controlada por meio de fluxos de trabalho de componentes — tarefas coordenadas que gerenciam um evento na nuvem.

Barramento de mensagens

O barramento de mensagens é o sistema que encaminha mensagens baseadas em eventos e alertas para cada componente afetado. Quando um evento dispara uma mensagem, ela é enviada pelo barramento de mensagens a um componente específico, que possui regras sobre como processá-la. O barramento de mensagens também é responsável por normalizar as mensagens com base nas regras de componentes específicos.

A arquitetura de nuvem de referência da F5 e da IBM usa a solução IBM Tivoli Netcool OMNIbus como barramento central de mensagens; no entanto, qualquer barramento de mensagens corporativo pode ser usado para transmitir notificações de eventos por todo o sistema.

Orquestrador

O orquestrador pode ser considerado o cérebro da nuvem empresarial — o componente responsável por tomar a maioria das decisões de provisionamento em nível macro com base nas mensagens recebidas pelo barramento. O orquestrador dará início aos principais eventos e fluxos de trabalho na arquitetura de nuvem, como iniciar o fluxo de trabalho de “provisionamento de uma nova máquina virtual”. O orquestrador também é responsável por buscar os dados necessários para cada fluxo de trabalho e fornecê-los aos componentes pertinentes. Por exemplo, ele forneceria as informações de endereço IP necessárias para provisionar uma nova máquina virtual.

Para a arquitetura de referência, o orquestrador é criado usando uma série de scripts interpretados que processam mensagens do barramento e iniciam eventos de fluxo de trabalho. Pode ser usado qualquer tipo de orquestrador, como IBM Tivoli Intelligent Orchestrator, HP Operations Orchestration ou VMware vCenter Orchestrator.

Controlador de Nuvem

O controlador de nuvem é o sistema de front-end responsável por coletar e agregar os dados preliminares necessários para iniciar um processo de provisionamento. Inicialmente, essas informações são fornecidas por um administrador como parte do processo de criação e são específicas para cada tipo de fluxo de trabalho usado no provisionamento. Por exemplo, o controlador de nuvem coleta informações que incluem a localização da VM, a classe do aplicativo (servidor web, servidor de banco de dados, servidor de e-mail etc.) e os requisitos mínimos de recursos.

Durante um evento de provisionamento automatizado, depois que esses dados preliminares já tiverem sido armazenados no sistema, o orquestrador solicita e extrai as informações existentes para iniciar o fluxo de trabalho de provisionamento. Alguns exemplos de controladores de nuvem são o Eucalyptus Cloud Controller, o VMware vCloud Director e o Amazon EC2. Para possibilitar o crescimento futuro e a expansão para outras plataformas de nuvem, é recomendável escolher um controlador de nuvem que possa se integrar ou se comunicar com um conjunto padrão de APIs de nuvem. Isso permite estender o controlador de nuvem a um provedor de nuvem pública ou híbrida sem a necessidade de reprojetar a arquitetura da plataforma de nuvem empresarial.

Controlador de cluster/hipervisor

O controlador de cluster é o componente da nuvem corporativa responsável por gerenciar a máquina virtual que está sendo provisionada, bem como o armazenamento e os metadados necessários para executar a VM. Como ambiente de execução da VM, o controlador de cluster inclui o hipervisor da plataforma virtual e também pode incluir um ambiente mais amplo de gerenciamento de hipervisores. Por exemplo, o controlador de cluster pode ser um hipervisor básico, como o VMware ESXi, ou um conjunto maior de sistemas de hipervisor distribuídos, como o VMware vSphere ou o VMware vCloud.

Monitoramento

O monitoramento da integridade e do status é um elemento essencial de qualquer implantação de aplicações empresariais. O monitoramento também fornece atualizações de status aos sistemas de provisionamento, por exemplo, quando uma máquina virtual está em execução e respondendo a conexões na rede. O monitoramento contínuo do sistema pode fornecer alertas em tempo real que, em última análise, alimentam novos fluxos de trabalho e afetam as decisões de provisionamento. Qualquer componente capaz de monitorar o status das aplicações e da rede pode ser usado na implantação da nuvem empresarial; no entanto, o software IBM Tivoli Monitoring é usado na arquitetura de referência da F5 e da IBM.

DNS

O Sistema de Nomes de Domínio (DNS) desempenha um papel fundamental na arquitetura de referência de nuvem corporativa da F5 e da IBM: ele é responsável por armazenar não apenas as informações de endereços IP e nomes de domínio para IPv4 e IPv6, mas também metadados do sistema, como as informações coletadas pelo controlador de nuvem e os dados de identificação exclusiva das máquinas. Para essa arquitetura de referência, o DNS foi escolhido como local de armazenamento de metadados por ser um sistema baseado em padrões que já existe na maioria das redes, estar disponível para todos os componentes da nuvem e eliminar a necessidade de adicionar à infraestrutura um armazenamento adicional do tipo banco de dados. Pode ser usada qualquer solução de DNS gerenciada pela equipe de TI que permita adicionar outras zonas e arquivos de zona.

Armazenamento

Na arquitetura de referência da F5 e da IBM, o controlador do cluster executa a máquina virtual a partir do armazenamento local; no entanto, quando ela não está em execução, o disco virtual da VM fica no armazenamento virtualizado. Durante um evento de provisionamento do fluxo de trabalho, o controlador do cluster solicitará o disco virtual ao dispositivo de armazenamento virtual por meio do Network File System (NFS).

Controlador de Entrega de Aplicações

O último componente da nuvem corporativa é o Controlador de Entrega de Aplicações (também chamado de balanceador de carga), que, na arquitetura de referência da F5 e da IBM, é o F5® BIG-IP® Local Traffic Manager™ (LTM). BIG-IP LTM gerencia conexões, serviços e a entrega dos dados da aplicação provenientes da máquina virtual. Em última análise, BIG-IP LTM é a parte final do sistema que atua em um evento de provisionamento do fluxo de trabalho.

Passo a passo: provisionamento manual e automatizado

O objetivo da arquitetura de referência de nuvem empresarial da F5 e da IBM é fornecer uma plataforma baseada em recursos e aplicável ao mundo real para a implantação dinâmica de aplicações. Depois que todos os componentes estiverem implementados, eles trabalharão em conjunto — por meio de diversos fluxos de trabalho — para provisionar novos serviços de aplicações conforme necessário. Há duas maneiras de provisionar os sistemas implementados na nuvem empresarial: provisionamento manual e provisionamento automatizado.

Provisionamento manual

Normalmente, o primeiro fluxo de trabalho na nuvem corporativa é iniciado por meio de um processo manual, com base nas informações fornecidas pelo administrador do sistema ou pelo solicitante da aplicação. Isso não significa que o fluxo de trabalho seja manual; apenas a inserção inicial das informações no sistema é feita manualmente. Depois que os dados são coletados junto ao administrador, o sistema inicia eventos automatizados e predefinidos do fluxo de trabalho para o provisionamento da aplicação.

Etapa 1: entrada de dados no controlador de nuvem

Usando a interface gráfica do controlador de nuvem, o administrador (ou o solicitante da aplicação, dependendo de quem é responsável por iniciar um novo evento de provisionamento) insere as informações necessárias para criar uma nova máquina virtual e colocar uma aplicação em operação. Essas informações geralmente consistem em dados de infraestrutura de alto nível, como:

• Tipo de aplicativo: uma lista predefinida de tipos de aplicativos disponíveis, como Microsoft SharePoint, servidor Web, servidor de e-mail, banco de dados Oracle etc.
• Informações de rede: endereço IP do cluster, URL de front-end, se este aplicativo será acessível publicamente ou apenas internamente etc.
• Informações de provisionamento: quaisquer informações adicionais necessárias para o sistema de provisionamento, como a localização da rede (geralmente uma referência geográfica vinculada a um data center físico, por exemplo, “Europa – Data Center de Copenhague”) e quaisquer restrições quanto ao número mínimo e máximo de instâncias permitidas de um determinado tipo de aplicação.

Essas informações são usadas como metadados para o provisionamento automatizado em toda a nuvem corporativa.

Etapa 2: Inicie o fluxo de trabalho de provisionamento; distribua os metadados

Depois que o administrador envia os dados necessários, a próxima etapa é o controlador de nuvem empacotar essas informações — juntamente com um ID de instância exclusivo, criado dinamicamente e usado em todo o sistema para identificar essa instância durante o provisionamento, como “vm12345” — e distribuí-las ao orquestrador por meio do barramento de mensagens.

Todas as informações fornecidas durante a primeira etapa são normalizadas pelo barramento de mensagens antes de serem entregues ao orquestrador.

Paralelamente, o controlador de nuvem fornece os mesmos metadados e o ID exclusivo da instância ao hipervisor, por meio de uma API, e o instrui a implantar a imagem de aplicação necessária. Esse evento faz com que o hipervisor solicite ao armazenamento baseado em nuvem a imagem de disco da máquina virtual correspondente. O dispositivo de armazenamento recupera a imagem de disco apropriada via NFS e começa a copiá-la para o armazenamento local.

Etapa 3: o orquestrador distribui os metadados

Depois que o orquestrador recebe do barramento de mensagens as informações normalizadas do evento e os metadados, ele inicia dois fluxos de trabalho distintos que enviam simultaneamente os metadados para o(s) sistema(s) de monitoramento e para o DNS. O(s) sistema(s) de monitoramento usam essas informações para configurar uma programação de monitoramento automatizado para a aplicação e começam a monitorá-la após receberem a notificação de que ela está em execução. Durante essa etapa, o orquestrador também define limites para os eventos do sistema de monitoramento — por exemplo, instruindo o monitor a enviar uma notificação de evento quando a utilização da CPU dessa instância virtual ultrapassar 75%.

O orquestrador também envia os metadados da instância virtual para o DNS, onde esses dados são armazenados para uso em toda a nuvem corporativa. O orquestrador é responsável por enviar os metadados no formato adequado da zona DNS; portanto, ele deve criar nomes de domínio com base no ID da instância, criar registros DNS IPv4 e IPv6, adicionar informações da instância provenientes do controlador de nuvem e incluir as informações da nova instância na zona apropriada. Por exemplo, o orquestrador usará o ID exclusivo da instância, criará uma entrada DNS para “vm12345.vm.cloud.example.com” e a adicionará à zona example.com existente.

A etapa final da distribuição de metadados por toda a nuvem corporativa é preencher o controlador de entrega de aplicações BIG-IP LTM com as informações da nova instância, como nome do host, endereço IP, tipo de aplicação (ou pool no BIG-IP LTM) e informações de monitoramento.

Etapa 4: Notificação da máquina virtual

Na etapa 2, o controlador de nuvem instruiu o hipervisor a iniciar a máquina virtual associada à instância recém-provisionada. Assim que essa VM estiver em execução conforme o esperado e disponível para conexões, ela notificará o orquestrador por meio de um alerta de evento no barramento de mensagens. O orquestrador receberá esse alerta de evento e iniciará um fluxo de trabalho que instruirá o BIG-IP LTM a marcar a nova VM como disponível no pool e a começar a encaminhar e distribuir novas conexões para a instância virtual com base no método de balanceamento de carga. O BIG-IP LTM também começará a monitorar a nova instância usando o monitor de aplicação previamente configurado e atribuído ao pool de aplicações.

O alerta de evento da VM recém-iniciada também fará com que o orquestrador notifique o sistema geral de monitoramento da nuvem corporativa para que comece a monitorar a instância virtual. Nesse momento, a instância virtual recém-provisionada estará em execução na nuvem corporativa e processando solicitações de serviços de aplicativos. Esse é o modo de operação normal de todos os serviços que fazem parte da nuvem corporativa.

Provisionamento automatizado

O provisionamento manual é a primeira etapa do fluxo de trabalho para provisionar serviços na nuvem corporativa, mas não é a forma mais frequente de provisionamento. Em um sistema que funciona sem problemas, a nuvem corporativa evolui para um sistema de automonitoramento mais dinâmico e fluido, provisionando automaticamente novos serviços conforme a necessidade e a demanda. Esse provisionamento automático ágil está no centro de qualquer plataforma de nuvem e exige eventos e fluxos de trabalho adicionais de provisionamento automatizado para monitorar e responder a eventos em tempo real.

Etapa 1: Monitoramento e alertas

A primeira etapa de qualquer sistema de provisionamento automático é o monitoramento: coletar e detectar eventos em todo o sistema. Durante a primeira rodada de provisionamento manual, os sistemas de monitoramento foram alimentados com informações sobre as instâncias virtuais, como nome, localização, tipo de monitoramento e limites de eventos. Essas informações são usadas para monitorar automaticamente a disponibilidade e o desempenho das aplicações e das instâncias virtuais. Quando um evento — por exemplo, uma determinada instância virtual consumindo mais de 75% dos recursos de CPU disponíveis — é detectado pelo sistema de monitoramento, ele gera um evento no barramento de mensagens que alerta o orquestrador sobre o esgotamento dos recursos.

Etapa 2: Coleta de dados

Em um cenário típico de provisionamento automatizado, o orquestrador é responsável por criar uma nova instância virtual que ajudará a reduzir a carga de recursos na instância atual. Duas ou mais instâncias virtuais serão usadas para distribuir as cargas de processamento e de rede da aplicação.

Para iniciar um fluxo de trabalho de provisionamento automatizado, o orquestrador deve ser responsável por coletar eventos dos componentes, bem como por solicitar os metadados necessários para provisionar uma nova instância virtual. Na arquitetura de referência da F5 e da IBM, os metadados são armazenados no DNS e preenchidos como parte do fluxo de trabalho original de provisionamento manual. O DNS retornará ao orquestrador informações como, por exemplo, o tipo de aplicação, a localização geográfica e os limites de provisionamento.

Etapa 3: Iniciando o fluxo de trabalho

Na etapa final de um fluxo de trabalho de provisionamento automatizado, o orquestrador envia os metadados obtidos do DNS ao controlador de nuvem por meio do barramento de mensagens. Essencialmente, essa etapa automatizada simula o momento em que um administrador insere as informações da máquina e inicia manualmente o fluxo de trabalho de provisionamento. O controlador de nuvem recebe essas informações (da mesma forma que as receberia do administrador no provisionamento manual) e inicia um novo fluxo de trabalho de provisionamento de instância virtual. A partir desse ponto, as etapas e os fluxos de trabalho de provisionamento detalhados acima são repetidos até que a nova instância virtual esteja ativa, em execução e aceitando novas conexões.

Uma implantação típica de nuvem empresarial incluirá fluxos de trabalho de provisionamento manuais e automatizados. Novos serviços ou aplicações serão inicialmente implantados por meio de um fluxo de trabalho manual, para que um administrador possa controlar como e onde o serviço será implantado. Depois que um serviço estiver em funcionamento, os fluxos de trabalho de provisionamento automatizados gerenciarão o provisionamento com base nas necessidades e na disponibilidade de recursos.

Conclusão

A opção por implantar uma nuvem corporativa privada não deve resultar em maior complexidade nem em problemas de interoperabilidade. O objetivo de qualquer implantação de nuvem é reduzir as barreiras à criação de novos serviços e oferecer uma infraestrutura de computação mais ágil. Uma nuvem corporativa leva essa agilidade ao data center, melhorando significativamente a capacidade de gerenciamento e o controle.

Em parceria com a IBM, a F5 criou uma arquitetura de referência para uma nuvem empresarial com provisionamento automático. Essa arquitetura foi projetada para ser modular e flexível, permitindo que os componentes existentes sejam integrados conforme necessário e que toda a nuvem empresarial seja conectada a qualquer outra plataforma de nuvem por meio de APIs e de uma infraestrutura de mensagens compartilhada. Nenhuma nuvem empresarial privada é exatamente igual a outra; no entanto, a arquitetura da F5 e da IBM se adapta a diferentes ambientes, levando os benefícios de uma infraestrutura ágil a qualquer implantação de aplicações ou data center.

¹ Babcock, Charles (18 de janeiro de 2011). “Nuvens privadas decolam.” Information Week. Web.

PUBLICADO EM 10 DE JANEIRO DE 2012