Archive

Posts Tagged ‘serveur’

Cloud Computing et contrôle industriel : L’usine dans les nuages ?

Cloud Computing Word cloud

Le Cloud Computing et toutes les notions dérivées du SaaS (Software as a Service) ont largement envahi les colonnes de la presse technique. A tel point que le contrôle industriel, qui n’est pas forcément friand de la technologie en date, commence sérieusement à s’y intéresser.

Les pré-requis de la mutation
Par essence, le terme de service désigne quelque chose d’immatériel. Pour toutes les fonctions liées au matériel, il faut donc les rendre indépendantes d’un matériel spécifique. En d’autres termes, il faut donc les « virtualiser ». La virtualisation va donc consister à s’abstraire d’un matériel spécifique, pour pouvoir, en théorie tout au moins, exécuter la fonction sur n’importe quelle machine.

Mais ce n’est pas tout. Si, bien sûr, il y a un sens usuel (et relativement ancien) au terme de « service« , les expressions comme « On Demand« , « as a Service » sont très liées à la diffusion de l’internet. De manière implicite, l’accès au « service » va se faire pour les utilisateurs au travers d’un navigateur Internet, c’est à dire un client web. En conséquence, les fonctions d’accès client doivent reposer sur des technologies web.

Lire la suite…

Comment diagnostiquer les problèmes liés aux fuites mémoire avec la plateforme COOX ?

Outils de diagnostic d’une fuite mémoire 

Mémoire
La mémoire est une ressource limitée ! et en java, lorsque la JVM n’a plus assez de mémoire pour s’exécuter, elle génère une Erreur java.lang.OutOfMemoryError.
Plusieurs cas de figure sont alors envisageables :
– Soit vous n’avez pas alloué assez de mémoire à la JVM
– Soit le système a, ce que l’on appelle, une fuite mémoire

Si vous êtes dans le 1er cas, les choses se résolvent assez facilement : il suffit d’allouer plus de mémoire grâce au paramètre -Xmx, et le tour est joué !
Dans le second cas, il va falloir déterminer d’où vient la fuite mémoire.

Mécanisme du ramasse-miettes (Garbage Collector)
Cet élément contribue à la robustesse et à la performance des programmes. Le ramasse-miettes est appelé régulièrement et automatiquement pendant l’exécution du programme.
Sur les systèmes multi-processeurs et/ou multi-cœurs, celui-ci emploie même des threads multiples à faible priorité afin de perturber le moins possible l’exécution de programme.
En outre, le programmeur peut au besoin suggérer de lancer le ramasse-miettes à l’aide de la méthode System.gc().

Un grief récurrent à l’encontre de langages comme C++ est la lourde tâche d’avoir à programmer manuellement la gestion de la mémoire. En C++, la mémoire allouée par le programme pour créer un objet est désallouée lors de la destruction de celui-ci (le plus souvent par un appel explicite à l’opérateur delete). Si le programmeur oublie de coder la désallocation, ceci aboutit à une « fuite mémoire », et le programme en consomme de plus en plus. Pire encore, si par erreur un programme demande plusieurs fois une désallocation, ou emploie une zone de mémoire après avoir demandé sa désallocation, celui-ci deviendra très probablement instable et se plantera.

En Java, une grande partie de ces problèmes est évitée grâce au ramasse-miettes. L’espace mémoire nécessaire à chaque objet créé est alloué dans un tas de mémoire en anglais : memory heap, réservé à cet usage.
Le programme peut ensuite accéder à chaque objet grâce à sa référence dans le tas. Quand il n’existe plus aucune référence permettant d’atteindre un objet, le ramasse-miettes le détruit automatiquement — puisqu’il est devenu inaccessible — libérant la mémoire et prévenant ainsi toute fuite de mémoire.

Le ramasse-miettes emploie un algorithme de marquage puis libération – en anglais –  : mark and sweep qui permet de gérer les cas complexes d’objets se référençant mutuellement ou de boucles de références (cas d’une liste à chaînage double par exemple).
En pratique il subsiste des cas d’erreur de programmation où le ramasse-miettes considèrera qu’un objet est encore utile alors que le programme n’y accèdera plus, mais dans l’ensemble, le ramasse-miettes rend plus simple et plus sûre la destruction d’objets en Java (en supprimant la nécessité de placer au bon endroit du code l’appel à l’opérateur delete).

Diagnostic
Afin de nous aider à analyser et diagnostiquer avec vous les problèmes liés aux fuites mémoire, voici quelques outils à mettre en place qui vous permettront de collecter les informations nécessaires pour cette étude :

  • Le diagnostic tool

La plateforme COOX 7 Helium propose l’outil « Diagnostic tool » pour faciliter la collecte et l’envoi d’informations au support technique. Cet outil peut s’installer sur nimporte quelle machine (voir COOX-DOC-Platform).
Vous pouvez alors nous faire parvenir les éléments lorsque le figeage se produit, en nous précisant la date et l’heure dudit événement.

tool

N’oubliez pas de cocher « collecter le heap dump des serveurs »

Le heap dump des serveurs :
Collecter le heap dump des serveurs revient à exporter le contenu mémoire des JVM des serveurs. Cela permet notamment de diagnostiquer plus facilement les problèmes de débordement mémoire. Toutefois, si cela n’est pas nécessaire, ne le cochez pas systématiquement car les dumps mémoire augmentent grandement le temps de collecte des informations.

  • Heap dump automatique du serveur

Dans le cas où le diagnostic tool n’arrive pas à se connecter au serveur, n’oubliez pas de prendre une capture de la console de cet outil et de nous l’envoyer.
Un autre outil peut être alors utilisé : le dump auto. Le principe consiste à demander à la JVM de faire un Heap dump automatiquement quand on arrive au fameux OutOfMemoryError !
Les deux options à utiliser sont les suivantes :

-XX:+HeapDumpOnOutOfMemoryError : active le dump automatique
-XX:HeapDumpPath : spécifie le fichier d’export

Exemple de modification du fichier manager.properties :
args=-Dswing.aatext\=true -Xmx1G -XX\:PermSize\=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:\\tmp\\mydump.hprof -cp .;system\\* globalscreen.startManager

 Cet outil peut être aussi bien utilisé en COOX 6.01, COOX 6.02 qu’en COOX 7 Helium.

  • VisualVM

Visual VM est un outil de monitoring de JVM locale ou distante. Il est intégré au JDK depuis la version 6 update 7. Vous le trouverez dans le répertoire JAVA_HOME/bin/jvisualvm
Il permet notamment :
– de connaître l’occupation CPU, la taille de la heap, le nombre de threads ainsi que le nombre de classes chargées de la JVM. On peut suivre l’évolution dans le temps de ces métriques.
– de réaliser un dump des threads en activité et de la heap.

  1. Faire un Heapdump du poste serveur avec VisualVm au moment du figeage

heapdump

Dans le cas de l’image ci-dessus le poste serveur est le 192.168.0.107

2. Enregistrer des Snapshots

Visualvm permet avec les plugins de prendre des snapshots de la mémoire (avec le graphe de tous les objets)

Génération d’un Snapshot :

snapshot

Exploitation et enregistrement d’un Snapshot :

snapshot1

snapshot2

 

COOX – Module Archive Manager : Comment faire pour enrichir la réplication de la base de données par l’option « Stratégie de réplication MES »

Dans le module Archive Manager de COOX, la réplication autorise l’écriture des données dans deux bases de données différentes, ce qui permet :

  • d’avoir une continuité de fonctionnement en cas de défaillance d’un serveur de données
  • d’éviter toute perte de données en cas de défaillance d’un serveur de base de données
  • de planifier une intervention pour revenir à une situation nominale

Nous avons enrichi la fonction de réplication de la base de données par l’option : Stratégie de réplication MES

replication

Stratégies de réplication SCADA :
Le fonctionnement de la réplication correspond à la stratégie de réplication SCADA. C’est le mode utilisé par défaut et correspond au mode de fonctionnement originel.
L’objectif de la stratégie de réplication SCADA est d’avoir une continuité maximale de production.
Ainsi, dans le cas d’une réplication active avec une base de données primaire et une base de données secondaire, cette stratégie décrit le scénario suivant :

  1. Perte du primaire : on bascule sur le secondaire
  2. Retour du primaire : on reste sur le secondaire
  3. Perte du secondaire : on bascule sur le primaire
  4. Retour du secondaire : on reste sur le primaire

Stratégies de réplication MES
Par opposition, le logiciel propose maintenant la stratégie de réplication MES.
L’objectif de cette stratégie est de maximiser la garantie des données.
Ainsi, dans le cadre d’une réplication active avec une base de données primaire et une base de données secondaire, cette stratégie se met en place comme suit :

test

  1. Perte du primaire : on bascule sur le secondaire, le primaire n’est plus autorisé

test2

  1. Retour du primaire : on reste sur le secondaire
  2. Perte du secondaire : on ne bascule pas sur le primaire, car il n’est pas autorisé

test2

  1. Retour du secondaire : on réutilise le secondaire, car il est autorisé

Exploitez vos données sans limitation de durée avec l’Archive Manager

Le volume des bases de données mises en œuvre grossit inévitablement au fil de l’exploitation d’une application (événements process, courbes, traçabilité…).
Même si les tailles des disques ne cessent de croître et augmentent la quantité d’informations qui peuvent être gardées « en ligne », la consultation de ces données en production peut ralentir le système et avoir un impact négatif sur la production si l’on souhaite un archivage sur le long terme.
On appréciera aussi de disposer d’un dispositif de sauvegarde des données qui permette de stocker certaines d’entre elles hors du site de production.

Une bonne solution est d’entretenir sur un serveur annexe des archives régulières, et d’utiliser le mécanisme de purge de COOX pour maintenir la base de production à une taille qui garantit des performances optimales.

Le module Archive Manager, qui s’installe sur ce serveur annexe, permet de gérer un nombre non limité d’archives et de les exploiter dans un environnement approprié. Les archives sont réalisées avec une forte compression, le module Archive Manager se chargeant de la décompression de l’archive à consulter. Les fichiers d’archives compressés sont faciles à gérer avec des dispositifs de sauvegarde classiques.
Les archives réalisées intègrent automatiquement une sauvegarde de la configuration d’application au moment de l’archive, et l’Archive Manager utilise pour l’exploitation des données archivées un sous ensemble de cette application enregistré en même temps que l’archive.

Les archives réalisées intègrent automatiquement une sauvegarde de la configuration d’application au moment de l’archive, et l’Archive Manager utilise pour l’exploitation des données archivées un sous ensemble de cette application enregistré en même temps que l’archive.
De cette manière, vous avez la garantie que l’exploitation des archives s’effectue avec des outils conviviaux, et dans des conditions similaires à celles de la production.
Il sera en effet plus commode d’utiliser le traceur, le journal, ou la vue de dossier de lots pour consulter les données correspondantes, plutôt qu’un outil de recherche en base de données.

Les données ci-dessous donnent un ordre d’idée sur les performances du mécanisme d’archivage :
·        5 Go de données stockées (base MySQL)
·        Durée d’archivage : 10 min (transparent pour la production)
·        Taille de l’archive : 200 Mo
·        Durée de la restauration : 30 min


  

Plateforme COOX : Comment faire pour configurer la réplication d’une base de données dans COOX ?

La réplication permet l’écriture des données dans deux bases de données différentes, ce qui permet :

– d’avoir une continuité de fonctionnement en cas de défaillance d’un serveur de base de données
– d’éviter toute perte de données en cas de défaillance d’un serveur de base de données
– de planifier une intervention pour revenir à une situation nominale
– couplage avec la redondance des services

Définition des architectures : Deux types d’architecture sont possibles :

– Le serveur de base de données et le serveur d’application sont hébergés par la même machine

 

– Le serveur de base de données et le serveur d’application sont hébergés par des machines différentes

Interface de paramétrage :

-Définition de deux adresses IP
-Base de données principale
-Base de données secondaire
-Un ou deux noms de base de données
-Le caractère « ; » sert de séparateur

Défaillance de la base de données :

-Le système indique la défaillance
-Le système switch sur la DB de secours
-Il faut planifier une intervention pour revenir à la situation nominale

%d blogueurs aiment cette page :