En utilisant AWS re:Post, vous acceptez les AWS re:Post Conditions d’utilisation
AWS re:Postre:Post

Using the EBS io2 Volume with Multi-Attach enabled on different EC2 instances

0

We have a EBS io2 Volume with Multi-Attach enabled that we are attaching and mounting to 2 different EC2 instances, but it only shows the files on the 2nd instance that were available at the point when the volume is mounted but does not show any changes being made to them on the 1st instance. We need to restart the instance and mount the volume again to see the new ones again.

That is not much useful when we want to even just check the files or see any changes on the drive.

We have the auto mounting on instance start setup in the fstab file with the following command UUID=<my-ebs-volume-uuid> /shared xfs defaults,nofail 0 2

We also auto mount another efs volume using the following command in fstab file, which works fine and also reflects the changes on both the instances <my-efs-id>.efs.eu-central-1.amazonaws.com:/ /efs nfs4 defaults,_netdev 0 0

Does anyone have an idea what we might be doing wrong for the multi-attach EBS volume?

Sujets
CalculStockage
Balises
Amazon EC2StockageAmazon Elastic Block Store
Langue
English
Singh
demandé il y a 3 mois361 vues
1 réponse
2
Réponse acceptée

Simply attaching the volume to multiple instances doesn’t mean your filesystem would support multiple writers/readers. Multi attach use cases are explained in this blog https://aws.amazon.com/blogs/storage/delivering-instant-data-sharing-with-multi-attach-enabled-amazon-ebs/

profile picture
EXPERT
Kallu
répondu il y a 3 mois
profile picture
EXPERT
Riku_Kobayashi
vérifié il y a 3 mois
  • Singh
    il y a 3 mois

    Thanks @Kallu for the link explaining the issue. So that means that by default the multi-attach volume can't be used as a shared storage on multiple ec2 instances without setting them up using the CVM for taking instant snapshots. I guess that would also create significant cost increases for running such a setup.

    Ideally using EFS would have worked for our use case, but since there are substantial latency issues for hundreds of read/write operations on different files on it, unfortunately in our load tests the lags became too large to work with it. Hence this was being tried out as an auto-scaling option with the nodejs application with a shared storage. Thanks again for the help.

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions

Contenus pertinents