При изменении #EBS с обычного на #iops, нужно учитывать, что эта операция может занять некоторое время (до 40 минут для 200ГБ), а вернуть обратно (на обычный) можно будет лишь через шесть часов, иначе #error:

Wait at least 6 hours between modifications per EBS volume.

Кроме того, операция возвращения будет ещё более длительной (раза в два дольше - до двух часов на 200ГБ).

Автоматизация преобразования #NVMe типов #EBS #volume вида /dev/nvme0n1 в обычные /dev/xvdf:

https://github.com/oogali/ebs-automatic-nvme-mapping

Проблема актуальна для новых Nitro-based виртуалок (C5/M5/T3/etc), где в качестве EBS используются NVMe block devices.

⁠Увеличение EC2 диска

Просто увеличить размер диска (#EBS #Volume) через AWS Console не составляет труда. Для пущей безопасности в любом случае лучше сделать перед этим снэпшот.

Главное не забыть, что кроме увеличения диска, после требуется ещё и увеличение раздела, иначе доступное пространство не изменится.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

Это простая, частая и обычно хорошо запоминающаяся ошибка — будет более полезно новичкам, но также и напоминание тем, у кого в очередной раз «всё забилось логами».

⁠Выбор типа EBS

Полезная статья по выбору #EBS:

https://aws.amazon.com/blogs/storage/maximizing-microsoft-sql-server-performance-with-amazon-ebs/

#EC2

EBS Volumes + Multi-Attach

Теперь на смешной вопрос новичков, а можно ли примонтировать один EBS диск к двум инстансам, вам придётся сдержать свой сарказм и ответить - да, можно:

https://aws.amazon.com/blogs/aws/new-multi-attach-for-provisioned-iops-io1-amazon-ebs-volumes/

Nitro-based системы продолжают удивлять и даже, вот, как теперь, обескураживать. Действительно, теперь можно элементарно подцепить один диск к нескольким инстансам. Они все смогут туда и писать и читать как на обычный диск. Просто сказка!

Подводные камни EBS io1 Volumes Multi-Attach

Ох, их есть, всё не просто так во всех смыслах.

Цена

Ну, для начала, собственно, это лишь для io1 (Provisioned IOPS дисков), т.е., как минимум, банально дороже (по сравнению с gp2 General Purpose SSD). Как минимум на треть для больших объёмов и в разы для маленьких. Но тут понятно и каждый сможет выбрать и посчитать.

EFS Killer? (спойлер - нет)

Далее - консистентность. Возможность монтировать к нескольким инстансам теперь есть, но кто позаботится о том, чтобы несколько пишущих одновременно на такой диск не потёрли сделанное соседом? Ответ - вы, ваше приложение. Вам дали возможность, а вот, чтобы было всё пучком - давайте, уж, сами. А если нет - используйте EFS, где за вас такое (с)делает Амазон.

В том числе поэтому выход данной фичи не заменит (и не убьёт) EFS, которой мы пользовались раньше для реализации подобного функционала. Опять же, EFS это MultiAZ, а диск, понятно, находится в какой-то конкретной одной подзоне. И, наконец, EFS масштабируется по объёму, что не сделает EBS Multi-Attach. Так что, нет, EFS никуда не денется. Хотя, конечно, для простых случаев, его можно будет заменить.

Файловая система

В примере по ссылке выше лихо показывается, как такое делается на файловой системе XFS, которая ничего не знает про кластерность и не заботится о подобных вещах. Если вы озаботитесь - тогда это OCFS или GFS2.

Способы применения

Однако, если мы подцепим диск и настроим, чтобы каждый инстанс писал в свою директорию (например, дружно складывая на такой логи с именем хоста в пути) - получим простую (с той же XFS) и при этом рабочую конструкцию.

Или когда один пишет, а все остальные лишь читают. И куча других вариантов, где, собственно, и получается, что Вы забодитесь о консистентности (учитывая возможные проблемы чтения/записи, а потому избегая их возникновения способом взаимодействия).

Сходу видятся способы применения для Warm DR - это когда основная система трудится, а другая стоит под парами и готова сразу же подхватить знамя, как только упадёт главная (и для этого к ней примонтирован тот же диск, с которым она не работает, пока работает-жива основная).

Опять же кубернетовское общество сейчас возрадуется и наверняка что-то понапридумывает для задействования в качестве Persistent Storage. В общем, применений Multi-Attach for Provisioned IOPS (io1) EBS Volumes наверняка будет не мало - поделитесь своими вариантами в комментариях.

В любом случае - отличная фича, нужно осваивать.

#EBS

В официальном разделе FAQ для Amazon EBS был добавлен следующий пункт:

Q: Can my application use Multi-Attach?

If your application does not require storage layer coordination of write operations, such as a read-only application or it enforces application level IO fencing, then your application can use Multi-Attach.

Он касается недавно вышедшей фичи EBS Multi-Attach, дающей возможность примонтировать один и тот же диск к нескольким виртуалкам сразу и что эту действительно полезную возможность нужно применять с головой. Потому, в частности, добавлю, что у файловой системы XFS есть её кластерный вариант - CXFS:

http://csweb.cs.wfu.edu/~torgerse/Kokua/Irix_6.5.21_doc_cd/usr/share/Insight/library/SGI_bookshelves/SGI_Admin/books/CXFS_AG/sgi_html/ch01.html

#EBS

Когда нужно в каком-то аккаунте почистить орды кем-то наделанных EBS снэпшотов и AMI-образов, то вручную кликать можно устать. Для автоматизации процесса подойдёт простая утилитка:

https://github.com/bonclay7/aws-amicleaner

#EBS #AMI

⁠Увеличение EBS диска на ходу

Если когда внезапно кончается место, вы по привычке останавливаете виртуалку, чтобы докинуть ей пространства, то наверняка вы пропустили, что для всех современных виртуалок есть фича Amazon EBS Elastic Volumes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html

То есть не обязательно тормозить инстанс, чтобы докинуть места на системный диск, можно это сделать в процессе (см. картинку).

Официальная ссылка на решение такой проблемы:

https://aws.amazon.com/premiumsupport/knowledge-center/expand-root-ebs-linux/

#EBS

Best Practices для шифрования EBS дисков:

https://aws.amazon.com/blogs/compute/must-know-best-practices-for-amazon-ebs-encryption/

Некоторые всегда полезные моменты по шифрованию:

🔹Совсем старые типы виртуалок (C1, M1, M2, T1) не поддерживают EBS шифрование
🔹Зашифрованный AMI нельзя сделать публичным
🔹Зашифрованный с помощью дефолтного ключа (AWS Managed) образ нельзя расшарить — для этого нужно шифровать с помощью AWS managed CMK

#EBS #best_practices

​​Новые EBS диски io2 — стократное увеличение надёжности и 500 иопсов на гигабайт!

https://aws.amazon.com/blogs/aws/new-ebs-volume-type-io2-more-iops-gib-higher-durability/

Да, обратите внимание - io2 стоит столько же, сколько io1.

Так что при создании стоит выбирать io2, а для текущих дисков — правая клавиша, Modify Volume и получаем все преимущества io2 за те же деньги!

#EBS