HCL hat den Interim Fix 2 für Domino 12.0.1 veröffentlicht. Er enthält wichtige Fixes für Probleme und Abstürze in Bezug auf das DAOS: Fix introduced in release SPR Description Additional information Domino 12.0.1 Interim Fix 2 (12.0.1 IF2) DCKTCARNVR Fixed an issue where error may result in long held locks on daoscat.nsf during replication SPPPCAMM6Y […]
Der Beitrag HCL Domino 12.0.1 IF2 mit wichtigen Fixes für DAOS erschien zuerst auf n-komm.
Im letzten Teil unserer DAOS Reihe schauen wir uns kurz an, was genau auf uns zu kommt, wenn wir den Domino Attachment and Object Service aktiviert haben.
Durch die Aktivierung von DAOS stellt euch der IBM Domino Server einen neuen Dienst zur Verfügung, den DAOS Manager (DAOSMgr). Der DAOS Manager empfängt tell-Befehle und unterstützt euch bei der Arbeit mit DAOS. Hier eine kurze Übersicht über die beiden wesentlichsten Befehle:
tell daosmgr status
Eine allgemeine, recht umfassende Übersicht über den Status des DAOS Repository erhaltet ihr durch den "tell daosmgr status"-Befehl. Besonders zu betrachten ist der "catalogState", welcher stehts auf "SYNCHRONIZED" stehen sollte sowie die letzte "pruneEndTime" und "resyncEndTime".
Abb. 1: DAOS Manager Status
tell daosmgr resync [force]
Dieser Befehl sorgt dafür, dass der DAOS Catalog neu abgeglichen wird. Der DAOSMgr selbst weiß nicht, welche Dateien zu welcher Datenbank gehören. In den Datenbanken selbst ist diese Referenz gesichert. Mit Hilfe des "Resync" überprüft der DAOS Manager jede Datenbank und fragt ab, ob alle Dateien, welche die Datenbank ausgelagert hat, noch vorhanden sind.
Auf diese Weise habt ihr immer einen guten Überblick über eure DAOS Repositories. Solltet ihr dennoch Probleme mit eurem DAOS haben, helfen wir gerne weiter.
Zu den vorherigen Teilen unserer DAOS-Reihe geht es hier entlang:
DAOS - die Rettung eures Speicherplatzes! Teil 1: Allgemeines
DAOS - die Rettung eures Speicherplatzes! Teil 2: Planung und Vorbereitung
DAOS - die Rettung eures Speicherplatzes! Teil 3: Konfiguration und Aktivierung
Nachdem wir nun alles für die Einführung des IBM Domino Attachment and Object Services vorbereitet haben, geht es heute ans Eingemachte!
DAOS konfigurieren:
Auch für DAOS gibt es im Server Dokument einen entsprechenden Reiter. Hier können der Pfad für das Repository (DAOS-Basispfad), die Mindestgröße eines auszulagernden Anhangs, sowie die Dauer der Aufbewahrung eines Revisionsstands einer Datei, nachdem alle darauf verweisenden Dokumente schon gelöscht wurden, festlegen.
Abb. 1: Das Serverdokument mit den Konfigurationsmöglichkeiten für DAOS
Der DAOS Estimator gibt auch hier zum Teil Empfehlungen (Vgl. Teil 2: Plattenspeicher zur Verfügung stellen).
Abb. 2: Ausschnitt der Analyse des DAOS Estimators
Mit Hilfe der vom DAOS Estimator erfassten Daten lässt sich ableiten, dass es bei dem hier analysierten Server sinnvoll ist, die minimale Dateigröße auf 64kb zu setzen. Bei Dateigrößen, die darunter liegen, ist das Einsparpotential zu gering. Zu beachten ist allerdings auch die Anzahl der Attachments, welche ausgelagert würden. DAOS hat eine maximale Repository Grenze von 39.960.000 Dateien. Das hört sich im ersten Moment recht umfangreich an, betrachten wir aber noch einmal unser Beispiel und würden die DAOS Attachment Grenze auf 0kb legen, so würden in etwa eine halbe Million Attachments extrahiert werden (Vgl. Teil 2: Abb. 1, Extrapolated # of duplicate attachments). Besonders bei Archivservern sollten die entsprechenden Werte des DAOS Estimators gründlich betrachtet werden. DAOS läuft auch weiter, wenn die maximale Grenze von Repository Files erreicht wurde. Allerdings werden keine weiteren Anhänge mehr ins Repository verschoben.
Nach der Konfiguration von DAOS sollte der entsprechende Repository-Pfad im Dateisystem angelegt werden und der Domino Server neu gestartet werden.
In dem neue angelegten DAOS Repository Ordner werden vom Domino Server die Ordner 0001 - 9999 erzeugt. In jedem dieser Ordner werden maximal 40.000 sogenannte "Notes Large Object"-Dateien (*.nlo) erzeugt. Jede einzelne dieser Dateien repräsentiert ein Attachment. Die Dateien werden standardmäßig verschlüsselt abgelegt und haben als Dateinamen einen Hashwert. Sobald ein Order "voll" ist wird automatisch der nächste Ordner angelegt.
Abb. 3: DAOS Repository mit Notes Large Objects
Eine einmal angelegte Datei im Repository wird nie wieder verändert. IBM empfiehlt die Antivirenprüfung für das DAOS Verzeichnis zu deaktivieren. Die Virenprüfung von Attachments sollte schon im Vorfeld erfolgen, zum Beispiel durch den Lotus Protector oder einen anderen Service. Gerade bei aktivierter Verschlüsselung macht eine Virenprüfung noch weniger Sinn.
DAOS für Datenbanken aktivieren
Neben der Aktivierung im Serverdokument unter dem DAOS-Reiter müssen auch die Datenbanken, die vom Domino Attachment and Object Service erfasst werden sollen, für den Service aktiviert werden.
Nur Datenbanken mit on-disk structure (ODS) 51 (ab Version 8.5) oder höher können von DAOS bearbeitet werden. Standardmäßig werden Datenbanken mit dem Domino Server der Version 8.5 aber auf ODS 43, also der älteren Version, erzeugt. Hier empfiehlt es sich im Konfigurationsdokument des Servers den notes.ini Parameter "CREATE_R85_DATABASES=1" zu setzen. Dieser sorgt dafür, dass bei einem compact -c die Datenbanken in 8.5 auf ODS 51 angelegt werden.
Damit die Datenbank durch DAOS erfasst wird, kann man entweder in den Datenbankeigenschaften den Haken "Domino Attachment and Object Service verwenden" setzen (siehe Abb. 4) oder alternativ dem ohnehin im Anschluss nötigen compact den Parameter "-daos on" mitgeben, wie im folgendem Beispiel:
load compact -c -daos on mail\admin.nsf
Durch den Parameter -c wird eine Komprimierung der Datenbank mit Hilfe einer neuen Instanz der Datenbank erzeugt. In Verbindung mit dem notes.ini Parameter CREATE_R85_DATABASES=1 wird diese neue Instanz als ODS51 erzeugt und ist somit DAOS-fähig. Schlussendlich wird durch das DAOS Flag DAOS innerhalb der Datenbank aktiviert und die Attachments werden gemäß den Vorgaben im Serverdokument extrahiert und in das DAOS Repository abgelegt.
Um gleich noch weiteren Platz in der Datenbank einzusparen, kann man in den Datenbankeigenschaften noch weitere Optionen setzen. Die LZ1-Komprimierung für Anhänge erfasst ebenfalls die Anhänge, welche durch DAOS nicht erfasst werden. Die Komprimierung der Datenbankgestaltung und Dokumentendaten spart ein weiteres an Speicherplatz ein.
Abb. 4: Datenbankeigenschaften für aktiviertes DAOS
Solltet ihr die ersten beiden Teile der DAOS Reihe verpasst haben, findet ihr Sie hier:
DAOS - die Rettung eures Speicherplatzes! Teil 1: Allgemeines
DAOS - die Rettung eures Speicherplatzes! Teil 2: Planung und Vorbereitung
Andernfalls machen wir in den nächsten Tagen weiter mit dem Thema "Pflege von DAOS mit Hilfe des DAOS Managers" im 4. Teil von "DAOS - die Rettung eures Speicherplatzes!"
Und weiter geht es mit unserer Reihe zum Thema Domino Attachment and Object Service. Falls ihr den ersten Teil verpasst haben solltet: DAOS - die Rettung eures Speicherplatzes! Teil 1: Allgemeines
In diesem Teil geht es darum, welche Voraussetzungen ihr für die Aktivierung von DAOS vorbereiten müsst:
Wie ihr DAOS anschließend richtig konfiguriert und aktiviert erfahrt ihr im nächsten Teil der DAOS-Reihe.
Plattenspeicher zur Verfügung stellen
Zur Aktivierung von DAOS muss im Vorfeld ausreichender Speicherplatz zur Verfügung gestellt werden. Dabei kann man den DAOS Estimator zur vorab Bewertung zu Rate ziehen.
Hier könnt ihr den DAOS Estimator bequem herunterladen.
Mit Hilfe des DAOS Estimators erhält man eine Analyse des gewählten IBM Domino Servers. Diese zeigt anschaulich die zu erwartenden Einsparpotentiale und gibt Referenzwerte für den benötigten Plattenspeicher für das DAOS Repository. Den DAOS Estimator sollte man nach Möglichkeit in schwach frequentierten Zeiten, bzw. angekündigten Downtimes laufen lassen. Während unserer Analyse auf verschiedenen Servern führte der DAOS Estimator leider wiederholt zum Absturz der Server. Hier ist also Vorsicht geboten! Die Daten sind im Anschluss aber absolut verlässlich und eine gute Hilfe in der weiteren Planung.
Abbildung 1: Ausschnitt der Analyse des DAOS Estimators
Wie in der Abbildung zu erkennenm ist liegt bei aktuellem Datenbestand die geschätzte Größe des DAOS Directory bei 361.5 GB (Extrapolated Size of DAOS dir). Eine einzurichtende DAOS Partition sollte also vorerst mit ca. 500 GB ausreichend dimensioniert sein.
Der Umzug eines DAOS Directorys auf eine größere Partition funktioniert im übrigen einwandfrei und kann auch während des Livebetriebs sehr weit vorbereitet werden. Eine Downtime von ca. 5 Minuten wird zur anschließenden Aktivierung eines neuen DAOS Repository Pfads benötigt.
Transaktionsprotokollierung aktivieren
Der DAO-Service setzt aktivierte Transaktionsprotokollierung voraus. Diese kann im Serverdokument unter dem Reiter "Transaktionsprotokollierung" aktiviert werden. Für DAOS reicht die umlaufende Protokollierung vollkommen aus.
Abb 2: Die Aktivierung und Konfiguration der Transaktionsprotokolle im Serverdokument
IBM empfiehlt eindringlich das Verzeichnis für Transaktionsprotokolle auf einer vom Domino-Data unabhängigen Partition zu legen. Nach Konfiguration der Transaktionsprotokollierung im Serverdokument sollte das entsprechende Verzeichnis im Dateisystem angelegt werden. Nach einem Restart des Domino Servers sollten in der notes.ini die Konfigurationseinstellungen für die Transaktionsprotokollierung vorhanden sein. Nun muss noch der gesamte Windows Server neu gestartet werden, damit die Transaktionsprotokolle angelegt werden.
Mehr zu Transaktionsprotokollen findet man auch in diesem IBM Best Practice Artikel.
Jetzt könnten wir mit der eigentlich Konfiguration von DAOS beginnen - das machen wir aber erst im nächsten Teil: DAOS - die Rettung eures Speicherplatzes! Teil 3: Konfiguration und Aktivierung
Diese Funktion des IBM Domino Servers ist zwar schon ein bisschen älter, kommt aber offensichtlich nicht aus der Mode - wie man an den vielen Anfragen unserer Kunden in der letzten Zeit sehen kann.
Der IBM® Lotus® Domino® Server verwendet den Domino Attachment and Object Service (DAOS), um erheblichen Speicherplatz auf Dateiebene zu sparen, indem Daten, die als identisch / doppelt / redundant erkannt wurden, von Datenbanken (Anwendungen) auf dem gleichen Server gemeinsam genutzt werden. In Datenbanken, die DAOS verwenden, speichert Domino keine separate und vollständige Kopie eines redundanten Anhangs mehr. Stattdessen speichert der Server eine Referenz zu doppelten Anhängen (eine sogenannte NLO-Datei) in einem internen Repository und verweist aus mehreren Dokumenten in einer oder mehreren Datenbanken eines Domino Servers auf die gleiche Datei.
So lassen sich Szenarien, wie die folgende vermeiden: Wenn eine angehängte Datei groß ist und eine Nachricht, die diese Datei enthält, an eine Vielzahl von Benutzern gesendet wird, könnte das Erstellen einer separaten Kopie der Nachricht für jeden Empfänger mehrere Gigabyte Festplattenplatz belegen. Mehrere Kopien des gleichen Anhangs werden oftmals in Mail-Threads mit mehreren Antworten erzeugt. Durch das Aktivieren von DAOS wird die Plattenplatzbenutzung erheblich reduziert. (Quelle: IBM Lotus Domino and Notes Information Center)
Abb. 1: Vorher-Nachher-Vergleich auf Basis einer DAOS Aktivierung auf einem Server bei einem Kunden von uns.
DAOS wird je Server aktiviert und beeinflusst nicht den Betrieb weiterer Server in einer Domino Umgebung. So kann DAOS zum Testen auf einem Cluster Member aktiviert werden, ohne die Konfiguration der weiteren Cluster Member ändern zu müssen. Weiterhin kann mit DAOS die effektive Datenbankgröße gerade dann drastisch gesenkt werden, wenn die maximale unterstützte Größe von 64 GB erreicht wird (Vgl. TN #21093509). So sind theoretisch fast unbegrenzt große Datenbanken möglich.
Für die Aktivierung von DAOS benötigt man die Domino Server Version 8.5 oder höher mit aktivierter Transaktionsprotokollierung und ohne konfigurierte gemeinsame Mail. Systemseitig setzt DAOS eine Anpassung des Datensicherungskonzepts und eine Anpassung am Antiviren Programm voraus.
Sind diese Anforderungen erfüllt kann DAOS auf dem Server aktiviert werden und die redundanten Anhänge werden nach und nach ins Repository überführt. Damit auch Bestandsdaten ins DAOS überführt werden können, müssen die Datenbanken während der Komprimierung offline genommen werden. Ein vorhandener Cluster sollte dies ohne spürbare Konsequenzen für die Nutzer ermöglichen.
Die Aktivierung von DAOS setzt einen Neustart des Domino Servers voraus.
In den nächsten Tagen gibt es dann den zweiten Teil des DAOS-Reihe: DAOS - die Rettung eures Speicherplatzes! Teil 2: Planung und Vorbereitung
In der letzten Woche meldete ein Kunde ein Problem mit einem seiner IBM Domino Server. Nach einem Neustart erfolgte im Sekunden Takt immer folgende Meldung:
Abb. 1: Zensierter Auszug aus dem Serverlog
Der Domino Server wiederholte diese Meldungen über einen Zeitraum von mehreren Stunden bis er schlussendlich abstürzte.
Der Kunde bat uns nun um eine Problemlösung und eine Erläuterung, worauf dieses Verhalten zurückzuführen sei.
Kurz zur Umgebung: der Server ist auf der Notes und Domino Version 8.5, Shared Mail ist deaktiviert, DAOS (Domino attachment and object service) ist aktiviert.
Shared Mail war ein Feature, das zu den Ursprüngen von DAOS gerechnet werden kann. Mit Hilfe von Shared Mail konnten Attachments von E-Mails über verschiedene Postfächer geteilt werden und somit Speicherplatz eingespart werden. Mit der heutigen Domino Version wird dieses Feature nicht mehr weiter unterstützt, ersatzweise wurde die bessere DAOS Technik implementiert. Soviel zur Historie von "Gemeinsame Mail".
Die Kunst bei Shared Mail liegt vor allem in dessen Deaktivierung. Ist der Shared Mail Object Storage nämlich einmal gelöscht ist dies nicht mehr so einfach möglich.
Um das Feature ordnungsgemäß zu deaktivieren, muss man alle Postfächer, welche diese Technik mit nutzen, sozusagen "unlinken". Dies erfolgt mittels dreier Konsolen Befehle (Vgl. IBM Technote)
Load Object collect -force <mail>
<Mail> ist dabei der Ordner, in welchem die Postfächer liegen, bzw. kann auch eine explizite Datei sein.
Load Object Unlink <shared_directory>
<shared_directory> ist dabei der Ordner, welcher im Serverdokument unter dem Reiter "Gemeinsame Mail" konfiguriert ist.
Abb. 2: Serverdokument, Reiter "Gemeinsame Mail", an den gelb markierten Stellen stehen ggf. die konfigurierten Ordner.
Load Object Unlink <mail>
<Mail> ist dabei der Ordner, in welchem die Postfächer liegen, bzw. kann auch eine explizite Datei sein.
Nachdem diese Befehle abgearbeitet sind, kann Shared Mail im Konfigurationsdokument des IBM Domino Server deaktiviert werden.
Deaktiviert man so das "Gemeinsame Mail" Feature, wird man zukünftig nie wieder damit belästigt und kann ganz in Ruhe weiterarbeiten. Tut man dies hingegen nicht, indem man zum Beispiel nur im Serverdokument die Einstellung entfernt und ggf. sogar noch den Shared Mail Storage löscht, kann man zukünftig an die Probleme geraten, die wir nun beim Kunden zu lösen hatten.
Fakt war, dass der Shared Mail Storage nicht mehr vorhanden war. Somit brachte die von IBM empfohlene Vorgehensweise keine Erfolge, schließlich gab es keine Tickets im Object Store welche zurück in das Postfach migriert hätten werden können. In Absprache mit dem Kunden haben wir nicht versucht die Daten aus alten Sicherungen wieder herzustellen, sondern sind auf seinen Wunsch das Thema radikaler angegangen. Alle E-Mails, welche noch Verweise auf den ObjectStore enthielten, sollten restlos gelöscht werden.
Die Frage bestand nun darin wie man entsprechende E-Mails identifizieren kann. IBM liefert die Antwort (Vgl. IBM Technote).
E-Mails, welche Gebrauch vom Shared Mail Object Store machen, haben ein Feld mit dem Namen "$ObjectStoreSize".
Abb. 3: Dokumenten Eigenschaften, Feld "$ObjectStoreSize" identifiziert betroffene Dokumente.
Also wurde ein Agent programmiert, welcher alle entsprechenden Dokumente in den Datenbanken löscht. Anschließend wurde der "unlink"-Befehl auf die Datenbank ausgeführt. Beim nächsten Neustart waren die Fehlermeldungen verschwunden.
Abb. 4: Unlink Object Store vom Postfach, es mussten keine Notes mehr verarbeitet werden.
Gerade Features wie DAOS oder auch Shared Mail sollten nicht ohne tiefer gehende Kenntnisse deaktiviert oder gar nach der Deaktivierung ihrer Stores/Repositorys einfach gelöscht werden. Dadurch entstehen an den Datenbanken und dem Datenbestand ggf. irreparable oder nur mit immensem Aufwand zu behebende Schäden.
Da DAOS deaktiviertes Shared Mail als Voraussetzung hat, passiert gerade dies aber in letzter Zeit sicherlich in der ein oder anderen Domino Umgebung recht schnell. Sprecht uns lieber an, wir helfen gerne mit unserem KnowHow und stehen euch bei der Deaktivierung, Rekonfiguration und auch Wiederherstellung tatkräftig zur Seite!
Es häufen sich die Meldungen von Kunden, die Probleme mit BackupExec bei der Sicherung von Domino-Servern haben, bei denen DAOS aktiviert ist. Offenbar bekommt BackupExec vom Domino-Server keine oder nicht schnell genug die Liste der vorhandenen NLO-Dateien mit den jeweiligen Referenzen ausgeliefert.
Das führt dann zu entsprechenden Fehlern:
V-79-57344-39569
Final error: 0xE0009A91 – The Lotus Domino server failed to specify the NLO files that one or more Lotus Domino databases refer to.
Symantec nennt verschiedene Möglichkeiten, das zu beheben:
Mit Notes / Domino 8.5.1 wurde fr DAOS das sogenannte \”Remote Cloning\” eingefhrt. Dieses bedeutet, dass Dateianhnge unmittelbar durch Platzhalter (Tickets) ersetzt werden, wenn der Dateianhang bereits im DAOS Store vorhanden ist.
Bei entsprechender Konfiguration kann dieses bei mobilen Benutzern zu einer erheblichen Leistungssteigerung weitergeleiteter oder beantworteter EMails (mit groen oder vielen Dateianhngen) beitragen.
Hierzu sind folgende Voraussetzungen zu gewhrleisten:
1. Verwendung von Notes / Domino 8.5.1
2. DAOS auf Serverseite aktiviert
3. DAOS fr \”Mail.box\” des Servers und Mailfiles aktiviert
4. \”Mail.box\” des Clients verwendet ODS 51
Zum ausprobieren/verifizieren ist im Offline-Modus eine Mail mit (einem oder mehreren Dateianhngen) aus einer lokalen Replik weiterzuleiten und nach umschalten an den Server zu bertragen. Wenn die lokale \”Mail.box\” die ODS 51 hat, wird der Dateianhang NICHT physikalisch bertragen (\”Remote cloning\” – geht schnell und kostengnstig). Hat die lokale \”Mail.box\” nicht die aktuelle ODS, muss der Dateianhang physikalisch bertragen werden.
Damit die lokale \”Mail.box\” des Clients die ODS51 erhlt, ist der Notes.ini der entsprechende Parameter
CREATE_R85_DATABASES=1
hinzuzufgen und ggf. die schon bestehende \”Mail.box\” (sofern sie leer ist) zu lschen.
Um allen Clients diesen Notes.ini Parameter hinzuzufgen kann bei Neuinstallationen ein angepasstes Installationspaket verwendet werden oder eine Desktoprichtlinie fr neue und bestehende Client-Installationen eingesetzt werden.
Ausprobieren: Der Konfigurationsaufwand ist gering und das Ergebnis berzeugend!
CREATE_R85_DATABASES=1
CREATE_R85_DATABASES=1
CREATE_R85_DATABASES=1
Fr alle Administratoren, die sich immer noch nicht an DAOS herantrauen, mag eine Update-Schulung oder mindestens das Durcharbeiten eine Beitrags im IBM Learning Wiki hilfreich sein. Hier ist ein dafr hilfreiches Einstiegsdokument zu finden –> DAOS for Notes and Domino 8.5
Viel Spa beim Lesen!
