Computação em Nuvem

Aula 4: Principais arquiteturas

Apresentação
Nesta aula, abordaremos vários dos modelos fundamentais de arquitetura de computação em nuvem.

Para cada modelo apresentado, veremos exemplos de uso comuns, e as principais características de aplicações de
ambientes em nuvem.

Objetivos
Apontar os modelos fundamentais de arquitetura de computação em nuvem;

Exempli car usos comuns para cada arquitetura abordada;

Distinguir combinações de mecanismos de computação em nuvem usados em cada arquitetura.

Arquitetura de distribuição de carga

Recursos de TI podem ser horizontalmente escalados pela adição de um ou mais recursos de TI idênticos, e o balanceador de
carga é o mecanismo responsável por distribuir a carga de trabalho aos recursos de TI disponíveis.

A arquitetura resultante denominada arquitetura de distribuição de carga é importante, pois reduz a sobrecarga sobre
recursos de TI especí cos enquanto outros recursos podem estar ociosos.

A tarefa do balanceador de carga, portanto, é interceptar requisições dos usuários por serviços de nuvem e distribuir as
demandas de forma a manter um bom equilíbrio de utilização entre os recursos disponíveis, conforme ilustrado pela Figura 1.
 Figura 1: Arquitetura de distribuição de carga de trabalho

Além do balanceamento de carga, os seguintes mecanismos também podem ser parte desta arquitetura. Acompanhe a seguir:

 Mecanismos que podem fazer parte da arquitetura de distribuição de carga

 Clique no botão acima.

Mecanismos que podem fazer parte da arquitetura de distribuição de carga

Monitor de auditoria
Ao distribuir a carga de trabalho, o tipo e a posição geográ ca do recurso de TI que está tratando cada requisição pode
determinar se o monitoramento é necessário para cumprir requisitos legais e regulatórios.

Monitor de uso de nuvem

Diversos monitores podem estar envolvidos com o objetivo de monitorar a carga de trabalho e o processamento de
dados.

Hipervisor
A carga de trabalho entre hipervisores e seus servidores virtuais podem demandar distribuição.

Perímetro lógico da rede

O perímetro lógico da rede separa as fronteiras da rede do consumidor de nuvem em relação a como e onde as cargas
são distribuídas.

Cluster (agrupamento) de recursos

Recursos de TI agrupados podem gerar novas instâncias de recursos virtualizados de TI em resposta a demandas de
distribuição de carga de trabalho.

Replicação de recursos
Responsável por gerar novas instâncias de recursos virtualizados de TI em resposta à demandas de distribuição de
carga de trabalho.
 Arquitetura de Pool de recursos
Um pool de recursos (piscina de recursos) é um conjunto de recursos disponível para atribuição ao consumidor que requisitar
serviços. Em outras palavras, um pool de recursos pode ser descrito como uma abstração lógica para gerenciamento exível
de recursos.

A arquitetura baseada em pool de recursos é baseada no uso de um ou mais pool de recursos, nos quais recursos de TI
idênticos são agrupados e mantidos por um sistema que automaticamente se certi ca de que eles estão sincronizados.

 Exemplos de pool de recursos

 Clique no botão acima.

Exemplos de pool de recursos

Pool de servidores físicos: São compostos de diversos servidores físicos idênticos ligados em rede de
computadores, com seus sistemas operacionais e aplicações instalados e aguardando para uso imediato.

Pool de servidores virtuais: Geralmente escolhido por consumidores de nuvem durante a fase de
provisionamento. Por exemplo, um consumidor pode ter escolhido um pool de servidores Linux com 16GB de
memória RAM, que são, na verdade, servidores virtualizados.

Pools de armazenamento: Consistem em estruturas de armazenamento baseado e arquivos ou em blocos.

Pool de rede: É composto por diferentes dispositivos de rede pré-con gurados. Por exemplo, um pool de
dispositivos de rewalls virtuais ou switches físicos pode ser criado para redundância de conectividade,
balanceamento de carga, ou agregação de links (canais de comunicação).

Pools de CPU: São tipicamente cores (núcleos) individuais de processamento alocados a servidores virtuais.

Pools de memória RAM física: Podem ser usadas em provisionamento de novos servidores físicos ou para
escalar verticalmente servidores existentes.

Pools dedicados de recursos podem ser criados para cada tipo de recurso de TI e pools individuais podem ser agrupados em
pools maiores, no qual cada pool individual passa a ser chamado subpool, conforme ilustrado na Figura 2.

 Figura 2: Agrupamento de pool de recursos, com 4 subpools

 Pools de recursos podem ser altamente complexos, com múltiplos pools criados para aplicações e consumidores especí cos.
Uma estrutura hierárquica de pools pode ser estabelecida para formar pais, lhos, e pools aninhados, para que se possa
facilitar o processo de organização de requisitos diversos de pooling de recursos.

O exemplo mostrado na Figura 3 mostra B e C como lhos tirados do pai A. Essa pode ser uma alternativa a manter um pool
generalizado de recursos de TI compartilhado por todo o ambiente em nuvem.

 Figura 3: Agrupamento de pool de recursos, com 4 subpools

Pools lhos são, em geral, retirados de pools físicos, e isolados um dos outros para que cada consumidor de nuvem só tenha
acesso ao seu respectivo pool.

No modelo de pool aninhado, pools maiores são divididos em grupos menores que individualmente agrupam o mesmo tipo de
recurso de TI. Em geral, pools aninhados são usados para associar pools de recursos a diferentes departamentos ou grupos de
uma mesma organização consumidora de nuvem.

Na Figura 4 vemos um exemplo de pools alinhados, onde os Pools aninhados A.1 e A.2 são constituídos dos mesmos recursos
de TI que o Pool A, mas em diferentes quantidades. Em geral, pools aninhados são usados quando há necessidade de
instanciar rapidamente recursos de TI do mesmo tipo e com a mesma con guração.
 Figura 4: Os pools aninhados A.1 e A.2 são compostos dos mesmos recursos que o pool A, mas em diferentes quantidades.

Além dos mecanismos típicos de pooling de dispositivos de armazenamento e servidores virtuais, os seguintes mecanismos
também podem fazer parte da arquitetura de pooling de recursos. Acompanhe cada um deles a seguir:

 Mecanismos que podem fazer parte da arquitetura de pooling de recursos

 Clique no botão acima.

Mecanismos que podem fazer parte da arquitetura de pooling de recursos

Monitor de auditoria: Este mecanismo monitora o uso de pool de recursos para garantir conformidade com
requisitos regulatórios e de privacidade, especialmente quando pools contêm dispositivos de armazenamento ou
dados carregados na memória

Monitor de uso de nuvem: Diversos monitores podem estar envolvidos na monitoração e sincronização que são
requeridos pelos pools de recursos de TI e por qualquer sistema de gerenciamento subjacente.

Hipervisor: O mecanismo hipervisor, além de hospedar o servidor virtual e, às vezes, demandar eles mesmos por
pool de recursos, é responsável por prover aos servidores virtuais acesso aos pools de recursos.

Perímetro lógico da rede: O perímetro lógico da rede é usado para de nir a organização lógica dos recursos de
TI, bem como garantir seu isolamento

Cluster (agrupamento) de recursos: Recursos de TI agrupados podem gerar novas instâncias de recursos
virtualizados de TI em resposta a demandas de distribuição de carga de trabalho.

Replicação de recursos: Responsável por gerar novas instâncias de recursos virtualizados de TI em resposta a
demandas de distribuição de carga de trabalho.

Monitor pague-pelo-uso (pay-per-use): São responsáveis por coletar informações de uso e cobrança sobre
como consumidores de nuvem individuais foram alocados aos vários pools de recursos de TI.

Sistema de administração remota: Esse mecanismo é comumente usado como interface com os sistemas e
programas de backend (infraestrutura subjacente) para que se possa acessar as funcionalidades administrativas
aos pools de recursos, via um portal front-end (interface web).

Sistema de gerenciamento de recursos: Esse sistema provê aos consumidores de nuvem as ferramentas e
opções de gerenciamento de permissões para que seja possível administrar pools de recursos.

Replicação de recursos: Esse mecanismo é usado para gerar novas instâncias de recursos de TI para pools de
recursos.
 Arquitetura de escalabilidade dinâmica
O modelo de escalabilidade dinâmica se baseia em um sistema de dimensionamento prede nido que dispara a alocação
dinâmica de recursos de TI disponíveis em pools de recursos. A alocação dinâmica permite que haja utilização variável de
recursos conforme as utuações de demanda de usuários, já que os recursos de TI ociosos em um dado instante são
e cientemente liberados sem a necessidade de interação manual.

O dimensionador automático é con gurado com limitantes de carga de trabalho que ditam quando um novo recurso de TI
precisa ser adicionado ao processamento da demanda. Esse mecanismo pode ser disponibilizado com uma lógica que
determina quantos recursos de TI adicionais podem ser dinamicamente alocados, baseado nos termos do contrato de
provisionamento do consumidor de nuvem.

Quando o dimensionador automático aloca ou libera novos recursos de TI idênticos, dizemos que ocorre
escala/dimensionamento horizontal dinâmico.

Quando há ajuste em um mesmo recurso de TI, então, temos uma escala/dimensionamento vertical.

O terceiro tipo de dimensionamento dinâmico é a relocação dinâmica, em que o recurso de TI é relocado para um host com
maior capacidade. Por exemplo, um banco de dados pode precisar ser movido de um armazenamento SAN baseado em tas
com capacidade de leitura/escrita (I/O – Input/Output) de 4GB por segundo, para outro dispositivo baseado em SSD (Solid
State Driver) com capacidade de I/O de 12GB por segundo.

A arquitetura de escalabilidade dinâmica pode ser aplicada para um amplo espectro de recursos de TI, incluindo servidores
virtuais e dispositivos de armazenamento. Além das funções principais de dimensionamento/escalabilidade, os seguintes
mecanismos também podem ser usados nessa arquitetura. Veja a seguir quais são:

 Mecanismos que podem ser usados na arquitetura de escalabilidade dinâmica

 Clique no botão acima.

 Mecanismos que podem ser usados na arquitetura de escalabilidade dinâmica

Monitor de auditoria: Esse mecanismo monitora o uso de pool de recursos para garantir conformidade com
requisitos regulatórios e de privacidade, especialmente quando pools contem dispositivos de armazenamento ou
dados carregados na memória

Monitor de uso de nuvem: Monitora utuações dinâmicas e monitora e registra o uso em tempo real.

Hipervisor: Invocado pelo sistema de escalabilidade dinâmica para criar ou remover instâncias de servidores
virtuais, ou para escalar um dado servidor.

Monitor pague-pelo-uso (pay-per-use): O monitor pay-per-use é responsável por coletar informações de custo
de uso em resposta à escalabilidade dinâmica de recursos.

Arquitetura de capacidade elástica de recursos

Essa arquitetura está primariamente relacionada ao provisionamento dinâmico de servidores virtuais, usando sistemas que
alocam e liberam memória RAM e CPU em resposta imediata a utuações nos requisitos de processamento de recursos de TI
hospedados.

Pools de recursos são usados por tecnologias de escalabilidade que interagem com o hipervisor e/ou o VIM para recuperar
liberar recursos de CPU e memória em tempo de execução.

O processamento em tempo de execução do servidor virtual é monitorado para que recursos adicionais de processamento
possam ser trazidos do pool de via alocação dinâmica, antes que limitadores de capacidade sejam alcançados. O servidor
virtual, suas aplicações hospedadas e recursos de TI são verticalmente escalados em resposta.

Esse tipo de arquitetura de nuvem pode ser designado para que um script inteligente de automação envie requisições de
dimensionamento através do VIM, ao invés de contatar o hipervisor diretamente. Servidores virtuais que participam sistemas
de alocação elástica de recursos podem ter que ser reiniciados para que a alocação dinâmica surta efeito.

Alguns mecanismos que podem estar inclusos nesta arquitetura são:

 Clique nos botões para ver as informações.

Monitor de uso de nuvem 

Monitores especializados coletam informações sobre uso de recursos antes, durante e depois de ocorrer a escalabilidade,
para ajudar a de nir limitadores futuros para o processamento de servidores virtuais.

Replicação de recursos 

Replicação de recursos é usada por este modelo de arquitetura para gerar novas instâncias do recurso.

Monitor pague-pelo-uso (pay-per-use) 

O monitor pay-per-use é responsável por coletar informações de custo de uso em resposta à medida que ocorrem os
provisionamentos elásticos.

Arquitetura de balanceamento de serviço

Considerada uma variação da arquitetura de distribuição de carga, a arquitetura de balanceamento de serviço visa
especi camente escalar implementações de serviços em nuvem. Implantações redundantes de serviços de nuvem podem ser
criados, combinados sistemas de balanceamento de carga para distribuição dinâmica da carga de trabalho.

Implementações duplicadas de serviços em nuvem são organizadas em pools de recursos, enquanto o balanceador de carga
pode ser posicionado tanto como um componente externo quando um componente interno.

Dependendo da antecipação de carga de trabalho e da capacidade de processamento, múltiplas instâncias de cada

implementação de serviços de nuvem podem ser geradas como parte de um pool de recursos que responde mais
e cientemente à utuações nos volumes de requisições.

Os seguintes mecanismos adicionais podem estar contidos nesta arquitetura:

Clique nos botões para ver as informações.

Monitor de uso de nuvem 

Responsável pelo monitoramento das instâncias de serviços de nuvem, os respectivos níveis de consumo dos recursos de
TI, bem como diversos monitoramentos de tempo de execução, e tarefas de coleta de uso de dados.

Cluster de recursos 

Grupos de clusters ativos são incorporados nesta arquitetura para ajuda no balanceamento de carga de trabalho entre
diferentes membros do cluster.

Replicação de recursos 

Mecanismos de replicação de recursos são usados para gerar implementações de serviços em nuvem em suporte ao
mecanismo de balanceamento de carga.
 Arquitetura de nuvem em rajadas
A arquitetura de nuvem em rajadas estabelece uma forma de escalabilidade dinâmica que permite que recursos de TI em
nuvem sejam alocados sempre que certos níveis de capacidade são alcançados nos recursos de TI on-premise.

Os recursos de TI baseados em nuvem correspondente são pré-disponibilizados, mas permanecem inativos até que a rajada de
demanda ocorra, e os recursos de TI on-premise não são su cientes para atender a demanda. Quando os recursos de TI em
nuvem não são mais necessários, eles são liberados e a arquitetura retorna ao uso dos recursos de TI on-premise.

Ou seja, a rajada em nuvem é uma arquitetura escalável exível que provê

aos consumidores de nuvem a opção de usar recursos de TI em nuvem
somente para satisfazer picos de demandas que ultrapassam a capacidade
on-premise.

O escalonador automático determina quando deve redirecionar requisições para os recursos baseados em nuvem, e a
replicação de recursos é usado para manter a sincronicidade entre os recursos on-premise e baseados em nuvem.

Além do escalonador automático e do replicador de recursos, diversos outros mecanismos podem ser usados para
automatizar a dinâmica de migrar requisições entre os recursos de TI on-premise e baseados em nuvem.
 Arquitetura de provisionamento elástico de armazenamento
Consumidores de nuvem são comumente cobrados por espaço de armazenamento baseado em nuvem, conforme alocação
estática de armazenamento. Com isso, as cobranças são predeterminadas pela capacidade do disco alocado, e não depende
do armazenamento efetivamente utilizado.

A Figura 5 ilustra um cenário em que um consumidor de nuvem provisiona um servidor virtual com o sistema operacional Linux
e três HDs de 150GB. O consumidor de nuvem é cobrado pelo uso de 450GB de armazenamento depois de instalar o Linux,
mesmo que apenas alguns GB estejam efetivamente sendo utilizados.

 Figura 5: Exemplo de arquitetura de provisionamento elástico de armazenamento

Com isso, a arquitetura de provisionamento elástico de disco permite que o usuário seja cobrado somente pelo espaço que
está efetivamente sendo utilizado. Esse sistema usa tecnologia de provisionamento no para a alocação dinâmica de espaço
de armazenamento, e é suportada pelo monitor de uso em tempo real para coletar dados precisos de uso para ns de
cobrança.

Softwares de provisionamento no é instalado em servidores virtuais que processa alocação dinâmica de armazenamento via
hipervisor, enquanto um software de monitoramento de uso registra e relata dados detalhados de uso de discos para ns de
cobrança.

Os seguintes mecanismos podem ser incluídos nesta arquitetura em adição ao dispositivo de armazenamento, servidor virtual,
hipervisor, e monitor de uso detalhado:
 Clique nos botões para ver as informações.

Monitor de uso de nuvem 

Monitores especializados, podem ser usados para registrar e monitorar utuações de uso.

Replicação de recursos 

Importante para o sistema de provisionamento elástico de discos.

Arquitetura de armazenamento redundante

Dispositivos de armazenamento em nuvem estão sujeitos a falhas ocasionais e indisponibilidades que são causadas por
questões de conectividade de rede, de controlador, ou falha geral de hardware, além de incidentes de segurança.

O comprometimento da con abilidade de um dispositivo de armazenamento em nuvem pode ter um efeito cascata e gerar
impactos por meio de todos os serviços, aplicações e componentes de infraestrutura na nuvem que se apoiam sobre o serviço
de armazenamento.

A arquitetura de armazenamento redundante adiciona um dispositivo sobressalente de armazenamento em nuvem como parte
de um sistema de recuperação de falhas que sincroniza os dados do dispositivo sobressalente com o dispositivo primário.

Um gateway de serviço de armazenamento direciona consumidores a requisitarem do dispositivo secundário sempre que o
dispositivo primário falha, conforme ilustrado pela Figura 6.

Neste exemplo, ocorre uma falha (1) no dispositivo primário de armazenamento. Como o dispositivo secundário de
armazenamento é rotineiramente mantido sincronizado com o primário, ele está sempre pronto para assumir. Então, o gateway
de serviço de armazenamento passa a redirecionar (2) as requisições dos consumidores ao dispositivo secundário de
armazenamento. Esse dispositivo, por sua vez, encaminha (3) as requisições às unidades lógicas de armazenamento. Com
isso, os consumidores continuam a acessar seus dados mesmo quando há falha no dispositivo primário de armazenamento.
 Figura 6: Exemplo de dispositivo secundário atuando para contornar a falha no dispositivo primário

Atividade
1) Além do balanceamento de carga, quais são os mecanismos usados pela arquitetura de distribuição de carga?

2) Em relação à arquitetura de pool de recursos, dê exemplos de pool de recursos mais comuns.

3) Explique qual é a diferença entre a arquitetura de escalabilidade dinâmica e a arquitetura de nuvem em rajadas.

Notas
Referências

NETO, Manuel V de S. Computação em Nuvem - Nova Arquitetura de TI. 1 Ed. Rio de Janeiro: Brasport, 2015.

Leitura do livro didático base, disponível na Biblioteca Virtual Estácio:

Capítulo 5, Intraestrutura de nuvem

Capítulo 7, Data Centers: Arquitetura e Infraestrutura

Próxima aula

Modelos de entrega IaaS, PaaS e SaaS.

Explore mais

Assista aos vídeos:

O que é Cloud Burst

(Habilite a legenda, e ative a tradução automática para português);

Tipos de armazenamento em nuvem

(Habilite a legenda, e ative a tradução automática para português);

Arquitetura elástica de nuvem, Amazon

(Habilite a legenda, e ative a tradução automática para português);

Backup e redundância na nuvem

(Habilite a legenda, e ative a tradução automática para português).