Operations Surveys

This page collects information about surveys relevant to the EGI Opreations Community and the EGI Technology Providers (such as EMI, IGE, etc.). Surveys are conducted to collect information about deployed software, oprational tools and generally speaking to collect feedback from Resource Infrastructure Providers and Resource Centres.

Survey on Logging and Bookkeeping capabilities, service management and auditing and gLite-CLUSTER

• Release date: 18 Jan 2011
• Deadline for submission: 10 Feb 2011

Overview

• PART 1, Logging and Bookkeeping Service: Logging and Bookkeeping (LB) it is a monitoring service which gathers, aggregates and archives information on infrastructure behaviour from the perspective of users' tasks. The EMI project aims at extending the LB scope and its further integration with other grid services. The first page of the survey contains a set of questions to help LB Team to better design the new features of the LB Service, and to target the real users' needs.

• PART 2, Remote Grid Service Management (RGSM). Management is performed through a set of notifications issued to the relevant Grid service instance. Examples of management actions are: start, stop, drain etc. The RGSM framework can be used for remote management of a service. EMI has a dedicated task force to investigate the requirements for common service monitoring and management interfaces. This survey is to collect information and requirements from the EGI operations community and sites to understand which technologies are of interest for service management.

• PART 3, Grid service auditing (GSA), that is a feature that allows a system administrators and users to check the status of a service in terms of load, length of internal queues, and to monitor service workload from a grid point of view over time. Service auditing is different from Nagios-based monitoring as it is not based on probes, but rather on the periodic gathering of service status information.

• PART 4, gLite CLUSTER, glite-CLUSTER allows the configuration of information related to the batch system environment to be separated from the configuration of the job submission interface. With this service sites will be able to publish their resources information consistently and without any workaround. Even in case of multiple CEs or cluster with heterogeneous hardware configuaration. There are few questions to understand how the publishing of cluster information is a problem for site managers.

Instructions

Survey closed.

Resources

• pdf version of the survey

Results

Q1:Do you need more platforms to be supported by EMI software, in addition to those already in use (SL5)?

• 12 responses

Q2:Part One, Logging and Bookkeeping(Questions from 3 to 10)LB: Which services should be watched in the grid in addition to gLite WMS and CREAM, that are already supported by LB?

• ARC CE 7 - 58%
• UNICORE CE 5 - 42%
• Data Transfer 12 - 100%
• SRM Operations 8 - 67%
• Other 1

Q3:LB: What aggregated information would be useful (e.g. average queue traversal time, task failure rate etc.)?

• 12 responses

Q4:LB: And at what level of aggregation (referring to the previous question)?

• Per Use 6 - 55%
• Per VO 10 - 91%
• Per service instance 8 - 73%
• Other, please specify: 5 - 45%

Q5: Would you leverage capturing dependencies among the tracked entities (e.g. to know that a computational jobs are blocked by failing transfers of their inputs, and to be able to discover detailsimmediately)?

• Yes 5 - 50%
• No 5 - 50%

Q6: What is the desired level of complexity of the queries on the service?

• Simple, like: "all tasks on this CE", "this user's tasks within a given time interval": 4 - 36%
• More sophisticated, but through current LB querying language: 2 - 18%
• Full SQL/XQuery power on the task data: 7 - 64%
• Intermediate, describe here: 1 - 9%

Q7: LB: What are the output formats to be supported

• Glue-conforming WS interface: 6 - 55%
• Simple key=value text format: 7 - 64%
• JSON: 5 - 45%
• Human readable HTML:2 - 18%
• Other: 4 - 36%

Q8: What modes of retrieving information are foreseen ?

• Synchronous (query-response):7 - 64%
• Asynchronous (subscribe for notification, eventually via message bus): 4 - 36%

Q9: For how long data about the task should be kept?

• One day 0 0%
• One week 2 18%
• One month 4 36%
• One year or more 5 45%

Q10: Part two, Remote Grid Service Management (questions from 11 to 20) RGSM:Do any of your Grid services come with capabilities to react certain conditions by adapting their behaviour?

• Yes 4 40%
• No 6 60%

Q11: According to your day-to-day experience, please describe typical service management scenarios. How is management performed?

• 8 Responses

Q9: Are there any management commands that can be performed on your Grid services that go beyond specific business logic (e.g. purge persistent data)?

• Yes 2 25%
• No 6 75%

14. RGSM: What are the limits of your Grid service management capabilities?Is there a gap between the capabilities offered and your Grid service management needs? 9 Responses

15. RGMS:  Please list the 5 management commands you would need the most in your setup (e.g. start/stop services, deploy/un-deploy service, purge service data, dynamically change access rights..). 10 Responses

16. RGSM: Which of those 5 management commands apply to all of your Grid services? 9 Responses

17. RGSM: Out of your day-by-day eperience, how many services do you really need to manage remotely? 11 Responses

18. RGSM: are you capable of (un)deploy Grid services at runtime? Yes 1 9% No, but I would need it. 5 45% No, and I don't need it. 5 45% Total 11 100%

19. RGSM: If you're deploying stateful Grid services in a site: does the Grid service interface support Grid service state deletion? Yes 2 25% No 6 75% Total 8 100%

20. RGSM: What kind of setup would you prefer for remotely managing your Grid services? Dedicated: service management interfaces on each Grid service 5 45% Decoupled: services get their commands from a messaging solution they register to 1 9% Both 5 45% Total 11 100%

21. Part three, Grid Service Auditing (questions from 21 to 26). GSA: What kind of data are you already collecting about your Grid services and how are you doing it? 13 Responses

22. GSA: For which services auditing of service status is important?(service status: workload, queue status, etc..) 10 Responses

23. GSA: For each service above, which data is mainly useful? 8 Responses

24. GSA: For each service above, which data is mainly useful? 3 Responses

25. GSA: Are the current service auditing capabilities sufficient, or should this be improved? Yes 4 44% No 5 56% Total 9 100%

26. GSA: Should status data be automatically archived? Yes 9 90% No 1 10% Total 10 100%

27. Part four, glite-CLUSTER (questions from 27 to 29). gC: How many sites in your NGI/EIRO have heterogeneous clusters, or multiple sub clusters (disjoint sets of workernodes, each set having sufficiently homogeneous properties), or multiple CEs? 0 4 33% Up to 5 6 50% More than 5 2 17% Total 12 100%

28. gC: How many of those sites reported difficulties in configuring their CEs, in order to properly publish their site capacity? 0 5 38% Up to 5 5 38% More than 5 3 23% Total 13 100%

29. cG: Given that gLite-CLUSTER is released only for lgc-CE, how many sites in your NGI/EIRO are interested in usinge the gLite-CLUSTER capability? 0 8 62% Up to 5 2 15% More than 5 3 23% Total 13 100%