Kaufberatung: Datenbank Server

[nalrak0n]

Hallo zusammen

Ich muss einen Datenbank Server ablösen.
Dort läuft Redhat drauf und die ERP Software ABAS.
Momentan sind zwei 3GHz Xeon (800FSB) mit 8GB Ram verbaut.
Wenn ich top ausgebe tümpelt der mit grösster langeweile umher.

Nun habe ich die empfehlungen für den neuen Server bekommen.

2x Quad CPU
16GB Ram
Storage ist egal.

Ich finde das einfach einwenig übertrieben... ja klar mehr ist besser aber unnötig Geld möchte ich auch nicht ausgeben.

Es wird zu 90% einen HP DL380 G6.

Kennt jemand von euch das ABAS ERP System?
Danke um jeden Tip wie ich mich entscheiden soll.

 

[P2k1]

Die DL380 G6 sind super.
Nur für eine Anwendung, die scheinbar das "alte" System nicht auslastet, etwas unterfordert.

Ich würde das Geld lieber sparen und dann einen ESX Cluster mit HA aufsetzen und anfangen die ganzen "alten" vorhandenen Maschinen zu virtualisieren. ;-)

Also lieber sparen auf 2 DL380 G6 mit genügend RAM und nen Storage.

 

[heiner.hemken]

Hallo zusammen

Ich muss einen Datenbank Server ablösen.
Dort läuft Redhat drauf und die ERP Software ABAS.
Momentan sind zwei 3GHz Xeon (800FSB) mit 8GB Ram verbaut.
Wenn ich top ausgebe tümpelt der mit grösster langeweile umher.

Nun habe ich die empfehlungen für den neuen Server bekommen.

2x Quad CPU
16GB Ram
Storage ist egal.

Ich finde das einfach einwenig übertrieben... ja klar mehr ist besser aber unnötig Geld möchte ich auch nicht ausgeben.

Es wird zu 90% einen HP DL380 G6.

Kennt jemand von euch das ABAS ERP System?
Danke um jeden Tip wie ich mich entscheiden soll.

Wie gross sollte das Storage denn mindestens sein? Hast Du mal eine Nutzerstatistik vom vorhandenen System gemacht?

 

[Karbe]

Storage ist egal.

Bei vielen DB-Systemen ist genau das der Flaschenhals und nicht CPU/RAM.

Grüße

 

[nalrak0n]

Danke für die zahlreichen Antworten!

mit Storage ist egal bin ich eher auf die Grösse eingegangen.
Wird einmal ein Raid 1 fürs System und für die Daten ein Raid 10. Jeweils SAS 146GB mit 6Gb/s 10k U/min.
Die Auslastung der bestehenden SCSI Disk ist nicht sehr hoch.

Betreff der Virtualisierung....
- Wird erst ein Projekt in den nächsten 18 Monaten

 

[fdsonne]

Ich würde das Geld lieber sparen und dann einen ESX Cluster mit HA aufsetzen und anfangen die ganzen "alten" vorhandenen Maschinen zu virtualisieren. ;-)

Also lieber sparen auf 2 DL380 G6 mit genügend RAM und nen Storage.

Ne also Leute gibts...
Er sucht ne Empfehlung als Ersatz für nen Uralt DB Server der nun wirklich von sogut wie jeder normalen halbwegs brauchbaren Desktop PC Maschine in Sachen Leistung in die Tasche gesteckt wird und der dazu nochnich mal am Limit läuft und du empfiehlst hier nen ESX Cluster wo allein die ESX Lizenzen schon mindestens 4k€ in Beschlag nehmen werden, wenn man wirklich die Advanced oder Enterprise Version mit vollem HA Umfang (VMotion und Co., Loadbalancing usw.) haben will.
Dazu kommt das Storrag für so ein Cluster (FC oder iSCSI) letzteres ist eher Murks in derartigen Umgebungen.
FC Switche usw...
Bei zwei nichmal hochausgebauten Dual Quadcore Servern ala DL380G6 mit kleinen E5540er CPUs und je 24GB Speicher, Storrageworks und 15k SAS Platten, FC Switchen usw. inkl. ESX Lizenzen bist du da bei geschlagenen 20000-30000€...

Und da hast du nur die Basis, keine Softwarelizenzen (außer den ESXen), keine Backup Softwarelösung auf VM Ebene, keine Redundanz der FC Anbindung, keine Redundanz des Plattenstapels, keine Serverhardware für den VCenter Server usw.

 

[MAFRI]

@freunddeslichts..

du darfst nicht vergessen viele hier im luxx kaufen ihre software cracked - damit sie mehr geld für hw ausgeben können....

ich halt davon nix, wenn einem mal 2 oder 3 CALs fehlen okay das nicht so dramatisch da sagt keiner was da heißt es nur bitte nachlizenzieren..

 

[Gohst_oc]

Öhn nur so für meine eigenen Interessen:

Für was zum Henker braucht man ESX? ESXi kann doch auch alles was relevant ist?

Und mit KVM @ Linux hat man ne anscheinend würdige Lösung gegenüber ESX.
Vorallem was Treiber anbelangt.
Obschon es ein Denkfehler sei, die meisten Server supporten ESX(i) perfekt.

Ausserdem, ein Kunde von unserer Firma setzt ABBAS auch ein, die haben das auch auf ner VM.
Viel Leistung wird ja wirklich nicht abverlangt.

 

[nalrak0n]

@ Ghost_oc

Darf ich fragen wie viele User dein Kunde auf dem ABAS Server laufen hat?

@others
Ich glaub das Thema ESX ist hier wirklich fehl am Platz!

Grund für die eröffnung des Threads war es, dass ich die empfehlungen für den DB Server etwas hochgegriffen finde und gerne von den Experten hier die Meinung dazu hören wollte.

 

[MAFRI]

Gott das muss auf Hardware das sind DBs....

 

[nalrak0n]

Das wird es auch werden bzw. bleiben....
würde mich einfach wunder nehmen wie viele User da drüber laufen.

 

[Gohst_oc]

Naja, ich weiss es nicht so recht. Aber mehr als ABAS User 10 sollten es schon sein. Also 10 gleichzeitig.

Sind noch weitere DBs drauf.

Wenn der jetztige Server schon rumidelt, dann ists ja nahezu wurst wie schnell der neue sein wird.

Aber du kannst ja den neuen mit VMs quälen.
So kann man failovers machen, falls mal etwa der Exchange ausfällt.

Oder einen weiteren DC virtualisieren. Ausser Datenabgleich hatt der nix zu tun.

 

[nalrak0n]

Nee da wird noch gar nix virtualisiert! der ERP Server schon gar nicht.
Es geht hier rein um den ERP Server auszutauschen.

Ich habe mal offerieren lassen:

- HP DL380G6, E5530 mit 3x2GB Ram und 2x 146GB SAS + Raid Conti
dazu gibts:
- weiter 3x2GB Ram
- eine 146GB als Spare
- 5x 146GB SAS mit 6Gb/s
- ein zweites NT
natürlich noch das passende Carepack 4h 24x7

Ich denke dass wir mit der Config wirklich mehr als genügend Leistungsreserven haben. Preislich komm ich grad auf ca. 6700CHF ( ~5100€ )

 

[Backbone]

Eingedenk der Tatsache das sich die jetzige Konfig auch langweilt bis du mit dem genannten Schätzchen auf Nr. sicher. Am Preis wäre freilich noch was zu tun.

Backbone

 

[fdsonne]

@freunddeslichts..

du darfst nicht vergessen viele hier im luxx kaufen ihre software cracked - damit sie mehr geld für hw ausgeben können....

ich halt davon nix, wenn einem mal 2 oder 3 CALs fehlen okay das nicht so dramatisch da sagt keiner was da heißt es nur bitte nachlizenzieren..

Neja davon halte ich persönlich erstmal so gar nix... Schon allein deswegen, weil ich als gelernter Anwendungsentwickler meine eigene Softwareentwicklungsarbeit auch entlohnt haben möchte nicht frei im Netz publiziere sofern sich damit was verdienen lässt und dementsprechend ich auch die Arbeit anderer mit einer Entlohnung würdige

@nalrak0n
ansich ist die Zusammenstellung deutlich zu gut dimensioniert.
Aber durchaus OK, wenn man mal in die Zukunft blickt und der Server ggf. auch andere Aufgaben mit übernehmen wird.

Aber mal was anderes, wie wäre es denn anstatt dem DL380 mit nem DL360...
Ausgestattet mit ner zweiten 4er Backplane bekommst dort auch 8 HDDs 2,5" SFF rein.
Platz für nen ordentlichen HP Raidcontroller ist ebenso...

Den 380er als Server zu nehmen würde ich nur dann empfehlen, wenn wirklich mehr als die zwei PCIe Slots in Benutzung sind. Ansonsten kann der nix besser als der 360er


Zu den HDDs, welches Raidlevel willst du denn mit den 6 SAS HDDs fahren?
Für DBs rate ich dringendst von Raidleveln mit Paritätsberechnungen ab
In deinem Fall wohl nicht sonderlich schlimm, weil die Performance sowieso nicht ausgeschöpft wird, aber dennoch...

 

[Daikon]

"Offtopic"

Warum sollte man keinen SQLer virtualisieren? Was spricht dagegen? Wenn man ein entsprechendes SAN mit ordnetlich Spindeln hat, sowie eine ordentliche VM Farm, dann ist auch die Performance vorhanden.

 

[nalrak0n]

@Daikon
haben momentan kein SAN -> hat sich erledigt.

@fdsonne

ansich ist die Zusammenstellung deutlich zu gut dimensioniert.
Aber durchaus OK, wenn man mal in die Zukunft blickt und der Server ggf. auch andere Aufgaben mit übernehmen wird.

Diese Gedanken habe ich mir gemacht.

Aber mal was anderes, wie wäre es denn anstatt dem DL380 mit nem DL360...
Ausgestattet mit ner zweiten 4er Backplane bekommst dort auch 8 HDDs 2,5" SFF rein.
Platz für nen ordentlichen HP Raidcontroller ist ebenso...

Werde mir mal die aktuellen Geräte ansehen.

Zu den HDDs, welches Raidlevel willst du denn mit den 6 SAS HDDs fahren?
Für DBs rate ich dringendst von Raidleveln mit Paritätsberechnungen ab
In deinem Fall wohl nicht sonderlich schlimm, weil die Performance sowieso nicht ausgeschöpft wird, aber dennoch...

die ersten 2 Platten kommen als Raid1 + eine als Spare im schrank
die anderen 4 als Raid 10 + ein Spare im schrank

 

[fdsonne]

"Offtopic"

Warum sollte man keinen SQLer virtualisieren? Was spricht dagegen? Wenn man ein entsprechendes SAN mit ordnetlich Spindeln hat, sowie eine ordentliche VM Farm, dann ist auch die Performance vorhanden.

Es ist einfach mal schnurtz egal wie dick deine Maschinen oder deine Storageanbindung ist. Ein virtulaisierter SQL Server wird immer deutlich langsamer laufen als ein SQLer der physisch auf die Maschine zugreifen kann.
Und genau das ist der Punkt.

Bei anderen Diensten merkt man das idR nicht so stark, aber bei nem DB Server ist der Unterschied schon extrem spürbar.

 

[Backbone]

Warum sollte man keinen SQLer virtualisieren? Was spricht dagegen? Wenn man ein entsprechendes SAN mit ordnetlich Spindeln hat, sowie eine ordentliche VM Farm, dann ist auch die Performance vorhanden.

Es gibt eine ganze Reihe von Gründen warum man das nicht tun sollte. Im Businessbereich sind es jedoch meist zwei:
1. Die Anwendung selbst wird vom Hersteller in virtuellen Umgebungen nicht supported. Wenn was nicht geht, steht man dann ziemlich im Regen. Das kann sich schlicht keiner Leisten, insbesondere wenn es unternehmenskritische Applikationen sind.

Es ist einfach mal schnurtz egal wie dick deine Maschinen oder deine Storageanbindung ist. Ein virtulaisierter SQL Server wird immer deutlich langsamer laufen als ein SQLer der physisch auf die Maschine zugreifen kann.
Und genau das ist der Punkt.

Bei anderen Diensten merkt man das idR nicht so stark, aber bei nem DB Server ist der Unterschied schon extrem spürbar.

Im reinen I/O Bereich sind die Unterschiede da, ja, aber "spürbar" ist eben so eine Sache. Wenn es auch auf die letzten 5% Leistung ankommt, ist Virtualisierung vom Tisch. Auf der anderen Seite kann es eben auch Vorteile bringen einen SQL-Server in eine VM zu heben und das tauscht man dann gegen ein bisschen weniger Leistung. In der Praxis kommt es auf die konkrete Anwendung an. Belastet die die vorhandene Hardware bis an die Grenze und braucht man die maximale Leistung, dann eben nicht. Lasten die Anwendung die Hardware nicht voll aus, hat man von Virtualisierung einige interessante Vorteile über die nachzudenken durchaus lohnt.

Backbone

 

[fdsonne]

Ich hab damals auf Arbeit mal Lastmessugen mit dem SQL 2005 Server von MS druchgeführt. Wir hatten da so ne Anwendung die lief auf nem damals schnöden Pentium 4 mit 3,2GHz als Dualcore, gepaart mit 2 SATA HDDs im Raid 1 fürs OS und 4xSCSI 15k HDDs im Raid10 für die SQL DBs.
Als Gegentest war ein ESX Server bestückt mit zwei 5160er Core2 Xeons und 6 SAS SFF 15k HDDs (auch Raid1+10)
Der virtualisierte Server war deutlich langsamer in der Anwendung als der alte und deutlich Hardwareunterlegenere P4

Auch ist das ganze HDD Management in der virtuellen Umgebung oft DB Server ungeeignet. Schon allein die Blocksize der virtuellen HDDs usw. sind eber auf sequenzielles Schreiben/Lesen hin ausgebaut.
Man könnte natürlich die Disks oder das Array direkt in die VM Mounten, dann würde man den Punkt umgehen, aber damit verliert man leider einige sehr neckische Vorteile im Bezug auf VMs (gerade in Bezahlmich virtuellen Umgebungen ala ESX ohne i)

 

[sashXP]

Grundsätzlich:es wurde entweder noch nicht genant, oder ich habe es überlesen:
welche DB-Server System wird/soll eingesetzt werden?

Oracle Als Beispiel empfiehltz nicht auf ein Raid5 die DBs laufen zu lassen etc.

Weiterhin:
RAM --> STORAGE --> CPU - in dieser Reihenfolge beschleunigt man eine DBS. Storage ist also schon relativ wichtig.

Unter Oracle lässt sich jedes Tabelspace auf eine eigene HDD lagern. Unter MS SQL-Server kann man das Log und Data Verzeichnis trennen und so die Performance erhöhen.

Bei 10 Usern und einem M SSQL/Oracle ist das doch aber alles latte...
Die DB sollte nicht mehr wie 8 GB haben. Da reichen locker!!!! - 12 GB Ram, 2x RAID1 und ein schnieker dual/quadcore - fertig.