Год назад Amazon запустил в отдельных регионах свой новый облачный продукт — Elastic File System. Этим летом «новинка» наконец-то добралась до Европы и России. Зачем вообще понадобился этот сервис, в чем его фишки и для чего он категорически не подойдет, мы кратко расспросили эксперта по AWS Кори Куинна (Corey Quinn).
О спикере
Кори Куинн: Проверенный спикер многих DevOps-конференций, специалист по AWS, известен рассылкой lastweekinaws.com. Инженер-менеджер и облачный стратег.
О сервисе
Elastic File System — файловое хранилище, которое упрощает работу с облаком для приложений, ориентированных на взаимодействие с обычной файловой системой. При этом за счет «облачности» есть возможность гибко настраивать его объем.
— На кого ориентирован сервис EFS?
Кори Куинн: В целом, сервис Amazon EFS направлен на замену инструментов NFS (с сетевой файловой системой). Поскольку Amazon Web Services (AWS) до сих пор не позволяет использовать NetApp в дата-центре us-east-1, пользователям исторически приходилось водружать собственную реализацию NFS.
В сценариях, где архитектура приложения требует совместного доступа к массивам данных, до недавнего времени это был единственный возможный вариант.
— В отличие от уже существовавшего сервиса Amazon S3, предоставляющего пользователям именно облачный интерфейс доступа к хранилищу из любой точки мира, EFS поддерживает идеологию блокировки файлов и прочие аспекты «классических» файловых систем. Существуют ли проблемы, которые может решить EFS, но не мог решить, к примеру, S3?
Кори Куинн: Большое преимущество Amazon EFS на фоне Amazon S3 заключается в том, что вам не нужно переписывать свои устаревшие приложения для работы с новыми концепциями хранения объектов. Вы можете просто использовать NFS так, как вы это делали всегда.
Отличный пример — Wordpress. Вместо того, чтобы обучать консоль, различные ноды и прочие компоненты правильному взаимодействию с Amazon S3, вы можете использовать один смонтированный том, который будет просто работать из коробки, без каких-либо изменений в приложениях. Во всех других отношениях, будем откровенны, EFS ужасен.
— Какие существуют альтернативы Amazon EFS? В чем их основные отличия?
Кори Куинн: Очевидно, что для многих задач Amazon S3 является лучшим выбором, правда, с оговоркой, что не все приложения поддерживают модель, в рамках которой объекты живут не на стороне API. Легко сидеть на вершине идеализированной башни из слоновой кости и говорить, что каждое используемое приложение должно быть переработано. Но рассуждая таким образом, мы игнорируем реальность, с которой сталкиваются многие предприятия. Им необходимо иное решение.
Кстати, если говорить об альтернативах, не стоит забывать и об Elastic Block Store. Он также работает хорошо. Однако единовременно подмонтировать его можно только к одному инстансу. Следовательно, его невозможно расшарить.
— Хотя изначально Amazon EFS ориентирован в том числе на IoT и обработку больших данных, есть ли в инфраструктуре AWS решение поинтереснее для данных аспектов применения?
Кори Куинн: В принципе, скоростные показатели S3 весьма неплохи, но тут надо ориентироваться на типы задач. Однако эту тему лучше обсудить с экспертами в данной области. IoT и BigData — это очень специфичная область. И, к сожалению, не моя специализация.
— EFS ориентирован на работу c инстансами Amazon EC2. Можно ли использовать его за пределами инфраструктуры AWS?
Кори Куинн: Это возможно, но во многих случаях овчинка не будет стоить выделки. Большинство существующих операционных систем не переварят задержки, которая возникнет при передаче данных через интернет в процессе того, что для них будет представляться локальными дисковыми операциями. Если подходить к процессу с официальной точки зрения, необходимо использовать AWS Direct Connect для доступа к EFS. Однако, будем откровенны, получить необходимый доступ можно и с помощью различных VPN-ухищрений.
— Можете ли Вы привести пример каких-то скрытых особенностей или проблем у сервиса?
Кори Куинн: Самая интересная скрытая «фишка» EFS заключается в том, что производительность хранилища масштабируется линейно и автоматически по мере роста объема хранимых данных. В результате единственный на сегодняшний день способ повысить производительность на имеющихся томах EFS — это положить туда большие объемы лишних данных. Таким образом, система увеличит лимит по операциям ввода/вывода в секунду в соответствии с объемом хранимой информации.
— Какие еще факторы оказывают наибольшее влияние на производительность сервиса?
Кори Куинн: Конечно же, наибольшую роль играет сценарий использования. Облако — гибкая структура. Для одних приложений драйвер обеспечивает низкую задержку ввода/вывода, а в других ситуациях организовывает массовое распараллеливание задачи.
Но существует ряд сценариев, где использование облачного хранилища нецелесообразно. Местами из-за сетевых ограничений, а где-то — из-за задержек при передаче данных, особенно в регионах с экономическими проблемами или низкой доступностью телекоммуникационных каналов. В целом, облако великолепно. Но это не значит, что его нужно использовать всегда и везде.
На нашей конференции DevOops 2017, которая пройдет 20 октября в Санкт-Петербурге, Кори Куинн представит доклад «Come scale away with me: solving for problems you don’t have». Кроме того, вас наверняка заинтересуют вот эти горячие темы:
О спикере
Кори Куинн: Проверенный спикер многих DevOps-конференций, специалист по AWS, известен рассылкой lastweekinaws.com. Инженер-менеджер и облачный стратег.
О сервисе
Elastic File System — файловое хранилище, которое упрощает работу с облаком для приложений, ориентированных на взаимодействие с обычной файловой системой. При этом за счет «облачности» есть возможность гибко настраивать его объем.
— На кого ориентирован сервис EFS?
Кори Куинн: В целом, сервис Amazon EFS направлен на замену инструментов NFS (с сетевой файловой системой). Поскольку Amazon Web Services (AWS) до сих пор не позволяет использовать NetApp в дата-центре us-east-1, пользователям исторически приходилось водружать собственную реализацию NFS.
В сценариях, где архитектура приложения требует совместного доступа к массивам данных, до недавнего времени это был единственный возможный вариант.
— В отличие от уже существовавшего сервиса Amazon S3, предоставляющего пользователям именно облачный интерфейс доступа к хранилищу из любой точки мира, EFS поддерживает идеологию блокировки файлов и прочие аспекты «классических» файловых систем. Существуют ли проблемы, которые может решить EFS, но не мог решить, к примеру, S3?
Кори Куинн: Большое преимущество Amazon EFS на фоне Amazon S3 заключается в том, что вам не нужно переписывать свои устаревшие приложения для работы с новыми концепциями хранения объектов. Вы можете просто использовать NFS так, как вы это делали всегда.
Отличный пример — Wordpress. Вместо того, чтобы обучать консоль, различные ноды и прочие компоненты правильному взаимодействию с Amazon S3, вы можете использовать один смонтированный том, который будет просто работать из коробки, без каких-либо изменений в приложениях. Во всех других отношениях, будем откровенны, EFS ужасен.
— Какие существуют альтернативы Amazon EFS? В чем их основные отличия?
Кори Куинн: Очевидно, что для многих задач Amazon S3 является лучшим выбором, правда, с оговоркой, что не все приложения поддерживают модель, в рамках которой объекты живут не на стороне API. Легко сидеть на вершине идеализированной башни из слоновой кости и говорить, что каждое используемое приложение должно быть переработано. Но рассуждая таким образом, мы игнорируем реальность, с которой сталкиваются многие предприятия. Им необходимо иное решение.
Кстати, если говорить об альтернативах, не стоит забывать и об Elastic Block Store. Он также работает хорошо. Однако единовременно подмонтировать его можно только к одному инстансу. Следовательно, его невозможно расшарить.
— Хотя изначально Amazon EFS ориентирован в том числе на IoT и обработку больших данных, есть ли в инфраструктуре AWS решение поинтереснее для данных аспектов применения?
Кори Куинн: В принципе, скоростные показатели S3 весьма неплохи, но тут надо ориентироваться на типы задач. Однако эту тему лучше обсудить с экспертами в данной области. IoT и BigData — это очень специфичная область. И, к сожалению, не моя специализация.
— EFS ориентирован на работу c инстансами Amazon EC2. Можно ли использовать его за пределами инфраструктуры AWS?
Кори Куинн: Это возможно, но во многих случаях овчинка не будет стоить выделки. Большинство существующих операционных систем не переварят задержки, которая возникнет при передаче данных через интернет в процессе того, что для них будет представляться локальными дисковыми операциями. Если подходить к процессу с официальной точки зрения, необходимо использовать AWS Direct Connect для доступа к EFS. Однако, будем откровенны, получить необходимый доступ можно и с помощью различных VPN-ухищрений.
— Можете ли Вы привести пример каких-то скрытых особенностей или проблем у сервиса?
Кори Куинн: Самая интересная скрытая «фишка» EFS заключается в том, что производительность хранилища масштабируется линейно и автоматически по мере роста объема хранимых данных. В результате единственный на сегодняшний день способ повысить производительность на имеющихся томах EFS — это положить туда большие объемы лишних данных. Таким образом, система увеличит лимит по операциям ввода/вывода в секунду в соответствии с объемом хранимой информации.
— Какие еще факторы оказывают наибольшее влияние на производительность сервиса?
Кори Куинн: Конечно же, наибольшую роль играет сценарий использования. Облако — гибкая структура. Для одних приложений драйвер обеспечивает низкую задержку ввода/вывода, а в других ситуациях организовывает массовое распараллеливание задачи.
Но существует ряд сценариев, где использование облачного хранилища нецелесообразно. Местами из-за сетевых ограничений, а где-то — из-за задержек при передаче данных, особенно в регионах с экономическими проблемами или низкой доступностью телекоммуникационных каналов. В целом, облако великолепно. Но это не значит, что его нужно использовать всегда и везде.
На нашей конференции DevOops 2017, которая пройдет 20 октября в Санкт-Петербурге, Кори Куинн представит доклад «Come scale away with me: solving for problems you don’t have». Кроме того, вас наверняка заинтересуют вот эти горячие темы:
- Ансамбль солёных поваров-кукловодов: сравниваем Ansible, SaltStack, Chef и Puppet (Андрей Филатов, Epam Systems)
- Расширяем k8s (Николай Рыжиков, Health Samurai)
- DevOps в масштабе: греческая трагедия в трёх актах (Барух Садогурский, JFrog и Леонид Игольник, CA Technologies)
- Troubleshooting & debugging production applications in Kubernetes (a.k.a. The Failing Demo Talk) (Ray Тsang, Google и Барух Садогурский, JFrog)
Комментарии (4)
potan
18.10.2017 18:37А за счет чего Elastic Block Store может работать лучше, чем Elastic File System?
vlreshet
18.10.2017 18:50Отличный пример — Wordpress. Вместо того, чтобы обучать консоль, различные ноды и прочие компоненты правильному взаимодействию с Amazon S3
Плохой пример. Wordpress — это PHP, а для него у официальной библиотеки s3 есть метод registerStreamWrapper, который перехватывает все обращения к файловой системе через обычные функции, и напрявляет их правильным образом на s3. Я так огромную древнюю CRM систему полностью перевёл на s3 в две строчки кода.
lolipop
18.10.2017 19:36Кори Куинн: Самая интересная скрытая «фишка» EFS заключается в том, что производительность хранилища масштабируется линейно и автоматически по мере роста объема хранимых данных. В результате единственный на сегодняшний день способ повысить производительность на имеющихся томах EFS — это положить туда большие объемы лишних данных. Таким образом, система увеличит лимит по операциям ввода/вывода в секунду в соответствии с объемом хранимой информации.
Напарывался на это. Фишка там в том, чтобы залить объемных файлов, чтобы лимиты на скорость повысились. Однако, делать это надо сразу же при создании efs, иначе(вроде, на следующий день) лимиты на скорость уже применились и новые файлы создаются с черепашьей скоростью. Для составления представления о скорости — папка с 3ГБ мелких файлов копировалась в efs около СУТОК.
dmitriylyalyuev
О да… Хватанул я этого "производительность хранилища масштабируется линейно и автоматически по мере роста объема хранимых данных"…
Если у вас всего 10ГБ данных и больше вам не надо — заливайте туда данные из /dev/null и желательно 1ТБ минимум. Тогда хоть как-то оно будет жить.
В противном случае — скорость на столько низкая, что использовать "это" нет никакой нормальной возможности. Я предпочел поднять EC2 инстанс с NFS внутри и монитировать его так же на ноды.