Tableau Blueprint-hjälp

Obs! Detta ämne gäller enbart Tableau Server.

Tableau Server kan installeras lokalt med fysiska eller virtuella maskiner eller i molnet och har stöd för Windows- eller Linux-operativsystem. För att bestämma maskinvaruplattform och dimensionering bör du ta hänsyn till följande variabler: din miljö, datakällor och hantering för att ge dataåtkomst med självbetjäning, potentiell arbetsbelastning från alla användare och faktisk användningsdata. Om det är första gången du driftsätter Tableau Server bör du fokusera på dina miljöstandarder och källor till data. För befintliga driftsättningar analyserar du Tableau Server-data och utvärderar arbetsbelastning och användning samt miljö och källor till data.

Hårdvarukrav

Oavsett var du väljer att driftsätta Tableau Server är det viktigt att du har rätt storlek på maskinvaran. Din planering bör anpassas till verksamhetens växande behov genom att du bedömer serveranvändning och användarengagemang oftare, skalar oftare och ändrar topologi oftare än annan programvara. Följ motsvarande länk för att hitta den maskinvaruplattform som passar ditt företags standarder:

• Rekommenderade baslinjekonfigurationer (Windows | Linux)
• Tableau Server på VMware VSphere
• Storlek och typ av AWS-instans (Windows | Linux)

• Typ och storlek av Google Compute Engine Virtual Machine (Windows | Linux)

• Typ och storlek för en virtuell dator av typen Microsoft Azure (Windows | Linux)
• Storlek och typ av Alibaba Cloud ECS-instans (Windows | Linux)

Om du driftsätter Tableau Server i molnet kan du undvika ojämn prestanda på grund av resurskonflikter genom att använda dedikerad maskinvara och statisk tilldelning av RAM-minne. Om du behöver ta hänsyn till kostnaden är virtuell maskinvara också en gångbar lösning. Vi rekommenderar att du testar din egen infrastruktur för att hitta den konfiguration som passar dina behov bäst. Ett exempel på hur man utför ett sådant test finns i faktabladet Tableau at the Speed of EC2 (Tableau med EC2-hastighet). (Det här experimentet genomfördes i AWS, men testteorin går att tillämpa på alla molnleverantörer.)

Initial dimensionering

Ditt Tableau-kontoteam är tillgängligt för att bedöma dina krav och hjälpa dig med dimensioneringen. Vid en första driftsättning av Tableau bör du räkna med 600-800 Explorers per 8-kärnig nod med uppskattningsvis 10 % aktiva användare (interaktiva, samtidiga förfrågningar som gjorts till Tableau Server, inklusive instrumentpanel-användning på en laptop eller mobil enhet, webbredigering och anslutning till och sökning i publicerade datakällor). Detta är bara en startpunkt och bör inte betraktas som någon fast dimensioneringsregel efter den första driftsättningen. Det bör finnas minst 8 GB RAM-minne per kärna för en produktionsserver. För kluster med färre än 40 kärnor används noder med 8 kärnor och för kluster med fler än 40 kärnor används noder med 16 kärnor. Den relativa arbetsbelastningen för varje licenstyp måste beaktas vid dimensioneringen av maskinvaran. Om man antar att en Explorer räknas som en användare, har en Creator en relativ arbetsbelastning på 2,4 användare, medan en Viewer har en relativ arbetsbelastning på 0,75 av en användare. Med hjälp av dessa koefficienter för arbetsbelastning kan du uppskatta klustrets kapacitet. I följande tabell visas exempel på motsvarande arbetsbelastning på varje rad:

Den faktiska arbetsbelastningen för Creators, Explorers och Viewers kan variera med användningen av Tableau Server-funktioner, t.ex. hur ofta de ansluter till data och gör ändringar på webben samt tittar på och interagerar med innehåll. När användarna har introducerats och börjar skapa och konsumera innehåll bör du övervaka hårdvaru- och innehållsutnyttjandet för att fatta välgrundade beslut om serverdimensionering med hjälp av data från verktyg för hårdvaruövervakning och Tableau Servers lagringsplats. Mer information finns i Övervakning i Tableau och Mätning av Tableau-användarnas engagemang och acceptans

Skalbarhet

I både nya och befintliga driftsättningsscenarier är målet att proaktivt upprätthålla tillräcklig tillgänglighet, kapacitet och tillräckligt utrymme samt att minimera resurskonflikter. Liksom andra företagsplattformar skalas Tableau Server upp genom att du lägger till processor, minne och/eller hårddisk eller genom att lägga till fler noder i ett kluster. Tableau Server skalar nästan linjärt men använder sig också av hårdvaruresurser i enlighet med din unika miljö, data, arbetsbelastning och användningsmix. Belastningstester och kapacitetsplanering bör utföras regelbundet, enligt vad som beskrivs i Underhåll i Tableau.

Skalbarhet och prestanda är starkt beroende av externa system, t.ex. datakällor, datavolymer och nätverkshastigheter, användararbetsbelastning och arbetsboksutformning, vilket kan förändras snabbt medan driftsättningen fortskrider. Om vi till exempel utgår från en korrekt dimensionerad hårdvarukonfiguration för den första driftsättningen kan följande ha en stor inverkan på serverprestanda och användarupplevelse: oplanerad tillströmning av nya användare, oövervakad användning, ineffektiva arbetsböcker, bristfällig utformning av dataextrakt och uppdateringsscheman vid högtrafik. Prestandan försämras på grund av den samlade effekten av de enskilda incidenterna. Mer information finns i faktabladet Tableau Server Scalability (Skalbarhet i Tableau Server).

När du driftsätter Tableau Server i molnet kan du utnyttja alla befintliga skalningsmöjligheter i Tableau-plattformen, till exempel dynamisk topologi. Med en enkel omstart av servern kan du också ändra de underliggande datorerna som stöder plattformen så länge deras offentliga IP-adress inte ändras.

För driftsättningar med en enda nod kan du också stänga av Tableau Server-maskiner under driftstopp för att minska maskinkostnaderna. Om du gör det i ett kluster med flera noder kommer Tableau att hamna i ett begränsat tillstånd. Men du kan använda dynamisk topologi för att responsivt anpassa Tableau Servers processallokering, så att du kan justera balansen mellan maskinkostnader och kapacitetsbehov. Funktioner för automatisk skalning som avslutar eller instansierar maskiner baserat på efterfrågan stöds inte.

Servermiljöer

Förutom produktionsmiljön rekommenderar Tableau en testmiljö för att testa uppgraderingar och ändringar i servertopologin. Din produktionsmiljö kommer att stödja modern analys med hjälp av produktions- och sandlådeprojekt med processer för validering, främjande och certifiering av innehåll – allt i en och samma miljö. Mer information om dessa processer för innehållshantering finns i Kontroll i Tableau. Produktions- och testmiljöerna bör ha identiska maskinvaruspecifikationer, servertopologi och konfiguration. Detta gör det möjligt för administratörer att testa uppgraderingar och delta i betaprogram i testmiljön genom att återställa produktionsinnehållet.

Vissa organisationer har IT-policyer som kräver tre miljöer – utveckling, kvalitetskontroll och produktion – för att isolera användningsfall för utveckling, testning och konsumtion av innehåll i separata Tableau Server-installationer. Om detta är ett krav för din organisation så måste var och en av de tre miljöerna licensieras separat eftersom de skulle betraktas som tre produktionsmiljöer enligt definitionen i Tableaus slutanvändaravtal. Produktions- och kvalitetskontrollmiljöerna ska ha identiska specifikationer, servertopologi och konfiguration. Om du måste köra tre separata miljöer, försök att inte replikera en traditionell utvecklingscykel enligt vattenfallsmodellen med en modern analysplattform. Användare kan föredra kvalitetskontrollmiljön för att kringgå strikta policyer eller förseningar med att få in innehåll i produktionen. Arbeta därför för en bra balans genom att automatisera migreringen av innehåll till produktionsservern med Content Migration Tool som finns i Tableau Advanced Management eller i anpassade arbetsflödesskript med hjälp av Tableaus REST API:er. Utvecklingsmiljön behöver inte ha samma maskinvaruspecifikationer som produktions- och kvalitetskontrollmiljöerna, såvida inte utvecklingsmiljön används för uppgraderingstestning eller deltar i betaprogram.

Hög tillgänglighet

Du bör installera och konfigurera Tableau utifrån dina tillgänglighetskrav och lägga till ytterligare noder för kapacitet och/eller hög tillgänglighet (Windows | Linux). För att stödja verksamhetskritiska användningsfall bör du driftsätta en HA-klusterkonfiguration (High-Availability) med en extern lastbalanserare (Windows | Linux).

En HA-installation av Tableau Server har minst tre noder och flera redundanta instanser av nyckelprocesser (lagringsplats, fillagring/datamotor och koordinationsservice) på olika noder. Målet är att minimera systemavbrott genom att eliminera enskilda felpunkter och möjliggöra upptäckt av fel med reservomkoppling där det är möjligt. Mer information finns i faktabladet Tableau Server High Availability (Hög tillgänglighet i Tableau Server).

Följ mönstret nedan för att bygga ditt HA-kluster:

1. Installera den initiala noden och låt det arkitekturmedvetna smarta installationsprogrammet konfigurera processerna (Windows | Linux). Den aktiva lagringsplatsen finns på Nod 1.
2. Replikera processkonfigurationen till andra VizQL-noder för att säkerställa redundans (Windows | Linux). Den passiva lagringsplatsen finns på Nod 2. Nod 3-processerna kommer att spegla Nod 1 och Nod 2, men det kommer inte att finnas någon lagringsplatsprocess på den.
3. Lägg till uppsättning med samordningstjänster och klientfiltjänst (Client File Service, CFS) (Windows | Linux).
4. Lägg till extern lastbalanserare (Windows | Linux).
   

HA-driftsättning av Tableau Server med 3 noder (Obs! Samordningstjänsten och klientfiltjänsten visas inte här)

Behovet av specialiserade noder utvecklas med tiden. Arbetsbelastningar med extrakttunga och frekventa extraktuppdateringar bör isoleras från arbetsbelastningen för interaktiv visualiseringsåtergivning. I en extrakttung miljö är de flesta datakällor extrakt. Om du har några få extremt stora utdrag kan du hamna i den här kategorin, liksom om du har många små utdrag. Driftsättningar där utdrag ofta uppdateras, t.ex. flera gånger om dagen under kontorstid, bör isoleras på specialiserade noder i bakgrundsprocessorn. För att isolera arbetsbelastningen för bakgrundsprocessorn lägger du till specialiserade noder för bakgrundsprocessorn och säkerställer redundans, som beskrivs i noderna 4 och 5 nedan. Med nodroller kan du konfigurera var i din Tableau Server-installation som vissa typer av arbetsbelastningar ska bearbetas. Funktionerna för nodroller låter dig dedikera och skala resurser till specifika arbetsbelastningar. Mer information om hur du konfigurerar nodroller för bakgrundsprocessor och fillagring finns i Hantering av arbetsbelastning genom nodroller.

HA-driftsättning av Tableau Server med 5 noder (Obs! Samordningstjänsten och klientfiltjänsten visas inte här)

Från och med version 2019.3 kan du distribuera Tableau Servers lagringsplats till Amazons RDS-tjänst (Relational Database Service). Tableau Server-lagringsplatsen är en PostgreSQL-databas som lagar data om alla användarinteraktioner, extraktuppdateringar och annat. Amazon RDS erbjuder inbyggd skalbarhet, tillförlitlighet, hög tillgänglighet och säkerhet för PostgreSQL. Genom att integrera med AWS och konfigurera Tableau Servers externa lagringsplats kan du dra nytta av dessa extra fördelar med att distribuera i molnet. Mer information finns i Extern Tableau Server-lagringsplats.

När du driftsätter Tableau Server i det offentliga molnet har du några alternativ för att ytterligare minska risken för driftstopp. Till exempel stöds både driftsättning av varje nod av Tableau Server i ett eget virtuellt nätverk och i olika tillgänglighetszoner/zoner. Om du separerar din miljö kan detta dock ske på bekostnad av ökade fördröjningar i hela systemet. Innan du slutför din miljö bör du överväga att testa både prestanda och tillgänglighet för att se till att du har rätt balans för ditt datacommunity. Tableau Server har inte stöd för driftsättning av ett kluster med flera noder i olika regioner.

Katastrofåterställning

När du planerar för katastrofåterställning (DR) i din Tableau-miljö finns det två huvudfaktorer att ta hänsyn till: målsättning för återställningstid (RTO) och målsättning för återställningspunkt (RPO). RTO är ett mått på hur stora driftstopp ditt företag kan acceptera innan en fullständig återhämtning, och det påverkar hur ofta du återställer dina säkerhetskopior till ett alternativt kluster och hur mycket du investerar i infrastrukturen. RPO, som är ett mått på hur mycket dataförlust ditt företag kan tolerera, påverkar hur ofta du behöver ta säkerhetskopior av ditt system. För Tableau Server kan RPO inte vara kortare än den tid det tar att utföra en fullständig säkerhetskopiering av servern. Tabellen nedan illustrerar hur du planerar för ett intervall av RTO-krav:

Oavsett om du använder en värdlösning med Tableau Server lokalt eller i molnet är processen för säkerhetskopiering densamma. Använd kommandot TSM Backup för att skapa en säkerhetskopia av Tableau Server och återställ den säkerhetskopian på en ny dator. Det går inte att ta en ögonblicksbild av en Tableau Server-dator och återställa den på en ny dator. Mer information om koncept och faktablad om hög tillgänglighet och katastrofåterställning finns i Verksamhetskritisk driftsäkerhet.