![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
O objetivo de uma política de failover da nuvem é garantir que o serviço da nuvem esteja disponível pelo menos 99,5 por cento do tempo. Ele deve focar em como um aplicativo Software como Serviço (SaaS), plataforma Platform as a Service (PaaS) ou máquinas virtuais Infrastructure as a Service (IaaS) em execução em um serviço da nuvem pode ser transferido de um datacenter com falha para um em funcionamento a fim de fornecer serviço quase ininterrupto a clientes da nuvem.
Os usuários da nuvem querem evitar uma falha catastrófica de um serviço da nuvem como a indisponibilidade da rede que pôs abaixo a região (da Virgínia do Norte) nos EUA da Amazon pelo menos duas vezes:
- Em 2007, o Serviço da Amazon Elastic Compute Cloud (EC2) foi afetado.
- Em 2011, a solução da Amazon Cloud Computing PaaS, EC2 e Relational Database Service foram afetados.
As outras duas regiões de datacenter da Amazon nos Estados Unidos continuaram a executar com bom funcionamento.
Na região da Virgínia do Norte, os volumes de armazenamento que o serviço EC2 da Amazon usava automaticamente criavam backups deles mesmos ao preencher a capacidade de armazenamento. Quando os backups automáticos tentaram armazenar eles mesmos além do limite máximo da capacidade de armazenamento, a indisponibilidade foi o resultado. A rede não tinha onde armazenar mais backups.
Uma indisponibilidade deste tipo pode fazer com que os clientes percam milhares de horas de dados. Este artigo mostra como evitar esses tipos de perdas. Ele descreve a política de failover da nuvem, riders específicos da nuvem e cenários de parada do dano, correção do problema, restauração do sistema e notificação de clientes.
A seguir, exemplos de quais componentes e tarefas devem ser incluídas em um rider específico a Saas para uma política de failover de nuvem proativa.
Devido ao controle limitado que um usuário SaaS tem, o rider específico a SaaS contém um mínimo de três componentes:
- Controle do usuário
- Licença de usuário
- Um plano de failover
O único controle que um usuário SaaS tem é acessar os aplicativos SaaS para executar funções de negócios. O componente da licença de usuário, como negociado com o provedor, deve especificar o número máximo de:
- Aplicativos SaaS para acessar.
- Usuários simultâneos para acessar um aplicativo.
- Solicitações alocadas para cada usuário.
O componente de licença do usuário deve especificar tipos de aplicativos SaaS que os usuários têm permissão de acessar, como finanças, gerenciamento de projeto, relações com o cliente, gerenciamento de varejo e até mesmo scanner de vulnerabilidade com o IBM Rational AppScan.
O componente do plano de failover deve afirmar que as instâncias do aplicativo SaaS estão a postos para permitir failover de um centro hospedado ao outro. Ele deve indicar ofertas ao provedor, serviços de backup e serviços (SLAs) e estar em conformidade com as leis de privacidade de dados como o Federal Privacy Act e o Electronic Documents Act.
No mínimo, os usuários SaaS devem ter permissão de:
- Acesse o aplicativo SaaS até o número máximo de acesso por usuário.
- Atualize registros baseados nas funções que os usuários estão designados.
- Receba alertas de segurança.
Apenas o provedor pode:
- Comprar uma licença de upgrade de software.
- Gerenciar correções com aplicativos SaaS.
- Acessar aplicativos do sistema e máquinas virtuais.
- Acessar as máquinas virtuais subjacentes da infraestrutura de computação tradicional.
Quando um aplicativo SaaS falha, o provedor deve especificar como é possível fazer failover do aplicativo SaaS do datacenter com falha para um em funcionamento no tempo mais curto possível (com períodos não mais longos que cinco minutos) e como pode restaurar o aplicativo após corrigir os problemas.
Vamos observar um cenário de falha do SaaS para ilustrar este conhecimento.
Aplicativos CRM sob premissa de uma empresa foram migrados com sucesso como aplicativos SaaS para um provedor externo que hospeda um ambiente de vários proprietários nas regiões do datacenter nos Estados Unidos. Quando uma falha de rede em um datacenter derrubou o sistema por alguns dias — , devido a backups automáticos de dados de armazenamento que preenchem toda a capacidade de armazenamento e não deixam lugar algum na rede para armazenar 200 milhões de transações de todo o mundo, — uma revolta de reclamações aconteceu (como seria esperado):
- Os vendedores gritaram.
- Os telefones nas centrais de atendimento de ajuda tocaram alto e o tempo todo por dias.
- O provedor suspirou (quando descobriu-se que não seria possível obter os aplicativos CRM SaaS de volta no serviço em dois minutos após a falha, como garantido em um SLA negociado com os usuários SaaS).
Louco por soluções rápidas, o provedor colocou um aviso em seu website "Por favor, aguarde... resolveremos problema no sistema em breve." Não foi bom o bastante.
Levou alguns dias para que o provedor obtivesse os aplicativos SaaS em funcionamento. O provedor não pôde fornecer failover efetivo. A seguir, estão as ações proativas que o provedor pode tomar para parar o dano, corrigir os problemas, restaurar o sistema e notificar os clientes.
Para parar o dano, planeje o futuro preparando os aplicativos SaaS como instâncias para failover automatizado. O SLA como negociado entre o assinante SaaS e o provedor deve estar a postos. Quando o desempenho recai muito abaixo do nível da disponibilidade de serviço garantida (99,9 por cento), um alerta deve ser enviado ao provedor. O desempenho que foi abaixo do nível pode voltar ao nível garantido quase instantaneamente dependendo do tráfego na rede.
Enquanto isso, os clientes SaaS são notificados de que o serviço é continuado em outro datacenter enquanto o provedor está corrigindo os problemas.O provedor os deixará saber quando o serviço é restaurado no datacenter de origem.
(Observe que existe um forte elemento de notificação em todas as ações proativas descritas nessas políticas: deixar que as partes interessadas saibam o que está acontecendo em suas operações pode geralmente lhe dar mais tempo de corrigir um problema, manter os clientes no escuro sobre uma situação legítima sempre funcionará para sua desvantagem.)
O provedor pode planejar o futuro para o failover e ter uma política de failover a postos:
- Instale instâncias do aplicativo SaaS para permitir failover de um datacenter a outro.
- Verifique periodicamente para determinar se as fitas de backup estão funcionando adequadamente e livres de defeitos.
- Teste para ver se o software de rede pode corrigir o problema como é pretendido fazer.
A próxima etapa é começar a restaurar o sistema no datacenter onde o sistema foi danificado. O provedor configura um ambiente de teste para testar a resiliência do sistema restaurado para garantir failover relativamente flexível a outro datacenter. Por exemplo, o provedor aleatoriamente elimina recursos e serviços e anota os resultados.
Quando o teste é concluído, o provedor faz backup de uma cópia do sistema restaurado antes de movê-lo para um ambiente de produção.
Assim que os aplicativos SaaS forem restaurados no datacenter que foi danificado, o provedor notifica seus clientes de que a restauração foi concluída e os termos de SLA (crédito livre, reembolsos, uma oportunidade de encerrar) serão realizados.
Que componentes e tarefas devem ser incluídos em um rider específico a PaaS para uma política de failover de nuvem?
Os desenvolvedores PaaS têm mais controle, então o rider específico a PaaS deve conter um mínimo de um componente a mais que o rider SaaS — a capacidade de desenvolver aplicativos (os componentes para um desenvolvedor PaaS são controle de usuário, licença do desenvolvedor, desenvolvimento de aplicativo (não disponível para um usuário SaaS) e um plano de failover).
Um desenvolvedor PaaS controla o desenvolvimento de aplicativos SaaS e todos os aplicativos encontrados em um ciclo de vida de negócios integral; por exemplo, planilhas, processadores de texto e backups.
O componente de licença do desenvolvedor como negociado com o provedor deve especificar o número máximo de:
- Aplicativos a desenvolver.
- Número de desenvolvedores de aplicativos simultâneos permitidos.
- Número de usuários SaaS que acessam a requisição no PaaS permitido.
O componente de desenvolvimento de aplicativo deve especificar os tipos de aplicativos a desenvolver, como:
- Aplicativos SaaS
- Websites
- aplicativos de CRM
- Aplicativos remotos
- Aplicativos de faturamento e folha de pagamento
- Aplicativos de Service Delivery Platform (como TV remota)
- Aplicativos de gerenciamento de entrega de conteúdo
Um componente de planejamento de failover deve especificar que as instâncias do aplicativo SaaS estejam a postos para permitir failover de um centro hospedado a outro. O componente deve especificar se um desenvolvedor PaaS usaria seu próprio aplicativo ou ode failover do provedor e se ele poderia empregar ferramentas de terceiro para tarefas como balanceamento de carga. O plano deve também indicar se o provedor oferece serviços de backup e SLAS e se está em conformidade com as leis de privacidade de dados.
Os desenvolvedores PaaS têm permissão de:
- Criar, implementar e executar aplicativos.
- Gerenciar correções e upgrades.
- Determinar quais usuários SaaS podem acessar os aplicativos SaaS coexistentes no PaaS.
- Customize flexivelmente suas plataformas para reagir com condições de mercado local.
Eles também têm permissão de:
- Varrer aplicativos em busca de vulnerabilidades
- Configurar firewalls de aplicativo
- Criar e monitorar alertas de segurança.
- Executar operações de backup
No mínimo, apenas o provedor pode:
- Executar aplicativos do sistema.
- Executar máquinas virtuais.
- Acessar as máquinas virtuais subjacentes da infraestrutura de computação tradicional.
Vamos observar um cenário de falha PaaS para ilustrar este conhecimento.
Um aplicativo de "otimização de recurso" do desenvolvedor PaaS falha. A falha causa o encerramento completo desta plataforma e de outras plataformas PaaS hospedadas pelo mesmo provedor. Poderia ter sido causada por falha em criar instâncias de serviço replicadas que podem sobreviver a falhas de host. Infelizmente, o aplicativo de "otimização de recurso" não identificou falhas nem implementou tempos limites curtos e novas tentativas rápidas.
A seguir as ações proativas que o provedor pode tomar ao implementar os termos do rider específico PaaS negociado com o provedor ao para o dano, corrigir os problemas, restaurar o sistema e notificar clientes.
Para parar o dano, o desenvolvedor PaaS cria serviços simples compostos de um único host em vez de vários hosts dependentes. Isto permite que o desenvolvedor crie instâncias de serviço replicadas que possam sobreviver a falhas de host.
Quando acontecem falhas, o software do desenvolvedor deve rapidamente identificar essas falhas e começar o processamento failover.
Vamos supor que o desenvolvedor tenha um aplicativo de faturamento que consista de componentes de lógica de negócios... A, B e C... ele pode compor um grupo de serviços como este:
(A1, B1, C1), (A2, B2, C2) ... (An, Bn, Cn)
Where n is the number of component type representing the number of a
service group category
for service category 1,
A1 is the logic to find service code
B1 is the logic to insert service category into the bill
C1 is the logic to check the accuracy of zip codes
for service category 2,
A2 is the logic to find service code
B2 is the logic to insert service category into the bill
C2 is the logic to check the accuracy of zip codes
for service category n,
An is the logic to find service code
Bn is the logic to insert service category into the bill
Cn is the logic to check the accuracy of zip codes
|
Se uma única máquina virtual executando o PaaS falhar, a falha resultará na perda de todo o grupo do sistema. Isto significa que se o componente A1 falhar em um grupo do sistema, os outros dois componentes, B1 e C1 falham. Se houver mais de um grupo de serviços, todo o sistema falha.
Para corrigir o problema, o desenvolvedor decompõe os componentes nos conjuntos independentes como este:
(A1, A2,...An ), (B1, B2...Bn ), (C1, C2, ...Cn) |
Para que ele possa criar diversas cópias de serviço redundantes em datacenters em funcionamento. Isto significa que se o componente A1 falha ou é encerrado, todos os outros componentes A2... An no mesmo conjunto independente não falham. Os segundos conjuntos independentes de componentes B1,
B2...Bn e o terceiro conjunto de componentes C1, C2, ...Cn não falham.
O desenvolvedor usa tempos limites rápidos e tenta novamente os serviços lentos enquanto o failover de todos os conjuntos de serviço independentes do aplicativo de faturamento está em andamento. O desenvolvedor precisa determinar quando parar tempos limites e tenta novamente evitar o bloqueio do sistema resultante do consumo de todos os recursos que aguardam em serviços lentos ou com falha.
A próxima etapa é começar a restaurar a plataforma SaaS no datacenter em que o sistema foi danificado. Em um ambiente de teste, o provedor aleatoriamente para os recursos e serviços subjacentes no PaaS. O teste de desenvolvedor testa os aplicativos em várias condições para testar a resiliência do PaaS. Quando o teste é concluído, o provedor faz backup do sistema restaurado antes de ser movido para um ambiente de produção.
Assim que os aplicativos PaaS estão em execução no datacenter restaurado, o provedor notifica os desenvolvedores PaaS no sistema restaurado e os termos do SLA são realizados.
Finalmente, que componentes e tarefas devem ser incluídos em um rider específico a IaaS para uma política de failover da nuvem?
Como o IaaS é a base do nível do PaaS, o rider específico a IaaS deve conter um conjunto diferente de componentes. Além do controle do usuário, licença corporativa e um plano de failover, você encontrará um componente para máquinas virtuais.
Um especialista IaaS controla máquinas virtuais; os desenvolvedores PaaS e usuários SaaS não.
A licença corporativa deve especificar o número máximo de:
- Máquinas virtuais a desenvolver, executar e manter.
- Especialistas IaaS a acessarem simultaneamente as máquinas virtuais.
- Desenvolvedores PaaS a trabalharem com máquinas virtuais IaaS.
Um plano de failover deve permitir failover de máquinas virtuais IaaS de um centro hospedado a outro. Ele deve permitir que a infraestrutura IaaS e os especialistas de rede trabalhem com desenvolvedores PaaS para configurar máquinas virtuais de failover.
O especialista IaaS pode:
- Desenvolver, gerenciar e acessar máquinas virtuais.
- Autorizar desenvolvedores PaaS a desenvolverem aplicativos em máquinas virtuais.
- Usar ferramentas de terceiros para aumentar o desempenho (por exemplo, um balanceador de carga) e proteger dados do sistema.
- Varrer máquinas virtuais em busca de vulnerabilidades.
Esses especialistas também têm permissão de:
- Configurar firewalls de máquina virtual.
- Criar e monitorar alertas de segurança.
- Fazer backup de máquinas virtuais.
Apenas o provedor pode acessar a infraestrutura das máquinas virtuais subjacentes aos recursos de computação tradicionais. O especialista IaaS não pode.
Vamos observar um cenário de falha do IaaS para ilustrar este conhecimento.
As máquinas virtuais falham devido à falta de recursos adicionais necessários para consumo em altos pontos de E/S. Em outras palavras, não existem instâncias virtuais para permitir failover em um datacenter em funcionamento.
O provedor pode tomar as seguintes ações proativas.
Para parar o dano, planeje quantos recursos são necessários para executar máquinas virtuais em altos pontos de E/S. Isto pode ser feito por meio do planejamento de capacidade e políticas de limite de desempenho, por exemplo. (Há outros artigos mais detalhados na seção Recursos que lidam com políticas de limite e planejamento de capacidade.)
Para corrigir o problema, estabelecer políticas de limite de desempenho para determinar quando fornecer as máquinas virtuais necessárias durante altos períodos de E/S e como garantir que todos os pontos de ativação de serviço sejam atendidos. Certifique-se de que suas instâncias de máquina virtual nos datacenters que o host controla estejam a postos.
Além disso, quando ocorrem falhas, planeje que elas sejam rapidamente identificadas e que o provedor transfira as instâncias de máquina virtual baseadas em IaaS para outro datacenter.
A próxima etapa é começar a restaurar a plataforma IaaS no datacenter onde o sistema foi danificado. Em um ambiente de teste, o provedor pode aleatoriamente para os recursos e serviços subjacentes no IaaS. Após o teste ser concluído, o provedor faz backup do sistema restaurado antes de ser movido para um ambiente de produção.
Assim que as máquinas virtuais estejam em execução no datacenter restaurado, o provedor notifica especialistas IaaS na restauração completa de máquinas virtuais no datacenter.
A anatomia de uma política de failover da nuvem efetiva requer um planejamento de política proativa para:
- Determinar por que acontecem falhas na nuvem.
- Identificar essas falhas.
- Preparar riders específicos de nuvem na política para agir contra proativamente as variáveis responsáveis por essas falhas.
Sua equipe de desenvolvedores, usuários e provedores precisa trabalhar junto para compor a política e os riders. A equipe descobrirá que resolver os problemas sobre quais elementos, componentes e tarefas devem ser incluídos torna sua tarefa de categorizar a política muito mais fácil.
Neste artigo, eu tratei sobre os componentes e tarefas básicos que devem ser considerados como parte de uma política de failover em cada modelo de computação em nuvem — SaaS, PaaS e IaaS. Eu também forneci sugestões sobre como o provedor pode prosseguir para parar o dano, corrigir o problema, restaurar o sistema e, claro, notificar o cliente, para cada modelo.
Outros artigos (em Recursos) se aprofundam na definição dos elementos de política de propósito, escopo, plano de fundo, ações e restrições que ajudarão a rascunhar políticas de computação de nuvem para lidar com acionadores de limite, balanceamento de carga de trabalho, segurança geral, acesso remoto, migração de aplicativo, gerenciamento de risco de serviço, métricas de desempenho e mais. Em todas as instruções de política que eu forneci, confiabilidade e segurança estão sempre incluídas como componentes subjacentes principais.
Aprender
-
Saiba mais sobre o planejamento de capacidade para implementação da nuvem em "Segredo do Sucesso da Nuvem: Planejamento de Capacidade Flexível."
-
Esses artigos sobre criação de política do autor o levarão a um próximo nível:
- "Crie política de segurança para dispositivos móveis." (Segurança, remota)
- "Balancear carga de trabalho em um ambiente de nuvem: usar políticas de limite para balancear dinamicamente demandas de carga de trabalho." (Limite, carga de trabalho)
- "Computação em nuvem versus computação em grade: tipos de serviço, similaridades e diferenças e outros aspectos a serem considerados." (Mais políticas de limite)
- "Crie políticas de limite proativas na nuvem." (Limite)
- "Altere o comportamento dos aplicativos: dos aplicativos internos para a nuvem." (Migração de aplicativo)
- "Serviços em nuvem: reduza os riscos, mantenha a disponibilidade." (Mitigação de risco de serviço, confiabilidade)
- "Crie uma política de métricas de desempenho da nuvem." (Métricas de desempenho, teste, monitoramento)
-
Nos recursos de desenvolvedor da nuvem, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão desenvolvendo os seus projetos de implementação de nuvem.
-
Mais recursos do developerWorks que correspondem a este artigo podem ser localizados em SOA e serviços da web no developerWorks e segmentos de mercado no developerWorks.
-
Descubra como acessar o IBM SmartCloud Enterprise.
Obter produtos e tecnologias
-
Consulte as imagens do produto disponíveis para IBM SmartCloud Enterprise.
Discutir
-
Faça parte de um grupo de computação em nuvem no developerWorks.
-
Leia todos os ótimos blogs sobre nuvem no developerWorks.
-
Faça parte da comunidade do developerWorks, uma rede profissional e conjunto de ferramentas comunitárias para conectar, compartilhar e colaborar.
Judith M. Myerson é arquiteta e engenheira de sistemas. Suas áreas de interesse incluem sistemas corporativos, tecnologias de middleware, tecnologias de banco de dados, computação em nuvem, políticas de limites, segmentos de mercado, gerenciamento de rede, segurança, tecnologias de RFID, gerenciamento de apresentações e gerenciamento de projeto.
