How to keep IP address and hostname/FQDN during server migration.

Hello, I would like to know your opinion. We are migrating a single Informix server (no HA, just one server instance with 2 databases on one operating system/server). The customer asked us to keep the server's IP address and hostname (FQDN) because they are not sure who (users or other services) is using IP and who uses hostname/FQDN to access the database. They want to keep the IP address of the database server "same forever". This brings me an idea to separate the IP address from the server machine, but because the migration is done once in a blue moon (this one is done after 14 years) it also means, that the change of IP address of the server after data has been moved is not bad idea. I see here 3 options: Migrate data and change the IP address and hostname of the server (should need just update the OS hostname, OS IP and Informix sqlhosts file). Deploy proxy between clients and server with static IP (e.g. HA Proxy). Use Connection Manager as a proxy on a separate server (is this use case for CM, can CM be installed separately?) What are your experiences with this kind of migration/architectural change? Thank you for your opinions and ideas. ------------------------------ Ondrej ------------------------------

Hi, we have done both solutions. Deploy haproxy in tcp mode (high timeouts) alternative (easier) rinetd to redirect Use Connection Manager in passthrough mode (yes, can be installed separately) Connection manager in redirect mode should work as well, but will need direct connectivity from all clients to server (not sure if this a good idea for your environment, you would need to change the INFORMIXSERVER and make it available for all clients) Best,

Hi Ondrej, I'm not sure I'm fully getting your problem. You're planning to move this db server to a new host, and that new db server then should be reachable under same IP/FQDN? This, I'd say, would pose a problem only if and as long as the old host continues to operate under this IP/FQDN - if not, the new host could simply be configured to use those from now on. If both hosts are meant to continue, then neither of them could use these IP/FQDN and some sort of front end interface had to adopt them, relaying the traffic to the new host. CM could certainly be such front end, running on a third host (or on the old one should that have to keep its IP/FQDN). In 'Proxy' mode clients would run all their traffic through CM and only connect to this. In 'Redirect' mode clients would do initial connect to CM, then re-connect to the actual db server learned from CM. For this clients had to be sufficiently recent, to be able to understand the redirect protocol, and they'd have to have direct connectivity to the new host. HTH, Andreas ------------------------------ Andreas Legner ------------------------------

Hello Marcus. Thank you for the answer. Would you please describe what is your experience with each of the solutions? Is there any you would not recommend? ------------------------------ Ondřej ------------------------------

Hello Andreas, Thank you for your answer. You're planning to move this db server to a new host, and that new db server then should be reachable under same IP/FQDN? The goal is: Install a new server. Migrate databases from the old server and stop the old server. Start a new server with migrated databases The old server will be discontinued and the customer wants to keep access to the database on the new server with the same IP address and FQDN as the old server had. The application uses SDK 3.50 as far as I know (not possible to update because of some dependencies in the application - it is quite old). So only proxy mode is possible (not redirect). I Connection Manager anyhow licensed? Do I need any additional license to be able to install it separately from the database server? Thank you ------------------------------ Ondřej ------------------------------

CM is part of (newer) CSDK which is free of charge (only support would require separate license). On the other hand, I'm still not seeing why they don't simply run the new host with old host's IP + FQDN - probably there's a reason, though. ------------------------------ Andreas Legner ------------------------------

Hi, haproxy and rinetd simply redirect the TCP traffic. Both are doing a good job, but haproxy has the ability to forward the original IP (at least in our FreeBSD setup). Just use TCP mode with very long connection timeouts. rinetd has no concept of timeouts. It just accepts incoming connections on a specific IP/Port and connects to a different IP/Port, forwarding all the data in/out. The original IP Adress is then hidden from the IDS instance. Both are very stable and haproxy has a nice HTML management interface which lets you monitor the connection states. The easiest setup is rinetd, but does not offer a real ability to monitor the connections other then netstat commands. Informix CM in passthrough mode is more complex to configure and can be set up either in passthrough mode oder in redirect mode. Passthrough mode is more or less simulating the Informix connector (needs to have the INFORMIXSERVER value and the actual value of the instance behind CM must be different.). It can be used for HDR as well, in order to hide the active instance from the clients (and perform the switchover in case of a failed primary). This setup works with very old clients, which might be not aware of redirecting responses. In redirect mode, the CM will receive the initial connection and then redirect the client to the active server (mostly used when a HDR pair is in place, where the roles are switched from time to time or CM has the role to actively switch a secondary to primary if connection to the primary instance is lost for whatever reason). It can also work with aliases (one alias points to the primary instance always, another alias points to the secondary for read-only access, with a fallback to primary). In order to do this, the clients need to be aware of both instances and the CM. CM is also very stable and as already said, can (should) be set up on a different machine. We have used the rinetd and haproxy approach temporary in the past for the purpose to move the IDS instance to a separate network segment, which is not directly accessible for some clients. (like a DMZ). With CM, it is a little tricky to "just reboot the primary for a moment" for whatever reason, without initiating a failover to secondary. If your instance is standalone, and you just want to prevent changing all the clients setups, I would probably go with haproxy.

Mainly I agree with Marcus Haarmann. Any of your three options will work just fine. If you have older apps using CSDK/iConnect versions from before Connection Manager was an option, then using CM will require using passthrough/proxy mode. All newer CSDK clients can use the default redirect mode which is more efficient. There is not problem installing CM on a separate server from the engine. That matches Best Practice which includes running at least two CM instances and having the clients connect to a "group" that includes both CMs so that there is not single point of failure (except of course the single Informix server instance). ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Thank you Marcus. ------------------------------ Ondřej ------------------------------

Thank you Andreas I'm still not seeing why they don't simply run the new host with old host's IP + FQDN This was one of the options I mentioned. The reason (how it was explained to me) for keeping the IP and hostname is "Informix server had always this hostname and this IP". And they don't know if all clients use the FQDN and not the IP (and don't want to investigate it:-/). They want it, they pay it. :-| Because of that, I was thinking about separating the IP address from the server with the database and moving it to some other component in the network to give me some freedom in what's going on "behind this point". ------------------------------ Ondřej ------------------------------

Thank you Art for your answer. ------------------------------ Ondřej ------------------------------

Ondřey, Any solution that involves a proxy like HAProxy or CM with passthrough will increase latency. Some apps are quite sensitive to this. Given the IP address constraint which presumably also means you can't change sqlhosts on the clients or JDBC connection strings, swapping the IP addresses so the server appears to be the same as the old one is probably the solution I'd go with. Ben. ------------------------------ Benjamin Thompson ------------------------------

Thank you for your update, Benjamin. ------------------------------ Ondřej ------------------------------