Olá, DreamHosters!
Recentemente, o DreamObjects sofreu uma interrupção prolongada. O serviço ficou amplamente inacessível por um período de aproximadamente seis horas na sexta-feira, 13 de junho, e novamente por um segundo período de aproximadamente quatro horas no sábado, 14 de junho. Queríamos oferecer algumas informações sobre o que aconteceu e o motivo da interrupção.
Primeiro, para contexto, vamos discutir como o DreamObjects funciona. O DreamObjects existe como um cluster de servidores, onde cada servidor possui vários discos rígidos. A maioria dos servidores no cluster executa um software chamado Ceph, que é um sistema de armazenamento distribuído e tolerante a falhas.
Um sistema de armazenamento distribuído é aquele que armazena dados em várias unidades, e frequentemente essas unidades estão distribuídas por vários servidores. Um sistema de armazenamento tolerante a falhas é aquele que pode lidar com a perda de uma ou mais unidades, ou até mesmo de servidores inteiros, ou racks de servidores, sem perder dados. Ceph (e, portanto, DreamObjects) é ao mesmo tempo distribuído e tolerante a falhas. Em resumo, qualquer coisa que você nos envie é escrita em três unidades para proteger a integridade e a durabilidade dos seus dados.
Isso não quer dizer que cada máquina no cluster tenha a função de armazenar seus dados. Algumas – os gateways – são as máquinas com as quais você realmente se comunica através das APIs HTTP S3 ou Swift. Esses gateways então emitem solicitações em seu nome para as máquinas que realmente armazenam os dados.
E isso nos leva à causa raiz da interrupção: TL;DR os gateways não conseguiam se comunicar com os servidores de armazenamento backend, e assim o serviço parecia estar “desativado” apesar do fato de que o sistema de armazenamento subjacente estava ativamente trabalhando; ocupado garantindo que seus dados estavam seguros.
Na sexta-feira, uma alteração foi feita no “CRUSH map”, que indica ao Ceph como os dados devem ser divididos entre os servidores e discos que compõem o DreamObjects. Essas mudanças precisavam acontecer, mas não deveriam ter sido feitas todas de uma vez. Isso resultou em tanta movimentação de dados dentro do backend do cluster que as solicitações vindas dos gateways não puderam ser atendidas de maneira oportuna. Pela segurança dos dados – que é a primeira função de qualquer sistema de armazenamento – o Ceph dá prioridade ao movimento interno de dados sobre as solicitações dos gateways. Nossos engenheiros efetivamente, e bastante inadvertidamente, criaram um ataque de negação de serviço interno contra o DreamObjects. A alteração no mapa foi feita como resultado de um problema urgente com o próprio cluster do Ceph. Essa mudança, no entanto, foi feita às pressas e deveria ter sido implementada mais lentamente durante uma janela de manutenção pré-agendada (e anunciada).
A interrupção de sexta-feira foi agravada por um bug na versão do Ceph que estávamos executando naquele momento. Esse bug estava fazendo com que drives individuais se tornassem inacessíveis repetidamente, o que aumentou drasticamente o tempo de recuperação após a mudança do mapa. Cerca de metade do caminho através da interrupção, decidimos atualizar o Ceph. Isso, em última análise, permitiu que o cluster retornasse à saúde muito mais rápido do que poderia ter ocorrido normalmente.
No sábado, outro bug foi descoberto devido ao estresse da recuperação contínua do cluster e isso também nos fez perder acesso a unidades individuais repetidamente. Nossos amigos da Inktank gentilmente desenvolveram uma versão personalizada de Ceph para nós para resolver o problema.
Em resumo, a interrupção do DreamObjects foi resultado de uma alteração excessivamente agressiva na nossa configuração do Ceph e foi piorada por bugs latentes dentro do Ceph. No final, conseguimos resolver rapidamente todos os problemas com a ajuda da Inktank e o próprio Ceph foi fortalecido graças às nossas descobertas. Também é importante notar que o sistema de Storage subjacente funcionou conforme projetado, garantindo que os dados dos clientes estavam seguros e nunca em risco.
Estamos absolutamente comprometidos em garantir a alta qualidade e disponibilidade de todos os nossos serviços. A equipe de DreamObjects identificou uma série de mudanças em nosso código, processos e procedimentos para garantir que esse tipo de interrupção não aconteça novamente. Nomeadamente, os engenheiros de operações estarão auditando as mudanças no “CRUSH map” através de um processo de revisão mais rigoroso, incluindo revisão externa pela Inktank, os criadores do Ceph. Além disso, mudanças dessa magnitude serão anunciadas com bastante antecedência e realizadas em horários de menor movimento para limitar o risco.
Uma última coisa.
Todos os clientes do DreamObjects receberão 10% de desconto em sua fatura para o mês de junho de 2014.
Muitos agradecimentos são devidos aos nossos colegas da DreamHost em Operações de Centro de Dados, Suporte Técnico e Operações na Nuvem; e às ótimas pessoas da Inktank, por trabalharem incansavelmente para restaurar a disponibilidade e proteger os dados dos clientes.
