Failures of a Distributed System
POS/355
July 25, 2013

Failures of a Distributed System
In the words of Adam Savage from Mythbusters, “failure is always an option”. This holds true when talking about a distributed system, which is a computer network like a Wide Area Network (WAN) or a Local Area Network (LAN). Distributed systems is defined as a software system in which components located on networked computers communicate and coordinate their actions by passing messages (Coulouris, Dollimore, Kindberg, & Blair, 2012). This allows the computers or even devices like smart phones and tablets, to share resources like printers, hard drives, and even internet access. A centralized system is a computer that is by itself, one that is not connected to a laptop. Think of a centralized computer as one of the spy computers in movies, like Mission Impossible. These systems can and will fail, while sharing some failures; a distributed system has more components that could fail, leading to them having more problems.
There a many things that could fail on a distributed system, this paper will cover four of them, starting with hardware failure. Video cards, network access card, hard disk drives, solid-state drives, memory, and power supply units (PSU), these are all pieces of hardware that are in most of the computers sold today, and they can all die at a moment’s notice. Some of these items, if they failed would not affect the network or distributed system at all, like a video card or sound card dying on one computer would not cause problems for the rest of the network. Now if a shared hard disk drive died or even if connection was lost due to the cable unplugging, could have a detrimental effect on the system. If the primary files for the system were stored on that drive, users would not be able to access their work. This is a problem that is also found on a centralized system since they have the same hardware, which would cause that one computer not to work. To fix the problem of a hard disk drive not responding due to it being unplugged from the network, the system admin would check to see if he could see the drive on one of the networked computers. If the drive is not showing up or is non-responsive, he or she should first check all cable connections and plug in any that are disconnected. If no cables are unplugged and the drive is still not accessible, it might be a dead drive and should be replaced. To get the data off the drive if not backed up the system admin or tech could send it to a specialty location to do data recovery.
The next form of failure is a failure of link. This occurs when a link connection cannot be made on the system. Links are what the connections between computers are called; the internet is a huge link connection. Failure of link, as with hardware failure is caused by many things: broken router, DHS is incorrectly defined, IP blocking or mismatch, to something as simple as the devices wireless card is turned off. When a failure of link occurs, the devices on the system will not “talk” to each other. To troubleshoot this the user, tech, or system administrator should first check that the device is on, and the cable or wireless connection is working properly. If that does not resolve the issue, the next step would be to check that hardware such as modem or router to ensure that they are working properly. After that step is completed, and they are still not able to connect, they should check the router and device settings to make sure that everything is configured correctly to connect to the network. This type of fault can only happen on a distributed system, since as stated before a centralized system is stand-alone.
The third type of failure is message lost. Message lost means that one computer has sent a data, or a message to another computer and the second computer did not receive it. This can be a minor problem if the data was not important, or a major one if sending important information from one computer to the next. This type of failure can only happen on a distributed system. To explain this; in a distributed system, computer A will send a message to computer B. Computer A is asking computer B if it’s responsive. Since the message was lost, computer B does not know a question was asked of it, but more importantly, computer A never receives a replay. This can cause computer A to read that computer B is non-responsive and is down when in fact it is working fine. Once again, this is a distributed system failure only. The fourth and final failure the be discussed is the arbitrary failure also known as the
Byzantine failure. This fault is named after the Byzantine Generals' Problem, an agreement problem in which generals of the Byzantine Empire's army must decide unanimously whether to attack some enemy army. The problem is complicated by the geographic separation of the generals, who must communicate by sending messengers to each other, and by the presence of traitors amongst the generals. These traitors can act arbitrarily in order to achieve the following aims: trick some generals into attacking; force a decision that is not consistent with the generals' desires, or confusing some generals to the point that they are unable to make up their minds. If the traitors succeed in any of these goals, any resulting attack is doomed, as only a concerted effort can result in victory (Microsoft, 1982). This failure occurs when one of the devices on the system is not just crashing but handling requests in an incorrect manner, or sending the wrong data, or corrupting itself. When a Byzantine failure is produced, the system handles it in unexpected ways, unless a fault tolerance program is designed to handle it.
With any system, failure is always an option. Hardware problems; disk drives dying, routers being fried, can cause a failure. Failure of link can cause the whole system to not be able to communicate. Message lost can cause devices to think one is down, due to the other not receiving the message. The Byzantine failure can cause a system to act in unexpected ways. One thing all these failures have in common, is that they can all be fixed or the damaged done by the mitigated in some way.
References
Coulouris, G., Dollimore, J., Kindberg, T., & Blair, G. (2012). Distributed Systems: Concepts and Design (5th ed.). Boston, MA: Addison-Wesley.
Microsoft. (1982). The Byzantine Generals Problem. Retrieved from http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf