Qu’est un SnowflakeServer
Et surtout, comment l’éviter! Continuité de services, DRP
Traduction d’un article en anglais du 10 juillet 2012, par ;
Il peut être difficile de garder un serveur de production en marche. Vous devez vous assurer que le système d’exploitation et tout autre logiciel dépendant sont correctement corrigés pour le maintenir à jour. Les applications hébergées doivent être mises à niveau régulièrement. Des modifications de configuration sont régulièrement nécessaires pour modifier l’environnement afin qu’il fonctionne efficacement et communique correctement avec les autres systèmes. Cela nécessite une combinaison d’appels de ligne de commande, de basculer entre les écrans de l’interface graphique et de modifier des fichiers texte.
Le résultat est un flocon de neige unique — bon pour une station de ski, mauvais pour un centre de données.
Le premier problème avec un serveur flocon de neige est qu’il est difficile à reproduire. Si votre matériel commence à avoir des problèmes, cela signifie qu’il est difficile de démarrer un autre serveur pour prendre en charge les mêmes fonctions. Si vous devez exécuter un cluster, vous rencontrez des difficultés pour synchroniser toutes les instances du cluster. Vous ne pouvez pas facilement refléter votre environnement de production pour les tests. Lorsque vous rencontrez des défauts de production, vous ne pouvez pas les étudier en reproduisant l’exécution des transactions dans un environnement de développement. [1]
Faire des images de disque du flocon de neige peut y contribuer dans une certaine mesure. Mais de telles images se rassemblent facilement comme éléments inutiles de la configuration, sans parler des erreurs, se perpétuent.
Cependant, la véritable fragilité des flocons de neige survient lorsque vous devez les changer. Les flocons de neige deviennent bientôt difficiles à comprendre et à modifier. Les mises à niveau d’un logiciel à un bit provoquent des effets d’entraînement imprévisibles. Vous ne savez pas quelles parties de la configuration sont importantes, ou tout simplement comment elles sont sorties de la boîte il y a de nombreuses années. Leur fragilité conduit à de longues périodes de débogage stressantes. Vous avez besoin de processus manuels et de documentation pour prendre en charge toutes les exigences d’audit. C’est une des raisons pour lesquelles vous voyez souvent d’importants logiciels s’exécuter sur d’anciens systèmes d’exploitation.
Un bon moyen d’éviter les flocons de neige consiste à conserver la configuration de fonctionnement complète du serveur sous une forme de recette automatisée. Deux outils qui sont devenus très populaires pour cela récemment sont Puppet et Chef . Les deux vous permettent de définir l’environnement d’exploitation sous une forme de DomainSpecificLanguage et de l’appliquer facilement à un système donné.
L’intérêt d’utiliser une recette n’est pas seulement que vous pouvez facilement reconstruire le serveur (ce que vous pourriez aussi faire avec l’imagerie) mais vous pouvez également comprendre facilement sa configuration et ainsi la modifier plus facilement. De plus, puisque cette configuration est un fichier texte, vous pouvez le garder en contrôle de version avec tous les avantages que cela apporte.
Si vous désactivez tout accès direct du shell au serveur et forcez toutes les modifications de configuration à être appliquées en exécutant la recette à partir du contrôle de version, vous disposez d’un excellent mécanisme d’audit qui garantit que chaque modification de l’environnement est enregistrée. Cette approche peut être la bienvenue dans les environnements réglementés.
Le déploiement des applications doit suivre une approche similaire: entièrement automatisé, toutes les modifications du contrôle de version. En évitant les flocons de neige, il est beaucoup plus facile de faire des environnements de test de véritables clones de production, ce qui réduit les bogues de production causés par les différences de configuration.
Un bon moyen de vous assurer que vous évitez les flocons de neige est d’utiliser PhoenixServers . L’utilisation de recettes contrôlées par version pour définir les configurations de serveur est une partie importante de la Continuité de service.
[1] Une autre métaphore que j’ai entendue à ce sujet est que vous devez traiter vos serveurs comme du bétail et non comme des animaux de compagnie. Bien que j’avoue, je trouve étrange que cette métaphore soit utilisée par mes collègues végétariens.
