Nem todas as aplicações pertencem à cloud pública. Um controlo de máquina que tem de responder na ordem dos milissegundos, um sistema de gestão de mercadorias com grandes volumes de dados locais, um procedimento especializado com exigências rigorosas de soberania de dados – tais cargas de trabalho correm, por boas razões, onde surgem: nas próprias instalações. A latência, o controlo sobre os dados e a estrutura de custos com carga constante falam então claramente a favor do servidor local.
O problema não é o servidor local. O problema é o servidor local como único lugar. Uma sala de servidores num único local é uma construção de ponto único de falha – contra incêndio, danos por água, roubo, falha de energia e, há muito o caso mais frequente, contra um atacante que cifra toda a rede ao mesmo tempo. Quem quer manter as vantagens da operação local sem aceitar a sua fragilidade não escapa a uma pergunta: o que acontece se essa única sala amanhã já não existir?
A falsa alternativa: ou local ou cloud
A narrativa difundida diz que é preciso decidir – centro de dados ou sala de servidores própria, cloud ou on-premises. Isso é uma falsa alternativa. A operação local resolve exigências reais de latência e de soberania de dados que uma migração puramente para a cloud não elimina com argumentos. Por outro lado, o centro de dados externo resolve o risco associado ao local que uma operação puramente local não cobre estruturalmente. Ambos os lados são fortes para tarefas distintas.
A resposta sustentável não é um ou outro, mas uma divisão de trabalho: os sistemas produtivos correm onde pertencem – no local. O seu backup e um caminho de reinício ficam onde sobrevivem a um evento local – no centro de dados geograficamente separado. Chamamos a isto ponte híbrida: operação local e capacidade externa de reinício como um único modelo operacional contínuo, não como dois contratos separados.
O que permanece local – e o que é replicado
A divisão não segue nenhuma ideologia, mas a pergunta sobre onde uma carga de trabalho gera o seu benefício e onde é necessária uma cópia em caso de incidente.
Local permanece a operação produtiva. Tudo o que beneficia de caminhos curtos e baixa latência ou precisa de grandes volumes de dados constantemente acessíveis corre no servidor nas instalações: hosts de virtualização, serviços de ficheiros e de bases de dados, aplicações especializadas, proximidade às máquinas e ao local. Aqui conta o tempo de resposta, aqui conta o controlo total sobre o local físico dos dados.
Replicada é a capacidade de recuperação. Para o centro de dados externo não migra a operação produtiva, mas a sua proteção: pontos de backup consistentes das máquinas virtuais e dos dados – como cópia replicada fora das instalações, geograficamente separada do original. Assim, a última cópia nunca está apenas num lugar, e o reinício não depende precisamente do edifício que o incidente atingiu.
Que pelo menos uma cópia adicional tem de estar armazenada de forma imutável, para que sobreviva a um atacante com privilégios de administrador, é a segunda condição. Como a imutabilidade e a regra alargada 3-2-1-1-0 funcionam tecnicamente descrevemos detalhadamente noutro lugar; para este modelo operacional basta o lema: a cópia replicada no centro de dados só é uma verdadeira opção de recurso se não puder ser nem apagada nem alterada a partir da rede comprometida.
O verdadeiro ganho: reinício centralizado
Uma cópia de backup fora das instalações é pré-requisito, mas ainda não todo o valor. Decisivo é o que acontece com essa cópia em caso de incidente.
Se a sala de servidores local falhar – seja por incêndio, dano total de hardware ou cifragem – os serviços podem ser reiniciados de forma centralizada no centro de dados a partir da cópia replicada, enquanto o ambiente local é restaurado com calma. Isso desacopla dois relógios que, de outra forma, estão implacavelmente acoplados: o tempo até a operação voltar a funcionar e o tempo até a sala de servidores estar novamente operacional. Sem essa ponte, o negócio espera pela reparação do hardware. Com ela, os serviços críticos continuam a funcionar de forma centralizada, e a restauração local passa de uma emergência a um trabalho planeado.
É precisamente aqui que está a diferença entre «temos um backup» e «conseguimos voltar a arrancar». Um backup que está na mesma sala em chamas não cumpre a segunda afirmação.
RTO e RPO: os números antes da técnica
Quão rapidamente e com que estado de dados um serviço tem de voltar a funcionar é uma decisão de negócio, não técnica. Dois indicadores tornam-na discutível:
- RTO (Recovery Time Objective) – durante quanto tempo pode um serviço ficar parado após uma falha? Minutos, horas, um dia útil?
- RPO (Recovery Point Objective) – quanta perda de dados é suportável? O estado de há uma hora, da última noite, do fim de semana?
Estes valores variam conforme o serviço – e é neste ponto que a ponte híbrida justifica o seu custo. Um sistema ERP com RTO de duas horas e RPO de 15 minutos precisa de replicação frequente e de um reinício preparado no centro de dados. Um arquivo que, guardado uma vez por dia, suporta um dia de atraso, não precisa disso. Quem aplica a tudo o valor mais rigoroso paga por reservas de que ninguém precisa; quem aplica a tudo o valor mais permissivo só descobre a lacuna no incidente. A sequência correta é: primeiro priorizar os processos e definir as suas metas de RTO/RPO, depois dimensionar a frequência de replicação e o caminho de reinício em conformidade.
E porque um plano de reinício sem comprovação é apenas uma alegação, faz parte da ponte híbrida o cenário de incidente ensaiado: as recuperações são testadas, não presumidas. O enquadramento estruturado para isso – da priorização de processos ao plano de contingência documentado – pertence a um conceito de business continuity bem pensado, e não a um palpite.
Um modelo operacional, não um produto
O atrativo desta arquitetura está no facto de não impor nada de que a operação não precise de qualquer forma. Os servidores ficam onde a latência e a soberania de dados o exigem. A proteção fica onde um evento no local não a alcança. E a atribuição não está gravada em pedra: se a exigência mudar – uma carga de trabalho torna-se apta para a cloud, outra tem de voltar para as instalações por razões de compliance – a fronteira desloca-se, sem que o modelo tenha de ser reinventado. Importante é apenas que a cópia replicada e o caminho central de reinício sejam planeados desde o início, e não surjam como uma adaptação cara após a primeira falha.
Como a sector7 apoia
Planeamos, adquirimos e operamos servidores, storage e virtualização diretamente nas suas instalações – como parceiro HPE em condições de parceiro e, em caso de necessidade fundamentada, também Dell, Fujitsu ou sistemas especiais mediante consulta. A proteção implementamo-la com base em Veeam e replicamo-la para o nosso próprio parque de servidores, geograficamente redundante, na Alemanha – para que a última cópia nunca esteja apenas num lugar e os serviços possam reiniciar de forma centralizada em caso de incidente, enquanto restauramos o seu ambiente local. Os novos sistemas passam a ser acompanhados, de forma documentada, pela nossa monitorização NOC 24 horas por dia. Como empresa gerida pelo proprietário, sediada em Solingen e certificada pelos fabricantes para Juniper, Cisco, HPE, F5, Fortinet e Palo Alto Networks, reunimos proximidade local e centro de dados num só fornecedor. Como construímos e protegemos a sua infraestrutura local descrevemos na nossa página Servidor e Backup local.