Help bij Tableau Blueprint

Opmerking: dit onderwerp is alleen van toepassing op Tableau Server.

Tableau Server kan op locatie worden geïnstalleerd met fysieke of virtuele machines of in de cloud en ondersteunt Windows- of Linux-besturingssystemen. Als u uw hardwareplatform en dimensionering wilt bepalen, moet u rekening houden met de volgende variabelen: uw omgeving, bronnen van data en beheer om selfservice datatoegang te bieden, potentiële workload van alle gebruikers en daadwerkelijke gebruiksdata. Als dit de eerste keer is dat u Tableau Server implementeert, moet u zich concentreren op uw omgevingsstandaarden en databronnen. Voor bestaande implementaties analyseert u Tableau Server-data om de workload en het gebruik, naast de omgeving en databronnen, te evalueren.

Hardwarevereisten

Ongeacht waar u Tableau Server wilt implementeren, is het van cruciaal belang dat de hardware van de juiste omvang is. Uw planning moet worden afgestemd op de veranderende bedrijfsbehoeften door het servergebruik en de gebruikersbetrokkenheid vaker te beoordelen, vaker te schalen en de topologie vaker te wijzigen dan bij andere softwaretoepassingen. Bekijk de bijbehorende link naar het hardwareplatform dat past bij uw bedrijfsstandaarden:

• Aanbevolen baselineconfiguraties (Windows | Linux)
• Tableau Server op VMware VSphere
• Type en grootte van AWS-instantie (Windows | Linux)

• Type en grootte van virtuele machines van Google Compute Engine (Windows | Linux)

• Type en grootte van virtuele machines van Microsoft Azure (Windows | Linux)
• Type en grootte van Alibaba Cloud ECS-instantie (Windows | Linux)

Als u Tableau Server in de cloud implementeert en toegewezen hardware en statische toewijzing van RAM gebruikt, voorkomt u wisselende prestaties als gevolg van conflicten met resources. Als de kosten een overweging zijn, is virtuele hardware ook rendabel. We raden u aan uw eigen infrastructuur te testen om de configuratie te vinden die het beste bij uw behoeften past. Zie de whitepaper Tableau at the Speed of EC2 om te bekijken hoe u een dergelijke test uitvoert. (Dit experiment werd uitgevoerd in AWS, maar de testtheorie geldt voor elke cloudprovider.)

Initiële dimensionering

Uw Tableau-accountteam staat klaar om uw vereisten te beoordelen en u te helpen met de dimensionering. Bij een initiële implementatie van Tableau moet u rekenen op 600-800 Explorers per knooppunt van 8 kernen. We gaan daarbij uit van 10% actieve gebruikers (interactieve, gelijktijdige verzoeken aan Tableau Server, waaronder het gebruik van data door dashboards op een laptop of mobiel apparaat, het maken van online data en het verbinden met en opvragen van gepubliceerde databronnen). Dit is slechts een beginpunt en moet niet worden beschouwd als een vaststaande dimensioneringsregel na de initiële implementatie. Het geheugen moet minimaal 8 GB RAM per kern zijn voor een productieserver. Voor clusters met minder dan 40 kernen gebruikt u knooppunten met 8 kernen. In clusters met meer dan 40 kernen gebruikt u knooppunten met 16 kernen. Bij de hardwaredimensionering moet rekening worden gehouden met de relatieve workload van elk licentietype. We gaan ervan uit dat een Explorer als 1 gebruiker telt, een Creator een relatieve workload van 2,4 gebruikers heeft en een Viewer een relatieve workload van 0,75 van een gebruiker heeft. Met deze workloadcoëfficiënten kunt u de capaciteit van het cluster schatten. In de volgende tabel ziet u voorbeelden van overeenkomstige workloads in elke rij:

De daadwerkelijke workload van Creators, Explorers en Viewers kan variëren, afhankelijk van het gebruik van de Tableau Server-functies, zoals de frequentie waarmee verbinding wordt gemaakt met data en het maken van online inhoud, evenals het bekijken van en de interactie met inhoud. Wanneer gebruikers zijn aangemeld en inhoud gaan maken en gebruiken, moet u het hardware- en inhoudgebruik monitoren om weloverwogen beslissingen te kunnen nemen over de servergrootte op basis van gegevens uit hardwaremonitoringtools en de Tableau Server-opslagplaats. Zie Tableau-monitoring en Meting van betrokkenheid van en implementatie door Tableau-gebruikers voor meer informatie.

Schaalbaarheid

In zowel nieuwe als bestaande implementatiescenario's is het doel om proactief voldoende beschikbaarheid, capaciteit en speelruimte te behouden en conflicten om resources te minimaliseren. Net als andere bedrijfsplatformen schaalt Tableau Server op door een processor, geheugen en/of schijf toe te voegen of schaalt het uit door meer knooppunten aan een cluster toe te voegen. Tableau Server schaalt vrijwel lineair met de toevoeging van hardwareresources, afhankelijk van uw unieke omgeving, data, workload en gebruikscombinatie. Belastingstests en capaciteitsplanning moeten regelmatig worden uitgevoerd, zoals beschreven in Tableau-onderhoud.

Schaalbaarheid en prestaties zijn sterk afhankelijk van externe systemen, zoals databronnen, datavolume en netwerksnelheden, gebruikersworkloads en werkmapontwerp, die snel kunnen veranderen naarmate de implementatie vordert. Als we bijvoorbeeld uitgaan van een hardwareconfiguratie van de juiste grootte voor de initiële implementatie, kunnen ongeplande onboarding van gebruikers, ongecontroleerd gebruik, inefficiënte werkmappen, een niet optimaal ontwerp van gegevensextractie en schema's voor vernieuwing tijdens piekuren een grote impact hebben op de serverprestaties en gebruikerservaring, waardoor de prestaties verslechteren door het cumulatieve effect van de afzonderlijke incidenten. Zie de whitepaper Tableau Server Scalability voor meer informatie.

Wanneer u Tableau Server in de cloud implementeert, kunt u alle bestaande schaalmogelijkheden van het Tableau-platform, waaronder: Hete topologie (wijzigen van resources zonder opstarten van server) benutten. Met een eenvoudige herstart van de server kunt u ook de onderliggende VM’s wijzigen die het platform ondersteunen, zolang hun openbare IP-adres niet verandert.

Voor implementaties met één knooppunt kunt u Tableau Server-VM’s tijdens downtime ook uitschakelen om de kosten van de machines te verlagen. Als u dit doet met een cluster met meerdere knooppunten, heeft dit een negatief effect op de prestaties van Tableau. U kunt echter gebruikmaken van Hete topologie om de procestoewijzing van Tableau Server adequaat aan te passen, zodat u de balans tussen kosten van VM’s en capaciteitsbehoeften kunt afstemmen. De functionaliteit voor automatisch schalen die VM’s beëindigt of hiervoor een instantie maakt op basis van de vraag wordt niet ondersteund.

Serveromgevingen

Naast uw productieomgeving raadt Tableau één testomgeving aan voor het testen van upgrades en wijzigingen in de servertopologie. Uw productieomgeving ondersteunt moderne analyses met behulp van productie- en sandboxprojecten met processen voor inhoudsvalidatie, promotie en certificering, allemaal in één omgeving. Zie Tableau-governance voor meer informatie over deze inhoudsbeheerprocessen. De productie- en testomgevingen moeten identieke hardwarespecificaties, servertopologie en configuratie hebben. Hierdoor kunnen beheerders upgrades testen en deelnemen aan bètaprogramma's in de testomgeving door productie-inhoud te herstellen.

Sommige organisaties hebben een IT-beleid waarbij drie omgevingen zijn vereist (ontwikkeling, kwaliteitscontrole en productie). Op die manier kunnen gebruiksscenario's voor de ontwikkeling, het testen en het gebruik van inhoud worden geïsoleerd in afzonderlijke Tableau Server-installaties. Als dit een vereiste is voor uw organisatie, moet voor elk van de drie omgevingen afzonderlijk een licentie worden aangeschaft. Deze worden namelijk beschouwd als drie productieomgevingen zoals gedefinieerd in de licentieovereenkomst voor eindgebruikers van Tableau. De productie- en kwaliteitscontroleomgevingen moeten identieke specificaties, servertopologie en configuratie hebben. Als u over drie afzonderlijke omgevingen moet beschikken, probeer dan niet een traditionele watervalontwikkelingscyclus te repliceren met een modern analyseplatform. Gebruikers kunnen de voorkeur geven aan de kwaliteitscontroleomgeving om streng beleid of vertragingen bij het in productie nemen van inhoud te omzeilen. Werk dus aan een goed evenwicht door de migratie van inhoud naar de productieserver te automatiseren met de Content Migration Tool die u kunt vinden in Tableau Advanced Management of aangepaste workflowscripts met behulp van de REST API's van Tableau. De ontwikkelomgeving hoeft niet dezelfde hardwarespecificaties te hebben als de productie- en kwaliteitscontroleomgevingen, tenzij de ontwikkelomgeving wordt gebruikt voor upgradetests of deelname aan bètaprogramma's.

Hoge beschikbaarheid

U moet Tableau installeren en configureren op basis van uw beschikbaarheidsvereisten en extra knooppunten toevoegen voor capaciteit en/of voor hoge beschikbaarheid (Windows | Linux). Ter ondersteuning van bedrijfskritische gebruiksscenario's moet u een clusterconfiguratie met hoge beschikbaarheid (HA) implementeren met een externe loadbalancer (Windows | Linux).

Een installatie voor hoge beschikbaarheid van Tableau Server heeft minimaal drie knooppunten en meerdere redundante instanties van belangrijke processen (de opslagplaats, bestandsopslag/data-engine en coördinatieservice) op verschillende knooppunten. Het doel is om de downtime van het systeem te minimaliseren door afzonderlijke kritieke storingspunten te verwijderen en waar mogelijk detectie van storingen met failovers mogelijk te maken. Zie de whitepaper Tableau Server High Availability voor meer informatie.

Volg het onderstaande patroon om uw cluster voor hoge beschikbaarheid te maken:

1. Installeer het initiële knooppunt en laat het architectuurgevoelige slimme installatieprogramma processen configureren (Windows | Linux). De actieve opslagplaats bevindt zich op knooppunt 1.
2. Repliceer de procesconfiguratie naar andere VizQL-knooppunten, waardoor redundantie wordt gegarandeerd (Windows | Linux). De passieve opslagplaats bevindt zich op knooppunt 2. Knooppunt 3-processen zijn een weerspiegeling van knooppunten 1 en 2. Ze bevatten echter geen opslagplaatsproces.
3. Het coördinatieservice-ensemble en de clientbestandsservice toevoegen (Windows | Linux).
4. De loadbalancer toevoegen (Windows | Linux).
   

Een Tableau Server-implementatie voor hoge beschikbaarheid met drie knooppunten (opmerking: coördinatieservice en clientbestandsservice worden niet expliciet weergegeven)

De behoefte aan gespecialiseerde knooppunten verandert in de loop van de tijd. Vernieuwingsworkloads met de extracten van veel data of met een hoge frequente moeten worden geïsoleerd van de workload voor het weergeven van interactieve visualisaties. In een omgeving met extracties van veel data zijn de meeste databronnen extracten. Als u een paar extreem grote extracten hebt, kan uw implementatie in deze categorie vallen, net als wanneer u veel kleine extracten hebt. Implementaties waarbij extracten regelmatig worden vernieuwd, zoals meerdere keren per dag tijdens kantooruren, moeten worden geïsoleerd op gespecialiseerde Backgrounder-knooppunten. Voeg gespecialiseerde Backgrounder-knooppunten toe om de workload van het Backgrounder-proces te isoleren. Op die manier zorgt u voor redundantie, zoals hieronder wordt weergegeven in knooppunten 4 en 5. Met behulp van knooppuntrollen kunt u configureren waar bepaalde typen workloads worden verwerkt in uw Tableau Server-installatie. Met de functies voor knooppuntrollen kunt u resources aan specifieke workloads toewijzen en schalen. Zie Workloadbeheer via knooppuntrollen voor meer informatie over het configureren van knooppuntrollen voor Backgrounder en bestandsopslag.

Een Tableau Server-implementatie voor hoge beschikbaarheid met 5 knooppunten (opmerking: coördinatieservice en clientbestandsservice worden niet expliciet weergegeven)

Vanaf 2019.3 kunt u Tableau Server-opslagplaats implementeren in Amazon Relational Database Service (RDS). De Tableau Server-opslagplaats is een PostgreSQL-database waarin data worden opgeslagen over alle gebruikersinteracties, zoals bijvoorbeeld extractvernieuwingen. Amazon RDS biedt schaalbaarheid, betrouwbaarheid, hoge beschikbaarheid en ingebouwde beveiliging voor PostgreSQL. Door te integreren met AWS om de externe opslagplaats van Tableau Server te configureren, kunt u profiteren van deze extra voordelen van het inzetten van de cloud. Zie Externe opslagplaats Tableau Server voor meer informatie.

Wanneer u Tableau Server in de openbare cloud implementeert, hebt u een aantal opties om het risico op downtime verder te beperken. Zo worden het implementeren van elk knooppunt van Tableau Server in het eigen virtuele netwerk of in verschillende beschikbaarheidszones/zones beide ondersteund. Het scheiden van uw omgeving kan echter ten koste gaan van een grotere latentie in het hele systeem. Voordat u uw omgeving voltooit, kunt u overwegen om zowel de prestaties als de beschikbaarheid te testen om er zeker van te zijn dat u de juiste balans hebt voor uw datacommunity. Tableau Server biedt geen ondersteuning voor de implementatie van een cluster met meerdere knooppunten in verschillende regio's.

Noodherstel

Bij het plannen van noodherstel (Disaster Recovery of DR) in uw Tableau-omgeving zijn er twee belangrijke factoren waarmee u rekening moet houden: Recovery Time Objective (RTO) en Recovery Point Objective (RPO). De RTO is een maatstaf voor de hoeveelheid downtime die uw bedrijf kan accepteren voordat een volledig herstel plaatsvindt. Het is van invloed op de frequentie van herstel van uw back-ups naar een alternatief cluster en op de hoeveelheid infrastructuurinvesteringen. De RPO, een maatstaf voor de hoeveelheid gegevensverlies die uw bedrijf kan tolereren, beïnvloedt de frequentie waarin u back-ups van uw systeem moet maken. Voor Tableau Server kan de RPO niet korter zijn dan de tijd die nodig is om een volledige back-up van uw server te voltooien. In de onderstaande tabel ziet u hoe u kunt plannen voor een reeks RTO-vereisten:

Het maakt niet uit of u Tableau Server op locatie of in de cloud host, het back-upproces is hetzelfde. Gebruik de opdracht TSM Backup om een back-up van de Tableau Server te genereren en die back-up op een nieuwe VM te herstellen. Het maken van een momentopname van een Tableau Server-VM en het herstellen ervan op een nieuwe VM wordt niet ondersteund. Zie Bedrijfskritische betrouwbaarheid voor meer informatie over concepten en whitepapers met betrekking tot hoge beschikbaarheid en noodherstel.