Quando o servidor de ficheiros pára, a empresa percebe depressa quanto trabalho depende dele. Orçamentos ficam por emitir, documentos deixam de abrir, a aplicação de gestão pode perder acesso a pastas partilhadas e quem está em teletrabalho deixa de conseguir trabalhar. Um cluster de servidor de ficheiros existe para reduzir esta dependência de uma única máquina. Mas não é uma resposta automática para todas as PME – e, quando é mal desenhado, pode acrescentar custo e complexidade sem resolver o risco principal.
A questão certa não é «precisamos de um cluster?». É outra: quanto custa à empresa ficar sem acesso aos seus ficheiros durante duas horas, meio dia ou dois dias? A resposta deve considerar equipas paradas, atrasos perante clientes, perda de vendas e pressão sobre quem tem de recuperar o serviço.
O que é um cluster de servidor de ficheiros
Um cluster junta dois ou mais servidores para disponibilizar um serviço com maior continuidade. No caso dos ficheiros, o objectivo é que as pastas partilhadas permaneçam acessíveis mesmo que um servidor tenha uma avaria, precise de manutenção ou deixe de funcionar.
No modelo mais comum para uma PME, existe um nó activo, que está a servir os ficheiros, e outro preparado para assumir essa função. Se o primeiro falhar, o segundo toma o controlo. Esta mudança pode exigir alguns momentos de indisponibilidade, mas evita que uma falha de hardware se transforme numa paragem prolongada.
Há também arquitecturas em que ambos os servidores trabalham em simultâneo. Podem repartir carga ou disponibilizar serviços diferentes, mas exigem maior cuidado na gestão dos dados, da rede e das permissões. Não são necessariamente melhores: devem ser escolhidas quando existe uma necessidade real de desempenho ou disponibilidade mais elevada.
O utilizador não deve ter de saber qual é o servidor que está activo. Idealmente, acede sempre ao mesmo nome de rede, como `Ficheiros` ou `Dados`, e a infraestrutura trata do restante. É este detalhe que torna a solução útil no dia-a-dia: não basta haver dois equipamentos; é preciso que a transição seja previsível e controlada.
O que um cluster resolve – e o que não resolve
Um cluster protege sobretudo contra a indisponibilidade de um servidor. Pode responder a uma fonte de alimentação avariada, a um disco com falha, a uma actualização que obriga a parar um nó ou à avaria completa de uma máquina virtual ou física.
No entanto, dois servidores no mesmo armário não protegem contra todos os cenários. Se ambos dependem da mesma alimentação eléctrica, do mesmo switch, da mesma sala ou do mesmo armazenamento, continuam a partilhar pontos únicos de falha. Um incêndio, uma inundação, uma falha eléctrica grave ou um erro na rede pode afectar toda a plataforma de uma vez.
E há um risco que merece especial atenção: um cluster não é um backup. Se alguém apagar uma pasta, se um colaborador gravar por engano uma versão errada de um ficheiro, ou se um ataque de ransomware cifrar os dados partilhados, essa alteração pode ser replicada para os restantes nós. A disponibilidade mantém-se, mas os dados continuam comprometidos.
Por isso, uma empresa que investe num cluster sem cópias de segurança independentes cria uma falsa sensação de segurança. A regra 3-2-1 continua a aplicar-se: três cópias dos dados, em dois suportes distintos, com uma cópia fora das instalações. Quando possível, deve existir ainda uma cópia protegida contra alteração ou eliminação indevida.
Quando faz sentido um cluster de servidor de ficheiros
A decisão depende mais da operação do que do número de computadores. Uma empresa com quinze utilizadores pode precisar de alta disponibilidade se cada encomenda, processo de produção ou atendimento ao cliente depender de ficheiros internos. Em contrapartida, uma empresa maior pode aceitar algumas horas de paragem se tiver processos alternativos bem definidos e os dados estiverem protegidos por backups testados.
Um cluster tende a fazer sentido quando a indisponibilidade de ficheiros tem impacto directo na facturação ou no serviço ao cliente; quando existem vários colaboradores a trabalhar sobre documentos e bases de dados partilhadas; quando a organização tem horários alargados e não pode aguardar pela intervenção no dia seguinte; ou quando o custo de uma paragem supera claramente o investimento numa segunda infraestrutura.
Também pode ser uma opção sensata para organizações que já usam virtualização. Nesse contexto, a continuidade pode ser tratada ao nível das máquinas virtuais, do armazenamento e da rede, em vez de se limitar ao servidor de ficheiros. O desenho correcto depende das aplicações instaladas, do volume de dados e do tempo máximo de recuperação aceitável.
Nem todos os ficheiros exigem o mesmo nível de disponibilidade. Documentos administrativos podem tolerar uma interrupção curta. Já ficheiros usados por uma aplicação de produção, desenhos técnicos em utilização constante ou dados partilhados por equipas comerciais podem justificar um investimento superior. Separar estes níveis de criticidade evita pagar por uma arquitectura complexa para dados que não a necessitam.
Os componentes que não podem falhar no desenho
A palavra «cluster» pode dar a ideia de que basta comprar dois servidores. Na prática, a continuidade é tão forte quanto o elemento mais frágil da arquitectura. Se os dois nós dependem do mesmo switch sem redundância, uma avaria nesse equipamento continua a interromper o acesso às pastas.
O armazenamento é outro ponto decisivo. Algumas soluções usam discos locais replicados entre servidores; outras recorrem a armazenamento partilhado. A primeira opção pode reduzir dependências externas, mas exige uma boa ligação entre os nós e controlo rigoroso da replicação. A segunda pode simplificar certos cenários, mas obriga a garantir que esse armazenamento não se torna no novo ponto único de falha.
A rede deve ter capacidade adequada, equipamentos empresariais bem configurados e segmentação quando necessária. Não vale a pena criar redundância nos servidores e manter a infraestrutura apoiada num router fornecido pelo operador, sem políticas de segurança, sem visibilidade e sem equipamento de substituição preparado.
Há ainda um mecanismo pouco visível, mas crítico: o quorum. É ele que ajuda os servidores a decidir qual pode manter o serviço activo quando deixam de comunicar entre si. Sem esta salvaguarda, ambos podem assumir que devem servir os mesmos dados ao mesmo tempo. Este cenário, conhecido como split-brain, pode causar conflitos e corrupção de informação. É uma das razões pelas quais este tipo de solução deve ser implementado e acompanhado por técnicos com experiência.
Acesso remoto, permissões e segurança
Um cluster não substitui controlo de acessos. Se qualquer colaborador consegue abrir todas as pastas, copiar dados sensíveis para uma pen ou apagar documentos críticos, a disponibilidade do serviço pouco protege a empresa.
As permissões devem seguir as funções de cada pessoa e grupo de trabalho. A equipa comercial precisa de aceder à informação comercial, mas não necessariamente aos dados salariais. A contabilidade pode necessitar de documentos financeiros, mas não de projectos técnicos em curso. Esta separação reduz erros e limita o impacto de uma conta comprometida.
Para quem trabalha fora do escritório, o acesso deve passar por uma VPN devidamente configurada, autenticação forte e regras de firewall adequadas. Expor directamente partilhas de ficheiros à Internet é um risco desnecessário. O acesso remoto deve ser tão controlado quanto o acesso dentro das instalações.
Também importa manter os sistemas actualizados, usar antivírus empresarial e registar eventos relevantes. Se houver uma actividade invulgar – por exemplo, centenas de ficheiros renomeados em poucos minutos – a empresa precisa de detectar o problema cedo. A velocidade de resposta determina muitas vezes se o incidente fica contido ou se se espalha por toda a organização.
Antes de avançar, teste o cenário de falha
Uma solução de continuidade só é credível quando é testada. Não basta ver dois servidores ligados e assumir que a comutação vai funcionar num momento crítico. É necessário simular a falha de um nó, confirmar que os utilizadores voltam a aceder às pastas, validar permissões e medir quanto tempo demora a recuperação.
Os backups também devem ser restaurados num ambiente controlado. A pergunta não é apenas «o backup foi executado?». É «conseguimos recuperar os ficheiros certos, no prazo de que precisamos?». Esta validação deve incluir ficheiros recentes, versões antigas e, se aplicável, dados usados pelas aplicações da empresa.
Um bom projecto começa por identificar os serviços críticos, o tempo de paragem aceitável e os pontos únicos de falha existentes. Por vezes, a resposta será um cluster de dois nós. Noutras situações, será mais sensato reforçar backups, substituir o servidor envelhecido, melhorar a firewall e preparar um procedimento de recuperação claro.
A tecnologia deve acompanhar a realidade do negócio, não impor uma arquitectura só porque parece avançada. Se a sua empresa não consegue explicar como continuaria a trabalhar amanhã caso o servidor de ficheiros falhasse, esse é o momento certo para avaliar o risco e definir um plano concreto.
No responses yet