Des questions similaires ont été posées mais j'ai besoin de savoir ce qui serait recommandé dans les circonstances, pour savoir si je manque quelque chose dans ma compréhension de l'utilisation d'EC2.
Une petite startup gère son entreprise sur le réseau EC2 et m'a demandé quelques conseils sur les options de sauvegarde. Ils sont autofinancés en ce moment et font ce qu'ils peuvent pour réduire les coûts lorsque cela est possible. Sans trop me plonger dans la configuration de leurs systèmes, je vais donner un serveur web comme exemple; c'est un simple serveur web avec une base de données. Le hic, c'est qu'ils ne veulent pas que le serveur soit arrêté.
La personne qui a effectué la configuration pense qu'elle doit soit effectuer des vidages périodiques de la base de données et les stocker sur S3, soit créer des scripts qui reconstruiraient un nouveau serveur sur Amazon en cas de besoin en sauvegardant certains dossiers contenant des informations de configuration. . Il a suggéré que créer des instantanés du serveur serait un gaspillage, car ils prennent beaucoup d'espace disque et qu'il y aurait essentiellement une rotation des données entre les grands vidages de données, de sorte que l'instantané deviendrait rapidement obsolète.
Ma pensée était de prendre un instantané de la machine virtuelle, puis de faire des vidages périodiques de la base de données et de les stocker dans S3. S'ils devaient perdre l'instance EC2 ou que quelque chose comme une mise à jour la rendait inutilisable, ils pourraient utiliser l'instantané pour reconstruire le serveur relativement rapidement avec le dernier vidage de la base de données, plutôt que de recommencer à zéro pour créer une nouvelle instance à partir d'un nouvelle AMI.
D'après ce que je comprends, prendre un instantané d'une instance EC2 (ou d'un magasin EBS) nécessitera un temps d'arrêt, ce qu'ils hésitent à avoir. J'ai également lu que vous devriez avoir le serveur arrêté pour garder le système de fichiers cohérent lors de l'instantané qu'il a pris. Puisqu'ils n'ont pas encore de cluster derrière un équilibreur, ceux-ci limitent les options impliquant des instantanés.
Les scripts pour construire des serveurs, sauf s'il y a quelque chose de spécifique à Amazon que je ne connais pas, impliqueraient la création d'un serveur Chef ou Puppet qui pourrait déployer de nouveaux serveurs avec leurs rôles associés sur EC2. À l'heure actuelle, la startup n'a pas de financement pour garder ce type de serveur dans les coulisses et, pour le moment, ils n'ont pas vraiment besoin de déployer autant de serveurs.
Idéalement, ils auraient le financement pour créer un certain nombre de serveurs derrière un équilibreur virtuel ou le service d'équilibrage d'Amazon, puis arrêter les serveurs un à la fois pour effectuer des mises à jour ou des instantanés. En ce moment, je serais nerveux à l'idée de faire des mises à jour parce que si vous faites des vidages de la base de données, cela n'aidera pas si une mise à jour du système modifie une bibliothèque sur laquelle s'appuie leur application et que le service tombe en panne.
J'ai également supposé qu'une autre option consiste à exécuter un script qui crée un volume EBS, le monte et, sur le serveur, à exécuter quelque chose comme rsync pour capturer la plupart des informations du système de fichiers sur le volume EBS, puis compresser et copier le contenu sur S3, déconnecter le volume et détruisez-le pour économiser les coûts de stockage, puis effectuez un vidage de la base de données pour capturer des données en vol qui seraient autrement incohérentes. Pour certains de leurs serveurs, il deviendra très probablement nécessaire d'enregistrer sur des volumes EBS temporaires à mesure que les besoins de leur base de données augmenteront.
Un sandbox VMWare est en cours de création pour recréer leurs systèmes réseau dans un environnement où les mises à jour peuvent être prétestées avant de les appliquer aux systèmes de production d'Amazon. J'espère que cela minimisera la possibilité qu'une mise à jour du système tue leur application.
Donc ... étant donné les restrictions de l'exécution d'un serveur, avec une base de données et un serveur d'applications sur le système, qui cherchent à ne pas avoir de temps d'arrêt le plus proche possible (restreindre l'utilisation des instantanés et faire en sorte que le processus de sauvegarde soit aussi "chaud" que possible ( créé en direct sans arrêter le serveur), suis-je sur la mauvaise voie pour suggérer de planifier un temps pour créer un instantané de l'instance EC2 dans son état de fonctionnement et à partir de là, faire des vidages de base de données pour copier vers S3? Existe-t-il une meilleure stratégie à poursuivre dans la création d'une sauvegarde en direct d'un serveur si les instantanés créent des temps d'arrêt?
la source
Réponses:
Il y a quelque chose d'intéressant dans cette question - en particulier en ce qui concerne l'idée de temps d'arrêt. Une partie de l'idée étant que si une application est sensible aux temps d'arrêt, le temps de récupération doit également être pris en compte. (Comme argument extrême, aucune sauvegarde ne nécessite aucun temps d'arrêt, sauf si vous avez besoin de ces sauvegardes, auquel cas le temps d'arrêt peut approcher de l'infini ).
Un peu sur EBS
Les volumes et les instantanés EBS fonctionnent au niveau du bloc, ce qui permet de prendre des instantanés pendant l'exécution d'une instance, même si le volume EBS est en cours d'utilisation. Cependant, seules les données qui se trouvent réellement sur le disque (c'est-à-dire qui ne sont pas dans un cache de fichiers) seront incluses dans l'instantané. C'est cette dernière raison qui fait naître l'idée de clichés cohérents.
Un point intéressant ici est que dans les deux cas ci-dessus, vous n'avez pas besoin d'attendre la fin de l'instantané pour rattacher / débloquer et reprendre l'écriture sur le disque - une fois que l'instantané a été lancé, vos données seront cohérentes à ce moment. En règle générale, cela ne nécessite que quelques secondes pendant lesquelles votre disque est verrouillé en écriture. De plus, puisque la plupart des bases de données structurent leurs fichiers sur le disque de manière raisonnable - il y a de fortes chances que les insertions aient un effet minimal sur les blocs existants - ce qui minimise les données ajoutées à l'instantané.
Considérez le point de la sauvegarde
Les volumes EBS sont déjà répliqués dans une zone de disponibilité - il y a donc un certain degré de redondance intégré. Si votre instance se termine, vous pouvez simplement attacher le volume EBS à une nouvelle instance et (après avoir dépassé le manque de cohérence) reprendre là où vous laisser derrière soi. À bien des égards, cela fait du volume EBS un instantané incohérent, à condition que vous puissiez y accéder. Cela dit, la plupart des utilisateurs EC2 se souviennent probablement des échecs en cascade des volumes EBS depuis début 2011 - les volumes étaient inaccessibles pendant plusieurs jours, et certains utilisateurs ont également perdu des données.
RAID1
Si vous essayez de vous protéger contre la défaillance d'un disque EBS (cela arrive), vous pouvez envisager une configuration RAID1. Étant donné que les volumes EBS sont des périphériques blocs, vous pouvez facilement utiliser mdadm pour les configurer dans la configuration souhaitée. Si l'un de vos volumes EBS ne fonctionne pas conformément aux spécifications, il est assez facile de le faire échouer manuellement (et de le remplacer ultérieurement par un autre volume EBS). Bien sûr, cela a des inconvénients - augmentation du temps pour chaque écriture, une plus grande sensibilité aux performances variables, le double du coût des E / S (monétarie, pas en termes de performances), aucune véritable protection contre une défaillance AWS plus répandue (un problème courant l'année dernière était l'impossibilité de détacher les volumes EBS qui étaient dans un état verrouillé), et bien sûr, l'état incohérent du disque en cas d'échec.
S3FS
Une option pour certaines applications (certainement PAS pour les bases de données) est de monter S3 en tant que système de fichiers local (par exemple via s3fs). C'est lent, il manque certaines des fonctionnalités que l'on peut attendre d'un système de fichiers et peut ne pas se comporter comme prévu (cohérence éventuelle). Cela dit, dans un but simple comme la mise à disposition de fichiers téléchargés sur plusieurs instances, cela peut avoir du mérite. Évidemment, ce n'est pas pour tout ce qui nécessite de bonnes performances de lecture / écriture.
Journal de bin MySQL
Une autre option spécifique à MySQL peut être l'utilisation du bin-log. Vous pouvez configurer un deuxième volume EBS qui stockera votre bin-log (pour minimiser l'effet des écritures ajoutées sur votre base de données), et l'utiliser en conjonction avec les vidages de base de données que vous effectuez. Vous pourriez même être en mesure de le faire avec s3fs, qui peut avoir du mérite si les performances sont tolérables (une rsync serait probablement mieux que d'essayer d'utiliser directement s3fs, et vous voudrez certainement compresser ce que vous pouvez).
Encore une fois, cependant, nous revenons à l'idée de but. Considérez ce qui se passerait avec les suggestions ci-dessus:
Donc vraiment, RAID1 est pour la plupart inutile et le bin-log prend trop de temps - les deux peuvent avoir du mérite dans certaines circonstances, mais sont loin de l'idée de sauvegarde.
Instantanés
Il est important de noter que les instantanés sont différentiels et ne stockent que les blocs réels qui contiennent des données (et sont compressés). Contrairement à un volume EBS, où si vous avez un volume de 20 Go, mais n'utilisez que 1 Go, vous êtes toujours facturé pour le stockage «provisionné» (20 Go). Avec un instantané, vous n'êtes facturé que pour ce que vous utilisez. Si aucune donnée ne change entre les instantanés, il n'y a (théoriquement) aucun frais. (Les instantanés sont facturés pour les PUTS / GETS et le stockage utilisé).
En passant, je recommande fortement que vos données d'application (y compris les bases de données) ne soient pas stockées sur votre volume racine (que vous avez peut-être déjà configuré). Un des avantages est que, espérons-le, votre volume racine voit un minimum de changement - ce qui signifie que ses instantanés peuvent être moins fréquents (ou auront un minimum de changement), ce qui réduit les coûts et la facilité d'utilisation.
Il est également pertinent de mentionner que vous pouvez supprimer les anciens instantanés à tout moment - même s'ils sont différentiels, ils n'affecteront pas les autres instantanés. Cela dit, chaque bloc alloué à un instantané ne sera pas abandonné tant qu'aucun instantané ne fera encore référence à ce bloc.
Le problème avec les vidages périodiques est d'abord le temps entre les vidages (éventuellement résolu en utilisant le bin-log de MySQL) et aussi la difficulté de récupération. Il faut du temps pour importer un grand vidage et relire tous les événements d'un bin-log. De plus, la création d'un cliché n'est pas sans conséquences sur les performances. On peut dire que ces vidages nécessitent probablement beaucoup plus de stockage qu'un instantané. Mettre en place un volume EBS uniquement pour les bases de données et les instantanés qui seraient préférables dans la plupart des cas (cela dit, la prise d'un instantané a également une certaine implication en termes de performances).
La beauté des instantanés et des volumes EBS est qu'ils peuvent être utilisés sur d'autres instances. Si votre instance ne démarre pas, vous pouvez attacher le volume racine à une autre instance pour diagnostiquer et résoudre le problème - ou simplement pour copier vos données - et pouvez changer de volume racine avec seulement quelques minutes d'arrêt (arrêtez l'instance, détachez le volume racine, attachez un nouveau volume racine, démarrez l'instance). Cette même idée s'applique à avoir vos données sur un deuxième volume EBS. Essentiellement, il vous suffit de faire tourner une nouvelle instance à partir de votre AMI personnalisée et d'y attacher votre volume EBS actuel - cela permet de minimiser les temps d'arrêt.
(On pourrait faire valoir (et je ne le recommanderais probablement pas) que vous pourriez configurer deux copies de MySQL sur le même serveur (maître-esclave), en utilisant deux volumes EBS, puis arrêter votre esclave pour prendre un instantané de son Volume EBS - il sera cohérent, sans temps d'arrêt - mais les coûts de performance n'en valent probablement pas la peine).
AWS a une mise à l'échelle automatique - qui sera en mesure de maintenir un nombre constant d'instances (même si ce nombre est 1) - vous déploieriez cependant à partir d'un instantané - donc si votre instantané n'est pas utile, la prémisse n'est pas très utile .
Un autre couple de points - vous pouvez déployer autant d'instances que vous le souhaitez à partir d'un instantané unique (contrairement à un volume EBS, qui ne peut être attaché qu'à une seule instance à un moment donné). En outre, les volumes EBS sont limités à utiliser dans une zone de disponibilité, tandis que les instantanés peuvent être utilisés dans une région.
Idéalement, avec un instantané, si votre serveur tombe en panne, vous pouvez simplement en lancer un nouveau en utilisant le dernier instantané - surtout si vous séparez votre volume racine de vos données, une mauvaise mise à jour devrait entraîner un minimum de temps d'arrêt (car vous transférer le volume EBS contenant vos données - et en prendre un instantané pour préserver tout ce qui pourrait être corrompu en raison d'une incohérence).
En remarque, Amazon déclare que le taux d'échec des volumes EBS augmente avec la quantité de données modifiées sur eux depuis le dernier instantané.
Recommandations finales
Lecture recommandée:
(Je crois que j'ai trop écrit, mais pas assez - mais j'espère que vous trouverez quelque chose qui vaut la peine d'être lu).
la source
Il est possible de créer un instantané d'un volume EBS en direct , mais vous devez vous assurer que le système de fichiers est dans un état cohérent, puis figé pendant le lancement de l'instantané. Tous les systèmes de fichiers ne le permettent pas, bien que ce soit certainement possible et la base de notre propre solution de sauvegarde.
Les instantanés EBS sont également assez bon marché car ils ne facturent que les données modifiées, et les frais de données sont très raisonnables en eux-mêmes et en dehors. Gardez cependant à l'esprit que cela est basé sur un changement de niveau de bloc, donc peut changer assez rapidement. Cela est également vrai entre les instantanés, seules les données modifiées entre les instantanés sont facturées. Pour vous donner une idée des coûts, nous payons <10 $ par mois pour le stockage des snapshots, et nous prenons des snapshots quotidiens, en conservant les 7 derniers quotidiens et les derniers mois pour des snapshots hebdomadaires, et nous avons 2 serveurs suivant ce schéma (~ 20 snapshots, Disques durs de 20 Go).
la source
Que diriez-vous d'une solution de sauvegarde bon marché et peu coûteuse comme Zmanda Cloud Backup? Nous l'utilisons pour sauvegarder environ 6 serveurs et 1 SQL Server et c'est seulement environ 10 $ par mois. Vous pouvez crypter vos données avec un certificat auto-signé et ils utilisent s3 pour stocker les données (il n'y a donc pas de frais de transfert de données si vous sauvegardez depuis EC2).
la source