As emocionantes aventuras de um sysadmin linux na procura pelo uptime perfeito!

FLISOL-DF 2011: Escalabilidade e Alta Disponibilidade

Posted: abril 13th, 2011 | Author: coredump | Filed under: Linux e Open Source | Tags: , ,

Essa é a palestra sobre Escalabilidade e Disponibilidade que apresentei no FLISOL-DF 2011.

Teve até um número de pessoas legal para o horário, agradecimentos à coordenação que conseguiu me encaixar com tamanha rapidez na grade!

Eu vou ter de mexer em algumas coisas para diminuir tamanho e alguns assuntos, mas no mais, foi bem legal.

intel

No Comments »

MongoDB: sharding e mapReduce()

Posted: novembro 14th, 2010 | Author: coredump | Filed under: Linux e Open Source, Programação | Tags: , , ,

Uma das coisas interessantes que me atraiu a testar o MongoDB foram as capacidades de sharding e replicação do mesmo. Sharding é uma técnica muito usada atualmente para lidar com escalabilidade de massas de dados, consiste basicamente em dividir os dados de uma aplicação entre vários bancos: por exemplo, numa aplicação com 1000 usuários o sharding faria que os usuários com nomes de A a J ficassem em um servidor, e de K a Z em outro servidor. Claro que tem mais coisas envolvida, recomendo a leitura do excelente artigo Sharding for startups que discute como particionar os dados e como fazer aplicações que suportam sharding.

O MongoDB é um banco de dados não SQL que tem ganhado espaço. Foursquare por exemplo usa o Mongo com uma massa de dados razoável (3 shards de 60Gb, de acordo com uma informação já um pouco desatualizada). Nas versões mais recentes, o MongoDB também ganhou suporte nativo a sharding e uma replicação mais robusta.

Bancos NoSQL como  Mongo tem grandes diferenças com os RDB existentes. A mais importante, SQL não existe, então algumas coisas como SELECT SUM() ou SELECT … GROUP BY que se está acostumado a usar tem de ser implementados de outra forma. As vezes é melhor implementar todo esse tratamento na aplicação, mas no caso do MongoDB ele possui uma implementação de Map/Reduce nativa, exatamente para se fazer esse tipo de tratamento de dados. Um detalhe interessante na performance deste sistema é que no caso de bancos com shards o trabalho é dividido entre os mesmos.

Para testar o ganho de performance e se a divisão era feita corretamente, fiz o seguinte teste: habilitei sharding em uma collection com dados de logs com 19 milhões de registros, cada registro com tamanho entre 150 e 220 bytes. Usei as seguintes funções para o Map/Reduce:

Função de mapeamento (map):

function m() {
	emit(this.c, {duration: this.d,
			size: this.s,
			conn: 1});
}

Função de redução (reduce):

function r(key, val) {
	var total_duration = 0;
	var total_size = 0;
	var total_conn = 0;
	for (var i = 0; i < val.length; i++) {
		total_duration += val[i].duration;
		total_size += val[i].size;
		total_conn += 1;
	}
	return {duration: total_duration,
			size: total_size,
			total_conn : total_conn };
}

O balanceamento dos dados entre os dois shards que eu criei demorou quase três horas, nesse tempo o banco continua disponível exceto por updates em dados que estão no processo de serem movidos para outro shard. Depois de terminado esse processo eu tinha dez milhões de registros no servidor original e os outros nove milhões e qualquer coisa no segundo shard.

O processo de Map/Reduce com apenas um banco demorou 15 minutos para completar, agindo sobre todos os registros. Depois do sharding, esse tempo caiu pela metade indo para 7 minutos. Se a melhora for sempre nesta proporção a adição de shards implica diretamente na divisão do tempo do processamento pelo número de shards envolvidos. De acordo com a equipe de desenvolvimento do MongoDB eles estão trabalhando agora para melhorar o paralelismo da operação de Map/Reduce mas aparentemente isso depende da engine que eles usam para interpretar o javascript das funções.

O sharding do MongoDB é bem implementado, mas tem de se ter cuidado na hora de escolher a chave pela qual ele vai fazer a divisão dos dados. Uma chave mal escolhida pode fazer com que os shards fiquem mal balanceados e acabe com todo o ganho de performance que teria sido conseguido. Um exemplo seria se no meu teste eu tivesse acabado com um milhão de records em um dos shards, e os outros dezoito no outro: os resultados estariam disponíveis no shard com menos data muito antes do outro terminar.

intel

No Comments »

Ftrace – tracing de funções do kernel Linux

Posted: novembro 10th, 2010 | Author: coredump | Filed under: Linux e Open Source, Programação | Tags: , , ,

Saiu um artigo sobre o assunto na LWN a alguns meses atrás, o function tracer do Kernel tá uma coisa linda. Basicamente a ferramenta é colocada diretamente no kernel para fazer tracing do que está acontecendo no kernel.

Eu tenho por exatamente usado para estudar internals. Por exemplo:

[tracing]# cat trace
          <idle>-0     [000] 1726568.996435: hrtimer_get_next_event <-get_next_timer_interrupt
          <idle>-0     [000] 1726568.996436: _spin_lock_irqsave <-hrtimer_get_next_event

Essa saída aí em cima mostra a thread idle (swapper), PID 0, rodando na CPU 0, timestamp de quando a função foi executada e as funções que estão rodando. Existem várias configurações que podem ser feitas, como por exemplo adicionar informações de latência no tracing. Isso faz com que além dos timestamps sejam colocadas as informações de quanto tempo cada função demorou para executar.

Eu escrevi um scriptizinho em bash para facilitar minha vida ao ligar e desligar o tracing. Na minha máquina funcionou beleza (ainda tem bugs, mas funciona), mas lembre-se que alguns tracers (como o function) tem de ser habilitados no Kernel e pelo menos no kernel do Debian não estavam. Como eu já estava recompilando o 2.6.36 para fazer alguns testes, aproveitei para habilitar.

O Perfikt é uma ferramenta  GTK que usa dados do Valgrind e aparentemente tem suporte para a interface de tracing do kernel, fornecendo uma interface gráfica bem simpática para a parada.

Mais sobre o assunto (em inglês):

intel

No Comments »

Código de Ética do Sysadmin

Posted: setembro 17th, 2010 | Author: coredump | Filed under: Linux e Open Source | Tags: ,

Eu me associei a LOPSA no Sysadmin Appreciation Day deste ano, tava baratinho, dá uns descontos para OReilly e é uma comunidade de Sysadmins, que era o que eu estava procurando. Eles também tem um ótimo Código de Ética. Numa dessas madrugadas insones eu aproveitei para dar uma traduzida inicial nele, que está colocada abaixo. Ainda tem coisa pra mexer e estou aceitando dicas.

O Código de Ética do Administrador de Sistemas

Nós como Administradores de Sistemas profissionais nos comprometemos aos mais altos padrões de conduta ética e profissional e concordamos em ser guiados por este código de ética, e encorajamos a todos outros Administradores de Sistemas a fazer o mesmo.

Profissionalismo Irei manter a conduta profissional no ambiente de trabalho e não permitirei que questões ou crenças pessoais me façam tratar pessoas injustamente ou sem profissionalismo.

Integridade Serei honesto nas minhas relações profissionais e verdadeiro nas minhas competências e nos impactos dos meus erros. Buscarei assistência de outros quando for necessário.

Irei evitar conflitos de interesses e tendências sempre que possível. Quando meu conselho for procurado, se eu tiver algum conflito de interesse ou tendência, irei declará-los se apropriado, e recusar se necessário.

Privacidade Irei acessar informações privadas em sistemas computacionais apenas quando necessário no curso de meus deveres técnicos. Irei manter e proteger a confidencialidade de qualquer informação a qual eu tenha tido acesso, independente do método pelo qual eu tenha tido conhecimento à mesma.

Leis e Normas Irei me educar com relação a leis, regulamentos e normas relativas a execução dos meus deveres.

Comunicação Irei me comunicar com a gerência, usuários e colegas sobre assuntos computacionais de interesse mútuo. Irei me esforçar para escutar e entender as necessidades de todas as partes envolvidas.

Integridade dos sistemas Irei me esforçar para garantir a integridade, confiabilidade e disponibilidade dos sistemas pelos quais eu sou responsável.

Irei desenhar e manter cada sistema de maneira a suportar o propósito do sistema para a organização.

Educação Irei continuar a atualizar e melhorar meu conhecimento técnico e outras habilidades relacionadas ao trabalho. Irei compartilhar meu conhecimento e experiência com outros.

Responsabilidade com a Comunidade de Computação Irei cooperar com a comunidade de computação para manter a integridade de redes e recursos computacionais.

Responsabilidade social Como profissional informado, irei encorajar o desenvolvilento e adoção de normas e leis consistentes com estes princípios éticos.

Responsabilidade ética Irei me esforçar para construir e manter um ambiente de trabalho seguro, sadio e produtivo.

Irei fazer o meu melhor para tomar decisões consistentes com a segurança, privacidade e bem estar da minha comunidade e do público, e revelar rapidamente fatores que possam representar riscos ou perigos desconhecidos.

Irei aceitar e oferecer críticas construtivas de trabalhos técnicos quando apropriado e irei creditar corretamente as contribuições de outros.

Irei liderar por exemplo, mantendo elevados padrões éticos e graus de profissionalismo no exercício dos meus deveres. Irei auxiliar meus colegas a seguir este código de ética.

No Comments »

PKI: Indo de Gnomint para EJBCA

Posted: abril 1st, 2010 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: , , ,

Uma das coisas que eu sempre me preocupo em fazer ao chegar em um novo trabalho para lidar com infraestrutura é instalar uma série de serviços para ajudar na administração. Isso inclui wikis, monitoramento, um sistema de tickets de serviço, e por ai vai. Outra coisa é criar uma estrutura básica de PKI para emissão de certificados SSL para servidores e outros serviços.

Gerenciar uma Certificate Authority (Autoridade Certificadora ou CA) pode ser feito de várias formas, desde usando os comandos do openssl na mão, passando por utilizar as facilidades de PKI do Active Directory do Windows e algumas ferramentas gráficas como o Gnomint.

Até a semana passada eu estava realmente usando o Gnomint, mas tive uma série de problemas, principalmente com encoding e com um plano de utilizar essa PKI de forma mais ampla. O Gnomint é ótimo para gerenciar pequenas PKIs, mas quando você pensa em emitir milhares de certificados SSL, vocẽ precisa de algo mais parrudo.

Acabei lendo sobre o EJBCA, que é uma aplicação que roda em JBoss e tem uns usuários bem famosos (incluindo o SERASA, aqui no Brasil). O EJBCA foi então a escolha para gerência da PKI.

A instalação dele no Debian (Lenny) foi bem simples, basicamente porque o pacote JBoss do Debian atualmente não faz porra nenhuma, e você tem de baixar o mesmo do site do JBoss e instalar na mão (isso quer dizer descompactar para algum lugar, eu sugiro o /opt). Algumas coisas que eu fiz e podem ajudar:

  • Instalar o JDK6 e o ant via pacote do Debian mesmo: sun-java6-sdk e ant, o ant instala como ant-gcj mas funcionou certinho.
  • Baixar do site da Sun a JCE (Java Cryptography Extensions), e colocar os conteúdos do zip em /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security – isso é necessário para que o Java aceite algumas características mais pesadas em certificados, como senhas com mais de 7 caracteres.
  • Baixe o EJBCA e descompacte no /opt também. Eles não avisam, mas um monte de coisas precisa ser feita desse diretório, ou seja, não se pode simplesmente instalar e apagar, tem de guardar e fazer backup.
  • Configurar as variáveis JAVA_HOME e APPSRV_HOME (apontando para onde está o JBoss) no seu ambiente corretamente. Isso é uma mão na roda e evita que você rode a parada com uma jvm diferente da que você quer. Configure também as variáveis ANT_OPTS e JAVA_OPTS para incluir os parâmetros de memória, eu uso “-Xms128m -Xmx768m” em uma  VM de 1 GB de memória.
  • Se você vai usar poucos certificados, ou está instalando para testar, pode utilizar o banco de dados padrão que é em memória. Caso contrário, instale o postgresql-8.3 (ou mais atual).

Com isso você mata os pré-requisitos do EJBCA. De resto, o guia de instalação dele é bem certinho. Mas basicamente o que você tem de fazer é:

  • Dentro do diretório do EJBCA tem o diretório conf, onde você deve copiar o ejbca.properties.sample para ejbca.properties e configurar. Algumas coisas são bem avançadas como por exemplo guardar as chaves e certificados em dispositivos de hardware, mas no meu caso a maioria dos padrões serviu bem.
  • Leia o arquivo database.properties.sample e o documento howto databases que tem dentro do /doc do EJBCA. Lá tem os comandos para se criar o banco postgres mas basicamente você cria um usuário ejbca com uma senha qualquer, e um banco com este usuário sendo o owner.

O resto do guia é bem mastigado. Lembre-se que o login na interface administrativa só é feito via Certificado, então depois de instalado não perca o arquivo superadmin.p12 queé gerado na instalação e deve ser importado no seu browser para que se possa acessar a interface.

Dentro do diretório do EJBCA existem também documentos descrevendo a utilização de vários servidores de aplicação diferentes assim como outros bancos de dados.

A outra parte foi mais complicada. Eu tinha de pegar os certificados e as chaves privadas das minhas CAs internas do Gnomint e colocá-las no EJBCA. Seria simples, se o Gnomint exportasse o PKCS#12 direito, mas aparentemente ele faz alguma besteira no formato e o EJBCA dá um erro. A solução foi a seguinte, e pode ser utilizada para migração de várias outras formas de PKI para o EJBCA:

  • No Gnomint, exportei separadamente o certificado da minha Root CA para um arquivo e a chave privada da mesma para outro.
  • Usando o openssl, criei um arquivo PKCS#12 usando estes dois arquivos, com o seguinte comando:

sudo openssl pkcs12 -export -out rootca.p12 -inkey rootca.key -in rootca.pem -name privateKey

  • Isso ai cria um arquivo que o EJBCA alegremente importou como a minha nova RootCA, via interface gráfica, sem estresse.
  • Caso você, como eu, tenha de importar CAs subordinadas (sempre uma boa idéia), você tem de repetir o procedimento acima para cada uma (exportar chave e certificado de cada uma), mas tem uma pegadinha: no caso de CAs subordinadas, você tem de incluir no comando openssl a opção -certfile rootca.pem. Porquê disso, você deve perguntar. Porquê sem isso, a cadeia (chain) de certificados fica incorreta no PKCS#12 e quando a Sub CA for importada ela vai aparecer como auto-assinada, e não assinada pela sua Root CA (ou seja, sua cadeia vai ficar quebrada).
  • Eu tive de importar também alguns certificados já emitidos para servidores aqui. Isso não é extremamente necessário, mas se não for feito você vai ficar sem uma forma de revogar estes certificados pelo EJBCA futuramente. Existe uma ferramenta chamada bin/ejbca.sh do EJBCA que faz essa importação sem trauma.

Depois disso, só alegria. O EJBCA tem uma interface pública que fica disponível na porta 8080, onde são publicados as CRL (Certificate Revocation Lists) e também onde usuários podem submeter CSRs (Certificate Signing Request) para geração de novos certificados. A interface administrativa roda na porta 8443 e só pode ser acessada por quem tem o certificado correto instalado no browser, e cuida do resto da PKI.

PKIs são dados sensíveis. Você deve ter backups seguros das configurações e principalmente das keychains das suas CAs. Se você perde uma chave ou um certificado Raiz, você perde toda a segurança que ele propõe, e vai ter de re-emitir TODOS os seus certificados. Lembre-se de limitar o acesso a interface administrativa e a própria máquina, várias camadas de firewall são aconselhadas.

A minha PKI roda numa máquina virtualizada, mas eu não aconselho isso para qualquer lugar onde os certificados serão utilizados em funões críticas. Uma máquina virtualizada é altamente mais sucetível a ataques e a roubo de dados (afinal de contas, se roubar a imagem, rouba-se tudo).

O próximo passo é dar uma conferida na integração do EJBCA com LDAP, para ver como fica uma PKI realmente grande e integrada com outros sistemas.

intel

6 Comments »