Usando AWS re:Post, accetti AWS re:Post Termini di utilizzo
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?

Argomenti
ComputazionaliArchiviazione
Tag
Amazon EC2ArchiviazioneAmazon Elastic Block Store
Lingua
English
Singh
posta 3 mesi fa361 visualizzazioni
1 Risposta
2
Risposta accettata

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
ESPERTO
Kallu
con risposta 3 mesi fa
profile picture
ESPERTO
Riku_Kobayashi
verificato 3 mesi fa
  • Singh
    3 mesi fa

    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.

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande

Contenuto pertinente