Billy G. Olsen, PE Hydrologist In Charge NWS – ABRFC – Tulsa, OK NWS RFC SERVICE BACKUP...
-
Upload
kristian-melton -
Category
Documents
-
view
217 -
download
0
Transcript of Billy G. Olsen, PE Hydrologist In Charge NWS – ABRFC – Tulsa, OK NWS RFC SERVICE BACKUP...
Billy G. Olsen, PEHydrologist In Charge
NWS – ABRFC – Tulsa, OK
NWS RFCSERVICE BACKUP
DISCUSSION
HIC CONFERENCE
31 July 2008
POINT OF DISCUSSION
Current circumstances in AWIPS-II & CHPS planning activities provide a refreshing opportunity to address NWS RFC Service Backup
Potential for RFC service backup to finally go mainstream with national support
How do we take advantageof this opportunity?
CURRENT RFC SERVICE BACKUP STATUS
Various unique local/regional hardware and data ingest/dissemination configurations
One commonality is RFC self-backup
Systems are not supported nationally
RFC BACKUP OPERATIONS NATIONAL PLANNING TEAM
Post-Katrina
Chartered May 2006 (Feb 07, Mar 07, Jan 08)
Currently on hold based on AWIPS-II uncertainties
NATIONAL PLANNING TEAMTEAM CHARTER FOR RFC BACKUP OPERATIONSVision: A robust operational scheme which supports operational backup of River Forecast Centers (RFC)
in time scales of hours to weeks.
Mission: Review current national and regional policies and procedures for RFC backup operations. Define necessary operational concepts for RFC backup. Identify operational and system requirements to implement the operational concepts. Develop the OSIP Stage 2 Concept of Operations (ConOps) and Operational Requirements Document (ORD).
Scope of Authority/Limitations: Team will review NWSI 10-2201, Backup Operations, and appropriate Regional Supplements. Team will review the Hurricane Katrina Service Assessment, especially the findings and recommendations related to RFC Backup, as well as the report on LMRFC backup operations compiled by a sub-team. Team should consider lessons learned and past practices from previous RFC backup operations, as well as various operational concepts, including Service Backup, Computational Backup, Local Backup, and others as appropriate, in developing an RFC Backup ConOps Team will consult with internal and external partners and customers, as needed Organizational allegiances among the team members must not be allowed to influence either the evaluation or the recommendations The team will make decisions by consensus The team will solicit/incorporate minority opinions if decisions are not reached by consensus No travel expenses will be authorized Team membership will be comprised of representation from OHD, OCWWS/HSD, NWS Regions, and OST.
Termination Date: The team will complete its work within 6 months of its formation.
Success Criteria/Deliverables: Deliver a Concept of Operations (ConOps) and Operational Requirements Document (ORD) which will constitute the OSIP Stage 2 documentation
Commencement & Termination Date:• The team will be formed and commence activities by March 9, 2007 and deliver its final report and briefing by September 31, 2007Team Membership – Representatives From:SR – Eric Jones, Senior Forecaster, LMRFC, Team LeaderCR – John Halquist, DOH, NCRFCWR – Harold Opitz, HIC, NWRFCAR – Dave Streubel, Senior Hydrologist, APRFCER – Joe Heim, Senior Forecaster, OHRFCOCWWS – Randy Rieman, Senior Support HydrologistOHD – Jon Roe, Chief, OHD Software Engineering Branch, or designeeOST – TBD
OSIP 07-056 River Forecast Center (RFC) Backup Initiative
IWT Lead:Randy Reiman OCWWS/HSD
Current IWT Members:
OHD, John Halquist (CR), Harold Opitz (WR), Robin Radlein (AR), Joe Heim (ER), Jeff Zimmerman (OCWWS/HSD), Leroy Spayd (OCWWS), Albert Mongeon (OOS/MLAD), Brian Doerk (OCIO), Jim Lane or designee (OS&T)
Latest Review Team Meeting Notes:
Conditions: (1) Clarify SON to be more direct about goals, and to include linkages to related projects: AWIPS Evolution - #04-005, RFC Archive Server Tech Refresh Initiative - #07-054, and RFC AWIPS Configuration #07-059 (2) Revisions to Project Plan to include additional team members, clarify objectives, address AWIPS related risk factors, linked projects, and other revisions.
Recommendation: Conditional ApprovalStrategic Priority:Moderate; Operational: High
Latest Gate Meeting Notes:
Virtual Gate 1; January 17, 2008. Gatekeepers [D. Manning (ER), A. Edman (WR), D. Carpenter (AR), D. Page (OHD), C. Diaz (OS), R. Billingsley (SR), M. Hudson (CR) M. Paese (OPS), D. Jones (OST)]
Disposition: ApproveVote break down: approve - ER,CR,WR, SR, OPS, OS, OST, OHDconditionally approve AR...ensure the scope of the project is clear. Is the intent to develop a COOP for RFCs or not. If so concerned this is not the right venue. SON and PP should clearly state the intention of the project.CR suggested the capability used at eht NCRFC and MBRFC should be looked at as a possible solution in the future stages.
OSIP 07-056 INTEGRATED WORK TEAM (IWT)
Organization Identify Lead Role
OCWWS/HSD Randy Rieman IWT Lead
Southern Region Eric Jones, Senior Forecaster, Lower-Mississippi RFC Team Member
OHD Jon Roe, Hydrologic Software Engineering Branch Team Member
Central Region John Halquist, Development Operations Hydrologist (DOH), North Central RFC
Team Member
Western Region Harold Opitz, Hydrologist in Charge (HIC) North-West RFC Team Member
Alaska Region Dave Streubel, Senior Hydrologist, Alaska-Pacific RFCRobin Radlein Supervisory Hydrologist
Team MemberTeam Member
Eastern Region Joe Heim, Senior Forecaster, Ohio RFC Team Member
OCWWS Leroy Spayd Management Oversight
OCWWS/HSD Jeff Zimmerman OCWWS/HSD Lead
OOS/MLAD Albert Mongeon Team Advisor
OCIO Brian Doerk Technical Advisor
OS&T Jim Lane or designee Technical Lead
OSIP Analyst Chris Holte (OHD) Project Support
RELATIONSHIP OF CHPS AND RFC BACKUP
FEWS design offers local high availability system as well as on/off site backup capability
Experience with UK & European systems
Flexible system allows working within a budget
Synchronization relates to IHFS & OFS “type” data
At first glance…bandwidth appears manageable
CHPS AND RFC BACKUP --- See CHPS WIKI Page ---
CHPS AND RFC BACKUP - Preferred Configuration
CHPS AND RFC BACKUP - Flexibility
FCST Shell& MasterControllerOn OnePlatform
CHPS AND RFC BACKUP
Standby atOther RFC
CHPS AND RFC BACKUP – Fully Synchronized Operator Client
RELATIONSHIP OF AWIPS-II AND RFC BACKUP
Concept of Operationsand
Operational Requirements
AWIPS Thin ClientOSIP Number: 08012
July 21, 2008
Steve Schotz - NWS/OST/PPD/SPB - Team Lead Ronla Henry - NWS/OST/SEC/DB Bill Ward - NWS/PR/ES&SD Duane Carpenter - NWS/AR/ESSD Heath Hockenberry - NWS/OCWWS/MSD/FPWSB Cyndie Abelman - NWS/OCWWS/MSD/AWSB Scott Jacobs - NWS/NCEP/NCO/SIB Richard Jesuroga - OAR/GSD Sher Schranz - OAR/GSD Eric Howieson - NWS/SR/SOD/SIB Mark Mollner - NWS/WR/SSD Josh Watson - NWS/ER/SSD Michael Graf - NWS/OCWWS/MSD/AWSB Gregory Noonan - NWS/CR/MSD
AWIPS-II THIN CLIENTThe Advance Weather Interactive Processing System-II (AWIPS-II) will provide a robust and flexible infrastructure for NWS forecast operations. Upon deployment, AWIPS-II will provide the functional equivalent of today's baseline software through AWIPS-I Operational Build (OB) 9. Currently, AWIPS-I does not include integrated enterprise solution to support the following missions: Center Weather Service Units (CWSUs) Weather Service Offices (WSOs) Incident Support Specialists (ISS) including Incident Meteorologists (IMET) NCEP Centers to partially support their Continuity of Operations (COOP) requirements and remote access requirementsThese program areas require remote access to AWIPS capabilities to support their mission requirements.The purpose of this AWIPS Thin Client project is to develop and deploy an integrated thin client solution that will satisfy the NWS enterprise requirements for remote access to AWIPS-II capabilities. The thin client capabilities must support the operational needs of the mission areas defined above. NWS has an existing thin client capability provided by FX-Net. However, FX-NET only partially addresses NWS AWIPS remote access requirements. In addition, FX-Net is built on the original AWIPS-I architecture. Without an integrated thin client capability, NWS would be forced to maintain and enhance the original AWIPS-I baseline or enhance FX-NET to interface with the AWIPS-II baseline. This would duplicate software O&M efforts.
The Thin Client project planning and development will be led by the NWS in partnership with the NOAA Earth System Research Laboratory, Global Systems Division (GSD) and Raytheon Technical Services (RTS), the AWIPS-II prime contractor. Once developed, the thin client will become part of the AWIPS-II baseline and supported by RTS, accordingly.
The Thin Client project is part of the second phase of the AWIPS Technology Infusion project (OSIP 04-005) that extends the AWIPS-II architecture to all levels of NWS operations.
4.3 NCEP ScenariosUser: All NCEP forecastersAction: Continuity of Operations Plan (COOP) ImplementationThe National Centers have requirements to maintain the level of product creation during a COOP event. The Centers would use the Thin Client during the transition period from the main site to the backup site. In some short-lived situations, the use of the Thin Client may be preferable to fully activating the backup site.
AWIPS-II THIN CLIENT
NCEP plans to use for backup (COOP)
Thin Client Schedule07/01/08
I.High-Level Schedule
Major Deliverable(s) - OSIP Stage Milestone
Deployment – Stage 5 3Q FY11
Development – Stage 4 FY10
Applied Research, Technical Requirements, Business Case Analysis – Stage 3 FY09
Concept of Operations and Operational Requirements Document (ConOps) – Stage 2 FY08
I.FY08 Proposed Stage 2 Schedule
AWIPS-II THIN CLIENTSCHEDULE – OSIP 08-012
OSIP Deliverable Date
Gate 2 Disposition 9/30/08
Gate 2 Team Review 9/19/08
OST Gate 2 Internal Review 9/12/08
Final Draft ConOps to OSIP Site 9/5/08
IWT Draft ConOps Comments Due 8/22/08
Second Draft ConOps Document including Requirements Section 8/07/08
Telecon to Brain Storm Requirements (if needed) 7/29/08
Telecon to Review Consolidated Sections 1-7 and Brain Storm Requirements 7/22/08
First Draft Sections 1-7 (Sans requirements) 7/18/08
RFCs NeedTo ActNow !
AWIPS-II THIN CLIENTTECHNOLOGY QUESTIONS
Thin clientFrom Wikipedia, the free encyclopedia
A thin client (sometimes also called a lean or slim client) is a client computer or client software inclient-server architecture networks which depends primarily on the central server for processing activities, and mainly focuses on conveying input and output between the user and the remote server.
In contrast, a thick or fat client does as much processing as possible and passes only data for communications and storage to the server.
Many thin client devices run only web browsers or remote desktop software, meaning that all significant processing occurs on the server. However, recent devices marketed as thin clients can run complete operating systems such as Debian GNU/Linux, qualifying them as diskless nodes or hybrid clients.As a consequence, the term "thin client", in terms of hardware, has come to encompass any device marketed as, or used as, a thin client in the original definition – even if its actual capabilities are much greater. The term is also sometimes used in an even broader sense which includes diskless nodes. [1]
RFC BACKUP IN THE CHPS / AWIPS-II ENVIRONMENT
?
SOME OPTIONS ARE…
WHERE DO WE GO FROM HERE?
A) Sort out bureaucracy (teams / projects)
B) Re-Start National RFC Backup Team (liaison w/CAT & Thin Client Teams)
1) Same team as previously (National RFC Bkup)2) Same team as OSIP IWT 07-056 (RFC Bkup)3) Add new team member(s) from CAT RFC(s)4) Form new team
C) CAT becomes responsible for RFC Backup planning (liaison w/Thin Client Team & RFCs/Regions)
D) Add an RFC Rep to Thin Client Team (liaison w/CAT & RFCs/Regions)
E) Other ideas
---END---