Modern Linux Cluster
Note: This is just an introduction of LinXter
architecture as a whole for the purpose of briefing by the developers and
interested persons. The extensive description of each part of the LinXter
will be released soon.
LinXter is a cluster which is based
on Linux operating system. In this articles we will take an overview of
LinXter architecture. A cluster is an group of computers called nodes
which are interconnected together and make an illusion that they are one
computer. When number of nodes are increased the computational power of
the cluster also increase but the performance increase is not linear. LinXter
is an simple cluster implementation in which few changes to existing cluster
architecture are suggested and soon will be implemented.
LinXter Conceptual architecture
As we see in architecture there are three
things are highlighted:
- LinXter: LinXter is a cluster management system
you may also call it as cluster middleware which governs all operations
of the nodes. It is the backbone of the cluster which is responsible for
IPC, Scheduling of jobs, managing process and virtual memory management.
- Data Link: This is and ethernet links whose bandwidth
is in gigabits/s. Such a high bandwidth is necessary for the efficient communication.
- Node: Nodes are the normal PCs or any other computer
e.g. workstation, server etc. No matter which type of computer it is it
is just added as a node in cluster. Every node should have following things:
It should be operational with or without LinXter.
It is must that all nodes should belong to same family of architecture.
LinXter is having its main focus on following components:
- Process Pool
- Virtual Memory Management
- Active and Passive Nodes
- Connectivity between nodes
- Process Management
We are focusing on these issues because these are going to
be attraction of LinXter we have not yet decided on following issues
but soon those things also will be standardized.
- Connectivity between nodes: Every node is connected
through a ethernet interface. The bandwidth of this interface should be
very high for performance constrains. As these interface having analogy
to the data buses in CPU. As those buses are have very high bandwidth our
ethernet should also having high bandwidth.
As every node is defined by a unique number it is not hard to communicate
with a particular node. This numbering system may anything ex. TCP/IP nomination
system. There will not be any host-client or frontend-client structure
in LinXter. Every node will be at same operating level and all necessary
decisions will be taken by that node itself. This will employ the true concept
of cluster, otherwise it will be simply host-client parallel computing and
We will also use message broadcasting in the LinXter as it will enable one-to-many
communication possible. This will also enable us employing Dynamic Node
- Active and Passive Nodes: A new concept in LinXter
is introduced that it will employ Active and Passive nodes.
Active node is a special mode of operation of node in which the node
is part of cluster as well as it is serving the request of its user. Simply
it is sharing some resources with cluster such as some processing power.
Passive mode is mode of operation in which node dedicates all of
its resources to the cluster and its user interfacing devices are disabled
- Process Pool: Process pool is constructed by sharing
main memory or virtual memory from each node individually. Thus Process
pool is combination of main memory and virtual memory. As we discussed above
in LinXter every node is able to schedule and manage itself, this is a true
cluster. As every node is having same OS there will be uniformity in the
scheduling algorithms and management processes.
There is one more important thing about the process pool. Every process
will be created as a packet (don't confuse this with Internet data packet)
this packet will consist all necessary information about that process and
necessary to run that process. This data may be processor registers, global
data of process, who created the job, to whom the result is submitted etc.
As there is a process queue there will be a node queue also. Whenever there
will be a process in ready state in process pool the next node from ready
node queue will fetch that process for execution. This process is very simple
as there is no involvement of another node in the cluster. Since every node
will decide which process he has to execute, schedule itself and unless
any signal is received by that process it will execute. Thus in this system
there will be no performance bottleneck or overhead to a particular system
which normally happens in the client-server computing or few other clusters
- Interprocess communication in the LinXter will be very
simple and effective. All POSIX communication mechanisms will be implemented
as it is in the LinXter. Signals, pipes, shared memory and all other facilities
will be implemented. We are also planning to extend the IPC mechanism for
the efficient network communication.
- Process management: It is another issue of major
concern. In LinXter every process will be first submitted to the process
pool and then only it will be assigned to a node. New or improved load balancing
mechanisms will be used as those mechanisms are currently being standardized
and soon we are going to release them. There will be locking mechanisms
like mutex or spin locks will be provided to each process to ensure that
no any two nodes are going to execute same process at any instance.
This was a brief introduction to LinXter and hope you will
be having now a better understanding of LinXter. Since our documentation team
is currently undergoing to release the next versions of documentation soon.
If you are interested in involving this project it will be nice. We are keen
to help you so that you can help us to construct a better future of LinXter.
Last updated: 7-01-2003