Migration IBM Domino to Exchange 2016 Postfachgröße

[NorbertFe 2.035]

Das dürfte eine Frage der Anforderungen sein..

Stimmt, fällt mir nur schwer doppelte Parity und dreifache Datenhaltung sinnvoll in Einklang zu bringen. ;)

 

Es war auch etwas vereinfacht von uns und RAID6 nur ein Beispiel.

Weiß ich doch. :)

 

Bei uns wird derzeit nur RAID-DP eingesetzt da die Platten alle in Netapps stecken und die Server Plattenlos sind. Wenn die Platten noch größer werden müsen wir vermutlich auf dreifache Parität umsteigen.

Ich kenne das, nur stellt sich im Fall von mehrfach redundanten Daten irgendwann die Frage, warum man dann eben alles auch noch auf so teuren Storage packen will/muss.

 

Die Anforderungen ergeben sich hier aus Verfügbarkeit und Geschwindigkeit.

Naja, oder daraus, dass man halt so ein Storage schon da hat und dann irgendwann nicht mehr "umbauen" will/kann. ;)

 

 

Bye

Norbert

[zahni 554]

Neben dem komprimieren der Notes Datenbanken hat man meist in größeren Umgebungen auch gerne die NTF, die Schablone für die Notes Datenbanken, zentral abgelegt und in der NSF nur einen Zeiger auf NTF angelegt. Zumindest hatten wir das in der Umgebung so gemacht, die ich damals betreut hatte.

Bei Notes steckt alles in einzelnen "Notes"-Datenbanken. Das Design und  die  Funktionalitäten wird von Vorlagen (NTF) übernommen. Die sind zwar verknüpft  werden aber komplett in die Zieldatenbanken übernommen.

Vorteil: Wer es kann, kann das Design anpassen, damit die  NTF aktualisieren und per Designer-Task auf aller verknüpften NSF-DBs  ausgerollt.

 

BTW:  Netapp Mit Raid-DP und Flash Pools sind cool ;).

 

@Nils:  Bei uns hätte man sich nur an Ausschreibungen beteiligen müssen ;) .

[Sunny61 806]

Bei Notes steckt alles in einzelnen "Notes"-Datenbanken. Das Design und  die  Funktionalitäten wird von Vorlagen (NTF) übernommen. Die sind zwar verknüpft  werden aber komplett in die Zieldatenbanken übernommen.

Ich kenne das so: In jeder NSF steckt die NTF komplett, mit irgendeinem Task konnte man die NTF entfernen und nur das Design übernehmen. Dadurch reduzierte sich die Größe einer frisch erzeugten NSF um 90%.

 

Vorteil: Wer es kann, kann das Design anpassen, damit die  NTF aktualisieren und per Designer-Task auf aller verknüpften NSF-DBs  ausgerollt.

Genau das hatten wir damals auch gemacht und so ~90% Platz auf dem Server eingespart.

[NorbertFe 2.035]

640KB sind schließlich genug :D

[zahni 554]

Ich kenne das so: In jeder NSF steckt die NTF komplett, mit irgendeinem Task konnte man die NTF entfernen und nur das Design übernehmen. Dadurch reduzierte sich die Größe einer frisch erzeugten NSF um 90%.

 

 

Ok, will ich nicht ausschließen. Mit den vielen Versionen gab es hier  bestimmt auch Änderungen.

 

Ich hatte mal mit Domino zu tun, als Microsoft noch nicht wusste, wozu das Internet gut ist und auch keinen Exchange hatte ;) . Teilweise hatte ich da Nachrichtenübermittlung mittels (ISDN)-Modem eingerichtet.

[gelöscht 0]

Es hat mich nur ein bisschen interessiert was diesen enormen Größenunterschied ausmacht. :)

 

Bzw. warum er doch so enorm ausfällt. Ich hatte selbst damit gerechnet das es größer wird. Aber nicht so groß. ;)

Also eine akademische Frage die so viel bringt wie: meine Birne is aber nicht so rund wie dein Apfel, warum?

 

ASR

[magheinz 110]

Stimmt, fällt mir nur schwer doppelte Parity und dreifache Datenhaltung sinnvoll in Einklang zu bringen. ;)

 

Weiß ich doch. :)

 

Ich kenne das, nur stellt sich im Fall von mehrfach redundanten Daten irgendwann die Frage, warum man dann eben alles auch noch auf so teuren Storage packen will/muss.

 

Naja, oder daraus, dass man halt so ein Storage schon da hat und dann irgendwann nicht mehr "umbauen" will/kann. ;)

 

 

Bye

Norbert

Die doppelte Parity kommt auf Grund der Anforderungen an den Storage welcher zentral ist. Doppelt weil ein rebuild bei heutigen Plattengrößen länger dauert als das man sich auf eine Parity verlassen möchte.

Die drei DAG-Knoten kommen aus der Anforderung an den Dienst: zwei laufen im Primärsystem und der dritte im DR-System.

Fällt das primäre Bladecenter aus läuft der dritte, der auch die CAS-Rolle hat weiter. Dank der doppelten Parity im Storage auch mit der verlangten Verfügbarkeit. Man verzichtet dann bis zum Ersatz des primären Bladecenters halt auf Updates welche einen reboot des Exchangeserver verlangen.

Die zentrale Storage ist halt da, lokaler Strorage auf Servern passt nicht mehr ins Konzept. Im Cisco UCS-Bladecenter ist die Hardware durch Software definiert. lokaler Storage schränkt da unsinnigerweise ein. Deswegen auch boot-from-lun. Somit kann ein Blade ausgetauscht werden ohne das irgendetwas umkonfiguriert werden muss. Policy vom defekten Blade trennen, Blade raus, neues rein, policy dran hängen.

Bis auf die Seriennummer ist kein Unterschied zu merken. MACs, UUIDs,m Luns etc werden übernommen.

[NorbertFe 2.035]

Sag ich doch. Weils halt da ist. Nicht Weils für Exchange sinnvoll wäre. Exchange ist in so einem Szenario meist nur etwas was zwar jeder will und braucht, aber inzwischen eigentlich sinnvoller entkoppelt vom zentralen Storage zu betreiben. Macht halt kaum jemand, weil Mans halt hat. ;)

[magheinz 110]

Moin,

 

dann solltet ihr darüber noch mal nachdenken. Exchange mit Netapp-DP oder gar TP ist Perlen vor die Säue. Den teuren Speicherplatz kann man besser für Systeme verwenden, die das brauchen, weil sie nicht wie Exchange selbst bessere Mechanismen für "Verfügbarkeit und Geschwindigkeit" haben.

 

Wenn Geld keine Rolle spielt, kann man das natürlich machen. Dann hätte ich gern mal einen Termin bei euch. :D

 

Gruß, Nils

Was heißt Geld spielt keine Rolle? Die netapp kauft man per Rahmenvertrag. Damit steht der Storageanbieter fest. Für Server gilt das gleiche. Ein Kauf an den Rahmenverträgen ist nicht erlaubt.

Man könnte jetzt zu kleineren Geräten des gleichen Herstellers greifen, muss dann aber auch unter Umständen die Admins neu schulen.

Diese Perlen können also durchaus berechtigt sein da man nicht nur die reinen Anschaffungskosten sehen darf.

Ein Verzicht auf Rahmenverträge verlagert die Kosten von der IT in den Einkauf und bringt viele Probleme mit sich. Man ist recht schnell bei europaweiten Ausschreibungen. Da gewinnt  man auch nichts.

 

Geld spielt durchaus eine Rolle, doch die Optionen sind in manchen Umfeldern einfach eingeschränkt.

Sag ich doch. Weils halt da ist. Nicht Weils für Exchange sinnvoll wäre. Exchange ist in so einem Szenario meist nur etwas was zwar jeder will und braucht, aber inzwischen eigentlich sinnvoller entkoppelt vom zentralen Storage zu betreiben. Macht halt kaum jemand, weil Mans halt hat. ;)

Alles andere ist im Gesamtbild halt auch unwirtschaftlich.

Laut MS kann man ab drei Knoten ja auch auf Backup verzichten. Macht das irgendwer wirklich?

bearbeitet 2. Dezember 2017 von magheinz

[NorbertFe 2.035]

Sagen Rahmenvertragsinhaber oft. ;) ich glaub’s dir doch. Mir sind Kunden auch lieber, bei denen man nicht um jede Technik und jeden Euro noch 10 Runden drehen muss.

bearbeitet 2. Dezember 2017 von NorbertFe

[magheinz 110]

Vergaberecht halt...

Das hat nicht immer mit Verstand und Logik zu tun, erklärt aber teilweise sogar solche Sachen wie Konzerthäuser und Flughäfen...

[NilsK 2.937]

Moin,

 

ja, deshalb sind vertriebliche Termine bei solchen Kunden ja auch begehrt. :D

 

Gruß, Nils