/!\ en cas de vdoms activés : Les
commandes qui suivent sont entrées en mode “config global”
get system ha status <– Pour voir les
informations détaillées sur l’état du cluster ainsi que la raison de la
dernière bascule
Prim-FW (global)
# get sys ha status
HA Health Status: OK
Model: FortiGate-VM64-KVM
Mode: HA A-P
Group: 9
Debug: 0
Cluster Uptime: 14 days 5:9:44
Cluster state change time: 2019-06-13 14:21:15
Raison
des dernières bascules:
<2019/06/13 14:21:15> FGVMXXXXXXXXXX44 is
selected as the master because it has the largest value of uptime.
<2019/06/13 14:15:46> FGVMXXXXXXXXXX46 is
selected as the master because it has the largest value of uptime.
<2019/06/12 11:17:04> FGVMXXXXXXXXXX44 is
selected as the master because it has the largest value of override priority.
ses_pickup: enable, ses_pickup_delay=disable
override: disable
Vérifier la synchronisation de la configuration de chaque membre du cluster:
Prim-FW(global)#diag
sys ha checksum cluster
==================
FGVMXXXXXXXXXX44 ==================
is_manage_master()=1, is_root_master()=1
debugzone
global: c5 33 93 23 26 9f 4d 79 ed 5f 29 fa 7a 8c c9
10
root: d3 b5 fc 60 f3
f0 f0 d0 ea e4 a1 7f 1d 17 05 fc
Cust-A: 84 af 8f 23 b5 31 ca 32 c1 0b f2 76
d2 57 d1 bc
all: 04 ae 37 7e dc 84 aa a4 42 3d db 3c a2
09 b0 60
checksum
global: c5 33 93 23 26 9f 4d 79 ed 5f 29 fa 7a 8c c9
10
root: d3 b5 fc 60 f3
f0 f0 d0 ea e4 a1 7f 1d 17 05 fc
Cust-A: 84 af 8f 23 b5 31 ca 32 c1 0b f2 76
d2 57 d1 bc
all: 04 ae 37 7e dc 84 aa a4 42 3d db 3c a2
09 b0 60
==================
FGVMXXXXXXXXXX46 ==================
is_manage_master()=0, is_root_master()=0
debugzone
global: c5 33 93 23 26 9f 4d 79 ed 5f 29 fa 7a 8c c9
10
root: d3 b5 fc 60 f3 f0 f0 d0 ea e4
a1 7f 1d 17 05 fc
Cust-A: 84 af 8f 23 b5 31 ca 32 c1 0b f2 76
d2 57 d1 bc
all: 04 ae 37 7e dc 84 aa a4 42 3d db 3c a2
09 b0 60
checksum
global: c5 33 93 23 26 9f 4d 79 ed 5f 29 fa 7a 8c c9
10
root: d3 b5 fc 60 f3
f0 f0 d0 ea e4 a1 7f 1d 17 05 fc
Cust-A: 84 af 8f 23 b5 31 ca 32 c1 0b f2 76
d2 57 d1 bc
all: 04 ae 37 7e dc 84 aa a4 42 3d db 3c a2
09 b0 60
S’il n’y a pas de mismatch, la
configuration est synchronisée. Auquel cas, un problème de cluster remonté
via la GUI sera un bug d’affichage.
S’il y a un mismatch, voici comment voir où le mismatch se situe :
1.vérifier dans quelle grande partie de la conf le mismatch se trouve:
# diag sys ha checksum cluster
================== FGT1 =================
is_manage_master()=0, is_root_master()=0
debugzone
global: : 79 24 76 8a a8 03 9a 81 dc c4 3c f8 96 72 59 11
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92
all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f
checksum
global: : 79 24 76 8a a8 03 9a 81 dc c4 3c f8 96 72 59 11
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92
all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f
================== FGT2 ==================
is_manage_master()=1, is_root_master()=1
debugzone
global: 89 f2 f0 0b e8 eb 0d ee f8 55 8b 47 27 7a 27 1e
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92
all: a7 8d cc c7 32 b5 81 a2 55 49 52 21 57 f9 3c 3b
checksum
global: 89 f2 f0 0b e8 eb 0d ee f8 55 8b 47 27 7a 27 1e
root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92
all: a7 8d cc c7 32 b5 81 a2 55 49 52 21 57 f9 3c 3b
2. donc comme on le voit il y a une différence sur « global ». Il faut donc aller sur chaque membre du cluster et regarder plus en détail cette partie.
# diag sys ha checksum show <VDOM_NAME>
Par exemple:
# diag sys ha checksum show global
Donc ici (on peut changer de membre du cluster avec # exec ha manage <ID_membre_cluster> ou # exec ha manage <ID_membre_cluster> <login_admin> :
| FGT_1 #diag sys ha checksum show global system.global: d6c216d8449d75b2cd80110fa02a85e5 system.accprofile: 7df6f055a28e5d5216c4d2c2b3ee77d1 system.npu: 7df6f055a28e5d5216c4d2c2b3ee77d1 system.vdom-link: 7df6f055a28e5d5216c4d2c2b3ee77d1 wireless-controller.global: 7df6f055a28e5d5216c4d2c2b3ee77d1 wireless-controller.vap: cda65c180c25050eb83398fa23ab7fd1 system.switch-interface: cda65c180c25050eb83398fa23ab7fd1 system.interface: 56f2362fd69f51a2b6fc22a008c0c755 system.password-policy: 56f2362fd69f51a2b6fc22a008c0c755 system.sms-server: 56f2362fd69f51a2b6fc22a008c0c755 system.fsso-polling: af9c2b4f63e40551e33eabd64436fb3e system.ha: ddfeff2ae037f615fbd83110169b70d2 | FGT_2 #diag sys ha checksum show global system.global: d6c216d8449d75b2cd80110fa02a84e5 system.accprofile: 7df6f055a28e5d5216c4d2c2b3ee77d1 system.npu: 7df6f055a28e5d5216c4d2c2b3ee77d1 system.vdom-link: 7df6f055a28e5d5216c4d2c2b3ee77d1 wireless-controller.global: 7df6f055a28e5d5216c4d2c2b3ee77d1 wireless-controller.vap: cda65c180c25050eb83398fa23ab7fd1 system.switch-interface:cda65c180c25050eb83398fa23ab7fd1 system.interface: 56f2362fd69f51a2b6fc22a008c0c755 system.password-policy: 56f2362fd69f51a2b6fc22a008c0c755 system.sms-server: 56f2362fd69f51a2b6fc22a008c0c755 system.fsso-polling: af9c2b4f63e40551e33eabd64436fb3e system.ha: ddfeff2ae037f615fbd83110169b70d2 |
On voit ici que c’est dans « admin settings »
3.on peut même aller encore plus loin avec :
# diag sys ha checksum show global <object.name>
Par exemple:
| FGT1 #diag sys ha checksum show global system.global [admin-server-cert]=’Fortinet_Factory’: f9d23d8f459c415d1742630c4c0cd99d [admintimeout]=’480′: 8041fc04d56bd268f40fafc37b5fd078 [alias]=’FGVM010000087496′: a47b05f1b3646431fb078469cfca3225 [fgd-alert-subscription]=’advisory latest-threat’: e15ed9aae8a488d992774994c36566b1 [timezone]=’04’: 5af081b7089c3f69917ea509f3cb5e6d | FGT2 #diag sys ha checksum show global system.global [admin-server-cert]=’Fortinet_Factory’: f9d23d8f459c415d1742630c4c0cd99d [admintimeout]=’380′: 8041fc04d56bd268f40fafc37b5fd079 [alias]=’FGVM010000087496′: a47b05f1b3646431fb078469cfca3225 [fgd-alert-subscription]=’advisory latest-threat’: e15ed9aae8a488d992774994c36566b1 [timezone]=’04’: 5af081b7089c3f69917ea509f3cb5e6d |
4. Donc l’admin timeout est différent. Un changement de conf sur le membre qui a une mauvaise valeur corrigera le souci.
A noter que n’importe quel changement déclenchera une nouvelle synchro de configuration.
A ce stade, on pourra refaire une synchro de configuration avec la commande déjà plus haut :
# diag sys ha checksum cluster
================== FGT1 =================
is_manage_master()=0, is_root_master()=0
debugzone
global: : 79 24 76
8a a8 03 9a 81 dc c4 3c f8 96 72 59 11
root: cf 85 55 fe a7 e5 7c 6f a6
88 e5 a9 ea 26 e6 92
all: f4 62 b2 ce 81 9a c9 04 8f 67
07 ec a7 44 60 1f
checksum
global: : 79 24 76
8a a8 03 9a 81 dc c4 3c f8 96 72 59 11
root: cf 85 55 fe a7 e5 7c 6f a6
88 e5 a9 ea 26 e6 92
all: f4 62 b2 ce 81 9a c9 04 8f 67
07 ec a7 44 60 1f
==================
FGT2 ==================
is_manage_master()=1, is_root_master()=1
debugzone
global: : 79 24 76
8a a8 03 9a 81 dc c4 3c f8 96 72 59 11
root: cf 85 55 fe a7 e5 7c 6f a6
88 e5 a9 ea 26 e6 92
all: f4 62 b2 ce 81 9a c9 04 8f 67
07 ec a7 44 60 1f
checksum
global: : 79 24 76
8a a8 03 9a 81 dc c4 3c f8 96 72 59 11
root: cf 85 55 fe a7 e5 7c 6f a6
88 e5 a9 ea 26 e6 92
all: f4 62 b2 ce 81 9a c9 04 8f 67
07 ec a7 44 60 1f
En cas de problèmes de mismatch complémentaire, tenter de recalculer les checksums:
#diagnose sys ha checksum recalculate [<vdom-name> | global]
En complément, pour diagnostiquer les
problèmes de HA complémentaires :
diag debug app hasync 255
diag debug enable
execute ha synchronize start
diagnose debug application hatalk -1
Lancer les commandes suivantes pour vérifier les mismatches :
diag debug config-error-log read <– (1)
diag hardware device disk <– (2)
show sys storage <– (2)
show wanopt storage <– (2)
- Pour vérifier les lignes de configuration qui ont mal été comprises par le FortiGate
- La taille des disques doit correspondre
