Hinweise zu Ausfallsicherheit und Performance/Caching
Hinweise zur Performance: 3-stufig
Grundsätzlich verbessert der PARTapplicationServer die Performance (Suche und Index-Browsing).
Wenn CADENAS_DATA auf einem Extra-Filer liegt, dann sollte das Caching für den PARTapplicationServer aktiviert werden. Siehe hierzu Abschnitt 1.3.5.8.3.7, „ Indexdateien von $CADENAS_DATA auf PARTapplicationServer cachen “.
Wenn der Client eine schlechte Netzwerkverbindung zum PARTapplicationServer hat, dann sollte PARTdataManager Client-Caching aktiviert werden (Squid oder RFS). Siehe Abschnitt 1.3.5.8.2.4, „Caching clientseitig bzw. an Nebenstandorten “.
Von CADENAS implementierte Backup-Server- Strategie
Details hierzu finden Sie unter Abschnitt 1.4.4.1, „ Dialogbereich "Verbundene Server" “.
PARTapplicationServer als Dienst einzurichten hat den Vorteil, dass er beim Start des Serverrechners automatisch gestartet wird und Windows-Mechanismen zur Überwachung der Stabilität genutzt werden, wie z.B. Neustart bei Absturz (nach einer Minute [kann per registry noch weiter runtergestellt werden]).
Siehe hierzu unter Abschnitt 1.3.5.7, „ PARTapplicationServer als Dienst einrichten “.
PLINKDB läuft meist auf einem vorhandenen DB-Server, dessen Verfügbarkeit vom Kunden gewährleistet wird (DB-spezifische Strategien)
Für den Ablageort des Poolverzeichnisses gibt es mehrere Möglichkeiten:
Poolverzeichnis auf Server legen, aber mit anderer Freigabe als CADENAS_DATA
CADENAS_DATA=/server/share/data Poolverzeichnis=/server/share2/data/pool
CADENAS_DATA auf ein dummy-Verzeichnis legen, dann kann das Poolverzeichnis auf den Server zeigen.
CADENAS_DATA=c:/dummydir Poolverzeichnis=/server/share/data/pool
Wichtig ist nur, dass das Poolverzeichnis nicht unter CADENAS_DATA liegt; denn dann ist das RemoteFileSystem für das Poolverzeichnis zuständig. Und damit ist es ReadOnly.
Die in den Konfigurationsdateien eingestellten Ports für den PARTapplicationServer und den Suchserver sind per Default unterschiedlich, so dass man auf einem Server in der Umstellungsphase parallel fahren kann.
Verlangsamen der Suche bei Verwendung einer virtuellen Festplatte
Beim Testen auf einer Virtuellen Maschine ist zu berücksichtigen, dass die C-Platte auf dem Server nicht wirklich lokal ist, sondern im Netzwerk liegt. (Bei einer "echten" C-Platte ist die Geschwindigkeit evtl. höher.)
Wenn Caching eingesetzt wird, werden alle Suchindexe auf dem PARTapplicationServer zwischenspeichert. Das ist sinnvoll, weil Zugriff auf lokale Ressourcen schneller ist.
Im Falle einer VM passiert aber in Wirklichkeit etwas anderes: Aus dem Netz wird wieder zurück ins Netz gecacht und dann von dort geladen… Dies kann beim Kunden ein "Flaschenhals" sein.
Besser ist ein ESX-Host mit lokalen Platten. Noch besser ein ESX-Host mit lokalen SSDs. Damit könnte man die Suchzeiten nochmal drücken, vor allem wenn eine Suche so viele Teile liefert, dass nicht mehr alles in den Hauptspeicher passt. Außerdem hat man dann keinen Netzwerkengpass.
