Pianificare, ridimensionare e gestire una soluzione gateway business critical

Questo articolo è destinato a chiunque intenda distribuire un gateway dati locale in uno scenario business critical. Un gateway dati locale è business critical se è fondamentale per il normale funzionamento dell'azienda e gestisce i dati business critical.

Se i gateway business critical non vengono gestiti correttamente, è possibile che si verifichino query non riuscite o prestazioni lente. Quando si pianifica, si ridimensiona e si gestisce correttamente la soluzione gateway business critical, è possibile ridurre al minimo la probabilità di un problema che influisce sull'azienda.

Terminologia

In questo articolo vengono usati i termini importanti seguenti:

  • Gateway: applicazione gateway dati locale installata in un computer.
  • Server gateway: computer Windows (macchina virtuale o computer fisico/server) in cui è installata l'applicazione gateway dati locale.
  • Cluster gateway: set di gateway che interagiscono (e potrebbero essere con carico bilanciato).
  • Membro del gateway: un gateway che fa parte di un cluster gateway.

L'immagine seguente illustra la relazione tra i concetti definiti in precedenza.

Immagine di un cluster gateway come parte di tre server gateway, ognuno contenente un gateway separato

Consigli per i gateway business critical

Per i gateway business critical, i gateway devono essere distribuiti e gestiti correttamente per garantire disponibilità elevata, prestazioni ottimali e scalabilità gestibile. La distribuzione non corretta dei gateway può comportare prestazioni scarse, query non riuscite e difficoltà nella diagnosi di potenziali problemi. Potrebbe anche impedire la possibilità di aumentare e ridurre le prestazioni dei gateway man mano che aumentano l'utilizzo.

Per garantire scalabilità, prestazioni e velocità effettiva ottimali, seguire le indicazioni riportate nelle sezioni successive.

Conoscere tutte le chiavi di ripristino del gateway

Assicurarsi che tutte le chiavi di ripristino del gateway siano note e mantenute in un luogo sicuro. Senza una chiave di ripristino, non è possibile recuperare o effettuare il downgrade dei gateway. Questa limitazione è per impostazione predefinita. Se si perdono le chiavi di ripristino, l'unica opzione consiste nel creare nuovi gateway e ricreare le origini dati. Inoltre, non è possibile aggiungere nuovi gateway al cluster senza la chiave di ripristino, che limita la scalabilità futura.

Archiviare le chiavi di ripristino in un luogo sicuro proprio come si archivierebbero le credenziali amministrative, ad esempio una password sicura, accessibile solo dagli amministratori autorizzati.

Se attualmente non si conoscono tutte le chiavi di ripristino del gateway, si tratta di un rischio aziendale significativo. Creare immediatamente nuovi cluster gateway e avviare la migrazione dei carichi di lavoro ai cluster gateway.

Carichi di lavoro di sviluppo e carichi di lavoro critici per l'azienda

Separare i carichi di lavoro di sviluppo da quelli aziendali critici configurando uno o più cluster gateway di sviluppo e uno o più cluster gateway di produzione, come descritto di seguito.

Immagine di un cluster gateway di sviluppo e test con tre gateway e un cluster di produzione separato con tre gateway

Usare un cluster gateway di sviluppo per testare nuovi modelli semantici, report, query e così via. Dopo aver verificato un nuovo carico di lavoro, eseguirne la migrazione a un cluster di gateway business critical. Questo processo evita che carichi di lavoro nuovi, non testati o sperimentali possano intaccare i carichi di lavoro di produzione.

Usare anche i cluster gateway di sviluppo per testare i nuovi aggiornamenti del gateway prima di applicare gli aggiornamenti ai cluster di gateway critici per l'azienda. I nuovi aggiornamenti del gateway devono essere distribuiti per almeno 24 ore nei cluster del gateway di sviluppo prima di essere usati nei cluster di gateway business critical.

Usare più cluster gateway

Se si sta creando un cluster gateway per un numero elevato di utenti dell'organizzazione, è necessario creare più cluster gateway in base alle business unit o minori per limitare eventuali potenziali effetti sulle prestazioni a un piccolo subset di utenti.

Non è consigliabile usare un singolo cluster di gateway business critical per un'intera azienda (a meno che l'azienda non sia piccola). In uno scenario di cluster gateway singolo, un utente potrebbe inviare una query che causa un impatto significativo sulle prestazioni per tutto il traffico attraverso il gateway. Se il gateway viene usato nell'intera azienda, l'impatto sulle prestazioni potrebbe influire sull'intera azienda. Inoltre, quando un cluster gateway viene usato in un'intera azienda, potrebbe essere più difficile identificare quale query potrebbe causare un problema di prestazioni quando si usa la funzionalità di monitoraggio delle prestazioni del gateway.

Immagine di un'organizzazione di esempio con cluster gateway separati per business intelligence aziendale e app, il reparto finanziario, il reparto marketing e le app e business intelligence personali.

Usare le funzionalità di disponibilità elevata e bilanciamento del carico del gateway

Usare sempre le funzionalità di disponibilità elevata e bilanciamento del carico del gateway per qualsiasi cluster di gateway business critical.

  • Disponibilità elevata: elimina la presenza di un singolo punto di errore.
  • Bilanciamento del carico: distribuisce automaticamente il carico di lavoro in tutti i server gateway nel cluster.

Configurare almeno due gateway per ogni cluster di gateway nel caso in cui un gateway sia offline per qualsiasi motivo. Questa configurazione garantisce che un singolo errore del gateway non causi un errore dell'intero cluster gateway. Inoltre, i limiti di CPU, memoria e concorrenza possono essere abilitati nei gateway per distribuire meglio il carico nel cluster gateway.

Pianificare e gestire la scalabilità del cluster gateway

La configurazione di un cluster gateway usando le linee guida hardware e software consigliate garantisce che il cluster venga eseguito con prestazioni ottimali. I gateway non ridimensionati correttamente potrebbero comportare prestazioni scarse. Esistono molti fattori da considerare per ottenere prestazioni ottimali nel cluster del gateway.

Determinare le specifiche hardware del server gateway

Le specifiche del server gateway (CPU, memoria, disco e così via) sono un fattore importante, come nella maggior parte dei casi, le trasformazioni di Power Query vengono applicate ai dati nel server gateway. Di conseguenza, un server gateway deve avere risorse, memoria e potenza di elaborazione sufficienti per gestire tutte le trasformazioni dei dati.

Quando è necessario scegliere una dimensione del server, sono presenti due metriche più importanti: memoria e CPU. Per elaborare i passaggi di trasformazione dei dati di Power Query nel gateway, è necessaria sia una quantità di memoria che una potenza della CPU. È importante che il server gateway sia abbastanza potente da elaborare il carico di lavoro più elevato disponibile. Se il server gateway non è in grado di gestire il carico di lavoro, la query diretta o l'aggiornamento dei dati avrà esito negativo. È anche importante comprendere il numero di query eseguite contemporaneamente.

Queste diverse opzioni di query hanno un effetto diverso sul server gateway.

Tipo di query Fattore limite
Import Memory
DirectQuery CPU
Live Connessione CPU

Durante un'importazione, è necessario eseguire query ed elaborare l'intero set di dati, che è un'attività di memoria intensa. Questa importazione spesso richiede più tempo. DirectQueries e Live Connessione ions sono in genere pesanti per la CPU. Nella maggior parte dei casi, le query dirette vengono eseguite molte volte per elaborare solo una piccola parte dei dati. Poiché viene elaborata solo una piccola parte dei dati, queste query dirette non sono in genere un'attività pesante per la memoria. Tuttavia, poiché le query vengono eseguite molte volte su richiesta, questa operazione può richiedere un utilizzo elevato della CPU.

A seconda del carico di lavoro, valutare la possibilità di ottimizzare il server gateway per la memoria o la CPU.

Quando ridimensionare un cluster gateway

Il ridimensionamento è un aspetto importante di un cluster di gateway business critical. Con l'aumento dell'utilizzo con il cluster gateway, è necessario aumentare e/o aumentare le prestazioni del cluster gateway per garantire prestazioni ottimali. È consigliabile iniziare a aumentare il numero di istanze di un cluster gateway se in precedenza sono stati ridimensionati i gateway nel cluster.

Il ridimensionamento e la distribuzione del carico del traffico tra singoli nodi all'interno di un cluster è un processo complesso che varia a seconda di ogni singolo scenario. Anche se non esiste un modello definitivo per garantire che tutto il traffico del gateway venga eseguito in modo prevedibile, i limiti elencati di seguito indicano una necessità di ridimensionamento. In generale, è consigliabile aumentare il numero di istanze (aggiungendo nodi al cluster) preferibilmente per aumentare le prestazioni (aumento della CPU, della RAM o dello spazio su disco in singoli nodi). La scalabilità orizzontale tende a essere più efficace complessivamente nella capacità del sistema nel suo complesso di gestire traffico aggiuntivo. La scalabilità orizzontale ha anche un impatto positivo sulla larghezza di banda totale che il cluster può elaborare, mentre la scalabilità verticale in genere non è. Quando uno o più nodi del gateway mostrano indicazioni sul raggiungimento delle soglie descritte di seguito, è consigliabile considerare l'aumento del numero di istanze del cluster.

  • CPU: la CPU è superiore all'80% per lunghi periodi di tempo, ma occasionali picchi brevi (meno di 5 minuti) che max out CPU non sono anomale.

  • RAM: i cali di memoria disponibili al di sotto del 20% regolarmente.

  • Disco: lo spazio libero su disco è inferiore a 5 GB di frequente. Questo dip potrebbe anche indicare la necessità di configurare la memorizzazione nella cache o le directory di spooling in modo più strategico.

  • Concorrenza: esecuzione simultanea di più di 40 query in un singolo nodo.

Poiché gli aggiornamenti e le query distribuite tra i nodi del gateway possono avere profili molto diversi, è consigliabile anche esaminare in modo più approfondito i processi a esecuzione prolungata o a elevato utilizzo di memoria. L'ottimizzazione delle query in questi casi può avere un impatto enorme sulle prestazioni e sulla scalabilità, non solo per i singoli report e aggiornamenti, ma nel sistema nel suo complesso. È consigliabile isolare gli aggiornamenti in questione in un singolo cluster gateway dedicato per valutare le caratteristiche delle prestazioni ed eseguire l'ottimizzazione usando la diagnostica del piano di query, gli indicatori di riduzione e tutte le altre raccomandazioni sulle prestazioni pubblicate. Questo isolamento riduce al minimo la quantità di dati recuperati e la quantità di post-elaborazione necessaria. Questo isolamento può essere usato anche come strategia a lungo termine per sequenziare processi ETL a esecuzione prolungata in un cluster gateway dedicato per ridurre la contesa con altri aggiornamenti tipici nell'organizzazione.

Aumento delle prestazioni di un cluster gateway

Immagine di un errore di query usando un cluster gateway con due gateway con 5 GB di memoria e un esito positivo della query usando un custer con due gateway, con un gateway con 7 GB di memoria

La scalabilità verticale è quando si aumentano le specifiche (CPU, memoria, disco e così via) dei server gateway.

La scalabilità verticale potrebbe essere necessaria se viene raggiunta la CPU o la memoria massima quando il gateway esegue una o più query. Una query può essere eseguita solo in un server gateway, motivo per cui il server gateway deve disporre di risorse sufficienti per elaborare l'intera query insieme ai dati risultanti.

Aumento del numero di istanze di un cluster gateway

Immagine di un errore di query usando un cluster con due gateway con 5 GB di memoria ciascuno e un esito positivo della query usando un cluster con tre gateway con 5 GB di memoria ciascuno

L'aumento del numero di istanze è necessario se il server gateway ha già specifiche elevate (in altre parole, il server gateway è già stato ridimensionato) o se sono stati raggiunti i limiti di ciò che un singolo server gateway può gestire a causa del numero di query simultanee in esecuzione. L'aumento del carico su larga scala nell'intero set di membri del gateway è un'ottima indicazione che il ridimensionamento di un cluster tramite l'aggiunta di nodi è il corso di azione corretto. Quando ridimensionare un cluster gateway fornisce soglie specifiche che indicano quando è il momento di ridimensionare. Per altre informazioni sull'aumento del numero di istanze, vedere Usare le funzionalità di disponibilità elevata e bilanciamento del carico del gateway.

Ridimensionamento creando nuovi cluster gateway

Se l'utilizzo delle risorse del cluster gateway è elevato o un numero eccezionale di utenti che si basano su un cluster gateway, è possibile creare un nuovo cluster gateway. È quindi possibile eseguire la migrazione di un subset del carico di lavoro al nuovo cluster del gateway. Quando un numero elevato di utenti si basa su un singolo cluster gateway, la probabilità che un utente possa inviare una query che causa un impatto significativo sulle prestazioni nell'intero cluster del gateway aumenta significativamente.

Un numero eccezionale di utenti che si basano su un singolo cluster di gateway è un indicatore che deve essere creato un nuovo cluster gateway.

Monitoraggio e risoluzione dei problemi relativi alle prestazioni del gateway

È importante monitorare le prestazioni complessive dei gateway business critical usando la funzionalità di monitoraggio delle prestazioni del gateway. È anche possibile usare questa funzionalità per risolvere i problemi di prestazioni, identificare i colli di bottiglia e identificare le query che influiscono sulle prestazioni complessive del gateway. Questa funzionalità è anche uno strumento importante per determinare quando ridimensionare un cluster gateway.

Se si identifica una query come un impatto notevole sul gateway con prestazioni complessive ridotte, è possibile riscrivere la query in modo da essere più efficiente e ridurre al minimo l'impatto sulle prestazioni.

Se Microsoft identifica prestazioni scarse causate da un gateway o da un componente correlato al gateway, ad esempio una capacità Power BI Premium in overload, il componente di overload deve essere risolto ridimensionando o riducendo il carico. Microsoft non esamina le prestazioni scarse quando viene sovraccaricato un gateway o un componente correlato al gateway.