company_banner

Operon: ускоряет производительность Ansible

Автор оригинала: David
  • Перевод


Я очень рад наконец представить Operon, высокопроизводительную замену Ansible Engine. Operon разработан для крупных установок и распространяется по подписке. Он запускает существующие плейбуки, модули, плагины и сторонние инструменты без модификации, используя усовершенствованный движок, существенно увеличивает реальное число адресуемых в один прогон узлов, потенциально экономя часы при каждом вызове.


Operon устанавливается как отдельно, так и совместно с Ansible Engine: можно постепенно переводить на него свои проекты или использовать при запусках по желанию.


Ниже приведен график прогона на 416 задач common.yml из DebOps 0.7.2, развернутого через SSH:



По сравнению с "чистым" Ansible Operon сокращает время прогона на одном узле примерно на 60%. Но при массовых запусках преимущество куда больше. Взгляните, как растет время работы (железо: 24 GB, 8-ядерный Xeon E5530; разворачивается в виртуальные машины Google Cloud по SSH за 18мс):



За каждый прогон было исполнено по 416 задач на каждом узле, включая loop items. В прогоне на 1024 узла за 54 минуты было исполнено 490496 задач; средняя пропускная способность — 151 задача/секунду. Горизонтальное масштабирование налицо: почти 4-кратное, с 256 до 1024 узлов.


Прогон с Ansible на 256 узлов пришлось отменить: в течение длительного периода времени он не давал результатов, много раз приходилось перезапускать, сокращая количество процессов с 40 до 10, чтобы Ansible не исчерпал ресурсы оперативной памяти. С 13 процессами, может, и получилось бы, но от дальнейших попыток пришлось отказаться: мы и так потратили 2 дня машинного времени.


За финальный прогон, перед отменой Ansible завершил 89% задач за 6 часов и 13 минут:



Operon при каждом прогоне в параллельном режиме развернулся на все узлы. Выполняя 1024 процессов на 8 ядрах, он дает едва заметный прирост нагрузки, а на 24 ядрах количество процессов вырастает аж до 6144. Если бы мы запустили то же количество задач, на том количестве узлов, только при 16 ядрах, прогон, думаем, получилось бы завершить не за 54 минуты, а за 27.


Потребление памяти очень предсказуемо и в значительной мере отвязано от процессов. С 256 процессами Operon потребляет вчетверо меньше, чем Ansible потребляет с 10; при этом процессорного времени контроллер потребляет минимум в 15 раз меньше.



Вот здесь кривая идет на спад: прогон Ansible на 64 узлах выполнен с 40 процессами, тогда как прогон на 256 узлах — с 10. Ansible для прогона на 256 узлах потребовалось 1,6 Gb/процесс; так, независимо от наличных ресурсов оперативной памяти, создалось жесткое ограничение по достижимому параллелизму.


Operon — это новый шаг в подходе к разработке, который дебютировал с Mitogen для Ansible. Он наследует объемные улучшения низкоуровневой производительности, необходимой уже тысячам пользователей:




Не только ПО


Производительность — побочный эффект культурного сдвига в сторону большей ориентировки на пользователя, совместимости и интернализации издержек. Нам есть что показать, но чтобы вы в полном мере ощутили вкус новинки, я с удовольствием объявляю: будет гарантия синтаксиса плейбука с прямой совместимостью — в дополнение к восстановлению некоторых устаревших конструктов Ansible Engine.


include:


- include: "i-will-always-work.yml"

"with" loops


- debug: msg={{item}}
  with_items: ["i", "will", "always", "work"]

"squash actions"


- apt:
    name: "{{item}}"
  with_items: ["i", "will",
               "always", "work"]

дефисы в именах групп


$ cat hosts
  [i-will-always-work.us.mycorp.com]
  host1

хэш-слияние


# I will always work
  [defaults]
  hash_behaviour = merge

Поставки Operon с синтаксисом, совместимым с Ansible 2.9, получат постоянную поддержку, а отключения синтаксиса в Ansible Engine в будущем Operon не коснутся. Подобные изменения вредят рабочим установкам, никак не улучшая возможностей, и они же — главный источник работ по исправлению ошибок во время обновлений.


Со временем эта гарантия распространится на семантику движка и далее.


Как приобщиться?


Первоначально Operon будет распространяться с поддержкой от Network Genomics, а это — опыт и приверженность сервису, которых вы больше нигде не получите. Если ваша команда застряла в ловушке развертываний или устала годами чинить обновления, подумайте над тем, чтобы запросить оценку, и не откладывая, напишите мне по электронке — по любым вопросам и непонятным моментам.


Лучшее ПО — в открытом доступе, поэтому общедоступный релиз состоится, когда мы будем в состоянии обеспечить определенный уровень бесплатной поддержки. Подпишитесь на нашу рассылку, чтобы вовремя узнавать о будущих релизах.


Улучшит ли Operon производительность Windows?
Да. Если у вас проблемы с производительностью во время развертываний на Windows, пока просто следите за новостями.


Улучшит ли Operon производительность сетевого устройства?
Да. Operon представляет архитектурный редизайн, который распространяется далеко за пределы транспортного уровня и в равной мере применим для всех типов соединений.


Operon — это ответвление Ansible?
Нет. Operon — это инкрементная перезапись движка, небольшой компонент около 60к строчек кода, из которых заменили примерно четверть. Каждая установка Ansible включает порядка 715к строчек, из которых подавляющее большинство, как и Operon, независимо поддерживается крупным сообществом Ansible.


Улучшит ли Operon Ansible Engine?
Да. Operon уже продвигает улучшение внутри Ansible Engine, а поскольку он — доработка, есть стимул сделать вклад, подправить код там, где надо.


Operon — это бесплатное ПО?
Да. Operon выпускается под той же GPL лицензией, что и Ansible, и можно свободно использовать код в рамках этой лицензии.


Ломает ли Operon совместимость?
Нет. Operon не нарушает совместимости со стандартным набором модулей, интерфейсами плагинов или окружающей экосистемой Ansible, и нарушать не планирует. Совместимость — прежде всего: нельзя отставать от будущих улучшений, как и забывать об обратной совместимости вроде улучшенной стабильности синтаксиса плейбука.


Нужен ли мне Operon, если у меня планы всего на один узел?
Operon обеспечит непрерывную конкурентоспособность навыков, в которые вы так много вложили. Он предлагает повышенную гибкость, которой прежде просто не существовало: свободу выбирать движок. С Operon вы выигрываете, даже если не используете его напрямую.

Southbridge
588,76
Обеспечиваем стабильную работу highload-проектов
Поделиться публикацией

Похожие публикации

Комментарии 8

    +4
    Главного вопроса нет: Когда Operon войдет в состав Ansible?
      +1
      Пока туда даже mitogen не вошел. Хотя разговоры идут.
      +3
      Сравнение с mitogen скоростью будет?
      И хотелось бы конечно сравнить на более нормально написанных тасках/ролях/плейбуках, ибо сейчас там оверхейд по всяким лишним сравнениям и преобразованиям…
        0

        Коллеги кто-то сталкивался с ошибкой "the respondent Context has disconnected" при использовании mitogen?

          0

          Все же наверняка есть в ишью трекере?
          https://github.com/dw/mitogen/issues/431
          Сам на такое не попадал, но может просто везло

            0

            Проблема в том что я уже попробовал все варианты из гугла.
            Есть предположение с тем что я запускаю это на WSL

              0

              Вендопроблемы? Сорри, с таким не сталкивался.
              Обычный ансибл, как я понимаю, у Вас работает нормально?

                +1

                Да работает отлично но медленно, mitrogen работает в разы быстрее, но редко.

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

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