Category Archives: 10665

Exchange 2010 DAG auf Netapp und anderem Storage

Unter Exchange 2010 kann man die Datenbanken ja auf bis zu 15 Server spiegeln. Wichtig in diesem Zusammenhang ist dann nur,das der Mountpoint der gleiche ist. Das schicke daran ist das man dann auch von einem passiven Knoten eine Datansicherung erstellen kann. Verwendet man die Netapp Snapshot TEchnologie ist das sogar besonders schnell und mit SnapManager für Exchange ist ein direkter Zugriff auf die einzelnen Elemente möglich. Das erleichtert die Herstellung von Elementen im täglichen Betrieb sehr.


Liegt ein Teil der DAG Mitglieder bzw. die Datenbanken auf einem Netapp – Filer und ein anderer Teil nicht, gibt es unter Umständen aber eine “Überraschung”: Mit Snapdrive lassen sich keine Luns mehr erstellen oder Mounten, der im Bild angezeigte Fehler tritt auf.



Dieser Fehler läßt sich aber dadurch beheben, das man auch auf den Mailboxservern, welche nicht an den Netappfiler angeschlossen sind Snapdrive installiert. Der Fehler tritt danach nicht mehr auf. Warum genau Netapp dieses Verfahren gewählt hat versuche ich gerade in Erfahrung zu bringen, ein Ticket ist schon eröffnet.


 


Viele Grüße


 


Walter Steinsdorfer


 


Die Lösung ist

Microsoft, Exchange 2010 und die Datensicherungsstory

Als das Exchange 2010 – Marketing so langsam ins Rollen geriet kam die Geschichte von Exchange-Umgebungen ohne Backup auf. Desöfteren habe ich gelesen, noch öfter gehört, das man lt. Microsoft kein Backup mehr für Umgebungen mit einer Database Availability Group benötigt. ich war Anfangs sehr erstaunt über die Häufigkeit mit der diese Aussage getroffen wurde. Tatsächlich ist es aber möglich eine Exchange Umgebung ohne Backup zu betreiben, allerdings nur unter sehr engen Rahmenbedingungen. Microsoft hat zu Backup, Restore und Disaster Recovery eine Seite im Technet eingerichtet.

Eine der Rahmenbedingungen ist es, mindestens 3 Kopien einer Datenbank innerhalb der DAG zu verwalten, eine davon über einen gewissen Zeitraum gelagged (d.h. die Daten in den TA-Logs werden übertragen aber nicht in die Datenbank eingearbeitet, d.h. der Rollforward wird um den eingestellten Zeitraum verzögert.). Auf diese Kopie darf aber dann wirklich nur im Disasterfall zugegriffen werden, da die Onlineschaltung das sofortige Einspielen der Log-Dateien bewirken würde und der “Sicherheitszeitraum” wäre dahin. Sollten Sie eine derartige Umgebung einrichten holen sie sich an dieser Stelle Rat von einem erfahrenen Experten.

Eine weitere Bedingung ist das die Datenbanken auf Circular Logging eingestellt werden müssen. Ohne Backup erfolgt ja kein Abschneiden der Transaktionsprotokolle, auch die größte Festplatte wäre irgendwann voll.

Möchte man kein Backup mehr machen auf das man im Bedarfsfall zurückgreifen kann muß man natürlich zuallererst darüber nachdenken, wie lange auf Daten, insbesondere diejenigen welche vom Benutzer gelöscht werden noch zugegriffen werden muß. Es bietet sich an dafür das in Exchange 2010 eingebaute “Single Item Recovery” zu nutzen. Der Einwand “Die Datenbanken werden ja dann riesig” verstehe ich. Doch genau dafür ist Exchange 2010 ja ausgelegt, bis zu 2 TB große Datenbanken werden supportet. Da man davon 100 pro DAG-MailboxServer haben kann, ist es eine reine Kostenfrage. Und Festplatten werden ja bekanntlich immer preiswerter, 1TB ist schon für unter 80 EUR zu bekommen.

Also: Exchange 2010 ohne Backup zu betreiben geht. Allerdings in engen Grenzen. Zu beachten sind natürlich auch die jeweils im Land geltenden Vorschriften für Datenarchivierung sofern man darunter fällt.

Viele Grüße

 

Walter Steinsdorfer

Falschen Iscsi-Initiator eingespielt, was nun?

Auf der Microsoft Download-Seite des ISCSI-Initiator 2.08 erhält man durch einen Klick auf den Link “Download Files below” Zugriff auf den Download des Microsoft ISCSI-Initiators. Eine feine Sache, denn damit kann man über Gigabit-Anbindungen Storages mit einem ISCSI-Target anbinden. Die für den Server so lokal sichtbaren Festplatten sind genau wie tatsächlich im Server eingebauten Festplatten nutzbar. Einige Netzwerkkarten bieten sogar an das man über ISCSI den Server bootet. In einigen Fällen ist das eine richtig “coole” Sache. Wenn man viele baugleiche Server aus einer Baureihe kauft kann man diese über ISCSI booten und einfach einen davon “Weglegen”. Sollte eine Hardware versagen muß die Ausfall-Maschine einfach eingeschaltet werden und die Konfiguration der defekten übertragen werden. Noch besser finde ich das man vor dem Einspielen von Updates einfach einen Schnappschuss erstellt. Sollten die Updates scheitern kann man einfach die Schattenkopie einspielen, meist geht das am San das man die Schattenkopie wieder herstellt. Auch ein einfaches Klonen von Server ist so möglich (bitte Vorsicht wegen der SID).

Tja, was wenn man den oben angesprochenen ISCSI-Initiator herunterlädt und den vorhandenen ISCSI-Initiator updated? Wenn der Server über das SAN gebootet wird ist der heruntergeladene Initiator leider der falsche und der Server bluescreend gleich nach dem Startbildschirm. Den richtigen, Bootfähigen Initiator findet man, wie auf der Abbildung dargestellt etwa in der Mitte der Downloadseite.

iscsi-initiator

Hat man aus irgendwelchen Gründen nun keinen Schnappschuß gemacht kann der sich im Reebootmodus befindliche Server mit der Option “Last good Known” wieder zum Leben erweckt werden (F8 beim Windows – Splash – Screen). Der richtige, Bootfähige ISCSI-Initiator frägt übrigens bei der Installation welche Netzwerkkarte zum Booten verwendet wird. Daran ist der eindeutig erkennbar.

Viele Grüße

 

Walter Steinsdorfer