Ist das der Fall, verbringt Veeam nicht unerhebliche Zeit damit, den noch nicht genutzten (sparse) Plattenplatz zu verarbeiten (veeamagent32.exe bei 100% CPU). Im konkreten Fall einer VM mit 200 GB konfiguriertem und 25 GB genutztem Plattenplatz, bedeutet das in Zahlen:

• 3-4 Minuten Sicherung der tatsächlichen belegten 25GB.
• 4-5 Minuten Verarbeitung der restlichen, nicht existenten Daten.
• > 100% Overhead.

Die 4-5 Minuten Overhead fallen mit CBT komplett weg … was sich bei einer entsprechenden Anzahl an VMs und provisioniertem Plattenplatz summieren kann. Was für Veeam gilt, kann wegen VADP natürlich auch für andere Backup-Hersteller gelten (muss aber nicht).

Direkt nächsten Montag haben wir in Webcast Nr. 6 Matthias Frühauf, System Engineer bei Veeam, zu Gast. Der hat ofenfrisch von der VMworld 2010 in San Fransisco eine funktionsfähige Demo vom in Kürze erscheinenden Veeam Backup & Replication v5 im Gepäck und wird am lebenden Objekt zeigen, was eine zeitgemäße Sicherungslösung in virtuellen Umgebungen so alles hergibt. Inhaltliche Details sowie die Möglichkeit zur Anmeldung finden Sie hier. Wir freuen uns wie immer über rege Teilnahme und Ihre Fragen.

Update: Aufgrund einer unvorhersehbar wackeligen Internet-Verbindung vom uns zugeschalteten Hr. Frühauf im Hotel in Österreich gibt es nächsten Montag, 20.09.2010, 16:00 – 17:00 einen Ersatz-Termin für diesen Webcast. Anmeldung ist wie gehabt online.

Alle bereits angemeldeten Teilnehmer erhalten Montag vormittag automatisch eine neue Einladungs-E-Mail. Wir entschuldigen uns für die Unannehmlichkeiten und werden dafür den offiziellen Teil beim nächsten Webcast kurz halten – uns also voll auf Backup & Replication v5 konzentrieren.

Danke an alle Teilnehmer und das Feedback. Wir werden das Thema demnächst mit einer exemplarischen Produkt-Demo von Veeam Backup & Replication vertiefen und zeigen, wie die Integration einer solchen Backup-Lösung konkret funktioniert und was für tolle Sachen sich damit realisieren lassen. Sie haben weiteres Feedback oder Fragen? Lassen Sie es uns wissen!

Sie haben noch keine klassische Sicherungslösung mit VMware-Zusatzagenten im Einsatz, wüssten Ihre VMs aber gerne sicher? Dann registrieren Sie sich für unseren kommenden Webcast zum Thema “Backup in VMware-Umgebungen” oder vereinbaren einen Beratungstermin zum Thema mit uns. Ob groß oder klein, die Lösung orientiert sich an Ihnen.

Veeam Backup und vStorage API

Veeams Sicherungslösung unterstützt (wie seine Mitbewerber) einige Daten-Transport-Wege, um VMs Image-basiert und in bester Road-Runner-Manier zu sichern. Einer läuft über die vStorage API und dessen Network Block Device (NBD) Protokoll – ähnlich aber intelligenter als von VCB im Netzwerk-Modus bekannt.

Die Sicherungs-Engine verbindet sich dabei direkt mit dem ESX Host, der die zu sichernde VM beherbergt und saugt sich die relevanten Daten übers Netzwerk.

Access denied?…

Nun kann dies aber fehlschlagen und im konkreten Fall tat es das beim Sichern von VM-Daten mit folgenden Meldungen im B&R Log.

[14.07.2010 10:47:03] < 4204> dsk| >> |VDDK error: 13.You do not have access rights to this file
[14.07.2010 10:47:03] < 4204> dsk| >> |Failed to open VMDK.

Die “no access rights” Meldung sah verdächtig nach Privilegien-Problemen aus, jedoch weder die benötigten Mindest-vCenter-Privilegien für Veeams B&R noch das temporäre Umstellen der verwendeten Credentials auf den Administrator-Account brachten Abhilfe.

… oder doch was anderes?

Schaut man nun ein paar Zeilen weiter oberhalb im Log, sieht man dort Timeout-Meldungen bei Verbindungen zum ESX Host Port 902.

[14.07.2010 10:47:03] < 5844> dsk| WARN|[NFC ERROR] NfcNewAuthdConnectionEx: Failed to connect to peer. Error: Timeout while attempting read
[14.07.2010 10:47:03] < 5844> dsk| NBD_ClientOpen: Couldn't connect to esxtest.roc.consol.de:902 Timeout while attempting read

Hinter diesem Port lauscht der vmware-authd, der Verbindungen vorm Weiterreichen an die ESX Services authentifiziert. Die “no access rights”-Meldungen sind also nur eine Nachwehe des eigentlichen Problems, den Timeouts bei der Authentifizierung. Eine testweise aufgebaute manuelle Verbindung zeigt, dass eine Verbindung zwar zustande kommt, der authd aber erst nach 10 Sekunden mit einer Antwort aufwartet …

telnet esxhost.domain.tld 902
(Pause)
220 VMware Authentication Daemon Version 1.10: ...

Genau das ist der Timeout, den B&R bei Verbindungsversuchen verwendet, somit die Antwort vom authd wohl ganz knapp nicht mehr mitbekommt und ergo keine Authentifizierung zustande kommt.

Der Bösewicht: xinetd/libwrap, Ident und eine Windows Firewall

Warum nun braucht der authd die Denkpause, bis er antwortet? Mit etwas tcpdump und strace in der Service Console (ich vermiss die jetzt schon) war der Übeltäter schnell identifiziert: Eingehende Verbindungen auf Port 902 werden zuerst von xinetd entgegen genommen, der mit libwrap arbeitet, was wiederum einen (nicht Authentifizierungs-kritischen) Ident Lookup in Gegenrichtung, also zum Veeam Backup Server, TCP Port 113, auslöst.

Auf dem lauscht bei Windows-Systemen von Haus aus nichts. Verbindungsversuche sollten also umgehend abgelehnt werden. Nur nicht so bei vorliegendem Veeam Server. Dort war die Windows Firewall aktiv, welche eingehende Verbindungen auf TCP Port 113 ohne Antwort an die Gegenstelle einfach verwarf. xinetd/libwrap warteten also 10 Sekunden auf eine Antwort die nicht kam und erst dann wurde authd gestartet.

Die Definition einer Firewall-Ausnahme-Regel für TCP Port 113 löste folglich das Problem. Eigentlich unsinnig, da dort nichts lauscht, aber nichtsdestotrotz effektiv. Eine Anpassung der /etc/hosts.allow zur Unterdrückung der Ident Lookups wäre eine andere Alternative, diese wiederum müsste man aber auf allen ESX Hosts ausrollen.

Lange Rede, kurzer Sinn

Die auf ESX Servern beheimatete xinetd/libwrap/authd-Kombination führt also bei eingehenden Verbindungen auf Port 902 zu Ident Lookups, die bei aktiver Windows Firewall auf der Gegenstelle erstmal in einen 10 Sekunden-Timeout laufen und Veeam Backup and Replication in der Zwischenzeit aufgibt. So zumindest beobachtet mit ESX 4.0U1. Warum der Fehler bei so einer gängigen Konfiguration nicht bei Tante Google zu finden ist, ist mir unklar. Aber das sollte sich hiermit ändern.