VMware und FC-SAN

[Paul Muster]

Tach z'ammen,

hier[tm] steht eine kleine SAN-Infrastuktur verteilt über zwei
Standorte. FC-Switches 1a und 1b und Storage 1 am Standort 1,
FC-Switches 2a und 2b und Storage 2 am Standort 2.

#
[Hosts Standort 1] # [Hosts Standort 2]
| | # | |
[ FC-Switch 1a ]==|====\ [ FC-Switch 2a ] |
| | # \ / | |
| | # X | |
| [ FC-Switch 1b ]===/ \==|==[ FC-Switch 2b ]
| | # | |
| | # | |
[Storage 1] # [Storage 2]
#

Jeder Host hängt jeweils mit einem Link an jedem der beiden örtlichen
Switches. Die Switches hängen am örtlichen Storage und sind mit den
Switches am anderen Standort verschaltet.

Es gibt _keinen_ "SAN-Kopf", der Daten über die Standorte hinweg auf das
jeweils andere Storage spiegelt.

Nun soll ein VMware-Cluster aufgebaut werden, in dem FT und vMotion zur
Verfügung stehen. Damit soll eine vollständige Standortredundanz _auf
VMware-Ebene_ geschaffen werden. (Standortredundanz _auf
Applikationsebene_ in den VMs, z.B. DRDB oder irgendwelche
Datenbank-Clusterlösungen, ist nicht gefragt.)

Wie macht man das nun? "Möchte" man eine 10GE-Verbindung zwischen den
VMware-Hosts schalten und mit vSAN arbeiten? Oder gibt es auch elegante
Varianten, bei denen man darauf verzichten kann? Irgendwie geschickt die
LUNs überkreuz mounten, die Querlinks sind ja da?

Würde mich über Denkanstöße sehr freuen.


Danke & viele Grüße

Paul

[Sven Hartge]

Post by Paul Muster
hier[tm] steht eine kleine SAN-Infrastuktur verteilt über zwei
Standorte. FC-Switches 1a und 1b und Storage 1 am Standort 1,
FC-Switches 2a und 2b und Storage 2 am Standort 2.
#
[Hosts Standort 1] # [Hosts Standort 2]
| | # | |
[ FC-Switch 1a ]==|====\ [ FC-Switch 2a ] |
| | # \ / | |
| | # X | |
| [ FC-Switch 1b ]===/ \==|==[ FC-Switch 2b ]
| | # | |
| | # | |
[Storage 1] # [Storage 2]
#
Jeder Host hängt jeweils mit einem Link an jedem der beiden örtlichen
Switches. Die Switches hängen am örtlichen Storage und sind mit den
Switches am anderen Standort verschaltet.
Es gibt _keinen_ "SAN-Kopf", der Daten über die Standorte hinweg auf das
jeweils andere Storage spiegelt.

Das wäre jetzt nicht unwichtig, wenn man eine wirkliche Redundanz haben
will. Du willst ja bei Ausfall von einem Standort die VMs wieder
automatisch durch die HA am anderen Standort starten können.

Also brauchst du einen Mirror der Daten am jeweils anderen Standort.
NetApp nennt soetwas z.B. (Stretched) MetroCluster.

Soetwas reduziert natürlich deine Gesamtkapazität, da du ja faktisch ein
Netzwerk-RAID1 oben drüber stülpst.

Post by Paul Muster
Nun soll ein VMware-Cluster aufgebaut werden, in dem FT und vMotion
zur Verfügung stehen. Damit soll eine vollständige Standortredundanz
_auf VMware-Ebene_ geschaffen werden. (Standortredundanz _auf
Applikationsebene_ in den VMs, z.B. DRDB oder irgendwelche
Datenbank-Clusterlösungen, ist nicht gefragt.)
Wie macht man das nun? "Möchte" man eine 10GE-Verbindung zwischen den
VMware-Hosts schalten und mit vSAN arbeiten? Oder gibt es auch
elegante Varianten, bei denen man darauf verzichten kann? Irgendwie
geschickt die LUNs überkreuz mounten, die Querlinks sind ja da?
Würde mich über Denkanstöße sehr freuen.

Wie weit sind die beiden Standorte denn voneinander entfernt,
Latenz-technisch gesehen?

Ich habe $hier zwei ESX-Cluster, ein Cluster an zwei Standorten mit
einer NetApp MetroCluster-Lösung für den Storage, die ESX sind in einem
logischen LAN liegend mit 20GBit zwischen den Standorten verbunden, das
FC für den MetroCluster mit 2x 8GBit.

Wobei hier die ESX kein FC sprechen sondern NFS, das FC ist nur für den
internen Verkehr der beiden Köpfe da.

An jedem Standort gibt es je einen Kopf mit je 4 Shelves drunter, wobei
die Hälfte der Platten in jedem Shelf dem Kopf am anderen Standort
"gehört". Somit besteht mein Aggregat in einem Kopf aus zwei Plex mit je
4 Raidgruppen. Diese 2 Aggregate (je eins pro Kopf) sind in je 8
NFS-Volumes aufgeteilt, also 16 NFS-Volumes insgesamt, die jeder ESX
mountet, d.h. auch die ESX am Standort 2 mounten die 8 Volumes vom Kopf
am Standort 1 und umgekehrt.

Im Failover-Fall übernimmt dann der überlebende Kopf die kompletten IPs
und vFiler vom andere Kopf und die Volumes bleiben (mit reduzierter
Bandbreite natürlich) dennoch erhalten.

Der andere Cluster ist ebenso an zwei Standorten aufgebaut, mit 20GBit
im LAN und einem iSCSI-SAN basierend auf HP P4500 als Multisite-Cluster.
Auch hier gibt es eine entsprechende Failover-Mechanik und auch hier
bindet jeder ESX-Server alle Volumes ein, wobei es hier keine feste
Aufteilung der iSCSI-LUNs auf eine feste Seite gibt, das regelt die
SAN/iq-Software von HP intern.

Aber in allen Fällen gibt es eine vorgelagerte Intelligenz zwischen ESX
und Platten, die die Daten verteilt, spiegelt und im Fehlerfall
weiterhin zugänglich macht.

Ich wüßte nicht, wie man das sonst anders sicher, funktional und wartbar
hinbekommen sollte.

Mit der VSAN-Technik von VMware habe ich mich bisher noch nicht näher
befasst, aber den Grob-Überblick, den ich habe sagt mit, dass man damit
auch das Ziel erreichen kann. Allerdings braucht es dann wieder lokale
Platten in deinen ESX-Servern, um dieses hyperkonvergente Setup zu
erreichen.

S°

[Paul Muster]

Post by Sven Hartge

Post by Paul Muster
hier[tm] steht eine kleine SAN-Infrastuktur verteilt über zwei
Standorte. FC-Switches 1a und 1b und Storage 1 am Standort 1,
FC-Switches 2a und 2b und Storage 2 am Standort 2.
#
[Hosts Standort 1] # [Hosts Standort 2]
| | # | |
[ FC-Switch 1a ]==|====\ [ FC-Switch 2a ] |
| | # \ / | |
| | # X | |
| [ FC-Switch 1b ]===/ \==|==[ FC-Switch 2b ]
| | # | |
| | # | |
[Storage 1] # [Storage 2]
#
Jeder Host hängt jeweils mit einem Link an jedem der beiden örtlichen
Switches. Die Switches hängen am örtlichen Storage und sind mit den
Switches am anderen Standort verschaltet.
Es gibt _keinen_ "SAN-Kopf", der Daten über die Standorte hinweg auf das
jeweils andere Storage spiegelt.

Das wäre jetzt nicht unwichtig, wenn man eine wirkliche Redundanz haben
will. Du willst ja bei Ausfall von einem Standort die VMs wieder
automatisch durch die HA am anderen Standort starten können.
Also brauchst du einen Mirror der Daten am jeweils anderen Standort.
NetApp nennt soetwas z.B. (Stretched) MetroCluster.
Soetwas reduziert natürlich deine Gesamtkapazität, da du ja faktisch ein
Netzwerk-RAID1 oben drüber stülpst.

Ja, diese Mirror-Funktion (am besten als Teil des SAN) fehlt. Aber die
wird es nicht geben, ich muss das anders lösen. Klar, dabei geht die
Hälfte der Kapazität verloren, das ist aber vertretbar.

Post by Sven Hartge

Post by Paul Muster
Nun soll ein VMware-Cluster aufgebaut werden, in dem FT und vMotion
zur Verfügung stehen. Damit soll eine vollständige Standortredundanz
_auf VMware-Ebene_ geschaffen werden. (Standortredundanz _auf
Applikationsebene_ in den VMs, z.B. DRDB oder irgendwelche
Datenbank-Clusterlösungen, ist nicht gefragt.)
Wie macht man das nun? "Möchte" man eine 10GE-Verbindung zwischen den
VMware-Hosts schalten und mit vSAN arbeiten? Oder gibt es auch
elegante Varianten, bei denen man darauf verzichten kann? Irgendwie
geschickt die LUNs überkreuz mounten, die Querlinks sind ja da?
Würde mich über Denkanstöße sehr freuen.

Wie weit sind die beiden Standorte denn voneinander entfernt,
Latenz-technisch gesehen?

~8ms, also *sehr* annehmbar. L2-transparent natürlich, sonst wären HA
und FT sowieso nicht sinnvoll machbar.

Post by Sven Hartge
[sehr interessante Ausführungen über andere Infrastrukturen]
Aber in allen Fällen gibt es eine vorgelagerte Intelligenz zwischen ESX
und Platten, die die Daten verteilt, spiegelt und im Fehlerfall
weiterhin zugänglich macht.
Ich wüßte nicht, wie man das sonst anders sicher, funktional und wartbar
hinbekommen sollte.

Wäre es einfach, hätte ich nicht gefragt. ;-)

Post by Sven Hartge
Mit der VSAN-Technik von VMware habe ich mich bisher noch nicht näher
befasst, aber den Grob-Überblick, den ich habe sagt mit, dass man damit
auch das Ziel erreichen kann. Allerdings braucht es dann wieder lokale
Platten in deinen ESX-Servern, um dieses hyperkonvergente Setup zu
erreichen.

Meinem bisherigen Verständnis nach würde auch eine LUN auf einem lokal
per FC angebundenen SAN als "local attached storage" angesehen und
könnte vom vSAN genutzt werden.
Macht das jemand hier? Nutzt überhaupt irgendwer der Mitlesenden vSAN?


Danke & viele Grüße

Paul

[Sven Hartge]

Post by Paul Muster

Post by Sven Hartge

Post by Paul Muster
hier[tm] steht eine kleine SAN-Infrastuktur verteilt über zwei
Standorte. FC-Switches 1a und 1b und Storage 1 am Standort 1,
FC-Switches 2a und 2b und Storage 2 am Standort 2.
#
[Hosts Standort 1] # [Hosts Standort 2]
| | # | |
[ FC-Switch 1a ]==|====\ [ FC-Switch 2a ] |
| | # \ / | |
| | # X | |
| [ FC-Switch 1b ]===/ \==|==[ FC-Switch 2b ]
| | # | |
| | # | |
[Storage 1] # [Storage 2]
#
Jeder Host hängt jeweils mit einem Link an jedem der beiden örtlichen
Switches. Die Switches hängen am örtlichen Storage und sind mit den
Switches am anderen Standort verschaltet.
Es gibt _keinen_ "SAN-Kopf", der Daten über die Standorte hinweg auf das
jeweils andere Storage spiegelt.

Das wäre jetzt nicht unwichtig, wenn man eine wirkliche Redundanz haben
will. Du willst ja bei Ausfall von einem Standort die VMs wieder
automatisch durch die HA am anderen Standort starten können.

Ja, diese Mirror-Funktion (am besten als Teil des SAN) fehlt. Aber die
wird es nicht geben, ich muss das anders lösen. Klar, dabei geht die
Hälfte der Kapazität verloren, das ist aber vertretbar.

Post by Sven Hartge
Mit der VSAN-Technik von VMware habe ich mich bisher noch nicht näher
befasst, aber den Grob-Überblick, den ich habe sagt mit, dass man
damit auch das Ziel erreichen kann. Allerdings braucht es dann wieder
lokale Platten in deinen ESX-Servern, um dieses hyperkonvergente
Setup zu erreichen.

Meinem bisherigen Verständnis nach würde auch eine LUN auf einem lokal
per FC angebundenen SAN als "local attached storage" angesehen und
könnte vom vSAN genutzt werden. Macht das jemand hier? Nutzt
überhaupt irgendwer der Mitlesenden vSAN?

Sofern du es nicht mit der ESX-eigenen VSAN-Technik umsetzen kannst,
lohnt sich evtl. ein Blick auf die HP StorVirtual VSAN-Technik. (Die
basiert auf vApps mit der P4500-Software von HP Lefthand.)

Damit habe ich in einer Offsite-Lokation einen 2-Knoten-ESX-Cluster
VSAN-fähig gemacht.

Allerdings ist das dann iSCSI und du brauchst eine entsprechend
brauchbare Verbindung zwischen deinen beiden Standorten. 8ms Latenz
konnte schon zu viel sein, die meisten Paper sprechen von "at most 4ms,
better 2ms RTT".

Grüße,
Sven.

[Paul Muster]

Post by Sven Hartge
Sofern du es nicht mit der ESX-eigenen VSAN-Technik umsetzen kannst,

...was der Fall ist, wie du in deinem zweiten Posting erläutert hast, ....

Post by Sven Hartge
lohnt sich evtl. ein Blick auf die HP StorVirtual VSAN-Technik. (Die
basiert auf vApps mit der P4500-Software von HP Lefthand.)

Ja, sieht interessant aus. Aber wir werden - leider - die
VMware-Umgebung zwei Nummern kleiner bauen und mit Redundanz/Failover
_auf Applikationsebene_ arbeiten müssen.

Im nächsten Projekt wird es dann hoffentlich eine "richtige"
VMware-Clusterlösung.


Viele Grüße

Paul

[Sven Hartge]

Post by Paul Muster
Meinem bisherigen Verständnis nach würde auch eine LUN auf einem lokal
per FC angebundenen SAN als "local attached storage" angesehen und
könnte vom vSAN genutzt werden.

So wie ich das sehe: Nein. Der VSAN-Code möchte die Platten und die
zwangsweise nötige SSD direkt ansprechen:

"VSAN requires a RAID Controller / HBA which supports passthrough mode
or pseudo passthrough mode. Validate with your server vendor if the
included disk controller has support for passthrough."

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058424

,----
| * Storage requirements
|
| - At least 1 SAS or SATA Solid State Drive (SSD).
| - Ensure the SSD is not claimed by vSphere Flash Read Cache.
| - Do not format SSDs with VMFS or any other file system.
| - At least 1 SAS or SATA Hard Disk (HDD).
| - A SAS or SATA Host Bus Adapter (HBA), or RAID controller that is set up
| in non-RAID (pass through) mode.
`----

Ach ja:

https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/virtual-san-60-administration-guide.pdf

Seite 14:

,----
| * Limitations of Virtual SAN
|
| - Virtual SAN does not support such features as Fault Tolerance, vSphere
| DPM, and Storage I/O Control.
| - Virtual SAN does not support RDM, VMFS, diagnostic partition, and
| other device access features.
`----

Dein gewünschtes Feature "FT" ist damit schon einmal weg.

Mir scheint, in deinem Fall wird das eher auf ein klassisches
DR-Szenario hinauslaufen, also
https://www.vmware.com/products/site-recovery-manager/

S°

[Paul Muster]

Post by Sven Hartge
So wie ich das sehe: Nein. Der VSAN-Code möchte die Platten und die
Dein gewünschtes Feature "FT" ist damit schon einmal weg.

Örks. Da schlägt wohl durch, dass der Mutterkonzern nicht zuviel Umsatz
verlieren will, weil VMware plötzlich ernsthaft ein SAN emulieren kann.


mfG Paul

[Roland Sommer]

Post by Sven Hartge
Ich habe $hier zwei ESX-Cluster, ein Cluster an zwei Standorten mit
einer NetApp MetroCluster-Lösung für den Storage, ...
Im Failover-Fall übernimmt dann der überlebende Kopf die kompletten IPs
und vFiler vom andere Kopf und die Volumes bleiben (mit reduzierter
Bandbreite natürlich) dennoch erhalten.

Du kennst auch http://kb.vmware.com/kb/1001783 failure scenario #9? (das
verschweigen viele sehr, sehr gerne und der Rest kennt das erst gar
nicht)

[Sven Hartge]

Post by Roland Sommer

Post by Sven Hartge
Ich habe $hier zwei ESX-Cluster, ein Cluster an zwei Standorten mit
einer NetApp MetroCluster-Lösung für den Storage, ...
Im Failover-Fall übernimmt dann der überlebende Kopf die kompletten
IPs und vFiler vom andere Kopf und die Volumes bleiben (mit
reduzierter Bandbreite natürlich) dennoch erhalten.

Du kennst auch http://kb.vmware.com/kb/1001783 failure scenario #9?
(das verschweigen viele sehr, sehr gerne und der Rest kennt das erst
gar nicht)

Ja, kenne ich und ist in unsere Prozeduren auch so dokumentiert.

S°

[Michael Logies]

On Fri, 02 Oct 2015 21:46:10 +0200, Paul Muster

Post by Paul Muster
Würde mich über Denkanstöße sehr freuen.

Ich habe nur die Hälfte der Kürzel verstanden und habe nur Erfahrungen
im Kleinbetrieb, aber eine RAID1-Spiegelung übers LAN, die man auf die
Verzeichnisse der jeweiligen VM-Dateien beschränken kann, geht mit
Mirrorfolder (ich spiegele damit laufende VMs):

http://www.techsoftpl.com/backup/
MirrorFolder is a real-time folder mirroring and synchronization
software to backup files on Windows desktop/laptop/server computers.

One can setup one or more mirrors for important folders, or even an
entire drive, to another local/removable/network drive for automatic
synchronization or real-time mirroring. (...)

Übers LAN habe ich mit der Software keine längere Erfahrung. Ich
spiegele Schreibzugriffe (RAID1 in eine Richtung) damit nur interne
Festplattenbereiche auf eine bzw. parallel auch mehrere, externe
USB-Festplatten/SSDs.

Ich weiß nicht, wie gut Mirrorfolder Schreibfehler erkennt.
Normalerweise schreibt es die gespiegelten Daten nur und prüft nicht,
ob die tatsächlich richtig angekommen sind. Das Prüfen mache ich ab
und dann mit Hashing (md5deep), sind bislang keine Fehler aufgetreten.

Grüße

M.

[Roland Sommer]

Post by Paul Muster
hier[tm] steht eine kleine SAN-Infrastuktur verteilt über zwei
Standorte. FC-Switches 1a und 1b und Storage 1 am Standort 1,
FC-Switches 2a und 2b und Storage 2 am Standort 2.
#
[Hosts Standort 1] # [Hosts Standort 2]
| | # | |
[ FC-Switch 1a ]==|====\ [ FC-Switch 2a ] |
| | # \ / | |
| | # X | |
| [ FC-Switch 1b ]===/ \==|==[ FC-Switch 2b ]
| | # | |
| | # | |
[Storage 1] # [Storage 2]
#

nur nebenbei: über Kreuz bei den fc Switches ist nicht notwendig. Warum
Du beide Storages an beide Hosts anschließt, habe ich auch nicht
wirklich verstanden.

Post by Paul Muster
Es gibt _keinen_ "SAN-Kopf", der Daten über die Standorte hinweg auf das
jeweils andere Storage spiegelt.

Genau das brauchst Du aber. Genauer gesagt, kann das durch das Storage
selbst erledigt werden oder durch eine Schicht dazwischen (nennt
Software Defined Storage SDS). Sven hat Dir Lefthand aka HP
StorageVirtual ans Herz gelegt, da schließe ich mich gerne an. Diese
Lösung gibt es als Software oder Hardware Appliance, Erstere
installierst Du z.B. auf Deine existierende ESXi Hosts mit drauf.

Wir haben uns gegen VMware VSAN entschieden, weil es u.a. auf 3 Hosts
limitiert ist und deutlich teuerer ist also z.B. Lefthand. Bis vSphere
5.5 durfte VSAN auch nicht parallel zu sonstigen VMs auf denselben Hosts
betrieben werden, wie das bei 6.0 ist, weiß ich nicht.

Post by Paul Muster
Nun soll ein VMware-Cluster aufgebaut werden, in dem FT und vMotion zur
Verfügung stehen. Damit soll eine vollständige Standortredundanz _auf
VMware-Ebene_ geschaffen werden.

Braucht ihr wirklich VMware FT oder ist VMware HA auch ausreichend? Du
kennst Du Einschränkungen hinsichtlich vCPU bzw. Lizenzen?

Post by Paul Muster
Wie macht man das nun? "Möchte" man eine 10GE-Verbindung zwischen den
VMware-Hosts schalten und mit vSAN arbeiten? Oder gibt es auch elegante
Varianten, bei denen man darauf verzichten kann? Irgendwie geschickt die
LUNs überkreuz mounten, die Querlinks sind ja da?

Das kommt u.a. auf die verwendeten Storages und das Budget an. Ich nehme
an, Du möchtest die Anlage nicht wesentlich verändern, dann empfiehlt
sich HP StoreVirtual als VSA auf den Hosts. Genau kann ich es noch nicht
sagen (PoC steht noch an und bisher haben wir HW Appliances verbaut),
aber theoretisch min. 2x 10 GbE pro Host bzw. zwischen den beiden Hosts
zusätzlich für das iSCSI SAN.

Wenn das Storage im Fehlerfall vollautomatisch umschalten soll, brauchst
Du noch ein Failover Manager (FOM). Das ist eine VM die idealerweise auf
einem dritten Host in einem dritten Raum läuft und Verbindung zu den
beiden ersten Hosts hat.

Generell sollte Dir klar sein, dass das ziemlich komplexe Setups sind
und einigen Betreuungsaufwand und vor allem -Know How erforden.

[Sven Hartge]

Post by Roland Sommer
Das kommt u.a. auf die verwendeten Storages und das Budget an. Ich nehme
an, Du möchtest die Anlage nicht wesentlich verändern, dann empfiehlt
sich HP StoreVirtual als VSA auf den Hosts. Genau kann ich es noch nicht
sagen (PoC steht noch an und bisher haben wir HW Appliances verbaut),
aber theoretisch min. 2x 10 GbE pro Host bzw. zwischen den beiden Hosts
zusätzlich für das iSCSI SAN.

Dummweise empfielt HP eine maximale Latenz von 2ms. Paul hat leider
8ms+. Das dürfte einen LHN-Cluster doch deutlich ausbremsen, da die
Daten beim Schreibzugriff ja auch auf die Remote-Site geschrieben werden
müssen und erst nach dem das erfolgt ist, wird die Transaktion dem ESX
bestätigt. Er hat also dadurch schon einmal 16ms Grund-Latenz auf alle
Schreibzugriffe.

Und da immer nur ein Node als Gateway für eine LUN dienen kann, kann
dies auch einmal der Node an der Remote Site sein und dann hast du bei
allen Lesezugriffen auf diese LUN 16ms Latenz und bei allen
Schreibzugriffen 32ms.

Das dürfte sehr sehr unbefriedigend sein.

Der MultiSite-Lefthand-Cluster $hier liegt in zwei unterschiedlichen
Gebäuden auf dem selben Campus, das LAN dazwischen hat im Schnitt unter
1ms Latenz, dort funktioniert das Setup sehr gut.

Bei 8ms reden wir ja vermutlich von knapp 100km Distanz. Das ist für
einen sychnronen Storage-Mirror schon echt eine Hausnummer.

S°

[Roland Sommer]

Post by Sven Hartge
Dummweise empfielt HP eine maximale Latenz von 2ms. Paul hat leider
8ms+.

auf der momentan LAN Konfig, ja. Aber er könnte die aktuell nicht
wirklich genutzen fc Leitungen für iSCSI SAN verwenden.

[Paul Muster]

Post by Roland Sommer

Post by Sven Hartge
Dummweise empfielt HP eine maximale Latenz von 2ms. Paul hat leider
8ms+.

auf der momentan LAN Konfig, ja. Aber er könnte die aktuell nicht
wirklich genutzen fc Leitungen für iSCSI SAN verwenden.

Jepp, ich könnte die Fasern auch "einfach" von den FC-Switches auf die
Ethernet-Switches umstecken.

Es sind übrigens ~12km zwischen den Standorten, da sollte eigentlich
deutlich weniger als 8ms möglich sein. Mal gucken.


mfG Paul

[Paul Muster]

Post by Roland Sommer

Post by Paul Muster
hier[tm] steht eine kleine SAN-Infrastuktur verteilt über zwei
Standorte. FC-Switches 1a und 1b und Storage 1 am Standort 1,
FC-Switches 2a und 2b und Storage 2 am Standort 2.
#
[Hosts Standort 1] # [Hosts Standort 2]
| | # | |
[ FC-Switch 1a ]==|====\ [ FC-Switch 2a ] |
| | # \ / | |
| | # X | |
| [ FC-Switch 1b ]===/ \==|==[ FC-Switch 2b ]
| | # | |
| | # | |
[Storage 1] # [Storage 2]
#

nur nebenbei: über Kreuz bei den fc Switches ist nicht notwendig.

Nicht beim derzeitigen Aufbau, ja.

Post by Roland Sommer
Warum
Du beide Storages an beide Hosts anschließt, habe ich auch nicht
wirklich verstanden.

Das ist nicht der Fall. Jeder Host hängt - über jeden der zwei örtlichen
Switche - an dem lokalen Storage.

Durch die FC-Infrastruktur wäre es wohl _möglich_, LUNs
standortübergreifend zu mounten, das wird aber bisher nicht gemacht.

Post by Roland Sommer

Post by Paul Muster
Es gibt _keinen_ "SAN-Kopf", der Daten über die Standorte hinweg auf das
jeweils andere Storage spiegelt.

Genau das brauchst Du aber. Genauer gesagt, kann das durch das Storage
selbst erledigt werden oder durch eine Schicht dazwischen (nennt
Software Defined Storage SDS). Sven hat Dir Lefthand aka HP
StorageVirtual ans Herz gelegt, da schließe ich mich gerne an. Diese
Lösung gibt es als Software oder Hardware Appliance, Erstere
installierst Du z.B. auf Deine existierende ESXi Hosts mit drauf.

Klingt schick. Ist allerdings wieder Drittsoftware, die ich eigentlich
loswerden will...

Post by Roland Sommer
Wir haben uns gegen VMware VSAN entschieden, weil es u.a. auf 3 Hosts
limitiert ist und deutlich teuerer ist also z.B. Lefthand. Bis vSphere
5.5 durfte VSAN auch nicht parallel zu sonstigen VMs auf denselben Hosts
betrieben werden, wie das bei 6.0 ist, weiß ich nicht.

Oha, das sind ja neben den von Sven schon genannten Einschränkungen noch
mehr Argumente gegen VMware vSAN. Danke, das kann ich wohl streichen.

Post by Roland Sommer

Post by Paul Muster
Nun soll ein VMware-Cluster aufgebaut werden, in dem FT und vMotion zur
Verfügung stehen. Damit soll eine vollständige Standortredundanz _auf
VMware-Ebene_ geschaffen werden.

Braucht ihr wirklich VMware FT oder ist VMware HA auch ausreichend? Du
kennst Du Einschränkungen hinsichtlich vCPU bzw. Lizenzen?

Ich hätte gerne FT, weil ich die aktuell genutzten Failover-Mechanismen,
die auf Applikationsebene realisiert sind, loswerden will. Vielleicht
ist dafür die Zeit aber noch nicht reif. Oder vielleicht ist das einfach
keine gute Idee und Standort-Redundanz macht man grundsätzlich anders.

Post by Roland Sommer

Post by Paul Muster
Wie macht man das nun? "Möchte" man eine 10GE-Verbindung zwischen den
VMware-Hosts schalten und mit vSAN arbeiten? Oder gibt es auch elegante
Varianten, bei denen man darauf verzichten kann? Irgendwie geschickt die
LUNs überkreuz mounten, die Querlinks sind ja da?

Das kommt u.a. auf die verwendeten Storages und das Budget an. Ich nehme
an, Du möchtest die Anlage nicht wesentlich verändern, dann empfiehlt
sich HP StoreVirtual als VSA auf den Hosts. Genau kann ich es noch nicht
sagen (PoC steht noch an und bisher haben wir HW Appliances verbaut),
aber theoretisch min. 2x 10 GbE pro Host bzw. zwischen den beiden Hosts
zusätzlich für das iSCSI SAN.
Wenn das Storage im Fehlerfall vollautomatisch umschalten soll, brauchst
Du noch ein Failover Manager (FOM). Das ist eine VM die idealerweise auf
einem dritten Host in einem dritten Raum läuft und Verbindung zu den
beiden ersten Hosts hat.
Generell sollte Dir klar sein, dass das ziemlich komplexe Setups sind
und einigen Betreuungsaufwand und vor allem -Know How erforden.

Jupp, ganz offensichtlich. Ich werde die vielen Informationen (Danke!)
in den nächsten Tagen mal verarbeiten und mich bzgl. StoreVirtual schlau
machen. Vielleicht haben wir das ja bereits an anderer Stelle im
Unternehmen im Einsatz und dort auch das Knowhow.


Viele Grüße

Paul

[Sven Hartge]

Post by Paul Muster

Post by Roland Sommer
Braucht ihr wirklich VMware FT oder ist VMware HA auch ausreichend?
Du kennst Du Einschränkungen hinsichtlich vCPU bzw. Lizenzen?

Ich hätte gerne FT, weil ich die aktuell genutzten
Failover-Mechanismen, die auf Applikationsebene realisiert sind,
loswerden will. Vielleicht ist dafür die Zeit aber noch nicht reif.
Oder vielleicht ist das einfach keine gute Idee und Standort-Redundanz
macht man grundsätzlich anders.

$hier im Haus gab es auch immer wieder Nachfragen nach VMware FT. Bei
genauere Betrachung stellte sich aber heraus, das FT gar nicht nötig
war, weil der Einsatz-Zweck dies schlichtweg gar nicht bedurfte. Man
muss sich wirklich gut überlegen, ob man wirklich einen Service hat, der
_gar keine_ Downtime verträgt, selbst die geringe Zeit nicht, die VMware
HA braucht, um die VM auf einem anderen ESX wieder anzuwerfen.

An einer Stelle gab es hier so eine Software, die nicht in der Lage war,
die Connection zum Datenbank-Server selbst wieder aufzubauen, wenn
dieser mal weg war. Dort wurde das Problem dann aber so gelöst, dass dem
Hersteller mal Druck gemacht wurde, das zu fixen. Danach war FT an der
Stelle dann auch vom Tisch. Vor allem weil so eine Unterbrechung ja auch
jederzeit auf Netzebene stattfinden kann. (Solche Software passiert
halt, wenn man eine Software mit lokaler Datenbank plötzlich als
Multi-Server-tauglich anpreist ohne als Hersteller zu wissen, was das
eigentlich bedeutet.)

VMware FT ist wirklich eine nette Technik, aber wenn man mal eherlich
ist: in 99% der Fälle braucht man diese Art von Fehlersicherheit gar
nicht.

Bevor ihr jetzt also in viel zu großen Bahnen denkt, macht doch erst mal
eine ernsthafte Evaluierung, _was genau_ eigentlich die
Fehlersituationen sind und was in welcher Form wie verschmerzbar ist.

Grüße,
Sven.

[Paul Muster]

Post by Sven Hartge

Post by Paul Muster
Ich hätte gerne FT, weil ich die aktuell genutzten
Failover-Mechanismen, die auf Applikationsebene realisiert sind,
loswerden will. Vielleicht ist dafür die Zeit aber noch nicht reif.
Oder vielleicht ist das einfach keine gute Idee und Standort-Redundanz
macht man grundsätzlich anders.

$hier im Haus gab es auch immer wieder Nachfragen nach VMware FT. Bei
genauere Betrachung stellte sich aber heraus, das FT gar nicht nötig
war, weil der Einsatz-Zweck dies schlichtweg gar nicht bedurfte. Man
muss sich wirklich gut überlegen, ob man wirklich einen Service hat, der
_gar keine_ Downtime verträgt, selbst die geringe Zeit nicht, die VMware
HA braucht, um die VM auf einem anderen ESX wieder anzuwerfen.
VMware FT ist wirklich eine nette Technik, aber wenn man mal eherlich
ist: in 99% der Fälle braucht man diese Art von Fehlersicherheit gar
nicht.
Bevor ihr jetzt also in viel zu großen Bahnen denkt, macht doch erst mal
eine ernsthafte Evaluierung, _was genau_ eigentlich die
Fehlersituationen sind und was in welcher Form wie verschmerzbar ist.

Hier handelt es sich bei einer der fraglichen Applikationen um eine
Windows-Dateifreigabe. Der erfolgt... ach, das willst du gar nicht
wissen. Aber der Zugriff kann tatsächlich nicht 10s warten. Auch keine
3s, nicht einmal 1s. Ja, auch das ist historisch gewachsene Software,
die eigentlich von Grund auf neu entwickelt gehört. (Da gehört eine
Datenbank mit eigenen HA-Funktionalitäten hin.) Aber wie es halt so ist:
Die Applikation ist geschäftskritisch und man ist froh, dass der
Hersteller sie überhaupt noch wartet, und will ihn daher nicht unter
Druck setzen.


Viele Grüße

Paul

[Paul Muster]

Post by Roland Sommer

Post by Paul Muster
hier[tm] steht eine kleine SAN-Infrastuktur verteilt über zwei
Standorte. FC-Switches 1a und 1b und Storage 1 am Standort 1,
FC-Switches 2a und 2b und Storage 2 am Standort 2.
#
[Hosts Standort 1] # [Hosts Standort 2]
| | # | |
[ FC-Switch 1a ]==|====\ [ FC-Switch 2a ] |
| | # \ / | |
| | # X | |
| [ FC-Switch 1b ]===/ \==|==[ FC-Switch 2b ]
| | # | |
| | # | |
[Storage 1] # [Storage 2]
#

nur nebenbei: über Kreuz bei den fc Switches ist nicht notwendig. Warum
Du beide Storages an beide Hosts anschließt, habe ich auch nicht
wirklich verstanden.

Zwischenzeitlich hat man es mir erklärt: Die zwei Hosts
(Windows-Fileserver, einer pro Standort), die das SAN bislang benutzen,
haben jeweils die LUN von *beiden* Storages gemoutet und eine Software,
die diese synchron hält. Ist eine Software von Veritas und spielt
irgendwie mit Windows Cluster Service zusammen.

Wir werden nun in der Testumgebung mal schauen, wie wir das in VMs
umbauen können und gleichzeitig andere Volumes auf dem Storage für
VMware als Datastore nutzen können. (Immer nur am eigenen Standort,
nicht standortübergreifend.)
Dabei werden wir auf jegliche besonderen Features von VMware verzichten
und die Hochverfügbarkeit des Fileservice weiterhin wie oben beschrieben
realisieren. HA und erstrecht FT brauchen wir dafür nicht.

Mal schauen, ob und wie das klappt.


Viele Grüße

Paul

[Roland Sommer]

Post by Paul Muster
Zwischenzeitlich hat man es mir erklärt: Die zwei Hosts
(Windows-Fileserver, einer pro Standort), die das SAN bislang benutzen,
haben jeweils die LUN von *beiden* Storages gemoutet und eine Software,
die diese synchron hält. Ist eine Software von Veritas und spielt
irgendwie mit Windows Cluster Service zusammen.

wird dann wohl Veritas SF (Storage Foundation) also Host-based Mirroring
sein.

Post by Paul Muster
Wir werden nun in der Testumgebung mal schauen, wie wir das in VMs
umbauen können und gleichzeitig andere Volumes auf dem Storage für
VMware als Datastore nutzen können. (Immer nur am eigenen Standort,
nicht standortübergreifend.)

Im Prinzip kannst Du das 1:1 als VMs nachbauen. Dabei bekommt jeder ESXi
Host je einen großen Datastore als seinen "primären" DS auf dem im
selben Raum befindlichen Storage angelegt. Darauf werden alles vDisks
plaziert und die für den Windows FileServer über einen separaten SCSI
Controller mit physical Bus sharing angehängt. IIRC ist dann vMotion
nicht mehr möglich (gilt bis 5.5, 6.0 hab ich mir noch nicht angesehen).

Post by Paul Muster
Dabei werden wir auf jegliche besonderen Features von VMware verzichten
und die Hochverfügbarkeit des Fileservice weiterhin wie oben beschrieben
realisieren. HA und erstrecht FT brauchen wir dafür nicht.

Alternativ könntet ihr euch auch transparenten Failover mit SMB 3.0
anschauen, dann habt ihr alles Windows nativ. Ich kenne das allerdings
nur theoretisch, weil wir das mal für den Hyper-V Cluster angedacht
hatten.

[Paul Muster]

Post by Roland Sommer

Post by Paul Muster
Zwischenzeitlich hat man es mir erklärt: Die zwei Hosts
(Windows-Fileserver, einer pro Standort), die das SAN bislang benutzen,
haben jeweils die LUN von *beiden* Storages gemoutet und eine Software,
die diese synchron hält. Ist eine Software von Veritas und spielt
irgendwie mit Windows Cluster Service zusammen.

wird dann wohl Veritas SF (Storage Foundation) also Host-based Mirroring
sein.

Ja, genau.

Post by Roland Sommer

Post by Paul Muster
Wir werden nun in der Testumgebung mal schauen, wie wir das in VMs
umbauen können und gleichzeitig andere Volumes auf dem Storage für
VMware als Datastore nutzen können. (Immer nur am eigenen Standort,
nicht standortübergreifend.)

Im Prinzip kannst Du das 1:1 als VMs nachbauen. Dabei bekommt jeder ESXi
Host je einen großen Datastore als seinen "primären" DS auf dem im
selben Raum befindlichen Storage angelegt. Darauf werden alles vDisks
plaziert und die für den Windows FileServer über einen separaten SCSI
Controller mit physical Bus sharing angehängt. IIRC ist dann vMotion
nicht mehr möglich (gilt bis 5.5, 6.0 hab ich mir noch nicht angesehen).

Ungefähr das ist nun der Plan, ja. Bin persönlich ein bisschen
enttäuscht, die ganzen "coolen Features" dann nicht zu haben, aber wir
brauchen sie auch nicht. Redundanz wird komplett auf Applikationsebene
gemacht, daher wird es zumindest vorerst kein HA und erstrecht kein FT
geben...

Post by Roland Sommer

Post by Paul Muster
Dabei werden wir auf jegliche besonderen Features von VMware verzichten
und die Hochverfügbarkeit des Fileservice weiterhin wie oben beschrieben
realisieren. HA und erstrecht FT brauchen wir dafür nicht.

Alternativ könntet ihr euch auch transparenten Failover mit SMB 3.0
anschauen, dann habt ihr alles Windows nativ. Ich kenne das allerdings
nur theoretisch, weil wir das mal für den Hyper-V Cluster angedacht
hatten.

Wir machen jetzt erstmal den Schritt von vielen "Blechs" auf wenige
"Blechs" plus Virtualisierung. Danach sind Weiterentwicklungen der
Umgebung viel einfacher und besser testbar. Da schauen wir dann, was auf
Applikationsebene mittlerweile evtl. eleganter geht.


Danke für alle Beiträge & viele Grüße

Paul