Cloud Hosting

[RJM62]

I'm outgrowing my present hosting plan, and I decided today to try something new: A VPS on a cloud.

I presently have a mirrored VPS that has been pretty reliable, for the most part. The mirroring is a bit kludgy, however, and it usually takes a few minutes for the failover to kick in. Not a horribly big deal, but I have some ideas in mind for which I need better.

In particular, I now have spam-filtered contact forms down to a science. Without the least bit of arrogance, I can say that after about two years of testing, I believe that my contact form spam filtering solution is the best in the world. I want to start selling it to clients whose sites are managed by others, hosting the entire contact form shebang on my own server so I don't have to share the code. But I need as close to 100 percent uptime as possible to do that.

I considered dual dedicated servers, which would have cost me somewhere around $230.00 a month, IIRC. But I also started looking at Cloud Hosting, which will cost me $129.00 a month.

Now understand that I like my hosting company. They're friendly, supportive, and have been extremely reliable. They're probably the best I've used, all in all. They also use good servers in excellent datacenters with excellent, multi-redundant connectivity.

They're also honest; and when I asked their CEO for advice in an extended PM exchange, he recommended the Cloud Hosting, despite it being half the cost of dual dedicated servers.

So here's what I'll be getting for my $129.00 a month:

• CPU: Intel 2.4Ghz (dedicated)
• RAM: 2GB (dedicated)
• Hard Disk: 80GB
• Operating System: Linux (centOS)
• Control Panel: cPanel - WHM - Fantastico - unlimited domains
• Bandwidth: 1000GB/mo.
• Redundancy / Fault Tolerance: Guaranteed 100 percent network uptime; Guaranteed Zero Downtime in Case of HW Failure

I really didn't do much shopping around outside my present provider because I actually am that happy with them, and I tend to be (perhaps exceedingly) loyal. It took me longer than I should have waited to jump ship from my previous company when their service became unacceptable after a move to a horrid DC. Since coming to my present company, I've been quite pleased.

I started with a single, mid-level VPS. I then upgraded that account when I started writing apps that needed more RAM, and then I migrated to the Mirrored VPS solution when that became available. Since then, I've had only a very few outages, none lasting more than a few minutes before the failover kicked in. But the Cloud promises failover within three pings, which is pretty darned impressive if they can actually keep that promise.

I'll be doing the migration myself (as I usually do) because I have some oddball things configured in Apache and elsewhere to make some of the sites work. As soon as they tell me the VPS is ready, I'll do the Apache rebuild and other installations, and start migrating accounts over. I still have until the end of the month on the present account, so I'll also point the DNS entries to the new IPs as I go along, and change the nameserver IPs when everything is moved over.

-Rich

 

[jsstevens]

Do you do (or plan to do) anything to have your data somewhere where you can physically get to it? A backup onto local media of some sort, perhaps?

I'm intrigued by the cloud capabilities, but I'm a little leery of having all my data in some one else's shop.

John

 

[RJM62]

Do you do (or plan to do) anything to have your data somewhere where you can physically get to it? A backup onto local media of some sort, perhaps?

I'm intrigued by the cloud capabilities, but I'm a little leery of having all my data in some one else's shop.

John

Oh, absolutely. I'm a backup nut. I (literally) have backups of my backups.

I download the tarballs from the server onto my local data drives (which are RAIDed). The array is backed up regularly to an external drive, and the external drive is in turn backed up to online backup.

I always tell people: I've never heard anyone complain about having too many good backups.

-Rich

 

[Let'sgoflying!]

I did a search and I think you mean this.
Maybe someone else can explain it, I couldn't get past the lingo to determine its day to day function in ordinary words.

"Virtual private servers bridge the gap between shared web hosting services and dedicated hosting services, giving independence from other customers of the VPS service"

 

[RJM62]

I did a search and I think you mean this.
Maybe someone else can explain it, I couldn't get past the lingo to determine its day to day function in ordinary words.

"Virtual private servers bridge the gap between shared web hosting services and dedicated hosting services, giving independence from other customers of the VPS service"

Okay, shared hosting means just that: A number of clients share a single machine with a server operating system, and share its resources. No user is guaranteed any particular amount of resources, so one user whose scripts are poorly written can cause performance losses for all the other users on the machine.

A dedicated server means an entire physical machine upon which one operating system is installed, and it is under one customer's control. That customer can do pretty much whatever he likes with that machine, including selling shared hosting to others.

In simple terms, a virtual private server is an attempt to provide the benefits of a dedicated server at a lower cost by dividing a single physical machine into multiple "virtual machines," each of which has its own operating system and a specified amount of resources, and which in theory should be relatively unaffected by other virtual machines on the physical machine.

To accomplish this, a host operating system is installed on a single, powerful physical machine. Virtualization software is in turn installed on the host operating system (or more commonly, is part of it), and creates a number of virtual machines. Each of the virtual machines is assigned certain resources (CPU, RAM, etc.).

In my case, my VPS is always assigned one of the physical machine's processors and two GB of RAM, but other configurations are possible. It's possible, for example, to assign "guaranteed" resources and "burst" resources, meaning that the machine is always guaranteed a certain amount of CPU, RAM, etc; but can also "borrow" resources for short periods of time when it needs more.

An operating system is then installed on each virtual machine in much the same was as it would be installed on a physical machine. It can be any operating system supported by the host operating system, and the different virtual machines can have different operating systems from each other. I had a choice of 30 combinations of various Unix and Windows versions and various control panels.

Each virtual machine, in this case, is called a VPS - Virtual Private Server. The user can manage it as if it were a dedicated server, meaning he can install software, make whatever configuration changes he likes, etc.

I was leaning toward dedicated servers, but was encouraged to try the cloud VPS instead because my main concern was as close to uninterrupted uptime as possible, but I really didn't need massive amounts of storage or bandwidth. The fellow at the hosting company felt that the cloud would be a better solution for my particular needs because of the extremely fast failover and other factors, some of which were way over my head.

And, of course, I can always upgrade at some time in the future.

I'm curious how this will work out. It seems intriguing to me, and this company isn't one to make promises they can't keep. When I took the mirrored VPS they told me that the failover would take five to ten minutes to happen because of the peculiarities of a VPS, but I don't recall it ever taking more than a minute or two. Now they're telling me that they can reduce that time to three pings, max, on the cloud, which is my main reason for doing the upgrade. It will allow me to do some things I've been shying away from until now.

-Rich

 

[Let'sgoflying!]

Thanks for the education!
Hope the test is open book!!

 

[RJM62]

Well, that's done.

It was a tedious affair, mainly because of the need to dismantle the mirroring on the old setup (especially in the DNS settings) prior to moving the accounts over. There were several ways to go about doing this, but unfortunately the easy way didn't occur to me until after I had moved all thirty-something accounts over individually. But they're all moved over now, and most of the clients experienced no downtime at all. The new server is so fast I have to be careful not to hurt myself.

I'm keeping the old server up for a while (it's paid for through the end of the month) mainly for DNS. I shortened all the TTLs before moving the accounts, and stuck "A" entries pointing to the new server's IP in the DNS after each move; but I really didn't have as much time as I would have liked prior to the move to assure that local DNS caching won't be a problem. I had the TTLs pretty short to begin with, however, so I don't think there will be any problems. I also used the same nameserver names and updated the IPs on them after I migrated the last account, so that should be fine.

The hosting company would have done the migration for me, but there were a lot of quirky things in there that most of the support techs don't understand. There's only one guy there, as far as I know, who really understood how the mirroring worked. Luckily for me, he's a chatty fellow, and he taught me the ins and outs of it.

Because of the way the load-balancing worked, simply copying the accounts over in the usual way would have resulted in about half of the requests failing unless the mirroring was properly dismantled. Basically this came down to removing the entries to the slave server, and also pointing both nameservers at the primary server for a time.

There was one glitch: One of the accounts was over-quota (actually, it went over-quota after the move, quite coincidentally, probably due to mail). But that was easy to fix once I figured out what had gone wrong.

All in all, I'm happy. It was tedious, but everything went well. Maybe my dream of 100 percent uptime will finally be realized.

-Rich