Оценка производительности сервера Ansible (роль)

Поймите производительность вашего компьютера/контейнера/дроплета/линода с помощью Ansible.

При запуске на новом хосте это даст вам представление о базовой производительности и о том, соответствует ли она вашим целям.

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

Катализатор

Катализатором этого проекта стало несколько случайное поведение наших облачных машин. Позвольте мне оставить детали о том, кто поставщик, закодировав их имя в совершенно несвязанное и загадочное кодовое имя: "Акула".

Акула хорошо справляется с запуском новых облачных машин, которые мы будем называть крили. Производительность крили нигде явно не указана в документации Акулы, кроме как то, что у них общие процессоры. Конкретно нигде не указано, сколько IOPS вы можете ожидать от дисков или ОЗУ, какой объем памяти, или какой семейство процессоров гипервизора; и есть вероятность, что вам будет предоставлена машина, которая находится на нижнем уровне производительности.

Акула не заботится о создании одинаковых крили, ей важно создать МНОГО крили, и поэтому она пытается разместить как можно больше крили на одном гипервизоре, пока это не станет невозможным, и в этот момент пользователи уже начинают замечать явное ухудшение производительности.

Однако пользователю важно лишь то, что за что бы он не платил (по часам), это всегда соответствует одному и тому же спецификации и возможностям каждый раз, когда он его запускает. Понятно, что это критично для вашего приложения/бизнеса, и официально нет информации, что вы можете ожидать чего-то другого от Акулы (за исключением официально заявленной и документированной изменчивости в пространстве общих процессоров, когда используется определенный тип общей крили - но это единственное, что они упоминают о процессорах).

Сценарий использования

Роль была создана, чтобы обеспечить двустороннюю проверку.

1. Сначала вы хотите запустить её перед любым фактическим развертыванием, чтобы убедиться, что ваша базовая производительность соответствует вашим предположениям, и, возможно, просто удалить вашу крили и воссоздать, если она сильно не согласована.
2. Затем вы хотите, чтобы это запускалось по расписанию или инициировалось конкретными событиями (например, когда вы видите снижение времени отклика приложения, предоставленного другими инструментами), чтобы выяснить, не связаны ли реальные проблемы, с которыми вы сталкиваетесь, с низкой производительностью вашей инфраструктуры. По крайней мере, до того, как начать обвинять разработчиков в том, что они используют неоптимизированный код. Или, вероятно, вы можете сделать последнее, так как мы твердо верим в мета-игру "выпускать рано, оптимизировать, когда принуждают".

Основная идея

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

Тестирование

./bootstrap_testing.sh
source testing_env/bin/activate
read -s PASS && ANSIBLE_BECOME_PASS=$PASS molecule verify -s lxd

Программа будет молчать, чтобы вы могли ввести свой sudo пароль. Сделайте это, нажмите enter, и она продолжит.

Использование

Когда клонируется из git репозитория

Дополните ваш playbook.yml этой ролью и отрегулируйте параметры в соответствии с приемлемой базовой производительностью.

- name: Проверка
  hosts: все
  become: true

  roles:
    - role: ansible-server-performance-assessment
      spa_disk_write_MB_per_s_assertion: 300 [в МБ/с, отрегулируйте по вкусу]
      spa_disk_read_MB_per_s_assertion: 300 [в МБ/с, отрегулируйте по вкусу]
    
      # Тестирование сети
      # спасибо speedtest.net! Я никогда не думал, что буду использовать вас в продакшене, но вот мы и здесь.
      spa_speedtest_tmp_file: /tmp/spa_speedtest.out
      spa_downlink_assertion: 100  # Значение в Мб/с (БИТЫ в секунду)
      spa_uplink_assertion: 100  # Значение в Мб/с (БИТЫ в секунду)
        
      # Тестирование памяти
      spa_memory_speed_assertion: 10000  # Значение в МБ/с (БАЙТЫ в секунду)
        
      # Тестирование процессора
      spa_cpu_event_per_second_assertion: 300  # Количество событий в секунду, как это сообщает Sysbench

  tags:
    - benchmark
    - никогда

Пример выше будет работать только при использовании параметра --tags=benchmark при запуске ansible (для более легкого объединения с существующими файлами playbook).

Ограничения

Роль не будет работать слишком хорошо или вообще на локалях, отличных от en, поскольку часть извлечения данных тестирования происходит с использованием специфических фраз в их выводах. Это можно исправить во втором этапе разработки кем-то, кто лучше разбирается в awk и регулярных выражениях, чем я.