Festplattenkonfiguration für Transaktion logging und DAOS

[TimDom]

Hallo zusammen,

derzeit habe ich hier eine für mich grosse Knobelaufgabe.  
Und zwar geht es um die Hardwareausstattung für einen neuen Dominoserver und dessen Konfiguration, was die Platten angeht.
Also, Ziel sollte es sein, einen Domino unter Linux mit Transaction Logging und DAOS zu implementieren.
Dafür wird ein Server mit einem Raid Controller bereitgestellt und max. 10 Platten können in den Rechner rein.

Nun stellt sich die Frage, wie man hier am sinnigsten Raids baut.
Als Idee hatte ich mal 2 Platten zu einem Raid 1 zu bauen, wo dann Linux und die Binaries vom Domino drauf liegt.
Dann ein paar Platten als Raid 5, wo die eigentlichen Dominodaten (also das Notes-data des Servers) liegt.
Die gleiche Anzahl der Platten wollte ich noch mal als Raid 5 bauen und da das Transaction Logging und die Daten fürs DAOS.
Ach ja. Eine Platte als Hot spare wird auch noch konfiguriert, wenn mein Plan aufgeht.

Allerdings hab ich eben mal ein BestPractice für Transaction logging gelesen, wo davon geredt wird, dass die Platten da besser als Raid 1 verbunden sein sollen.

Irgendwie stehe ich da momentan mit ein paar Fragezeichen davor.  

Hat dazu jemand eine Empfehlung, wie man den Rechner am besten konfiguriert?

[ra.t]

Hallo...,
für wieviel Anwender soll denn der Server sein ?
Wenn du ein schnelles System brauchst dann überleg mal für den Server ein gespiegeltes RAID 0 und eine Extraplatte für das Transaktionslogging.
Du kannst es ja testen, indem du ca. 100000 kleine Dateien hin und her kopierst.
Danach installier alles auf RAID 5. Mißt du keinen Unterschied, dann kannst du es ja so lassen.

Mit der ersten Konfiguration habe ich immer schnellere Server gehabt.
Du kannst ja auch nur das DATA Verzeichnis in ein RAID 5 packen und den Rest auf RAID 0, das geht auch gut.
Also viele Möglichkeiten.
mfg
ralf

[TimDom]

Hi,
da sollen so in etwa 500 User drauf. Tendenz steigend
Kommt ja auch noch die Frage, wieviel Platz ich pro Mailfile erlaube.
Machen wir keine Quota, dann geht das wohl ins Unendliche.
1GByte ist da momentan im Gespräch.

Tjo, viele Möglichkeiten. Ist richtig. Darum frag ich ja nach Erfahrungen 

[TimDom]

Ach ja. Das eigentliche Ziel sollte natürlich das absolut realistische sein:

Viel Platz, 100% Sicher gegen Ausfälle und super schnell. 

[koehlerbv]

Und was macht Ihr mit den Mails, die wegen der 1 Gig-Grenze raus müssen? Welchen Bestimmungen unterliegt Ihr da?

Bernhard

[TimDom]

Naja, die gehen dann wohl direkt an den Absender zurück.
Und der User kann nicht mehr senden. Klingt doof, ist aber halt so.

Ist halt eine interne Regulierung, wo es (zunächst) mal nicht viel dran zu drehen gibt.
Wenn das nicht währe, wären 2 stellige KByte Grössen fast die Regel.
Und das geht nun mal gar nicht.

[koehlerbv]

Nein, ich meine die Mails, die die Anwender bei Erreichen einer Grenze löschen müssen.

Bernhard

PS: Die "2-stelligen KByte-Grössen" finde ich niedlich. Habt Ihr Commodore C-64 mit Notes zum laufen gebracht?

[eknori]

Kommt ja auch noch die Frage, wieviel Platz ich pro Mailfile erlaube.
Machen wir keine Quota, dann geht das wohl ins Unendliche. Sad
1GByte ist da momentan im Gespräch.

Das hängt auch davon ab, wie eure Einstellun im Abschnitt Transactional Logging an der Stelle Quota enforcement: aussehen.
Je nachdem bezieht sich dann die Quoata auf die PHYSIKALISCHE Grösse oder die LOGISCHE Grösse.
Bei der lögischen grösse werden die ausgelagerten Attachments beim Quota mit berücksichtigt. Da kann dann je nach Userverhalten schnell die Grenze erreicht werden.
Bei der physikalischen Grösse kann die resultierende (logische)  Datenbank mitunter leicht mehrere 10 GB erreichen, bovor die Quota die 1GB überschreitet.

Was das TL angeht, so würde ich die Logfiles immer auf eine einzelne Platte legen, die über eigen eigenen Controller gesteuert wird. RAID 5 an der Stelle , nein. Das sind einfach zu viele Schreib-Operationen. Da stört RAID5 nur.

[TimDom]

Nein, ich meine die mails, die die Anwender bei Erreiche ner Grenze löschen müssen.

Bernhard

PS: Die "2-stelligen KByte-Grössen" finde ich niedlich. Habt Ihr Commodore C-64 mit Notes zum laufen gebracht?

Ach so. Na da gibt's keine Bestimmung. Da geht's nach dem Motto "Schau mal unter 'All Dokuments'" sortiere nach Grösse und archiviere die Mails/Anhänge, welche am grössten sind und auch ins Archiv können aus inhaltlicher Sicht. Also nicht mehr oft genutzt werden.

Kb. Hoppala. Naja, Ein bisschen Spass muss sein  
Dabei liegt doch das G nicht in unmittelbarer Nähe vom K.

So im Ganzen scheint das ja ein nicht ganz triviales Thema zu sein.

Aber wichtig scheint dann wohl zu sein, das TL auf ne separate Platte bestenfalls mit einem eigenen Controller.
Und wie schaut das mit dem DAOS und dem Plattenverhältnis zu Platz für die Mailfiles aus?
Gibt's da irgendwelche Statistiken, wie das Verhältnis ausehen könne?
Aber ist ja sehr von den Usern bzw des Mailverhaltens ab.

[eknori]

Gibt's da irgendwelche Statistiken, wie das Verhältnis ausehen könne?

Nein, da gibt es nicht wirklich was.Man kann auch nicht pauschal sagen 1:10 (Mail/DAOS)
Das hängt massgeblich vom Userverhalte, der Anzahl und den Grössen der Attachments und der Anzahl der Dupikate ab. In jedem Fall ist DAOS aber ein Gewinn.

[TimDom]

Okay. Das hab ich mir schon mal gedacht. Also mal den DAOS Estimator angeschmissen und schauen.

Und Thema TL?

Wir gross sollte die Platte sein, wenn wir mal annehmen 500 User mit max. 1GByte Mailfile?

[eknori]

Auch das hängt ein bisschen von deiner Backupstrategie ab. Inkementelles Backup mit Restoremöglichkeit im Minutentakt?
Wenn man das so paranoid aufziehen will, dann sollte die Platte schon eine gewisse Grösse haben.
Ich bin mit meinen max 4GB rollierendes TL auf einer 15k drehenden Platte immer sehr gut gefahren.

[TimDom]

Da schneidest Du ja mal direkt das nächste gute Thema an. 

Backup. Was muss denn bei einem solchen Server (Mailfiles, TL und DAOS) gesichert werden?
Bislang sichern wir einfach die NSF's weg und das wars.
Nur in Sachen TL und DAOS noch keine Erfahrung bzw. BestPractices gefunden. 

[eknori]

Backup. Was muss denn bei einem solchen Server (Mailfiles, TL und DAOS) gesichert werden?

Genau das ...

[Pyewacket]

Wir hatten einen (Applikations) Server testweise auf archiving translog umgestellt und innerhalb weniger Stunden war das 50 GB Laufwerk voll. Gibt es eine Möglichkeit zu ermitteln wieviele GB der Server je Stunde/Tag/Woche ins Translog schreibt damit zusätzlich notwendiger Plattenplatz und Backup-Kapazität geplant werden können?

Peter

[stoeps]

Perfekt wäre das: http://www.wissel.net/blog/d6plinks/SHWL-7RB3P5

[TimDom]

Jetzt werde ich doch noch mehr Off-Topic.

Mal angenommen das System läuft jetzt wunderbar mit TL und DAOS und es wird auch alles o.a. gesichert.
Wie stelle ich mich denn an, wenn jetzt a) ein User sein komplettes Mailfile gelöscht hat oder b) er ich eine oder mehrere Mails von einem bestimmten Datum zurücksichern will?

Normalerweise könnte man ja das Mailfile von irgendwann zurücksichern und gut ist. Aber bei DAOS liegen ja die Attachments nicht im Postfach. Wie stelle ich mich dazu an?

Und bei TL? Wie kann ich da quasi minutengenau wiederherstellen?

[stoeps]

Wie stelle ich mich denn an, wenn jetzt a) ein User sein komplettes Mailfile gelöscht hat oder b) er ich eine oder mehrere Mails von einem bestimmten Datum zurücksichern will?

Normalerweise könnte man ja das Mailfile von irgendwann zurücksichern und gut ist. Aber bei DAOS liegen ja die Attachments nicht im Postfach. Wie stelle ich mich dazu an?

Und bei TL? Wie kann ich da quasi minutengenau wiederherstellen?

Zu 1) http://bit.ly/z0DSPu

Treffer 1&2

Zu 2) mit der entsprechenden Backup Software mit Domino TL Unterstützung

[(h)uMan]

Perfekt wäre das: http://www.wissel.net/blog/d6plinks/SHWL-7RB3P5

Wir haben unsere neuen Domino-Server HD-technisch fast analog so ausgestattet.

Nur die Raid1 für ViewRebuild und TransLog laufen über einen Controller.

Die Blockgrößen für die logische Volumes haben wir entsprechend den IBM Performance-Guides gesetzt.

Und wenn wir auf eine DAOS- und 64bit-fähige Backup-Software gewechselt haben, werden wir sogar DAOS aktivieren :-)