Handbuch zu Tableau Server Enterprise-Bereitstellung

Die folgende Abbildung zeigt die relevanten Tableau Server-Prozesse und wie sie in der Referenzarchitektur bereitgestellt werden. Das ist die minimale für Unternehmen geeignete Bereitstellung von Tableau Server.

Die Prozessdiagramme in diesem Thema sollen die wichtigsten, bestimmenden Prozesse eines jeden Knotens zeigen. Es gibt viele unterstützende Prozesse, die ebenfalls auf den Knoten laufen und in den Diagrammen nicht dargestellt sind. Eine Liste aller Prozesse finden Sie im Konfigurationsabschnitt dieses Handbuchs: Teil 4 – Installieren und Konfigurieren von Tableau Server.

Tableau Server-Prozesse

Die Tableau Server-Referenzarchitektur ist eine Bereitstellung von Tableau Server in einem Cluster aus vier Knoten, mit einem externen Repository in PostgreSQL:

• Tableau Server-Anfangsknoten (Knoten 1): Auf diesem Knoten werden erforderliche TSM-Administrations- und Lizenzierungsdienste ausgeführt, die nur auf einem einzelnen Knoten im Cluster ausgeführt werden können. Im Unternehmenskontext ist der Tableau Server-Anfangsknoten der primäre Knoten im Cluster. Auf diesem Knoten werden auch redundante Anwendungsdienste mit Knoten 2 ausgeführt.
• Tableau Server-Anwendungsknoten (Knoten 1 und Knoten 2): Die beiden Knoten bedienen Clientanforderungen, stellen eine Verbindung zu Datenquellen und Datenknoten her und fragen diese ab.
• Tableau Server-Datenknoten (Knoten 3 und Knoten 4): Zwei Knoten, die für die Verwaltung von Daten vorgesehen sind.
• Externes PostgreSQL: Auf diesem Host wird der Tableau Server-Repository-Prozess ausgeführt. Für eine Hochverfügbarkeits-Bereitstellung müssen Sie einen zusätzlichen PostgreSQL-Host für aktive/passive Redundanz ausführen.

  Sie können PostgreSQL auch auf Amazon RDS ausführen. Weitere Informationen zu den Unterschieden zwischen der Ausführung des Repositorys auf RDS oder auf einer EC2-Instanz finden Sie unter Externes Tableau Server-Repository (Linux)(Link wird in neuem Fenster geöffnet).

  Für die Bereitstellung von Tableau Server mit einem externen Repository ist eine Tableau Advanced Management-Lizenz erforderlich.

  Wenn es in Ihrem Unternehmen kein internes Datenbank-Know-How gibt, können Sie den Tableau Server-Repository-Prozess optional in der standardmäßigen, internen PostgreSQL-Konfiguration ausführen lassen. In dem Standardszenario wird das Repository auf einem Tableau-Knoten mit eingebettetem PostgreSQL ausgeführt. In diesem Fall empfehlen wir, dass das Repository auf einem dedizierten Tableau-Knoten und ein passives Repository auf einem zusätzlichen dedizierten Knoten ausgeführt werden, damit Repository-Failover unterstützt wird. Weitere Informationen dazu finden Sie unter Repository-Failover ( Linux(Link wird in neuem Fenster geöffnet)).

  Die in diesem Leitfaden beschriebene AWS-Implementierung erläutert beispielsweise, wie das externe Repository auf PostgreSQL bereitgestellt wird, das auf einer EC2-Instanz ausgeführt wird.

• Optional: Wenn in Ihrem Unternehmen externer Speicher verwendet wird, können Sie den Tableau-Dateispeicher als externen Dienst bereitstellen. Der externe Dateispeicher im zentralen Bereitstellungsszenario ist in diesem Handbuch nicht enthalten. Informationen dazu finden Sie unter Installieren von Tableau Server mit dem externen Dateispeicher (Linux(Link wird in neuem Fenster geöffnet)).

  Für die Bereitstellung von Tableau Server mit einem externen Dateispeicher ist eine Tableau Advanced Management-Lizenz erforderlich.

PostgresSQL-Repository

Das Tableau Server-Repository ist eine PostgresSQL-Datenbank, in der Serverdaten gespeichert werden. Zu diesen Daten zählen Informationen über Tableau Server-Benutzer, -Gruppen, -Gruppenzuweisungen, -Berechtigungen, -Projekte, -Datenquellen, -Extraktmetadaten und -Aktualisierungsinformationen.

Die standardmäßige PostgresSQL-Bereitstellung belegt fast 50 % der Systemspeicherressourcen. Abhängig von der Nutzung (für die Produktion und große Produktionsbereitstellungen) kann die Ressourcennutzung steigen. Daher empfehlen wir, den Repository-Prozess auf einem Computer auszuführen, auf dem keine anderen ressourcenintensiven Serverkomponenten wie VizQL, Hintergrundprozesskomponenten oder die Daten-Engine ausgeführt werden. Das Ausführen des Repository-Prozesses zusammen mit einer dieser Komponenten führt zu E/A-Konflikten, Ressourcenbeschränkungen und einer Verschlechterung der Gesamtleistung der Bereitstellung.

Knoten 1: Anfangsknoten

Auf dem Anfangsknoten wird eine kleine Anzahl wichtiger Prozesse ausgeführt und die Anwendungslast mit Knoten 2 geteilt.

Der erste Computer, auf dem Sie Tableau installieren (der "Anfangsknoten"), hat einige einzigartige Eigenschaften. Drei Prozesse werden nur auf dem Ausgangsknoten ausgeführt und können – außer bei einem Ausfall – nicht auf einen anderen Knoten verschoben werden. Dies sind der Lizenzdienst (Lizenzverwaltung), der Aktivierungsdienst und der TSM-Controller (Administration Controller).

Knoten-1-Failover und automatische Wiederherstellung

Die Lizenz-, Aktivierungs- und TSM-Controller-Dienste sind für die Funktionsfähigkeit einer Tableau Server-Bereitstellung entscheidend. Im Falle eines Ausfalls von Knoten 1 können Benutzer weiterhin eine Verbindung zu der Tableau Server-Bereitstellung herstellen, da eine ordnungsgemäß konfigurierte Referenzarchitektur Anfragen an Knoten 2 weiterleiten wird. Ohne diese zentralen Dienste befindet sich die Bereitstellung jedoch in einem kritischen Zustand und es besteht die Gefahr, dass sie jederzeit ausfallen kann. Informationen dazu finden Sie unter Automatische Wiederherstellung des Anfangsknotens.

Knoten 1 und 2: Anwendungsserver

Auf den Knoten 1 und 2 werden die Tableau Server-Prozesse ausgeführt, die Clientanforderungen bedienen, Datenquellen abfragen, Visualisierungen generieren, mit Inhalten umgehen, Verwaltungsaufgaben erledigen sowie andere zentrale Tableau-Geschäftslogik verwalten. Die Anwendungsserver speichern keine Benutzerdaten.

Hinweis: "Anwendungsserver" ist ein Begriff, der sich auch auf einen Tableau Sever-Prozess bezieht, der in TSM aufgeführt ist. Der zugrunde liegende Prozess für "Anwendungsserver" ist VizPortal.

Parallel ausgeführt, skalieren Knoten 1 und Knoten 2, um Anforderungen von der Lastenausgleichslogik zu bedienen, die auf den Reverseproxy-Servern ausgeführt wird. Sollte einer dieser redundanten Knoten ausfallen, werden Clientanfragen und -bearbeitung von dem verbleibenden Knoten verarbeitet.

Die Referenzarchitektur wurde so konzipiert, dass komplementäre Anwendungsprozesse auf demselben Computer ausgeführt werden. Das bedeutet, dass die Prozesse nicht um Rechenressourcen konkurrieren und somit keine Konflikte verursachen.

So ist beispielsweise VizQL, ein zentraler Verarbeitungsdienst auf Anwendungsservern, in hohem Maße CPU- und speicherhungrig. VizQL beansprucht fast 60 bis 70 % der CPU und des Arbeitsspeichers des Computers. Daher ist die Referenzarchitektur so konzipiert, dass sich keine weiteren Prozesse auf demselben Knoten wie VizQL befinden, die Speicher oder CPU stark in Anspruch nehmen. Tests zeigen, dass die Last oder die Anzahl an Benutzern keinen Einfluss auf die Speicher- oder CPU-Auslastung auf VizQL-Knoten hat. In unserem Auslastungstest hat sich beispielsweise gezeigt, dass sich eine Verringerung der gleichzeitigen Benutzer nur auf die Leistung des Dashboards oder den Ladevorgang der Visualisierung auswirkt, während die Ressourcennutzung dadurch jedoch nicht verringert wird. Basierend auf dem verfügbaren Arbeitsspeicher und der CPU während der Spitzenauslastung können Sie daher das Hinzufügen weiterer VizQL-Prozesse in Betracht ziehen. Als Ausgangspunkt für typische Arbeitsmappen sollten Sie 4 Kerne pro VizQL-Prozess zuweisen.

Skalieren von Anwendungsservern

Die Referenzarchitektur ist so ausgelegt, dass es auf einem nutzungsbasierten Modell basierend skaliert wird. Als allgemeinen Ausgangspunkt empfehlen wir mindestens zwei Anwendungsserver, die jeweils bis zu 1.000 Benutzer unterstützen. Planen Sie bei steigender Benutzerbasis einen weiteren Anwendungsserver für jeweils weitere 1.000 Benutzer ein. Überwachen Sie Nutzung und Leistung, um die Benutzerbasis pro Host für Ihr Unternehmen zu optimieren.

Knoten 3 und 4: Datenserver

Die Dateispeicher-, Daten-Engine- (Hyper) und Hintergrundprozesskomponente-Prozesse befinden sich aus den folgenden Gründen auf den Knoten 3 und 4:

• Extraktoptimierung: Die Ausführung von Hintergrundprozesskomponente, Hyper und Dateispeicher auf demselben Knoten optimiert die Leistung und Zuverlässigkeit. Während des Extraktionsprozesses fragt die Hintergrundprozesskomponente die Zieldatenbank ab, erstellt die Hyper-Datei auf demselben Knoten und lädt sie dann in den Dateispeicher hoch. Wenn diese Prozesse auf demselben Knoten ablaufen, müssen bei der Extraktionserstellung keine großen Datenmengen über das Netz oder die Knoten kopiert werden.
• Ergänzender Ressourcenausgleich: Die Hintergrundprozesskomponente ist hauptsächlich CPU-intensiv. Die Daten-Engine ist ein speicherintensiver Prozess. Die Kopplung dieser Prozesse ermöglicht eine maximale Ressourcennutzung auf jedem Knoten.
• Konsolidierung von Datenprozessen: Da es sich bei jedem dieser Prozesse um Back-End-Datenprozesse handelt, ist es sinnvoll, sie in der sichersten Datenschicht auszuführen. In zukünftigen Versionen der Referenzarchitektur werden die Anwendungs- und Datenserver in getrennten Schichten ausgeführt. Aufgrund von Anwendungsabhängigkeiten in der Tableau-Architektur müssen Anwendungs- und Datenserver jedoch zu diesem Zeitpunkt in derselben Schicht ausgeführt werden.

Skalieren von Datenservern

Wie bei Anwendungsservern müssen die Ressourcen, die für Tableau-Datenserver erforderlich sind, auf Grundlage einer nutzungsbasierten Modellierung geplant werden. Gehen Sie im Allgemeinen davon aus, dass jeder Datenserver bis zu 2.000 Extraktaktualisierungsaufträge pro Tag unterstützen kann. Wenn Ihre Extraktaufträge zunehmen, fügen Sie zusätzliche Datenserver ohne den Dateispeicherdienst hinzu. Im Allgemeinen eignet sich die Datenserverbereitstellung mit zwei Knoten für Bereitstellungen, die das lokale Dateisystem für den Dateispeicherdienst verwenden. Beachten Sie, dass sich das Hinzufügen weiterer Anwendungsserver nicht linear auf die Leistung oder Skalierung auf Datenservern auswirkt. Abgesehen von einem gewissen Verwaltungsaufwand, den zusätzliche Benutzerabfragen mit sich bringen, sind die Auswirkungen weiterer Anwendungshosts und Benutzer minimal.