Jump to content

Spackenheimer

Newbie
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

2 Neutral

About Spackenheimer

  • Rank
    Newbie
  1. Hallo liebes Forum wir haben seit 17. März Probleme mit zwei Windows 2016 Std. VMs, die als Terminalserver im Verbund laufen, einer davon ist der Broker. Die VMs frieren nach dem Hochfaren bei der ersten Anmeldung komplett ein (auch bei einem lokalen Konto). Sie antworten dann auch nicht mehr auf Ping. In der VMware Konsole kreiselt teilweise noch der Kreis bei der Anmeldung, teilweise bewegt sich aber gar nichts. Nach Zeitraum x, meist ca. 10 Minuten, reagieren sie auf einmal wie von Geisterhand wieder, auch der Ping kommt ab dem Zeitpunkt wieder zurück. Das Verhalten zeigen sie wie es aussieht nur nach dem Boot, wenn sie durchlaufen gibt's keine Probleme. Da es ab dem 17. März auftrat und an dem Tag bzw. wahrscheinlich in der Nacht auch Updates installiert wurden, hatte ich natürlich Windows Updates im Verdacht, habe auf einen Stand von der Woche davor zurückgesichert - kein Unterschied, Fehler tritt auch ohne die Updates vom 17. März auf. Der Fehler tritt übrigens auch nicht bei jedem Boot auf! Es wirkt willkürlich. Ist-Umgebung: 3 Fujitsu ESXi Hosts welche im Cluster mit HA-Unterstützung laufen (noch unter VMware 6.0). Speicher ist ein Dell Unity das per FC angebunden ist. Der Fehler tritt nur bei diesen beiden VMs auf. Wir haben noch einen anderen 2016 Std, der zeigt das Verhalten nicht, hat aber auch nicht die aktuellsten Updates. Es wurde an den VMs nichts installiert, da hat sich seit Monaten nichts geändert. Sie wurden ursprünglich Ende 2017 installiert, waren seit Mitte 2018 im produktiven Einsatz und liefen seitdem reibungslos durch. Der Fehler tritt auf jedem Host auf. Auch wenn man die VMs komplett heruntergefahren hatte. Die Auslastung der Hosts ist nicht außergewöhnlich. Wir haben schon alle VMs heruntergefahren und die Hosts neugestartet, sie liefen seit 240 Tagen - keine Besserung. Wir haben sogar einen Ersatz-Host dort ins Netz gebracht, aktuelle und ungenutzte Hardware von vor 2 Jahren, der Datenspeicher ist ebenfalls ein anderer (per NFS von OpenE eingebunden), die Switches etc. über die er ins Netzwerk geht sind andere. Der Host (Supermicro) läuft unter VMware 6.5, wir haben die VMs also auf diesen Host zurückgesichert, auf 6.5 aktualisiert, die VMware Tools aktualisiert. Das lief die ersten 10 Neustarts dann auch, weswegen wir Kompatibilitätsprobleme mit 2016 und VMware 6.0 im Verdacht hatten - bei Tests gestern Abend trat der Fehler dort aber wieder auf. Man findet auch in keinem Log Fehler, weder im vSphere, noch in VeeamOne. Die einzige Auffälligkeit die ich dort feststellen konnte war das hier, Speichernutzung ging unter die Decke, obwohl die Maschine nichts gemacht hat. 32GB Ram, die normalerweise auch bei voller Nutzeranzahl nicht über 25GB Auslastung gehen. Zur Wiederholdung: es passierte in diesem Zeitraum auf der VM absolut nichts. Man sieht, dass es sich ab etwa 8:20 Uhr (erster Screenshot) bzw. 9 Uhr (zweiter Screenshot) wieder normalisiert hat, ab dann arbeiten die VMs als wäre nichts gewesen und bringen auch normale Performance. So langsam gehen mir die Ideen aus. Die Terminalserver neu zu installieren wollte ich mir wenn möglich ersparen, zumal ich bei meiner Recherche Beiträge gesehen habe, wo der Fehler auch nach Neuinstallationen auftrat.
  2. Ja, das hätte ich dazuschreiben können, zumal es im Nachhinein damit eigentlich auch offensichtlich war. :) Das Umstellen der 1Gbit auf Standby sollte im laufenden Betrieb ohne Ausfall möglich sein oder? EDIT: Mut zur Lücke - erwartungsgemäß keine Ausfälle beim Umstellen der 1Gbit Karte als standby.
  3. Habe es zwischenzeitlich gefunden. Die Hosts sind über zwei unterschiedliche physische NICs angebunden, die interne 1Gbit Karte und eine gesteckte 10Gbit. Der Lastausgleich der vSwitche war auf "Anhand der ursprünglichen ID des virtuellen Ports routen" gestellt. Habe auf "Ausdrückliche Failover-Reihenfolge verwenden" gestellt, damit passiert laut Doku kein Lastausgleich und da die 10Gbit Karte in der Failover-Reihenfolge oben steht wird nun nur sie genutzt. Alle vorher langsamen VMs sind nun schneller.
  4. Hallo, wir setzen einen Cluster aus 3 identischen Hosts sein, auf denen insgesamt ca. 25 VMs verteilt sind (gleichmäßig verteilte Last). Die Hosts sind untereinander mit 10Gbit Karten an 10Gbit Switches mit guten Kabeln verbunden. Ich habe das Problem, dass einige VMs nur 1Gbit Geschwindigkeit bekommen, obwohl der VMXNET3 Adapter konfiguriert ist und in den Eigenschaften der Netzwerkverbindung auch 10Gbit angezeigt werden. Die VMs hängen pro Host jeweils an denselben vSwitches in denselben VM-Netzwerken. Das Problem betrifft nur einzelne VMs pro Host. Andere VMs desselben Hosts bekommen mit denen auf anderen Hosts die vollen 10Gbit, also liegt es nicht an den Hosts oder der physischen Verkabelung. Die betroffenen VMs bekommen mit anderen VMs desselben Hosts volle 10Gbit, nur eben nicht zu einem anderen Host. VM1 auf Host1 zu VM2 auf Host1: 10Gbit VM1 auf Host1 zu VM3 auf Host2: 1Gbit VM2 auf Host1 zu VM3 auf Host2: 10Gbit Die Geschwindigkeit teste ich mit NetIO 1.33, die Ergebnisse sind reproduzierbar. An den VMware Tools und somit den Treibern der VMXNET3 scheint es nicht zu liegen, denn auch VMs mit älteren Versionen von 2015 kriegen die volle Geschwindigkeit. Außerdem kriegen die betroffenen VMs ja zu welchen auf demselben Host die volle Geschwindigkeit. Auch das OS scheint keinen Einfluss zu haben. Ich finde auch in den Eigenschaften der vSwitches oder der VMs keinerlei Einstellungen, die zum Problem passen würden. Die Tests im anhängenden Beispiel (192.168.3.32 ist eine betroffene langsame VM) gingen von Host 2 -> Host 3 Host 2 -> Host 1 (langsam) Host 2 -> Host 1 (schnell) Hier noch ein Schaubild meiner Tests, worin zu sehen ist, dass einzelne VMs betroffen sind, nicht aber die Hosts untereinander. Alle VMs haben den VMXNET3 Adapter und zeigen 10Gbit an. Rot = 1Gbit Grün = 10Gbit
  5. Nicht bei denen, das ist geradezu ausgeschlossen. Die sind froh, dass ihnen die Schuhe passen. MultiWan haben wir bereits, allerdings aufgrund von immer wieder aufgetretenen Problem beim Loadbalancing nur noch als automatisches Fallback.
  6. Die Telefone sollen ein anderes Gateway kriegen als die PCs, da die Telefonie über einen anderen Internetanschluss läuft. Verstehe noch nicht so recht, was ich dadurch komplizierter mache. So kann ich (für mein Empfinden unkompliziert :)) den Telefonen ein anderes Gateway zuweisen, habe sie sonst aber im selben Netz.
  7. Der Hintergrund ist, dass die physikalische LAN-Verkabelung für uns ein Mysterium ist und wir teilweise nur einen LAN-Anschluss pro Arbeitsplatz (oder sogar für mehrere) haben. Daher werden wir teilweise nicht drumrum kommen, den PC am Telefon durchzuschleifen. Die Telefone werden außerdem an die virtualisierte 3CX Telefonanlage angebunden und es soll sich alles im selben Netz (und VLAN?) befinden, sodass der Verkehr nicht geroutet werden muss.
  8. Findest du das für den Anwendungsfall auch Käse? Ein 255.255.254.0 Netz mit aktuell ca. 200 aktiven Geräten, in das wir ca. 100 Telefone integrieren wollen, und das eben gerne in einen definierten IP-Bereich. Der Hinweis war Gold wert! Mit 000413 funktioniert es dann auch. ;)
  9. Ich verstand den Hinweis nicht als bindend und dachte, dass es so nachhaltiger ist als ein neues Thema zu eröffnen, aber gut. :) Habe den obigen Beitrag bearbeitet, damit es nicht so aus dem Zusammenhang gerissen ist.
  10. Hallo Forum, ich versuche aktuell Telefonen per Richtlinie einen DHCP Bereich zuzuordnen, die MAC beginnt mit 00014. Wenn ich jedoch als Bedingung 00014* definiere, wird beim Hinzufügen die vorderste 0 entfernt und es wird 0014*. Vermutlich, weil die Eingabe als HEX erfolgen soll...? Dadurch funktioniert die Begingung nicht. Wenn ich 000014* eingebe wird es auch so gespeichert, dasselbe bei 0014*. Bringt mir nur beides nichts. :) Hat jemand eine Idee wie ich das umgehe?
×
×
  • Create New...