OhNoIKilledMyHD
Lieutenant
- Registriert
- Sep. 2010
- Beiträge
- 767
Wie am günstigsten 32 GB ECC Memory?
- Ersteller Medione
- Erstellt am
D
DunklerRabe
Gast
Wie bei vielen Komponenten aus dem Bereich ist die Verfügbarkeit halt nicht so brilliant, man kriegt es aber und es gehört noch zu den besser verfügbaren: http://geizhals.at/de/521405
Ok, dann ist C32 auch nicht interessant (offensichtlich braucht man da 2 CPUs für 8 RAM Sockets).
G34 und 2011 Xeon liegen zu dicht beieinander, da greife ich natürlich zu Intel.
Folglich sähe die Config so aus:
MB: X9SRA 290 Euro
CPU: E5 1620 290 Euro
RAM: 4x http://geizhals.at/570292 .. ist der ok?
Bitte nochmal absegnen, dann bestelle ich
Danke für eure Hilfe!
PS: Sehe gerade, dass das MB noch nirgendwo lieferbar ist. Ich kann aber auch noch etwas warten..
G34 und 2011 Xeon liegen zu dicht beieinander, da greife ich natürlich zu Intel.
Folglich sähe die Config so aus:
MB: X9SRA 290 Euro
CPU: E5 1620 290 Euro
RAM: 4x http://geizhals.at/570292 .. ist der ok?
Bitte nochmal absegnen, dann bestelle ich
Danke für eure Hilfe!
PS: Sehe gerade, dass das MB noch nirgendwo lieferbar ist. Ich kann aber auch noch etwas warten..
Zuletzt bearbeitet:
D
DunklerRabe
Gast
Klar, der Ram ist ok!
Ich würde wegen dem Board mal bei www.sona.de anfragen.
Deren Supermicro Sortiment ist sehr umfangreich, bei den Single Sockel 2011 Platinen ist das X9SRA aber noch nicht dabei. Allerdings ist die Chance durchaus da, dass die es sowieso in ihr Sortiment aufnehmen werden und da kann es nicht schaden schonmal vorab anzufragen.
Ich würde wegen dem Board mal bei www.sona.de anfragen.
Deren Supermicro Sortiment ist sehr umfangreich, bei den Single Sockel 2011 Platinen ist das X9SRA aber noch nicht dabei. Allerdings ist die Chance durchaus da, dass die es sowieso in ihr Sortiment aufnehmen werden und da kann es nicht schaden schonmal vorab anzufragen.
Hi,
dass man bei C32 fuer 8 Sockel 2 CPUs braucht, wurde ja schon gesagt. Wenn man in diese Groesse gehen will, lohnt C32 nicht mehr, wie ihr oben ja schon berechnet habt. C32 waere nur sinnvoll, wenn 4 Slots und 32 GB reichen. Einzig denkbar waere, eine C32 Dualplatine jetzt mit einer CPU und 4 Speicherriegeln zu bestuecken und spaeter die zweite CPU + RAM nachzustecken.
RAM-Speed: Wie ich schon schrieb, ist da 2011 deutlich im Vorteil, weil auch mit 2xQR nur unwesentlich langsamer.
Na... 2 Grafikkarten in einem Board, 2 Maeuse, 2 Tastaturen, 2 Monitorsaetze und dann Linux so laufen lassen, dass zwei unabhaengige X-Instanzen die beiden Arbeitsplaetze bedienen koennen. "Nativ", weil dabei keine Virtualisierung beteiligt ist, sondern alles direkt auf dem Rechner laeuft. Du wolltest aehnliches ja per Durchreichen der Grafikkarten aufbauen (was durchaus heikel sein kann). Fuer Windows gibt es sowas wie meins auch... das heisst dann Microsoft Multipoint Server.
Viele Gruesse,
Jan
dass man bei C32 fuer 8 Sockel 2 CPUs braucht, wurde ja schon gesagt. Wenn man in diese Groesse gehen will, lohnt C32 nicht mehr, wie ihr oben ja schon berechnet habt. C32 waere nur sinnvoll, wenn 4 Slots und 32 GB reichen. Einzig denkbar waere, eine C32 Dualplatine jetzt mit einer CPU und 4 Speicherriegeln zu bestuecken und spaeter die zweite CPU + RAM nachzustecken.
RAM-Speed: Wie ich schon schrieb, ist da 2011 deutlich im Vorteil, weil auch mit 2xQR nur unwesentlich langsamer.
Na... 2 Grafikkarten in einem Board, 2 Maeuse, 2 Tastaturen, 2 Monitorsaetze und dann Linux so laufen lassen, dass zwei unabhaengige X-Instanzen die beiden Arbeitsplaetze bedienen koennen. "Nativ", weil dabei keine Virtualisierung beteiligt ist, sondern alles direkt auf dem Rechner laeuft. Du wolltest aehnliches ja per Durchreichen der Grafikkarten aufbauen (was durchaus heikel sein kann). Fuer Windows gibt es sowas wie meins auch... das heisst dann Microsoft Multipoint Server.
Viele Gruesse,
Jan
Jan, warum hältst Du das Durchreichen der Grafikkarte per VT-d für heikel? Ich habe eher Bedenken, dass die Zuweisung der USB Devices an die VMs durcheinander geraten könnte, da ich dieselben Geräte für jeden Platz verwenden möchte.
D
DunklerRabe
Gast
Durchreichen von Devices ist grundsätzlich eine schlechte Idee, wenn man einen ESX Cluster aufbaut. Da du das aber nicht machst steht dem eigentlich nichts im Weg.
Ob es so sinnvoll ist eine Grafikkarte durchzureichen wüsste ich jetzt auch nicht, vermutlich eher nicht. Das kann vielleicht Sinn machen, wenn die virtuelle Maschine die Grafikkarte z.B. zur Berechnung mitnutzen oder Spiele rendern soll.
Wenn ich aber nur virtuelle Arbeitsplätze erschaffen möchte, dann scheint das aber eher nicht die richtige Lösung zu sein. Da kann ich eher auf eine Citrix Umgebung o.Ä. zurückgreifen, oder, viel simpler, vom Arbeitsplatz über einen Thin Client per RDP auf die virtuelle Maschine gehen.
Ob es so sinnvoll ist eine Grafikkarte durchzureichen wüsste ich jetzt auch nicht, vermutlich eher nicht. Das kann vielleicht Sinn machen, wenn die virtuelle Maschine die Grafikkarte z.B. zur Berechnung mitnutzen oder Spiele rendern soll.
Wenn ich aber nur virtuelle Arbeitsplätze erschaffen möchte, dann scheint das aber eher nicht die richtige Lösung zu sein. Da kann ich eher auf eine Citrix Umgebung o.Ä. zurückgreifen, oder, viel simpler, vom Arbeitsplatz über einen Thin Client per RDP auf die virtuelle Maschine gehen.
Ja, die Lösung mit den Thinclients und RDP haben wir ja auch momentan.
Meine Idee, warum ich sie durch den Server ersetzen möchte, sind folgende:
- In den Anmeldungen stehen 2 Rechner dicht beieinander und es sind die wichtigsten Plätze, die wirklich immer funktionieren müssen
- Die Server haben sowieso soviel Power (insbesondere, wenn ich die Intellösung nehme), dass es wirklich total egal ist, ob noch 2 zusätzliche XP Instanzen darauf laufen.
- Bei der Thinclient Lösung gibt es Probleme, wenn eine der folgenden Teile ausfällt: Thinclient (2x), Switch, Server. Bei der Serverlösung ist es nur der Server selbst. Weniger Hardware, weniger Probleme..
Wenn man aus ESXi auch einen Client machen will, dann ist es zwingend notwendig, dass man die Grafikkarte an die virtuelle Maschine durchreicht (wie sonst soll etwas auf dem Bildschirm erscheinen?). Das hat weniger mit GPU Computing oder Spielen zu tun.
Meine Idee, warum ich sie durch den Server ersetzen möchte, sind folgende:
- In den Anmeldungen stehen 2 Rechner dicht beieinander und es sind die wichtigsten Plätze, die wirklich immer funktionieren müssen
- Die Server haben sowieso soviel Power (insbesondere, wenn ich die Intellösung nehme), dass es wirklich total egal ist, ob noch 2 zusätzliche XP Instanzen darauf laufen.
- Bei der Thinclient Lösung gibt es Probleme, wenn eine der folgenden Teile ausfällt: Thinclient (2x), Switch, Server. Bei der Serverlösung ist es nur der Server selbst. Weniger Hardware, weniger Probleme..
Wenn man aus ESXi auch einen Client machen will, dann ist es zwingend notwendig, dass man die Grafikkarte an die virtuelle Maschine durchreicht (wie sonst soll etwas auf dem Bildschirm erscheinen?). Das hat weniger mit GPU Computing oder Spielen zu tun.
D
DunklerRabe
Gast
Ehrlich gesagt, ich finde das sind keine gültigen Argumente. Was machst du denn, wenn der Server ausfällt? Du sagst zwar "Bei der Serverlösung ist es nur der Server selbst", aber ich finde das ist schon ein sehr großes "nur"!
Von der Leistung her hast du natürlich Recht, da sehe ich auch gar kein Problem.
Wenn diese beiden Arbeitsplätze aber so wichtig sind, dann musst du so oder so mit Redundanz arbeiten. Das würde auch für den Server gelten.
Ist mir natürlich klar, genau daher habe ich das ja erwähnt. Ich würde das nicht machen
Für deine Zwecke scheint mir das zu unorthodox, das kann man eben eher für andere Dinge nutzen.
Von der Leistung her hast du natürlich Recht, da sehe ich auch gar kein Problem.
Wenn diese beiden Arbeitsplätze aber so wichtig sind, dann musst du so oder so mit Redundanz arbeiten. Das würde auch für den Server gelten.
Ist mir natürlich klar, genau daher habe ich das ja erwähnt. Ich würde das nicht machen
Für deine Zwecke scheint mir das zu unorthodox, das kann man eben eher für andere Dinge nutzen.
Hi,
warum ist vt-d kritisch? Ich liefere dir mal ein paar Argumente:
Viele Leute nutzen ESXi.
Von denen nutzen einige PCI passthrough.
Von denen wiederum nutzen die meisten es fuer GPU-Computing oder das Durchreichen von Storage-Controllern.
Nur sehr wenige werden eine Grafikkarte in eine VM durchreichen, um sie da wirklich als Grafikkarte zu verwenden (von deren zwei ganz zu schweigen).
Von daher: Wenn da irgendwo Bugs drin sind, dann ist das etwas, das recht wenig getestet sein wird, vor allem, wenn du ein als "unsupported" laufendes Board nimmst. Du handelst dir also ein gewisses Risiko ein, Unstabilitaeten zu bekommen.
Ich habe mit PCI passthtrough unter KVM (Linux-Hypervisor) schon einiges ausprobiert. GPUs fuer diesen Zweck sind kritischer... unter KVM geht das nur aeusserst selten (andere Karten dagegen im Grunde immer). Sicher wird ESXi da weiter sein, die grundlegenden Probleme sind aber die gleichen.
USB-Komponenten: Wenn du die ueber den Pfad durchreichst (so macht KVM das), dann ist das kein Problem - ich wuerde dieses eher da sehen, wenn die Leute irgendwelche anderen USB-Dinge ranstecken.
Dazu kommt: Physischer Zugriff auf den Server, und das im Normalbetrieb! Das will man nicht, weil es das Risiko des Ausfalls deutlich erhoeht.
Unsinn. Du erzeugst ein deutlich hoeheres Risiko des Serverausfalls bei deinem Aufbau (s.o.), wohingegen der ganze Rest Dinge sind, die in 0,nichts ausgetauscht sind. Nimm einen hochwertigeren Switch - ich kann mich nicht erinnern, wann sowas bei uns das letzte Mal ausgefallen ist (und da liegt eine wesentlich hoehere Last drauf - z.B. 24 Studentenarbeitsplaetze, die ueber dieses Netz ihre Homeverzeichnisse bekommen usw.). Falls dir das nicht reicht... nimm zwei Switche und bau das Netzwerk redundant. Was die Thinclients angeht... warum kaufst du nicht einen in Reserve? Im Worst Case kann man den schnell austauschen, ohne dafuer Fachleute zu brauchen (das kannst du ja sogar so vorbereiten, dass jeder das hinbekommt, indem du die Adressen schon entsprechend eintraegst usw.). Wenn dein PCI passthrough runtergeht, dann musst du da ran und der ganze Laden steht, nicht nur ein oder zwei Plaetze.
Viele Gruesse,
Jan
warum ist vt-d kritisch? Ich liefere dir mal ein paar Argumente:
Viele Leute nutzen ESXi.
Von denen nutzen einige PCI passthrough.
Von denen wiederum nutzen die meisten es fuer GPU-Computing oder das Durchreichen von Storage-Controllern.
Nur sehr wenige werden eine Grafikkarte in eine VM durchreichen, um sie da wirklich als Grafikkarte zu verwenden (von deren zwei ganz zu schweigen).
Von daher: Wenn da irgendwo Bugs drin sind, dann ist das etwas, das recht wenig getestet sein wird, vor allem, wenn du ein als "unsupported" laufendes Board nimmst. Du handelst dir also ein gewisses Risiko ein, Unstabilitaeten zu bekommen.
Ich habe mit PCI passthtrough unter KVM (Linux-Hypervisor) schon einiges ausprobiert. GPUs fuer diesen Zweck sind kritischer... unter KVM geht das nur aeusserst selten (andere Karten dagegen im Grunde immer). Sicher wird ESXi da weiter sein, die grundlegenden Probleme sind aber die gleichen.
USB-Komponenten: Wenn du die ueber den Pfad durchreichst (so macht KVM das), dann ist das kein Problem - ich wuerde dieses eher da sehen, wenn die Leute irgendwelche anderen USB-Dinge ranstecken.
Dazu kommt: Physischer Zugriff auf den Server, und das im Normalbetrieb! Das will man nicht, weil es das Risiko des Ausfalls deutlich erhoeht.
Unsinn. Du erzeugst ein deutlich hoeheres Risiko des Serverausfalls bei deinem Aufbau (s.o.), wohingegen der ganze Rest Dinge sind, die in 0,nichts ausgetauscht sind. Nimm einen hochwertigeren Switch - ich kann mich nicht erinnern, wann sowas bei uns das letzte Mal ausgefallen ist (und da liegt eine wesentlich hoehere Last drauf - z.B. 24 Studentenarbeitsplaetze, die ueber dieses Netz ihre Homeverzeichnisse bekommen usw.). Falls dir das nicht reicht... nimm zwei Switche und bau das Netzwerk redundant. Was die Thinclients angeht... warum kaufst du nicht einen in Reserve? Im Worst Case kann man den schnell austauschen, ohne dafuer Fachleute zu brauchen (das kannst du ja sogar so vorbereiten, dass jeder das hinbekommt, indem du die Adressen schon entsprechend eintraegst usw.). Wenn dein PCI passthrough runtergeht, dann musst du da ran und der ganze Laden steht, nicht nur ein oder zwei Plaetze.
Viele Gruesse,
Jan
@Rabe: Wenn "nur" der Server ausfällt, dann steht das gesamte Netzwerk so oder so (egal ob ein Thinclient in der Anmeldung ist oder nicht). Die Ausfallwahrscheinlichkeit von Thinclient + Switch + Server ist einfach höher als von nur dem Server (der ja übrigens redundant vorhanden ist). Das "nur" bezog sich auch darauf, dass eben "nur" eine Komponente vorhanden ist, die kaputt gehen kann.
@Jan: Physikalisch hätte niemand Zugriff auf die Server. Sagt dir USM etwas? Das sind Möbel, die man sich selbst zusammenbauen kann, und ich wollte die Server fest in der Anmeldung verbauen (mit genug Luftzirkulation..). Wenn man an die Server heranmöchte, müsste man ein Blech herausschlagen. Bei den Clients könnte man praktisch nur die Bildschirme an und ausschalten. Sollte mal jemand einen Client versehentlich herunterfahren, wollte ich ein script schreiben, das alle paar Minuten checkt, ob das passiert ist, und die vm ggf. wieder startet.
Allerdings war mir nicht bewusst, dass GPUs aus irgend einem Grund anspruchsvoller beim Durchreichen sind als andere Devices (der Grund ist mir auch nicht ganz klar..). Es gibt ja auch solche USB Grafikkarten. Wäre das vielleicht sinnvoller?
Thin Clients sind übrigens schon als Reserve vorhanden
@Jan: Physikalisch hätte niemand Zugriff auf die Server. Sagt dir USM etwas? Das sind Möbel, die man sich selbst zusammenbauen kann, und ich wollte die Server fest in der Anmeldung verbauen (mit genug Luftzirkulation..). Wenn man an die Server heranmöchte, müsste man ein Blech herausschlagen. Bei den Clients könnte man praktisch nur die Bildschirme an und ausschalten. Sollte mal jemand einen Client versehentlich herunterfahren, wollte ich ein script schreiben, das alle paar Minuten checkt, ob das passiert ist, und die vm ggf. wieder startet.
Allerdings war mir nicht bewusst, dass GPUs aus irgend einem Grund anspruchsvoller beim Durchreichen sind als andere Devices (der Grund ist mir auch nicht ganz klar..). Es gibt ja auch solche USB Grafikkarten. Wäre das vielleicht sinnvoller?
Thin Clients sind übrigens schon als Reserve vorhanden
Zuletzt bearbeitet:
Hi,
Genau kann ich dir das auch nicht begruenden, ich weiss nur, dass KVM seit laengerem genau dabei haengt und es diverse Versuche gibt, das zu aendern. Es soll auch nicht ganz einfach sein, es dem Gast so zu verkaufen, dass er damit booten kann und die Karte als seine primaere sieht. Wie gesagt - meine Erfahrungen kommen von KVM, nicht ESXi. Ich denke aber, dass aus nachvollziehbaren Gruenden kaum jemand so etwas tut, so dass die Aussage, dass dies weniger gut getestet sein wird als alles andere, in jedem Fall gilt.
Was USB-Grafikkarten angeht... das ist schon fast eine Art kleiner Zeroclient. Ich wuesste nicht, warum man so einem Ding mehr trauen sollte als einem Thinclient, der keine beweglichen Teile beinhaltet. Am Ende koennte das vergleichbar sein.
Nein, eben nicht! Du vergleichst Aepfel mit Birnen! Ein headless ESX, der "nur" normale VMs betreibt, ist wesentlich weniger komplex in HW und SW als ein ESX, der 2 Grafikkarten enthaelt und die mitsamt Eingabegeraeten an die VMs durchreicht. Von daher ist die Ausfallwahrscheinlichkeit auch um einiges hoeher und obige Aussage unzutreffend. Thinclient und Switch sind ohne Unterbrechung des Betriebs rasch gewechselt.
Von einem SAN als Shared Storage habe ich bislang nichts gelesen, aber vielleicht habe ich das aber auch uebersehen. Damit hast du kein Hotswap, sondern musst wenigstens erst ein Backup aller VMs und Daten einspielen - das kostet VIEL Zeit (=downtime) und benoetigt dich. Einen Thinclient kann jeder wechseln oder du remote helfen.
Von daher muss der Server als einzige kritische Komponente so zuverlaessig wie moeglich sein.
Viele Gruesse,
Jan
Genau kann ich dir das auch nicht begruenden, ich weiss nur, dass KVM seit laengerem genau dabei haengt und es diverse Versuche gibt, das zu aendern. Es soll auch nicht ganz einfach sein, es dem Gast so zu verkaufen, dass er damit booten kann und die Karte als seine primaere sieht. Wie gesagt - meine Erfahrungen kommen von KVM, nicht ESXi. Ich denke aber, dass aus nachvollziehbaren Gruenden kaum jemand so etwas tut, so dass die Aussage, dass dies weniger gut getestet sein wird als alles andere, in jedem Fall gilt.
Was USB-Grafikkarten angeht... das ist schon fast eine Art kleiner Zeroclient. Ich wuesste nicht, warum man so einem Ding mehr trauen sollte als einem Thinclient, der keine beweglichen Teile beinhaltet. Am Ende koennte das vergleichbar sein.
Nein, eben nicht! Du vergleichst Aepfel mit Birnen! Ein headless ESX, der "nur" normale VMs betreibt, ist wesentlich weniger komplex in HW und SW als ein ESX, der 2 Grafikkarten enthaelt und die mitsamt Eingabegeraeten an die VMs durchreicht. Von daher ist die Ausfallwahrscheinlichkeit auch um einiges hoeher und obige Aussage unzutreffend. Thinclient und Switch sind ohne Unterbrechung des Betriebs rasch gewechselt.
Von einem SAN als Shared Storage habe ich bislang nichts gelesen, aber vielleicht habe ich das aber auch uebersehen. Damit hast du kein Hotswap, sondern musst wenigstens erst ein Backup aller VMs und Daten einspielen - das kostet VIEL Zeit (=downtime) und benoetigt dich. Einen Thinclient kann jeder wechseln oder du remote helfen.
Von daher muss der Server als einzige kritische Komponente so zuverlaessig wie moeglich sein.
Viele Gruesse,
Jan
D
DunklerRabe
Gast
Ich muss sagen, dass ich das ähnlich sehe!
Theoretisch reduzierst du zwar die Anzahl der Komponenten, die ausfallen können. Aber du schaffst dir ein Konstrukt mit so vielen neuen, potenziellen Fehlerquellen, sodass du im Endeffekt nichts gewonnen hast. Es ist sogar eher vom Gegenteil auszugehen!
Vorallem wird das Ausmaß eines Ausfalls dadurch erheblich größer!
Theoretisch reduzierst du zwar die Anzahl der Komponenten, die ausfallen können. Aber du schaffst dir ein Konstrukt mit so vielen neuen, potenziellen Fehlerquellen, sodass du im Endeffekt nichts gewonnen hast. Es ist sogar eher vom Gegenteil auszugehen!
Vorallem wird das Ausmaß eines Ausfalls dadurch erheblich größer!
Hi,
dann verstehe ich dein Konzept mit dem PCI passthrough noch weniger.
Fall 1: Server mit PCI passthtrough, Server faellt aus.
Der andere Server uebernimmt zwar, aber die beiden Arbeitsplaetze sind weg. Jemand muss die IO-Komponenten physisch an den anderen Server umstecken, was eine laengere Downtime zur Folge hat - selbst unter der Annahme, dass die Geraete so stehen, dass man wirklich nur umstecken muss. Hier koenntest du mit 2 KVMs (diesmal in der Bedeutung eines Keyboard/Mouse/Monitor-Umschalters) nachhelfen, aber die Sessions sind in jedem Fall weg, denn da du ein virtuelles NAS hast und kein echtes, kannst du die VMs nicht live migrieren.
Fall 2: Server OHNE PCI passthtrough + Thin Clients, Server faellt aus
Der andere Server uebernimmt. Sessions sind auch weg, aber nach einem Reconnect sind die Thin Clients wieder mit den VMs auf dem anderen Rechner verbunden und laufen weiter. Mit etwas Geschick geht das automatisch. Bezueglich Migrieren/Nicht migrieren gilt das gleiche wie oben.
Fall 3: Server OHNE PCI passthtrough + Thin Clients, Thin Client faellt aus
Neuen Thin Client nehmen, starten, Session reconnecten, weiterarbeiten.
Was sehen wir? Fall 2 ist weniger schlimm als Fall 1. Fall 3 ist absolut harmlos, da nur einen Arbeitsplatz betreffend und schnell und ohne Datenverlust reparierbar (sogar mitten in einer Eingabe!). Fall 1 ist aus den diskutierten Gruenden aber wahrscheinlicher als Fall 2, vermutlich sogar wahrscheinlicher als Fall 2 ODER Fall 3 (logisches ODER). Ich sehe da keinerlei Rechtfertigung fuer deinen Ansatz!
Wenn es das Budget hergeben wuerde, waere die Idealloesung uebrigens eine ganz andere: FreeNAS auf ZWEI echte Rechner (da reichen kleine CPUs) und ueber redundante Switches mit ZWEI plattenlosen ESXi draufgehen. Die NAS synchronieren wie gehabt. Im Fall eines NAS-Ausfalls muesste man wie jetzt auf das andere umschwenken und die VMs neu starten (es sei denn, die VMs machen Software RAID 1 ueber je 2 iSCSI-Volumes, die von je einem NAS kommen, dann laufen sie auch beim NAS-Ausfall weiter), im Fall eines ESXi-Ausfalls wird alles automatisch migriert. Vorteil waere, dass man die Server kleiner auslegen koennte, weil sie sich im Normalbetrieb, wenn also beide laufen, die Last teilen koennen und es im Fehlerfall nicht schlimm ist, wenn die VMs etwas langsamer laufen, weil sie swappen muessen. Dann wuerde man vermutlich mit einem E3 und 16 GB auch auskommen und koennte vom gesparten Geld das redundante NAS anschaffen (waere aber wohl doch etwas teurer).
Viele Gruesse,
Jan
dann verstehe ich dein Konzept mit dem PCI passthrough noch weniger.
Fall 1: Server mit PCI passthtrough, Server faellt aus.
Der andere Server uebernimmt zwar, aber die beiden Arbeitsplaetze sind weg. Jemand muss die IO-Komponenten physisch an den anderen Server umstecken, was eine laengere Downtime zur Folge hat - selbst unter der Annahme, dass die Geraete so stehen, dass man wirklich nur umstecken muss. Hier koenntest du mit 2 KVMs (diesmal in der Bedeutung eines Keyboard/Mouse/Monitor-Umschalters) nachhelfen, aber die Sessions sind in jedem Fall weg, denn da du ein virtuelles NAS hast und kein echtes, kannst du die VMs nicht live migrieren.
Fall 2: Server OHNE PCI passthtrough + Thin Clients, Server faellt aus
Der andere Server uebernimmt. Sessions sind auch weg, aber nach einem Reconnect sind die Thin Clients wieder mit den VMs auf dem anderen Rechner verbunden und laufen weiter. Mit etwas Geschick geht das automatisch. Bezueglich Migrieren/Nicht migrieren gilt das gleiche wie oben.
Fall 3: Server OHNE PCI passthtrough + Thin Clients, Thin Client faellt aus
Neuen Thin Client nehmen, starten, Session reconnecten, weiterarbeiten.
Was sehen wir? Fall 2 ist weniger schlimm als Fall 1. Fall 3 ist absolut harmlos, da nur einen Arbeitsplatz betreffend und schnell und ohne Datenverlust reparierbar (sogar mitten in einer Eingabe!). Fall 1 ist aus den diskutierten Gruenden aber wahrscheinlicher als Fall 2, vermutlich sogar wahrscheinlicher als Fall 2 ODER Fall 3 (logisches ODER). Ich sehe da keinerlei Rechtfertigung fuer deinen Ansatz!
Wenn es das Budget hergeben wuerde, waere die Idealloesung uebrigens eine ganz andere: FreeNAS auf ZWEI echte Rechner (da reichen kleine CPUs) und ueber redundante Switches mit ZWEI plattenlosen ESXi draufgehen. Die NAS synchronieren wie gehabt. Im Fall eines NAS-Ausfalls muesste man wie jetzt auf das andere umschwenken und die VMs neu starten (es sei denn, die VMs machen Software RAID 1 ueber je 2 iSCSI-Volumes, die von je einem NAS kommen, dann laufen sie auch beim NAS-Ausfall weiter), im Fall eines ESXi-Ausfalls wird alles automatisch migriert. Vorteil waere, dass man die Server kleiner auslegen koennte, weil sie sich im Normalbetrieb, wenn also beide laufen, die Last teilen koennen und es im Fehlerfall nicht schlimm ist, wenn die VMs etwas langsamer laufen, weil sie swappen muessen. Dann wuerde man vermutlich mit einem E3 und 16 GB auch auskommen und koennte vom gesparten Geld das redundante NAS anschaffen (waere aber wohl doch etwas teurer).
Viele Gruesse,
Jan
Hey, wollte mich mal zurückmelden, weil ich jetzt die Lösung seit einiger Zeit in Betrieb habe.
Auch wenn ich Jan meinen vollsten Respekt zolle, teile ich nicht seine Meinung seines letzten Beitrages. Ich habe nun folgende Lösung aufgebaut:
- esxi Server mit lokalem FreeNAS (RaidZ2 mit SSD Cache), Controller passthrough per VT-d
- Speicher per NFS vom lokalen FreeNAS gemountet
- FreeNAS spiegelt per ZFS Replication alle 15 Minuten die Daten auf einen identischen Rechner. Snapshots werden von den letzten 3 Tagen vorgehalten (zusätzliche Backups sind auch noch vorhanden)
- Terminal Server läuft als VM auf dem FreeNAS Storage
- Thin Clients sind per iSCSI angebunden, booten diskless ein XP und greifen per RDP auf den Terminal Server zu
- Die 2 Arbeitsplätze in den Anmeldung sind ebenfalls virtuelle Instanzen auf dem esxi Server. Die Bildschirmausgabe erfolgt per passthrough eines USB Controllers. An dem USB Controller hängen Keyboard, Mouse, Scanner und eine USB Grafikkarte. KVMs sind vorhanden.
Die Lösung funktioniert absolut stabil!
PS:
Theoretisch hätte man vermutlich sogar alle ThinClients durch folgendes ersetzen können:
http://www.yatego.com/cm3-computer/...werk-display-adapter-lan-usb-auf-dvi-vga-hdmi
Da diese "Grafikkarte" per LAN angeschlossen wird, braucht man auch kein PCI passthrough. Vielleicht probiere ich das mal aus, wenn noch ein Client ins Netz muss.
Auch wenn ich Jan meinen vollsten Respekt zolle, teile ich nicht seine Meinung seines letzten Beitrages. Ich habe nun folgende Lösung aufgebaut:
- esxi Server mit lokalem FreeNAS (RaidZ2 mit SSD Cache), Controller passthrough per VT-d
- Speicher per NFS vom lokalen FreeNAS gemountet
- FreeNAS spiegelt per ZFS Replication alle 15 Minuten die Daten auf einen identischen Rechner. Snapshots werden von den letzten 3 Tagen vorgehalten (zusätzliche Backups sind auch noch vorhanden)
- Terminal Server läuft als VM auf dem FreeNAS Storage
- Thin Clients sind per iSCSI angebunden, booten diskless ein XP und greifen per RDP auf den Terminal Server zu
- Die 2 Arbeitsplätze in den Anmeldung sind ebenfalls virtuelle Instanzen auf dem esxi Server. Die Bildschirmausgabe erfolgt per passthrough eines USB Controllers. An dem USB Controller hängen Keyboard, Mouse, Scanner und eine USB Grafikkarte. KVMs sind vorhanden.
Die Lösung funktioniert absolut stabil!
PS:
Theoretisch hätte man vermutlich sogar alle ThinClients durch folgendes ersetzen können:
http://www.yatego.com/cm3-computer/...werk-display-adapter-lan-usb-auf-dvi-vga-hdmi
Da diese "Grafikkarte" per LAN angeschlossen wird, braucht man auch kein PCI passthrough. Vielleicht probiere ich das mal aus, wenn noch ein Client ins Netz muss.
Zuletzt bearbeitet:
