automação de data center
TRANSCRIPT
Bruno Marcondes <[email protected]> || @bmarcondesEduardo S. Scarpellini <[email protected]> || @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