Guida alla distribuzione di Tableau Server per le organizzazioni di grandi dimensioni

L’immagine seguente mostra i processi rilevanti di Tableau Server e come sono distribuiti nell’architettura di riferimento. Questa distribuzione è considerata la distribuzione minima di Tableau Server appropriata per un’organizzazione di grandi dimensioni.

I diagrammi dei processi in questo argomento hanno lo scopo di illustrare i principali processi per ciascun nodo. Nei nodi vengono eseguiti anche molti processi di supporto che non sono mostrati nei diagrammi. Per un elenco di tutti i processi, consulta la sezione di questa guida relativa alla configurazione, Parte 4 - Installazione e configurazione di Tableau Server.

Processi di Tableau Server

L’architettura di riferimento di Tableau Server è una distribuzione cluster di Tableau Server a quattro nodi con il repository esterno in PostgreSQL:

• Nodo iniziale di Tableau Server (Nodo 1): esegue i servizi amministrativi e di licenza di TSM richiesti che possono essere eseguiti solo su un singolo nodo nel cluster. Nel contesto aziendale, il nodo iniziale di Tableau Server è il nodo primario del cluster. Questo nodo esegue anche servizi applicativi ridondanti con il Nodo 2.
• Nodi dell’applicazione Tableau Server (Nodo 1 e Nodo 2): i due nodi elaborano le richieste client, si connettono a origini dati e nodi di dati ed eseguono query.
• Nodi di dati di Tableau Server (Nodo 3 e Nodo 4): due nodi dedicati alla gestione dei dati.
• PostgreSQL esterno: questo host esegue il processo di repository di Tableau Server. Per la distribuzione a disponibilità elevata è necessario eseguire un host PostgreSQL aggiuntivo per la ridondanza attiva/passiva.

  Puoi anche eseguire PostgreSQL su Amazon RDS. Per maggiori informazioni sulle differenze tra l’esecuzione del repository su RDS rispetto a un’istanza EC2, consulta Repository esterno di Tableau Server (Linux(Il collegamento viene aperto in una nuova finestra)).

  La distribuzione di Tableau Server con un repository esterno richiede una licenza Tableau Advanced Management.

  Se la tua organizzazione non dispone di competenze interne di amministrazione dei database, puoi facoltativamente eseguire il processo Repository di Tableau Server nella configurazione PostgreSQL interna predefinita. Nello scenario predefinito, il repository viene eseguito su un nodo Tableau con PostgreSQL incorporato. In questo caso, è consigliabile eseguire il repository su un nodo Tableau dedicato e un repository passivo su un nodo dedicato aggiuntivo per supportare il failover del repository. Vedi Failover del repository (Linux(Il collegamento viene aperto in una nuova finestra)).

  A titolo di esempio, l’implementazione AWS descritta in questa Guida spiega come distribuire il repository esterno su PostgreSQL in esecuzione in un’istanza EC2.

• Facoltativo: se la tua organizzazione utilizza l’archiviazione esterna, puoi distribuire l’archivio file di Tableau come servizio esterno. Questa guida non include l’archivio file esterno nello scenario di distribuzione principale. Vedi Installare Tableau Server con l’archivio file esterno (Linux(Il collegamento viene aperto in una nuova finestra)).

  La distribuzione di Tableau Server con un Archivio file esterno richiede una licenza Tableau Advanced Management.

Repository PostgresSQL

Il repository di Tableau Server è un database che archivia i dati del server. Questi dati includono informazioni sugli utenti di Tableau Server, i gruppi e le assegnazioni di gruppo, le autorizzazioni, i progetti, le origini dati, l’estrazione di metadati e le informazioni di aggiornamento.

La distribuzione predefinita di PostgresSQL utilizza quasi il 50% delle risorse di memoria del sistema. In base al relativo utilizzo (per distribuzioni di produzione e di grandi dimensioni), l’utilizzo delle risorse può aumentare. Per questo motivo, è consigliabile eseguire il processo Repository in un computer che non esegue altri componenti server con un utilizzo intensivo delle risorse, come VizQL, Gestione componenti in background o Motore dati. L’esecuzione del processo Repository insieme a uno di questi componenti creerà conflitti di I/O o vincoli di risorse e ridurrà le prestazioni complessive della distribuzione.

Nodo 1: nodo iniziale

Il nodo iniziale esegue un numero limitato di processi importanti e condivide il carico dell’applicazione con il Nodo 2.

Il primo computer su cui si installa Tableau, il "nodo iniziale", ha alcune caratteristiche uniche. Tre processi, il servizio licenze (Gestione licenze), il servizio di attivazione e il controller TSM (Controller di amministrazione), vengono eseguiti solo sul nodo iniziale e non possono essere spostati su nessun altro nodo, se non in caso di guasto.

Failover e ripristino automatizzato del Nodo 1

Il servizio licenze, quello di attivazione e il controller TSM sono fondamentali per l’integrità di una distribuzione di Tableau Server. In caso di errore del Nodo 1, gli utenti potranno comunque connettersi alla distribuzione di Tableau Server, poiché un’architettura di riferimento configurata correttamente indirizzerà le richieste al Nodo 2. Tuttavia, senza questi servizi di base, la distribuzione sarà in uno stato critico di errore in sospeso. Vedi Ripristino automatizzato del nodo iniziale.

Nodi 1 e 2: server applicazioni

I Nodi 1 e 2 eseguono i processi di Tableau Server che elaborano le richieste client, eseguono query sulle origini dati, generano visualizzazioni, gestiscono il contenuto e l’amministrazione e altre funzionalità principali della logica di business di Tableau. I server applicazioni non memorizzano i dati degli utenti.

Nota: "Server applicazioni" è un termine che si riferisce anche a un processo di Tableau Server elencato in TSM. Il processo sottostante per "Server applicazioni" è VizPortal.

Eseguiti in parallelo, il Nodo 1 e il Nodo 2 si adattano alle richieste di servizio dalla logica di bilanciamento del carico eseguite sui server proxy inversi. In quanto nodi ridondanti, in caso di problemi di uno di questi nodi, le richieste e i servizi client vengono gestiti dal nodo rimanente.

L’architettura di riferimento è stata progettata in modo che processi applicativi complementari vengano eseguiti sullo stesso computer. Ciò significa che i processi non sono in competizione per le risorse di calcolo e non creano contese.

Ad esempio, VizQL, un servizio di elaborazione di base nei server applicazioni, è altamente vincolato dalla CPU e dalla memoria: utilizza quasi il 60-70% della CPU e della memoria del computer. Per questo motivo, l’architettura di riferimento è progettata in modo che nessun altro processo vincolato dalla memoria o dalla CPU si trovi nello stesso nodo di VizQL. I test mostrano che la quantità di carico o il numero di utenti non influisce sull’utilizzo della memoria o della CPU nei nodi VizQL. Ad esempio, la riduzione del numero di utenti simultanei nel nostro test di carico ha effetto solo sulle prestazioni del processo di caricamento della dashboard o della visualizzazione, ma non riduce l’utilizzo delle risorse. Pertanto, in base alla disponibilità di memoria e CPU durante i picchi di utilizzo, potresti prendere in considerazione l’aggiunta di più processi VizQL. Come punto di partenza per cartelle di lavoro tipiche, alloca 4 core per ogni processo VizQL.

Scalabilità dei server applicazioni

L’architettura di riferimento è progettata per la scalabilità in base a un modello basato sull’utilizzo. Come punto di partenza generale, è consigliabile un minimo di due server applicazioni, ciascuno dei quali supporta fino a 1000 utenti. Con l’aumento della base di utenti, pianifica l’aggiunta di un server applicazioni per ogni 1000 utenti aggiuntivi. Monitora l’utilizzo e le prestazioni per ottimizzare la base di utenti per ogni host dell’organizzazione.

Nodi 3 e 4: Data Server

I processi Archivio file, Motore dati (Hyper) e Gestione componenti in background si trovano nei Nodi 3 e 4 per i seguenti motivi:

• Ottimizzazione dell’estrazione: l’esecuzione di Gestione componenti in background, Hyper e Archivio file nello stesso nodo ottimizza le prestazioni e l’affidabilità. Durante il processo di estrazione, Gestione componenti in background esegue query sul database di destinazione, crea il file Hyper sullo stesso nodo e quindi effettua il caricamento nell’archivio file. Posizionando insieme questi processi nello stesso nodo, il flusso di lavoro di creazione delle estrazioni non richiede la copia di volumi elevati di dati attraverso la rete o i nodi.
• Bilanciamento delle risorse complementare: Gestione componenti in background richiede principalmente risorse CPU. Motore dati è un processo che richiede molta memoria. L’associazione di questi processi consente il massimo utilizzo delle risorse in ciascun nodo.
• Consolidamento dei processi dati: poiché tutti questi processi sono processi dati back-end, è opportuno eseguirli nel livello di dati più sicuro. Nelle versioni future dell’architettura di riferimento, i server applicazioni e i Data Server verranno eseguiti in livelli distinti. Tuttavia, a causa delle dipendenze dell’applicazione nell’architettura di Tableau, attualmente i server applicazioni e i Data Server devono essere eseguiti nello stesso livello.

Scalabilità dei Data Server

Come nel caso dei server applicazioni, la pianificazione delle risorse necessarie per i Data Server di Tableau richiede la modellazione basata sull’utilizzo. In generale, presupponi che ogni Data Server possa supportare fino a 2000 processi di aggiornamento delle estrazioni al giorno. Con l’aumento dei processi di estrazione, aggiungi altri Data Server senza il servizio Archivio file. In genere, la distribuzione del Data Server a due nodi è adatta per le distribuzioni che utilizzano il file system locale per il servizio Archivio file. Tieni presente che l’aggiunta di altri server applicazioni non influisce in modo lineare sulle prestazioni o sulla scalabilità dei Data Server. Infatti, con l’eccezione di un sovraccarico derivante da ulteriori query degli utenti, l’impatto dell’aggiunta di più host e utenti dell’applicazione è minimo.