Автоматизация замены дисков с помощью Ansible

[Xop]

Свои модули и фильтры — это хорошо, но почему не использовать роли и action-плагины? Роли пишутся на том же ансибле и могут вызывать модули и другие роли (в том числе с кастомными параметрами), и вполне поддаются интеграционному тестированию. Если хочется более сложную логику — есть action-плагины, которые с точки зрения плейбука выглядят как модули, но выполняются на стороне контроллера, а не хоста, и поэтому так же могут вызывать другие action-плагины и модули. Плюс за счёт того, что пишутся на питоне могут быть покрыты уже и юнит-тестами. А вот вызывать из своих модулей другие не получится — модули обязаны быть self-contained.

[Qk4l]

Роли используются для организации плейбуков.
По сути в этом проекте для каждой уникальной группы (с точки зрения замены диска) есть отдельная Ansible роль.
Например процесс замены в раздатчике видео будет описан в роли video-download, а процесс замены системного диска с редеплоем сервера в redeploy.

Кастомных action плагинов нет, не было явной необходимости в них. Но build-in конечно используем.
Напрмер assert через которые прогоням проверки перед возратом нагрузки на диск/сервер или закрытием тикета.

[Qk4l]

Спасибо за наброс про action плагины.
Почитал про них, переосмыслил. В арсенале однозначно пригодятся =)

[pansa]

Мы стараемся больше не использовать аппаратные и софтовые RAID, так как резервируем наши системы на уровне дата-центров, а не серверов.

А скажите честно, ведь это ещё и потому, что подавляющее большинство реализаций RAID, особенно аппаратных, представляет собой совершенно угрёбищную (простите, но на самом деле я хотел сказать грубее...) реализацию? Да, особенно «утилит управления». Их не то что интегрировать в систему автоматизации, их руками-то использовать невозможно без мата…

[Qk4l]

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

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

[pansa]

О да, ещё же прошивки. Последний секс с LSI/avago как раз заключался в том, что прошивку надо отслеживать и обновлять для: самого контроллера, плюс его bios, и ещё отдельно для модуля суперконденсатора. Удобство процесса прошивки тоже отдельная песня. Интересно, как вы с таким справляетесь. С учётом зоопарка и его размера это нехилая работа. А без нее опасно — мы ловили спонтанные ребуты, пока не обновились.

[fessmage]

У 3ware была неплохая утилита tw_cli, потом когда они попали под крыло LSI — появилась storcli, с тем же синтаксисом. Вот ими еще можно пользоваться, сделаны по-человечески. В отличие от старых lsiutil, megacli и hpacucli.