Dealing with IP addresses, DNS, Firewalls and Whitelisting Rules
As noted in other migration documents, when you migrate an instance (server) by relaunching it, the new instance will get a new primary (static) IP address and a new MAC address. The change in IP address will have the following consequences:
If people (or other machines) are referring to the instance by its old static IP address, the IP address that they were previously using will stop working. Indeed, at some point in the future, the IP is liable to be reassigned to a different server. (This is one reason why it is inadvisable to publish the IP addresses for instances.)
If people (or other machines) are referring to the instance via a DNS name, then the DNS entry needs to be updated. For this to happen smoothly, you typically need to adjust the DNS entries TTL (time to live) value to a small number of seconds. This will be explained below.
Use of floating IP addresses instead of static IPs does simplify things. A floating IP can be disassociated with one instance and associated with another. Indeed, you can associate a floating IP address that was created in one AZ with an instance in a different AZ.
However, attaching an out-of-zone floating IP address is not an ideal situation:
It can lead to non-optimal routing of your instance’s network traffic. For example, if a QRIScloud floating IP is attached to a TPAC instance, external network packets will be routed to Brisbane and then back to Hobart, resulting in noticeably slower networking.
Some Nectar nodes (or their host Universities) run vulnerability scanners against all IPs in their network ranges, including the floating IP sub-ranges. If a floating IP is attached out-of-zone, the scanners may scan servers in a different zone. This may trigger a (false) security alert.
For these reasons, it is advisable to allocate a new floating IP for your instance after migrating it between AZs. Out of caution, you should request network quota for additional floating IPs so that you don’t have to delete the old ones before creating the new ones.
Another issue may arise if you are using proprietary software with usage restrictions managed by license keys and/or a license manager:
In some cases, the license may give you the right to use the software on specific servers, identified by IP address or by MAC address. If this is the case, you may need to contact the vendor and request a new license key from them. (Check the vendor supplied documentation.)
In other cases, the license may be a site license managed by your home institution, and using the software may depend on it “calling home” to your institution’s license server. If you move your server, it may no longer be able to access the license manager. At any rate, you should discuss this with the relevant people at your home institution. If you don’t know who they are, lodge a Nectar support request explaining your problem and we can attempt to find the appropriate contact for you.
Finally, when the IP address (static or floating), you may need to adjust firewall settings. For example, if you have configured security groups for some server to grant access to the old IP, then you may need to update the groups’ access rules. Another case is if your instance needs to access servers behind an institutional firewall.
For more information on the how to perform some of the above migration-related tasks:
