Afrihost Cloud Servers Down Again?

Thor187 said:
Still have a effy setup VM with them cannot wait to move it across to domains but currently their is a possibility of downtime should we move potentially breaking some sites, so cannot risk it at the moment.
Click to expand...

Eish, that is not a nice thing to have... all of the best!
 
Thor187 said:
Still have a effy setup VM with them cannot wait to move it across to domains but currently their is a possibility of downtime should we move potentially breaking some sites, so cannot risk it at the moment.
Click to expand...

I'd recommend prepping the DNS first. So change all of the affected sites on that server to new DNS hosting (wherever that may be, probably at the new host). So your new host DNS entries points back to Afrihost currently, breaking nothing. It should be a seamless switchover as both DNS servers (at Afrihost, and at new host) will have same settings.

I usually set the TTL of the records on the new host to 1 minute so that any requests will have to refresh after 1 minute (you will see later why)

Wait for it to propagate, I usually do it a week in advance of everything.

Once you're in control of the DNS of the sites at the new host, backup and restore the sites on the new host. Depending on the number of sites, it usually takes me less than an hour to do.

I then use the hosts file on Windows to override the DNS to point to the new host, so when I open my browser and type in the domain, I hit the new servers, not the ones at Afrihost. After I've tested everything works fine, I change the DNS entries for the web hosting to point to the new server.

Since your DNS servers are already with the new host with a TTL of 1 minute, the DNS should change quite quickly and sending traffic to the new host. Change the TTL back to the default for those entries.

You will notice I said specifically the web hosting.

If you have email on Afrihost as well, what I do is basically the same as outlined above, but I'd create a subdomain entry on the new DNS to point to the IP address of the "old" mail server. I recreate all the POP accounts on the new host for all the domains and then login via webmail to POP the old mail server with any mail (if the client doesn't download all their mail immediately)

I do the same with the MX records when all that is prepped, then I just setup the webmail to POP the old mail server every 5 minutes for any messages that might have been delivered there during switchover. Since the TTL is 1 minute, it's rare that it does, depends on the volume of mail your clients get. Set the TTL to the default once the MX records are also switched over and tested and keep checking for old mail for another week or so after.

You should be up and running with 0 downtime like this and you will have the ability to just point the DNS back to the old servers in case there is an issue.

I've moved more than 100 sites like this hosted on a dedicated server before.
 
envo said:
I'd recommend prepping the DNS first. So change all of the affected sites on that server to new DNS hosting (wherever that may be, probably at the new host). So your new host DNS entries points back to Afrihost currently, breaking nothing. It should be a seamless switchover as both DNS servers (at Afrihost, and at new host) will have same settings.

I usually set the TTL of the records on the new host to 1 minute so that any requests will have to refresh after 1 minute (you will see later why)

Wait for it to propagate, I usually do it a week in advance of everything.

Once you're in control of the DNS of the sites at the new host, backup and restore the sites on the new host. Depending on the number of sites, it usually takes me less than an hour to do.

I then use the hosts file on Windows to override the DNS to point to the new host, so when I open my browser and type in the domain, I hit the new servers, not the ones at Afrihost. After I've tested everything works fine, I change the DNS entries for the web hosting to point to the new server.

Since your DNS servers are already with the new host with a TTL of 1 minute, the DNS should change quite quickly and sending traffic to the new host. Change the TTL back to the default for those entries.

You will notice I said specifically the web hosting.

If you have email on Afrihost as well, what I do is basically the same as outlined above, but I'd create a subdomain entry on the new DNS to point to the IP address of the "old" mail server. I recreate all the POP accounts on the new host for all the domains and then login via webmail to POP the old mail server with any mail (if the client doesn't download all their mail immediately)

I do the same with the MX records when all that is prepped, then I just setup the webmail to POP the old mail server every 5 minutes for any messages that might have been delivered there during switchover. Since the TTL is 1 minute, it's rare that it does, depends on the volume of mail your clients get. Set the TTL to the default once the MX records are also switched over and tested and keep checking for old mail for another week or so after.

You should be up and running with 0 downtime like this and you will have the ability to just point the DNS back to the old servers in case there is an issue.

I've moved more than 100 sites like this hosted on a dedicated server before.
Click to expand...

Issue is with ERP systems and Soap Calls being made the world full which restricts IP's and its different providers more than 600 sites ranging from legacy php4ish etc lots of symlink race exploits

So I am planning to rebuild the entire setup well not I alone, I will ask the expert guidance of Domains to assist when we move over.
 
Which ERP Systems/SOAP Calls are you talking about? (out of interest sake), as I had a few as well which I was able to set-up to resolve to a CNAME on my domain (which was possible with all of them) which meant I could change my IP 20 times without worrying about any restrictions. The SSL Certs were a bit of a pain because you need to reissue them, but it was pretty straight forward.

Eish @ PHP4 legacy apps... that's like still having stuff run in VB6 :D
 
envo said:
Which ERP Systems/SOAP Calls are you talking about? (out of interest sake), as I had a few as well which I was able to set-up to resolve to a CNAME on my domain (which was possible with all of them) which meant I could change my IP 20 times without worrying about any restrictions. The SSL Certs were a bit of a pain because you need to reissue them, but it was pretty straight forward.

Eish @ PHP4 legacy apps... that's like still having stuff run in VB6 :D
Click to expand...

I'll rather PM you (:

Can't disclose such info in the wide and open hehe
 
envo said:
snip.
Click to expand...


good share, this is how we are doing it: Currently moving a few hundred domains which were on dedicated servers (having root access makes the below a breeze) with Afrihost to our own virtualized infrastructure. We were previously making use of AH's DNS cluster which is is rubbish, as a result we built a new cluster and connected all servers to it.

1) Move all domains to EPP if they aren't there yet, keep the DNS servers in place as they are.

2) Purge the default mailboxes on all domains. (we have far too many client's who don't use this yet whoever setup these servers made a royal mess of this and accounts are bloated to 50GB+ with SPAM).

3) mass update all TLLs for everything to 600

4) The transfer: we have scripted this but what essentially happens is: new server sends a transfer request to the old server, starts transferring the data similar to how CPanel transfer tool works, once transfer is complete new server updates the DNS on the old server changing the MX and the account to backup email exchanger. This means all mail which is delivered to the old server as of now (with DNS still pointing there) will be routed to the new mail server when received as it checks its DNS and see what the new MX is.

On the new server the MX records are checked (we have a few clients with stuff like hosted Exchange or google apps) and if it needs to deliver locally it adds a secondary MX and configures that server to accept mail for the specified domain(check out secondaryMX, awesome plugin).

5) Finally a mail comes through and we change the NS records on the registrar side (I would have loved to have direct access to ZACR to di this myself but sadly we are a reseller) which is done manually.

6) Once NS is updated we suspend the account on the old server.

During this process we did 80-100 domains per day without anyone* noticing.

*except those pesky printer technicians who choose to use an IP rather then a host name for scan to mail. We picked up 90% of these guys by searching through the delivery reports but there are a few that we missed.
 
Ipwn 4 said:
good share, this is how we are doing it: Currently moving a few hundred domains which were on dedicated servers (having root access makes the below a breeze) with Afrihost to our own virtualized infrastructure. We were previously making use of AH's DNS cluster which is is rubbish, as a result we built a new cluster and connected all servers to it.

1) Move all domains to EPP if they aren't there yet, keep the DNS servers in place as they are.

2) Purge the default mailboxes on all domains. (we have far too many client's who don't use this yet whoever setup these servers made a royal mess of this and accounts are bloated to 50GB+ with SPAM).

3) mass update all TLLs for everything to 600

4) The transfer: we have scripted this but what essentially happens is: new server sends a transfer request to the old server, starts transferring the data similar to how CPanel transfer tool works, once transfer is complete new server updates the DNS on the old server changing the MX and the account to backup email exchanger. This means all mail which is delivered to the old server as of now (with DNS still pointing there) will be routed to the new mail server when received as it checks its DNS and see what the new MX is.

On the new server the MX records are checked (we have a few clients with stuff like hosted Exchange or google apps) and if it needs to deliver locally it adds a secondary MX and configures that server to accept mail for the specified domain(check out secondaryMX, awesome plugin).

5) Finally a mail comes through and we change the NS records on the registrar side (I would have loved to have direct access to ZACR to di this myself but sadly we are a reseller) which is done manually.

6) Once NS is updated we suspend the account on the old server.

During this process we did 80-100 domains per day without anyone* noticing.

*except those pesky printer technicians who choose to use an IP rather then a host name for scan to mail. We picked up 90% of these guys by searching through the delivery reports but there are a few that we missed.
Click to expand...

/Makes copious notes
 
Thor187 said:
/Makes copious notes
Click to expand...

My pleasure, if you time step 4 perfectly (even if it is done manually) you can run migrations in business hours and all your client see is a slight mail delay while their mail.domain.tld record expires locally.
 
Ipwn 4 said:
My pleasure, if you time step 4 perfectly (even if it is done manually) you can run migrations in business hours and all your client see is a slight mail delay while their mail.domain.tld record expires locally.
Click to expand...


I thought that hehehehe

Hence why I imidiatly Googled that whole procedure to the tea.

(:
 
This is about the third Sunday that it's been a problem...

The issue with FTP was (allegedly) because I'd used brute force HTTP access... Might this be because their servers are as soft as ****? May be I'd dared to use the refresh button more than twice!

A change of host looks most likely...
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X