1 / 13

SA1 requirements

Discover the requirements, installation, configuration, and service instrumentation for gLite. Learn about the benefits of Yaim and how it simplifies the process. Includes varying strengths of requirements and experiences.

fhuff
Télécharger la présentation

SA1 requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SA1 requirements gLite Installation, configuration and service instrumentation

  2. Overview • Yaim • Why we needed it • How it works • Experience • gLite • Installation, Configuration and Instrumentation • Varying strengths of requirements • Some already met Oliver Keeble / 01-03-05

  3. Yaim – why we needed it • The Manual Installation Guide was hard to use • >300 pages of documentation, ranging from MON box (17) to RB (65 ) • Time consuming • Error prone • LCFGng not available on SL3 • Unpopular / problematic • Nothing else available to configure a site • Several pre-existing service configuration scripts • Logical solution: scripts • Many script excerpts in the documentation • Unambiguous description of generic install Oliver Keeble / 01-03-05

  4. Yaim - how it works • 1 Install OS (SL3 or RH7.3) • Kickstart, CD etc. • Ensure NTP is configured • Install and configure apt • Likely to move to yum • 2 Modify site config file for the site • Key value pairs sufficient (just) • 3 Copy site config file (and certs) • 4 Run installation script • 5 Run configuration script shell functions APT rep Site Config File f1 f2 fn uses uses uses uses uses M/W Installation script M/W Configuration Script Oliver Keeble / 01-03-05

  5. Yaim – what people like • No installation server • Independent of fabric management tools • Easy to use • Less technical knowledge required • Reduces errors • Fast – simple sites in under an hour • Extensible • Allows manual tuning • Documents the standard install • Executable documentation • Easier to manage updates • One file to inspect • Easy access to middleware updates and fixes Oliver Keeble / 01-03-05

  6. Requirements: Service configuration • Top level config file • Encapsulating the SITE • As human readable as possible (simple XML is fine) • The current gLite config files are meeting this requirement • Parameter classification - must/might/shouldn't be changed • In place!!! • Parameter validation • Config scripts should catch inappropriate defaults persisting • Network accessible? (has to be secure) • Service oriented approach • Should be able to install all on one machine to prove the absence of conflicts between services • Useful during development • Deployment recommendations with respect to service distribution across nodes Oliver Keeble / 01-03-05

  7. Requirements: Site architectures • Flexible enough to accommodate different site architectures • Not necessarily out of the box • Extensible for easy addition of new or local components • eg Multiple CEs, WNs on NAT, different storage systems… • Multiple instances of services (to address scalability) • Access to storage, computing etc. • Separation of service and state (reliability) • Fabric Management friendly • Can turn off eg cron or user management • Firewall management - gLite port table Oliver Keeble / 01-03-05

  8. Requirements: KISS • Err on the side of simplicity • We'd prefer a narrower functionality which works well • Leave the management GUIs for later • Cover the functionality that small to medium sites with a standard layout need • Larger more complex sites will adapt anyway • Focus on the simper use cases • More complex scenarios should in part be covered by sites and provided via WIKI FAQ pages – community effort • Knowledge of non-standard configurations can accumulate here Oliver Keeble / 01-03-05

  9. Requirements: Configure and Install • Separate installation and configuration • Installation • m/w in native formats for supported architectures • Well specified dependencies • Avoid non SL3 dependencies wherever possible • We will create apt/yum repositories • Configuration • Post-install config / service config is a useful distinction • More interested in a solid install than post-install reconfiguration • Runtime reconfiguration should not require interruption of service if possible • Reversible? eg, we can add a VO, but can we remove one? • Upgrade & Reconfiguration • Configuration changes between versions should be easily identifiable so that localisations can remain compatible Oliver Keeble / 01-03-05

  10. Requirements:Relocatable middleware • Relocatability • The middleware should be relocatable - we will be using this feature on WNs and UIs • A UI/WN should be installable without root privileges • We currently supply a “Tar ball” distribution • Tar balls are available for creating UIs and WNs • The constraint to install in the /opt directory has been removed • A user can install and configure a UI • New Deployment Scenarios for sites • A WN can be network mounted  only one WN needs to be configured. • Multiple versions can be used  transition to new version possible without stopping the service • WNs could be deployed on sites as user level software Oliver Keeble / 01-03-05

  11. Requirements: Other components • CA management should remain decoupled • Security patches • Batch systems • As the sites move to new solutions gLite should follow • openPBS  Torque + MAUI • maybe tomorrow SunGridEngine • Documentation • Underlying configuration documented where necessary • After SA1 has made the JRA1 docs more (end) user friendly JRA1 should consider to use them as a platform for future releases • Ultimately it would be good for the installation to be handled this way too Oliver Keeble / 01-03-05

  12. Requirements:Service Instrumentation • Not related to other topics!!! • Minimal: • Services need interface to answer questions • Status: OK, critical, scheduled off • Version (secure interface) • Load: Estimated percentage of max load • In addition human readable string providing any reasons • Better: • Secure interface to trigger actions on the service • restart • stop/start • pause (service processes pending requests, but doesn’t accept new ones) • re-read configuration • Each of them needs to be locally activated (site controls what can be done remotely) • Secure publishing the permission matrix • Best: • Secure remote access to log files and state Oliver Keeble / 01-03-05

  13. Summary • Based on recent experience with LCG-2 • Priorities and future direction • Some ‘headlines’… • Configuration • Site configuration file, human readable • Extensible • Installation • Good dependency management • Proper handling of upgrades • Instrumentation • Advertising status • Relocatable and user installable client libraries Oliver Keeble / 01-03-05

More Related