Rebooting a server that is a thousand miles away

click to enlarge

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. 

click to enlarge

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.

click to enlarge

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? 

I was intrigued to learn that if you rent a dedicated server from a hosting service provider, one of the things that you might get is the ability to control such things remotely.  With this particular server the way our hosting provider does this is by means of an interface called IPMI (Wikipedia article).   I connect using a VPN to a private network LAN that is inside the cage.  I then open a web browser and go to an IP address on that LAN, where I log in to a web-based management interface, as you can see here.

click to enlarge

For this screen shot I clicked on “Server Health” and “Sensor Readings”.  You can see that at the time of this screen shot, the system temperature was 25°C and the cooling fan was spinning at 1880 RPM.  

click to enlarge

Next I clicked on “Remote Control” and “Power Control”.  You can see where I can power the server off or power it on.  You can see where I can click to power-cycle the server.

Do you use a dedicated server?  If so, do you have a way that you can reboot it remotely?  Please describe it in a comment below.

3 thoughts on “Rebooting a server that is a thousand miles away

  1. When I read your question, the thought that immediately popped into my head was that one causes a power outage at the given location :P. Anyway, it doesn’t surprise me that you can reboot remotely using software… after all, when my personal wifi router goes down, I can reboot using my phone app… and like magic everything works again.

  2. Facilities vary depending on ones needs. At some co-location facilities one puts, or used to put before AWS and the commiditization of cloud services , their own equipment in a cage, the colo’ providing power, connectivity and cooled, secure environment. Rebooting and other tasks could be done by the customer or by arrangement with the colo’ staff.

  3. Carl – You are showing an out of band “baseboard monitoring console” (the SuperMicro interface). That interface is based upon code on the motherboard and runs outside of, an independent of, the OS. So yes you can use that reset, power off, or power cycle your server. I have one running, but its only 10 feet away (in a cabinet in my home office). As to remote reboot, my current servers are set to restart when power comes back on (in case of a power failure). But to manually reboot them, I would normally do that from within Windows (yes my servers all run windows); just use a “shutdown /r” command at a dos prompt with elevated privileges.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.