Wiki

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

====== Rapport hebdo cestas ======
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.

<WRAP center round important 60%>
A FAIRE UNE FOIS PAR MOIS \\
Vérifier si le NAS est bien à jour au niveau de l'anti-virus avant de commencer le rapport \\
Car cela peut-être long et contrôler une fois que tout est fini s'il s'est bien mis à jour\\

[[tma:contrats_set:rex_ai:update_nas_cestas|https://wikiai.aifrance.com/doku.php?id=tma:contrats_set:rex_ai:update_nas_cestas]]

</WRAP>

====1 - Mise à jour des tâches Simply====

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.

====2 - Connexion aux serveurs CESTAS====

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 [[tma:pv:acces_sites:cestas|la page wiki qui va bien]])\\
Pour savoir à quoi correspondent ces serveurs, il y a un Wiki sur l'architecture de CESTAS : cf[[[[tma:pv:schemas_elec:cestas|Architecture monitoring CESTAS]]]]

====3 - Vérification des performances serveurs ====
<del>
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.**</del>

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

====4 - Vérification alarmes en cours MASTER====
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.**

====5 - Vérification des rapports sur SQL sur les CLUSTER====

==5 - 1 - Exécution requête==
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

== 5 - 2 - Vérification présence alarmes dans table ALR ==

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. [[tma:pv:rex_ai:conext_control:verification_eventlogscanner|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. :[[tma:pv:rex_ai:rapports:relance_calculs_end|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.

== 5 - 3 - Cluster 1 : Modification date Event Log Scanner ==
**__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 :

== 5 - 4 - Vérification alarmes actives ==
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.

== 5 - 5 - Vérification du nombre de jours calculés==
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. :[[tma:pv:rex_ai:rapports:relance_calculs_end]].**

==5 - 6 - Vérification des niveaux de seuils d'indicateurs==
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. :[[tma:pv:rex_ai:rapports: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é.

====6 - Relancer les services SMS ====
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.

{{:tma:pv:rex_ai:rapports:service_sms_cestas.png?600|}}
\\
\\
- 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 :

{{:tma:pv:rex_ai:rapports:microsoftteams-image.png?400|}}
====7 - Test d'envoi de SMS ====
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

==7 - 1 - Modification du message à envoyer==
**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) :

<WRAP center round tip 60%>
Il faut bien penser à enregistrer les modifications réalisées sur chaque variables (via un CTRL+S par exemple)
</WRAP>

==7 - 2 - Forçage de la  variable de test ==
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**" :

==7 - 3 - Vérification ==
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.

<WRAP center round alert 60%>
Ce dernier point est très important car si l'on oublie de modifier la description des variables, tous les SMS d'alarmes qui partiront pour les SPVs concernées par nos tests auront "Test TMA" dans leur libellé ce qui induira probablement Clemessy en erreur.
</WRAP>

====8 - Vérification sauvegardes bases SQL  ====

**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 :
{{:tma:pv:rex_ai:rapports:Cestas_procedure_backup.png}}\\
\\
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.

==== 9 - Vérifier l'espace disque des serveurs ====

**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)

==== 10 - Vérifier la santé du santé du NAS ====
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

Vérification des backups :
Il faut vérifier que les fichiers de backup des clusters 1, 2, 3, 4 ainsi que du master sont bien rapatriés dans le NAS. Les backups sont stockés dans le répertoire suivant :
Nas cestas Documents-BACKUPS_SQL-SV_NON_TESTEES.
C'est ici que nous supprimons les backups pour libérer de l'espace. Avant de les supprimer, il faut d'abord vérifier les derniers backups et les passer en SV testées. Pour ce faire, vérifiez que la taille des backups est cohérente. Les backups des 4 clusters doivent avoir sensiblement la même taille, tandis que celui du master est généralement plus petit. Par exemple, si le backup du cluster 3 fait 200 Mo un jour, alors qu'il fait habituellement 25 Go, c’est qu’il y a problème.
Une fois que vous êtes certain que le backup est correct, allez dans BACKUP_SQL-SV_TESTEES et déplacez les cinq bases saines du MASTER/CLUSTER depuis le dossier SV_NON_TESTEES du NAS vers le dossier SV_ARCHIVES du NAS. Créez un dossier nommé "SV_SQL_ddmmyy" (en remplaçant ddmmyy par la date actuelle). À l’intérieur, créez un fichier texte indiquant la date de début du backup (date la plus ancienne des données) et la date de fin (date à laquelle le backup a été réalisé).
Enfin, une fois les backups sauvegardés, vous pouvez supprimer toutes les backups présentes dans le répertoire SV_NON_TESTEES.

<WRAP center round tip 60%>
[[tma:contrats_set:rex_ai:update_nas_cestas|https://wikiai.aifrance.com/doku.php?id=tma:contrats_set:rex_ai:update_nas_cestas]]
</WRAP>

==== 11 - Vérifier le Clear Scada Serveur du MASTER et de tous les CLUSTERS ====

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__.
{{ :tma:pv:rex_ai:rapports:serverstatus.png?nolink |}}

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**

====12 - acquittement des alarmes ====

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
\\
{{:tma:pv:rex_ai:rapports:vua_alarme_cestas.png?400|}}
\\
- Cliquer en haut à droite sur Ack. Clear
\\
- Cela va ouvrir une pop-up. Cliquer sur Oui.
\\
{{:tma:pv:rex_ai:rapports:acquit_vue_alarme_cestas.png?400|}}

====13 - Arrêt et redémarrage des VM clusters ====

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**

====14 - Vérification du compteur Night Var====

Sur le Master, vue Globale CESTAS, "Vers Utility" => onglet "Control Loop"

Relever la valeur du Compteur d'activation (en haut à droite)

====15 - Envoi du rapport ====

Une fois le rapport complété, l'envoyer à David et Clérye.\\
\\
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**

Résumé

Wiki

Outils pour utilisateurs

Outils du site

Outils de la page