O cenário é comum. Empresa com dois ou mais escritórios que precisa compartilhar suas informações e arquivos entre as localidades. Não é algo tão simples, mas há soluções engenhosas para esta situação. Este assunto é ao mesmo tempo estratégico para o empresário que quer prover todas as informações para seus colaboradores que trabalham em locais distintos bem como um desafio técnico para os responsáveis por TI.
Por isso mesmo este texto visa de forma simples passar estas informações para estes dois grupos tão distintos de leitores. Alguns parágrafos serão mais técnicos visando o pessoal de TI, mas essencialmente visa alertar e abrir esta possibilidade para empresários que têm a necessidade e não sabem que o problema tem soluções acessíveis e simples.
Mas porque do título “…, o pesadelo e o sonho“?? Na verdade vou apresentar duas soluções possíveis e igualmente eficazes. Mas uma delas, por desconhecer uma “manha”, vivi um “inferno astral”. Como não quero que meus leitores passem pelo mesmo infortúnio, escrevo este texto.
O Cenário
Empresa se estabelece uma grande sede. Vasto espaço para crescimento. Mas quando se é competente e trabalha direito o reconhecimento acontece bem com o crescimento. Um novo escritório, na mesma cidade ou em outra cidade torna-se necessário. Porém a massa de trabalhos, arquivos, documentos, imagens está em local único, o servidor da empresa. A compra de um segundo servidor com a cópia dos dados “resolve” o problema original, mas traz uma nova situação complicada. A partir do dia que existem dois locais com usuários distintos e novos trabalhos ninguém mais sabe onde se encontram as versões mais atuais de documentos sensíveis à operação da empresa. Se fosse possível ter apenas um servidor esta situação não aconteceria.
Sem ser muito técnico há uma solução de caráter temporário que é interligar as duas sedes pela Internet (usando uma VPN ? rede virtual privativa) e os usuários da sede menor acessam remotamente os arquivos na sede maior. Funciona? Claro, mas para um grupo pequeno de pessoas apenas e com prejuízo na condição de uso. Por mais rápido que seja a conexão com a Internet, arquivos maiores (2, 5, 10, 20 Mbytes) demoram demais para serem carregados, entre 2 e 10 minutos. Leva este tempo para ler e o mesmo tanto para gravar! Chega uma hora que se torna inviável.
As duas soluções que serão apresentadas a seguir partem do princípio da existência de uma conexão VPN estabelecida entre as duas sedes. Isto pode ser feito de diversas formas. Desde um serviço especializado de VPN contratado junto a um provedor de Internet ou uma simples conexão feita pelo próprio servidor ou por roteadores com este recurso (VPN fim a fim).
Solução 1 ? o versátil ROBOCOPY ? pesadelo e quase um sonho
Administradores de rede e servidores conhecem formas de criar scripts (arquivos contendo conjunto de comandos) para diversas finalidades. Usando esta tecnologia existe uma forma engenhosa de resolver a situação de manter os dados de dois locais diferentes, em dois servidores distintos com os mesmos arquivos.
Na verdade manter os “mesmos arquivos” significa algo um pouco mais sofisticado. Significa que apenas as versões MAIS NOVAS de cada arquivo devem ser trocadas. O que foi criado ou alterado na sede A deve ser enviado para a sede B. Da mesma forma apenas os arquivos novos e alterados na sede B devem ser enviados para a sede A.
A primeira vez que tentei resolver este problema usei o recurso mais simples possível. Tratava-se do antigo comando XCOPY (extended copy) que existe desde os primórdios dos DOS 3.3 e todas as versões subsequentes do Windows. Porém o XCOPY não é ideal para copiar apenas arquivos novos ou alterados. E tem uma característica terrível que só descobri depois. Se alguém deixar um arquivo aberto em uma estação, o XCOPY ao tentar copiá-lo não obtém sucesso e o processo fica estagnado (não vai para frente e o processo não é completado).
Mas a própria Microsoft criou um SUPER COPY, ou melhor, o ROBUST FILE COPY que é chamado de ROBOCOPY. São dezenas de opções, parâmetros e possibilidades. Veio como um programa à parte para o Windows XP e Windows Server 2003 e tornou-se um comando nativo do Windows Vista, Windows 7 e Windows Server 2008. Um singelo exemplo está abaixo.
ROBOCOPY C:DOCUMENTOS D:DOCUMENTOS /S /R:2 /w:1
Este comando copia apenas os arquivos DIFERENTES da pasta C:DOCUMENTOS para outro disco D:DOCUMENTOS (que pode ser na mesma máquina ou em outro servidor remoto), com todas as subpastas (/S) tentando copiar arquivos “presos” por até 2 vezes (/R:2) esperando por 1 segundo entre as tentativas (/W:1). Dá para criar LOGs (registro de tudo que foi copiado) e tantas outras opções. Seria enfadonho explicar em detalhes o ROBOCOPY (veja detalhes no hiperlink). Mas deve ter ficado claro que este BRILHANTE comando resolveria o meu problema!! Assim foi criado um par de scripts programados para rodar em cada um dos servidores para copiar o que tinha de novo ou alterado da sede A para a sede B e vice versa.
Tudo funcionando, acompanhei por dois ou três dias e tudo estava aparentemente certo. APARENTEMETE. Foi quando o PESADELO começou. Pessoas da sede A e da sede B começaram a reclamar que seus trabalhos recém-feitos haviam sido perdidos, tinha voltado a ser como eram dias atrás (alterações perdidas). Crise brava! Não uma ou duas, mas MUITAS pessoas com o mesmo problema. Depois de muita tensão e estudo descobri que há uma ANOMALIA no comportamento do brilhante ROBOCOPY.
Por padrão o ROBOCOPY copia os arquivos DIFERENTES, sem se importar se o DESTINO é mais novo ou mais antigo. Assim ao fazer cópias de sede A para a sede B os arquivos diferentes (mesmo mais ANTIGOS) são copiados sobre os arquivos MAIS NOVOS da sede B. Estava descoberta a anomalia e o problema. Por isso que inúmeras pessoas reclamavam com razão que seus trabalhos estavam “SUMINDO”. Para realizar backups em discos externos (HDs externos) o arquivo ser diferente é suficiente, mas NÃO PARA SINCRONIZAR SERVIDORES.
Estudando a documentação do ROBOCOPY descobri existir o parâmetro /XO que faz o comando funcionar como era esperado. Ajustados os scripts, o nefasto efeito de arquivos mais antigos serem copiados sobre os mais novos no outro servidor parou de acontecer. Ficou tudo QUASE perfeito. Este esquema usando scripts e ROBOCOPY apresentou ainda DUAS grandes deficiências :
Solução 2 ? Microsoft DFS ? o sonho!!
DFS ? Distributed File System, ou Sistema de Arquivos Distribuído é um recurso que nasceu no de forma incipiente no Windows 2000 Server, mais de dez anos atrás. Mas atingiu sua plena maturidade no Windows Server 2008 R2. Assim o que vou mostrar está longe de ser algo novo. Mas exigia certo estudo. A solução feita com o ROBOCOPY, mesmo não sendo perfeita, deu-me tempo para estudar melhor esta “nova” alternativa.
O conceito: o recurso DFS é amplo e tem muitas facetas distintas, mas o que me importava era a possibilidade de integração, sincronização de dados de forma inteligente. E põe inteligente nisso. Tomemos como exemplo dois servidores (podem ser mais). Algumas pastas podem ser escolhidas e estas serão constantemente monitoradas pelo Windows. Os seguintes eventos são resolvidos por esta ferramenta:
Há muitas outras características, mas já ficou claro que apenas estas 3 citadas acima resolvem completamente a situação a qual eu me propunha solucionar. O DFS está presente como uma função a mais da “role” FILE SERVICES e deve ser instalada explicitamente no servidor.
Outro uso importante para o DFS REPLICATION é manter um servidor redundante no mesmo local. Caso haja pane do primeiro o segundo pode rapidamente configurado para assumir seu lugar e assim a empresa não terá perda de continuidade em seus trabalhos.
Resumidamente falando o DFS REPLICATION pode ser configurado de muitas formas. Pode ser unidirecional ou bidirecional (no meu caso tinha que ser bidirecional). Pode envolver muitos servidores (no meu caso eram apenas 2). A Microsoft recomenda que até 10 servidores sejam usados para MULTI REPLICAÇÃO, ou seja, TODOS REPLICANDO EM TODOS. Já imaginaram? Qualquer alteração feita em um dos 10 é repetida nos outros 9… Fantástico. Mas podem ser usadas outras arquiteturas. Um conjunto ainda maior de servidores podem ser associados por meio de um “concentrador” e este enviar as alterações para outros. Enfim, são muitas possibilidades.
Fica claro que ocorre uma forte comunicação entre os servidores. Mas principalmente no cenário remoto (via VPN) como fica o consumo de recurso de comunicação (banda de Internet)?
Este ponto foi tratado com bastante esperteza pela Microsoft. A empresa em questão, objeto deste “case” tinha um link de Internet de 10 Mbps em uma sede e link de 2 Mbps na outra sede. Se o volume de arquivos novos fosse grande demais em determinado dia a sede B ficaria completamente sem condição de acesso à Internet, pois teria toda sua capacidade “drenada” pelo DFS REPLICATION. Assim o administrador de rede pode definir o quanto do recurso pode ser usado a cada momento:
Isto é facilmente enxergado e configurado na tela mostrada abaixo.
Embora durante o dia haja apenas 128 Kbps reservado para esta operação, quando os volumes envolvidos são pequenos ou médios as operações são replicadas rapidamente. Apenas no caso de uma cópia massiva de arquivos na rede que estas apenas serão completadas no período após o expediente, com toda a capacidade de uso da Internet à disposição.
Quando eu implantei este recurso entre sede A e sede B da referida empresa, os servidores já se encontravam em locais distintos. Assim a “replicação inicial” demorou quase duas semanas para ser completada. Eram quase 500 Gb de arquivos!! Rápido se pensar no volume, graças ao sofisticado algoritmo de compressão de dados usado pela Microsoft. Depois disso as operações eram virtualmente instantâneas (no máximo 2 segundos para acontecerem na outra ponta).
Por isso quando for possível o ideal é realizar esta replicação primordial com os dois servidores lado a lado, na mesma rede, sem envolver comunicação remota via Internet. Depois pode levar cada servidor para seu destino final onde a replicação dos arquivos acontecerá de imediato via Internet.
CONCLUSÃO
A tarefa de manter dois ou mais locais com o mesmo conjunto de arquivos dispõe de várias soluções. O DFS Replication do Microsoft Windows Server 2008 R2 embora tenha já no mínimo um par de anos, nem sempre é usado pelas empresas. Talvez por desconhecimento. E não há motivos para isso. A solução “caseira” via scripts com o também competente ROBOCOPY é uma solução “honrosa”. Tem como virtude a simplicidade, mas como demonstrado apresenta alguns “poréms” que podem ou não serem tolerados. Depende de cada situação.
Já há alguns meses este cenário descrito está implantado com sucesso pleno. Administrar o uso do recurso (para não consumir demais a capacidade da Internet), manter 2 servidores exatamente iguais, seja a 2 metros de distância, 500 metros ou 2000 Km é um serviço fantástico. DFS Replication não é ferramenta de backup. Mas ter um ou mais servidores rigorosamente com o mesmo conteúdo é uma segurança a mais para a empresa, em caso de pane severa de um de seus repositórios de arquivos.
Por fim devo confessar que me surpreendi com a simplicidade da implementação. Soubesse eu que fosse assim, nem teria usado a alternativa dos scripts com ROBOCOPY (que é uma ótima ferramenta, mas não a melhor para ESTE cenário). E para o empresário, que quer apenas que suas informações estejam igualmente disponíveis e acessíveis plenamente em todas as suas sedes, escritórios ou filiais, o DFS Replication é uma ferramenta essencial.
Alguns links para consulta :
http://technet.microsoft.com/en-us/library/cc753479(WS.10).aspx
http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx
http://www.windowsnetworking.com/articles_tutorials/implementing-dfs-replication.html
PS: continuarei a série de textos sobre relógios-computadores-de-pulso para corredores na sequência. Interrompi para falar deste outro assunto.
PS : este texto foi originalmente publicado como “Sincronizando servidores, o pesadelo e o sonho!” em meu blog pessoal FXREVIEW
por Bruno Paiuca Dentro da jornada de digitalização dos ecossistemas de segurança, a validação e…
A Alphabet, controladora do Google, planeja levantar US$ 80 bilhões por meio da venda de…
O Sberbank, maior banco da Rússia, está oferecendo modelos de inteligência artificial (IA) a países…
A Palo Alto Networks registrou forte aumento na procura de clientes por orientações sobre segurança…
O iFood confirmou nesta terça-feira (03) o vazamento de dados cadastrais de aproximadamente 1,2 milhão…
O CEO da OpenAI, Sam Altman, participará da cúpula do G7 na França em junho,…