TM-Server (VM per ESXi) im Fehlerfall auf Client klonen

[cardisch]

Hi@all,

ich betreue die Arzt-Praxis meines Bruders, bin also weder mit Patienten, noch mit dem Turbomed per se vertraut.
Kurze Einführung in die Softwareumgebung:
HP-Server, dort ist ein ESXi installiert, die die einzige VM mit TM beherbergt (W2k8R2).
Die Datensicherung erfolgt im ersten Schritt auf eine NAS, mittels (aktuell) Acronis Backup, vielleicht zukünftig mittels Veeam Backup (um die VM als Ganzes zu sichern).
Ich habe hier einen Client mit ausreichend Speicher, SSDs und VMWare Workstation ausgerüstet, damit im Fehlerfall dieser die Funktionalität des Servers übernehmen kann.
Heute wurde testweise eine solche VM erstellt und ein Komplettbackup des Servers eingespielt.
Der Server als solcher arbeitet auch, innerhalb der VM bekomme ich Turbomed auch gestartet, jedoch können sich die Clients (trotz des "natürlich" gleichen Namens/IP-Adresse) nicht mit dem Server verbinden.
Fehler:
"Diese Station wurde als Arbeitsstation des Servers "Server" konfiguriert. Bei der Verbindungsaufnahme trat jedoch eine unzulässige Zeitüberschreitung auf. Bitte überprüfen Sie den Servernamen, den Serverport und ggf Ihr Netzwerkkonfiguration. Das Programm wird jetzt beendet"

Hostname, statische IP (sowohl an Client, als auch am Server), Freigaben, alles passt und ist funktionsfähig.
Firewall am Client ist aus, IPCONFIG /flushdns, rauswerfen und wiederaufnehmen der Clients in die Domäne...Nichts hat geholfen.
Jetzt brauche ich mal einen Tipp, welche Stellschraube mir helfen kann.
Danke und Gruß

Carsten

[nmndoc]

Hallo,

Kurze Einführung in die Softwareumgebung:
HP-Server, dort ist ein ESXi installiert, die die einzige VM mit TM beherbergt (W2k8R2).
Die Datensicherung erfolgt im ersten Schritt auf eine NAS, mittels (aktuell) Acronis Backup, vielleicht zukünftig mittels Veeam Backup (um die VM als Ganzes zu sichern).

ich bin mir nicht 100%ig sicher, denke aber, das Veeam auch die Storage-API benötigt, um die VM an sich zu sichern. D.h. mit der kostenlosen ESXi-Lizenz wird das dann nichts, sondern mind. die kleinste (Essentials oder so ähnlich).

Ich habe hier einen Client mit ausreichend Speicher, SSDs und VMWare Workstation ausgerüstet, damit im Fehlerfall dieser die Funktionalität des Servers übernehmen kann.
Heute wurde testweise eine solche VM erstellt und ein Komplettbackup des Servers eingespielt.

D.h. wenn ich es recht verstehe, haben Sie eine VM frisch aufgesetzt und dann dort hinein zurück gesichert? Ist das das gleiche Betriebssystem?
Kopieren Sie doch mal die ganze VM, zB via vSphere Client > Datei > Export > OVF-Vorlage

Dann die auf den Client übernehmen, ob da das Problem dann auch noch auftritt.

Der Server als solcher arbeitet auch, innerhalb der VM bekomme ich Turbomed auch gestartet, jedoch können sich die Clients (trotz des "natürlich" gleichen Namens/IP-Adresse) nicht mit dem Server verbinden.
Fehler:
"Diese Station wurde als Arbeitsstation des Servers "Server" konfiguriert. Bei der Verbindungsaufnahme trat jedoch eine unzulässige Zeitüberschreitung auf. Bitte überprüfen Sie den Servernamen, den Serverport und ggf Ihr Netzwerkkonfiguration. Das Programm wird jetzt beendet"

Hostname, statische IP (sowohl an Client, als auch am Server), Freigaben, alles passt und ist funktionsfähig.
Firewall am Client ist aus, IPCONFIG /flushdns, rauswerfen und wiederaufnehmen der Clients in die Domäne...Nichts hat geholfen.
Jetzt brauche ich mal einen Tipp, welche Stellschraube mir helfen kann.

also, erstens s.o. (komplette VM übernehmen)

Dann: was bedeutet genau "alles passt". Kommen Sie vom Client auf zB \\<server>\turbomed\?
Kann der TM-Server vom Client aus auch angepingt werden?
Sonst würde ich darauf tippen, dass die virtuelle Netzwerkkarte nicht als "bridged" konfiguriert ist.

FastObjects Server läuft auch?

und: die alte Server-IP ist der VM zugewiesen, nicht dem Client?

[cardisch]

Hallo NMNDOC,

ZU 1:bin jetzt in der Praxis, leider abreiten die Damen hier noch, kann noch nicht alles testen, aber schon einmal antworten.
Ich hoffe nicht, dass sich Acronis und Veeam beißen, Acronis arbeitet ja zeitgesteuert aus dem Windows, Veeam soll (ist aber noch Zukunftsmusik) Sonntag die gesamten VMDK-Files sichern.
Der Nachteil vom Veeam, nämlich dass in der kostenlosen Version nur gesamte VMs sichern kann, sehe ich in der Zwischenzeit als Vorteil.

Zu 2:
Ja, habe eine VMWare Workstation installiert, eine neue VM erstellt, dabei auch sofort genügend Platz (600GB) für die VM erstellt.
Dann habe ich mittels Acronis-Boot-Medium ein erstelltes Vollbackup (also System, Laufwerk C (Windows) und D (Daten)) zurückgespielt und gestartet.
Es handelt sich also um das "echte" System. Natürlich wurden sowohl der Esxi als auch das Windows-Gastsystem auf dem ESXi heruntergefahren und sogar vom Netz getrennt.
Die Sicherung über VSphere kann ich aktuell noch nicht testen, da immer noch Angestellte anwesend sind .

Zu 3:
Ja, ein Ping (Name/IP) funktioniert einwandfrei, auch die Freigaben des Servers können erreicht werden (und der Server findet seine Freigaben zur vorhandenen Backup-NAS auch)
Ob die Karte aktuell "bridged" ist kann ich nicht sagen, siehe oben.
Fast Objects "sollte" laufen, da der Server selbst ja arbeiten kann, ich gucke aber in ca einer Stunde danach.
Ja, die VM des Servers hat (da Domänencontroller) natürlich ein statische IP-Adresse.

Gruß

Carsten

[cardisch]

Bin jetzt am VM-Server des Client-PC.
Netzwerkkarte steht auf bridged, FastObjects-Dienst läuft, Ping "Server" -4 (um IPv4 zu erzwingen) funktioniert mit Hostnamen und IP-Adresse.
Habe testweise die Netzwerkkarte mal auf Host-only gestellt, da funktioniert dann WIRKLICH nichts, witzigerweise ist die Fehlermeldung dieselbe.
Ich weiß nur nicht, ob die MAC-Adresse eine Rolle spielt.
Habe heute mit unseren Turbomed-Supportern gesprochen, die kennen den Fehler, auch oder gerade aus VMs heraus, da hat aber IPv6 für Probleme gesorgt, dies ist hier komplett ausgeschaltet.
Gruß

Carsten

[cardisch]

Hi,

Ich habe zwar nicht die Lösung des Problems, aber eine elegante Umschiffung gefunden.,
Den virtuellen Server starten, warten, dass alles Dienste (vermeintlich) laufen.
Dann "Einfach" einen Dauerping an die IP des Servers (nur zur Kontrolle) schicken, die Netzwerkkarte im VMWare von "Bridged" auf "Host-only" umstellen, den Ping kontrollieren, wenn ein paar Pakete abhanden gekommen sind wieder zurückstellen, fertig.
So könnt ihr eure gesicherten Maschinen virtuell schnell wieder einsatzfähig machen (so wie es hier geplant war).

Gruß und Danke für die Unterstützung,

Carsten

[nmndoc]

Hallo,

der ESX ist ja ausgesteckt? Sonst hätte ich gesagt evtl. liegts am Switch/MAC-Cache. Oder Arp-Cache am Client ("arp -a)"


Evtl. ist es doch ein IPv6 Problem bzw. mit der Namensauflösung?

Ich nehme an, der DC hat IPv6 aktiv und Nameserver für die Clients?
Falls ja: U.u. ist DNS nicht korrekt konfiguriert und die Namensauflösung über IPv6 funktioniert nicht.

Evtl mal zum Testen in den TM-Grundeinstellungen am Client statt des Servernamens die IP eintragen.

Ansonsten ist das leider aus der Ferne etwas schwierig ... wenn man davor sitzt ist es (manchmal) dann ganz einfach (oder man kann zumindest systematisch Fehler ausschließen).

Sonst evtl. doch auch mal den Umzug der ganzen VM testen.


PS: weg veeam: ich meinte etwas anderes: BAckup-Software für ESX benötigt i.d.Regel die Storage-API von ESX, die aber erst ab der (kleinsten) kommerziellen Lizenz freigeschaltet ist.
Kann aber sein, dass das kostenlose Veeam die nicht braucht, weil es ohnehin nur komplette VMs sichern kann (und zB keine Differenz etc)

[wahnfried]

...die kennen den Fehler, auch oder gerade aus VMs heraus, da hat aber IPv6 für Probleme gesorgt, dies ist hier komplett ausgeschaltet.

...dazu eine Erfahrung aus einer anderen Umgebung:

Habe derzeit einen TurboMed-Server als Win7-Arbeitgruppen-PC laufen, dort hatte ich (aufgrund erinnerter Infos, das dies stören könnte) das IPv6 auch ausgeschaltet.

Dann bekam ich öfter Probleme, weil die Netzwerkverwaltung die Verbindung zu den anderen PC "verlor". Dadurch hatten die Clients der Praxis in irregulären Abständen dann einen Verbindungsabbruch zum FOS und damit dann keine Praxis-arbeit mehr möglich außer am Server... Die Netzwerkerkennung musste dann per Klick und "Heimnetz neu konfigurieren als privates Netzwerk" umgestellt werden, dann lief es wieder.

Einmal wurde mir im Laufe einer Fehleranalyse aber angezeigt, dass IPv6 nicht aktiv sei und das ein Problem sein könne.

Daraufhin IPv6 wieder aktiviert (ohne spezifische Einstellungen) - und der Fehler trat seitdem nicht mehr auf.

Vielleicht aktivieren Sie doch mal das IPv6 "zusätzlich"?

Grüsse, Wahnfried

[EXEWERKER]

Turbomed kommuniziert nicht via IP v6. Deshalb würde ich es ausschalten, da man so die Fehler in in IP v4 schneller findet.

[cardisch]

Hi@all,

Schön, dass das Thema noch immer hochgehalten wird.
Habe mich bei einem DomänenAdministrator Infos geholt, der kennt dieses etwas zickige verhalten von virtuellen Maschinen.
Insofern nehme ich das als gegeben hin und mache einfach einen passenden vermerk im notfallhandbuch.
Gruß
Carsten

[wahnfried]

Turbomed kommuniziert nicht via IP v6. Deshalb würde ich es ausschalten, da man so die Fehler in in IP v4 schneller findet.

Das ist ja schön, aber warum zickt meine Netzwerkkommunikation dann rum, wenn ich IPv6 deaktiviere? Das heißt doch für mich, dass Windows nicht so gern ohne dies arbeitet...

Insofern lieber MIT aktiviertem IPv6 und OHNE Verbindungsabbrüche als andersherum...

TurboMed (das Programm hier...) hat sich nicht darüber beklagt.

Sollte es einen echten Fehler in der TurboMed-Client-Server-Kommunikation geben, kann ich ja ggfs das IPv6 zur Fehlersuche deaktivieren.

Grüsse, Wahnfried

[nmndoc]

Turbomed kommuniziert nicht via IP v6. Deshalb würde ich es ausschalten, da man so die Fehler in in IP v4 schneller findet.

Ohne die genaue Umgebung (u.a. Anwendungen) zu kennen, würde ich von solchen pauschalen Maßnahmen absehen.

Hier mal einige Aussagen, wie Microsoft das sieht:

IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function.

Oder wie wäre es damit:
It’s a common misconception that unchecking IPv6 disables the protocol when in fact all it does is introdUCE transient errors. Windows Vista and later operating systems heavily rely upon IPv6 für internal operation, which means the protocol cannot be disabled or uninstalled entirely. unchecking IPv6 on the adapter settings only unbinds the protocol from the NIC and the OS can still attempt to send remote traffic to the NIC where it never hits the wire.

@Wahnfried: erklärt evtl. auch Ihre Erfahrungen.

Ansonsten gibt es auch Anwendungen zB Exchange die ohne IPv6 gar nicht mehr laufen. Und auch DC auf neueren OS Versionen machen m.E. Probleme.

[EXEWERKER]

Ohne die genaue Umgebung (u.a. Anwendungen) zu kennen, würde ich von solchen pauschalen Maßnahmen absehen.

IP V6 ist ja auch nicht grundsätzlich sinnlos, sondern nur für Turbomed unnütz.
Zur Ursachenforschung schalten wir es aus. Dann stellen sich die IP v4 Fehler auch heraus.

Wenn alles geht, dann kann man es auch wieder anschalten. Schaden wird es nicht.

[Yong]

TM am Server mal als Mehrplatzbetrieb starten. Bei uns trat so ein Fehler auf, wenn am Server Einzelplatz Betrieb lief. . .

. . .
Der Server als solcher arbeitet auch, innerhalb der VM bekomme ich Turbomed auch gestartet, jedoch können sich die Clients (trotz des "natürlich" gleichen Namens/IP-Adresse) nicht mit dem Server verbinden.
. . .

[cardisch]

@Yong

Problem ist von meiner Seite gelöst.
Trotzdem danke