Executando processos RSync em Paralelo para Acelerar Cópias

O RSync é uma ferramenta muito útil, e extremamente flexível. Basicamente, serve para fazer cópias. Ele já salvou minha vida algumas vezes, facilitando tarefas complicadas.

Vou falar sobre algumas das características do RSync, apenas para dar uma idéia:

  • Verifica a integridade dos arquivos copiados;
  • Transfere apenas as diferenças dos arquivos (yeah, não transfere o arquivo inteiro, apenas os bits diferentes!);
  • Mantém cópias idênticas entre 2 diretórios distintos, apagando os “excessos”;
  • No caso de cópias remotas, pode usar compressão para diminuir o uso de banda;

E por aí vai …

Existem inúmeros cenários onde se pode usar o RSync. A internet está repleta de exemplos. Mas, para alguns casos, nem o Google consegue ajudar. É aí que nós, contribuidores individuais, entramos. Continue reading

Novo XFS: Um Sistema de Arquivos Eficiente

Existe no mercado grande preocupação com performance de aplicações. Muito investimento é feito no desenvolvimento de softwares que consigam utilizar da melhor forma possível os recursos computacionais atuais. Mais notadamente CPU, I/O e Memória. E grande êxito tem sido alcançado. No entanto, existe um detalhe que muitas vezes não é considerado de forma adequada: O sistema de arquivos. Muitos acreditam que os recentes EXT4 e BTRFS são a solução para estes problemas. Mas nem sempre. Estes FS são baseados em um conceito antigo, de uma época em que não existiam os multicores. A falha não é de implementação, mas de design. Da forma como foram concebidos, quando são executados por uma plataforma multi-processada (8 Cores ou 8 CPUs, por exemplo), sofrem pelas limitações do paralelismo, onde chegamos a um ponto onde mais passa a ser menos. É isso mesmo, eu não estou ficando louco. Vou explicar:

O custo de comunicação é alto, pois além da própria transmissão, temos o protocolo usado para isso, o que estabelece um “compromisso” entre grau de paralelismo e desempenho. Este compromisso chama-se granularidade, e é o elemento básico que será executado em paralelo. Meio confuso, certo? Na verdade não. Agora você vai captar a mensagem:

  • Granularidade Fina: Um conjunto pequeno de instruções são executadas em paralelo.
  • Granularidade Média: Funções são executadas em paralelo, através de threads.
  • Granularidade Grossa: Processos com grande quantidade de código são executados em paralelo.

Resumindo:

  • Granularidade Fina = Alta Comunicação / Menor Performance.
  • Granularidade Grossa = Pouca Comunicação / Maior Performance.

Isso me lembra da Lei de Amdahl, que rege o desempenho de aplicações paralelas, onde:

T1 é o tempo de execução serial em 1 processador, e TP é o tempo de execução paralela em “P” processadores. Com isso você calcula uma coisa chamada “speed-up”:

Sp=T1/TP
Tp=sT1+(1-s) T1/p
Sp=p/(sp+(1-s))

A essa hora você deve estar pensando: “Caramba André, que palhaçada é essa?”. Desculpe. Melhor parar antes que você me xingue…

O que eu quero mesmo que você saiba é:

  1. Um sistema é escalável quando permanece eficiente quando há aumento de recursos.
  2. Paralelismo é quando um mesmo processo pode executar em mais de um processador.

Mas o que isso tem a ver com XFS? Tudo!

Fato: A partir de 4 Cores e um certo volume de dados, a performance da grande maioria dos FS começa a degradar, em especial, com operações que geram uma grande quantidade de metadados (dados que descrevem ou geram outros dados, como por exemplo, um datawarehouse, as tabelas de um banco de dados ou ainda descompactar um arquivo).

Para resolver estes problemas, o XFS passou por um processo de upgrade que levou vários anos para ser concluído, e culminou na implementação de uma técnica chamada delayed logging (atualizações no journal são atrasadas e as escritas que seriam realizadas a um mesmo bloco, passaram a ser combinadas e aplicadas uma única vez), ao mesmo tempo em que manteve compatibilidade com as versões anteriores. Captou? Foi feito um trabalho em cima da granularidade! Imagino que estas alterações de algoritmo devem ter gerado um esforço imenso…

Só para esclarecer, um journal é como se fosse um log binário, utilizado para facilitar a vida do FS na hora de se recuperar de uma falha de escrita ou um shutdown forçado, onde os FS não são desmontados corretamente.
No passado, a performance do XFS para tratamento de metadados era bem ruim, pois imensas quantidades de journal eram geradas. Mas a partir do Kernel 3.3, este e outros problemas foram solucionados. Agora o XFS consegue escalar de forma linear por todos os cores de um CPU, aumentando cada vez mais a performance. Ou seja, em uma realidade multicore como a que vivemos, não importa a quantidade de dados/metadados: quanto mais CPU, maior a capacidade para ler e escrever de forma eficiente em um disco preparado com XFS. Ok, uma boa controladora de discos ajuda, mas não faz milagres.

Mas quão rápido ficou o XFS depois do upgrade?

Comparando com o EXT4, até 4 cores, este último tem uma performance ligeiramente maior, mas quando escalamos para 8 cores, a performance do EXT4 começa a degradar (lembra do limite do paralelismo?), ao mesmo tempo em que a performance do XFS aumenta exponencialmente. É literalmente um “perdeu, playboy!” 🙂

Vamos ilustrar de forma gráfica para facilitar o entendimento:

Rápido, não?

É provável que em um futuro próximo muitas plataformas, em especial as destinadas à execução de datawarehouses, passem a adotar o XFS como sistema de arquivos padrão.

Eu já estou homologando o novo XFS em alguns ambientes, e tem funcionado muito bem!

Quer tirar suas próprias conclusões? É simples: basta atualizar o Kernel do seu SO para versão 3.3+ e formatar algum disco com XFS. Após, use o software fs-mark para fazer os testes de performance.

Um abraço!

Storages com NFS: Rápidos como iSCSI e Fibre Channel

O NFS, apesar de sua fácil implementação e administração, não possui performance boa o suficiente para ser implementado em uma SAN (Storage Area Network). Isso é um MITO!

Se bem configurado e planejado, o NFS performa tão bem quanto seus concorrentes comumente vistos em storages, como o iSCSI e o Fibre Channel (FC). O segredo? Tratar o NFS da mesma forma que seus concorrentes.

Historicamente, o iSCSI é uma alternativa de menor custo ao FC, pois possibilita que seja utilizada uma infraestrutura de rede padrão, ao ponto que os FCs necessitam de hardwares especiais (switches de fibra, gbics, etc), que custam muitos dólares. A alguns anos atrás, somente conexões de fibra eram capazes de alcançar velocidaes de 1gbit/s. Atualmente, temos velocidaes de 2, 4 e até 10gbits/s via conexões de fibra. Mas o custo permanece muito elevado. Felizmente, já está disseminada no mercado a utilização de redes Ethernet Gigabit, que utilizam conexões de cobre, por um custo expressivamente menor que ao das redes de fibra. Como o preço das redes de cobre é menor, é possível que sejam comprados mais equipamentos, como placas de rede, e agregá-las para que funcionem em conjunto, conseguindo assim alcançar velocidades iguais às das conexões de fibra, E o melhor, agregando interfaces, além de desempenho, ganhamos resiliência. Ou seja, alta disponibilidade.

Interessante, certo? Mas parece complexo de implementar. Na verdade, não é. Alguns comandos básicos nos switches e no SO (Linux/Solaris), e nada mais. Leia mais sobre isso aqui e aqui.

Mas estávamos falando de performance NFS, e que ele precisava ser tratado de forma semelhante ao iSCSI/FC para que tenha o mesmo desempenho.

Um erro comum, é que o SysAdmin “monta” as partições NFS a partir de uma LAN utilizada pelos usuários e demais máquinas na rede, sem pensar que esta LAN já possui tráfego passante demais.

Em contra partida, costuma-se preparar ambientes iSCSI/FC em uma rede a parte, com interfaces e endereçamentos de rede dedicados (assim não temos concorrência no meio físico). Fica quase impossível não ter um desempenho melhor que o restante da LAN neste canal dedicado a comunicações com o storage. Ou seja, se adotarmos interfaces e IPs dedicados para o uso do NFS, teremos quase a mesma performance.

Mas por que quase? Pois não é somente ter um canal dedicado e correr para o abraço. É preciso fazer Tunning (ajuste) da configuração do NFS, para que este performe melhor. Normalmente isso é um trabalho chato e demorado, mas não tema, você não está lendo este post à toa. Vou lhe dizer tudo o que é preciso saber para ter uma boa performance.

Temos várias versões de NFS em prática no mercado, a saber:

  • NFSv2: Mais antigo, mais rápido mas possui alguns bugs.
  • NFSv3: Possui uma boa relação entre performance/segurança.
  • NFSv4: Mais recente, mais seguro, porém mais lento.

Os melhores resultados durante a pesquisa que realizei foram com o NFSv3. Para fins de comparação, haviam os seguintes ambientes:

  • Storage NetApp FAS2040 via iSCSI
  • Storage NetApp FAS2040 via NFS
  • Storage EMC CX3-10 via iSCSI

Não vou entrar em todos os detalhes técnicos dos testes realizados, mas falarei do que mostrou maior relevância para o usuário final: Gravação/Leitura de arquivos. Utilizamos 5000 arquivos de 100Kb cada e 1 arquivo de 500Mb. Para o arquivo maior (500Mb), não foi observada variância significativa de tempo de acesso dentre os ambientes de teste. No entanto, para os arquivos menores, a diferença foi grande. Focaremos nestes.

Qualquer controladora de discos faz um esforço muito maior no tratamento de grandes quantidades de arquivos pequenos, em relação ao tratamento de arquivos grandes. É comum levar o dobro do tempo para transferir um volume de 10Gb composto de milhares de arquivos pequenos, em relação a transferência de um único arquivo deste tamanho.

Assim sendo, o tunning do NFS precisa ser direcionado ao fato de que arquivos menores necessitam de tratamento especial. Após inúmeros testes, decidimos que estes parâmetros para montagem de um volume NFS eram os mais adequados a performance que estávamos buscando:

root@canopus:/# grep nfs /etc/vfstab | tail -1
173.11.1.100:/vol/nfs_files_e0b - /mnt/vol/files nfs - yes rw,hard,nointr,llock,vers=3,proto=tcp,rsize=524288,wsize=524288

Com estas configurações, foi possível obter estes tempos de acesso:

NetApp FAS2040 NFS: Cópia de 5000 arquivos de 100kb (média de tempo):

real    0m16.985s
user    0m0.221s
sys     0m5.157s

NetApp FAS2040 NFS: Cópia de 1 arquivo de 500Mb (média de tempo):

real    0m5.700s
user    0m0.003s
sys     0m3.366s

NetApp FAS2040 iSCSI: Cópia de 5000 arquivos de 100kb (média de tempo):

real    0m7.458s
user    0m0.221s
sys     0m6.213s

NetApp FAS2040 iSCSI: Cópia de 1 arquivo de 500Mb (média de tempo):

real    0m5.242s
user    0m0.003s
sys     0m4.300s

EMC CX3-10 iSCSI: Cópia de 5000 arquivos de 100kb (média de tempo):

real    0m16.571s
user    0m0.220s
sys     0m6.796s

EMC CX3-10 iSCSI: Cópia de 1 arquivo de 500Mb (média de tempo):

real    0m5.572s
user    0m0.004s
sys     0m4.352s

Observe que os parâmetros NFS apresentados são um estudo de caso, e podem não atender a todos os ambientes. Então antes de colocá-los em produção, faça um teste em laboratório para ver se o comportamento será satisfatório para sua estrutura.

Nota: propositalmente não mostrei os números iniciais antes das otimizações.

O que podemos aprender disso tudo:

O NFS é rápido, fácil de implementar, fácil de administrar, não requer interação com softwares adicionais (Netapp SanTool, MPxIO, PowerPath, etc) e não possui as complexidades de lidar com LUNs, comuns em estorages que funcionam apenas com iSCSI/FC.

O VMWare, dentre muitos outros, já possui suporte nativo a NFS, e funciona muito bem.

Ah, e para os meus saudosos amigos que acham que fibra é o único meio capaz de transportar 10Gbit/s, já ouviram falar em Twinax? É de cobre, faz 10Gbit/s, e custa menos. 😛

O que você está esperando para implementar NFS em sua SAN? Facilite sua vida!

Economizando Banda (e dinheiro) com um Otimizador de Tráfego

Existem no mercado diversos equipamentos pagos que servem para otimizar tráfego. Para empresas que possuem links de dados “ponto a ponto” (MPLS, Frame Relay, Multilinks WAN, ISDN, ADSL, etc) de baixa capacidade, como 1Mb por exemplo, um otimizador é fundamental.

Às vezes existe a necessidade de interligar 2 pontos geograficamente distintos, como Matriz e Sucursal, mas o orçamento é muito baixo para arcar com os custos de equipamentos e serviços. É aí que entra o otimizador de tráfego.

Com um otimizador é possível melhorar a performance de uma estrutura já existente, ou ainda contratar um serviço de menor capacidade e otimizá-lo posteriormente.

E o melhor: sem gastar nada com soluções de terceiros! Isso mesmo. Sem comprar equipamentos especiais e sem renovações anuais.

Para isso, temos a ferramenta TrafficSqueezer. Vale a pena conferir. Se interessou mas você não tem uma pessoa para implementar esta solução, eu posso ajudar. Fique a vontate para entrar em contato.