| 73 | | Configuration common between several clusters is stored in a site hierarchy, stored under [source:templates/trunk/sites sites] directory. As far as Quattor is concerned, a ''site'' doesn't have to match a geographical location but is an abstract entity corresponding to a set of shared configuration parameters. A cluster may belong to several ''sites'' corresponding to different set of common parameters. For example, a cluster may belong to 2 sites : {{{mycity}}} and {{{gridsite}}}. {{{mycity}}} will define parameters corresponding to a specific geographical locations (like network related parameters) that are common to all kind of clusters (grid machines, non grid servers, desktops...) at this geographical location. {{{gridsite}}}, on the other hand, will define parameters that are common to all grid machines, whatever geographical location they belong to. |
| | 75 | When using [wiki:Doc/SCDB SCDB], machine profiles are organized in `''clusters''. A cluster in SCDB is not related to a computing cluster but to an arbitrary grouping of machines. All clusters in SCDB '''must''' reside into the [source:templates/trunk/clusters cfg/clusters] templates hierarchy. There are many reasons why a site may want to have separate SCDB clusters, for example : |
| | 76 | * Different group of machines : grid servers, internal servers, desktops... |
| | 77 | * Different version of grid middleware : currently, all the machines in a cluster must run the same middleware version (see gLite [wiki:Doc/gLite/TemplateLayout templates layout]). When transitionning from one version to another, the site need to create a new cluster. |
| | 78 | * Production and testbed machines |
| | 79 | * Clusters of machines spread over different geographical locations |
| | 80 | * Split of a large number of machines into smaller units, for example based on alphabetical order of machine names |
| | 81 | |
| | 82 | When a site is running several clusters, it is generally convenient not to duplicate information shared by several clusters. This is done through the concept of ''sites''. A site in SCDB '''is not related to a geographical grouping of machines'''. And a cluster '''can belong to several sites'''. This is up to each site to define how it uses SCDB sites. By convention, all the SCDB sites are defined into [source:templates/trunk/sites cfg/sites] but nothing prevents a site to use another name for this or use several different template hierarchies. |
| | 83 | |
| | 84 | A cluster is associated with one or several sites by the cluster specific file [source:templates/trunk/clusters/example/cluster.build.properties cluster.build.properties]. If associated with several sites, the first one takes precedence over the following one if a template exists in several sites. This ability to associate a cluster with several ''sites'' is a key SCDB feature that can be used for several use cases. |
| | 85 | |
| | 86 | === Managing several geographical sites from one SCDB === |
| | 87 | |
| | 88 | In this use case, one SCDB is used to managed different geographic sites, sharing some configuration information between them. In the following example, the geograhical site is called `mycity` and all sites belong to one grid site called `gridsite`. This is easily achieved by defining the following SCDB sites : |
| | 89 | * {{{mycity}}} : defines parameters corresponding to the geographical locations (like network related parameters) that are common to all kind of clusters (grid machines, non grid servers, desktops...). |
| | 90 | * {{{gridsite}}}, on the other hand, will define parameters that are common to all grid machines, whatever geographical location they belong to. |
| | 91 | |
| | 92 | In `cluster.build.properties`, you include `mysite` before `gridsite`, with something like : |
| | 93 | {{{ |
| | 94 | cluster.pan.includes=mycity mycity/**/* gridsite gridsite/**/* |
| | 95 | }}} |
| | 96 | |
| | 97 | ''Note : look at [wiki:Doc/TemplateCustom#ClustersandTemplateHierarchies] for more information on `cluster.build.properties` format.'' |
| | 98 | |
| | 99 | If you want to add a cluster at another geographical location (e.g. `mycity2` belonging to the same grid site, you will just need to adapt this cluster `cluster.build.properties` with something like : |
| | 100 | {{{ |
| | 101 | cluster.pan.includes=mycity2 mycity2/**/* gridsite gridsite/**/* |
| | 102 | }}} |
| | 103 | |
| | 104 | If you want to add a non grid cluster at location `mycity`, you will tune this cluster `cluster.build.properties` with something like : |
| | 105 | |
| | 106 | In `cluster.build.properties`, you include `mysite` before `gridsite`, with something like : |
| | 107 | {{{ |
| | 108 | cluster.pan.includes=mycity mycity/**/* |
| | 109 | }}} |
| | 110 | |
| | 111 | === Supporting production and test clusters === |
