Samba mais disponível

Transcrição

1 Configure um cluster Samba com o CTDB REDES 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 oferecendo serviço de arquivos e impressão para sistemas Windows e Unix desde Os desenvolvedores do Samba [2] sempre tiveram dificuldades 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 servidor 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 problema Os desenvolvedores do Samba precisaram resolver alguns problemas intrínsecos para servir o mesmo arquivo ao mesmo tempo para múltiplos nós clientes ligados ao cluster do sistema de arquivos. Primeiramente, o protocolo Common Internet Filesystem 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 enviar 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 58

2 Samba REDES 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 tabelas 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 mesmas 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 Database (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 Tabela 1: Resultados do Smbtorture NBENCH Número de nós 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 significa que TDBs podem ser tão velozes quanto a memória compartilhada. Um primeiro passo dos desenvolvedores 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 hemisfério sul e a conexão do Samba Taxa de dados MB/s MB/s MB/s MB/s ao CTDB originalmente só estava disponível na forma de uma versão personalizada da versão 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- Rede pública Rede de gerenciamento Samba SSH Nó de serviço Nó de serviço Nó de gerenciamento ctdb Rede privada (CTDB) ctdb Rede privada (CTDB) ctdb /shared /shared /shared Sistema de arquivos distribuído 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. Linux Magazine #60 Novembro de

3 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 disponibilidade. O histórico completo do CTDB se encontra no wiki do Samba [8]. Como funciona O 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 configuradas de forma idêntica e servem as Quadro 1: Compilação do CTDB mesmas áreas dos arquivos dos compartilhamentos. Portanto, o modelo do CTDB é basicamente um cluster de balanceamento de carga com recursos 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 é gerenciado pelos TDBs locais. O projeto Samba usa o sistema de gerenciamento de código-fonte Git [10] desde o fim de Os desenvolvedores mantêm o Samba e o CTDB no servidor git://git.samba.org e em sua respectiva interface web [11]. Os ramos 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 Sahberg [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] make make install Não são necessárias opções especiais no./configure. O já comum --prefix 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 O Samba usa bancos de dados TDB para várias tarefas. Os bancos de dados de locks, mensagens, conexõ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 gerenciar 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 dentro 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 dados, 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 sempre 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 escalabilidade do CTDB é que os dados dos registros nos bancos voláteis são 60

4 Samba REDES 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-reparos Se 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 banco de dados: um nó é o mestre de recuperação que coleta os registros de todos os outros nós. Se ele encontrar 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, comparado 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 é escolhido 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 fcntl(). Outros processos eletivos mais complexos poderiam eliminar essa exigência, mas, por outro lado, um sistema de arquivos de cluster intacto resolve o problema de separação sujeito a erros do CTDB. Mão na massa Para instalar o CTDB, os desenvolvedores 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 Samba Listagem 2: Arquivo smb.conf para um cluster 01 [global] 02 clustering = yes 03 netbios name = cifscluster 04 workgroup = mydomain 05 security = ads 06 passdb backend = tdbsam idmap backend = tdb2 09 idmap uid = idmap gid = groupdb:backend = tdb 13 fileid:algorithm = fsname [share] 16 path = /storage/share 17 vfs objects = fileid Figura 2 O popular ctdb status mostra o status do cluster. Se 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 execuçã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 (talvez 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- Linux Magazine #60 Novembro de

5 REDES Samba 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: Figura 3 O comando ctdb ip informa ao administrador como os IPs são distribuídos ao longo dos servidores. dos TDB persistentes como secrets. tdb e passwd.tdb em private dir. As versões atuais do CTDB distribuem automaticamente os TDBs persistentes 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 identificador para armazenar informações de locking: o smbd normalmente cria Quadro 2: Como compilar seu próprio Samba 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âmetro vfs objects = fileid numa seção do arquivo de configuração ativa o 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 cluster 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 everything make 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 precisa 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-sharedmodules=. 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 versões do Samba provavelmente resolverá essa questão. Os comandos a seguir geram RPMs para sistemas Red Hat e SUSE diretamente a partir de um checkout do git: cd samba/source./packaging/rhel-ctdb/makerpms.sh vfs objects = fileid fileid:algorithm = fsid Endereços IP Para distribuir endereços IP públicos ao longo dos nós do cluster, 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 disponibilidade. 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últiplos 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 especificar 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. 62

6 Samba REDES É importante entender que o balanceamento de carga e a distribução de clientes ao longo dos nós clientes são orientados à conexã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 cliente 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ó. Ferramentas O pacote do CTDB oferece dois programas úteis, ctdb e onnode, juntamente 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 (figura 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 ferramenta muito útil que permite executar comandos em um ou múltiplos nós: Figura 4 O comando smbstatus mostra as conexões de todos os nós do cluster. 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últiplos números de nó, ou uma faixa 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- Linux Magazine #60 Novembro de

7 REDES Samba 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): Ouvintes Para garantir operações de monitoramento e failover sem problemas, é importante não usar os parâmetros de configuração interfaces ou bind interfaces only para restringir 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 , ou :: no caso do IPv6. A listagem 2 mostra um exemplo de arquivo de configuração do Samba que o administrador distribuiria para todos os nós do cluster. O comando smbstatus exibe as conexõ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 forma semelhante, os administradores 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últiplos 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. Mais informações [1] Samba: Conclusão Pela primeira vez, e sob a única condição de ter um sistema de arquivos de cluster que passe no teste do ping-pong, o Samba 3.3, em combinaçã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 baseado em registros do Samba. n onnode 0,2-5 service ctdb start Para mais informações, confira a página de manual do onnode [4]. [2] Equipe do Samba: [3] Microsoft entrega documentação do protocolo: [4] Projeto CTDB: [5] Princípios de locking de arquivos (Wikipédia em inglês): [6] TDB: [7] Repositório do CTDB de Ronnie Sahlberg: git://git.samba.org/sahlberg/ctdb.git [8] Samba e clusters: [9] Andrew Tridgell e Ronnie Sahlberg, Samba em cluster, na linux.conf.au 2008: linux.conf.au/2008/slides/178-tridge-ctdb.pdf [10] Samba via Git: php/using_git_for_samba_development [11] Interface web do repositório Git do Samba: [12] Mirror do repositório git: [13] RPMs do CTDB para RHEL: [14] RPMs do CTDB para outras distribuições: Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site:

8 Quer falar com os profissionais de TI com maior nível de conhecimento técnico do mercado nacional? Então anuncie na Linux Magazine! Segundo dados do Instituto Verificador de Circulação*, a Linux Magazine está posicionada entre as três revistas mais vendidas no segmento de TI do mercado editorial brasileiro. Além disso, é a revista que tem o público mais qualificado no quesito técnico. Nossa combinação exclusiva de conteúdo avançado com uma abordagem prática faz da Linux Magazine a publicaçã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. Para anunciar, entre em contato: anuncios@linuxmagazine.com.br *Comparação de circulação para os últimos três meses de publicações nacionais voltadas ao segmento de TI.