DAOS – die Rettung eures Speicherplatzes! Teil 1: Allgemeines

16. September 2013 Posted by Florian Pfeifer

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)

 

SpeichernutzungDAOS.png

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

Wie man einen Default-Server-Task deaktiviert, am Beispiel des UpdAll

13. September 2013 Posted by Florian Pfeifer

Da ich mich derzeit intensiv mit dem in IBM Notes und Domino 9 neu hinzugefügten Servertask Database Maintenance Tool (DBMT) beschäftige, habe ich mich zur Vorbereitung auch mit der Deaktivierung des UpdAll auseinandergesetzt und hier mal eine meiner Meinung nach recht vollständige Lösung zur Deaktivierung eines Default-Server Tasks dokumentiert. Ich denke dem ein oder anderen wird es behilflich sein; zur Vorbereitung der Umstellung auf DBMT ist es zumindest unerlässlich. Auf DBMT werde ich in Kürze in einem weiteren Artikel umfangreich eingehen.

Der UpdAll läuft typischerweise jede Nacht um zwei Uhr und wird durch den Notes-Ini-Parameter ServerTasksAt2 definiert. Zur Deaktivierung des Servertasks solltet ihr

  • diesen Parameter kürzen,
  • entsprechende Programmdokumente auf "Deaktiviert" setzen oder
  • ggf. Konfigurationsdokumente, welche den Parameter aktiv setzen, anpassen.

Ob bei euch ein entsprechender Notes-Ini-Parameter gesetzt ist, wird euch über den Konsolenbefehl show config servertasks* angezeigt.

 

Abb. 1: Mit "show config <Suchbegriff>" werden euch aktuelle Notes-Ini Einstellungen in der Konsole angezeigt.

 

Parameter kürzen:

Wie in Abbildung 1 dargestellt solltet ihr normalerweise einen Eintrag für ServerTasksAt2 mit dem Wert UpdAll in eurer Konsole sehen. Diesen könnt ihr nun entweder via Konsolenbefehl überschreiben oder die notes.ini auf dem Server bearbeiten. Zum Überschreiben via Konsolenbefehl nutzt bitte den set config <variable>=<wert> Befehl. in unserem Fall also set config ServerTasksAt2=.
Sollten bei euch noch andere ServerTasks um 2 Uhr starten, so ergänzt diese wieder entsprechend.

 

Programmdokumente auf "Deaktiviert" setzen:

Alternativ zur ServerTasksAt2 Angabe in der notes.ini kann es auch sein, dass ihr Programmdokumente habt, welche sich um die Ausführung des UpdAll bemühen. Programmdokumente findet ihr im Administrator Client auf dem Reiter Konfiguration und dort in der Kategorie "Server -> Programme".

 

Abb. 2: In der Programmübersicht seht ihr, ob der UpdAll zeitlich getriggert als Programmdokument aufgeführt ist.

 

Solltet ihr ein solches Programmdokument haben, so könnt ihr dies entweder einfach nur deaktivieren oder löschen. Ich präferiere immer die "Deaktivieren" Variante. Bitte achtet darauf, dass Programmdokumente für jeden Server einzeln existieren. Deaktiviert also nur das Programmdokument auf dem Server, auf dem ihr es wirklich deaktivieren wollt.

 

Abb. 3: Programmdokumente können den Status "Aktiviert", "Deaktiviert" oder "Nur beim Serverstart" haben.

 

Konfigurationsdokumente, welche den Parameter aktiv setzen, anpassen

Zu guter Letzt gibt es die Möglichkeit, dass ihr zwar den Notes-Ini-Parameter gelöscht habt, dieser sich aber regelmäßig wieder neu setzt. Das lässt in der Regel darauf schließen, dass ihr ein Konfigurationsdokument für den Server habt und in diesem der Notes-Ini-Parameter gesetzt wird. Konfigurationseinstellungen findet ihr im Administrator Client unter "Konfiguration -> Server -> Konfigurationen".

 

Abb. 4: Eine Übersicht über alle Konfigurationsdokumente und deren Einstellungen findet ihr am schnellsten im Administrator Client.

 

Um das richtige bzw. alle gültigen Konfigurationsdokumente zu finden, müsst ihr Folgendes beachten:

  1. Konfigurationsdokumente können explizit für Server gelten, somit achtet darauf ob in der ersten Spalte euer Servername gelistet ist.
  2. Konfigurationsdokumente können für Servergruppen gelten, somit achtet darauf ob in der ersten Spalte eine Gruppe gelistet ist, welche euren Server beinhaltet.
  3. Konfigurationsdokumente können Global gelten, auf dem Screenshot seht ihr ein * Dokument.


Wie diese Konfigurationsdokumente untereinander hierarchisch stehen habe ich bislang nirgendwo schwarz auf weiß nachlesen können. Ich hoffe, dass die Reihenfolge "Explizit" vor "Gruppe" vor "Global" lautet. Was allerdings passiert, wenn mehrere Servergruppenkonfigurationen vorhanden sind, welche sich gegenseitig widersprechen, will ich gar nicht wissen. Sollte hierzu jemand belastbare Informationen haben, möge er gerne unten einen Kommentar ergänzen. Danke!

Zurück zum Thema: Solltet Ihr nur einen expliziten Eintrag für den Server haben, öffnet diesen und kontrolliert, ob auf dem Reiter "NOTES.INI-Einstellungen" ein ServerTasksAt2-Eintrag vorhanden ist und editiert diesen gegebenenfalls.

 

Abb. 5: Über das Konfigurationsdokument können Notes-Ini-Parameter zentral gesetzt werden.

 

Solltet ihr aber Konfigurationsdokumente haben, welche für mehrere Server oder gar alle Server gelten und nur darin eine entsprechende Einstellung vorfinden, so legt bitte ein Konfigurationsdokument für den expliziten Server an und setzt den Parameter ServerTasksAt2 auf leer bzw. passt diesen an.

Nun sind alle typischen Stellen für einen UpdAll- Invoke kontrolliert und bearbeitet worden. Mir sind aber auch schon Agenten unter gekommen, welche einen Konsolenbefehl schicken. Solltet ihr also an keiner der drei Stellen fündig geworden sein, so schadet ein Blick in das Server Log für die letzten sieben Tage nicht. Sucht hier aktiv nach UpdAll Ausgaben und ggf. findet ihr dadurch einen aufrufenden Agenten.

 

Abb. 6: Im Log findet ihr Ausgaben des UpdAll-Tasks.

 

Schlussendlich könnt ihr euch sehr sicher sein, dass ihr euren ServerTask deaktiviert habt. Wie oben schon angedeutet dient dieser explizite Fall hier zur Vorbereitung des DBMT, welches euch viele Wartungsprobleme abnimmt. Seid also gespannt auf den in Kürze erscheinenden Blog-Eintrag "Wie aktiviert man DBMT und was gilt es dabei zu beachten?".

 

Strg+Alt+Entf in verschiedenen Umgebungen

13. September 2013 Posted by Florian Pfeifer

Nach der kurzen Sommerpause melden wir uns endlich wieder zurück: mit einem kleinen aber feinen Tipp für all diejenigen, die häufiger in VMs oder RDP Sessions unterwegs sind.

Den wichtigsten Klammergriff von Windows kennt inzwischen jeder. Im Laufe der Jahre wurde er auch mit weiteren Funktionen versehen. Mittlerweile kann man nur noch mittels des Klammergriffs sein Kennwort unter Windows ändern und das führt dazu, dass man in alternativen Umgebungen auch die Möglichkeit braucht, den Klammergriff auszulösen.
 
Abb. 1: Strg+Alt+Entf - seit der Einführung von Windows unabdingbar
 
Wie aber löst man das hinter dem Klammergriff liegende Event in einer VM aus? Drückt man hier Strg+Alt+Entf so wird das Event an das eigene Windows durchgereicht, egal ob man in der VM im Vollbildmodus arbeitet oder nicht. Glücklicherweise kommt das Event aber auch in der VM an. Aber ein wenig nervig ist das ja schon. VMware hat den EventListener umgebogen. Drückt man in Windows die Tastenkombinaten mit einem Einf statt einem Entf wird an die VM trotzdem der richtige Klammergriff übermittelt.
 
Abb. 2: Strg+Alt+Einfg hat bei VMs den gleichen Effekt.
 
Zuletzt hing ich in einer RDP Session auf einem fremden Computer, der mich förmlich bedrängte, dass ich doch bitte das Kennwort ändern solle. Dafür müsste ich nur den bekannten Klammergriff machen. Weit gefehlt! Mit "Entf" kam ich nur in die Oberfläche von meinem Windows und mit dem mir bekannten "Einf" aus den VMs kam ich auch nicht weiter. Ein kurzer Blick in die Hilfe gab dann sofort die nötige Unterstützung. Einfach statt "Entf" hier die "Ende"-Taste mitbenutzen.
 
Abb. 3: Strg+Alt+Ende hat bei RDP Sessions den gewünschten Effekt.
 
Sicherlich muss auch der ein oder andere von euch regelmäßig in VMs und/oder RDP Sessions hantieren und vielleicht freut sich der ein oder andere ja über diesen simplen kleinen Hinweis.

 

Shared Mail ablösen

13. September 2013 Posted by Florian Pfeifer

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!

 

Bitte mal eben die Serverkonsole!

13. September 2013 Posted by Florian Pfeifer

Manchmal möchte man sich auf die Schnelle die Serverkonsole seines IBM Domino Servers anschauen können und hat gerade nicht den Administratorclient gestartet und auch nicht ausreichend Zeit, sich auf den Server aufzuschalten. Mit Hilfe einer selbst konfigurierten Symbolleistenaktion kann man Abhilfe schaffen.

Abb. 1: Mit der Remote-Serverkonsole kann man einen beliebigen Server wählen und direkt dessen Log Live verfolgen und auch Kommandos senden.

 

Was ist dafür zu tun?

Ihr müsst einfach in die Vorgaben eures Clients wechseln und den Punkt "Symbolleiste -> Anpassen -> Neu -> Schaltfläche" auswählen.

Abb. 2: In den Vorgaben kann man sich eigene Schaltflächen für die Symbolleiste erstellen.

 

In dem sich nun öffnenden Dialog kann man die Eigenschaften der Schaltfläche genauer spezifizieren. Für die oben abgebildete Remote Admin Console muss man Folgendes einstellen.

Abb. 3: Die Eigenschaften einer Schaltfläche können im Detail eingestellt werden. Auch eigene Icons sind einstellbar.

 

Anschließend wird eure selbst erstellte Schaltfläche automatisch der selektierten Symbolleiste hinzugefügt (vergesst nicht zu speichern).

Abb. 4: Die Aktion ist nun in der Symbolleiste angekommen. Mit speichern übernehmt ihr diese auch dauerhaft.

 

Ich hoffe, dass ich euch damit ab und an ein bisschen Zeit sparen kann.
Bei Fragen rund um die Notes / Domino Administration könnt ihr euch jederzeit gerne bei uns melden!

 

Bei Notes und Domino geht das Erstelldatum gelöschter und wiederhergestellter Dokumente verloren

13. September 2013 Posted by Florian Pfeifer

Das folgende Problemchen habe ich vor kurzem bei einem Kunden bemerkt, als ich eine neue View in einer seiner IBM Notes und Domino Datenbanken erstellt habe:
 
Fragt man mit "@Created" das Erstelldatum eines ehemals gelöschten und anschließend aus dem Papierkorb wiederhergestellten Dokuments ab, so erhält man nicht das ursprüngliche Erstelldatum, sondern das Wiederherstellungsdatum. Das ursprüngliche Erstelldatum ist ab dem Moment der Löschung verloren.
 
Das heißt also für die Anwendungsentwicklung: bei entsprechenden Szenarien berücksichtigen, dass man ein "Computed when composed"-Feld mit anlegt und in diesem das Erstelldatum mit ablegt, zumindest wenn man beabsichtigt, jemals mit dem Datum zu arbeiten UND einen einen "Trash" (Papierkorb) in der Datenbank zu aktivieren.