Neuer Cluster "meine Idee"

T. Dreher

Member
Dec 28, 2015
5
0
21
60
Hallo zusammen :)

Wir haben derzeit 3 Server mit VMware im Einsatz, die Ressourcen werden solangsam knapp.

Unser Plan ist nun 2 neue Server anzuschaffen und einen 5 Node-Proxmox-Cluster aufzusetzen.

Nur mal ganz grob, dass man eine Vorstellung hat, die VMs welche darauf laufen sollen sind W2K8S (Active Directory, Exchange, MS-SQL), W2K12S (Fileserver, Remotedesktop), Debian (Oracle, MySQL etc.).

Die Server wären ungefähr gleich, außer die CPU-Cores und der RAM.
Gedacht ist ein Ceph-Cluster, mit erstmal 3x2TB(2.5Zoll) pro Host also insgesamt 15 Platten (15 OSDs).
Den Servern spendieren wir jeweils einen HBA-Adapter für die Ceph-Platten.

Für die Datenbanken hätten wir gerne einen DRBD-Cluster auf einem ZFS Mirror (2x SSD Samsung M.2 PCI-E 960 PRO 1 TB). Diesen allerdings nur auf 3 Nodes.

Das ganze habe ich ähnlich mit 3 Test-Nodes derzeit am laufen.

Was haltet Ihr von der Konfiguration?
Hat jemand schon Erfahrung mit DRBD 9 auf ZFS?

Über kritische Fragen und eine rege Diskussion würde ich mich freuen :)

Vielen Dank und Gruß
TD
 
Sehr ihr noch SSDs für jeden Ceph Knoten als Journal vor? Ohne würde ich das nicht in Betrieb nehmen wollen - viel zu langsam.

Die 960 Pro ist eine Prosumer-Karte und wahrscheinlich ähnlich schlecht für ZFS geeignet als meine 950 Pro die ich mal testweise mit ZFS probiert habe. Die synchronen Schreibvorgänge sind da - sagen wir mal - OK, aber nicht unbedingt für ein hochperformantes ZFS-system geeignet. Warum wollt ihr DRBD auf ZFS laufen lassen? Ist technisch möglich, aber welche Vorteile versprecht ihr euch damit?

Sind die CPUs von der Version her gleich und nur die Cores unterschiedlich oder verschiedene Generationen? Falls es unterschiedliche Generationen sind könnte es Probleme beim Livemigrieren geben (muss aber nicht).

Bzgl Oracle: Interessant, dass ihr das auf Debian fährt. Falls das keine XE ist müsst ihr nur aufpassen, dass ihr named user lizenziert habt, denn virtualisiertes Oracle auf Prozessorlizenzen ist eigentlich unbezahlbar bei der Menge an Prozessoren die ihr dann habt. Für Oracle 12 müsst ihr dann auch mit den maximalen Host-CPUs aufpassen, denn das höchste an Gefühlen ist dann leider Dual-Socket.
 
Hallo erstmal Danke für die Antworten und Fragen :)

SSDs für den Ceph-Journal haben wir nicht vorgesehen, könntest Du eine SSD empfehlen?
Da sind ja auch nicht alle geeignet, ich habe da schon ganz schlechte Erfahrungen gemacht.
Der Cephpool soll eher für normale Dateiablage etc. verwendet werden.

Eigentlich dachten wir, dass die NVMe 960 Pro (http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/ssd960.html) sehr gut für unsere Zwecke geeignet wäre, aber Erfahrung wie Du haben wir da noch keine.
Welche M.2 SSD wären denn geeignet?

DRBD auf ZFS deshalb weil wir gerne zusätzlich Raid1 hätten mit unseren M.2 SSDs, da sind 2 auf einem Adapter.
DRBD dann wegen Ausfallsicherheit, Livemigration und der besseren Performance gegenüber Ceph bei Datenbanken.

Die CPUs sind tatsächlich verschiedene Generationen E5620, E5-2620 und die dann ganz Neuen.

Oracle haben wir die Lizenzvariante "Standard Edition one" als Prozessorlizenz welches es glaube ich gar nicht mehr gibt.
Dies ist eine spezielle Version in Verbindung mit unserer Anwendung 'D'ORG'.
Aber danke für den Hinweis :)

Gruß
TD
 
Hallo erstmal Danke für die Antworten und Fragen :)

SSDs für den Ceph-Journal haben wir nicht vorgesehen, könntest Du eine SSD empfehlen?
Da sind ja auch nicht alle geeignet, ich habe da schon ganz schlechte Erfahrungen gemacht.
Der Cephpool soll eher für normale Dateiablage etc. verwendet werden.

http://www.sebastien-han.fr/blog/20...-if-your-ssd-is-suitable-as-a-journal-device/

Eigentlich dachten wir, dass die NVMe 960 Pro (http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/ssd960.html) sehr gut für unsere Zwecke geeignet wäre, aber Erfahrung wie Du haben wir da noch keine.
Welche M.2 SSD wären denn geeignet?

Zu meiner 950 habe ich auf der o.g. Seite meine Messwerte hinterlassen, diese sind aber Meilenweit weg von den mittlerweile dort veröffentlichten. Ich habe eben den Autor mal angefragt ob er mir die Messwerte geben kann. Meine hat nur maximal 4 MB/sec synchrones schreiben - was schon sehr unterirdisch ist. Ein anderer Kommentator hat jedoch gleich schlechte Ergebnisse.

Die SSD ist eigentlich auch total Quatsch wenn du nicht gerade IB oder 100GBE hast, da du die Schreibraten ja nicht übertragen kannst. In DRBD wird ja synchron geschrieben, d.h. in dem Fall einer NVMe ist der Bottleneck die 10 GBE connection (die du hast oder????).

DRBD auf ZFS deshalb weil wir gerne zusätzlich Raid1 hätten mit unseren M.2 SSDs, da sind 2 auf einem Adapter.
DRBD dann wegen Ausfallsicherheit, Livemigration und der besseren Performance gegenüber Ceph bei Datenbanken.

DRBD is klar, aber ZFS darunter? Warum kein normales, doofes software raid ala mdadm? Wenn ihr keine Features von ZFS verwendet, würde ich es (auch wenn ich totaler ZFS Befürworter bin) nicht einsetzen. Ihr wollt dann jeweils auch DRBD über 3 Rechner machen und somit die identischen Daten 6-fach kopiert haben? (DRBD über 3 * 2 Kopien)?

Die CPUs sind tatsächlich verschiedene Generationen E5620, E5-2620 und die dann ganz Neuen.

Hier vor dem Produktivgehen mal ein paar Tests machen ob das prima migrierbar ist. Ggf. würde ich den Prozessor festschreiben auf was anderes als KVM64, da ihr ggf. Probleme bekommt wenn ihr auf den neuen Maschinen eine VM startet und die auf die alten Prozessoren migriert.

Oracle haben wir die Lizenzvariante "Standard Edition one" als Prozessorlizenz welches es glaube ich gar nicht mehr gibt.
Dies ist eine spezielle Version in Verbindung mit unserer Anwendung 'D'ORG'.
Aber danke für den Hinweis :)

Ja, die gibt es nicht mehr und ihr seid leider mit euren ASFU Prozessorlizenzen natürlich auch an die "normalen" Lizenzbedingungen von Oracle geknüpft, die in virtuellen Umgebungen herrschen (virtuell = Alle Prozessoren im Cluster müssen lizenziert werden). Ich habe noch keinen ASFU-Vertragspartner gesehen der auch nur ansatzweise verstanden hat wie Oracle lizensiert und somit die eigenen Kunden bescheißt, denn die dürfen ja bei einer Lizenzprüfung blechen. Haben die euch auch Oracle unter Debian angedreht?
 
http://www.sebastien-han.fr/blog/20...-if-your-ssd-is-suitable-as-a-journal-device/

Danke für den Link :)

Die SSD ist eigentlich auch total Quatsch wenn du nicht gerade IB oder 100GBE hast, da du die Schreibraten ja nicht übertragen kannst. In DRBD wird ja synchron geschrieben, d.h. in dem Fall einer NVMe ist der Bottleneck die 10 GBE connection (die du hast oder????).

Also hälts Du meine Idee für Quatsch?
Man könnte doch auch Protocol B nehmen?
https://www.drbd.org/en/doc/users-guide-90/s-replication-protocols
Ja 10 GBE haben wir.

Bei Datenbanken kommt es ja nicht unbedingt nur auf die Datenrate an, sondern auf die Zugriffszeiten und I/Os an oder liege ich da ganz falsch?

DRBD is klar, aber ZFS darunter? Warum kein normales, doofes software raid ala mdadm? Wenn ihr keine Features von ZFS verwendet, würde ich es (auch wenn ich totaler ZFS Befürworter bin) nicht einsetzen. Ihr wollt dann jeweils auch DRBD über 3 Rechner machen und somit die identischen Daten 6-fach kopiert haben? (DRBD über 3 * 2 Kopien)?

Danke für den Hinweis, ja mdadm könnte man in dem Fall auch nehmen.
Ich bin ebenfalls ein ZFS Fan, an das dsync Problem der HDs bei ZFS hatte ich nicht gedacht.
Ich habe das Testweise am Laufen und bin mit der Performance eigentlich zufrieden.
Da muss ich wohl nochmals genauer testen.

Ja es sollen dann 3 * 2 Kopien sein.
Das wäre es uns wert, wegen der Ausfallsicherheit (Probleme mit dem Host) und 2-rangig wegen dem Migrieren.
Der Gedanke ist der, wenn eine Platte stirbt passiert erstmal gar nichts und wir können die Platte dann planbar austauschen. Die VM vor dem Plattentausch sogar eventuell auf einen anderen Host migrieren.

Hier vor dem Produktivgehen mal ein paar Tests machen ob das prima migrierbar ist. Ggf. würde ich den Prozessor festschreiben auf was anderes als KVM64, da ihr ggf. Probleme bekommt wenn ihr auf den neuen Maschinen eine VM startet und die auf die alten Prozessoren migriert.

Danke für den Tipp

Ja, die gibt es nicht mehr und ihr seid leider mit euren ASFU Prozessorlizenzen natürlich auch an die "normalen" Lizenzbedingungen von Oracle geknüpft, die in virtuellen Umgebungen herrschen (virtuell = Alle Prozessoren im Cluster müssen lizenziert werden). Ich habe noch keinen ASFU-Vertragspartner gesehen der auch nur ansatzweise verstanden hat wie Oracle lizensiert und somit die eigenen Kunden bescheißt, denn die dürfen ja bei einer Lizenzprüfung blechen. Haben die euch auch Oracle unter Debian angedreht?

Das wusste ich nicht, dass wären dann 10 Prozessoren?!
Der Oracleserver hat doch aber selber nur 1 Core in der VM, das ist unlogisch, aber du weißt es scheinbar besser.
Ich frage da mal bei unserem Partner nach.

Früher lief der Oracleserver tatsächlich auf DEBIAN, mittlerweile aber auf "Oracle Linux".
 
Also hälts Du meine Idee für Quatsch?
Man könnte doch auch Protocol B nehmen?
https://www.drbd.org/en/doc/users-guide-90/s-replication-protocols
Ja 10 GBE haben wir.

Bei Datenbanken kommt es ja nicht unbedingt nur auf die Datenrate an, sondern auf die Zugriffszeiten und I/Os an oder liege ich da ganz falsch?

Vielleicht jammere ich auf hohem Niveau, aber wenn du NVMe verbaust, die mit 2,1 GB/sec schreiben kann, dein DRBD-Interconnect aber nur maximal 1,125 GB/sec liefert ist das nur 50% der Geschwindigkeit. Das finde ich schon krass - da brauchst du ja nicht so ne teure Karte zu kaufen, sondern eine die "langsamer" ist. Inwiefern DRBD mit 3 Knoten multicast verwendet weiß ich nicht, aber ich hoffe es mal sonst halbiert sich die Menge gleich nochmal um 50% auf nur noch 25%.

Lesend ist die NVMe natürlich top (wenn die lokale Kopie verwendet wird).


Danke für den Hinweis, ja mdadm könnte man in dem Fall auch nehmen.
Ich bin ebenfalls ein ZFS Fan, an das dsync Problem der HDs bei ZFS hatte ich nicht gedacht.
Ich habe das Testweise am Laufen und bin mit der Performance eigentlich zufrieden.
Da muss ich wohl nochmals genauer testen.

Gehen tut unter Linux immer alles ... wie sinnvoll oder schnell es ... das ist die Frage. Wenn zu zufrieden bist, verwende es weiter - ich brauch keinen unnötigen Overhead der mir später mal "aufstoßen" könnte (mehr dazu unten)

Ja es sollen dann 3 * 2 Kopien sein.
Das wäre es uns wert, wegen der Ausfallsicherheit (Probleme mit dem Host) und 2-rangig wegen dem Migrieren.
Der Gedanke ist der, wenn eine Platte stirbt passiert erstmal gar nichts und wir können die Platte dann planbar austauschen. Die VM vor dem Plattentausch sogar eventuell auf einen anderen Host migrieren.

In deinem Beispiel können doch 5 Platten ausfallen und es läuft immer noch alles weiter - im worst case halt nur noch lesend mit max. 10 GBE, aber das ist ja noch besser als nichts.

Für das was ihr da an Geld in Prosumer SSDs packt wäre es doch fast schon eine Überlegung wert ein SAN zu kaufen, da habt ihr die ganzen Probleme und Overhead (Ceph, DRBD, mdadm/ZFS) nicht. Ich greife meistens nur noch zu KISS-Hardware. Aufbauen, benutzen gut ist. Ceph würd ich nur ab mind. 5 Servern (ok, habt ihr) verwenden, dann ab 4 Platten zzgl. Journal SSD. Und selbst dann muss das noch nicht schnell sein. Ceph ist auch ne tolle Geschichte, aber eben auch nicht einfach zu warten oder zu verwenden wenn man was in die Hose geht. Bei einem SAN kommt der Fachmann vorbei und schaut, wobei das meistens nur ne Platte reinschieben ist - das kann dann jeder. Shelves sind auch schnell rangehängt und so weiter. Man muss halt wissen wie viel Zeit man da reinstecken will. Zum Spielen ist das super, aber wie schnell wird das ungemütlich wenn mal was nicht funktioniert (angenommen du bist der Einzige der das Ding warten kann). TCO ist hier das "Totschlagargument". Linux ist toll und billig (bis kostenlos), aber wenn keiner da ist, der den Kram administriert ist Windows eben doch viel, viel günstiger.

Ich bin auch für Spielen, Lernen und alles mit freier Software machen, aber ich kann durchaus verstehen, dass man etwas möchte was man anstöpselt und es funktioniert. Wir greifen immer zu Fiberchannel, da es bisher am wenigsten Probleme gemacht und immer schnell war, bisher war jedes SAN mit iSCSI soooo langsam, da wurde immer am falschen Ende gespart. Selbst die günstigsten FC-SAN (also reale Hardware, keine Software-Lösungen) leisten solide Arbeit für oft schon wenig Geld. Dann wird nur noch angestöpselt und gut ist (angenommen man hat keine große fabric).

Das wusste ich nicht, dass wären dann 10 Prozessoren?!
Der Oracleserver hat doch aber selber nur 1 Core in der VM, das ist unlogisch, aber du weißt es scheinbar besser.
Ich frage da mal bei unserem Partner nach.

Was der Partner meint ist eigentlich auch egal, Oracle sagt es definitiv anders und die Prüfen und verlangen dann Geld (Nachzahlung ist immer Listenpreis ab eigentlichem Verkaufsdatum zzgl. Support)

http://docplayer.org/1280456-Oracle-vertriebs-bachelor-business-practice-licensing.html
Seite 77 und 78

Ist leider immer wieder ein leidiges Thema, aber ich kann es auch nicht ändern :-/
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!