VMware-Forum

Hallo Leute,

Meine Server-Projekt-Planung steht in der Endphase, naja zumindest dachte ich das. Das letzte hatte ich aus mangelnder Erfüllung der Anforderungen wieder bachab geschickt und auf Eis gelegt. Jetzt muss aber bald was her, die alten Server serbeln teilweise schon und ich schlafe schlecht... Sehr schlecht

Allerdings habe ich immer noch ein paar Vorbehalte. Vielleicht könnt/wollt ihr mir ja helfen. Habe auch schon mit einigen Anbietern, Herstellern, SMB-Schmieden gesprochen, diverses ausprobiert usw. aber für SMB gibt es wohl nicht viel sinnvolles.

Vielleicht erst die Anforderung:
- Fault Tolerance für einen SQL-Server + einen Small Business Server
--> Ausfall nicht verschmerzbar. 5min Datenverlust = ziemlich uncool. Offline auch nicht prall, da Produktion teilweise stehen würde.
Aktuelle Vorsorge: Ablage der Daten auf zwei Systemen/Datenbanken. Bei Crash allerdings nicht unbedingt schnell wiedr online, da nur Messdaten nicht ganze DB redundant gespeichert wird.

- FT oder zumindest Datensicherheit für Restart für einen Unix SCO Server
--> Ausfall wäre zwar verschmerzbar, da Daten reproduzierbar. Aber trotzdem mühsam. Daher wenn schon Kohle ausgeben, dann soll auch die HA sein. Auch waren die Backups in der Vergangenheit nicht immer zuverlässig, auch wenn System dies so gemeldet hat.

- FT zumindest Datensicherheit für einen Windows Client inkl. Objektorientierter Datenbank (Name entfallen)
--> braucht Performantes DiskSubSytem für die Datenbank damit Sortierung + Filterung nicht zur qual werden (1DS = 1MB), soll aber nicht in der Produktivumgebung stehen, sondern per ThinClient + natives USB-Redirect mit der VM verbunden werden.
--> Dachte an Kombi mittels VmWare View + Teradici-Protokoll welches mir das alles mitgibt.

- Später Virtualisierung aller Clients für einfacheres Deployment sowie 0 Daten auf Client. --> Sicherheit.
- Zwei getrennte Räume (Feuer)
- SMB-Kosten.
- Möglichst einfacher Unterhalt

Eine Clusterlösung kommt aufgrund der massiv gesteigerten Komplexität sowie der horrenten Preise für MS-Lizenzen nicht in Frage.

LoadBalancing, LiveMigration und solche Spässe brauche ich nicht zwingend. Mir ist es eigentlich ziemlich latte wenn ein Server ein Core auf beiden Servern für sich beansprucht. Prozzi+Ram ist der kleinste Teil der Kosten. Wenn ein Core/Thread nicht reicht, ist halt schade und ein dickerer Prozzi muss her, aber das gilt für beide Varianten.

Pro Xen
- Xen Free + Marathon für 2 Hosts (Soviele Prozzi-Sockel wie gewünscht) = ca. 5000 Euro (exkl.)
- Absolut simple Infrastruktur + Setup, jeder halbwegs taugliche Freizeitadmin bekommt Unterhalt etc. hin, auch Failover rekonstruktion ist mehr oder minder ein Klacks.
- Simples 'richtiges' Full Machine FT oder Component Level FT
- Einfachstes Storage für 'richtiges' Storage FT nötig --> 2xLocal
- Angeblich (gemäss Marathon) viel kleinerer Performance-Verlust bei FT als VmWare
- Keine Hardwarebeschränkung

Contra Xen/Marathon
- Kein Unix SCO möglich und wohl auch nie unterstützt (Keine Pläne seitens Marathon)
- Kein Client OS möglich und auch keine Pläne (Marathon)
--> Evtl. lösbar mittels Serverlizenz, allerdings dann Backup-Agent teurer + Serverlizenz + evtl Lizenzverletzung der verwendeten Applikation, sollte sie laufen.
- Keine wirkliche Community für Lösung von Problemen.


Pro VmWare
- Unterstützt alles an OS die ich gerne hätte
- Riesige Community

Contra VmWare
- Nur gemeinsames Disksubsystem, fällt dieses aus zbsp. wegen Feuer, ist tote Hose. DR notwendig
- Recht hohe Lizenz + Hardwarekosten. SAN mit sicher 2 Controller (hängt ja alles von ab) + grundsätzlich auch nen Mirror. SAN-Failover aber schwierig realisierbar.
- Desasterfälle sind ein Graus. Schon einfache Ausfälle von Komponenten sind nicht unbedingt spassig.
- Ziemlich zickig in Bezug auf die Hardware (zumindest wenn man VM-Ware-Anforderungen liest)


Ergebnis: Nun wie man unschwer erkennen kann, hatte ich mich eigentlich schon für Xen + Local Storage entschieden. Aus Komplexitäts + Kostengründen. Das Dillema mit dem Client könnte ich evtl. mit einem supporteten Serversystem lösen (ergibt neue Lizenkosten für OS + BackupAgent), was übrig bleibt ist die Unix-Mühle die in einer VM laufen muss.

Ansatz 1:
- Nested VM's innerhalb einer geschützten Windows Server VM, produktiv wohl nicht wirklich empfehlenswert. Technisch auch eher schwierig bis gar nicht zu realisieren.

Ansatz 2:
- Innerhalb Windows Server VM auf Marathon Level 3 ein iSCSI Target bereitstellen.
- Von diesem iSCSI target die Unix Maschine booten. Entweder als weitere VM auf Xen ohne Marathon-Protect oder einer physikalischen Maschine. Bei einem Serverausfall reboot mit vollständig erhaltenen Daten von anderem Server. Gemäss Marathon: Möglich

Ansatz 3:
- VmWare nehmen + Pille schlucken das Disksubsystem der SPOF ist.
- Dual Controller mit SAS Anbindung (kein teures FC)
- Hoffen auf Besserung bei Performance und Direktuntestützung für separate Local-Storages.

Ansatz 4:
Kombination aus beidem, iSCSI Starwind Target auf einer/mehreren protecteten Marathon-Maschinen (also mirrored Storage), billigstes VmWare-Small-Business HA Paket + zwei zusätzliche physische Maschinen auf welchen alles via VmWare virtualisiert wird, was sich Unix oder Client schimpft.
Wäre wohl kostentechnisch langsam grenzwertig, Technisch auch die Kategorie Overkill, Performance wohl auch eher Kategorie grenzwertig, aber wohl machbar. Dafür eine nette Spielwiese mit der man alles machen kann.

Ansatz 5:
VmWare HA + Beten + iSCSI Starwind target auf Windows + Replikation des Starwind-Servers mittels DoubleTake. Wird so promoted von Starwind, aber ehrlich gesagt habe ich darin nicht wirklich viel vertrauen.

Ansatz 6:
- Nix von aldem, SMB auf BareMetal
- Rest virtualisiert innerhalb des SMB mit VmWare Workstation, Server oder ähnlichem
- Full Server Replikation mit DoubleTake, asynchron (nahezu synchron bei dicker leitung)
- Ungutes Gefühl aber angeblich zumindest windows alleine funktionstüchtig
- Kein guter Schlaf, Blanke Nerven

Desaster-Fall:
Nur damits erwähnt ist, Backup ist schon auch geplant. Sollte alles schiefgehen. Mit MS SCDPM + Acronis Images.


Wäre super wenn ich ein paar konstruktive Inputs bekommen könnte. Denke wir sind nicht alleine mit solchen Wünschen/Ängsten etc. mit welchen auch Kleinfirmen zu kämpfen haben, die zwar durch die IT ne Menge automatisieren können, gleichzeitig aber immer mehr von einem funktionierenden System abhängig sind je mehr produktive Maschinen daran hängen.

Grüsse und Dankeschön

Sorry aber ich bin nicht sicher was du jetzt willst.

Ich teile deiner Meinung der Vor- und Nachteile nicht! Ich sehe momentan VMware mit der Nase vorn. Xen ist meiner Meinung nach ein totes Pferd auf das man nicht mehr setzen sollte. Allgemein stimmt einiges einfach nicht von den Vor- und Nachteilen.

Zu allem anderen weiß ich nicht was du genau willst...

Hi Heros,

OK, versuche es mal anders:

- Zwei eigenständige, parallel laufende Server. darauf ein SMB, SQL sowie ein Unix-Server + eine ClientMaschine.
- Zwei Räume in zwei Gebäuden
- Fällt ein Server aus, soll der andere direkt übernehmen, ohne neustart, Memory-Verlust, korrupte Datenbanken etc. Also VmWare FT oder Marathon VM

VmWare passt mir grundsätzlich auch besser alleine schon von der Unterstützung der OS, allerdings bin ich auf ein DiskSubystem angewiesen, welches Spiegelung von sich aus beherrscht was die kosten mal per se fast verdoppelt.

Mit welchen Vor- Nachteilen bist du nicht einverstanden? Xen für sich alleine würde ich auch nicht einsetzen, nur in Verbindung mit Marathon, weil es mir eben erlaubt, zwei Server völlig parallel, ohne gemeinsames DiskSubSystem laufen zu lassen. Dadurch habe ich in beiden Brandabschnitten einen Server, der sämtliche Daten zu Verfügung stellen kann.

Man sollte mit seinen Forderungen nach Hochverfügbarkeit nicht übertreiben. Denn selbst nur mit FT und einer Dual-Controller Storage bist du schon wesentlich besser wie heute.
FT heißt im übrigen auch nur 1vcpu pro VM und keine Snpashots. (auch kein VCB?!)
Wieso nicht eine zentrale Storage mit gutem Service abgesichert (oder ersatzteile vorort bzw beim lokalen Systemhaus) und 2 getrennte Host, die auf die Storage per FC oer ISCSI zugreifen.
Im zweiten Raum wo keine Storage steht läuft der Backup-Server. So ist zumindest der Backup räumlich getrennt vom Storage. Denn im wirklichen Brandfall nützt dir der andere Server-Raum ja auch nix. (Also produktiv-technisch gesehen, wenns brennt, wird ja keiner weiterarbeiten)

Hallo,

zuerst einmal ist dein Scenario extrem kostenintensiv, das solltest du deinem Management deutlich machen.

Wer solche Anforderungen an seine IT stellt, muß auch entsprechende Mittel zur Verfügung stellen.
Wenn Ihr z.B. an eine Spedition diese Anforderungen stellen würdet, müßten Sie zwei LKW mit identischer Ladung über unterschiedliche Routen zwischen Kunden und Lieferant einsetzen.
Gibt sicher nicht viele Kunden, die solche Anforderungen stellen und dann auch bezahlen würden.

Na ja, egal, IT kann ja grundsätzliches alles (wenn ich doch nur unseren Sales Leuten glauben könnte)

Für deine Windows VM's gibts ne relativ simple Lösung, nämlich alles mit mirrored dynamic Disks zu betreiben.
Dazu nimmst du zwei getrennte Disk Arrays und erzeugst dort deine Datastores.
Anschließend je Diskarray die erforderliche Anzahl der benötigten Windows Disks erzeugen und dann zu mehreren mirrored dynamic Disks zusammen bauen.

Hier ne Anleitung zum Eintrichten für die System & Boot Disk.
How to mirror the system and boot partition (RAID1) in Windows Server 2003

Das in Verbindung mit FT sollte den ganzen Blues mit überschaubarem Aufwand ermöglichen.

Viel Erfolg,
Ralf

Hallo Leute,

Danke für die Inputs.

Nun, das es nicht umsonst wird, ist klar. Ein Datenverlust in der Produktion können wir uns eben grundsätzlich nicht erlauben. Sofern bezahlbar, soll es eben gar nicht erst soweit kommen und eine Menge Nerven sparen. Meine Nerven sind einige tausender Wert (zumindest meiner Meinung nach ).

@Supi: Wegen Übertreibung der Verfügbarkeit: Nun, warum sollte man es nicht tun, wenn es finanziell keinen grossen Unterschied macht?

Zumindest bei der Xen Marathon-Lösung bleiben die Kosten sehr überschaubar, Marathon wird pro Host abgerechnet, also egal wie viele Prozzis ich reinschiebe. Auch reicht die FreeVersion von Xen. Auf die ganzen einfache Features wie AutoRestart, LoadBalancing etc. kann ich ja verzichten. Ein Coldsystem bräuchte ich ja sinnigerweise sowieso, warum dieses nicht grad als Failover nutzen? Bei Xen Marathon betragen die Zusatzkosten 5000 Euro, im Verhältniss zu den eh nötigen Investitionen bietet dies im Verhältniss zum Preis einen imho sehr grossen Mehrwert.

Feuer Nun wir sind ein ziemlich gebranntes Kind was Umweltschäden angeht. Ein Problem weniger zu lösen = viel wert in einem Kleinbetrieb.

Sprich wenn ich VmWare zu ähnlichen oder auch leicht höheren Kosten bei gleichen Features auf igend eine Art implementieren kann, ohne dass das ganze zu Komplex und dadurch anfälliger und teuer wird, würde ich das sicher tun. Allerdings habe ich zumindest noch keine Möglichkeit dafür gefunden. Leider.

@Ralf: An die Variane mit Dynamic Mirror Disk dachte ich auch schon. Allerdings kam ich noch ned auf die Idee, dies auch innerhalb einer VM zu tun. Ich frage mich gerade ob das VmWare + den Mirror-VM's wirklich egal ist, wenn der Storage abgehängt wird. Bin da etwas skeptisch. Oder wie genau würdest Du das aufgleisen? Hätte jetzt an ein iSCSI Target gedacht, welches in die VM eingebunden wird.

Wäre dies auf VmWare Ebene möglich, sofort. Leider bietet VmWare ja kein RAID1 iSCSI initiator an, welche das Problem ziemlich einfach lösen würde. Aber da hat vielleicht EMC den Daumen drauf. SAN-Spiegelungen sind ja ein sehr lukratives Geschäft. Auch konnte/wollte mir Starwind kein Zero-Downtime für ihre enterprise-Lösung garantieren, wodurch es wohl nicht wirklich für VmWare FT geeignet ist.


Wie gesagt, bei der Unix-Mühle könnte ich auf FT gut verzichten. Da reicht grundsätzlich ein täglicher Backup. Wenn sich ein Ausfall vermeiden lässt, Technik eh für die andern angeschafft wird, warum nicht nutzen. Sofern eben möglich.

EDIT: Wenn ein iSCSI Target innerhalb einer per FT gesicherten Umgebung läuft, darauf das Image einer VM liegt, diese von ausserhalb geladen wird, habe ich ja faktisch den gleichen Stand wie die Standard HA Features, ausser dass es eben nicht automatisch neu gestartet wird. Würde dann den Client halt im Serverraum 'lagern' um von USV und kurzen Kabel zu profitieren und mich via RDP mit ihm verbinden. Auf diesem läuft dann vmware workstation welcher den Unixsever lädt. Im Desasterfall wären die Daten des Unix auf dem zweiten Server noch vorhanden und es muss einfach eine neue physische Client-Maschine das Image wieder laden. Wäre das ein gangbarer/sinnvoller weg?

Grüsse und schönen Dank.

Hallo,

solange du auf dem Server keinen Rescan initiierst, sollte das für die VM's egal sein.
Allerdings kann ich nicht die Hand dafür ins Feuer legen, das müßte man einfach mal so aufsetzen und testen.

Ich bin mir aber ziemlich sicher, das VMware nur beim Starten einer VM die Verfügbarkeit der erforderlichen Resourcen überprüft.
Da in deinem Scenario FT ja laufende VM überwachen soll, muß eigentlich "nur" ein Umschalten zum überlebenden ESX Server stattfinden.

Aber wie gesagt, Versuch macht kug.

SAN Spiegelungen sind für dein Scenario nur bedingt geeignet, schließlich willst du die entsprechenden LUNs auf beiden Seiten im RW Modus verfügbar haben.
Klassische SAN Spiegelungen basieren darauf, das eine Seite im Status RW steht und alle Änderungen synchron (oder asynchron) übertragen werden.
Die remote Seite ist dabei üblicherweise im Read-Only oder Not Ready Modus.

Was du brauchst ist ein virtuelles Target, das sich aus zwei realen Targets ein RAID 1 baut.
So viele Anbieter gibt es da nicht.

Viel Erfolg
Ralf

Tach,

Virtueller iSCSI Target mit Mirror: In der Tat, wirklich fündig wurde ich aber nicht zumindest nichts was nicht wieder einen SPOF hätte.

Mit dem Xen+Marathon wäre diese Fliege zumindest mit einer Klappe geschlagen. Die Windows-Server quasi ab Werk mit FT gesichert, mit direktem Zugriff auf Disk-Subsystem ohne Umweg über iSCSI. Den müsste nur Unix nehmen.

Wenn jemand Tipps oder Tools kennt für VmWare ESX welche bezahlbaren und produktiv einsetzbar sind, gerne her damit. Mir wäre ja VmWare grundsätzlich sympathischer. Ich meine ich habe sogar mal irgendwas gelesen, was auf jedem Host ein iSCSI Target auf Linux Ebene bereitstellt (ESX) mit identischen IP's, MAC etc. und diese dann für die ESX als Shared Storage genommen werden und als einzelner erkannt wird. Allerdings nicht wieder gefunden und meine es wurde auch nur HA und Live Migration unterstützt, nicht FP.

EDIT: Zum Versuch: Hmm, dazu müsste ich die neue Hardware erst haben. Die wäre aber nicht die gleiche bei Shared oder Local Disks. Die Hardware die 'über' ist, ist leider nicht so modern. Evtl. zwei kleine nehmen und evtl. als Testumgebung behalten.

Grüsse und Danke

Mein Tipp waere:
Mach 2 oder mehr Anforderungsprofile. Einmal dein 99.999%-100% Wunsch und dann etwas realistischen wie Wiederherstellung der Infrastruktuer bzw. definierter Teile in X Stunden. Das entsprechenden ausarbeiten und mit Zahlen belegen und da wir nicht betriebsblind sind fuer VMware und XEN ausarbeiten.

Zum Thema VMwareFT mal die "Bedingungen" wo es denn eingesezt werden kann durchlesen weil davon lassen sich ja die Nachteile ableiten. Das ganze dann mal mit Marathon vergleichen und sehen das es eine grosse Uebereinstimmung gibt.

Anstelle vom Kinderkram wie Starwind auf virtuellen Platten mal DataCore SanSymphony oder sofern SanMelody das mit den 2 Server auch beinhaltet entsprechend das angucken.

Was auch passen koennte ist VMware SRM sofern denn eine kurze Downtime akzeptabel ist und man ein Storage mit syncroner Spiegelung hat. Hat man die nicht so kaeme ein "Datenverlust" von Zeitraum X dazu.

- Systeme muessen gewartet/Repariert und gepatch werden
- Die Failover Prozeduren muessen einfach und beherschbar sein, Automatisierbar und wenn es geht auch Testbar

Was ich jetzt nicht herauslesen konnte war ob du mit einem ESX Host pro RZ auskommst oder nicht.

Gruss
Joerg

Hi Joerg,

Vielen Dank für den Input.

Das einzige aus den Unterlagen ersichtliche Unterschied ist technisch nur der Storage. Der Rest ist ja eigentlich identisch.

Was vom Performance-Overhead wirklich stimmt, mag ich nicht beurteilen, da keine unabhängige Studie gesehen und nicht selbst probiert. Mir gegenüber wurden Werte von Marathon üblicherweise 1-2%, VmWare bis zu 20% und teilweise mehr genannt. Ich weiss aber wirklich nicht, was und wie die Jungs diese Werte gemessen/ermittelt haben oder ob es reine Marketingmasche ist.

Das entsprechenden ausarbeiten und mit Zahlen belegen und da wir nicht betriebsblind sind fuer VMware und XEN ausarbeiten.

Genau deshalb wende ich mich ja an dieses Forum, weil ich beim mitlesen immer das Gefühl hatte, dass die meisten auch über den Tellerrand schauen.

Zahlenschieben habe ich durchaus schon gemacht.

Externer, gemeinsamer, einfacher Speicher wäre ungefähr gleich teuer wie Local + separt. Doppelter Externe Speicher schnell rund 6k Euro teurer oder mehr, je nach Anspruch, reine Hardware. Dazu kommen dann Softwarekosten für irgend eine Art Mirror.

VmWare Advanced ist von den Lizenzgebüren für zwei Hosts mit je einer CPU sehr ähnlich. Zusätzlich kommt jedoch 2k Euro für vCenter Foundation. Für jede zusätzliche CPU pro Host jedoch schnell doppelt so teuer. Dies schlagen aktuell aber wohl eher nicht zu Buche, weil wohl eine CPU reichen sollte, da eh nur 1 Core zugeteilt werden kann bei FP. Also 4 VM's für FP möglich.

Wären also reine Fixkosten ohne zu wissen was Speichermirror-Software kostet mindestens 8'000 Euro mehr für die gleiche Funktion. Bei Annahme das Software Datacore ca. 2-3k, kostet, wären das ca. 10k Euro mehr. (bei vmWare nicht ganz sicher ob inkl. oder ekl. MWST, rest ekl.)

Rein technisch spricht imho auch mehr für die Marathon-Lösung. Einfach, Kein Datenverlust, keine korrupten DB's, keine unnötige komplizierte Infrastruktur, Keine Lizenzkosten bei Erweiterung. Zweit- und letztes spricht eher für M. Die Systeme welche diesen hohen Schutz benötigen sind nur SMB + SQL. Wichtig sind ein paar wenige GB + halt die OS. Der grosse Teil der Daten (Sekundär + Terziär) könnte auch auf nur per täglichem Backup problemlos gemanaget werden. Durch Local-Storage wohl auch eher bessere Performance als lahmes 1GBit iSCSI. FC wird nochmal teurer, vor allem wegen HBA's.

Aber eben, das ist mein Eindruck den ich beim Vergleich und Kostenzusammenstellung ermittelt habe. Bei den Disks für externe Systeme einen sehr sehr ordentlicher Rabatt bei meinem Hardware-Typ eingerechent.

Die Workstation mit der DB würde wohl auch auf Serversoftware laufen (Abklärung läuft). Bei nutzung eines Client-OS, ne Menge Lizenzgebühren für Backup Agent + OS weniger. Disk-Performance ist sie unersättlich, je mehr desto besser. Datenverlust darf sie keinen haben, durch verkettung einiger unglücklicher Umstände könnte dies sehr peinlich und im schlimmsten Fall sogar existenziell sein. Wird aber etwas abgefedert durch gleichzeitig möglichen XML-Export auf ein Netzwerkshare. Import jedoch m.W. nicht möglich, also Auswertung dann lästig. Downtime von einem Tag ist aber zu verkraften sofern die Datenbank eben noch in Ordnung ist. Am liebsten Synergien/Spindeln der Server nutzen.

Die UnixMaschine ist einfach nur lästig wenn sie ausfällt, da mit arbeit verbunden bis sie wieder läuft. Kostet es nur wegen ihr viele tausender mehr, dann soll eine andere Lösung für sie her. Problematisch sind hier immer Restores, nicht ganz trivial wenn nicht ein Image Copy Paste gemacht werden kann. Sprich Prozedere ist lästig und nervig aber bis auf Mannstunden nicht geschäftsschädigend.

Allgemein: Grundsätzlich bin ich um alles froh, was schonmal nicht einfach so ausfallen kann und mir dadurch etwailige Arbeitsstunden erspart.


Zu Vorschlag Datacore: Da brauche ich zwei zusätzliche, vollwertige Maschinen oder?

Zu Vorschlag SRM: Nun das ist soweit ich das verstanden habe eine asynchrone replizierung oder? Sprich was unterwegs ist, ist weg oder?

Zu deinen wichtigen Punkten: So sehe ich das auch. Das alles möglichst easy.

Hoffe es kam etwas klarheit mit rein. Thema ist komplex, ohne viel Text alles zu nennen sowieso und das alles als KU in Produktion, die nicht Margen von IT-Fritzen haben (:keksrüberreich:) noch schwieriger.

Grüsse und dankeschön

UrsDerBär hat geschrieben:
Zu Vorschlag Datacore: Da brauche ich zwei zusätzliche, vollwertige Maschinen oder?

Zu Vorschlag SRM: Nun das ist soweit ich das verstanden habe eine asynchrone replizierung oder? Sprich was unterwegs ist, ist weg oder?

moin, ich mische mal mit. Tschuldigung wenn ich hier etwas wiederhole, der Thread ist ziemlich mächtig

Datacore benötigt zwei separate Maschinen als Contoller für die SAN virtualisierungsschicht.
Vorteil der Datacore Lösung, der Ausfall eines Storages wird von den angeschlossenen Servern (ESX, Xen, Windows) nicht wahrgenommen. Datacore kümmert sich um die Datenreplikation zwischen den Storages, man spart sich also die Hersteller Lizenzen fürs Mirroring. Datacore macht in FibreChannel Umgebungen sinn.

Marathon ist ja eine reine Software Lösung, die die replikation zwischen zwei getrennten Storages über ein (separates) Netzwerk erledigt. Marathon Everrun gibts ja nur für Xen und nicht für Vmware, also vorsicht. Dafür wird die nächste XenServer Version Everrun direkt enthalten, also Support by Citrix.

Der SRM selbst übernimmt keine Datenreplikation, das muss der Storage machen, synchron oder asynchron ist also eine Frage der Leitung SRM übernimmt jedoch die automatische Konfiguration der VMware Umgebung im Desaster Fall. Da die VMs sich auf zwei verschiedenen Storages befinden, muss beim Ausfall des einen, das System auf das andere (den Spiegel) umgeschwenkt werden. SRM macht in größeren Umgebungen durchaus sinn, wenn die Konfiguration einiger hundert VMs etlich Stunden oder tage benötigen würden.

Ich pers. würde die Datacore bzw. Falconstore Variante empfehlen, also Storagevirtualisierung. Vorteile sind man ist unabhängig vom verwendeten System, sowohl Xen, als auch VMware und Windows profitieren von der Redundanz, die eigentlich kaut Hersteller völlig transparent ablaufen sollte. Nachteil: Teuer und in der Praxis ist ein Storage Ausfall immer mit Respekt zu behandeln.

P.S. Es kann durchaus sinnvoll sein, auf zwei Pferde zu setzen. Wir verwenden für heterogene Systeme Vmware, für homogene Systeme (in diesem Fall XenApp) setzen wir auf Provisionierte VMs unter XenServer.

Dankschöööönn

Ok, dann fasse ich mal zusammen:
- Wir wissen nicht was an der Aussage des Performance Overhead dran ist bei VmWare FT. Evtl jemand schon Erfahrungen gesammelt? Single --> HA --> FP-Modus?
- VmWare braucht ein paar Sekunden bis Server wieder da ist, bei Marathon sind immer beide da. --> Was passiert bei VmWare mit SQL-Befehle die reinkommen in dieser Zeit?
- VmWare braucht für richtiges FP eine Storagebasierte Spiegelung Marathon reicht Lokal aus.
- Prinzipbedingt spielt es für Windows Server keine Rolle ob Marathon oder VmWare.
- Starwind auf einer VirtualDisk innerhalb VM ist Kinderkram. Könnte man aber machen wenn Performance für jene Anwendung eine untergeordnete Rolle spielt. Ausprobieren.
- Datacore Variante wäre sehr flexible mit Erweiterung
- Datacore erhöht Komplexität ( FC oder iSCSI Infrastruktur + zusätzliche Server + Switches benötigt)
- Datacore braucht braucht für Storageausfälle KnowHow
- Mit Datacore wird man arm.
- SRM braucht auch Datacore

Jemand etwas dagegen einzuwenden?

Conclusion:
- VmWare Lizenzen: 2k Euro (Bei ProzessorErweiterung zusätzlich ca. 2.5k)
- Hardwarekosten: ca. 6k Euro mehr bei einfachste Variante mit 2 Hosts. Kommt noch Switchkosten für Storage, FC-Adapter etc. hinzu, geht es wohl effektiv schnell gegen 10k Euro und mehr.
- Datacore-Lizenzen: Bei 1TB Speicher: 5k Euro für Spiegelvariante. Spirale nach oben unglaublich --> Bsp. wenn Nutzung für Sekundär Speicher, Backup usw. auch erwünscht.

Wären für eine sinnvolle VmWare-Variante also rund 13-20k Euro mehr für eine FT Umgebung für zwei Server.

Was übrig bleibt und finanziell tragbar ist:
- FT bleiben lassen: Während mind. 2 Monate im Jahr je länger je kriminell, ausser man macht andere Varianten wie Cluster.

- VmWare: Wir machen eine einfache Shared-Storage-Variante, zbsp. SAS. Infrastruktur alle am gleichen Ort. Risiko eines Brandes wird ignoriert. Kostenpunkt ca. 4k Euro mehr --> Hardware + VmWare Lizenz. Produktionstillstand wenn Speichersystem ausfällt. Oder Bastellösung à la Dynamic Disc RAID 1.

- Xen/Marathon: Bietet aktuell für die Windows-System alles was ich haben möchte. Unix muss irgend eine Bastellösung her, dafür gut mit Backups abgesichert sein um Nerven und Arbeitsstunden zu sparen. Leider nicht innerhalb von VmWare Workstation auf einer Windows-Server-VM realisierbar. Für die Workstation muss ein Server-Betriebssystem verwendet werden. --> Heute OK bekommen, das theoretisch kein Problem sein müsste. Auch kann nciht mit dem Teradici-Protokoll USB gleich mit übertragen werden. RDP + irgend eine andere Form von USB-To-Lan muss verwendet werden.

Ich tendiere aus Kosten- und Featuregründen zu Xen-Marathon sofern es technisch nicht irgendwelche NoGo's gibt die ich noch nicht erkannt habe.
Gleichzeitig akzeptiere ich eine einfache Lösung für Unix, indem ich sie entweder direkt auf einem der Xen-Server laufen lasse und direkt auf Disk zugreife oder indem ich von einem iSCSI Target innerhalb einer Windows Server VM boote, hätte dann quasi einfaches manuelles HA.

Auch verzichte ich vorläufig sicher auf Client-Virtualisierung. Evtl diese dann auf einer oder zwei VmWare-Maschinen mit der billigsten KMU-Lizenz.

Was meint Ihr? Grobe Denkfehler? Grobe Dummheit wenn Xen/Marathon verwendet wird?

Leider nicht innerhalb von VmWare Workstation auf einer Windows-Server-VM realisierbar.

wieso nicht ?

@continum: Nun, VmWareWorkstation läuft doch normalerweise nicht innerhalb einer VM. Oder nur via ESX->VM>32 Bit+Spezial-Flags (Backdoor). Ob das soooo intelligent ist? Das das ganze auch in einer VM auf Xen/Marathon tutet, bezweifle ich jetzt etwas. Aber noch nie getestet...

Nun, VmWareWorkstation läuft doch normalerweise nicht innerhalb einer VM.

doch - das funktioniert recht gut - ist aber nichts fuer Dauerloesungen ...

hm, ein produktiver sql server der nicht eine sekunde ausfallen darf und dann ausgerechnet auf einem sbs server läuft? oder ist sql/sbs getrennt? irgendwie klingt dein aufbau sehr abenteuerlich, zumindest für die größenordnung um den es zu gehen scheint.

gerade in einer kleinen produktionsumgebung würde ich genau überlegen ob ich mit einer virtualisierungslösung und dem ganzen rattenschwanz der benötigt wird auch wirklich etwas gewinne.

ein einfacher cluster mit emc/doubletake ist vergleichweise günstig und ohne großen hardware aufwand möglich. teure lizenzen, san + san equipment fallen weg - das ist eine menge schotter für hardware, lizenzen und wartung der wegfällt.


ich persönlich würde den sql und möglichst viele der anderen dienste in einem emc co-standby oder doubletake gespiegelten cluster betreiben.

sbs => zusätzlichen dc installieren

file => mit sql auf einem cluster betreiben

windows client => verlagerung der db auf den cluster sofern möglich, image backup mit windows boardmittel einrichten. die frage der "datensicherheit" sollte sich eigentlich nicht stellen, oder gibts kein backupkonzept?

sco kiste => abhängig von den diensten auf einen linux cluster migrieren. im idealfall lässt sich die lösung auch komplett auf den windows cluster verlagern und die umgebung wird nochmals einfacher. die frage der datensicherheit sollte sich nicht stellen, oder gibt es kein backupkonzept?

Tach Zusammen

@Continum: Echt? Und das kriege ich installiert? Auf meiner Arbeitsmaschine habe ich es noch nicht geschafft in eine VM die unter VmWare Workstation läuft, ebenfalls VmWare Workstation zu installieren. Ging davon aus, dass es dann auch unter Xen nicht gehen würde.

Wens recht gut funktioniert, warum sollte man es nicht tun?

@Gerhard: Keine Angst. Die sind schon getrennt. Seit 2008 bekommt man ja bei der Premium-Variante eine Extra Server Lizenz hinzu. Wäre sonst mit Exchange und allem anderen zusammen auf einem Core wohl doch etwas naja unterdimensioniert.
Zusätzlich noch ein physischer Domänencontroller BDC der zugleich als Fileserver für alles sekundäre + private Daten der Inhaberfamily dient.

Daher finde ich persönlich nur die Unix-Variante etwas abenteuerlich. Umbiegen lässt sich da nix, Umgebung ist vom Software-Hersteller so vorgeben. Ist ein kleiner Zweig unserer Firma. Muss halt irgendwie einigermassen vernünftig laufen.

Die zusätzlichen Kosten liegen bei der Marathon Variante bei 5k Euro. DoubleTake bin ich etwas skeptisch. Ist aber auch nicht wesentlich billiger. Da brauche ich ziemlich teure Lizenzen für den SQL, weil dieser nicht mehr über eine SMB-Lizenz abgedeckt wird. Auch brauche ich dann vier teure, vollausgerüstete physische Maschinen anstelle von zwei. Synchron ist es nicht, nur asynchron. Alle brauchen eh nur ein Teil der Leistung, fressen aber ganzen Strom. Sprich Servertechnsich fast doppelte Anschaffungskosten. Diese Variante hatte ich als erstes geprüft und für unsinnig gehalten. Rechne ich noch die Arbeitsmaschien hinzu, wären wir bei deren sechs. Sinnig wird das erst mit TimeData, das ist sogar etwas, dass ich zusätzlich in Betracht ziehen würde.

SQL-Lizenzen für Cluster-Betrieb sind auch nicht günstig. Für das was Marathon kostet, bekomme ich noch nicht mal eine einzige SQL-Lizenz die Clusterfähig ist. Und auch Cluster sind nicht unbedingt unkomplex wenn etwas ausfällt. Auch sie brauchen einen gemeinsamen Speicher. Hier wäre nur Replikation ein gangbarer weg. Auch nicht ubedingt trivial in Ausfallsituationen.

EDIT: Die Workstation mit DB. Nun, die DB ist irgend eine Objektorientierte. Alleine die Lizenzgebühren für das Ausführen der DB auf einer andere Maschine als die Arbeitsmaschine sind jedoch schon unverhältnissmässig teuer, vor allem wens nicht gebraucht wird. Will gar nicht wissen was es koste - wenn üherhaupt möglich - dies auf einem Cluster zu tun. Da scheint mir ein simples spiegeln mit VmWare oder Xen doch viel einfacher und weniger anfällig als eine komplexe Clusterstruktur.

Backupkonzept gibts natürlich schon. Das letzte woran ich sparen würde. Ich leide - auch wegen Vorfällen in der Vergangenheit - an Datensicherheitsparanoia, lieber doppelt und dreifach gesichert. Aber Restores sind je nach dem immer mühsam und mit mehr oder weniger Arbeit und auch Risiken verbunden. Kann man sie von vornherein möglichst ausschliessen, um so besser. 100%ig Sicherheit hat man nie, ich bin bestrebt, sie möglichst gut zu erreichen, mit Mitteln die ein KMU zu Verfügung hat.

Mal was anderes... was sagen die $Vendor/Microsoft Lizenzen zum Thema Marathon und VMware FT? Das Ding laeuft 2x zur gleichen Zeit auf unterschiedlichen Hosts und gehoert somit 2x lizenziert.

Um nochmal den Bogen zu VMware zubekommen.

2x 1 Sockel Hosts mit VMware FT
1x SAN Melody welches mit 2 DataCore Servern virtualsiert wird und entsprechends lokales Storage als iSCSI Target bereitstellen. Also Quasi das was du mit Starwind machen wolltest nur diesmal mit halbwegs Hand und Fuss. Die kleinste Version sollte da ja ausreichen. Das supportet der Hersteller sogar.

Gruss
Joerg

Hallo Joerg, guter Input.

Zu den Lizenzen: Nun das ist durchaus eine gute Frage.

Stellt sich die Frage ob dann sogar der SMB sich selbst runterfahren würde, weil er einen zweiten erblickt... Das wäre die schlechteste Variante. Die Lizenzierung an sich wäre ja beim SMB noch bezahlbar.

Werde mich mal schlau machen bei den MS-Jungs. Das wäre ja vermutlich auch bei VmWare FT ein Problem oder?


Zum Vorschlag: Wie genau meinst du das? so?
- 2x Host für alles
- Datacore jeweils als VM auf beiden Hosts laufen lassen, als eigenständige VM
- Die drei Maschinen (SMB 2008, SQL + evtl. Unix) jeweils innerhalb eines solchen Targets laufen lassen, jeweils als FP.

Klingt eigentlich gar nicht so übel wenn dies tatsächlich supportet ist. Fragt sich nur, ob dies dann für die Primärmaschinen auch Performant rennt. Jeweils auch separate Nics für Mirror-Traffic? Direktverbindung?

Könnte man in Hinblick auf Erweiterung mit Clients auch 2 Sockel Boards verwenden und nur einen bestücken ohne das VmWare mault oder wäre es dann sinnvoller, grössere CPU's zu verbauen, welche mit den verbleibenden Kernen möglichst alle Maschinen bedienen können?

UrsDerBär hat geschrieben:Zum Vorschlag: Wie genau meinst du das? so?
- 2x Host für alles
- Datacore jeweils als VM auf beiden Hosts laufen lassen, als eigenständige VM
- Die drei Maschinen (SMB 2008, SQL + evtl. Unix) jeweils innerhalb eines solchen Targets laufen lassen, jeweils als FP.

FP?.
Ich meine das Konstrukt welches du mit Starwind schon realsieren wolltest. Jeweils auf jedem Hosts eine VM mit dem Kram damit man ein ausfallsicheres iSCSI SAN realisiert. Da Datacore dies in der Standardkonfig schon so vorsieht, mit einer direkt Verbindung zwischen den 2 "Heads", laesst sich das 1:1 uebertragen in die virtuelle Welt. Performance Wunder darf man nicht erwarten aber die HEADs wuerden aus dem Cache (Wenn die Daten auch beim Secundary HEAD angekommen sind) Antworten und den I/O Sammeln um ihn dann auf die Platten zuschreiben.

Klingt eigentlich gar nicht so übel wenn dies tatsächlich supportet ist. Fragt sich nur, ob dies dann für die Primärmaschinen auch Performant rennt. Jeweils auch separate Nics für Mirror-Traffic? Direktverbindung?

Könnte man in Hinblick auf Erweiterung mit Clients auch 2 Sockel Boards verwenden und nur einen bestücken ohne das VmWare mault oder wäre es dann sinnvoller, grössere CPU's zu verbauen, welche mit den verbleibenden Kernen möglichst alle Maschinen bedienen können?

Ja du kannst nen DUAL Server kaufen und den nur miteiner CPU dann betreiben. vSphere sieht dann auch nur diese eine CPU.

Gruss
Joerg

Hi Joerg,

Sorry, Tippselfehler, meinte natürlich FT und nicht FP.

Dann habe ich das soweit richtig verstanden, denke ich. Damit würden dann aber alle VM's innerhalb eines solchen Mirror-Target laufen. Das Starwind-Konstrukt wollte ich ja nur für die Unix-Maschine.

Vielleicht könnte man ja die Disks dem Datacore direkt durchreichen, dann wäre es vermutlich auch performanter oder? Dazu dedizierte Nics für diese Spässe.

Werde mal genau ausrechnen wie viel teurer diese Variante im Endeffekt wäre und auch zwei einfache, separate Maschinen prüfen. Überschlagsmässig wirds aber schon ziemlich heftig.

Grüsse und Dankeschön

Hallo Zusammen,

Nach eingehender Beratung kamen wir zum Schluss, dass wir eine VmWare Variante mit gemeinsamen Speicher in Angriff nehmen werden.

Feuer werden mir mittels Backup sichern. Zusätzlich werden wir die Software umprogrammieren damit die nur einmalig erfassbaren Daten jeweils an zwei Orten abgelegt werden. Gibt dann zwar massig Einpflegungsaufwand, aber der Eintretungsfall ist ja nicht so wahrscheinlich.

Die Vorteile insgesamt überwiegen und VmWare wird wohl in Zukunft auch nicht schlafen.

Was noch bleibt:
- Wo kaufen? Direkt bei VmWare oder beim Serverausrüster (war hier nicht was, dass man immer erst über den muss?) Oder über einen Wiederverkäufer? Was empfiehlt sich am besten?
- Lohnt Platinum-Support?
- Was für ein gemeinsamer Speicher? SAS mit Multipath-> Wie wird das gelöst? (3Gbit), iSCSI (1Gbit) oder FC (4Gbit)?
- Wieviel Einfluss hat die Cache-Grösse des StorageControllers in einer VmWare Umgebung? Sprich macht es sich bemerkbar ob man 1GB oder 2GB nimmt?
-- >Wenn FC, dann würde ich Direkt-Verbindung wollen, ohne Umweg über Switch. Switches käme nur dazu, wenn irgendwann ein Dritter ESX hinzukommen würde.

Wenn wir so oder so Softwareanpassungen vornehmen, bleibt die Frage, ob dann sogar HA mit den Essentials reichen würde?!? Oder anders formuliert, wie robust sind die Exchange und SQL Datenbank auf "Strom-Weg" wenn der Server crasht?

Grüsse und nochmal Dankeschön für die Inputs & Vorschläge

Machmal bitte einen neuen Thread auf, weil so richtig passt das nun nicht mehr zu Thema.

1. Kaufen sollte man nur das was auf der HCL steht. Aonsten solle mich sich das genu Ueberlegen und auch der Vorgesetzte sollte das akzeptieren. (DIe Konzequenz)
2. Kaufen tust du bei dem VMware Partner deines Vertrauen (Finger heb!) oder beim Server Anbieter
3. iSCSI hat das an Bandbreite was dein Ethernet so hergibt... 10Gbit ist moeglich... aber viele Geraete gibts da noch nicht. Die Aussage meines Anbieters war die "Soviel Spindels wollen sich doch noch garnicht kaufen damit man 10Gbit fuettern kann". Aus diesem Grunde haben die Kisten hier 4x1Gbit. Wenn man im VMware Umfeld sich tummelt dann ist das Random I/O bei kleiner Blocksize.
4. Cache spielt eine Grosse Rolle sofern er Batterie gepuffert ist
5. Shared DAS/SAS kenne ich jetzt so nicht. Auch das Konstrukt ein FC SAN von beiden Kontrollern ueber Kreuz an jeden ESX anzuschliessen finde ich befremdlich und ich weis nicht ob ESX das als SHARED ansieht.... vorstellen koennte ich mir das aber schon.

Neuartige Backupprodukte von VEEAM und Vizioncore benutzen die neue vStorage API und so Dinge wie De-Duplication und *Changed Block Tracking*. Das heist eine Inkrementale Sicherung ist fix gemacht sofern sich nicht soviel geaendert hat. Einige der Produte koennen das Backup auf einem 2. ESX/Datastore ablegen so das man im Falle der Faelle die VM, welche auch schon unter einem anderen Namen angelegt wurde, wieder in Betrieb nehmen kann.

Hmmm einen Punkt hatte ich noch... aber ich habs vergessen

Gruss
Joerg

Dein Wunsch mit allen Daten an 2 Standorten.
Wäre das vielleicht mit den Dell Equalogics machbar ? Stichwort: Auto-Replication? http://www.dell.com/downloads/global/pr ... debook.pdf

Supi hat geschrieben:Dein Wunsch mit allen Daten an 2 Standorten.
Wäre das vielleicht mit den Dell Equalogics machbar ? Stichwort: Auto-Replication? http://www.dell.com/downloads/global/pr ... debook.pdf

Der Nachteil bei der Geschichte ist das man 2 Arrays davon braucht

Die herunter geschnuerte Version welche da PS4000 lautet geht mit einem Kontroller und 8 Platten bei 11k los. Das die Anzahl von Verbindungen/Snapshots kuenstlich limitiert worden sind ist nicht das Problem... gerade im VMware Umweld gewichtet das nicht sehr stark.

Was man aber bei jeder Volume Replication hat ist das ESX Problem das er die LUN als Snapshot erstmal erkennt und man haendisch bzw. Script gesteuert im Fall der Faelle was machen muss. Also so ein transperenter FailOver ist das erstmal nicht.

Wie haben hier 2x PS5000E Equallogics und sind damit sehr zufrieden. Die laufen in einer Gruppe und "spannen" die LUN auch ueber beide Arrays.


Gruss
Joerg