Skip to main content
Enterprise applications
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Disaster recovery per Microsoft SQL Server con ONTAP

Collaboratori

I database e le infrastrutture applicative aziendali spesso richiedono la replica per proteggersi da disastri naturali o interruzioni impreviste del business, con tempi di inattività minimi.

La funzionalità di replica del gruppo di disponibilità always-on di SQL Server può essere un'opzione eccellente, mentre NetApp offre la possibilità di integrare la protezione dei dati con la funzionalità always-on. In alcuni casi, tuttavia, è consigliabile prendere in considerazione la tecnologia di replica ONTAP. Le opzioni di replica di ONTAP, tra cui MetroCluster e SnapMirror, possono scalare meglio con un impatto minimo sulle performance, proteggere i dati non SQL e generalmente fornire una soluzione di replica e DR con l'infrastruttura completa.

SnapMirror asincrono

La tecnologia SnapMirror offre una soluzione aziendale asincrona rapida e flessibile per la replica dei dati su LAN e WAN. La tecnologia SnapMirror trasferisce solo i blocchi di dati modificati a destinazione dopo la creazione del mirror iniziale, riducendo in modo significativo i requisiti di larghezza di banda di rete.

Di seguito sono riportati alcuni consigli su SnapMirror per SQL Server:

  • In caso di utilizzo di CIFS, la SVM di destinazione deve appartenere allo stesso dominio Active Directory del quale fa parte la SVM di origine, in modo da non interrompere le liste per il controllo degli accessi (ACL) archiviate nei file NAS durante il ripristino in caso di disastro.

  • L'utilizzo di nomi di volumi di destinazione identici ai nomi di volumi di origine non è necessario, ma può semplificare la gestione del processo di montaggio dei volumi di destinazione nella destinazione. Se viene utilizzato CIFS, occorre rendere identico il namespace NAS di destinazione nei percorsi e nella struttura delle directory al namespace di origine.

  • Per motivi di coerenza, non pianificare gli update SnapMirror dai controller. Attiva invece gli update di SnapMirror da SnapCenter per aggiornare SnapMirror al termine del backup completo o del log.

  • Distribuire volumi che contengono dati SQL Server tra diversi nodi nel cluster per consentire a tutti i nodi del cluster di condividere l'attività di replica di SnapMirror. Questa distribuzione ottimizza l'utilizzo delle risorse dei nodi.

Per ulteriori informazioni su SnapMirror, vedere "TR-4015: Guida alle Best practice e alla configurazione di SnapMirror per ONTAP 9".