Hallo Jones,
ich hatte in dem einen verlinkten Thread hier schon einiges dazu geschrieben. Daher fasse ich mich zu deinen konkreten Fragen etwas kürzer und gebe danach noch mal allgemein ein paar Punkte an:
Fragen:
zur Virit. Installation von INVESTOX .... funzt das ohne Probleme oder ist es sicherer/besser/stabiler/schneller INV nur direkt auf C: zu installieren - wie gehabt?
Das ist kein entweder / oder. Bei mir funktioniert das unter Vmware vSphere und unter Microsoft Hyper-V ohne Funktions(!)probleme und völlig stabil. Schneller ist es natürlich, auf die Virtualisierung zu verzichten. Ob das dann auf C: oder D: installiert wird, hat damit nix zu tun - bei der Virtualisierung übrigens auch nicht. Ob das BESSER ist, kann man so nicht sagen. Das ist am Ende eine Bewertung, die auf deine persönliche Situation hin vorgenommen werden muss. Siehe dafür den allgemeinen Teil unten.
Vor- oder Nachteil bzw. Sinnhaftigkeit der Virtualisierung von Inv wenn eh ein "RAID10" dahinter ist ?
Der Hypervisor, den du verwenden möchtest, der muss das RAID10 performant ansprechen können. Kann er das nicht, dann bleibt von dem RAID1 nix übrig. Das wirst du probieren müssen und sowas kostet Zeit und Einarbeitung. Generell würde ich mal hinterfragen wollen, ob die Plattengeschwindigkeit in deinem Szenario tatsächlich so kritisch bzw. ein limitierender Faktor ist.
Leistungsfähikeit und optimale Nutzung der CPU Kerne für max Performance von Investox im Vergleich "Virtuelle- VS. Herkömmlicher" Installation ?
Tja, das ist eine spannende Frage. Ich hatte auf meinem Server bisher Vmware vSphere 5.1. Da war die Performance gefühlt in Ordnung, wobei ich klarstellen möchte, dass mir der Vergleich zur ich nenne es mal Direktinstallation fehlt. Neulich habe ich auf Microsoft Hyper-V migriert, weil der in der kostenlosen Version einfach mehr kann (siehe unten). Und da laufen bei mir die Anwendungen 1. gefühlt und 2. auch messbar langsamer! Das nervt micht so, dass ich wohl auf vSphere zurückmigrieren werde, wenn der freie 6er erscheint. Näheres unten.
Was ist wenn ich mehrere Instanzen betreiben muß?[*]Wie ist das dann mit den extern programmierten Indikatoren?
Mehrere Instanzen innerhalb der gleichen virtuellen Maschine? Dann brauchst du nix weiter zu beachten. Mehrere Instanzen auf verschiedenen virtuellen Maschinen brauchen mehrere Lizenzen.
Zugriff via Teamviewer, VNC... mit Problemen behaftet oder nicht?
Ich greife per Windows RDP zu und das funktioniert ohne Probleme.
Was gäbe es noch zu behirnen auf das ich jetzt noch nicht gedacht habe? ]Mich würde Eure Erfahrung / Meinung zu iesem Thema bzw. zu den oben angeführten Punkten interessieren.
So, jetzt wird es spannend
Grundsätzlich gilt: Du machst hier eine Baustelle auf und zwar keine kleine!
Ich selbst sehe den wesentlichen Vorteil der Virtualisierung bei den Backups, Replikation oder gar im Clustering. Wenn deine Serverhardware die Grätsche macht, dann spielst du die virtuelle Maschine auf einem anderen Server auf und kannst quasi sofort loslegen. Quasi deshalb, weil du natürlich Lücken in der Kursversorgung hast und weil am Ende dann doch nicht alles so einfach ist, wie auf dem Papier. Ich weiß z.B. nicht, ob die Online-Lizenz von Investox die dann notwendiger Weise stattfindende Änderung der IP-Adresse überlebt (sollte sie besser, denn man kann heute nicht voraussetzen, dass eine IP-Adresse statisch ist). Wenn du Replikation eingerichtet hast, dann wird jede Änderung des Hauptrechners mit wenigen Sekunden Verzögerung in eine schon bestehende zweite (oder sogar dritte) aber ausgeschaltete virtuelle Maschine (sinnvoller Weise auf einem anderen Server) nachgezogen und du hast dann kaum Verluste bei einem Crash). Wenn du Clustering konfiguriert hast, dann geht alles sofort zur 2. virtuellen Maschine und die ist schon gestartet und kann übernehmen, ohne dass man sie wie Replikation erst hochfahren müsste. Bei der Replikation kann die zweite Hardware in einem ganz anderen Rechenzentrum (oder bei dir zu Hause) stehen. Beim Clustering sollte das besser sehr nahe dran sein. Wie viel Performanceverlust beim Clustering auftritt, kann ich dir allerdings nicht sagen. Vom Prinzip her würde ich das bei der Replikation für sehr gering halten, aber gemessen habe ich das nicht.
Ein weiterer Vorteil ist, dass du auf der gleichen Hardware noch weitere Rechner laufen kannst. Ich habe z.B. noch einen kleinen Linuxserver drauf, der kleiner Administrationstätigkeiten übernimmt. Du könntest auch Produktion und Entwicklung bzw. Test auf der gleichen Hardware aber sauber getrennt laufen lassen. Der Produktion gibst du hohe Priorität, damit diese die CPUs bekommt, wenn sie die braucht. Wenn sie die nicht braucht, laufen in der Entwicklung die langlaufenden Backtests. Klar dürfte sein, dass in so einem Szenario die Ausführungsgeschwindigkeit in Prod nicht mit der Direktintallation auf der Hardware mithalten können wird. Die Frage wird dann sein, ob die Prod "schnell genug" ist.
Replikation und Clustering muss man bei Vmware vSphere kaufen und das wird gleich teuer. Bei Microsoft Hyper-V ist das alles in der kostenlosen Version drin. Hyper-V kann auch Trim-Kommandos aus der virtuellen Umgebung an den Hypervisor und damit an die echte Platte durchreichen. Eine SSD weiß ja nix von der Virtualisierung und wird ohne Trim-Kommandos ja doll im Kopp! Das ist übrigens auch bei RAID-Controllern zu prüfen, wenn da SSDs dran hängen!
Blöd unter Hyper-V: Das nutzte mir nix, denn die SSD wurde genauso schnell angesprochen, wie mein RAID1 mit herkömmlichen Platten. Performancegewinn durch SSD gleich 0! Erst als ich die SSD per PassThrough direkt an die virtuelle Maschine durchgereicht habe, ging die ab wie ein Turnschuh. Nur: Dann habe ich das Trim-Kommando direkt aus der VM an die Platte und das eben genannte Feature wird gar nicht verwendet. Bei vSphere habe ich die SSD aus diesem Grund übrigens auch als physical Device angebunden (nicht zur Verwechseln mit Direct-IO. Wenn dir das nichts sagt => sagte ich schon, dass du hier eine Baustelle vor dir hast? ;-)
vSphere kann auch USB-Ports an eine virtuelle Maschine durchreichen. Dann könnte (ich habe es nicht getestet) man die Lizenz auch über ein Dongle an die Maschine binden. In dem Fall ist der Nutzen von Replikation und Clustering natürlich insoweit begrenzt, als dass man dann auch eine getestete(!) Lösung für die Lizenz in petto haben muss.
Microsoft Hyper-V installierst du quasi wie Windows Server (die meisten Windows-Server bringen sogar Hyper-V mit und dann hast du auch gleich eine bestimmte Anzahl von Windowslizenzen für die VMs dabei). Grundsätzlich geht das auch mit Windows 8, aber dann brauchst du extra Lizenzen für das Windows in der oder den VMs. Hyper-V Server (was ein eigenständiges Produkt ist und in dieser Hinsicht nicht mit dem Hyper-V von Windows Server verwechselt werden sollte, ist sogar kostenlos und von der Funktionalität nicht eingeschränkt. Man hat allerdings keine vollwertige grafische Oberfläche, das ist eher so wie Windows Server Core. Und zu guter Letzt ist es noch so, dass der Hyper-V in dem bezahlten(!) Windows 8 weniger kann, als der kostenlose Hyper-V Server (weiß der Geier warum). Der Hyper-V in Windows 8 kann z.B. keine Replikation.
Wenn du dich nun dazu entscheidest, lieber Vmware vSphere zu nehmen, dann lies mal besser weiter ;-) Bzw. lies mal die Installationsanleitung und schau dir an, ob du dir das geben willst. Der konfiguriert sich wieder ganz anders, als du es von Linux oder sowieso von Windows gewohnt bist. Und wenn du Hardware hast, die von Vmware nicht (mehr) unterstützt wird, was dir z.B. bei der Netzwerkkarte sehr schnell passieren kann, dann installiert der sich nicht. Da musst du dann mit Drittanbietersoftware ISO-Files patchen, damit die Treiber alle da sind. Das ist auch der (oder ein?) Grund, warum alle so auf der Hardware Compatibility List (HCL) von Vmware rumreiten.
Das schöne bei vSphere ist aber wiederum, dass der ziemlich schlank ist und man ihn auch auf einem USB-Stick installieren kann. Das kann in dem ein oder anderen Szenario interessant sein. Die Konfigurationstools von vSphere unterscheiden sich in zwei Klassen: den C# Client, der kostenlos ist, nicht alles kann was die aktuellen vSphere-Versionen unterstützen und sehr schnell ist. Und dann gibt es den Web-Client, der alles kann, sehr langsam ist und extra Geld kostet und sogar eine eigene VM zur Installation braucht... Ich habe am Ende die Konfiguration von Hand mit einem Texteditor geändert - sicher nicht jedermanns Sache.
Updates spielst du in Hyper-V genauso ein, wie bei Windows gewohnt, denn die kommen über Windows Update. Bei vSphere ist das wieder nicht so einfach. Generell sollte der Server - und darauf bin ich hier gar nicht eingegangen) aber gut abgeschottet vom Rest der Welt sein. Das gilt insbesondere für den Hypervisor! Insofern sind regelmäßige Updates hier nicht so kritisch sofern alles funktioniert.
So, das war jetzt mal kurz(!) das was ich zu zwei mir bekannten Hypervisoren sagen kann. Es gibt aber noch einige dutzend andere - ein großes Feld zum Experimentieren ;-)
Grüße
Pax Romana