
A year or so ago we migrated quite a few of our firm’s server functions, including this blog, and our firm’s main web site and our firm’s shopping cart, to a shared server in this large building (company web site) in Phoenix, Arizona (aerial photo at right). I’ve never been in that building and my best guess is I won’t ever be in that building. The shared server was on an equipment rack in a cage controlled by our hosting service provider. The building provides multiple connections to the Internet and diesel-powered backup power supplies. In the photograph you can see the diesel fuel storage tanks.
Shared servers are really good to know about. A shared server can provide a very inexpensive way to host many functions in a secure and reliable environment.
On a shared server, you are sharing processor and hard-drive and network-connection bandwidth resources with others on the same server. This means that if you were to use too much of the resources, your hosting service provider would suggest you move to a dedicated server. This also means that if some other user or users on the same server were to use a lot of resources at a particular time, your functions would get slowed down. If for example you were hosting a web site on the server, the web site might run slower for visitors to the web site, because of the activities of other users on the shared server. Another thing to keep in mind is that not all hosting service providers are created equal. Some providers will load too many users on a shared server, and the result will be that it runs slowly for everyone.
Back when we used a shared server at Godaddy, it often ran slowly. I imagine this is because Godaddy put lots of users onto each server. It is part of why we migrated to our present hosting service provider. During the time that we used a shared server with our present hosting service provider, it happened only very rarely that the shared server would run slowly for us.

A couple of months ago we migrated most of the functions that were on that shared server to a dedicated server. The dedicated server costs more per month, but of course there are benefits to its being a dedicated server. The server is very fast. It never slows down because of other users, because there are no other users. And you have “root access” meaning that you can do really neat things. One of the neat things that I was able to do is to set up Let’s Encrypt (blog article) in the AutoSSL of the cPanel (Wikipedia article) in this machine. The consequence of this is that we won’t ever again have to pay money for an SSL certificate for any web site on this server.

I haven’t ever actually seen our dedicated server, and I probably never will, but from its specs I can guess that it might look like the one pictured at right. It takes up one “rack unit” on an equipment rack in the same cage where the shared server was located.
The natural question that one might ask is, if we ever were to find the need to reboot our dedicated server, how would we do it? Would I need to get on an airplane, fly to Phoenix, present myself at this building, get myself admitted to the cage, figure out which server is mine, and push the “reset” button? Or would I need to contact our hosting service provider and beg and plead for them to send someone to the cage to do this?
Surely not.
So should the need arise, how would we reboot it? Continue reading “Rebooting a server that is a thousand miles away”




