Nous utilisons actuellement plusieurs serveurs web qui accèdent à un serveur mysql et à un serveur de fichiers. Si j'envisage de m'installer dans le nuage, puis-je utiliser la même configuration et attacher l'EBS à plusieurs instances de machines ou quelle est une autre solution ?
Réponses
Trop de publicités?Même si vous pouviez attacher un volume EBS à plus d'une instance, ce serait une _TRES MAUVAISE_ IDÉE_. Pour citer Kekoa, "c'est comme utiliser un disque dur dans deux ordinateurs à la fois".
Pourquoi est-ce une mauvaise idée ? ... La raison pour laquelle vous ne pouvez pas attacher un volume à plus d'une instance est que 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 aboutiraient presque certainement à des déchirures et à la corruption des données.
En d'autres termes, le double montage d'un volume EBS ne fonctionnerait que si vous exécutez un système de fichiers en cluster conçu pour partager un périphérique de bloc entre plusieurs machines. En outre, même cela ne serait pas suffisant. Il faudrait tester EBS pour ce scénario et s'assurer qu'il offre les mêmes garanties de cohérence que les autres solutions 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 grappe 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 peu triviale.
Sinon, voyez 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 disposer d'un sous-système de périphérique de bloc partagé. Une telle solution est souvent plus efficace.
Dans votre cas, vous pouvez toujours avoir une seule instance MySql / serveur de fichiers à laquelle accèdent plusieurs frontaux Web. Ce serveur de fichiers pourrait alors stocker ses données sur un volume EBS, ce qui vous permettrait 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.
"Y a-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 qui, sous le capot, doivent encore faire des appels de service web relativement coûteux pour chaque lecture/écriture. Pour un répertoire d'outils partagé, cela fonctionne très bien. Pour le type d'utilisation de FS en cluster que l'on voit dans le monde du HPC, aucune chance. Pour faire mieux, il faudrait un nouveau service qui fournisse un protocole binaire orienté connexion, comme NFS. Proposer un tel système de fichiers multi-montés avec des performances et un comportement raisonnables serait un ajout de fonctionnalité formidable pour EC2. Je plaide depuis longtemps pour qu'Amazon construise quelque chose de ce genre.
Non, c'est comme utiliser un disque dur dans deux ordinateurs.
Si vous voulez des données partagées, vous pouvez configurer un serveur auquel toutes vos instances peuvent accéder. Si vous souhaitez une simple zone de stockage 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 faire en sorte 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 uniquement pour servir des fichiers à partir du serveur de fichiers, avez-vous envisagé de mettre en place un système permettant d'envoyer certaines requêtes à un processus sur le serveur de fichiers plutôt que de demander aux serveurs web de servir ces fichiers ?
Plusieurs serveurs Web accédant à un serveur MySQL et à un serveur de fichiers sont normaux dans AWS. Voici quelques-unes des meilleures pratiques à suivre pour l'architecture mentionnée ci-dessus :
Point 1) MySQL sur EC2 peut être configuré comme maître-esclave en mode asynchrone/semi-synchrone dans AWS. EBS-OPT+PIOPS en RAID 0 est recommandé pour une base de données haute performance.
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 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 en utilisant EBS. Plusieurs serveurs Web peuvent communiquer simultanément avec un seul GlusterFS sur l'infrastructure AWS.
Point 4) Si votre application peut être intégrée à S3 comme magasin de fichiers, il est préférable de le faire en raison de la stabilité qu'il apporte à l'architecture. Vous pouvez également accéder à S3 en utilisant des outils comme S3fuse à partir de votre application.
- Réponses précédentes
- Plus de réponses