Share via

  • Articolo

Miglioramento della scalabilità e della disponibilità

In molte applicazioni, è essenziale garantire una maggiore disponibilità e una migliore scalabilità in lettura. L'utilizzo della replica può rappresentare uno dei fattori chiave di soluzioni in grado di offrire entrambe. Alcune applicazioni potrebbero essere progettate al fine di migliorare la disponibilità o la scalabilità tramite la replica. Se è necessario affrontare uno solo di questi aspetti, considerare uno degli scenari seguenti:

Nelle figure seguenti vengono illustrate due applicazioni che consentono di migliorare la disponibilità e la scalabilità grazie all'utilizzo della replica. In entrambi i casi, i tre database delle figure sono peer, ovvero contengono schemi e dati uguali. L'attività di scrittura relativa a questi database deve essere partizionata. Se il database contiene un catalogo di prodotti, è possibile, ad esempio, indirizzare al primo database gli aggiornamenti dei nomi di prodotti che iniziano per A-I, al secondo quelli che iniziano per J-R e al terzo quelli che iniziano per S-Z. Gli aggiornamenti vengono replicati successivamente negli altri database.

Nella prima figura viene illustrata una configurazione in cui ogni server Web e ogni server applicazioni utilizza i dati di un particolare server di cache. Le letture e gli aggiornamenti di un dato utente confluiscono in uno specifico server applicazioni e quindi in uno specifico server di cache. Dato che il server applicazioni aggiorna la cache direttamente, non è necessario un server di origine centrale. Gli aggiornamenti di ogni cache vengono propagati alle altre.

Utilizzo della replica come soluzione di scalabilità per le attività di lettura

Nella seconda figura vengono illustrati tre server geograficamente distanti attraverso i quali passa un flusso di dati, il che consente a ognuno dei server di supportare le richieste di lettura e migliorare la disponibilità.

Replica peer-to-peer in posizioni diverse

Esempio Adventure Works Cycles

Adventure Works Cycles è un'azienda manifatturiera fittizia utilizzata per esemplificare concetti e scenari relativi ai database. Per ulteriori informazioni, vedere Database di esempio AdventureWorks.

Adventure Works Cycles dispone di numerosi uffici in tutto il mondo, tra cui sedi a Los Angeles, Londra e Taipei. Le informazioni relative agli ordini dei clienti vengono raccolte presso ogni località e quindi replicate nelle altre.

Le informazioni relative agli ordini possono essere lette da qualsiasi sede, pertanto, se la sede di Londra attraversa un periodo di intensa attività di lettura, le applicazioni interne potranno distribuire parte di questa attività alle altre due sedi.

Se un server è inattivo per manutenzione nella sede di Londra, ad esempio, sarà sempre possibile recuperare gli ordini da un'altra località e il personale della sede di Londra potrà continuare a leggere e inserire i dati. Quando il server di Londra viene riportato in linea, le modifiche ricevute durante il periodo di inattività verranno propagate in modo da aggiornarlo.

Requisiti comuni per questo scenario

Le applicazioni che utilizzano la replica per la scalabilità e la disponibilità in genere devono soddisfare i requisiti seguenti necessari per una soluzione di replica adeguata:

  • Il sistema deve consentire l'esecuzione di modifiche da qualsiasi server e la replica delle modifiche in tutti gli altri server.

  • È necessario che nel sistema venga mantenuta la consistenza delle transazioni.

  • Il sistema deve avere una bassa latenza, ovvero gli aggiornamenti di un server dovranno raggiungere gli altri server rapidamente.

  • La velocità effettiva del sistema deve essere elevata, perché il sistema deve essere in grado di gestire la replica di un numero elevato di transazioni.

  • L'elaborazione delle repliche deve richiedere un overhead minimo.

Tipo di replica da utilizzare per questo scenario

Microsoft In SQL Server viene utilizzata una metafora basata sul settore dell'editoria per la descrizione dei componenti del sistema di replica. I componenti includono server di pubblicazione, Sottoscrittori, pubblicazioni, articoli e sottoscrizioni.

Nelle figure riportate sopra, tutti i server di cache sono server di pubblicazione e Sottoscrittori. Tutti i dati nel database replicato di ogni server vengono inclusi nella pubblicazione e ogni tabella di dati è un articolo (gli articoli possono anche essere altri oggetti di database, ad esempio stored procedure). Ogni server sottoscrive pubblicazioni degli altri server, ricevendo schemi e dati come una sottoscrizione. Per ulteriori informazioni sui componenti del sistema, vedere Panoramica del modello di pubblicazione della replica.

SQL Server supporta diversi tipi di replica per soddisfare differenti esigenze applicative, ovvero la replica snapshot, transazionale e di tipo merge. Per ottenere i migliori risultati ai fini dell'implementazione di questo scenario, è consigliabile utilizzare la replica transazionale peer-to-peer, adatta alla gestione dei requisiti descritti nella sezione precedente. Per ulteriori informazioni sulla replica transazionale peer-to-peer, vedere Replica transazionale peer-to-peer.

[!NOTA]

È possibile che si verifichino conflitti di dati se l'applicazione richiede modifiche a una specifica riga da più nodi contemporaneamente. In questo caso, utilizzare la replica di tipo merge, che è adatta alla gestione di conflitti. Per ulteriori informazioni sulla replica di tipo merge, vedere Panoramica della replica di tipo merge.

Le caratteristiche di progettazione tipiche della replica transazionale la rendono il tipo di replica ideale per soddisfare i requisiti principali di questo scenario:

  • Possibilità di apportare modifiche da qualsiasi server

  • Consistenza delle transazioni

  • Bassa latenza

  • Velocità effettiva elevata

  • Overhead minimo

L'opzione peer-to-peer per la replica transazionale consente ai server di pubblicare e sottoscrivere gli stessi dati. Tutti i nodi in una topologia peer-to-peer sono peer, ovvero ogni nodo pubblica e sottoscrive gli stessi schemi e dati. Le modifiche (inserimenti, aggiornamenti ed eliminazioni) possono essere apportate in tutti i nodi e replicate in tutti gli altri nodi.

Passaggi per l'implementazione dello scenario

Per implementare questo scenario, è innanzitutto necessario creare pubblicazioni e sottoscrizioni e quindi inizializzare ogni sottoscrizione. Per ulteriori informazioni, vedere:

Dopo l'inizializzazione delle sottoscrizioni e l'attivazione del flusso di dati tra peer, potrebbe essere necessario consultare gli argomenti seguenti per raccogliere ulteriori informazioni sulle attività più comuni di amministrazione e monitoraggio: