[18/12/2020 09:43] Identificado instabilidade no ambiente Hyper-V, ocasionando inacessibilidade de acesso no clx-1.spo.platon.net.br
[18/12/2020 09:44] Em investigação
[18/12/2020 10:11] Em processo de mitigação / subindo serviços
[18/12/2020 10:17] Problema mitigado e serviços normalizados
[03/11 13:18] Identificado problema. Investigando...
[03/11 13:36] Iniciando instância e serviços...
[03/11 13:53] Serviços iniciados e acesso normalizado.
[14:35] Notado lentidão de acesso no servidor. Em investigação.
[14:45] Problema mitigado, porém continua em investigação.
[30/08/2020 22:40] Identificado via monitoramento lentidão no acesso aos serviços do servidor de hospedagem compartilhada clx-1.
[31/08/2020 00:36] Identificado que problema de lentidão estava ocorrendo no storage, acionado fornecedor para solução.
[31/08/2020 02:47] Problema corrigido e performance normalizada.
[16:15] Identificado problema no ambiente de hospedagem compartilhada clx-1.
[16:20] Problema está sendo investigado, ainda não havendo previsão exata de retorno devido a investigação estar em andamento.
[17:30] Previsão de retorno de 15 minutos
[17:36] Serviços restabelecidos.
Agendado atividade de manutenção preventiva impactando ambiente de hospedagem compartilhada clx-1.spo.platon.net.br.
[22/07 23:40] Identificado clx-1 como inoperante
[22/07 23:41] Iniciado investigação do problema
[23/07 00:48] Iniciado procedimento de inicialização do servidor...
[23/07 00:49] Servidor iniciado, porém não conclui a inicialização dos serviços.
[23/07 01:00] Investigando junto ao fornecedor possibilidade de problema de conectividade entre equipamentos da nuvem.
[23/07 05:04] Serviços restabelecidos.
Identificado problema em nó do storage. Mitigado e agendado manutenção preventiva para a próxima madrugada.
[15:51] Identificado falha de conectividade com o servidor clx-1.
- [13:53] Alguns clientes informaram não estar acessível as páginas neste servidor, incluindo Webmail;
- [13:55] Identificado que o problema se refere apenas ao Apache (os demais serviços estavam normalizados);
- [13:55] Nos testes realizados foi percebido que em alguns momentos estava acessível, em outros não;
- [14:24] Foi recompilado o serviço do Apache para mitigar o problema;
- [14:30] Iniciado processo de investigação do problema;
- [15:36] Identificado que houve falha de conectividade com o servidor ocsp.comodoca.com, fazendo com que alguns sites que utilizam ssl tivessem resultassem em Timeout, outros entretanto acessavam com lentidão;
- [15:40] Feito contato com fornecedor para entender a causa raíz do problema e a probabilidade de novos problemas, assim como criado plano de contingência para evitar este servidor durante o processo de SSLStapling caso falhas ocorram novamente;
Conclusão: Relatado instabilidade de acesso por alguns clientes, entretanto serviços no servidor relacionado permaneciam ativos e sem aparente problema. Após análise mais apronfundada foi notado que o problema afetava apenas o acesso a sites, mais especificamente com SSL. Concluindo análise dos logs foi identificado uma falha entre 13:52 até 14:20h onde o servidor ocsp.comodoca.com da Agente Certificadora parceira estava tendo problemas na conexão, fazendo com que o processo de SSLStapling não funcionasse em nosso servidor, deixando alguns acessos lentos e em outros casos inacessíveis devido a dificuldade de confirmar a origem do certificado. Para resolver completamente o problema, foi acionado a equipe da Comodo e adicionado o servidor ocsp.comodoca.com no NOC da Platon para identificar futuros problemas. Caso ocorra novos problemas no servidor do fornecedor, será desabilitado o SSLStapling temporariamente, evitando que o problema seja sentido no cliente final.
Pico de processamento que tornou o servidor inacessível e necessitou reboot para restabelecer os serviços.
Pico de processamento que tornou o servidor inacessível e necessitou reboot para restabelecer os serviços.
- [10/09 07:07] Identificada falha em um dos servidores (nós) que compõem o nosso cluster;
- [10/09 07:08] Inicialização da migração automática dos servidores virtuais dos clientes para os demais servidores do nosso cluster;
- [10/09 07:15] Identificada uma falha no serviço de H.A (High Availability) do nosso ambiente ocasionando alertas de “falso positivo”. Por conta do tempo de propagação do falso alerta, alguns servidores virtuais levaram um tempo maior para estabilizar em nosso cluster;
- [10/09 08:05] Finalizado o processo de migração com o restabelecimento do ambiente;
- [10/09 10:55] Problema identificado na conectividade interna da nuvem, não sendo possível acessar os servidores;
- [10/09 10:56] Inicialização da migração automática dos servidores virtuais para os demais servidores do cluster;
- [10/09 11:15] Identificamos erros no processo de migração automática dos servidores virtuais por conta de uma sobrecarga gerada no ambiente. Essa sobrecarga ocasionou o “congelamento” de alguns volumes do nosso storage impedindo o acesso aos “hosts hypervisor”. Esse congelamento dos volumes impediu que os servidores virtuais fossem inicializados;
- [10/09 11:50] Realizada uma parada dos serviços de virtualização e acessos aos volumes de discos para que fossem aplicadas as correções em conjunto com nosso fornecedor;
- [10/09 12:15] Inicialização dos serviços de virtualização e acessos aos volumes de discos;
- [10/09 12:25] Iniciado processo de inicialização dos servidores virtuais;
- [10/09 12:55] Serviços completamente restabelecidos;
Conclusão:
Conforme análise feita em conjunto com nosso fornecedor, identificamos uma falha crítica no serviço de H.A (High Availability), causando um falso positivo, no qual gerou uma movimentação massiva das máquinas virtuais dentro do ambiente do cluster. Durante o processo ocorreram “locks” nos volumes, impossibilitando a estabilização das máquinas virtuais no processo automático de migração entre os servidores (nós). Por este motivo, foi necessário à intervenção da equipe técnica em conjunto ao fornecedor.
Foram aplicadas as correções no sistema de H.A(High Availability) do ambiente para que não sejam registrados novos incidentes de falso positivo. Com essa correção não devemos ter novas ocorrências dessa natureza dentro do nosso ambiente
[14/09 11:25] Identificado pico de processamento que causava lentidão nas contas do servidor clx-1;
[14/09 11:40] Processamento continuou subindo e ocasionou inacessibilidade dos serviços do servidor clx-1;
[14/09 13:20] Restabelecido serviço de emails para recebimento de emails no servidor clx-1;
[14/09 13:50] Iniciado investigação a nível de Sistema Operacional, devido a suspeita em possível falha na integração do módulo CageFS com Apache;
[14/09 16:30] Iniciado investigação paralela a nível de balanceamento de carga entre os nós da nuvem;
[14/09 19:20] Serviço normalizado e picos de processamentos com todos os serviços ativos devidamente controlado;
[14/09 19:40] Concluída atualização de kernel e revisão de configurações relacionadas ao CageFS, LVE e Apache;
[14/09 21:30] Feito troca de nós no balanceamento de carga da nuvem, com intuito de forçar instância a não utilizar nó em que estava quando ocorreu a instabilidade;
[14/09 21:30] Iniciado monitoramento intensivo para detectar processos que possam elevar processamento;
[15/09 08:40] Identificado novo pico de processamento sem impactar contas de clientes;
[15/09 08:50] Processamento normalizado sem afetar nenhuma conta;
[16/09 00:00] Nenhum pico de processamento identificado no decorrer do dia;
[17/09 09:50] Identificado novo pico de processamento, causando lentidão de acesso em algumas contas de clientes;
[17/09 11:00] Processamento contido e desempenho retomado a normalidade;
[18/09 05:00] Iniciado procedimento de ampliação de processadores no servidor clx-1 com reinicialização do servidor concluída as 5:10 h;
[18/09 05:20] Novos picos de processamentos identificados após upgrade de estrutura;
[18/09 11:12] Concluída nova atualização de kernel com patch fornecido pela CloudLinux;
[18/09 11:20] Picos de processamento permaneceram após conclusão da atualização do kernel;
[18/09 01:20] Concluída nova atualização de kernel com novo patch de correção fornecido pela CloudLinux;
[18/09 01:30] Confirmada solução definitiva do problema após reboot com atualização de kernel;
[19/09 15:46] Concluído todo processo de investigação e documentação da falha;
Conclusão:
Após início dos picos de processamento e primeira análise no dia 14/09, duas frentes de trabalho foram montadas para contornar o problema, uma para análise de estrutura (nuvem) junto ao datacenter e outra para análise de sistema operacional junto ao fornecedor do mesmo. Após diversos testes, investigações, ficou-se constatado ser um problema no tratamento dos processos de sistema relacionados ao kernel do Linux, onde não ocorria a devida limitação de consumo de hardware e todos os processos buscavam utilizar o máximo de processamento possível, mesmo após aumento de núcleos dentro da instância; consequentemente, entendeu-se ser um problema com o kernel do sistema operacional, mesmo estando em uma versão stable. Dois novos patches foram fornecidos pela fornecedora do Sistema Operacional, e após aplicação do segundo patch, o servidor voltou a normalidade.
Após utilizarmos apenas versões estáveis de todos os softwares em nossa estrutura de hospedagem de sites compartilhadas, novas medidas de prevenção serão tomadas para evitar que problemas similares possam ocorrer, entretanto destacamos que o Sistema Operacional CloudLinux baseado no kernel da RedHat é um dos sistemas operacionais mais utilizados no mundo, e a probabilidade de conflitos e/ou bugs que possam ocasionar esse tipo de problema são pequenas. Nossa equipe permanece trabalhando em conjunto com a desenvolvedora do Sistema Operacional para lançar a correção aplicada em sua versão stable para inclusive evitar que outras estruturas similares a da Platon possam sofrer com este incidente.
Por fim, destacamos que o problema foi completamente mitigado e nenhuma degradação na estrutura foi detectada, voltando por completo em sua normalidade.
- Instabilidade nos serviços de email e http [15:45]
- Identificado alto processamento no servidor. Feito reboot para obter acesso novamente [16:00]
- Serviço completamente normalizado, entretanto permanece em investigação [16:20]
- Identificado instabilidade no link Algar [09:10]
- Alterado rota de tráfego para evitar instabilidade [09:33]
- Identificado pico de processamento no servidor, onde houve necessidade de reboot;
- Servidor está normalizado, mas permanece em investigação.
- Identificado falha de conectividade interna na rede Platonic Cloud.
- Problema resolvido as 16:33h.
- Investigação permanece ativa...
Conclusão:
Ocorreu a comutação dos volumes e conexões em uma controladora de uma unidade de storage que suporta o ambiente do Platonic Cloud, onde a controladora passiva recebeu os volumes e conexões, porém houve perda das conexões neste processo, afetando parte do ambiente atendido por este equipamento. Todos os fabricantes foram acionados afim de certificarmos que a causa raiz fosse mapeada para evitar novas ocorrências do mesmo problema. Será agendada janela emergencial, no dia 22/06/2018 à partir das 23h59, com duração esperada de 1h, que não prevê indisponibilidade, para aplicação de nova versão/atualização da unidade de storage, bem como foi recomendado pelo fornecedor do sistema utilizado em nosso cloud a alteração de parâmetros de reconexão, para evitar o comportamento inesperado.
- Falha resolvida as 18:43, porém, alguns servidores precisaram ser reiniciados.
- Todos os servidores e serviços foram restabelecidos as 19:00h.
Foi identificado um possível ataque de força bruta no servidor clx-1.spo.platon.net.br.
- Está sob investigação [14:12]
- FTP temporariamente desabilitado para investigação mais aprofundada [15:20]
- FTP reabilitado, porém, permanece em monitoramento [16:30]
Será realizada manutenção preventiva no servidor clx-1.spo.platon.net.br, onde poderá ocorrer instabilidades de acesso a este servidor nos 20 minutos programados de manutenção.
Detectado instabilidade na comunicação do Datacenter com a internet.
A razão disso parece estar relacionada a múltiplos circuitos gerando erros pelos provedores de link. Nós re-roteamos o tráfego para outros provedores e a partir disso a conectividade foi normalizada para nossos clientes.
Nós ainda estamos trabalhando na causa primária do problema neste momento. Mais informações serão fornecida quando estiver tudo normalizado.
- Detectado lentidão na conexão com o servidor.
- Problema com backbone Verizon em verificação.
- Problema com backbone Verizon confirmado. Utilizado pelas operadoras GVT e Unifique na região Sul do Brasil.
- Rota com GVT modificada, resolvido parcialmente.
Identificado problemas com o MySQL, resultando no uso elevado de processamento e consequentemente na instabilidade do serviço.
Localizado a conta que estava causando o excesso de uso de processamento e realizado a suspensão da mesma, normalizando o serviço.
Ocorreu um incidente que resultou no rompimento em 3 pontos da fibra ótica fornecida pela Gvt ao nosso datacenter.
