Szenario Lastverteilung

Im Lastverteilungsszenario werden mehrere Suchanwendungen betrieben, die alle den gleichen Datenstand haben. Alle Suchanwendungen befinden sich normalweise hinter einem Loadbalancer der die Anfragen entsprechend verteilt. Eine Suchinstanz aus dem Verbund ist per Definition der Master, von dem die Daten an die anderen Suchinstanzen (Slaves) verteilt werden. Die UI-Anwendung ist mit diesem Such-Master verknüpft. Ob der Such-Master, wie die anderen Instanzen, Produktiv-Suchanfragen beantwortet oder als reine Staging-Umgebung betrieben wird, ist Ihnen überlassen. Diese Dokumentation geht davon aus, dass Sie drei produktive Suchinstanzen (search01, search02 und search03) nutzen wollen, bei denen search01 der Such-Master ist und alle ein unabhängiges Dateisystem haben.

Mit diesem Szenario lässt sich auch ein Fallbacksystem, um beispielsweise die Ausfallsicherheit zu erhöhen, erstellen.

Konfiguration Analytics

Sie müssen sicherstellen, dass Analytics Zugriff auf die Such- und Trackinglogfiles der produktiven Suchanwendungen besitzt. Falls jede Suchinstanz ihr eigenes Ressourcenverzeichnis hat, kann das entweder dadurch gemacht werden, dass Analytics Dateizugriff auf diese Verzeichnisse hat oder indem die Logfiles aus den Ressourcenverzeichnissen der Suchanwendungen auf den Analytics-Server übertragen werden. Die Such- und Trackinglogfiles werden nach dem Schreiben nicht mehr von der Suchinstanz verwendet, so dass diese verschoben werden können. Die Dateien müssen auf dem Analytics-Server nach Suchinstanz getrennt bleiben. Die Zielstruktur auf dem Analytics-Server könnte beispielsweise wie folgt aussehen:

/opt/factfinder/search01
  |-- searchLogs
    |-- channel-a
    	|-- daily
  	    	|-- ff.20121126.log
 		    |-- ff.20121126.log.catalog
  |-- scicLogs
    |-- shoppingcart.2012-12-10.log
    |-- shoppingcart.2012-12-11.log
/opt/factfinder/search02
  |-- ...
/opt/factfinder/search03
  |-- ...

Dementsprechend müssen die Pfadangaben in der application.properties angepasst werden (siehe FACT-Finder einrichten).

ffa.persistence.searchLogDirectory=/opt/factfinder/search01/searchLogs,/opt/factfinder/search02/searchLogs,/opt/factfinder/search03/searchLogs
ffa.persistence.scicLogDirectory=/opt/factfinder/search01/scicLogs,/opt/factfinder/search02/scicLogs,/opt/factfinder/search03/scicLogs

Konfiguration bei Nutzung eines Netzwerkspeichers

Falls alle Suchinstanzen das gleiche Ressourcenverzeichnis nutzen, muss eine weitere Java-Option gesetzt werden (siehe Software einrichten), da alle Instanzen ansonsten in das gleiche Logfile schreiben und dies zu Problemen führt. Fügen Sie daher bitte folgende Option in ihre setenv.sh-Datei und passen die Bezeichnung hostname jeweils an (zB search01):

-Dfff.node.logs.subdirectory='hostname'

Wenn diese Option aktiv ist, legt die jeweilige Suchanwendung im Logfileordner ein Unterverzeichnis mit der hostname-Bezeichnung an, für die Master-Anwendung können Sie das in der UI-Anwendung unter System -> Systeminformationen -> Pfade prüfen. Sollten Sie es zusätzlich bei den Slaves überprüfen wollen, so rufen Sie jeweils folgende URL auf:

http://<URL zur Suchanwendung>/Messages.ff?do=showSystemMonitoringOverview

Sollten die Pfade korrekt angezeigt werden, so muss auch hier noch die Konfigurationsdatei application.properties der Analytics-Anwendung mit den entsprechenden Pfaden angepasst werden (siehe oben).

Konfiguration Suchinstanzen

Wie zu Beginn erwähnt, gehen wir davon aus, dass die Instanz search01 unsere Masteranwendung ist. Das bedeutet, dass der FACT-Finder Nutzer alle Aktionen (zB Konfiguration von Einstellungen) auf dieser Instanz durchführt, daher muss die UI-Anwendung auf diese Instanz verweisen (siehe Konfiguration). Zudem wird diese Anwendung, als einzige im Verbund, die Produktdaten des Shops importieren und FACT-Finder Datenbanken erstellen, die anschließend an die anderen Instanzen verteilt werden, wodurch sich Last auf den anderen Systemen einsparen lässt. Für die Importe ist es notwendig, dass die Such-Master-Anwendung eine Verbindung zur Analytics Anwendung besitzt (siehe Konfiguration). Bitte prüfen Sie in der UI-Anwendung unter System -> Systeminformationen, dass alle Angaben richtig sind und die verknüpften Systeme gefunden werden.

Hinweis: Im Normalfall sind die Importe zeitgesteuert, so dass am besten das Änderungsdatum überwacht werden sollte. Alternativ ist es auch möglich die Import über APIs anzustoßen und nach Beendigung des Imports die Synchronisation durchzuführen.

Anpassungen in der Master-Suchanwendung

Um die spätere Synchronisation der Daten zu vereinfachen, sollten die Scheduler-Konfigurationen in den FACT-Finder Ressourcen aus dem conf-Ordner in ein anderes Verzeichnis gelegt werden. Wir empfehlen daher den Ordner conf/scheduler eine Ebene höher zu schieben, so dass dieser direkt im anwendungsspezifischen Ressourcen Verzeichnis liegt (Beispiel /opt/factfinder/fact-finder/scheduler). Damit FACT-Finder diesen Ordner danach wiederfindet, muss in der Konfigurationsdatei conf/fff.properties folgender Eintrag hinzugefügt bzw. angepasst werden:

scheduler.directory={APP_RESOURCES}/scheduler/

Bitte prüfen Sie im Anschluss ob die Konfiguration erfolgreich geändert wurde, indem Sie in der Oberfläche unter System -> Systeminformationen zuerst auf "Konfiguration erneut laden" klicken und danach die Einträge unter "Geplante Aufgaben" anschauen.

Synchronisation der Ressourcen

Damit die Such-Slaves mit aktuellen Daten und den Änderungen aus dem Such-Master versorgt werden, muss eine Datensynchronisation von Master zu den Slaves eingerichtet werden. Durch die obere Änderung des Scheduler-Verzeichnisses lasst sich dies beispielsweise über rsync durchführen. Im Detail muss der Inhalt folgender Unterordner des Ressourcen-Verzeichnisses zwischen den Instanzen synchron gehalten werden:

  • analytics
  • campaigns
  • conf
  • customClasses
  • indexes

Sobald dies eingerichtet und durchgeführt wurde, müssten die Konfigurationsdateien des Such-Masters auf allen Such-Slaves gespiegelt worden sein. Da wir im vorherigen Schritt die Datei conf/fff.properties bearbeitet haben, kann der Erfolg der Synchronisation über das vorhanden sein dieser Änderung nachgeprüft werden.

Anpassungen in den Slave-Suchanwendung

Auf den Such-Slaves müssen noch die Importe und andere regelmäßige Aufgaben deaktiviert werden, da diese von der Master-Anwendung übernommen werden. Hierzu kopieren wir zuerst das scheduler-Verzeichnis vom Master auf einen Slave und entfernen in diesem alle properties-Dateien mit Ausnahme von clearCache.properties und reloadAllDatabases.properties. Das angepasste Verzeichnis muss dann so auf die weiteren Slaves kopiert werden. Da wir dieses Verzeichnis nicht vom Master synchronisieren, werden die Änderungen nicht überschrieben.

Konfiguration bei Nutzung eines Netzwerkspeichers

Falls Sie einen Netzwerkspeicher nutzen, greifen alle Suchinstanzen automatisch auf die gleichen Konfigurationen und Datenbanken zu, so dass eine Synchronisation dieser entfällt. In dieser Variante ist es jedoch auch gewünscht, dass nur eine Suchumgebung im Verbund die Importe ausführt, so dass hierfür noch Anpassungen notwendig sind.

Wie bei der Konfiguration der Logfiles, muss auch hier eine weitere Java Option in der setenv.sh gesetzt werden, an Hand dieser, der Scheduler unterschiede Dateien verwendet. Bitte fügen Sie folgende Option hinzu und passen den Wert von hostname entsprechend an (zB search01).

-Dinstance='hostname'

Als nächstes verwenden Sie diese Java-Option in der Pfaddefinition für die Scheduler-Dateien. Wie bei der oberen Variante müssen Sie hierfür die Konfigurationsdatei conf/fff.properties anpassen und folgenden Eintrag hinzufügen oder anpassen:

scheduler.directory={APP_RESOURCES}/conf/scheduler/{prop:instance}/

Legen Sie danach im Ressourcen-Verzeichnis unter /conf/scheduler je ein Unterverzeichnis pro Instanz an, die jeweils entsprechend dem Hostnamen benannt ist (im Beispiel search01, search02, search03). Verschieben Sie danach die properties-Dateien unter conf/scheduler in das Unterverzeichnis der Such-Master-Anwendung (search01).

Kopieren Sie danach die Dateien clearCache.properties und reloadAllDatabases.properties zusätzlich in jedes Verzeichnis eines Such-Slaves.

Konfiguration Loadbalancer

Wenn das Personalisierungs Modul aktiv ist, ist es wichtig, dass Suchanfragen einer Session immer von der gleichen Instanz beantwortet werden. Aus diesem Grund muss der Loadbalancer session-sticky konfiguriert werden und die Zuordnung anhand des Parameters sid durchführen. Der Parameter kann sowohl im HTTP-Header als auch in den URL-Parametern vorkommen, so dass eine Prüfung beider Vorkommnisse wichtig ist.

Auf dieser Seite