segunda-feira, 23 de janeiro de 2012

Sincronizando servidores, o pesadelo e o sonho!

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.

Inúmeros servidores conectados entre si – será possível??


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 :

  • ·         Sincronização apenas uma vez por dia, feita de madrugada.
  • ·         Arquivos apagados “reapareciam”. Este é o efeito colateral da forma como foi feita a sincronização. O arquivo apagado na sede A era recopiado da sede B (que não fora apagado). Assim qualquer arquivo apagado em qualquer das sedes era recuperado pois vinha do outro servidor.

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:

·         Se um arquivo é criado em qualquer dos servidores naquela pasta escolhida (ou sub-pasta) este arquivo é instantaneamente copiado para o outro servidor no mesmo local.
·         Se um arquivo é alterado, seja ele grande ou pequeno, o outro servidor recebe a atualização. Mas de forma inteligente. Usando um complexo algoritmo de compressão (RDC - Remote Diferential Compression), o conteúdo é analisado e apenas a parte que foi alterada do arquivo é transmitida para o outro lado.

·         Se um arquivo é APAGADO em uma das duas pontas (um dos servidores), o mesmo arquivo e na mesma pasta também é apagado no outro servidor em poucos segundos.

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.

Serviço DFS e sua função de Replicação

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:


  • Todo dia das 21:00 até 08:00 usa toda a capacidade (100%)
  • Das 08:00 às 09:00 e das 20:00 às 21:00 usa 50%
  • Das 09:00 às 20:00 apenas 128 Kbps (5% da banda mínima)
  • Sábados e Domingos todo dia 100%
Isto é facilmente enxergado e configurado na tela mostrada abaixo.

Controle de consumo de banda de Internet por dias/horários

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.


Arquitetura multi replicação do DFS Replication

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.



12 comentários:

  1. Xandó,mais uma vez, palmas por mais um excelente artigo, e principalmente pela sua generosidade em compartilhar seu conhecimento. São essas atitudes que tornam o mundo um pouco melhor para todos.
    Obrigado.

    ResponderExcluir
  2. Caro William você não pode imaginar como é encorajador um comentário como o seu. Eu que agradeço MUITO seu feed-back tão simpático e recompensador. Se pude ajudar compartilhando minhas "cabeçadas" eu fico muito feliz pois este espaço está aqui para isso mesmo!! Grande abraço

    ResponderExcluir
  3. É que hoje em dia com tanta competitividade, dificuldade pra ganhar a vida, manter o emprego, é raro ver pessoas compartilhando conhecimento útil. E até entendo, e nem acho que seja egoismo por parte de quem guarda para si seus conhecimentos, pois parece haver mais gente querendo te derrubar e tomar o que é seu, do que pessoas te ajudando a subir; então é uma forma de protegerem si e garantir o sustento deles e de seu próximos, né. Eu, particularmente, tento crescer e ajudar meu próximo crescer tbm. Não estou dizendo que eu seja melhor e mais nobre que ninguem, apenas, em meio aos erros e pequenezas que cometo, me esforço tbm pra tentar ajudar, com o mínimo que possa.
    Pessoas como voce, Piropo, Laercio, Sucupira, Abel Alves, Elis, e um longo etc, já me enriqueceram muito com seus conhecimentos e generosidade.
    Enfim, parando com a rasgação de seda :>), desejo a todos muito sucesso, amor e prosperidade... vcs são 10. :>)

    ResponderExcluir
  4. Xandô, vendo alguns comentários às suas colunas aqui e lá no FPCs, resolvi deixar um "conselho":

    " Algumas pessoas vão te amar pelo que você é,
    e outras, vão te odiar pelo mesmo motivo...
    Acostume-se! Impossível agradar a todos! "

    ResponderExcluir
  5. William, sobre o primeiro comentário, fico muito satisfeito de fazer realmente algo útil para as pessoas. Eu acredito que as pessoas que escondem as coisas têm sucesso efêmero pois vivemos em uma época na qual o conhecimento evolui muito rápido. Se descubro algo e compartilho, penso que conquisto o respeito por parte das pessoas e isso em termos de trabalho, fará estas pessoas e me procurarem se um dia precisarem de um trabalho mais elaborado. E assim tenho novos desafios.

    Sobre o segundo comentário, de fato ninguém agrada a todos. E olha que volta e meia levo bordoadas a granel por parte de uns e penso ter agradado a outros. E como você disse, pelos mesmos motivos. Difícil entender a natureza humana. Mas acho que embora me entristeçam as manifestações duras contra mim, mesmo quando fiz o meu melhor, são inevitáveis, sejam por arrogância (pessoas que se acham deuses da sabedoria) ou mesmo por inveja. Estou "formando calo" e já já não ligo mais. Agradeço MUITO seu apoio e de tantos outros leitores!! Grande abraço.

    ResponderExcluir
  6. Boa tarde, tenho na empresa que trabalho o ERP SAP, banco dados SQL SERVER você acha que funcionaria??? Como seria internamente a manipulação no BANCO DE DADOS???

    ResponderExcluir
    Respostas
    1. Olá José Humberto, esta solução NÃO serve para replicação de banco de dados. Pelo menos não é o que já testei. SQL Server tem soluções de replicação transacional, que entrega "scripts" para serem executados a cada segundo de um servidor para outro, mantendo as bases idênticas. Os comandos básicos de INSERT, DELETE e UPDATE são replicados e mantêm tudo igual. Mas não com esta solução que eu mostrei. Essa é boa para FILE SERVER. Abraços

      Excluir
  7. Boa Noite, Gostaria de uma Ajuda sua neste assunto, Peguei um servidor ja estruturado para dar manutenção, ontem eu precisei de voltar a data do servidor principal para que algumas alterações pudessem ser feitas, porem eu não sabia que este servidor principal e replicado por um outro no gerenciamento dfs, sendo assim durante esse periodo que a data ficou diferente, o replica excluiu parte dos arquivos do servidor principal e enviou para uma pasta em D:\CNP\DfsrPrivate\ConflictAndDeleted, o problema é que ele separo os arquivos de suas pastas de origem, ficando muito confuso encontrar um arquivo sem esta estrutura original que eles possuíam, fiz uma copia destes arquivos e desabilitei o dfs, Outro PROBLEMA, ao fazer isso eu perdi o arquivo ConflictAndDeletedManifest.xml, que continham a origem dos arquivos onde eu poderia utilizar um script da microsoft para restaura os arquivos. Existe alguma forma de eu restaura estes arquivos da mesma forma que eles estavam antes? Obrigado!

    ResponderExcluir
    Respostas
    1. Caro Boris trata-se de uma situação de exceção bastante particular. Essa história de ter mudado a data "quebrou a perna" do esquema. Este é um caso que eu nem tentaria ir por este lado e sim resgataria os arquivos do seu backup.

      Excluir
  8. Ótimo artigo, passei por situações semelhantes. Estou finalizando o DFS em mais uma Empresa criando o namespace para acesso ao diretório replicado que em caso de queda automaticamente ele assume. Excelente ferramenta!!! Parabéns pelo artigo

    ResponderExcluir
    Respostas
    1. Super obrigado pelas suas palavras e apoio Mauricio!! Que bom que você também está usando e está tão satisfeito quanto eu!! Abraços

      Excluir
  9. Ola Flavio, otimo artigo. Pergunto, essa solução é semelhante ao drbd no linux? se sim, ela elimina o problema que existe de latencia de link? ou necessitamos de link dedicado ponto a ponto no caso de matriz/filial alterando os arquivos fulltime. Obrigado.

    ResponderExcluir