O que verificar num servidor novo antes de ele receber produção

Um dedicated server novo chega habitualmente com um sistema operativo, um login e uma suposição: que tudo o que pagou está presente, saudável e configurado para ser usado. Na maior parte das vezes isso é quase verdade. O intervalo entre quase e totalmente é de onde vêm as bases de dados lentas, os links de rede inativos e as interrupções surpresa. Aqui fica a verificação de aceitação que achamos que todos os servidores merecem antes de receberem produção, com os comandos para a executar por si.

Porque é que os testes de aceitação são saltados

Um servidor que arranca parece terminado. O sistema operativo não se queixa de um módulo de memória que não vê, de uma cache RAID a correr sem a sua bateria, ou de um bond que envia todos os pacotes por um único link. Cada um destes é invisível no uso normal e caro mais tarde, e cada um demora minutos a verificar no primeiro dia. Depois do go-live, as mesmas verificações precisam de uma janela de manutenção.

Memória: toda, equilibrada, sem erros

Confirme que o sistema vê todos os módulos que encomendou, e que estão numa disposição equilibrada pelos canais de memória de cada processador. Uma disposição desequilibrada corre, mas mais devagar do que devia.

dmidecode -t memory | grep -E 'Size|Locator' | grep -v 'No Module'
free -h
ras-mc-ctl --errors

Erros de memória corrigidos nos primeiros dias de vida de um servidor são razão para substituir um módulo agora, enquanto é fácil, não uma curiosidade para observar.

Discos e o controlador RAID

Leia a saúde de cada disco, incluindo os escondidos atrás de um controlador RAID por hardware, e o estado da write cache do controlador:

smartctl -a /dev/sda
smartctl -a -d megaraid,0 /dev/sda    # a drive behind a MegaRAID-family controller
storcli64 /c0 show all                # Dell PERC and LSI family
ssacli ctrl all show config detail    # HPE Smart Array

Procure contadores de reallocated, pending ou media errors diferentes de zero em qualquer disco. Um disco novo com um erro corrigido é um disco cuja própria correção de erros já está a trabalhar arduamente. No controlador, confirme que o disco lógico está no nível RAID que encomendou, que a cache está em modo write-back e que a bateria ou o módulo de cache com flash reporta saudável. Um controlador que caiu para write-through por causa da bateria pode fazer um array de SSD parecer disco rotativo.

Depois meça o throughput no volume vazio antes de ele conter dados, com uma ferramenta como o fio, para ter uma referência com que comparar mais tarde.

O flash está a ser tratado como flash?

Os controladores RAID por hardware muitas vezes não passam a flag de solid state ao kernel, pelo que um volume construído com SSD é reportado como disco rotativo e recebe definições afinadas para meios rotativos:

lsblk -d -o NAME,ROTA,SCHED,MODEL
cat /sys/block/sda/queue/read_ahead_kb

Se ROTA diz 1 num volume que sabe ser flash, confirme primeiro o tipo de meio a partir do controlador, e depois corrija-o com uma regra udev para que sobreviva a reboots:

# /etc/udev/rules.d/60-ssd-tunings.rules
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}="0"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/read_ahead_kb}="16"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/nr_requests}="1024"

udevadm control --reload && udevadm trigger --action=change /sys/block/sda

Não aplique isto a um volume sobre discos rígidos. Um read ahead curto convém ao flash e prejudica as leituras sequenciais de meios rotativos.

Rede: dois links, ambos a funcionar

Um servidor com duas portas em bond está muitas vezes a usar só uma. O transmit hash por omissão do bonding driver do Linux olha apenas para endereços MAC, e num datacenter, onde um host fala com um punhado de MAC de gateways e peers, isso pode colocar quase todos os fluxos no mesmo link.

cat /proc/net/bonding/bond0
ethtool -S <first port> | grep -E 'tx_packets|rx_packets'
ethtool -S <second port> | grep -E 'tx_packets|rx_packets'

Verifique que ambos os membros estão up, que o LACP se emparelhou com o switch e que a política de hash é a que pretendia. Sob carga, os contadores de ambos os membros devem crescer a ritmos semelhantes. Para a maioria dos servidores, fazer hash em endereços IP e portas distribui o tráfego muito melhor:

nmcli con mod bond0 bond.options "mode=802.3ad,miimon=100,lacp_rate=slow,xmit_hash_policy=layer3+4"

Acerte o lado do switch com isto, para que o tráfego seja distribuído da mesma forma nos dois sentidos. Depois puxe um cabo, confirme que o servidor continua acessível, volte a ligá-lo e repita com o outro.

Alimentação, hora e acesso remoto

ipmitool sdr type "Power Supply"
chronyc tracking
getenforce

Ambas as fontes de alimentação devem estar presentes e alimentadas, e devem ser alimentadas por linhas de energia diferentes. Um servidor com duas fontes ligadas à mesma linha tem um único ponto de falha com passos extra. Confirme que o controlador out of band (iLO, iDRAC ou IPMI) está acessível na sua rede de gestão e licenciado para a consola remota de que vai precisar. Se o SELinux faz parte do seu padrão, confirme que está enforcing antes de a primeira aplicação ser instalada, não depois.

Escreva-o

A última verificação é a documentação: número de série, posição no rack, cada porta com o seu endereço MAC e a que se liga, cada endereço IP, as duas linhas de energia e os IDs dos cabos.

Como o fazemos

Os nossos dedicated servers são plataformas HPE ProLiant e Dell PowerEdge, com gestão out of band numa rede isolada. Cada RAID build passa por uma verificação de saúde dos discos e um teste de throughput antes de ser entregue. O flash atrás de um controlador RAID recebe a afinação acima, com base no tipo de meio lido dos discos. Cada bond faz hash em endereços e portas, com o switch a condizer. Verificamos os contadores por porta para provar que ambos os links transportam tráfego.

Se tem um servidor já em produção que nunca passou por esta verificação, não é tarde demais, e teremos todo o gosto em percorrê-la consigo.

CTA

Fale com um engenheiro

Related

Relacionados: Bare metal servers em HPE e Dell · Engenharia de desempenho e capacidade · Storage SAN enterprise em HPE 3PAR, all-flash