Bruno Marcondes <brmarcondes@ig.com> || @bmarcondesEduardo 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 XMLRPCo 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 Fileo Packageo Serviceo User/Group

• Interdependência + Eventos (Triggers).o Subscribeo Notifyo 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 – iGclass 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õeso Pythono 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