TOC

5 façons d’améliorer la configuration de votre serveur de production d’applications Web de production

introduction

Une fois que votre application est opérationnelle dans un environnement de serveur cloud, vous vous demandez peut-être comment améliorer votre environnement de serveur pour passer de «ça marche» à un environnement de production à part entière. Cet article vous aidera à vous familiariser avec la planification et la mise en œuvre d’un environnement de production en créant une définition vague de «production», dans le contexte d’une application Web dans un environnement de serveur cloud, et en vous montrant des composants que vous pouvez ajouter à votre environnement existant. l’architecture pour faire la transition.

Aux fins de cette démonstration, supposons que nous commençons avec une configuration similaire à celle décrite dans https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web- application [5 configurations de serveur communes], comme cet environnement à deux serveurs servant simplement une application Web:

image: https: //assets.digitalocean.com/articles/architecture/production/it_works.png [Configuration de l’application]

Votre configuration réelle peut être plus simple ou plus complexe, mais les idées générales et les composants présentés ici doivent s’appliquer dans une certaine mesure à n’importe quel environnement de serveur.

Commençons par définir ce que nous entendons par «environnement de production».

Qu’est-ce qu’un environnement de production?

Un environnement de serveur pour une application Web, au sens général, comprend le matériel, les logiciels, les données, les plans opérationnels et le personnel nécessaire au bon fonctionnement de l’application. Un environnement de production fait généralement référence à un environnement de serveur conçu et mis en œuvre avec le plus grand soin pour les niveaux acceptables de ces facteurs:

  • * Disponibilité *: possibilité pour l’application d’être utilisable par les utilisateurs auxquels elle est destinée pendant les heures annoncées. La disponibilité peut être perturbée par toute défaillance qui affecte suffisamment un composant critique (par exemple, l’application se bloque en raison d’un bogue, le périphérique de stockage de la base de données est défaillant ou l’administrateur système met accidentellement le serveur d’applications hors tension).

Un moyen de promouvoir la disponibilité consiste à réduire le nombre de points de défaillance uniques dans un environnement. Par exemple, l’utilisation d’une adresse IP statique et d’un service de basculement de surveillance garantit que les utilisateurs ont uniquement accès à des équilibreurs de charge sains. Pour en savoir plus, consultez https://www.digitalocean.com/community/tutorials/how-to-use-floating-ips- on-digitalocean # comment-mettre-en-oeuvre-une-ha-configuration [cette section de Comment utiliser les adresses IP flottantes] et cette https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx -load-balancing [article sur l’équilibrage de charge].

  • * Récupération *: possibilité de récupérer un environnement d’application en cas de défaillance du système ou de perte de données. Si un composant critique échoue et n’est pas récupérable, la disponibilité deviendra inexistante. L’amélioration de la «maintenabilité», un concept associé, réduit le temps nécessaire à l’exécution d’un processus de récupération donné en cas de défaillance et peut donc améliorer la disponibilité en cas de défaillance.

  • * Performances *: l’application fonctionne comme prévu sous une charge moyenne ou maximale (p. Ex. il est raisonnablement sensible). Bien que très important pour vos utilisateurs, les performances ne comptent que si l’application est disponible.

Prenez le temps de définir des niveaux acceptables pour chacun des éléments mentionnés ci-dessus, dans le contexte de votre application. Cela dépendra de l’importance et de la nature de l’application en question. Par exemple, il est probablement acceptable qu’un blog personnel desservant quelques visiteurs souffre de temps d’arrêt occasionnel ou de performances médiocres, tant que le blog peut être récupéré, mais la boutique en ligne d’une entreprise doit viser très haut. Bien sûr, il serait bien d’atteindre 100% dans chaque catégorie, pour chaque application, mais cela n’est souvent pas réalisable en raison de contraintes de temps et d’argent.

Notez que nous n’avons pas mentionné (a) la fiabilité du matériel, la probabilité qu’un composant matériel donné fonctionne correctement pendant un laps de temps spécifié avant une panne, ou (b) la sécurité en tant que facteurs. En effet, nous supposons (a) que les serveurs cloud que vous utilisez sont généralement fiables mais risquent d’être défaillants (car ils fonctionnent sur des serveurs physiques), et (b) que vous suivez les meilleures pratiques de sécurité au meilleur de vos capacités- Autrement dit, ils sortent du cadre de cet article. Vous devez cependant savoir que la fiabilité et la sécurité sont des facteurs qui peuvent directement affecter la disponibilité, ce qui peut rendre nécessaire la possibilité de récupération.

Au lieu de vous montrer une procédure étape par étape pour créer un environnement de production, ce qui est impossible en raison des besoins et de la nature variables de chaque application, nous allons présenter quelques composants tangibles que vous pouvez utiliser pour transformer votre configuration existante en un environnement de production.

Jetons un coup d’œil aux composants!

[[1-backup-system]] === 1. Système de sauvegarde

Un système de sauvegarde vous donnera la possibilité de créer des sauvegardes périodiques de vos données et de restaurer des données à partir de sauvegardes. Les sauvegardes permettent également la restauration de vos données, à un état antérieur, en cas de suppression accidentelle ou de modification non désirée, pouvant survenir pour diverses raisons, notamment une erreur humaine. Tout le matériel informatique a un risque de panne à un moment donné, ce qui peut potentiellement entraîner une perte de données. Dans cet esprit, vous devez conserver des sauvegardes récentes de toutes vos données importantes.

  • Requis pour la production? * Oui. Un système de sauvegarde peut atténuer les effets de la perte de données, ce qui est nécessaire pour atteindre la capacité de récupération et, par conséquent, facilite la disponibilité en cas de perte de données. Toutefois, il doit être utilisé en conjonction avec des plans de récupération solides, décrits dans la section suivante. Notez que les sauvegardes basées sur des instantanés de DigitalOcean peuvent ne pas suffire à tous vos besoins en matière de sauvegarde, car elles ne sont pas bien adaptées à la sauvegarde de bases de données actives et d’autres applications avec une E / S d’écriture disque élevée, si vous exécutez ce type d’application, ou voulez plus de flexibilité dans la planification des sauvegardes, veillez à utiliser un autre système de sauvegarde tel que Bacula.

image: https: //assets.digitalocean.com/articles/architecture/production/backup_system.png [Exemple de système de sauvegarde]

Le diagramme ci-dessus est un exemple de système de sauvegarde de base. Le serveur de sauvegarde réside dans le même centre de données que les serveurs d’applications, où les sauvegardes initiales sont créées. Par la suite, des copies hors site des sauvegardes sont effectuées sur un serveur situé dans un centre de données différent afin de garantir la conservation des données en cas de catastrophe naturelle, par exemple.

Considérations

  • * Sélection de sauvegarde: * Les données que vous sauvegarderez. Sauvegardez au minimum toutes les données que vous ne pouvez pas reproduire de manière fiable à partir d’une source alternative.

  • * Planification des sauvegardes: * Quand et à quelle fréquence vous effectuerez des sauvegardes complètes ou incrémentielles. Des considérations spéciales doivent être prises en compte pour les sauvegardes de certains types de données, telles que les bases de données actives, qui peuvent affecter votre planification de sauvegarde.

  • * Période de conservation des données: * Combien de temps conserverez-vous vos sauvegardes avant de les supprimer?

  • * Espace disque pour les sauvegardes: * La combinaison des trois éléments précédents affecte la quantité d’espace disque requise par votre système de sauvegarde. Tirez parti de la compression et des sauvegardes incrémentielles pour réduire l’espace disque requis par vos sauvegardes.

  • * Sauvegardes hors site: * Pour protéger vos sauvegardes contre les sinistres locaux, il est conseillé de conserver, dans un centre de données donné, une copie de vos sauvegardes dans un emplacement distinct du point de vue géographique. Dans le diagramme ci-dessus, les sauvegardes de NYC3 sont copiées dans SFO1 à cette fin.

  • * Tests de restauration de sauvegarde: * Testez régulièrement votre processus de restauration de sauvegarde pour vous assurer que vos sauvegardes fonctionnent correctement

Tutoriels connexes

[[2-recovery-plans]] === 2. Plans de récupération

Les plans de reprise constituent un ensemble de procédures documentées permettant de récupérer d’éventuelles défaillances ou erreurs d’administration dans votre environnement de production. Au minimum, vous souhaiterez un plan de récupération pour chaque scénario invalidant qui, selon vous, se produira inévitablement, tel qu’une défaillance matérielle du serveur ou une suppression accidentelle de données. Par exemple, un plan de récupération très simple en cas de panne de serveur peut consister en une liste des étapes que vous avez suivies pour effectuer votre déploiement de serveur initial, avec des procédures supplémentaires pour restaurer les données d’application à partir de sauvegardes. Outre une bonne documentation, un meilleur plan de récupération peut tirer parti des scripts de déploiement et des outils de gestion de la configuration, tels que Ansible, Chef ou Puppet, pour automatiser et accélérer le processus de récupération.

  • Requis pour la production? * Oui. Bien que les plans de récupération n’existent pas en tant que logiciels dans votre environnement de serveur, ils constituent un composant nécessaire pour une configuration de production. Ils vous permettent d’utiliser efficacement vos sauvegardes et fournissent un plan pour la reconstruction de votre environnement ou la restauration de l’état souhaité en cas de besoin.

image: https: //assets.digitalocean.com/articles/architecture/production/recovery_plans.png [Exemple de plans de récupération]

Le diagramme ci-dessus est une vue d’ensemble d’un plan de récupération pour un serveur de base de données défaillant. Dans ce cas, le serveur de base de données sera remplacé par un nouveau avec le même logiciel installé et la dernière sauvegarde correcte sera utilisée pour restaurer la configuration et les données du serveur. Enfin, le serveur d’applications sera configuré pour utiliser le nouveau serveur de base de données.

Considérations

  • * Documentation de la procédure: * L’ensemble des documents à suivre en cas d’échec. Un bon point de départ consiste à créer un document détaillé que vous pouvez suivre pour reconstruire un serveur défaillant, puis à ajouter des étapes pour restaurer les différentes données d’application et la configuration à partir de sauvegardes.

  • * Outils d’automatisation: * Les scripts et les logiciels de gestion de la configuration fournissent une automatisation qui peut améliorer les processus de déploiement et de récupération. Bien que les guides pas à pas soient souvent adéquats pour remédier simplement à une défaillance, ils doivent être exécutés par une personne et ne sont donc pas aussi rapides et cohérents qu’un processus automatisé.

  • * Composants critiques: * Les composants nécessaires au bon fonctionnement de votre application. Dans l’exemple ci-dessus, les serveurs d’application et de base de données sont des composants critiques, car en cas d’échec, l’application devient indisponible.

  • * Points de défaillance uniques: * Les composants critiques qui ne disposent pas d’un mécanisme de basculement automatique sont considérés comme un point de défaillance unique. Vous devez essayer d’éliminer au mieux vos points de défaillance afin d’améliorer la disponibilité.

  • * Révisions: * Mettez à jour votre documentation à mesure que votre processus de déploiement et de récupération s’améliore.

[[3-load-balancing]] === 3. L’équilibrage de charge

L’équilibrage de charge peut être ajouté à un environnement de serveur pour améliorer les performances et la disponibilité en répartissant la charge de travail sur plusieurs serveurs. Si l’un des serveurs dont la charge est équilibrée échoue, les autres serveurs gèrent le trafic entrant jusqu’à ce que le serveur défaillant redevienne sain. Dans un environnement de serveur cloud, l’équilibrage de charge peut généralement être mis en œuvre en ajoutant un serveur d’équilibrage de charge, qui exécute le logiciel d’équilibrage de charge (proxy inverse), devant plusieurs serveurs exécutant un composant particulier d’une application.

  • Requis pour la production? * Pas nécessairement. L’équilibrage de charge n’est pas toujours nécessaire dans un environnement de production, mais il peut constituer un moyen efficace de réduire le nombre de points de défaillance uniques dans un système, s’il est correctement implémenté. Il peut également améliorer les performances en augmentant la capacité grâce à la mise à l’échelle horizontale.

image: https: //assets.digitalocean.com/articles/architecture/production/load_balancing.png [Équilibrage de la charge]

Le diagramme ci-dessus ajoute un serveur d’applications supplémentaire pour partager la charge et un équilibreur de charge pour répartir les demandes des utilisateurs sur les deux serveurs d’applications. Cette configuration peut améliorer les performances si le serveur d’applications unique avait du mal à gérer le trafic. Elle peut également aider à garder l’application disponible si l’un des serveurs d’applications tombe en panne. Cependant, le serveur de base de données et le serveur d’équilibrage de charge lui-même ont toujours deux points de défaillance uniques.

Considérations

  • * Composants à équilibrage de charge: * Tous les composants d’un environnement ne peuvent pas être équilibrés facilement. Une attention particulière doit être accordée à certains types de logiciels tels que les bases de données ou les applications avec état

  • * Réplication des données d’application: * Si un serveur d’applications avec équilibrage de charge stocke les données d’application localement, telles que les fichiers téléchargés, ces données doivent être mises à la disposition des autres serveurs d’applications via des méthodes telles que la réplication ou des systèmes de fichiers partagés. Cela est nécessaire pour garantir que les données de l’application seront disponibles, quel que soit le serveur d’application choisi pour répondre aux demandes des utilisateurs.

  • * Goulots d’étranglement liés aux performances: * Si un équilibreur de charge ne dispose pas de suffisamment de ressources ou n’est pas configuré correctement, il peut en réalité réduire les performances de votre application.

  • * Points de défaillance uniques: * Bien qu’un équilibrage de charge puisse être utilisé pour éliminer les points de défaillance uniques, un équilibrage de charge mal planifié peut en réalité ajouter plus de points de défaillance uniques. L’équilibrage de charge est amélioré avec l’inclusion d’un deuxième équilibreur de charge avec une adresse IP statique devant la paire qui envoie le trafic à l’un ou à l’autre en fonction de la disponibilité.

[[4-monitoring]] === 4. surveillance

Monitoring peut prendre en charge un environnement de serveur en surveillant le statut des services et les tendances d’utilisation des ressources de votre serveur, offrant ainsi une excellente visibilité sur votre environnement. L’un des principaux avantages des systèmes de surveillance est qu’ils peuvent être configurés pour déclencher une action, telle que l’exécution d’un script ou l’envoi d’une notification, lorsqu’un service ou un serveur tombe en panne, ou si une certaine ressource, telle que le processeur, la mémoire ou stockage, devient sur-utilisé. Ces notifications vous permettent de réagir à tout problème dès qu’il se produit, ce qui peut aider à minimiser ou à prévenir le temps d’indisponibilité de votre application.

  • Requis pour la production? * Pas nécessairement, mais le besoin de surveillance augmente à mesure que la taille et la complexité de l’environnement de production augmentent. Il constitue un moyen simple de suivre vos services critiques et les ressources du serveur. À son tour, la surveillance peut améliorer la capacité de récupération et informer la planification et la maintenance de votre configuration.

image: https: //assets.digitalocean.com/articles/architecture/production/monitoring.png [Exemple de surveillance]

Le diagramme ci-dessus est un exemple de système de surveillance. En règle générale, le serveur de surveillance demande des données d’état au logiciel de l’agent s’exécutant sur les serveurs d’application et de base de données, et chaque agent répond avec des informations sur l’état du logiciel et du matériel. Le ou les administrateurs du système peuvent ensuite utiliser la console de surveillance pour examiner l’état général de l’application et accéder à des informations plus détaillées, si nécessaire.

Considérations

  • * Services à surveiller: * Les services et logiciels que vous allez surveiller. Au minimum, vous devez surveiller l’état de tous les services qui doivent fonctionner correctement pour que votre application fonctionne correctement.

  • * Ressources à surveiller: * Les ressources que vous allez surveiller. Des exemples de ressources incluent l’utilisation du processeur, de la mémoire, du stockage et du réseau, ainsi que l’état du serveur dans son ensemble.

  • * Rétention des données: * La période pendant laquelle vous conservez les données de surveillance avant de les jeter. Ceci, ainsi que le choix des éléments à surveiller, affecteront la quantité d’espace disque nécessaire à votre système de surveillance.

  • * Règles de détection des problèmes: * Les seuils et les règles qui déterminent si un service ou une ressource sont dans un état OK. Par exemple, un service ou un serveur peut être considéré comme sain s’il exécute et traite des demandes, tandis qu’une ressource, telle que le stockage, peut déclencher un avertissement si son utilisation atteint un certain seuil pendant un certain temps.

  • * Règles de notification: * Les seuils et les règles qui déterminent si une notification doit être envoyée. Bien que les notifications soient importantes, il est également important d’ajuster vos règles de notification afin de ne pas en recevoir trop; une boîte de réception pleine d’avertissements et d’alertes va souvent être ignorée, les rendant presque aussi inutiles que pas d’avis du tout

[[5-centralized-logging]] === 5. Enregistrement centralisé

La journalisation centralisée peut prendre en charge un environnement de serveur en offrant un moyen simple d’afficher et de rechercher vos journaux, qui sont normalement stockés localement sur des serveurs individuels de l’ensemble de votre environnement, à un seul endroit. Outre la commodité de ne pas avoir à se connecter à des serveurs individuels pour lire les journaux, la journalisation centralisée vous permet également d’identifier facilement les problèmes qui touchent plusieurs serveurs en corrélant leurs journaux et leurs métriques au cours d’une période donnée. Cela permet également une plus grande flexibilité en termes de conservation des journaux, car les journaux locaux peuvent être déchargés des serveurs d’applications vers un serveur de journaux centralisé disposant de son propre stockage indépendant.

  • Obligatoire pour la production? * Non, mais comme la surveillance, la journalisation centralisée peut fournir des informations inestimables sur l’environnement de votre serveur à mesure qu’il croît en taille et en complexité. En plus d’être plus pratique que la journalisation traditionnelle, il vous permet d’auditer rapidement les journaux de votre serveur avec une visibilité accrue.

image: https: //assets.digitalocean.com/articles/architecture/production/centralized_logging.png [Journalisation centralisée]

Le diagramme ci-dessus est un exemple simplifié d’un système de journalisation centralisé. Un agent d’envoi de journaux est installé sur chaque serveur et configuré pour envoyer des journaux d’applications et de bases de données importants au serveur de journalisation centralisé. Le ou les administrateurs du système peuvent ensuite afficher, filtrer et rechercher tous les journaux importants à partir d’une console unique.

Considérations

  • * Journaux à recueillir: * Les journaux particuliers que vous enverrez de vos serveurs au serveur de journalisation centralisé. Vous devriez rassembler les journaux importants de tous vos serveurs

  • * Conservation des données: * Période pendant laquelle vous conservez les journaux avant de les supprimer. Ceci, ainsi que votre choix de journaux à rassembler, affectera la quantité d’espace disque nécessaire à votre système de journalisation centralisé.

  • * Filtres de journal: * Les filtres qui analysent les journaux simples en données de journal structurées. Le filtrage des journaux améliorera votre capacité à interroger, analyser et représenter graphiquement les données de manière significative.

  • * Horloges de serveur: * Assurez-vous que les horloges de vos serveurs sont synchronisées et définies sur le même fuseau horaire, afin que votre journal chronologique soit précis dans tout votre environnement.

Conclusion

Lorsque vous assemblez tous les composants, votre environnement de production peut ressembler à ceci:

image: https: //assets.digitalocean.com/articles/architecture/production/production.png [Production]

Maintenant que vous connaissez les composants qui peuvent être utilisés pour prendre en charge et améliorer la configuration d’un serveur de production, vous devez réfléchir à la manière dont vous pouvez les intégrer à vos propres environnements de serveur. Bien sûr, nous n’avons pas couvert toutes les possibilités, mais cela devrait vous donner une idée de l’endroit où commencer. N’oubliez pas de concevoir et de mettre en œuvre votre environnement de serveur en fonction d’un équilibre entre vos ressources disponibles et vos propres objectifs de production.

Si vous souhaitez configurer un environnement comme celui ci-dessus, consultez ce didacticiel: Building for Production: Web Applications.

Related