• Thomas Pollinger
• 26.06.2017
• DE

Gewusst wie! "Cluster-Communication optimieren"

Optimieren ist immer so eine Sache, denn man fragt sich erstmal: "Was soll ich denn optimieren?". In diesem Fall war es recht einfach, da viele s.g. " Warning " Meldungen im wsms.log aufgelaufen sind. 

Grund dafür war die Freigabe (Release) eines Templates an einer Content-Klasse, welche eine zentrale Rolle spielt und dazu noch eine extrem hohe Anzahl von Instanzen besitzt. In diesem Fall handelt es sich um die zentrale Masterpage, welche das Grundgrüst zu jeder Webseite ist. Wir haben da eine Menge Instanzen (mit ca. 16.000+) und wenn man dann am Code des Templates an dieser Content-Klasse was ändert, kann es schon zu vielen Updates im Cache des Mangement Servers (bei jedem Node im Cluster) führen.

Wenn nun diese Meldungen im wsms.log in einer sehr hohen Anzahl auftreten.

Quelle: OpenText.WS.MS.Cache.UpdateClusterCacheWorker.LogFinishClusterMessage (:0)
Komponente: ClusterMessage
Kategorie: Application
Schweregrad: Warning
Nachricht:
Server:03CDCD719AA048D7855BCD30CF7CB6A4, MessageId:19A9A05B7FF243FDB7959AF589C7D8A4,
Receiver:27630022EF574515BE5E58B76DDEF96F, Created:06/22/2017 13:11:13,
Type:CacheUpdater, Status:None, Message:cache: ElementCache;8c681c01-ece4-4fc8-b1fb-45c4a7760501,
action: Clear, item: , Info:Transfering message took longer than current threshold: 00:00:12.7969314

Dann muss man erstmal nicht beunruhigt sein, sondern sich besonnen an die Optimierung des Web Site Management (RedDot CMS) Server Clusters machen.

Anpassung der richtigen Konfiguration

Für die korrekte Kommunikation innerhalb eines Management Server Clusters, werden s.g. "Cluster-Tickets" zwischen den einzelnen Cluster-Nodes verschickt. Wenn einer der Nodes es nicht rechtzeitig, in der Glütigkeitsdauer des Tickets, schafft in diesem Fall den Cache zu überarbeiten, dann wird dies mit einem Warning in das wsms.log dokumentiert. Dies ist dann erstmal nur ein Zeichen, dass der aktuell eingestellte Wert nicht ausreichend ist und angepasst werden sollte.

Die passende Konfiguration findet man in der OpenText.WS.MS.ObjectService.exe.config. welche im Verzeichnis OpenText\WS\MS\Services\Navigation zu finden ist. Dort gibt es die Möglichkeit die Anzahl der s.g. ClusterThreads zu verändern:

<?xml version="1.0"?>
<configuration>
  <system.runtime.remoting>
    <customErrors mode="off"/>
    <application>
      <lifetime leaseTimeout="10M" renewOnCallTime="10M"/>
      <service>
        <wellknown mode="Singleton" objectUri="ConfigurationResources" type="Reddot.CMS.Resources.ResourceProxy, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="Reddot.CMS.Rendering.PageRenderer" type="Reddot.CMS.Rendering.PageRenderer, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="RenderService" type="Reddot.CMS.Rendering.RenderService, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="EventLog" type="Reddot.CMS.Interop.Logger, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="Reddot.Vb6.DataFunctions" type="Reddot.Vb6.DataFunctions, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="PageIndexCache" type="Reddot.CMS.Project.Navigation.PageIndexCache, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="LanguageData" type="Reddot.CMS.Resources.LanguageDatabase, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="NavigationServiceFunctions" type="Reddot.CMS.Project.Navigation.NavigationServiceFunctions, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="OpenText.WS.MS.Cache.CacheManager" type="OpenText.WS.MS.Cache.CacheManager, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="Reddot.CMS.SessionState.SessionService" type="Reddot.CMS.SessionState.SessionService, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="Reddot.CMS.Project.ProjectService" type="Reddot.CMS.Project.ProjectService, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="Reddot.CMS.Project.ICheckRights" type="Reddot.CMS.Interop.CheckRights, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="Reddot.Vb6.Vb6Services" type="Reddot.Vb6.Vb6Services, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="Reddot.Vb6.MessageService" type="Reddot.Vb6.MessageService, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="ClusterMessage" type="Reddot.Vb6.ClusterMessage, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <wellknown mode="Singleton" objectUri="CacheMessage" type="OpenText.WS.MS.Cache.CacheMessage, OpenText.WS.MS.Server, Version=16.0.1.0, Culture=neutral, PublicKeyToken=9763136D9E6661AD"/>
        <activated type="Reddot.CMS.Project.Navigation.PageIndexCleaner, OpenText.WS.MS.Server"/>
      </service>
      <channels>
        <!-- This channel must be named in order to prevent "Channel has
             already been registered" errors. The remote logging mechanism
             tends to register an unnamed TCP channel before the service
             process has fully initialized. -->
        <channel name="ServiceProcessTcpChannel" ref="tcp" port="10082">
          <serverProviders>
            <formatter ref="binary" typeFilterLevel="Full"/>
          </serverProviders>
          <clientproviders>
            <formatter ref="binary"/>
          </clientproviders>
        </channel>
      </channels>
    </application>
  </system.runtime.remoting>
  <appSettings>
    <add key="RenderSpotError" value="false"/>
    <add key="UsePreCaching" value="false"/>
    <!-- Use multiple threads to render NavigationOutputAreas  -->
    <add key="MultiThreadRendering" value="true"/>
    <!-- The number of threads that are used to render NavigationOutputAreas -->
    <add key="RenderThreads" value="100"/>
    <!-- The number of threads used to work on cluster updates -->
    <add key="ClusterThreads" value="500"/>    
    <!-- The time between cache cleanup runs -->
    <add key="CacheServiceTimer" value="00:01:00"/>    
    <add key="CacheTimeStampTimer" value="00:00:05"/>
    <add key="CacheMonitoring" value="0"/>
    <!-- Threshold for cache release in MB -->
    <add key="CacheMemory" value="2500"/>
    <!-- Release percentual number of items in the cache in case of a cache memory threshold violation  -->
    <add key="CacheRelease" value="30"/>
    <add key="ClientSettingsProvider.ServiceUri" value=""/>
  </appSettings>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/>
  </startup>
  <system.web>
    <membership defaultProvider="ClientAuthenticationMembershipProvider">
      <providers>
        <add name="ClientAuthenticationMembershipProvider" type="System.Web.ClientServices.Providers.ClientFormsAuthenticationMembershipProvider, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" serviceUri=""/>
      </providers>
    </membership>
    <roleManager defaultProvider="ClientRoleProvider" enabled="true">
      <providers>
        <add name="ClientRoleProvider" type="System.Web.ClientServices.Providers.ClientRoleProvider, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" serviceUri="" cacheTimeout="86400"/>
      </providers>
    </roleManager>
  </system.web>
  <runtime>
    <gcServer enabled="true"/>
  </runtime>
</configuration>

In unserem Fall haben wir uns von dem Standardwert Woche für Woche nach oben gearbeitet, bis wir einen Wert gefunden haben, welcher nicht mehr zu den Meldungen geführt hatte. Dabei ist wichtig, auch das Verhalten des gesamten Systems zu beobachten. Also Dinge wie:

• CPU-Auslatung
• Speicher-Auslastung
• I/O-(Storage)-Auslastung
• Netzwerk-Auslastung
• Meldungen in der Windows Ereignisanzeige
• Allgemeines Verhalten des Management Server
• Einträge im wsms.log

Innerhalb des Clusters sollte dieser Wert auf alles Nodes gleichzeitig und auf den selben Wert angepasst werden. Nach der Änderung dieses Wertes ist es Notwendig, die Dienste des Management Server frisch zu starten. Alternativ kann man auch den ganzen Server neu starten, um z.B. zu sehen ob nach der Änderung ein Neustart des gesamten Systems noch reibungslos funktioniert.

Hinweis: Diese Anpassungen sollten besonnen vorgenommen werden und in kleinen Schritten. Das bedeutet zwar mehr Zeitaufwand und eine längere Analysephase, jedoch auch weniger Risiko und bessere Vergleichswerte ;)

Tipp: Nach der Änderung sollte man sich zwingend eine Kopie oder Sicherung der Dateien anlegen. Denn mit jedem Update des Management-Server, welches einen s.g. "Reset Configuration Files" durchführt, sind diese Anpassungen wieder weg.

Fazit

Nicht jede Fehlermeldung oder Warnung in einem Log bedeutet erstmal das etwas kaputt ist. Denn viele Meldungen deuten einfach nur daraufhin, dass bestimmte Einstellungen im System noch nicht optimal sind und eine Anpassungen benötigen. Das solche individuellen Anpassungen Zeit benötigen und auch je nach Umgebung anders aussehen können, liegt in der Natur der Sache. Jedoch sind diese auch wichtig, damit eine Software korrekt arbeiten und sich den Gegebenheiten auch anpassen kann. 

Ebenfalls ist es wichtig, wenn ein seltsames Verhalten nach Änderung der Einstellung auftritt, dies zu dokumentieren und auch zu melden. Denn wenn eine Software immer nur mit Standardwerten betrieben und auch getestet wird, kann es gut sein, dass sich noch an der einen oder anderen Stellen Probleme auftun.

Daher sollte man immer ein Vorher vs. Nachher Verhalten dokumentieren und auch dies mit den passenden Logfiles, Einstellungen, Screenshots usw. sichern. Damit auch OpenText innerhalb der Entwicklung die Chance bekommt, das Verhalten zu reproduzieren, zu analysieren und dann dafür eine passende Korrektur zu liefern.

In diesem Sinne, viel Spaß beim tunen ;)

Über den Autor: