Il y a de cela une dizaine de jours, la partition système d’un serveur d’un de nos clients est passé en lecture seule suite à un problème de consistence sur le disque. Pour les services en cours et ne dépendant pas de fichiers sur cette partition, les services continuaient de fonctionner. Pour les autres, ils étaients hors service ou dans une situation de dsyfonctionnement dès lors qu’ils avaient besoin d’écrire un fichier sur la partition système.

Pour rétablir le service dans les plus brefs délais et investiguer ce problème dans un second temps, nous avons décidé de créer un nouveau serveur, de lui attacher les données et l’IP du serveur hors-service. Cette opération a été grandement facilitée vu que nous utilisons dans ce cas l’offre IAAS de Gandi : en quelques clicks, un nouveau serveur a été provisionné, et les disques contenant les données et les backups ont été attachés au nouveau serveur.

Vient alors Ansible : grâce aux playbooks, préalablement rédigés par nos soins, pour installer l’ensemble des logiciels et le paramétrage associé des serveurs de notre client, le serveur était opérationnel dans les 15 minutes. Quelques tests plus tard, nous pouvions alors migrer l’IP de l’ancien serveur vers le nouveau et rendre le site à nouveau accessible au bout de 30 minutes environ.

Malheureusement, toutes les modifications et quelques actions n’étaient pas encore reportées ou rédigées dans nos playbooks. L’heure suivante a donc consisté à rattrapper ces informations et jouer les actions manquantes. Depuis lors, elles ont été réintégrées dans les playbooks .

Au final, en 1h30 après décision de reconstruire le serveur, le service était totalement rétabli et avec un retour partiel au bout de 30 minutes environ. Si nous avions du rejouer toute l’installation à la main, cela aurait durer bien plus de temps et avec des risques d’erreurs / oublis non négligeables et sans parler du doute persistent : a-t-on bien tout récupéré ?

Un crash serveur est une situation stressante pour tout le monde ; il est agréable de pouvoir compter sur un outil comme Ansible pour garantir l’état final d’un serveur (prédictibilité). Cela apporte une certaine sérénité et permet de rétablir le service au plus vite pour le bien de tous. Au-delà du premier déploiement, cela requiert une certaine hygiène de vie du serveur pour maintenir les playbooks à jour.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes elasticsearch kafka postgres traefik ansible grafana influxdb python aws sécurité timeseries tick mysql redis cloud ovh cassandra chronograf swarm test docker-compose hashicorp helm ksql log machine-learning microservice résilience serverless spark terraform timescaledb angularjs api architecture cncf confluent container graphql javascript opensource rancher service-mesh stream windows arm csp devops dns documentation elastic gcp git hpkp iac ingress java jenkins kafka-streams kapacitor kibana lambda lean licence maintenance microsoft mobile monitoring nginx npm optimisation orientdb prometheus redhat rest rethinkdb reverse-proxy rook sauvegarde sql ssh telegraf warp10 agile apm automatisation azure bash big-data bilan cert-manager certificat cli cluster continous-delivery continous-integration cookie cérénit dashboard fluxlang framework gdpr gitlab grav hsts https hypriot hébergement istio json k3s kubedb lets-encrypt linux load-balancer mongodb perspective php pip pipeline ptsm reaper replication rpi rsyslog s3 scale scaleway schema secrets solr sre systemd vault virtualenv vue.js wagtail yarn accessibilité akka alerte alibaba amazon-emr anonymisation anthos ara audit bastion beam beat bounded-context branche brigade browser buildkit cahier-des-charges cassandra-reaper cd cdc ceph certificats checklist chrome ci ci/cd cloud-init cloud-native cloud-storage clusterip cockroachdb code codeurs-en-seine confluence consul containerd continous-deployment coreos cors cqrs crash cron crontab csrf css curl d3.js daemonset data-pipelining data.gouv.fr datacenter dataviz date ddd debezium debian deployment desktop devoxx diff distributed-systems dive docker-app docker-hub docker-registry docker-swarm documentdb dokcer draft drop-in déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering ergonomie etcd event-sourcing facebook faisabilité falcor feature-policy feed filebeat firebase firefox fish flash flask fleet flink fluentd flux formation foundation frontend fsync fullstack github gke glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy hdfs header html html5 http http/3 hue ia iaac ibm immutable incident index influxace influxcloud influxdata influxdays infrastructure-as-code ingénierie inspec jq jquery jwt k3d k8s k9s kubeadm kubecon kubectl laravel liste-de-diffusion loadbalancer logstash logstatsh loi maesh mailing-list management mariadb meetup message metallb micro-service molecule mot-de-passe multi-cloud médecine métrique newsletter nodeport nomad nosql null opendata openebs openmetrics openshit openssh openweb operator over-engineering packaging pandas partiql password percona performance persistent-volume-claim pipenv pod portainer prediction prescience publicité push pyenv quasardb quay queue quic ram rambleed raml react recaptcha recherche registry reindex reinvent reliability responsive revocation revue-de-code rkt rolespec root rpo rto runc rwd scanner sdk search select serverless-architecture service-worker sha1 sharding shell shipyard société souveraineté-numérique spinnaker spécifications sri ssh-agent ssl statistique superset sympa syslog-ng test-unitaire tidb tiers timer timezone tls training travail ubuntu unikernel unit ux vendredi vie-privée virtualbox virtualisation vitess vm vnc volume voxxeddays vpc vscode web yubikey

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)