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 Simply ouvertes, leur pourcentage, de quel côté est la balle (Investigation AI ou Attente SE par ex.). Pour cela, connectez vous sur Simply, allez sur le projet CESTAS et triez les tâches par progression.

Dans ce qui suit, il faut se connecter au VPN sur Forticlient.
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 bitwarden, 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.

Pour la vérification de la sauvegarde des bases SQL :
Sur le MASTER et TOUS LES CLUSTERS :
Se connecter sur SQL, avec l'authentification windows :
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

S’il n’y a presque plus d’espace disponible sur le Nas il faut le vider pour le vider aller sur le master. Dans l'exploreur des fichiers aller dans network puis dans NAS_CESTAS – Documents – BACKUPS_SQL – SV_NON_TESTEES dans ce dernier fichier sont présent des backups non testés ou l’on peut en effacer un certain nombre il faut en garder 2 de chaque cluster (les plus récent) et effacer le reste.

• 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 flèche 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 flèche bleu dans la barre de menu de windows en bas à droite (en étant connecté au cluster concerné)
• Cliquer sur Shutdown
• Attendre que la flèche devienne grise quelques instants
• Redémarrer le clear scada serveur
• Attendre que la flècheredevienne bleue
• Vérifier à nouveau si toutes les tâches sont maintenant avec un Failure Count à zéro

Cette partie va nous permettre d'acquitter l'ensemble des alarmes qui ne sont plus présentes dans chaque SPV.

Pour cela il faut :
- Se connecter au master afin d'avoir accès à tout les SPV.
- Cliquer sur un SPV (celui de votre choix car il faudra faire de même pour tout les SPV).
- Aller sur la vue d'alarme

- Cliquer en haut à droite sur Ack. Clear
- Cela va ouvrir une pop-up. Cliquer sur Oui.

Il faut arrêter et redémarrer chaque VM des clusters, les uns après les autres.

Se connecter à l'ESXi du cluster que l'on veut arrêter (attention la connexion est plutôt longue)

Faire un arrêt de la VM du cluster (pas un redémarrage)

Une fois la VM arrêtée, redémarrer la VM avec l'ESXi.

Passer sur tous les clusters, les uns à la suite des autres

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