1 / 10

Archive Retrieval—Beta Test March 14, 2003

Archive Retrieval—Beta Test March 14, 2003. Introduction. Current archiving system is inadequate for several reasons Majority of the software runs under OpenVMS Maintenance of the OpenVMS-based code is extremely difficult, hence costly Code changes are difficult to make

bijan
Download Presentation

Archive Retrieval—Beta Test March 14, 2003

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. Archive Retrieval—Beta TestMarch 14, 2003 Implementation Review

  2. Introduction • Current archiving system is inadequate for several reasons • Majority of the software runs under OpenVMS • Maintenance of the OpenVMS-based code is extremely difficult, hence costly • Code changes are difficult to make • Recompilation of the code often exposes latent bugs unrelated to the intended fixes • The requirements and assumptions that shaped the system are antiquated • Ingest and distribution services operate near the limit of their capacity • Mismatch between older S/W and newer peripherals • Operations objectives no longer met by system functionality • Flexibility in handling requests that require manual intervention • Support for “lights out” operations Implementation Review

  3. Architectural Objectives • Meet the needs of archive users today and the future • Improve operator control of the system • Provide more control over the running system • Increase automation options • Improve throughput & reliability • Relieve system bottlenecks in unreliable areas of the system • Staging disk space & outgoing network connections • Reduce system downtime • Adjust use case of MO jukebox more in line with vendor expectations • Lessen impedance mismatch at the OTFR interface • Support future data products and services • Increasing request sizes due to large data products require higher capacity shippable media like DVD • High degree of platform independence • UNIX is favored in the current implementation • Improve system maintainability Implementation Review

  4. Release Strategy • Distribution will be ready for release prior to server availability • Demands placed on the compute infrastructure by the new distribution architecture disallow deployment on existing H/W • 1 Java process per active request + ~5 servers + complete OTFR system • Mitigate risk of deploying a new architecture by releasing as soon as possible in parallel with existing system • DADS 10.0 is planned for April 1 release as a beta system while DADS 9.X continues to run under OpenVMS • Will use Sun Fire 280R system (2 CPU) until 15K is available • Off-loading some archive users to beta system will increase headroom in current system Implementation Review

  5. DADS 10.0 Deployment Strategy • Initial release on April 1 • Deploy with its own OTFR system on 280R • Server has the same architecture as the 15K • 2 CPU system will support some small number of concurrent requests • Run in parallel with the current OpenVMS DADS 9.x/OTFR system • S/W, database, and StarView changes already in place to support this mode of operations • A group of beta testers selected to exercise the new system • DADS 9.x will serve as a backup for these users in case of difficulty Implementation Review

  6. Release Objectives • Construct a system test environment • Archive development and test systems today do not mirror operations • Provide a system test bed to resolve liens, fix problems, establish operations procedures before full-up release • Determine optimal full-up release system configuration • Verify functional correctness • Establish operations procedures Implementation Review

  7. Beta Test User Selection • Will use a mix of current archive users • Internal, external users • Measure impact of delivery modes • Exercise priority reassignment • Low-, high-impact users • Tune parameters and controls for fair use of the system when a large dynamic range of request sizes is present • Multiple instruments & missions • Cover the range of available HST data • Exercises different paths through OTFR • FUSE archive users • Archive operators • Evaluate controllability of the system under a variety of scenarios • Exercise failure recovery Implementation Review

  8. Test Plan Overview • Rapid development, build, test, and deploy on the beta test platform • Build cycle will be shortened to address issues quickly • Users will be made aware of the potential for downtime • Delivery of any liens against the system and features planned for later releases • Data depot capability will be added over the course of the test (will be designated DADS 10.1) • Enhanced capabilities not scheduled for the initial release will be added as they are implemented • The beta test platform will shift from the 280R to the 15K as it becomes available • Mitigates risk associated with the H/W platform in transitioning to the full operational release (DADS 10.2) Implementation Review

  9. Beta Test Completion Criteria • 15K must be available before new system assumes full archive distribution load • System performance and loading characteristics during the test must be well understood • Will determine exact runtime configuration of full operational release • Support for data depot must be available • Archive operators must concur that the system is ready Implementation Review

  10. Schedule Implementation Review

More Related