O que a queda do Google Cloud pode nos ensinar?

Por Colaborador externo | 31.08.2015 às 14:01

Por Antonio Carlos Pina*

Do dia 13 ao dia 16 de agosto de 2015, a zona chamada “europe-west1-b” do Google Cloud sofreu seguidos incidentes que resultaram inclusive na perda de dados de máquinas virtuais. Durante esses 3 dias foram realizadas manobras de recuperação e sistemas ficaram sem funcionar por tempos variáveis.

Como visto publicamente no dashboard do GCE (Google Cloud Engine), a principal causa foram 4 raios sucessivos que caíram no sistema de fornecimento de energia, provocando um apagão no datacenter e consequentemente o desligamento dos sistemas de storage. Os sistemas foram recuperados durante os 3 dias de incidente com processos diversos, até que se atingiu uma determinada quantidade de dados recuperados pra que o Google definisse como encerrado o incidente, mesmo que perdendo parte das informações. Um ponto importante é que clientes que possuíam snapshots puderam usá-los para recuperação daquele estado específico.

O Google Cloud informou que o incidente afetou 5% de todos os discos, mas que a recuperação de dados foi bem sucedida. A perda de dados foi de 0.000001% do total, um número bastante pequeno, exceto se você for um dos clientes afetados. Nesse caso, percentuais à parte, a perda pode ser considerada gigantesca e inclusive encerrar uma empresa.

Alguns usuários de Cloud podem se assombrar com isso: “Como uma empresa gigante como o Google tem uma queda e perde dados? ”, ou ainda os alarmistas: “Vejam como Cloud é inseguro. Nem o Google consegue fazer funcionar”. Nada mais distante da realidade. São afirmações frutos do desconhecimento de real tecnologia Cloud.

Então, afinal, Cloud é ou não seguro? Meus dados não estão seguros na nuvem? Vamos rever os pontos comuns a todos os provedores Cloud do mercado:

  1. O fato de estar hospedado em uma nuvem não é automaticamente sinônimo de ter tolerância a falhas. Uma das maiores falácias é “vou hospedar no provedor xyz porque ele tem infraestrutura replicada em 3 datacenters”. A infraestrutura sim, é replicada, mas não os dados ou serviços, a não ser que esta informação esteja explícita. Normalmente, storages de objeto (Object Storages) são replicados, mas máquinas virtuais não.
  2. Hardware é hardware e falha – Se o serviço não está explicitamente listado como replicado ou tolerante à falha, assuma que ele pode falhar. Na dúvida, converse com seu provedor de Cloud e pergunte sobre os níveis de tolerância à falha. Nunca assuma nada, pergunte!
  3. O seu backup é sua responsabilidade, a não ser que o provedor de cloud o forneça como parte do serviço. Não parta do princípio que existe um backup automático e que “qualquer problema o provedor pode voltar o backup”. O provedor perguntará: “Que backup?”
  4. Das diversas vantagens do Cloud sobre datacenters físicos, a elasticidade e velocidade de aprovisionamento são imbatíveis. Utilize esses recursos para garantir a segurança de seus dados
  5. Não existe uma definição ou receita única de tolerância à falha. A mesma pode envolver desde redundância de serviços até simplesmente uma recuperação rápida, tudo depende da criticidade do serviço. Seu provedor de Cloud pode ajudá-lo a encontrar a melhor solução com o melhor custo-benefício que atenda suas expectativas.

Por último, mas não menos importante, verifique se seu provedor é especializado em projetos transientes (cria-usa-apaga-cria-usa-apaga) ou projetos de longa duração (cria-usa). Os primeiros normalmente esperam que, se um servidor seu for destruído, você possa criar outro, restaurando os dados de algum lugar. Não é dada tanta importância à resiliência do dado. Já os últimos normalmente são mais preparados para orientar quanto às estratégias de tolerância à falha e de missão-crítica, onde o sistema deve permanecer ligado pelo maior tempo possível.

Em todos os casos, a execução do projeto em parceria com o provedor, analisando as alternativas de forma transparente, garantirá o sucesso vindouro.

*Antonio Carlos Pina é diretor de Tecnologia da Mandic Cloud Solutions.