Pouvez-vous associer Amazon EBS à plusieurs instances?
Nous utilisons actuellement plusieurs serveurs Web accédant à un serveur mysql et à un serveur de fichiers. Pour passer au cloud, puis-je utiliser cette même configuration et associer EBS à plusieurs instances d'ordinateur ou quelle autre solution?
UPDATE (avril 2015): pour ce cas d'utilisation, vous devriez commencer à regarder le nouveau Amazon Elastic File System (EFS) , conçu pour être multiplié par l'attachement, 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 au bloc brut IO.
Vous trouverez ci-dessous une explication originale de la raison pour laquelle il est impossible de monter en toute sécurité un périphérique de bloc brut sur plusieurs ordinateurs.
ORIGINAL POST (2011):
Même si vous pouviez attacher un volume EBS à plusieurs instances, il s'agirait d'un _REALLY_BAD_IDEA_. Pour citer Kekoa, "c'est comme utiliser un disque dur dans deux ordinateurs à la fois"
Pourquoi est-ce une mauvaise idee? ... La raison pour laquelle vous ne pouvez pas attacher un volume à plusieurs instances est qu’EBS fournit une abstraction de "stockage en mode bloc" sur laquelle les clients exécutent un système de fichiers tel que 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 en mode bloc. Deux instances accédant au même système de fichiers finiraient presque certainement par des déchirures et une corruption des données.
En d'autres termes, le montage double d'un volume EBS ne fonctionnerait que si vous exécutiez un système de fichiers en cluster conçu pour partager un périphérique en mode bloc entre plusieurs ordinateurs. De plus, même cela ne suffirait pas. EBS aurait besoin d'être testé pour ce scénario et de s'assurer qu'il offre les mêmes garanties de cohérence que les autres solutions de périphérique de bloc partagé ... c'est-à-dire que les blocs ne sont pas mis en cache à des niveaux intermédiaires non partagés tels que le noyau Dom0, la couche Xen et le noyau DomU. Il faut également prendre en compte les performances de la synchronisation des blocs entre plusieurs clients: la plupart des systèmes de fichiers en cluster sont conçus pour fonctionner sur des réseaux SAN dédiés à haute vitesse, et non pour un Ethernet standard au mieux. Cela semble si simple, mais ce que vous demandez est une chose très anodine.
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 de sous-système de périphérique en bloc partagé. Plusieurs fois, une telle solution est en réalité plus efficace.
Dans votre cas, vous pouvez toujours avoir une seule instance/serveur de fichiers MySql accessible par plusieurs serveurs frontaux Web. Ce serveur de fichiers peut ensuite stocker ses données sur un volume EBS, ce qui vous permet d'effectuer des sauvegardes d'instantanés nocturnes. Si l'instance qui exécute le serveur de fichiers est perdue, vous pouvez détacher le volume EBS, le rattacher à une nouvelle instance de serveur de fichiers et le restaurer et l'exécuter en quelques minutes.
"Y at-il quelque chose comme S3 en tant que système de fichiers?" - Oui et non. Oui, il existe des solutions tierces telles que s3fs qui fonctionnent "bien", mais sous le capot, elles doivent toujours passer des appels de service Web relativement coûteux pour chaque lecture/écriture. Pour un répertoire d'outils partagés, fonctionne très bien. Pour le type d'utilisation en cluster FS que vous voyez dans le monde du calcul intensif, aucune chance. Pour faire mieux, vous auriez besoin d’un nouveau service fournissant un protocole binaire orienté connexion, tel que NFS. Offrir un tel système de fichiers multi-montés avec des performances et un comportement raisonnables serait un atout majeur pour EC2. Je suis depuis longtemps un avocat pour que Amazon construise quelque chose comme ça.
Non, cela revient à 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 passant au cloud, vous pouvez avoir exactement la même configuration, mais vous pouvez éventuellement remplacer le serveur de fichiers par S3 ou avoir toutes vos instances connectées à votre serveur de fichiers.
Vous avez beaucoup d'options, mais partager un disque dur entre des instances n'est probablement pas la meilleure option.
Non, selon la documentation EBS: "Un volume ne peut être associé qu'à une seule instance à la fois".
Comment utilisez-vous le stockage partagé actuellement? S'il ne s'agit que de servir des fichiers à partir du serveur de fichiers, avez-vous envisagé de configurer un système de sorte que vous puissiez envoyer par proxy des demandes à un processus sur le serveur de fichiers plutôt que de laisser les serveurs Web traiter ces fichiers?
Je suis à peu près sûr que vous ne pouvez pas, mais vous pouvez cloner un EBS et le joindre à une autre instance.
Ceci est utile pour des 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 magasin de blocs unique.
Plusieurs serveurs Web accédant à MySQL Server et au serveur de fichiers sont normaux dans AWS. Certaines des meilleures pratiques à suivre pour l'architecture susmentionnée sont les suivantes:
Point 1) MySQL sur EC2 peut être configuré comme maître-esclave en mode async/semi-sync dans AWS. EBS-OPT + PIOPS en RAID 0 est recommandé pour une 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 de lecture RDS peuvent être associé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 communiquer simultanément avec GlusterFS sur AWS infra.
Point 4) Si votre application peut être intégrée à S3 en tant que magasin de fichiers, cela est préférable en raison de la stabilité apportée à l’architecture. Vous pouvez également accéder à S3 à l'aide d'outils tels que S3Fuse à partir de votre application.
Pourquoi ne créez-vous pas une instance avec volume et sshfs sur ce volume dans d'autres instances?
Il existe quelque chose dans le monde informatique appelé système de fichiers en cluster, 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 répondu "oui" n'ont pas répondu à la question, mais à une question différente. Si EFS est simplement un service NFS, il ne s'agit pas de la réponse à la question telle que formulée à l'origine. Et peu importe que EFS soit "déployé dans toutes les zones" ou non, car vous pouvez créer votre propre instance NFS de manière autonome, et avoir plusieurs serveurs monter NFS. Ce n'est pas quelque chose de 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 dans les larmes" sont dans l'erreur. Nous avons monté plusieurs disques sur plusieurs serveurs pendant des décennies. Si vous avez déjà travaillé avec un SAN (réseau de stockage), il est tout à fait normal de connecter le même périphérique à plusieurs nœuds via FibreChannel SAN. Ainsi, quiconque a exploité des serveurs il y a une décennie avant que les serveurs de virtualisation/cloud ne soient devenus omniprésents a une certaine exposition à cela.
Bientôt, il y avait des systèmes de fichiers en cluster où deux systèmes pouvaient lire et écrire exactement sur le même volume. Je pense que cela a déjà commencé avec l’histoire de VAX et Alpha VMS. Les systèmes de fichiers en cluster utilisent un schéma d'exclusion mutuelle distribuée pour pouvoir manipuler directement des blocs.
L'avantage de monter le même disque sur plusieurs nœuds est la rapidité et la réduction des points uniques de pannes.
Or, les systèmes de fichiers en cluster ne sont pas devenus extrêmement populaires dans le secteur de l'hébergement "grand public", c'est vrai. Et ils sont compliqués et ont des pièges. Mais vous n'avez même pas besoin d'un système de fichiers en cluster pour utiliser un disque connecté à plusieurs nœuds de calcul. Que faire 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 que celui 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 batteries de serveurs évolutives rapidement. Vous pouvez avoir votre disque système principal tout préparé et utiliser juste un très 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 du/en mode lecture-écriture, vous pouvez insérer une Union-FS à 3 couches:
- Le disque système principal en lecture seule, avec l’installation De démarrage, du noyau et de l’utilisateur.
- Un système de fichiers de configuration, avec seulement les quelques fichiers .__ (principalement dans/etc) spécifiques au serveur individuel. Ce disque Peut être écrit par un autre serveur pour préparer le démarrage d’une instance .____new. Voici des exemples de fichiers:/etc/hostname et Très peu de fichiers de configuration devant rester différents par noeud.
- Le disque inscriptible, dont vous n’avez peut-être pas besoin du tout, pourrait être juste /Tmp en tant que système de fichiers en mémoire.
Donc, oui, la question avait beaucoup de sens, et malheureusement la réponse est (toujours) "Non". Et non, NFS n’est pas un excellent substitut à 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 l’accès au même périphérique de blocage physique.
PS: J'aurais aimé soumettre une version abrégée de ceci comme 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 inclure mon point pourquoi 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 accédez à (et partagez) des périphériques de blocage physiques. Cela faciliterait le partage du disque de démarrage, vous évitant ainsi de configurer le démarrage réseau bootd, qui peut s'avérer fastidieux. Mais sur AWS, il n’existe pas non plus de démarrage réseau.