KVM Storage Lösung

[Selfy]

Hi Leute,

wir interessieren uns für Möglichkeiten unsere virtuellen KVM Instanzen zukünftig über ein zentrales Storage-System laufen zu lassen. Das Storage sollte ca. 80TB Speicher per Raid5 und 1TB SSD Cache (Raid Controller) bereitstellen. Da für uns der Kostenpunkt entscheidend ist, würden wir dieses System selber bauen und nicht auf fertige Lösungen zurückgreifen wollen. Mit wie viel RAM bzw. welcher CPU sollte so ein Storage mindestens ausgestattet werden. 10Gbit + SAN-Switch ist klar. Habt ihr Erfahrungen mit irgendwelchen Software-Lösungen gemacht, welche auf so einem Storage installiert werden? Haben mal die Firma Nexenta aufgeschnappt. Könnt ihr dazu was sagen?

Die Hostsysteme sollen mit jeweils 256GB RAM und entsprechend starken CPUs ausgestattet werden. Ist es notwendig, dass man die Hostsysteme jeweils mit 10Gbit NICs ausstattet, oder gibt es hier vll. auch günstigere praktikable Lösungen?

Derzeit geht es um fünf Hostsysteme, die Zahl wird sich allerdings in absehbarer Zeit erhöhen.

Ich freue mich auf eure Antworten.

 

[Firewire2002]

In der Größenordnung sollte man sich dann vielleicht schon mal überlegen, ob man das Storage unbedingt selbst bauen muss oder ob man vernünftige Storagelösungen samt Support einkauft.
Und gerade der Support ist im Storagebereich absolutes Gold wert, denn nur die wenigsten können von sich behaupten, die Software und Hardware die sie einsetzen, vollständig debuggen zu können. Wenn es später mal Performancengpässe gibt, stehst du als Storageadmin ziemlich schnell blöd da, wenn du nicht weißt warum die Software IOPS auf den Platten verursacht oder eben x-mal länger braucht um Blöcke zu finden. Der einfache Gedanke "der braucht halt soviel IOPS - also erschlag ich es mit mehr Hardware" kann schnell teurer als vernünftiger Storage-Support werden.

Was soll es denn werden? Block- oder File-Storage? Soll jede KVM Instanz eine eigene iSCSI LUN bekommen, oder wollt ihr ein großes NFS Storage auf dem die Image-Files der KVM Instanzen liegen? Nexenta kann grundsätzlich beides.

Nexenta hat nur ein rießen großes Problem: Die Software sieht per Definition vor, dass sie bei IO Fehlern einen Kernelpanic auslöst. Auch bei Platten, die gar keinem Volume zugewiesen sind, weil man sie vielleicht gerade erst gesteckt hat.
Das Verhalten lässt sich zwar abschalten, ist aber nicht empfehlenswert, ausser einem ist die Datenkonsistenz egal. Denn dann gibts auch keinen Kernelpanic mehr, wenn Nutzdaten von IO Fehlern betroffen sind.

Wenn es reines iSCSI sein soll, könntest du dir mal die HP MSA oder Infortrend Eonstore anschauen.

Bei NFS-Filern wird es schwieriger, ohne direkt in abartige Preisklassen abzudriften. EMC Isilon kann NFS als auch iSCSI, ist ein verdammt stabiles Cluster. Unter 3 Node und einem dicken Geldbeutel geht da allerdings nichts. Support für Software und Hardware ist allerdings erstklassig. Die bieten auch 4 Stunden Hardware-SLA an. Im Zweifel steht der Techniker mit Ersatzteil eher vor Ort als du bemerkt hast, dass etwas kaputt ist. (Habe noch so ein Cluster "rumstehen" )
Die andere Alternative wäre wohl NetApp, die wird dann allerdings nochmal eine Ecke teurer und die Vertriebler verrechnen sich gern mal bei den tatsächlich lieferbaren IOPS. Da sollte man selbst bisschen mitdenken und deren Angebote korrigieren.
Ansonsten halt Selbstbau mit Linux.

Bedenke bitte, dass du dich vielleicht auch nicht von einem einzelnen Storage abhängig machen willst. Jenachdem wie wichtig die KVM Instanzen sind. Bei Selbstbau Lösungen bist du dann entweder bei DRBD Clustern oder Ceph Clustern. Bei den kommerziellen Lösungen wie NetApp oder Isilon sind das dann mindestens 3-5 Nodes (je nach Verfügbarkeitsansprüchen).

Was die Netzanbindung betrifft, so ist 10Gbit Storageseitig Standard. Je nach Anforderung sogar mehr, wobei man das eher über mehrere Nodes in die Breite skaliert und eher seltener mit 10Gbit Trunks pro Node oder 40Gbit NICs arbeitet.

Ram ist stark vom Protokoll und den Cache-Möglichkeiten abhängig. Bei Filern sagt man für gewöhnlich 1GB Ram pro 1TB Storage.

Grundvorraussetzung ist, dass du weißt was die Hostsysteme an IOPS und Datendurchsatz generieren. Erst dann kann man halbwegs sinnvoll ein Storage planen. Das was du bisher geliefert hast reicht da bei weitem nicht aus. Kapazität ist bei einem Storage das geringste Problem.

 

[Thunderbyte]

Bei derartigen Größenordnungen ist Selbstbau m.E. keine Alternative. Wenn ich Dich so verstanden habe, dass Du ein Raid5 (einzelnes Volume?) über 80TB machen willst: schlechte Idee. Beim Rebuild, der Äonen dauern wird, sind die Volumes ungeschützt gegen weiteren Festplattenausfall. Daher entweder in kleinere Einheiten runterbrechen, oder Raid6 mit Hotspare.

Zwischen den sehr teueren Profis und Selbstbaulösung würde m.E. auch noch die RackStation Reihe von Synology liegen, die im Vergleich mit z.B. Netapp pervers günstig ist:

https://www.synology.com/de-de/products/RS3614xs+ (3800€)
Erweiterungseinheit: https://www.synology.com/de-de/products/RX1214 (1050€)

oder deutlich sinnvoller, da auch moderner:

https://www.synology.com/de-de/products/RS18016xs+ (5400€)
mit einer oder mehreren Erweiterungseinheiten:
https://www.synology.com/de-de/products/RX1216sas (2450€)

Alles natürlich mit 6GB WD Red Pro und 2x1TB SSDs (z.B. Samsung 850 Pro). Bei 12x6TB sind das bereits 60TB im SHR-2 (2 Festplattenredundanz). Mit Erweiterungseinheit hat man noch deutlich Platz nach oben und die SSDs können erweiterungseinheitsübergreifend als Cache verwendet werden.

Nebenbei: wie siehts denn mit Backup aus? Raid schützt vor Backup nicht!

 

[Firewire2002]

Sofern iSCSI und nicht NFS zum Einsatz kommen soll, bleibt ja eh nicht viel an Backupvarianten übrig, wenn es Konsistent sein soll.
Die tollen angepriesenen LUN Snapshots der Storageappliances haben ein rießen großes Problem: Sie haben keine Kenntnis von dem Dateisystem da drin und dem Server der es nutzt. Meistens gibt es dann ein Gegenstück für die Serverseite dazu, die als Agent fungiert und vom Storage den Befehl entgegen nimmt, die Caches zu flushen, damit die LUN für einen kurzen Zeitraum definitiv konsistent ist um einen Snapshot zu ziehen.
Wie man bei Synology aber schon so nett sehen kann, gibt es diese Agents nur für eine kleine Auswahl an Betriebssystemen (dort nur VMware ESX und Windows). Mit einem Linux KVM Host hat man da ziemlich die Arschkarte.

Dann heißt es aber wieder selbstbasteln und den ganzen Backup-Job vom Server aus koordinieren. Die Logik also rumdrehen und selbst Caches flushen und danach das Storage anweisen den Snapshot anzulegen. Oder wieder zu den teureren Storagelösungen zu greifen, die zumindest oft auch solche Agents für RHEL und SLES anbieten. Ob andere "kleinere" Distributionen auch funktionieren ist aber eher Glückssache.

Ansonsten bleibt da nur eine Backuplösung aus der KVM Instanz heraus. Da gibts ja die unterschiedlichsten Software-Lösungen dafür.
Dann brauchts nur noch ein Storage wo man die Backups auch ablegen kann.

Damit wären wir also nun schon bei 3 Storages. 2 für den HA-Betrieb und eins für die Backups.

 

[Thunderbyte]

Hm, ich würde auch kein KVM hernehmen. Wie in meiner Antwort zum ersten Post schon angedeutet, ist mir das alles zu "selbstgestrickt".

ESXi ist für Vollvirtualisierung einfach m.E. besser und professioneller, dafür gibt es zahlreiche BackupSWLösungen wie Veeam oder Trilead Explorer. Wenns nur was kleines sein soll, kann man auf den Synologys mittlerweile auch Docker Container betreiben, die vermutlich RAM effizienter sind als KVM. Aus dem Interface heraus kann man diese Docker Container wunderbar exportieren und somit sichern. Der Storage wäre dann quasi schon lokal, iSCSI oder NFS wären unnötig, das Netzwerk als möglicherweise limitierender Faktor auch. Beides geht natürlich trotzdem z.B. mit einem ESXi Server (der dann halt z.B. nur vom USB Stick läuft).