Der kleine Werkzeugkasten für die vCenter Server Appliance

Die vCenter Server Appliance (VCSA) war ein großartiger Schritt in die richtige Richtung. Einfache Bereitstellung, keine Windows-Lizenz, einfaches Management über eine Web-GUI.

Besonders in Version 6.0 gab es ein paar Probleme mit Logfiles, die nicht archiviert und/oder rotiert wurden. Oftmals wurde die Appliance bei der Bereitstellung auch etwas zu klein dimensioniert und die Virtuelle Infrastruktur ist seither stärker als geplant gewachsen.

So kam es immer wieder vor, daß Mountpoints bis ans Limt gefüllt wurden und die Appliance dann mangels Platz den Dienst verweigerte. Dieser Artikel fasst mehrere KB Artikel und Blogbeiträge zusammen, da ich diese immer wieder aufs Neue suchen musste.

Alle Angaben, Kommandos und Prozeduren ohne Garantie und auf eigene Gefahr! Vor Durchführung der Arbeiten ist unbedingt ein Snapshot und/oder ein Backup zu erstellen.

Cron

Viele Hintergrunddienste werden über Cronjobs gesteuert. So zum Beispiel die Archivierung und Kompression der Logfiles. Findest dies nicht mehr statt, könnte es sein, dass der entsprechence Conjob nicht funktioniert.

Man kann sehr einfach prüfen, wann Cron letztmalig gelaufen ist.

ls -l /var/spool/cron/lastrun/

Zum Vergleich schicke ich ein date Kommando voraus.

vc:~ # date
Mon Dec 4 12:55:39 CET 2017
vc:~ # ls -l /var/spool/cron/lastrun/
total 0
-rw------- 1 root root 0 Dec 3 20:00 cron.daily
-rw------- 1 root root 0 Dec 4 12:15 cron.hourly
-rw------- 1 root root 0 Dec 1 20:00 cron.weekly

Wie hier gut zu sehen ist, lief cron.daily am Abend zuvor, cron.hourly vor 40 Minuten und cron.weekly vor drei Tagen. Also alles in Ordnung mit den Cronjobs.

Wäre dies nicht der Fall, lohnt ein Blick auf die Ablaufeinstellungen des Root Passwortes. Dann müssten entsprechende Einträge im Log zu finden sein.

grep "Authentication token is no longer valid; new one required" /var/log/messages.0.log | head

Das Kommando liefert dann mehrere Ergebnisse in folgender Form zurück:

<timestamp> vcenter /usr/sbin/cron[<ID>]: Authentication token is no longer valid; new one required

Es gilt, das Ablaufdatum des Root-Passwortes zu prüfen.

Root Password Ablauf anzeigen

Achtung! Das ist kein Tippfehler! Es heisst nicht “change”, sondern “chage”.

chage -l root

Ist es abgelaufen, wird man zur Erneuerung aufgefordert.

Password change requested. Choose a new password.
 Old Password:
 New password:

Eine erneute Abfrage zeigt die aktuelle Einstellung.

vc:~ # chage -l root
Minimum: 0
Maximum: 99999
Warning: 7
Inactive: -1
Last Change: Dec 27, 2016
Password Expires: Never
Password Inactive: Never
Account Expires: Never

In diesem Fall läuft das Passwort nicht, bzw. erst nach 99999 Tagen (fast 274 Jahre) ab. Das sollte genügen 😉

Restart vCenter Server Services

Gelegentlich ist es notwendig, alle Dienste neu zu starten. Das kann entweder durch einen Reboot oder etwas schneller durch folgende Befehle erreicht werden.

service-control --stop --all
service-control --start --all

Services

Alle Dienste anzeigen.

service-control --list

Alle Dienste mit Status anzeigen.

service-control --status

Dienste gezielt stoppen.

service-control --stop servicename

Dienste gezielt starten.

service-control --start servicename

LVM

Ein Teil der VCSA Partitionen unterliegen dem Logical Volume Manager (LVM). damit lassen sich Partitionen im laufenden Betrieb vergrößern. Zunächst ermittelt man das zugehörige VMDK File und vergrößert dieses im vSphere Client. Anschließend wird das Volume im OS vergrößert.

VCSA Filesystem commands

lsblk

vc:~ # lsblk
NAME MAJ:MIN RM SIZE RO MOUNTPOINT
sda 8:0 0 20G 0
├─sda1 8:1 0 132M 0 /boot
├─sda2 8:2 0 1G 0 [SWAP]
└─sda3 8:3 0 10.9G 0 /
sdb 8:16 0 1.4G 0
sdc 8:32 0 25G 0
└─swap_vg-swap1 (dm-8) 253:8 0 25G 0 [SWAP]
sdd 8:48 0 50G 0
└─core_vg-core (dm-7) 253:7 0 50G 0 /storage/core
sde 8:64 0 10G 0
└─log_vg-log (dm-6) 253:6 0 10G 0 /storage/log
sdf 8:80 0 10G 0
└─db_vg-db (dm-5) 253:5 0 10G 0 /storage/db
sdg 8:96 0 5G 0
└─dblog_vg-dblog (dm-4) 253:4 0 5G 0 /storage/dblog
sdh 8:112 0 25G 0
└─seat_vg-seat (dm-3) 253:3 0 25G 0 /storage/seat
sdi 8:128 0 1G 0
└─netdump_vg-netdump (dm-2) 253:2 0 1016M 0 /storage/netdump
sdj 8:144 0 10G 0
└─autodeploy_vg-autodeploy (dm-1) 253:1 0 10G 0 /storage/autodeploy
sdk 8:160 0 10G 0
└─invsvc_vg-invsvc (dm-0) 253:0 0 10G 0 /storage/invsvc
fd0 2:0 1 4K 0
sr0 11:0 1 1024M 0

lsscsi

vc:~ # lsscsi
[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi
[0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj
[0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk
[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0

Hat man das VMDK ermittelt, welches die Partition trägt, kann man im vSphere-Client die virtuelle Disk vergrößern. Im nächsten Schritt wird ein “autogrow” Befehl ausgeführt, der das logische Volume maximiert.

vpxd_servicecfg storage lvm autogrow

Das funktioniert nur bei Volumes, die dem LVM unterstehen. Für Disk 1 (sda) mit der / partition funktioniert dies beispielsweise nich.

Große Dateien finden

Auf der Suche nach Kandidaten, die das root-, oder /storage/log Volume verstopfen kann folgender Befehl hilfreich sein.

du -a /var | sort -n -r | head -n 10

du -a /storage/log | sort -n -r | head -n 10

Logrotate verkürzenn

Ich hatte kürzlich den Fall, daß ein Log in relativ kurzer Zeit über mehrere Gigabyte angewachsen ist. Um dies zu verhindern setzte ich die Logrotation von wöchentlich auf täglich.

cd /etc/logrotate.d

Das entsprechende Skript sichern wir, bevor wir es verändern. In diesem Fall war es dnsmasq

cp dnsmasq ./dnsmasq.old

Als nächstes öffnen wir das Skript im vi.

vi dnsmasq

In den “INSERT” Mode wechseln mit “i”

Zeile 2 “weekly” ändern in “daily”.

/var/log/dnsmasq.log {
daily
missingok
notifempty
delaycompress
sharedscripts
postrotate
[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`
endscript
create 0640 dnsmasq dnsmasq

vi verlassen mit “:wq!”

Das große dnsmasq.log liegt immer noch da und soll gelöscht werden.

cd /var/log

rm dnsmasq.log

Speicher wird nach Löschen nicht wieder freigegeben

Nach löschen einer oder mehrer Dateien vergrößert sich der freie Speicherplatz nicht und df -h zeigt noch die ursprüngliche Belegung. Dies ist der Fall, wenn noch ein Prozess auf die Datei zugreift.

lsof | grep deleted

Die Zahl nach dem Prozessnamen ist die Prozess-ID (PID).

postgres 8860 vpostgres 10u REG 253,4 16777216 16395 /storage/dblog/vpostgres/pg_xlog/000000010000011900000041 (deleted)

Um den Löschvorgang abzuschließen müssen wir den Prozess beenden. Dabei ist <PID> durch die tatsächliche ID zu ersetzen.

kill -9 <PID>

Eine erneute Kontrolle mit df -h zeigt, daß der Speicherplatz freigegeben wurde.

VCSA debug tools