Давайте) Я не хочу делать монстра, а предлагаю точечно использовать нужное нам поведение из Terraform. Можно обойтись без упоминания Terraform, но тогда понадобится дольше пояснять, что хочется реализовать. На самом деле Terraform использует текущий конфиг(1), ранее примененный – tfstate(2) и текущее состояние по управляемым элементам(3), что, действительно, является честным поведением. В статье используется сравнение 1-2, в Вашем подходе 2-3. Так что, думаю, и в Вашем случае можно сказать «вы предлагаете из одного инструмента сделать другой». Можно это как угодно назвать, но реализованная логика и сложность не поменяется.
И в Вашем и моем подходе используется «идемпотентность на уровне роли стандартными методами инструмента (никакого питон кода)».
Дополнительно, предложенный мною подход имеет следующие сильные стороны:
1. Безопасность – используем только объекты, ранее попавшие под управление. Не пытаюсь работать со всеми пользователями в системе. К примеру, условие сравнения пользователей может быть некорректным (пустая переменная или пробел), что может привести к попытке удаления всех пользователей ОС, маловероятно, но возможно. Подход с управлением только «своими» элементами использует Terraform, и я это поддерживаю.
2. Функционал – можно использовать поля из удаляемых объектов, говорил в комментарии выше.
3. Универсальность – локальные факты можно использовать в других задачах примерно с одинаковой кодовой базой. Если сравнивать с «живым» состояние системы, то потребуется каждый раз вызывать соответствующие утилиты и заниматься парсингом их вывода, задача может стать сложной ввиду различий вывода от версии к версии.
Но есть и слабые стороны:
1. Сложно вывести элемент из-под управления – нужно редактировать факты.
2. Возможность удалить всех пользователей под управлением роли – по этой причине идет проверка на наличие минимум двух админов.
Но давайте все же сравним сложность подходов по кодовой базе.
Жирным – подход из статьи, курсивом – сравнение на «живую». Без форматирования общие шаги
1. Различные проверки – скорее всего одинаково по сложности.
2. Обновить локальные факты – модуль setup
3. Управление имеющимися пользователями и другие шаги, связанные с этим – одинаково по сложности.
4. Получаем актуальный список пользователей – модуль getent
5. Удаление пользователей. В одном случае diff по фактам. В другом diff из модуля getent. Одинаковая сложность если выкинуть реализацию работы с отдельными параметрами удаленных элементов.
6. Сохранить переменные в локальные факты – модуль copy
7. Повторно обновить локальные факты – модуль setup. На самом деле модуль вызывать не обязательно. Другой код, работающий с фактами, должен обновить их самостоятельно, как делается в п2, добавлено для наглядности.
Думаю, пункты 4 и 6 соразмерны в ложности реализации. В сухом остатке, вся разница выражается в двух вызовах модуля setup (один обязательный, второй для перестраховки). В результате «Не могу сказать, что получилось проще», учитывая сильные и слабые стороны подхода, но точно не «Господи зачем так сложно?».
Искренне признателен, что заглянули в комментарии, рассказали о своем опыте и отстаиваете его. Читателям будет полезно знать предложенный Вами подход, спасибо!
Ваш вариант не выглядит Проше, или я пока не пойму в чем выигрыш. Идентичная логика, только вызов неопределенного модуля, в статье упоминается, что не хочется писать python код, когда можно обойтись кодом на ansible.
Прорабатывали предложенный вариант с вызовом модуля ansible.builtin.getent. Не могу сказать, что получилось проще. Подход с использованием фактов показался более универсальным.
К примеру, дает возможность использовать параметры из удаленных элементов. Это реализовано в коде при проверке условия удаления домашней директории пользователя.
Возможно в примере не стоило использовать два списка для определения админов, тогда получилось бы нагляднее, но хотелось донести реальный опыт.
Так описанное решение в публикации и есть реализация RHEL High Availability Cluster. Если бы делали решение под конкретного вендора, то полностью следовали бы его рекомендациям (по правильной реализации High Availability Cluster). В своем предыдущем комментарии указал, что просто для этого нужен vSphere 8.0 т.к. именно Pacemaker будет взаимодействовать с vWDT. Пожалуйста, укажите где я не прав.
Извините, все равно не понимаю, как automount можно безопасно использовать, имея несколько серверов приложений, NFS и общий диск.
Комментарий понял так: на серверах приложений прописываем в automount несколько NFS серверов. При недоступности одного NFS сервера, приложения подключаются к другому.
Представьте ситуацию, активный NFS сервер стал недоступен, все клиенты подключились к следующему. Недоступный NFS сервер возвращается в работу, возможны следующие проблемы:
1. Нет гарантий, что все клиенты смогут синхронно переподключиться к возвращенному в работу NFS серверу
2. Клиенты продолжат работать с текущим NFS сервером. Но тут уже серверу приложений надо перезагрузиться. Насколько понимаю, он подключится к возвращенному в работу NFS серверу
Оба эти сценария могут привести к множественному доступу на запись к общему диску, что привести к утрате данных.
Поэтому используется Pacemaker и входная точка, которой он управляет, для гарантии согласованного доступа к диску.
Отвечая на вопрос, напомню, что он основан на моем субъективном мнении и опыте. Учитывал контрактные обязательства перед заказчиком, опыт работы с ним, текущую инфраструктуру. Возможно, для Вас все сказанное будет неактуально. Основными критериями выбора в пользу POSIX ФС стали:
1. Более низкая стоимость разработки сервиса. Возможно, программисты скажут, что нет разницы или что S3 даже проще.
2. Административный ресурс. Сложнее найти на рынке специалистов, имеющих опыт развёртывания и эксплуатации Minio или Ceph, чем с pacemaker. Не говоря уже о том, чтобы обучить их этому. S3 более сложен для понимания, чем pacemaker с NFS.
3. Мониторинг. Текущая система мониторинга умеет работать с pacemaker и NFS. Внедрение Minio потребовало бы обновления системы мониторинга или реализации мониторинга через дополнительные скрипты.
4. Резервное копирование и восстановление. С S3 сложнее восстанавливать, особенно весь кластер при его утрате. Система резервного копирования заказчика не умеет создавать резервные копии с S3.
5. Администрирование. Восстановление узла, расширение доступного пространства – операции проще в предложенной реализации. У Minio появляются дополнительные сложности в виде ребалансировки (из того, что сразу пришло в голову).
6. Аппаратные ресурсы. В текущей инфраструктуре диски подаются с FC фабрики. Minio реализует собственную отказоустойчивость с использованием локальных дисков. FC диски дорого использовать для Minio.
Наверное, это основное, что вспомнил. Под требования проекта весомых плюсов от реализации S3 совместимого хранилища не увидел.
Отдельно скажу, что S3, и Minio в частности, используем на других проектах, где видим выигрыш от его реализации.
vWDT это просто еще одна реализация watchdog. Не знал о его существовании. Но, наверное, не стал бы использовать. Хотелось получить универсальное решение. В описанном решении softdog нужен не только как классический watchdog, через него Pacemaker проводит обработку отказа в различных сценариях.
Судя по статье, он поддерживается с vSphere 8.0, у нас версия была младше. Может еще какие-либо ограничения есть. Если когда-нибудь доведется, попробую, спасибо.
Использовал automount на стороне клиента. Как его прикрутить для общего диска и не допустить множественного доступа с нескольких узлов, не понятно.
Давайте) Я не хочу делать монстра, а предлагаю точечно использовать нужное нам поведение из Terraform. Можно обойтись без упоминания Terraform, но тогда понадобится дольше пояснять, что хочется реализовать. На самом деле Terraform использует текущий конфиг(1), ранее примененный – tfstate(2) и текущее состояние по управляемым элементам(3), что, действительно, является честным поведением. В статье используется сравнение 1-2, в Вашем подходе 2-3. Так что, думаю, и в Вашем случае можно сказать «вы предлагаете из одного инструмента сделать другой». Можно это как угодно назвать, но реализованная логика и сложность не поменяется.
И в Вашем и моем подходе используется «идемпотентность на уровне роли стандартными методами инструмента (никакого питон кода)».
Дополнительно, предложенный мною подход имеет следующие сильные стороны:
1. Безопасность – используем только объекты, ранее попавшие под управление. Не пытаюсь работать со всеми пользователями в системе. К примеру, условие сравнения пользователей может быть некорректным (пустая переменная или пробел), что может привести к попытке удаления всех пользователей ОС, маловероятно, но возможно. Подход с управлением только «своими» элементами использует Terraform, и я это поддерживаю.
2. Функционал – можно использовать поля из удаляемых объектов, говорил в комментарии выше.
3. Универсальность – локальные факты можно использовать в других задачах примерно с одинаковой кодовой базой. Если сравнивать с «живым» состояние системы, то потребуется каждый раз вызывать соответствующие утилиты и заниматься парсингом их вывода, задача может стать сложной ввиду различий вывода от версии к версии.
Но есть и слабые стороны:
1. Сложно вывести элемент из-под управления – нужно редактировать факты.
2. Возможность удалить всех пользователей под управлением роли – по этой причине идет проверка на наличие минимум двух админов.
Но давайте все же сравним сложность подходов по кодовой базе.
Жирным – подход из статьи, курсивом – сравнение на «живую». Без форматирования общие шаги
1. Различные проверки – скорее всего одинаково по сложности.
2. Обновить локальные факты – модуль setup
3. Управление имеющимися пользователями и другие шаги, связанные с этим – одинаково по сложности.
4. Получаем актуальный список пользователей – модуль getent
5. Удаление пользователей. В одном случае diff по фактам. В другом diff из модуля getent. Одинаковая сложность если выкинуть реализацию работы с отдельными параметрами удаленных элементов.
6. Сохранить переменные в локальные факты – модуль copy
7. Повторно обновить локальные факты – модуль setup. На самом деле модуль вызывать не обязательно. Другой код, работающий с фактами, должен обновить их самостоятельно, как делается в п2, добавлено для наглядности.
Думаю, пункты 4 и 6 соразмерны в ложности реализации. В сухом остатке, вся разница выражается в двух вызовах модуля setup (один обязательный, второй для перестраховки). В результате «Не могу сказать, что получилось проще», учитывая сильные и слабые стороны подхода, но точно не «Господи зачем так сложно?».
Искренне признателен, что заглянули в комментарии, рассказали о своем опыте и отстаиваете его. Читателям будет полезно знать предложенный Вами подход, спасибо!
Ваш вариант не выглядит Проше, или я пока не пойму в чем выигрыш. Идентичная логика, только вызов неопределенного модуля, в статье упоминается, что не хочется писать python код, когда можно обойтись кодом на ansible.
Прорабатывали предложенный вариант с вызовом модуля ansible.builtin.getent. Не могу сказать, что получилось проще. Подход с использованием фактов показался более универсальным.
К примеру, дает возможность использовать параметры из удаленных элементов. Это реализовано в коде при проверке условия удаления домашней директории пользователя.
Возможно в примере не стоило использовать два списка для определения админов, тогда получилось бы нагляднее, но хотелось донести реальный опыт.
Так статья не про настройку Linux. Но sssd, pam и sudo мы используем.
Пример с локальными админами взят как самый показательный. Но можно взять любой случай с использованием сложных структур данных.
Так описанное решение в публикации и есть реализация RHEL High Availability Cluster. Если бы делали решение под конкретного вендора, то полностью следовали бы его рекомендациям (по правильной реализации High Availability Cluster). В своем предыдущем комментарии указал, что просто для этого нужен vSphere 8.0 т.к. именно Pacemaker будет взаимодействовать с vWDT. Пожалуйста, укажите где я не прав.
Извините, все равно не понимаю, как automount можно безопасно использовать, имея несколько серверов приложений, NFS и общий диск.
Комментарий понял так: на серверах приложений прописываем в automount несколько NFS серверов. При недоступности одного NFS сервера, приложения подключаются к другому.
Представьте ситуацию, активный NFS сервер стал недоступен, все клиенты подключились к следующему. Недоступный NFS сервер возвращается в работу, возможны следующие проблемы:
1. Нет гарантий, что все клиенты смогут синхронно переподключиться к возвращенному в работу NFS серверу
2. Клиенты продолжат работать с текущим NFS сервером. Но тут уже серверу приложений надо перезагрузиться. Насколько понимаю, он подключится к возвращенному в работу NFS серверу
Оба эти сценария могут привести к множественному доступу на запись к общему диску, что привести к утрате данных.
Поэтому используется Pacemaker и входная точка, которой он управляет, для гарантии согласованного доступа к диску.
Отвечая на вопрос, напомню, что он основан на моем субъективном мнении и опыте. Учитывал контрактные обязательства перед заказчиком, опыт работы с ним, текущую инфраструктуру. Возможно, для Вас все сказанное будет неактуально. Основными критериями выбора в пользу POSIX ФС стали:
1. Более низкая стоимость разработки сервиса. Возможно, программисты скажут, что нет разницы или что S3 даже проще.
2. Административный ресурс. Сложнее найти на рынке специалистов, имеющих опыт развёртывания и эксплуатации Minio или Ceph, чем с pacemaker. Не говоря уже о том, чтобы обучить их этому. S3 более сложен для понимания, чем pacemaker с NFS.
3. Мониторинг. Текущая система мониторинга умеет работать с pacemaker и NFS. Внедрение Minio потребовало бы обновления системы мониторинга или реализации мониторинга через дополнительные скрипты.
4. Резервное копирование и восстановление. С S3 сложнее восстанавливать, особенно весь кластер при его утрате. Система резервного копирования заказчика не умеет создавать резервные копии с S3.
5. Администрирование. Восстановление узла, расширение доступного пространства – операции проще в предложенной реализации. У Minio появляются дополнительные сложности в виде ребалансировки (из того, что сразу пришло в голову).
6. Аппаратные ресурсы. В текущей инфраструктуре диски подаются с FC фабрики. Minio реализует собственную отказоустойчивость с использованием локальных дисков. FC диски дорого использовать для Minio.
Наверное, это основное, что вспомнил. Под требования проекта весомых плюсов от реализации S3 совместимого хранилища не увидел.
Отдельно скажу, что S3, и Minio в частности, используем на других проектах, где видим выигрыш от его реализации.
vWDT это просто еще одна реализация watchdog. Не знал о его существовании. Но, наверное, не стал бы использовать. Хотелось получить универсальное решение. В описанном решении softdog нужен не только как классический watchdog, через него Pacemaker проводит обработку отказа в различных сценариях.
Судя по статье, он поддерживается с vSphere 8.0, у нас версия была младше. Может еще какие-либо ограничения есть. Если когда-нибудь доведется, попробую, спасибо.
Использовал automount на стороне клиента. Как его прикрутить для общего диска и не допустить множественного доступа с нескольких узлов, не понятно.
в описанной реализации это невозможно. Для Active-active нужны кластерные ФС. Тут можно только сделать размазывание NFS ресурсов по узлам
так этот issues в статье и указан, из него стало понятно какой параметр править.
Если будет время, подскажите о каких метриках идет речь
Добрый день.
Спасибо за статью, узнал для себя много нового.
Подскажите, а как определяете проблемные запросы? От кого они пришли?
Пробовал включить Audit policy на все операции get, list, watch, система логирования не справилась с нагрузкой.
Тут нельзя править комментарии) Приняли PR
Сейчас в отпуске. На следующей неделе займусь. Комментарий поправлю по итогу работ.
Благодарю
Спасибо! Не видел такие настройки helm, попробую.