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.
- La méthode recommandée consiste à détacher le volume, à le prendre en photo et à le rattacher - ce qui n'est généralement pas pratique.
- La deuxième meilleure option consiste à vider les caches d'écriture sur le disque, à geler le système de fichiers et à prendre votre instantané.
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:
- Volumes EBS inaccessibles:
- RAID1 - inutile, car vous ne pouvez pas accéder aux données
- bin-log - inutile, sauf si vous l'avez exporté vers S3 - probablement un délai si vous le faites
- L'instance se termine de façon inattendue:
- RAID1 - vos disques sont disponibles, mais pas cohérents, votre base de données peut récupérer de l'incohérence de son propre chef
- bin-log - vos données doivent être accessibles, bien que vous deviez peut-être revoir les derniers événements
- Quelqu'un exécute DROP DATABASE en tant que root:
- RAID1 - vous avez deux copies parfaites d'une base de données inexistante
- bin-log - vous devriez pouvoir rejouer les événements juste avant la commande, donc vous devriez être ok
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
- Utilisez des instantanés - ils sont excellents - ils réduisent les temps d'arrêt beaucoup plus qu'ils ne les provoquent
- Séparer les données et le volume racine, peut-être même placer les bases de données sur leur propre volume, et un instantané avant les mises à jour si nécessaire
- Utilisez le bin-log pour rester aussi `` chaud '' que possible - téléchargez-le (compressé) sur S3
- Assurez-vous d'obtenir réellement les données de l'instance (même si les données sont intactes sur un volume EBS, le volume lui-même peut être temporairement inaccessible).
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).