Tip

What to do when the Web server is down

So your Web server is down. Here's how to fix it and avoid further issues.

The Web has become a staple of civilization over the past two decades. Typically ranked just below running

    Requires Free Membership to View

water and reliable electricity on the hierarchy of societal needs, the Web server has provided more in the way of societal productivity, individual entertainment and overall quality of life than perhaps any other development over the past half century.

Taken for granted by many modern end users, the Web server has allowed for academic research, personal enrichment and pizza orders, all from within the comfort of the end user's home. In order to compete, most reputable businesses have taken the plunge into the world of websites and, by default, a plunge into the depths of Web server development, configuration and maintenance. As businesses become increasingly reliant on their Web servers and as those servers become increasingly complex, organizations should pay more attention to contingency plans should their server or cluster of servers fail.

Redundancy and the Web server

Before proceeding any further, let's highlight the importance of redundancy. In the past, redundancy solutions were varied, but they all involved the purchasing and implementation of other physical machines. Today, the proliferation of virtualization has created a kind of snow ball effect that has resulted in some effective redundancy platforms. Enterprise environments are still in need of multiple machines -- just not as many. Whatever virtualization platform is chosen, simply choosing one will go a long way toward alleviating any downtime issues associated with a Web server failure.

Step 1: What happened?

As with production servers, administrators must diagnose symptoms as soon as possible when the Web server is down. Some of the questions that need to be resolved are:

  • Have there been any reported power outages, generator tests or other such occurrences that could affect the overall physical environment?
  • Is access to your Web server completely cut off or can some IP address ranges still hit the server?
  • Is management access to the server still possible?
  • Have there been any unusual entries into the logs?

These are just a few of the immediate triage questions that need to be answered prior to delving deeper into the problem.

Step 2: The simplest solution is often the best

There have been many times when I have been deeply involved in a troubleshooting scenario where, if I had simply taken a step back and taken a macro view of the problem, countless man hours and costs of finding a solution would have been saved. For example, does the host machine have power, or did someone unknowingly unplug the power cord? If the machine obviously has power, but there doesn't seem to be any network connectivity, check to see if the Ethernet or fiber cable has been inadvertently unplugged. Yes, these seem like painfully obvious solutions, but any experienced system administrator will tell you that these scenarios pop up more often than one would care to think.

Step 3: If basic troubleshooting doesn't work

Now that you've checked all of your cables and other peripheral devices, try to ping the device from within the LAN. Fortunately, the ping command is universal, so this should be straightforward regardless of the platform in use. If you can ping the server from within the LAN, try pinging the server from outside of the LAN. Doing this will go a long way in determining if the problem is at the routing and switching level, rather than at the server level. Also, if your Web server is virtualized, try pinging the IP address of the physical machine itself. This will help you to further isolate the problem. If you can't ping the server at all, and you've definitely checked the network connection, it's time to go deeper.

Step 4: Nope, the Web server is still down

You've checked your cables. You've attempted to ping the box, and you still don't have network access to the server. The good news is that you have essentially isolated the problem to either the physical machine or the operating system. Either way, you don't have to send your minions out on wild goose chases anymore, and everyone can focus on a specific area.

Taking your low hanging fruit mentality to the top of the troubleshooting tree, begin by opening whatever interface you feel comfortable with and checking your local network configuration. Is DHCP enabled? Is the Web server pointed to the correct DNS server? If so, depending on your platform, check to see if the Web server service is turned on. In a Windows environment, you would ensure that the actual Web server role has been enabled. In Linux, the specifics vary a little more, but try to find a file or service labeled httpd and ensure that the service is running.

Step 5: Desperate times call for desperate measures

If none of the above seems to work, check the logs and try to pinpoint the log entries that occurred around the same time as the Web server failure. Delegating this, while some of the more experienced troubleshooters attempt to examine other areas, may prove beneficial. Also, if it has been determined that network connectivity is not the problem, starting a Wireshark capture may be helpful in determining what exactly is traversing the network, thereby assisting in the troubleshooting process.

Overall, the reasons for Web server failure are varied. Power surges, incorrect configuration, errors in how the firewall is set up and even malicious traffic from the Internet could all be sources of failure and headaches for system administrators. All of these should provide that much more motivation for enterprise decision makers to ensure that sufficient redundancy solutions are in place, as well as detailed troubleshooting procedures tailored to the needs of the local network.

About the author:

Brad Casey is an expert on network security with experience in penetration testing, public key infrastructure, VoIP and network packet analysis. He also covers system administration, Active Directory and Windows Server 2008, with interest in Linux virtualization and Wireshark captures. He spent five years in security assessment testing for the U.S. Air Force.
brad1505@hotmail.com

This was first published in April 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.