Automic Workload Automation

 View Only
  • 1.  DBService Agent for Seccond Node

    Posted Dec 02, 2021 08:11 AM
    Hello Experts,

    There are two different automation engines. We installed DBService agent on one of them and the connection is successful.

    When I install DBService2 on the second NODE, when I define "engine1IP":"2217" in engine.ini, it sometimes works and sometimes gets an error. Error: login not found in dbserviceagent1... I think both agents are conflicting.

    In short, how should I configure the ini file when I install the second agent on the second node?

    Thanks in advance...

    ------------------------------
    Emre
    ------------------------------


  • 2.  RE: DBService Agent for Seccond Node

    Posted Dec 02, 2021 11:22 AM
    Hi @Emre Boler,

    Like so (see screen shot):
    NODE-A, defined CP-Ports: 2217,2219                                                                                    NODE-B, defined CP-Ports: 2218,2220


    Cheers
    Christoph

    ------------------------------
    ----------------------------------------------------------------
    Automic AE Consultant and Trainer since 2000
    ----------------------------------------------------------------
    ------------------------------



  • 3.  RE: DBService Agent for Seccond Node

    Posted Dec 03, 2021 05:00 AM
    Edited by Emre Boler Dec 03, 2021 06:28 AM
    Hello @Christoph Rekers,

    First of all, thank you very much for the detailed information.

    If I understood correctly, after making a definition as you stated,

    On the ServiceManagerDialog, the localhost2:8871 port, when I "Start" the DBServiceAgent-2, it will be visible on the AWI, right? I ask this because when I defined localhost:2217 in the ucsrv.ini file on the 2nd node, I could not see the second dbservice agent on AWI. I understand it's because I'm not using port 2218.

    Well I tried to use 2218 for seccond node. But I got this error for connection object for first db service agent. But when I stoped the dbserviceagent-2, same configuration for dbserviceagent-1 works well. There is a problem here :)

    Error in Connection Object: U00052010 UCUCM: Login 'LOGIN.DB.01.SERVICE' for connection 'CONN.SQL.TEST' could not be resolved. Reason: 'no_Login_Entry'

    Thanks in advance.

    ------------------------------
    Emre
    ------------------------------



  • 4.  RE: DBService Agent for Seccond Node

    Posted Dec 03, 2021 06:59 AM
    Edited by Christoph Rekers Dec 03, 2021 07:00 AM

    Hi @Emre Boler,

    In the [DB_SERVICE]​ section in the ucsrv.ini you define the CP to which the DB_SERVICE agent should connect to. The DB-Service agent located on SRV-A should connect to that CP (CP=localhost:2217). The port number 2217 is the listening port of the CP. 

    The DB-Service agent is a "normal" DB agent executable, that does not use its own ini-file, but the ini-file of his local Automic server (ucsrv.ini) The Agent should be started using a SMGR (this can be the same SMGR the server processes are started with). The start command of the DB_Service agent looks like this:

    /usr/lib/jvm/adoptopenjdk-11-hotspot/bin/java -jar -Xmx256M /opt/automic/v12.3.4/Automation.Platform/Agents/SQL/DB-SERVICE@SRV-A/bin/ucxjsqlx.jar -service  -i/opt/automic/v12.3.4/Automation.Platform/AutomationEngine/bin/ucsrv.ini

    Note the Parameter -service and the -i. The latter tells the agent at startup: don't use your own ini, use the servers' ini. That ini provides you with your name and the CP that you should connect to.

    Once the DB-Service is started, it appears as active in the SMGR-Dialog:




    The DB-Service agent can be implicitly used in VARA.SQL (not in a VARA.SQLI), meaning it can't be choosen manually by a user. And in CONN-objects to test a connection to an DB. It can not be used in a JOBS.SQL!

    Cheers
    Christoph

    ------------------------------
    ----------------------------------------------------------------
    Automic AE Consultant and Trainer since 2000
    ----------------------------------------------------------------
    ------------------------------



  • 5.  RE: DBService Agent for Seccond Node

    Posted Dec 06, 2021 07:01 AM
    Edited by Emre Boler Dec 06, 2021 07:03 AM
    Hi @Christoph Rekers,

    Thank you for your explanation. 

    Actually ucsrv.ini files and smgr looks exactly the same.

    Also defined ports ucsrv.ini. for A 2217-2219 for B 2218-2220
    For Node A:
    cp: localhost:2217
    For Node B:
    cp: localhost:2218

    While one of the agents is closed, the other connection is working without any error, but if both agents are up, the following situation occurs.

    I want to explain the problem with some real parameters.

    DBService1 up
    DBService2 up


    Login1 Object Created with agent: DBService1


    Login2
    Object Created with agent: DBService2


    Con1 with login1: Works well, always working


    Con2 with login2: Error No login entry, always getting the error. (When I stoped DBService1 then CON2 works well with same settings)

    VARA.SQL with Login1 + Con1 in preview : Sometimes it works, sometimes it doesn't.Sometimes means 50%

    Sometimes works...


    VARA.SQL with Login2 + Con2 in preview : Sometimes it works, sometimes it doesn't.Sometimes means 50%
    Sometimes work...



    Thanks in advance...

    ------------------------------
    Emre
    ------------------------------



  • 6.  RE: DBService Agent for Seccond Node

    Posted Dec 07, 2021 04:01 AM
    Hi @Emre Boler,

    I can confirm the same behavior. I would suggest to open a ticket. (Testet version: V12.3.4, Server OS= Linux, DB=Postgresql 10)



    Cheers
    Christoph

    ------------------------------
    ----------------------------------------------------------------
    Automic AE Consultant and Trainer since 2000
    ----------------------------------------------------------------
    ------------------------------



  • 7.  RE: DBService Agent for Seccond Node

    Posted Dec 07, 2021 04:56 AM

    Hey there,

    Is there a typo in your description of cp ports of both ae?

    ae1 - 2217 to 2219, ae2 - 2218 to 2220

    But in that case 2218 and 2219 falls in the range of both, which is incorrect.

    BTW why both agents have 127.0.0.1 as IP?

    The CONN objects are the same, right? The field for LOGIN object is not required if you use the 'alternative username and password fields"

    Please try it both ways.

    Moreover in your LOGINs the username/password looks the same but you are limiting them for 1 login object for 1 agent, which is kinda odd in this case.

    Why simply not use 1 login object and have * in the AGENT name. 

    I believe this would resolve your issue.

    It is happening because the DB Service Agent used for resolving is picked up randomly. Hence if you are limiting by LOGIN object with credentials only for DBSERVICE1 and not DBSERVICE2, you will have ~50% successrate as it will be successfull only when DBSERVICE1 is used.

    This is clearly visible in your screenshots. 

    The reason to have 2 DBSERVICE agents is to ensure HA. When one of them is down (or the whole AE server) the other to take the action instead. Limiting your LOGIN objects for only specific agent is controversial to the above.

    P.S. If you add username/password to the 'alternative' fields in the CONN objects you wont need LOGIN objects neither in CONN or VARA.SQL.



    ------------------------------
    ------------------------------
    Automic SME @ DXC.Technology
    ------------------------------
    ------------------------------



  • 8.  RE: DBService Agent for Seccond Node

    Posted Dec 08, 2021 03:42 AM
    Edited by Christoph Rekers Dec 08, 2021 08:29 AM
    @Emre Boler @ALL

    ​​​Okay, let's sort this out (for all that aren't familiar with the DB_SERVICE). Valid for V12.x

    ...for the records:

    1. The so called DB_SERVICE consists of a normal database agent executable

    2. It can be installed in any directory of the AE server machine. Give it it's own directory in case you also run a "normal" database agent on the AE server machine. Dont't run the same normal database agent executable twice (normal + DB_SERVICE). That's also important for so called RA-agents, but this is a different story...

      ADDED: to be precise: the DB_SERVICE agent can be installed on any machine, but it still needs to have the server.ini. It can be copied to e.g. the agents bin, but than the CP= in the [DB_SERVICE] section needs to contain the actual Automic servers's machine name or IP adress instead of "localhost" (see below) and the ServiceManager (uc4.smd) needs to point the the adapted location of the server.ini (ucsrv.ini) like -i/install/path/of/dbservice/bin/ucsrv.ini

    3. The DB_SERVICE doesn't use its own ini-file, it uses the AE server's ini-file, where it get's its name from and also the connection parameter to connect to its CP. This is typically CP=localhost:2217 , where 2217 is the listening port of one of the local CPs

    4. The DB_SERVICE agent needs to have a subfolder to its "bin", called "jdbc". This folder contains one jdbc driver for each type of database the DB_SERVICE should connect to. It is important to only have 1 (one) driver per DB type, preferably the most current.

    5. The DB_SERVICE agent needs to be started with two additional parameters (in comparison to "normal" agents). The first paramiter is -service (litterally "minus service"). The second is -ilocation_and_name_of_servers_ini. Note that there's no blank between -i (litterally "minus lowercase i") and the path.

    6. If the servers.ini (ucsrv.ini) does not contain the name of the DB_SERVICE agent - section [DB_SERVICE]  - the agent will report the machine's name as its own name to the AE server. This works, as long as the local OS agent (Win/UNIX) has not already been started with this name. So it's a good idea to pre-define the name in the [DB_SERVICE] section of ucsrv.ini

    7. The agent writes its logs to its temp directory. The name is DB_SERVICEsrv_log__xx.txt

    8. The DB_SERVICE agent can be started using the ServiceManager. The comand pattern looks like this:
      java -jar ucxjsqlx.jar -service -i/path/to/servers/ini/ucsrv.ini

      On my machine this is the full command:

      /usr/lib/jvm/adoptopenjdk-11-hotspot/bin/java -jar -Xmx256M /opt/automic/v12.3.4/Automation.Platform/agents/SQL/DB-SERVICE@SRV-A/bin/ucxjsqlx.jar -service -i/opt/automic/v12.3.4/Automation.Platform/AutomationEngine/bin/ucsrv.ini

    9. The agent should have "sufficient" memory at hand. For my system and its load 256MB are sufficient: -Xmx256M

    10. Once the agent is started it appears in the Administration panel of client 0000. Technically it isn't neccessary to enable the agent for any client. CONN objects for VARA.SQLs (not to be confused with VARA.SQLI, these don't use CONN objects), can be created in Client 0000 and later be "consumed" in any other client. The same applies to LOGIN objects that migt be used in VARA.SQLs or other objects.

      All Automic Admins should keep in mind, that CONN objects for DB connections (and Webservices) are counted as agents, which require a valid agent licence! So it might be a good idea, to create DB-CONN objects only on user's demand in client 0000 and prevent the creation in all other clients.

    11. When DB-CONN objects are tested against any database, it is the DB_SERVICE agent that creates the connection to the remote database, regardless whether the CONN object is later on used in a VARA.SQL or a JOBS.SQL. In other words: when no DB_SERVICE agent is in use, CONN objects can't be tested using the "Test" button (see screen shot below).

    12. DB-CONN objects provide a field where a LOGIN object can be entered. This LOGIN can hold one or more DB_SERVICE agent entries or a star in the "agent field".

    13. In an 2-Server environment two DB_SERVICE agents can be set up to ensure high availability. If the AE has two DB_SERVICE agents at hand, it picks one agent to execute the VARA.SQL command. The server stays with the DB_SERVICE agent he has initially choosen. This is the first DB_SERVICE agent that connects to the server. If a CONN object uses a LOGIN object that just contains DB_SERVICE-agent-B but Agent-B was the second that has connected to the server, the connection test fails with the message: U00052010 UCUCM: Login 'LOGIN.SQL.B' for connection 'CONN.POSTGRESQL.' could not be resolved. Reason: 'no_Login_Entry' => it's obvious that this message is misleading/wrong. 
      If DB_SERVICE-agent-A disconnects, the server falls back to DB_SERVICE-agent-B and the test will succeed.

      => Conclusion: create one single LOGIN object that holds both agents and the credentials (DB-User and PW) for the database that needs to be accessed.


    Here's my setup:

    ucsrv.ini
















    Hope this clarifies the DB_SERVICE 

    Cheers
    Christoph



    ------------------------------
    ----------------------------------------------------------------
    Automic AE Consultant and Trainer since 2000
    ----------------------------------------------------------------
    ------------------------------