Scalabilità orizzontale di una soluzione di Analysis Services
È spesso possibile che un amministratore di database di Analysis Services desideri migliorare il tempo di risposta delle query per un numero sempre maggiore di utenti finali. È possibile ottenere tale risultato in due modi: aumentando la potenza del server esistente (scalabilità verticale) oppure distribuendo il carico tra più server di piccole dimensioni (scalabilità orizzontale).
La scalabilità verticale di una soluzione è in genere limitata dall'impossibilità di espandere o aggiornare ulteriormente l'hardware esistente. È possibile ad esempio che la scheda madre esistente non supporti la nuova versione di CPU o che sia stato raggiunto lo spazio degli indirizzi fisici per la memoria consentito. La scalabilità orizzontale di una soluzione risulta invece più flessibile e le limitazioni possono essere superate con maggiore semplicità. Se è stato raggiunto il limite massimo del numero di server in Bilanciamento carico di rete (NLB, Network Load Balancer), è possibile aggiungere un ulteriore NLB alla soluzione e distribuire i server tra più NLB.
In questo documento viene illustrata un'architettura teorica per la scalabilità orizzontale di una soluzione di Analysis Services.
Scenario
Un amministratore di database di Analysis Services deve fornire agli utenti finali una soluzione di Analysis Services con un tempo di risposta alle query migliore, garantendo inoltre un tempo di inattività minimo per l'aggiornamento dei dati. Il numero originale di 80 utenti è raddoppiato nell'ultimo mese e si ritiene che il numero attuale sia destinato a raddoppiare di nuovo nei prossimi sei mesi. A partire dal settimo mese, è inoltre prevista una crescita mensile del numero di utenti pari al 4%. Le attuali dimensioni del database di Analysis Services sono pari a 80 GB, con un aumento di 6 GB al mese. Il database contiene attualmente i dati degli ultimi 12 mesi, ma dovrà contenere la cronologia degli ultimi 3 anni fiscali oltre a quello corrente. Il tempo di elaborazione medio è di 2 ore e mezzo e il tempo di inattività è limitato a mezz'ora.
Alternative
Una volta letti i dettagli dello scenario, è possibile che si individui nella scalabilità verticale del server l'unica soluzione possibile. In questo modo, si otterrebbe un servizio privo di tempi di inattività, ma con prestazioni ridotte durante la fase di elaborazione. Gli utenti attuali sono tuttavia 160 e nei prossimi sei mesi si arriverà al doppio: 320 utenti. Tale numero continuerà ad aumentare di 13-16 utenti al mese per un periodo indefinito. In base a questa media, con una crescita stabile, il numero di utenti raddoppierà di nuovo tra il diciottesimo e il diciannovesimo mese. In questa situazione, sarà difficile espandere l'hardware in modo corretto e giustificare una richiesta di budget per un'attrezzatura di cui verrà sfruttato meno del 50% della capacità effettiva nei prossimi 12 mesi.
Fortunatamente, la scalabilità orizzontale è supportata in SQL Server 2008Analysis Services con la funzionalità di sola lettura del database.
Architettura con scalabilità orizzontale
La progettazione di questa architettura prevede due elementi:
Un layout fisico per aumentare al massimo la velocità effettiva dell'utente finale.
Un framework delle operazioni per ridurre al minimo il tempo di inattività.
Layout fisico
La soluzione è costituita da tre componenti principali:
Ambiente di elaborazione
Rete di archiviazione (SAN)
Ambiente di accesso ai dati
Nel primo componente, l'ambiente di elaborazione, i dati vengono aggiornati ed elaborati mediante un segmento della rete SAN. Nel secondo componente, SAN, i dati vengono mantenuti per gli ambienti di elaborazione e di accesso ai dati. Nel terzo componente, l'ambiente di accesso ai dati, i dati vengono resi disponibili agli utenti finali.
Ambiente di elaborazione
L'ambiente di elaborazione è costituito da un server, da una connessione alla rete di archiviazione SAN e da un volume logico SAN in cui sono contenuti i dati di Analysis Services.
Rete di archiviazione (SAN)
Questa soluzione è costituita da due "volumi logici SAN" indipendenti: uno per l'ambiente di elaborazione, l'altro per quello di accesso ai dati.
La rete di archiviazione SAN rappresenta il set di dispositivi che forniscono lo spazio fisico di archiviazione per i database multidimensionali. SAN consente di stabilire connessioni ad alta velocità tra i server e lo spazio di archiviazione, che include lo spazio di archiviazione condiviso, i cluster e meccanismi di recupero dati.
In questo documento il termine "volume logico SAN" definisce l'unità di archiviazione individuata dal sistema operativo come unità fisica.
Ambiente di accesso ai dati
L'ambiente di accesso ai dati è costituito da più server che condividono lo stesso volume logico SAN. Il numero iniziale di server è in genere pari a tre. Gli utenti si connettono ai server di accesso ai dati tramite un dispositivo NLB che esegue il routing di tutte le richieste in entrata mediante un algoritmo di bilanciamento del carico.
Varianti del layout fisico
Se necessario, è possibile utilizzare le seguenti varianti per ottenere prestazioni migliori nella soluzione.
Ambiente di elaborazione
In alcuni casi, è possibile utilizzare due server di elaborazione: uno per i database relazionali, l'altro per contenere i database di Analysis Services.
È possibile inoltre definire più volumi logici per contenere i database relazionali e i database multidimensionali in modo indipendente nella rete di archiviazione SAN.
Ambiente di accesso ai dati
Due o più NLB vengono definiti come parte della soluzione, con un numero minimo di tre server di accesso ai dati per dispositivo NLB.
Framework delle operazioni
La soluzione prevede tre fasi:
Elaborazione dati
Tempo di inattività
Reimpostazione dell'elaborazione dati
Elaborazione dati
In questa fase, il database multidimensionale viene aggiornato ed elaborato. Quando il contenuto del database multidimensionale è pronto per l'invio, l'ambiente di accesso ai dati elabora i dati per il trasferimento. Questo processo prevede i seguenti passaggi:
Scollegare il database di Analysis Services dal server di elaborazione dati.
Impostare come non in linea il volume logico SAN che contiene il database di Analysis Services.
Tempo di inattività
In questa fase, il contenuto del database aggiornato viene scambiato con il contenuto del database originale.
Impostare i dispositivi NLB per rifiutare le richieste in entrata.
Scollegare i database di Analysis Services da ciascun server di accesso ai dati.
Impostare come non in linea il volume logico SAN che contiene il database di Analysis Services per ciascun server di accesso ai dati.
Mediante i comandi SAN, eseguire lo scambio dei volumi logici SAN tra l'ambiente di elaborazione e l'ambiente di accesso ai dati.
Portare in linea, come dispositivo di sola lettura, il volume logico SAN che contiene il database di Analysis Services per ciascun server di accesso ai dati.
Collegare il database di Analysis Services a ogni server di accesso ai dati, in modalità ReadOnly.
Impostare i dispositivi NLB per accettare le richieste in entrata.
Reimpostazione dell'elaborazione dati
In questa fase, il contenuto del volume logico SAN precedente viene aggiornato e portato in linea nell'ambiente di elaborazione.
Mediante i comandi SAN, eseguire il mirroring del volume logico SAN nell'ambiente di accesso ai dati sul volume logico SAN dell'ambiente di elaborazione.
Portare in linea, come dispositivo di lettura/scrittura, il volume logico SAN che contiene il database di Analysis Services per l'ambiente di elaborazione.
Collegare il database di Analysis Services al server dell'ambiente di elaborazione, in modalità ReadWrite.