Minimize downtime when changing IPs of a single or multiple accounts.
It is well known that changing the IP of a site will make it unavailable until the dns cache expires.
This "unavailability" has been successfully avoided manually by creating a manual httpd.conf entry with an duplicate apache virtual host on the old ip as well and then once the cache expired, deleting the old virtual host.
To handled this elegantly a temporary virtual host would need to be set up that gets deleted after a custom time, like 24 hrs usually is enough. This way, changing the ip address of a site would not cause any downtime because the server would respond on both IPs for the same domain.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
What would be your expectation on how to handle the "original" IP address?
I assume that it should be considered "in use" and therefore block any other accounts from being assigned that IP address?
You mention that it should be temporary and potentially automatically revert/destroy the VirtualHost entry/entries for the "original" IP after about 24 hours. Are there concerns with this being a mere assumption and potentially setting up a time delay to break the site if the user hasn't properly set their nameservers or DNS propagation simply hasn't occurred yet? Should this process not be manual to remove the "original" VirtualHost(s)?
This seems like a potentially complex and unwieldy feature that may end up causing more confusion and masking underlying DNS problems that would show themselves once the temporary VirtualHost(s) are removed. I'd like to hear more explanation on desired implementation and further comments from other customers on whether this is something in demand.
What would be your expectation on how to handle the "original" IP address?
I assume that it should be considered "in use" and therefore block any other accounts from being assigned that IP address?
You mention that it should be temporary and potentially automatically revert/destroy the VirtualHost entry/entries for the "original" IP after about 24 hours. Are there concerns with this being a mere assumption and potentially setting up a time delay to break the site if the user hasn't properly set their nameservers or DNS propagation simply hasn't occurred yet? Should this process not be manual to remove the "original" VirtualHost(s)?
This seems like a potentially complex and unwieldy feature that may end up causing more confusion and masking underlying DNS problems that would show themselves once the temporary VirtualHost(s) are removed. I'd like to hear more explanation on desired implementation and further comments from other customers on whether this is something in demand.
What would be your expectation on how to handle the "original" IP address?
I assume that it should be considered "in use" and therefore block any other accounts from being assigned that IP address?
You mention that it should be temporary and potentially automatically revert/destroy the VirtualHost entry/entries for the "original" IP after about 24 hours. Are there concerns with this being a mere assumption and potentially setting up a time delay to break the site if the user hasn't properly set their nameservers or DNS propagation simply hasn't occurred yet? Should this process not be manual to remove the "original" VirtualHost(s)?
This seems like a potentially complex and unwieldy feature that may end up causing more confusion and masking underlying DNS problems that would show themselves once the temporary VirtualHost(s) are removed. I'd like to hear more explanation on desired implementation and further comments from other customers on whether this is something in demand.
What would be your expectation on how to handle the "original" IP address?
I assume that it should be considered "in use" and therefore block any other accounts from being assigned that IP address?
You mention that it should be temporary and potentially automatically revert/destroy the VirtualHost entry/entries for the "original" IP after about 24 hours. Are there concerns with this being a mere assumption and potentially setting up a time delay to break the site if the user hasn't properly set their nameservers or DNS propagation simply hasn't occurred yet? Should this process not be manual to remove the "original" VirtualHost(s)?
This seems like a potentially complex and unwieldy feature that may end up causing more confusion and masking underlying DNS problems that would show themselves once the temporary VirtualHost(s) are removed. I'd like to hear more explanation on desired implementation and further comments from other customers on whether this is something in demand.
The benefits of having 0 downtime on an IP change would outweigh the possible complexity.
I would have the old ip remain in the status it has. example:
site example.com is on ip 155.155.155.155
i move it to IP 155.155.155.156
the new virtual server gets created on 155.155.155.156 and a destruct command gets scheduled for 12/24/48 hrs to delete the original virtual host on 155.155.155.155
the option would appear on the user interface:
[X] leave the old virtual host in place on the old ip address for [ 24 ] hrs.
Warning: make sure your dns expiry time is set for under the selected time period.
if in the weird case a user has a very long dns TTL it is up to him to handle it manually but that is a special case and in MOST cases, TTl is set to 6/12 hrs (6 or 12 or 24 or max 48)
this would effectively create 0 downtime on an in-house IP change, while currently there is a guaranteed 6 hrs downtime on networks that accessed the site recently and have the old IP cached.
as to the OLD ip after the scheduled virtualhost automated self-destruct:
The benefits of having 0 downtime on an IP change would outweigh the possible complexity.
I would have the old ip remain in the status it has. example:
site example.com is on ip 155.155.155.155
i move it to IP 155.155.155.156
the new virtual server gets created on 155.155.155.156 and a destruct command gets scheduled for 12/24/48 hrs to delete the original virtual host on 155.155.155.155
the option would appear on the user interface:
[X] leave the old virtual host in place on the old ip address for [ 24 ] hrs.
Warning: make sure your dns expiry time is set for under the selected time period.
if in the weird case a user has a very long dns TTL it is up to him to handle it manually but that is a special case and in MOST cases, TTl is set to 6/12 hrs (6 or 12 or 24 or max 48)
this would effectively create 0 downtime on an in-house IP change, while currently there is a guaranteed 6 hrs downtime on networks that accessed the site recently and have the old IP cached.
as to the OLD ip after the scheduled virtualhost automated self-destruct:
I agree that zero downtime is a great thing to offer. A complex feature easily converts into higher support costs (due to frequency of incidents), as well as higher maintenance and injecting overall complexity into the entire system which results in fragility. Simpler is better.
Thank you for walking through the various permutations, it helps improve our understanding of your intent.
I agree that zero downtime is a great thing to offer. A complex feature easily converts into higher support costs (due to frequency of incidents), as well as higher maintenance and injecting overall complexity into the entire system which results in fragility. Simpler is better.
Thank you for walking through the various permutations, it helps improve our understanding of your intent.
This is quite important feature, that is missing. When changing IP for account - it should be available on both IPs for either limited time or permamently. Probably this could be achieved by allowing virtual host for account to respond on several IPs. If that is complex - at least something.
This is quite important feature, that is missing. When changing IP for account - it should be available on both IPs for either limited time or permamently. Probably this could be achieved by allowing virtual host for account to respond on several IPs. If that is complex - at least something.
Replies have been locked on this page!