Distributed operating system: Difference between revisions

Revision as of 04:21, 20 April 2010

Revision as of 07:10, 20 April 2010

Line 33:

<br /><br />

}}

{| class="wikitable" cellpadding="0" style="border:1.0px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|35px]]

|style="background:#DFFFFF;width:500px;"|'''Rework Initial Sections and add Refs'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 07:10, 20 April 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.0px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|35px]]

|style="background:#DFFFFF;width:500px;"|'''Loaded Design Considerations and Transparency Sections'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 07:05, 18 April 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.0px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|35px]]

|style="background:#DFFFFF;width:500px;"|'''Reworking of Overview and Description'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 09:58, 15 April 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.0px solid black;color:#000;margin-left:18em;"

|-

Line 38 ⟶ 53:

|style="background:#DFFFFF;width:500px;"|'''Near final draft of Lead/Introduction'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 09:56, 14 April 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.0px solid black;color:#000;margin-left:18em;"

|-

Line 231 ⟶ 247:

===Transparency===

Transparency, simply put, is the quality of a distributed system to be seen and understood as a single-system image;. and byTransparency faris the greatest overriding consideration in the high-level conceptual design of a distributed operating system. While a simple concept, thisthe oneconsideration issueof touchestransparency anddirectly affectseffects decision making in almost every aspect of design byof introducinga distributed operating system. Depending on the degree to which transparency is implemented into a system, certain requirements and/or restrictions onmay thosebe aspectsimposed andupon oftenthe inmany theirdesign considerations, and the relationships withbetween othersthem.

Inter-Process Communication (IPC) is the critical complement to transparency, as low-level IPC implementation considerations. General communications, process interactions, and data flows all depend on IPC sub-systems. Each situation requires fast, efficient, and reliable exchange capabilities; requiring both efficient primitives and stable protocol. And while this often leads to various scenario-specific solutions, the calling interface must be consistent.

===Inter-Process Communication===

Inter-Process Communication (IPC) is the implementation of general communication, process interaction, and data flow between threads and/or processes both within a system node, and between all nodes in a distributed system. The distributed nature of a system's nodes and the multi-level considerations of intra-node and inter-node requirements provide the base-line for high-level IPC design considerations. However, IPC in a distributed operating system is a low-level implementation. IPC is the low-level critical complement to the high-level concept of transparency. Many of the requirements and restrictions imposed on a system as a result of transparency will be accomplished directly or indirectly through IPC. In this sense, IPC is the greatest underlying concept in the low-level design considerations of a distributed operating system.

===Process Management===

Process management provides policies and mechanisms for effective and efficient sharing of a system's distributed processing resources between that system's distributed processes. These policies and mechanisms support operations involving the allocation and de-allocation of processes and ports, as well as provisions to run, suspend, migrate, halt, or resume execution of processes, to mention a few. While these distributed system resources and the operations on them can be either local or remote with respect to each other, the distributed operating system must still maintain complete state of and sychronization over all processes in the system; and do so in a manner completely consistent from the user's unified system perspective.

As an example, load balancing is a common process management function. One consideration of load balancing is which process should be moved. The kernel may have several mechanisms, one of which might be priority-based choice. This mechanism in the kernel defines '''what can be done'''; in this case, choose a process based on some priority. The system management components would have policies implementing the decision making for this context. One of these policies would define what priority means, and how it is to be used to choose a process in this instance.

Process management is a global system concept, which provides mechanisms for effective and efficient use and sharing of processing resources throughout the system. These resources, and operations on them, can be either local or remote; however, in either event, they must remain completely consistent from the user perspective. As an example, Load Balancing is an important process management function. Some of the questions involved are which process to move, and when and where to move it. These are Policy decisions relegated to Resource Management; but, the migration of the process (ex. moveProcess(fromA, toB) is a mechanism implementation of Process Management. The migration process, either local to another core or remote to another computer, again must remain consistent in presentation to the user. Other functions of this sub-system include the allocation and de-allocation of processes and ports, as well as provisions to run, suspend, and resume execution of a process. Again, these are mechanisms, related only to "What" is done, not which one, how, or where.

===Resource Management===

Line 242 ⟶ 261:

===Reliability===

One of the basic tenants of distributed systems is a high-level of reliability. This quality attribute of a distributed operating system has become a staple expectation. Reliability is most often considered from the perspectives of availability and security of a system's hardware, services, and data. Issues arising from availability failures or security violations are considered faults. Faults are physical or logical defects that can cause errors in the system. For a system to be reliable, it must somehow overcome the adverse effects of faults. There are fourthree general methods for dealing with faults: fault avoidance, fault tolerance, and fault detection and recovery. Fault avoidance are proactive measures taken to minimize the occurrence of faults. These proactive measures can be in the form of transactions, replicated resources and faultprocesses, and primary back-ups of complete servers. Fault tolerance is the ability of a system to continue some meanful level of operation in the face of a fault. In the event a fault does occur, the system should detect the fault and have the capability to respond quickly and effectively to recover full functionality. In any event, Any actions taken should make every effort to preserving the single system image.

===Performance===