Content deleted Content added
No edit summary |
No edit summary |
||
Line 10:
These two entities, the microkernel and the management components collection, work together, They support the global system’s goal of seamlessly integrating all network-connected resources and processing functionality into an efficient, available, and unified system.<ref name="DCT">Fortier, P. J. 1986 Design of Distributed Operating Systems: Concepts and Technology. Intertext Publications, Inc., McGraw-Hill, Inc.</ref> This seamless integration of individual nodes into a global system is referred to as '''transparency''', or '''Single system image'''; describing the illusion provided to users of the global system’s appearance as a singular and local computational entity.
==Description==
===A system within a system===
{{multiple image
| direction = vertical
| width = 175
| footer = <b>Operating system organization:<br/>Monolithic vs. Distributed OS</b>
| image1 = Monolithic Kernel OS Model.PNG
| alt1 = Operating system model with monolithic kernel that includes all system services.
| caption1 = Monolithic kernel OS model<br/><br/>
| image2 = Microkernel DOS Model.PNG
| alt2 = Distributed operating system model with separate microkernel and system management components.
| caption2 = Distributed microkernel OS model<br/><br/>
}}
A Distributed operating system is an [[operating system]]. This statement may be trivial, but it is not always overt and obvious because the distributed operating system is such an integral part of the [[distributed system]]. This idea is synonymous to the consideration of a [[Square (geometry)#Properties|square]]. A square might not immediately be recognized as a rectangle. Although possessing all requisite [[Attribute (computing)|attributes]] defining a rectangle, a square’s additional attributes and specific configuration provide a disguise. At its core, the distributed operating system provides only the essential services and minimal functionality required of an operating system, but its additional attributes and particular [[Computer configuration|configuration]] make it different. The Distributed operating system fulfills its role as operating system; and does so in a manner indistinguishable from a centralized, [[Monolithic kernel|monolithic operating system]]. That is, although distributed in nature, it supports a '''Single system image''' through the implementation of '''Transparency'''; or more simply said, the system’s appearance as a singular, local entity.
===Operating system basics===
An operating system, at a basic level, is expected to isolate and manage the physical complexities of lower-level [[hardware]] resources. In turn, these complexities are organized into simplified logical [[abstractions]] and presented to higher-level entities as [[Interface (computer science)|interfaces]] into the underlying [[Resource (computer science)|resources]]. These marshalling and presentation activities take place in a secure and protected environment, often referred to as the “[[Supervisor mode#Supervisor mode|system-level]],” and describe a minimal scope of practical operating system functionality. In graphical depictions however, most monolithic operating systems would be illustrated as a discrete container sandwiched between the local hardware resources below and application programs above. The operating system container would be filled with a robust compliment of services and functions to support as many potential needs as possible or practical. This full-featured collection of services would reside and execute at the system-level and support higher, “[[User space|user-level]]” applications and services.
===Distributed operating system essentials===
A distributed operating system, illustrated in a similar fashion, would be a container suggesting [[Microkernel#Essential components and minimality|minimal operating system functionality and scope]]. This container would completely cover all disseminated hardware resources, defining the system-level. The container would extend across the system, supporting a layer of modular software components existing in the user-level. These software components supplement the distributed system with a configurable set of added services, usually integrated within the monolithic operating system (and the system-level). This division of minimal system-level function from additional user-level modular services provides a “[[separation of mechanism and policy]].” Mechanism and policy can be simply interpreted as "how something is done" versus "why something is done," respectively. Achieving this separation allows for an exceptionally loosely coupled, flexible, and scalable distributed system.
== Overview ==
=== The kernel ===
The Kernel is a minimal, but complete set of node-level utilities necessary for access to a node’s underlying hardware and resources. These mechanisms provide the complete set of “building-blocks” essential for node operation; mainly low-level allocation, management, and disposition of a node’s resources, processes, communication, and I/O management support functions.<ref name="COS">P. Brinch Hansen, Ed. 2000 Classic Operating Systems: from Batch Processing to Distributed Systems. Springer-Verlag New York, Inc.</ref> These functions are made possible by exposing a concise, yet comprehensive array of primitive mechanisms and services. The kernel is arguably the primary consideration in a distributed operating system; however, within the kernel, the subject of foremost importance is that of a well-structured and highly-efficient communications sub-system.<ref name="TLD"/>
In a distributed operating system, the kernel is often defined by a relative to absolute minimal architecture. A Kernel of this design is referred to as a Microkernel.<ref>Using LOTOS for specifying the CHORUS distributed operating system kernel Pecheur, C. 1992. Using LOTOS for specifying the CHORUS distributed operating system kernel. Comput. Commun. 15, 2 (Mar. 1992), 93-102.</ref> <ref>COOL: kernel support for object-oriented environments Habert, S. and Mosseri, L. 1990. COOL: kernel support for object-oriented environments. In Proceedings of the European Conference on Object-Oriented Programming on Object-Oriented Programming Systems, Languages, and Applications (Ottawa, Canada). OOPSLA/ECOOP '90. ACM, New York, NY, 269-275.</ref> The microkernel usually contains only the mechanisms and services which, if otherwise removed, would render a node or the global system functionally inoperable. The minimal nature of the microkernel strongly enhances a distributed operating system’s modular potential.<ref name="DCD">Distributed Operating Systems: Concepts and Design Sinha, P. K. 1996 Distributed Operating Systems: Concepts and Design. 1st. Wiley-IEEE Press.</ref> It is generally the case that the kernel is implemented directly on the bare metal of a node’s hardware; it is also common for a kernel to be replicated over all the nodes in a system.<ref name="DCP">Distributed Operating Systems Galli, D. L. 1999 Distributed Operating Systems: Concepts and Practice. 1st. Prentice Hall PTR.</ref> The combination of a kernel’s minimal design and ubiquitous coverage greatly aids in global system extensibility, and the ability to dynamically introduce new nodes or services.<ref name="DSA">Distributed Operating Systems and Algorithms Chow, R. and Chow, Y. 1997 Distributed Operating Systems and Algorithms. Addison-Wesley Longman Publishing Co., Inc.</ref>
[[Image:System Management Components.PNG|thumbnail|right|175px|alt=General overview of system management components that reside above the microkernel.|System management components overview]]
=== System management components ===
A node’s system management components are a collection of software server processes that basically define the policies of a system node. These components are the composite of a node’s system software not directly required within the kernel. These software services support all of the needs of the node; namely communication, process and resource management, reliability, performance, security, scalability, and heterogeneity to mention just a few. In this capacity the system management components compare directly to the centralized operating system of a single-entity system.<ref name="TLD"/>
However, these system management components have the added challenges with respect to supporting a node's responsibilities to the global system. In addition, the system management components accept the defensive responsibilities inherent to a distributed collection of networked nodes. Quite often, any effort to realize success in a particular area illuminates conflict with similar efforts in other areas. Therefore, a consistent approach of balanced perspective and understanding of the overall system and it goals can help mitigate complexity and quickly identify points of the diminishing returns. It is for this purpose that the separation of policy and mechanism is so critical.<ref name="DSA"/>
=== Working together as an operating system ===
The architecture and design of a distributed operating system is specifically aligned with realizing individual mode and global system goals, in a manner consistent with separating policy and mechanism. Simply said, a distributed operating system attempts to provide a highly efficient and reliable distributed computing framework with a minimum user awareness of the underlying command and control efforts.<ref name="DCD"/> The multi-level collaboration between a kernel and the system management components, and in turn between the distinct nodes in a distributed system is the functional opportunity of the distributed operating system. However, this opportunity comes at a very high cost in complexity.
===The price of complexity===
In a distributed operating system, the exceptional degree of inherent complexity could easily render the entire system an anathema to any user. As such, the logical price of realizing a distributed system – including its operating system – must be calculated in terms of overcoming vast amounts of complexity on many levels, and in many areas. This calculation includes the depth, breadth, and range of design investment and architectural planning required in achieving even the most modest implementation.<ref>Surajbali, B., Coulson, G., Greenwood, P., and Grace, P. 2007. Augmenting reflective middleware with an aspect orientation support layer. In Proceedings of the 6th international Workshop on Adaptive and Reflective Middleware: Held At the ACM/IFIP/USENIX international Middleware Conference (Newport Beach, CA, November 26 - 30, 2007). ARM '07. ACM, New York, NY, 1-6.</ref> These design and development considerations are critical and unforgiving. For instance, an deep understanding of a distributed operating system’s overall detail is required from the start.<ref name="LSF"/> As an aid in this effort, most rely strongly on the immense amount of documented experience and research in distributed computing which exists, and continues even today.
Line 77 ⟶ 52:
===Perspectives: past, present, and future===
Many notable experts look to the early 1970s for the earliest distributed systems, complete by definition and capable of being considered and implemented wholly. Research and experimentation efforts began in earnest in the mid to late-1970s and continued into the early 1990s, with a few implementations achieving modest commercial success. The subject of distributed operating systems however, has a much richer historical perspective when considering design issues severally with respect to some of the individual primordial strides towards distributed computing. There are several instances of fundamental and pioneering implementations of primitive distributed system and component concepts dating back to the early 1950s. Looking to the modern distributed system and its future, the accelerating proliferation of multiprocessor systems and multi-core processors has led to a re-emergence of the distributed system concept. The inherent challenges in many-core and multiprocessor science has led to an enormous increase in distributed system related research. Many of these research efforts investigate and describe interesting and plausible paradigms for the future of distributed computing.
==Distributed computing models==
===The nature of distribution===
{{multiple image
| direction = vertical
| width = 175
| footer = <b>Node Organization in different computing models</b>
| image1 = Node Organization-Centralized Model.PNG
| alt1 = General overview of centralized node organization. Notice the distinct single-level, master-slave relationships.
| caption1 = Generalized organization of nodes in a centralized model.<br/><br/>
| image2 = Node Organization-Network Model.PNG
| alt2 = General overview of networked node organization. Notice the multi-level relationships within distinct partitions.
| caption2 = Generalized organization of nodes in a networked model.<br/><br/>
| image3 = Node Organization-Distributed Model.PNG
| alt3 = General overview of distributed node organization. Notice the open relationships, without levels or partitions.
| caption3 = Generalized organization of nodes in a distributed model.<br/><br/>
}}
The unique nature of the Distributed operating system is both subtle and complex. A distributed operating system’s hardware infrastructure elements are not centralized, that is the elements do not have a tight proximity to one another at a single ___location. A given distributed operating system’s structure elements could reside in various rooms within a building, or in various buildings around the world. This geographically spatial dissemination defines its decentralization; however, the distributed operating system is a distributed system, not simply decentralized.
Line 109 ⟶ 75:
=== Three basic distributions ===
To better illustrate this point, let us more closely reflect upon these three system [[Software architecture|architectures]]; centralized, decentralized, and distributed. In this examination, we will consider three tightly-related aspects of their structure: organization, connection, and control. Organization will describe physical arrangement characteristics, connection will involve associations among constituent structural entities, and control will correlate the manner, necessity, and rationale of the earlier considerations.
====Organization====
Firstly, we consider the subject of organization. A centralized system is organized most simply, basically one real level of structure and all constituent element’s highly influenced by and ultimately dependent upon this organization. The Decentralized system is a more [[Federation|federated structure]], multiple levels where subsets of a system’s entities unite, these entity collections in turn uniting at higher levels, in the direction of and culminating at the central element. The distributed system has no discernable or necessary levels; it is purely an autonomous collection of discrete elements.
| |||