Pouvez-vous attacher Amazon EBS à plusieurs instances?

Nous utilisons actuellement plusieurs serveurs Web accédant à un serveur mysql et un serveur de fichiers. Si vous envisagez de passer au cloud, puis-je utiliser cette même configuration et attacher l'EBS à plusieurs instances de machine ou quelle est une autre solution?

MISE À JOUR (avril 2015) : Pour ce cas d'utilisation, vous devriez commencer à regarder le nouvel Amazon Elastic File System (EFS) , qui est conçu pour être multiplié exactement comme vous le souhaitez. La principale différence entre EFS et EBS est qu'ils fournissent des abstractions différentes: EFS expose le protocole NFSv4, tandis qu'EBS fournit un accès aux E / S par blocs bruts.

Vous trouverez ci-dessous mon explication originale sur les raisons pour lesquelles il n'est pas possible de monter en toute sécurité un périphérique bloc brut sur plusieurs machines.

POSTE ORIGINAL (2011):

Même si vous pouviez obtenir un volume EBS attaché à plusieurs instances, ce serait un _REALLY_BAD_IDEA_. Pour citer Kekoa, "c'est comme utiliser un disque dur sur deux ordinateurs à la fois"

pourquoi est-ce une mauvaise idee? ... La raison pour laquelle vous ne pouvez pas attacher un volume à plus d'une instance est qu'EBS fournit une abstraction de "stockage en bloc" sur laquelle les clients exécutent un système de fichiers comme ext2 / ext3 / etc. La plupart de ces systèmes de fichiers (par exemple, ext2 / 3, FAT, NTFS, etc.) sont écrits en supposant qu'ils ont un accès exclusif au périphérique bloc. Deux instances accédant au même système de fichiers se termineraient presque certainement par des larmes et une corruption des données.

En d'autres termes, le double montage d'un volume EBS ne fonctionnerait que si vous exécutiez un système de fichiers de cluster conçu pour partager un périphérique bloc entre plusieurs machines. De plus, même cela ne suffirait pas. EBS devrait être testé pour ce scénario et pour s'assurer qu'il offre les mêmes garanties de cohérence que les autres solutions de périphériques de blocs partagés ... c'est-à-dire que les blocs ne sont pas mis en cache à des niveaux intermédiaires non partagés comme le noyau Dom0, la couche Xen, et le noyau DomU. Et puis il y a les considérations de performances liées à la synchronisation des blocs entre plusieurs clients - la plupart des systèmes de fichiers en cluster sont conçus pour fonctionner sur des SAN dédiés à haut débit, et non sur un réseau Ethernet de base. Cela semble si simple, mais ce que vous demandez est une chose très non triviale.

Vous pouvez également voir si votre scénario de partage de données peut être NFS, SMB / CIFS, SimpleDB ou S3. Ces solutions utilisent toutes des protocoles de couche supérieure destinés à partager des fichiers sans avoir un sous-système de périphérique bloc partagé. Plusieurs fois, une telle solution est en fait plus efficace.

Dans votre cas, vous pouvez toujours avoir une seule instance / serveur de fichiers MySql accessible par plusieurs frontaux Web. Ce serveur de fichiers pourrait ensuite stocker ses données sur un volume EBS, ce qui vous permet d'effectuer des sauvegardes instantanées nocturnes. Si l'instance exécutant le serveur de fichiers est perdue, vous pouvez détacher le volume EBS et le rattacher à une nouvelle instance de serveur de fichiers et être de nouveau opérationnel en quelques minutes.

"Existe-t-il quelque chose comme S3 en tant que système de fichiers?" - Oui et non. Oui, il existe des solutions tierces comme s3fs qui fonctionnent "bien", mais sous le capot, elles doivent encore faire des appels de service Web relativement coûteux pour chaque lecture / écriture. Pour un répertoire d'outils partagé, fonctionne très bien. Pour le type d'utilisation FS en cluster que vous voyez dans le monde HPC, pas une chance. Pour faire mieux, vous auriez besoin d'un nouveau service qui fournit un protocole orienté connexion binaire, comme NFS. Offrir un tel système de fichiers multi-monté avec des performances et un comportement raisonnables serait un excellent complément de fonctionnalités pour EC2. Je suis depuis longtemps un défenseur d'Amazon pour construire quelque chose comme ça.

Mise à jour (2020) C'est maintenant possible!

Cela est désormais possible avec les types d'instances les plus récents exécutés dans AWS Nitro dans la même zone de disponibilité. Il y a quelques mises en garde, mais c'est idéal pour certains cas d'utilisation qui nécessitent la vitesse d'EBS et où EFS n'est pas faisable.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

Message original (2009)

Non, c'est comme utiliser un disque dur sur deux ordinateurs.

Si vous souhaitez partager des données, vous pouvez configurer un serveur auquel toutes vos instances peuvent accéder. Si vous souhaitez une zone de stockage simple pour toutes vos instances, vous pouvez utiliser le service de stockage S3 d'Amazon pour stocker des données distribuées et évolutives.

En migrant vers le cloud, vous pouvez avoir exactement la même configuration, mais vous pouvez éventuellement remplacer le serveur de fichiers par S3 ou que toutes vos instances se connectent à votre serveur de fichiers.

Vous avez beaucoup d'options, mais le partage d'un disque dur entre les instances n'est probablement pas la meilleure option.

Non, selon la documentation EBS: "Un volume ne peut être attaché qu'à une seule instance à la fois".

Comment utilisez-vous le stockage partagé actuellement? Si c'est juste pour servir des fichiers à partir du serveur de fichiers, avez-vous envisagé de configurer un système afin que vous puissiez envoyer certaines requêtes à un processus sur le serveur de fichiers plutôt que de laisser les serveurs Web servir ces fichiers?

Je suis assez sûr que vous ne pouvez pas, mais vous pouvez cloner un EBS et le joindre à une autre instance.

Ceci est utile pour les ensembles de données fixes ou pour tester des données `` réelles '' mais ne permet pas à plus d'une instance de fonctionner sur un seul magasin de blocs

L'accès au serveur MySQL et au serveur de fichiers par plusieurs serveurs Web est normal dans AWS. Certaines des meilleures pratiques à suivre pour l'architecture mentionnée ci-dessus sont:

Point 1) MySQL sur EC2 peut être configuré en tant que maître-esclave en mode asynchrone / semi-synchro dans AWS. EBS-OPT + PIOPS en RAID 0 est recommandé pour la base de données hautes performances

Point 2) Vous pouvez également utiliser le mode Amazon RDS + Multi-AZ. Pour la mise à l'échelle en lecture, plusieurs répliques en lecture RDS peuvent être attachées à MySQL RDS.

Point 3) Le volume EBS ne peut pas être attaché à plusieurs EC2 simultanément. Vous pouvez créer un serveur de fichiers basé sur GlusterFS sur Amazon EC2 à l'aide d'EBS. Plusieurs serveurs Web peuvent parler simultanément à un seul GlusterFS sur AWS infra.

Point 4) Dans le cas où votre application peut être intégrée à S3 en tant que magasin de fichiers, elle est préférable en raison de la stabilité qu'elle apporte à l'architecture. Vous pouvez également accéder à S3 à l'aide d'outils tels que S3fuse depuis votre application.

EBS vient d'annoncer que c'est possible: https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/

Il existe quelque chose dans le monde informatique connu sous le nom de Clustered Filesystem, Redhat GFS, Oracle OCFS2, Veritas CFS ...

La réponse courte est un «non» catégorique. D'autres l'ont dit ci-dessus.

Ceux qui ont dit «oui» n'ont pas répondu à la question, mais à une question différente. Si EFS est juste un service NFS, alors ce n'est pas la réponse à la question comme indiqué à l'origine. Et peu importe si EFS est "déployé dans toutes les zones" ou non, car vous pouvez faire votre propre instance NFS tout à fait et avoir plusieurs serveurs monter NFS. Ce n'est pas nouveau, nous l'avons déjà fait en 1992. SMB et sshfs, ce ne sont que des moyens de monter des lecteurs en tant que système de fichiers distant.

Ceux qui ont dit «pourquoi voudriez-vous faire cela» ou «tout se terminera en larmes» ont tort. Nous montons plusieurs disques sur plusieurs serveurs depuis des décennies. Si vous avez déjà travaillé avec un SAN (Storage Area Network), la possibilité de connecter le même périphérique à plusieurs nœuds généralement via FibreChannel SAN est tout à fait normale. Ainsi, quiconque a exécuté des serveurs il y a dix ans avant que les serveurs de virtualisation / cloud ne deviennent omniprésents y est exposé.

Bientôt, il y eut des systèmes de fichiers en cluster où deux systèmes pouvaient lire et écrire exactement sur le même volume. Je crois que cela a déjà commencé avec le temps VAX et Alpha VMS dans l'histoire. Les systèmes de fichiers en cluster utilisent un schéma d'exclusion mutuelle distribué pour pouvoir manipuler directement les blocs.

L'avantage de monter le même disque sur plusieurs nœuds est la vitesse et la réduction des points de défaillance uniques.

Maintenant, les systèmes de fichiers en cluster ne sont pas devenus très populaires dans le secteur de l'hébergement «grand public», c'est vrai. Et ils sont compliqués et comportent des écueils. Mais vous n'avez même pas besoin d'un système de fichiers en cluster pour utiliser un disque attaché à plusieurs nœuds de calcul. Et si vous voulez un lecteur en lecture seule? Vous n'avez même pas besoin d'un système de fichiers en cluster! Vous venez de mettre dans votre / etc / fstab le même périphérique physique en lecture seule (ro). Ensuite, vous montez sur 2 ou 10 serveurs EC2 et tous peuvent lire directement à partir de cet appareil!

Il existe un cas d'utilisation évident pour cela dans le monde des serveurs cloud lors de la création de fermes à évolution rapide. Vous pouvez préparer votre disque système principal et n'utiliser qu'un tout petit disque de démarrage et de configuration pour chacun des serveurs. Vous pouvez même tous les faire démarrer à partir du même disque de démarrage, et juste avant le remontage de / en mode lecture-écriture, vous pouvez insérer un Union-FS avec 3 couches:

1. Le disque système principal en lecture seule, avec l'installation de démarrage, du noyau et de l'espace utilisateur
2. Un système de fichiers de configuration, avec seulement quelques fichiers (principalement dans / etc) qui sont spécifiques au serveur individuel. Ce disque peut être écrit par un autre serveur pour préparer le démarrage d'une nouvelle instance. Les fichiers d'exemple ici seraient / etc / hostname et juste très peu de fichiers de configuration qui doivent rester différents par nœud.
3. Le disque inscriptible, dont vous n'avez peut-être pas besoin du tout, peut être uniquement / tmp en tant que système de fichiers mémoire.

Donc, oui, la question avait beaucoup de sens, et malheureusement la réponse est (toujours) "non". Et aucun NFS n'est pas un excellent remplacement pour ce cas d'utilisation car il pénalise toute activité de lecture à partir du disque système. Cependant, le démarrage réseau à partir d'un disque système NFS est la seule alternative à la mise en œuvre du cas d'utilisation que j'ai décrit ci-dessus. Malheureusement, la configuration de l'agent de démarrage réseau et de NFS est beaucoup plus délicate que d'accéder simplement au même périphérique de bloc physique.

PS: J'aurais aimé soumettre une version plus courte de ceci en tant que commentaires, mais je ne peux pas à cause du seuil ridicule de 51 points de crédit, donc je dois écrire une réponse avec le même "Non" essentiel mais pour inclure mon point pourquoi c'est une question pertinente qui n'a pas reçu de réponse méritée.

PPS: Je viens de trouver quelqu'un chez StackExchange qui mentionne iSCSI. iSCSI est un peu comme NFS, mais logiquement comme un SAN FibreChannel. Vous pouvez accéder (et partager) des périphériques de bloc physiques. Cela faciliterait le partage du disque de démarrage afin que vous n'ayez pas besoin de configurer le démarrage du réseau bootd, ce qui peut être délicat. Mais sur AWS, il n'y a pas non plus de démarrage réseau disponible.

Bien qu'EBS n'autorisait auparavant qu'une seule instance EC2 à être attachée à un volume donné, l'attachement multiple est désormais possible, au moins pour les volumes io1. Pour plus d'informations, consultez cet article de blog AWS .

Pourquoi ne créez-vous pas une instance avec volume et sshfs sur ce volume dans d'autres instances?

Vous pouvez utiliser totalement un lecteur sur plusieurs serveurs dans AWS. J'utilise sshfs pour monter un lecteur externe et le partager avec plusieurs serveurs dans EC2.

La raison pour laquelle j'avais besoin de connecter un seul lecteur à plusieurs serveurs est d'avoir un seul endroit pour placer toutes mes sauvegardes avant de les retirer en local.