O objetivo deste artigo é viabilizar o uso do catálogo do Bacula (banco de dados) de maneira replicada e com balanceamento de carga providos pelo PgPool – Postgresql.
Repositórios:
Utilizando o Debian 7.2, adicionei o repositório do Postgresql em todas as máquinas que hospedarão os serviços, para poder utilizar as versões mais novas deste banco de dados:
wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
add-apt-repository “deb http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main”
apt-get update
Configurando a Replicação e Balanceamento de Carga com o PostgreSQL e Pgpool2
(fonte: http://www.keyup.eu/en/blog/89-replication-and-load-balancing-with-postgresql-and-pgpool2)
Assumindo que temos 3 máquinas com Debian Linux na mesma rede:
192.168.0.1 – para o pgpool2
192.168.0.2 – para o primeiro servidor pgsql
192.168.0.3 – para o segundo servidor pgsql
Claro que você pode ter mais de dois servidores pgsql ou até um postgres na mesma máquina do pgpool2, o que neste caso não é muito recomendado.
Instalar os Bancos Postgres (nós)
Acesse a máquina 192.168.0.2 e instale o pacote do Postgres:
apt-get install postgresql
Altere a senha padrão do postges:
sudo su postgres
psql
alter user postgres with password ‘novasenha’;
q
Repita este passo para a outra máquina servidora de banco de dados – 192.168.0.3.
Forneça permissões de acesso às bases para o pgpool2
Abra o arquivo /etc/postgresql/9.2/main/pg_hba.conf e insira esta linha no final do arquivo:
host all postgres 192.168.0.0/24 md5
Reinicie o postgresql e repita o procedimento para a seguinte máquina – 192.168.0.3.
Prepare os bancos para serem acessados pelo o pgpool2
Ainda nas duas máquinas servidoras dos bancos (192.168.0.2 e 3), instale também:
apt-get install postgresql-9.2-pgpool2
Install pgpool2
Acesse a máquina 192.168.0.1 e instale o pgpool2:
apt-get install pgpool2
Consiga a senha em formato md5 do usuário postgres (em uma das máquinas servidoras do bd), que definimos anteriormente. Acesse a console psql (su postgres, psql), e execute o comando:
select passwd from pg_shadow where usename = 'username';
Copie a senha em formato md5.
Abra /etc/pgpool2/pcp.conf (na máquina do Pgpool) e adicione a seguinte linha:
user:md5password
Que se parecerá com isso:
postgres:ahb52d7w3o4n2fg8x8wfd4rdbctbjfkq
Então configure /etc/pgpool2/pgpool.conf. Sua configuração dos nós deve se parecer com isso:
backend_hostname0 = '192.168.0.2'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/9.2/main/'
backend_flag0 = 'ALLOW_TO_FAILOVER'
backend_hostname1 = '192.168.0.3'
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/9.2/main/'
backend_flag1 = 'ALLOW_TO_FAILOVER'
Você também pode querer alterar a porta do Pgpool. Utilizamos a porta padrão neste manual:
port = 5432
Habilite também a replicação e o balanceamento de carga:
replication_mode = on
...
load_balance_mode = on
Para iniciar o Pgpool:
pgpool
Para parar:
pgpool stop
Mas inicialmente você deve iniciar o pgpool com visão das mensagens de log na tela:
pgpool -n &
Para testar o pool:
createdb -p 5432 -U postgres bench_replication
ou:
psql -p 5432 -U postgres
Pronto!
Em caso de problemas leia também: http://pgpool.projects.pgfoundry.org/pgpool-II/doc/tutorial-en.html
Instalação do Bacula:
Durante a instalação do Bacula ignore a instalação e configuração do Postgresql que será instalado como dependência. Ele pode inclusive ser desinstalado.
Utilize o dpkg-reconfigure bacula-director-pgsql para criar o banco de dados em nosso pool.
Durante as perguntas, utilize conexão tcp/ip e autenticação por palavra-passe (senha).
Se o configurador automático terminar com erro, pode ser necessário executar o script que popula o banco de dados do Bacula manualmente:
/usr/share/bacula-director/make_postgresql_tables -U postgres
Assim que conseguir criar o banco, direitos para o usuário bacula e popular as tabelas, o Bacula estará pronto para ser utilizado.
Avaliação de Performance
Como existe uma clara evolução na Performance do PostgreSQL que acompanha o lançamento de novas versões*, optou-se pela utilização da versão 9.3 para este estudo (a mais nova).
*http://suckit.blog.hu/2009/09/26/postgresql_history
Comparou-se uma estrutura simples (aplicação Bacula conectado a um servidor Postgresql Simples), com outra estrutura balanceada e replicada (Bacula conectado localmente ao serviço PgPool, configurado para uso de dois servidores Postgresql em máquinas distintas).
Simulação (carga de trabalho sintética – pgbench)
As duas estruturas utilizam conexão com o banco TCP/IP, de maneira a igualar questões de tráfego de rede local que poderiam impactar nas medições.
Máquinas Virtuais Virtual Box, com 01 (um) processador e 384 (trezentos e oitenta e quatro) Mb de memória RAM. Sistema Operacional Debian 7.2.
O pgbench consiste num conjunto de comandos e de massa de dados para realização de testes de benchmark do Postgresql.
Para criar o banco com dados sintéticos:
createdb -U postgres -p 5432 bench_parallel
/usr/lib/postgresql/9.3/bin/pgbench -i -s 10 -p 5432 -U postgres bench_parallel
Obs.: o -s 10, por exemplo, cria 1.000.000 tuplas no banco.
Executar o benchmark:
time /usr/lib/postgresql/9.3/bin/pgbench -t 1000 -p 5432 -U postgres bench_parallel
Obs. 2: -t é a quantidade de transações submetidas por cliente.
===========================================================================
Escrita 1000000 tuplas
Single: 6s;
Balanceado/Replicado: 131s;
Escrita 2000000 tuplas
Single: 39s;
Balanceado/Replicado: 263s;
Escrita 3000000 tuplas
Single: 59s;
Balanceado/Replicado: 384s;
Escrita 4000000 tuplas
Single: 80s;
Balanceado/Replicado: 524s;
Escrita DDL 5000000 tuplas
Single: 102s;
Balanceado/Replicado: 670s;
===========================================================================
Benchmark 1000 transações
Single: 84s;
Balanceado/Replicado: 26s;
Benchmark 2000 transações
Single: 128s;
Balanceado/Replicado: 57s;
Benchmark 3000 transações
Single: 194s;
Balanceado/Replicado: 96s;
Benchmark 4000 transações
Single: 383s;
Balanceado/Replicado: 233s;
Benchmark 5000 transações
Single: 415s;
Balanceado/Replicado: 279s;
===========================================================================
Medição (carga de trabalho real do Bacula)
02 jobs de backup e de leitura executados simultâneamente, com a mesma quantidade de arquivos armazenados para os dois clientes.
As medições de leituras foram consolidadas pela média dada por 3 execuções.
===========================================================================
Escrita backup 40 mil arquivos:
Single: Job1 15 mins 47 secs; Job2 14 mins 24 secs;
Replicado: Job1 18 mins 52 secs; Job2 17 mins 10 secs;
Escrita backup 80 mil arquivos:
Single: Job1 41 mins 31 secs; Job2 38 mins 45 secs;
Replicado: Job1 41 mins 23 secs; Job2 39 mins 3 secs;
Escrita backup 120 mil arquivos:
Single: Job1 51 mins 45 secs; Job2 57 mins 40 secs;
Replicado: Job1 59 mins 56 secs; Job2 53 mins 21 secs;
===========================================================================
===========================================================================
Escrita backup 100 mil arquivos vazios:
Single: Job1 2 mins 3 secs; Job2 1 min 46 secs secs;
Replicado: Job1 6 mins 15 secs; Job2 6 mins 2 secs;
Escrita backup 200 mil arquivos vazios:
Single: Job1 7 min 8 secs; Job2 6 mins 22 secs;
Replicado: Job1 ; Job2 x;
===========================================================================
===========================================================================
Leitura backup 40 mil arquivos:
Single: Job1 35s; Job2 57s;
Replicado: Job1 39s; Job2 1m3s;
Leitura backup 80 mil arquivos:
Single: Job1 1m51s; Job2 1m8s;
Replicado: Job1 1m57s; Job2 1m4s;
Leitura backup 120 mil arquivos:
Single: Job1 2m12s; Job2 2m30s;
Replicado: Job1 2m22s; Job2 2m26s;
===========================================================================
Conclusões
Os comandos de escrita provocados pelo comando pgbench na inicialização da massa de teste possuem uma performance consideravelmente pior na estrutura replicada, provavelmente por conta de controles de sincronismo e consistência entre as bases, o que não chega a ser tão impactante, na medida que estes comandos são executados eventualmente na sua criação ou modificação, mas pode comprometer processos de disaster recovery do mesmo, ou a performance de aplicações com alta dependência de escrita no banco.
Em relação à superioridade na performance de leitura e escrita simuladas pelo benchmark – pgbench (em torno de 50% mais eficiente) na estrutura balanceada e replicada, pode ser bastante vantajosa para sistemas web (ou outros) em que a escrita no banco de dados não seja predominante.
Na medição da carga de trabalho provida pela ferramenta de Backup Bacula, a velocidade de escrita e leitura tanto para a estrutura simples quanto para a estrutura com 02 (dois) bancos de dados replicados se mostra basicamente igual na medição, em se tratando de arquivos com variadas quantidade de dados, selecionados aleatoriamente em ambiente de produção. Entretanto utilizando-se arquivos com quantidades de dados bastante reduzidas (mensagens em servidor de email), gerou-se um overhead na capacidade de escrita dos bancos e pode-se verificar uma pior performance para o ambiente replicado e balanceado, no que tange operações de escrita.
A maneira como o Servidor do Bacula realiza conexões com o Banco de Dados para leitura (listagem e restauração de arquivos) faz com que não haja um diferença de performance, na medida que as suas funções de leitura são sempre seriais. Os tempos de listagem dos arquivos backupeados são basicamente iguais para as duas topologias.
O uso de consultas paralelas poderia ser tentada (segregação de diferentes tabelas em bancos diferentes, também provido pelo PgPool); entretanto provavelmente não haveriam muitos ganhos de performance, na medida que apenas uma tabela é basicamente utilizada para a maioria das operações do Bacula, tanto de backup quanto restore (tabela Job).
Disponível em: 
Português
