Disponibilità tramite ridondanza - database SQL di Azure
Si applica a: 
Database SQL di Azure
Questo articolo descrive l'architettura di database SQL di Azure che ottiene la disponibilità tramite ridondanza locale e disponibilità elevata tramite ridondanza della zona.
Panoramica
Il database SQL viene eseguito nella versione stabile più recente del motore di database di SQL Server nel sistema operativo Windows con tutte le patch applicabili. Il database SQL gestisce automaticamente le attività di manutenzione critiche, quali l'applicazione di patch, i backup, gli aggiornamenti di Windows e SQL e gli eventi non pianificati come errori di hardware, software o rete sottostanti. Quando un database o un pool elastico nel database SQL viene sottoposto a patch esegue un failover, il tempo di inattività non influisce se si usa la logica di ripetizione dei tentativi nell'app. Il database SQL di Azure può effettuare rapidamente il recupero anche nei casi più critici, garantendo che i dati siano sempre disponibili. La maggior parte degli utenti non nota che gli aggiornamenti vengono eseguiti continuamente.
Per impostazione predefinita, database SQL di Azure ottiene la disponibilità tramite ridondanza locale, rendendo il database disponibile durante:
- Operazioni di gestione avviate dal cliente che comportano un breve tempo di inattività
- Operazioni di manutenzione del servizio
- Problemi relativi a:
- rack in cui sono in esecuzione i computer che alimentano il servizio
- computer fisico che ospita il motore di database SQL
- Altri problemi relativi al motore di database SQL
- Altre potenziali interruzioni locali non pianificate
La soluzione a disponibilità predefinita è progettata per garantire che i dati di cui è stato eseguito il commit non vadano mai persi a causa di errori, che le operazioni di manutenzione non influiscano sul carico di lavoro e che il database non rappresenti un singolo punto di guasto nell'architettura del software.
Tuttavia, per ridurre al minimo l'impatto sui dati in caso di interruzione di un'intera zona, è possibile ottenere una disponibilità elevata abilitando la ridondanza della zona. Senza ridondanza della zona, i failover vengono eseguiti localmente all'interno dello stesso data center, il che potrebbe causare l'indisponibilità del database fino a quando non viene risolta l'interruzione. L'unico modo per eseguire il ripristino è tramite una soluzione di ripristino di emergenza, ad esempio il failover geografico tramite la replica geografica attiva, i gruppi di failover o il ripristino geografico di un backup con ridondanza geografica. Per ulteriori informazioni, si veda Panoramica sulla continuità aziendale.
Esistono tre modelli di architettura della disponibilità:
- Il modello di archiviazione remota basato su una separazione tra calcolo e archiviazione. Si basa sulla disponibilità e sull'affidabilità del livello di archiviazione remota. Questa architettura è destinata alle applicazioni aziendali orientate al budget che possono tollerare una riduzione del livello delle prestazioni durante le attività di manutenzione.
- Il modello di archiviazione locale basato su un cluster di processi del motore di database. Si basa sul fatto che esiste sempre un quorum di nodi disponibili del motore di database. Questa architettura è destinata alle applicazioni cruciali con prestazioni di I/O elevate, velocità di transazione elevata e garantisce un impatto minimo sulle prestazioni sul carico di lavoro durante le attività di manutenzione.
- Il modello Hyperscale che usa un sistema distribuito di componenti a disponibilità elevata, come ad esempio nodi di calcolo, server di pagine, servizio di log e archiviazione permanente. Ogni componente che supporta un database Hyperscale offre ridondanza e resilienza agli errori. I nodi di calcolo, i server di pagine e il servizio di log vengono eseguiti in Service Fabric di Azure, che controlla il funzionamento di ogni componente ed esegue i failover nei nodi integri disponibili in base alle esigenze. L'archiviazione persistente usa Archiviazione di Azure con le funzionalità native di disponibilità elevata e ridondanza. Per maggiori informazioni, vedere Architettura Hyperscale.
All'interno di ognuno dei tre modelli di disponibilità, il database SQL supporta le opzioni di ridondanza locale e ridondanza di zona. La ridondanza locale offre resilienza all'interno di un data center, mentre la ridondanza della zona migliora ulteriormente la resilienza proteggendo dalle interruzioni di una zona di disponibilità all'interno di un'area.
La tabella seguente illustra le opzioni di disponibilità in base ai livelli di servizio:
| Livello di servizio | Modello di disponibilità elevata | disponibilità con ridondanza locale | Disponibilità con ridondanza della zona |
|---|---|---|---|
| Utilizzo generico (vCore) | Archiviazione remota | Sì | Sì |
| Business Critical (vCore) | Archiviazione locale | Sì | Sì |
| Hyperscale (vCore) | Hyperscale | Sì | Sì |
| Basic (DTU) | Archiviazione remota | Sì | No |
| Standard (DTU) | Archiviazione remota | Sì | No |
| Premium (DTU) | Archiviazione locale | Sì | Sì |
Per maggiori informazioni su contratti di servizio specifici per diversi livelli di servizio, si veda Contratto di servizio per il database SQL di Azure.
Disponibilità tramite ridondanza locale
La disponibilità con ridondanza locale si basa sull'archiviazione del database nell'archiviazione con ridondanza locale che copia i dati tre volte all'interno di un singolo data center nell'area primaria e protegge i dati in caso di errore locale, ad esempio una rete su scala ridotta o un'interruzione dell'alimentazione. L'archiviazione con ridondanza locale è l'opzione di ridondanza più economica e offre una durabilità inferiore rispetto alle altre opzioni. Se all'interno di un'area si verifica un disastro su vasta scala come un incendio o un alluvione, tutte le repliche dell'account di archiviazione che usano l'archiviazione con ridondanza locale potrebbero essere perse o irrecuperabili. Di conseguenza, per proteggere ulteriormente i dati quando si usa l'opzione di disponibilità con ridondanza locale, è consigliabile usare un'opzione di archiviazione più resiliente per i backup del database. Ciò non si applica ai database Hyperscale, in cui viene usata la stessa risorsa di archiviazione sia per i file di dati che per i backup.
La disponibilità con ridondanza locale è disponibile per tutti i database in tutti i livelli di servizio e l'obiettivo del punto di ripristino (RPO), che indica che la quantità di perdita di dati, è zero.
Livelli di servizio Basic, Standard e Utilizzo generico
I livelli di servizio Basic e Standard del modello di acquisto basato su DTU e il livello di servizio Utilizzo generico del modello di acquisto basato su vCore usano il modello di disponibilità di archiviazione remota sia per il calcolo serverless che per quello con provisioning. La figura seguente mostra quattro nodi diversi con i livelli di calcolo e archiviazione separati.
Il modello di disponibilità dell'archiviazione remota include due livelli:
- Un livello di calcolo senza stato che esegue il processo del motore di database e contiene solo dati temporanei e memorizzati nella cache, come ad esempio i database
tempdbemodelnell'unità SSD collegata e la cache dei piani, il pool di buffer e il pool columnstore in memoria. Il nodo senza stato è gestito da Service Fabric di Azure che inizializza il motore di database, controlla il funzionamento del nodo e, se necessario, esegue il failover in un altro nodo. - Un livello di dati con stato con i file di database (
.mdfand.ldf) archiviati in Archiviazione BLOB di Azure. L'Archiviazione BLOB di Azure include funzionalità predefinite di disponibilità e ridondanza dei dati. Garantisce che ogni record nel file di log o nella pagina del file di dati venga mantenuto anche se il processo del motore di database si arresta in modo anomalo.
Ogni volta che viene aggiornato il motore di database o il sistema operativo oppure viene rilevato un errore, Service Fabric di Azure sposta il processo del motore di database senza stato in un altro nodo di calcolo senza stato con capacità libera sufficiente. I dati presenti in Archiviazione BLOB di Azure non vengono interessati dallo spostamento e i dati e i file di log vengono associati al processo di motore di database appena inizializzato. Questo processo garantisce la disponibilità elevata, ma un carico di lavoro elevato potrebbe riscontrare una riduzione delle prestazioni durante la transizione perché il nuovo processo del motore di database inizia con la cache a freddo.
Disponibilità dei livelli di servizio Premium e Business Critical
Il livello di servizio Premium del modello di acquisto basato su DTU e il livello di servizio Business Critical del modello di acquisto basato su vCore usano il modello di disponibilità di archiviazione locale, che integra le risorse di calcolo (processo del motore di database) e l'archiviazione (SSD collegata localmente) in un singolo nodo. La disponibilità elevata viene ottenuta replicando sia il calcolo che l'archiviazione in nodi aggiuntivi.
I file di database sottostanti (.mdf/.ldf) vengono inseriti nell'archiviazione SSD collegata per fornire operazioni di I/O a bassa latenza al carico di lavoro. La disponibilità elevata viene implementata mediante una tecnologia simile a Gruppi di disponibilità AlwaysOn di SQL Server. Il cluster include una singola replica primaria accessibile per i carichi di lavoro dei clienti in lettura/scrittura e fino a tre repliche secondarie (calcolo e archiviazione) contenenti copie dei dati. La replica primaria esegue costantemente il push delle modifiche alle repliche secondarie in ordine e garantisce che i dati vengano mantenuti in un numero sufficiente di repliche secondarie prima di eseguire il commit di ogni transazione. Questo processo garantisce che, se la replica primaria o la replica secondaria leggibile si arrestino in modo anomalo per qualsiasi motivo, esiste sempre una replica completamente sincronizzata in cui eseguire il failover. Il failover viene avviato da Service Fabric di Azure. Quando una replica secondaria diventa la nuova replica primaria, viene creata un'altra replica secondaria per garantire che il cluster disponga di un numero sufficiente di repliche per mantenere il quorum. Al termine di un failover, le connessioni SQL di Azure vengono reindirizzate automaticamente alla nuova replica primaria o alla replica secondaria leggibile.
Come vantaggio aggiuntivo, il modello di disponibilità dell'archiviazione locale include la possibilità di reindirizzare le connessioni SQL di Azure di sola lettura a una delle repliche secondarie. Questa funzionalità è denominata Scalabilità in lettura. Offre una capacità di calcolo aggiuntiva del 100% senza costi aggiuntivi per le operazioni di sola lettura, ad esempio i carichi di lavoro analitici, dalla replica primaria.
Livello di servizio Hyperscale
L'architettura del livello di servizio Hyperscale è descritta in Architettura delle funzioni distribuite.
Il modello di disponibilità in Hyperscale include quattro livelli:
- Un livello di calcolo senza stato che esegue i processi del motore di database e contiene solo dati temporanei e memorizzati nella cache, ad esempio la cache RBPEX non coprente e i database
tempdbemodelecc. nell'unità SSD collegata, e cache dei piani, pool di buffer e pool columnstore in memoria. Questo livello senza stato include la replica di calcolo primaria e, facoltativamente, una serie di repliche di calcolo secondarie che possono fungere da destinazioni di failover. - Livello di archiviazione senza stato formato da server di pagine. Questo livello è il motore di archiviazione distribuito per i processi del motore di database in esecuzione nelle repliche di calcolo. Ogni server di pagine contiene solo dati temporanei e memorizzati nella cache, ad esempio la cache RBPEX coprente nell'unità SSD collegata, e le pagine di dati memorizzate nella cache in memoria. Ogni server di pagine dispone di un server di pagine associato in una configurazione attiva-attiva per garantire il bilanciamento del carico, la ridondanza e la disponibilità elevata.
- Livello di archiviazione del log delle transazioni con stato formato dal nodo di calcolo che esegue il processo del servizio di log, dalla zona di destinazione del log delle transazioni e dall'archiviazione a lungo termine del log delle transazioni. La zona di destinazione e l'archiviazione a lungo termine usano Archiviazione di Azure, che offre disponibilità e ridondanza per il log delle transazioni, garantendo la durabilità dei dati per le transazioni di cui è stato eseguito il commit.
- Livello di archiviazione dati con stato con i file di database (.mdf/.ndf) archiviati in Archiviazione di Azure e aggiornati dai server di pagine. Questo livello usa le funzionalità di disponibilità e ridondanza dei dati di Archiviazione di Azure. Garantisce che ogni pagina in un file di dati venga mantenuta anche se i processi in altri livelli di arresto anomalo dell'architettura Hyperscale o se i nodi di calcolo hanno esito negativo.
I nodi di calcolo in tutti i livelli Hyperscale vengono eseguiti in Service Fabric di Azure, che controlla l'integrità di ogni nodo ed esegue i failover sui nodi integri disponibili, se necessario.
Per maggiori informazioni sulla disponibilità elevata in Hyperscale, vedere Disponibilità elevata del database in Hyperscale.
Disponibilità elevata tramite ridondanza della zona
La disponibilità con ridondanza della zona garantisce che i dati vengano distribuiti in tre zone di disponibilità di Azure nell'area primaria. Ogni zona di disponibilità è una posizione fisica separata con alimentazione, raffreddamento e rete indipendenti.
La disponibilità con ridondanza della zona è disponibile per i database nei livelli di servizio Business Critical, Utilizzo generico e Hyperscale del modello di acquisto basato su vCore e solo nel livello di servizio Premium del modello di acquisto basato su DTU - i livelli di servizio Basic e Standard non supportano la ridondanza della zona.
Anche se ogni livello di servizio implementa la ridondanza della zona in modo diverso, tutte le implementazioni garantiscono un obiettivo del punto di ripristino (RPO) senza perdita di dati di cui è stato eseguito il commit al failover.
Livello di servizio Utilizzo generico
La configurazione con ridondanza della zona per il livello di servizio per Utilizzo generico è disponibile sia per il calcolo serverless che per quello con provisioning per i database nel modello di acquisto vCore. Questa configurazione usa le Zone di disponibilità di Azure per replicare i database tra più posizioni fisiche all'interno di un'area di Azure. Selezionando la ridondanza della zona, è possibile rendere i database singoli e i pool elastici serverless nuovi ed esistenti e con provisioning per utilizzo generico resilienti a una serie di errori molto più ampia, comprese le interruzioni irreversibili dei data center, senza alcuna modifica della logica dell'applicazione.
La configurazione con ridondanza della zona per un livello Utilizzo generico consiste in due livelli:
- Un livello di dati con stato con i file di database (.mdf/.ldf) archiviati in ZRS (archiviazione con ridondanza della zona). Usando la ZRS, i dati e i file di log vengono copiati in modo sincrono in tre zone di disponibilità di Azure isolate fisicamente.
- Livello di calcolo senza stato che esegue il processo di sqlservr.exe e contiene solo dati temporanei e memorizzati nella cache, ad esempio i database
tempdbemodelnell'unità SSD collegata e la cache dei piani, il pool di buffer e il pool columnstore in memoria. Il nodo senza stato è gestito da Service Fabric di Azure che inizializza il processo sqlservr.exe, controlla l'integrità del nodo e, se necessario, esegue il failover in un altro nodo. Per i database serverless con ridondanza della zona e con provisioning per utilizzo generico, i nodi con capacità di riserva sono facilmente disponibili in altri zone di disponibilità per il failover.
La versione con ridondanza della zona dell'architettura a disponibilità elevata per il il livello di servizio Utilizzo generico è illustrata nel diagramma seguente:
Quando si configurano i database per Utilizzo generico con ridondanza della zona, tenere presente quanto segue:
- Per il livello Utilizzo generico, la configurazione con ridondanza della zona è disponibile a livello generale nelle aree seguenti:
- (Africa) Africa meridionale e settentrionale
- (Asia Pacifico) Australia orientale
- (Asia Pacifico) Asia orientale
- (Asia Pacifico) Giappone orientale
- (Asia Pacifico) Corea centrale
- (Asia Pacifico) Asia sud-orientale
- (Asia Pacifico) India centrale
- (Asia Pacifico) Cina settentrionale 3
- (Asia Pacifico) Emirati Arabi Uniti settentrionali
- (Europa) Francia centrale
- (Europa) Germania centro-occidentale
- (Europa) Italia settentrionale
- (Europa) Europa settentrionale
- (Europa) Norvegia orientale
- (Europa) Polonia centrale
- (Europa) Europa occidentale
- (Europa) Regno Unito meridionale
- (Europa) Svizzera settentrionale
- (Europa) Svezia centrale
- (Medio Oriente) Israele centrale
- (Medio Oriente) Qatar Centrale
- (America del Nord) Canada centrale
- (America del Nord) Stati Uniti orientali
- (America del Nord) Stati Uniti orientali 2
- (America del Nord) Stati Uniti centro-meridionali
- (America del Nord) Stati Uniti occidentali 2
- (America del Nord) Stati Uniti occidentali 3
- (America del Sud) Brasile meridionale
- Per la disponibilità con ridondanza della zona, la scelta di una finestra di manutenzione diversa da quella predefinita è attualmente disponibile nelle aree selezionate.
- La configurazione con ridondanza della zona è disponibile solo nel database SQL quando viene selezionato l'hardware della serie standard (Gen5).
- La ridondanza della zona non è disponibile per i livelli di servizio Basic e Standard nel modello di acquisto DTU.
Livelli di servizio Business Critical/Premium
Quando la ridondanza della zona è abilitata per il livello di servizio Premium o Business Critical, le repliche vengono inserite in zone di disponibilità diverse nella stessa area. Per eliminare un singolo punto di guasto, viene duplicato anche l'anello di controllo in più zone come tre anelli gateway. Il routing a un anello di gateway specifico è controllato da Gestione traffico di Azure. Poiché la configurazione con ridondanza della zona nei livelli di servizio Premium o Business Critical usa le repliche esistenti per posizionare in zone di disponibilità diverse, è possibile abilitarla senza costi aggiuntivi. Se si seleziona una configurazione con ridondanza della zona, è possibile rendere i database Premium o Business Critical e i pool elastici resilienti a una serie molto più ampia di errori, incluse le interruzioni irreversibili del data center, senza modifiche della logica dell'applicazione. È anche possibile convertire qualsiasi pool elastico o database Premium o Business Critical alla configurazione con ridondanza della zona.
La versione con ridondanza della zona dell'architettura a disponibilità elevata è illustrata nel diagramma seguente:
Quando si configurano i database Premium o Business Critical con ridondanza della zona, tenere presente quanto segue:
- Per informazioni aggiornate sulle aree che supportano i database con ridondanza della zona, vedere Supporto dei servizi in base all'area.
- Per la disponibilità con ridondanza della zona, la scelta di una finestra di manutenzione diversa da quella predefinita è attualmente disponibile nelle aree selezionate.
Livello di servizio Hyperscale
È possibile configurare la ridondanza della zona per i database nel livello di servizio Hyperscale. Per maggiori informazioni, vedere Creare un database Hyperscale con ridondanza della zona.
L'abilitazione di questa configurazione garantisce la resilienza a livello di zona tramite la replica tra zone di disponibilità per tutti i livelli Hyperscale. Selezionando la ridondanza della zona, è possibile rendere i database Hyperscale resilienti a una serie di errori molto più ampia, comprese le interruzioni irreversibili dei data center, senza alcuna modifica della logica dell'applicazione. Tutte le aree di Azure con zone di disponibilità supportano il database Hyperscale con ridondanza della zona. Il supporto della ridondanza della zona per l'hardware PRMS Hyperscale e MOPRMS è disponibile nelle aree elencate qui.
La disponibilità con ridondanza della zona è supportata sia nei database autonomi Hyperscale che nei pool elastici Hyperscale. Per maggiori informazioni, vedere Pool elastici Hyperscale.
Il diagramma seguente illustra l'architettura sottostante per i database Hyperscale con ridondanza della zona:
Tenere presente le limitazioni seguenti:
La configurazione con ridondanza della zona può essere specificata solo durante la creazione del database. Questa impostazione non può essere modificata dopo il provisioning della risorsa. Usare copia del database, ripristino temporizzato o creare una replica geografica per aggiornare la configurazione con ridondanza della zona per un database Hyperscale esistente. Quando si usa una di queste opzioni di aggiornamento, se il database di destinazione si trova in un'area diversa dall'origine o se la ridondanza dell'archiviazione di backup del database dalla destinazione è diversa dal database di origine, l'operazione di copia avrà una dimensione pari a quella dell'operazione di dati.
Per la disponibilità con ridondanza della zona, la scelta di una finestra di manutenzione diversa da quella predefinita è attualmente disponibile nelle aree selezionate.
Attualmente non è possibile specificare la ridondanza della zona durante la migrazione di un database a Hyperscale usando il portale di Azure. È tuttavia possibile specificare la ridondanza della zona usando PowerShell di Azure, l'interfaccia della riga di comando di Azure o l'API REST durante la migrazione di un database esistente da un altro livello di servizio del database SQL di Azure a Hyperscale. Di seguito un esempio dell'interfaccia della riga di comando di Azure:
az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`Per abilitare la configurazione con ridondanza della zona per Hyperscale, è necessaria almeno una replica di calcolo a disponibilità elevata e l'uso dell'archiviazione di backup con ridondanza della zona o geografica.
Disponibilità con ridondanza della zona del database
Nel database SQL di Azure, un server è un costrutto logico che funge da punto di amministrazione centrale per una raccolta di database. A livello di server, è possibile amministrare account di accesso, metodo di autenticazione, regole del firewall, regole di controllo, criteri di rilevamento delle minacce e gruppi di failover. I dati correlati ad alcune di queste funzionalità, ad esempio gli account di accesso e le regole del firewall, vengono archiviati nel database master. Analogamente, anche i dati per alcune DMV, ad esempio sys.resource_stats, vengono archiviati nel database master.
Quando un database con una configurazione con ridondanza della zona viene creato in un server logico, anche il database master associato al server viene automaticamente reso con ridondanza della zona. Ciò garantisce che in un'interruzione di zona le applicazioni che usano il database rimangano invariate perché le funzionalità dipendenti dal database master, ad esempio gli account di accesso e le regole del firewall, sono ancora disponibili. Rendere ridondante la zona del database master è un processo asincrono e richiederà del tempo per essere completato in background.
Quando nessuno dei database in un server è con ridondanza della zona o quando si crea un server vuoto, il database master associato al server è senza ridondanza della zona.
È possibile usare PowerShell di Azure o l'interfaccia della riga di comando di Azure o l'API REST per controllare la proprietà ZoneRedundant per il database master:
Usare il comando di esempio seguente per controllare il valore della proprietà "ZoneRedundant" per il database master.
Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"
Testare la resilienza degli errori dell'applicazione
La disponibilità elevata è una parte fondamentale della piattaforma del database SQL che funziona in modo trasparente per l'applicazione di database. Tuttavia, è plausibile voler testare il modo in cui le operazioni di failover automatico avviate durante gli eventi pianificati o non pianificati influirebbero su un'applicazione prima di distribuirla nella produzione. È possibile attivare manualmente un failover chiamando un'API speciale per riavviare un database o un pool elastico. Nel caso di un database o pool elastico serverless o con provisioning per utilizzoo generico con ridondanza della zona, la chiamata API comportebbe il reindirizzamento delle connessioni client al nuovo database primario in una zona di disponibilità diversa dalla zona di disponibilità del database primario precedente. Oltre a testare l'impatto del failover sulle sessioni di database esistenti, è anche possibile verificare se ciò modifica le prestazioni end-to-end a causa di modifiche alla latenza di rete. Poiché l'operazione di riavvio è intrusiva e un numero elevato di esse potrebbe comportare stress per la piattaforma, è consentita una sola chiamata di failover ogni 15 minuti per ogni database o pool elastico.
Per maggiori informazioni sulla disponibilità elevata e ripristino di emergenza del database SQL di Azure, vedere l'Elenco di controllo su disponibilità elevata/ripristino di emergenza.
È possibile avviare un failover usando PowerShell, l'API REST o l'interfaccia della riga di comando di Azure:
| Tipo di distribuzione | PowerShell | API REST | Interfaccia della riga di comando di Azure |
|---|---|---|---|
| Database | Invoke-AzSqlDatabaseFailover | Failover del database | az rest può essere usato per richiamare una chiamata API REST dall'interfaccia della riga di comando di Azure |
| Pool elastico | Invoke-AzSqlElasticPoolFailover | Failover di pool elastici | az rest può essere usato per richiamare una chiamata API REST dall'interfaccia della riga di comando di Azure |
Importante
Il comando Failover non è disponibile per le repliche secondarie leggibili dei database Hyperscale.
Conclusione
Il database SQL di Azure offre una soluzione a disponibilità elevata predefinita pienamente integrata con la piattaforma Azure. Esso è altamente dipendente da Service Fabric per il rilevamento degli errori e il ripristino, da Archiviazione BLOB di Azure per la protezione dati e da Zone di disponibilità per una tolleranza di errore più elevata. Inoltre, il database SQL usa la tecnologia dei Gruppi di disponibilità Always On di SQL Server per la sincronizzazione dei dati e il failover. La combinazione di queste tecnologie consente alle applicazioni di ottenere tutti i vantaggi di un modello di archiviazione mista e supporta i contratti di servizio più esigenti.
Contenuto correlato
Per altre informazioni, vedere: