Concerns
В ADCM реализовано уведомление пользователей в виде проблем (concerns). Такие проблемы-уведомления возникают, например, в случае некорректной конфигурации, когда не заполнены поля обязательных параметров в конфигурациях сервисов, компонентов либо других объектов. Другим примером, при котором ADCM создаёт проблему-уведомление, является ситуация, когда после изменения конфигурации объекта пользователь забывает применить её на хостах кластера и продолжает работу с устаревшей конфигурацией.
Причины возникновения проблем, а также их типы и свойства подробно описаны ниже.
Типы проблем
В ADCM есть три типа проблем:
-
Flag
-
Lock
-
Issue
Проблемы всех типов отображаются в UI.
Проблемы могут быть блокирующими либо неблокирующими. Если проблема является блокирующей, то для связанного с ней объекта ADCM недоступны какие-либо action и обновления. В UI блокирующие проблемы обозначаются красным цветом, а неблокирующие — жёлтым.
Рассмотрим каждый из типов отдельно.
Flag
Flag — это неблокирующая проблема, которая указывает на несовпадение конфигурации объекта в базе ADCM с его реальной конфигурацией на хосте. Как правило, появление флага свидетельствует об устаревании конфигурации на хостах после изменения параметров объекта в ADCM без последующего применения. Чтобы устранить такую проблему, необходимо применить изменения на хостах кластера, выполнив соответствующие действия (actions).
|
ВАЖНО
Проблема типа flag доступна только в том случае, если это поддерживается использующимся продуктом.
|
Причина (cause) проблемы типа flag отображается в UI в виде сообщения <Concern owner> has an outdated configuration.
Цель возникновения проблем типа flag — исключить взаимодействие с объектами, конфигурация которых устарела на хостах, а также обеспечить возможность гибкой настройки порядка выполнения action для взаимосвязанных сервисов. Например, изменение конфигурации уже установленного сервиса может потребовать его перезапуска. В этом случае ADCM создаёт проблему типа flag, которая напоминает пользователю о необходимости выполнения перезапуска.
Lock
Lock — это блокирующая проблема, которая возникает каждый раз при запуске action на объекте. При этом элементы UI и API, связанные с объектом, становятся недоступны.
Причина проблемы типа lock отображается в UI в виде сообщения Object was locked by running job <job>.
Цель возникновения проблем типа lock — предотвратить одновременный запуск нескольких action пользователем.
Issue
Issue — это блокирующая проблема, которая может быть вызвана несколькими причинами:
-
У объекта есть незаполненные либо невалидные поля в его конфигурации. Эта причина отображается в UI в виде сообщения <Concern owner> has an issue with its config.
-
Объект содержит сервис с обязательным импортом. Эта причина отображается в UI в виде сообщения <Concern owner> has an issue with required import.
-
Для работы кластера требуется установить обязательный сервис. Эта причина отображается в UI в виде сообщения <Concern owner> has an issue with required service.
-
Объект содержит сервис, для работы которого требуется установить другой сервис. Эта причина отображается в UI в виде сообщения <Concern owner> has an issue with requirement. Need to be installed: <target service>.
-
В объекте не настроен маппинг между хостами и компонентами. Эта причина отображается в UI в виде сообщения <Concern owner> has an issue with host-component mapping.
Цель возникновения проблем типа issue — предотвратить некорректное взаимодействие и работу объектов.
Источники проблем
У проблем существует источник (owner). Источник проблем типа flag и issue — это объект ADCM, на который воздействует эта проблема.
В UI источник проблемы демонстрируется во всплывающем окне с сообщением о причине рядом со значком проблемы.
У проблем типа lock источником является соответствующая задача (job).
Приоритизация и наследование проблем
Если у объекта ADCM есть две проблемы, причём одна из них блокирующая, а другая нет, то блокирующая проблема обладает более высоким приоритетом. При этом значок проблемы окрашивается в цвет более приоритетной проблемы.
Также проблемы могут наследоваться объектами от других объектов. Например, если проблема есть у хостпровайдера, то она может быть унаследована хостом, созданным с помощью этого хостпровайдера.
Между родительским и дочерним объектами проблемы наследуются в обе стороны. Объекты находятся в родительско-дочерних отношениях, если между ними существует явная иерархическая связь. Если проблема есть у сервиса, то она наследуется как кластером, содержащим этот сервис, так и компонентом, который содержится в этом сервисе. Проблема сервиса не наследуется хостами, если компоненты сервиса не добавлены на хост. При этом, если проблема есть у кластера, содержащего хост без компонентов, то эта проблема кластера не будет унаследована хостом, пока на этом хосте не появится хотя бы один компонент. Аналогично, в случае появления проблемы на хосте без компонентов она не будет передаваться кластеру, содержащему этот хост.
Проблема типа flag у сервиса не распространяется на другие сервисы в кластере. Проблемы типа lock и issue распространяются от хоста на компоненты, которые находятся на хосте, даже если источником проблемы является другой родительский объект: кластер, сервис, компонент или хостпровайдер.
Если удалить объект-источник проблемы, то будут удалены и проблемы всех связанных с ним объектов (как родительских, так и дочерних). Например, если удалить из кластера сервисы, которые содержат проблемы, то у кластера эти проблемы тоже исчезнут. При этом проблемы, источником которых является сам кластер, не исчезнут.