Dans le répertoire
P:\Projets\ARIB2593 - =S= CSE -TMA CESTAS\4 Dossier technique\4.2 Documents AI\4.2.4 Développement\Maintenance préventive
faites une copie du dernier compte-rendu, puis renommez-le en date du jour.

Mettez à jour sur le rapport les tâches FlySpray ouvertes, leur pourcentage, de quel côté est la balle (Investigation AI ou Attente SE par ex.). Pour cela, connectez vous sur FlySpray PV, allez sur le projet CESTAS et triez les tâches par progression.

Dans ce qui suit, il faut se connecter au VPN sur Forticlient.Cela va vous isoler du réseau AI, pensez à mettre en local votre compte-rendu ainsi que la base keepass.
Se connecter en bureau à distance sur chacun des 5 serveurs (1 Master et 4 Cluster). \\Pour se connecter au VPN CESTAS puis aux serveurs, suivre ce lien (cf la page wiki qui va bien)
Pour savoir à quoi correspondent ces serveurs, il y a un Wiki sur l'architecture de CESTAS : cfArchitecture monitoring CESTAS]]

Vérification de la CPU/RAM sur les serveurs : pour chaque serveur, ouvrir le gestionnaire des tâches (clic droit sur la barre du bureau) et regarder la mémoire la CPU utilisées.
Si la mémoire dépasse 70%, planifier un redémarrage du serveur.

Nous avons observé que les redémarrages ne résolvent pas systématiquement ce problème.

A l'aide de KeePass, lancer l'application ViewX du MASTER et se connecter à toutes les machines. Vérifiez s'il y a de nouvelles alarmes sur la vue Welcome du Master.
Si de nouvelles alarmes sont présentes, les notifier dans le compte rendu.

Sur chaque Cluster, cliquer sur la requête “Req_Check_Rapports_CC_TMA_CESTAS_V4.sql” située dans le dossier “Requêtes TMA” disponible sur le bureau. Cela va lancer l'application SQL Management. Entrez la date du jour puis exécutez la requête.
Sinon la requête est là:
P:\Projets\ARIB2593 - =S= CSE -TMA CESTAS\4 Dossier technique\4.2 Documents AI\4.2.4 Développement\RequêtesSQL_AutomatisationRapportsCC

Le premier select va retourner la date de la dernière alarme transférée dans la base SQL dans la table dbo.ALR.
Vérifiez que la dernière alarme date d'au maximum 2 jours avant la date courante.
S'il n'y a pas d'alarmes depuis plusieurs jours (3 jours), vérifier les logs de l'Event Log Scanner. Une page wiki est dédié à l'Event Log Scanner Si une erreur tourne en boucle, redémarrer le service et relancer les calculs depuis le jour de la dernière alarme (le calcul des END se fait avec la table ALR). cf. :rejouer_fichiers_cestas.

Pour Redémarrer l'event log scanner allez sur le symbole play bleu ⇒ server status. Dans l'arborescence allez sur localhost ⇒ General ⇒ Modules. Faites un clic droit sur CCEventLogScanner puis Stop puis Start.

Sur le cluster 1 : Il faut ouvrir les propriétés de l'Event Log Scanner afin de mettre la date de la veille dans la case “Date used for limitation” comme présenté sur l'image ci-dessous :

Le deuxième select va retourner la liste des alarmes actives.
Regardez ces alarmes et notez les dans le rapport.
Utiliser les filtres permet de comprendre la situation en cas de beaucoup d'alarmes.

Vérifier alors que pour chaque Id de SPV, le nombre de jours présents dans les rapports (colonne “Nb_Jour”) correspondent au nombre de jours dans le mois en cours, en comptant à partir de la veille.
Vérifier que le dernier jour du rapport correspond à la veille du jour actif.
Si ce n'est pas le cas, il faut relancer les rapports pour les SPV concernées : cf. :relance_calculs_end.

La troisième partie du résultat de la requête détecte s'il y a des données calculées “hors limites”, comme un PR supérieur à 100%. Si des lignes apparaissent dans ce secteur, c'est qu'il y a un défaut quelque part, se référer à la colonne “Commentaires” pour savoir quel indicateur est dépassé. Relancer alors les rapports des SPV concernées cf. :relance_calculs_end.

La requête est construite de façon à comparer chaque colonne à des seuils haut et bas. Il se peut que ces seuils (notamment les seuils haut) soient trop bas. Il faut alors en discuter avec l'équipe TMA pour voir s'il faut les modifier.

Si aucun problème n'est détecté, inscrivez “RAS” pour les lignes “Rapports de Production” et pour “Rapports de Performance” en précisant les SPV. Par exemple : Code « SPV01, SPV02, SPV07, SPV08, SPV11, SPV24 : RAS »

Pensez à sauvegarder la requête car cela permet au prochain rapport de voir pour quelles dates il a été effectué.

Dans cette section, nous allons relancer les services SMS afin de diminuer la non réception des SMS par l'astreinte Clemessy.

Tout d'abord, notez la valeur du nombre d'échecs de SMS dans le rapport avant de le reseter dans la suite de ce paragraphe.

Pour faire cela, il faut: - Etre connecté au Master et être sur View X, - Dans l'arborescence (à gauche de l'écran), aller dans Master (VM_MASTER), puis sur Common ensuite SMS et double cliquer sur SMS Service et SMS Pager Channel afin d'ouvrir ces pages.

- Dans chacune de ces pages, il faut décocher la case en service puis sauvegarder puis la recocher et de nouveau la sauvegarder. Cela permettra de rétablir la connexion si toute fois celle-ci a été perdue. - Remettre aussi à 0 le nombre de commandes SMS entrantes, comme ci-dessous :

Dans cette section, on va tester l'envoi de SMS d'alarmes pour chaque Cluster (sur une seule SPV par Cluster) afin de s'assurer que tout fonctionne correctement au niveau de l'envoi des SMS.

Les SPVs sur lesquelles on va faire nos tests sont les suivantes :

• Cluster 1 : SPV01
• Cluster 2 : SPV04
• Cluster 3 : SPV03
• Cluster 4 : SPV05

Depuis le MASTER, ouvrir l'arborescence pour aller dans le dossier Alarmes_SMS_Clusters comme sur l'image ci-dessous :

Ensuite, il faut aller modifier les configuration de 4 variables de ce dossier :

• SPV01_Maint_Synth
• SPV04_Maint_Synth
• SPV03_Maint_Synth
• SPV05_Maint_Synth

Pour cela, il suffit de double cliquer sur la variable que l'on souhaite modifier dans l'arborescence.

Dans la configuration de chacune de ces 4 variables, il faut modifier la description de la variable en remplacant “Maintenance” par “Test TMA” (cf image ci-dessous) :

Dans l’arborescence de chaque Clusters, rechercher la variable Test_SMS des SPV01 (pour le Cluster 1), SPV04 (pour le Cluster 2), SPV03 (pour le Cluster 3), SPV05 (pour le Cluster 4). Effectuez ensuite un Clique droit sur la variable puis cliquer sur “Forcer” :

Sélectionnez ensuite la valeur “Test Alarme et cliquer sur “OK” :

Une fois que l'on a forcer ces 4 variables, il faut vérifier qu'elles sont bien apparues dans le bandeau d'alarme du Master :

Une fois que ces 4 alarmes sont bien présentes sur le Cluster, il faut appeler l'Astreinte Clemessy pour savoir s'ils ont bien reçus les 4 SMS d'alarmes. Pour les joindre, il faut appeler au 07 85 51 87 95.

Pour finir, si l'astreinte Clemessy a bien reçu les SMS d'alarmes il faut :

• Remettre à 0 les 4 variables Test_SMS que l'on a forcé dans la partie 6-2 de cette page wiki.
• Puis bien penser à “LIBERER LE FORCAGE”.
• Modifier la description des variables modifiées dans la partie 6-1 de cette page.

Chaque semaine, le Dimanche, toutes les bases SQL PVDB+CCDATA des 5 serveurs d’exploitation MASTER/CLUSTER sont restaurées sur le PCBACKUP.
Il faut vérifier que ces restaurations se passent correctement via les logs:
* Se connecter sur le PCBACKUP (accès : voir KeePass TMA) * Aller dans C:\Programmes_Transferts et ouvrir le fichier de log Verification_BD.txt * Vérifier la colonne DATE_Fin : cette date doit être comprise entre J-1 et J-8. Si la date est plus ancienne, c'est que la base ne s'est pas restaurée : voir Wiki sur GESTION BD SQL CESTAS
Cestas - restauration backups

Pour le CCDATA_MASTER qui est différent des autres cluster, la vérification est différente, le nombre de la colonne NB_JOURS doit varier entre chaque vérification
Si les colonnes DATE_Fin et SI_ZERO_OK sont OK, inscrire dans le rapport hebdomadaire la date de la dernière restauration saine DATE_Fin du log de vérification.

* ATTENTION aussi à la taille des bases. Les backup des 4 clusters font sensiblement la même taille alors que celle du master est plus petite. En outre, dans N\\BACKUP_SQL\SV_NON_TESTEES du PCBACKUP, les tailles des autres backup ont sensiblement une taille cohérente. Si par exemple le backup cluster3 fait 200Mo le dernier jour alors qu'il en fait 25Go d'habitude alors c'est qu'il y a un problème. * Toujours sur le PCBACKUP, aller dans N\\BACKUP_SQL\SV_NON_TESTEES et couper/Coller les 5 bases saines (cf log et taille) MASTER/CLUSTER depuis le dossier SV_NON_TESTEES du NAS vers le dossier SV_ARCHIVES du NAS, en créant un dossier spécifique du type “SV_SQL_ddmmyyyy”. De cette manière on sait quelles sauvegardes ont correctement été restaurées. * Dernière étape, il faut purger le répertoire SV_NON_TESTEES du NAS. Si par exemple on a des BD saines au 18/07 et celles d'avant au 10/07, on peut supprimer les SV du 11/07 au 17/07 qui ne sont plus utiles. Une fois toutes les vérifications faites sur le PC Backup, bien penser à le redémarrer à l'aide de la commande Shutdown -R via l'invite de commandes

Pour la vérification de la sauvegarde des bases SQL :
Sur le MASTER et TOUS LES CLUSTERS :
Se connecter sur SQL :
Aller dans l'onglet SQL Server Agent puis dans Jobs et enfin faire clic droit sur Sauvegarde_Pvdb&CCData.Subplan_1 pour afficher l'historique :

Vérifier que la dernière sauvegarde se soit bien passée (coche verte)
En cas d'erreur détectée (coche rouge), regarder l'erreur donnée dans les détails.

Il est possible que l'erreur soit due à un manque de place sur le disque F: pour effectuer la sauvegarde.
Dans ce cas, aller dans le dossier F:/Backup_BDD et supprimer les anciennes backups pour libérer de l'espace.

Se connecter sur le MASTER et TOUS LES SERVEURS

Vérifier l'espace des différents disques.
Libérer l'espace le cas échéant. (Nous avons eu un crash du cluster3 par manque d'espace sur le disque C: le 19/06/2023)

Se connecter à l'interface web du NAS (depuis le MASTER ou n'importe quel CLUSTER via IE ou Mozilla) et contrôler l'état de santé du NAS :

• Vérifier qu'il reste de l'espace disque
• Vérifier que les 2 disques sont en état de marche
• Vérifier la mise à jour de l'anti virus au moins une fois par mois si possible

Il est nécessaire de vérifier que toutes les tâches soient bien lancées avec zéro failure count.

Pour cela,

• Faire clique droit sur la petite boule bleu dans la barre de menu de windows en bas à droite
• Aller dans le Server Status
• Déployer l'arborescence en cliquant sur le petit plus du serveur jusqu'à Localhost\General, Il faut vous logger en Super utilisateur CC de préférence (voir Keypass).
• Cliquer sur Modules
• Cliquer sur la Colonne Status pour trier les tâches qui sont marquées “Running”
• Vérifier que pour toutes ses tâches “Running” la colonne Failure Count soit à zéro.

Dans le cas contraire, il sera nécessaire d'arrêter le Clear Scada serveur et de le relancer. Il sera également nécessaire d'être logger en tant que Super Utilisateur CC (voir keypass).

• Faire clique droit sur la petite boule bleu dans la barre de menu de windows en bas à droite (en étant connecté au cluster concerné)
• Cliquer sur Shutdown
• Attendre que la boule devienne grise quelques instants
• Redémarrer le clear scada serveur
• Attendre que la boule redevienne bleue
• Vérifier à nouveau si toutes les tâches sont maintenant avec un Failure Count à zéro

Une fois le rapport complété, l'envoyer à David.

Enfin le stocker sur le serveur dans:
P:\Projets\ARIB2593 - =S= CSE -TMA CESTAS\4 Dossier technique\4.2 Documents AI\4.2.4 Développement\Maintenance préventive