Configuration du cluster pour la haute disponibilité dans un environnement GDPC

La procédure de configuration détaillée dans cette rubrique est spécifique au cluster géographiquement dispersé (GDPC) Db2® pureScale® (GDPC). Cette procédure doit être réalisée après la création de l'instance initiale ou toute opération ultérieure de réparation ou de suppression pour le modèle de ressource ou le domaine homologue.

1. Mettez à jour les délais d'attente en cas d'incident de stockage.
   1. Vérifiez qu'en cas de défaillance du contrôleur de stockage ou du site, une erreur est renvoyée rapidement à Spectrum Scale en définissant les paramètres de pilote de périphérique appropriés. Notez que ces paramètres sont différents en fonction des pilotes de périphérique. Lisez la documentation du contrôleur de stockage ou consultez un expert en stockage sur le site pour vérifier que les erreurs sont renvoyées dans les 20 secondes.
      Par exemple, sous DS8K avec la valeur par défaut AIX® SDDPCM, les mises à jour sont les suivantes:

      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. Vérifiez que les attributs ont été correctement définis sur chaque ordinateur :

      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. Mettez à jour les délais d'attente des ressources.
   En raison des exigences de reprise de la réplication Spectrum Scale , les temps de reprise pour certains échecs peuvent être légèrement plus longs dans un environnement de cluster Db2 pureScale (GDPC) géographiquement dispersé que dans un environnement Db2 pureScale monosite. Pour tenir compte de cela, certaines ressources de l' IBMTivoli® System Automation for Multiplatforms doivent voir leurs valeurs de délai d'expiration ajustées. Pour régler les délais d'attente, exécutez les commandes suivantes en tant que superutilisateur sur un hôte quelconque du 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

   Pour afficher les délais d'attente mis à jour, exécutez les commandes suivantes en tant que superutilisateur :

   lsrsrc -t IBM.Application Name MonitorCommandTimeout CleanupCommandTimeout

3. Pour créer des ressources de résilience du réseau pour un réseau Ethernet privé, exécutez :

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

   Sur chaque hôte, vérifiez la configuration de la résilience du réseau en exécutant :

   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.