NetApp SnapDrive auf drei Knoten DAG – Access Denied

Vor einigen Tagen haben wir bei einem Kunden ein Problem mit einem Exchange 2010 Server gehabt, der sich nach dem Update auf RU4 für SP3 etwas seltsam verhalten hat. Der geöffnete Case bei Microsoft endete mit der Empfehlung, den Server neu zu installieren.

Die Umgebung war wie folgt aufgebaut:
2 Exchange 2010 SP3 RU 4 Server in einer DAG
Betriebssystem Windows Server 2008 R2 SP1, aktueller Patchlevel

Da wir aber während der Zeit nicht „einbeinig“ da stehen wollten, haben wir kurzerhand einen weiteren Server installiert, und wollten diesen in die DAG aufnehmen. Die Exchange Installation ist sauber durchgelaufen, doch nach dem Hinzufügen zur DAG traten auf den ersten beiden Servern Probleme auf.

Auf beiden Servern waren die Datenbanken über FibreChannel LUNs von einem NetApp Filer angebunden. Dazu haben wir das Tool SnapDrive von NetApp genutzt.

Die Backups der Server wurden über den SnapManager für Exchange durchgeführt, ebenfalls von NetApp.

Der Fehler, der nach Hinzufügen des dritten Knotens zur DAG auftrat, war ein schlichtes „Access Denied“ bei jeglicher Aktion im SnapDrive auf den alten Servern. Die Backups mit dem SnapManager liefen aber nach wie vor einwandfrei, und es traten auch sonst keine weiteren Fehler auf.

Nach ein wenig suchen, kamen wir zu folgendem Ergebnis:

1. SnapDrive muss auf jedem Member-Server innerhalb einer DAG installiert sein, auch wenn die Datenbanken lokal liegen, und NICHT über LUNs von einem NetApp Filer kommen.

SnapDrive versucht bei jeder Aktion mit allen Member-Servern der DAG zu kommunizieren. Da der dritte Knoten seine Datenbanken auf lokalen Festplatten liegen hatte, hatten wir dort kein SnapDrive installiert, was zur Fehlermeldung „Access Denied“ geführt hat. Das „Access Denied“ bezog sich also die ganze Zeit über auf den Versuch, mit dem neuen Member –Server zu kommunizieren.
Hier vielleicht ein kleiner Hinweis an die Kollegen von NetApp: DAS hätte man wirklich auch mal besser darstellen können. Wir haben einige Zeit damit verbracht auf den ursprünglichen Knoten nach Fehlern zu suche, und konnten uns auch nicht erklären, wo der Fehler auf einmal herkommt. Schließlich hatten wir an den „alten“ Servern keine Änderungen vorgenommen.

2. Es gibt einige Hotfixe für Server 2008 R2, die bekannte Probleme lösen. Diese trafen zwar auf uns nicht zu, aber vielleicht helfen sie Euch weiter.

Infos dazu im Exchange Team Blog: http://blogs.technet.com/b/exchange/archive/2011/11/20/recommended-windows-hotfix-for-database-availability-groups-running-windows-server-2008-r2.aspx

Tagged with: , ,
Veröffentlicht in Exchange

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

DeBugIT Autoren

Gib deine E-Mail-Adresse ein, um diesem Blog zu folgen und per E-Mail Benachrichtigungen über neue Beiträge zu erhalten.

Follow DeBugIT – IT Blog on WordPress.com
%d Bloggern gefällt das: