Recebi um bocado de feedback de outros sysadmins sobre o post anterior via twitter ou IM. Se quiserem postar aqui as respostas mais gente vai poder ver.

Minha experiência pessoal é como sysadmin de redes (na época basicamente com equipamentos Cisco) e com Linux/Unix. Mas certeza que a idéia geral serve pra quem pensa em seguir carreirar como Sysadmin Microsoft, Oracle ou qualquer outra variação.

Já pegando o gancho aqui vale a pena citar o seguinte: Quanto mais especializado você for melhor você vai ganhar e menor vai ser o mercado de trabalho.

Explicando: Não tem muitos sysadmins especializados em deployment de super-computadores híbridos para análise meteorológica. Esses caras ganham uma boa grana. Mas em compensação quantos super-computadores tem por ai? Você precisa se decidir o quão especialista quer ser e definir seu plano de carreira.

Independente de que tipo de sysadmin que deseja ser existem algumas coisas que, no meu ponto de vista, são extremamente básicas e já vi muito nego que dá carteirada com certificação passando de otário por não saber o básico.

Redes

IMHO a primeira coisa a se saber é redes. TCP/IP. Não perca tempo com outras tecnologias se não pretende ser sysadmin de rede. (Vale ressaltar aqui que eu estou em dívida comigo mesmo por ainda não ter estudado IPv6 à fundo).

A impressão que eu tenho é que um sysadmin que não sabe rede é como um médico que não sabe dividir o corpo humano em cabeça, tronco e membros. Mas acredite, isso acontece direto. Quando eu trabalhava com redes era ocorrência diária o time de Windows ou Unix mandar chamados de “problema de rede” dizendo que o serviço X ou Y não estava acessível, mas “o servidor está OK”.

Não precisava mais do que 5 minutos de troubleshooting pra descobrir que o serviço não estava rodando, que estava dando connection refused, o processo dava reset na conexão ou outra coisa qualquer, totalmente não-relacionada a rede. Faça um favor para você mesmo e evite pagar de otário aprendendo a utilizar ping, netstat, route.

E sysadmins Microsoft em geral parecem ter um especial dificuldade em entender o conceito de “default gateway”. Então se você for trabalhar com MS e souber isso, já largou na frente.

Troubleshooting

E falando em troubleshooting eu deveria ter começado é com isso. Capacidade de efetuar troubleshooting é simplesmente a mais importante qualidade na vida de um sysadmin.  E eu penso que “troubleshooting skills” nada mais é do que apenas um nome chique pra “bom-senso”, então todo mundo deveria ter, mas 30 segundos na Internet me mostram que isso não é bem verdade.

Apesar de ser uma coisa que eu considero como um talento nato o mesmo com certeza pode e deve ser melhorado. Ao invés de fugir de problemas encare-os de frente e tente resolver todo tipo de pepino que aparecer na sua frente. Faça uma Wiki pessoal utilizando algo como o Google Notebook ou TiddlyWiki e mantenha registro de como solucionou problemas. Estude estratégias de resolução de problemas, como a minha favorita Divide and Conquer, e lembre-se sempre que você não é tão especial quanto você acha. Grandes chances de alguém já ter tido o mesmo problema que você está tendo. E nesse caso o Google é seu amigo. Aliás, seguindo o link que o Andreyev postou aqui, aprenda a usar o Google direito!

As bases

Então considerando que você já está OK com os dois pontos anteriores, vamos falar da sua área de atuação. E aqui vou usar meu exemplo pessoal como sysadmin Linux.

Antes de sair por ai assinando seu email como sysadmin e tomar uma bofetada como essa, conheça muito bem as bases e raízes do sistema. Saiba a diferença entre sistemas derivados de System V e BSD, leia e aprenda a maior quantidade de comandos que conseguir.

Conheça a estrutura de diretórios Unix e o Filesystem Hierarchy Standard .

Deixe de ser fan-boy de distribuição, já que um bom sysadmin Linux deve ser capaz de sentar na frente de um console, determinar que distribuição está rodando e sair trabalhando. E sim, Ubuntu é lindo, fácil de instalar e cheio de aplicações (eu mesmo uso), mas o fato de você ter ele instalado em dual-boot no seu micro de casa a 6 meses não te qualifica como sysadmin.

Hoje em dia sou preguiçoso, mas no passado já fui mais ativo e perdi as contas de quais distribuições usei. Cheguei a ter uma máquina de teste onde toda semana eu instalava algo diferente, como TurboLinux e Progeny. Sempre um exercício interessante.

Considere usar algo um pouco mais baixo-nível por um tempo, como Slackware ou Gentoo, mas do ponto de vista comercial preocupe-se mesmo com RedHat, SuSE e Ubuntu. Aliás, minha experiência corporativa até o momento diz que a RedHat reina absoluta. Estudar essa distribuição em particular é interessante. Use o CentOS caso, como eu, não tenha US $800 sobrando pra comprar uma licença.

Aprenda a compilar um kernel, compilar pacotes, utilizar gerenciadores de pacotes, e instalar módulos do Perl ou Ruby via CPAN ou Gem.

Por favor, aprenda permissões e saiba parâmetros do chown e chmod. Utilizar o sudoers e saber da existência do /etc/securetty também não machuca ninguém. Não rele no /etc/passwd via editor de texto, mas se realmente não tiver outra opção utilize o vipw!

Scripting

Fato: Mais cedo ou mais tarde você vai precisar criar um script pra alguma coisa. Por isso aprenda shell script muito bem. Eu diria que é um diferencial excelente na hora de procurar emprego. Mas nada de aprender mais ou menos e sair cantando de galo por ai. Saber fazer um “pipe grépe” não é escrever shell script.

E uma coisa que acompanha shell script tão bem quanto café acompanha leite é expressão regular. Poucos sysadmins conhecem regex e a vida é MUITO, MUITO mais fácil com ela.

E se quiser ir um pouco mais fundo (dica: sempre queira), aprender um outra linguagem mais complexa é sempre interessante. Pessoalmente escolhi Python, mas conheço também um pouco de Perl e gostaria muito de ter tempo pra estudar Ruby. Essas linguagens mais complexas e cheias de recursos podem acabar facilitando sua vida reduzindo a quantidade de código que precisaria para fazer a mesma coisa em Bash, por exemplo.

E aqui vale enfatizar: Não invente moda. Nada de criar um script gigante e cheio de frescura se puder resolver o problema só um find -exec.

Seja preguiçoso

Isso mesmo. Pense sempre o seguinte: Como eu consigo executar essa tarefa com o menor esforço possível? Ou então: Como eu posso automatizar essa atividade pra não precisar fazer isso todo dia? E ainda: O que eu posso fazer pra parar de ter esse problema e nego me enchendo o saco todo fim do mês?

Lembre-se que o at, a crontab ou outros schedulers são seus amigos. Criar um daemonzinho utilizando um shell script também pode ser uma saída para algumas coisas.

E caso precise fazer algo que realmente não possa ser 100% automatizado faça uma excelente documentação do processo e deixe em algum lugar disponível para consulta não só sua como de qualquer outro colega. Assim a próxima vez o processo pode passar para mãos mais inexperientes ou simplesmente pra quem estiver disponível. Não precisa ser necessariamente você.

E por falar em preguiça, por hoje chega.

Não sei vocês, mas eu tenho a impressão que as coisas estão meio estacionadas faz um tempo. Eu mesmo estou usando na minha workstation do trabalho um Ubuntu 9.10 e não vejo o menor motivo pra upgrade. Parece que nos últimos anos nada digno de nota aconteceu. Ou talvez tenha, mas só não foi nada que me interessou.

Porém para um futuro próximo parece que vamos ter um aumento de performance sensacional, um filesystem de gente grande e uma camada gráfica decente . Isso tudo num espaço de talvez um ano?

Tô na pilha para colocar as mãos num Ubuntu 11.10 e descobrir que ele roda melhor, mais rápido, mais confiável e mais bonito na mesma máquina que estou usando hoje.

Uma feature que eu ainda não tinha usado é a API que eles disponibilizam para todos os clientes. Bem bacana e flexível.

Como em casa eu tenho IP dinâmico e vez por outra ele muda justamente quando preciso acessar de volta resolvi aproveitar e fiz um shell script quick’n dirty pra usar esse recurso bacana.

Sei que existem diversos serviços de DNS dinâmico por ai, mas preferi essa alternativa que pode ser útil pra mais alguém com uma necessidade parecida.

Tá aqui o script.

Se você já precisou acessar um servidor Linux atrás de um NAT sobre qual você não tem controle sabe como seria bom poder iniciar a conexão do lado do servidor conectando de volta em você.

Isso é possível com um túnel SSH reverso. A idéia é que o servidor que você deseja acessar inicia a conexão do lado dele, conecta-se na sua máquina e disponibiliza, via túnel SSH uma porta de volta pra ele.

Eu uso isso como um acesso rápido de casa para a empresa naqueles casos onde preciso só acessar rapidamente alguma coisa vinha linha de comando. Tenho acesso VPN se precisar de email, Terminal Services, etc. Seria possível fazer tudo via túnel, mas ai o desempenho não fica grandes coisas e nem é tão conveniente.

O comando (a ser executado do servidor atrás do NAT) é:

ssh -nNT -R 2222:localhost:22 username@suamaquina

Uma vez estabelecido o túnel você pode conectar de volta à partir da sua máquina utilizando:

ssh -p 2222 username@localhost

Como é possível que a conexão caia, o processo trave ou sei lá o que mais, recomendo os seguintes truques:

• Use chaves públicas para autenticação, assim não precisa de senha
• Rode a sessão inicial dentro do screen, isso evita perder o console
• Rode o túnel dentro de um loop while, pro processo poder ser restaurado caso morra
• Pra evitar alguém te sacanear crie um usuário dedicado pra essa conexão e aponte o shell dele para /bin/false

Mesmo com a a infra-estrutura toda virtualizada e clusterizada nos ESXi fazer um cluster de MySQL ainda é uma boa idéia.

Não só você pode colocar as duas máquinas em storages diferentes e eliminar mais um ponto de falha mas também você pode dedicar uma (ou mais) VM(s) para read-only.

Isso quer dizer que seus usuários rodando reports e chamando estatísticas/gráficos no meio do dia não vão afetar o desempenho de quem está entrando operações em produção.

Isso dito entra em cena o MySQL Multi Master Replication Manager (MMM): Um conjunto de scripts Perl que facilita a replicação e gerenciamento do seu cluster MySQL.

Abaixo os passos que utilizei para criar um cluster de 2 máquinas CentOS 5.5. Vou assumir que você já tem as máquinas em pé com MySQL devidamente instalado.

Além das máquinas rodando o MySQL você vai precisar de uma terceira, que é o monitor. É esse cara que vai manter os olhos no cluster, decidir quando uma máquina morreu e gerenciar os papéis de cada uma.

Nem idéia ainda dos requisitos mínimos desse servidor, visto que apenas fiz um teste pequeno aqui. Mas tá rodando sem reclamar em 1 processador e 512 de RAM.

Cenário:

IP Leitura/Gravação MySQL -> 10.0.0.1

IP Somente Leitura MySQL -> 10.0.0.100

IP Servidor MySQL 1 (hostname master) -> 10.0.0.2

IP Servidor MySQL 2 (hostname master2) -> 10.0.0.3

IP Monitor (hostname mon) -> 10.0.0.10

Editando a configuração do MySQL:

Em cada um dos servidores adicione as seguintes linhas embaixo da sessão [mysqld] do /etc/my.cnf:

#MMM
read-only
replicate-ignore-db = mysql
binlog-ignore-db = mysql
log-bin=master-binary
relay-log=master-relay
server-id=2

#MMM
read-only
replicate-ignore-db = mysql
binlog-ignore-db = mysql
log-bin=master2-binary
relay-log=master2-relay
server-id=2

Instalando o MMM:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum -y install perl-Algorithm-Diff perl-Class-Singleton perl-DBD-MySQL perl-Log-Log4perl perl-Log-Dispatch perl-Proc-Daemon perl-MailTools
yum install mysql-mmm.noarch mysql-mmm-agent.noarch mysql-mmm-tools.noarch

Configurando os Usuários:

Dentro de cada servidor precisamos criar 3 usuários: replication, agent e monitor. Abra seu console do MySQL e mande:

GRANT REPLICATION CLIENT                 ON *.* TO 'mmm_monitor'@'10.0.0.%' IDENTIFIED BY 'monitor_password';
GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO 'mmm_agent'@'10.0.0.%'   IDENTIFIED BY 'agent_password';
GRANT REPLICATION SLAVE                  ON *.* TO 'replication'@'10.0.0.%' IDENTIFIED BY 'replication_password';
FLUSH PRIVILEGES;
FLUSH TABLES WITH READ LOCK;

Abra duas sessões (uma em cada MySQL) e não as feche depois de rodar os comandos acima. Com eles executados faça a seguir:

SHOW MASTER STATUS;

E o resultado vai ser algo como:

mysql> SHOW MASTER STATUS;
+-----------------------+----------+--------------+------------------+
| File                  | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------------+----------+--------------+------------------+
| master2-binary.000003 |       98 |              | mysql            |
+-----------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

mysql>

Você vai usar essa informação nos comandos abaixo. Note que você deve utilizar o output da execução em uma máquina no input da outra, de forma que crie uma cross-reference entre elas:

change master to master_host = '10.0.0.3', master_user='replication', master_password='replication_password', master_log_file='master2-binary.000001', master_log_pos=98;

A seguir vamos editar o /etc/mysql-mmm/mmm_common.conf:

active_master_role      writer

<host default>
    cluster_interface       eth1
    pid_path                /var/run/mysql-mmm/mmm_agentd.pid
    bin_path                /usr/libexec/mysql-mmm/
    replication_user        replication
    replication_password    replication_password
    agent_user              mmm_agent
    agent_password          agent_password
</host>

<host master>
    ip      10.0.0.2
    mode    master
    peer    master2
</host>

<host master2>
    ip      10.0.0.3
    mode    master
    peer    master
</host>

<role writer>
    hosts   master,master2
    ips     10.0.0.1
    mode    exclusive
</role>

<role reader>
    hosts   master,master2
    ips     10.0.0.100
    mode    balanced
</role>

Este arquivo deve ser exatamente o mesmo nos dois lados do cluster!

E só fica faltando agora editar o /etc/mysql-mmm/mmm_agent.conf:

include mmm_common.conf
this master

Com tudo isso pronto vamos no servidor de monitoramento e fazemos:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum install mysql-mmm-monitor.noarch

Copiamos nele também o /etc/mysql-mmm/mmm_common.conf.

E depois editamos o /etc/mysql-mmm/mmm_mon.conf:

<monitor>
    ip                  127.0.0.1
    pid_path            /var/run/mysql-mmm/mmm_mond.pid
    bin_path            /usr/libexec/mysql-mmm
    status_path         /var/lib/mysql-mmm/mmm_mond.status
    ping_ips            10.0.0.1,10.0.0.2,10.0.0.3,10.0.0.100
    auto_set_online     60

    # The kill_host_bin does not exist by default, though the monitor will
    # throw a warning about it missing.  See the section 5.10 "Kill Host
    # Functionality" in the PDF documentation.
    #
    # kill_host_bin     /usr/libexec/mysql-mmm/monitor/kill_host
    #
</monitor>

<host default>
    monitor_user        mmm_monitor
    monitor_password    monitor_password
</host>

debug 0

Iniciando os serviços:

Nos servidores MySQL:

service mysql-mmm-agent start
chkconfig mysql-mmm-agent on

No servidor de monitoração:

service mysql-mmm-monitor start
chkconfig mysql-mmm-monitor on

Se tudo correu bem em alguns segundos você vai ter os serviços rodando e pode ver o status deles à partir do servidor de monitoração com o seguinte comando:

[root@mon ~]# mmm_control show
  master(10.0.0.2) master/ONLINE. Roles: writer(10.0.0.1)
  master2(10.0.0.3) master/ONLINE. Roles: reader(10.0.0.100)

Referências:

http://www.packtpub.com/article/install-manage-use-mmm-for-mysql-high-availability

http://www.packtpub.com/article/setting-up-mysql-replication-for-high-availability?utm_source=rk_mysql_cb_abr2_0510&utm_medium=content&utm_campaign=ramsai

http://fedoraproject.org/wiki/EPEL/FAQ#What_is_EPEL.3F

http://mysql-mmm.org/mmm2:guide

IMHO um bom home office precisa de Internet banda larga, uma rede local sua workstation de trabalho e um servidor de testes e um bom tanto de storage.

Pensando nisso hoje lembrei do meu primeiro home office, quando ainda morava em São Bernardo (circa 2004):

• Speed 256K
• Hub 10Mb/s
• Workstation Atlhon 900Mhz/512RAM/80GB (era também o firewall/router)
  • SuSE (??)
• Server test Atlhon 750Mhz/512 RAM/40GB
  • Debian
  • Kurumin

E a cara dele era assim:

Hoje, meu home office tem:

• Internet à cabo de 15Mb/s
• Firewall / Router / Wifi (ddwrt)
• Switch 100Mb/s
• Workstation AMD Athlon(tm) 64 X2 / 2GB RAM / 1.3TB
  • Ubuntu
• Múltiplos servidores de teste virtualizados (três hurras para virtualização)
  • Debian
  • CentOS
  • Fedora
  • ArchLinux
  • Ubuntu

Mas em compensação ele é assim:

Pois é… nem tudo na vida é upgrade.

Cenário: Um servidor que estava rodando e funcional há mais de um ano teve um reboot agendado  de madrugada. Depois do reboot recebo alertas que o tal não voltou automaticamente como esperado.

Servidor: Dell PE 2850 com 3 NICs: 2 Intel + 1 DLink rodando CentOS 5.2

Remotamente acessei o KVM e vi que o servidor estava OK, no tela de login. Nenhuma mensagem de erro e as interfaces em pé. Como já sou macaco velho na hora pensei que as interfaces de rede tinham mudado de lugar (já vi isso várias vezes), mas não tinha como testar pois elas estão em redes físicas separadas (não dava só pra reconfigurar uma vlan no switch), então tive que vir pra empresa mesmo.

Chegando aqui, dito e feito. As interfaces (eth0 e eth2) alternaram de posição. Eu já tinha visto isso acontecer antes, mas não sem um upgrade de kernel.

A questão é que o servidor estava up há mais de 1 ano, enquanto eu só tenho 8 meses de empresa. Isso significa que meus antecessores podem ter feito upgrade de kernel em um determinado momento, mas nunca deram boot na versão nova. Eu nunca vou saber.

Mas na verdade o problema poderia ter sido evitado facilmente se as interfaces tivessem sido configuradas adequadamente logo de cara.

No RHEL e no CentOS as interfaces são ativadas pelo /etc/sysconfig/network-scripts/ifcfg-ethX. Onde X é o número da interface. Um dos parâmetros que pode ser configurado é HWADDR, onde você amarra o endereço físico (MAC Address) à interface, de forma que na hora de subir a mesma o Linux saberá exatamente qual é qual.

Aqui tem mais detalhes desse arquivo de configuração, enquanto aqui tem uma excelente explicação de porquê as interfaces podem alternar de posição.

A maior universidade aqui da região, a Dalhousie, acabou de criar um mirror de software livre.

Como se não fosse bom o suficiente ter um mirror fisicamente tão próximo, diminuindo em muito a latência na rede, ainda por cima eles usam o mesmo provedor que eu e tem um PTT (Ponto de Troca de Tráfego) dentro do datacenter deles.

Olhem só o traceroute:

Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. DD-WRT.home.lan                  0.0%     3    0.5   0.6   0.5   0.7   0.1

 2. ???

 3. hlfx-asr1.eastlink.ca            0.0%     3    9.8   9.2   8.4   9.8   0.7

 4. hlfx-br1.eastlink.ca             0.0%     3    9.0  12.9   9.0  16.2   3.7

 5. hlfx-dr3.eastlink.ca             0.0%     2    7.0  21.1   7.0  35.2  19.9

 6. dal-gw.eastlink.ca               0.0%     2    7.8   9.8   7.8  11.8   2.9

 7. 198.166.1.37                     0.0%     2    8.5   8.1   7.8   8.5   0.5

 8. 192.75.96.254                    0.0%     2    9.1   9.3   9.1   9.4   0.3

Coloquei um download pra rolar, just for fun aqui. Não deu nem graça:

347,852,800 1.75M/s   in 3m 10s

Se eu ainda estivesse na universidade onde trabalhava o link entre elas é 1Gbp/s. O gargalo iria ser meu disco! Que coisa linda de imaginar.

Mas com isso eu já consigo viver feliz o suficiente, obrigado.

Uma forma simples de conseguir uma segurança bacana é utilizar o modo restrito do bash. Com isso habilitado o shell irá desabilitar as seguintes funções:

• Mudar o diretório (cd)
• Mudar o valor das variáveis SHELL, PATH, ENV, or BASH_ENV
• Comandos que incluem /
• Especificar um arquivo que contenha / como fonte para o comando “.”
• Usar redirecionamento de output (>, >>, |)
• etc (man bash para todas as features)

Colocando para rodar:

Crie um link do bash para o rbash e adicione o mesmo em /etc/shells:

ln -s /bin/bash /bin/rbash
echo /bin/rbash >> /etc/shells

Depois é só mudar o shell do usuário a ser restringido para usar o rbash:

usermod -s /bin/rbash username

Combinando isso com traps (do CTRL+C, por exemplo) você consegue criar um ambiente seguro o suficiente para fornecer serviços e acessos aos seus servidores e ainda assim dormir à noite.

Como diria o SuSE: Have a lot of fun!

Mergulhamos fundo em virtualização na empresa e eu ando varando as madrugadas migrando a infra-estrutura. Algumas coisas interessantes para dizer sobre isso…

A primeira observação é que a geração anterior de sysadmins a qual eu substituo até começou o processo – mas infelizmente por falta de fundos ou de apoio ou de conhecimento ou, mais provavelmente, de uma combinação dos três – fez uma melança horrível. E acertar esse meio-ambiente previamente virtualizado para o nosso novo vSphere tem sido mais complexo do que o previsto.

Com versões diferentes de vmware, número limitado de licenças de vCenter e vSphere (sim… no momento tenho os dois), uso de diferentes tecnologias e servidores como storage e péssimos posicionamentos dentro do rack migrar uma máquina virtual de um servidor ESX 3.5 para o vSphere pode ser uma tarefa bem ingrata. Principalmente quando você tem uma janela de manutenção limitada.

Imaginem a seguinte situação: Meu vCenter tinha 4 servidores ESX 3.5 sendo gerenciados. 2 numa subnet, 1 em outra subnet e outro numa terceira subnet. Não houve a preocupação de criar uma interface de gerenciamento na subnet de administração. Pior: subnets de níveis de segurança diferente. Então todo o tráfego do VMware passava pelo firewall.

Nem preciso dizer que vmotion não funcionava, né? Mas também não ia adiantar… No storage criaram um volume para cada ESX, de forma que um não via as VMs do outro. Então o vmotion tinha que ser full. Ah, sim… E cada ESX tinha apenas máquinas virtuais da subnet a qual a interface de administração pertencia. Trunk é para os fracos. Já falei que vmotion não funcionava?

Resumindo, eram apenas contâineres isolados com uma interface de administração centralizada. Horrível.

O que eu fiz agora, que compramos 4 Power Edges R710 top de linha e um storage EqualLogic foi sapecar placas de rede nos bichos. Cada servidor tem: 1 NIC pro iDrac, 1 NIC pra gerenciamento do vmware (incluindo vmotion), 1 NIC para cada subnet nas quais terei máquina virtual, 1 NIC para a rede de backup, 1 NIC para o storage e ainda 1 NIC disponível no momento (provavelmente utilizarei para fault-tolerance).

Para migrar as máquinas da antiga infra (!??) virtual para essa nova a forma mais fácil tem sido, acredite se quiser, usar o VMware Converter. Em alguns casos consegui fazer uma gambiarra e conectar com um ESXi novo num storage antigo e importar a VM para dentro do meu inventário e depois fazer um vmotion para o EqualLogic, mas foram poucos os casos que consegui.

E a cereja no bolo: No total já devo ter migrado – entre máquinas virtuais e P2V – uns 20 servidores. Desses todos, menos 2, eram Linux. Dos dois Windows que migrei um deles deu merda. Só 50% de aproveitamento. Como pode uma coisa dessa? Ainda bem que só servidor de uso interno é Windows, viu? Todos os servidores de serviços aos clientes são Linux. Senão a essa hora eu já tinha pedido para sair.

De qualquer forma tem sido uma tarefa longa e tediosa. Minhas madrugadas basicamente tem sido 2 horas de sono seguidas de 1 hora acordado em ciclos eternos até que acabe de migrar as máquinas do dia ou acabe a janela de manutenção e eu tenho simplesmente que destruir a VM nova e bootar a VM antiga.

Em compensação – exceto por ontem à noite – P2V tem sido uma baba. Conecto no servidor, desabilito todos os serviços e o crond, faço o P2V, dou shut na interface do switch onde a máquina físca está, subo a máquina virtual, instalo vmware-tools e corro pro abraço. No dia seguinte – quando chego no escritório – vou até o console do servidor e dou shutdown nele. Uns dois dias depois tiro a máquina do data-center e já era.

E aqui entre nós: Quando tenho a oportunidade de dormir eu até descanço mais tranquilo, pois alguns servidores muito críticos que fiz P2V estavam rodando em hardware com mais de três anos e o tempo médio para restaurar os backups é de 5 a 8 horas. Nem tava afins de enfrentar uma merda dessas.

Kudos para quem inventou o conceito de snapshot de file system direto no storage viu?