Autor: Michael Schroeder

Veröffentlicht am

Zero-Client: Fujitsu veröffentlicht Version 6

Nachdem es letze Woche aus internen Quellen angekündigt wurde, erschien heute die Version 6 des Zero-Client Managers mit allen zugehörigen Softwareprodukten wie Direct Service oder des Lizenzservers.

Ich vermisse allerdings noch das Updatepaket, mit welchem man z.B. eine ZC-Controller der Version 5 auf Version 6 aktualisieren kann.

Was ist neu:

  • Support für VMware WDDM Display Driver (endlich!) 🙂
  • Anmeldung per RSA Secur ID (alternativ)
  • Unterstützung vSphere 5 U1
  • Unterstützung VMware View 5.0.1
  • Unterstützung Windows 8 Gastsysteme
  • Unterstützung vCenter Appliance
  • Fehlermeldung „connection lost unexpectedly“ erscheint nicht mehr wenn Sitzung am Zero-Client getrennt wird.
  • bessere Unterstützung für Hyper-V (auch für Multilanguage Windows)
  • viele weitere Bugfixes

Praxistest folgt in Kürze… 🙂

Veröffentlicht am

CPU Ready und CPU Co-STOP

Bei der Kontrolle der Leistungsdaten eines ESXi Servers (vSphere-Client – Performance – Realtime) fiel mir ein unglaublich hoher Wert für CPU-Ready auf. Laut Graph war dort ein Wert von fast 23 Sekunden. Wie kann das sein?

Bevor man die Werte deutet, sollte man zunächst einige Bergriffe definieren.

CPU-Ready

Angabe in Prozent (%RDY) oder in Millisekunden (ms). CPU-Ready bezeichnet die Zeit, die eine VM warten muß bis ihrer vCPU eine physische CPU zugeteilt wird.

VM bereit – Host nicht.

Co-Scheduling

Hat eine VM mehr als eine vCPU, so müssen diese zeitgleich physischen CPU Kernen des Host Systems zugeordnet werden. Das bedeutet im Klartext, eine VM mit einer vCPU muß warten bis ein Kern frei ist. Eine VM mit 4 vCPU muß entsprechend warten bis 4 Kerne gleichzeitig frei sind. Letzteres ist wesentlich weniger wahrscheinlich. Und damit sind wir auch beim dritten Schlagwort: Co-Stop.

Co-STOP

Zeit, die eine VM bereit ist, jedoch aufgrund von Wartezeiten durch Co-Scheduling nicht einem physischen Kern zugeteilt werden kann. Im Prinzip das selbe wie CPU-Ready, jedoch für VMs mit Virtual Symetric Multiprocessing (vSMP). Während hohe CPU-Ready Werte auf ein Hostsystem unter Druck schließen lassen, kann man dies bei hohen Co-STOP Werten nicht unbedingt folgern. Es bedeutet nur, daß der Host nicht die geforderte Anzahl physischer Kerne gleichzeitig bereitstellen kann. „CPU Ready und CPU Co-STOP“ weiterlesen

Veröffentlicht am

Resourcepools und VMs auf einer Ebene

Zu meiner regelmäßigen vSphere Lektüre gehört der Blog von Frank Denneman. Oft findet man dort sehr gute Grundlagenartikel mit übersichtlichen Illustrationen.

In einem seiner aktuellen Beiträge schreibt er über VMs, die sich zusammen mit Resourcepools auf einer Hierarchie-Ebene befinden. Diese Vorgehensweise findet man immer wieder bei Kunden im produktiven Einsatz. Meist aus Unachtsamkeit, oder mangels tieferem Verständnis der Thematik. In seinem Artikel schildert er die Auswirkungen eines solchen Umfelds, wenn es zu akuter Ressourcenknappheit innerhalb des Clusters kommt.

Weitere Artikel zum Thema

ElasticSky: Das Resourcepool Paradoxon (Deutsch)
Yellow-Bricks: Resource Pool Pie Paradox (Originalartikel)
Yellow-Bricks: Resource Pools and Shares

Veröffentlicht am

Dateireplikationsdienst neu starten

Gelegentlich bringt ein Domaincontroller einen Fehler im Ereignisprotokoll unter Dateireplikationsdienst (NT File Replication Service NTFRS).

Der Dateireplikationsdienst konnte die Replikation von DC1 nach DC2 für c:\winnt\sysvol\<DOMAIN> mit DNS-Namen DC2.domain.com nicht aktivieren. Es wird ein neuer Versuch gestartet.

Das Protokoll auf der Gegenseite zeigt jedoch keinerlei Probleme mit dem Dateireplikationsdienst. Oft ist diese Meldung ein Artefakt oder Hinweis auf eine Störung in der Vergangenheit, die aber aktuell nicht mehr besteht.

Zur Klärung ist es nicht notwendig, den Domaincontroller neu zu starten. Oft genügt es, den Dateireplikationsdienst neu zu starten.

net stop ntfrs

Nach erfolgreicher Beendigung des Dienstes wird dieser neu gestartet.

net start ntfrs

Wenn wirklich kein Problem mehr besteht, dann findet man im Ereignisprotokoll den Event 13516.

Der Dateireplikationsdienst verhindert nicht mehr die Heraufstufung des Computers DC1 zum Domänencontroller. Der Systemdatenträger wurde erfolgreich initialisiert. Der Anmeldedienst wurde benachrichtigt, dass der Systemdatenträger jetzt als SYSVOL freigegeben werden kann.

Links:

Microsoft TechNet zum Fehler 13508