Je ne vais pas rentrer dans le détail du matériel mais juste en ayant la vision boîte noire : j'ai un point de montage sur lequel j'ai de la place et je désire connaître ses performances.
Comme cela a déjà été indiqué dans les posts précédents, ces résultats dépendent de beaucoup de paramètres (cache, taille de l'I/O).
Pour ma part, j'utilise Iozone un petit utilitaire en C qui fonctionne sur systèmes POSIX (testé sur HP-UX, AIX et Linux) et qui permet de simuler des I/O en faisant varier les paramètres :
+ lecture/écriture
+ taille de l'I/O
+ cache/pas cache
+ synchrone/asynchrone (pour les écritures)
Iozone est un vrai couteau suisse mais
+ Il n'est plus maintenu (date de 1998 - 2002)
+ Les tableurs excel pour avoir de zolis graphes sont payants . C'est uniquement pour le rendu, les matrices de résultats sont exploitables avec un peu d'habitude.
En particulier, il est indispensable de connaître la taille des I/O qui vont être faits.
Par exemple,
* sur un serveurs de fichiers, on aura de longues I/O séquentielles : Plusieurs centaines de ko en 1 I/O
* sur une base de données : on pourra avoir différents types d'I/O
+ sur un Scan complet des Tables, on aura tendances à avoir des "grosses I/O" (prefetch des valeurs suivantes) (dizaines voire centaine de ko l'I/O)
+ sur une requête simple ou sur un jointure sur index on pourra avoir des petites I/O (4ko,8ko qui sont des multiples de la taille du bloc)
(Sur la base de données, je me base sur des mécanismes de type 'Oracle')
Et c'est pourquoi si on joint sur 90% de la table, il est peut être préférable de faire un Full Table Scan que de mettre des Index.
Et c'est la raison pour laquelle il me semble primordial de d'abord s'attacher au besoin du stockage (I/O, débit, latence) avant de tenter un test brut.
Je me permets de faire un petit retour de mon expérience (je ne prétend pas être expert sur le sujet) sur ces différents outils :
OTRS (testé en version 3.0) , on est actuellement en 3.2 donc je ne peux pas dire sur les nouvelles fonctionnalités : Cet outil est "seulement" un outil de ticketing sur lequel on peut "saupoudrer" une notion ITIL via son plugin ITSM
GLPI : gestion de parc informatique (Inventaire, Ticketing, gestion des contrats, …)
La version standard est plutôt orienté poste de travail (moniteurs, périphérique,imprimantes, cartouche) mais il manque (en standard) des objets "datacenter" (enclosure/blade center, Switch SAN)
Inventaire physique et logique
Le couplage avec un agent d'inventaire type OCS NG/FusionInventory est sympathique (testé avec Fusion Inventory) même s'il manque à mon goût quelques champs dans le modèle de base GLPI
On peut faire un usage "datacenter" avec des plugins
Architecture réseau pour avoir une map du datacenter
Adressage IP pour avoir une vision des plages IPs utilisés
Gestion de baies : par contre, comme dit précédemment, les blade center ne sont pas gérés donc tu ne sais pas gérer les lames
Applicatifs : permet de simuler des regroupements pour définir une application. Il peut être détourné pour des regroupements physiques (châssis Reseau/Lames) mais cela n'est pas très satisfaisant.
La gestion des plugins est, à mon sens, lourde mais avec de nombreuses fonctionnalités . Par contre, je dois reconnaître qu'il me manque de la doc A JOUR pour développer
Racktables : outil à la base fait pour gérer des racks réseau (la culture réseau est assez présente) mais qui permet maintenant une gestion de racks datacenter
Bonne gestion des types d'objets et des relations d'inclusions . Une chaîne du type est gérée : Une VM est dans un serveur qui est lui-même dans un bladecenter lui même dans un rack lui-même dans une rangée (ROW) lui-même dans une salle
Pas d'inventaires logiques (liste des logiciels installés sur le serveurs )
Seulement de la gestion d'inventaire + contrats (pas d'outils de ticketing intégré)
La gestion des plugins est rudimentaires (fichiers php à inclure dans un répertoire)
ITOP : CMDB + gestion des incidents + gestion des problèmes (la plus proche d'ITIL à mon sens parmi GLPI, racktables, ITOP)
Au niveau affichage, c'est plus sexy que les autres
Au niveau des composants, cela est relativement complet pour une vision datacenter (Rack, Enclosure, Server, Switch, Fabric SAN) ainsi que logique (Logiciels, VM, …)
Au niveau des informations, j'ai des manques curieux : par exemple, on ne peut pas dire à quelle position (U) se trouve un serveur dans un RACK
[^] # Re: Systemd
Posté par Etienne Carrière . En réponse à la dépêche CentOS 7 fait son entrée au CERN. Évalué à 8.
Ils utilisaient donc systemd à Black Mesa dès 2000 . Ils étaient vraiment en avance sur leur temps ;)
# IOzone
Posté par Etienne Carrière . En réponse au journal Linux Centos et disque SSD. Évalué à 2.
Je ne vais pas rentrer dans le détail du matériel mais juste en ayant la vision boîte noire : j'ai un point de montage sur lequel j'ai de la place et je désire connaître ses performances.
Comme cela a déjà été indiqué dans les posts précédents, ces résultats dépendent de beaucoup de paramètres (cache, taille de l'I/O).
Pour ma part, j'utilise Iozone un petit utilitaire en C qui fonctionne sur systèmes POSIX (testé sur HP-UX, AIX et Linux) et qui permet de simuler des I/O en faisant varier les paramètres :
+ lecture/écriture
+ taille de l'I/O
+ cache/pas cache
+ synchrone/asynchrone (pour les écritures)
Iozone est un vrai couteau suisse mais
+ Il n'est plus maintenu (date de 1998 - 2002)
+ Les tableurs excel pour avoir de zolis graphes sont payants . C'est uniquement pour le rendu, les matrices de résultats sont exploitables avec un peu d'habitude.
En particulier, il est indispensable de connaître la taille des I/O qui vont être faits.
Par exemple,
* sur un serveurs de fichiers, on aura de longues I/O séquentielles : Plusieurs centaines de ko en 1 I/O
* sur une base de données : on pourra avoir différents types d'I/O
+ sur un Scan complet des Tables, on aura tendances à avoir des "grosses I/O" (prefetch des valeurs suivantes) (dizaines voire centaine de ko l'I/O)
+ sur une requête simple ou sur un jointure sur index on pourra avoir des petites I/O (4ko,8ko qui sont des multiples de la taille du bloc)
(Sur la base de données, je me base sur des mécanismes de type 'Oracle')
Et c'est pourquoi si on joint sur 90% de la table, il est peut être préférable de faire un Full Table Scan que de mettre des Index.
Et c'est la raison pour laquelle il me semble primordial de d'abord s'attacher au besoin du stockage (I/O, débit, latence) avant de tenter un test brut.
[^] # Re: GLPI ?
Posté par Etienne Carrière . En réponse au journal Itop... l'ITSM opensource. Évalué à 10.
Bonjour,
Je me permets de faire un petit retour de mon expérience (je ne prétend pas être expert sur le sujet) sur ces différents outils :
Mes 2 cents