Guida di Tableau Blueprint

Nota: questo argomento si riferisce solo a Tableau Server.

Tableau Server si può installare in locale con macchine fisiche o virtuali, oppure nel cloud, supporta i sistemi operativi Windows o Linux. Per determinare la piattaforma e le dimensioni dell’hardware, considera queste variabili: ambiente, origini dei dati e gestione per consentire l’accesso ai dati self-service, l’opportuno carico di lavoro potenziale per tutti gli utenti e dati sull’utilizzo effettivo. Se distribuisci Tableau Server per la prima volta dovrai prestare attenzione agli standard dell’ambiente e alle origini dei dati. Per le distribuzioni esistenti, analizzerai i dati di Tableau Server per valutare il carico di lavoro e l’utilizzo, oltre all’ambiente e alle origini dei dati.

Requisiti hardware

Indipendentemente da dove si sceglie di distribuire Tableau Server, è fondamentale che l’hardware abbia dimensioni adeguate. La pianificazione deve essere coerente con l’evoluzione delle esigenze aziendali, aumentando la frequenza delle valutazioni dell’utilizzo del server e del coinvolgimento degli utenti, dei ridimensionamenti e delle modifiche alla topologia rispetto ad altre applicazioni software. Consulta il link corrispondente alla piattaforma hardware adatta agli standard della tua azienda:

• Configurazioni di base consigliate (Windows | Linux)
• Tableau Server su VMware vSphere
• Tipo e dimensione di un’istanza di AWS (Windows | Linux)

• Tipo e dimensione di una macchina virtuale Google Compute Engine (Windows | Linux)

• Tipo e dimensione di una macchina virtuale Microsoft Azure (Windows | Linux)
• Tipo e dimensione di un’istanza Alibaba Cloud ECS (Windows | Linux)

Per le distribuzioni di Tableau Server sul cloud, l’uso di hardware dedicato e il ricorso all’allocazione statica della RAM eliminano la variabilità delle prestazioni determinata dall’utilizzo condiviso delle risorse. Se si desidera contenere i costi si può prendere in esame anche l’hardware virtuale. Consigliamo di testare l’infrastruttura per individuare la configurazione più adatta alle esigenze specifiche. Per un esempio dei test da svolgere, consulta il whitepaper Tableau at the Speed of EC2. Questo esperimento è stato svolto con AWS, ma la teoria del test vale per qualsiasi fornitore di servizi cloud.

Dimensionamento iniziale

Il team responsabile dell’account Tableau è disponibile per valutare le tue esigenze e per fornire assistenza nel dimensionamento. In una distribuzione iniziale di Tableau, si devono stimare 600-800 utenti Explorer per ogni nodo a 8 core, ipotizzando che il 10% degli utenti siano attivi (richieste interattive e simultanee inviate a Tableau Server, compreso l’utilizzo delle dashboard su un portatile o dispositivo mobile, il Web authoring e la connessione e interrogazione delle origini dati pubblicate). Questo è solo il punto di partenza: non si deve considerare come una regola fissa per il dimensionamento, dopo la distribuzione iniziale. La memoria deve prevedere almeno 8 GB di RAM per ogni core, per un server di produzione. Per i cluster con meno di 40 core, si utilizzeranno nodi a 8 core; nei cluster con oltre 40 core sceglieremo nodi a 16 core. Il carico di lavoro relativo per ciascun tipo di licenza deve essere considerato nel dimensionamento dell’hardware. Supponiamo che un Explorer equivalga a un utente, ogni Creator ha un carico di lavoro relativo di 2,4 utenti, mentre un Viewer ne ha uno di 0,75 utenti. Questi coefficienti per il carico di lavoro consentono di stimare la capacità del cluster. La tabella seguente mostra in ogni riga degli esempi di carichi di lavoro equivalenti:

Il carico di lavoro effettivo di Creator, Explorer e Viewer può variare in base all’utilizzo delle funzionalità di Tableau Server, come la frequenza di connessione ai dati e il Web authoring, ma anche in base alla visualizzazione dei contenuti e all’interazione con questi ultimi. Via via che l’onboarding degli utenti prosegue e si inizia a creare e utilizzare contenuti, occorre monitorare l’utilizzo dell’hardware e dei contenuti per prendere decisioni informate sul dimensionamento dei server, con i dati provenienti dagli strumenti di monitoraggio dell’hardware e dal repository di Tableau Server. Per ulteriori informazioni, consulta le sezioni Monitoraggio di Tableau e Misurazione del coinvolgimento e dell’adozione degli utenti di Tableau.

Scalabilità

Sia nel caso di una distribuzione nuova che in quello di una esistente, l’obiettivo è garantire in modo proattivo disponibilità, capacità e capacità aggiuntiva in misura sufficiente, riducendo al minimo il conflitto di risorse. Come altre piattaforme aziendali, Tableau Server si espande verticalmente aggiungendo capacità a livello di processore, memoria e/o disco oppure orizzontalmente aggiungendo più nodi a un cluster. Tableau Server è scalabile in modo quasi lineare, aggiungendo risorse hardware, in base al proprio ambiente, ai dati, al carico di lavoro e agli specifici contesti di utilizzo. Si devono svolgere regolarmente prove di carico e la pianificazione della capacità, come indicato nella sezione Manutenzione di Tableau.

La scalabilità e le prestazioni dipendono notevolmente da sistemi esterni, come origini dei dati, volume dei dati e velocità della rete, carichi di lavoro degli utenti e progettazione delle cartelle di lavoro, che possono variare rapidamente con l’avanzare delle distribuzioni. Ad esempio, ipotizzando che la configurazione hardware sia dimensionata correttamente per la distribuzione iniziale, un aumento imprevisto del numero di utenti, utilizzo non monitorato, cartelle di lavoro inefficienti, design non ottimale dell’estrazione dei dati e pianificazioni degli aggiornamenti nelle ore di punta possono avere conseguenze notevoli sulle prestazioni del server e sull’esperienza dell’utente, compromettendo le prestazioni a causa dell’effetto cumulato dei singoli eventi. Per ulteriori informazioni, consulta il whitepaper Scalabilità di Tableau Server.

Distribuendo Tableau Server nel cloud è possibile sfruttare tutte le caratteristiche di scalabilità della piattaforma Tableau, tra cui la topologia dinamica. Il semplice riavvio del server consente anche di modificare le macchine sottostanti che supportano la piattaforma, purché il loro indirizzo IP pubblico rimanga invariato.

Per le implementazioni con un solo nodo è anche possibile spegnere le macchine su cui è in esecuzione Tableau Server nei periodi di inattività, per ridurre i costi. Nei cluster multi-nodo, tuttavia, questa operazione compromette le prestazioni di Tableau. Si può però ricorrere alla topologia dinamica per regolare l’allocazione dei processi di Tableau Server, raggiungendo un equilibrio tra i costi legati alle macchine e le esigenze di elaborazione. La funzionalità di ridimensionamento automatico, che interrompe e avvia le istanze delle macchine in base alle richieste, non è supportata.

Ambienti server

Oltre all’ambiente di produzione, Tableau consiglia di usare un ambiente di test per testare gli upgrade e le modifiche alla topologia del server. L’ambiente di produzione supporterà l’analisi moderna mediante progetti di produzione e sandbox con processi di convalida, promozione e certificazione dei contenuti, il tutto in un unico ambiente. Per ulteriori informazioni su questi processi di gestione dei contenuti, consulta la sezione Governance di Tableau. Gli ambienti di produzione e di test devono avere le stesse specifiche hardware, la stessa topologia del server e la stessa configurazione. Gli amministratori potranno così testare gli upgrade e partecipare ai programmi beta nell’ambiente di test ripristinando i contenuti destinati alla produzione.

Alcune organizzazioni adottano criteri IT che richiedono tre ambienti (Sviluppo, QA e Produzione) per isolare i casi di utilizzo per sviluppo, test e consumo dei contenuti in installazioni separate di Tableau Server. Se la tua organizzazione prevede questo requisito, ciascuno dei tre ambienti deve disporre di una licenza separata, perché verrebbero considerati come tre ambienti di produzione, come definito nel Contratto di licenza per l’utente finale di Tableau. Gli ambienti di produzione e di QA devono avere le stesse specifiche, la stessa topologia del server e la stessa configurazione. Se hai bisogno di tre ambienti separati, cerca di non replicare un ciclo di sviluppo a cascata tradizionale con una piattaforma di analisi moderna. Gli utenti potrebbero preferire l’ambiente QA per eludere politiche rigorose o ritardi nel trasferimento dei contenuti alla produzione, quindi cerca di raggiungere un buon equilibrio automatizzando il trasferimento dei contenuti sul server di produzione usando lo strumento Content Migration Tool disponibile in Tableau Advanced Management o degli script di flusso di lavoro personalizzati utilizzando le API REST di Tableau. L’ambiente di sviluppo non deve necessariamente avere le stesse specifiche hardware degli ambienti di produzione e di QA, a meno che l’ambiente di sviluppo venga usato per eseguire dei test sugli upgrade o la partecipazione ai programmi beta.

Alta disponibilità

Dovrai installare e configurare Tableau in base ai requisiti di disponibilità e aggiungere nodi supplementari per aumentare la capacità e/o la disponibilità (Windows | Linux). Per supportare casi d’uso di importanza critica, è necessario distribuire una configurazione dei cluster ad alta disponibilità (High Availability, HA) con il bilanciamento del carico esterno (Windows | Linux).

Un’installazione di Tableau Server di tipo HA dispone di almeno tre nodi e più istanze ridondanti per i processi chiave (repository, archivio file/motore dati e servizio di coordinamento) su nodi diversi. L’obiettivo consiste nel ridurre al minimo i tempi di inattività del sistema eliminando i singoli punti di errore e consentendo il rilevamento degli errori attraverso la funzionalità di failover, quando possibile. Per ulteriori informazioni, consulta il whitepaper Alta disponibilità di Tableau Server.

Segui il modello qui sotto per creare il tuo cluster ad alta disponibilità:

1. Installa il nodo iniziale e consenti al programma di installazione, che considera l’architettura del sistema, di configurare i processi (Windows | Linux). Il repository attivo si trova sul nodo 1.
2. Replica la configurazione del processo su altri nodi VizQL, garantendo la ridondanza (Windows | Linux). Il repository passivo si trova sul nodo 2. I processi del nodo 3 rispecchieranno i nodi 1 e 2, con l’eccezione del fatto che non avrà processi del repository.
3. Aggiungi l’insieme di servizi di coordinamento e il servizio file client (Windows | Linux).
4. Aggiungi il bilanciamento del carico esterno (Windows | Linux).
   

Una distribuzione HA di Tableau Server a 3 nodi (Nota: il servizio di coordinamento e il servizio file client non sono esplicitamente mostrati)

L’esigenza di avere nodi specializzati si evolve nel tempo. I carichi di lavoro in presenza di molti estrazioni e con frequenti aggiornamenti devono essere isolati dal carico di lavoro interattivo di rendering delle visualizzazioni. In un ambiente ricco di estrazioni, la maggior parte delle origini dati è rappresentata dalle estrazioni. La presenza di alcune estrazioni molto grandi può far rientrate la tua distribuzione in questa categoria; lo stesso è vero se si hanno molte estrazioni piccole. Le distribuzioni in cui si aggiornano le estrazioni molto spesso, ad esempio più volte al giorno durante l’orario di lavoro, devono essere isolate su dei nodi di gestione componenti in background specializzati. Per isolare il carico di lavoro del processo di gestione componenti in background, aggiungi nodi di gestione componenti in background specializzati, garantendo la ridondanza, come mostrato nei nodi 4 e 5 qui sotto. Utilizzando i ruoli dei nodi si può configurare la posizione in cui determinati tipi di carichi di lavoro vengono elaborati nell’installazione di Tableau Server. Le funzioni dei ruoli dei nodi consentono di dedicare e scalare le risorse a carichi di lavoro specifici. Per ulteriori informazioni sulla configurazione dei ruoli dei nodi per gestione componenti in background e archivio file, consulta la sezione Gestione del carico di lavoro attraverso i ruoli dei nodi.

Una distribuzione HA di Tableau Server a 5 nodi (Nota: il servizio di coordinamento e il servizio file client non sono esplicitamente mostrati)

Dalla versione 2019.3, puoi distribuire il repository di Tableau Server sul Relational Database Service (RDS) di Amazon. Il repository di Tableau Server è un database PostgreSQL in cui vengono archiviati i dati relativi a tutte le interazioni degli utenti, agli aggiornamenti delle estrazioni e altro ancora. Amazon RDS offre scalabilità, affidabilità, alta disponibilità e protezione integrata per PostgreSQL. Effettuando l’integrazione con AWS per configurare il repository esterno di Tableau Server, potrai sfruttare questi ulteriori vantaggi della distribuzione del cloud. Per ulteriori informazioni, consulta la sezione Repository esterno di Tableau Server.

Se si distribuisce Tableau Server nel cloud pubblico sono disponibili alcune opzioni per attenuare ulteriormente il rischio dei tempi di inattività. Ad esempio, è possibile distribuire ogni nodo di Tableau Server nella sua rete virtuale o in diverse zone o zone di disponibilità. La separazione dell’ambiente però potrebbe determinare una maggiore latenza in tutto il sistema. Prima di finalizzare l’ambiente, considera l’eventualità di testare sia le prestazioni che la disponibilità, per confermare di aver raggiunto un equilibrio adeguato alla tua community di utenti dei dati. Tableau Server non supporta la distribuzione di un cluster multi-nodo in diverse regioni.

Ripristino di emergenza

Nel pianificare il ripristino di emergenza (Disaster recovery, DR) nell’ambiente di Tableau, bisogna considerare due fattori principali: il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO). L’RTO misura quanto tempo di inattività l’azienda può tollerare prima del ripristino completo e influisce sulla frequenza con cui ripristini i tuoi backup in un cluster alternativo e sull’ammontare degli investimenti nell’infrastruttura. L’RPO è una misura delle perdita di dati che la tua azienda può tollerare; influisce sulla frequenza con cui dovrai eseguire i backup del sistema. Per Tableau Server l’RPO non può essere minore del tempo necessario per un backup completo del server. La tabella seguente mostra come definire una serie di requisiti per l’RTO:

Che Tableau Server sia distribuito in locale oppure nel cloud, la procedura di backup non cambia. Il comando TSM Backup permette di generare un backup di Tableau Server e di ripristinare tale backup su un’altra macchina. Le operazioni di creazione di uno snapshot di una macchina con Tableau Server e di ripristino su un’altra macchina non sono supportate. Per ulteriori informazioni, consulta la sezione Importanza dell’affidabilità per i concetti e i whitepaper relativi all’alta disponibilità e al ripristino di emergenza.