Procedura TEST DR con Site Recovery Manager per mission critical applications: Cluster Microsoft per MS SQL

Posted on 7 dicembre 2011 di

0


Alquanto laborioso è testare il Vostro ambiente Cluster Microsoft in ambito di DR anche se su VMWare e Netapp. Sicuramente è più facile testarne la funzionalità relizzando un vero recovery per motivi legati principalemente alle vlan ed alle raggiungibilità dei dns per i servizi. Inoltre se avete introdotto Site Recovery Manager successivamente all’esistenza del vostro cluster, non avrete implementato e migrato a soluzioni tipo Snapmanager per SQL…che vi faciliterebbe nella mappatura delle LUN dei volumi RDM.

La condizione in esame è che voi abbiate le LUN snapmirrorate ma non il volume vmfs dei pointer vmware alle LUN stesse (tanto è inutile mirrorarlo poichè le signatures delle LUN cambiano da un sito all’altro).

Premesso quanto sopra, ecco come testare senza un vero recovery il tutto.

TEST DR con Site Recovery Manager vmware/netapp per mission critical applications >> Cluster Microsoft

N.B. Cluster Microsoft in ambiente virtuale preesistente (NO utilizzo di snapmanager per sql)

  1. Creato un datastore vmfs (non nfs) per il cluster DR , che servirà per i puntamenti alle lun snapmirrorate così configurato (aggiunto al cluster DR)
  2. Dettacchati dal recovery plan i dischi RDM dei nodi, vengono solo restorati automaticamente quelli di sistema (Potection Group)
  3.  Impostati i nodi sul non accendersi automaticamente nel recovery plan
  4. Startando il piano di recovery, il cluster microsoft viene ripristinato ma non acceso. I dischi sono solo quelli di sistema e non quorum e dischi RDM. Prestare attenzione alla lan di test: se volete far “parlare” i servizi tra loro dovrete metterli in uno stesso host esx.
  5. Creato un flexclone per il test  (in fase di dr il break del mirror renderebbe il volume con le lun per gli rdm disponibile direttamente) e mappate e  messe online le lun in esso presenti.
  6. Effettuato rescan datastore su vcenterdr e verificata esistenza lun, segnando il giusto ordine con cui devono essere mappati i dischi del cluster confrontandoli con quelli in produzione.
  7. Aggiunti i dischi rdm al primo nodo del cluster seguendo il giusto ordine.
  8. Il domain controller deve però essere raggiungibile dalla lan di test quindi modificare ip del dc e dns del nodo1 in caso di necessità.

TEST ESEGUITO CON ESITO POSITIVO: Cluster service e database partono correttamente sul nodo1. Basta fare le stesse modifiche sul nodo2 ed il cluster è attivo sull’ambiente di test.

Annunci