Warum virtualisiert man, ab wann lohnt es sich?

Hauptsächlich zur Erhöhung der Effizienz und Sicherheit, da die virtuellen Systeme (in der Theorie) sich nicht gegenseitig sehen und beeinflussen können.

Wenn eine VM kompromittiert wird, löscht man sie einfach und erstellt eine neue. Dann sind nur die Daten in der VM betroffen und die anderen bleiben unbetroffen.

Google bemühen...Für die Gründe findet zu ca 544.000 Seiten. Viel Spaß

Hallo Netzwerkazubiene,

hier ein paar Bespiele für Dich.

https://www.campusnet.de/leistungen/virtualisierung/

https://www.computerwoche.de/a/die-10-groessten-vorteile-von-server-virt ...

MfG ns81tec

Aha? Du scheinst ja ein richtiger EliteHacker zu sein. Ich hoffe du bist nicht für die Security bei euch zuständig.
Denn wenn VM1 und VM2 + VMx im gleichen Netz, in der gleichen Domäne und ggf. auch noch die gleichen BS sind. Wie kannst du dann sicherstellen bzw. behaupten, dass diese im Falle einer Kompromittierung nicht betroffen sind?

Ich schließe mich an. Diese Aussage von @EliteHacker ist so getroffen nicht zutreffend. Geradezu gefährlich, wenn man sich dann möglicherweise auch noch darauf verlässt.

Hi,

wie schon erwähnt, stell dir vor, du benötigst 10 verschiedene Server, die unterschiedliche Dienste bereitstellen, kaum CPU-Last erzeugen und nur mäßig RAM "fressen"
Beim Nicht-Virtualisieren bedeutet dies: 10 verschiedene Server, mit unterschiedlichen CPU-Konfigurationen und RAM-/ Storage-Bestückungen. Dazu dann 10 Wartungsverträge (oder eben x-Server "auf Halde")

Beim Virtualisieren stelle ich "nur" einen (ggf. zwei, der Redundanz wegen) Server dort hin, der ausreichend ausgestattet ist (z.B. 256GB RAM, zwei 16Core-CPUs und 5TB Storage im RAID5 oder RAID 10.
Die Anschaffungs- und Unterhaltungskosten dürften hier deutlich geringer sein.

Natürlich ist die Kehrseite auch: fällt dieser eine physische Server aus, hänge 10 virtuelle mit am Fliegenfänger...

Zudem ist das Backup und ein Restore deutlich leichter. wird eine gesicherte VM auf einem anderem physischen Server, aber wieder als VM bereitgestellt, hat das nahezu keine Folgeprobleme. Hab ich aber einen physischen Server gesichert, dessen Hardware schon 8 Jahre alt ist (die GL ist ein Sparfuchs), dürfte ein Restore auf jüngere Hardware mit etwas mehr Handarbeit einher gehen.


Wenn ich zudem drei Server habe, die so ausgelegt sind, dass die den Ausfall eines Servers kompensieren können, kann ich im laufenden Betrieb auch mal eben die Hardware mit Updates etc. versorgen - ohne, dass die User etwas merken.


Gruß
em-pie

Doch schon....denn Google verweist auch nur auf Foren, Blogs etc und diese werden von lebenden Pesonen mit Beiträgen versorgt. Somit zieht diese Ausrede nicht! Diese haben wir von Azubis zu oft gehört ;)

Aber das gröbste haben die Kollegen ja bereits geschrieben.

Den Rest erledigt Google, BING oder whatever

Du nennst selbst das beste Beispiel: Ein DC sollte nur ein DC sein, war immer schon so. Kleinigkeiten wurden da auch hier und da mal drauf gepackt (DHCP oder Druckserver) aber sicherlich kein SAGE, keine Datenbanken, kein Mail Server, etc.

Es wäre natürlich bequem ein Windows Update laufen zu lassen und alles ist aktuell aber was, wenn das Windows Update scheitert? Welche Software ist dann schuld? Selbst wenn heute das Setup von Software B nicht die Einstellungen von Software A überschreibt (wie früher mal) dann hast du immer noch eine enorme Komplexität zu berücksichtigen.

Aber alle anderen Vorteile sollte wirklich super in Blogs zu lesen sein, das Rad muss man nicht neu erfinden.

Das hoffe ich auch.


Wer hat was davon gesagt, dass die VMs im gleichen Netzwerk stehen?

Ach sooo, du redest von Windows...

Man kann eigentlich nie zu 100% feststellen, ob die Daten nicht betroffen sind. Deswegen habe ich oben extra "in der Theorie" geschrieben. Nichts ist zu 100% sicher. Es gibt keine absolute Sicherheit. Es geht um Risikominimierung und um das Senken der Eintrittswahrscheinlichkeit. Es bleibt immer ein Restrisiko übrig.

Wenn man es einem Laien erklärt, muss man manchmal Dinge vereinfachen. Ich hätte auch einfach ein paar Sicherheits-Buzzwords um mich werfen können, das hätte dann aber niemandem geholfen.

Also - mal ein paar Gründe warum man Virtuallisiert - nicht zwingend nach irgendwas geordnet und mit sicherheit nicht vollständig:

a) Stromverbrauch/Kosten: Würdest du die Dienste auf verschiedene Server aufteilen (z.B. weil du für 2 Kunden identische Server-Software auf demselben Port brauchst) hast du natürlich einen deutlich höheren Stromverbrauch wenn eben 2 Server laufen als wenn nur einer läuft der nur ne geringfügig höhere CPU-Last fährt.

b) Leistungsanpassung: Wenn du dir deinen Rechner anguckst wirst du sehen das die CPU den grössten Teil des Tages nur eines macht: Warten... und warten... und warten... Dem Server gehts da ähnlich. Der wartet, dann kommst du kurz mit deiner Anfrage, dann geht der wieder schlafen. Wenn du jetzt also 2 Server hinstellst hast du 2 Server die ggf. zu 99% Idle sind. Dafür bezahlst du aber 2x komplett die Hardware. ODER du nimmst halt 2 VMs. Der HyperVisior (ESXi, Win-HyperV,...) gibt nun die (virtuelle) Hardware an die VMs und du hast ne bessere Ausnutzung

c) Sicherheit: Nicht in dem Sinne wie der Elite-Hacker oben meinte (wenn eine VM gehackt wurde die einfach nur neu aufsetzen? Gute idee, damit der Hacker denselben Weg wieder gehen kann)?. Sondern: Nehmen wir an du hast 2 (oder mehr) Server zur Verfügung, RAM, HDD usw. haben die genug. Jetzt kannst du recht einfach nen Cluster aufbauen. Fällt dir die HARDWARE von Server 1 aus (weil die Azubine gemeint hat die muss den Stecker ziehen um ihr Handy zu laden :P) übernimmt halt Server 2. Im besten Fall vollautomatisch - d.h. der Endanwender bekommt nicht mal mit das dessen Server grad von einem phys. Server auf den anderen gewechselt hat. Diese Technik kann man natürlich auch gut nutzen wenn man z.B. Updates auf dem Host installieren will -> alle VMs auf den 2ten Server werfen, Updates einspielen, neustarten, VMs alle auf den ersten Server und Server 2 mit Updates versorgen... -> du hast keine Downtime mehr

d) Einfache Bereitstellung: Stell dir vor du musst z.B. die (automatische) Installation einer Software testen. Dein erster Durchlauf geht zu 90% und bricht dann ab. Bei einer VM kannst du einfach die "alte" Disk wieder einbinden, starten und fertig -> du must nicht lange mit Backup/Restore eines phys. Servers rumtoben. Danach kannst du weiter testen (würdest du den zweiten Test einfach auf der original VM machen könnte es ja sein das ein Fehler immer nur beim ersten Durchlauf auftritt weil irgendwo nen Timeout z.B. auftritt).

e) Restore: Natürlich ist es auch deutlich leichter eine VM wiederherzustellen. Nimm dir mal dein Windows von vor 10-15 Jahren und versuche das auf nem aktuellen Rechner wiederherzustellen -> es fliegt dir aufgrund fehlender Treiber idR jämmerlich um die Ohren. Wenn du aber z.B. nen Server als VM hast kannst du die VM auch einfach auf nem anderem Server (solang dasselbe OS für den HyperVisor) wiederherstellen. Es ist da ja keine reale Hardware-Bindung.

So - jetzt könnte man sich fragen: Warum dann nicht nur 2-x richtig grosse Server in nem Unternehmen und einfach ALLES als VM? Man könnte ja sogar die Arbeitsplätze als VM machen - wäre ja genial. Weil schon brauch ich nur 2 Server ins Backup nehmen und als Arbeitsplätze könnte ich mit RDP/Citrix/... mich an der VM anmelden und der ganze Laden läuft. Nun - in vielen Fällen geht das, aber nicht in allen. Nehmen wir an du möchtest einen Cisco-Switch konfigurieren. Dann ist natürlich blöd wenn du das Konsolenkabel nicht anschliessen kannst ;). Soweit es also um direkten Hardware-Zugriff geht wirds kompliziert. Wenn du CAD Arbeitsplätze hast haben die idR. Leistungsfähigere Grafikkarten - auch die kannst du natürlich nicht beliebig oft in den Server packen (u.a. weil die Hardware ja irgendwo stecken muss).

Dadurch hast du heute idR. Mischbetriebe bei denen einige Arbeitsplätze (oder auch nur Applikationen) als VM bzw. VM-Service laufen, andere direkt auf dem Rechner verbleiben. Man kann aber davon ausgehen das der Weg immer mehr in Richtung VM gehen wird (auch Cloud-Computing ist am Ende VM-Technik). Denn es ist nunmal finanziell (und auch umweltmässig) sinnlos wenn Rechner 90+% Idle fahren. Da macht es einfach mehr Sinn die Dinge zusammenzufassen. Denn anders als bei phys. Computern kann man bei VMs auch "overbooking" machen - solang man es nicht übertreibt. D.h. du weisst das dein Server zwar nur 128 GB hat, du hast aber VMs die zusammen 140 GB nutzen. Sofern aber nicht alle gleichzeitig laufen ist das kein Problem (und selbst wenn wirds erst dann zu nem Problem wenn die wirklich alle auch den Speicher nutzen). DAS ist dann eben die Aufgabe des Admins dafür zu sorgen das die Resourcen vernünftig genutzt werden.

Das Storage liegt bei Clustern/mehreren Servern üblicherweise extern (SAN). Es geht sogar noch besser, du kannst natürlich das Storage selbst auch noch virtuallisieren :D. Dabei jedoch immer im Hinterkopf behalten: Es sollte trotzdem sichergestellt sein das nicht 2 Server zur selben Zeit auf dieselben Daten zugreifen, das kann ganz böse ausgehen ... DARUM kümmert sich aber idR. eben auch die Cluster-Infrastruktur, man muss es halt nur im Kopf haben das auch zu prüfen DAS die das tut (oder das es mechanismen gibt die das erlauben)

Snapshots bzw eine VM Clonen ist auch noch praktisch zum Testen.

Ach ... diese Fachleute. Den allerwichtigsten Grund pro Virtualisierung habt Ihr natürlich vergessen zu erwähnen: man muss nicht einmal im Jahr 4 Server entstauben, sondern halt nur einen. Ist das nix?

LG, Thomas

Um nochmal auf die Eingangsfrage zu fokussieren:

Man könnte theoretisch alle Server-Dienste auf einen einzigen Blech-Server packen - macht man - wie du schon richtig erkannt hast - aber nicht.

Wenn man nur einen Blech-VM- Host hat und da alle Dienste in z.B. 10 VMs aufteilt, oder gar alle Dienste auf einem Win-Server, hat man aber auch noch nicht viel gewonnen, weil, wenn der Host ausfällt, sind alle VMs oder der WinServer mit allen Diensten mit offline.

Daher hat man 2 oder mehr Hosts, auf denen die VMs mindestens 1-fach redundant - also 2 synchrone Kopien - betrieben werden - HA: "High Availability".

Die Aufteilung der Dienste auf VMs ermöglicht die Sicherheits- und Lastabhängige Verteilung der VMs auf verschiedene Hosts - manuell oder auch automatisch.

Im Worst Case - Szenario ( z.B. Ausfall aller Server [in einem Raum/Gebäude] durch Feuer, etc.) kann man einzelne priorisierte Dienste Recht schnell auf schwächerer Hardware wieder vom Backup in Betrieb nehmen - falls gerade kein passender leistungsfähiger Server zur Verfügung steht.

Z.B. Hyper-V und DC-VM:

Die gesicherte VM könntest du notfalls ohne Zusatzsoftware sogar auf einem vergleichbar schwachen Office- Win10/Win11 PC aktivieren und in kurzer Zeit den wichtigsten AD-Dienst wieder am Start haben.

Die Denkweise kann hier noch viel weiter gehen - z.B. eine VM im Standort A, eine Kopie im Standort B - das wäre auch bei z.B. Feuer stabil redundant...

.

Hallo,
1. Ressourcen besser nutzen.
2. Dienste unabhängig voneinander betreiben
3. Hardware abhängig zu sein
4. Leichter Failover Lösungen aufbauen

der Logische nächste Schritt sind dann die Container Lösungen.

@wiesi200


Ja - noch ein gutes Argument! Diese Hardwareabhängigkeit durch Virtualisierung macht mich auch mehrmals in der Woche richtig rollig


Juppele - sollte man aber warten, bis die Lage an den Container-Umschlagshäfen wieder stabil ist.

LG, Thomas

sorry natürlich unabhängig

Moin...
oh... der Herr Elite Gedönsrat hat gesprochen...
zur erhöhung der effizienz ist schon mal richtig, aber hauptsächlich weill es dienste gibt ( MS EXchange, SQL, RDP usw.. die nicht zusammen auf einem Blech / VM laufen würden bzw. sollen!
das sie sich nicht gegenseitig sehen und beeinflussen können bzw.sollen ist natürlich bullshit... stell dir vor, dein exchange darf nicht auf das AD zugreifen.. etc...
ein Server, egal ob Blech oder VM, ohne das er dienste anbietet, oder konnektivität- wird nicht gebraucht, ergo- schalte ihn aus, dann wäre er sicher....
noch mehr Bullshit... ist nur schade, das sich kaum eine schad software daran hält.....

also sachen gibbet
Frank

N'Abend.
Der IT-Consultant sagt jetzt: Das skaliert besser.
Ein bisschen Wahrheit steckt da auch drin, einer VM hast du "mal eben" mehr RAM, mehr CPUs und größere Platten verpasst, ohne dafür den Schraubendreher rauskramen zu müssen. Dazu kommt, dass die "Ein-Server-für-alles"-Strategie ein sicherheitstechnischer Alptraum ist. Und dann noch die Tatsache, dass sich bestimmte Server-Dienste nicht gemeinsam auf einer Maschine betreiben lassen, weil es a) erst gar nicht geht oder b) nicht supported ist.

Je nach Größe eines Unternehmens kommt die Skalierung tatsächlich zum Tragen: Du kannst mit Virtualisierung deutlich mehr Server auf deutlich weniger Raum betreiben, benötigst also z.B. nur noch ein Rack statt eine ganze Reihe usw.

"Rentieren" kann sich Virtualisierung aber schon in Klein(st)betrieben, da auch (oder gerade?) dort das Thema Sicherheit (und Flexibilität) immer mehr in den Fokus rückt (bzw. rücken muss und wird).

Cheers,
jsysde

Ja natürlich sollten die Dienste nicht alle auf der selben Kiste laufen. Logisch! Selbstverständlich!


Ich meinte auf dem Host selbst, ohne Netzwerk.


Ich habe selten eine Schadsoftware gesehen, welche aus einer VM ausbricht und durch das Hostsystem andere VMs infiziert.

Höchstens über das Netzwerk, aber wer halt Firewalls nicht korrekt konfiguriert, ist selbst schuld.
Wenn man alle VMs in das selbe Netzwerk stellt und alles miteinander verbindet, dann kann die Schadsoftware sich auch auf die anderen VMs verbreiten. Logisch. Dann sind natürlich auch mal mehrere VMs unvertrauenswürdig.

Was habt ihr denn alle? Steigt mal ab.

Sehe ich auch so, heutige Empfehlungen gehen so weit, DCs in einem separaten VLAN zu platzieren, und das andere Clients/Server nur auf die nötigen AD-Ports/Dienste zugreifen kann.

Ebenso bei Datenbanken - warum sollte ein File-Server auf den DB-Port eines DB-Servers zugreifen können? Und auch AD-Ports braucht's zwischen den beiden nicht.
Praktisch wie ein Web-/Proxyserver in der DMZ und die Content-Server in anderen Netzen.

Natürlich muss hier für jedes Netz entschieden werden, wie weit die Trennungen sinnvoll sind..

und nicht zu vergessen..Updates und Backups...
Reboot von einer VM geht deutlich schneller als erst Mal 15 Minuten zu warten bis der Server mit den BIOS Checks durch ist.
Backups erstellen oder wiederherstellen....virtualisiert deutlich einfacher, ansonsten müsste man auf jeden Server einzeln einen Agent fürs Backup einsetzen. Oder Wiederherstellung....physikalischen Server Wiederherstellen dauert deutlich länger.

Und wegen "alles in einen", das will man weder physikalisch noch virtualisiert. Wenn due ienn WSUS oder Printerserver mal schnell durchstarten willst dtört das in der Regel kaum jemanden den Moment, wenn da noch der Exchange und der Fileserver drauf ist schon erheblich.
Und wenn dann ein Update irgendwie doch rumzickt was aber eben evtl. nur den Druckserver beeinträchtigt, dann kann es sein das alle anderen Komponenten auch betroffen sein.

Hallo.

Man kann zentrale Dienste bzw. Serverdienste - mittels virtueller Server - aber auch zu Tode separieren.

Schon öfter erlebt:

Kostspielige Fachsoftware eingekauft, läuft klassisch nach dem Server-Client-Modell (es gibt also eine Serverseite, ggf. noch mit DB, und eine Clientseite, jeweils mit eig. Setup usw. usf.). Dafür haben wir einen virtuellen Applikationsserver, wo solcherlei Software draufgehört bzw. grundsätzlich draufsoll.

Der Consultant des Herstellers kommt am Installationstag entweder persönlich oder per Fernwartung. Irgendwas klappt schon beim Server-Setup für die Fachsoftware nicht. Der Server ist 'ne ganz normale (virtuelle) Kiste mit allerlei Software drauf, ansich gut gepflegt, alle Windows-Updates drauf, genügend Rechenleistung, Plattenplatz und RAM vorhanden, aber das Setup der Software schmeißt 'nen Fehler, den weder der Consultant noch ich je gesehen haben. Abbruch, neuer Versuch. Wieder nix, Fehler an der gleichen Stelle. Abbruch, dieses mal Serverneustart und neuer Versuch. Das Gleiche. Fehlermeldung googeln. Nix zu finden. Oder nur ähnliches, das nicht passt. Er ruft einen Kollegen an, der weiß auch keinen Rat.

Und jetzt?

"Haben Sie noch einen anderen Server"?

"Dafür? Nein."

"Ihre Server sind doch virtuell, könnten Sie uns da nicht ... ?"

Mangels Datacentre-Lic. erstmal nachsehen, ob noch eine virtuelle Serverinstanz vom letzten Standardkauf offen (also frei) ist oder wäre. Falls ja, alles gut, falls nein, Chef erst fragen, ob ich bei Comparex auf die Schnelle einmal W2K16/19/22 Standard nachkaufen darf. Natürlich mit Bemerkung des Chefs, wozu das denn nun schon wieder sein soll. Erklärung, daß es der Consultant mit der neuen Software auf unserem - eigens für die Fachapplikationen vorgesehenen - Server nicht hinkriegt. "Das ist doch nicht unser Problem, der soll das gefälligst lösen!!!"

Termin verschoben ("wir müssen uns genauer erkundigen und melden uns wieder"). 2 Tage später schreibt mir der Consultant - erwartungsgemäß - daß dieser Fehler unbekannt und bisher bei keinem anderen Kunden aufgetreten sei und an unserem Server liegen müsse (der bisher alle anderen Fachprogramme anstandslos annnahm und beherbergte und ein fehlerfreies Anwendungsprotokoll aufweist).

Am Ende kriegt dieses eine Fachprogramm einen eigenen (virtuellen) Windows-Server.

Manche Softwarehersteller verlangen solches aber manchmal auch schon ausdrücklich vorab (also, daß ihr Zeug auf einem eigenen Server laufen muß und da hinterher auch nichts anderes drauf darf).

Ich hab' mittlerweile 4 solcher VMs, die eine, die ich wg. der geschilderten Installationsschwierigkeiten anlegen mußte, und drei weitere, weil der Softwarehersteller das von vornherein so verlangte. Was hätten die eigentlich früher, sagen wir vor 20 Jahren, gemacht? Verlangt, daß für jeden Popelkram ein eigenes, teures Blech gekauft wird?

Ich muß, glaube ich, nicht betonen, daß den 4 VMs 24/7/365 stinklangweilig ist. Die Programme sind - im Sinne von Leistung, RAM- oder Platzbedarf - vollkommen harmlos.

Was will ich damit sagen?

Wo Virtualisierung herrscht, vermehren sich die VMs mitunter wie die Karnickel. Oftmals unnötigerweise. Ist ja auch gar zu einfach, mal eben 'nen neuen Server aufzusetzen.

Mein Fazit: Ich finde schon, daß man nicht für jeden Popelkram eine eigene VM braucht, Dinge, die zueinander passen und/oder sich nachweislich nicht stören und nicht im Wege sind, dürfen auch gemeinsam auf eine VM. Bei einem Applikationsserver etwa. Oder, daß der DC auch DNS und DHCP macht. Oder der Druckserver gleichzeitig auch DMS und AV. Ist natürlich stets auch einzelfallabhängig, ich mein' das eher grundsätzlich. Die Vorteile der Virtualisierung stellt das ja trotzdem nicht in Frage.


Viele Grüße
von
departure69

Naja - ich kann schon verstehen wenn einzelne Dienstleister auch gerne eigene Server haben wollen. Denn da geht es ja auch um den Support UND um das Ansehen der (meistens ja neuen) Software beim Kunden. Jetzt kannst dir ja vorstellen - ich verkaufe dir meine Software für 500.000 Euro. Ich installiere die - und weil du mich drum bittest und ich nett bin auch auf einem Server bei dem schon eine andere Software läuft. Läuft auch alles gut - nur hat der andere Dienstleister eben ne Routine drin die z.B. jeden Morgen sagt "killall java" und seine SW neustartet. Da MEINE davon nix weiss rufst du morgens erstmal an weil mein Dienst natürlich nich da is... Jetzt geht die Fehlersuche los - und MEINE Software hat erstmal den Eindruck das die instabil is... ICH muss Zeit investieren um rauszufinden was da passiert - und habe vermutlich auch gleich noch das dicke "minus" im Buch weil ich ja deine Zeit auch "verschwende". Wir gucken immerhin einige Stunden drauf, prüfen Logs,... und die SW rennt stabil - bis morgen früh...

Und leider wird heute Software immer mehr nur noch hingepfuscht. Wenn die einmal läuft - bloss nie wieder anfassen... Und da man den anderen Dienstleister nich kennt - dem soll man vertrauen? Und im dümmsten Fall verliert man den Kunden weil die eigene "sch... Software" nich läuft - nur weil nen anderes Programm z.B. den Speicher nich sauber verwaltet,... Oder das andere Prog verlangt irgendwelche speziellen Update-Versionen die meines nich mehr unterstützt weil veraltet,...

Von daher macht das oft schon Sinn die Dienste zu trennen. Und zum Schluss machts auch für dich Sinn - denn oftmals musst du (per NDA) eh dafür sorgen das kein anderer, vorallem kein anderer Dienstleister, an meine Daten kommen kann...

@MirkoKR


Die Empfehlungen kommen von Leuten, die ihre Kohle mit administrieren verdienen? So was kann man in einer grossen Bude mit eigenem IT-Personal machen, in einer Einzelkämpferpraxis wüsste ich nach zwei Wochen VLAN-Basteln nicht mehr, um welchen Hals ich mein Stethoskop legen muss.

Ich habe - bis der Bill das Teil in's Digitalnirwana verbannt hat - 13 Jahre mit SBS gearbeitet - DC, Exchange, Printserver, Fileserver, UC-Server, Antimalwareserver, DB-Server meiner PVS - alles auf einem Blechle mit 32G-Ram und einem Xeon. Lief ohne jedes Problem.

Jetzt habe ich eine Kiste mit 2 Xeon Gold und 160 GB, in derem HyperV soviele Server-VM laufen, dass ich immer wieder gucken muss, wo da was spielt. Looft och. Ist aber deutlich aufwändiger zu unterhalten ... und der Krimskrams mit der TIS kommt ja noch on top. Mittlerweile frisst mir das Gedöns geschätzt ein bis zwei Tage pro Monat - jut, am WE sind das sicher keine Achtstundentage, aber nerven tut das schon ein bisschen.

So viel als nötig, so wenig wie möglich sollte IMHO die Devise sein ...

LG, Thomas

Nein
Dazu brauchst Du Windows Server mit RDS.

Pauschal eine perfekte Lösung zu empfehlen ist da eher schwer. Im Dezember ist bei uns ein Datev Server installiert worden. Thematisch wollt ich ihn zu unserer Zeiterfassung packen. Der Dienstleister merkte hier Ann das es zwar geht aber nicht so toll ist. Datev hat mehrere Updates pro Jahr wo der Server rebooten muss. Da Lohnabrechnung nur immer nur an ein paar Tagen im Monat ist, stellt das kein großes Problem. Die Zeiterfassung bei uns darf nur Sonntags außer Betrieb nehmen. Beides aber Server wo sich kein Mensch direkt anmeldet und nur "Dienste" laufen.
Aber grundsätzlich ja, bei Virtualisierung nicht übertreiben und schauen was Sinn macht

moin...

wirklich?

Frank

Neben Sicherheit und Flexibilität andere Betriebssysteme nutzen zu können (Linux, ältere Win-Versionen etc) geht es auch um Konflikte/Abhängigkeiten. Wenn du alles auf einen einzigen Server installierst, hängt schnell alles mit allem zusammen. Dafür hat man mit VMs mehr Wartungsaufwand, weil man eben 10 Betriebssysteme hat statt einem. Um das einzudämmen, hat sich mittlerweile die Containerisierung zunehmend durchgesetzt. Zumindest unter Linux, in Windows verfolge ich das schon länger nicht mehr. Container nutzen einen gemeinsamen Kernel und isolieren vereinfacht gesagt nur eine Anwendung (z.B. einen Webserver) in einen Container.

Der Overhead eines kompletten Betriebssystemes, wie man es bei den klassischen VMs hat, fällt dadurch weg. Dadurch lassen sich deutlich mehr Container auf dem gleichen bare metal Server betreiben, als VMs. Dennoch sind die Container voneinander isoliert, haben ihr eigenes Dateisystem, eigene Bibliotheken und so weiter. Außerdem ist das ganze portabel. Das Image kann man einfach auf einer anderen Maschine nutzen. Wenn man die Anwendungsdaten in den Volumes mitkopiert, hat man eine 1:1 Kopie, etwa als Testsystem.

Unabhängig dazu: Probleme mit Windows-Updates gab es soweit ich das mitbekommen habe früher nicht so häufig. Das scheint mit Windows 10 zugenommen zu haben. Da wurden auch allerlei Änderungen vorgenommen, wie z.B. kürzere Supportzyklen und damit häufigere Funktionsupdates. Als ich selbst noch viel Windows genutzt habe, hat mir Windows 10 zwei Systeme mit Updates zerschossen. Das ist mir davor nie passiert, obwohl ich zu sämtlichen Versionen bis XP mindestens ein System längere Zeit im Einsatz hatte. Mit Virtualisierung hat das Problem also weniger etwas zutun, man hat ja auch schon mit älteren Windows-Versionen virtualisiert.