Download Nodes of a distributed system

Nodes of a distributed system.
■ A minicomputer with a single CPU serving several apps
from several users. Extension to multi-core CPU with
appropriate caches. e.g.
CPU
CPU
L1
L1
L2
L3
CPU
L2
CPU
L1
L1
■ A processor pool system. m users + n processors. A
multiprocessor approach.
User 1
User j
User 2
CPU POOL
User k
User i
Possible extension:
● Each user may be a unit under one organization. A
cluster. A Cloud.
● Each user may be fixed or mobile. E.g.
Ad hoc wireless networks. MANET. iMANET.
SPAN. Opportunistic networks (Exor, More)
http://www.slideshare.net/ENGMSHARI/adhoc-networks
http://www.powershow.com/view/9e9d7N2I3N/Opportunistic_Networks_powerpoint_ppt_presentation
● Each node may be a host with its own private
memory, and I/O devices. They may be connected to
each other via a LAN (usually private) or a public
Network. They may share a global RAID memory.
Again a multiprocessor cluster organization.
http://iopscience.iop.org/1367-2630/9/5/110/fulltext/
A hierarchical cluster.
● Each node is a mobile wi-fi device in a Manet
(Mobile) with no centralized address resolution
system.
● Each node is a peer in a decentralized peer-to-peer
network.
Integrating operations of nodes in a distributed system.
Mandate: Processes of an application should be
scattered across various nodes in a DS.
Few examples of an integrated operational framework.
Network Operating Systems (NOS). Aka Dialoguer.
 Earliest form of DCE in a DS architecture.
NOS: DCE
Operating System
NOS: DCE
Hardware units
Operating System
Hardware units
NOS: DCE
Operating System
Hardware units
NOS: DCE
Operating System
Hardware units
 Goal: Resources sharing
 A local request for a resource usage, would be sent
directly to the kernel. Otherwise, sent to the NOS
layer of the node that contains the resource.
e.g. One might use
rlogin: machine k
passwd:
Or, rmv machine k /file l machine p /file q
May be clients receive their files from a global file
server. E.g. two clients and two file severs, but each
mounting the servers in different places offering a
different local look.
Client 1
Client 2
Server 1
Game X
Game Y
Game Z
Game W
Server 2
mails
news
orders
documents
Client 1
Client 2
Games
Games
Work
Games Y
Games X
Games Z
Mail
News
Orders
Games Y
Games X
Games Z
Work
Mail
News
Orders
 Many NOS had been developed on top of the Unix
OS. E.g. Newcastle connection (aka Unix united)
developed as NOS in University of Newcastle upon
Tyne.
 Other examples of NOS (mainly as shared file and
printer servers): MS Windows Server 2003, MS
Windows Server 2008, UNIX, Linux, Mac OS X,
Novell Netware.
 Other examples: NOS embedded in a router or a
firewall. E.g. CISCO IOS (Internet Operating
Systems), Huawei VRP (Versatile Routing
Platform), MicroTik RouterOS (Router Operating
System)
■ An NOS in modern terminology is a system that provides
an execution environment for programmatic control of the
network.
■ An NOS provides only a programmatic interface.
Applications implemented on top of NOS perform actual
management tasks.
■ Operationally, a NOS provides programs with centralized
programming model as if all the data that the computation
at the machine needs is available always. An inherently
distributed algorithm would not work in this modality.
■ Challenging issue: Scalability.
Check: Network Operating Systems.
http://cactus.eas.asu.edu/partha/Teaching/531-common-files/NetworkOS.pdf
An ideal distributed system (reminder one more time)
■ An NOS oversees a collection of machines as a loosely
coupled software on a loosely coupled hardware. A DS sees
its organization as a tightly coupled software on a loosely
coupled hardware. This is an ideal picture.
■ For a DS, a single global IPC so that any process can talk
to any process. Not accepted: Different mechanisms on
different machines, or one mechanism for local
communication and something else for global
communication.
■ Process management must be same everywhere. Must not
depend on machine type.
■ File system must appear the same everywhere. Every file
should be visible at every location subject to protection and
security constraints.
■ Same system call interface everywhere. Each kernel must
be allowed local control over its immediate environment.
E.g. each kernel is allowed to control its private memory.
Cluster server: Windows and Sun (or Solaris) Cluster
servers.
 Provides redundancy. If one node fails, another
one comes up. Eliminates single point of
failure.
 In addition to redundancy, may provide
Component Load Balancing (CLB in MS, now
deprecated), Network Load Balancing (NLB in
MS).
 Windows NT servers offer Wolfpack
For more about Windows (or generic) clusters, check MS
Server clusters architecture overview.
download.microsoft.com/download/0/a/4/0a4db63c-0488-46e3-8add28a3c0648855/ServerClustersArchitecture.doc
Redundancy in private storage: RAID.
RAID Organization.
• RAID – multiple disk drives provides reliability via
redundancy.
• Redundant Array of Independent Disks (RAID)
• RAID is arranged into six different levels.
• Several improvements in disk-use techniques involve
the use of multiple disks working cooperatively.
• Disk striping uses a group of disks as one storage unit.
• RAID schemes improve performance and improve the
reliability of the storage system by storing redundant
data.
– Mirroring or shadowing keeps duplicate of each
disk.
– Block interleaved parity uses much less
redundancy.
– Not necessarily redundant
RAID Levels.
Amoeba
■ A microkernel based distributed operating system
developed by Tanenbaum.
■ Design goals:
 Users interact with it as if it’s a UNIX-like
timesharing system.
 Users should see only one system
 Users log into the system as a whole.
 Users command could be executed using
several machines. Parallelism.
 System achieves Performance via FLIP (Fast
Local Internet Protocol).
■ Amoeba Architecture
http://fsd-amoeba.sourceforge.net/amoeba.html
More reading:
Difference between Amoeba and Sprite:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.4795&rep=rep1&type=pdf
Difference between Amoeba and Chorus:
bahumuth.chaosnet.org/fantasy/writings/Comparison.pdf