Construindo uma Nuvem Empresarial com F5 e IBM

INTRODUÇÃO

Segundo algumas estimativas, a nuvem corporativa, também conhecida como nuvem privada, está sendo adotada em um ritmo mais rápido do que a nuvem pública. A empresa de consultoria empresarial Accenture estima que a penetração da nuvem privada em empresas será de 77% até o final de 2011.1 Grande parte dessa rápida mudança para criar uma infraestrutura ágil no local decorre da necessidade, por parte dos departamentos de TI de grandes e pequenas empresas, de manter o controle e o gerenciamento internos da infraestrutura e dos dados.

Uma vez tomada a decisão de adotar uma infraestrutura de nuvem, a escolha entre interna/privada e externa/pública se resume a uma análise de custo, risco e valor. Uma nuvem pública normalmente oferece uma abordagem flexível e a maior economia de custos; no entanto, ela traz riscos associados à segurança, acordos de nível de serviço (SLAs), disponibilidade e gerenciamento. A TI pode tirar proveito de uma escala quase ilimitada com um baixo custo de entrada, mas sacrifica o controle. Mudar de um data center tradicional no local ou hospedado para uma nuvem pública externa é basicamente como mover todo o seu data center para as mãos de outra pessoa.

Com uma nuvem corporativa, a TI tem o nível de controle necessário e evita os riscos associados a uma nuvem pública; mas uma nuvem privada é mais cara de implantar, exige níveis adicionais de conhecimento e experiência da equipe e adiciona um nível maior de complexidade ao data center local. A infraestrutura de nuvem corporativa pode ser dimensionada conforme necessário e fornece provisionamento dinâmico e agilidade, mas essa escala e controle geralmente têm um custo de entrada mais alto.

Juntas, a F5 Networks® e a IBM projetaram uma arquitetura de referência para a nuvem corporativa que alivia muitos dos desafios associados à complexidade. Ele traz muitos dos componentes de arquitetura e escala de uma nuvem pública para o local, reduzindo significativamente o custo de construção de um sistema interno e fragmentado. Ao predefinir os componentes necessários e descrever como esses componentes funcionam juntos, 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 ações com base em eventos. Um evento em algum lugar do sistema cria um alerta ou mensagem que é captada por um componente (um que se inscreveu no barramento de mensagens ou um que foi solicitado diretamente por meio de uma chamada de API), que então atua nessa mensagem. Fluxo de trabalho é o processo e a ordem em que os componentes atuam nas mensagens do sistema.

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

Arquitetura de fluxo de trabalho

A arquitetura de nuvem corporativa da F5 e da IBM é baseada em dois princípios essenciais:

  1. Há um barramento de mensagens centralizado usado para transportar mensagens de notificação de eventos, e todos os componentes que precisam agir em eventos são vinculados ao barramento.
Diagrama da arquitetura de referência da nuvem
Arquitetura de referência em nuvem.

Além desses dois princípios, a arquitetura de referência do F5 e da IBM é extremamente maleável, o que significa que ela pode se adaptar a qualquer data center ou arquitetura de nuvem existente. Se já existir um mecanismo de orquestração para gerenciar a implantação de VM, por exemplo, essa arquitetura de referência poderá ser adaptada para que o mecanismo existente possa ser usado. Um equívoco em relação à construção de uma nuvem corporativa é 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á existem e quais são novos, o fluxo de trabalho da nuvem corporativa é composto de componentes específicos que executam tarefas específicas. Todo o sistema de nuvem é composto por esses componentes individuais, que trabalham juntos para fornecer a infraestrutura de nuvem completa. Essa infraestrutura é alimentada 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 transporta mensagens baseadas em eventos e alertas para cada componente afetado. Quando um evento aciona uma mensagem, essa mensagem é enviada pelo barramento de mensagens para um componente específico, que tem regras sobre o que fazer com essa mensagem. O barramento de mensagens também é responsável por normalizar mensagens com base em regras para componentes específicos.

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

ORCHESTRATOR

O orquestrador pode ser considerado o cérebro da nuvem corporativa — o componente responsável por tomar a maioria das decisões de provisionamento de macro com base nas mensagens recebidas pelo barramento. O orquestrador iniciará os principais eventos e fluxos de trabalho na arquitetura de nuvem, como iniciar o fluxo de trabalho “provisionar 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 aplicáveis; por exemplo, o orquestrador forneceria as informações de endereço IP necessárias para provisionar uma nova VM.

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

Controlador de Nuvem

O controlador de nuvem é o sistema 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 para provisionamento. Por exemplo, o controlador de nuvem coleta informações que incluem localização da VM, classe de aplicativo (servidor web, servidor de banco de dados, servidor de e-mail, etc.) e requisitos mínimos de recursos.

Durante um evento de provisionamento automatizado, e depois que esses dados preliminares já foram armazenados no sistema, o orquestrador solicita e extrai as informações existentes para iniciar o fluxo de trabalho de provisionamento. Exemplos de controladores de nuvem incluem Eucalyptus Cloud Controller, VMware vCloud Director ou Amazon EC2. Para crescimento futuro e capacidade de expansão para outras plataformas de nuvem, é uma boa prática escolher um controlador de nuvem que possa integrar ou se comunicar com um conjunto padrão de APIs de nuvem. Isso permite que o controlador de nuvem se estenda para um provedor de nuvem pública ou híbrida sem reestruturar a plataforma de nuvem corporativa.

Controlador de cluster/Hipervisor

O controlador de cluster é o componente na 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 o ambiente de gerenciamento do hipervisor maior. Por exemplo, o controlador de cluster pode ser um hipervisor básico, como o VMware ESXi, ou uma coleção maior de sistemas de hipervisor distribuídos, como o VMware vSphere ou o VMware vCloud.

Monitoramento

O monitoramento de integridade e status são elementos essenciais de qualquer implantação de aplicativo empresarial. O monitoramento também fornece atualizações de status para sistemas de provisionamento, por exemplo, quando uma máquina virtual está ativa 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 do aplicativo e da rede pode ser usado na implantação da nuvem corporativa; no entanto, o software IBM Tivoli Monitoring é usado na arquitetura de referência F5 e IBM.

DNS

O Sistema de Nomes de Domínio (DNS) desempenha um papel fundamental na arquitetura de referência de nuvem corporativa F5 e IBM: Ele é responsável por armazenar não apenas as informações de IP e nome de domínio para IPv4 e IPv6, mas também metadados do sistema, como as informações coletadas pelo controlador de nuvem e informações exclusivas de identificação da máquina. Para esta arquitetura de referência, o DNS foi escolhido como o local de armazenamento de metadados porque é um sistema baseado em padrões que já existe na maioria das redes, está disponível para todos os componentes da nuvem e alivia a necessidade de adicionar armazenamento adicional do tipo banco de dados à infraestrutura. Qualquer solução de DNS gerenciada por TI e que tenha a capacidade de adicionar zonas e arquivos de zona adicionais pode ser usada.

Armazenamento

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

Application Delivery Controller

O último componente na nuvem corporativa é o Application Delivery Controller (também conhecido como balanceador de carga), que, na arquitetura de referência F5 e IBM, é o F5® BIG-IP® Local Traffic Manager™ (LTM). O BIG-IP LTM gerencia conexões, serviços e entrega de dados de aplicativos provenientes da máquina virtual. Por fim, o BIG-IP LTM é a parte final do sistema que atua em um evento de provisionamento de fluxo de trabalho.

Passos: Provisionamento Manual e Automatizado

O objetivo da arquitetura de referência de nuvem corporativa F5 e IBM é fornecer uma plataforma baseada em recursos do mundo real para implantação dinâmica de aplicativos. Depois que todos os componentes estiverem instalados, eles trabalharão juntos — por meio de vários fluxos de trabalho — para provisionar novos serviços de aplicativos conforme necessário. Há duas maneiras de provisionar sistemas em vigor na nuvem corporativa: provisionamento manual e provisionamento automatizado.

Provisionamento manual

Normalmente, o primeiro fluxo de trabalho na nuvem corporativa é iniciado a partir de um processo manual com base na entrada do administrador do sistema ou do solicitante do aplicativo. Isso não quer dizer que o fluxo de trabalho seja manual; apenas o ato de inserir informações no sistema pela primeira vez é manual. Depois que os dados são coletados do administrador, o sistema inicia eventos de fluxo de trabalho automatizados predefinidos para provisionamento de aplicativos.

Passo 1: Entrada de dados do controlador de nuvem

Usando a GUI do controlador de nuvem, o administrador (ou solicitante do aplicativo, dependendo de quem é responsável por iniciar um novo evento de provisionamento) insere as informações necessárias para iniciar uma nova máquina virtual e colocar um aplicativo online. Essas informações geralmente são dados de infraestrutura de nível superior, como:

  • Tipo de aplicação: Uma lista predefinida de tipos de aplicativos disponíveis, como Microsoft SharePoint, um servidor web, um servidor de e-mail, um banco de dados Oracle, etc.
  • Informações de rede: Endereço IP do cluster, URL do front-end, se este aplicativo será público ou somente interno, etc.
  • Informações de provisionamento: Qualquer informação adicional necessária para o sistema de provisionamento, como localização de 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 sobre o número mínimo e máximo de instâncias permitidas de um determinado tipo de aplicativo.

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

Etapa 2: Iniciar fluxo de trabalho de provisionamento; distribuir metadados

Depois que o administrador envia os dados necessários, a próxima etapa é o controlador de nuvem empacotar essas informações — junto com uma ID de instância exclusiva criada dinamicamente e usada em todo o sistema para identificar essa instância para provisionamento, como "vm12345" — e distribuí-la ao orquestrador pelo barramento de mensagens.

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

Em conjunto, o controlador de nuvem fornece os mesmos metadados e ID de instância exclusivo ao hipervisor, por meio de uma API, e o instrui a implantar a imagem do aplicativo necessária. Este evento solicita que o hipervisor solicite a imagem de disco da máquina virtual aplicável do armazenamento baseado em nuvem. O dispositivo de armazenamento recupera a imagem de disco apropriada via NFS e começa a copiar essa imagem para o armazenamento local.

Etapa 3: O Orchestrator distribui metadados

Depois que o orquestrador recebe as informações de eventos normalizadas e os metadados do barramento de mensagens, ele inicia dois fluxos de trabalho diferentes que enviam simultaneamente os metadados para os sistemas de monitoramento e DNS. Os sistemas de monitoramento usam essas informações para configurar um cronograma de monitoramento automatizado para o aplicativo e começar a monitorar o aplicativo após a notificação de que ele está ativo e em execução. Durante esta etapa, o orquestrador também definirá limites para os eventos do sistema de monitoramento — por exemplo, instruindo o monitor a enviar uma notificação de evento quando a CPU desta instância virtual exceder 75% de utilização.

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 de zona DNS apropriado, portanto, ele deve construir nomes de domínio com base no ID da instância, criar registros DNS IPv4 e IPv6, adicionar informações de instância do controlador de nuvem e adicionar as novas informações de instância à zona apropriada. Por exemplo, o orquestrador pegará o ID de instância exclusivo, criará uma entrada DNS para “vm12345.vm.cloud.example.com” e a adicionará à zona example.com existente.

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

Etapa 4: Notificação de 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. Quando a VM estiver instalada e funcionando 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 pegará esse alerta de evento e iniciará um fluxo de trabalho que instruirá o BIG-IP LTM a sinalizar a nova VM como disponível no pool e a começar a enviar 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 com o monitor de aplicativos configurado anteriormente e atribuído ao pool de aplicativos.

O alerta de evento da VM recém-executada também solicitará que o orquestrador notifique o sistema geral de monitoramento de nuvem empresarial para começar a monitorar a instância virtual. Neste ponto, a instância virtual recém-provisionada está instalada e em execução na nuvem corporativa e manipulando solicitações de serviço de aplicativo. Este é o modo operacional normal de todos os serviços que fazem parte da nuvem corporativa.

Provisionamento automatizado

O provisionamento manual é a primeira etapa do fluxo de trabalho no provisionamento de serviços na nuvem corporativa, mas não é a forma mais frequente de provisionamento. Em um sistema de funcionamento tranquilo, a nuvem corporativa migra para um sistema mais dinâmico e fluido de automonitoramento, e autoprovisiona novos serviços conforme necessário e com base na demanda. Esse autoprovisionamento ágil está no centro de qualquer plataforma de nuvem e requer eventos e fluxos de trabalho de provisionamento automatizados adicionais para monitorar e reagir a eventos em tempo real.

Passo 1: Monitoramento e Alertas

O primeiro passo de qualquer sistema de autoprovisionamento é o monitoramento: coletar e detectar eventos em todo o sistema. Durante a primeira rodada de provisionamento manual, os sistemas de monitoramento foram preenchidos com informações de instância virtual, como nome, local, tipo de monitoramento e limites de eventos. Essas informações são usadas para monitorar automaticamente a disponibilidade e o desempenho dos aplicativos e 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 os recursos esgotados.

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 aliviar a carga de recursos na instância atual. Duas ou mais instâncias virtuais serão usadas para distribuir as cargas de computação e rede do aplicativo.

Para iniciar um fluxo de trabalho de provisionamento automatizado, o orquestrador deve ser responsável por coletar eventos de componentes, bem como solicitar metadados necessários para provisionar uma nova instância virtual. Na arquitetura de referência F5 e IBM, os metadados são armazenados no DNS e preenchidos como parte do fluxo de trabalho de provisionamento manual original. O DNS retornará informações — por exemplo, tipo de aplicativo, localização geográfica e limites de provisionamento — ao orquestrador, como tipo de aplicativo, localização geográfica e 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 adquiridos do DNS para o controlador de nuvem pelo barramento de mensagens. Essencialmente, essa etapa automatizada simula a etapa em que um administrador insere informações da máquina e inicia manualmente o fluxo de trabalho de provisionamento. O controlador de nuvem receberá essas informações (da mesma forma que faria com o administrador no provisionamento manual) e iniciará um novo fluxo de trabalho de provisionamento de instância virtual. A partir deste ponto, as etapas de provisionamento e os fluxos de trabalho 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 corporativa incluirá fluxos de trabalho de provisionamento manuais e automatizados. Novos serviços ou aplicativos serão implantados inicialmente usando um fluxo de trabalho manual para que um administrador possa controlar como e onde o serviço é implantado. Depois que um serviço estiver instalado e funcionando, os fluxos de trabalho de provisionamento automatizado gerenciarão o provisionamento com base nas necessidades e na disponibilidade dos recursos.

Conclusão

A escolha de implantar uma nuvem empresarial privada não deve ter o custo de maior complexidade ou inoperabilidade. O objetivo de qualquer implantação de nuvem é reduzir as barreiras de criação de novos serviços e fornecer uma infraestrutura de computação mais ágil. Uma nuvem corporativa traz essa agilidade ao data center para melhor gerenciamento e controle.

Com a IBM, a F5 criou uma arquitetura de referência para uma nuvem corporativa 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 corporativa seja conectada a qualquer outra plataforma de nuvem por meio de APIs e uma infraestrutura de mensagens compartilhada. Nenhuma nuvem empresarial privada é igual a outra; no entanto, a arquitetura F5 e IBM se adaptará a diferentes ambientes, ao mesmo tempo em que traz os benefícios de uma infraestrutura ágil para qualquer implantação de aplicativo ou data center.

 

1 Babcock, Charles (2011, 18 de janeiro). “Nuvens privadas decolando.” Semana da Informação. Rede.

Publicado em 10 de janeiro de 2012
  • Compartilhe no Facebook
  • Compartilhar para X
  • Compartilhe no Linkedin
  • Compartilhar por e-mail
  • Compartilhe via AddThis

Conecte-se com F5

F5 LABS

O que há de mais moderno em inteligência de ameaças a aplicativos.

DevCentral

A comunidade F5 para fóruns de discussão e artigos de especialistas.

Sala de redação da F5

Notícias, blogs F5 e muito mais.