Перейти к содержимому

17.03.2011

7

Установка Oracle EM Management Agent на linux-сервер с установленным ПО Oracle

Это третий пост из серии «Управление инфраструктурой Oracle с помощью EM Grid Control 11g» и посвящен он установке Management Agent на другие хосты в вашей сети, для мониторинга установленного ПО Oracle, и отправки этих данным в EM Grid Control.

В начале немного теории и общих слов.
Management Agent — это программный компонент системы Oracle Enterprise Manager, который устанавливается на каждый наблюдаемый хост. Агент отвечает за мониторинг всех целей, которые он обнаружит на этом хосте. Так же в его задачи входит передача собранной информации в Oracle Management Service (OMS), обслуживание и сопровождение найденных целей на хосте.
Агенты могут быть установлены на разные операционные системы и наблюдать разные типы целей. В свою очередь OMS, после установки агента на какой-либо хост, берет на себя наблюдение за доступностью хоста и доступностью установленного агента. Наглядная иллюстрация представлена ниже.

Установка агента.
Для установки агента мы воспользуемся специальной процедурой, которая доступна в EM Grid Control консоли, и называется она «Mass agent deployment procedure». Эта процедура берет установочные файлы агента для нужного типа установленной операционной системы на хосте, копирует их на сервер по ssh, используя логин и пароль пользователя, который заведен на этом хосте (лучше чтобы это был тот же пользователь, под которым там уже работает другое ПО Oracle), и далее опять-таки по ssh выполняет установку агента. В EM Grid Control есть возможность загрузить версии агентов для разных ОС автоматически из My Oracle Support или же самому скачать агенты с сайта Оракл и положить в определенное место, чтобы EM Grid Control узнал об их существовании.

Для того, чтобы процедура установки прошла успешно, необходимо выполнение некоторых условий, среди которых доступность хостов по сети, корректно настроенный DNS, доступность сервера по ssh, наличие на устанавливаемом хосте пользователя, из-под которого будет производится установка и под кем будет работать сам агент. Конечно же есть требования касательно установленных пакетов, но так как на этом хосте уже стоит какое-то ПО Oracle, то скорее всего, все эти требования уже выполнены. С полным перечнем необходимых условий для установки можно ознакомиться тут. Так же необходимо знать некоторые сведения о OMS, но ведь это же вы сами его ставили? 🙂

И так, приступим.
Заходим в консоль EM Grid Control. Идем в закладку «Deployments» и там выбираем «Install agent». У нас открывается страница деталей установки нового агента.

Здесь надо указать откуда мы хотим брать установочные файлы, выбрать версию агента (список доступных версий формируется из анализа доступных установочных файлов), указать версию ОС, куда мы хотим ставить агент, указать список хостов (если указать более одного адреса, то на сервера накладывается требование — они все должны быть с одним типом операционной системы, то есть здесь нельзя указать сервер с linux-i386 и linux-x86_64), если на требуемых хостах стоит ПО Oracle, например базы данных, и они объединены в кластер, то так же следует указать названия нод. Далее надо указать логин и пароль пользователя для доступа к серверу. Ниже можно увидеть чекбокс про запуск скрипта root.sh, если вы прописали пользователя в sudoers, то можете смело ставить галочку, если же нет, то обязательно после успешной установки агента не забудьте сами выполнить этот скрипт из-под рута, он будет лежать в директории, куда поставится агент (в данном случае это /u01/oracle/agent11g/root.sh). Если вы не выполните этот скрипт, то не будут произведены некоторые важные настройки на сервере (например выставление SUID-бита некоторым утилитам), вследствие которых у вас не будут собираться некоторые метрики и возможно еще появятся какие-нибудь проблемы. Затем указать директорию для установки агента (обычно это ORACLE_BASE), указать порт, на котором будет слушать агент. Если ваш EM Grid Control так же является кластером, то можно указать параметры для доступа к хосту балансировщику. Обязательно надо указать пароль для доступа к OMS, чтобы агент смог зарегистрироваться в OMS и в дальнейшем обмениваться информацией с EM Grid Control. Заполняем все необходимые поля и жмем «далее». На следующей странице нам предлагают указать параметры для доступа к My Oracle Support. Если ваши хосты не имеют доступа к интернету, да и даже если имеют, можно пропустить этот шаг, потому как для того, чтобы получать всю необходимую информацию о критических патчах и другую полезную информацию, достаточно подключить к My Oracle Support только хост, где установлен EM Grid Control. После нажатия «submit» на сервере EM запустится процедура установки агентов на указанные хосты, а нам тем временем будет показана картинка с очень обобщенным состоянием дел.

Если все параметры были указаны правильно и все прошло удачно, то результатом ожидания станет вот такая страница.

Вообщем в процессе установки агента может возникнуть множество проблем:

  • Не найдены какие-то утилиты. В установочных файлах агентов для каждого типа операционной системы лежат полные пути до нужных системных утилит, таких как scp, sudo и т. д. Соответственно, если утилита не найдена по этому пути, это приводит к ошибке. Методов исправления тут более чем предостаточно — можно поправить пути в файлах агента (я говорю в файлах, потому как на самом деле есть несколько файлов и EM проверяет наличие нужного параметра в определенной последовательности), можно на удаленном сервере поправить пути, или банально установить нужную утилиту, если она отсутствовала.
  • Агент на удаленном сервере не может связаться с OMS-сервером. Такая ошибка может появляться в случае, если у вас нет DNS-сервера, или в вашей зоне отсутствуют записи для всех хостов. Дело в том, что EM при установке агента пытается с удаленного хоста обратиться к OMS не по ip-адресу, а по имени. Поэтому крайне рекомендую просто прописать все имена в DNS. Хотя можно обойтись просто правкой /etc/hosts на удаленном сервере с указанием там имени OMS и соответствующего адреса. Только учтите, что это придется делать каждый раз и на каждом хосте.
  • Банальные ошибки неверных паролей, ip-адресов и несоответствие выбранных платформ реальным.

Но я надеюсь что эти проблемы обойдут вас стороной, и все получится!

Узнайте больше из Oracle
  • MadMike

    Неплохие статьи, спасибо!
    И вопрос — установил GridControl 11g на Linux — скопировал дистр агента для Windows, установил на другой хост Windows 2003, установил через GridControl на него агента (оказывается надо на виндовый хост ставить cygwin — ssh, zip). После решил поставить на этот хост Oracle 10g R2 — но, к сожалению, dbca не видит агента при создании базы 🙁
    Не сталкивались с таким? А то только начал знакомится с gridcontol, ваши статьи сильно облегчили это знакомство

    • KSDaemon

      Нуу как по мне — так проще было агента через обычный runInstaller поставить. Но Если сумели через cygwin/ssh — круто.
      С таким не сталкивался, но не вижу проблемы просто поставить БД, а потом агенту сказать что у вас появилась БД.

    • KSDaemon

      У агента есть возможность поиска/обнаружения целей. Так что думаю что таким способом можно это обойти.

  • Екатерина

    Спасибо, ваши статьи очень помогли. Но столкнулась с проблемой на этапе установки агента. Может, вы подскажете.
    Есть сервер SLES 10 SP4 (x64). На нем Grid Control 11g с репозиторием Oracle 11.2.0.2 (x64). Есть сервер SLES11 SP1 (x64), Oracle 11.2.0.2 (x64). Хочу поставить этот сервер на мониторинг. Пытаюсь установить агента из интерфейса Grid. Жму Deployments -> Agent installation -> Install agent -> Fresh install. Выбираю мой сервер, все нужные данные вбиваю. Предлагает ставить агента версии 11.1.0.1. И появляется проблема на этапе Checking Prerequisites.

    Ругается на пакет: Passed Checking for libstdc++-4.1.0; Not found. Failed

    На сервере, который ставлю на мониторинг, есть уже пакет libstdc++43-4.3.4_20091019-0.7.35. Но он не устраивает. Пытаюсь поставить нужный пакет.

    # rpm -ivh libstdc++-4.1.0-25.x86_64.rpm
    Preparing… ########################################### [100%]
    file /usr/lib64/libstdc++.so.6 from install of libstdc++-4.1.0-25.x86_64 conflicts with file from package libstdc++43-4.3.4_20091019-0.7.35.x86_64
    file /usr/lib/libstdc++.so.6 from install of libstdc++-4.1.0-25.x86_64 conflicts with file from package libstdc++43-32bit-4.3.4_20091019-0.7.35.x86_64

    А удалять уже установленный пакет не хочется, т.к. боюсь, что-нибудь может слететь.

    • KSDaemon

      Странно, почему происходит конфликт….
      Но вообще libstdc++ (версии 4.1.0) и libstdc++43 (версии 4.3.4) — это вообще разные пакеты.
      Посмотрите кому действительно нужен libstdc++43, если нужен — попробуйте обновиться.
      Если особых зависимостей нет, то смело удаляйте и ставьте libstdc++. Ну или же все-таки придется через force ставить…
      Других вариантов особо-то и нет….
      Проверил у себя (правда у меня libstdc++44, а не 43) — никаких проблем с установкой не обнаружил, правда это на CentOS/RHEL.

  • Cade

    Хорошая статья, но
    что может означать следующая ошибка при попытке установки агента.
    RHEL 5.6, wls1032. GridControl_11.1.0.1.0_Linux_x86-64

    Error 500—Internal Server Error

    java.lang.NoClassDefFoundError: Could not initialize class oracle.sysman.oii.oiip.osd.unix.OiipuUnixOps
    at oracle.sysman.oii.oiip.oiipg.OiipgEnvironment.getEnv(OiipgEnvironment.java:201)
    at oracle.sysman.oii.oiix.OiixEnvironmentOps.getEnv(OiixEnvironmentOps.java:53)
    at oracle.sysman.prov.agentpush.util.AgentPushUtil.checkLocalTempPathWritability(AgentPushUtil.java:172)
    at oracle.sysman.prov.agentpush.ui.validate.ValidateHelper.performValidationForFresh(ValidateHelper.java:1081)
    at oracle.sysman.prov.agentpush.ui.validate.ValidateHelper.performValidation(ValidateHelper.java:2107)
    at oracle.sysman.prov.agentpush.ui.validate.prereq.PrereqFreshValidator.validate(PrereqFreshValidator.java:132)
    at oracle.sysman.prov.agentpush.services.BaseServiceHandler.process(BaseServiceHandler.java:200)
    at oracle.sysman.prov.agentpush.services.BaseServiceHandler.doPost(BaseServiceHandler.java:126)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
    at oracle.sysman.prov.agentpush.services.AgentpushAuthFilter.doFilter(AgentpushAuthFilter.java:122)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
    at oracle.sysman.eml.app.EMRepLoginFilter.doFilter(EMRepLoginFilter.java:311)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
    at oracle.sysman.emas.fwk.MASConnectionFilter.doFilter(MASConnectionFilter.java:41)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
    at oracle.sysman.eml.app.ContextInitFilter.doFilter(ContextInitFilter.java:502)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
    at oracle.adf.library.webapp.LibraryFilter.doFilter(LibraryFilter.java:159)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
    at oracle.dms.wls.DMSServletFilter.doFilter(DMSServletFilter.java:326)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
    at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3592)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
    at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202)
    at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108)
    at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

  • Белов

    Error 500—Internal Server Error

    java.lang.NoClassDefFoundError: Could not initialize class oracle.sysman.oii.oiip.osd.unix.OiipuUnixOps

    Эта ошибка возникает, потому что вы установили WLS с 32-х разрядного дистрибутива wls1032_linux32. Удалите все, что было OMS, WLS и репозитарий. Скачайте дистрибутив wls1032_generic из пункта Additional Platform (For 64-bit….) и все будет, как в аптеке.