nsf und nlo Dateien auf neue Platten umziehen: DAOS "sieht" kopierte nlo's nicht

[Jörg P.]

Moin,

wir haben noch einen Domino 9.0.1 mit inzwischen FP9 als Archiv Server laufen. Dieser "wächst und gedeiht"   , daher soll der Server neue, größere und schnellere Festplatten bekommen. Vor allem schneller, da sich die zuletzt bereit gestellten als zu langsam erwiesen (ist ja nur ein Archiv... ).

Eigentlich nicht schwer... Platten dranhängen, Data und DAOS Verzeichnis kopieren, Volume umhängen, fertig. Nun sind die alten Platten aber so langsam und die Datenmenge so groß (diverse TB), das das Kopieren mehrere Tage dauert. Die nlo's wurden bereits im laufenden Betrieb kopiert. Die nsf's sollten übertragen werden, wenn der Server aus ist, was dann eine sehr, sehr lange Downtime bedeuten würde.

Um das zu vermeiden war die Idee, einen 2. Archivserver zu installieren (wurde als Partitionierter Server auf der vorhanden Plattform hinzugefügt) und diesem Server die nlo's ins DAOS Verzeichnis zu kopieren. Anschliessend sollten Repliken der Archiv-DBs vom alten auf diesem neuen Server erstellt werden. Die Downtime für das finale Umschalten von alt auf neu sollte sich so auf ein minimum reduzieren.

Funkioniert soweit auch. Allerdings werden für die Repliken auf dem neuen Server neue nlo's erstellt. Die vorhandenen nlo Dateien werden offenbar vom DAOS nicht gesehen. Ein resync und resync force halfen nicht. Die Verschlüsselung der nlo's ist auf beiden Seiten deaktiviert.

Kann dem DAOS auf dem 2. Domino Server beigebracht werden, die "untergeschobenen" nlo's zu nutzen? Vielleicht indem die daoscat.nsf und daos.cfg einfach von Server 1 zu Server 2 kopiert werden? Leider sind die Pfade zum Data und DAOS Verzeichnis nicht gleich, falls das eine Rolle spielt.

Gruß
Jörg

[eknori]

Frage: habt ihr die NLO Verschlüsselung aktiv?
Wenn ja, dann kann der 2. Server die NLO nicht "sehen", weil sie mit der ID des ersten Servers verschlüsselt sind. Das Kopieren könnt ihr euch daher komplett sparen.

sorry, wer lesen kann ...

[eknori]

Der einfachste Weg ist wirklich, neue repliken anzulegen und DAOS die Arbeit machen zu lassen, als irgedwelche Stunts zu versuchen.

[Captain_Future]

Hallo Jörg,

zudem holt Server 1 beim Replizieren aus DAOS das Attachment und schiebt es mit auf Server 2, wenn dieser DAOS aktiviert hat, erstellt er ein eigenes NLO und katalogisiert es in den DAOS Catalog.
Die kopierten NLOs interessieren Server 2 nicht, weil nicht im DAOS Catalog und in den Dokumenten keine Referenz auf diese NLOs vorhanden, sondern nur auf die selbst erstellten NLOs.
Hinzu kommt, wie Ulrich bemerkt hat, wenn die NLO Verschlüsselung aktiv ist, kann Server 2 die NLOs sowieso nicht lesen, da diese mit der ID von Server 1 verschlüsselt sind.
Ein Kopieren des DAOS Katalogs bringt nichts, außer Du ziehst wirklich den Server 1:1 auf ein neues Blech, also Referenzen auf die Attachments in den Dokumenten und die Server-ID bleiben identisch.

Ergo nix kopieren, lass den Server 2 einfach sein eigenes DAOS aufbauen. Wenn alles durchrepliziert ist, kannst Du den 2. Server dann zum offiziellen Archiv-Server machen und den ersten deaktivieren.

Gruß
CF

[Jörg P.]

Danke schon mal für eure Antworten.

Ich habe noch Hoffnung, das das ganze doch so funktioniert wie gedacht. Ich hatte ganz übersehen, das ich nach dem "tell daosmgr resync force" keine weitere Replik auf dem 2. Server neu erstellt hatte.

Das habe ich eben probiert und mir auf beiden Servern die nlo's zu dieser DB angeschaut. Sieht gut aus, aber das teste ich noch weiter aus. Würde halt viel Zeit sparen.

Ich berichte...

[Pfefferminz-T]

Ich habe dazu schon robocopy mit der mirror-Option und entsprechend vielen Tasks verwendet. Im laufenden Betrieb abends das Kopieren auf die neue Hardware angestossen und dann am Tag x noch einen letzten Abgleich bei beendetem Server durchgeführt. Voraussetzung für das Kopieren bei verschlüsselten NLOs ist natürlich, das dieselbe ServerID auf der neuen HW verwendet wird.

[eknori]

Ehrlich gesagt erscheint mir das Alles ein wenig wirr und planlos.

OK , Verschlüsselung ist aus.
Dann dürften aber auch keine  neuen NLO produziert werden, weil der Hashwert ja gleich ist. Werden sie doch produziert, dann ist entweder

a) ein Teil der kopierten NLO doch verschlüsselt,
b) der Schwellwert anders
c) die NLO auf dem Sourcesystem nicht vorhanden

In jedem Fall ist dann das Zielsystem "strubbelig"; irgendwann rächt  sich das.

Und ob das vorherige Kopieren + Replizieren + Rumrätseln + Nacharbeit schneller ist als ein sauberes Replizieren der Datenbanken lasse ich mal dahingestellt. Solange keine Vergleichsmessung gemacht wurde ist das Glaskugellesen.

[Pfefferminz-T]

Yep, Kopieren auf OS-Ebene macht nur Sinn, wenn ihr alle Dateien, NLOs, FTI, Data-Verzeichnis etc. auch auf diesem Weg transferiert. Ansonsten den vorgesehenen Domino-Weg über Replikation.