Issues using hostname aliases for grid hosts

The purpose of this task was to create images with pre-installed glite packages for each basic grid service, such as the computing element, the storage element, the worker node and the user interface. Afterwards, virtual machines based on the corresponding image are deployed for each type of service and configured with the yaim tool according to the hostname, certificates and information related to the specific instance of the grid service.

Grid services such as the worker node and the user interface appeared to be more portable during their deployment in the corresponding types of virtual machines. Nevertheless, the computing element and the storage element introduced some restrictions to their deployment in nodes with non-static configuration, which is the case of virtual machined on demand.

The authentication and authorization mechanisms require valid certificates for both of these services. These certificates are issued according the hostname of the service. It is also required that DNS lookups for the IP and the hostname can be resolved and thus the DNS servers need to be configured properly. Moreover, each time that the hostname of the site-bdii changes, which is usually deployed in the computing element, then the top level bdii needs to be informed about this change.

A tested solution was to add the hostname used in the certificates as an alias of the canonical corresponding hostname. This solution partially worked for the computing element. The canonical hostname was defined in the LFC_ALIAS attribute of the site-info.def configuration file and only in this way the jobs could be staged among the computing element and the worker nodes. The major problem with the usage of the alias hostnames was during the authentication procedure for data services. For example, the GridFTP server failed during data transfers, because authorization was denied to “globus_gsi_gssappi” due to the fact that the name of the remote host (alias hostname of the storage element) and the expected name of the remote host (canonical name of the storage element) did not match. For that reason, the data services require only the usage of the actual hostname of the machine for the configuration of the service. The globus-gridftp service may need to be contacted in the Cream CE as well.

Another problem related to the storage element and the above settlement of the alias hostname is that the storage element publishes information to the site GIIS and the top-level bdii service with attribute values for both the canonical and the alias hostnames, even if the alias hostname is not referred in any configuration file. This probably results in the fact that no information about the storage element appears in the top-level BDII server occasionally. Since no GlueSA information can be found in the top-level bdii server from time to time, the data services involving the specific storage element (and the corresponding SAM tests) fail.