Nochmal Off Topic: Server Hardware mit RAID Controller, was passiert bei Mainboard Defekt?

[Rosendoktor]

Hi,

Noch ein OT, sorry...

Mal angenommen, es wird ein lokaler Server betrieben auf dedizierter Server Hardware mit RAID Controller auf dem Mainboard, z.B. auf sowas: https://www.fujitsu.com/de/products/computing/servers/primergy/tower/tx1310m3/, und es sind zwei Platten/SSDs im RAID1 verbaut.

Wie ist das, wenn bei so einem Ding das Netzteil oder das Mainboard die Grätsche machen? Soll ja auch vorkommen, mir sind im Lauf der Jahre etwa gleich viele Mainboards wie HDDs kaputtgegangen.

Kann man in so einem Fall die Daten von den intakten Platten an einem anderen PC mit normalem Controller lesen, oder gar mit einer der Platten einen anderen (Desktop-) PC booten und diesen provisorisch/temporär als Server betreiben? Oder bedeutet das Downtime bis baugleicher Ersatz beschafft ist?

Ich hab bisher "nur" Linux und FreeBSD mit Software RAID im Einsatz (mdadm bzw. gmirror), da ist das ja kein Problem, nur soll da halt Windows drauf laufen was ja kein Software RAID kann.

Grüße,

Robert

 

[CommanderZed]

Soviel ich weiß unterstützt Windows Server doch Software-Raid? Habs allerdings selbst noch nie genutzt.

Soweit ich weiß ist das je nach Controller & Firmware teilw. sehr unterschiedlich, idr. kann man die aber wohl eher nicht lesen.

Idr. spielt man dann doch einfach nur das Backup wieder ein auf einer anderen maschine.

 

[Azazyel]

Soviel ich weiß unterstützt Windows Server doch Software-Raid? Habs allerdings selbst noch nie genutzt.

Schon Windows NT konnte Software-Raid und es geht auch noch mit Windows Server 2019.

Soweit ich weiß ist das je nach Controller & Firmware teilw. sehr unterschiedlich, idr. kann man die aber wohl eher nicht lesen.

Korrekt. In der Regel braucht man einen baugleichen Controller, um die Daten auszulesen.

Idr. spielt man dann doch einfach nur das Backup wieder ein auf einer anderen maschine.

Nebst unverzichtbarem Backup kann man im kleinen Maßstab auch gleich die Workload mit Hyper-V Replication virtualisiert betreiben.

Dann führt der Ausfall eines Mainboards, Controllers oder Speichermediums nur zu unwesentlich erhöhtem Blutdruck.

 

[mr44er]

Soviel ich weiß unterstützt Windows Server doch Software-Raid?

Richtig, nur Booten konnte man nie davon bzw. das System auf softraid intallieren. Wie der jetzige Stand beim aktuellen Windows ist, weiß ich nicht.

Wie ist das, wenn bei so einem Ding das Netzteil oder das Mainboard die Grätsche machen?

Bei HW-RAID muss man immer davon ausgehen, dass man von der Hardware abhängig ist, mit der der Verbund erstellt wurde. Dh. gleiche Ersatzhardware mit gleichem FW-Stand auf Halde liegen haben. Da gibt es natürlich Ausnahmen, die man mit anderen Controllern lesen kann, aber das willst du nicht genau dann erst herausfinden, wenn das Desaster schon passiert ist. Ebenfalls willst du nicht im Desasterfall erst bangen, ob du noch irgendwie irgendwo genau diese Ersatzhardware auftreiben kannst.

 

[Azazyel]

Richtig, nur Booten konnte man nie davon bzw. das System auf softraid intallieren. Wie der jetzige Stand beim aktuellen Windows ist, weiß ich nicht.

Es erfordert (im Gegensatz zur Spiegelung von Daten-Partitionen) Handarbeit: https://docs.microsoft.com/en-us/tr...kup-and-storage/establish-boot-to-gpt-mirrors

 

[Yamagi]

Windows unterstützt mit Storage Spaces schon länger modernes Volume Management. Auf der einzelnen Box ist es konzeptionell ähnlich zu ZFS, man legt sich Pools aus einem oder mehreren Laufwerken an und erstellt darauf einzelne Volumes. Die Pools können verschiedene Redundanzlevel haben, vom einfachen Stripe bis hin zu RAID-ähnlichen Setups. Über mehrere Boxen verteilt verhält es sich ähnlich wie Ceph, die Daten werden in Objekte zerlegt und entsprechend der Redundanzvorgaben und mit Hilfe von Lokalitätsinformationen über den Cluster verteilt. Man kann dort auch Azure als externes Kopie anflanschen, wenn man es braucht oder will...

Das im Moment in Sachen (lokalem) Storage schwächste System ist Linux. Was nicht zuletzt daran liegt, dass sie es seit Jahren nicht schaffen ein modernes Dateisystem in den Kernel zu integrieren. Man kann seine Daten btrfs anvertrauen und hoffen, dass es gut geht. Man kann ZFS nutzen, aber externe Kernelmodule sind halt generell immer hakelig und bei Dateisystem noch mal extra lustig. bcachefs könnte was werden, ist aber noch weit von Produktionsreife entfernt. Bleibt der Klassiker aus lvm2 und xfs bzw. ext4, was aber im Vergleich zur Konkurrenz altbacken und unnötig hampelig wirkt.

 

[pit234a]

es sind zwei Platten/SSDs im RAID1 verbaut.

wobei das womöglich noch die beste Variante ist, denn viele raid-controller machen dabei einfach aus einer Platte zwei, sprich, du kannst dann jede einzelne Platte auch alleine betreiben und mit etwas Glück halt direkt und ohne den raid-Controler des MB.

Selbst bei SW-Raid (mit Linux) (mdadm oder lvm) musst du ja genau dokumentieren, was du gemacht hast. Nur sehr selten gelingt es, Daten von einer Platte aus dem Verband zu lesen, wenn man keine Information dazu hat, wie der aufgebaut war.

 

[medV2]

Das ein HW RAID nur wieder mit baugleichem Controller läuft ist etwas aus den frühen 2000ern und hält sich leider bis heute hartnäckig. Ich kann natürlich nicht genau für den Controller auf diesem verlinkten Board sprechen, aber idr. sind Controller von Adaptec oder LSI (und die großen HW Hersteller wie Dell oder HPE verbauen idr solche, nur rebranded) zu anderen Controllern der selben Generation kompatibel (sofern die nötigen Features unterstützt werden) und auch neuere Generationen können die alten noch lesen und gegebenenfalls auf das neue Format umstellen.

 

[CommanderZed]

Okay, ich glaube die Ursprungsfrage wurde nun recht ordentlich abgefrühstückt.

Aber ich nehme dies mal aus aufhänger für eine allg. Frage, und zwar ob ihr auch das Gefühl habt das RAID, also "Festplattenausfallsicherheit" nicht etwas zu hoch gehangen wird, gerade auch hier in dem Forum?

Wie schaut das denn bei euch allen so in der Praxis aus? Hier mal bei uns:

Wir betreiben nur wenige Server selbst, dort waren aber in den letzten 11 Jahren nur extrem selten Serverfestplatten defekt, und wenn waren die immer älter als 5 Jahre. Genauso häufig waren andere komponenten defekt.

Etwas "breiter" kann ich es bei unseren Desktop-Geräten sehen, so ca. 850+ Geräte.
Hier sinds ca. 1-3 Festplatten und 2-6 andere defekte im Jahr - insgesamt also verschwindent gering. Und halt auch eher "Allg. Hardwareschaden".

Klar braucht man immer ein gutes Backup, schon allein weil neben HDD defekt es echt viele andere, wahrscheinlichere Gründe für Datenverlust gibt, aber zwischen Backup und HA ist halt auch nen Großer unterschied.
Aber kann es sein das die Zeit der "Mir rauchen im Server 2x im Jahr 4 von 8 Platten der unglaublich schnellen(!) 7200er und 10K Platten ab" eher ne sache der späten 90er und frühen 2000er war, oft kombiniert mit schlechter Belüftung / Klimatisierung?

Und macht wenn man wirklich "HA" braucht neben den "Raid" nicht eher ein günstiges "Vollersatzsystem" sinn, also nen "Hot-Standy-Server" auf den man mehr oder weniger live alles spiegelt oder so? Oder z.B. 3 Hardware-Server die Lastmäßig zu dritt 1/3 reserveleistung haben und die für einen "ausgefallenen" komplett übernehmen können? Und ist das nicht sinnvoller als irgend nen ranzigen Controller/Mainboard in der Schublade zu haben? Zumal Hardware auch nicht mehr unendlich teuer ist, gerade auch im Vergleich zu Softwarelizenzen, Support e.t.c.

Und ist privat nicht nen gutes Backup zwar u.U. aufwändiger, aber evtl. besser als sich Mega nen Kopf um die HA zu machen? Ist das teilw. villeicht auch son "Haben Wollen" IT-Nerd Ding?

 

[medV2]

Ich hab da bei uns in der Firma andere Erfahrungen gemacht: Bei unsren ca. 15 Servern mit im Schnitt 8-12 Platten Pro Server hab ich ca 1-2 Festplattenausfälle pro Jahr. Auch relativ gleichmäßig verteilt über neue und alte. Dagegen kommen in den letzten 10 Jahren nur 3 RAM defekte (die auch zu keinem kompletten Ausfall führen), 1 defektes Mainboard und 1 defektes Netzteil.
Manchmal hat man auch einfach Pech - wir hatten mal eine lieferung Festplatten von denen in den ersten beiden Jahren fast die hälfte verstorben sind.
Ich muss aber auch sagen, dass unsre Server relativ häufig erneuert werden, die wenigsten sind älter als 5-6 Jahre. Auch verwenden wir großteils günstige SATA Platten. Von daher minimiert HA auf den Festplatten durchaus deutlich die Ausfallzeiten. Vorallem kostet das auch nicht viel - im vergleich zu einem vollwertigem Hot Standbysystem.

 

[mr44er]

Wegen der Flut schlechter Kondensatoren um die 2000er rum sind merklich mehr Boards ausgefallen und Netzteile durchgeraucht. Netzteile wohl auch eher durch Lüfterausfall, weil das Kugellager durch war. Habe keine Statistiken geführt, was kaputt ist, wird eben ausgetauscht. Das werden andere bestätigen können, durch deren Hände viel Hardware ging.
ASUS hat um 2012 rum werbewirksam 'solid caps' verbaut. Bis dahin waren bei mir dann so auch die letzten problematischen Dinger entweder gestorben oder anderweitig upgegraded. Seitdem ist mir kein Board mehr weggestorben.

Bei Festplatten kann man nicht kalkulieren, hoffen oder beten. Die sterben halt irgendwie, irgendwann. Da tröstet es wenig, ob das jetzt ein FW-/Material-/Transport-Fehler ist oder die Badewannenkurve überhaupt existiert. Das Problem Datenverlust kann man nur mit mehrfachen Backups, Dateisystemen mit Funktionen gegen bitrot erschlagen. Wenn man dann noch Sahne mit Kirsche aka HA draufpacken kann und sich das leisten will, gerne doch.

@medV2 hat natürlich Recht. Wenn ich die Option aber habe, es mir so inkompatibel wie möglich zu machen mit nem HW-RAID, warum sollte ich das tun?

Wenn meine PrimärHW abgeschmolzen ist, will ich irgendnen Frankensteinboard zupfen können und an die Daten rankommen, egal wie verboten das Gebastel aussieht, wie lange ich offline bin (=mir reicht privat daher cold standby) oder wie lahm ein Umkopieren geht. Da nehme ich liebend gerne softraid und vermeide wenns und abers durch Komplexität.

Im geschäftlichen Umfeld würde ich immer HA vorziehen. Scheiße passiert nunmal und selbst wenn ein offline-Fenster von 6-12 Stunden vertretbar eingeplant ist, kann man nie vorhersagen, ob die Problemlösung sofort angegangen werden kann oder ob das Problem (was man ja vorher nicht kennt) in dem Zeitfenster behoben werden kann.

 

[Rosendoktor]

Danke Euch für die Antworten, die im wesentlichen meine Vermutungen, Befürchtungen und Bedenken bestätigen.

Zunächst mal, was Windows 10 Pro an "Spiegelung" anbietet, hat meiner Meinung nach mit einem sinnvollen Software RAID nicht viel zu tun. Man kann Datenpartitionen spiegeln, okay. Man kann auch die Systempartition spiegeln, aber nicht 1:1, und dann fragt das Windows 10 früh im Bootvorgang auch noch, von welcher der beiden "Kopien" es denn nun booten soll. An der Stelle hab ich den Versuch damals abgebrochen... Zudem wird die EFI Partition nicht auf die zweite Platte repliziert, fällt die erste Platte aus, wäre es also nicht mal mehr bootfähig. Der Showstopper schlechthin ist aber, dass sich Spiegelung und Bitlocker gegenseitig ausschliessen. Ende Gelände.

Der Hintergrund von dem ganzen ist, dass ich gebeten wurde, mich um die IT einer Arztpraxis zu kümmern, die von einer Freundin gerade übernommen wird. Es sind etliche Investitionen nötig, darunter medizinische Geräte, Patientenakquise, und eben die völlig marode IT. Letztere hat im Gegensatz zu den anderen Punkten eben keinen Return-Of-Invest, insofern ist es durchaus verständlich, dass das zunächst mal nur am Laufen gehalten werden soll und ein Komplettangebot vom Hersteller der Praxisverwaltungssoftware über 3 Arbeitsplätze und einen Server für 18000.- € entsetzt abgelehnt wurde.

Die Hardware muss komplett ersetzt werden, daher auch die Frage, worauf künftig die Serveranwendung der Praxisverwaltungssoftware betrieben werden soll. So wie es jetzt ist kann ich es keinesfalls guten Gewissens lassen (siehe anderer OT Thread).

Mein Problem dabei ist, dass ich kein IT KMU bin das sich per Servicevertrag für das Vorhalten von Ersatzhardware und schnellen Notfallservice bezahlen lässt. Diese Verantwortung kann und will ich nicht übernehmen. Also entweder läuft der Serverkram auf Standardardware die sich immer irgendwie binnen Stunden ersetzen lässt, notfalls durch eine der Arbeitsstationen, oder es werden gleich zwei von den Servern angeschafft, einer in Produktion, einer als Cold Spare oder als weitere Arbeitsstation, soviel teurer als Arbeitsstationen sind die auch nicht. In beiden Fällen müssen im Notfall nur die Platten umgestöpselt werden. Sowas können die selbst machen, von mir aus mit Anleitung per Telefon.

Was RAID und Backup angeht, RAID ersetzt kein Backup, und Backup ersetzt kein RAID. Das ergänzt sich. Im obigen Anwendungsfall kommt es nicht nur auf die Sicherheit der Daten (stündliches und tägliches Backup sind geplant), sondern auch auf Verfügbarkeit an. Jeder IT Ausfall bedeutet sofortige Schliessung und damit Umsatz- und Renomeeverluste, da keine Patienten angenommen werden können und Termine abgesagt werden müssen ohne Kartenleser und ohne Zugriff auf die Patientenakten. Ein RAID System meldet den Ausfall und läuft einfach weiter, ein nicht RAID System fällt sofort aus bis die Ersatzplatte beschafft, installiert und das Backup zurückgespielt ist, und das können die definitiv nicht selbst da...

 

[CommanderZed]

Okay, kleines Sorry das ich deinen Thread gekapert hatte, ich dachte es geht um Gedankenspiele oder nen privates Projekt - bitte schreib doch dazu wenn es um ein Teilproblem eines anderen Threads geht oder schreib einfach im vorhandenen thread weiter.
Ein RAID macht in den meisten fällen sicher sinn und ist ja auch nicht unendlich teurer, ich wollte nur darauf hinaus das es nicht "alles" ist weil mir das in den recht vielen "RAID" Diskusionen hier im Forum oft etwas untergeht. Hätte ich gewusst das es hier um um die Arztpraxis geht, hätte ich mich zurückgehalten - sorry nochmal.

Bei meinen vorherigen arbeitgeber, so bis 2009, haben Primär KMU gemacht, vor allen Betriebe zwischen 2 und 20 Mitarbeiter, keine Arztpraxen, aber Anwälte, Speditionen e.t.c. - technisch hat sich die Welt da schon 2x weitergedreht, aber ich denke ich hab noch immer ein paar Ideen wie kleinere Unternehmen so "ticken"

Korrigier mich bitte, aber der Hersteller der Software wird vermutlich Windows vorschreiben?

Hier ein paar Ideen:

Clientseitig einen zusätzlichen "reserve" Arbeitsplatz einplanen der aber auch gelegentlich genutzt wird.
Dadurch weiß man das er funktionsfähig ist und alle Updates hat, und wenn er ein Problem hat wird es gemeldet und repariert.
Wird er dann"gebraucht" als Ersatz an den "wichtigen" Plätzen kann man ihn schnell mal eben umstöpseln und weiß das er funktioniert.

Es macht sicher auch sinn ein Netzteil u.ä. vorzuhalten.

Generell habe ich eher schlechte Erfahrungen mit Ersatzhardware im Schrank gemacht - die neigt auch dazu zu altern und ist nach 3 Jahren evtl. defekt, oder hat nen wichtiges Update nicht bekommen oder so - ein "Gelegentlich verwendeter Reserve PC" am Azubi / Praktikanten / Reserve / Abstellkammer / Sonstwas Platz ist da u.U. zuverlässiger weil technische Probleme einfach auffallen und dann gelöst werden können bevor sie für den Katastrophen fall genutzt werden.

Wir sind seit ca. 2 Jahren auf so kleine Mini-PCs (Buchgröße) umgestiegen, bei uns von Dell, gibts aber auch von vielen anderen Namenhaften Herstellern - vorteil: Das Netzteil ist idr. extern und kann leicht getauscht und bevorratet werden, Endbenutzer trauen es sich schon allein aufgrund der wenig abschreckenden größe mal selbst zwischen Arbeitsplätzen e.t.c. zu tauschen. (Generell gehen bei uns Clientseitig Festplatten / Ssds seltener als Netzteile defekt).
Nicht ganz unwichtig: GGF. den leuten erklären das eine gute Belüftung der Geräte nicht unwichtig ist.

Viele hersteller bieten auch "Pro" Support über z.B. 5 Jahre an, bei denen bessere Techniker schneller kommen und man auch eine kompetentere Hotline hat.

Serverseitig würde ich wenn das irgendwie im Budget drinne ist auf zwei Geräte gehen, wenns Microsoft ist könnte man da auch was mit Hyper-V und Replikation basteln, da gibts viele interessante Optionen bei denen man auch nicht manuell irgendwelche Platten wechseln muss, man kann den zweiten ja auch u.U. etwas sparsamer ausstatten (kein Redundantes Netzteil oder so).

Man sollte u.U. aber auch für den Einbrauch mit Diebstahl und ggf. Vandalismus* oder Wasserschaden der gesamten IT Planen - das ist das was "damals" bei uns so ziemlich am häufigsten vorkam was "Hardwareverluste" anging - in sonne kleine Arztpraxis wird u.U. eher eingestiegen als in ein großes Unternehmen.
*(Oft glauben die Einbrecher an große Bargeldbestände, werden die nicht gefunden wird manchmal verwüstet)

Management nach dem Kauf:
Ich würde Softwareseitig auf jedenfall eine robuste Fernwartungsmöglichkeit einplanen - villeicht auch ein "Wartungs"-VPN in das Netz um vill. auf eine Management-Konsole des Server zu kommen e.t.c.

Was ich noch nicht ganz verstanden habe, betreust du die dann alleine, gibts es da noch weiteres IT-"Personal" z.B. im Freundeskreis oder wird wenn du mal im Urlaub bist, länger Krank bist e.t.c. ein externer Dienstleister gerufen?

Wenn ja macht es sinn den vill. auch mit ins Boot zu holen, oder zumindest eine Doku für "IT-Nicht-Ganz-So-Experten" zu erstellen, oder sowas "vorzuhalten" - seien wir ehrlich, die bezahlbaren, regionalen Dienstleister die KMU & Co. betreuen sind oft(!) reine Windowsexperten und auch da nicht unendlich tief drinne. (Solltest du zufällig aus dem Großraum Bremen kommen könnte ich sogar jemanden empfehlen)

 

[pit234a]

Der Hintergrund von dem ganzen ist, dass ich gebeten wurde, mich um die IT einer Arztpraxis zu kümmern, die von einer Freundin gerade übernommen wird.

großes Problem!

Freundin ist gut und kümmern auch. Wenn es aber um IT für eine Arztpraxis geht, gibt es viele viele Vorgaben, die du womöglich auf Grund deines Status als Freund nicht erfüllen kannst. Um Arztpraxen habe ich mich nie gekümmert und werfe aus meinem Umfeld mal nur einige Behauptungen ein, die nachdenklich machen sollen.
Vermutlich wird diese IT ein Medizin-Produkt sein. Es wird sich darauf womöglich SW befinden, um sich Patientenbilder anzusehen. Auch dann, wenn dies nicht der Befundung dient, gibt es hier etliche Auflagen für den Betreiber.
Die Patientendaten selbst müssen sicher sein und natürlich dürfen sie nur gemäß der DSGVO erhoben und gespeichert werden (also nicht auf einem günstigen Server außerhalb Europas). Oben angesprochen wurde etwa das Modell der "Fernwartung": wenn der aus der ferne Wartende dabei ausreichend Rechte erhält, um an Patientendaten zu kommen, geht das nicht. Oder an Personal-Daten: wer war wann wie lange eingeloggt? Darf niemand wissen. Und so weiter....
Sodann die standardisierten Anforderungen der Kassen-ärztlichen Vereinigung, um überhaupt Leistungen abrechnen zu können und demgegenüber das saubere Management der IGEL-Leistungen.

Ich will mich nicht weiter darin vertiefen, das führt zu weit weg. Nur als Wink mit dem Zaunpfahl: es geht hier nicht nur um IT, also nicht nur um einige PCs mit oder ohne Raid. Das ist ein sehr sehr komplexes Thema, vor allem in rechtlicher Hinsicht.
Als IT-Fachmann oder als Freund ist man da womöglich gar nicht gut aufgestellt, nicht gut genug. 18K nun mögen als viel Geld erscheinen, aber Strafen und Ansprüche auf Wiedergutmachung bei Verletzung von Vorschriften können schnell ein Vielfaches dieser Summe werden.
Hier heißt es, deutlich über den technischen Horizont hinaus zu blicken und sich abzusichern.

 

[Azazyel]

Das ist ein sehr sehr komplexes Thema, vor allem in rechtlicher Hinsicht.

Man sollte zumindest nicht blauäugig an das Thema herangehen. Die Vorschriften sind allerdings auch kein Hexenwerk.

Als IT-Fachmann oder als Freund ist man da womöglich gar nicht gut aufgestellt, nicht gut genug.

Man kann es natürlich auch als Gelegenheit sehen, sich in die Thematik reinzufuchsen und für die (neben)berufliche Selbständigkeit zu nutzen.

 

[kira12]

Danke Euch für die Antworten, die im wesentlichen meine Vermutungen, Befürchtungen und Bedenken bestätigen.

Die Hardware muss komplett ersetzt werden, daher auch die Frage, worauf künftig die Serveranwendung der Praxisverwaltungssoftware betrieben werden soll. So wie es jetzt ist kann ich es keinesfalls guten Gewissens lassen (siehe anderer OT Thread).

Hallo,

wir haben auf Arbeit Anlagen mit alten P4 Xeon Dell Servern. Das Angebot vom Hersteller über ein Update war schon fast frech. Dann haben wir die Win2k Software viruell auf ESXi laufen lassen und nun läuft es schnell und günstig. Wäre vielleicht eine Option wenn ein Rechner ausfällt. Mit einem Backup lässt sich ja schon vorher testen ob das läuft.

Gruß ré

 

[Azazyel]

Dann haben wir die Win2k Software virtuell auf ESXi laufen lassen und nun läuft es schnell und günstig.

Ich würde heutzutage auch keinen Server mehr direkt auf Blech betreiben, sondern grundsätzlich virtualisieren. Die Flexibilität im Betrieb ist ebenso günstig wie unbezahlbar.

Ob ESXi, Hyper-V oder KVM - Geschmacksfrage. Leider ist FreeBSDs bhyve immer noch fernab der Produktionsreife.

 

[foxit]

Da muss ich def. zustimmen. Mit oVirt und Proxmox stehen neben Xenserver und ESXi gute Alternativen bereit. Bhyve muss man noch etwas streicheln aber unter FreeBSD gibts ja noch Jails.

 

[Yamagi]

Ach kommt, Bhyve ist schon deutlich besser geworden. Das einzige fehlende Feature, was man vielleicht noch als zwingend ansehen kann, ist Live-Migration und die ist inzwischen mit Save / Restore Support ja auch halb da.

 

[Andy_m4]

Ich würde heutzutage auch keinen Server mehr direkt auf Blech betreiben, sondern grundsätzlich virtualisieren.

Kommt drauf an. Vor allem weil Voll-Virtualisierung auch ne Menge Overhead mitsich bringt. Das ist Ressourcenverschwendung und Komplexitätssteigerung ohne das dem immer so ein realer Mehrwert gegenüber steht.

Ob ESXi, Hyper-V oder KVM - Geschmacksfrage.

Ich würde wenn immer möglich eher auf OS-Virtualisierung zurückgreifen. Gerade Jails sind hier wunderbar (und das dort jetzt auch der Linux-Support deutlich besser geworden ist erweitert das Anwendungsfeld noch zusätzlich).

Leider ist FreeBSDs bhyve immer noch fernab der Produktionsreife.

Ich finde bhyve einen sehr angenehmen und schlanken Hypervisor ohne unnötigen Schnickschnack. Er kann sicher noch die ein oder andere Optimierung vertragen und die Tools drum herum sind ganz sicher auch noch verbesserungswürdig, aber er ist absolut einsetzbar.

 

[Azazyel]

Kommt drauf an. Vor allem weil Voll-Virtualisierung auch ne Menge Overhead mitsich bringt. Das ist Ressourcenverschwendung und Komplexitätssteigerung ohne das dem immer so ein realer Mehrwert gegenüber steht.

Die Vorteile für Betrieb, Test, Wartung, Migration uvm. sind enorm. Der Mehrbedarf an Hardware ist überschaubar, die Technik ausgereift. Für meinen Geschmack überwiegen die vielen Vorteile im Vergleich zu nacktem Blech die wenigen Nachteile für die meisten Anwendungsfälle bei weitem.

Ich würde wenn immer möglich eher auf OS-Virtualisierung zurückgreifen.

Das eine schließt das andere nicht aus. Im angesprochenen Anwendungsfall ist aber auch nicht absehbar, inwieweit Windows-Container hier zielführend wären.

Gerade Jails sind hier wunderbar (und das dort jetzt auch der Linux-Support deutlich besser geworden ist erweitert das Anwendungsfeld noch zusätzlich).

Leider sind Jails für viele gängige Szenarien völlig unzureichend (vgl. u.a. mein Beitrag hier). Zumal ich keine produktive Linux-Anwendung in einem FreeBSD-Jail betreiben würde. Ist aber auch off-topic.

Ich finde bhyve einen sehr angenehmen und schlanken Hypervisor ohne unnötigen Schnickschnack. Er kann sicher noch die ein oder andere Optimierung vertragen und die Tools drum herum sind ganz sicher auch noch verbesserungswürdig, aber er ist absolut einsetzbar.

Für den Heimeinsatz? Sicherlich.
Für den Produktivbetrieb? Naja.

Es gibt schon noch ordentlich Bugs. Die Integration in libvirt lässt auch noch sehr zu wünschen übrig. Damit fällt auch die Integration in viele essentielle Tools (Vagrant, Terraform uvm.) flach.

Langsam mausert sich bhyve. Um mit KVM und Konsorten auf Augenhöhe zu sein, braucht es aber noch viel Feinschliff.

 

[Andy_m4]

Der Mehrbedarf an Hardware ist überschaubar, die Technik ausgereift.

Wie gesagt. Es steigt die Komplexität. Hinzu kommen noch die ganzen Tools obendrauf die dann noch brauchst, um Deinen VM-Zoo verwalten zu können. Also noch mehr Komplexität.

Das eine schließt das andere nicht aus.

Hat so ja auch niemand behauptet. Deswegen schrieb ich ja: "Wenn möglich".

inwieweit Windows-Container hier zielführend wären.

Windows-Container hatte ich auch gar nicht im Sinn.

Leider sind Jails für viele gängige Szenarien völlig unzureichend (vgl. u.a. mein Beitrag hier)

Du vergleichst eine Virtualisierungsumgebung (Jails) mit einer Container-Lösung (Docker) ?
Äpfel, Birnen :-)

Zumal ich keine produktive Linux-Anwendung in einem FreeBSD-Jail betreiben würde.

Oft ist das ja auch gar nicht notwendig. Aber wenn, dann hast Du halt die Möglichkeit.

Für den Heimeinsatz? Sicherlich.
Für den Produktivbetrieb? Naja.

Zugegebenermaßen hab ich mit Windows nicht viel zu tun, weshalb die Vollvirtualisierung für mich weniger ein Thema ist. Und für alles andere ist OS-Level-Virtualisierung mir lieber.

Es gibt schon noch ]ordentlich Bugs[/URL].

Na meinste die hast Du bei ESXi oder Hyper-V nicht?
Microsoft und VMWare haben halt keine öffentlichen Bugtracker. Deshalb siehst Du die bloß nicht.

Langsam mausert sich bhyve. Um mit KVM und Konsorten auf Augenhöhe zu sein, braucht es aber noch viel Feinschliff.

Hat ja auch niemand bestritten. :-)
Im Gegenteil.
Dennoch lässt es sich schon ganz gut einsetzen.

Ansonsten hängt halt viel von den Einsatzszenarien ab. Ein Pauschales "taugt nix" oder "ist unzureichend" ist da eher schwierig.

 

[Azazyel]

Du vergleichst eine Virtualisierungsumgebung (Jails) mit einer Container-Lösung (Docker) ?
Äpfel, Birnen :-)

Wir reden über Optionen für den Betrieb von Anwendungen - dementsprechend statthaft ist der Vergleich. Seit ich mit OCI-Containern arbeite, ist mir auch Abwesenheit vergleichbarer Lösungen unter FreeBSD schmerzhaft bewusst.

Microsoft und VMWare haben halt keine öffentlichen Bugtracker. Deshalb siehst Du die bloß nicht.

Der Bugtracker von KVM als Bestandteil der Linux-Kernels ist öffentlich. KVM hat auch die Kinderkrankheiten hinter sich gelassen, die bhyve noch auskurieren muss.

Ein Pauschales "taugt nix" oder "ist unzureichend" ist da eher schwierig.

Solange bhyve mit den De-Facto-Standardtools in diesem Bereich nicht ordentlich zusammenspielt, tue (nicht nur) ich mir schwer, bhyve als ernsthafte Alternative in Betracht zu ziehen. Um wieder on-topic zu werden, schon der Betrieb einer Windows-VM kann aktuell noch sehr abenteuerlich werden.

 

[Yamagi]

Um wieder on-topic zu werden, schon der Betrieb einer Windows-VM kann aktuell noch sehr abenteuerlich werden.

Ganz ehrlich, mit Bugblaming zu argumentieren ist gefährlich. Denn jede hinreichend komplexe Software hat Bugs, viele davon peinlich. Wenn Bhyve durch Probleme im Zusammenspiel den Hypervisors mit den bekanntermaßen eher bröseligen virtio-blk Treibern für Windows - das war einer der Gründe, NVMe-Emulation zu implementieren - abenteuerlich ist und sich für produktiven Einsatz ungeeignet, würde ich die Finger auch qemu + KVM lassen. Ich erinnere mich spontan an:

• Subtile FPU State Korruption bei Linux 5.2, war wirklich spaßig das überhaupt auf den Hypervisor einzugrenzen: https://lkml.org/lkml/2019/7/17/758
• Irreparabel zerstörte qcow2-Images durch qemu 4.1, erst nach Wochen repariert: https://bugzilla.redhat.com/show_bug.cgi?id=1763519

Oder HyperV. Die Dezemberupdates für Windows 2019 haben mir mehrere VMs gecrasht, da ab und an auf durch den Hypervisor an den Gast gesendete fsfreeze Event niemals das fsthaw Event folgt, wodurch die Dateisysteme der VM dauerhaft blockiert bleiben. Ob das repariert wurde, sehen wir dann nach dem Januar Patchday.

Davon einmal abgesehen, war das Ziel des bhyve-Projekts niemals komplette, professionelle Lösungen für Datacenter-Virtualisierung zu ersetzen. Das hätte es realistisch gesehen sowieso nie gekonnt, denn das würde mehr Manpower benötigen als das FreeBSD-Projekt als Ganzes hat. Außerdem wäre es sinnlos gewesen, HyperV, vmWare und co. existieren und sind etabliert, haben die von Schlipsis so geliebten Zertifizierungen, etc. Das Ziel war es einen gut ins FreeBSD Basisystem integrierten, schlanken Hypervisor zu schaffen.

 

[Andy_m4]

Wir reden über Optionen für den Betrieb von Anwendungen - dementsprechend statthaft ist der Vergleich.

Wie gesagt. Äpfel, Birnen.
Docker und Co sind ein viel höheren Level.
Docker ist selbst keine Virtualisierungstechnik, sondern benutzt LXC bzw. heutzutage Namespace&CGGroups um auf Basis dessen eine Containerlösungzu bauen. Wenn Du Jails vergleichst, dann musst Du das halt mit LXC respektive Namespaces/CGGroups vergleichen.
BastilleBSD wäre das FreeBSD-Pendant zu Docker. Die machen halt so Container nehmen aber als OS-Level-Virtualization das was sie unter FreeBSD halt vorfinden. Nämlich Jails.

Du kannst ja von mir aus sagen, Docker und Co sind die ausgereifteren und etablierteren Techniken.
Und ich bin auch nicht gegen Docker oder ähnliche Containerlösungen. Ich sehe ihren Einsatzzweck und erkenne ihre Daseinsberechtigung an. Aber genauso haben halt auch plain-Jails (also auch ohne Bastille oder Vergleichbares) ihre Daseinsberechtigung.

Seit ich mit OCI-Containern arbeite, ist mir auch Abwesenheit vergleichbarer Lösungen unter FreeBSD schmerzhaft bewusst.

Wobei dieses ganze OCI-Zeugs bisher(!) ohnehin eine Linux-only-Veranstaltung ist.
Wenn Du da irgendwie ein "Docker"-Image auf Windows laufen lässt, dann funktioniert das ja im wesentlichen so, das eine LInux-VM hochgefahren wird um dann darin die Container-Anwendung auszuführen. So ne von-hinten-durch-die-Brust-ins-Auge-Geschichte.
Wenn Du es so machst, dann kannste auch gleich FreeBSD als OCI-aware bezeichnen.

Der Bugtracker von KVM als Bestandteil der Linux-Kernels ist öffentlich.

Und was ist mit VMWare und Hyper-V? :-)

KVM hat auch die Kinderkrankheiten hinter sich gelassen, die bhyve noch auskurieren muss.

Da würde ich vielleicht sogar noch mitgehen. Also wenn Du sagst: Die anderen Lösungen gibts schon länger und damit ist die Wahrscheinlichkeit höher, das zumindest grobe Bugs (a-ka Kinderkrankheiten) schon gefixt sind. Aber so hast Du ja nicht argumentiert. Du hast Dich rein auf die offenen Bugs bei bhyve bezogen. Und das ist dann insgesamt ein bisschen zu wenig.

Vor allem weil mit mehr Funktionalität (die die etablierteren Lösungen ja auch ohne Zweifel haben und was von Dir ja auch durchaus zu Recht als Vorteil für diese Lösungen gewertet werden) auch mehr potentielle Bugs bedeuten.

Solange bhyve mit den De-Facto-Standardtools in diesem Bereich nicht ordentlich zusammenspielt, tue (nicht nur) ich mir schwer, bhyve als ernsthafte Alternative in Betracht zu ziehen.

Es hängt halt davon ab, was man braucht. Wie an anderer Stelle schon gesagt soll bhyve ja auch weniger als "große Lösung" herhalten (also da wo die ganzen etablierten VM-Lösungen benutzt werden). Das braucht man nämlich nicht überall.

Und in seiner Nische macht bhyve einen guten Job. Ungeachtet dessen, das hier und da noch was fehlt. Das wird auch so niemand bestreiten.
bhyve jeglichen Nutzen abzusprechen ist da trotzdem völlig überzogen.
Wie schon mehrfach gesagt; Kommt darauf an was man machen möchte

Um wieder on-topic zu werden, schon der Betrieb einer Windows-VM kann aktuell noch sehr abenteuerlich werden.

Der Betrieb von Windows ansich kann schon sehr abenteuerlich werden. :-)
Ansonsten hat es natürlich nur begrenzten Wert irgendwelche einzelnen Bugs rauszusuchen. Denn die findest Du in jedem Programm.
Ich könnte auch einfach hingehen und sagen: KVM auf Intel-Prozessoren? Seeehr abenteuerlich:

206215 – QEMU guest crash due to random 'general protection fault' since kernel 5.2.5 on i7-3517UE

bugzilla.kernel.org

Irgendwelche einzelnen Bugs rauszufischen und daraus irgendwelche halballgemeinen Aussagen draus zu basteln -> das ist abenteuerlich.