01
Schritt 1: Bestand messen statt schätzen
Die Inventarliste aus der Buchhaltung stimmt nie. Was zählt, sind gemessene Auslastung, offene Verbindungen und die Frage, welche Maschine ohne welche andere nicht funktioniert.
# vSphere-Inventar mit den Werten, die spaeter die Zielgroesse bestimmen
govc find / -type m | wc -l
govc ls -l /DC/vm
govc vm.info -json app01 | jq '.virtualMachines[].config | {cpu:.hardware.numCPU,ram:.hardware.memoryMB,firmware:.firmware}'
# Auf jedem Linux-Gast: wer redet mit wem?
ss -tulpen | awk '{print $5, $6, $7}' | sort -u
systemctl list-units --type=service --state=running --no-pager
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
# Auf jedem Windows-Gast
# Get-NetTCPConnection -State Established | Select-Object LocalPort,RemoteAddress,RemotePort,OwningProcess
# Get-Service | Where-Object Status -eq Running | Select-Object Name,DisplayNameVier Werte je Maschine entscheiden über den Aufwand: Firmware, also BIOS oder UEFI, der Plattencontroller, die Betriebssystemversion samt Supportstatus und offene eingehende Verbindungen. Die Auslastung misst du über mindestens vier Wochen, sonst erwischst du den Monatsabschluss nicht.
# AWS Application Discovery Service: Agenten und erfasste Server
aws discovery describe-agents --region eu-central-1 --output table
aws discovery describe-configurations --configuration-ids <id>
aws discovery start-export-task --export-data-format CSV
# Azure Migrate wird ueber Portal, ARM-Vorlagen und PowerShell gesteuert,
# eine vollstaendige az-CLI-Abdeckung gibt es dafuer nicht.
# Nach der Erfassung: Bewertungsergebnis exportieren und pruefen, welche
# Maschinen als "bereit mit Bedingungen" oder "nicht bereit" markiert sind.Beide Werkzeuge liefern eine Abhängigkeitskarte. Sie ist der eigentliche Grund, sie einzusetzen, denn daraus ergeben sich die Migrationswellen: Maschinen, die miteinander sprechen, ziehen gemeinsam um, sonst läuft der Verkehr nach der Umschaltung quer durch die Standleitung.
