Semi-Dedicated Server problem

[esnail]

new thread.

[martynh99]

Originally Posted by John

Hello,

Flesso is correct. I'm sure many of you have dealt with our UK support staff and obviously know this to be untrue.

The posters intentions are quite clear and he certainly isn't hiding them. It will be dealt with.

Would it be possible to quantify how much of the support is non-uk based.

Everytime I'm on live chat it's India( don't be fooled by the English names), I get it's only when I escalate that I get UK based support usually in the form of NickG.

I have to say I find the livechat very poor, even the simplest questions get mis-interpreted / mis-answered.

I'm not going to go into great detail here as I'm dealing direct with Nick on these issues but if I get windows support and report high Disk Queue Lengths and ask the techie to check the physical node for any high disk activity, I wouldn't expect them to come back after 5 minutes investigation with 'Cpu resources and memory resources are ok'

i'm now 1 hour into a livechat with my webserver on it's back and it seems it's because another customer on the semi-dedicated node running a backup of their container -

[eUKhost.com]

Originally Posted by martynh99

Would it be possible to quantify how much of the support is non-uk based.

Everytime I'm on live chat it's India( don't be fooled by the English names), I get it's only when I escalate that I get UK based support usually in the form of NickG.

I have to say I find the livechat very poor, even the simplest questions get mis-interpreted / mis-answered.

I'm not going to go into great detail here as I'm dealing direct with Nick on these issues but if I get windows support and report high Disk Queue Lengths and ask the techie to check the physical node for any high disk activity, I wouldn't expect them to come back after 5 minutes investigation with 'Cpu resources and memory resources are ok'

i'm now 1 hour into a livechat with my webserver on it's back and it seems it's because another customer on the semi-dedicated node running a backup of their container -

Hi Martyn,

We have high volume of chats and tickets today. Our UK Team is looking after Server side problems only. It should be sorted by our Livechat Support Team if your problem is limited to your vps only.

[martynh99]

Originally Posted by eUKhost.com

Hi Martyn,

We have high volume of chats and tickets today. Our UK Team is looking after Server side problems only. It should be sorted by our Livechat Support Team if your problem is limited to your vps only.

It's been an issue thats ongoing for some weeks, intermittent but sustained high disk queue lengths even when my websites/databases are shutdown - that to me is a server issue as in the physical node is restricting my containers access to resources that it should otherwise have.

[eUKhost.com]

Originally Posted by martynh99

It's been an issue thats ongoing for some weeks, intermittent but sustained high disk queue lengths even when my websites/databases are shutdown - that to me is a server issue as in the physical node is restricting my containers access to resources that it should otherwise have.

Hi Martyn,

There's absolutely no problem on the main node which is hosting your semi-dedicated server. Problem that you see from your end cannot be recreated from our side. Nick has mentioned couple of times and I will repeat same thing, We will need to move your semi-dedicated server on another node as that may solve this unknown problem.

I'm not sure why you don't wish to move your semi-dedicated server on a different node. We have assured you couple of times and we would like to reassure you that there won't be any downtime during migration process.

[martynh99]

Originally Posted by eUKhost.com

Hi Martyn,

There's absolutely no problem on the main node which is hosting your semi-dedicated server. Problem that you see from your end cannot be recreated from our side. Nick has mentioned couple of times and I will repeat same thing, We will need to move your semi-dedicated server on another node as that may solve this unknown problem.

I'm not sure why you don't wish to move your semi-dedicated server on a different node. We have assured you couple of times and we would like to reassure you that there won't be any downtime during migration process.

Your techies speak another version - they have identified it is the virtuozzo backup of another container which they will not / can not kill off and are currently logging a case with SWSoft.

The reason I don't want to move AGAIN is that 3 moves in a year is not ideal, downtime etc you mention that downtime will not occur, how confident are you - surely the container would need stopping and copying to the new node and DNS updates to take place.

Currently my feeling is that if I am to move, it will be to another hosting provider.

Just for info to the members who may think 'already moved a couple of times so maybe it's his sites', the reason for the other moves were

- Original VPS had config issues that could not be resolved easily
- 2nd VPS had intermittent CPU issues that could not be explained - again with all my websites /databases shutdown.


1 other thing I forgot to add, this virtuozzo backup of another client has been running for about 2 hours - 2 hours for max 60gb ???

Just to add the techie is now rebooting the main node, the one that has no problem

Taking this out of the forum now, Mark / Nick you will be getting an email once the server is operational again - my comments from hereon are not for a public forum.

[John]

Hello,

I have spoken to the VPS Team and they have informed me that the Node you are hosted on has already been flagged for a migration. Our technical team has noticed the Node performing slower than it should be, especially during back ups. Although, I would like to add, no other customers on that node have notified us of any problems. The configuration of the new server is the following:

8x Intel ( R) Xeon( R) CPU E5420 @ 2.50GH
12 GB RAM

We are confident the move will solve any performance issues you are experiencing. Yes, unfortunately this will result in an IP change, but this can not be avoided. I have been assured by our tech team that the only downtime would be from any DNS change. Also, the old Semi-Dedicated will remain online until you give permission for it to be shut down. This should mitigate any downtime due to a DNS change, since both servers will be on at the same time. Your sites will still resolve from the old Semi-Dedicated until the new one propagates.

You will receive an e-mail in the next few days with further information. In the meantime, we apologise for any further inconvenience you experience.

[martynh99]

Originally Posted by John

Hello,

I have spoken to the VPS Team and they have informed me that the Node you are hosted on has already been flagged for a migration. Our technical team has noticed the Node performing slower than it should be, especially during back ups. Although, I would like to add, no other customers on that node have notified us of any problems.

Interesting, as in all recent live chats and email communications on this issue, all i've heard from support is
'I have checked the load on main server. Cpu resources and memory resources are pretty normal'

I have checked and the node on which your VPS created is absolutely working fine

Originally Posted by John

The configuration of the new server is the following:

8x Intel ( R) Xeon( R) CPU E5420 @ 2.50GH
12 GB RAM

We are confident the move will solve any performance issues you are experiencing. Yes, unfortunately this will result in an IP change, but this can not be avoided. I have been assured by our tech team that the only downtime would be from any DNS change. Also, the old Semi-Dedicated will remain online until you give permission for it to be shut down. This should mitigate any downtime due to a DNS change, since both servers will be on at the same time. Your sites will still resolve from the old Semi-Dedicated until the new one propagates.

So if a DNS change is required, there will be downtime - whilst minimal this is downtime and not as mentioned earlier in this thread by Mark ' We have assured you couple of times and we would like to reassure you that there won't be any downtime during migration process.'
Also if you can't identify what the problem is on the current node, how can you be confident that this move will resolve it ?

Originally Posted by John

You will receive an e-mail in the next few days with further information. In the meantime, we apologise for any further inconvenience you experience.

I'm considering my options now. I have as previously mentioned migrated twice in 9 months due to server config / performance issues not related to my websites - to do this a 3rd time because you can't find the issue concerns me somewhat. Add to this the number of outages I have encountered either due to misconfiguration of my container(wasn't set to auto-start when physical node was booted, don't know how many times this caused an outage before Nick found the issue) or where a disk rebuild has resulted in the Physical node having to be taken offline(raid is supposed to be resilient) to enable the rebuild to complete and it's not been a smooth ride at all.

You may want to speak to Mark / Nick whom I have emailed some concerns from today.

[John]

Hello,

Perhaps I wasn't clear in my last reply, allow me to try again. No other users have complained about any issues on the hardware node, apart from you. Whilst I'm not dismissing your issue, I would hope that you can see this hardly screams of a server about to fall over and die. Normal when they checked, perhaps, but it has been flagged for an upgrade for awhile now, along with every other Q6600 Server, I might add. The performance of that particular server isn't as high as we expect from a Node.

You know as well as I do that a DNS change can cause some downtime. However, if the old server is online, your customers will be reaching the old server until the new server starts propagating.

Assuming this is a resource issue, the problem will be solved on the new node. Especially since no new accounts will be created on this server, as it's just an upgrade for existing clients. If there is something wrong inside your virtual environment, I can't promise this will fix it. However, if there is something wrong, I can be confident that it has nothing to do with our configuration.

[martynh99]

Originally Posted by John

Hello,

Perhaps I wasn't clear in my last reply, allow me to try again.

Your last reply was clear, I was merely pointing out inconsistencies with earlier comments and your livechat ops.

Originally Posted by John

No other users have complained about any issues on the hardware node, apart from you.

Maybe they haven't noticed, maybe they run plain html or very simple sites that can handle high disk queue lengths - the majority of my sites rely on databases (mysql & MSSQL) - excessive, sustained high disk queue lengths are not good in these types of scenarios as i'm sure you know.

Originally Posted by John

Normal when they checked, perhaps,

Normal every single time I have a livechat session, even when the problem persists as was the case today, livechat said no issues on the node , apart from of course the backup process that had been running for a couple of hours that wouldnt die and resulted in a hard reboot of a server. Very normal

Another fine instance from only last week, the server was dead in the water - not responding to pings or anything - livechat ops first response was, have you made changes to the firewall ? Surely the first check you make when a customer says their server is not responding to ping is to check it's online. Turns out you did some manual reboots of the containers at around 9am in the morning, shame you didn't check they came back up after - 7 hours it was down for.

Originally Posted by John

but it has been flagged for an upgrade for a while now, along with every other Q6600 Server, I might add. The performance of that particular server isn't as high as we expect from a Node.

Communication - i've raised this issue loads of times over the past few weeks and Nick has been heavily involved, not once has the flagging of this server been mentioned - Just that the server is running normal

Originally Posted by John

You know as well as I do that a DNS change can cause some downtime. However, if the old server is online, your customers will be reaching the old server until the new server starts propagating.

Absolutely, hence my stressing the point that there will be downtime but Mark had stated previously there wouldn't be - consistency of communication. I am very techical, some customers who have hosting with you won't be and would have believed Marks statement. In my case there are a number of databases involved so some users hitting one server and others hitting the other is not a viable option. Again I know the technicalities but some customers wouldn't.

Originally Posted by John

Assuming this is a resource issue, the problem will be solved on the new node. Especially since no new accounts will be created on this server, as it's just an upgrade for existing clients. If there is something wrong inside your virtual environment, I can't promise this will fix it. However, if there is something wrong, I can be confident that it has nothing to do with our configuration.

I've come to a decision - I will have one last chance at keeping my hosting with Eukhost and migrate to the new server. However, I would like to handle the migration myself, that way I am in control of the sites and databases, i.e. I can code the sites so that both instances old & new hit the database on the server. (this is how we did it last time we had to migrate). I will phase the migration over the next 2 days if thats ok with yourselves.

[John]

Hello,

You may discuss the time frame with our VPS department, I don't see a problem with it. The migration of it yourself is also fine by us, since you are in control of your own destiny then, so to speak.

[Daniel]

Originally Posted by martynh99

Absolutely, hence my stressing the point that there will be downtime but Mark had stated previously there wouldn't be - consistency of communication. I am very techical, some customers who have hosting with you won't be and would have believed Marks statement. In my case there are a number of databases involved so some users hitting one server and others hitting the other is not a viable option. Again I know the technicalities but some customers wouldn't.

I wish to know why there would be downtime? Usually you will have the other websites mirrored on the other semi-dedicated server, backup and restore onto your new one and change the DNS. Usually when the DNS has propagated and everything is working correctly then your old semi-dedicated server is suspended / terminated

[martynh99]

Originally Posted by martynh99 Absolutely, hence my stressing the point that there will be downtime but Mark had stated previously there wouldn't be - consistency of communication. I am very techical, some customers who have hosting with you won't be and would have believed Marks statement. In my case there are a number of databases involved so some users hitting one server and others hitting the other is not a viable option. Again I know the technicalities but some customers wouldn't.

Originally Posted by Daniel

I wish to know why there would be downtime? Usually you will have the other websites mirrored on the other semi-dedicated server, backup and restore onto your new one and change the DNS. Usually when the DNS has propagated and everything is working correctly then your old semi-dedicated server is suspended / terminated

Answer highlighted in bold from my original post says it all - if there is a database that gets updated then there has to be a period of downtime while that database is backed up & restored to the new server.
As there is a period of time for the DNS to propogate, some customers could be hitting the old server and some hitting the new server.
Yes there are ways round that but not all people have the technical know how on how to get around this which was my point.

[eUKhost.com]

Originally Posted by martynh99

Answer highlighted in bold from my original post says it all - if there is a database that gets updated then there has to be a period of downtime while that database is backed up & restored to the new server.
As there is a period of time for the DNS to propogate, some customers could be hitting the old server and some hitting the new server.
Yes there are ways round that but not all people have the technical know how on how to get around this which was my point.

What if we route traffic of port 3306, 80 and 25 from old semi-dedicated server to your new semi-dedicated server ?

Will you face downtime ?

[martynh99]

Originally Posted by eUKhost.com

What if we route traffic of port 3306, 80 and 25 from old semi-dedicated server to your new semi-dedicated server ?

Will you face downtime ?

Generally that would work with minimal downtime yes, there would still be a small amount of downtime to get the databases across from old node to new node.

I'm already on with the migrations to the new server that's been provisioned up for me thanks,