Top-BDII list for NGI

From EGIWiki
Jump to: navigation, search
Main operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security

top-BDII deployment policy

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

  • A Resource infrastructure Provider integrated with EGI (single NGIs, federated NGIs and EIROs) MUST provide an authoritative information discovery service (top-BDII), which can be either directly operated by the Resource Infrastructure Provider, or indirectly by a 3rd party (like a partner NGI).
  • Authoritative top-BDII services - as well as other NGI authoritative services - are defined in GOCDB in the NGI site or NGI service grouping. The Resource infrastructure Provider is responsible of keeping this information accurate.
  • Resource Centres SHOULD be configured to deploy the top-BDII provided by their Resource infrastructure Provider as primary service. Secondary top-BDII instances can be used at the client level for failover reasons upon agreement with the Resource infrastructure Provider operating these.
  • The Resource infrastructure Provider service MUST be a highly available service. The minimum quality requirements (monthly Availability and Reliability) are defined in the Resource Infrastructure Provider OLA. In case these quality parameters cannot be guaranteed, Resource infrastructure Providers are RECOMMENDED to use the top-BDII catch-all service provided by EGI.

top-BDII Availability and Reliability (no more collected)

This page contains the list of the Top-BDII instances that are operated by the NGIs. Starting from October 2011, these instances will be considered for the generation of the monthly NGI Availability and Reliability report.

Availability and Reliability figures are extracted from MyEGI (ROC profile, OPS VO).


  • if you think that a wrong top-BDII entry is mentioned in the table below, please send a GGUS ticket to the Operations support unit indicating the entry to replace and the new service end-point.
  • the same top-BDII instance can be reported for more than one NGI. This is the case if two ore more NGIs are sharing this service, this is typically the case when they are operated by the same Operations Centre.
  • several top-BDII instances can be reported for one NGI. This is the case one a NGI deploys failover at client side using multiple top-BDII instances as alternative contact points (MAN05). In this case the NGI overall top-BDII hourly availability is calculated by OR-ing the hourly availability of the individual top-BDIIs.

Top-BDIIs operated by the NGIs

GOC DB service group with NGI Top BDIIs:

Operations Centre Top-BDII host(s) Notes

(last update: April 2013)

AfricaArabia 1 end-point
AsiaPacific 1 end-point
CERN 3 end-points
Serbia 1 endpoint
Armenia 1 end-point
Austria Austrian sites are collaborating with the NGI_IT Operations Center
Bosnia Herzegovina 1 end-point
Bulgaria 1 end-point
Belarus 1 end-point
Switzerland 1 end-point
Czech Republic DNS alias for three instances running at different sites.
Germany 3 end-points
top-BDII hosted by NDGF
Spain,,, Spanish sites also point to the Portuguese TopBDII
Finland NDGF top-BDII:
Georgia 1 end-point
Croatia 1 end-point
Hungary 1 end-point
Italy five instances under dns round robin
Lithuania 1 end-point
Latvia > 1 end-point
FYR Macedonia,
Moldova 1 end-point
Montenegro Montenegro is using the EGI catch-all Top-BDII
Norway NDGF top-BDII (
Poland,, All 3 working under DNS pool
Portugal,,, Portuguese sites also point to the Spanish TopBDIIs
Slovenia, 2 end-points
Sweden NDGF top-BDII
Turkey 2 end-points
ROC_LA 1 end-point
Russia,, 3 end-points
Ukraine 3 end-points


top-BDII availability/reliability statistics are based on availability/reliability data that is published by MyEGI through the SAM Programmatic Interface (SAM PI). MyEGI is the authoritative source of availability/reliability data (GridView is now decommissioned).

A brief description of the algorithm adopted to compute top-BDII availbility and reliability statistics follows.

Different schenarios are possible.

Scenario 1. Single top-BDII

The NGI reports only one Top-BDII. It could be a single top-bdii instance, or alternatively a DNS alias for a pool of top-BDII instances (the DNS alias MUST BE monitored by the NGI Nagios). In this case Availability and Reliability are the monthly Availability and Reliability reported directly by the MyEGI Programmatic Interface.

Note: If the alias is used by the sites but only the single instances in the pool are monitored by Nagios, then in the table above the list of instances per NGI has to be reported. In this case Availability and Reliability are computed according to Scenario 2.

Scenario 2. List of top-BDIIs

The NGI reports a list of top-BDIIs. These are all used by the sites to configure failover at client side. In this case the algorithm steps are the following:

  1. Query MyEGI to get the hourly A/R values for every top-BDII instance in the list. (Example of query)
  2. Hourly Availability and Reliability: given the list of Availability/Reliability figures for the top-BDII in the list, the maximum Availability/Reliability figures are computed. These are selected to be the hourly Availability/Reliability. (Example of query)
  3. Monthly Availability and Reliability: the monthly Availability/Reliability is the arithmetic mean of the hourly Availability/Reliability figures in the reference month:
Monthly A/R: (sum of the Hourly A/R figures)/(number of hours when the status was known).