SUSE / ha-sap-terraform-deployments

Automated SAP/HA Deployments in Public/Private Clouds

GNU General Public License v3.0

122 stars 88 forks source link

Monitoring VM has no route for the Netweaver PAS and AAS monitoring exporter IP (sap_host_exporter) #740

Closed diegoakechi closed 3 years ago

diegoakechi commented 3 years ago

Used cloud platform Azure

Used SLES4SAP version SLES for SAP 15.2

Used client machine OS openSUSE TW.

Expected behaviour vs observed behaviour

The PAS and AAS sap_host_exporter targets should be available on Prometheus, but currently, they appear configured by Down.

Currently, there is a secondary IP and vHostname sapha1pas used by the sap_host_exporter monitoring. On etc/hosts we see:

10.74.1.30      vmnetweaver01
10.74.1.31      vmnetweaver02
10.74.1.32      vmnetweaver03
10.74.1.33      vmnetweaver04
10.74.1.34      sapha1as
10.74.1.35      sapha1er
10.74.1.36      sapha1pas
10.74.1.37      sapha1aas1

But there is no Static IP associated with the NIC used by the machine. Adding it manually solves the problem (IP 10.74.1.36 was added manually):

How to reproduce

The default deployment of HANA + Netweaver + Monitoring using the Develop branch produces this end-result.

Logs This was spot on the Trento Demo deployment. The logs can be collected there.

diegoakechi commented 3 years ago

This is apparently a regression of https://github.com/SUSE/ha-sap-terraform-deployments/pull/710

yeoldegrove commented 3 years ago

This is apparently a regression of #710

my bad ... I will look into it.

710 was merged to fix #611

diegoakechi commented 3 years ago

@yeoldegrove No worries ;)

yeoldegrove commented 3 years ago

722 introduces some logic to add VIPs to PAS/AAS instance NIC and also to ASCS (in non-HA use case). The logic can get quite complex.

A decision has to be made:

1. use logic from #722 to add VIPs to NIC
  - only in azure, as other cloud providers work
1. do not use VIPs at all for PAS/AAS
  - remove code from all cloud providers
  - same logic as in i. has to be implemented to pass "real IP" as VIP to pillar
1. use "real IP" to monitor NW
  - might not be that easy, as virtual host name is set in /etc/sap_host_exporter/${SID}_PAS${INSTANCE}.yaml and this comes directly from the pillar
  - logic in pillar/tf code has to be changed which might be as complex as i.

There might be other solutions that I cannot think of at the moment.

yeoldegrove commented 3 years ago

@arbulu89 What is your opinion on this?

arbulu89 commented 3 years ago

HI @yeoldegrove ,

Assuming that the PAS and AAS services won't move from their host machines, I think we could use the option 2, as it looks the easier and quite reasonable.

yeoldegrove commented 3 years ago

750 implements a solution to this problem now

summed up:

The Netweaver virtual IPs for AS/ERS are reachable via different mechanism for public clouds:

azure -> load-balancer gcp -> route to VM (changed by cluster) aws -> route to VM (changed by cluster) For the Netweaver virtual IPs for PAS/AAS there is currently no mechanism implemented to make them reachable to other nodes.

This PR makes these PAS/AAS virtual IPs reachable via these mechanisms:

azure -> vIP on network interface on VMs load-balancer setup would also be possible in theory but is way more complex (e.g. create rules per node) gcp -> route to VM (static) aws -> route to VM (static)