Bruno Marcondes <brmarcondes@ig.com> || @bmarcondes
Eduardo S. Scarpellini <escarpellini@ig.com> || @escarpellini
Automação de Data Center
Agenda

Ambiente/Cenário Atual.

Premissas e princípios.

Deploy de servidores.

Gerenciamento de configuração.

Administração centralizada.

Monitoração.

Integração.
Cenário Atual
Cenário Atual

4 Sites

POA

SPO

BSB

RJ

Aproximadamente 1500 servidores.

Linux (CentOS / RedHat), Apache, PHP, Varnish,
Java, Python, MySQL.
Sem automação

Fluxos e processos custosos.

Processos manuais de configuração.

Contabilização e controle dos recursos alocados feitos de
forma manual.

Difícil manutenção dos agentes/configurações de
monitoração.
Infraestrutura como código
“Possibilita a reconstrução do negócio
a partir de um repositório de códigos-
fonte, backups da aplicação e
recursos físicos”
(Adam Jacobs - Opscode)
Premissas e Princípios
Premissas e Princípios

Segurança.

Convenção sobre configuração - padronização/simplicidade.

Agilidade.

Automatização.

Centralização de configurações, logs, eventos.

Auditoria (accounting, tracking).

[near-]Realtime data ("live" inventory information, gráficos,
alarmes).

Reaproveitamento de código/projetos (open-source).

Evitar o "not invented here syndrome".
Deploy de servidores
O início de um novo DataCenter
• Deploy da primeira máquina (servidor de instalação)
• Instalação manual do SO.
• Script em Python utilizando fabric para deploy do
puppet + manifests.
– Puppet é o responsável pelo seu auto-deploy
(puppetmasterd) + servidor BOOTP, TFTP, etc.
Inventário de hardware

Distribuição diskless (PXE+NFS).

CentOS 5.5

Coleta de informações via lshw.

POST de dados para fila (RabbitMQ).

Consumidor da fila para persistência em base central
(MySQL).

Checagem de integridade da informação, se esta já existir
previamente.

Hardware disponível para consulta ou instalação.

[re]boot do servidor via IPMI e instalação com sistema
operacional definitivo.
Fluxo de
Instalação de
hardware
Manual / Local
Remoto / Automatizado
Cobbler
• Permite a rápida configuração de um ambiente de instalação via rede
(provisionamento de servidores).
• Garante a harmonia de:
o DHCP/BOOTP (templates).
o TFTP + syslinux (templates).
o Kickstart (templates).
o Repositórios de pacotes.
• Suporte a:
o IPMI (power management: DRAC, iLO, etc).
o Triggers (integração com webservices)
o Diversas distribuições, versões e arquiteturas de GNU/Linux.
• Interfaces:
o CLI (command line)
o XMLRPC
o WEB (Cobbler Web)
Cobbler Web
Gerenciamento de Configuração
Puppet
• Ruby.
• Modular.
• XMLRPC/REST (+SSL).
• Meta-linguagem para definição de manifests/classes.
o Acesso a funcões/código externos (ruby).
o Herança / especialização de classes.
• Classes compostas por recursos abstratos (domínio do cliente).
o File
o Package
o Service
o User/Group
• Interdependência + Eventos (Triggers).
o Subscribe
o Notify
o OnlyIf/Unless
Puppet - iG
• Classificação de nós externa.
o Baseada em ambiente+pool+hostname.
o Integrado ao DNS (CNAME's).
•Funções que facilitam a criação de novos manifests/classes
(padrão).
• Configurações centralizadas e versionadas (Mercurial).
– Aplicaveis a hosts, pools/farms ou ambientes
inteiros.

Templates para configurações que demandam váriaveis.

Toda classe é acompanhada de um recorte de regras
específicas de firewall.
Puppet - iG
• DNS (convenção):
• A: <asset-id>.tld
– hardware4494.tld
• CNAME: <pool>-<id>.[env].tld
– blig-ws-1.prod.tld (prod).
– home-cache-2.adm.qa.tld (QA).
• Puppet (classes + arquivos):
• /env/pool/hostname/fs-tree
– /all/etc/hosts
– /prod/blig-ws/etc/hosts
– /prod/blig-ws/blig-ws-8/etc/hosts
Puppet – iG
class proxy_server_squid {
package {
"squid":
ensure => installed;
}
file {
"/etc/squid/squid.conf":
source => reposrc(“/etc/squid/squid.conf", $fqdn)
notify => Service["squid"],
}
exec {
"/usr/sbin/squid -z":
unless => "/usr/sbin/squid check"
}
service {
"squid":
ensure => running,
enable => true,
}
}
Alternativas
CFEngine
Chef
Administração Centralizada
Func
• Execução de módulos/funções de maneira massiva (ad hoc).
o overlord => minions.
• XMLRPC (+SSL)
• Arquitetura modular (fácil desenvolvimento).
o Ex.: command, jboss, rpm, iptables, process, ping, etc.
• Interfaces
o Python API
 import func.overloard.client
o CLI
 func 'home-ws-*.tld' call command run 'httpd -V'
 func 'blig-ws-[123].tld' call hardware info
We are buddies!!!
Alternativas
Capistrano
Fabric
MCollective
Monitoração
Collectd
• Performático e leve.
o C.
o Alta resolução/granularidade (segundos).
• Plugins.
o Apache, Nginx, Mysql, Bind, Varnish, RRD, Nagios, etc.
• Extensões
o Python
o Java.
o Perl.
o Bash (exec).
• Network
o Push de dados para o servidor (passivo).
o Multicast (auto-discovery).
o Visualização.
– RRD plugin + collectd-web.
Agregação e visualização de dados
Collectd-web
Alternativas (coleta e visualização)
• Mon
• Munin
• Cacti
• Graphite
• Ganglia
• Visage
Alarmes e eventos
• Nagios
– "The Industry OpenSource Standard"
– Conhecido por todos adminstradores.
• Interface amigável para administração.
– NagiosQL
• Alternativas
– Reconnoiter
– Zabbix
– Zenoss
– OpenNMS
Integração
Control Station

Dashboard unificado para as ferramentas citadas.
– Python/Django + MySQL + RabbitMQ.
• Facilidade/Plugins/Reaproveitamento/Performance.

Ponto único para as informações relevantes.
– Dados de inventário.
– WorkFlows / Requisições.
– CRUDs.
– Mashup (gráficos).
– Visões consolidadas/alto-nível para sites, serviços e pools.

Webservices (REST) para integração entre serviços de backend.
Control Station
Control Station
Control Station
Referências

http://fedorahosted.org/cobbler/

http://www.puppetlabs.com/

http://www.cfengine.org/

http://www.opscode.com/

http://fedorahosted.org/func/

http://www.rabbitmq.com/

http://www.djangoproject.com/

http://docs.fabfile.org/

http://www.capify.org/

http://code.google.com/p/mcollective/

http://en.oreilly.com/velocity
Automação de Data Center
Automação de Data Center

Automação de Data Center