Amazon EFS работает быстрее, когда там много данных

    Год назад 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». Кроме того, вас наверняка заинтересуют вот эти горячие темы:

    • +19
    • 4,8k
    • 4
    JUG.ru Group 1 357,00
    Конференции для взрослых. Java, .NET, JS и др. 18+
    Поделиться публикацией
    Комментарии 4
    • +1

      О да… Хватанул я этого "производительность хранилища масштабируется линейно и автоматически по мере роста объема хранимых данных"…


      Если у вас всего 10ГБ данных и больше вам не надо — заливайте туда данные из /dev/null и желательно 1ТБ минимум. Тогда хоть как-то оно будет жить.


      В противном случае — скорость на столько низкая, что использовать "это" нет никакой нормальной возможности. Я предпочел поднять EC2 инстанс с NFS внутри и монитировать его так же на ноды.

      • 0
        А за счет чего Elastic Block Store может работать лучше, чем Elastic File System?
        • 0
          Отличный пример — Wordpress. Вместо того, чтобы обучать консоль, различные ноды и прочие компоненты правильному взаимодействию с Amazon S3
          Плохой пример. Wordpress — это PHP, а для него у официальной библиотеки s3 есть метод registerStreamWrapper, который перехватывает все обращения к файловой системе через обычные функции, и напрявляет их правильным образом на s3. Я так огромную древнюю CRM систему полностью перевёл на s3 в две строчки кода.
          • +1
            Кори Куинн: Самая интересная скрытая «фишка» EFS заключается в том, что производительность хранилища масштабируется линейно и автоматически по мере роста объема хранимых данных. В результате единственный на сегодняшний день способ повысить производительность на имеющихся томах EFS — это положить туда большие объемы лишних данных. Таким образом, система увеличит лимит по операциям ввода/вывода в секунду в соответствии с объемом хранимой информации.

            Напарывался на это. Фишка там в том, чтобы залить объемных файлов, чтобы лимиты на скорость повысились. Однако, делать это надо сразу же при создании efs, иначе(вроде, на следующий день) лимиты на скорость уже применились и новые файлы создаются с черепашьей скоростью. Для составления представления о скорости — папка с 3ГБ мелких файлов копировалась в efs около СУТОК.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое