Serverdimensionierung 2016

[Günther Rupitz]

Hallo

Unsere Dominoserver sind hardwaremäßig in die Jahre gekommen und müssen ersetzt werden.

Den letzten Forumseintrag zu dem Thema habe ich aus dem Jahr 2005 gefunden, die letzte Doku von IBM aus 2006. Gibt es hier denn nichts aktuelleres?

Des weiteren kann ich mich an ein Best Practice bezüglich der Konfiguration des Storages erinnern (also welche Verzeichnisse auf eigenen RAID Kanal), das finde ich leider nicht mehr.

Danke Günther

[Pfefferminz-T]

Eine sehr gute Darstellung und Beschreibung des Idealfalls:

http://www.wissel.net/blog/d6plinks/SHWL-7RB3P5

Ausgehend von der optimalen Konfiguration dann auf eure Bedürfnisse abspecken.

Ich kenne sehr viele unterschiedliche Umgebungen bei Kunden, virtualisiert/nicht virtualisiert auf allen möglichen Plattformen. Eine grundsätzliche Empfehlung ist schwierig, zwei Unternehmen mit derselben Anzahl an Anwendern können sich in Ihren Anforderungen und Arbeitsweisen komplett unterscheiden.

[Günther Rupitz]

Ich kenne sehr viele unterschiedliche Umgebungen bei Kunden, virtualisiert/nicht virtualisiert auf allen möglichen Plattformen. Eine grundsätzliche Empfehlung ist schwierig, zwei Unternehmen mit derselben Anzahl an Anwendern können sich in Ihren Anforderungen und Arbeitsweisen komplett unterscheiden.

Genau diese Grafik habe ich für die Aufteilung des Storage gesucht, danke.

Was die Dimensionierung angeht wäre halt eine Richtlinie für Mail-Only Server was folgende Parameter angeht super:

- CPU
- Speicher
- Storage-Geschwindigkeit (IOPs?)

Apps haben wir auf eine eigene Maschine ausgelagert.

Günther

[Pfefferminz-T]

Offiziell gibt es Sizings von der IBM Techline, die aber sehr sehr vorsichtig gemacht sind... bedeutet das empfohlene ist das absolute Highend. Sizings gibt es sonst halt im Rahmen von Projekten vom jeweiligen Dienstleister. Neben den rein technischen Punkten muss man ja auch die zukünftige Entwicklung im Auge behalten, das Verhältnis heavy/midweight/light user, nur Notes oder auch iNotes, Traveler und Co... alles Dinge, die in einem vernünftigen Sizing einbezogen werden.

[schroederk]

Was CPU und Speicher betrifft... Wird der zukünftige Server denn echtes Blech oder virtualisiert?
Wenn virtualisiert, dann kannst Du doch auch recht überschaubar anfangen, z.B. 4 Kerne und 8GB Ram.
Wenn es dann nicht ausreicht, ist doch sehr schnell was dazugebaut.
Habt ihr denn bisher noch keinen Server gehabt, an dem ihr euch orientieren könnt?

Was die Storage-Geschwindigkeit an geht, haben wir unsere Virtualisierung in einem einzigen großen Storage.
Da gabs bei uns keine Auswahl bezüglich IOPs 

[Günther Rupitz]

Wir können insofern nicht ganz auf der bisherigen Infrastruktur aufbauen, da wir und dazu entschlossen haben
unsere bisher dezentral organisierten Domino Server in einem Standort zusammenzufassen und dort einen Cluster betreiben wollen.

Bisher haben alle in den Maildatenbanken am Server gearbeitet, in Zukunft wollen wir flächendeckend ManagedReplica aktivieren, das sollte den Server ja grundsätzlich entlasten.

Derzeitiger Plan ist es den primären Clusterserver als Blech und den sekundären als VM zu betreiben.

Die Berechnung des Backupservers ist ja relativ einfach, da muss ich nur das Speichervolumen kennen und die weitere Entwicklung abschätzen, Kopfzerbrechen bereitet mir die primäre Maschine, hier sprechen wir von ca. 600 Benutzern und 7TB Mail-Rohdaten.

Günther

[heini_schwammerl]

32 GB RAM (+), soviel Enterprise SSD wie finanzierbar, bei Webzugriff 4 Gigabit NIC's und als CPU ein Xeon E5-2640 v4 (oder besser).  Wenn es die Lizensierung zulässt kann man auch auf 2 oder mehr Sockel hochgehen, bringt aber nach meiner Erfahrung nicht viel da Disk I/O unter Domino sehr oft ein limitierender Faktor ist.

Ansonsten kann man leider mit den Angaben nur wenig anfangen da z.B. nicht ersichtlich ist wie viele Nutzer am Hauptstandort sitzen, wie die Anbindung der Außenstellen erfolgt (Bandbreite, Latenz), wie sich die Nutzungszeiten verteilen und welches Betriebssystem verwendet wird. Auch ist prinzipiell nicht nur das Gesamt Mailvolumen entscheidend sondern die Größe der einzelnen Mailboxen und ob z.B. Volltextindizes erlaubt sind.

Wenn Ihr plant auch mit Outlook Clients zu arbeiten wäre da noch eine zu betreibende DB2 Instanz. Dieser Task verträgt sich bisher nicht mit dem Notes Traveler Server und in der Theorie wäre da auch noch eine Sametime Instanz für den kostenfreien Chat (welche nur mit einem 32 Bit Domino läuft) sowie die "geschenkten" IBM Connections Lizenzen (welche man natürlich auch einfach in die Ecke legen kann).

Außerdem soll es ja immer noch Installationen geben welche den Viren- und Spamschutz auf dem Domino Mailserver betreiben was zusätzliche Ressourcen benötigt (und als Dank auch nicht immer stabil läuft).

Und dann wäre da noch IBM Verse welches ja angeblich noch dieses Jahr erscheinen soll.

Ich persönlich habe mit dem ein Mailserver für Alle nicht immer gute Erfahrungen gemacht (sobald es über eine bestimmte Anzahl an Nutzern hinaus ging). Die Server werden exorbitant teuer, die Performance in der Regel trotzdem nicht besser und der eingesparte Administrationsaufwand geht teilweise wieder verloren weil man Wartungsintervalle noch besser planen muss. Aber man hat zumindest die Komplexität der IT Systeme etwas verringert.

Ein reiner Mailserver kommt aber meiner Erfahrung nach mit moderner Hardware gut zurecht wenn man mal davon absieht dass manche Vorgänge (z.B. die Aktualisierung des Volltextindex) in manchen Situationen gefühlt immer zu langsam sind (weil man ungeduldig ist).

[eknori]

gut auf den Punkt gebracht

Wir haben seinerzeit gute Erfahrungen mit Blades gemacht. Aber das ist auch schon gut und gerne 6-7 jahre her.

Und dann wäre da noch IBM Verse welches ja angeblich noch dieses Jahr erscheinen soll.

 

[Günther Rupitz]

Hallo

Danke für die bisherigen Rückmeldungen.

Die offenen Fragen:

- Es sind reine Mailserver, alle Applikation/Traveler sind auf einen eigenen Server ausgelagert
- Die Größe der Maildatenbanken ist sehr unterschiedlich, geht aber im Extremfall > 10GB, wir schlagen wo es geht Archive vor, sind hier aber nicht immer restriktiv.
- Volltextindizes gibt es für jede Maildatenbank da wir die Anzahl an Webusern erhöhen wollen
- Managed Replica soll flächendeckend ausgerollt werden, daher ist der Standort des Benutzers hier jetzt nicht das grosse Thema
- OS: Windows
- Viren: nur auf OS-Ebene, aber Notes Dateien sind hier ausgenommen
- Outlook Client - hier warte ich mal die Entwicklung der nächsten Monate ab
- Verse: schau ma mal

Wir präferieren derzeit die zentrale Servervariante um Komplexität beim runderhum rauszunehmen. So haben wir nicht in jedem Mini-Standort ein Highend Backup das Notes-fähig ist. Und Lösungen mit Scripts bedürfen immer manuelle Kontrolle.
Des weiteren hatten wir immer wieder Probleme mit Traveler/Webmail von entfernten Servern wenn die Bandbreite/Latenz nicht optimal war. Ich weiss, das lässt sich zentralen Repliken lösen, erhöht aber wieder die Komplexität und muss manuell gewartet werden.

Günther

[heini_schwammerl]

- Volltextindizes gibt es für jede Maildatenbank da wir die Anzahl an Webusern erhöhen wollen
- Managed Replica soll flächendeckend ausgerollt werden, daher ist der Standort des Benutzers hier jetzt nicht das grosse Thema

Das widerspricht sich meiner Meinung nach ein wenig.
Der Standort spielt insofern eine Rolle dass wenn diese sowieso langsam angebunden sind man auf dem Server etwas mehr Luft hat. Ansonsten hatte ich ja schon geschrieben dass man, was RAM und CPU betrifft, nicht übermäßig hohe Anforderungen hat. Der Domino Server selbst kommt mit ein paar Gigabyte aus, der Rest wird dann zum cachen des Dateisystems verwendet. Das ist meiner Meinung nach eher bei Applikationsservern interessant.
 
Was die CPU betrifft. Ich würde den CPU Takt über die Anzahl der Kerne stellen, also lieber "nur" 6 echte Kerne mit ordentlich Bumms als viele Kerne mit z.B. 2 GHz Grundtakt. Da Intel momentan im Serverbereich keine echte Konkurrenz hat sind die Preise aber teilweise sehr gewöhnungsbedürftig.

Eine zweite CPU ist natürlich auch nett aber meiner Erfahrung nach muss man dann den Domino Server partitionieren (also mit 2 Instanzen fahren). Das würde sich etwas mit Deinem Wunsch beissen die Komplexität zu verringern.
Gruß

Henning

[byte]

Ein nicht unbedeutender Aspekt spielt auch folgende Rolle: Aufbau der Plattenstapel

Denkt daran,  Domino schreibt keine großen Dateiblöcke, somit sollte  der IO  nicht  darauf ausgelegt werden, große Dateiblöcke zu  schreiben sondern viele kleinere  ...

Es gibt Helden,  die bauen aus einer großen Netapp -   aggregierte LUNS und pflanzen dort einzelne VMDK Files drauf und erwarten eine hohe IO, da die Netapp ja viel  "bumms" hat.

Wenn die Absicht besteht, DAOS zu verwenden, wird sich das bitterlich rächen...

Auch gibt es Spezialisten, die hauen auf 2 aggregierte Luns, Mail & App Server in selbiger Form und wundern sich  über eine "low" IO

Crystal Benchmark ist ein tolles Tool, allerdings sollte man  dann  beim Durchsatz richtig testen nicht auf "große " Dateien einstellen.

Am Ende heisst es dann wie immer :   "Domino ist schuld"

weiterhelfende Links :

http://blog.nashcom.de/nashcomblog.nsf/dx/domino-with-netapp-storage.htm

http://www.netapp.com/us/media/tr-3917.pdf

[Tannibal]

@byte: Versteh deine Aussage nicht ganz. Wo gehört es denn hin wenn man VMware+NetApp verwendet? Es gibt ja nur die Möglichkeit per NFS oder iSCSI Lun? (bzw MS iSCSI..)
Oder geht es dir um die Trennung auf Aggregat-Ebene?

[byte]

@byte: Versteh deine Aussage nicht ganz. Wo gehört es denn hin wenn man VMware+NetApp verwendet? Es gibt ja nur die Möglichkeit per NFS oder iSCSI Lun? (bzw MS iSCSI..)
Oder geht es dir um die Trennung auf Aggregat-Ebene?

Aggregierung  und dann Einbindung der erschaffenen Volumes  an das Ziel Systems der VM INSTANZ (VM / ESX ) per  ISCSI /FCP 
(jedoch nicht als VMDK File auf dem angebundenen  Volume des VM Ware Servers / ESX , welches erschaffen wurde -  so  wie es vielerorts praktiziert wird.)

In dem genannten VM "Best Practice" Dokument steht es auch ganz klar definiert.,

https://www-10.lotus.com/ldd/dominowiki.nsf/dx/daos-best-practices -  Punkt 3.. low cost drives...

Volltextindex  sollte man  auf SSD Volumes legen .. das ist effizienter...

Siehe auch: http://www.netapp.com/us/media/tr-3588.pdf

[Tannibal]

Domino Partitionen haben wir über Microsoft iSCSI eingebunden. Bei anderen Systemen wollen wir eigentlich davon wegkommen. (existieren noch wegen der damaligen 400gb Grenze)
Raw Device Mapping gäbe es auch noch, aber damit haben wir keine Erfahrung.

Ich habe mal wieder CrystalDisk ausgeführt mit der kleinsten Einstellung. Hier war der ESX-iSCSI-Datastore etwas schneller. Liegt evtl am vmware-cache? und der Tatsache, dass der Adapter nur 1gbit hat.