25.08.2022

3761

Hyper-V Reboot Orchestrierung

Hallo zusammen,

wir haben diverse Hostsysteme mit Hyper-V als Virtualisierungsumgebung.
Die Hosts müssen natürlich auch gepatcht und ab und an neugestartet werden.
Ich würde das gerne etwas autarker gestalten, deswegen die Frage, ob jemand eine Art Start- und Shutdown-Orchestrierung für die VMs empfehlen kann.

Ich stelle mir das so vor, dass sich konfigurieren lässt, wer von wem abhängig ist (inkl. Prüfung beim Start ob zB Dienst y in VM z läuft, bevor die nächste VM gestartet wird).

Zweck soll explizit nicht Monitoring sein, sondern bspw. wenn die DCs vollständig hochgefahren ist, dann automatisch mit dem Exchange fortzufahren.

Ja, man kann mit Startverzögerung und Co arbeiten, aber das geht doch bestimmt auch schöner.

Bevor ich nun in Powershell vom Host in die VMs reinschaue und das selber alles zusammentrage, wollte ich einmal nach euren Erfahrungen fragen.

Gibt es soetwas?

Danke und Grüße

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3752957985

Url: https://administrator.de/contentid/3752957985

Ausgedruckt am: 22.11.2024 um 08:11 Uhr

36 Kommentare

Neuester Kommentar

Ja gibt es.
Wir unterscheiden das allerdings in mindestens drei Ebenen.

Hardware Patchen.
Cluster Patchen.
OS Patchen.

Du möchtest die Hypervisor patchen? Cluster Aware Updating schon Mal gehört?

Cluster Aware Update
Clusterfähiges Aktualisieren

Funktioniert anstandslos.

Aeh, nebenbei, Exchange? Da brauchst du dir keine Sorgen machen. Der wartet von selbst, bis der DC wieder da ist.

Zitat von @beidermachtvongreyscull:
Cluster Aware Update

Das benötigt jedoch die doppelte Anzahl an Lizenzen.

Hallo zusammen,

es handelt sich um Standalone Hosts an verschiedenen Standorten, keine Cluster. Die Redundanz wird durch die Rollenverteilung auf den VMs selbst hergestellt.

Hätte ich direkt dazu schreiben sollen.

Grüße

Zitat von @Jumanji:

Hallo zusammen,

es handelt sich um Standalone Hosts an verschiedenen Standorten, keine Cluster. Die Redundanz wird durch die Rollenverteilung auf den VMs selbst hergestellt.

Hätte ich direkt dazu schreiben sollen.

Grüße

Ui.
Das macht die Sache spannend.
Standalone-Hosts ohne weitere Ausfallsicherheit? Ist mutig. Ehrlich.

Schau mal hierauf:
https://www.zueschen.eu/hyper-v-failover-cluster-geplanter-shutdown-bei- ...

Ist zwar für einen Cluster gedacht, aber es ließe sich auf Einzelhosts umarbeiten.

Der Kollege hat da ein spannendes Script gebaut, um VMs runterzufahren.
Du könntest z.B. auf dieser Basis auch Windows.Update antriggern.

Wenn es Wurscht ist, in welcher Reihenfolge die VMs wieder hochkommen, ginge auch sowas:
Im Hyper-V-Manager entsprechend einstellen, dass sie wieder gestartet werden.

Wenn der HyperV Updates installiert und dann einen Neustart macht, sollte er die VMs pausieren/runterfahren und dann wieder hochfahren, sofern er das hinbekommt.

Ich hatte das auch schon, dass Dienste beim Runterfahren hängenbleiben und einen Tritt in den Hintern via Powershell brauchten.

Moin Jumanji,

wir haben diverse Hostsysteme mit Hyper-V als Virtualisierungsumgebung.
Die Hosts müssen natürlich auch gepatcht und ab und an neugestartet werden.
Ich würde das gerne etwas autarker gestalten, deswegen die Frage, ob jemand eine Art Start- und Shutdown-Orchestrierung für die VMs empfehlen kann.

Die Updates eines Hyper-V Nodes oder gleich Clusters zu automatisieren 😱, das willst du glaube ich nicht wirklich. Das ist meiner bisherigen Erfahrung nach, russisches Rollet mit Zeitschaltuhr.

Zu einem sauberen Hyper-V-System-Update gehören, wie unbelanglos es schon geschrieben hat,
ausser dem Einspielen der Windowsupdates, noch diverseste andere Schritte.

Die Firmwares der Server sollten mitaktualisiert werden, auch die von RAID-Controller, HBA’s, Netzwerkkarten & Co.KG. Und immer schön die entsprechenden ReadMe’s durchlesen, ob da nicht irgendein Feature dazugekommen ist, was du eventuell nicht haben möchtest oder eines gestrichen wurde, welches du wiederum noch benötigst.
Ich habe erst letzte Woche ein Intel-Server komplett aktualisiert und habe alleine für das Einspielen der 12 BIOS Versionen, über einen Manntag verbraten. 😭

Dann müssen natürlich auch die Treiber mitaktualisiert werden.
Bei einigen Herstellern, werden z.B. die Treiber der NIC’s beim Ausführen des Treibersetups keineswegs automatisch aktualisiert, sobald diese als Uplink an einem vSwitch hängen.🤢
Dann muss man die pNIC temporär aus dem vSwitch schmeissen, dann muss diese über den Gerätemanager deinstalliert werden. Danach die Hardwareerkennung laufen lassen, kontrollieren ob nach der Neerkennung der korrekte (neue) Treiber geladen wurde und wenn ja, dann kann man diese dem entsprechenden vSwitch wieder als Uplink unterjübeln.
Ja ich weiss, hört sich stressig an. 🤮
Zur Verteidigung … ist nicht auf meinem Mist gewachsen.

Dann müssen auch noch die ganzen VM’s gepatcht werden, aber ab hier kann man durchaus auf klassische Patchmanagement-Lösungen und oder WSUS zurückgreifen.

Wenn es nur darum geht, die Server in einer Bestimmten Reihenfolge Runter und rauffahren zu lassen, dann wirst du mit Power-Shell, wahrscheinlich am schnellsten an Ziel kommen.

https://www.windowspro.de/script/vms-hyper-v-einschalten-anhalten-herunt ...
https://docs.microsoft.com/en-us/powershell/module/hyper-v/start-vm?view ...
https://docs.microsoft.com/en-us/powershell/module/hyper-v/stop-vm?view= ...

Beste Grüsse aus BaWü
Alex

Mahlzeit.

Schwieriges Terrain.

Bin mit dem CAU zwei Mal auf die Fresse gefallen. Hat mich darin bestätigt, dass solche Aktionen eben nicht automatisch durchgeführt gehören. Gut, Cluster gibt' in meiner Umgebung eher selten, es kommen ähnlich wie bei dir nur Bleche, ggf. mit Replikation, zum Einsatz.

Ich habe mir folgendes Vorgehen angewöhnt; Updates kommen vom WSUS:
- Installation auf allen Windows-Maschinen starten, inkl. der Bleche
- VMs werden, sobald "Neustart erforderlich", über "Aktualisieren und Herunterfahren" ausgeschaltet
- Wenn alle VMs aus sind, werden die Bleche durchgestartet
-- Evtl. Treiber- und Firmware-Updates sind ein möglicher Zwischenschritt
- Wenn die Bleche sauber wieder online sind, werden die VMs (Abhängigkeiten beachten!) wieder gestartet

Optional:
- Bei Replika-Setup kann man, wenn längere Maintenance an einem Blech nötig ist, die VMs auf dem Replika-Host online nehmen, dann haben zumindest die User keine Downtime

Das ist so die "High Level Overview" - VMs starten bei uns niemals automatisch und werden, falls nicht vorher schon getan, beim Herunterfahren der Bleche ebenfalls heruntergefahren. Nicht gespeichert, sondern heruntergefahren.

Warum?
Wenn dein Blech nach nem Update "Schluckauf" hat und/oder der RAID-Treiber fleißig Platten aus den RAIDs kloppt, dadurch z.B. ein SQL-Server mehrfach hart abgeschaltet wird und du "mal eben" die WaWi/Finanzsoftware wieder an den Start bringen musst.... dann mach ich lieber ein paar Klicks mehr und keiner hat Stress.

Generell bin ich kein großer Freund von "Treiber-/Firmware-Update um des Updates Willen", gerade nicht bei Virtualisierungshosts und Storage-Systemen. Wenn es keinen zwingenden Grund für diese Updates gibt, werden die schlicht nicht installiert - was ein "zwingender Grund" ist, steht in den Release-Notes der Versionen und ist abhängig von deiner eigenen Sichtweise und/oder den Vorgaben/Ausstattung vor Ort.

Auch hier die Erklärung oder zumindest einer der Gründe dafür:
Jahre her, da war ich noch der Meinung: Geil, Treiber-/Firmware-Update, das wird beim nächsten Maintenance-Window eingespielt. Einer der Mitspieler: Broadcom-NICs im HyperV-Cluster-Node. NICs für LACP konfiguriert. Lief alles glatt, Cluster online, VMs liefen alle. Aber halt gefühlt 90% langsamer als vor dem Update. Problem: Der Broadcom-Treiber konnte mit unseren HP-Switches und LACP nix anfangen. Sowas steht halt nicht in Release Notes und Changelogs, schlicht, weil's vorher niemanden aufgefallen ist.

Es gibt also viele Abhängigkeiten und Fallstricke, und ja, es ist im Fehlerfall immer eine "Verkettung unglücklicher Umstände", die kein Mensch auf dem Schirm hatte. Wenn deine Infrastruktur fehlerfrei und performant läuft - lass die Finger weg von Updates, bloß weil die grad released wurden.

Die o.g. Schritte hab' ich teilweise auch in PowerShell-Skripts verpackt oder nutze Management-Systeme, wo vorhanden, um zumindest einen Teil davon zu automatisieren. Von einer "Vollautomation" bin ich lange weg - zumal ich mich ja auch nicht selbst "wegrationalisieren" will.

Cheers,
jsysde

Moin Jsysde,

Wenn deine Infrastruktur fehlerfrei und performant läuft - lass die Finger weg von Updates, bloß weil die grad released wurden.

"Never touch a running System" war vorgestern, sprich vor Internet.
Heute patcht man hauptsächlich nicht der Performance sondern der Sicherheit wegen.
Und Sicherheitsupdates hinauszuzögern, ist im Zeitalter der DSGVO-Wadenbeisserle, keine so gute Idee. 😉

Ich sag da jetzt nur Intel ME & Co.

Beste Grüsse aus BaWü
Alex

Servus @MysticFoxDE,

danke für die Belehrung, du hast meinen Post völlig falsch verstanden - ich gehöre zu denjenigen, die schon "seit immer" sagen, das "never change a running system" in der IT nix zu suchen hat. Welcher Zusammenhang jetzt aber zwischen nicht installierter Treiber-Updates, die nicht sicherheitsrelevant sind, mit der DSGVO besteht, will sich mir nicht erschließen.

Der von dir zitierte Satz aus meinem Posting bezieht sich explizit auf Infrastruktur: Switches, Router, Treiber von HyperV-Infrastruktur etc. "Weiche" Dinge wie eben ein laufendes Windows gehören nicht zur Infrastruktur und gehören natürlich zeitnah und immer wieder gepatcht.

Cheers,
jsysde

Moin Jsysde,

danke für die Belehrung

ich habe dir lediglich meine Erfahrung mitgeteilt, was du daraus machst ist deine Sache.

du hast meinen Post völlig falsch verstanden - ich gehöre zu denjenigen, die schon "seit immer" sagen, das "never change a running system" in der IT nix zu suchen hat.

Das hat sich für mich halt etwas anders angehört, sorry, wenn ich da was missverstanden habe.

Welcher Zusammenhang jetzt aber zwischen nicht installierter Treiber-Updates, die nicht sicherheitsrelevant sind, mit der DSGVO besteht, will sich mir nicht erschließen.

z.B. so was.
https://www.bsi.bund.de/SharedDocs/Warnmeldungen/DE/TW/2022/02/warnmeldu ...

Der von dir zitierte Satz aus meinem Posting bezieht sich explizit auf Infrastruktur: Switches, Router, Treiber von HyperV-Infrastruktur etc. "Weiche" Dinge wie eben ein laufendes Windows gehören nicht zur Infrastruktur und gehören natürlich zeitnah und immer wieder gepatcht.

Das sehe ich definitiv anders, auch die von dir aufgezählten Komponenten können kritische Sicherheitslücken enthalten, vor allem die Router und sollten ebenfalls wenn möglich, sehr zeitnah gepatcht werden.

By the Way, LACP (LBFO-Teaming) ist seit Server (Hyper-V) 2016 seitens Microsoft abgekündigt und wird seit dem auch nicht mehr supportet.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...

Beste Grüsse aus BaWü
Alex

Moin.

Ok, jetzt hol' ich kurz die Buntstifte raus und male es auf - damit es auch der letzte versteht:
Natürlich gehören _sicherheitsrelevante!_ Patches zeitnah eingespielt. Überall. Man muss sich schon viel Mühe geben, meine Posts dahingehend falsch zu verstehen.

Cheers,
jsysde

Ich rolle bei mir nur sicherheitsrelevante Patches für Windows aus.

Vielleicht bin ich rückständig, weil ich einen homogenen Windows Server 2016 Cluster auf Gen8-Hardware von HP betreibe, die Firmware nicht mehr weiterentwickelt wird und somit ggfs. Sicherheitslücken auch nicht mehr geschlossen werden und ich zum Administrieren Windows 10 1511 brauche, weil da auch noch ein Flashplayer drin ist.

Und zeitnah spiele ich Windowsupdates nicht mal ein. Vorallem auf den HyperVs nicht. Da warte ich mal drei Wochen bevor CAU die Updates draufhauen darf.

Der einzige Server, der adhoc Sicherheitsupdates installiert ist unser Exchange 2016. Das ist auch so erwünscht meinerseits, denn wenn MS mal wieder ein vergiftetes Update raushaut, hab ich nur eine Maschine auf Schnauze liegen und nicht alle.

Hinsichtlich Sicherheit wegen "veraltet hier veraltet da". Ist haltbar und bedarf keiner Diskussion.

Ich weiß folgendes:

Mein Cluster, so veraltet wie er sein mag, läuft in seiner jetzigen Konfiguration einfach rund.
Wenn ich Ersatzteile brauche, kriege ich die auf dem Gebrauchtmarkt für lau. Zusätzliche Gen8-Blades auch.
Ich betreibe meinen Cluster hinter einer aktuellen Firewall. Kein Dienst kommt einfach so raus und rein kommt nichts, außer MFA-VPN.
Meine Nutzer sind von mir dahingehend sensibilisiert worden und das wird regelmäßig aufgefrischt, dass sie maßgeblich zur Sicherheit des Ganzen beitragen. Das funktioniert wie ein Uhrwerk und ich finde es schön, dass ich mich auf meine Nutzer verlassen kann.

Wenn man um ein vermeintlich unsicheres System eine gehärtete Schutzwand aus Firewall und sensibilisierten Nutzern aufbaut, dann braucht sich aus meiner Sicht etwas weniger Sorgen zu machen.

Ein Cluster macht nur dann Sinn, wenn man da richtig Geld in die Hardware steckt und alles redundant auslegt. Ansonsten kann ein kurzer disconnect einer Ressource dir ganz leicht eine VMD schrotten, schon öfter erlebt, und dann geht erstmal das wiederherstellen an.

Standalone Hosts laufen für weniger Ressourceneinsatz stabiler, gerade in kleinen Umgebungen kann das sinnvoller sein. Und btw. einen HyperV Host updaten während die VMs laufen, ist gar kein Problem, die Maschinen werden gespeichert, und laufen nach dem Reboot einfach weiter. Hundert mal gemacht, nie ein Problem gehabt, zumindest mit Server 2016. Ich schedule den Reboot einfach ausserhalb der Arbeitszeit und gut is. Und wenn da tatsächlich mal ein Fehler auftreten sollte, fehlerhafter Patch oder ähnliches, dann hilft dir eine Automatisierung eh nix, dann musst du manuell ran, weil nie alle Eventualitäten davon abgedeckt sein können.

Man kann ja auch die Dienste redundant auslegen, so das auf jedem der Hosts eine VM läuft, die den Dienst anbietet, z.B. mit DFS, mehreren DCs und DNS, geclusterter Dienst (z.B. SQL oder Exchange). Dann kann ein Host ruhig mal kurz offline sein ohne den Betrieb zu stören.
Und wenn du was hast, das man nicht clustern kann, kann man es per Shared Nothing Live Migration auf einen anderen Host verschieben, auch nicht das Problem.

Ansonsten kann ein kurzer disconnect einer Ressource dir ganz leicht eine VMD schrotten, schon öfter erlebt, und dann geht erstmal das wiederherstellen an.

Nur, wenn du einen Datenträger übers Netzwerk mountest. iSCSI oder ähnliches. Normle VMs sind schmerzfrei.

Moin beidermachtvongreyscull,

ich zum Administrieren Windows 10 1511 brauche, weil da auch noch ein Flashplayer drin ist.

das brauchst du nicht wirklich.

Mann kann z.B. einen Chrom (Portable) mit ein paar Tricks wieder dazu bringen Flash wiederzugeben.

Im Netz gibt's dazu duzende Anleitungen.

https://superuser.com/questions/1616866/use-flash-player-after-12-jan-20 ...
https://www.reddit.com/r/flash/comments/luh7z2/portable_adobe_flash_that ...
https://www.stephenwagner.com/2021/01/13/enable-adobe-flash-chrome-after ...

Beste Grüsse aus BaWü
Alex

Moin NordicMike,

Zitat von @NordicMike:

Ansonsten kann ein kurzer disconnect einer Ressource dir ganz leicht eine VMD schrotten, schon öfter erlebt, und dann geht erstmal das wiederherstellen an.

Nur, wenn du einen Datenträger übers Netzwerk mountest. iSCSI oder ähnliches. Normle VMs sind schmerzfrei.

Kann ich nur bestätigen.
Heute morgen ist einem unserer Kunden sein Cluster hart abgeraucht, weil eine der USV's, die der Kunde eigentlich schon seit Jahren ersetzen wollte, kurzerhand den Dienst quittiert hat. 🤮
Auf der anderen Seite, selber Schuld, mehr als Warnen kann man als externer Berater ja (manchmal leider) auch nicht.

Na ja, auf jeden Fall laufen seine > 100 VM's, darunter diverseste DB Server, nun wieder ohne jegliche Probleme.
Und das ist zum grössten Teil, dem per SAS angeschlossenem SAN geschuldet.

Bei iSCSI Zielen, die wir früher überwiegend zu Backupzwecken verwendet haben, sah die Sache nach einem Clustercrash öfters etwas anders aus, vor allem bei Verwendung von ReFS. Da ist dann schon das eine oder andere Volume, mal komplett über den Jordan gegangen.

Beste Grüsse aus BaWü
Alex

Zitat von @NordicMike:

Ansonsten kann ein kurzer disconnect einer Ressource dir ganz leicht eine VMD schrotten, schon öfter erlebt, und dann geht erstmal das wiederherstellen an.

Nur, wenn du einen Datenträger übers Netzwerk mountest. iSCSI oder ähnliches. Normle VMs sind schmerzfrei.

Genau das macht man beim Clustering aber, sonst macht ein Shared Storage ja keinen Sinn. Ob SAS oder iScsi Anbindung ist relativ wurscht, wenn der Controller einen Schluckauf hat, kann sowas passieren. Treiberupdates sollte man deshalb nur machen, wenn grad gar nix auf dem Host läuft. Aber selbst, wenn die Hardware nicht das Problem ist, kann es passieren, das der Server mal kurz nicht mit dem Storage sprechen will.
Mittlerweile laufen z.B. unsere drei Exchange deswegen wieder direkt auf dem Host und alle haben die selben Datenbanken gemountet, je größer die VHDs werden, desto wahrscheinlicher ist, das sie mal kaputt gehen.
Macht in unserem Fall auch Sinn, weil man sonst die Software für jedes Blech, auf dem es theoretisch laufen könnte, nochmal lizenzieren müsste.

Genau das macht man beim Clustering aber, sonst macht ein Shared Storage ja keinen Sinn.

Kommt darauf an, wenn der Cluster auf ein Netzwerkshare eines anderen Rechners zugreift (z.B. SMB), hast du das Problem nicht. Nur, wenn der Cluster selbst was "mountet", also das Filesystem für sich beanspricht und beim unmounten noch sauber abschliessen muss und seine gecachten Sachen ablegen muss, dann hast du ein Problem.

Mittlerweile laufen z.B. unsere drei Exchange deswegen wieder direkt auf dem Host und alle haben die selben Datenbanken gemountet,

Genau das macht jedoch keinen Sinn. Exchange Server müssen nicht eine gemeinsame Datenbank mounten, das wäre ein SPOF, wenn diese eine Datenbank korrupt wird oder ganz hops geht, stehen alle drei Exchange Server.

Exchange Server arbeiten mit DAGs, in der jeder Exchange seine eigene Datenbank hat und die DAG synchronisiert sich under den 3 Datenbanken untereinander. Jede Datenbank hat die Inhalter/ Postfächer aller Benutzer, also in diesem Fall in 3-facher Ausfertigung. Dann darf auch mal ein Exchange mit seiner Datenbank komplett ausfallen und die anderen zwei Exchange machen mit jeweils ihrer eigenen lokalen (unabhängigen) Datenbank weiter, ohne, dass irgendein Benutzer was bemerkt.

Und warum müssen drei Exchange, wenn sie ein SAN nutzen, die selbe Datenbank haben?

Das SAN hat ja nicht nur den Vorteil, dass man shared-bla-bla machen kann, sondern seine Investition besser oder überhaupt ausnutzen. Dicke lokale RAIDs sind je meist sinnlos wie ein Kropf.

Und warum müssen drei Exchange, wenn sie ein SAN nutzen, die selbe Datenbank haben?

Müssten ja nicht das habe ich ja beschrieben. Nicht einmal ein SAN ist dafür nötig. Eine einfache lokale Platte pro Exchange Host reicht für eine DAG.

Dicke lokale RAIDs sind je meist sinnlos wie ein Kropf.

Von einem dicken lokalen Raid war auch von niemanden die Rede. Bei einer DAG brauchst du nicht einmal ein Raid.

Zitat von @NordicMike:

Genau das macht man beim Clustering aber, sonst macht ein Shared Storage ja keinen Sinn.

Wenn du da VHDs ablegst hast du eher noch größere Probleme als bei iScsi, oder wo willst du die VHD und die VM Config und Snapshots ablegen so das Livemigration funktioniert?

Zitat von @2423392070:
Und warum müssen drei Exchange, wenn sie ein SAN nutzen, die selbe Datenbank haben?
Das SAN hat ja nicht nur den Vorteil, dass man shared-bla-bla machen kann, sondern seine Investition besser oder überhaupt ausnutzen. Dicke lokale RAIDs sind je meist sinnlos wie ein Kropf.

Hat keiner gesagt, das man das so machen MUSS. Wir haben ja die Exchanges aus dem SAN ausgegliedert.
Wir machen das so, weil Direct Attached Storage im Vergleich zu SAN so gut wie nix kostet und die stabilste Anbindung bietet. Wenn mir ein Host abraucht, hab ich noch zwei in anderen Brandabschnitten, die den Dienst bereitstellen können.
Zudem wenn du jetzt drei Server und drei Bleche hättest, die Live auf jeweils den anderen Host migriert werden können, dann muss jeder dieser Server auf allen drei Blechen lizenziert werden, wir bräuchten also neun Exchange Lizenzen statt drei.

Moin rzlbrnft,

Wir machen das so, weil Direct Attached Storage im Vergleich zu SAN so gut wie nix kostet und die stabilste Anbindung bietet.

das kann ich so nicht stehen lassen, vor allem nicht bei einem DAG mit 3 Servern.
Bei deiner Lösung benötigst du die dreifache Speicherkapazität im Vergleich zu einem SAN, ausserdem erzeugst du durch den Abgleich der DB's auch einen sehr hohen Betriebsoverhead.
Und ein anständiges und damit meine ich nicht automatisch ein teures SAN, läuft mindestens genauso stabil wie ein lokaler Speicher, eigentlich noch stabiler, da ein anständiges Enterprise SAN meistens über zwei Controller verfügt.

Zudem wenn du jetzt drei Server und drei Bleche hättest, die Live auf jeweils den anderen Host migriert werden können, dann muss jeder dieser Server auf allen drei Blechen lizenziert werden, wir bräuchten also neun Exchange Lizenzen statt drei.

So weit ich weiss aber nur dann, wenn du als Hypervisor nicht Hyper-V verwendest und oder Microsofts Lizenzbedingungen viel zu genau nimmst.

Gruss Alex

Kommt auch immer drauf an, was man unter Server versteht.

Unsere Server haben fast ausnahmslos nicht Mal mehr eine Backplane für Local Storage, selbst die 20 Euro sparen wir uns haben einen besseren Luftzug.

Board, RAM, CPUs, CNA/NIC, iDRAC und das war's. Selbst auf SD Karten wird verzichtet weil FCoE-Boot from SAN.

Und das alles aus Kostengründen. Selbst eine Platte mit Kabel, auch ohne dedizierten Controller ist zu teuer und hat lediglich Nachteile.

Moin unbelanglos.

Ich kann die Backplane bei den Intel-Chassis die wir verwenden, im Vorfeld leider nicht abbestellen, aber vor der Auslieferung zum Kunden, rupfe ich diese und sämtliche unnütze Verkabelung, aus dem gleichen Grund wie du (besseren Luftzug), als erstes heraus.

Board, RAM, CPUs, CNA/NIC, iDRAC und das war's. Selbst auf SD Karten wird verzichtet weil FCoE-Boot from SAN.

Als Boot-Laufwerk kommen/kamen bei uns bisher die Intel Optane-SSD's (PCIe) zum Einsatz.
Die Dinger sind unverwüstlich und haben zudem einen 1A Durchsatz bei einer atemberaubenden Latenz.
Zudem schonen wir dadurch etwas die SAN Ressourcen, so dass dessen Leistung zu 100% den VM's zur Verfügung steht.

Und das alles aus Kostengründen. Selbst eine Platte mit Kabel, auch ohne dedizierten Controller ist zu teuer und hat lediglich Nachteile.

Das kann ich nur bestätigen.

Beste Grüsse aus dem Schwabenländle
Alex

Unsere ESXI haben ein 16GB LUN zum Booten und da ist eigentlich nicht wirklich was los.

Eine Sache wünschen wir uns und zwar viel früher im Boot Prozess MPIO zu haben, hat aber bisher immer gereicht.

Uns entfernt Dell wirklich alles, aus den Blades.
Die PE haben teilweise Hardware die wir entfernen.

Vielen Dank an alle für die Diskussion.
Ich nehme aus den Beiträgen mit, dass ihr das Patchen, Neustarten und Anfahren der Hosts bzw. VMs weitestgehend per Hand ausführt.

Da hier keine hochkomplexen Vorgänge auf den VMs laufen, die nicht durch Redundanzen im Fehlerfall von anderen Standorten aufgefangen werden, werde ich mich einmal an einem PowerShell Script auf dem Hyper-V Host selbst versuchen. Pingen, Dienste prüfen, ggf. Monitoring API befragen, dann die nächste VM anstarten etc.

Hätte ja nur sein können, dass es da schon etwas Fertiges gibt.

Zitat von @MysticFoxDE:
das kann ich so nicht stehen lassen, vor allem nicht bei einem DAG mit 3 Servern.
Bei deiner Lösung benötigst du die dreifache Speicherkapazität im Vergleich zu einem SAN, ausserdem erzeugst du durch den Abgleich der DB's auch einen sehr hohen Betriebsoverhead.

Ein SAN ersetzt keine DAG, weil die Wiederherstellung eines Exchanges immens lang dauert.
Zudem hab ich durch die DAG die Möglichkeit, Updates im laufenden Betrieb zu fahren, ohne die User zu beeinträchtigen. Heißt, ich brauch sowieso die doppelte Datenmenge, und mit drei Stück bei 300 Usern hab ich dann auch noch die nötige Performance, die ich zum arbeiten brauch.
Wenn sich die drei Server dann aber einen SAN Storage teilen, hab ich wieder den gleichen Flaschenhals, vor allem bei Billigschrott.

Und ein anständiges und damit meine ich nicht automatisch ein teures SAN, läuft mindestens genauso stabil wie ein lokaler Speicher, eigentlich noch stabiler, da ein anständiges Enterprise SAN meistens über zwei Controller verfügt.

Du widersprichst dir in dem Satz selber. Entweder setzt du irgend ein billiges halbgares NAS als SAN ein, oder eine Enterprise Lösung.
Ein anständiges SAN ist redundant angebunden, schnell und hochverfügbar, und damit automatisch sauteuer.
Du brauchst den Storage, die Festplatten und mindestens 2 SAN Switche inklusive HBA in jedem Server. Alles was weniger hat ist kein SAN, sondern Müll.
Zudem bist du nie geschützt, wenn dein Storage Controller abraucht, außer du hasst einen Dual Storage Controller, da sprechen wir dann aber von 10k aufwärts für einen einzelnen Storage, und was mach ich im Brandfall? Blitzeinschlag? Wasserschaden?

Wir hatten genau an dem Standort wo wir jetzt wieder auf Direct Attach umgestiegen sind, ein "nicht so teures SAN" im Einsatz, Resultat, es hat wegen Netzwerkausfällen eine 1 TB VHD geschrottet, die Wiederherstellung hat Ewigkeiten gedauert und ein Tag Arbeit war trotzdem futsch.

Einen Server krieg ich für ca. 2k, zwei brauch ich sowieso, 8TB Festplatten liegen bei 250, 2TB SSDs bei ca. 400, wenn du mir sagst wo ich für das Geld einen Dual-Controller SAN Storage inklusive Festplatten herbekomme, kauf ich sehr gern da ein.

Moin rzlbrnft,

Ein SAN ersetzt keine DAG,

das kommt immer auf den Grund an.

weil die Wiederherstellung eines Exchanges immens lang dauert.

das hängt einzig und alleine von deinem Backupkonzept und dessen Leistungsfähigkeit ab.

Zudem hab ich durch die DAG die Möglichkeit, Updates im laufenden Betrieb zu fahren, ohne die User zu beeinträchtigen.

das Argument ist wiederum korrekt, aber meiner Ansicht nach nicht Kriegsentscheidend.

Was machst du mit deinem DAG, wenn der Schaden auf der Datenbankebene liegt?
Ja, ich weiss, sehr gemeine Frage. 😎

Heißt, ich brauch sowieso die doppelte Datenmenge,

Nein, das brauchst du bei einem SAN eben nicht, zumindest nicht wenn es um die Datensicherheit geht.

und mit drei Stück bei 300 Usern hab ich dann auch noch die nötige Performance, die ich zum arbeiten brauch.

Wir habe ohne DAG und bei Systemen auf denen über 300 User rumlungern auch keine Performanceprobleme.

Wenn sich die drei Server dann aber einen SAN Storage teilen, hab ich wieder den gleichen Flaschenhals, vor allem bei Billigschrott.

Bei Billigschrott hast du meistens bei allen Dingen früher oder später ein Problem und nicht nur bei SAN's. 😉

Du widersprichst dir in dem Satz selber. Entweder setzt du irgend ein billiges halbgares NAS als SAN ein, oder eine Enterprise Lösung.

Wir nehmen immer das letztere und dennoch muss dieses nicht teuer sein, zumindest nicht im Vergleich zu den hier bekannten A-Brands. 😎

Ein anständiges SAN ist redundant angebunden, schnell und hochverfügbar, und damit automatisch sauteuer.

Nein, das stimmt eben nicht.
Du solltest dir vielleicht auch mal anderen Dinge wie HP, DELL, FUJI, LENOVO & Co anschauen.

So was z.B.
http://infortrend.com/
Hat übrigens auch CERN im Einsatz und NEIN, die Dinger sind eben nicht teuer.

Du brauchst den Storage, die Festplatten und mindestens 2 SAN Switche inklusive HBA in jedem Server. Alles was weniger hat ist kein SAN, sondern Müll.

Bei deinen 300 Usern benötige ich lediglich 2 Hypervisor-Nodes und ein SAN und der Rest ist Perlen vor die Säue geschmissen.
Und darauf kannst du übrigens auch den Rest deiner IT-Landschaft laufen lassen und nicht nur den Exchange.

Zudem bist du nie geschützt, wenn dein Storage Controller abraucht, außer du hasst einen Dual Storage Controller,

Ein Enterprise SAN ohne Dual-Controller ist KEIN Enterprise SAN.

da sprechen wir dann aber von 10k aufwärts für einen einzelnen Storage,

Nein, nein und nochmals nein.
Ich kann dir gerne ein Angebot zuschicken.

und was mach ich im Brandfall?

Du hast also keine Löschanlage im Serverraum.

Blitzeinschlag?

USV's und anständige Erdung anscheinend auch nicht vorhanden.

Wasserschaden?

Und Wasser- oder Abwasserleitungen scheinen durch den Serverraum auch noch durchzugehen.

Wir hatten genau an dem Standort wo wir jetzt wieder auf Direct Attach umgestiegen sind, ein "nicht so teures SAN" im Einsatz, Resultat, es hat wegen Netzwerkausfällen eine 1 TB VHD geschrottet,

Ähm, wie kann den bitte ein Direct Attach SAN wegen Netzwerkausfällen eine VHD schrotten?
SAN ist FC oder SAS und komm mir jetzt bitte nicht mit iSCSI um die Ecke, das ist pseudo SAN (ausgenommen Backupumgebungen).

die Wiederherstellung hat Ewigkeiten gedauert und ein Tag Arbeit war trotzdem futsch.

eine Wiederherstellung einer 1T vhd/vhdx dauert bei den meisten unserer Kunden keine 15 Minuten.

Einen Server krieg ich für ca. 2k, zwei brauch ich sowieso,

Ja, das Chassis, Board und ein Netzteil vielleicht, zumindest wenn wir von Enterprise Qualität sprechen.
Dann kommen noch die CPU's dazu, der RAM, und der eine oder andere Schnickschnack.
Sprich, für 2K bekommst du sicher keinen Enterprise Server.

wenn du mir sagst wo ich für das Geld einen Dual-Controller SAN Storage inklusive Festplatten herbekomme, kauf ich sehr gern da ein.

Bist du Endkunde oder Systemintegrator?
Wenn Endkunde, dann kann ich dir ein Angebot zuschicken.

Wenn Systemintegrator, dann schau mal hier vorbei.
https://www.prostor.de/

Beste Grüsse aus BaWü
(Ja, OK, geschummelt, momentan sitze ich noch im ICE nach BaWü 🤪)

Alex

Warum ist ISCSI Pseudo-SAN?
Der ISCSI-Stack von Equalogic ist legendär und in allen SAN-Produkten von Dell zu finden. A

Moin unbelanglos,

Warum ist ISCSI Pseudo-SAN?
Der ISCSI-Stack von Equalogic ist legendär und in allen SAN-Produkten von Dell zu finden. A

weil iSCSI im Vergleich zu FC oder SAS, einen viel grösseren Overhead hat.

Gruss Alex

Der "Overhead", spielt aber außerhalb von Soft-iSCSI nur dann eine Rolle, wenn es z. B. um absolute Niedriglatenzanwendungen geht. Oder um die Vorteile von z. B. Von NVME-OF.

Außerdem sollte man bei solchen Aussagen auch immer fairerweise berücksichtigen, das ungleichwertige Hardware oft eingesetzt wird, wenn es zu solchen Aussagen kommt.
ISCSI auf entsprechender Hardware ist richtiges San, genau wie FCoE.

Und ja, ich weiß hier im Forum, geht es immer um Militärtechnik und Hochfrequenzhandel.

Moin unbelanglos,

Der "Overhead", spielt aber außerhalb von Soft-iSCSI nur dann eine Rolle, wenn es z. B. um absolute Niedriglatenzanwendungen geht. Oder um die Vorteile von z. B. Von NVME-OF.

nein, das ist nicht korrekt, der angesprochene Overhead spielt auch bei Hard-iSCSI ebenso eine Rolle.

https://www.thomas-krenn.com/de/wiki/Leitfaden_Storage_Konnektivit%C3%A4 ...

Außerdem sollte man bei solchen Aussagen auch immer fairerweise berücksichtigen, das ungleichwertige Hardware oft eingesetzt wird, wenn es zu solchen Aussagen kommt.
ISCSI auf entsprechender Hardware ist richtiges San, genau wie FCoE.

ja, OK und S2D/vSAN ist dann wohl auch ein richtiges Storage.

Kleiner Tipp. Teste mal selbst und dann wirst du den nicht gerade kleinen Unterschied schon sehen.

Und ja, ich weiß hier im Forum, geht es immer um Militärtechnik und Hochfrequenzhandel.

echt ... wo?
Spass beiseite, den Unterschied merkt selbst ein kleiner Mittelständler.
Den Latenz ist für jeden wichtig und nicht nur bei Militärtechnik oder den Finanzheinis.
Höhere Latenzen bedeuten unter dem Strich immer eine höhere Wartezeit beim User, und dessen Arbeitszeit ist meistens nicht kostenlos.

Gruss Alex

Zitat von @MysticFoxDE:

Moin rzlbrnft,