IP number change

[henk_stobbe]

What happens if a node changes IP number? He has to be installed again>

[Radoslaw_Szulgo]

Unfortunately, we do not support that currently. In case that happens, you need to reinstall a node so the new network configuration is applied across all cluster nodes.

[kia_forooghi · Accepted solution]

Here are the instructions to 'fix' a node that lives on a box with a change in IP:

1. Change directory to the directory containing the Dynatrace Managed install (i.e., /opt/dynatrace-managed)
   cd /opt/dynatrace-managed/
2. Run this command to find all files with the 'old' IP address (replace <OLD_IP_ADDRESS> with the old IP address, like 192.168.137.150)
   find . -type f -exec grep -H <OLD_IP_ADDRESS> {} \;
3. You should see an output.
4. Run this command to replace the old IP with the new (make sure this time it's STATIC) IP address:
   find ./ -type f -exec sed -i 's/<OLD_IP_ADDRESS>/<NEW_IP_ADDRESS>/' {} \;
5. For example, if the intentions is to change the node's IP from 192.168.137.150 to 192.168.1.127, the command would look like this:
   find ./ -type f -exec sed -i s/192.168.137.150/192.168.1.127/' {} \;
6. Once the command is done executing, verify it was successful by using the original search command with the new IP:
   find . -type f -exec -H <NEW_IP_ADDRESS> {} \;
7. Again, replacing <NEW_IP_ADDRESS> with your new IP, e.g., 192.168.1.127
8. Start the node using the /opt/dynatrace-managed/launcher/dynatrace.sh script

[Lauri-J]

Hey,

I will share my experiences with following these steps in case there is somebody out there about to do these changes.

While Dynatrace server was functional with the new IP address, I encountered issues with update and installer packages. It seems like the old IP address might be hard coded into the packages, which caused issues with Dynatrace updates.

I got the following error after automatic Managed update attempts:
Cannot check Elasticsearch indices on Dynatrace cluster nodes. Error: Failed to send GET request to http://<Old IP address>:9200/_all/_settings/index.version.created

I then decided to install another cluster node in the new network alongside the old one as an intended workaround to get the updates working. When running the Managed installer on the new node, I got another timeout caused by a request to the old IP address that was no longer in use, failing the installation.

I did not want to go through checking and/or modifying the installer packages in case the IP was hard coded in them. I ended up running the script above again with IP addresses in reverse and moving the original node back to the old network, then opening the required ports between the two nodes that were now in different networks. This restored the functionality of Managed updates and installations.

While Managed server itself was functional after the commands, I would still highly recommend doing the network switch the supported way.

Br,
Lauri

[Radoslaw_Szulgo]

Have you verified it works? There might be also some database changes required.

[ernesto_rueda]

Hello @Radoslaw S. and @Kia F.

I've just did this, and it worked.

Do you think there could be any repercussion?

Best regards.

[amr_fahmy]

It is worked with me as well.

[Lauri-J]

Hey,

I will share my experiences with following these steps in case there is somebody out there about to do these changes.

While Dynatrace server was functional with the new IP address, I encountered issues with update and installer packages. It seems like the old IP address might be hard coded into the packages, which caused issues with Dynatrace updates.

I got the following error after automatic Managed update attempts:
Cannot check Elasticsearch indices on Dynatrace cluster nodes. Error: Failed to send GET request to http://<Old IP address>:9200/_all/_settings/index.version.created

I then decided to install another cluster node in the new network alongside the old one as an intended workaround to get the updates working. When running the Managed installer on the new node, I got another timeout caused by a request to the old IP address that was no longer in use, failing the installation.

I did not want to go through checking and/or modifying the installer packages in case the IP was hard coded in them. I ended up running the script above again with IP addresses in reverse and moving the original node back to the old network, then opening the required ports between the two nodes that were now in different networks. This restored the functionality of Managed updates and installations.

While Managed server was functional after running the commands above, I would still highly recommend doing the network switch the supported way to get the latest updates and being able to install more cluster nodes.

Br,
Lauri