Configurazione del cluster per l'alta disponibilità in un ambiente GDPC

La procedura di configurazione descritta in questo argomento è specifica per il cluster geograficamente disperso (GDPC) Db2® pureScale® (GDPC). Questa procedura deve essere eseguita dopo la creazione dell'istanza iniziale o dopo qualsiasi operazione di riparazione o cancellazione successiva per il modello di risorsa o il dominio peer.

1. Aggiornamento tempo di errore di archiviazione.
   1. Assicurarsi che nel caso di controller di archiviazione o errore del sito, venga restituito rapidamente un errore a Spectrum Scale impostando i relativi parametri del driver del dispositivo. Da notare che i parametri rilevanti differiscono per i diversi driver di dispositivi. Controllare la documentazione del controller di archiviazione o consultare un esperto di archiviazione sul sito per garantire che gli errori vengano restituiti entro 20 seconds minuti.
      Ad esempio, su DS8K utilizzando il valore predefinito AIX® SDDPCM, gli aggiornamenti sono:

      chdev -l hdiskX -a 'cntl_delay_time=20 cntl_hcheck_int=2' –P
      
      repeat for every hdiskx 
      
      chdev -1 fscsiY -a dyntrk=yes -a fc_err_recov=fast_fail -P
      
      repeat for every fscsiY adapter
      
      reboot the host
      
      repeat chdevs for every host in the cluster

   2. Verificare che gli attributi siano stati impostati correttamente su ogni computer:

      root> lsattr -El fscsi0  
      attach          switch     How this adapter is CONNECTED           False
      dyntrk          yes        Dynamic Tracking of FC Devices          True
      fc_err_recov    fast_fail  FC Fabric Event Error RECOVERY Policy   True
      
      root> lsattr -El hdiskA1
      PCM             PCM/friend/otherapdisk  Path Control Module              False
      PR_key_value    none                    Persistent Reserve Key Value     True
      Algorithm       fail_over               Algorithm                        True
      autorecovery    no                      Path/Ownership Autorecovery      True
      clr_q           no                      Device CLEARS its Queue on error True
      cntl_delay_time 20                      Controller Delay Time            True
      cntl_hcheck_int 2                       Controller Health Check Interval True

2. Aggiorna il time - out delle risorse.
   A causa dei requisiti di ripristino della replica Spectrum Scale , i tempi di ripristino per alcuni errori possono essere leggermente più lunghi in un ambiente GDPC ( Db2 pureScale cluster) geograficamente disperso rispetto a un ambiente Db2 pureScale a sito singolo. Per ovviare a questo problema, è necessario modificare i valori di timeout di alcune risorse dell' IBMTivoli® System Automation for Multiplatforms. Per regolare i time - out, eseguire i seguenti comandi una volta come root su uno qualsiasi degli host presenti nel cluster:

   	root> export CT_MANAGEMENT_SCOPE=2;
   	# Update 2 member-specific timeouts.  For these, the resource
   	# names to update will look like db2_<instance>_<member_id>-rs.
   	# In this example we have members 0-4, and our instance name is
   	# db2inst1:
   	root> chrsrc -s "Name like 'db2_db2inst1_%-rs'" IBM.Application 		CleanupCommandTimeout=600
   	root> chrsrc -s "Name like 'db2_db2inst1_%-rs'" IBM.Application 		MonitorCommandTimeout=600
   
   	# In the next two commands, replace ‘db2inst1’ with your instance
   	# owning ID
   	root> chrsrc -s "Name like 'primary_db2inst1_900-rs'" 			IBM.Application CleanupCommandTimeout=600
   	root> chrsrc -s "Name like 'ca_db2inst1_0-rs'" IBM.Application 		CleanupCommandTimeout=600
   
   	# In the following commands, replace ‘db2inst1’ with your
   	# instance owning ID, and repeat for each host in your cluster,
   	# except the tiebreaker host T
   	root> chrsrc -s "Name like 'instancehost_db2inst1_hostA1'" 			IBM.Application MonitorCommandTimeout=600
   	root> chrsrc -s "Name like 'instancehost_db2inst1_hostA2'" 			IBM.Application MonitorCommandTimeout=600
   	root> chrsrc -s "Name like 'instancehost_db2inst1_hostA3'" 			IBM.Application MonitorCommandTimeout=600
   	root> chrsrc -s "Name like 'instancehost_db2inst1_hostB1'" 			IBM.Application MonitorCommandTimeout=600
   	root> chrsrc -s "Name like 'instancehost_db2inst1_hostB2'" 			IBM.Application MonitorCommandTimeout=600
   	root> chrsrc -s "Name like 'instancehost_db2inst1_hostB3'" 			IBM.Application MonitorCommandTimeout=600
   
   	# In the last two commands, replace ‘db2inst1’ with your instance
   	# owning ID, and ‘hostA3’ with the hostname of the first CF added
   	# to the cluster, and ‘hostB3’ with the hostname of the second
   	# CF added to the cluster.
   	root> chrsrc -s "Name like 'cacontrol_db2inst1_128_hostA3'" 		IBM.Application MonitorCommandTimeout=600
   	root> chrsrc -s "Name like 'cacontrol_db2inst1_129_hostB3'" 		IBM.Application MonitorCommandTimeout=600

   Per mostrare i time - out aggiornati, eseguire il seguente comando come root:

   lsrsrc -t IBM.Application Name MonitorCommandTimeout CleanupCommandTimeout

3. Per creare risorse di resilienza di rete per la gestione della rete Ethernet privata:

   root> /home/db2inst1/sqllib/bin/db2cluster -cfs -repair -network_resiliency -all

   Su ogni host, verificare la configurazione di resilienza della rete eseguendo:

   root> /home/db2inst1/sqllib/bin/db2cluster -cfs -verify -network_resiliency 
   
   Sample output of successful verification:
   $ db2cluster -cfs -verify -network_resiliency
   Successfully verified configurations on local host.