![]() |
|||
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
| ||
CellsYou can set up the grid engine system as a single cluster or as a collection of loosely coupled clusters called cells. The SGE_CELL environment variable indicates the cluster being referenced. When the grid engine system is installed as a single cluster, $SGE_CELL is not set, and the value default is assumed for the cell value. User NamesIn order for the grid engine system to verify that users submitting jobs have permission to submit them on the desired execution hosts, users' names must be identical on the submit and execution hosts involved. You may therefore have to change user names on some machines, because grid engine system users map directly to system user accounts. Note - User names on the master host are not relevant for permission checking. These user names do not have to match or even exist. Installation AccountsYou can install the grid engine software either as the root user or as an unprivileged user (for example, your own user account). However, if you install the software logged in as an unprivileged user, the installation allows only that user to run grid engine system jobs. Access is denied to all other accounts. Installing the software logged in as the root account resolves this restriction. However, root permission is required for the complete installation procedure. Also, if you install as an unprivileged user, you are not allowed to use the qrsh, qtcsh, qmake commands, nor can you run tightly integrated parallel jobs. Note - If you decide to install grid engine as an unprivileged user, you must set the sge_commd port number higher than or equal to 1024. File Access PermissionsIf you install the software logged in as root, you might have a problem configuring root read/write access for all hosts on a shared file system. Therefore, you might have problems putting sge-root onto a network-wide file system. You can force grid engine software to run all grid engine system components through a non-root administrative user account (called sgeadmin, for example). With this setup, you need only read/write access to the shared sge-root file system for this particular user. The installation procedure asks whether files should be created and owned by an administrative user account. If you answer "Yes" and provide a valid user name, files are created by this user. Otherwise, the user name under which you run the installation procedure is used. It is recommended that you create an administrative user, and answer " Yes" to this question. Make sure in all cases that the account used for file handling on all hosts has read/write access to the sge-root directory. Also, the installation procedure assumes that the host from which you access the grid engine software distribution media can write to the sge-root directory. Note - The name of the root user on Windows hosts depends on the system language of the Windows operating system. It is even possible to change the name of the root user. The default name for many languages is the name Administrator. Network ServicesDetermine whether your site's network services are defined in an NIS database or in an /etc/services file that is local to each workstation. If your site uses NIS, find out the host name of your NIS server is so that you can add entries to the NIS "services" map. The grid engine system services are sge_execd and sge_qmaster. To add the services to your NIS map, choose reserved, unused port numbers. The following examples show sge_qmaster and sge_execd entries.
Master HostThe master host controls the grid engine system. This host runs the master daemon sge_qmaster, and the scheduling daemon, sge_schedd. The master host must comply with the following requirements:
Note - Windows hosts cannot act as master hosts. Shadow Master HostsThese hosts back up the functionality of sge_qmaster in case the master host or the master daemon fails. To be a shadow master host, a machine must have the following characteristics:
Note - If no cell name is specified during installation, the value of cell is default. The shadow master host facility is activated for a host as soon as these conditions are met. You do not need to restart the grid engine system daemons to make a host into a shadow master host. Note - Windows hosts cannot act as master hosts. Spool Directories Under the Root DirectoryDuring the installation of the master host, you must specify the location of a spooling directory. This directory is used to spool jobs from execution hosts that do not have a local spooling directory.
Note - If no cell name is specified during installation, the value of cell is default. You do not need to export these directories to other machines. However, exporting the entire sge-root tree and making it write-accessible for the master host and all executable hosts makes administration easier. Choosing Between Classic Spooling and Database SpoolingDuring the installation, you are given the option to choose between classic spooling and Berkeley DB spooling server. If you choose Berkeley DB spooling, you are then given the option to spool to a local directory or to a separate host, known as a Berkeley DB spooling server. While classic spooling is an option, you should see better performance using a Berkeley DB spooling server. Part of this performance increase is because the master host can make non-blocking writes to the database, but has to make blocking writes to the text file used by classic spooling. Other factors that may influence your decision are file format and data integrity. There is a greater level of data integrity when you write to the Berkeley DB, rather than to a text file. However, a text file stores data in a format that humans can read and edit. Normally, you do not need to read these files, but the spooling directory contains the messages from the system daemons, which can be useful during debugging. Database Server and Spooling HostThe master host can store its configuration and state to a Berkeley DB spooling database. The spooling database can be installed on the master server or on a separate host. When the Berkeley DB spools into a local directory on the master host, the performance is better, but if you want to set up a shadow master host, you need to use a separate Berkeley DB spooling server (host). In this case, you have to choose a host with a configured RPC service. The master host connects through RPC to the Berkeley DB. Note - Using a shadow master host is more reliable, but using a separate Berkeley DB spooling host results in a potential security hole. RPC communication as used by the Berkeley DB can be easily compromised. Only use this alternative if your site is secure and if users can be trusted to access the Berkeley DB spooling host by means of TCP/IP communication. If you choose to use Berkeley DB spooling without a shadow master, you don't need to set up a separate spooling server. Likewise, if you choose not to use Berkeley DB spooling, you can set up a shadow master host without setting up a separate spooling server. Once you determine whether you need a separate spooling server, you will also need to determine the location for the spooling directory. The spooling directory must be local to the spooling server. A default value for the location of the spooling directory is recommended during installation but this default value is not suitable when the file server is different from the master host. The requirements for the Berkeley DB spooling host are similar to the requirements for the master host:
| ||
| ||
![]() |