Building High Performance Cluster / Compute Cluster on Linux
Steps in configuring a High Performance Cluster
-
Setting up Hardware.
-
Install Linux operating system on all nodes.
Like Redhat or Fedora or SUSE or Ubuntu
-
Configure Network on all nodes.
-
Setup Hostname(s) on all nodes.
-
Setup DNS on head node.
-
Setup NFS server on head node and export home directory.
-
Mount home directory of head node on all compute nodes.
-
Setup Head node or front end node as NIS Domain server and promote as Master for cluster domain.
-
Add all compute nodes to clusters domain.
-
Create NIS user accounts on head node.
-
Login using NIS account on compute nodes and test.
-
Setup Password less SSH (Secure Shell Protocol) and test.
-
Install Compilers and other development tools (If not installed earlier).
-
Install Message Passing Interface Library (Open MPI or MPICH).
-
Update PATH environment variable and add PATH_TO_LIBRARY variable.
-
Create hosts file.
-
Write a sample Hello world Parallel program and test cluster setup.
-
Write parallel programs and analyze performance.
Note : This guide assumes you are using RHEL or Fedora Linux
Step 1: Setting up Hardware
The following configuration allows you to connect a group of computers (called nodes or members) to work together as a cluster. This is required to achieve Single System Image (SSI).
To set up a cluster, you must connect the nodes to certain cluster hardware and configure the nodes into the cluster environment as shown in the following diagram.
Steps in configuring a High Performance Cluster
- Setting up Hardware.
- Install Linux operating system on all nodes.
Like Redhat or Fedora or SUSE or Ubuntu
- Configure Network on all nodes.
- Setup Hostname(s) on all nodes.
- Setup DNS on head node.
- Setup NFS server on head node and export home directory.
- Mount home directory of head node on all compute nodes.
- Setup Head node or front end node as NIS Domain server and promote as Master for cluster domain.
- Add all compute nodes to clusters domain.
- Create NIS user accounts on head node.
- Login using NIS account on compute nodes and test.
- Setup Password less SSH (Secure Shell Protocol) and test.
- Install Compilers and other development tools (If not installed earlier).
- Install Message Passing Interface Library (Open MPI or MPICH).
- Update PATH environment variable and add PATH_TO_LIBRARY variable.
- Create hosts file.
- Write a sample Hello world Parallel program and test cluster setup.
- Write parallel programs and analyze performance.
Note : This guide assumes you are using RHEL or Fedora Linux
Step 1: Setting up Hardware
The following configuration allows you to connect a group of computers (called nodes or members) to work together as a cluster. This is required to achieve Single System Image (SSI).
To set up a cluster, you must connect the nodes to certain cluster hardware and configure the nodes into the cluster environment as shown in the following diagram.
The amount and type of hardware varies according to the purpose and availability requirements of the cluster. Typically, an enterprise-level cluster requires the following type of hardware.
A typical Enterprise level High Performance cluster Architecture:
Different Kinds of cluster private networks with their speeds:
Gigabit Ethernet
Gigabit Ethernet (GbE or 1 GigE) is a term describing various technologies for transmitting Ethernetframes at a rate of a gigabit per second, as defined by the IEEE 802.3-2008 standard. Half-duplex gigabit links connected through hubs are allowed by the specification but in the marketplace full-duplex withswitches are normal.
Myrinet
Myrinet, ANSI/VITA 26-1998, is a high-speed local area networking system designed by Myricom to be used as an interconnect between multiple machines to form computer clusters. Myrinet has much less protocol overhead than standards such as Ethernet, and therefore provides better throughput, less interference, and lower latency while using the host CPU..
The amount and type of hardware varies according to the purpose and availability requirements of the cluster. Typically, an enterprise-level cluster requires the following type of hardware.
A typical Enterprise level High Performance cluster Architecture:
Different Kinds of cluster private networks with their speeds:
Gigabit Ethernet
Gigabit Ethernet (GbE or 1 GigE) is a term describing various technologies for transmitting Ethernetframes at a rate of a gigabit per second, as defined by the IEEE 802.3-2008 standard. Half-duplex gigabit links connected through hubs are allowed by the specification but in the marketplace full-duplex withswitches are normal.
Myrinet
Myrinet, ANSI/VITA 26-1998, is a high-speed local area networking system designed by Myricom to be used as an interconnect between multiple machines to form computer clusters. Myrinet has much less protocol overhead than standards such as Ethernet, and therefore provides better throughput, less interference, and lower latency while using the host CPU..
Performance
Myrinet is a lightweight protocol with little overhead that allows it to operate with throughput close to the basic signaling speed of the physical layer. On the latest 2.0 Gbit/s links, Myrinet often runs at 1.98 Gbit/s of sustained throughput, considerably better than what Ethernet offers, which varies from 0.6 to 1.9 Gbit/s, depending on load.
Infiniband
InfiniBand is a switched fabric communications link primarily used in high-performance computing. Its features include quality of service and failover, and it is designed to be scalable. The InfiniBand architecture specification defines a connection between processor nodes and high performance I/O nodes such as storage devices.
Myrinet is a lightweight protocol with little overhead that allows it to operate with throughput close to the basic signaling speed of the physical layer. On the latest 2.0 Gbit/s links, Myrinet often runs at 1.98 Gbit/s of sustained throughput, considerably better than what Ethernet offers, which varies from 0.6 to 1.9 Gbit/s, depending on load.
Infiniband
InfiniBand is a switched fabric communications link primarily used in high-performance computing. Its features include quality of service and failover, and it is designed to be scalable. The InfiniBand architecture specification defines a connection between processor nodes and high performance I/O nodes such as storage devices.
Description
Signaling rate
The serial connection's signalling rate is 2.5 gigabit per second (Gbit/s) in each direction per connection. InfiniBand supports double (DDR) and quad data (QDR) speeds, for 5 Gbit/s or 10 Gbit/s respectively, at the same data-clock rate.
Links use 8B/10B encoding — every 10 bits sent carry 8bits of data — making the useful data transmission rate four-fifths the raw rate. Thus single, double, and quad data rates carry 2, 4, or 8 Gbit/s respectively.
The serial connection's signalling rate is 2.5 gigabit per second (Gbit/s) in each direction per connection. InfiniBand supports double (DDR) and quad data (QDR) speeds, for 5 Gbit/s or 10 Gbit/s respectively, at the same data-clock rate.
Links use 8B/10B encoding — every 10 bits sent carry 8bits of data — making the useful data transmission rate four-fifths the raw rate. Thus single, double, and quad data rates carry 2, 4, or 8 Gbit/s respectively.
Latency
The single data rate switch chips have a latency of 200 nanoseconds, and DDR switch chips have a latency of 140 nanoseconds.The end-to-end latency range ranges from 1.07 microseconds MPI latency (Mellanox ConnectX HCAs) to 1.29 microseconds MPI latency (Qlogic InfiniPath HTX HCAs) to 2.6 microseconds (Mellanox InfiniHost III HCAs).
The single data rate switch chips have a latency of 200 nanoseconds, and DDR switch chips have a latency of 140 nanoseconds.The end-to-end latency range ranges from 1.07 microseconds MPI latency (Mellanox ConnectX HCAs) to 1.29 microseconds MPI latency (Qlogic InfiniPath HTX HCAs) to 2.6 microseconds (Mellanox InfiniHost III HCAs).
Topology
InfiniBand uses a switched fabric topology, as opposed to a hierarchical switched network like Ethernet.
As in the channel model used in most mainframe computers, all transmissions begin or end at a channel adapter. Each processor contains a host channel adapter (HCA) and each peripheral has a target channel adapter (TCA). These adapters can also exchange information for security or quality of service.
InfiniBand uses a switched fabric topology, as opposed to a hierarchical switched network like Ethernet.
As in the channel model used in most mainframe computers, all transmissions begin or end at a channel adapter. Each processor contains a host channel adapter (HCA) and each peripheral has a target channel adapter (TCA). These adapters can also exchange information for security or quality of service.
Messages
InfiniBand transmits data in packets of up to 4 kB that are taken together to form a message. A message can be:
ATM
Asynchronous transfer mode (ATM) is an electronic digital data transmission technology. ATM is implemented as a network protocol and was first developed in the mid 1980s. The goal was to design a single networking strategy that could transport real-time video conference and audio as well as image files, text and email. Two groups, the International Telecommunications Union and the ATM Forum were involved in the creation of the standards.ATM uses a connection-oriented model and establishes a virtual circuit between two endpoints before the actual data exchange begins.
Step 2 : [Installing Linux Operating System Methods]
Install the operating system by any one of the following methods.
Note: This document doesn’t cover the procedure for Installation methods. Please refer the links provided below for ore information.
See the following list of installation methods to determine the type of installation that you want to do and the information source for the installation
The following methods can be used:
Step 3 : [Configuring Network on all nodes]
Configuring network involves assigning IP Address, subnet mask and gateway for each node on cluster. It is compulsory to assign static IP address rather than DHCP for cluster private network.
In order to configure the network do the following.
-
Open a terminal
-
Give the command setup ( A Command menu appears )
-
Select Network Configuration and hit enter
-
A message “Would you like to setup Networking†appears. Select YES.
Note: If there are multiple network cards, select for which card you want to configure.
-
Enter IP Address , Net Mask, Default Gateway , Primary DNS (If necessary) and choose OK.
-
Now you return to main menu select Quit and hit enter.
-
Restart the network service as said follows in order to take changes effect.
# service network restart [ Note : Enter the commands in shell / terminal ]
-
Check the assigned IP Address as follows.
When Linux is installed, First Ethernet device is as called eth0. You can determine the IP address of this device with the ifconfig command.
# ifconfig –a
-
Follow the same procedure to configure network for both Administration network and cluster private network.
Step 4 : Configuring the Hostname
To configure hostname (Machine Name) in Linux edit the following file and make an entry as said below.
# vi /etc/sysconfig/network
HOSTNAME = <required-hostname.domain-name>
Note : Restart the machine once in order to take the changes effect. (Be careful while restarting in live environment.)
Steps 5 -11 [Configuring NIS]
Configuring NIS is necessary in order to perform computation on cluster nodes by passing messages to each other, this requires a global shared space and password less logins. All this can be achieved by configuring NIS. Head node will be the NIS master and all other nodes (Compute nodes) will be NIS clients.
Network Information Services (NIS) enables you to create user accounts that can be shared across all systems on your network. The user account is created only on the NIS server. NIS clients download the necessary username and password data from the NIS server to verify each user login.
An advantage of NIS is that users need to change their passwords on the NIS server only, instead of every system on the network. This makes NIS popular in computer training labs, distributed software development projects or any other situation where groups of people have to share many different computers.
The disadvantages are that NIS doesn't encrypt the username and password information sent to the clients with each login and that all users have access to the encrypted passwords stored on the NIS server..
The Lightweight Directory Access Protocol (LDAP) offers similar features to NIS but has the advantage of supporting encryption without additional software. It is for this reason that LDAP has become increasingly popular for this type of application
Note : headnode refers to hostname of Head-node / Front end in cluster. cnode refers to the hostname of compute node in the cluster. The configuration done on the cnode has to be done for all compute nodes in the cluster.
Scenario
Implementation plan:
-
Configure headnode as an NFS server to make its /home directory available to the compute nodes.
-
Configure cnode as an NFS client that can access headnode's /home directory.
-
Configure headnode as an NIS server.
-
Create a user account (nisuser) on headnode that doesn't exist on cnode. Convert the account to a NIS user account.
-
Configure cnode as an NIS client.
-
Test a remote login from headnode to cnode using the username and password of the account nisuser.
InfiniBand transmits data in packets of up to 4 kB that are taken together to form a message. A message can be:
ATM
Asynchronous transfer mode (ATM) is an electronic digital data transmission technology. ATM is implemented as a network protocol and was first developed in the mid 1980s. The goal was to design a single networking strategy that could transport real-time video conference and audio as well as image files, text and email. Two groups, the International Telecommunications Union and the ATM Forum were involved in the creation of the standards.ATM uses a connection-oriented model and establishes a virtual circuit between two endpoints before the actual data exchange begins.
Step 2 : [Installing Linux Operating System Methods]
Install the operating system by any one of the following methods.
Note: This document doesn’t cover the procedure for Installation methods. Please refer the links provided below for ore information.
See the following list of installation methods to determine the type of installation that you want to do and the information source for the installation
The following methods can be used:
Step 3 : [Configuring Network on all nodes]
Configuring network involves assigning IP Address, subnet mask and gateway for each node on cluster. It is compulsory to assign static IP address rather than DHCP for cluster private network.
In order to configure the network do the following.
- Open a terminal
- Give the command setup ( A Command menu appears )
- Select Network Configuration and hit enter
- A message “Would you like to setup Networking†appears. Select YES.
Note: If there are multiple network cards, select for which card you want to configure.
- Enter IP Address , Net Mask, Default Gateway , Primary DNS (If necessary) and choose OK.
- Now you return to main menu select Quit and hit enter.
- Restart the network service as said follows in order to take changes effect.
# service network restart [ Note : Enter the commands in shell / terminal ]
- Check the assigned IP Address as follows.
When Linux is installed, First Ethernet device is as called eth0. You can determine the IP address of this device with the ifconfig command.
# ifconfig –a
- Follow the same procedure to configure network for both Administration network and cluster private network.
Step 4 : Configuring the Hostname
To configure hostname (Machine Name) in Linux edit the following file and make an entry as said below.
# vi /etc/sysconfig/network
HOSTNAME = <required-hostname.domain-name>
Note : Restart the machine once in order to take the changes effect. (Be careful while restarting in live environment.)
Steps 5 -11 [Configuring NIS]
Configuring NIS is necessary in order to perform computation on cluster nodes by passing messages to each other, this requires a global shared space and password less logins. All this can be achieved by configuring NIS. Head node will be the NIS master and all other nodes (Compute nodes) will be NIS clients.
Network Information Services (NIS) enables you to create user accounts that can be shared across all systems on your network. The user account is created only on the NIS server. NIS clients download the necessary username and password data from the NIS server to verify each user login.
An advantage of NIS is that users need to change their passwords on the NIS server only, instead of every system on the network. This makes NIS popular in computer training labs, distributed software development projects or any other situation where groups of people have to share many different computers.
The disadvantages are that NIS doesn't encrypt the username and password information sent to the clients with each login and that all users have access to the encrypted passwords stored on the NIS server..
The Lightweight Directory Access Protocol (LDAP) offers similar features to NIS but has the advantage of supporting encryption without additional software. It is for this reason that LDAP has become increasingly popular for this type of application
Note : headnode refers to hostname of Head-node / Front end in cluster. cnode refers to the hostname of compute node in the cluster. The configuration done on the cnode has to be done for all compute nodes in the cluster.
Scenario
Implementation plan:
- Configure headnode as an NFS server to make its /home directory available to the compute nodes.
- Configure cnode as an NFS client that can access headnode's /home directory.
- Configure headnode as an NIS server.
- Create a user account (nisuser) on headnode that doesn't exist on cnode. Convert the account to a NIS user account.
- Configure cnode as an NIS client.
- Test a remote login from headnode to cnode using the username and password of the account nisuser.
Configuring The NFS Server
Here are the steps to configure the NFS server in this scenario:
1. Edit the /etc/exports file to allow NFS mounts of the /home directory with read/write access.
/home *(rw,sync)
2. Let NFS read the /etc/exports file for the new entry, and make /home available to the network with the exportfs command.
[root@headnode tmp]# exportfs -a
[root@headnode tmp]#
3. Make sure the required nfs, nfslock, and portmap daemons are both running and configured to start after the next reboot.
[root@headnode tmp]# chkconfig nfslock on
[root@headnode tmp]# chkconfig nfs on
[root@headnode tmp]# chkconfig portmap on
[root@headnode tmp]# service portmap start
Starting portmapper: [ OK ]
[root@headnode tmp]# service nfslock start
Starting NFS statd: [ OK ]
[root@headnode tmp]# service nfs start
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS daemon: [ OK ]
Starting NFS mountd: [ OK ]
[root@headnode tmp]#
After configuring the NFS server, we have to configure its clients.
Here are the steps to configure the NFS server in this scenario:
1. Edit the /etc/exports file to allow NFS mounts of the /home directory with read/write access.
/home *(rw,sync)
2. Let NFS read the /etc/exports file for the new entry, and make /home available to the network with the exportfs command.
[root@headnode tmp]# exportfs -a
[root@headnode tmp]#
3. Make sure the required nfs, nfslock, and portmap daemons are both running and configured to start after the next reboot.
[root@headnode tmp]# chkconfig nfslock on
[root@headnode tmp]# chkconfig nfs on
[root@headnode tmp]# chkconfig portmap on
[root@headnode tmp]# service portmap start
Starting portmapper: [ OK ]
[root@headnode tmp]# service nfslock start
Starting NFS statd: [ OK ]
[root@headnode tmp]# service nfs start
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS daemon: [ OK ]
Starting NFS mountd: [ OK ]
[root@headnode tmp]#
After configuring the NFS server, we have to configure its clients.
Configuring the NFS Client
You also need to configure the NFS clients to mount their /home directories on the NFS server.
These steps archive the /home directory. In a production environment in which the /home directory would be actively used, you'd have to force the users to log off, backup the data, restore it to the NFS server, and then follow the steps below. As this is a cluster environment, these prerequisites aren't necessary.
1. Make sure the required netfs, nfslock, and portmap daemons are running and configured to start after the next reboot.
[root@cnode tmp]# chkconfig nfslock on
[root@cnode tmp]# chkconfig netfs on
[root@cnode tmp]# chkconfig portmap on
[root@cnode tmp]# service portmap start
Starting portmapper: [ OK ]
[root@cnode tmp]# service netfs start
Mounting other filesystems: [ OK ]
[root@cnode tmp]# service nfslock start
Starting NFS statd: [ OK ]
[root@cnode tmp]#
2. Keep a copy of the old /home directory, and create a new directory /home on which you'll mount the NFS server's directory.
[root@cnode tmp]# mv /home /home.save
[root@cnode tmp]# mkdir /home
[root@cnode tmp]# ll /
...
...
drwxr-xr-x 1 root root 11 Nov 16 20:22 home
drwxr-xr-x 2 root root 4096 Jan 24 2003 home.save
...
...
[root@cnode tmp]#
3. Make sure you can mount headnode's /home directory on the new /home directory you just created. Unmount it once everything looks correct.
[root@cnode tmp]# mount 192.168.1.100:/home /home/
[root@cnode tmp]# ls /home
ftpinstall nisuser quotauser cnode www
[root@cnode tmp]# umount /home
[root@cnode tmp]#
4. Start configuring autofs automounting. Edit your /etc/auto.master file to refer to file /etc/auto.home for mounting information whenever the /home directory is accessed. After five minutes, autofs unmounts the directory.
#/etc/auto.master
/home /etc/auto.home --timeout 600
5. Edit file /etc/auto.home to do the NFS mount whenever the /home directory is accessed. If the line is too long to view on your screen, you can add a \ character at the end to continue on the next line.
#/etc/auto.home
* -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid,tcp \
192.168.1.100:/home/&
6. Start autofs and make sure it starts after the next reboot with the chkconfig command.
[root@cnode tmp]# chkconfig autofs on
[root@cnode tmp]# service autofs restart
Stopping automount:[ OK ]
Starting automount:[ OK ]
[root@cnode tmp]#
After doing this, you won't be able to see the contents of the /home directory on headnode as user root. This is because by default NFS activates the root squash feature, which disables this user from having privileged access to directories on remote NFS servers. You'll be able to test this later after NIS is configured.
All newly added Linux users will now be assigned a home directory under the new remote /home directory. This scheme will make the users feel their home directories are local, when in reality they are automatically mounted and accessed over your network.
You also need to configure the NFS clients to mount their /home directories on the NFS server.
These steps archive the /home directory. In a production environment in which the /home directory would be actively used, you'd have to force the users to log off, backup the data, restore it to the NFS server, and then follow the steps below. As this is a cluster environment, these prerequisites aren't necessary.
1. Make sure the required netfs, nfslock, and portmap daemons are running and configured to start after the next reboot.
[root@cnode tmp]# chkconfig nfslock on
[root@cnode tmp]# chkconfig netfs on
[root@cnode tmp]# chkconfig portmap on
[root@cnode tmp]# service portmap start
Starting portmapper: [ OK ]
[root@cnode tmp]# service netfs start
Mounting other filesystems: [ OK ]
[root@cnode tmp]# service nfslock start
Starting NFS statd: [ OK ]
[root@cnode tmp]#
2. Keep a copy of the old /home directory, and create a new directory /home on which you'll mount the NFS server's directory.
[root@cnode tmp]# mv /home /home.save
[root@cnode tmp]# mkdir /home
[root@cnode tmp]# ll /
...
...
drwxr-xr-x 1 root root 11 Nov 16 20:22 home
drwxr-xr-x 2 root root 4096 Jan 24 2003 home.save
...
...
[root@cnode tmp]#
3. Make sure you can mount headnode's /home directory on the new /home directory you just created. Unmount it once everything looks correct.
[root@cnode tmp]# mount 192.168.1.100:/home /home/
[root@cnode tmp]# ls /home
ftpinstall nisuser quotauser cnode www
[root@cnode tmp]# umount /home
[root@cnode tmp]#
4. Start configuring autofs automounting. Edit your /etc/auto.master file to refer to file /etc/auto.home for mounting information whenever the /home directory is accessed. After five minutes, autofs unmounts the directory.
#/etc/auto.master
/home /etc/auto.home --timeout 600
5. Edit file /etc/auto.home to do the NFS mount whenever the /home directory is accessed. If the line is too long to view on your screen, you can add a \ character at the end to continue on the next line.
#/etc/auto.home
* -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid,tcp \
192.168.1.100:/home/&
6. Start autofs and make sure it starts after the next reboot with the chkconfig command.
[root@cnode tmp]# chkconfig autofs on
[root@cnode tmp]# service autofs restart
Stopping automount:[ OK ]
Starting automount:[ OK ]
[root@cnode tmp]#
After doing this, you won't be able to see the contents of the /home directory on headnode as user root. This is because by default NFS activates the root squash feature, which disables this user from having privileged access to directories on remote NFS servers. You'll be able to test this later after NIS is configured.
All newly added Linux users will now be assigned a home directory under the new remote /home directory. This scheme will make the users feel their home directories are local, when in reality they are automatically mounted and accessed over your network.
Configuring the NIS Server
NFS only covers file sharing over the network. You now have to configure NIS login authentication for the lab students before the job is done. The configuration of the NIS server is not difficult, but requires many steps that you may overlook.
Note: In the early days, NIS was called Yellow Pages. The developers had to change the name after a copyright infringement lawsuit, yet many of the key programs associated with NIS have kept their original names beginning with yp.
NFS only covers file sharing over the network. You now have to configure NIS login authentication for the lab students before the job is done. The configuration of the NIS server is not difficult, but requires many steps that you may overlook.
Note: In the early days, NIS was called Yellow Pages. The developers had to change the name after a copyright infringement lawsuit, yet many of the key programs associated with NIS have kept their original names beginning with yp.
Install the NIS Server Packages
All the packages required for NIS clients are a standard part of most Fedora installations. The ypserv package for servers is not.
All the packages required for NIS clients are a standard part of most Fedora installations. The ypserv package for servers is not.
Edit Your /etc/sysconfig/network File
You need to add the NIS domain you wish to use in the /etc/sysconfig/network file. For the cluster, call the domain as MY.CLUSTER.COM.
#/etc/sysconfig/network
NISDOMAIN="MY.CLUSTER.COM"
You need to add the NIS domain you wish to use in the /etc/sysconfig/network file. For the cluster, call the domain as MY.CLUSTER.COM.
#/etc/sysconfig/network
NISDOMAIN="MY.CLUSTER.COM"
Edit Your /etc/yp.conf File
NIS servers also have to be NIS clients themselves, so you'll have to edit the NIS client configuration file /etc/yp.conf to list the domain's NIS server as being the server itself or localhost.
# /etc/yp.conf - ypbind configuration file
ypserver 127.0.0.1
NIS servers also have to be NIS clients themselves, so you'll have to edit the NIS client configuration file /etc/yp.conf to list the domain's NIS server as being the server itself or localhost.
# /etc/yp.conf - ypbind configuration file
ypserver 127.0.0.1
Start the Key NIS Server Related Daemons
Start the necessary NIS daemons in the /etc/init.d directory and use the chkconfig command to ensure they start after the next reboot.
[root@headnode tmp]# service portmap start
Starting portmapper: [ OK ]
[root@headnode tmp]# service yppasswdd start
Starting YP passwd service: [ OK ]
[root@headnode tmp]# service ypserv start
Setting NIS domain name MY.CLUSTER.COM: [ OK ]
Starting YP server services: [ OK ]
[root@headnode tmp]#
[root@headnode tmp]# chkconfig portmap on
[root@headnode tmp]# chkconfig yppasswdd on
[root@headnode tmp]# chkconfig ypserv on
Table lists a summary of the daemon's functions.
Start the necessary NIS daemons in the /etc/init.d directory and use the chkconfig command to ensure they start after the next reboot.
[root@headnode tmp]# service portmap start
Starting portmapper: [ OK ]
[root@headnode tmp]# service yppasswdd start
Starting YP passwd service: [ OK ]
[root@headnode tmp]# service ypserv start
Setting NIS domain name MY.CLUSTER.COM: [ OK ]
Starting YP server services: [ OK ]
[root@headnode tmp]#
[root@headnode tmp]# chkconfig portmap on
[root@headnode tmp]# chkconfig yppasswdd on
[root@headnode tmp]# chkconfig ypserv on
Table lists a summary of the daemon's functions.
Required NIS Server Daemons
Daemon Name
Purpose
portmap
The foundation RPC daemon upon which NIS runs.
yppasswdd
Lets users change their passwords on the NIS server from NIS clients
ypserv
Main NIS server daemon
ypbind
Main NIS client daemon
ypxfrd
Used to speed up the transfer of very large NIS maps
Make sure they are all running before continuing to the next step. You can use the rpcinfo command to do this.
[root@headnode tmp]# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100009 1 udp 681 yppasswdd
100004 2 udp 698 ypserv
100004 1 udp 698 ypserv
100004 2 tcp 701 ypserv
100004 1 tcp 701 ypserv
[root@headnode tmp]#
The ypbind and ypxfrd daemons won't start properly until after you initialize the NIS domain. You'll start these daemons after initialization is completed.
Daemon Name
|
Purpose
|
portmap
|
The foundation RPC daemon upon which NIS runs.
|
yppasswdd
|
Lets users change their passwords on the NIS server from NIS clients
|
ypserv
|
Main NIS server daemon
|
ypbind
|
Main NIS client daemon
|
ypxfrd
|
Used to speed up the transfer of very large NIS maps
|
Make sure they are all running before continuing to the next step. You can use the rpcinfo command to do this.
[root@headnode tmp]# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100009 1 udp 681 yppasswdd
100004 2 udp 698 ypserv
100004 1 udp 698 ypserv
100004 2 tcp 701 ypserv
100004 1 tcp 701 ypserv
[root@headnode tmp]#
The ypbind and ypxfrd daemons won't start properly until after you initialize the NIS domain. You'll start these daemons after initialization is completed.
Initialize Your NIS Domain
Now that you have decided on the name of the NIS domain, you'll have to use the ypinit command to create the associated authentication files for the domain. You will be prompted for the name of the NIS server, which in this case is headnode.
With this procedure, all nonprivileged accounts are automatically accessible via NIS.
[root@headnode tmp]# /usr/lib/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS servers. Headnode is in the list of NIS server hosts. Please continue to add the names for the other hosts, one per line. When you are done with the list, type a <control D>.
next host to add: headnode
next host to add:
The current list of NIS servers looks like this:
headnode
Is this correct? [y/n: y] y
We need a few minutes to build the databases...
Building /var/yp/MY.CLUSTER.COM/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/MY.CLUSTER.COM'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating services.byservicename...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
gmake[1]: Leaving directory `/var/yp/MY.CLUSTER.COM'
headnode has been set up as a NIS master server.
Now you can run ypinit -s headnode on all slave server.
[root@headnode tmp]#
Note: Make sure portmap is running before trying this step or you'll get errors, such as:
failed to send 'clear' to local ypserv: RPC: Port mapper failureUpdating group.bygid...
You will have to delete the /var/yp/MY.CLUSTER.COM directory and restart portmap, yppasswd, and ypserv before you'll be able to do this again successfully.
Now that you have decided on the name of the NIS domain, you'll have to use the ypinit command to create the associated authentication files for the domain. You will be prompted for the name of the NIS server, which in this case is headnode.
With this procedure, all nonprivileged accounts are automatically accessible via NIS.
[root@headnode tmp]# /usr/lib/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS servers. Headnode is in the list of NIS server hosts. Please continue to add the names for the other hosts, one per line. When you are done with the list, type a <control D>.
next host to add: headnode
next host to add:
The current list of NIS servers looks like this:
headnode
Is this correct? [y/n: y] y
We need a few minutes to build the databases...
Building /var/yp/MY.CLUSTER.COM/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/MY.CLUSTER.COM'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating services.byservicename...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
gmake[1]: Leaving directory `/var/yp/MY.CLUSTER.COM'
headnode has been set up as a NIS master server.
Now you can run ypinit -s headnode on all slave server.
[root@headnode tmp]#
Note: Make sure portmap is running before trying this step or you'll get errors, such as:
failed to send 'clear' to local ypserv: RPC: Port mapper failureUpdating group.bygid...
You will have to delete the /var/yp/MY.CLUSTER.COM directory and restart portmap, yppasswd, and ypserv before you'll be able to do this again successfully.
Start The ypbind and ypxfrd Daemons
You can now start the ypbind and the ypxfrd daemons because the NIS domain files have been created.
[root@headnode tmp]# service ypbind start
Binding to the NIS domain: [ OK ]
Listening for an NIS domain server.
[root@headnode tmp]# service ypxfrd start
Starting YP map server: [ OK ]
[root@headnode tmp]# chkconfig ypbind on
[root@headnode tmp]# chkconfig ypxfrd on
You can now start the ypbind and the ypxfrd daemons because the NIS domain files have been created.
[root@headnode tmp]# service ypbind start
Binding to the NIS domain: [ OK ]
Listening for an NIS domain server.
[root@headnode tmp]# service ypxfrd start
Starting YP map server: [ OK ]
[root@headnode tmp]# chkconfig ypbind on
[root@headnode tmp]# chkconfig ypxfrd on
Make Sure The Daemons Are Running
All the NIS daemons use RPC port mapping and, therefore, are listed using the rpcinfo command when they are running correctly.
[root@headnode tmp]# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1024 nlockmgr
100021 3 udp 1024 nlockmgr
100021 4 udp 1024 nlockmgr
100004 2 udp 784 ypserv
100004 1 udp 784 ypserv
100004 2 tcp 787 ypserv
100004 1 tcp 787 ypserv
100009 1 udp 798 yppasswdd
600100069 1 udp 850 fypxfrd
600100069 1 tcp 852 fypxfrd
100007 2 udp 924 ypbind
100007 1 udp 924 ypbind
100007 2 tcp 927 ypbind
100007 1 tcp 927 ypbind
[root@headnode tmp]#
All the NIS daemons use RPC port mapping and, therefore, are listed using the rpcinfo command when they are running correctly.
[root@headnode tmp]# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1024 nlockmgr
100021 3 udp 1024 nlockmgr
100021 4 udp 1024 nlockmgr
100004 2 udp 784 ypserv
100004 1 udp 784 ypserv
100004 2 tcp 787 ypserv
100004 1 tcp 787 ypserv
100009 1 udp 798 yppasswdd
600100069 1 udp 850 fypxfrd
600100069 1 tcp 852 fypxfrd
100007 2 udp 924 ypbind
100007 1 udp 924 ypbind
100007 2 tcp 927 ypbind
100007 1 tcp 927 ypbind
[root@headnode tmp]#
Adding New NIS Users
New NIS users can be created by logging into the NIS server and creating the new user account. In this case, you'll create a user account called nisuser and give it a new password.
Once this is complete, you then have to update the NIS domain's authentication files by executing the make command in the /var/yp directory.
This procedure makes all NIS-enabled, nonprivileged accounts become automatically accessible via NIS, not just newly created ones. It also exports all the user's characteristics stored in the /etc/passwd and /etc/group files, such as the login shell, the user's group, and home directory.
[root@headnode tmp]# useradd -g users nisuser
[root@headnode tmp]# passwd nisuser
Changing password for user nisuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root@headnode tmp]# cd /var/yp
[root@headnode yp]# make
gmake[1]: Entering directory `/var/yp/MY.CLUSTER.COM'
Updating passwd.byname...
Updating passwd.byuid...
Updating netid.byname...
gmake[1]: Leaving directory `/var/yp/MY.CLUSTER.COM'
[root@headnode yp]#
You can check to see if the user's authentication information has been updated by using the ypmatch command, which should return the user's encrypted password string.
[root@headnode yp]# ypmatch nisuser passwd
nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/::504:100::/home/nisuser:/bin/bash
[root@headnode yp]#
Unlike ypmatch, getent doesn't provide an encrypted password when run on an NIS server, it just provides the user's entry in the /etc/passwd file. On a NIS client, the results are identical with both showing the encrypted password.
[root@headnode yp]# getent passwd nisuser
nisuser:x:504:100::/home/nisuser:/bin/bash
[root@headnode yp]#
New NIS users can be created by logging into the NIS server and creating the new user account. In this case, you'll create a user account called nisuser and give it a new password.
Once this is complete, you then have to update the NIS domain's authentication files by executing the make command in the /var/yp directory.
This procedure makes all NIS-enabled, nonprivileged accounts become automatically accessible via NIS, not just newly created ones. It also exports all the user's characteristics stored in the /etc/passwd and /etc/group files, such as the login shell, the user's group, and home directory.
[root@headnode tmp]# useradd -g users nisuser
[root@headnode tmp]# passwd nisuser
Changing password for user nisuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root@headnode tmp]# cd /var/yp
[root@headnode yp]# make
gmake[1]: Entering directory `/var/yp/MY.CLUSTER.COM'
Updating passwd.byname...
Updating passwd.byuid...
Updating netid.byname...
gmake[1]: Leaving directory `/var/yp/MY.CLUSTER.COM'
[root@headnode yp]#
You can check to see if the user's authentication information has been updated by using the ypmatch command, which should return the user's encrypted password string.
[root@headnode yp]# ypmatch nisuser passwd
nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/::504:100::/home/nisuser:/bin/bash
[root@headnode yp]#
Unlike ypmatch, getent doesn't provide an encrypted password when run on an NIS server, it just provides the user's entry in the /etc/passwd file. On a NIS client, the results are identical with both showing the encrypted password.
[root@headnode yp]# getent passwd nisuser
nisuser:x:504:100::/home/nisuser:/bin/bash
[root@headnode yp]#
Configuring The NIS Client
Now that the NIS server is configured, it's time to configure the NIS clients.
Now that the NIS server is configured, it's time to configure the NIS clients.
Run authconfig or authconfig-tui
The authconfig or the authconfig-tui program automatically configures your NIS files after prompting you for the IP address and domain of the NIS server.
[root@cnode tmp]# authconfig-tui
Once finished, it should create an /etc/yp.conf file that defines, amongst other things, the IP address of the NIS server for a particular domain. It also edits the /etc/sysconfig/network file to define the NIS domain to which the NIS client belongs.
# /etc/yp.conf - ypbind configuration file
domain MY.CLUSTER.COM server 192.168.1.100
#/etc/sysconfig/network
NISDOMAIN=MY.CLUSTER.COM
In addition, the authconfig program updates the /etc/nsswitch.conf file that lists the order in which certain data sources should be searched for name lookups, such as those in DNS, LDAP, and NIS. Here you can see where NIS entries were added for the important login files.
#/etc/nsswitch.conf
passwd: files nis
shadow: files nis
group: files nis
Note: You can also locate a sample NIS nsswitch.conf file in the /usr/share/doc/yp-tools* directory.
The authconfig or the authconfig-tui program automatically configures your NIS files after prompting you for the IP address and domain of the NIS server.
[root@cnode tmp]# authconfig-tui
Once finished, it should create an /etc/yp.conf file that defines, amongst other things, the IP address of the NIS server for a particular domain. It also edits the /etc/sysconfig/network file to define the NIS domain to which the NIS client belongs.
# /etc/yp.conf - ypbind configuration file
domain MY.CLUSTER.COM server 192.168.1.100
#/etc/sysconfig/network
NISDOMAIN=MY.CLUSTER.COM
In addition, the authconfig program updates the /etc/nsswitch.conf file that lists the order in which certain data sources should be searched for name lookups, such as those in DNS, LDAP, and NIS. Here you can see where NIS entries were added for the important login files.
#/etc/nsswitch.conf
passwd: files nis
shadow: files nis
group: files nis
Note: You can also locate a sample NIS nsswitch.conf file in the /usr/share/doc/yp-tools* directory.
Start The NIS Client Related Daemons
Start the ypbind NIS client, and portmap daemons in the /etc/init.d directory and use the chkconfig command to ensure they start after the next reboot. Remember to use the rpcinfo command to ensure they are running correctly.
[root@cnode tmp]# service portmap start
Starting portmapper: [ OK ]
[root@cnode tmp]# service ypbind start
Binding to the NIS domain:
Listening for an NIS domain server.
[root@cnode tmp]#
[root@cnode tmp]# chkconfig ypbind on
[root@cnode tmp]# chkconfig portmap on
Note: Remember to use the rpcinfo -p localhost command to make sure they all started correctly.
Start the ypbind NIS client, and portmap daemons in the /etc/init.d directory and use the chkconfig command to ensure they start after the next reboot. Remember to use the rpcinfo command to ensure they are running correctly.
[root@cnode tmp]# service portmap start
Starting portmapper: [ OK ]
[root@cnode tmp]# service ypbind start
Binding to the NIS domain:
Listening for an NIS domain server.
[root@cnode tmp]#
[root@cnode tmp]# chkconfig ypbind on
[root@cnode tmp]# chkconfig portmap on
Note: Remember to use the rpcinfo -p localhost command to make sure they all started correctly.
Verify Name Resolution
As the configuration examples refer to the NIS client and server by their hostnames, you'll have to make sure the names resolve correctly to IP addresses. This can be configured either in DNS, when the hosts reside in the same domain, or more simply by editing the /etc/hosts file on both Linux boxes.
#
# File: /etc/hosts (cnode)
#
192.168.1.100 headnode
#
# File: /etc/hosts (headnode)
#
192.168.1.102 cnode
As the configuration examples refer to the NIS client and server by their hostnames, you'll have to make sure the names resolve correctly to IP addresses. This can be configured either in DNS, when the hosts reside in the same domain, or more simply by editing the /etc/hosts file on both Linux boxes.
#
# File: /etc/hosts (cnode)
#
192.168.1.100 headnode
#
# File: /etc/hosts (headnode)
#
192.168.1.102 cnode
Test NIS Access to the NIS Server
You can run the ypcat, ypmatch, and getent commands to make sure communication to the server is correct.
[root@cnode tmp]# ypcat passwd
nisuser:$1$Cs2GMe6r$1hohkyG7ALrDLjH1:505:100::/home/nisuser:/bin/bash
quotauser:!!:503:100::/home/quotauser:/bin/bash
ftpinstall:$1$8WjAVtes$SnRh9S1w07sYkFNJwpRKa.:502:100::/:/bin/bash
www:$1$DDCi/OPI$hwiTQ.L0XqYJUk09Bw.pJ/:504:100::/home/www:/bin/bash
cnode:$1$qHni9dnR$iKDs7gfyt..BS9Lry3DAq.:501:100::/:/bin/bash
[root@cnode tmp]#
[root@cnode tmp]# ypmatch nisuser passwd
nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/:504:100::/home/nisuser:/bin/bash
[root@cnode tmp]#
[root@cnode tmp]# getent passwd nisuser
nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/:504:100::/home/nisuser:/bin/bash
[root@cnode tmp]#
Possible sources of error would include:
Try to eliminate these areas as sources of error and refer to the syslog /var/log/messages file on the client and server for entries that may provide additional clues.
You can run the ypcat, ypmatch, and getent commands to make sure communication to the server is correct.
[root@cnode tmp]# ypcat passwd
nisuser:$1$Cs2GMe6r$1hohkyG7ALrDLjH1:505:100::/home/nisuser:/bin/bash
quotauser:!!:503:100::/home/quotauser:/bin/bash
ftpinstall:$1$8WjAVtes$SnRh9S1w07sYkFNJwpRKa.:502:100::/:/bin/bash
www:$1$DDCi/OPI$hwiTQ.L0XqYJUk09Bw.pJ/:504:100::/home/www:/bin/bash
cnode:$1$qHni9dnR$iKDs7gfyt..BS9Lry3DAq.:501:100::/:/bin/bash
[root@cnode tmp]#
[root@cnode tmp]# ypmatch nisuser passwd
nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/:504:100::/home/nisuser:/bin/bash
[root@cnode tmp]#
[root@cnode tmp]# getent passwd nisuser
nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/:504:100::/home/nisuser:/bin/bash
[root@cnode tmp]#
Possible sources of error would include:
Try to eliminate these areas as sources of error and refer to the syslog /var/log/messages file on the client and server for entries that may provide additional clues.
Test Logins via the NIS Server
Once your basic NIS functionality testing is complete, try to test a remote login. Failures in this area could be due to firewalls blocking TELNET or SSH access and the TELNET and SSH server process not being started on the clients.
Once your basic NIS functionality testing is complete, try to test a remote login. Failures in this area could be due to firewalls blocking TELNET or SSH access and the TELNET and SSH server process not being started on the clients.
Logging In Via Telnet
Try logging into the NIS client via telnet if it is enabled
[root@headnode tmp]# telnet 192.168.1.201
Trying 192.168.1.201...
Connected to 192.168.1.201.
Escape character is '^]'.
Red Hat Linux release 9 (Shrike)
Kernel 2.4.20-6 on an i686
login: nisuser
Password:
Last login: Sun Nov 16 22:03:51 from 192-168-1-100.MY.CLUSTER.com
[nisuser@cnode nisuser]$
Try logging into the NIS client via telnet if it is enabled
[root@headnode tmp]# telnet 192.168.1.201
Trying 192.168.1.201...
Connected to 192.168.1.201.
Escape character is '^]'.
Red Hat Linux release 9 (Shrike)
Kernel 2.4.20-6 on an i686
login: nisuser
Password:
Last login: Sun Nov 16 22:03:51 from 192-168-1-100.MY.CLUSTER.com
[nisuser@cnode nisuser]$
Logging In Via SSH
Try logging into the NIS client via SSH.
[root@headnode tmp]# ssh -l nisuser 192.168.1.102
nisuser@192.168.1.102's password:
[nisuser@cnode nisuser]$
In some versions of Linux, the NIS client's SSH daemon doesn't re-read the /etc/nsswitch.conf file you just modified until SSH is restarted. SSH logins, therefore, won't query the NIS server until this is done. Restart SSH on the NIS client.
[root@cnode root]# service sshd restart
Stopping sshd:[ OK ]
Starting sshd:[ OK ]
[root@cnode root]#
Try logging into the NIS client via SSH.
[root@headnode tmp]# ssh -l nisuser 192.168.1.102
nisuser@192.168.1.102's password:
[nisuser@cnode nisuser]$
In some versions of Linux, the NIS client's SSH daemon doesn't re-read the /etc/nsswitch.conf file you just modified until SSH is restarted. SSH logins, therefore, won't query the NIS server until this is done. Restart SSH on the NIS client.
[root@cnode root]# service sshd restart
Stopping sshd:[ OK ]
Starting sshd:[ OK ]
[root@cnode root]#
NIS Slave Servers
NIS relies a lot on broadcast traffic to operate, which prevents you from having an NIS server on a different network from the clients. You can avoid this problem on your local subnet by using slave servers that are configured to automatically synchronize their NIS data with that of the single master server.
You can also consider placing multiple NIS servers on a single subnet for the sake of redundancy. To do this, configure the NIS clients to have multiple NIS servers for the domain in the /etc/yp.conf file.
NIS relies a lot on broadcast traffic to operate, which prevents you from having an NIS server on a different network from the clients. You can avoid this problem on your local subnet by using slave servers that are configured to automatically synchronize their NIS data with that of the single master server.
You can also consider placing multiple NIS servers on a single subnet for the sake of redundancy. To do this, configure the NIS clients to have multiple NIS servers for the domain in the /etc/yp.conf file.
Configuring NIS Slave Servers
In this scenario, you need to add an NIS slave server named nisslave (IP address 192.168.1.254) to the MY.CLUSTER.COM NIS domain. You also must configure the NIS master server, headnode, to push its database map information to the slave whenever there is an update. Here are the steps you need.
1. As you're referring to our servers by their hostnames, you'll have to make sure the names resolve correctly to IP addresses. This can be done either in DNS, when the hosts reside in the same domain, or more simply by editing the /etc/hosts files on both servers as seen in Table 30.2.
In this scenario, you need to add an NIS slave server named nisslave (IP address 192.168.1.254) to the MY.CLUSTER.COM NIS domain. You also must configure the NIS master server, headnode, to push its database map information to the slave whenever there is an update. Here are the steps you need.
1. As you're referring to our servers by their hostnames, you'll have to make sure the names resolve correctly to IP addresses. This can be done either in DNS, when the hosts reside in the same domain, or more simply by editing the /etc/hosts files on both servers as seen in Table 30.2.
NIS Master / Slave /etc/hosts Files
Master (Headnode)
Slave (Nisslave)
#
# File: /etc/hosts (Headnode)
#
192.168.1.254 nisslave
#
# File: /etc/hosts (Nisslave)
#
192.168.1.100 headnode
2. Configure the NIS slave as a NIS client of itself in the /etc/yp.conf file, and configure the NIS domain in the /etc/sysconfig/network file as seen in Table 30.3.
Master (Headnode)
|
Slave (Nisslave)
|
#
# File: /etc/hosts (Headnode)
#
192.168.1.254 nisslave
|
#
# File: /etc/hosts (Nisslave)
#
192.168.1.100 headnode
|
2. Configure the NIS slave as a NIS client of itself in the /etc/yp.conf file, and configure the NIS domain in the /etc/sysconfig/network file as seen in Table 30.3.
NIS Master / Slave /etc/yp.conf Files
/etc/yp.conf
/etc/sysconfig/network
#
# File: /etc/yp.conf (Headnode)
#
ypserver 127.0.0.1
#
# File: /etc/sysconfig/network
#
NISDOMAIN="MY.CLUSTER.COM"
3. On the slave server, run ypbind so the slave can query the master server.
[root@nisslave tmp]# service portmap start
Starting portmapper: [ OK ]
[root@nisslave tmp]# service ypbind start
Binding to the NIS domain:
Listening for an NIS domain server.
[root@nisslave tmp]#
[root@nisslave tmp]# chkconfig portmap on
[root@nisslave tmp]# chkconfig ypbind on
4. Optimize database map transfers by the NIS map transfer daemon, which should the started on both the master and slave.
[root@nisslave tmp]# service ypxfrd start
Starting YP map server: [ OK ]
[root@nisslave tmp]#
[root@nisslave tmp]# chkconfig ypxfrd on
[root@headnode tmp]# service ypxfrd start
Starting YP map server: [ OK ]
[root@headnode tmp]#
[root@headnode tmp]# chkconfig ypxfrd on
5. Do a simple database query of the master from the slave using the ypwhich command with the -m (master) switch. You should get a listing of all the tables.
[root@nisslave tmp]# ypwhich -m
mail.aliases headnode
group.bygid headnode
passwd.byuid headnode
rpc.bynumber headnode
...
...
[root@nisslave tmp]#
6. Do an initial database download to the slave from the master with the ypinit command using the -s switch for a slave-type operation and specifying server headnode as the master from which the data is to be obtained. You should see "Trying ypxfrd - success" messages. If the messages say "Trying ypxfrd - not running," then start ypxfrd on both servers.
[root@nisslave tmp]# /usr/lib/yp/ypinit -s headnode
We will need a few minutes to copy the data from headnode.
Transferring services.byservicename...
Trying ypxfrd ... success
Transferring group.byname...
Trying ypxfrd ... success
...
...
nisslave's NIS data base has been set up.
If there were warnings, please figure out what went wrong, and fix it.
At this point, make sure that /etc/passwd and /etc/group have
been edited so that when the NIS is activated, the data bases you
have just created will be used, instead of the /etc ASCII files.
[root@nisslave tmp]#
If your database is corrupt or your /etc/hosts files are incorrect, you'll get map enumeration errors as shown. Use the make command again to rebuild your database on the master when necessary.
[root@nisslave tmp]# /usr/lib/yp/ypinit -s headnode
Can't enumerate maps from headnode. Please check that it is running.
[root@nisslave tmp]#
7. Now that the data has been successfully downloaded, it's time to make the slave server serve NIS clients with ypserv.
[root@nisslave tmp]# service ypserv start
Starting YP server services:
[root@nisslave tmp]#
[root@nisslave tmp]# chkconfig ypxfrd on
8. Log on to the master server. Add the slave server to the master server's database map by editing the /var/yp/ypservers file on the master.
[root@headnode yp]# cd /tmp
[root@headnode tmp]# cd /var/yp/
[root@headnode yp]# vi ypservers
Add nisslave to the file.
#
# File: /var/yp/ypservers
#
headnode
nisslave
9. The make file in the /var/yp directory defines how the NIS server will build the database map and how the master will relate to the NIS slave. Make a copy of the master's make file for safekeeping.
[root@headnode yp]# cp Makefile Makefile.old
10. Edit the make file to allow the master to push maps to the slave.
#
# File: /var/vp/Makefile
#
#
# Allow the master to do database pushes to the slave
#
NOPUSH=false
11. Use the make command to rebuild the database. The make command automatically pushes database updates to the servers listed in the /var/yp/servers file.
[root@headnode yp]# make
gmake[1]: Entering directory `/var/yp/MY.CLUSTER.COM'
Updating ypservers...
YPPUSH: gethostbyname(): Success
YPPUSH: using not FQDN name
gmake[1]: Leaving directory `/var/yp/MY.CLUSTER.COM'
gmake[1]: Entering directory `/var/yp/MY.CLUSTER.COM'
Updating netid.byname...
YPPUSH: gethostbyname(): Success
YPPUSH: using not FQDN name
gmake[1]: Leaving directory `/var/yp/MY.CLUSTER.COM'
[root@headnode yp]#
12. On the slave server, create a cron file in the /etc/crond.d directory, in this case named nis_sync, that will run periodic database downloads from the master server. This helps to ensure that the slave servers have current databases even if they miss updates from the master in the event the cluster goes offline for maintenance. Restart the cron daemon so that the configuration in this file becomes active.
[root@nisslave yp]# vi /etc/cron.d/nis_sync
#
# File: /etc/cron.d/nis_sync
#
20 * * * * /usr/lib/yp/ypxfr_1perhour
40 6 * * * /usr/lib/yp/ypxfr_1perday
55 6,18 * * * /usr/lib/yp/ypxfr_2perday
[root@nisslave yp]# service crond restart
That's a lot of work but it's still not over. There is one final configuration step that needs to be done on the NIS clients before you're finished.
/etc/yp.conf
|
/etc/sysconfig/network
|
#
# File: /etc/yp.conf (Headnode)
#
ypserver 127.0.0.1
|
#
# File: /etc/sysconfig/network
#
NISDOMAIN="MY.CLUSTER.COM"
|
3. On the slave server, run ypbind so the slave can query the master server.
[root@nisslave tmp]# service portmap start
Starting portmapper: [ OK ]
[root@nisslave tmp]# service ypbind start
Binding to the NIS domain:
Listening for an NIS domain server.
[root@nisslave tmp]#
[root@nisslave tmp]# chkconfig portmap on
[root@nisslave tmp]# chkconfig ypbind on
4. Optimize database map transfers by the NIS map transfer daemon, which should the started on both the master and slave.
[root@nisslave tmp]# service ypxfrd start
Starting YP map server: [ OK ]
[root@nisslave tmp]#
[root@nisslave tmp]# chkconfig ypxfrd on
[root@headnode tmp]# service ypxfrd start
Starting YP map server: [ OK ]
[root@headnode tmp]#
[root@headnode tmp]# chkconfig ypxfrd on
5. Do a simple database query of the master from the slave using the ypwhich command with the -m (master) switch. You should get a listing of all the tables.
[root@nisslave tmp]# ypwhich -m
mail.aliases headnode
group.bygid headnode
passwd.byuid headnode
rpc.bynumber headnode
...
...
[root@nisslave tmp]#
6. Do an initial database download to the slave from the master with the ypinit command using the -s switch for a slave-type operation and specifying server headnode as the master from which the data is to be obtained. You should see "Trying ypxfrd - success" messages. If the messages say "Trying ypxfrd - not running," then start ypxfrd on both servers.
[root@nisslave tmp]# /usr/lib/yp/ypinit -s headnode
We will need a few minutes to copy the data from headnode.
Transferring services.byservicename...
Trying ypxfrd ... success
Transferring group.byname...
Trying ypxfrd ... success
...
...
nisslave's NIS data base has been set up.
If there were warnings, please figure out what went wrong, and fix it.
At this point, make sure that /etc/passwd and /etc/group have
been edited so that when the NIS is activated, the data bases you
have just created will be used, instead of the /etc ASCII files.
[root@nisslave tmp]#
If your database is corrupt or your /etc/hosts files are incorrect, you'll get map enumeration errors as shown. Use the make command again to rebuild your database on the master when necessary.
[root@nisslave tmp]# /usr/lib/yp/ypinit -s headnode
Can't enumerate maps from headnode. Please check that it is running.
[root@nisslave tmp]#
7. Now that the data has been successfully downloaded, it's time to make the slave server serve NIS clients with ypserv.
[root@nisslave tmp]# service ypserv start
Starting YP server services:
[root@nisslave tmp]#
[root@nisslave tmp]# chkconfig ypxfrd on
8. Log on to the master server. Add the slave server to the master server's database map by editing the /var/yp/ypservers file on the master.
[root@headnode yp]# cd /tmp
[root@headnode tmp]# cd /var/yp/
[root@headnode yp]# vi ypservers
Add nisslave to the file.
#
# File: /var/yp/ypservers
#
headnode
nisslave
9. The make file in the /var/yp directory defines how the NIS server will build the database map and how the master will relate to the NIS slave. Make a copy of the master's make file for safekeeping.
[root@headnode yp]# cp Makefile Makefile.old
10. Edit the make file to allow the master to push maps to the slave.
#
# File: /var/vp/Makefile
#
#
# Allow the master to do database pushes to the slave
#
NOPUSH=false
11. Use the make command to rebuild the database. The make command automatically pushes database updates to the servers listed in the /var/yp/servers file.
[root@headnode yp]# make
gmake[1]: Entering directory `/var/yp/MY.CLUSTER.COM'
Updating ypservers...
YPPUSH: gethostbyname(): Success
YPPUSH: using not FQDN name
gmake[1]: Leaving directory `/var/yp/MY.CLUSTER.COM'
gmake[1]: Entering directory `/var/yp/MY.CLUSTER.COM'
Updating netid.byname...
YPPUSH: gethostbyname(): Success
YPPUSH: using not FQDN name
gmake[1]: Leaving directory `/var/yp/MY.CLUSTER.COM'
[root@headnode yp]#
12. On the slave server, create a cron file in the /etc/crond.d directory, in this case named nis_sync, that will run periodic database downloads from the master server. This helps to ensure that the slave servers have current databases even if they miss updates from the master in the event the cluster goes offline for maintenance. Restart the cron daemon so that the configuration in this file becomes active.
[root@nisslave yp]# vi /etc/cron.d/nis_sync
#
# File: /etc/cron.d/nis_sync
#
20 * * * * /usr/lib/yp/ypxfr_1perhour
40 6 * * * /usr/lib/yp/ypxfr_1perday
55 6,18 * * * /usr/lib/yp/ypxfr_2perday
[root@nisslave yp]# service crond restart
That's a lot of work but it's still not over. There is one final configuration step that needs to be done on the NIS clients before you're finished.
Configuring NIS Clients with Slaves
Edit the /etc/yp.conf file on all the clients to include nisslave, and restart ypbind.
#
# File: /etc/yp.conf (Cnode)
#
domain MY.CLUSTER.COM server 192.168.1.100
domain MY.CLUSTER.COM server 192.168.1.254
[root@cnode tmp]# service ypbind restart
Shutting down NIS services: [ OK ]
Binding to the NIS domain: [ OK ]
Listening for an NIS domain server..
[root@cnode tmp]#
Edit the /etc/yp.conf file on all the clients to include nisslave, and restart ypbind.
#
# File: /etc/yp.conf (Cnode)
#
domain MY.CLUSTER.COM server 192.168.1.100
domain MY.CLUSTER.COM server 192.168.1.254
[root@cnode tmp]# service ypbind restart
Shutting down NIS services: [ OK ]
Binding to the NIS domain: [ OK ]
Listening for an NIS domain server..
[root@cnode tmp]#
Changing Your NIS Passwords
You should also test to make sure your users can change their NIS passwords from the NIS clients with the yppasswd command. The process is different whether there is only a single NIS master or a master-slave server relationship.
You should also test to make sure your users can change their NIS passwords from the NIS clients with the yppasswd command. The process is different whether there is only a single NIS master or a master-slave server relationship.
When There Is Only an NIS Master
When there is only a single NIS server, password changes can be made only on the NIS server using the yppasswd command.
When there is only a single NIS server, password changes can be made only on the NIS server using the yppasswd command.
Users Changing Their Own Passwords
Users can change their passwords by logging into the NIS server and issuing the yppasswd command.
[nisuser@headnode nisuser]$ yppasswd
Changing NIS account information for nisuser on headnode.my-site.com.
Please enter old password:
Changing NIS password for nisuser on headnode.my-site.com.
Please enter new password:
Please retype new password:
The NIS password has been changed on headnode.my-site.com.
[nisuser@headnode nisuser]$
Users can change their passwords by logging into the NIS server and issuing the yppasswd command.
[nisuser@headnode nisuser]$ yppasswd
Changing NIS account information for nisuser on headnode.my-site.com.
Please enter old password:
Changing NIS password for nisuser on headnode.my-site.com.
Please enter new password:
Please retype new password:
The NIS password has been changed on headnode.my-site.com.
[nisuser@headnode nisuser]$
User "Root" Changing Passwords
The root user can change other users' passwords issuing the yppasswd command with the -p switch that specifies the username that needs the change.
[root@headnode tmp]# yppasswd -p nisuser
Changing NIS account information for nisuser on headnode.my-site.com.
Please enter root password:
Changing NIS password for nisuser on headnode.my-site.com.
Please enter new password:
Please retype new password:
The NIS password has been changed on headnode.my-site.com.
[root@headnode tmp]#
The root user can change other users' passwords issuing the yppasswd command with the -p switch that specifies the username that needs the change.
[root@headnode tmp]# yppasswd -p nisuser
Changing NIS account information for nisuser on headnode.my-site.com.
Please enter root password:
Changing NIS password for nisuser on headnode.my-site.com.
Please enter new password:
Please retype new password:
The NIS password has been changed on headnode.my-site.com.
[root@headnode tmp]#
When There Is A NIS Master / Slave Pair
With an NIS master and slave pair configuration, passwords can be changed on the NIS clients or the NIS slave, but not on the NIS master.
With an NIS master and slave pair configuration, passwords can be changed on the NIS clients or the NIS slave, but not on the NIS master.
Possible Password Errors
There are a number of unexpected errors you may find when changing passwords - errors that have nothing to do with bad typing.
There are a number of unexpected errors you may find when changing passwords - errors that have nothing to do with bad typing.
Segmentation Faults
Running the yppasswd command on the wrong client or server depending on your NIS master and slave configuration can cause segmentation fault errors. Here are some sample password change failures on an NIS client with only one NIS master server.
[nisuser@cnode nisuser]$ yppasswd
Segmentation fault
[nisuser@cnode nisuser]$
[root@cnode root]# yppasswd -p nisuser
Segmentation fault
[root@cnode root]#
Running the yppasswd command on the wrong client or server depending on your NIS master and slave configuration can cause segmentation fault errors. Here are some sample password change failures on an NIS client with only one NIS master server.
[nisuser@cnode nisuser]$ yppasswd
Segmentation fault
[nisuser@cnode nisuser]$
[root@cnode root]# yppasswd -p nisuser
Segmentation fault
[root@cnode root]#
Daemon Errors
The yppasswdd daemon must be running on both the client and server for password changes to work correctly. When they aren't running, you'll get errors.
[root@cnode etc]# yppasswd -p nisuser
yppasswd: yppasswdd not running on NIS master host ("headnode").
[root@cnode etc]#
You'll also get a similar error if you attempt to change an NIS password on an NIS master server in a master and slave configuration.
The yppasswdd daemon must be running on both the client and server for password changes to work correctly. When they aren't running, you'll get errors.
[root@cnode etc]# yppasswd -p nisuser
yppasswd: yppasswdd not running on NIS master host ("headnode").
[root@cnode etc]#
You'll also get a similar error if you attempt to change an NIS password on an NIS master server in a master and slave configuration.
Considerations for A Non NFS Environment
In many cases NFS, isn't used to create a centralized home directory for users and, therefore, you'll have to create it on each NIS client and not on the server.
This example creates the home directory for the NIS client, cnode. After doing this, you have to copy a BASH login profile file into it and modify the ownership of the directory and all the files to user nisuser.
Logins should proceed normally once this has been done and all the other steps have been followed.
[root@cnode tmp]# mkdir /home/nisuser
[root@cnode tmp]# chmod 700 /home/nisuser/
[root@cnode tmp]# ll /home
total 2
drwx------ 2 nisuser users 1024 Aug 4 08:05 nisuser
[root@cnode tmp]#
[root@cnode tmp]# cp /etc/skel/.* /home/nisuser/
cp: omitting directory `/etc/skel/.'
cp: omitting directory `/etc/skel/..'
cp: omitting directory `/etc/skel/.kde'
[root@cnode tmp]# chown -R nisuser:users /home/nisuser
[root@cnode tmp]#
In many cases NFS, isn't used to create a centralized home directory for users and, therefore, you'll have to create it on each NIS client and not on the server.
This example creates the home directory for the NIS client, cnode. After doing this, you have to copy a BASH login profile file into it and modify the ownership of the directory and all the files to user nisuser.
Logins should proceed normally once this has been done and all the other steps have been followed.
[root@cnode tmp]# mkdir /home/nisuser
[root@cnode tmp]# chmod 700 /home/nisuser/
[root@cnode tmp]# ll /home
total 2
drwx------ 2 nisuser users 1024 Aug 4 08:05 nisuser
[root@cnode tmp]#
[root@cnode tmp]# cp /etc/skel/.* /home/nisuser/
cp: omitting directory `/etc/skel/.'
cp: omitting directory `/etc/skel/..'
cp: omitting directory `/etc/skel/.kde'
[root@cnode tmp]# chown -R nisuser:users /home/nisuser
[root@cnode tmp]#
NIS Troubleshooting
Troubleshooting is always required as any part of your daily routine, NIS is no exception. Here are some simple steps to follow to get it working again.
1. The rpcinfo provides a list of TCP ports that your NIS client or server is using. Make sure you can TELNET to these ports from the client to the server and vice versa. If this fails, make sure all the correct NIS daemons are running and that there are no firewalls blocking traffic on the network or on the servers themselves. These ports change from time to time, so memorizing them won't help much.
The example tests from the client to the server.
[root@headnode tmp]# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32768 status
391002 2 tcp 32769 sgi_fam
100009 1 udp 1018 yppasswdd
100004 2 udp 611 ypserv
100004 1 udp 611 ypserv
100004 2 tcp 614 ypserv
100004 1 tcp 614 ypserv
100007 2 udp 855 ypbind
100007 1 udp 855 ypbind
100007 2 tcp 858 ypbind
100007 1 tcp 858 ypbind
600100069 1 udp 874 fypxfrd
600100069 1 tcp 876 fypxfrd
[root@headnode tmp]#
[root@cnode tmp]# telnet 192.168.1.100 858
Trying 10.41.32.71...
Connected to 10.41.32.71.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
[root@cnode tmp]#
2. Always use the ypmatch, getent, and ypwhich commands to check your NIS connectivity. If there is any failure, check your steps over again and you should be able to find the source of your problem.
3. Do not fail to create a user's home directory, set its permissions, and copy the /etc/skel files correctly. If you forget, which is a common error, your users may have incorrect login prompts and no ability to create files in their home directories.
It can never be overemphasized that one of the best places to start troubleshooting is by looking in your error log files in the /var/log directory.
SSH is often used to login from one system to another without requiring passwords. This is required in cluster environment in order to perform communications (message passing) at the time of production (running a job on cluster) with out asking the user for authentication.
ssh-keygen is used to generate the public key pair for you. Here is a session where your own personal private/public key pair is created:
Note : The signature algorithm can be rsa or dsa.
Before doing login as NIS user and do the following.
root@hnode:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/clusteruser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/clusteruser/.ssh/id_rsa.
Your public key has been saved in /home/clusteruser/.ssh/id_rsa.pub.
The key fingerprint is:
f6:61:a8:27:35:cf:4c:6d:13:22:70:cf:4c:c8:a0:23 clusteruser@hnode
The command ssh-keygen -t rsa initiated the creation of the key pair.
No passphrase was entered (Enter key was pressed instead).
The private key was saved in .ssh/id_rsa. This file is read-only and only for you. The public key is save in .
ssh/id_rsa.pub.
In this case, the content of file id_rsa.pub is
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEArkwv9X8eTVK4F7pMlSt45pWoiakFkZMw
G9BjydOJPGH0RFNAy1QqIWBGWv7vS5K2tr+EEO+F8WL2Y /jK4ZkUoQgoi+n7DWQVOHsRijcS3LvtO+50Np4yjXYWJKh29JL6GHcp8o7+ YKEyVUMB2CSDOP99eF9g5Q0d+1U2WVdBWQM= clusteruser@hnode
It is one line in length.
Its content is then copied in file .ssh/authorized_keys of the system you wish to SSH to without being prompted for a password.
The example shown here generated keys on hnode by user clusteruser. If the public key generated, file .ssh/id_rsa.pub, was copied to your account, file .ssh/authorized_keys on nickel.sao.nrc.ca, then user clusteruser@hnode is allowed to SSH into your own account on nickel.sao.nrc.ca without the use of a password.
To summarize, a personal private/public key pair is generated using the ssh-keygen command. The public key is then copied onto a remote systems' .ssh/authorized_keys file. And you can now SSH to the remote systems's account without the use of a password.
Troubleshooting is always required as any part of your daily routine, NIS is no exception. Here are some simple steps to follow to get it working again.
1. The rpcinfo provides a list of TCP ports that your NIS client or server is using. Make sure you can TELNET to these ports from the client to the server and vice versa. If this fails, make sure all the correct NIS daemons are running and that there are no firewalls blocking traffic on the network or on the servers themselves. These ports change from time to time, so memorizing them won't help much.
The example tests from the client to the server.
[root@headnode tmp]# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32768 status
100024 1 tcp 32768 status
391002 2 tcp 32769 sgi_fam
100009 1 udp 1018 yppasswdd
100004 2 udp 611 ypserv
100004 1 udp 611 ypserv
100004 2 tcp 614 ypserv
100004 1 tcp 614 ypserv
100007 2 udp 855 ypbind
100007 1 udp 855 ypbind
100007 2 tcp 858 ypbind
100007 1 tcp 858 ypbind
600100069 1 udp 874 fypxfrd
600100069 1 tcp 876 fypxfrd
[root@headnode tmp]#
[root@cnode tmp]# telnet 192.168.1.100 858
Trying 10.41.32.71...
Connected to 10.41.32.71.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
[root@cnode tmp]#
2. Always use the ypmatch, getent, and ypwhich commands to check your NIS connectivity. If there is any failure, check your steps over again and you should be able to find the source of your problem.
3. Do not fail to create a user's home directory, set its permissions, and copy the /etc/skel files correctly. If you forget, which is a common error, your users may have incorrect login prompts and no ability to create files in their home directories.
It can never be overemphasized that one of the best places to start troubleshooting is by looking in your error log files in the /var/log directory.
SSH is often used to login from one system to another without requiring passwords. This is required in cluster environment in order to perform communications (message passing) at the time of production (running a job on cluster) with out asking the user for authentication.
ssh-keygen is used to generate the public key pair for you. Here is a session where your own personal private/public key pair is created:
Note : The signature algorithm can be rsa or dsa.
Before doing login as NIS user and do the following.
root@hnode:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/clusteruser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/clusteruser/.ssh/id_rsa.
Your public key has been saved in /home/clusteruser/.ssh/id_rsa.pub.
The key fingerprint is:
f6:61:a8:27:35:cf:4c:6d:13:22:70:cf:4c:c8:a0:23 clusteruser@hnode
The command ssh-keygen -t rsa initiated the creation of the key pair.
No passphrase was entered (Enter key was pressed instead).
The private key was saved in .ssh/id_rsa. This file is read-only and only for you. The public key is save in .
ssh/id_rsa.pub.
In this case, the content of file id_rsa.pub is
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEArkwv9X8eTVK4F7pMlSt45pWoiakFkZMw
G9BjydOJPGH0RFNAy1QqIWBGWv7vS5K2tr+EEO+F8WL2Y /jK4ZkUoQgoi+n7DWQVOHsRijcS3LvtO+50Np4yjXYWJKh29JL6GHcp8o7+ YKEyVUMB2CSDOP99eF9g5Q0d+1U2WVdBWQM= clusteruser@hnode
It is one line in length.
Its content is then copied in file .ssh/authorized_keys of the system you wish to SSH to without being prompted for a password.
The example shown here generated keys on hnode by user clusteruser. If the public key generated, file .ssh/id_rsa.pub, was copied to your account, file .ssh/authorized_keys on nickel.sao.nrc.ca, then user clusteruser@hnode is allowed to SSH into your own account on nickel.sao.nrc.ca without the use of a password.
To summarize, a personal private/public key pair is generated using the ssh-keygen command. The public key is then copied onto a remote systems' .ssh/authorized_keys file. And you can now SSH to the remote systems's account without the use of a password.
MPI
Step Install Compilers and other development tools (If not installed earlier).
If C compliers and developments tools are not installed, install them before proceeding further using rpm.
Install Message Passing Interface Library (Open MPI or MPICH).
What is OpenMPI
The Message Passing Interface Standard (MPI) is a message passing library standard based on the consensus of the MPI Forum, which has over 40 participating organizations, including vendors, researchers, software library developers, and users. The goal of the Message Passing Interface is to establish a portable, efficient, and flexible standard for message passing that will be widely used for writing message passing programs.The advantages of developing message passing software using MPI closely match the design goals of portability, efficiency, and flexibility. MPI is not an IEEE or ISO standard, but has in fact, become the "industry standard" for writing message passing programs on HPC platforms.
The Open MPI Project is an open source MPI-2 implementation that is developed and maintained by a consortium of academic, research, and industry partners. Open MPI is therefore able to combine the expertise, technologies, and resources from all across the High Performance Computing community in order to build the best MPI library available. Open MPI offers advantages for system and software vendors, application developers and computer science researchers.
Features implemented or in short-term development for Open MPI include:
Download openmpi from the following link:
An Interface Specification:
History and Evolution:
Reasons for Using MPI:
Programming Model:
More resources are at : https://computing.llnl.gov/tutorials/mpi/
How to Install
Building Open MPI is typically a combination of running "configure"
and "make". Execute the following commands to install the Open MPI
system from within the directory at the top of the tree:
shell$ ./configure --prefix=/where/to/install
[...lots of output...]
shell$ make all install
If you need special access to install, then you can execute "make
all" as a user with write permissions in the build tree, and a
separate "make install" as a user with write permissions to the
install tree.
Compiling support for various networks or other specific hardware may
require additional command ling flags when running configure. See the
README file for more details. Note that VPATH builds are fully
supported. For example:
shell$ gtar zxf openmpi-X.Y.Z.tar.gz
shell$ cd openmpi-X.Y.Z
shell$ mkdir build
shell$ cd build
shell$ ../configure ...your options...
[...lots of output...]
shell$ make all install
Parallel builds are also supported (although some versions of "make",
such as GNU make, will only use the first target listed on the command
line when executable parallel builds). For example (assume GNU make):
shell$ make -j 4 all
[...lots of output...]
shell$ make install
Parallel make is generally only helpful in the build phase; the
installation process is mostly serial and does not benefit much from
parallel make.
Compiling MPI Applications
MPI applications should be compiled using the Open MPI "wrapper"
compilers:
C programs: mpicc your-code.c
C++ programs: mpiCC your-code.cc or
mpic++ your-code.cc (for case-insensitive filesystems)
F77 programs: mpif77 your-code.f
F90 programs: mpif90 your-code.f90
These compilers simply add various command line flags (such as -lmpi)
and invoke a back-end compiler; they are not compilers in themselves.
Update PATH environment variable and add PATH_TO_LIBRARY variable.
Create hosts file.
Write a sample Hello world Parallel program and test cluster setup.
/*
* Sample MPI "hello world" application in C
*/
#include <stdio.h>
#include "mpi.h"
int main(int argc, char* argv[])
{
int rank, size;
MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &size);
printf("Hello, world, I am %d of %d\n", rank, size);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();
return 0;
}
Write parallel programs and analyze performance.
Conclusion
References
http://www.linuxclusters.com/ [Information on configuring Linux clusters]
en.wikipedia.org/wiki/Cluster_(computing) [Information about what is cluster Computing]
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch06_:_Installing_Linux_Software[ Information on How to Install Linux Software ]
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch25_:_Network-Based_Linux_Installation [ Network based Installation on Linux how?]
http://www.redhat.com/docs/manuals/csgfs/browse/4.6/Cluster_Administration/s2-hw-setup-CA.html [ Redhat official site on RHE Linux Installation and Administration ]
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.2720 [ Info on parallel computing ]
https://computing.llnl.gov/tutorials/mpi/ [ About OpenMPI]
Step Install Compilers and other development tools (If not installed earlier).
If C compliers and developments tools are not installed, install them before proceeding further using rpm.
Install Message Passing Interface Library (Open MPI or MPICH).
What is OpenMPI
The Message Passing Interface Standard (MPI) is a message passing library standard based on the consensus of the MPI Forum, which has over 40 participating organizations, including vendors, researchers, software library developers, and users. The goal of the Message Passing Interface is to establish a portable, efficient, and flexible standard for message passing that will be widely used for writing message passing programs.The advantages of developing message passing software using MPI closely match the design goals of portability, efficiency, and flexibility. MPI is not an IEEE or ISO standard, but has in fact, become the "industry standard" for writing message passing programs on HPC platforms.
The Open MPI Project is an open source MPI-2 implementation that is developed and maintained by a consortium of academic, research, and industry partners. Open MPI is therefore able to combine the expertise, technologies, and resources from all across the High Performance Computing community in order to build the best MPI library available. Open MPI offers advantages for system and software vendors, application developers and computer science researchers.
Features implemented or in short-term development for Open MPI include:
Download openmpi from the following link:
An Interface Specification:
History and Evolution:
Reasons for Using MPI:
Programming Model:
More resources are at : https://computing.llnl.gov/tutorials/mpi/
How to Install
Building Open MPI is typically a combination of running "configure"
and "make". Execute the following commands to install the Open MPI
system from within the directory at the top of the tree:
shell$ ./configure --prefix=/where/to/install
[...lots of output...]
shell$ make all install
If you need special access to install, then you can execute "make
all" as a user with write permissions in the build tree, and a
separate "make install" as a user with write permissions to the
install tree.
Compiling support for various networks or other specific hardware may
require additional command ling flags when running configure. See the
README file for more details. Note that VPATH builds are fully
supported. For example:
shell$ gtar zxf openmpi-X.Y.Z.tar.gz
shell$ cd openmpi-X.Y.Z
shell$ mkdir build
shell$ cd build
shell$ ../configure ...your options...
[...lots of output...]
shell$ make all install
Parallel builds are also supported (although some versions of "make",
such as GNU make, will only use the first target listed on the command
line when executable parallel builds). For example (assume GNU make):
shell$ make -j 4 all
[...lots of output...]
shell$ make install
Parallel make is generally only helpful in the build phase; the
installation process is mostly serial and does not benefit much from
parallel make.
Compiling MPI Applications
MPI applications should be compiled using the Open MPI "wrapper"
compilers:
C programs: mpicc your-code.c
C++ programs: mpiCC your-code.cc or
mpic++ your-code.cc (for case-insensitive filesystems)
F77 programs: mpif77 your-code.f
F90 programs: mpif90 your-code.f90
These compilers simply add various command line flags (such as -lmpi)
and invoke a back-end compiler; they are not compilers in themselves.
Update PATH environment variable and add PATH_TO_LIBRARY variable.
Create hosts file.
Write a sample Hello world Parallel program and test cluster setup.
/*
* Sample MPI "hello world" application in C
*/
#include <stdio.h>
#include "mpi.h"
int main(int argc, char* argv[])
{
int rank, size;
MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &size);
printf("Hello, world, I am %d of %d\n", rank, size);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();
return 0;
}
Write parallel programs and analyze performance.
Conclusion
References
http://www.linuxclusters.com/ [Information on configuring Linux clusters]
en.wikipedia.org/wiki/Cluster_(computing) [Information about what is cluster Computing]
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch06_:_Installing_Linux_Software[ Information on How to Install Linux Software ]
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch25_:_Network-Based_Linux_Installation [ Network based Installation on Linux how?]
http://www.redhat.com/docs/manuals/csgfs/browse/4.6/Cluster_Administration/s2-hw-setup-CA.html [ Redhat official site on RHE Linux Installation and Administration ]
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.2720 [ Info on parallel computing ]
https://computing.llnl.gov/tutorials/mpi/ [ About OpenMPI]
No comments:
Post a Comment