Just to add to the confusion. The BDII could also replace the GRIS if we
choose to do so. Also as the BDII uses ldapadd and ldapmodify to
populate the DB, with a few tweaks the BDII could be used to replace the
GIP too. The GIPs concept is first use ldapadd to get the static data
then to run the plugins to get the dynamic data, which is essentially
ldapmodify.
The MDS GIIS and GRIS are indexing servers. The GRIS stores the URL of
the information providers and the GIIS has the URL of the lower level
indexing server in the hierarchy. When a query is made against an
indexing server, it passes this information to the lower level until it
reaches the information provider and the result it returned. This is
one of the main problems with MDS as the different levels are not
decoupled.
Although the BDII provides the same external interface for the query, it
works totally differently. The BDII is configured with the URLs of the
lower levels and a process periodically queries these URLs and updates
the write DB. When the write DB has be re-freshed, it is swapped to a
read only DB. Querys made to the BDII only go the read only DB and do
not propagate to the lower levels.
Thus although the GIIS/GRIS and BDII provider the same query interface
(LDAP), the way they work is completely different and therefore it is
probably a good idea to distinguish this difference. The common point is
the "scope" of the information they serve.
"resource" BDII = GRIS = Information from information providers on the
machine.
"site" BDII = site GIIS = Information from one site, could specify the
site name eg. NIKHEF site BDII
"top-level" BDII = top-level GIIS: Information for the whole grid.
Other types of BDII.
"experiment" BDII = A top-level BDII that uses the FCR Page to "tune"
the information to the needs of the VOs. Only does ldapmodify on
attributes.
Note that VOs should NOT have a "VO" BDII, a top-level BDII that
contains different sites. This was tried but leads to problems, the FCR
page should be used instead.
"OSG" BDII = A BDII that represents the sites in OSG. This is included
by the top-level BDII.
"ARC" BDII = A BDII that contains all the ARC sites and translates from
the ARC to Glue Schema. This will be included by the top-level BDII.
Laurence
Henry Nebrensky wrote:
>On Thu, 24 Nov 2005, Jeff Templon wrote:
>...
>
>
>>my take on the matter: the old BDII was originally made to take over the
>>function of the top-level info index; later the *software system* BDII
>>was used to implement lower levels of the system as well. Hence the
>>confusion, as you guys have already summarized.
>>
>>I think we should start separating the two. The BDII is a software
>>product. GRIS and GIIS would be OK except people might confuse them
>>with the globus products. We have
>>
>>GRIS (Grid Resource Info Service) -- single computer
>>GIIS (Grid Index Info Service) - anything that aggregates info from
>>multiple sources.
>>
>>GRIS is clear, GIIS is the problem in that there are multiple flavors.
>>
>>
>
>Depending on whether the "multiple flavors" is read as referring to
>site-vs-root (below) or MDS-vs-BDII; I would add that IMHO as S stands for
>service anything that exposes the right interface and supplies the
>expected set of information can be a GIIS, however it's implemented.
>
>So I'm quite happy with the "site-GIIS" suggestion (which the GOC DB
>already uses).
>
>
>
>>We could easily come up with site-GIIS which aggregates over a single
>>grid site, and root-GIIS which aggregates over all sites in a particular
>>grid federation.
>>
>>
>
>My objections to this would be that
>
> - the nutrient information That Thing distributes actually originates at
> a whole lot of resource GRIS's (trunk-GIIS? stalk-GIIS?)
>
> - people will refer to the site-GIIS as just a "GIIS", and we'll end up
> with the reverse confusion
>
>(and to top-level-BDII, suggested elsewhere
> - it's only a top-level anything in that it publishes data actually
> created several layers lower in the organisation. And where would
> something aggregating across Grids go?)
>
>
>My own preference would be to call it Something Utterly Different,
>but the best I can think of this late is Information Intermediary (is the
>old II acronym available for reuse yet?) or maybe Information Aggregation
>Service.
>
>Thanks
>
>Henry
>
>
>VOs wanting to use a filtered list of SUDs would implement an Information
>Intermediary Identifier (III). Wise experiments would have several IIIs in
>case of problems, and thus deploy an Information Intermediary Identifier
>Index (IIII).
>
>Hey, scalability's good, right?
>
>
>
|