Juste un retour d’expérience de plus de 10 ans sur ZABBIX. (Number of hosts 216 Number of items 6992 Number of triggers 3422)
IL s’agit d’un produit fabuleux, toujours en recherche d’amélioration, simple d’utilisation, rapide et conviviale.
Le seul point faible est la supervision réseau (Pas de map de topologie réseau automatique) et pas de rafraichissement dynamique des maps.

Mais dans une version future (1.8.11 actuellement), j’espère que cette fonctionnalité sera ajouté.

Cordialement
Bertrand ROY

La plupart de ces points sont présentés dans la première partie de l’article qui décrit les outils et leur fonctionnement : Comparatif outils de monitoring (métrologie et supervision) (1/2) : Zabbix, Centreon, Nagios, Cacti et Munin. Si vous avez encore une interrogation sur un élément en particulier dites-le moi.

Cordialement,

Frédéric FAURE

Effectivement, la tarification a une incidence sur cette modélisation, mais comme n’importe quelle base de données où on devrait optimiser la structure de sa base pour diminuer l’espace des données sur le disque, ou bien jouer sur de la dé-normalisation pour optimiser la performance des requêtes, … Modéliser sa base en fonction de ses priorités en fait. Il peut être intéressant, en plus de jouer sur la structure des items, d’optimiser la taille des attributs (nom et valeur) que l’on stocke.

#include <stdio.h>
#include <stdlib.h>
#include <omp.h>
#include <sys/time.h>

ainsi que les tabulations pour une meilleure lisibilité du code… Et puis quelques caractères qui ne sont pas passés… Ca ne risque pas de compiler ! :o)

Je corrige cela de suite ! :o)

Et pour information, la ligne pour la compilation du programme avant exécution :

gcc -Wall -fopenmp -otestCPU testCPU.c

Est-il judicieux de garder une même structure de données lorsque l’on passe d’une basse de données relationnelle à une base DynamoDB ?
(en partant bien entendu du principe que les colonnes sont facultatives)

Ou faut-il complètement la remodeler ?

le mode de tarification a-t-il une incidence sur cette modélisation dans le sens où la taille des items est prise en compte ?

Mais la comparaison s’arrête là car l’avantage de DynamoDB et ce qui fait la différence avec d’autres possibilités NoSQL c’est qu’il est vendu comme un service. Pas besoin de se soucier de ce qui va héberger notre système.

Ce qui induit un autre point : avant de mettre en place HBase, il faut s’assurer d’avoir suffisamment de données à y stocker, sinon ce ne sera ni efficace, ni intéressant. DynamoDB peut être utilisé pour n’importe quelle quantité de données et la capacité de débit est assurée par ailleurs.

La mise à disposition est donc complètement différente.

Frédéric FAURE

Serait-il possible de mettre en perspective DynamoDB et HBase ? J’y vois beaucoup de similitude et je serai ravi d’avoir votre regard sur ces deux bases NoSQL

En revanche, une instance EC2 ne sera pas patchée à notre insu lors d’opérations de maintenance à l’initiative d’Amazon : AWS est de type IaaS et nous sommes maître de notre instance virtuelle et de tout ce qu’il y a dedans (OS, logiciels, …). Nous décidons des redémarrages, patchs à passer sur l’OS, … et les données sur les disques locaux ne sont jamais altérées. Elles ne sont détruites que lorsque nous effectuons l’action « terminate » sur l’instance EC2.

Sur Azure, une opération de maintenance de type passage de patch sur l’OS (du Guest ou du Host) peut être à l’initiative de Microsoft, ce qui a une incidence sur le lecteur D: (partition système) qui est mis à jour. De même, attention, le disque E: (sur lequel les packages sont déployés) est dynamique et peut donc prendre une autre lettre (F:, G:, …) suite à une opération. Lors d’un redémarrage simple, les 3 disques sont généralement persistés, mais aucune garantie n’est prise par MS : Azure est de type PaaS, l’accès à l’OS est octroyé pour nous donner plus de liberté, mais nous n’avons pas la totale maîtrise dessus.

Dans le cas d’une base de données, l’installer sur un disque local d’un EC2 est tolérable pour peu que l’on fasse des backups réguliers car les crash hardware sont rares. Sur Azure, cela revient à jouer à la roulette russe car à tout moment, l’instance peut être simplement redémarrée (donc interruption de service), voire pire : patché (interruption de service plus longue, voire modification de la lettre du troisième disque). C’est pour cela que le SLA d’Azure ne fonctionne qu’à partir de 2 instances démarrées pour un rôle donné, pour qu’il y en ait toujours une UP. Si tu ne fais que de la lecture sur ta base ce n’est pas trop problématique avec 2 instances UP avec le même jeu de données. Mais si tu fais de l’écriture c’est ingérable : il te faudra mettre des systèmes de réplication poussés pour t’assurer que ce que tu écriras sur une instance sera bien répliqué sur une ou plusieurs autres pour ne pas perdre la donnée en cas d’opérations sur l’OS. En plus, il n’est pas possible de mettre en place du master-slave dans un même rôle car les instances sont équivalentes (on peut envisager de les spécialiser – master ou slave – dans un même rôle avec un mutex dans un espace partagé, genre le table service, mais ça devient trop du bricolage), ce qui t’oblige à jouer sur plusieurs rôles avec probablement un rôle dédié pour du proxying pour orienter les requêtes vers l’un ou l’autre. Je te laisse imaginer la complexité du chantier ! :o)

Frédéric FAURE