The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.
Difference between revisions of "New Availability Reporting"
m (moved Logical-site to POEM and ACE requirements) |
|||
| Line 1: | Line 1: | ||
=Use case 1: NGI availability= | =Use case 1: NGI availability reports= | ||
We would like to | We would like to have NGI Availability reports. These reports should include the central services operated by the NGI, this including the regional tools and other middleware core services operated, for example: | ||
* the VOMS service | * the VOMS service | ||
* the top-BDII service | * the top-BDII service | ||
* the WMS service | * the WMS service | ||
and the operational services including | |||
** the NGI SAM service | ** the NGI SAM service | ||
** the accounting portal and repositories (where available) | ** the accounting portal and repositories (where available) | ||
| Line 11: | Line 13: | ||
**... | **... | ||
VOMS | The concerned services would be only those for which the NGI has direct administration responsibilities. For example the NGI availability reports shouldn't include WMS, VOMS etc. instances that are independently deployed by the sites to support local user communities and local projects. | ||
It is important to consider that a NGI core services is often physically distributed across different sites, that only have the role of hosting the hardware (but no administration responsibility). This has several implications. | |||
# If one instance is down but the rest of the cluster is up, then the "logical" service is still available. This means that the alias should be monitored for the sake of availability computation, not the individual physical instances | |||
# The site availability should not be impacted by the unavailability of physical instances of a service operated by the NGI. | |||
This use case could be satisfied by: | |||
- grouping NGI services into a dedicated NGI site (in case of a distributed service, only the alias is registered) | |||
- create a NGI availability profile just applicable to the "NGI" site, where the availability of the site is computed as the AND composition of the availability of all registered services. Note that if some (optional) services are NOT available, then UP should be returned, i.e. the profile should include a mandatory set of services (e.g. regional SAM) and a complementary set of optional services (e.g. the local helpdesk, VOMS, etc.) | |||
==NGI middleware availability== | ==NGI middleware availability== | ||
Revision as of 16:31, 1 September 2011
Use case 1: NGI availability reports
We would like to have NGI Availability reports. These reports should include the central services operated by the NGI, this including the regional tools and other middleware core services operated, for example:
- the VOMS service
- the top-BDII service
- the WMS service
and the operational services including
- the NGI SAM service
- the accounting portal and repositories (where available)
- the NGI operations dashboard (where available)
- the NGI helpdesk (where available)
- ...
The concerned services would be only those for which the NGI has direct administration responsibilities. For example the NGI availability reports shouldn't include WMS, VOMS etc. instances that are independently deployed by the sites to support local user communities and local projects.
It is important to consider that a NGI core services is often physically distributed across different sites, that only have the role of hosting the hardware (but no administration responsibility). This has several implications.
- If one instance is down but the rest of the cluster is up, then the "logical" service is still available. This means that the alias should be monitored for the sake of availability computation, not the individual physical instances
- The site availability should not be impacted by the unavailability of physical instances of a service operated by the NGI.
This use case could be satisfied by: - grouping NGI services into a dedicated NGI site (in case of a distributed service, only the alias is registered) - create a NGI availability profile just applicable to the "NGI" site, where the availability of the site is computed as the AND composition of the availability of all registered services. Note that if some (optional) services are NOT available, then UP should be returned, i.e. the profile should include a mandatory set of services (e.g. regional SAM) and a complementary set of optional services (e.g. the local helpdesk, VOMS, etc.)
NGI middleware availability
The NGI middleare logical site includes all core middleware services operated by the NGI: WMS, top-BDII, VOMS etc. regardless of their physical location.
For example top-BDII is OK IF (tB1 is OK) OR (tB2 is ok) OR .... (tBN is ok).
NGI middleware service is UP IF (VOMS is UP) AND (top-BDII is UP) AND .... (WMS is UP)
NGI operations tool availability
The NGI operations logical site includes all operations tools operated by the NGI: helpdesk, SAM, ops dashboard etc.
NGI operations services is UP IF (Helpdesk is UP) AND ... AND (SAM is UP)
Use case 2: EGI.eu availability
We would like to measure the overall availability of EGI.eu services.
For example EGI.eu operations service is UP if (GGUS is UP) AND (Operations Portal is UP) AND ... AND (GOCDB is UP)
NGI is UP if (operations services is UP) AND (middleware services is UP)
Use case 3
The usage of the "logical" site could be used to represent a distributed Resource Centre (like the NDGF T1). At the moment it is a single site in GOCDB associated to country X. This use case is mentioned here for the records of the discussion. It is not a crticial use case for the moment.