Gids voor bedrijfsbrede implementatie van Tableau Server

De afbeelding hieronder toont de relevante Tableau Server-processen en hoe deze in de referentiearchitectuur zijn geïmplementeerd. Deze implementatie wordt beschouwd als de minimale Tableau Server-implementatie die geschikt is voor bedrijven.

De procesdiagrammen in dit onderwerp zijn bedoeld om de belangrijkste, bepalende processen van elk knooppunt weer te geven. Er zijn veel ondersteunende processen die ook op de knooppunten draaien, maar die niet in de diagrammen zijn weergegeven. Zie de configuratiesectie van deze gids, Deel 4 – Tableau Server installeren en configureren voor een lijst met alle processen.

Tableau Server-processen

De Tableau Server-referentiearchitectuur is een Tableau Server-clusterimplementatie met vier knooppunten en een externe opslagplaats op PostgreSQL:

• Het eerste knooppunt van Tableau Server (Knooppunt 1): voert de vereiste TSM-beheer- en licentieservices uit die alleen op één knooppunt in het cluster kunnen worden uitgevoerd. In de zakelijke context is het eerste knooppunt van Tableau Server het primaire knooppunt in het cluster. Dit knooppunt voert ook redundante toepassingservices uit met Knooppunt 2.
• De toepassingsknooppunten van Tableau Server (Knooppunt 1 en Knooppunt 2): de twee knooppunten verwerken clientverzoeken, maken verbinding met en voeren query's uit op databronnen en op de dataknooppunten.
• De dataknooppunten van Tableau Server (Knooppunt 3 en Knooppunt 4): twee knooppunten die speciaal zijn bedoeld voor het beheer van data.
• Externe PostgreSQL: deze host voert het proces voor de Tableau Server-opslagplaats uit. Voor implementatie van hoge beschikbaarheid moet u een extra PostgreSQL-host gebruiken voor actieve/passieve redundantie.

  U kunt PostgreSQL ook op Amazon RDS laten draaien. Zie Externe opslagplaats Tableau Server (Linux(Link wordt in een nieuw venster geopend)) voor meer informatie over de verschillen tussen het uitvoeren van de opslagplaats op RDS en een EC2-instantie.

  Voor het implementeren van Tableau Server met een externe opslagplaats is een Tableau Advanced Management-licentie vereist.

  Als uw organisatie niet over interne DBA-expertise beschikt, hebt u de optie om het proces voor de Tableau Server-opslagplaats uit te voeren in de standaard, interne PostgreSQL-configuratie. In het standaardscenario draait de opslagplaats op een Tableau-knooppunt met ingesloten PostgreSQL. In dit geval raden we aan om de opslagplaats op een speciaal Tableau-knooppunt te laten draaien en een passieve opslagplaats op een extra, speciaal hiervoor bestemd knooppunt, ter ondersteuning van de Failover voor opslagplaats. Zie Failover voor opslagplaats (Linux(Link wordt in een nieuw venster geopend)).

  Ter illustratie legt de AWS-implementatie die in deze gids wordt beschreven uit hoe u de externe opslagplaats implementeert op PostgreSQL die draait op een EC2-instantie.

• Optioneel: Als uw organisatie externe opslag gebruikt, kunt u Tableau Bestandsarchief implementeren als een externe service. In deze gids is het externe bestandsarchief niet in het kernimplementatiescenario opgenomen. Zie Tableau Server installeren met extern bestandsarchief (Linux(Link wordt in een nieuw venster geopend)).

  Voor het implementeren van Tableau Server met een extern bestandsarchief is een Tableau Advanced Management-licentie vereist.

PostgresSQL-opslagplaats

Tableau Server-opslagplaats is een PostgresSQL-database die serverdata opslaat. Deze data bevatten informatie over Tableau Server met betrekking tot de gebruikers, groepen en groepstoewijzingen, machtigingen, projecten, databronnen en metadata en vernieuwingsinformatie van extracten.

De standaard PostgresSQL-implementatie verbruikt bijna 50% van de resources voor systeemgeheugen. Afhankelijk van het gebruik (voor productie en grootschalige productie-implementaties) kan het gebruik van de resources nog toenemen. Om deze reden raden wij aan om het opslagplaatsproces uit te voeren op een computer waarop geen andere resource-intensieve servercomponenten zoals VizQL, Backgrounder of Data-engine worden uitgevoerd. Wanneer u het opslagplaatsproces samen met een van deze componenten uitvoert, ontstaan er I/O-conflicten, resource-beperkingen en worden de algehele prestaties van de implementatie slechter.

Knooppunt 1: eerste knooppunt

Het eerste knooppunt voert een klein aantal belangrijke processen uit en deelt de toepassingsbelasting met Knooppunt 2.

De eerste computer waarop u Tableau installeert, het 'eerste knooppunt', heeft een aantal unieke kenmerken. Drie processen worden alleen op het eerste knooppunt uitgevoerd en kunnen niet naar een ander knooppunt worden verplaatst, behalve in geval van een storing: de Licentieservice (Licentiebeheer), de Activeringsservice en de TSM-controller (Beheercontroller).

Knooppunt 1 failover en geautomatiseerd herstel

De services Licentie, Activering en TSM-controller zijn van cruciaal belang voor de status van een Tableau Server-implementatie. Als Knooppunt 1 uitvalt, kunnen gebruikers nog steeds verbinding maken met de Tableau Server-implementatie, omdat een correct geconfigureerde referentiearchitectuur de verzoeken naar Knooppunt 2 routeert. Zonder deze kernservices zal de implementatie een kritieke status krijgen en waarschijnlijk mislukken. Zie Automatisch herstel van eerste knooppunt.

Knooppunten 1 en 2: toepassingsservers

Knooppunten 1 en 2 voeren de Tableau Server-processen uit die clientverzoeken verwerken, databronnen bevragen, visualisaties genereren, inhoud en beheer hanteren en andere belangrijke bedrijfslogica van Tableau uitvoeren. De toepassingsservers slaan geen gebruikersdata op.

Opmerking:Toepassingsserver is een term die ook verwijst naar een Tableau Server-proces dat in TSM wordt vermeld. Het onderliggende proces voor Toepassingsserver is VizPortal.

Wanneer Knooppunt 1 en Knooppunt 2 parallel worden uitgevoerd, schalen ze om verzoeken te verwerken van de loadbalancing-logica die op de reverse-proxyservers wordt uitgevoerd. Wanneer een van deze knooppunten uitvalt, worden de clientverzoeken en -diensten door het resterende knooppunt afgehandeld, aangezien het redundante knooppunten zijn.

De referentiearchitectuur is zo ontworpen dat complementaire toepassingsprocessen op dezelfde computer worden uitgevoerd. Dit betekent dat de processen niet met elkaar concurreren om resources en zo conflicten veroorzaken.

Zo is bijvoorbeeld VizQL, een kernverwerkingsservice op toepassingsservers, sterk CPU- en geheugengebonden. VizQL gebruikt bijna 60-70% van de CPU en het geheugen op de computer. Om deze reden is de referentiearchitectuur zo ontworpen dat er zich geen andere geheugen- of CPU-gebonden processen op hetzelfde knooppunt bevinden als VizQL. Uit tests blijkt dat de hoeveelheid belasting of het aantal gebruikers geen invloed heeft op het geheugen- of CPU-gebruik op VizQL-knooppunten. Het verlagen van het aantal gelijktijdige gebruikers in onze belastingstest had alleen invloed op de prestaties van het dashboard of het laadproces van de visualisatie, maar het gebruik van resources werd niet verminderd. Afhankelijk van het beschikbare geheugen en de CPU tijdens piekgebruik, kunt u overwegen om meer VizQL-processen toe te voegen. Als startpunt voor typische werkmappen wijst u 4 kernen per VizQL-proces toe.

Toepassingsservers schalen

De referentiearchitectuur is ontworpen voor schaalbaarheid op basis van een gebruiksgebaseerd model. Als algemeen uitgangspunt adviseren wij minimaal twee toepassingsservers, die elk maximaal 1000 gebruikers ondersteunen. Naarmate het aantal gebruikers groeit, kunt u voor elke 1000 extra gebruikers een toepassingsserver toevoegen. Monitor het gebruik en de prestaties om het aantal gebruikers per host voor uw organisatie af te stemmen.

Knooppunten 3 en 4: dataservers

De processen Bestandsarchief, Data-engine (Hyper) en Backgrounder zijn om de volgende redenen op Knooppunt 3 en 4 samengebracht:

• Optimalisatie van extract: als u Backgrounder, Hyper en Bestandsarchief op hetzelfde knooppunt uitvoert, worden de prestaties en betrouwbaarheid geoptimaliseerd. Tijdens het extractieproces zal Backgrounder de doeldatabase bevragen, het Hyperbestand aanmaken op hetzelfde knooppunt en het vervolgens uploaden naar Bestandsarchief. Door deze processen op hetzelfde knooppunt te plaatsen, hoeven er voor de workflow voor het maken van extracties geen grote hoeveelheden data over het netwerk of de knooppunten te worden gekopieerd.
• Complementaire resourcebalancering: Backgrounder is voornamelijk CPU-intensief. Data-engine is een proces dat veel geheugen vergt. Door deze processen te koppelen, wordt het gebruik van de resources op elk knooppunt maximaal benut.
• Consolidatie van dataprocessen: omdat elk van deze processen back-enddataprocessen zijn, is het zinvol om ze in de veiligste datalaag uit te voeren. In toekomstige versies van de referentiearchitectuur zullen de toepassings- en dataservers in afzonderlijke lagen draaien. Vanwege toepassingsafhankelijkheden in de Tableau-architectuur moeten toepassings- en dataservers op dit moment echter in dezelfde laag draaien.

Dataservers schalen

Net als bij toepassingsservers is voor het plannen van de resources die nodig zijn voor Tableau-dataservers gebruiksgebaseerd modelleren vereist. Over het algemeen kunt u verwachten dat elke dataserver maximaal 2000 extractvernieuwingsjobs per dag kan ondersteunen. Naarmate het aantal extractjobs toeneemt, voegt u extra dataservers toe zonder de service Bestandsarchief. De implementatie van een dataserver met twee knooppunten is over het algemeen geschikt voor implementaties die het lokale bestandssysteem gebruiken voor de service Bestandsarchief. Houd er rekening mee dat het toevoegen van meer toepassingsservers geen lineaire invloed heeft op de prestaties of schaalbaarheid van dataservers. Afgezien van wat overhead door extra gebruikersquery's is de impact van het toevoegen van meer toepassingshosts en gebruikers minimaal.