Reprise du message précédent :

 
   Désolé j'ai pas de photos par contre, je comptais pas l'encadrer

Y a de quoi s'amuser déjà

Clair

Tu bosses ou ?
 
XaT

Bonsoir à tous,
 
Je sors de l'ombre de ce topic que je lis depuis de nombreux mois, mais je n'ai jamais osé intervenir vu le faible niveau que j'ai par rapport à vous ! En tout cas, je rigole bien des différentes anecdotes  
Néanmoins, je sais que ça regorge d'expert et que peut-être vous allez m'aider à faire un bon choix ! Donc voici ma question :
Qu'est-ce que ça apporte les SSD niveau serveur ?
Je me tâte, lors de la migration de Win 2003R2 vers Win 2012R2 sur un Dell R610, d'en profiter pour passer d'un 4*300 Go en raid 5 vers un ou des SSD.
Ce serveur fait serveur d'application, de fichiers, d'impression et RDP. 70 users environ, quasiment tous en clients légers qui se connectent au serveur en RDP.
Autant je connais le gain des SSD sur un PC, autant sur un serveur, je n'ai aucune expérience...
L'idée serait essentiellement de gagner sur la réactivité de l'ERP (En Windev ne vous moquez pas...) dont "l'éditeur" de cet ERP semble oublier (ou ne sait pas faire ?) d'optimiser le programme ou les bases de données hyperfiles...! Certaines requêtes sont extrêment longues... Si on pouvait gagner un peu la-dessus...
Ne me demander pas de voir avec l'éditeur pour optimiser son application, de ce côté là c'est mort...  
Voilà, je ne sais pas si je suis clair et s'il y a quelque chose à gagner ?
Je suis preneur de tout conseil.
Merci par avance,

tu monitores tes disques déjà ? combien as-tu d'IOPS, sais-tu quel en est le profil (lecture/écriture, grose/petites, aléatoires/séquentielles) ?

Non, tu as raison, je pourrai déjà commencer par ça  
Tu as des conseilles sur un logiciel qui permettrait de voir facilement ce qui cloche ? Le moniteur de performance intégré à Windows ?
Dans le passé, j'ai déjà essayé de l'utiliser, mais je n'arrive pas à l'exploiter correctement, à en tirer des conclusions...
Je vois bien des courbes qui montent et qui descendent, des échelles de valeurs qui ne m'aident pas beaucoup...

On parle de monitoring ?

Ok, j'ai commencé à regarder.
Ça n'a pas l'air simple à première vue  
Faut se faire une petite autoformation de quelques heures pour l'appréhender.
Merci,

un outil de monitoring te dira pas plus comment interpréter des valeurs brutes ou des graphs, tout au plus tu pourras repérer des patterns.
 
effectivement avec Perfmon tu as le conteneur "PhysicalDisk" dans lequel t'as sensiblement l'équivalent des fameuses iowait sous unix (les process sous windows ne fonctionnant pas de la meme façon)
 
-Current Disk Queue Length  
-Average Disk Queue Length
 
=> tu pourras voir si ton cpu passe trop de temps en attente de réponse de tes disques, si c'est bien là le problème.
 
Après, il est aussi possible qu'hyperfile soit une grosse chaufferie et que tu ne rencontrerais pas ces problèmes sur un bon vieux mySQL
 
Un éditeur d'ERP ou autre est aussi censé donner des "précos" matérielles suivant usage et nombre d'utilisateurs ...

un ERP en windev, tout de même   pourquoi pas un OS ?  

P'tin cette haine que j'ai envers Windows !
J'apprend rapidement Python, 2 heures pour comprendre comment ajouter des modules  
Ca me rappelle Java au début, 2 heures pour faire reconnaitre le compilateur à Eclipse à chaque fois    

C'est quoi le rapport avec Windows ?

Sous Unix tu fais 2 commande ça s'installe tout seul...Enfin c'est ce qui est marqué partout.

Je voudrais faire un bête script python pour mon synology, mais comme l'accès SSH n'est pas encore réglé à distance je peux pas tester directement dans l'environnement...
J'ai du tout installer sur mon windows, mais je comprend rien...

Oui, je sais... pas le choix... marié avec eux, copinage, tout ça....
C'est un ERP assez spécifique (tout comme leur CRM et leur logiciel de compta conçu aussi avec WinDev) à notre métier et très peu de concurrence sur le marché (et franchement pas mieux en fonctionnalité).
En fait, je sais que c'est assez daubé et je me demandais si un ou des SSD ne pallierait pas au manque de performance de l'application.
J'en suis rendu à cette alternative car avec leur CRM installé sur les portables des commerciaux, j'ai un ratio de 1:10 sur la rapidité de certaines tâches, sur un même PC, suivant que ce soit un Disque dur ou un SSD... Oui oui, j'ai bien dit de 1 à 10 !
Je pensais donc à un gain de performance sur l'ERP, peut-être pas du même niveau que sur un pc portable car je sais qu'un serveur n'est pas géré comme un portable (surtout avec une grappe de disque 10k tr/min de 300 Go en raid 5), mais tout gain serait le bienvenu...

Il t'a fallut 2h pour pip install blaaaa
 
 

On ne dit pas de mal de hyperfile... Quoi que
 
http://fr.wikipedia.org/wiki/HyperFileSQL

 
Oui je débute  
C'est vraiment reboutant toute la configuration avant de se lancer...Lancer un shell windows pour lancer un script via python pour installer la bibliothèque  

Sinon cygwin et hop un environnement déjà moins hostile pour travailler pour de vrai

J'ai beau installé la 3.4 avec pip de pré-installé, impossible de m'en servir    
Je comprend vraiment rien, je suis pas débile pourtant !... Python pip install n'est pas reconnu ni dans un shell windows, ni dans un shell python (oui dans les tutoriaux ils disent pas dans quel shell il faut lancer certaines commandes, c'est sûrement inné pour ceux qui l'utilisent souvent, mais quand t'en a jamais fait...  
Faut mettre "pip" sans python devant  
 
 
Bon j'arrête pour cette nuit, déjà parce que c'est pas vraiment le bon topic

Ben c'est quand même évident, pip est le PM de pyhton, tout comme gem est celui de ruby et npm celui de node
donc chacun est un outil autonome

http://babun.github.io/
Ou avec Chocolatey.
 
Mais c'est vrai que ça reste la misère sous Windows...
À tel point qu'utiliser un truc comme Vagrant pour du dév python/ruby/node.js sous Windows est probablement une meilleure idée en fait.

Zabbix > EoN ou l'inverse ?
(vous avez 4h )
 
Je compte tester les 2 pour remplacer mon Nagios...

Zabbix est puissant, moins de galère qu'avec Nagios, tu veux faire un check spécifique, tu crées un UserParameter dans la conf de ton agent avec la commande ou le script qui va bien et ton serveur Zabbix peut interroger le client en utilisant la clé définie. Rien que ça je trouve que c'est overkill

Euh. Je trouve Nagios moins galère que Zabbix justement Avec NRPE tu peux faire tout autant de chose
 
Après bien sûr, si on parle de Centreon, ça commence à devenir un « gros » truc plus compliqué (cliquodrome).
 
Mais l'architecture des fichiers de conf de Nagios reste simple et facile à comprendre

Pas d'accord, devoir poser tes scripts python ou perl pour que ça marche je trouve ça vite compliqué. Avec Zabbix soit tu fais appel à un script (mais là on est un peu dans le même cas que pour Nagios) sois tu appelles directement la commande que tu veux (un ps par exemple) et là c'est vite mis en place.
Jette un oeil aux fichiers de conf de Zabbix pour les agents, tu vas voir que niveau simplicité on peut difficilement faire mieux (en gros tu définis ton hostname, l'ip du serveur Zabbix et tes UserParameters si tu en as, pour les check de base pas besoin).

Ca semble intéressant babun, je vais tester ça je pense, surtout que généralement je me sers principalement du shell de cygwin et pas tellement des binaires fournis.

 
Tant que tu respectes le format de sortie (les codes d'erreur/warning Nagios = 0,1 et 2), tu peux très bien utiliser ce que tu veux (bash ou pas bash !)
 
http://www.kmggroup.ch/?p=126
 
J'avais zieuté Zabbix, je l'ai trouvé moins « parlant » (mais ça peut être l'habitude aussi)

Sauf que t'as quand même un script à poser, regarde par exemple pour check le RAID d'un serveur. Avec Zabbix si dans les binaires fournis avec ta carte RAID t'en as un qui renvoie 0 ou 1 (ou équivalent) t'as même pas besoin de poser un script, tout est dans ta conf Zabbix.
Ce que je pointe du doigt c'est que pour le moindre check qui n'est pas par défaut avec Nagios t'es obligé de créer un script à poser sur le client, l'ajout d'une fonction dans la conf de l'agent ne suffit pas.
Pour Zabbix y a une habitude à prendre, j'avais commencé avec Nagios aussi, et une fois sur Zabbix j'ai eu un temps d'adaptation, mais pour avoir utilisé les 2 y a pas photo je préfère Zabou

Justement j'aime bien cette séparation en petites briques distinctes Mais je comprends ton point de vue

Si tu cleanes bien dès le départ dans les script qui te serviront jamais dans la vie, effectivement c'est bien rangé  

Sans compter qu'EoN, c'est Nagios + interface de conf + cacti + nagvis + ...

 
+1
Avec les items de base du client Zabbix tu peux faire beaucoup beaucoup de choses (cpu/process/disques/...).
De mémoire, il me semble que NRPE c'est juste un pauvre wrapper qui te fait suivre les valeurs d'un script exécuté en local, avec zabbix tu poses ton binaire et point barre.
Pas besoin de 36000 surcouches type centreon ou autre machin juste pour faire des graphs, tout ca c'est déja là.
L'auto discovery (ajouté en 2.2 je crois) des infras VMware c'est juste magique, tu file l'adresse de ton vCenter au bouzin et il te détecte tout. Plus besoin de penser à rajouter ton ESXi dans le monitoring par exemple.
Les scénarios web, les items que tu peux grapher dynamiquement (plus de "ha merde j'ai oublié de générer un RRD et une définition de graph pour tel élement" ), les actions déclenchées par les triggers (genre restart tel truc si c'est tombé), et j'en oublie...  
Le concept de template me semble beaucoup mieux utilisé: genre un template qui surveille les éléments de base du système (avec des règles de découverte locale style partitions, cartes réseaux, ...) qui est le même pour tous tes Linux ou tous tes Windows, sur lequel tu vas greffer des templates spécifiques appli / hardware / ....
Au final je n'ai AUCUN élément fait juste sur un hôte, tout vient grâce à des templates, même si des fois ya juste 2 items et 1 trigger, au moins je sais que ca pourra facilement être réutilisé par la suite.
Et en ce moment c'est le foutoir dans la communauté nagios, ca fork dans tous les sens je crois ?  
 
Au final le gros problème de zabbix c'est son interface crado et compliqué à prendre en main (et ca en découle au début une impression d'usine à gaz monstrueuse), mais une fois passé cette étape, c'est du bonheur.
Sans compter que pour les amateurs de CLI, il y a une API REST plutôt bien foutu qui te permets de rentrer/sortir tout un tas d'infos.
 
[/fanboy]  

 
pour du système, Xymon
 
pour du réseau Nagios avec Thruk.
 
Et pour des graphs kikoo à vendre aux clients, Observium

Mouais, c'est exactement ce que je rapproche à Zabbix, un gros tout en un : faire la métrologie et les trigger dans le même outil, quel merdier... Surtout quand ça commence à chercher des trucs plus flexibles.

• Pour les alertes à haut niveau (fonctionnel) : Nagios est très simple à paramétrer.
• Pour les alertes plus bas niveau (services) : Idem, ça reste trivial.
• Pour les graphes/métrologie c'est collectd/logstash/kibana (stack ELK), imbattable : ya un « ramp up » mais une fois en place et proprement recetté, c'est une tuerie pour la métrologie (d'ailleurs grosse demande de plus en plus de métriques applicatives : la stack ELK arrive en force du côté dev aussi !)
• Pour les services qui tombent et se font relancé tout seul : systemd.
• Concernant les « templates » il y a bien sûr exactement la même chose dans Nagios.
• Pour les recettes à déployer sur toutes les machines : SaltStack (Ansible est pas mal aussi)

Bref, plein d'outils différents qui s'imbriquent très bien les uns avec les autres en fonction du niveau de détail voulu (et c'est scalable).

Après oui, l'avantage du monolithique pour une archi et des besoins qui restent simple, c'est que ça « juste marche » de suite. Par contre, dès que tu sors un peu des sentiers battus (clients qui veulent un bout d'analyse graphique poussés, d'autres juste des alertes, certains du déploiement auto, le tout à différents niveaux de permissions), ya aucun outil « tout en un » qui peut y répondre, ou alors ça coûte cher (en temps et/ou en argent).

J'entends bien : comparer Zabbix à 4 outils différents, c'est comparer des pommes et des oranges. Mais je crains qu'à l'avenir, ça va être de plus en plus dur (dans le métier d'admin) de rester sur un truc « qui fait tout ». Enfin c'est ce que je vois aussi bien dans le monde du dev que dans le devops « moderne » : programmation orientée composant (nodejs avec npm) et des API de partout pour être agnostique au maximum sur les technos. Bon j'ai un regard biaisé parce que je bosse avec en majorité des startups, mais ce sont souvent des précurseurs (ça finit par arriver dans le « mainstream » après élagages des technos qui n'ont pas percé)
/my 2 cents

edit : on parle de technos, mais c'est plus la philosophie de l'outil que l'outil en lui-même qui compte je trouve. Ça bouge trop vite maintenant pour se dire qu'on garde une techno pendant 10 ans. Faut juste trouver celles qui fonctionnent de manière interopérables et flexibles.

Et centreon?

 
C'est le gros du déployé aujourd'hui sur ceux qui sont en base « Nagios ». Ça reste (sans être péjoratif !) une surcouche web pour Nagios (même si depuis quelques versions ils ont fait des choix pour leur propre backend). C'est pratique pour organiser des équipes d'astreintes sans passer par du fichier de conf. Ya de bonnes idées mais c'est un peu violent en terme d'effet cliquodrome parfois.
 
Ya pas d'outil idéal, ça dépend du besoin
 
Je pense qu'en terme d'échelle Centreon est plus adapté à des installations importantes que Zabbix (j'ai toujours vu du Zabbix à petite échelle et Centreon à plus grosse : mais après ya toujours des exceptions, je parle pour ce que je vois de mon coté )

On utilise depuis un moment centreon. C'est pas mal. Après je gère pas trop le bouzin, mais plutôt pas mal foutu je trouve.