Virtualização — abordagem profunda

• Hipervisor Type-1 (bare-metal): roda direto no hardware (menor overhead e mais recursos de cluster/HA).
• Hipervisor Type-2 (hosted): roda sobre um SO (ótimo para desktop/lab, menos indicado para produção pesada).
• Virtualização assistida por hardware: Intel VT-x / AMD-V, EPT/NPT, IOMMU (essenciais em produção).
• Full virtualization: o guest não precisa “saber” que é VM.
• Paravirtualização: drivers otimizados (virtio, vmxnet3, pvscsi) para reduzir overhead.

Modelo mental (camadas)

[VM / Guest OS / Apps]
        |
 [Virtual HW: vCPU, vNIC, vDisk]
        |
    [Hypervisor]
        |
 [CPU/RAM/NIC/HBA físicos]
        |
      [Storage / Rede]

• vCPU ≠ core físico: vCPU é tempo de CPU agendado pelo hipervisor.
• Overcommit de CPU: você pode alocar mais vCPUs do que cores físicos, mas precisa monitorar latência (tempo de espera).
• CPU ready / steal time: indica que a VM quer CPU, mas o host está ocupado (sintoma clássico de overcommit).
• NUMA: em servidores multi-socket, memória “local” é mais rápida do que memória “remota”. VMs grandes precisam respeitar NUMA.
• Pinning/affinity: “prender” vCPUs em cores específicos pode ajudar workloads previsíveis, mas reduz flexibilidade do scheduler.

• Overcommit de RAM: possível em alguns hipervisores via técnicas de compartilhamento/ballooning, mas é arriscado para produção sem controle.
• Ballooning: driver no guest “devolve” RAM para o host sob pressão.
• Swap do host: é sinal vermelho; swap em host virtualizado geralmente derruba desempenho do cluster.
• Hugepages: páginas grandes reduzem overhead de TLB e podem melhorar performance (especialmente em workloads de memória intensiva).
• Reserva de memória: para VMs críticas, garanta RAM para evitar competição.

Modelo mental de pressão de memória
1) Cache/buffers reduzem
2) Ballooning (se habilitado)
3) Swap guest
4) Swap host  (pior cenário)

• Storage é o coração: a maioria dos gargalos em virtualização é IO (latência) e não CPU.
• Métricas-chave: latência (ms), IOPS, throughput (MB/s) e fila (queue depth).
• Protocolos: NFS (arquivo), iSCSI (bloco), FC (bloco), storage distribuído (Ceph, etc.).
• Cache: write-back/write-through, cache em SSD/NVMe para aceleração (com cuidado em consistência).
• RAID: RAID10 costuma ser “safe default” para IO aleatório; RAID5/6 economiza disco, mas penaliza escrita.

• vSwitch: switch virtual conectando vNICs das VMs a uplinks físicos.
• VLAN: segmentação L2 para separar redes (mgmt, storage, vMotion/live migration, produção, DMZ).
• Overlay (VXLAN/Geneve): segmentação virtual em larga escala (mais comum em SDN).
• Bonding/LACP: redundância e agregação (depende do design e do switch físico).
• SR-IOV: acesso quase direto à NIC (alta performance), mas reduz flexibilidade (migração/inspeção).

Segmentação recomendada (exemplo)
- VLAN 10: Management (hosts)
- VLAN 20: Storage (iSCSI/NFS/Ceph)
- VLAN 30: Live Migration / vMotion
- VLAN 40: Produção (VMs)
- VLAN 50: DMZ (serviços expostos)

• Thick: espaço reservado no datastore (mais previsível).
• Thin: aloca conforme uso (economiza, mas exige controle de capacity para evitar “datastore full”).
• Snapshots: ótimos para mudanças curtas; péssimos para manter por muito tempo (crescem e degradam IO).
• Consistência: snapshots/backup ideais usam “quiesce” (congelar IO) e integração com VSS (Windows) quando aplicável.

• Cluster: conjunto de hosts gerenciados como pool (balanceamento, migração, HA).
• HA: se um host cai, VMs reiniciam em outro host (depende de storage/rede/controle).
• Quorum: evita split-brain (principalmente em clusters com storage distribuído).
• Live migration: move VM ligada entre hosts (manutenção sem downtime, se rede/storage suportarem).
• Anti-affinity: regras para separar VMs críticas em hosts diferentes (ex: nós de cluster de banco).

HA não é DR:
- HA = continuidade local (falha de host)
- DR = desastre/site down (falha de datacenter)

• Backup: cópia independente, com retenção e verificação (restore test).
• Replicação: cópia contínua/quase contínua para outro storage/site (ótimo para DR, não substitui backup).
• RPO: quanto de dado você aceita perder (ex: 15 min).
• RTO: tempo para voltar (ex: 1 hora).
• Imutabilidade: proteção contra ransomware (backups WORM/imutáveis).

• Camada crítica: o hipervisor é “coroa” — se comprometer o host, compromete todas as VMs.
• RBAC: perfis por função (admin, operador, auditor) e princípio do menor privilégio.
• Rede de management isolada: sem acesso direto da internet; VPN e MFA.
• Atualizações: patching do hypervisor, management e firmware (planejamento com live migration).
• Segurança de backup: credenciais separadas, repositório protegido, imutabilidade.
• Segurança de rede: microsegmentação (quando disponível), firewalls, ACLs e VLANs.

• Não monitore só média: use percentis (p95/p99) para detectar degradações.
• CPU: uso, ready/steal, load, co-stop (quando aplicável).
• Memória: swap, ballooning, page faults, cache.
• Storage: latência (leitura/escrita), IOPS, fila, congestão, erros.
• Rede: throughput, perda, erros, drops, microbursts.
• Capacity: N+1, crescimento (mês a mês), “headroom” de datastore.

Modelo SRE (simplificado)
- Defina SLO: ex. "latência de storage p95 < 10ms"
- Crie alertas por SLO e saturação
- Revise tendência (forecast) e planeje expansão

• VM: virtualiza hardware; cada VM tem seu kernel/OS (isolamento forte, overhead maior).
• Container: compartilha kernel do host; empacota app+deps (leve, rápido, isolamento menor que VM).
• Na prática: containers rodam “em cima” de VMs na maioria das empresas (melhor governança e isolamento).
• Escolha: VM para workloads legados/estado/isolamento; containers para apps stateless e deploy frequente.

• 1) Requisitos: workloads, RPO/RTO, compliance, janela de manutenção.
• 2) Capacidade: CPU/RAM/IOPS, crescimento 12–24 meses, N+1.
• 3) Storage: arquitetura (SAN/NAS/distribuído), latência alvo, redundância, multipath.
• 4) Rede: VLANs/segmentação, uplinks, MTU, redundância, QoS se necessário.
• 5) Segurança: mgmt isolado, RBAC, MFA, logs centralizados, hardening.
• 6) Backup/DR: 3-2-1, imutabilidade, testes, runbooks.
• 7) Operação: monitoramento, alertas, patching, automação, documentação.

Blueprint mínimo (documento)
- Diagrama (rede + storage + hosts)
- Tabela de VLANs e IPs
- Políticas (RBAC, backup, patching)
- Runbook (failover/restore)
- Métricas/SLOs e alertas