DS/AS REPLACEMENT STEP 1 CRITICAL DESIGN REVIEW 8/10/04 Tim Hopkins

DS/AS REPLACEMENT

STEP 1

CRITICAL DESIGN REVIEW8/10/04

Tim HopkinsNWS SYSTEMS ENGINEERING CENTER

2

Deirdre Jones

Opening Remarks

3

Objectives

Critical Design Review for Step 1Preliminary Design Review for entire planWill follow up with PDR and CDR for Step 2, etc.

- Each Design Review will include an overview of entire plan with progress and milestones.

30-50 field sites deployed per Step 2, by Feb. 15, 2005Schedule accelerated at direction of Corporate Board, to

enhance system performance b/4 next severe weather season.

4

Team Organization and Responsibilities

Tim Hopkins (OST31) – Project LeadChuck Piercy (OST11) – Program Management and

BudgetWalter Scott (OST11) – COTRDave Holloran (NGIT) – Project ManagerLeigh Dominy (NGIT) – Project EngineerFranz Zichy/Karthik Srinivasan (OST31/OPS12) –

Maintenance and LogisticsMary Buckingham (OPS24) – Operational Assessment

Test DirectorCarl McCalla/Ed Mandell (OST31) – Software

Development and Integration Coordinator

5

Chuck Piercy

Program Management and Budget

6

AWIPS System Architecture

NEXRAD

GOES

ASOS

NCEP Weather Models

Buoys,River Gauges,Lightning, etc.

Terrestrial and Satellite

Communications Systems

Network Control Facility

AWIPS

Firewall

Retrieval, Processing &

Storage Servers

Workstations

Workstations

Workstations

Workstations

LAN

7

Legacy Architecture

PLAINTREESWITCH

HPDS

HPAS

HPWS

100 Mbps FDDI

HP-RTCP

SIMPACT

NEXRADRPG

FIREWALL

LINUXWS

LDADServer

10 MbpsEthernet

10 MbpsEthernet

WAN

ROUTERSIMPACT

Total Processing Capacity: Approx. 900 MFLOPS

8

Linux Phase I Architecture

HPDS

HPAS

HPWS

100 Mbps FDDI

LINUXCP

NEXRADRPG

FIREWALL

LINUXWS

LDADServer

10 MbpsEthernet

10 MbpsEthernet

WAN

LINUXPX

ROUTER

100 100

100PLAINTREESWITCH

10/100/1000 MbpsEthernet Switch

SIMPACT

Phase I Enhancements

Total Processing Capacity: Approx. 3750 MFLOPS

9

Linux Phase II Target Architecture

ROUTERLINUX

WS

NEXRADRPG

WANLINUX CLUSTER(s)

Ethernet 1000/100/10 Mbps SWITCH

LINUXPX

ASREPLACE-

MENT

DBSERVER

LDADFW

LDADSERVER

LINUXCP

Total Processing Capacity: Approx. 16,000+ MFLOPS

NEXRADRPG

AHPS Equip

SBN IP Multicast

WFO/RFCArchive

“Local Apps” Server CLUSTER

10

Expected WFO/RFC Hardware Architecture ~July ’05

DS1HP-UX10.2

Plaintree Switch


LDADFirewall

LINUXPX1

LINUXXT

LINUXSX1

Serial MUX

PV

LINUXDX1

LINUXDX2

Network Attached Storage (NAS)

LinuxCP

Router

WANAWIPSWAN

LinuxAX

LDADSERVER

RFCREP

NexradRPG

< 1 yr old

1-2 yr old

2-3 yr old

3+ yr old

Legend

100Mbps FDDI

DS2HP-UX10.2

LINUXLX

11

Operational Concept

Same operational concept, with enhanced computing resources additional storage space and centralized, shared mass storage using Network Attached Storage device.

12

DS/AS Replacement Roadmap

Leigh Dominy (NGIT)

13

Overview

An analysis of technology and development of a “to-be” architecture was initially briefed to the AWIPS Systems Engineering Team (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

DS/AS replacement Redundant LDAD servers

Serial mux upgrade Full DVB deployment 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.

14

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

15

AWIPS To-Be Architecture

Methodology

- Stage hardware, move software when ready

- Reuse hardware to ease transition and allow planned decommissioning

- Deploy flexible availability framework 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)

- Deploy to subset of sites prior to February 2005

16

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 and PX1/PX2 on GbE LAN LDAD firewall upgrade deployed independently

17

Step 1 and Release OB4Hardware Architecture

DS1


LDADFirewall

PX1

LINUXXT

PX2

Serial MUX

PV

DX1 DX2


LinuxCP

Router

WANAWIPSWAN

LinuxAX

LS1

NexradRPG

100Mbps FDDI

DS2

LINUXLX

AS1 AS2

MassStorageBenefits•Solves Active/Active PX problem•DS Mass Storage and AutoLoader can be decommissioned

Issues•Will plaintree swtch handle nfs traffic from DS/AS to NAS?•Does site have footprint for another rack before any old ones are decommissioned?•What is the file structure of the NAS?•Do most decoders use internal storage for temp files?•What kind of NCF monitoring will be available for the NAS?

plaintree

Light Blue or Clear boxes indicates new hardware component 7/30/04

18

Step 1 and Release OB4Software and Data Architecture

DS1 PX1 PX2

PV

LINUXDX1

LINUXDX2NAS

WAN

DS2 AS1 AS2

•Decoders•Radar Processing•Dial Radar•wfoAPI•RMRserver•Radar Server•Radar Text Decoder•WWA Processes•Database Engine•TexDB read/write•OH cron/apps•Shef decoder•MTA/MHS processes•LDAD server•LDAD routers•Listener•Local ldad applications•NWWS Product•LAMP

•Netmetrix•Trap Interceptor (ITO)

•asynchScheduler•Decoders•Metar•Synioptic•RAMOS•Redbook•RadarStorage•DNS•NIS•NTP•JetAdmin•SNMP Agent•NWWS Scheduler•NotificationServer•DamCat(OH)

•LAPS•Data Storage•Site Backup

•IFP•GFE•Decoders•Satellite•Grib•BinLightinig•Maritime•Profiler•Web Server•SafeSeas•CommsRouter•FFMP/SCAN•MSAS

•Decoders•BufMosDecoder•WarnDB•StdDB•Collective•Raob•Aircraft•ACARS•Bufr Drivers•textNotificationserver

•DNS Phase I •DNS Phase I

Bold Underlined text indicates newly ported or moved processes or data

Light Blue or Clear boxes indicate new hardware componentProcesses and/or data are listed underneath corresponding hardware component

7/30/04

19

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

Connect PX1/PX2 to GbE LAN and install PCI-X cards as future AS serial mux replacement once APS port is complete

Most data to the NAS, temporary files continue to be written to local diskPlanning early October OAT to verify DS1/DS2 and PX1/PX2 failover and

NAS data availabilityRequire a full deployment decision in mid-October to complete deployment of

initial 64 sites by 1 Feb 05

20

Step 1- Considerations

Current plan is to move data from DS mass storage and PX PowerVault to NAS

- Limited to 2GB tar files

- Some sites will need to clean up px1data and px2data prior to NAS installation

Rack placement at WFOs

- Early sites will have “extra” rack longer than sites deployed later in 2005

NAS1

10 x 72 GB Raw Disks (RAID 4)

Disks (10): Root/Data (7) + Parity (2) + Hot Spare (1)

Qtree Name Mount pointQuota (GB)

WFOQuota (GB)

RFC

/vol0/.snapshot -- 10 % -- 41.6 41.6

/vol0/home /home 2.0 8.0

/vol0/data_fxa /data/fxa 60.0 60.0

/vol0/data_x400 /data/x400 0.3 0.6

/vol0/awips_GFESuite /awips/GFESuite 35.0 0

/vol0/awips_adapt /awips/adapt 1.0 0

/vol0/data_adapt /data/adapt 2.5 0

/vol0/awips_hydroapps /awips/hydroapps 1.5 55.0

/vol0/awips_gis /awips/gis 0 3.0

/vol0/awips_dev /awips/dev 0.3 0.3

/vol0/data_local /data/local 9.0 1.5

/vol0/DS_shared /DS_shared 1.4 1.4

Total Space Used 154.6 171.4

WFO RFC

Low level Format Capacity (GB per disk) 66.0 66.0

WAFL requirement of 10% (GB per disk) 6.6 6.6

Raw Root/Data Available Capacity (GB) 415.8 415.8

Allocated Capacity (GB) 154.6 171.4

Unallocated Capacity (GB) 261.2 244.4

Network Attached Storage

21

Step 2- Decommission AS1/AS2

Release OB4 maintenance release (OB4.X) 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 processed data

- SX1 for Web Server, local applications and eventually LDAD

- Activate serial mux replacement and ported APS Non-ported software from AS1 to DS2 DX1/DX2 deployed with RH 7.2 as risk reduction

22

Step 2 and OB4.AS/OB5 (w/RH7.2)Hardware Architecture

DS1


LDADFirewall

PX1

LINUXXT

SX1

Serial MUX

PV

DX1 DX2


LinuxCP

Router

WANAWIPSWAN

LinuxAX

LS1

NexradRPG

100Mbps FDDI

DS2

LINUXLX

Benefits•Could stop maintenance on AS’s•Could eliminate 1 rack of equipment•Could decommission FDDI at this point if 100MB boards were cheaper than maintenance.•Start migration of MHS

Issues•Start running X.400 and SMTP in parallel.•Should PX and SX be retrofitted with extra disks?

plaintree


23

Step 2 and OB4.AS/OB5 (w/RH7.2) Software and Data Architecture

DS1 PX1 SX1

PV

DX1 DX2 NAS

WAN

DS2

•Radar Processing•Dial Radar•wfoAPI•RMRserver•Radar Server•WWA Processes•Database Engine•TexDB read/write•OH cron/apps•Shef decoder•MTA/MHS processes•LDAD server•LDAD routers•Listener•Local ldad applications•NWWS Product•LAMP

•Decoders•Metar•Synoptic•RAMOS•Netmetrix•Trap Interceptor (ITO)

•Data Storage•Site Backup

•FFMP/SCAN•SafeSeas•LAPS•MSAS•Text notificationserver•asynchScheduler•NWWS Scheduler•Notification server•DamCrest(OH)**

•Web Server•routerStoreNetcdf**

•Decoders•BinLightning•Satellite•Grib•Maritime•WarnDB•StdDB•Collective•BufMostDecoder•Raob•Aircraft•ACARS•Profiler•Redbook•RadarStorage•RadarMsgHandler•RadarTextDecoder•HandleGeneric•Bufr Drivers•CommsRouter•DNS•NIS•NTP•JetAdmin replacement•SNMP Agent•SMTP MTA/MHS•Xyplex hosting

•IFPServer•GFE

Bold Italicized text indicates moved processes Bold and underline indicates newly ported processes

Light Blue or Clear boxes indicate new hardware componentProcesses and/or data are listed underneath corresponding hardware component 7/30/04

*Serial MUX is an AS Decommissioning dependency**Requires prototype testing

24

Step 2- Incremental Activation

Failover scheme

- DX1 to DX2

- DX2 to DX1

- PX1 applications and servers to DX2

- PX1 processes APS and NWWSProduct to SX1 (require PCI-X card 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)

Provide sites with some level of performance improvement as early as software readiness allows

25

Step 3 – Deploy Data Base and OS

Deploy Linux PostgreSQL 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

- May be accelerated to OB5 for fxatext database Migrate ported databases

Upgrade operating system (currently RHE3.0) on all applicable hosts LX/XT CP (if full DVB deployment complete)

DX AX

PX/SX RP (RFCs only)

26

Step 3 and OB6 (w/RHE3.0)Hardware Architecture

DS1


LDADFirewall

PX1

LINUXXT

SX1

Serial MUX

DX1 DX2


LinuxCP

Router

WANAWIPSWAN

LinuxAX

LS1

NexradRPG

100Mbps FDDI

DS2

LINUXLX

Benefits•Start Migration of Databases

Issues•When will apps be ready to use PostgreSQL?•Data reliability with PostgreSQL•Will there be issues with running Informix and PostgreSQL in parallel?•What is the performance of PostgreSQL?

plaintree


PV PV

27

Step 3 and OB6 (w/RHE3.0) Software and Data Architecture

DS1 PX1 SX1DX1 DX2NAS

WAN

DS2

•Radar Processing•Dial Radar•wfoAPI•RMRserver•Radar Server•WWA Processes•Informix Database Engine •LDAD server•LDAD routers•Listener•Local ldad applications•NWWS Product



•FFMP/SCAN•SafeSeas•LAPS•MSAS•Text notificationserver•asynchScheduler•NWWS Scheduler•Notification server•DamCrest(OH)**•LAMP

•Web Server•routerStoreNetcdf**•ldadMon

•PostgreSQL Database Engine•OH cron/apps•Shef decoder•TextDB read/write•Decoders•BinLightning•Satellite•Grib•Maritime•WarnDB•StdDB•Collective•BufMostDecoder•Raob•Aircraft•ACARS•Profiler•Redbook•RadarStorage•RadarMsgHandler•RadarTextDecoder•HandleGeneric•Bufr Drivers•CommsRouter•DNS•NIS•NTP•JetAdmin replacement•SNMP Agent•SMTP MTA/MHS•Xyplex hosting•MHS Processes

•IFPServer•GFE

Bold and underline indicates newly ported processes


7/30/04

PV PV

•PostgreSQL Database

28

Step 3 – Incremental Activation

Decommission AS 2.1 and HP Informix HP Informix engine can remain on DS for site use Transition to SMTP and decommission x.400 Consideration - Can/should PostgreSQL be delivered early 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?

29

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

30

Step 4 and OBx Hardware Architecture

DS1


LDADFirewall

PX1

LINUXXT

SX1

Serial MUX

DX1 DX2


LinuxCP

Router

WANAWIPSWAN

LinuxAX Nexrad

RPG

100Mbps FDDI

DS2

LINUXLX

Benefits•Move old LS1 to internal LAN

Issues•Transition from LS to LSx needs to consider how/when local ldad apps will be done.•Do we run old LS and new LSx in parallel while sites convert their local software?•Int/Ext Ldad software must be ready to transition at the same time.•Could reuse PX1 and SX1 for LSx1/2 and buy higher end machines for PX1 and SX1

plaintree


PV PV LSx1

LS1

31

Step 4 and OBx Software and Data Architecture

DS1 PX1 SX1DX1 DX2NAS

WAN

DS2

•Radar Processing•Dial Radar•wfoAPI•RMRserver•Radar Server•WWA Processes•NWWS Product



•FFMP/SCAN•SafeSeas•LAPS•MSAS•Text notificationserver•asynchScheduler•NWWS Scheduler•Notification server•LAMP•DamCrest(OH)**

•Web Server•routerStoreNetcdf**•ldadMon•LDAD Server•LDAD routers•Listener•Local ldad applications

•PostgreSQL Database Engine•OH cron/apps•Shef decoder•TextDB read/write•Decoders•BinLightning•Satellite•Grib•Maritime•WarnDB•StdDB•Collective•BufMostDecoder•Raob•Aircraft•ACARS•Profiler•Redbook•RadarStorage•RadarMsgHandler•RadarTextDecoder•HandleGeneric•Bufr Drivers•CommsRouter•DNS•NIS•NTP•SNMP Agent•SMTP MTA/MHS•MHS Processes•JetAdmin replacement•Xyplex hosting

•IFPServer•GFE



7/30/04

PV PV


LSx1

•LDAD Server Applications

32

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)

33



LDADFirewall

PX1

LINUXXT

SX1

Serial MUX

DX1 DX2


LinuxCP

Router

WANAWIPSWAN

LinuxAX Nexrad

RPG

LINUXLX

Benefits•FDDI and DS decommissioned.•Reuse of LS for SW that isn’t proted yet. (non-redundant)•Rack consolidation

Issues•Dialup and wfoAPI may still be needed on an HP-UX machine•Netmetrix at HUB sites needs to be on HP-UX


PV PV LSx1

LS1

Not Upgraded•Printers•Xyplex•Modems•VIR’s•Simpacts

DX3(optional)

34


PX1 SX1DX1 DX2NAS

WAN

LS1

•Radar Processing•wfoAPI•RMRserver•Radar Server•WWA Processes•NWWS Product

•Decoders•Metar•Synoptic•RAMOS

•Data Storage•Site Backup•Trap Interceptor (ITO)



•PostgreSQL Database Engine•OH cron/apps•Shef decoder•TextDB read/write•Decoders•BinLightning•Satellite•Grib•Maritime•WarnDB•StdDB•Collective•BufMostDecoder•Raob•Aircraft•ACARS•Profiler•Redbook•RadarStorage•RadarMsgHandler•RadarTextDecoder•HandleGeneric•Bufr Drivers•CommsRouter•DNS•NIS•NTP•SNMP Agent•SMTP MTA/MHS•MHS Processes•JetAdmin replacement•Xyplex hosting

•IFPServer•GFE



7/30/04

PV PV


LSx1


•DialRadar•Netmetrix

DX3(optional)

35

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

36



LDADFirewall

PX1

LINUXXT

SX1

Serial MUX

DX1 DX2


LinuxCP

Router

WANAWIPSWAN

LinuxAX Nexrad

RPG

LINUXLX


PV PV LSx1

LS1

Not Upgraded•Printers•Xyplex•Modems•VIR’s•Simpacts

DX3(optional)

37


PX1 SX1DX1 DX2NAS

WAN

LS1

•Radar Processing•wfoAPI•RMRserver•Radar Server•WWA Processes•NWWS Product

•Data Storage•Site Backup•Trap Interceptor (ITO)



•PostgreSQL Database Engine•OH cron/apps•Shef decoder•TextDB read/write•RadarStorage•RadarMsgHandler•RadarTextDecoder•HandleGeneric•DNS•NIS•NTP•SNMP Agent•SMTP MTA/MHS•MHS Processes•JetAdmin replacement•Xyplex hosting

•IFPServer•GFE

Bold and italicized indicates newly ported processes


7/30/04

PV PV


LSx1


•DialRadar•Netmetrix

DX3(optional)

•Decoders•BinLightning•Satellite•Grib•Maritime•WarnDB•StdDB•Collective•BufMostDecoder•Raob•Aircraft•ACARS•Profiler•Metar•Synoptic•Redbook•RAMOS•Bufr Drivers•CommsRouter

38

High Level Schedule

Key dates

- Step 1 Deployment Decision by 21 October -necessary to complete initial deployment by 1 Feb

- Step 2 OB4.X – will provide performance improvements to Step 1 sites

- OB6 check-in

Task

OB5 Check-in

notif icationServer

Step 1-OAT

Step 1-Initial Deploy * Deploy DecisionOB5 Beta

Step 2-OB4.x Test **Accelerate if possible

Step 2-OB4.x-Deploy

Step 1- Full Deploy

OB5 Full Deployment

Step 3-DB Availability

Step 3- RHE3 procure

OB6 code check-in

OB6 Beta

Jul-05 Aug-05 Sep-05Mar-05 Apr-05 May-05 Jun-05Nov-04 Dec-04 Jan-05 Feb-05Jul-04 Aug-04 Sep-04 Oct-04

39

DX/NAS OAT

Mary Buckingham

OPS248/10/04

40

DX/NAS OAT

OAT begins about 9/30Need for early hardware deployment decision (by mid Oct)

- Risk hardware issues might not surface in so short a time- Can’t stress hardware much within these constraints- Possible a severe problem surfaces in operations - would affect

entire scheduleWill take 60 days to finish OAT to ensure installation or

software issues are found and fixedCombine with Serial MUX Replacement OAT

41

Preliminary Mod Note proof on NMTW 12 Test sites 1 RH (1st site, safest) 1 RFC 1 NCEP 9 WFO OB4 Prerequisite (Begin 9/23) - Will affect pace of installations Conflicts with VTEC and Watch by County ORDs (8/30-10/13) Sites selected based on:

- History of poor performance and risk in severe wx- Cover the spectrum of site types- Space for new rack

DX/NAS OAT

42

Risk Factors- Expect similar installation issues as encountered in PX install- Repointing all databases to new location (NAS)- Unknown local mounts- Rush on decisions and limited sites mean risk of not finding install or operational

issues until deployment Unknown how much relief step 1 will give sites

- Faster I/O should help but more problems might lurk OCONUS sites: unknown whether standard system will help their severe

problems- Additional engineering might be required- OAT will give info on whether more is needed

DX/NAS OAT

43

DS/AS Replacement Project Step 1

Software Development and Integration

No software development needed for Step 1

44

DS/AS Replacement Project Step 1

Maintenance and Logistics

Franz Zichy/Karthik Srinivasan (OST31/OPS12) – Maintenance and Logistics

45

Maintenance and Logistics Concept

Integrated logistic supportMaintenance and logistics conceptMaintenance policy and procedureDisposal ProcedureM&C of NAS, DX1 and DX2

46

Integrated Logistics Support

Supply Support Determine LRU

• DX1, DX2 cpu’s• NAS• Ge Switch• Miscellaneous (cables, manuals, etc)

- Assign Agency Stock Numbers (ASN)- Catalog [(p/n, price, manufacturer)]

47


OPS12 provides TIP (Technical Information Package)

- Inform field

• Schedule

• Technical specifications

• Maintenance concept

• Logistic concept NGIT will provide NRC with DX1/2 Checkout procedures NRC receives spare DX1/2servers

48


failed component tested.- Vendor notified of failed component

Components divided into LRUs and placed into stock at NLSC.- servers

- switches

49

Maintenance Concept

Linux device faults

HardwareFailure?

SoftwareFailure?

Ask site to ordernew Linux device

from CLS

NetworkFailure?

Call NCFopen trouble

ticket

Can it be repaired w ithNGIT/SST resources?

Yes

Linux Hardware Resolution Flowchart

Is it external to thedevice?

Yes

Use NGITresources to repair

Yes

EndClose Trouble

Ticket

Yes

Does newdevice work

Yes

ContinueTroubleshooting

No

A

A

Does devicework

No

Yes

Open DR/providework around until

next M R

No No

No

Use NGIT/SSTresources to repair

Yes

No

50

Maintenance Concept

Linux device fails- Open trouble ticket with NCF

• Hardware

• Network

• Software

- Hardware failure• Order new from CLS

- Network failure• If external, use NGIT resources

to repair

• If internal, order new from CLS

51

Maintenance Concept

Software failure- Open DR and/or provide work around until next MR- OS only in step 1

Linux hardware failure- Order new LRU from CLS- Once received, ship defective unit back in same container- Call NCF- Install new device- Site works with NCF to recover/configure device

52

Disposal of Existing Equipment

No disposal in Step 1

53

Monitor and Control

M&C of DX1 and DX2 will be through Xyplex

M&C of NAS will be through Xyplex

54

Security

Complying or will comply with all existing pertinent security policies, directives and rules

No known issues with Step 1

55

Installation Coordination Issues

Direct Ship from staging site in Chantilly to sites New Rack Requires Space and Power

- Similar to REP

Maintenance & Logistics issues- Spares for infant failures

- Deployment support

56

AWIPS DS/AS Replacment Step 1

Major Schedule Milestones

Initial SET Brief

PECP delivered

Task Authorized

Critical Design Review(CDR)

FMK Development

Mod Note Complete

Operational Assessment Test

Full Deployment

Feb04 Apr04 Jun04 Aug04 Sep04 Oct04-Feb05

8/10

9/288/30

9/29

1/6/05 2/16/05

10/6

10/29

9/28

6/23

2/34/26

57

Risks

NAS Single point of failureOld HP’s and FDDI to new GE and NAS Re-engineer of failover

58

Action Item Review

59

Deirdre Jones

Closing Remarks

Date post:	12-Jan-2016
Category:	Documents
Upload:	tivona
View:	89 times
Download:	0 times

DS/AS REPLACEMENT STEP 1 CRITICAL DESIGN REVIEW 8/10/04 Tim Hopkins

Documents