6 Alta disponibilidade na computação em nuvem

É importante destacar a necessidade da definição de SLAs entre clientes e

servidores para entender às expectativas do cliente em relação à nuvem, bem
como as obrigações do provedor de garantir a alta disponibilidade. Critchley
(2015) afirma que os SLAs para computação em nuvem são mais difíceis de
definir, pois o ambiente operacional não é controlado pela organização do
cliente, que deve definir as expectativas, e o provedor da nuvem precisará
mapeá-las no ambiente em nuvem. O autor acrescenta, ainda, que os SLAs
variam de acordo com o modelo de serviço (IaaS, PaaS e SaaS) escolhido pela
organização e cita dez áreas de SLAs que um cliente e um fornecedor de nuvem
precisam considerar e concordar, descritas a seguir (CRITCHLEY, 2015).

„ Entender os papéis e as responsabilidades: devem ser definidas quais

as atribuições do provedor e quais as do cliente. Por exemplo, deve-se
definir quem é responsável por detectar e relatar as ocasiões em que o
serviço de nuvem falha.
„ Avaliar políticas de nível de negócios: ao escolher o provedor do
serviço, os clientes devem considerar os requisitos de política e con-
formidades relevantes para eles, pois cada provedor tem suas políticas
já expressas em relação à legislação e à proteção de dados, que podem
não se encaixar com o que o usuário necessita.
„ Entender as diferenças de modelo de serviço e implantação: para cada
um dos modelos de serviço da nuvem, existem diferenças significativas
em relação a abstração, objetivos de nível de serviço e indicadores de
desempenho. Então, o SLA deve declarar as métricas para cada um dos
modelos, conforme os serviços contratados pelo cliente, além de conter
a especificação de qual modelo de implantação (nuvem privada, comu-
nitária, pública ou híbrida) está sendo contratado e quais tecnologias
de implantação serão adotadas.
„ Identificar objetivos críticos de desempenho: as metas de desempe-
nho na computação em nuvem estão diretamente relacionadas com a
eficiência e a precisão da prestação de serviços pelo provedor. Disponi-
bilidade, tempo de resposta e velocidade de processamento são algumas
das considerações típicas de desempenho. A partir disso, os clientes
devem decidir quais medidas são mais críticas para seu ambiente de
nuvem específico e garantir que essas medidas sejam incluídas no SLA.
 Alta disponibilidade na computação em nuvem 7

„ Avaliar os requisitos de segurança e privacidade: as posturas de

segurança, as políticas de respostas e os esquemas de controle de um
provedor devem ser integradas aos do consumidor. Contudo, a base
necessária para a segurança independe da solução em nuvem a ser
utilizada, pois é um esquema de classificação de segurança que se
aplica a toda a empresa e se baseia na criticidade e na sensibilidade dos
ativos da empresa. A classificação deve ser a base para a aplicação de
métodos de controle de acesso, arquivamento e criptografia. Em relação
à privacidade, quando os dados de uma empresa são transferidos para
a nuvem, a obrigação de protegê-los é do provedor. Portanto, deve ser
definido no SLA que qualquer perda, dano ou uso indevido dos dados
é de responsabilidade do prestador de serviço.
„ Identificar os requisitos de gerenciamento de serviço: todo sistema
de computação requer controles internos, gerenciamento, automação
e autocura. Na nuvem, esses gerenciamentos devem se aplicar a todas
as camadas de serviço, como fornecimento de infraestrutura principal,
operadoras de rede e ISP (Internet Service Provider; ou Provedor de
Serviço Internet, em português), armazenamento de dados com ou sem
backup e espelhamento e aplicativos com ou sem armazenamento de
dados. O SLA deve incluir disposições para auditoria, monitoramento
e relatórios, medição de uso de serviço, provisionamento de serviços,
mudança de gestão, atualizações e patches (programas de computador
criados para atualizar ou corrigir um software).
„ Preparar-se para o gerenciamento de falhas de serviço: o gerencia-
mento de falhas de serviços está relacionado com o que ocorre quando
um serviço em nuvem não é entregue de maneira satisfatória. Assim, no
SLA, devem ser definidos objetivamente os recursos e o desempenho
esperados do provedor, para que uma falha seja reconhecida como tal.
A preparação para o gerenciamento de falhas deve ter como objetivo
reduzir o impacto e a duração da falha.
„ Entender o plano de recuperação de desastres: o plano de recuperação
de desastres (DR, disaster recovery) para os clientes é de extrema im-
portância quando eles migram para a nuvem, pois estão deixando seus
dados e sistemas sob a responsabilidade de terceiros. Então, no SLA,
devem ser definidos princípios do plano de DR: cada cliente tem prio-
ridades únicas, como a importância de seus componentes e aplicativos
de infraestrutura, então um plano de DR de nuvem é específico para
cada empresa, sendo orientado por essas prioridades; o processo começa
com a identificação e a priorização de aplicativos, serviços e dados;
8 Alta disponibilidade na computação em nuvem

os objetivos de tempo de recuperação (RTO, recovery time objective) e

os objetivos de ponto de recuperação (RPO, recovery point objective)
são estabelecidos separadamente para cada serviço, a fim de minimizar
o impacto nos negócios; o plano de DR deve ser testado regularmente.
„ Definir um processo de gerenciamento eficaz: no SLA, devem ser
definidos processos de governança fortes e detalhados dentro da orga-
nização do cliente, para o uso dos serviços em nuvem. A primeira parte
diz respeito ao controle e à supervisão das etapas anteriores, ao passo
que a segunda parte do processo é a necessidade da revisão contínua do
uso de todos os serviços em nuvem, a fim de garantir que eles atendam
aos requisitos de negócios e resultem na satisfação do usuário.
„ Entender o processo de saída (p. ex., no caso de não cumprimento
dos critérios do SLA): no SLA, deve ser definido um plano de saída
do cliente, seja por incapacidade do provedor de entregar os níveis de
serviço exigidos, ou, quando antes do término do contrato, pelo fato
de que o cliente deseja realizar a mudança para um novo provedor.
Esse plano garante a eficiência dos procedimentos para transferir com
segurança e rapidez dados e aplicativos dos usuários para o outro ser-
viço, garantindo a continuidade dos negócios. Além disso, devem ser
especificadas métricas para assegurar que o provedor de nuvem esteja
implementando efetivamente esses procedimentos.

2 Disponibilidade em ambientes virtuais

Os provedores de computação em nuvem utilizam VMs em seus servidores,
de modo a reduzir custos, melhorar a gestão do ambiente de TI e aumen-
tar a disponibilidade. Um ponto positivo de se utilizar várias VMs em uma
única infraestrutura física é que os recursos de hardware são aproveitados
ao máximo, pois atingem a maior parte do processamento do hardware.
A utilização da virtualização em ambientes de computação em nuvem traz
inúmeras vantagens, pois as VMs apresentam certas exibilidades, como as
listadas a seguir.

„ Particionamento: possibilidade de várias aplicações e sistemas ope-

racionais serem suportados em um único servidor físico, bem como a
divisão de recursos de acordo com a necessidade de cada usuário que
está acessando a VM.
 Alta disponibilidade na computação em nuvem 9

„ Isolamento: cada VM é isolada do hardware do host e das outras

VMs presentes no mesmo host. Sendo assim, se uma das VMs falhar,
as demais não serão afetadas.
„ Multitenancy: é a capacidade da aplicação de suportar a execução de
diversos usuários ou grupos de usuários, em que cada um terá seus
dados separados, configurações próprias e funcionando de forma in-
dependente, porém com uma única aplicação rodando. Na computação
em nuvem, a virtualização cria um modelo de múltiplos inquilinos,
flexibilizando o compartilhamento de uma única infraestrutura física
de um provedor entre vários usuários.
„ Mapeamento dinâmico: o sistema consegue medir de maneira auto-
matizada o uso dos recursos, fazendo a distribuição de armazenamento,
processamento, memória e largura de banda de acordo com o uso va-
riável de cada cliente.

Contudo, apesar da flexibilidade apresentada com a utilização de VMs, exis-

tem riscos que podem causar indisponibilidade dos serviços em um ambiente
não projetado para a alta disponibilidade. Os riscos citados na seção anterior
também devem ser considerados aqui, porém o maior risco de disponibilidade
que as VMs podem apresentar é o SPoF (Single Point of Failure; ou Ponto
Único de Falha, em português).
Possuir diversos servidores virtuais configurados em um único servidor
físico é uma grande vantagem, porém acaba se tornando um SPoF, pelo mesmo
motivo. A virtualização em um servidor host executará várias cargas de
trabalho de produção, de modo que precisa ser altamente disponível. Então,
um único problema no hardware ou no hypervisor (virtualizador; i.e., quem
executa a comunicação entre as máquinas virtuais e os recursos físicos) pode
tornar todas as VMs indisponíveis, causando um grande transtorno a todos
os usuários que dependem do funcionando dos sistemas nelas configurados.
Salvador (2019) descreve algumas abordagens utilizadas para manter as
aplicações em execução em tempo integral, são elas:

„ Clustering: essa solução envolve agrupar hypervisors através de múltiplos

servidores físicos, para que, caso ocorra uma falha em algum deles, as VMs
ativas sejam transferidas para outro servidor. Os servidores se comunicam
por meio de mensagens de heartbeat, de modo que o servidor secundário
entende que o primário falhou e, então, assume as cargas de trabalho para
elas que não fiquem indisponíveis. O heartbeat funciona como um pulso
cardíaco, o qual recebe e envia sinais entre os nós de um cluster para iden-
10 Alta disponibilidade na computação em nuvem

tificar quando um deles falha, a fim de que não ocorra indisponibilidade

das VMs afetadas, eliminando, assim, o SPoF do ambiente.
„ Armazenamento compartilhado: como uma VM pode ser movida
entre diferentes hosts físicos e os hardware podem falhar, os dados
não devem ser armazenados localmente em cada servidor. Para que
as informações se mantenham seguras e acessíveis, faz-se necessária
a utilização de um armazenamento compartilhado, conhecido como
Disk Array (ou Matriz de Disco). O Disk Array é um sistema de ar-
mazenamento em disco que contém várias unidades de disco. Esses
sistemas de armazenamento utilizam hardware e software especiais,
juntamente aos drives de disco, visando a fornecer um armazenamento
rápido e confiável, com proteção avançada para o processamento de
dados. Dentro desse contexto, há normalmente dois tipos básicos de
virtualização que podem ocorrer: virtualização em bloco, que são redes
de armazenamento distribuído que aparentam ser um único dispositivo
físico; e virtualização em arquivos, em que o sistema de armazenamento
concede acesso a arquivos armazenados em vários hosts.
„ Alta disponibilidade: se alguma falha no sistema operacional for
detectada, o hypervisor automaticamente reinicializa a VM que se
encontra com falha. Se o hardware subjacente de uma VM apresentar
interrupção, ele reiniciará a aplicação em outro servidor físico.
„ Tolerância a falhas: a tolerância a falhas busca contornar os problemas
das VMs e prover sua disponibilidade contínua, mesmo com alguma
falha no servidor, pois o serviço cria uma instância cópia (i.e., uma
VM redundante que está em sincronia com a original), de modo que,
ao ser ativada, ela se encontre atualizada. Ou seja, é um método de
espelhamento. A instância cópia assumirá o controle imediatamente
se a VM de produção se tornar indisponível.

Todas essas abordagens podem ser observadas nas Figuras 1 e 2. Na Figura 1,

existem três servidores físicos, com um hypervisor instalado em cada um
deles, sendo que os servidores físicos 1 e 3 possuem duas VMs em execução
em cada um deles e o servidor 2 executa apenas uma VM. Todas as VMs estão
compartilhando o acesso em um dispositivo de armazenamento. O cluster
do hypervisor é ativado e controlado por meio de um gerenciador central
da infraestrutura virtualizada (VIM, virtualized infrastructure manager).
O VIM gerencia e controla os recursos físicos e virtuais de uma rede, enviando
mensagens regulares de heartbeat entre os servidores físicos para confirmar
que todos estão em funcionamento.
 Alta disponibilidade na computação em nuvem 11

Servidor Servidor Servidor Servidor Servidor

virtual virtual virtual virtual virtual
A B C D E

Hypervisor Hypervisor Hypervisor

Servidor Servidor Servidor

físico A físico B físico C

5
Mensagens
VIM de hearbeat

Figura 1. Abordagens de disponibilidade para VMs antes da falha.

Fonte: Adaptada de Erl, Mahmood e Puttini (2013).

Na Figura 2, a seguir, é possível observar a ocorrência da falha no servidor

físico 2, que ficou indisponível. Quando os outros servidores físicos e o VIM
param de receber as mensagens de heartbeat do servidor físico 2, o VIM analisa
a capacidade disponível em todos os hypervisors do cluster e escolhe qual
possui maior capacidade. Nesse exemplo, a escolha foi pelo servidor físico 3.
Por meio do dispositivo de armazenamento compartilhado, que contém os
arquivos de configuração dos servidores virtuais, é realizada a migração ao
vivo da VM C (live VM migration), que é um sistema capaz de realocar os
servidores virtuais ou instâncias de servidor virtual em tempo de execução.