Nerd Evolution….

A imagem não precisa de descrição….

Algumas dicas: padronização, documentação….

Para administrar de forma eficaz diversos servidores é indispensável a criação de padronizações que sejam divulgadas, utilizadas e bem difundidas e debatidas entre as pessoas que compõem a equipe de administradores. A experiência que adquiri durante os anos que trabalho com Linux/Unix me força a dizer que uma das  piores (senão  a pior), coisa que existe no “mundo Linux”  é que poucas pessoas seguem uma padronização e um agravante desta situação ainda existe, que é: a padronização totalmente incoerente ou quando a padronização existe apenas na cabeça de quem administrou. O intuito deste post é expor algumas padronizações que utilizo e que adotei durante este tempo que trabalho com tecnologias livre.

– Comentários nos confs

Eu particularmente mantenho os comentários padrões dos arquivos de configuração, porém existem aqueles que não gostam de nenhum comentário nos confs. Vou citar aqui um exemplo, vamos dar uma olhada num trecho do arquivo de configuração do Apache que acompanha o pacote “apache2” na distribuição OpenSuSE :

##

## Server-Pool Size Regulation (MPM specific)

##

# the MPM (multiprocessing module) is not a dynamically loadable module in the

# sense of other modules. It is a compile time decision which one is used. We

# provide different apache2 MPM packages, containing different httpd2 binaries

# compiled with the available MPMs. See APACHE_MPM in /etc/sysconfig/apache2.

# prefork MPM

<IfModule prefork.c>

# number of server processes to start

# http://httpd.apache.org/docs/2.2/mod/mpm_common.html#startservers

StartServers 5

# minimum number of server processes which are kept spare

# http://httpd.apache.org/docs/2.2/mod/prefork.html#minspareservers

MinSpareServers 5

# maximum number of server processes which are kept spare

# http://httpd.apache.org/docs/2.2/mod/prefork.html#maxspareservers

MaxSpareServers 10

# highest possible MaxClients setting for the lifetime of the Apache process.

# http://httpd.apache.org/docs/2.2/mod/mpm_common.html#serverlimit

ServerLimit 150

# maximum number of server processes allowed to start

# http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients

MaxClients 150

# maximum number of requests a server process serves

# http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequestsperchild

MaxRequestsPerChild 10000

</IfModule>

O exemplo acima ilustra o que é um arquivo de configuração bem estruturado e documentado, como podemos perceber ele explica resumidamente a funcionalidade das diretivas e para tornar a configuração mais completa, ainda indica um link para a documentação oficial do projeto. Se todos os administradores tivessem esse cuidado com certeza muito trabalho seria poupado.

Seguindo o exemplo citado acima, meu arquivo de configuração do postfix “/etc/postfix/main.cf”, tem uma estrutura semelhante com o trecho abaixo:

# http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions

# Verificacoes feitas apos o cliente enviar o enderece do destinatatio

# RCPT TO

smtpd_recipient_restrictions =

permit_mynetworks,

permit_sasl_authenticated,

permit_mynetworks,

reject_non_fqdn_hostname,

reject_non_fqdn_recipient,

reject_non_fqdn_sender,

reject_unknown_sender_domain,

reject_unknown_recipient_domain,

# http://www.postfix.org/postconf.5.html#reject_unauth_destination

reject_unauth_destination,

# http://www.postfix.org/postconf.5.html#reject_unauth_pipelining

reject_unauth_pipelining,

##check_policy_service inet:127.0.0.1:10001 # http://www.postfix.org/SMTPD_POLICY_README.html

– Particionamento

Configurar um servidor hoje em dia é uma tarefa trivial para alguns administradores de sistema e muitas ferramentas podem ser utilizadas para facilitar esta tarefa. Mas algo que é muito importante e não deve ser esquecido é a padronização dos servidores e na minha opinião a primeira padronização que devemos criar é para o particionamento. Confesso que já ouvi relatos impressionantes de alguns colegas que se depararam com esquemas no mínimo bizarros, alguns exemplos:

1. /tmp com 50 mb
2. /var/spool/mail com 10 GB
3. /boot com reiserfs

Agora eu pergunto:

– Porque o “/tmp” com apenas 50 MB? Está faltando espaço em disco e você economizou com o /tmp, afinal, são apenas arquivos temporários;

– Porque “/var/spool/mail” com 10 GB, pense comigo, se um dia teu server estiver com 5 GB de emails na fila, com certeza existe um problema muito maior no servidor que esta partição sozinha não vai resolver.

– /boot formatado com reiserfs, lógico, pois o sistema deve manter journaling para uma partição que é utilizada apenas no boot do sistema 🙂

Seria hilário se não fosse trágico….

Uma coisa é certa não existe uma padronização universal para todas as modalidades de serviços existentes hoje, mas alguns padrões são inevitáveis:

/usr -> Esta partição não precisa ser enorme, pois é aqui que a maioria dos programas instalados no teu servidor ficarão, sendo assim, pense bem , tu não vai precisar de 20GB nesta partição. Eu em todos os servidores que administro defino apenas 4GB para essa partição, e acho que não deve passar muito disso. Até 8 GB é aceitável…

/var -> Dependendo do tipo de servidor é importante termos um certo histórico de logs , mas cuidado… se esse histórico de logs for tão importante assim, utilize um servidor de logs, é mais inteligente, sendo assim, o máximo aconselhável para esta partição , na minha opinião, é 30GB ;

/tmp -> não precisa alocar 30 GB para esta partição, mas também não deixe apenas 100MB. 1GB tá bom!!

/var/lib/mysql -> acho importante ter uma partição separada para os dados do Mysql ;

/var/cache/squid -> para alguns servidores com Squid é interessante utilizarmos uma partição separada do sistema, e quem sabe até usando Reiserfs, o espaço pode variar.

swap -> cuidado com esse carinha aqui, se teu sistema utilizar muita swap teu server estará em apuros;

Não se esqueça das flags; nosuid, noexec e noatime …nem vou explicar aqui o que são essas flags, acho que isso vai ajudar : http://tinyurl.com/23ck22p

– Documentação

Sempre que faço algum tipo de configuração adicional ou encontro uma flag/falha em algum conf sigo os passos:

– Procuro na documentação oficial do software para ter certeza do que estou fazendo;

– Aplico a flag em alguma máquina virtual para testar o efeito da alteração ;

– Caso a etapa acima não tenha causado nenhum dano ou a morte de alguém aplico a regra no ambiente em produção e deixo em homologação por 24 horas;

– Caso nenhum servidor tenha rebootado inesperadamente depois de alterar a flag eu documento os passos para aplicá-la, e faço isso de 2 formas: a primeira via email para meu superior e a segunda em nosso sistema de documentação

Uma coisa é certa, documentar nunca é demais e esta etapa é uma das mais importantes para fazer um serviço bacana, pois afinal, você pode até morrer, mas a empresa onde você está trabalhando precisa continuar funcionando…certo,estou sendo trágico demais, mas voltando para a realidade, Documentar é preciso, viver não é preciso ….

– Se vai mexer faça backup …

Existem momentos em que vamos apenas adicionar uma flag no “/etc/fstab”, por exemplo, em um servidor que acabou ficando fora do padrão, este tipo de intervenção é tão básica , tão simples, tão idiota que as vezes, simplesmente editamos o arquivo e fod**-se , pois é, é ai que mora o perigo, vou citar um exemplo.

Imagine que vocẽ usa como editor padrão o “vim”, e que sempre que instala um novo servidor tu copia o arquivo “vimrc_example.vim” do “/usr/share/bla/bla/bla”, para tua pasta pessoal , este arquivo é uma mão na roda, deixa o vim todo colorido, gera backup dos arquivos editados e uma porrada de coisas mais. Com isso, imagine você deletando os arquivos de backup que o vim cria , algo como:

cd /etc/

rm -rf *~

Este comando pode até parecer brincadeira, mas a imagem abaixo mostra o que acontece quando não fazemos backup das coisas quando fazemos alguma intervenção no servidor :

É , é isso mesmo, com certeza uma hora ou outra vai dar merda !!!

Bom, vou ficando por aqui. Teremos mais posts sobre o assunto…

Mysql Master & Mysql Slave + Heartbeat

– Introdução

A configuração do processo de replicação do Mysql é algo trivial e não demanda de grande quantidade de trabalho , nem de neurônios,

porém o processo torna-se mais difícil caso exista a necessidade de ativar o Mysql Slave se o Mysql Master ficar indisponível, e neste caso transformar o Mysql Slave em Mysql Master.

Este processo irá envolver a configuração do software Heartbeat que irá controlar os recursos que são compartilhados entre os servidores.

Para termos essa configuração funcionando precisaremos de 3 endereços IPs válidos:

1 IP para o Mysql Master

1 IP para o Mysql Slave

1 IP para o Heartbeat**

*** O IP do Heartbeat não será fixo em nenhum dos servidores, este IP será configurado no servidor Mysql Master enquanto

ele estiver ativo, sendo assim, caso alguma falha ocorra e o Mysql Master fique inacessível o Heartbeat irá configurar

uma interface de rede virtual com este IP, sendo assim, todas as conexões direcionadas à este IP serão manipuladas pelo

outro servidor.

– Configurando o Mysql Master :

Adicionar as seguintes configurações ao arquivo “/etc/my.cnf”:

server-id = 1

log-bin = mysql-bin

log_slow_queries = /var/log/mysql-slow.log

report-host = mysql_master

relay-log = /var/lib/mysql/relay.log

relay-log-info-file = /var/lib/mysql/relay-log.info

relay-log-index = /var/lib/mysql/relay-log.index

Onde:

server-id -> Indica uma identificação única para o servidor Mysql;

log-bin -> define um prefixo para a criação dos arquivos de log binário que serão criados para replicação de dados;

report-host -> Define um nome para este servidor Mysql

relay-log -> são arquivos usados pela replicação slave para armazenar eventos recebidos pelo servidor master antes de sua execução no servidor slave.

– Configurando o Mysql Slave :

Adicionar as seguintes configurações ao arquivo “/etc/my.cnf”:

server-id = 2

log-bin = mysql-bin

master-host = 192.168.1.251

master-user = slave

master-password = slave

binlog-ignore-db = mysql

report-host = mysql-slave_01

relay-log = /var/lib/mysql/relay.log

relay-log-info-file = /var/lib/mysql/relay-log.info

relay-log-index = /var/lib/mysql/relay-log.index

Onde:

master-host -> Especifica o IP do servidor Mysql Master;

master-user -> Especifica o usuário Mysql que cuidará do processo de replicação dos dados;

master-password -> Especifica a senha do usuário Mysql que cuidará da replicação dos dados;

binlog-ignore-db -> Especifica qual banco de dados não deverá ser replicado do Mysql Master para o Mysql Slave

Como podemos perceber ambas as configurações do Mysql contém a opção “log-bin” isso se faz necessário pois quando o Mysql Slave assumir o papel de Mysql Master ele precisará criar os logs binários para replicá-los para o antigo Mysq Master.

– Instalando o Heartbeat

Basta executar:

yum install heartbeat

Após instalar o programa ative-o na inicialização do sistema:

chkconfig --level 3 heartbeat on

O diretório de configuração deste programa é “/etc/ha.d”.

O Heartbeat contém, basicamente , 3 arquivos de configuração:

– ha.cf -> Arquivo de configurações globais do Heartbeat

– authkeys -> Arquivo que contém a(s) chave(s) de autenticação

– haresources -> Arquivo onde são configurados os recursos que farão parte do cluster que configuraremos

– O arquivo ha.cf

Abaixo o conteúdo básico deste arquivo:

debugfile /var/log/ha-debug

logfile /var/log/ha-log

logfacility local0

keepalive 1

deadtime 15

warntime 5

initdead 120

udpport 694

bcast eth0

auto_failback off

node <node master>

node <node slave>

ping 192.168.1.132

respawn hacluster /usr/lib/heartbeat/ipfail

debug 1

use_logd yes

Onde:

debugfile -> indica qual arquivo deve armazenar as informações de debug do heartbeat

logfile -> indca o arquivo de log para mensagens de Aviso ou Alerta

keepalive -> determina quanto tempo entre os “heartbeats”

deadtime -> define quanto tempo é necessário para assumir o host como “morto”

warntime -> ???

initdead -> quanto tempo aguardar para que a interface no servidor fique ativa?

udpport -> porta para onde serão enviados os dados do heartbeat

bcast -> especifica a placa de rede que enviará testes para o segundo nó

auto_failback -> Especifica se quando o servidor preferencial (neste caso o Mysql Master), ficar on-line novamente ele deve responder oficialmente as requisições

node -> é o nome do host preferencial e secundário. Para obter este nome execute: uname -n

– O arquivo authkeys:

Abaixo o conteúdo do arquivo:

auth 2

2 crc

– O arquivo haresources :

Abaixo o conteúdo do arquivo:

<node master> IPaddr::192.168.1.248/24 mysql

Onde:

<node master> -> Especifica o nome do servidor preferencial do serviço monitorado pelo Heartbeat (em nosso caso o nome do Mysql Master)

IPaddr::192.168.1.248/24 -> Especifica o script (/etc/ha.d/resource.d/IPaddr),e o IP que deverão ser assinados para o servidor preferencial

mysql -> Nome do script que será executado quando o heartbeat for iniciado (/etc/ha.d/resource.d/mysql)

. Para o slave tornar-se master é necessário ativar a opção “log-bin” no my.cnf para

que o servidor slave possa gerar os logs binários para futuramente tornar-se master,

já a opção “–log-slave-updates” não deve ser utilizada pois causará a replicação

em duplicidade dos dados para o(s) servidor mysql slave.

. Para termos a replicação funcionando será necessário adicionar o usuário para

replicação em ambos os servidores Master e Slave e adicionar a permissão de replicação

em ambos os servidores, sem isso a replicação não funcionará.

. É indicado o usuário da opção “binlog-ignore-db” para configurar quais bancos não

serão replicados neste esquema .

. É indicada a utilização da opção “report-host” que habilita a execução do comando SQL

“SHOW SLAVE HOSTS” , que irá exibir uma lista de servidores Mysql Slaves conectados ao

Mysql Master.

Slave to Master executar:

STOP SLAVE -> Desliga a thread do Mysql Slave

CHANGE MASTER TO MASTER_HOST='';

RESET MASTER -> Limpará todos os logs binários e os criará do zero

Msater to Slave executar:

STOP SLAVE

CHANGE MASTER TO

MASTER_HOST='<IP do Novo Servidor Master',

MASTER_USER='<usuário slave>',

MASTER_PASSWORD='<senha do usuário slave>';

START SLAVE

Espero que essa documentação auxilie alguém !!

Até o próximo post….

How to become a Master of “Puppet”?

Bom este post não é sobre o Metallica. Este é o primeiro de alguns sobre o Puppet (http://www.reductivelabs.com/puppet/introduction/) .

Vamos por partes para aos poucos desmistificar esta ferramenta que vem sendo utilizada em diversos ambientes e por diversas empresas, sendo que a empresa onde trabalho atualmente é uma delas.

Introdução

– O que é o puppet?

Resumidamente….

O Puppet é um framework para automatizar/centralizar configurações. A melhor parte do Puppet pode ser definida com 2 palavras: automatização e centralização . Você pode se perguntar, porque essas duas palavras são tão importantes? A resposta é extensa mas é simples de ser entendida, e pode ser respondida até com outra pergunta, então vamos começar.

– Vamos para uma situação real

É possível, dependendo de onde você leitor trabalhe, que um novo servidor seja adicionado semanalmente à sua estrutura, sendo assim a tarefa de instalar o sistema, instalar os pacotes necessários, realizar a configuração dos serviços, ativar/desativar daemons do sistema, configurar regras de firewall, atualizar a documentação do processo de instalação e dezenas de outras coisas que podem existir na tua padronização. Sendo assim, essa tarefa é fácil e em alguns momentos até agradável, agora vamos imaginar outra situação: Imagine que a empresa onde você trabalha fecha AQUELE contrato bacana e a estrutura para suportar a demanda deste novo cliente precisa crescer algo em torno de 30 ou 40% e para que isso ocorra o departamente de infra-estrutura deverá provisionar “N” novos servidores. Agora imagine a bagunça que isso irá tornar-se, agora imagine-se passando dias e noites inteiras executando “apt-gets” ou “yum install” pra lá e pra cá, realmente não seria fácil.

– Como o Puppet pode me ajudar?

Na situação descrita acima a utilização do Puppet e outras soluções semelhantes, seria a mais indicada e o porque disso vou listar abaixo:

– As configurações dos servidores ficam centralizadas em um ponto , no PuppetMaster !

– O Puppet conta com uma linguagem própria e muito bem definida para manutenção de sistemas ;

– É possível propagar a alteração de um arquivo de configuração alterado para todos os servidores com o mínimo de esforço;

– A padronização da instalação dos servidores que compoem a infra-estrutura da sua empresa torna-se uma tarefa mais simples

– Minha vivência com Puppet

Eu ainda não sou um Master of Puppet , porém as minhas experiências com ele estão sendo muito boas, e para ser direto , um processo de instalação de servidor que antes , sem o Puppet, demorava 2 ou 3 horas hoje me toma apenas 10 minutos, tudo que eu preciso fazer é documentar os passos executados nestes 10 minutos. Logicamente algumas tarefas precisam ser realizadas manualmente como: requisição de reversos, configuração de IPs adicionais (que são obtidos após a liberação do servidor), mas muito tempo é economizado, isso é indiscutível. Este post introdutório termina aqui, aguarde que vem mais por ai !!!!

O que teremos pela frente nos próximos posts?

– Instalação e configuração do Puppet

– Criando alguns manifestos para o Puppet

– Centralizando os arquivos de configuração do Puppet

Até o próximo post…..

Memcached: Instalando/Configurando & Monitorando

Instalando o Memcached

Para instalar o memcached em sistemas RedHat ou baseados em RedHat execute:

yum install memcached

Após executar com sucesso a instalação é necessário ativar o memcached na inicialização do sistema:

chkconfig --level 3 memcached on

Inicie o processo do memcached:

service memcached start

Para verificar se o memcache está sendo executado corretamente execute:

lsof -i tcp:11211

Deverá ser exibida uma mensagem como:

memcached 19090 memcached 3u IPv4 31684538 TCP *:11211 (LISTEN)

Instalando a biblioteca PHP de acesso ao memcached

Existem 2 formas (basicamente),de realizar esta instalação. Uma instalação baseia-se em instalações onde o PHP foi compilado (geralmente a versão 4 do PHP), e outra instalação quando o PHP foi instalado a partir do RPM (geralmente a versão 5 do PHP).

Abaixo os passos para instalar a biblioteca para ambas as instalações:

PHP Compilado:

/usr/local/bin/pecl install memcache

PHP instalado via RPM:

yum install php-pecl-memcache

Configurando o PHP para salvar as sessões do PHP no memcached

Antes de configurar o PHP para salvar as sessões no memcached é necessário descobrir qual arquivo de configuração “php.ini” está sendo utilizado.

Para descobrir execute:

php -i | grep -i "Configuration File"

Este comando terá uma saída parecida com :

Configuration File (php.ini) Path => /usr/local/lib/php.ini

para instalações compiladas do PHP4, e :

Configuration File (php.ini) Path => /etc/php.ini

para instalações do PHP5.

Para ambas as situações os parâmetros de configuração serão os mesmos, para configurar as diretivas localize as linhas que iniciam com:

session.save_handler = files

session.save_path = /tmp

e substitua por :

session.save_handler = memcache

session.save_path = "tcp://'''IP DO SERVIDOR''':11211?persistent=1&weight=1&timeout=1&retry_interval=15"

Para efetivar estar configurações será necessário reiniciar o Apache :

service httpd restart

Monitoramento Munin

Para gerar gráficos de performance e para avaliar o uso do memcached aconselho o uso do Munin. Para que o munin seja capaz de gerar os gráficos é necessário instalar algumas bibliotecas de acesso ao memcached, sendo assim, execute:

perl -MCPAN -e shell

install Cache::Memcache

Existe um plugin de monitoramento do memcached disponível em: http://exchange.munin-monitoring.org/ ,basta procurá-lo ai 🙂 . Após obter obtê-lo dê permissão de execução para o script e coloque-o na pasta padrão dos plugins do munin ‘”/usr/share/munin/plugins”.Acesse a pasta “/etc/munin/plugins” e crie o link simbólico do script de monitoramento do memcached nesta pasta. Para testar o script execute:

munin-run <nome_do_script>

Caso o retorno seja o esperado, reinicie o munin:

service munin-node restart

Exemplo do gráfico gerado pelo munin….

Alvo dos próximos estudos

Abaixo listo o alvos meus próximos estudos:

– Scribe

http://github.com/facebook/scribe

O Scribe é um projeto desenvolvido pelo Facebook, distribuído sob licença livre. É um software que agrega dados de logs dos servidores.

– Varnish

http://varnish-cache.org/

É um acelerador HTTP, em breve mais detalhes.
Alguns detalhes adicionais no link abaixo:
http://queue.acm.org/detail.cfm?id=1814327

– Redis

http://code.google.com/p/redis/

– MapReduce Framework

MapReduce.simplified.data.Processing.on.Large.clusters

Vamos que vamos, vou manter o blog atualizado com as minhas impressões sobre esses estudos.

Profiling de consultas SQL

De Public

Algumas vezes nos deparamos com a necessidade de saber quanto tempo uma consulta SQL demora para ser executada. Em minhas pesquisas encontrei uma forma de fazer com que esse valor seja obtido, e algo muito simples de ser feito. Let’s go:

Acesse o Mysql e execute:


mysql> SET PROFILING=1;
mysql> EXPLAIN SELECT ...
mysql> SELECT ...
mysql> ALTER ...
mysql> SHOW PROFILES;

+----------+------------+-------------------------
| Query_ID | Duration | Query
+----------+------------+-------------------------
| 1 | 0.00036500 | EXPLAIN SELECT sbvi.id a
| 2 | 0.00432700 | SELECT sbvi.id as sbvi_i
| 3 | 2.83206100 | alter table sbvi drop in
| 4 | 0.00047500 | explain SELECT sbvi.id a
| 5 | 0.00367100 | SELECT sbvi.id as sbvi_i
+----------+------------+-------------------------

Uma coisa interessante é que dependendo da forma como o sistema funciona é possível utilizar essa opção como uma flag que pode ser ligada/desligada e fazer com que a saída do “SHOW PROFILES” seja armazenada em um arquivo de log.

Fica ai a dica.

Fonte: Planet Mysql

Edu Ardanuy

Lembrando os velhos tempos em que ouvia Black Metal

Aumentando a performance de escrita no Mysql

Estou avaliando todo o conteúdo do slide abaixo, mas mesmo assim vou colocá-lo à disposição !

Boa leitura p/ todos.