58 http://www.linuxmagazine.com.br

RE

DE

S

Configure um cluster Samba com o CTDB

Samba mais disponível

A versão 3.3 do Samba, associada ao gerenciador de locks CTDB, oferece suporte completo

à criação de clusters.por Michael Adam

O sistema de código aberto Samba [1] vem oferecen-do serviço de arquivos e

impressão para sistemas Windows e Unix desde 1992. Os desenvolvedores do Samba [2] sempre tiveram difi-culdades em emular características dos servidores Windows por não ter acesso às especificações, mas graças à liberação, por parte da Microsoft, dessas especificações no final de 2007 [3], a tarefa ficou muito mais fácil.

Um add-on recente chamado CTDB [4] agora oferece ao Samba um recurso que nem o Windows suporta: sistemas de arquivos em cluster. O Samba, com isso, passa a oferecer a opção de um sistema de arquivos distribuído com múltiplos nós que se apresentam como um único servidor de arquivos de alta performance. E esse sistema servi-dor de arquivos baseado em cluster é (mais ou menos) infinitamente

escalável com relação ao número de nós. O Windows 2003 oferece certo suporte a clusters, mas foi projetado tendo em mente servidores web e de bancos de dados, portanto é restrito a oito nós.

Este artigo descreve alguns dos problemas que o Samba soluciona por meio do uso de clusters. Além disso, forneceremos um histórico e analisaremos a arquitetura do CTDB, assim como forneceremos dicas de como configurar o CTDB e instalar o seu próprio cluster Samba.

O problemaOs desenvolvedores do Samba pre-cisaram resolver alguns problemas intrínsecos para servir o mesmo ar-quivo ao mesmo tempo para múlti-plos nós clientes ligados ao cluster do sistema de arquivos. Primeiramente, o protocolo Common Internet Fi-lesystem – ou CIFS, como é mais

conhecido – usado pelo Samba e pela Microsoft requer sofisticados mecanismos de locking, incluindo modos de compartilhamento que bloqueiam exclusivamente arquivos inteiros, e locks de faixas de bytes para bloquear partes de arquivos. Esses locks obrigatórios no Windows simplesmente não são conversíveis para os advisory locks (locks de aviso) usados na paisagem Posix [5]. Para contornar esse problema, o Samba precisa armazenar informações de locking do CIFS num banco de dados interno e verificar o banco de dados no momento do acesso ao arquivo.

Além disso, os vários processos do Samba precisam trocar mensagens. Por exemplo, um cliente pode en-viar uma requisição de lock com prazo de validade para uma área de arquivo atualmente bloqueada por outro cliente. Se um cliente retirar seu lock ainda dentro do prazo de

59

| REDESSamba

Linux Magazine #60 | Novembro de 2009

validade daquela requisição, o Samba concede um lock ao novo processo e envia um sinal para informar a esse novo processo à espera que há uma mensagem disponível. O sistema também precisa sincronizar as ta-belas de mapeamento de ID, que mapeiam usuários e grupos Windows aos do Unix.

O problema dos clusters também acrescenta outras complicações. Por exemplo, como servidor membro do domínio, o Samba precisa ter as mes-mas informações em todos os nós; isto é, ele precisa da senha da conta e do SID do domínio. Além disso, as sessões e conexões clientes SMB nos nós precisam ser informadas a todos os nós.

O banco de dados interno do Samba, chamado de Trivial Databa-se (TDB) [6] é um banco de dados rápido semelhante ao Berkeley DB e ao GNU DBM. O TDB suporta locks e, portanto, escrita simultânea. O Samba usa o TDB internamente

em vários locais, incluindo caches e outras tarefas de manipulação de dados. Ele até usa o mecanismo de mapeamento de memória mmap() para mapear áreas do TDB diretamente na memória principal, o que signifi-ca que TDBs podem ser tão velozes quanto a memória compartilhada.

Um primeiro passo dos desenvolve-dores do Samba para superar o desafio de um serviço de arquivos em cluster foi estender o banco de dados TDB para aprimorar o suporte a cenários de clusters. O Cluster TDB (CTDB) estreou no outono de 2007 no he-misfério sul e a conexão do Samba

ao CTDB originalmente só estava disponível na forma de uma versão personalizada da versão 3.0.25-ctdb. O código do cluster foi incluído no Samba padrão em sua versão 3.2.0, em julho de 2008, mas o esforço inicial ainda não estava completo. Com o Samba 3.3.0, lançado em janeiro de 2009, o Samba finalmente ganhou suporte completo a clusters.

O mantenedor do projeto CTDB no momento é Ronnie Sahlberg. Seu ramo git do CTDB [7] é o ponto de cristalização do código oficial do CTDB. Versões mais recentes do código suportam TDBs persisten-

Figura 1 Uma configuração básica de CTDB com dois nós de serviço e um nó de gerenciamento separado. A figura mostra uma visão esquemática do armazenamento e do sistema de arquivos de cluster compartilhado sob a raiz.

Tabela 1: Resultados do Smbtorture NBENCH

Número de nós Taxa de dados

1 109 MB/s

2 210 MB/s

3 278 MB/s

4 308 MB/s

Nó de serviço

Rede privada

(CTDB)

Sistema de arquivos distribuído

Rede privada

(CTDB)

Nó de serviço Nó de gerenciamento

/shared/shared/shared

ctdb ctdb ctdb

Samba SSH

Rede pública Rede de gerenciamento

60 http://www.linuxmagazine.com.br

REDES | Samba

tes e transações de bancos de dados no nível da API, tornando assim o CTDB utilizável por qualquer tarefa relacionada ao TDB. Além disso, os desenvolvedores estenderam o CTDB por meio de inúmeros recursos de monitoramento e alta disponibilida-de. O histórico completo do CTDB se encontra no wiki do Samba [8].

Como funcionaO Samba está presente em todos os nós, e todas as suas instâncias se apresentam como um único servidor Samba, do ponto de vista do cliente. As instâncias do Samba são configu-radas de forma idêntica e servem as

mesmas áreas dos arquivos dos com-partilhamentos. Portanto, o modelo do CTDB é basicamente um cluster de balanceamento de carga com re-cursos de alta disponibilidade.

Por trás dos panos, o daemon do CTDB, ctdbd, está em execu-ção em todos os nós. Os daemons negociam os metadados do banco de dados CTDB, sendo que cada daemon possui uma cópia local do banco TDB (chamada de LTDB) mantido para o CTDB. Essa cópia não reside no sistema de arquivos do cluster, mas na rápida memória local. O acesso aos dados é geren-ciado pelos TDBs locais.

O Samba usa bancos de dados TDB para várias tarefas. Os bancos de dados de locks, mensagens, co-nexões e sessões contêm somente dados voláteis, mas são dados que o Samba lê e grava com frequência. Outros bancos contêm informações não voláteis. O Samba não precisa de permissão de escrita nessas dados persistentes com frequência, mas a permissão de leitura é altamente crítica. Os requisitos de integridade de dados, portanto, são mais estritos para os bancos de dados persistentes do que para os voláteis. Entretanto, o desempenho é mais crítico para bancos voláteis.

O Samba utiliza duas técnicas completamente diferentes para ge-renciar bancos de dados voláteis e persistentes: no caso dos persistentes, cada nó sempre possui uma cópia completa e atualizada. O acesso de leitura é local. Se um nó quiser escrever nesse banco, ele precisa bloqueá-lo inteiro no escopo de uma transação para então completar suas operações de leitura e escrita den-tro dessa transação. A efetuação da transação distribui todas as alterações para os outros nós do CTDB.

No caso dos dados voláteis, cada nó mantém localmente apenas os registros que já acessou. Isso significa que somente um nó, o mestre de da-dos, possui os dados atualizados dos registros. Se um nó quiser escrever ou ler um registro, primeiramente ele verifica se é o mestre dos dados desse registro e, em caso positivo, acessa o LTDB diretamente. Caso contrário, ele primeiramente obtém os dados atualizados a partir do ctdbd, assume o papel de mestre dos dados e depois escreve localmente.

Como o mestre dos dados sem-pre escreve diretamente nos TDBs locais, um nó CTDB único não é mais lento que o Samba sem cluster. O segredo por trás da excelente esca-labilidade do CTDB é que os dados dos registros nos bancos voláteis são

Quadro 1: Compilação do CTDB

O projeto Samba usa o sistema de gerenciamento de código-fonte Git [10] desde o fim de 2007. Os desenvolvedores mantêm o Samba e o CTDB no servidor git://git.samba.org e em sua respectiva interface web [11]. Os “ra-mos” da versão oficial do Samba e o master estão disponíveis no repositó-rio git://git.samba.org/samba.git. O mirror [12] oferece até arquivos tar dos snapshots de cada revisão.

Os fontes oficiais do CTDB estão disponíveis no repositório de Ronnie Sah-berg [7]. O repositório em git:git.samba.org/obnox/samba-ctdb.git contém versões do Samba com extensões de cluster baseadas nos ramos oficiais – particularmente uma variante de cluster do Samba 3.2 (v3-2-ctdb//) pronta para produção. No momento da escrita deste artigo, o software CTDB era compatível com Linux e AIX. O sequência normal de comandos compila e instala o software:

cd ctdb/./autogen.sh./configure [opções]makemake install

Não são necessárias opções especiais no ./configure. O já comum --pre-fix permite personalizar os diretórios de instalação. Em sistemas RPM, é possível gerar um pacote diretamente a partir de um checkout do git:

cd ctdb/./packaging/RPM/makerpms.sh

Há RPMs pré-compilados do CTDB e do Samba v3-2-ctdb para Red Hat [13] e outras distribuições [14].

Listagem 1: Arquivo /etc/ctdb/nodes

01 192.168.46.7002 192.168.46.7103 192.168.46.72

61

| REDESSamba

Linux Magazine #60 | Novembro de 2009

enviados para somente um nó, em vez de para todos os nós. Afinal, é perfeitamente aceitável perder as alterações feitas por um nó a um banco volátil caso esse nó saia do cluster. As informações só dizem respeito às conexões desse mesmo nó. Os outros nós seriam incapazes de aproveitar tais informações de qualquer maneira.

Testes de desempenho num cluster [9] confirmam que essa arquitetura é sólida. Um teste Smbtorture do NBENCH em 32 clientes é mostrado na tabela 1. Uma única conexão com um compartilhamento num nó do cluster alcança taxa de transferência de 1,7 GBps.

Auto-reparosSe um nó falhar, o banco volátil provavelmente perderá seu mestre de dados referente a alguns registros. O processo de recuperação restaura um estado consistente para o ban-co de dados: um nó é o mestre de recuperação que coleta os registros de todos os outros nós. Se ele en-contrar um registro em um mestre de dados, procura o nó com a cópia mais recente. Para permitir que isso aconteça, o CTDB mantém um nú-mero de sequência para os registros num campo do cabeçalho, compa-rado com o TDB padrão; o número é incrementado a cada vez que o registro é transferido para outro nó. Ao final do processo de recuperação, o mestre de recuperação é o mestre de dados para todos os registros de todos os TDBs.

O mestre de recuperação é esco-lhido por um processo de eleição que utiliza o que se conhece como lock de recuperação. Esse recurso exige que o CTDB suporte locks Posix fcn-tl(). Outros processos eletivos mais complexos poderiam eliminar essa exigência, mas, por outro lado, um sistema de arquivos de cluster intac-to resolve o problema de separação sujeito a erros do CTDB.

Mão na massaPara instalar o CTDB, os desenvolve-dores do Samba recomendam (pelo menos) duas redes, de preferência fisicamente separadas: uma rede pública a partir da qual os clientes acessarão os serviços disponíveis (Samba, NFS, FTP...) e uma rede privada, que o CTDB utiliza para lidar com a comunicação interna ao cluster.

A rede do sistema do cluster pode estar numa rede separada ou na mesma utilizada internamente pelo CTDB. Uma rede de gerenciamento separada pode se mostrar boa para, digamos, login nos nós via SSH. A figura 1 mostra a configuração básica de um cluster CTDB.

O quadro 1 dá mais informações sobre como adicionar o CTDB a implementações de Samba que já estejam em uso. O arquivo central de configuração do CTDB é o /etc/sysconfig/ctdb. O mais importante a especificar é o arquivo de lock de recuperação, por meio da variável CTDB_RECOVERY_LOCK. Além disso, o u-suário administrador precisa popular o arquivo /etc/ctdb/nodes com os IPs de todos os nós do CTDB na rede privada (listagem 1). Esse arquivo também precisa ser idêntico em todos os nós.

Configuração do SambaSe você já tem suporte a cluster no Samba (confira o quadro 2), será preciso configurá-lo com os seus próprios parâmetros no smb.conf. O parâmetro clustering = yes ativa o recurso de clusters em tempo de exe-cução. Sem ele, a versão do Samba com esse recurso funcionará como qualquer outra versão mais antiga, ou seja, sem suporte a clusters.

Apesar do que dizem as várias páginas do wiki do Samba, não é necessário colocar private dir no sistema de arquivos do cluster (tal-vez apenas para um smbpasswd local). Esta informação só se aplica a versões mais antigas do CTDB, que eram incapazes de lidar com bancos de da-

Listagem 2: Arquivo smb.conf para um cluster

01 [global]02 clustering = yes03 netbios name = cifscluster04 workgroup = mydomain05 security = ads06 passdb backend = tdbsam07 08 idmap backend = tdb209 idmap uid = 1000000-200000010 idmap gid = 1000000-20000001112 groupdb:backend = tdb13 fileid:algorithm = fsname1415 [share]16 path = /storage/share17 vfs objects = fileid

Figura 2 O popular ctdb status mostra o status do cluster.

62 http://www.linuxmagazine.com.br

REDES | Samba

dos TDB persistentes como secrets.tdb e passwd.tdb em private dir. As versões atuais do CTDB distribuem automaticamente os TDBs persisten-tes ao longo do cluster.

Se for necessário mapear grupos, será preciso alterar o back-end, do padrão ldb para o tdb, com a opção groupdb:backend = tdb.

O Samba utiliza um código iden-tificador para armazenar informações de locking: o smbd normalmente cria

esse código aplicando a função stat() ao dispositivo do arquivo e ao número do inode. Porém, o cluster precisa de um ID que seja válido para múltiplos nós, pois o número do dispositivo é variável para um mesmo arquivo no cluster. O módulo do VFS fileid oferece uma técnica alternativa para formar um ID de arquivo que seja válido em todo o cluster. O parâme-tro vfs objects = fileid numa seção do arquivo de configuração ativa o

módulo fileid, seja globalmente ou apenas para um compartilhamento. O valor da opção fileid:algorithm na seção [global] configura o método, como em:

vfs objects = fileidfileid:algorithm = fsid

Endereços IPPara distribuir endereços IP pú-blicos ao longo dos nós do clus-ter, existem três opções: uma das possibilidades é atribuir endere-ços estaticamente sem envolver o CTDB. Nesse caso, o CTDB não pode usar seu recurso de alta dis-ponibilidade. Outra possibilidade é usar um único IP como endereço público do cluster no que se chama de modo LVS e permitir que o nó mestre LVS distribua o endereço para os nós participantes. Definir as variáveis CTDB_LVS_PUBLIC_IP e CTDB_PUBLIC_INTERFACE no arquivo /etc/sysconfig/ctdb ativa esse modo.

O terceiro método é permitir que o CTDB atribua dinamicamente múl-tiplos endereços IP públicos aos nós. Em combinação com um método round-robin, essa opção acrescenta o balanceamento de carga e a alta disponibilidade ao cluster CTDB. Para permitir isso, é preciso espe-cificar um arquivo – normalmente /etc/ctdb/public_addresses – com a variável CTDB_PUBLIC_ADDRESSES no arquivo /etc/sysconfig/ctdb em cada nó; o arquivo contém o conjunto de endereços com as máscaras de rede e interfaces de rede que o CTDB vai atribuir aos nós.

A lista de endereços não precisa estar em todos os nós, nem precisa ser idêntica em todos os nós. Em vez disso, é possível usar a topologia da sua rede pública e criar partições. Se um nó falhar, o CTDB transfere seus IPs públicos para outros nós do cluster, que possuem esses endere-ços em suas listas public_addresses.

Quadro 2: Como compilar seu próprio Samba

Se você não puder usar pacotes pré-compilados (ou simplesmente preferir não usá-los), pode compilar e instalar o Samba 3.3 com recursos de clus-ter a partir do código-fonte. Basta usar a sequência padrão de comandos:

cd samba/source./autogen.sh./configure \--with-cluster-support \--with-ctdb=/usr/include \--with-shared-modules=idmap_tdb2 [opções]make everythingmake install

O comando autogen.sh só é necessário quando se usa um snapshot do repositório git em vez do arquivo tar. O parâmetro --with-ctdb=configure define onde se localizam os cabeçalhos do CTDB no sistema. O Samba pre-cisa deles para compilar o código a fim de se comunicar com o CTDB. Se você já instalou o CTDB a partir de um pacote, o diretório mais indicado é o /usr/include/.

Compilar a variante de cluster do módulo padrão de mapeamento de IDs, idmap_tdb, adiciona o idmap_tdb2 à lista de módulos em --with-shared-modules=. A equipe do Samba atualmente está tentando unir o idmap_tdb e o idmap_tdb2 para suportar o idmap_tdb no cluster. Uma das próximas ver-sões do Samba provavelmente resolverá essa questão.

Os comandos a seguir geram RPMs para sistemas Red Hat e SUSE direta-mente a partir de um checkout do git:

cd samba/source./packaging/RHEL-CTDB/makerpms.sh

Figura 3 O comando ctdb ip informa ao administrador como os IPs são distribuídos ao longo dos servidores.

63

| REDESSamba

Linux Magazine #60 | Novembro de 2009

É importante entender que o balanceamento de carga e a dis-tribução de clientes ao longo dos nós clientes são orientados à co-nexão. Se um IP mudar de um nó para outro, todas as conexões que estiverem usando ativamente esse IP serão descartadas e os clientes precisarão reconectar-se.

Para evitar atrasos, o CTDB usa um truque: quando um IP se muda, o novo CTDB “faz cócegas” no clien-te com um pacote TCP ACK ilegal (tickle ACK, como é chamado) que contém um número de sequência inválido (zero) e um número ACK zero. O cliente responde com um pacote ACK válido, o que permite que o novo proprietário do IP feche a conexão com um pacote RST, for-çando assim o cliente a reestabelecer a conexão com o novo nó.

FerramentasO pacote do CTDB oferece dois programas úteis, ctdb e onnode, jun-tamente com o daemon ctdbd. A ferramenta ctdb é a interface cliente para gerenciar o cluster CTDB. O comando usado com mais frequ-ência é o ctdb status, que exibe o status geral do cluster (figura 2). O comando ctdb ip mostra a distribui-ção de IPs públicos nos nós (figu-ra 3). O ctdb permite que o admin realize ações no cluster, tais como ativar ou desativar nós individuais, adicionar ou remover IPs públicos, forçar uma recuperação ou aplicar vários ajustes. Confira a página de manual do CTDB [4] para mais informações.

O script onnode é uma ferramen-ta muito útil que permite executar comandos em um ou múltiplos nós:

onnode nó[,nó...] comando

O onnode obtém os detalhes do nó a partir do arquivo /etc/ctdb/nodes. O alvo pode ser um ou múl-tiplos números de nó, ou uma fai-xa de números, ainda todos os nós (all), os nós conectados (con), os nós saudáveis (ok) ou o mestre de recuperação (rm). O onnode usa o SSH para se conectar aos nós; por-

Figura 4 O comando smbstatus mostra as conexões de todos os nós do cluster.

www.lpi-brasil.org

64 http://www.linuxmagazine.com.br

REDES | Samba

Mais informações

[1] Samba: http://www.samba.org

[2] Equipe do Samba: http://www.samba.org/samba/team/

[3] Microsoft entrega documentação do protocolo: http://www.samba.org/samba/PFIF/

[4] Projeto CTDB: http://ctdb.samba.org/

[5] Princípios de locking de arquivos (Wikipédia em inglês): http://en.wikipedia.org/wiki/File_locking

[6] TDB: http://tdb.samba.org

[7] Repositório do CTDB de Ronnie Sahlberg: git://git.samba.org/sahlberg/ctdb.git

[8] Samba e clusters: http://wiki.samba.org/index.php/Samba_&_Clustering

[9] Andrew Tridgell e Ronnie Sahlberg, “Samba em cluster”, na linux.conf.au 2008: http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/178-tridge-ctdb.pdf

[10] Samba via Git: http://wiki.samba.org/index.php/Using_Git_for_Samba_Development

[11] Interface web do repositório Git do Samba: http://git.samba.org

[12] Mirror do repositório git: http://repo.or.cz/w/Samba.git

[13] RPMs do CTDB para RHEL: http://ctdb.samba.org/packages/

[14] RPMs do CTDB para outras distribuições: http://download.opensuse.org/repositories/home:/iamobnox/

Gostou do artigo?Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br

Este artigo no nosso site: http://lnm.com.br/article/3110

tanto, logins por SSH sem senha são uma boa ideia na rede interna do CTDB.

Usando o onnode, o administrador pode facilmente colocar arquvios de configuração nos nós ou instalar o mesmo pacote de software após armazenar os dados no sistema de arquivos do cluster:

onnode all cp /shared/smb.conf /etc/samba/smb.conf

Como o onnode só precisa fazer referência aos arquivos dos nós, é possível usá-lo para iniciar o ctdbd em todos os nós (ou apenas alguns):

onnode 0,2-5 service ctdb start

Para mais informações, confira a página de manual do onnode [4].

OuvintesPara garantir operações de monito-ramento e failover sem problemas, é importante não usar os parâme-tros de configuração interfaces ou bind interfaces only para res-tringir os IPs ou interfaces de rede nos quais o Samba deve escutar. O monitoramento de serviço do Samba exige que o Samba escute no endereço curinga 0.0.0.0, ou :: no caso do IPv6.

A listagem 2 mostra um exem-plo de arquivo de configuração do Samba que o administrador distri-buiria para todos os nós do cluster. O comando smbstatus exibe as co-nexões de todos os nós do cluster. Para isso, ele não apenas lista os IDs dos processos do smbd como também mostra seus prefixos de número do nó (figura 4). De for-ma semelhante, os administrado-res podem influenciar os daemons do Samba ao longo do cluster por meio do smbcontrol.

Ao usar um cluster Samba, não faz algum sentido utilizar o nome NetBIOS do serviço, nmbd, em múl-

tiplos nós – o broadcast sofreria de personalidade múltipla. Além disso, o serviço WINS não é capaz de lidar com clusters porque o Samba não trata bancos de dados wins.dat com o CTDB.

ConclusãoPela primeira vez, e sob a única condição de ter um sistema de ar-quivos de cluster que passe no teste do ping-pong, o Samba 3.3, em com-

binação com o CTDB, oferece um cluster CIFS altamente escalável e fácil de instalar para uso em produ-ção sem necessidade de patches e “gambiarras”. Após a configuração básica, a configuração baseada em registros e o script onnode tornam a administração do cluster uma tarefa aprazível. Consulte os links deste artigo para mais informações sobre o novo sistema de configuração ba-seado em registros do Samba. n

Segundo dados do Instituto Verificador de Circulação*, a Linux Magazineestá posicionada entre as três revistas mais vendidas no segmento de TIdo mercado editorial brasileiro. Além disso, é a revista que tem o público mais qualificado no quesito técnico. Nossa combinação exclusiva de con-teúdo avançado com uma abordagem prática faz da Linux Magazine a publi-cação preferida de quem toma decisões e faz recomendações para compra de produtos e contratação. Anuncie conosco e fale com esse público.

Quer falar com os 20.000 profissionais de TI com maior nível de conhecimento técnico

do mercado nacional? Então anuncie na Linux Magazine!

*Comparação de circulação para os últimos três meses de publicações nacionais voltadas ao segmento de TI.

Para anunciar, entre em contato:anuncios@linuxmagazine.com.br11 4082.1300