host_conf

HOST_CONF(5)      Grid Engine Enterprise Edition File Formats     HOST_CONF(5)



NAME
       host_conf - Grid Engine Enterprise Edition execution host configuration
       file format

DESCRIPTION
       Host_conf reflects the format of the template file for the execution
       host configuration.  Via the -ae and -me options of the qconf(1)
       command, you can add execution hosts and modify the configuration of
       any execution host in the cluster. Default execution host entries are
       added automatically as soon as a sge_execd(8) registers to
       sge_qmaster(8) for the very first time from a certain host. The
       qconf(1) -sel switch can be used to display a list of execution host
       being currently configured in your Grid Engine Enterprise Edition
       system. Via the -se option you can print the execution host
       configuration of a specified host.

       The special hostname "global" can be used to define cluster global
       characteristics.

FORMAT
       The format of a host_conf file is defined as follows:

       hostname
              The name of the execution host.

       load_scaling
              A comma separated list of scaling values to be applied to each
              or part of the load values being reported by the sge_execd(8) on
              the host and being defined in the cluster global "host" complex
              (see complex(5)).  The load scaling factors are intended to
              level hardware or operating system specific differences between
              execution hosts. If, for example, the load average value
              (load_avg in the "host" complex; see also uptime(1)) of a
              multiprocessor machine is to be compared with a single processor
              machine the load as reported by the single CPU host needs to be
              weighted up against the multiprocessor load (given the same CPU
              hardware) to be comparable. The load scaling factors are
              integers being multiplied with the reported load quantities to
              constitute weighted load values. Thus, following the example
              given above, the load value of the single processor machine
              needs to be multiplied by the number of processors of the single
              processor machine to become comparable.

              The syntax of a load factor specification is as follows: First
              the name of the load value (as defined in the "host" complex) is
              given and, separated by an equal sign, the load scaling value is
              provided. No blanks are allowed in between the load_scaling
              value string.

              The parameter load_scaling is not meaningful for the definition
              of the "global" host.

       complex_list
              The comma separated list of administrator defined complexes (see
              complex(5) for details) to be associated with the host. Only
              complex attributes contained in the enlisted complexes and those
              from the "global" and "host" complex, which are implicitly
              attached to each host, can be used in the complex_values list
              below. In case of the "global" host, the "host" complex is not
              attached and only "global" complex attributes are allowed per
              default in the complex_values list of the "global" host.

              The default value for this parameter is NONE, i.e. no
              administrator defined complexes are associated with the host.

       complex_values
              complex_values defines quotas for resource attributes managed
              via this host. Each complex attribute is followed by an "=" sign
              and the value specification compliant with the complex attribute
              type (see complex(5)).  Quota specifications are separated by
              commas. Only attributes as defined in complex_list (see above)
              may be used.

              The quotas are related to the resource consumption of all jobs
              on a host in the case of consumable resources (see complex(5)
              for details on consumable resources) or they are interpreted on
              a per job slot basis in the case of non-consumable resources.
              Consumable resource attributes are commonly used to manage free
              memory, free disk space or available floating software licenses
              while non-consumable attributes usually define distinctive
              characteristics like type of hardware installed.

              For consumable resource attributes an available resource amount
              is determined by subtracting the current resource consumption of
              all running jobs on the host from the quota in the
              complex_values list. Jobs can only be dispatched to a host if no
              resource requests exceed any corresponding resource availability
              obtained by this scheme. The quota definition in the
              complex_values list is automatically replaced by the current
              load value reported for this attribute, if load is monitored for
              this resource and if the reported load value is more stringent
              than the quota. This effectively avoids oversubscription of
              resources.

              Note: Load values replacing the quota specifications may have
              become more stringent because they have been scaled (see
              load_scaling above) and/or load adjusted (see sched_conf(5)).
              The -F option of qstat(1) and the load display in the qmon(1)
              queue control dialog (activated by clicking on a queue icon
              while the "Shift" key is pressed) provide detailed information
              on the actual availability of consumable resources and on the
              origin of the values taken into account currently.

              Note also: The resource consumption of running jobs (used for
              the availability calculation) as well as the resource requests
              of the jobs waiting to be dispatched either may be derived from
              explicit user requests during job submission (see the -l option
              to qsub(1)) or from a "default" value configured for an
              attribute by the administrator (see complex(5)).  The -r option
              to qstat(1) can be used for retrieving full detail on the actual
              resource requests of all jobs in the system.

              For non-consumable resources Grid Engine Enterprise Edition
              simply compares the job's attribute requests with the
              corresponding specification in complex_values taking the
              relation operator of the complex attribute definition into
              account (see complex(5)).  If the result of the comparison is
              "true", the host is suitable for the job with respect to the
              particular attribute. For parallel jobs each job slot to be
              occupied by a parallel task is meant to provide the same
              resource attribute value.

              Note: Only numeric complex attributes can be defined as
              consumable resources and hence non-numeric attributes are always
              handled on a per job slot basis.

              The default value for this parameter is NONE, i.e. no
              administrator defined resource attribute quotas are associated
              with the host.

       load_values
              This entry cannot be configured but is only displayed in case of
              a qconf(1) -se command. All load values are displayed as
              reported by the sge_execd(8) on the host. The load values are
              enlisted in a comma separated list. Each load value start with
              its name, followed by an equal sign and the reported value.

       processors
              This entry cannot be configured but is only displayed in case of
              a qconf(1) -se command. Its value is the number of processors
              which has been detected by sge_execd(8) on the corresponding
              host.

       usage_scaling
              This entry is only present in a Grid Engine Enterprise Edition
              system. It is not available in Grid Engine.

              The format is equivalent to load_scaling (see above), the only
              valid attributes to be scaled however are cpu for CPU time
              consumption, mem for Memory consumption aggregated over the
              life-time of jobs and io for data transferred via any I/O
              devices. The default NONE means "no scaling", i.e. all scaling
              factors are 1.

       resource_capability_factor
              This entry is only present in a Grid Engine Enterprise Edition
              system. It is not available in Grid Engine.

              The resource capability factor is used by Grid Engine Enterprise
              Edition when assigning jobs to execution hosts. The resource
              capability factor tells Grid Engine Enterprise Edition how the
              resources (CPU, memory, I/O, etc.) of one execution host compare
              to the resources of other execution hosts. This helps to ensure
              that a job requiring a large percentage of resources (i.e. lots
              of tickets) gets placed on an execution host containing a large
              percentage of the available resources. The load situation on the
              execution hosts is taken into account in addition, to guarantee
              that the selected host is both powerful enough and lightly
              loaded.

              For example, you might consider setting your resource capability
              factors for each execution host based on the number of CPUs, the
              speed of the CPUs and the installed main memory:

                 #_of_CPUs * (MHz/200) + GB_of_memory

              This would give an execution host with 32 200 MHz CPUs and 10
              gigabytes of memory a resource capability factor of 42, while an
              execution host with 24 200 MHz CPUs and 40 gigabytes of memory
              would get a resource capability factor of 64, i.e. memory has a
              significant impact in this example.

              Other factors that you might want to consider in setting the
              resource capability factor are:

                 job mix              - CPU or memory bound jobs
                 CPU benchmarks       - comparison by CPU vendor
                 megaflops (MFLOPS)   - for number crunching
                 I/O capabilities     - disk/network speed
                 available disk space - at the execution host

              The resource capability factor is stored as a floating point
              double value.  The range of values used is not important. Grid
              Engine Enterprise Edition only looks at the relation between
              values of different hosts.

       user_lists
              The user_lists parameter contains a comma separated list of so
              called user access lists as described in access_list(5).  Each
              user contained in at least one of the enlisted access lists has
              access to the host. If the user_lists parameter is set to NONE
              (the default) any user has access being not explicitly excluded
              via the xuser_lists parameter described below.  If a user is
              contained both in an access list enlisted in xuser_lists and
              user_lists the user is denied access to the host.

       xuser_lists
              The xuser_lists parameter contains a comma separated list of so
              called user access lists as described in access_list(5).  Each
              user contained in at least one of the enlisted access lists is
              not allowed to access the host. If the xuser_lists parameter is
              set to NONE (the default) any user has access.  If a user is
              contained both in an access list enlisted in xuser_lists and
              user_lists the user is denied access to the host.

       projects
              The projects parameter contains a comma separated list of
              projects that have access to the host. Any projects not in this
              list are denied access to the host. If set to NONE (the
              default), any project has access that is not specifically
              excluded via the xprojects parameter described below. If a
              project is in both the projects and xprojects parameters, the
              project is denied access to the host.  This parameter is only
              available in a Grid Engine Enterprise Edition system.

       xprojects
              The xprojects parameter contains a comma separated list of
              projects that are denied access to the host. If set to NONE (the
              default), no projects are denied access other than those denied
              access based on the projects parameter described above.  If a
              project is in both the projects and xprojects parameters, the
              project is denied access to the host.  This parameter is only
              available in a Grid Engine Enterprise Edition system.

SEE ALSO
       sge_intro(1), qconf(1), uptime(1), access_list(5), complex(5),
       sge_execd(8), sge_qmater(8).

COPYRIGHT
       See sge_intro(1) for a full statement of rights and permissions.



GEEE 5.3                 $Date: 2001/07/20 08:19:15 $             HOST_CONF(5)