Hi!
I'm in a situation where our company has a CentOS 5 32 bit system with cPanel, on a co-located HP server of our own, and due to missing SNI, plus the EOL of CentOS 5 support, we are forced to somehow migrate this system to CentOS 7 64 bit.
I know that an in-place upgrade is impossible, but the new system needs to end up on the same physical hardware (it's not that old, in fact the CentOS 5 system runs with a custom kernel because it was too new for it to even see the hard drives and sensors).
What we have right now:
- a public IP of say 123.456.789.50 (this IP is obviously not valid, just an example) with quite a few domains and websites on it; some of our own, some belonging to customers
- a physical machine on the above IP
What we can use:
- a new server that will run "other" (non-cPanel and non-web-hosting) things, but I can use it in the coming month before it enters heavy production use, and it is capable of running quite a few KVM guests if needed
- a public IP for this new server, say 400.500.600.12 , and a few extra NICs that could potentially get connected at the data center where we host our infrastructure
- a nice office where I can work on hardware, install a new OS, test things
My plan is - and this is where I need your input on this topic, if you see any problems with it or have better ideas:
1.) I can schedule two 4-6 hour maintenances this year without too much customer complaints.
2.) I would use the first maintenance window to create a VM on the new machine, shut down the old one, and copy the CentOS 5 system into it using rsync from a live CD. Some manual fixups on the copy, and it can boot in a VM.
After this, I would ask the data center operators to disconnect the old server's ethernet cable, and set the switches and wire a spare NIC up on this new machine so it could use the old server's IP. When the VM boots up it has access to this NIC, has the old IP, and can continue serving websites and process e-mails. At this point I can remove the old server from the data center, to do whatever I wish with it.
Up to this point this was fairly trivial, the customers won't really see the difference, and costs us only a few hours of downtime.
3.) At the office, I can load CentOS 7 (using the minimal install) onto the HP server, then install cPanel on it. We have to test some sites, how they behave on newer PHP versions, so this means some play is necessary with EasyApache4 and MultiPHP support, probably over a week or two.
I'll probably need a trial license from NDCHost (where we got our production server's cPanel license from), as I'm pretty sure we can't just request one from cpanel.com/trial (we did some cPanel PHP migration tests in the past, thus we probably already used that up for the office's external IP).
For a few select sites, I have to provide PHP 5.2, which was EOL on CentOS 5 ages ago, and was a real problem even then due to libpcre version requirements (we had to use 8.20 with it, while the system has PCRE 8.36 right now, but that's another story). It actually worked quite nicely with suPHP and .htaccess tricks, but the system had EasyApache3. I have no idea how difficult it will be with EA4 and CentOS 7...
4.) After the tests, time will come to somehow move the CentOS 5 VM's data into the new CentOS 7 system; this is the second scheduled downtime's window.
So the old hardware with CentOS 7 will make a trip into the data center. I see 2 possible solutions:
a) Do full account backups on the CentOS 5 system, shut it down, spin up the CentOS 7 machine and set it's IP to 123.456.789.50. Then I can mount the VM's file systems over the network, and restore the backups from there like they are local backups; probably using /scripts/restorepkg and a custom script around it, making sure the reseller accounts get restored first.
My problem with this approach is that the CentOS 5 and 7 systems will have different cPanel versions (the old one is stuck on 11.56 by now), different archs (i686 vs. amd64), and this might introduce errors during restore; only the cPanel developers could tell for sure.
b) Use the Transfer Tool ( Transfers - Documentation - cPanel Documentation ) while both servers are up. I need to have the CentOS 7 system to use the original IP in the end, 123.456.789.50 , and I think it's better to do it sooner than later. I can change the CentOS 5 VM's IP to be something like 10.1.2.123, and set the Host's firewall to forward almost all ports 1:1 to it from its external 400.500.600.12 IP, then set the CentOS 7 system to use 123.456.789.50. At this point the CentOS 7 system will be able to access the old CentOS 5 via SSH (or whatever it needs to do the transfer), and has the desired external IP.
However, the CentOS 5 system is behind NAT now, and on a totally new external IP license-wise, so another trip in advance to NDCHost, for another trial license?
Would I need to change the DNS zones for every account to have the 400.500.600.12 IP before the transfer on the CentOS 5 system? Some zone files have custom additions too, like manually added CNAME, A, TXT records and a few subdomains delegated to other DNS servers, so I would feel better to leave them alone and just get them copied to the CentOS 7 system as-is. What are the expectations of the Transfer Tool? Would it get surprised if it sees its own "shared IP" in there, expecting it to have the remote server's main IP?
Obviously, both systems need to be firewalled during transfers so domains that come up on them won't be accessible by customers during transfers, especially not e-mails (which can sit on their originating SMTPs and arrive a few hours late, no problem there; but having some show up on the old CentOS 5 due to some DNS differences and the customer using the new CentOS 7 system would be catastrophic, especially when the CentOS 5 system is already gone).
So, that's the plan, and I have to decide to do 4/a or 4/b. Maybe a 4/c solution? It would be nice to minimize downtime, and I have a feeling that a backup-network mount-restore sequence probably takes longer than the Transfer Tool between two running systems, but the IP/DNS changes might confuse it.
Any ideas? Thanks in advance for any input!
I'm in a situation where our company has a CentOS 5 32 bit system with cPanel, on a co-located HP server of our own, and due to missing SNI, plus the EOL of CentOS 5 support, we are forced to somehow migrate this system to CentOS 7 64 bit.
I know that an in-place upgrade is impossible, but the new system needs to end up on the same physical hardware (it's not that old, in fact the CentOS 5 system runs with a custom kernel because it was too new for it to even see the hard drives and sensors).
What we have right now:
- a public IP of say 123.456.789.50 (this IP is obviously not valid, just an example) with quite a few domains and websites on it; some of our own, some belonging to customers
- a physical machine on the above IP
What we can use:
- a new server that will run "other" (non-cPanel and non-web-hosting) things, but I can use it in the coming month before it enters heavy production use, and it is capable of running quite a few KVM guests if needed
- a public IP for this new server, say 400.500.600.12 , and a few extra NICs that could potentially get connected at the data center where we host our infrastructure
- a nice office where I can work on hardware, install a new OS, test things
My plan is - and this is where I need your input on this topic, if you see any problems with it or have better ideas:
1.) I can schedule two 4-6 hour maintenances this year without too much customer complaints.
2.) I would use the first maintenance window to create a VM on the new machine, shut down the old one, and copy the CentOS 5 system into it using rsync from a live CD. Some manual fixups on the copy, and it can boot in a VM.
After this, I would ask the data center operators to disconnect the old server's ethernet cable, and set the switches and wire a spare NIC up on this new machine so it could use the old server's IP. When the VM boots up it has access to this NIC, has the old IP, and can continue serving websites and process e-mails. At this point I can remove the old server from the data center, to do whatever I wish with it.
Up to this point this was fairly trivial, the customers won't really see the difference, and costs us only a few hours of downtime.
3.) At the office, I can load CentOS 7 (using the minimal install) onto the HP server, then install cPanel on it. We have to test some sites, how they behave on newer PHP versions, so this means some play is necessary with EasyApache4 and MultiPHP support, probably over a week or two.
I'll probably need a trial license from NDCHost (where we got our production server's cPanel license from), as I'm pretty sure we can't just request one from cpanel.com/trial (we did some cPanel PHP migration tests in the past, thus we probably already used that up for the office's external IP).
For a few select sites, I have to provide PHP 5.2, which was EOL on CentOS 5 ages ago, and was a real problem even then due to libpcre version requirements (we had to use 8.20 with it, while the system has PCRE 8.36 right now, but that's another story). It actually worked quite nicely with suPHP and .htaccess tricks, but the system had EasyApache3. I have no idea how difficult it will be with EA4 and CentOS 7...
4.) After the tests, time will come to somehow move the CentOS 5 VM's data into the new CentOS 7 system; this is the second scheduled downtime's window.
So the old hardware with CentOS 7 will make a trip into the data center. I see 2 possible solutions:
a) Do full account backups on the CentOS 5 system, shut it down, spin up the CentOS 7 machine and set it's IP to 123.456.789.50. Then I can mount the VM's file systems over the network, and restore the backups from there like they are local backups; probably using /scripts/restorepkg and a custom script around it, making sure the reseller accounts get restored first.
My problem with this approach is that the CentOS 5 and 7 systems will have different cPanel versions (the old one is stuck on 11.56 by now), different archs (i686 vs. amd64), and this might introduce errors during restore; only the cPanel developers could tell for sure.
b) Use the Transfer Tool ( Transfers - Documentation - cPanel Documentation ) while both servers are up. I need to have the CentOS 7 system to use the original IP in the end, 123.456.789.50 , and I think it's better to do it sooner than later. I can change the CentOS 5 VM's IP to be something like 10.1.2.123, and set the Host's firewall to forward almost all ports 1:1 to it from its external 400.500.600.12 IP, then set the CentOS 7 system to use 123.456.789.50. At this point the CentOS 7 system will be able to access the old CentOS 5 via SSH (or whatever it needs to do the transfer), and has the desired external IP.
However, the CentOS 5 system is behind NAT now, and on a totally new external IP license-wise, so another trip in advance to NDCHost, for another trial license?
Would I need to change the DNS zones for every account to have the 400.500.600.12 IP before the transfer on the CentOS 5 system? Some zone files have custom additions too, like manually added CNAME, A, TXT records and a few subdomains delegated to other DNS servers, so I would feel better to leave them alone and just get them copied to the CentOS 7 system as-is. What are the expectations of the Transfer Tool? Would it get surprised if it sees its own "shared IP" in there, expecting it to have the remote server's main IP?
Obviously, both systems need to be firewalled during transfers so domains that come up on them won't be accessible by customers during transfers, especially not e-mails (which can sit on their originating SMTPs and arrive a few hours late, no problem there; but having some show up on the old CentOS 5 due to some DNS differences and the customer using the new CentOS 7 system would be catastrophic, especially when the CentOS 5 system is already gone).
So, that's the plan, and I have to decide to do 4/a or 4/b. Maybe a 4/c solution? It would be nice to minimize downtime, and I have a feeling that a backup-network mount-restore sequence probably takes longer than the Transfer Tool between two running systems, but the IP/DNS changes might confuse it.
Any ideas? Thanks in advance for any input!
