La connettività dello storage alle IFI UCS locali e ai server blade viene fornita dagli switch Nexus del sito locale. Attraverso la connettività dello switch Nexus tra i siti, è possibile accedere allo storage anche dai blade server UCS remoti. La figura e la tabella seguenti mostrano il diagramma di connettività dello storage e un elenco di connessioni per i controller dello storage in ogni sito.

Due porte fisiche su ciascun controller di storage sono collegate a ciascuno switch Nexus per l'aggregazione della larghezza di banda e la ridondanza per questa convalida. Queste quattro connessioni partecipano a una configurazione di gruppo di interfacce sullo storage. Le porte corrispondenti sugli switch Nexus partecipano a un VPC per l'aggregazione e la resilienza del collegamento.

I protocolli di gestione in-band, inter-cluster e storage dei dati NFS/iSCSI utilizzano VLAN. Le porte VLAN vengono create sul gruppo di interfacce per separare i diversi tipi di traffico. Le interfacce logiche (LIF) per le rispettive funzioni vengono create sulla parte superiore delle porte VLAN corrispondenti. La figura seguente mostra la relazione tra connessioni fisiche, gruppi di interfacce, porte VLAN e interfacce logiche.

NetApp consiglia di implementare l'avvio SAN per i server Cisco UCS nella soluzione FlexPod. L'implementazione dell'avvio SAN consente di proteggere in modo sicuro il sistema operativo all'interno del sistema di storage NetApp, fornendo migliori performance e flessibilità. Per questa soluzione, è stato validato l'avvio SAN iSCSI.

La figura seguente mostra la connettività per l'avvio SAN iSCSI del server Cisco UCS dallo storage NetApp. Nell'avvio SAN iSCSI, a ciascun server Cisco UCS vengono assegnate due vNIC iSCSI (una per ciascun fabric SAN) che forniscono una connettività ridondante dal server fino allo storage. Le porte di storage Ethernet 10/25-G collegate agli switch Nexus (in questo esempio e1a, e1b, e1c e e1d) sono raggruppate in modo da formare un gruppo di interfacce (ifgrp) (in questo esempio, a0a). Le porte VLAN iSCSI vengono create su ifgrp e le LIF iSCSI vengono create sulle porte VLAN iSCSI.

Ogni LUN di boot iSCSI viene mappato al server che si avvia da esso attraverso le LIF iSCSI associando il LUN di boot con i nomi iSCSI qualificati del server (IQN) nel relativo igroup di boot. L'igroup di boot del server contiene due IQN, uno per ogni fabric vNIC/SAN. Questa funzione consente solo al server autorizzato di accedere al LUN di avvio creato appositamente per tale server.

I peer del cluster ONTAP comunicano tramite le LIF dell'intercluster. Utilizzando Gestione di sistema di ONTAP per i due cluster, è possibile creare le LIF di intercluster necessarie nel pannello protezione > Panoramica.

Per unire i due cluster, completare i seguenti passaggi:

Il mediatore ONTAP stabilisce un quorum per i cluster ONTAP in una relazione SM-BC. Coordina il failover automatizzato quando viene rilevato un guasto e aiuta a evitare scenari di split-brain quando ogni cluster tenta contemporaneamente di stabilire il controllo come cluster primario.

Prima di installare il mediatore ONTAP, consultare "Installare o aggiornare il servizio di supporto ONTAP" Pagina per i prerequisiti, le versioni di Linux supportate e le procedure per l'installazione sui vari sistemi operativi Linux supportati.

Una volta installato il mediatore ONTAP, è possibile aggiungere il certificato di sicurezza del mediatore ONTAP ai cluster ONTAP e configurare il mediatore ONTAP nel pannello protezione > Panoramica di Gestione sistema. La seguente schermata mostra la GUI di configurazione del mediatore ONTAP.

Dopo aver fornito le informazioni necessarie, il mediatore ONTAP configurato viene visualizzato nel pannello protezione > Panoramica di Gestione sistema.

Un gruppo di coerenza offre una garanzia di coerenza dell'ordine di scrittura per un workload dell'applicazione che copre un insieme di volumi specificati. Per ONTAP 9.10.1, ecco alcune delle limitazioni e delle limitazioni più importanti.

Per ulteriori informazioni, consultare la documentazione di ONTAP SM-BC sul "restrizioni e limitazioni".

Per la configurazione della convalida, è stato utilizzato Gestore di sistema di ONTAP per creare i gruppi di coerenza per proteggere le LUN di avvio ESXi e le LUN degli archivi dati condivisi per entrambi i siti. La finestra di dialogo per la creazione di gruppi di coerenza è accessibile selezionando protezione > Panoramica > protezione per la business continuity > Proteggi gruppo di coerenza. Per creare un gruppo di coerenza, fornire i volumi di origine, il cluster di destinazione e le informazioni sulla macchina virtuale di storage di destinazione necessari per la creazione.

Nella tabella seguente sono elencati i quattro gruppi di coerenza creati e i volumi inclusi in ciascun gruppo di coerenza per il test di convalida.

Una volta creati, i gruppi di coerenza vengono visualizzati sotto le rispettive relazioni di protezione nel sito A e nel sito B.

Questa schermata mostra le relazioni dei gruppi di coerenza nel sito A.

Questa schermata mostra le relazioni dei gruppi di coerenza nel sito B.

Questa schermata mostra i dettagli delle relazioni del gruppo di coerenza per il gruppo cg_infra_datastore_b.

Una volta creati i gruppi di coerenza, SnapMirror sincronizza i volumi di origine e di destinazione in modo che i dati possano essere sempre sincronizzati. I volumi di destinazione del sito remoto riportano i nomi dei volumi con il _dest end (fine destinazione). Ad esempio, per il volume esxi_a nel cluster del sito A, nel sito B è presente un volume esxi_a_dest Data Protection (DP) corrispondente

Questa schermata mostra le informazioni sul volume per il sito A.

Questa schermata mostra le informazioni sul volume per il sito B.

Per facilitare il failover trasparente delle applicazioni, è necessario mappare anche i LUN SM-BC mirrorati agli host dal cluster di destinazione. In questo modo, gli host possono visualizzare correttamente i percorsi verso le LUN dai cluster di origine e di destinazione. Il igroup show e. lun show Le uscite per il sito A e il sito B vengono acquisite nelle due schermate seguenti. Con le mappature create, ogni host ESXi nel cluster vede il proprio LUN di avvio SAN come ID 0 e tutte e quattro le LUN degli archivi dati iSCSI condivisi.

Questa schermata mostra la mappatura di igroups e LUN host per un cluster del sito A.

Questa schermata mostra la mappatura di igroups e LUN host per il cluster del sito B.

"Successivo: Convalida della soluzione - virtualizzazione."