Scope
Solution Manager 7.1 SP05 and higher
Terminology
- The term 'host' does NOT designate a network alias. Hosts must have their own IP addresses.
- A 'virtual host' designates a simulated host running for example on top of a VMware.
- A 'logical host' designates a network/host configuration which associates a physical host with one or more additional host names and dedicated IP addresses. This is used, for example, to be able to move systems from one physical host to another.
N.B.: To find the host name of an ABAP system, use transaction sm51, and for Java systems refer to the System Info Web page.
Introduction
Solution Manager 7.1 SP05 introduced a so called Agents-on-the-fly feature. It offers a built-in infrastructure/principle to put in place appropriate Diagnostics Agent landscapes in the context of High Availability environments, where SAP Systems or DB switch/fail-overs are occurring. With this Solution Manager built-in feature there is no more need to configure for example some proprietary High Availability Managers or to adapt failover scripts.
Note that the Agents On-the-fly feature could also be useful in the context of Physical/Virtual hosts running a high number of Logical hosts.
Existing Diagnostics Agent installations, which are already operational, should remain in place and no further action is required (from an agent installation/configuration point of view).
However, SAP recommends to consider the usage of the agents-on-the-fly feature, at the time NEW or ADDITIONAL systems are being or planned to be managed in ONE given Solution Manager system, and ONLY IN CASE these managed systems are operated in a high availability environment, or running on physical or virtual hosts having a high number of logical hosts.
You will find in the following two tables a check list of all important actions and possible pinpoints to take care of. In case you will put in place agents-on-the-fly, you need to evaluate the Managed system environment : "high availability" and/or "physical/virtual hosts running a high number of logical hosts". Depending on this environment use either the recommendations of the first table or the second below table.
Prerequisite
The "hosts file" format can severely impact the Diagnostics Agent, the SAP Host Agent and the connectivity between the managed systems and Solution Manager. More information: https://wiki.scn.sap.com/wiki/x/i4IjIQ
In case managed systems run with hostnames that are "simple" network hostname aliases (meaning not logical hostnames with dedicated IP addresses, like described in the above Terminology), the presently documented Agents On-the-fly feature will not work.
Further details on how to declare (fully qualified) logical hostnames with dedicated IP addresses could be found in SAP note 962955. (N.B.: For the Agents On-the-fly, do NOT consider item 4 in the procedure described in that SAP note.)
In case of doubts feel free to execute the following command on the Physical or Virtual Host to double check whether the (Logical) hostnames used by the Managed systems are listed.
- On Windows:
"C:\Program Files\SAP\hostctrl\exe\saphostctrl.exe" -function GetComputerSystem - On Unix:
/usr/sap/hostctrl/exe/saphostctrl -function GetComputerSystem - Output example, showing under entry ITSAMComputerSystem, that 5 hostnames are currently known/operated by this host, where the command is executed.
Having a closer look, we see 4 logical hostnames: db6lparci.wdf.sap.corp (IP 10.xxx.xxx.33), db6lparascs.wdf.sap.corp (IP 10.xxx.xxx.253), db6lpardb.wdf.sap.corp (IP 10.xxx.xxx.99), db6lparers.wdf.sap.corp (IP 10.xxx.xxx.153), and the underlying PhysicalHostA.wdf.sap.corp (IP 10.xxx.xxx.217):
*********************************************************
CreationClassName , String , ITSAMComputerSystem
Name , String , PhysicalHostA
Hostnames , String[] sep=; , PhysicalHostA.wdf.sap.corp;db6lparci.wdf.sap.corp;db6lparascs.wdf.sap.corp;db6lpardb.wdf.sap.corp;db6lparers.wdf.sap.corp;localhost;
IPAdresses , String[] sep=; , 10.xxx.xxx.217;10.xxx.xxx.33;10.xxx.xxx.253;10.xxx.xxx.99;10.xxx.xxx.153;127.0.0.1;
*********************************************************
[...]
It is recommended - as indicated in the following tables - to install "clean/fresh" Diagnostics Agents. Use the latest Diagnostics Agent installation package that is available on SMP (for information on the latest installer refer to SAP note 1833501). This will bring latest fixes and improvements for Installer, Kernel and JVM. The Agents must be installed at Physical or Virtual host level.
The Diagnostics Agents are also SAP systems, they have a System ID (SID) like DAA and an Instance-ID like SMDA97.
Do NOT use the possibility to install additional Diagnostics Agent instances for a given Diagnostics Agent SID (like DAA). In the context of the Agents On-the-fly feature, this type of Agent organization (same SID with multiple instances like 98, 97, etc.) is NOT allowed. For instance, when installing the Diagnostics Agents on shared/clustered file systems (/usr/sap), pay attention to use distinct SIDs.
Also consider SAP note 1365123 and the there attached document.
Note that all Diagnostics Agents/Agents On-the-fly, at Physical/Virtual or Logical host level, by default perform Outside Discovery. Specifically the Database and IIS discovery processing shall be switched off for Agents On-the-fly (running at Logical host level), as this data is already collected by the Diagnostics Agent (Physical/Virtual host level). Therefore consider the performance improvement related recommendations from SAP note 1611483.
Remark for Physical/Virtual Hosts running Windows 2003
As indicated in SAP note 1108852, check that the saploc share - if it exists - points to local drive.
If it points to the shared drive, delete the saploc share, before installing the Diagnostics Agent.
Remark related to MS SQL
As indicated in SAP note 1458291, make sure that at the time you are installing the Diagnostics Agent you choose one of the domain options, as the Agent has to run under a domain login, in order to avoid having potentially a high number of SQL Server Error Logs (related to login errors).
How to proceed in case Diagnostics Agents are already installed for the Managed Systems?
You will find in the following two tables a check list of all important actions and possible pinpoints to take care of. In case you will put in place Agents On-the-fly, you need to evaluate the Managed system environment : "High Availability" and/or "Physical/Virtual hosts running a high number of Logical hosts". Depending on this environment, either use the recommendations of the first table, or the second below table.
Note that SAP recommends removing any existing Diagnostics Agents on the underlying hosts.
Refer to the Diagnostics Agent Removal procedure described in Diagnostics Agent Maintenance Procedures.
Diagnostics Agent installation/deployment strategy in the context of Agents On-the-fly
Installation Strategy in an High Availability context (system switch over)
Where ? | Preparation | Installation | Setup | Remark |
---|---|---|---|---|
On ALL Physical or Virtual Hosts participating in a given switch/fail-over (switch between Host A & B) | Uninstall ALL Diagnostics Agents previously existing on these Physical or Virtual Hosts. Especially pay attention to the Diagnostics Agent Removal and the Byte Code Adapter aspects in the context of Java Managed Systems, as described in Diagnostics Agent Maintenance Procedures. | Install on ALL Physical or Virtual Hosts (part of the group) one Diagnostics Agent (latest version, see prerequisites section) without specifying any Logical hostname in SWPM. Also see SAP note 1365123. | Run for EACH Physical or Virtual Managed host the solman_setup -> Managed System Configuration -> Host to enable the Agents On-the-fly feature in step "Enter System Parameters" | The "Display resulting host list" button in step "Enter System Parameters" is showing the list of logical hostnames for which an Agent On-the-fly will be created only at the time these logical hostnames are associated to the presently configured Physical or Virtual Host. |
Logical Hosts (for example L1, L2, L3) | Uninstall any Diagnostics Agents which might have been installed in earlier times with a Logical hostname L1, L2 or L3. Especially pay attention to the Diagnostics Agent Removal and the Byte Code Adapter aspects in the context of Java Managed Systems, as described in Diagnostics Agent Maintenance Procedures. | Install no further Diagnostics Agent (other than those mentioned in the above table line). | In case one or several Managed Systems (including SCS instances in the context of SolMan 7.1 SP08 and higher) are installed with these L1, L2, L3 Logical hostnames, run also as usual the Managed System Configuration (in solman_setup transaction) for each of them. See also below chapter "Important remark concerning Java Managed systems on logical hosts". | In case no Diagnostics Agent is available in solman_setup -> Managed System Configuration -> "Assign Diagnostics Agent" for the Managed system, double check the "Remark" of above two table lines |
- N.B.: The above situation description applies in the context of one Solution Manager system. In case the Managed systems/hosts should be visible in one additional Solution Manager system, one additional Diagnostics Agent has to be installed using a new different System-ID. And this new additional Agent will then be configured in the solman_setup of that additional Solution Manager system, like described above.
- N.B.: The "Display resulting host list" button in step "Enter System Parameters" shows the list of logical hostnames for which an Agent On-the-fly will be created (only at moments where these logical hostnames are associated to underlying Physical or Virtual Host). Also note that the displayed hostname list is computed based on the Hostnames attribute returned by the following SAP HOST Agent command. It therefore does NOT include any network hostname alias. In case of doubts feel free to execute that command on the Physical or Virtual Host.
- On Windows:
"C:\Program Files\SAP\hostctrl\exe\saphostctrl.exe" -function GetComputerSystem - On Unix:
/usr/sap/hostctrl/exe/saphostctrl -function GetComputerSystem
- On Windows:
Installation Strategy outside any High Availability context (system switch over)
Environment | Preparation | Installation | Setup | Remark |
---|---|---|---|---|
No logical hostname is used on Physical or Virtual Host A | N/A | Like with earlier Solution Manager Support Packages install on Host A - if not already done - one Diagnostics Agent (latest version, see prerequisites section) without specifying any Logical hostname in SWPM. Also see SAP note 1365123. | Only run (like with earlier Solution Manager Support Packages) the Managed System Configuration for each Managed System running on this host in solman_setup | In case no Diagnostics Agent is available in solman_setup -> Managed System Configuration -> "Assign Diagnostics Agent" for the Managed system, double check whether the installed Diagnostics Agent is connected to Solution Manager using the Agent Administration UI |
Low amount of Logical hosts running on Physical or Virtual Host A | N/A | Like with earlier Solution Manager Support Packages install on Host A one Diagnostics Agent (latest version, see prerequisites section) per Logical hostname - if not already done - and take care to specify each time the relevant Logical hostname in SWPM. Also see SAP note 1365123. | Only run (like with earlier Solution Manager Support Packages) the Managed System Configuration for each Managed System running on these logical hosts in solman_setup | In case no Diagnostics Agent is available in solman_setup -> Managed System Configuration -> "Assign Diagnostics Agent" for the Managed system, double check whether the installed Diagnostics Agent is connected to Solution Manager using the Agent Administration UI |
High amount of Logical hosts running on Physical or Virtual Host A | Uninstall all Diagnostics Agents previously existing on Host A. Especially pay attention to the Diagnostics Agent Removal and the Byte Code Adapter aspects in the context of Java Managed Systems, as described in Diagnostics Agent Maintenance Procedures. | Install one Diagnostics Agent (latest version, see prerequisites section) on the underlying Physical or Virtual Host A, without specifying any Logical hostname in SWPM. Also see SAP note 1365123. | First run solman_setup -> Managed System Configuration -> Host for Managed Host A to enable the Agents On-the-fly feature in step "Enter System Parameters". See also below chapter "Important remark concerning Java Managed systems on logical hosts". | The "Display resulting host list" button in step "Enter System Parameters" is showing the list of logical hostnames for which an Agent On-the-fly will be created only at the time these logical hostnames are associated to Host A. |
- N.B.: The above situation description applies in the context of one Solution Manager system. In case the Managed systems/hosts should be visible in one additional Solution Manager system, one additional Diagnostics Agent has to be installed using a new different System-ID. And this new additional Agent will then be configured in the solman_setup of that additional Solution Manager system, like described above.
- N.B.: The "Display resulting host list" button in step "Enter System Parameters" shows the list of logical hostnames for which an Agent On-the-fly will be created (only at moments where these logical hostnames are associated to underlying Physical or Virtual Host). Also note that the displayed hostname list is computed based on the Hostnames attribute returned by the following SAP HOST Agent command. It therefore does NOT include any network hostname alias. In case of doubts feel free to execute that command on the Physical or Virtual Host.
- On Windows:
"C:\Program Files\SAP\hostctrl\exe\saphostctrl.exe" -function GetComputerSystem - On Unix:
/usr/sap/hostctrl/exe/saphostctrl -function GetComputerSystem
- On Windows:
Important remark concerning Java Managed systems on logical hosts
For NW AS Java based Managed Systems do NOT forget to mark the option "Deploy Byte Code Adapter under Managed System Instance(s)" within "Enter System Parameters" under Managed System Configuration / Technical Systems or Technical Scenarios (before 7.1 SP12 this option was called "Ensure HA virtualization compatibility").
Also provide a relative path, like "ByteCodeAdapter", for the "Introscope BC Adapter deployment path" field, in order to locate the BC Adapter binaries and configuration files inside the Managed system directory structure (/usr/sap/<ManagedSID>/<InstanceID>/ByteCodeAdapter). Note that the Diagnostics Agent OS user (member of the SAPSYS OS group) must therefore also have write permissions at this Managed System path location.
Remark: Note that it is just necessary to provide the folder name. The Introscope BC Adapter files will be placed under the managed system instance path((/usr/sap/<ManagedSID>/<InstanceID>/) plus the folder name provided.
Agents On-the-fly concept
Concept
When for a given Diagnostics Agent (installed for a Physical or Virtual host) the Agents On-the-fly feature is enabled, this Agent can potentially run additional Diagnostics Agent processes (Agents On-the-fly), under his SID and Instance Number. These additional processes are considered as being Diagnostics Agents On-the-fly or "Nodes".
The rule for having additional or less of these Agents On-the-fly at a given point in time is as follow. Whenever a new (Logical) hostname is visible on the underlying (Physical or Virtual) host, the Diagnostics Agent (installed initially), will automatically create one additional Agent On-the-fly. However when this Logical hostname is no longer associated with that underlying (Physical or Virtual) host, the Diagnostics Agent will stop and remove again the associated Agent On-the-fly.
N.B.:
- With this approach, the number of Diagnostics Agent instances (allocated Instance Number) on a Physical or Virtual, is also independent of the number of Managed Systems/Logical Hosts.
- Two Agents On-the-fly will have the same memory footprint as two "standard" Diagnostics Agents. However, note that the Diagnostics Agent installed on the underlying (Physical or Virtual) host has to be additionally considered for the overall memory footprint. At disk space level the Agents footprint will be less given that the SAPJVM & Kernel binaries are shared.
- Remember that network hostname aliases will not be considered. For further details refer also to the below "Enable the Agents On-the-fly feature" item description in the Setup storyboard.
Example
Landscape components
Hostname layout
Failover scenario
- Cluster Manager detects/triggers a DB failover
- Logical Host/IP is moved to failover cluster node
- DB instance is started on failover cluster node
- Diagnostics Agent (DAA) detects a change in the Logical Host allocation
- Agent On-the-fly on DAA is stopped/removed and created/started on DAB, according to the new cluster layout
- Normal operation can continue transparently
Setup Story Board
solman_setup transaction entrance
N.B.: The values P,V or L in the column "Host Type" mean respectively Physical, Virtual or Logical host. See also the initially presented terminology.
Assign Diagnostics Agent installed on Physical or Virtual Host level
Enable the Agents On-the-fly feature
N.B.: The "Display resulting host list" button in step "Enter System Parameters" shows the list of logical hostnames for which an Agent On-the-fly will be created (only at moments where these logical hostnames are associated to underlying Physical or Virtual Host). Also note that the displayed hostname list is computed based on the Hostnames attribute returned by the following SAP HOST Agent command. It therefore does NOT include any network hostname alias. In case of doubts feel free to execute that command on the Physical or Virtual Host.
- On Windows:
"C:\Program Files\SAP\hostctrl\exe\saphostctrl.exe" -function GetComputerSystem - On Unix:
/usr/sap/hostctrl/exe/saphostctrl -function GetComputerSystem
Finally, with SAP Solution Manager 7.1 SP10 or higher, remind to start the "Agent On-the-fly Administration" UI, in order to double check whether the expected Agents On-the-fly are created and connected. It is accessible via the "Advanced Settings" tab, within the Agent Administration UI.
Or, prior to SAP Solution Manager 7.1 SP10, double check in the "Agent Administration" UI.
N.B.: Use the SID/InstanceID to understand for each Agent On-the-fly by which Diagnostics Agent is has been created. Note that the Agent On-the-fly Instance ID includes the Logical hostname.
Frequently Asked Questions (FAQ)
Q: First actions in case an Agent On-the-fly does not seem to react on a Logical Hostname switch-over (from Physical/Virtual Host A to B)
- On Physical/Virtual Host A and Host B execute each time the following command to double check whether the Logical hostname move occurred as you expect at OS level and is seen by the SAP Host Agent.
- For Windows:
C:\Program Files\SAP\hostctrl\exe\saphostctrl.exe -function GetComputerSystem - For Unix:
/usr/sap/hostctrl/exe/saphostctrl -function GetComputerSystem
- For Windows:
- Additionally, perform on each Physical/Virtual Host (A and B) the ping command.
- ping -a <Logical hostname>
- In case the SAP Host Agent reflects correctly the hostname topology proceed as follow:
- Go to solman_setup -> Managed System Configuration -> Host for Host A
- Navigate to step "Enter System Parameters" / field "Local exclusion filter" and write down the currently provided value
- Provide now a new filter (regular expression) to temporarily exlude the concerned Logical hostname
- Press "Save"
- Wait one minute
- In step "Enter System Parameters" / field "Local exclusion filter" provide again the initial value (you written down).
- Press "Save"
- Wait one minute
- Proceed as explained above also for Host B
- In case the problem persists (Agent On-the-fly not moving) kindly open a message on component SV-SMG-DIA-SRV-AGT.
- Go to solman_setup -> Managed System Configuration -> Host for Host A
- In case the SAP Host Agent does not see the Logical hostname as you expect, please open a message on component BC-CCM-HAG.
Q: What actions to take when saving a wrong value in the "Local exclusion filter"
- In the "Local exclusion filter" field from step "Enter System Parameters" correct previously provided (exclusion) pattern
- Press "Save"
- Wait one minute
- In case the previously defined pattern was wrong and had as a consequence that too many Agents On-the-fly were created, also remind to delete from LMDB the not relevant hostnames.
- Therefore start LMDB transaction
- In "Host" tab delete the no longer relevant hosts, which have been created by the outside discovery process run by the Agents On-the-fly
25 Comments
Riccardo Escher
Wow! Thank you very much!
Jon Friesen
This is great, Olivier, and something that we have really been needing. I'm also glad it gives us an alternative to installing many separate agents, when customers have multiple logical hostnames in unclustered environments.
I'd like to clarify one point about the example landscapes above. In your example you show agent DAA and DAB on node A and B. But it seems to me the agents within a cluster must always have the same SID (DAA and DAA) if there is a java bytecode agent in use, since the J2EE configuration will have the /usr/sap/DAA/.../ path hardcoded in the J2EE startup parameters. This might be worth noting or please correct me if I am mistaken.
UPDATE: After rereading your blog I think you have already answered my question with: "in order to locate the BC Adapter binaries and configuration files inside Managed system directory structure". So if this works as expected the J2EE system no longer refers to a JAR file in the /usr/sap/DAA... structure, but rather in the /usr/sap/SID structure of its own instance. That is a terrific improvement and might also mean that the agent could be uninstalled / upgraded without first bouncing the J2EE system (a delicate dependency between the J2EE system and the monitoring agent). I'm going to confirm this in our lab and will report back here.
Unknown User (h8i2twi)
Hi all,
I read the wiki about the new architecture of SMD - agents-on-the-fly. As far as I understand the new usage of SMD is optional - even if SolMgr 7.1 SP 05 is used. If I want to use it I have to enable it explicetly. If I do not enable the feature the old usage scenarios are valid furthermore (I use one SMD instance for a unique service, e.g. CI; an other SMD instance for APP and so on)
Am I right ? Or is the new behavior the default if using SolMgr 7.1 SP 05 ?
Kind regards
Karlheinz
Olivier MONTABERT
Hi Karlheinz Heger,
To answer your question. You are right, this new concept should only be used in the circumstances described in the initial two matrixes.
I have also updated slightly the matrix entitled : Installation Strategy outside any High Availability context (system switch over). I hope this clarifies that the previous ways to install the Diagnostics Agents and to run the setup are still applicable.
Best regards,
Olivier
Andrew Greig
Hello, this looks like a very useful new feature. Could you expand on how I can use the 'Local exclusion filter' when selecting the logical hostnames for which on-the-fly agents should be created ?
In my case of an HA MSCS set-up the ASCS logical host-name is being picked up which I want to exclude as I just want the database logical host-name. Thanks.
Former Member
Hi,
Thanks a lot for this HA OTF guide. It makes my life a lot easier when dealing with HA agent requests.
Many thanks for your efforts to create this guide.
Kind regards,
Peter
Karlheinz Heger
Hi all,
I have still a litte quesion concerning SolManager configuration.
With our infrastructure solution 'FlexFrame for SAP' we have server racks with a lot of Linux servers. In our configuration a SAP service can run on any host of that rack because we have a single-os-image und using NFS (automounts) for accessing SAp specific file structures. If a server fails a HA monitor looks for another server and moves the services which reside on the failing host to another server in the server pool. Those spares are cold standby and if they are requested they are taken into the server pool (adding an image, configure, startup, ...). Those spares are only known by their name, e.g. spare001, spare002, ...
Per default there is no assignment (installation) of a SMD agent-on-the-fly. If the spare is requested we cannot install a SMD agent automatically because of uage of 'sapinst'. But what we have, there are a lot of non-spares running which already have an assigned (installed) SMD agent. My idea is to copy a given SMD installation (hostx, DAA, 97) to the requested spare (spare001/DAB/97) and modify profile name or change DAA to DAB in corresponding files. In principial it works (start/stop SMD agent) - I tried it. But what I do not know - how this works in collaboration with SolManager. I would say the copy contains a correct solution manager configuration - right ? Is it possible to configure the spares 'pro-active' with SolManager (without an given installation of SMD) and is that without problems for SolManager ? Is there a dynamic recognition of 'agents-non-the-fly' if a SMD agents start on the spares.
Kind regards
Karlheinz
Jari Seppänen
Hi,
We have same situation what Karlheinz Heger has described, running SAP in FlexFrame. It is not clear how to make new Solution Manager and agent setup "by the book". We have also understanding, that agent-on-the-fly is not supported in FlexFrame yet.
Is there any instructions directly to FlexFrame environment, since it is supported platform for running SAP systems?
Nice blog anyway!
BR, Jari
Olivier MONTABERT
Hi Karlheinz Heger, Hi Jari Seppänen,
I would like to provide an answer to your questions. You are right that in the context of FlexFrame the Agents On-the-fly support is not working for the time being. However note that we are working on this topic to get this operational by Q3 2013.
Thanks for your valuable input.
>> Update : Please consider also the input provided below by Norbert Sommer.
Best regards,
Olivier
Unknown User (zevc3t3)
Hi Olivier,
Thanks for the write up.
I've got a question. I have two physical machines, and when i use http://:59813 on the primary node it shows only one SID DAX, but AS Java Process table shows 5 processes (smdagent, smdagent_<apphostname1>, smdagent_<ascshostname> smdagent_<scshostname>, smdagent_<oraclevirtualname> ) while on secondary node it shows one SID DAX with 2 processes (smdagent, smdagent_<apphostname1>)
How else can these "OTHER" processes instantiate themselves apart from Enable Diagnostics Agents On-the-flyoption selected ?
(Managed System Setup -> Configure Hosts for <physicalhostname> agent do not seem to have this option selected.
Regards,
James Foo
Former Member
Hi Oliver,
we're also plannning to setup SM 7.1 with agents (possibly on-the-fly) for 2 FlexFrame environments.
Could you provide an update on your earlier comment regarding support for agents on-the-fly in a FlexFrame environment ?
Thanks and Kind Regards, Norbert Sommer
Former Member
Hi Oliver,
looks like agents on-the-fly is exactly what we need for our FlexFrame environments to avoid using a large number of instance numbers just for monitoring agents.
Is the discussed "FlexFrame issue" just the missing support for spare nodes which might not be assigned to a group ?
If we don't have that as all nodes are in use and assigned to a group, can we use the agents on-the-fly with the Q2 2013 (April) patch levels ?
Thanks and Kind Regards, Norbert Sommer
Former Member
Hi all,
the "FlexFrame(R) for SAP(R)" manual from May 2013 for SAP installations on FlexFrame version 5.2 contains extensive instructions for SMD agents on-the-fly
including information on how to deal with pool independent spare nodes, unattended SMD installation and automatic start of the SMD service.
At the moment I think the agent on-the-fly concept would generally also work under FF 5.1 if the SMD instances are started by hand.
Kind Regards, Norbert Sommer
Former Member
Hello,
Very nice guide, it was quite helpful to figure out what to do in my case. However, I have a question I was hoping you could answer.
I have a HA environment. 1 physical host (node A), 1 physical host (node B), 1 CI (virtual hostname), 1 DB (virtual hostname). It is not clear for me, do I need 1 DAA in each physical host? or just 1 in one of the physical hosts?
I ask because in your screenshots, it seems that you installed DAA in node A, and when you assign it to the physical host A and activate Agents-On-The-Fly, it recognizes the virtual hostname of the CI and the DB, and also adds the physical host node B. Am I seeing this correctly?
Because I installed in physical node A, when I assign the DAA to the node A and activate the AOTF, it adds the CI/DB virtual hostnames and the physical node A, but it doesn't add node B.
Does this mean I need to install another DAA in node B and do the same configuration? I would think that this would create duplicate nodes. 2 from node A for the CI/DB, 2 from node B for the CI/DB. Is that so?
I would make sense since if a physical node goes down and it balances to the other, still the nodes from physical node B will still work on the CI/DB. Anyway, I would like if you could confirm it! it sounds redundant.
Thank you,
Kind regards!
Olivier MONTABERT
HI Pablo,
Let me answer your question.
Yes, you have to install one Diagnostics Agent on each physical host (A and B). This will NOT lead to create duplicated Agents On-the-fly, as the logical hostnames (which I guess you are naming virtual hostnames) could only be declared/active on one Physical host (A or B) at a time.
Best regards,
Olivier
Former Member
Hello Olivier,
Thank you for your reply. I have managed to fully configure DAA "on the fly" configuration.
I would like to note something since this is a problem I have found and didn't find information about it anywhere else.
When you do the discovery, it detects the virtual nodes that are running on your system. If in your hostnames you have "ip HOSTNAME-IN-CAPS" instead of "ip hostname-in-lower-case", the node that is created is "SMDagent_HOST-IN-CAPS"... It allow you to register the node to the SLD, no problem.
HOWEVER, when you TRY to CONNECT the DAA "on the fly" to the Solution Manager to do the configuration, it will not work.... It seems that it is trying to find the process with a name "SMDagent_host-in-lower-case" and WILL NOT CONNECT!
We had to modify all the hosts and make the first entry after the IP to reflect a lower-case FQDN...and then when you connect it to the SolMan, it will detect the process perfectly.
Kind regards,
Pablo
Olivier MONTABERT
Hi Pablo,
As far as I know this issue has been fixed since some time now. So I expected that you were working on an older Solution Manager 7.1 SP/patch level.
Best regards,
Olivier
Iurii Tiunov
Hello experts, undortunatelly I do not clearly understant. Could we use the same DAA sid on node A and node B ? If , no, Why ?
Olivier MONTABERT
Hi Iurii,
Yes, you can use the same SID for the Agents (on node A and node B).
The present proposal - to use different SIDs while installating the Diagnsotics Agents on the different physical hosts part of a cluster group - is only a hint to later offer a way to visually distinguish in the Agent Administration UI the Agents On-the-fly running on node A from those running on node B. But this is not mandatory.
N.B.: Starting with Solution Manager 7.1 SP10 the present proposal (using different SIDs) has no longer an interest, as an additional UI is now provided to have an overview of the Agents On-the-fly and their location. This UI is named "Agent On-the-fly Administration" and is accessible from the Agent Administration UI / Advanced Settings.
Best regards,
Olivier
Iurii Tiunov
Great!
Oliver, thaks for the answer.
I have one more question. We faced with this issue due SAP system relocation from one physical host to another. I think my notice would be important in case of "Agents on the fly" concept.
We are using Solution Manager Technical monitoring, so on Application server\DB level uses logical hostnames but for monitoring hosts - physical hostnames uses. When we relocate SAP between physical hosts (logical hosts not changed) SMD agent also relocated and started for logical host successfully (like in agent on the fly concept). But for continue host monitoring we need to assign host template and activate it again in Technical Monitoring setup in Solution Manager.
I think the same situation will be exists in case of agent on the fly strategy. Is some workaround solution exists in this case ?
Olivier MONTABERT
Dear Iurii,
You are right. This is a known situation in the Technical Monitoring area, even when using Agents On-the-fly. You are right that it is not very convenient.
But, with Solution Manager 7.1 SP10 this operation has been automated as far as I know. Therefore the host template assignment and activation is reexectued on its own, in case the Logical host gets associated to a different Physical/Virtual host within LMDB. This occurs in case the so called Host outside discovery is operational.
Best regards,
Olivier
Vitaly Kirienko
Hi Olivier,
can you please specify which HA-technologies are currently supported by Agents on-the-fly concept?
Thanks, Vitaly
Sankara Bavirisetti
Hello Guys,
my ECC on distributed environment on HDB , does it support Agents -fly concepts or else I need to install Agent on each application sever, DB host etc.?
Regards,
Sankara
Vincent Segami
Hi Oliver,
We are getting the error below. SAPHostAgent Release: 721 | Version: 13
[EXCEPTION]
java.rmi.RemoteException: Webservice invocation error occured on stub com.sap.smd.agent.wsclients.saphostcontrol.SAPHostControlStub@5c381deb; nested exception is:
javax.xml.rpc.soap.SOAPFaultException: Failed to load SAP_ITSAMComputerSystem data
at com.sap.smd.agent.plugin.connectors.webservice.WebserviceInvocationHandler.invoke(WebserviceInvocationHandler.java:113)
at com.sun.proxy.$Proxy3.getComputerSystem(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at com.sap.smd.api.util.SynchronizedProxy$SyncHandler.invoke(SynchronizedProxy.java:32)
at com.sap.smdagent.plugins.connectors.webservice.RetryIfUnauthorizedProxy$RetrySyncHandler.singleInvoke(RetryIfUnauthorizedProxy.java:56)
at com.sap.smdagent.plugins.connectors.webservice.RetryIfUnauthorizedProxy$RetrySyncHandler.invoke(RetryIfUnauthorizedProxy.java:34)
at com.sun.proxy.$Proxy3.getComputerSystem(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at com.sap.smd.agent.facade.hostagent.HostAgentSyncProxy$SyncHandler.singleInvoke(HostAgentSyncProxy.java:111)
at com.sap.smd.agent.facade.hostagent.HostAgentSyncProxy$SyncHandler.invoke(HostAgentSyncProxy.java:65)
at com.sun.proxy.$Proxy4.getComputerSystem(Unknown Source)
at com.sap.smd.agent.plugins.dcc.job.PhysicalHostPushJob.executeOutsideDiscovery(PhysicalHostPushJob.java:382)
at com.sap.smd.agent.plugins.dcc.job.PhysicalHostPushJob.run(PhysicalHostPushJob.java:257)
at com.sap.smd.server.exec.TaskRunner.run(TaskRunner.java:47)
at com.sap.smd.server.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:781)
at java.lang.Thread.run(Thread.java:809)
Caused by: javax.xml.rpc.soap.SOAPFaultException: Failed to load SAP_ITSAMComputerSystem data
at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.buildFaultException(MimeHttpBinding.java:747)
at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.processDocumentFault(MimeHttpBinding.java:870)
at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.call(MimeHttpBinding.java:1454)
at com.sap.smd.agent.wsclients.saphostcontrol.SAPHostControlStub.getComputerSystem(SAPHostControlStub.java:910)
at com.sap.smd.agent.wsclients.saphostcontrol.SAPHostControlStub.getComputerSystem(SAPHostControlStub.java:926)
Can you explain what is causing this error?
Olivier MONTABERT
Hi Vincent,
Kindly try to install the latest available SAP Host Agent patch version, when you encounter this kind of error (SOAPFault).
And open a ticket on BC-CCM-HAG, in case this doesn't help.
Best regards,
Olivier