Redundância e alta disponibilidade SCADA: hot standby, RAID e operação 7×24

Em que casos o servidor único vira risco de parar a linha

Um único servidor SCADA cabe em linha-piloto, laboratório, ou campo que consegue produzir algumas horas sem a tela do software supervisório. Quando o turno organiza a produção por essa tela, antecipa problema pelo alarme, ou relatório de qualidade e energia ainda lê o histórico na mesma máquina, o servidor único deixa de caber.

O que de fato fere raramente é o travamento dramático. Mais comum é disco cheio, atualização do sistema emperrada, módulo de alimentação queimado, placa de rede que cai — e o turno seguinte é que descobre que a tendência não abre. A pergunta não é se o servidor vai falhar: é quanto a linha aguenta sem ele, e se os minutos de dado ainda estarão lá quando voltar.

• Produção contínua, sem janela: linha discreta, processo contínuo, grupo de estações de bombeamento ou utilidades da planta não esperam reinstalar uma máquina
• A tela é o posto de operação: partida/parada, descarga de receita e confirmação de alarme acontecem nessa tela, não só no painel ao lado da máquina
• Histórico e runtime no mesmo disco: o disco falha e somem juntos a tela de campo e a evidência que qualidade e energia usam
• O driver de comunicação só está nessa máquina: sessões de PLC, OPC e gateway caem com o host; mesmo trazendo um PC reserva, sem o canal montado o campo não se vê
• Plantão 7×24 com turno da noite enxuto: o plantonista confirma alarme, mas não restaura o espelho do servidor às duas da manhã

Se duas ou mais das acima se aplicam, o servidor único deixa de ser economia: é aceitar, por omissão, que falha de servidor equivale a poder parar a produção.

O que hot standby e cluster precisam sincronizar

Comprar mais uma licença e colocar outro computador ao lado ainda não é hot standby. Para a comutação valer, a reserva já precisa ter a cópia que o operador usa nos poucos segundos em que se troca. Quatro coisas costumam ser lembradas só na primeira comutação de verdade: base em tempo real, histórico, engenharia de tela, canais de comunicação.

Na entrega, tratamos cluster redundante e hot standby em duas máquinas como escolha de arquitetura, não como item de checklist na cotação. As duas máquinas combinam quem é o host, como o estado se copia, o que o operador vê na comutação. Atualização de tela em segundos no nó sobrevivente só tem sentido se os pontos atrás ainda estão sendo coletados.

• Base em tempo real: valor atual do ponto, estado de alarme, intertravamento e setpoint em memória. Se a reserva atrasar alguns segundos, o turno já opera errado pela tela
• Histórico: tendência, evento e curva de processo. RAID1 no disco não significa que a segunda máquina tenha cópia; histórico partido após a comutação é problema de qualidade e auditoria, não só de TI
• Engenharia de tela: telas, amarração de pontos, scripts, permissões de usuário e recursos multilíngues. O runtime sobe contra o arquivo de engenharia de ontem, o banco é novo e a tela também estará errada
• Canais de comunicação: caminho PLC, sessões OPC UA/DA, enlaces de gateway e a qual placa de rede estão amarrados. Se o canal só vive no host, a reserva ao subir vê uma fábrica vazia

Um ensaio que se consegue fazer: enquanto o operador olha tendência e confirma alarme, desconecte o host. Se a reserva não apresentar o mesmo conjunto de pontos, a mesma lista de alarmes e o trecho de histórico que acabou de passar, esse par ainda não conta como sistema redundante.

RAID e o servidor em que ele está

RAID1 no volume do banco segura um disco que quebra. Não segura placa-mãe, sistema operacional travado, os dois espelhos criptografados juntos, nem UPS que nunca fez ensaio de descarga. Redundância de disco e redundância de aplicação não estão na mesma camada; se a proposta as escreve juntas, o campo vê “já fizemos RAID e a linha parou do mesmo jeito”.

O servidor que hospeda o SCADA precisa ter alimentação, refrigeração e caminho de rede à altura da disponibilidade que o campo de fato quer. O valor da placa de rede dupla é isolar a rede industrial da corporativa, não só agregar banda. RAID1 no banco, hot standby e cluster redundante podem ocupar a mesma sala; se compartilham o mesmo switch, a mesma UPS e o mesmo ventilador do rack, ainda caem juntos.

• Volume do banco em RAID1: um disco quebrado não deve derrubar o histórico; ainda assim, o ensaio de restauração precisa provar que o backup se lê
• Fonte dupla, mais UPS com autonomia de fato medida, não só o número da plaqueta
• Uso das duas placas de rede escrito com clareza: uma face para a rede industrial, outra para a corporativa ou o segmento do histórico — não dois cabos no mesmo VLAN
• Separação física do par: duas no mesmo rack já é mais forte do que uma; duas em UPS distintas e switches de acesso distintos é o que segura falha de um único rack

Camada, meio de redundância e o que a aceitação precisa provar

Escrever “redundância” na proposta não se mede. A tabela abaixo está escrita para um terceiro, sem histórico do projeto, conseguir fazer o ensaio e anotar sim ou não. A terceira coluna se preenche com os números do próprio campo — tempo de comutação, buraco de histórico, quem tem autoridade para comutar — e não se copia o default do fabricante.

Os meios de arquitetura que adotamos em projeto incluem cluster redundante, hot standby em duas máquinas, RAID1 no banco, operação 7×24 e atualização de tela em segundos. São itens de aceitação, não percentual de disponibilidade do campo. Transferir três anos de dado para o histórico é outra decisão da camada de dados; deve ser escrita ao lado do desenho de RAID e réplica, não no lugar deles.

Isolamento de rede e permissões: só a camada que a disponibilidade precisa

Se a rede corporativa despeja na industrial, ou uma conta comprometida consegue parar os dois nós ao mesmo tempo, a alta disponibilidade cai junto. Isto não é um artigo de segurança OT; as linhas abaixo são o que o ensaio de comutação e a auditoria da planta encontram direto.

Em projeto de grande porte, já fizemos isolamento físico entre rede industrial e corporativa, comutação em três camadas em fibra gigabit, isolamento por placa de rede dupla no servidor, RAID1, autorização por classes e filtragem de arquivo de alto risco. Permissão, papel e auditoria se configuram segundo o requisito de segurança do campo. Desenho e documentação correspondentes se fornecem conforme o escopo do projeto, em conjunto com auditoria da planta, aceitação e avaliação de terceiro; a conclusão concreta segue a evidência do projeto.

• Isolar rede industrial e corporativa, para tempestade de broadcast ou malware do desktop não derrubar os dois SCADA juntos
• Amarrar as duas placas de rede por uso: tráfego de processo numa face, corporativo ou histórico na outra, sem bridge improvisada
• Permissão de escrita, descarga de receita e acesso à engenharia caem em papéis nominais, com registro de auditoria de quem alterou o quê
• No host SCADA, filtrar tipos de arquivo de alto risco; copiar o instalador por pen drive é o caminho comum das duas máquinas ganharem o mesmo software que não deveriam

Se o campo já tem um sistema de segurança OT, a redundância SCADA entra nesse sistema, não em outro paralelo. O ensaio de aceitação da tabela acima continua valendo: isolamento bem feito mas que não comuta ainda não conta como sistema de alta disponibilidade.