CAL: S/4 1610 No Connection despite all VMs green in CAL

[DirkS]

I have created a solution instance for a 1610 fully activated appliance 2 days ago. Since the daily restart today, I can no longer reach the system via the Fiori launchpad URL. However, in the CAL portal all VMs of the solution are displayed active/active. When I try to connect with the launchpad URL there is no error message at all. It looks like the launchpad service is just not running at all. No change after rebooting the instance by the way....everything green...but launchpad URL seems to be dead. Any idea what I can do about it ?

[achim_bode · Accepted solution]

Hi Dirk,

can you please post the content of /usr/sap/sapservice? Also a check of the DNS resolution will help us in finding the problem. Can you please post the output of

ping -c 3 vhcals4hci

ping -c 3 vhcalhdbdb

ping -c 3 vhcals4hcs

Last but not least the output of ps -edalfH might help as well.

Regards,

Achim

[DirkS · Accepted solution]

New log files are sent.

[former_member324206 · Accepted solution]

Hello Dirk,

We would need also the output of the ifconfig command on the failing system.

Thanks and best regards,

Atanas

[DirkS · Accepted solution]

Here we go:

sid-hdb-s4h:s4hadm 55> /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:0D:3A:26:09:56
inet addr:10.0.0.4 Bcast:10.31.255.255 Mask:255.224.0.0
inet6 addr: fe80::20d:3aff:fe26:956/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:40273 errors:0 dropped:1 overruns:0 frame:0
TX packets:37321 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:30342387 (28.9 Mb) TX bytes:4445747 (4.2 Mb)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:5169 errors:0 dropped:0 overruns:0 frame:0
TX packets:5169 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:366396 (357.8 Kb) TX bytes:366396 (357.8 Kb)

[former_member324206 · Accepted solution]

Hello Dirk,

The root cause not to start the system after suspend/activate is that the internal IP address of your instance has been changed unexpectedly. Could it be that somebody from your organization changed the IPs of the VMs after the initial startup (Please note that CAL is reserving the internal IPs as static and they are not meant to be changed).

Option 1: Terminate this instance and create a new one.

Option 2: On each virtual machine update the /etc/hosts file with the current IP addresses (found in Azure portal or by issuing ifconfig on OS level) and reboot the VMs. Note that SAP CAL won't update the IP entries in it's GUI, because we rely that they are static.

Best regards,

Atanas Lozanov

[DirkS · Accepted solution]

Hello Atanas,

Thank you for your accurate root cause analysis. Don't ask me why but the ABAP/HANA VM was configured with dynamic IP in the Azure portal. All other VMs of the solution are configured with static IP. As I am currently the only user with admin access to the Azure VMs, no one else can have modified this setting...and I am sure that I didn't modify it either. I have now switched over the VM to the same static IP it had before, restarted it and the SAP system is now working properly again - THANK YOU !!

However, I still wonder how the problem initially occured. Will let you know in case I can reproduce it.

Regards,

Dirk Sassmannshausen

[DirkS · Accepted solution]

I have done some more investigation and I think I found out what initially caused the problem. Whenever you change the port settings via the CAL portal for the instance, e.g. open up an additional HTTPs port, the IP address assignement of the VM in Azure miraculously switches from static to dynamic IP. As a result, with the next restart the system comes up with a new internal IP which causes the SAP system start to fail. I remember I opened up port 50000 in order to get access to oData services from Web-IDE and in my opinion this caused the issue.

Maybe something SAP could invest further with MS to tackle this and avoid problems for other users in the future.

[stanimir_eisner · Accepted solution]

Hi Dirk,

Thanks for sharing the results of your investigation.

Our investigation came to the same root cause. We were able to apply a fix yesterday so the problem should not appear again.

Best regards,

Stanimir

[DirkS]

Hello Stanimir,

Thank's for your quick response. The IP address is still the same (the solution is configured with static external IP and I verified it didn't change). For OS access, I have to wait for firewall clearance. Will get back to you with the logs as soon as I can connect with SSH.

Regards,
Dirk

[stanimir_eisner]

Hello Dirk,

In order to investigate the problem we need to check the logs from the VM with SAP S/4HANA.

Could you connect to the OS to collect the following logs?

/var/log/appliancedeploy.log
/var/log/applianceboot.log
/var/log/applianceagent.log
/var/log/sap

Please send them to cal.admin@sap.com

Could you also check the IP addresses? It could be that it changed after suspend and resume and you have bookmarked the old one.

Best regards,

Stanimir

[DirkS]

Just sent the logfiles to cal.admin, hope this helps.

[stanimir_eisner]

Hello Dirk,

We are already looking into the logs.

Best regards,

Stanimir