Veeam Backup & Replication – Error: VSSControl: Failed to prepare guest for freeze, wait timeout 900 sec

Bei einem Kunden funktionierte das Veeam Backup für eine VM nach der Installation eines Microsoft SQL Server 2016 Express nicht mehr. Fehlermeldung in Veeam:

Error: VSSControl: Failed to prepare guest for freeze, wait timeout 900 sec

Die von Veeam bereitgestelle KB1377 hat nicht geholfen. Bei der Überprüfung der Volumenschattenkopiedienste mit „vssadmin list writers“ wird der SQLWriter nicht aufgeführt. Die Anwendung von KB2095 von Veeam hilft allerdings auch nicht.

In den Ereignislogs des Servers findet sich folgende Fehlermeldung mit der Ereignis-ID 24583:

Sqllib-Fehler: OLE DB-Fehler beim Aufrufen von
                    IDBInitialize::Initialize. hr = 0x80004005.
                    SQLSTATE: HYT00, Native Error: 0
Source: Microsoft SQL Server Native Client 11.0
Error message: Anmeldungstimeout abgelaufen SQLSTATE: 08001, Native
               Error: -1
Source: Microsoft SQL Server Native Client 11.0
Error message: Netzwerkbezogener oder instanzspezifischer Fehler beim
               Herstellen einer Verbindung mit SQL Server. Der Server
               wurde nicht gefunden, oder auf ihn kann nicht
               zugegriffen werden. Überprüfen Sie, ob der Instanzname
               richtig ist und ob SQL Server Remoteverbindungen
               zulässt. Weitere Informationen erhalten Sie in der SQL
               Server-Onlinedokumentation.
SQLSTATE: 08001, Native Error: -1
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 11.0
Error message: SQL Server-Netzwerkschnittstellen: Fehler beim Suchen
               des angegebenen Servers/der angegebenen Instanz
               [xFFFFFFFF].
DBPROP_INIT_DATASOURCE: SRV003\SQLEXPRESS
DBPROP_INIT_CATALOG: master
DBPROP_AUTH_INTEGRATED: SSPI

Nachdem ich da nicht weiter wusste (diverse Dinge überprüft, wie bspw. die Zugriffsberechtigungen auf die Datenbank etc.), habe ich dann erstmal die SQL-Datenbanken in Veeam von der Sicherung ausgeschlossen. Ein Backup lief dann für den Server durch. Anschließend habe ich mir ein Script zur Datenbank-Sicherung erstellt, welches eigentlich als geplante Aufgabe täglich einmal durchlaufen sollte. Dazu habe ich die von Microsoft bereitgestellte Anleitung verwendet: https://support.microsoft.com/en-us/kb/2019698

Beim Testen des Scripts in der Testumgebung lief alles glatt. Auf dem Produktivserver erhielt ich dann aber die Fehlermeldung, dass die Instanz „.\SQLEXPRESS“ nicht gefunden wurde (obwohl sie lief). Das hat mir zu denken gegeben. Nachdem ich das Script so angepasst habe, dass die Instanz „SQLEXPRESS“ nicht mehr benannt wird (also nur „.\“), konnte ein Backup erstellt werden. Somit war mir klar, dass die Instanz quasi „unsichtbar“ ist. Nachdem ich mir dann die SQL-Server-Konfiguration im SQL Server Configuration Manager angeschaut habe, insbesondere bei den Server-Protokollen und dies mit der Konfiguration in der Testumgebung verglichen hatte, stellte ich fest, dass das Protokoll „Shared Memory“ nicht aktiviert war. Nachdem ich das Protokoll „Shared Memory“ sowie zur Sicherheit auch noch „Named Pipes“ aktiviert und den SQL-Server neu gestartet hatte, lief das Backup-Script auch mit der Benennung der Instanz. Eine Überprüfung der VSS-Writer mit „vsadmin list writers“ zeigte nun auch den SQL-Writer mit an.

Also habe ich die Ausnahme aus Veeam wieder entfernt und das Backup gestartet, welches dann erfolgreich durchgelaufen ist.

Redundante Servervirtualisierung

Gekürzte und etwas veränderte Dokumentation eines Projekts der Firma Sylphen, welches ich durchgeführt habe. Achtung! Diese Informationen sind relativ alt und ich würde es heute auch nicht mehr so machen. Wer keine Angst vor Microsoft hat, sollte sich auf jeden Fall den kostenlosen Hyper-V Server 2012 anschauen.

Projektbeschreibung

Aus Platz-, Kosten- und Energieeffizienzgründen sollen die bestehenden physikalischen Server eines Unternehmens virtualisiert und auf einem einzigen physikalischen Server in virtuellen Maschinen installiert werden.

Weiterhin soll ein Backupserver zur Verfügung gestellt werden, der bei einem Ausfall des Hauptservers dessen Arbeit übernimmt, so dass ein unterbrechungsfreier Arbeitsfluss gewährleistet wird. Hier wird ein Distributed Replicated Block Device (DRBD) angestrebt, welches, ähnlich einem RAID1-System, für Redundanz im Serverbetrieb sorgt und somit eine optimale Lösung für einen Ausfallserver darstellt.

Lösungsansätze

In Betracht kamen zwei Lösungsansätze:

  1. Synchronisierung des Hauptservers mit dem Ausfallserver über rSync
  2. Einsatz eines DRBD

Aufgrund der großen Datenmengen würde rSync schnell an seine Grenzen geraten, insbesondere da virtuelle Maschinen teilweise sehr groß (10 GB und mehr) werden können. Würde nun während einer Synchronisierungsphase der Hauptserver ausfallen, wäre die virtuelle Maschine, die gerade synchronisiert wird, auf dem Ausfallserver ebenfalls defekt. Der entscheidende Vorteil von DRBD ist jedoch aufgrund der Ähnlichkeit zu einem RAID1, dass hier jedes geänderte Bit einzeln übertragen wird und bei Ausfall des Hauptservers das Backup nur wenige Sekunden alt ist und die Arbeit nach nur einer kurzen Unterbrechung direkt wieder an der Stelle aufgenommen werden kann, die zum Zeitpunkt des Ausfalls bestand.

Der Einsatz von DRBD ist somit die geeignetste Lösung.

Realisierung

Grundsystem

Als Grundsystem wird ein Debian 5.0 (Lenny) 64bit installiert, auf dem der VMware-Server installiert wird. Da das Betreiben eines VMware-Servers auf dem Host-System keine großen Ansprüche hat, reicht die Basisinstallation des Debian-Systems.

Dabei werden dem System eine statische IP sowie ein Hostname zugewiesen. Der Server erhält folgende Netzwerkkonfiguration für die erste Netzwerkkarte (eth0):

Hostname: hauptserver
IP: 192.168.0.11
Subnetzmaske: 255.255.255.0
Standardgateway: 192.168.0.254

Die Rolle des Standardgateways übernimmt hier der vorhandene DSL-Router.

Es wird zusätzlich zu root der Benutzer vmware eingerichtet.

Um zu gewährleisten, dass keine aktuell bekannten Probleme den Betrieb stören, wird ein Update des Debian-Systems mit apt-get update durchgeführt.

Der Backupserver erhält die gleiche Konfiguration wie der Hauptserver. Einzig die IP-Adresse und der Hostname werden anders gewählt:

Hostname: ausfallserver
IP: 192.168.0.12

DRBD

Auf beiden Systemen kann nun DRBD installiert werden. Dazu ist es notwendig, noch einige Pakete zu installieren:

apt-get install make gcc flex drbd8-utils drbd8-modules-2.6-686
apt-get install linux-headers-2.6.26-686 psmisc build-essential

Es wird zunächst in das Verzeichnis /usr/src gewechselt, um die Source-Dateien von DRBD herunter zu laden und zu entpacken:

wget http://oss.linbit.com/drbd/8.3/drbd-8.3.1.tar.gz
tar -xzf drbd-8.3.1.tar.gz

DRBD soll als Modul gestartet werden, also nicht direkt in den Kernel eingebunden werden. Deshalb wird folgender Befehl ausgeführt:

cd drbd-8.3.1
make clean all

Ist die Kompilierung zum Modul erfolgreich verlaufen, wird das Modul im System installiert:

make install

Beide Systeme erhalten nun auf der zweiten Netzwerkkarte IP-Adressen, um miteinander kommunizieren zu können. Die zweite Netzwerkarte ist insofern nützlich, als das der gewöhnliche Netzwerk-Verkehr durch das DRBD nicht eingeschränkt wird.

Das Hauptsystem, hauptserver, erhält die IP-Adresse 192.168.1.11 auf eth1 und der Backupserver, ausfallserver, erhält die IP-Adresse 192.168.1.12 auf eth1.

Wichtig ist es, in die Datei /etc/hosts beide Server mit ihren Adressen auf eth1 einzutragen, um später eine Namensauflösung zu ermöglichen:

192.168.1.11            hauptserver
192.168.1.12            ausfallserver

Die Systeme werden direkt miteinander verbunden, um den Umweg über einen Switch zu vermeiden, womit auch eine potentielle Problem- oder Fehlerquelle ausgeschlossen wird.

Nach der Installation des DRBD-Moduls und der Konfiguration der Netzwerkumgebung wird die Datei /etc/drbd.conf auf jedem Server angepasst.

global {
  usage-count no;
}

common {
  protocol C;
}

resource r0 {
  on hauptserver {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   192.168.1.11:7789;
    meta-disk internal;
  }
  on ausfallserver {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   192.168.1.12:7789;
    meta-disk internal;
  }
}

Um das DRBD zu initialisieren, wird der Befehl drbdadm up r0 ausgeführt. Dieser Befehl beinhaltet die einzelnen Befehle create-md, attach, syncer und connect. Mit create-md werden die Metadaten des DRBD erstellt. Der Befehl attach asoziiert das DRBD mit seinem Gegenpart, während syncer die die Synchronisierungsparameter setzt und connect schließlich die Verbindung zum Gegenpart herstellt.

Um zu prüfen, ob das DRBD erfolgreich initialisiert wurde, wird der Befehl cat /proc/drbd eingegeben. Das Ergebnis sieht ungefähr wie folgt aus:

version: 0.7.22 (api:79/proto:74)
SVN Revision: 2554 build by root@hauptserver, 2009-06-19 20:47:34
 0: cs:Connected st:Secondary/Secondary ld:Inconsistent
    ns:0 nr:0 dw:0 dr:0 al:0 bm:752 lo:0 pe:0 ua:0 ap:0

Um dem DRBD nun noch mitzuteilen, welches System das Primärsystem ist, wird folgender Befehl auf hauptserver eingegeben:

drbdadm -- --overwrite-data-of-peer primary r0

DRBD beginnt nun, sich zu synchronisieren, was einige Minuten in Anspruch nimmt. Das DRBD ist somit erschaffen.

Im Anschluss wird das DRBD mit einem Dateisystem zu versehen, damit es verwendet werden kann:

 mkfs.ext3 /dev/drbd0

Heartbeat

Damit ausfallserver im Notfall als Ausfallserver einspringen kann, ist es notwendig, zusätzlich ein Heartbeat-Service einzurichten. Andernfalls würde das DRBD nur ein nicht-lesbares Device auf ausfallserver zur Verfügung stellen.

Zunächst wird Heartbeat auf beiden Systemen installiert:

apt-get install heartbeat-2

Für die Konfiguration des Heartbeat-Services werden nun auf hauptserver die Konfigurationsdateien erstellt:

cd /etc/ha.d
cp -a /usr/share/doc/heartbeat-2/authkeys .
chmod 0600 authkeys
cp -a /usr/share/doc/heartbeat-2/ha.cf.gz .
gunzip ha.cf.gz
cp -a /usr/share/doc/heartbeat-2/haresources.gz .
gunzip haresources.gz

Die Datei ha.cf wird folgendermaßen angepasst:

logfacility     local0
ucast eth1 192.168.1.12
auto_failback on
node    hauptserver
node    ausfallserver

Die Datei  haresources wird mit folgenden Werten gespeichert:

hauptserver drbddisk::r0 \ Filesystem::/dev/drbd0::/data::ext3 \

Zum Abschluss der Grundkonfiguration wird in der Datei authkeys noch die Authentifizierungsmethode gewählt. Da es sich um eine vertrauenswürdige Umgebung handelt, wird die einfachste Methode „CRC“ gewählt:

auth 1
1 crc

Anschließend werden die Konfigurationsdateien, die auf beiden Servern, mit einer Ausnahme in der ha.cf, identisch sein müssen, nach ausfallserver übertragen:

scp ha.cf haresources authkey ausfallserver$PWD:

Auf ausfallserver wird in der ha.cf die IP-Adresse auf 192.168.1.11 geändert.

Initial wird der Heartbeat-Service mit folgendem Befehl auf beiden Systemen gestartet:

/etc/init.d/heartbeat

Unter /data ist nun der Speicherplatz vorhanden, der für die VMs genutzt werden soll.

VMware

Zur Installation des VMware-Servers sind weiterhin noch zusätzliche Pakete notwendig, die noch nachinstalliert werden müssen:

apt-get install psmisc build-essential

Vorbereitend zur Installation des VMware-Servers wird das Verzeichnis /data/VMs erstellt, in dem später die virtuellen Maschinen gespeichert werden sollen.

Der VMware-Server befindet sich bereits auf einer CD, die in das System gemounted wird. Das VMware-Server-Paket wird nach /tmp kopiert und dort entpackt.

cd /tmp
tar xvfz VMware-server-2.0.1-156745.x86_64.tar.gz

Nach dem Entpacken des Paketes wird der VMware-Server installiert.

cd VMware-server-2.0.1-156725.x86_64
./vmware-install.pl

Alle Abfragen, die das Installationsscript stellt, werden mit den Standardwerten beantwortet. Die Annahme der Lizenzvereinbarung wird mit der Eingabe „yes“ bestätigt. Bei der Abfrage nach dem Speicherort für die virtuellen Maschinen wird der Pfad /data/VMs angegeben.

Der Abschluss der Installation ist die Eingabe Seriennummer für den VMware-Server.

Nun können über die Weboberfläche des VMware-Servers (hier https://192.168.0.11:8333) die virtuellen Maschinen angelegt werden.

Fehlervermeidung und -behebung

Die  virtuellen Maschinen werden bei einem Ausfall des primären Servers automatisch auf dem Sekundärserver gestartet. Da vorher in der Regel kein Beenden der virtuellen Maschinen auf dem Primärsystem durchgeführt wurde, kann es dazu kommen, dass die Dateisysteme der virtuellen Maschinen inkonsistent werden. Nach Möglichkeit sollten deshalb so bald wie möglich die virtuellen Maschinen neu gestartet werden, um Inkonsistenzen durch Checkdisk zu beheben.

Sollte die Verbindung zwischen beiden Systemen unterbrochen werden, starten sich die virtuellen Maschinen auf dem Sekundärsystem automatisch, wodurch jeder virtuelle Server nun zweimal im Netzwerk vorhanden ist. In diesem Fall müssen die virtuellen Maschinen auf dem Sekundärsystem manuell wieder heruntergefahren werden. Abhilfe kann hier die Implementierung von STONITH (Shoot the other node in the head) schaffen.

Um weitere Probleme zu vermeiden, sollte man, wenn nötig, immer zuerst das Sekundärsystem herunter fahren und danach das Primärsystem. Bei der Startreihenfolge ist die umgekehrte Reihenfolge zu beachten. Zuerst sollte das Primärsystem gestartet werden, danach erst das Sekundärsystem.

Präsentation

Unter folgendem Link steht die Präsentation des Projektes im PowerPoint 2007 Format zur Verfügung: Präsentation Redundante Servervirtualisierung