elmeracmeee
Goto Top

Verwaltung für ein- und auschecken von VMs

Hallo,

wir haben ca. 20 Mitarbeiter, die für die Wartung von älteren Maschinen und Anlagen, teils sehr alte Software benutzen müssen.
Passend zu der alten Software ist dementsprechend auch das OS. Ab Win XP ist alles dabei.
Früher hatten wir dazu eigene Laptops, die für den jeweiligen Auftrag dann aus dem Schrank geholt wurden.
Probleme: Überschneidung von Aufträgen, aber nur ein Gerät da und Hardwaredefekte.
Idee war dann, wir virtualisieren dies.
Dies funktioniert auch prinzipiell gut. Die MA kopieren sich die notwendige VMs auf den eigenen Laptop und fahren dann zur Anlage.
Nun hat sich aber herausgestellt, dass auf diesen VMs und an den Programmeinstellungen auch Änderungen vorgenommen werden müssen.
Die angepasste VM wird dann wieder auf die zentrale Ablage kopiert.
Damit ist die Herausforderung hier wahrscheinlich schon jedem klar.
Der letzte VM, die hochgeladen wird, gewinnt. Hat jemand vorher eine Änderung hochgeladen, wird das überschrieben.

Das Problem ist den MA bekannt, aufgrund der Anzahl der MA und mittlerweile auch VMs verliert man aber die Übersicht.

Wir sind also auf der Suche nach einer Lösung / Software / Verwaltungssystem mit der man VMs aus- und einchecken bzw auch versionieren kann.
Kennt jemand dazu etwas? Oder hatte schon mal eine ähnliche Herausforderung?

Derzeit nutzen wir den VMWare Workstation Player.

Danke und Gruß

Content-ID: 668539

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

Ausgedruckt am: 24.11.2024 um 15:11 Uhr

150631
150631 02.10.2024 aktualisiert um 09:11:01 Uhr
Goto Top
Die Maschinen Vor Ort haben ja nicht immer eine IP-Kommunikation. Schon mal drüber nach gedacht S5, S7, ModBus, RSxyz usw in IP zu Kapseln und den VMs zukommen zu lassen, VMs die nicht zwingend mit auf den Bau getragen werden müssen?

Ansonsten eine Versionierungs-Software. PLM System usw...
ukulele-7
ukulele-7 02.10.2024 um 09:16:28 Uhr
Goto Top
Also die Situation ist schon sehr speziell. Wenn die VMs auf ihrer zentralen Ablage nur "liegen" und nicht von dort aus online gehen könnte streng genommen auch jedes DMS dafür eingesetzt werden. Aber bei jeder neuen Version wird die komplette Datei dupliziert, nicht nur etwa Änderungen. Das könnte schnell speicherintensiv werden.
ElmerAcmeee
ElmerAcmeee 02.10.2024 um 09:24:42 Uhr
Goto Top
Hallo,
Die Maschinen Vor Ort haben ja nicht immer eine IP-Kommunikation. Schon mal drüber nach gedacht S5, S7, ModBus, RSxyz usw in IP zu Kapseln und den VMs zukommen zu lassen, VMs die nicht zwingend mit auf den Bau getragen werden müssen?
Kannst du das näher ausführen?
Du meinst die VMs im RZ hosten und das Protokoll per Converter, Fritzbox und VPN dorthin leiten?


Ansonsten eine Versionierungs-Software. PLM System usw...
Für Standard Dateien hätten wir ein DMS. PLMs sind auch im Einsatz. Aber nichts was mit 30GB VMDK Dateien umgehen könnte.
Aber von der Idee her, ja.
ukulele-7
ukulele-7 02.10.2024 um 09:38:50 Uhr
Goto Top
Du kannst den Nutzern auch das Recht Ändern und Löschen auf dem Volume für die VMDKs entziehen, damit zwingst du sie, neue Versionen auch als neue Datei abzulegen. Ein Datum + ggf. Benutzername als Namenskonvention und schon habt ihr eine Versionierung. Allerdings hast du dann kein Checkout / Sperre, das müsste auch organisatorisch gelöst werden.
StefanKittel
StefanKittel 02.10.2024 um 10:01:50 Uhr
Goto Top
Hallo,

über Versionierung wurde ja schon gesprochen.

Ich wäre auch ein Fan dafür die VM im RZ zu hosten und nur die Kommunikation zum Standort zu schicken.
Sofern das technisch geht. Es ist ja nicht alles Ethernet was glänzt...

Alternativ werfe ich noch eine verzögerte Versionierung in den Raum.
Die Techniker dokumentiere alle gemachten Änderungen und spielen die VM nicht zurück.
In der Firma setzt sich Jemand mit den Notiozen hin und ändert die VM direkt am Server.
Damit umgeht man auch das Problem, dass zwei Leute gleichzeitig Änderungen machen.
Ja, das ist aufwendiger. Ist aber die Frage wie häufig Änderungen vorkommen und wie aufwendig diese sind.

Stefan
StefanKittel
StefanKittel 02.10.2024 um 10:08:12 Uhr
Goto Top
Nachtrag zu Versionierung.
Man muss ja nicht die ganze VMDK übertragen.

Warum nicht Git innerhalb der VM nutzen um die Program- und Konfigurationsdateien zu übertragen?
Für Registryänderungen kann man diese recht einfach in eine Datei schreiben und dann zurückschreiben.

Sofern die VM Internet kann.

Stefan
ElmerAcmeee
ElmerAcmeee 02.10.2024 um 10:11:24 Uhr
Goto Top
Hallo,
Zitat von @ukulele-7:
Also die Situation ist schon sehr speziell. Wenn die VMs auf ihrer zentralen Ablage nur "liegen" und nicht von dort aus online gehen könnte streng genommen auch jedes DMS dafür eingesetzt werden. Aber bei jeder neuen Version wird die komplette Datei dupliziert, nicht nur etwa Änderungen. Das könnte schnell speicherintensiv werden.

richtig, die Dateien liegen nur dort und laufen nicht auf einem Hypervisor.
Natürlich müssen wir ausrechnen was uns das kostet und ob die Kunden bereit sind dies zu tragen.
Storage und Backup nutzen Dedup. Von daher hält sich das in Grenzen.

Organisatorisch hatten wir das bereits versucht. Mit steigender Anzahl an MA und VMs funktioniert das leider nicht. daher auch dieser Thread.
Das mit Online hosten und das Protokoll zu konvertieren ist ein interessanter Ansatz. Ich werde das mal mit den Kollegen ausarbeiten.
Die Rückmeldung hierzu wird dauern ...


Danke und Gruß
ukulele-7
ukulele-7 02.10.2024 um 10:29:55 Uhr
Goto Top
Ich finde den Ansatz von @StefanKittel tatsächlich besser, weil er auch eine Dokumentation bildet, in denen die Änderungen aufgelistet werden. Das kann helfen ähnliche Änderungen an ähnlichen Systemen umzusetzen und bildet die Information einfach sehr präzise ab.

Tatsächlich stellt sich die Frage wie oft wirklich Änderungen passieren und ob man bei einer Versionierung alte Versionen lange vorhalten muss. Wenn Anfangs schon niemand daher geht und die Änderungen, wie vorgeschlagen, dokumentiert und dann integriert, wird wohl auch niemand den Aufwand betreiben wollen, das rückwirkend zu machen. Das kann eigentlich nur dazu dienen, einen kürzlich aufgetretenen Versionskonflikt mühsam zu bereinigen. Wenn aber keine Probleme auftreten, wird keiner mehr zwei alte Versionen booten und sich allen Ernstes alle Unterschiede angucken.
150631
150631 02.10.2024 um 11:10:05 Uhr
Goto Top
Zitat von @ElmerAcmeee:

Hallo,
Die Maschinen Vor Ort haben ja nicht immer eine IP-Kommunikation. Schon mal drüber nach gedacht S5, S7, ModBus, RSxyz usw in IP zu Kapseln und den VMs zukommen zu lassen, VMs die nicht zwingend mit auf den Bau getragen werden müssen?
Kannst du das näher ausführen?
Du meinst die VMs im RZ hosten und das Protokoll per Converter, Fritzbox und VPN dorthin leiten?


Ansonsten eine Versionierungs-Software. PLM System usw...
Für Standard Dateien hätten wir ein DMS. PLMs sind auch im Einsatz. Aber nichts was mit 30GB VMDK Dateien umgehen könnte.
Aber von der Idee her, ja.

Ja. So die Idee. Selbst die Fritzbox wäre denkbar 11
Michi91
Michi91 02.10.2024 aktualisiert um 12:15:10 Uhr
Goto Top
Naja, du kannst auch GIT einsetzen um große Dateien zu versionieren. Zusammen mit Deduplizierung wird sich die Datenmenge hoffentlich in Grenzen halten. Die Mitarbeiter müssen Ihre Änderungen sauber dokumentieren und ggf. muss einer den Hut aufhaben und ggf. die Änderungen mergen.

Bei VM's sicher nicht einfach, daher: was @StefanKittel schrieb: Die Änderungen innerhalb der VM z.B. mit GIT versionieren face-smile
Und dann gibts zwei Varianten: Der Mitarbeiter holt sich alle Änderungen vor der Arbeit ab, oder es gibt eine Deploymentpipeline, welche eine neue VM erzeugt und der Mitarbeiter kann diese dann herunterladen face-smile

Alternativ sich mit Config-Management wie Puppet, Ansible usw. befassen.

Eine weitere, organisatorische, Lösung: Änderungen dürfen nur an einem laufenden System vorgenommen werden, an dem sich jeweils nur eine Person anmelden kann und dann wird nächtens ein Export erzeugt.