Awips product improvement architecture review 24 june 2004
1 / 23

AWIPS Product Improvement Architecture Review 24 June 2004 - PowerPoint PPT Presentation

  • Uploaded on

AWIPS Product Improvement Architecture Review 24 June 2004. Overview. Joint discussions led to an analysis of technology and development of a “to-be” architecture which was briefed to the SET on 2/3/04.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'AWIPS Product Improvement Architecture Review 24 June 2004' - hateya

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Awips product improvement architecture review 24 june 2004

AWIPS Product Improvement

Architecture Review

24 June 2004


  • Joint discussions led to an analysis of technology and development of a “to-be” architecture which was briefed to the SET on 2/3/04.

  • To-be architecture provides the framework to complete individual product improvement tasks while maintaining a common goal.

    X-terminals Redundant LDAD firewalls

    Router Upgrade Redundant LDAD servers

    DS replacement Full DVB deployment

    Serial mux upgrade

  • To-be architecture facilitates development of a roadmap for schedule, budget and deployment planning.

  • Roadmap assists in issue and dependency identification and resource planning for risk reduction.

Awips to be architecture
AWIPS To-Be Architecture

  • Hardware

    • Utilize Network Attached Storage (NAS) technology

    • Deploy commodity servers on GbE LAN

    • Incrementally deployed and activated

    • Promote reuse of select hardware

    • Remove limitations of direct attached storage

  • Software

    • For availability, move from COTS solution to use of public domain utilities

      • Some experience with NCF and REP

      • Can be decoupled from operating system upgrades

      • Supports NAS environments

      • Can be augmented for load balancing if required

    • Deploy low cost Linux database engine

Awips to be architecture1
AWIPS To-Be Architecture

  • Methodology

    • Stage hardware, move software when ready

    • Reuse hardware to ease transition and allow planned decommissioning

    • Deploy flexible availability framework

    • Deploy Linux database engine

  • Goals

    • Decommission AS, AdvancedServer, DS and FDDI

    • Support universal deployment of single Linux distribution (currently RHE3.0 with OB6)

    • Provide dedicated resource for local applications

    • Expandable within framework (easy to add servers)

Step 1 initial hardware deployment
Step 1 – Initial Hardware Deployment

  • Release OB4 is a prerequisite

  • Initial staging of hardware

    • New rack

    • NAS w/LTO-2 tape (~400GB storage and backup)

    • 2 commodity servers – DX1/DX2

    • 2 GbE switches and associated cables, etc

    • 2 8-port serial mux replacements (installed in PX1/2)

  • NAS key to incremental deployment and activation

  • Serial mux replacements installed but not activated

  • LTO-2 drive for site backup

  • New hardware on GbE LAN

  • LDAD firewall upgrade deployed independently

Step 1 and release ob4
Step 1 and Release OB4

Red text indicates newly ported or moved processes

Step 1 incremental activation
Step 1 - Incremental Activation

  • Activate NAS

    • Point DS to NAS

      • Allows DS1/DS2 to be used as active/active pair using existing MC/ServiceGuard infrastructure

      • Decommission DS mass storage and autoloader

    • Point PX1/PX2 to NAS

      • Maintain active/active pair

      • Deliver new availability mechanism

      • De-activate cluster management portion of AS2.1

      • PowerVault (PV) deactivated for near-term

  • Cooked data to the NAS, temporary files continue to be written to local disk

  • Short (2 week OAT) to verify DS1/DS2 and PX1/PX2 failover and NAS data

  • OAT in early October to allow full deployment decision and complete deployment to initial 41 sites by 1 Feb 05

Step 1 current action items
Step 1 – Current Action Items

  • Coordinate serial mux upgrade hardware delivery to site with DS replacement. This reduces number of hardware installs to be monitored by NCF, but as APS software will not deploy the final cable connections will be delayed until Step 2. (NGIT - L. Dominy)

  • Required infrastructure changes include consolidate data from DS mass storage and PX power vault, verify MC/SG on DS1/2, deactivate cluster manager portion of AS2.1 on PX1/2, install new availability software on PX1/2 and deactivate the power vault. (NGIT - L.Dominy)

  • Verify only cooked data on NAS (currently all /data/fxa, /data/fxa_local, and /home). Review /data/fxa structure. (SEC - E. Mandel/FSL - D. Davis)

  • Review IFP file system to determine which directories go to NAS for data storage (all binaries should be on a server(s) and temporary file directories to stay on PX1/2. (FSL - D. Davis)

Step 2 decommission as1 as2
Step 2- Decommission AS1/AS2

  • Release OB4 maintenance release of stable OB5 software required for AS decommissioning

  • Activate DX1/DX2

    • Infrastructure/decoders move to DX1

    • IFP/GFE to DX2

    • Newly ported functionality to DX1

  • Reuse PX1 and PX2 as PX1 and SX1

    • PX1 for applications/processes using “cooked data”

    • SX1 for Web Server, local applications and eventually LDAD

    • Activate serial mux replacement and ported APS

  • Non-ported software from AS1 to DS2

  • Hosts remain on RH 7.2 as risk reduction

Step 2 and ob4 x ob5 w rh7 2
Step 2 and OB4.x/OB5 (w/RH7.2)

Red text indicates newly ported processes, green text for moved processes.

Step 2 incremental activation
Step 2- Incremental Activation

  • Failover scheme

    • DX1 to DX2

    • DX2 to DX1

    • PX1 applications (less LAPS which does not failover) and servers to DX2

    • PX1 processes APS and NWWSProduct to SX1 (require serial mux access)

    • SX1 baseline software to PX1

  • Decommission AS1/AS2 and excess rack

  • Linux SMTP MTA deployed as start of migration from x.400 (required for DS decommission)

Step 2 current action items
Step 2 - Current Action Items

  • Ensure OB5 tasking with priority check-in for Linux AsyncProductScheduler and NWWS Scheduler. Does NWWS Product need to ported at same time? (SEC - E. Mandel)

  • Ensure OB5 tasking with priority check-in for Linux LAPS, notificationServer, Redbook and radarStorage. If prototype testing is successful check-in Linux routerStoreNetcdf. (FSL - D. Davis)

  • Activate serial mux upgrade and move/connect cables. (NGIT - L. Dominy)

  • Requires movement of processes between servers, review architecture roadmap and verify no dependencies have been overlooked. (SEC, FSL, MDL, OH and NGIT)

Step 3 deploy data base and os
Step 3 – Deploy Data Base and OS

  • Deploy Linux POSTGES data base engine to DX1

    • Move existing PV to new rack and connect to DX1/2

    • Reconfigure PV (possibly into 2 separate direct attached disk farms, one for each DX)

    • Database availability via mirrored or replicated databases is TBD at this time

  • Migrate ported databases

  • Upgrade operating system (currently RHE3.0) on all applicable hosts

    LX/XT CP (if full DVB deployment complete)

    DX AX (Linux Informix migration?)

    PX/SX RP?

Step 3 and ob6 rhe3 0
Step 3 and OB6 (RHE3.0)

Red text indicates newly ported processes.

Step 3 incremental activation
Step 3 – Incremental Activation

  • Decommission AS 2.1 and HP Informix

  • HP Informix engine can remain on DS for site use (though if all databases are ported not sure why?)

  • Transition to SMTP and decommission x.400

Step 3 action items questions
Step 3 - Action Items/Questions

  • Verify if RHE3.0 to be procured for all hosts in OB6 timeframe. (OST – Ed Mandel)

  • Can/should POSTGRES be delivered early (OB5.x) to RH7.2 DXs?

    • Most sites run software against GFS databases, not their own databases.

    • Database and software will be tested with RHE3 only as part of OB6.

    • If databases delivered early how/when does parallel ingest get developed and tested?

    • Should RFCs be handled differently?

  • Determine plans for RFC archive server’s use of Informix.

  • Do the RP servers get RHE3.0 with OB6?

Step 4 deploy ldad upgrade
Step 4 – Deploy LDAD Upgrade

  • Deploy LS1 and LS2

    • Deploy redundant server pair (requirements still tbd)

    • Could reuse PX1/SX1 as LS1/LS2 and use new generation hardware for PX1/SX1

  • Activate LS1/LS2

    • Migrate internal LDAD processing to SX1

    • Some internal and external LDAD processing must transition at same time

  • Reuse existing HP LS on internal LAN

    • Existing 10/100 MB LAN card

Step 4 and obx
Step 4 and OBx

Red text indicates newly ported processes.

Step 5 decommission ds1 ds2
Step 5 – Decommission DS1/DS2

  • Continue to move ported software/databases to Linux servers

    • Combine with step 6 if additional DXs are required

    • DX1 for database server and infrastructure

    • DX2 for IFP/GFE

    • DXn for decoders

  • All Linux devices on GbE LAN

  • Remaining functionality on LS on 100MB LAN

    • DialRadar/wfoAPI (tied to FAA/DoD requirements) may be OBE at this point. If so, Simpacts and LS can be decommissioned at all non-hub sites.

    • Netmetrix (required at hub sites only)

Step 5 and obx
Step 5 and OBx

Red text indicates newly ported processes.

Step 6 process loading
Step 6 – Process Loading

  • Incrementally add DX hosts for load balancing for new functionality and data sets.

    • DX1 for database server and infrastructure

    • DX2 for IFP/GFE

    • DXn for decoders

Step 6 and obx
Step 6 and OBx

Green text indicates moved processes.

High level schedule
High Level Schedule

  • Key dates

    • notificationServer port and enhancements

    • Step 1 OAT (must complete before initial deployment)

    • Step 2 OB4.x OAT and Full Deployment

    • OB6 check-in