Speicherung von VMs in VSphere

[m0ep]

Hi,

Ich habe mir zur Aufgabe gesetzt für das nächste Jahr unsere Hypervisor Hardware zu erstzen.

aktuell betreiben wir 5 HP DL360 Gen9 (3 für interne VMs und 2 für Gateways und DMZ Maschinen)

die internen VMs werden auf 2 verschiedenen Rackstations von Synology (eingebunden über ISCSI) abgelegt.

die Mschinen auf den anderen 2 ESXI liegen auf einem seperaten Speicher via ISCSI.

jetzt meine eigentliche Fragen :

1. Wie löst ihr das ? legt ihr eure maschinen lieber lokal auf den Hosts ab ? (geplant sind für die Zukunft Supermicro Epic Server) weil diese ggf. deutlich bessere Performance bieten würden mit SAS SSDs im Raid.
aktuell wäre ein Ausfall eines Hosts nicht wild, man könnte der VM einfach neu Computing Resourcen zuweisen über Vsphere und weiter gehts.
wenn mir allerdings eine der Rackstations ausfällt laufen auch viele der VMs nicht mehr. Außerdem könnte ich bei lokaler Speicherung und dem Ausfall des Hosts die VM immer noch aus der Replikation wiederholen.

2. aktuell sind die HP Server nur mit 10G angebunden, ich bin aber mit der Performance nicht ganz glücklich und würde zuküftig gerne auf 25G umstellen, macht das Sinn ?

Danke schon mal im Vorraus.

 

[underclocker2k4]

Schonmal über vSAN nachgedacht?
Dann bringen die Hosts selber den Storage mit.
Bei einem kleinen Aufbau würde man ggf. auf ein RAID1 gehen und hätte dann gespiegelt über alle Hosts den Storage dann quasi wieder lokal.

Die Repli wird vom vSAN selber gemacht. Fällt also ein Host aus, macht das vCenter den Rest selber.

PFTT und SFTT sind dann Diskussionen, wo man jetzt tiefer einsteigen muss. Sprich also, gibt es 2 Standorte und Co.
Nachteil beim vSAN ist, dass man noch Infrastruktur drumherum braucht, die man so nur bedingt braucht, aber ggf. eh schon hat, je nach Situation.
vSAN kostet natürlich auch Geld, spart am Ende aber das zentrale Storage und man hat einen live sync.

Die Frage ist, was man noch so an Storage im Netzwerk hat, für Fileshare. Vom Prinzip her könnte das auch das vSAN machen, ist ggf. aber nicht besonders kosteneffektiv.

Am Ende läuft das auf den Unterbau des Storages hinaus und was man da für Verfügbarkeiten haben möchte.
Es gibt ja noch grundsätzlich klassisches SAN. Die Frage ist, wie schnell Syno das einen Sync macht. Denn am Ende hast du auch Inkonsistenten, gerade bei DBs eher nicht so geil.
Mit den "richtigen" Systemen passiert das in Echtzeit.

Was den NIC-Speed angeht, würde ich mal prüfen, was denn über die Leitung geht. Es kann auch gut sein, dass der ISCSI Stack auf der Syno da die Faxen macht.

An und für sich würde ich die VMs alle auf einen Cluster/Verbund konsolidieren. Getrennt über VLANs oder auch physisch. Zu brachten gilt, dass ESX maximal 16 10GBE Ports kann.

EDIT:
Aber auch das Storagenetzwerk sollte man sich anschauen. Also Struktur, Switche, MC-LAG und weitere Geschichten.

 

[konfetti]

Hier laufen die 3 ESX-Hosts mit 10G im Storage-Netz, die VMs liegen auf ner MSA1060 - die Anbindung nach außen ist bei den aktuellen Hosts noch 4x 1GB - wird bei den neuen Hosts (so sie denn kommen) auch auf 10G umgesetzt.

Bei meinem vorherigen AG waren die 2 ESX Hosts per SAS an die MSA angebunden - klar, in beiden Fällen ist das Storage der SPOF aber irgend einen Tot stirbt man immer, wenns nicht unendlich ins Geld gehn soll.

über vSAN hatten wir bei meinem vorherigen AG auch mal nachgedacht, aber dann aus Kostengründen verworfen.

 

[m0ep]

Danke für eure Antworten.

Ich werde mir vSAN mal anschauen, vor allem was das kosten soll, evtl. macht das ja Sinn für uns. Ich könnte ja im Fehlerfall immernoch die Maschinen aus der Replikation holen oder ggf. aus dem VM Backup wiederherstellen.
mir ist nur aufgefallen das wenn man Backups auf den Ubuntu Servern einspielt, das z.t. deutlich länger braucht. Als Vergleich dazu habe ich mal welche von den Maschinen lokal auf den Hosts abgelegt, dort sind 4 10K SAS Platten im Raid5 mit ca. 7TB Kapazität drin. Das lief geühlt schneller. Wobei in der schnelleren der beiden Rackstation (FS-4300) ein größerer Raid aus 7,68TB Samsung SSDs läuft.

 

[underclocker2k4]

vSAN macht gerade in kleineren Umgebungen Sinn, da per Socket (<=32C) lizensiert wird, zusätzlich zum vSphere.
Wichtig ist eben, was bei einer BIA in Richtung HA rauskommt.
Wenn einem die HA egal ist, dann kostet vSAN unnötig Geld, wie auch jedes andere SAN.
vSAN tritt nicht gegen eine Syno und Co an, sondern gegen klassische SANs.
vSAN wird dann aber auch sehr teuer, je nach Systemdesign.
Das kommt z.T. auch auf die Einkaufskonditionen für die einzelnen Systeme an. Mal kann sich bei dem einen das und mal beim anderen das andere rechnen, obwohl alles gleich ist, außer eben der Preis.

Bei Trafficbetrachtungen würde ich mir auch immer den Traffic anschauen, sprich die NW-Leitungen, was geht da wann drüber.
Oftmals kann auch Jumboframes ein Problem sein, dann läuft 10GBE auch mal gerne mit der Handbremse.
Da ist dann schon ne einfache SATA SSD schneller.

Wir planen unsere Systeme aktuell mit 50-200TB Netto Kapa.

Falls SAN notwendig sein sollte, auch mal bei Huawei vorbeischauen. Die machen Kampfpreise....

 

[Supaman]

Wenn man das mal abstrahiert, hat man folgende Möglichkeiten:
1) Raid auf dem lokalen Host
2) physisches SAN
3) VMware vSAN

Für was man sich entscheidet, hängt primär davon ab, ob man HA haben muss / haben will und wie immer - was es kosten darf.
Das VMware vSAN findet ich persönlich unangemessen teuer, dafür hat man alles unter einem Dach.

Alternativen:
1 - Proxmox Cluster für virtualisierung + Storage
2 - Proxmox Cluster für vSAN Storage, virtualisierung über VMware
3 - PetaSAN als vSAN Storage, virtualisierung über VMware
4 - Nappit als vSAN Storage, virtualisierung über VMware

 

[Luckysh0t]

Wir haben unsere 8 vSphere Hosts über FC an einem all-flash Dell SC9000 Cluster. Ist aber abgekündigt.

 

[underclocker2k4]

Das VMware vSAN findet ich persönlich unangemessen teuer, dafür hat man alles unter einem Dach.

Um da nochmal einzusteigen. vSAN in der kleinsten Ausbaustufe braucht 3 vSAN Hosts + witness node (irgendeine Gurke, die das kann)
Geht man auf singleSocket Systeme sind das also 3 vSphere+vSAN-Lizenzen.
(hinzu kommt, dass (Nettokapa+25%)*3=Bruttokapa für Storage da sein muss) (hier gib es sogar Konstellationen, dass man lieber noch 30TB Storage kauft, um keinen weiteren Node mit Lizenzen zu füttern)

Wenn man die eh hat, dann kann das eher Sinn machen, als wenn man eher weniger Nodes hat. Will sagen, Nodes wegen vSAN beschaffen ist nur in extremem Ausnahmefällen sinnvoll.
Im Idealfall sind die Systeme mit 32C ausgestattet, falls man die Ressourcen braucht. (WindowsDC wird dann "interessant")

Ansonsten gibt es neben SAN ja auch noch NAS. Die haben dann ggf. Probleme beim HA.
Merke, das steht und fällt mit den Anforderungen, dann kommen Kosten und nicht zu vergessen ist der Support.
vSAN muss man auch beherrschen, wie jedes andere System. Das ist dann aber eben doch was anderes wie ne einfache Syno mit nem iSCSI-mount.

Alles in allem nicht so einfach. Im Idealfall holz man sich nochmal nen Berater ins Haus.

 

[Supaman]

Nach Liste war vSAN inkl. mindestens 1 Jahr Zwangs Support irgendwo um die 5k -6k Euro, und dann braucht man noch die Hardware dazu.
Das finde ich persönlich als "Einstieg" für den VMware HA Cluster bissl happig.

 

[underclocker2k4]

Keine Frage, da bin ich bei dir.
Es gibt, meiner Meinung nach, einen relativ schmalen sweet spot, wo vSAN Sinn machen kann, davor nicht und danach aber auch nicht. (außer irgendwelche großen Erweiterungen, die das voraussetzen)
Letztendlich muss der TE ja bewerten, was er denn überhaupt an Power braucht.
Wenn wir am Ende bei 20k HW sind und dann das nochmal grob nur an hypervisor-Unterbau draufpacken, dann hat man ggf. irgendwas falsch gemacht.
In jedem Fall Sollte man überlegen, ob man nicht die einzelnen Zonen konsolidiert. ESX bietet aufgrund seiner internen Architektur genug Mechanismen um auch kritische Zonen zusammenzuschalten.
Da sind mitunter andere Hypervisor schlechter ausgestattet. Das ist aber eine Frage der Sec in dem use case.

Daher auch der Hinweis oben zu Huawei, wenn es denn HA in der Form sein muss.