Très bon article!
Pour ma part, je suis resté en 2000.
Les technos de 2010 nécessitent une conception particulière et plutôt de repartir de zéro.
Je vois mal comment faire une transition douce des concepts des années précédentes avec les concepts actuels dans le cloud (à moins de ne faire que de la VM basique mais ce ne sont pas les concepts de 2010 (1)).
Le personnel nécessaire et/ou le temps de mise en oeuvre au départ est un peu plus important.
Autre souci, les éditeurs de logiciels métier ne sont pas passés à ces concepts. Tenter de les rentrer au chausse pieds dans du déploiement automatisé, c'est coûteux, sans garantie d'aboutir et risqué car si ça ne fonctionne pas, c'est parce qu'on n'a pas suivi les procédures!
Pour la sécurité, M$crote ne nous aide pas. Quasiment partout où je suis passé, les mises à jour ne sont pas faite. On a peur que ça casse tout (y compris sur des Linux). C'est, de mon point de vue, la grande faute de M$. Rappelez-vous les passages d'une version de Windaube à une autre, toujours pas certain que tout fonctionne (et même on peut être certain qu'il y aura un truc essentiel qui va foirer). Le passage du SP2 de XP a été l'une des pire choses pour la sécurité. Un procès devrait être intenté rien que pour ça et toutes les réticences que ça a engendré au sujet des mises à jour. Les cafouillages des derniers patchs entretiennent ces méfiances.
Notes:
(1)
Chez un Gros opérateur (Historique) Français, la notion de cloud est limitée à de la Virtualisation pour l'infra et des services web mutualisés pour le grand publique… Ils sont restés en 2000 sur les concepts mais essaient d'utiliser les technos actuelles.
Dans certaines installations, un file system peut être quasiment en permanence en read only. Si on a un mécanisme pour se prémunir de panes de courant lorsqu'il passe en écriture (pour une mise à jour par ex), la journalisation ne sert à rien et on peut gagner de la place dans ce cas là.
Dans le même genre, toujours pour des file systems en read only, de la compression asymétrique peut être très intéressante. C'est consommateur en cpu/ram/temps pour la compression et presque rien pour la décompression.
Je n'ai pas encore essayé. Pour moi ça semble plutôt complémentaire à Nagios dans le sens où c'est très orienté données numériques et qu'elles sont envoyées directement des machines supervisées.
Nagios est au départ orienté test simple (les perfdata sont arrivées après) et plutôt par requête depuis l'extérieur de la machine supervisée.
Vérifier que le serveur HTTP fonctionne bien est plus fiable en faisant une requête depuis l'extérieur qu'en lui demandant si il vas bien ;)
Et superviser un matériel propriétaire tout intégré ne permettant pas d'installer de module supplémentaire dessus (exemple : un matériel réseau routeur, switch) ne semble pas super adapté pour Prometheus (ni nethdata, ni telegraph); il faut une machine de "polling"
Mais à l'inverse devoir mettre du snmp pour superviser l'utilisation CPU/RAM, etc. c'est lourd (oui on peut faire autrement aussi heureusement)
Une refonte de l'interface Nagios (Il faut vraiment que je teste sérieusement certains forks comme shinken) avec intégration des principes de ces outils avec agent et graphiques serait l'idéal.
Du peu que j'ai utilisé dans les anciennes versions, l'intégration est plutôt bien faite. Par contre, de mon point de vue, il y a un énorme point noir à cette solution : les mises à jour.
En effet, il semble toujours nécessaire, pour mettre à jour, de faire une sauvegarde, de réinstaller de zéro et de restaurer. Dans un environnement de production avec des contraintes de sécurité, cette méthode est inadaptée et risquée.
Si je dois installer un environnement de supervision, je reste pour le moment sur du debian ou ubuntu avec config à la main. Au moins on peut mettre à jour les composants.
Un sujet que je trouve très surprenant dans cette distribution ce sont les mises à jour. Je n'ai vu aucune mise à jour de sécurité. De plus, pour mettre à jour d'une version à une autre la seule méthode est une sauvegarde de la config, installation from scratch et restauration. Aujourd'hui je trouve ces méthodes dépassées.
# Je suis resté en 2000
Posté par Pascal Greliche (site web personnel) . En réponse à la dépêche Démystifier l’activité d’hébergeur. Évalué à 7.
Très bon article!
Pour ma part, je suis resté en 2000.
Les technos de 2010 nécessitent une conception particulière et plutôt de repartir de zéro.
Je vois mal comment faire une transition douce des concepts des années précédentes avec les concepts actuels dans le cloud (à moins de ne faire que de la VM basique mais ce ne sont pas les concepts de 2010 (1)).
Le personnel nécessaire et/ou le temps de mise en oeuvre au départ est un peu plus important.
Autre souci, les éditeurs de logiciels métier ne sont pas passés à ces concepts. Tenter de les rentrer au chausse pieds dans du déploiement automatisé, c'est coûteux, sans garantie d'aboutir et risqué car si ça ne fonctionne pas, c'est parce qu'on n'a pas suivi les procédures!
Pour la sécurité, M$crote ne nous aide pas. Quasiment partout où je suis passé, les mises à jour ne sont pas faite. On a peur que ça casse tout (y compris sur des Linux). C'est, de mon point de vue, la grande faute de M$. Rappelez-vous les passages d'une version de Windaube à une autre, toujours pas certain que tout fonctionne (et même on peut être certain qu'il y aura un truc essentiel qui va foirer). Le passage du SP2 de XP a été l'une des pire choses pour la sécurité. Un procès devrait être intenté rien que pour ça et toutes les réticences que ça a engendré au sujet des mises à jour. Les cafouillages des derniers patchs entretiennent ces méfiances.
Notes:
(1)
Chez un Gros opérateur (Historique) Français, la notion de cloud est limitée à de la Virtualisation pour l'infra et des services web mutualisés pour le grand publique… Ils sont restés en 2000 sur les concepts mais essaient d'utiliser les technos actuelles.
# journalisation inutile pour les file systems en read only
Posté par Pascal Greliche (site web personnel) . En réponse à la dépêche Partitions ext4 : ne gaspillez plus l’espace disque !. Évalué à 8.
Dans certaines installations, un file system peut être quasiment en permanence en read only. Si on a un mécanisme pour se prémunir de panes de courant lorsqu'il passe en écriture (pour une mise à jour par ex), la journalisation ne sert à rien et on peut gagner de la place dans ce cas là.
Dans le même genre, toujours pour des file systems en read only, de la compression asymétrique peut être très intéressante. C'est consommateur en cpu/ram/temps pour la compression et presque rien pour la décompression.
# Complémentaire à Nagios
Posté par Pascal Greliche (site web personnel) . En réponse à la dépêche Découverte de l’outil de supervision Prometheus. Évalué à 4.
Je n'ai pas encore essayé. Pour moi ça semble plutôt complémentaire à Nagios dans le sens où c'est très orienté données numériques et qu'elles sont envoyées directement des machines supervisées.
Nagios est au départ orienté test simple (les perfdata sont arrivées après) et plutôt par requête depuis l'extérieur de la machine supervisée.
Vérifier que le serveur HTTP fonctionne bien est plus fiable en faisant une requête depuis l'extérieur qu'en lui demandant si il vas bien ;)
Et superviser un matériel propriétaire tout intégré ne permettant pas d'installer de module supplémentaire dessus (exemple : un matériel réseau routeur, switch) ne semble pas super adapté pour Prometheus (ni nethdata, ni telegraph); il faut une machine de "polling"
Mais à l'inverse devoir mettre du snmp pour superviser l'utilisation CPU/RAM, etc. c'est lourd (oui on peut faire autrement aussi heureusement)
Une refonte de l'interface Nagios (Il faut vraiment que je teste sérieusement certains forks comme shinken) avec intégration des principes de ces outils avec agent et graphiques serait l'idéal.
# Mise à jour
Posté par Pascal Greliche (site web personnel) . En réponse à la dépêche EyesOfNetwork 4.2 est sorti. Évalué à 7.
Du peu que j'ai utilisé dans les anciennes versions, l'intégration est plutôt bien faite. Par contre, de mon point de vue, il y a un énorme point noir à cette solution : les mises à jour.
En effet, il semble toujours nécessaire, pour mettre à jour, de faire une sauvegarde, de réinstaller de zéro et de restaurer. Dans un environnement de production avec des contraintes de sécurité, cette méthode est inadaptée et risquée.
Si je dois installer un environnement de supervision, je reste pour le moment sur du debian ou ubuntu avec config à la main. Au moins on peut mettre à jour les composants.
# Un autre sur Twitter
Posté par Pascal Greliche (site web personnel) . En réponse à la dépêche Décès de Cédric Blancher, chercheur en sécurité informatique. Évalué à 4.
https://twitter.com/Herve_Schauer/status/399844467286347776
# Mises à jour
Posté par Pascal Greliche (site web personnel) . En réponse à la dépêche EyesOfNetwork 4.0 est sorti. Évalué à 3.
Un sujet que je trouve très surprenant dans cette distribution ce sont les mises à jour. Je n'ai vu aucune mise à jour de sécurité. De plus, pour mettre à jour d'une version à une autre la seule méthode est une sauvegarde de la config, installation from scratch et restauration. Aujourd'hui je trouve ces méthodes dépassées.
# Horaires?
Posté par Pascal Greliche (site web personnel) . En réponse à la dépêche Atelier IPv6 ou le futur de l'internet - Mardi 16 juin 2009 à Rennes. Évalué à 4.
# Re: Red Hat arrête le support gratuit
Posté par Pascal Greliche (site web personnel) . En réponse à la dépêche Red Hat arrête le support gratuit. Évalué à -1.