Download - M4 Design and Features Review January 2007
M4 Design and Features Review January 2007
M4 Technical Committee Review of the Final M4 Design and Features
January 11, 2007
Meeting Agenda
9:00 AM – 9:45 AM
Introduction•Review M4 Project Objectives•Review Project Milestones•Project Status and Schedule•Meeting Objectives
10:00 AM – Noon
System Design and Configuration•Target Platforms and Development Toolsets•Revised System Architecture•Data and Topology Configuration
Noon – 12:30 Working Lunch (provided)
12:30 – 4:30 PM
System Features•M4 Client•Data Submission•Legacy Data Migration•Failover
January 11, 2007
M4 Project Objectives
M4 application to replace legacy MiniMon and MultiMon applications and will run on current Microsoft Windows platforms with the following objectives:
1. All interrogation data collected by this system will be 100% valid.
2. Interrogation data will be provided to PTAGIS in “near-real” time.
3. 99.9% uptime of all system components.
4. SxC functionality must have as good or better efficiency as MULTIMON.
5. Interface with G2 readers and all legacy hardware.
6. Interface with PTAGIS data management systems.
7. Ease of use.
8. Common application for all deployment scenarios.
9. Monitoring will take precedence over SxC control operations.
10.Provide, as an option, continuous operation with automated fail-over from system or application faults.
January 11, 2007
M4 Project Milestones
Project Milestones from M4 Delivery on PTAGIS Wiki
January 11, 2007
Project Status
• Large portion of project already implemented as M4 alpha release
• Decision to drop Marathon platform and provide custom failover solution
• Development put on hold as of 10/2006 per failover decision
• Architecture revised to include requested features for software failover
• Completion of PLC communication evaluation
• Presentation of revised architecture and design to M4 Committee for approval
• Review and finalize SxC requirements
• Continue production of M4 development
January 11, 2007
Project Schedule Proposal
• Jan. 2007: M4 Committee approves the revised design of M4; SxC requirements are reviewed by the SxC Subcommittee
• Feb. 2007: SxC requirements are complete and approved by SxC Subcommittee
• June 2007: Delivery of a beta M4 that performs basic monitoring and data-submission
– Some basic regression testing on SxC alpha releases throughout summer
• Sept. 2007: Delivery of a beta M4 that performs all functions including SxC and fail-over
– Thorough regression testing and tuning are performed on the beta
– Live fish test is scheduled to evaluate performance of tuned SxC
• Sept. 2007: Delivery of MobileMonitor 2.0 that interfaces with M4 beta
• Dec. 2007: M4 Committee approves production release of M4
January 11, 2007
Meeting Objective
To begin production development, the M4 Committee will need to approve the following:
1. Project Schedule Proposal
2. Development Tools and Target Platforms
3. Revised System Architecture
4. Topology Configuration Features
5. M4 Client Features
6. Data Submission Design and Features
7. Legacy Data Migration Design and Features
8. Failover Cluster Design and Features
January 11, 2007
Development Toolset
The following development tools will be used to develop M4:• .NET Framework 2.0 and C# Language
– .NET Framework 3.0 is considered for Windows Communication Foundation to replace 2.0 Remoting features and includes Windows Vista support.
• SQL Server Express (client database)– Free, lightweight and popular– Ease of integration and management in .NET; XML support– File-based deployment; automatic tuning and patching– Powerful, reliable, secure and scalable– Reporting and Replication Services
• SQL Server Standard (data submission staging database)– Low TCO: pricing supports low-connectivity with large data volumes– Hosts native XML Web Services without need for IIS– Processor License: $6K; Server + 5 CALS: $2K + $162 additional CAL
• Parijet PLC Communication Library
January 11, 2007
Target Platforms
M4 will support the following platforms:
• Windows XP SP2 or better
• Windows 2003 Server
• Windows Vista
• Windows 2000*
*Windows 2000 will not be supported if .NET 3.0 is used
Failover Cluster Requirements:
• Windows 2003 Server– Redundant NIC card supporting fail-over (Private Network)– Single NIC card (Public Network)– High Performance System (dual-core, 2GB, RAID)
January 11, 2007
Supported Devices
Device DESCRIPTION PROTOCOL COMMUNICATION
FS2001 ISO Digital Angel Portable Reader ASCII Serial
FS1001 Digital Angel Juvenile Stationary Reader
ASCII/BPA Serial
FS1001A Digital Angel Adult Stationary Reader
ASCII/BPA Serial
FS1001M Digital Angel Multiplexer Reader
ASCII Serial
B2CC-G2 Digital Angel B2CC Reader XML Serial/Ethernet
G2 MUX Proposed In-stream Reader ASCII USB Driver
GPS Global Positioning System NMEA Serial
SLC-500 Programmable Logic Ctrl. ENETIP Ethernet
January 11, 2007
Revised System Architecture
Online Revised M4 System Architecture
January 11, 2007
M4 Data
The advantages of storing data into a structured database instead of text file:
• Data is relational in nature (status reports linked to topology version)
• Data retrieval for robust reporting and viewing on the client
• Database can be secured
• Adaptable: new types of messages can be easily added to system
• Reliable: data is stored immediately into database and not bufferedDeviceMessage
MessageKey
TopologyKey
SiteCode
AntennaGroupID
DeviceID
AntennaID
Buffered
MessageMessageKey
MessageType
LocalTimeStamp
PSTTimeStamp
Processed
MessageTextMessageKey
LineNumber
MessageText
MessageTypesMessageType
MessageTypeDescription
January 11, 2007
Message Data
M4 collects a variety of messages (data) from various sources:• Device• System (application and OS)• Separation-by-Code Operations• Failover Operations
Each message has the following attributes:• Timestamp in Local and PST time (with millisecond resolution)• Source information (machine, topology, device, SxC, application type)• Message Type:
– Real-time or buffered tag
– Device (alarms, status, noise, GPS coordinates)
– Monitor operation (start, stop, pause, system status, pulse)
– Error (system and device)
– SxC operation data
– Failover (planned, system fault)
January 11, 2007
Topology Configuration
• Topology configuration describes a set of physical devices and their topologic relationships that provide instrumented monitoring at one or more interrogation sites over a period of time
• It provides location-specific context to interrogation data
• A version of a topology configuration has a one-to-one relationship with collected data; M4 maintains this historical relationship between topology version and data
• Topology information is submitted to PTAGIS and integrated into SiteConfig data table
• Topology configurations are managed by a version number
January 11, 2007
Topology Component Relationships
Topology
Site
Site
Site
Antenna Group Antenna Group
Reader Device
Reader Device
Reader Device
Reader Device
January 11, 2007
Topology Component Relationships
Topology
Site
Reader Device
Antenna
Antenna
Antenna
Antenna
Trigger Device
Trigger Device
Trigger Device
January 11, 2007
Topology Component Features
Description Provides a detailed description for this topology
Version* Major version and revision number, i.e. 1.5
Created* Date version was created
Modified* Date version was last modified
Activated* Date topology was activated (data collected)
Expiration* Date topology expired
State* Current Topology Lifecycle States: New Pending Active Expired
*Read Only
January 11, 2007
Site Component Features
Site Code Three character code assigned by PTAGIS
Description Description of interrogation site
Type Type of site: Juvenile (mainstem) Adult (mainstem) In Stream
Location Optional: Lat/long pair representing location of site
Supports SxC True if SxC operations occur at this site
January 11, 2007
Antenna Group Component Features
Description Verbose detail about this grouping of antennas
Sorting Sequence Provides logical sorting in relation to physical layout of antenna groups
Site Entrance True if located at entrance of a site
Site Exit True if located at exit of a site
Final Disposition Information on fish disposition after leaving antenna group:UnknownIndeterminateRiverTransportationSample TransportationSMP
Location Optional: Lat/long coordinate pair.
January 11, 2007
Device Component Features
Device ID Two character hexadecimal unique identifier assigned by PTAGIS
Description Optional: Verbose description of device
Device Type Type of device: F1001 FS1001A FS1001M FS2001 FS1001G2 GPS SLC500 B2CC
Data Protocol Communication protocols: ASCII Binary (BPA) NMEA SLC500 XML
January 11, 2007
Device Component Features Continued
Port Type Type of Communication Port: Serial (RS-232) UDP TCP
Port Communication port (serial: COM1, TCP: 1599)
Ethernet Settings Ethernet communication settings: Host Name Remote Port
Serial Settings Serial communication settings: Baud Rate Parity Data Bits Stop Bits
Location Optional: Lat/Long coordinates of device
January 11, 2007
Mux Antenna Component Features
Antenna ID Two character hexadecimal unique identifier assigned by PTAGIS
Alias ID Optional: two character hexadecimal site unique identifier to bypass current PTAGIS limitations.
Description Optional: verbose description of antenna placement
Location Optional: lat/long coordinates of antenna
January 11, 2007
Gate Component Features
Description Verbose Description of Gate
Type Type of gate: Two Way Three Way
Address PLC bit-mask address of a physical gate
Delay Period Period in milliseconds to delay before opening gate
Location Optional: lat/long coordinates of gate
January 11, 2007
Creating or Modifying Topology Configuration
M4 distinguishes between two types of topology changes:
• Major Changes– Adding or removing a topology component (device, antenna, gate)– Renaming a device id, mux-antenna identifier or site code– Changing the relationship between any of the components, i.e. moving a device
from one antenna group to another– Changing the type of a device
• Minor Changes– Changing a serial port or other serial or Ethernet setting– Changing data protocol or port type for a device– Changing the description of a component– Changing any of the gate settings.
January 11, 2007
Topology Versioning Rules
• Major changes require a new topology version– Topology version number will increment (example 1.0 to 2.0)– A new topology can be created while monitoring with the New Topology Manager– User activates a new topology and restarts the monitor to use the new topology
version– User can import a new topology version from a file.
• Minor changes can be made to the active topology version– Topology version number will increment (example 1.0 to 1.1)– Monitor must be stopped to make minor changes– User performs minor changes from the Topology Viewer
January 11, 2007
General Topology Rules
1. A valid topology version must exist before the monitor can start• M4 will be installed with a default, empty topology version (0.0)• Any start actions will be disabled if version is not valid• Starting monitor from Service Control Manager will fail and generate an error• A valid topology version has:
• At least one site defined• At least one reader device defined for a site• Any antenna-groups must contain two or more readers• All mandatory settings for each component are specified and
valid• Only one device can be enabled for a single port address
2. Importing a topology version will create a new topology version
3. Topology configuration will override any device id transmitted in data
4. Clustered machines must run the same topology version
5. Any changes to topology take effect the next time the monitor is started
January 11, 2007
M4 Client
January 11, 2007
Behind the Scenes of M4 Client
Primary Server
User Session
System Device.dll
M4 Site Monitor Service SxC.dll
Failover.dll
Client Database
Config.XML
M4Remoting.dll
Failover ServerPrimary ServerUser Session
M4Remoting.dll
System Device.dll
M4 Site Monitor Service SxC.dll
Failover.dll
Client Database
Config.XML
January 11, 2007
M4 Client Features
Topology
Viewer
Data Viewer
Site
Monitor
Device
SxC
Process
Other Topologies
Filter
January 11, 2007
M4 Client Features
January 11, 2007
Additional M4 Client Features
• Data Viewer displays pages of data– Rows per page is user-defined– Sorting Data (TBD)
• Set Data Viewer to Auto-Refresh– Any filters apply– Cannot scroll (only data that will fit in viewer displayed)
• Right-click device to enable or disable• Right-click device or component to generate context-sensitive reports• SxC Operations
– Start/Stop/Refresh SxC Operations independently from stopping/restarting Monitor– Access SxC Configuration (from topology component or menu)
• Export message data in variety for formats (XML, CSV)• Import data from MobileMonitor 2.0 or other M4 installation• User-initiated data submissions to PTAGIS• Reporting: Device Diagnostics, Noise, Tag Hits, Site Operations, Antenna-Group
Efficiency (TBD), SxC Gate Efficiency (TBD)• Manage Application Settings (schedules for upload, trigger devices, pulse records;
failover configuration, upload settings, time zone)• Download Wizard to download stored data from remote readers
– Supports single serial port for multiple remote readers (maps to existing topology)– Converts buffered tags to real-time tags if timestamps are available
January 11, 2007
Creating a New Topology
The New Topology Manager is used to create new topology versions
• Accessed from M4 Client menu• Available even if monitor is running• Create new topology:
– Blank– Existing Topology– Discover– Import
• Provides validation tool• User must activate a new topology
version to be used on restart of monitor
• New topology version can be saved, closed, and updated at a later time
January 11, 2007
M4 Data Submission to PTAGIS
M4 Client
PTAGIS
PIT StagingDatabase
Client Database
LDAP
M4 Site Monitor Service
M4 Client
3. Connect HTTPS/TCP
4. Authenticate/Authorize
5. Upload Outstanding Data
XML
6. Feedback
1. Initiate
WS-PDS Web Service
Upload Manager
2. Read Config.XML
1. Upload process is initiated either automatically or by user
2. Upload Manager reads the configuration file (user, connection)
3. Upload Manager connects to WS-PDS web service at PTAGIS
4. Authentication and Authorization with WS-PDS based upon evidence supplied from client
5. Upload outstanding Topology Versions and Message Data
6. Upload Manager reports feedback from WS-PDS service
January 11, 2007
Data Submission Step 1: Initiating the Upload
Two ways to start an upload:
1. Manual Upload– End-user initiates upload manually by selecting Upload Data command from M4
Client menu– This upload can be initiated independent of the state of the monitor– Feature will allow a user to reset data for resubmission to PTAGIS– User will be provided feedback during the upload process with the ability to
cancel the process
2. Automatic Upload– Data is uploaded to PTAGIS on a user-defined schedule– Monitor must be running– Data will be uploaded on the next scheduled interval when monitor is started (will
not perform a make-up)– Uploading data should not impact performance of the system– Feedback from upload sessions can be viewed from a system report or the Data
Viewer
January 11, 2007
Data Submission Step 2: Read the Configuration File
Before an M4 installation can upload, these settings must be configured from the M4 Client:
SETTING DESCRIPTION
PTAGIS Upload Interval
How frequently the M4 system will automatically upload data to PTAGIS. Zero to disable
PTAGIS Account Name
Name of the PTAGIS user account for authentication and authorization during upload
PTAGIS Account Password
Password associated with PTAGIS account for authentication during uploads. Encrypted.
Use VLAN Connection
Indicates whether to use a TCP connection if VLAN network is configured at the site.
PTAGIS Host Name
Name or IP address of host to query for WS-PDS service
The M4 Client configuration manager will have a Test command to validate the configuration settings with WS-PDF web service.
January 11, 2007
Data Submission Step 3: Connecting to the Web Service
• M4 Upload Manager on client computer queries PTAGIS host server over the network for the existence of the WS-PDS service.
• If service is disabled or network connection fails, upload session is terminated and condition is logged
• For M4 installations within Commission network– Use VLAN setting is true– A faster, more reliable TCP connection is used
• For M4 installations outside of Commission network– An HTTPS connection is used instead– Less prone to Firewall issues
• Note: Windows Communication Foundation in .NET 3.0 simplifies the task of building this web service and communicating with this web service with various network bindings
January 11, 2007
Data Submission Step 4: Authentication and Authorization
Once a connection is established, the client requests authentication and authorization from the WS-PDS web service:
• The PTAGIS user name and encrypted password are sent to WS-PDS.
• WS-PDS queries the PTAGIS LDAP server with credentials for an authorization role (Data Coordinator)
• If authenticated and authorized, upload session will continue
• If not authenticated or authorized, upload session is terminated at both service and client. Condition is logged on both client and server
• PTAGIS personnel can be alerted to any failed connection attempts
January 11, 2007
Data Submission Step 5: Upload Outstanding Data to PTAGIS
Upload Manager is connected and authorized, now it must determine what data to submit:
• Each data message and topology version has a status flag indicating if it has been previously uploaded
• All new topology and message data are packaged together into an XML file (preserving referential integrity) and transferred to the WS-PDS service
• The WS-PDS service verifies the XML file integrity with a file hash:– if file is not valid, it request a resubmission from the client– If file is valid, both client and server consider this a success (in case connection
is broken or database is offline)
• WS-PDS loads data in XML file into staging database on server– XML file is preserved on server for integrity
January 11, 2007
Data Submission Step 6: Upload Session Feedback
• The WS-PDS service provides asynchronous feedback to the Upload Manager residing on the client indicating any exceptions or the success of the loaded data
• If success is reported, Upload Manager updates the status field for all records in the client database that were uploaded in the session.
• The Upload Manager records the session’s success or failure in the client database and Windows Event Log viewer
• Custom alerts can be configured to notify users via email that an upload session failed.
January 11, 2007
Legacy Data Migration
1. Initiate Migration2. Load New Topology Data (alert PTAGIS personnel)3. Update New Message Data4. Update Staging Data State5. Compact Staging Data
PTAGIS Staging
PIT StagingDatabase
Legacy PTAGIS
1. In
itiat
e
PTAGIS3
2. Load New Topology To SiteConfig
4. U
pdat
e
Home/Ptoc/Stage
Int. File
PTTPIDL
3. Load New Message Data
PIT Data Migration Service
5. Com
pact
M4Data
Archive.XML
Ale
rt
January 11, 2007
Data Migration Step 1: Initiate Migration
• Staging database hosts custom SQL Server Integration Service (SSIS) called PIT Data Migration Service (PDMS)
• PDMS can be configured and maintained from SQL Server Management Studio or custom application interface
• PDMS service is initiated automatically upon a user-defined schedule to correspond with existing IDL service for optimum processing of data
• PDMS service can be initiated manually by PTAGIS personnel
January 11, 2007
Data Migration Step 2: Load New Topology Data
• PDMS service performs a query within staging database to determine if any new topology data needs to be migrated
• A report is generated providing a summary of topology changes at each site and emailed to target PTAGIS personnel
• PDMS connects to the PTAGIS3 database and inserts the new topology data directly into SiteConfig schema
• PDMS will alert PTAGIS personnel to any errors or faults
• If PDMS cannot migrate topology data, the migration session is aborted (no data will be uploaded until problem resolved)
January 11, 2007
Data Migration Step 3: Load New Message Data
• PDMS generates an in-memory dataset of all new message data that corresponds to PTAGIS interrogation data specifications with these configurable options:
– Generate real-time tag records only (this could be set for a site-by-site basis)– Sites to exclude (can be set for period of time)– Limit number of real-time tags per second (Unique Off)
• PDMS transforms dataset into standard PTAGIS interrogation data files with these configurable options:
– Allow interrogation data files to span multiple days (generates less files to load)– Suppress interrogation files that do not contain interrogation records
• PDMS submits interrogation records for traditional PTAGIS loading:– Generates XML header for PTTP loading and puts them into staging directory– Submits them directly to IDL
• This method of loading data will ease deployment of M4 with existing client applications (MiniMon/MultiMon)
January 11, 2007
Data Migration Step 4: Update Staging Data
• PDMS service updates data in Staging Database to prevent it from being migrated when the service runs again
• PDMS service can provide a utility to allow a manual reset of select data in Staging Database for reloading to PTAGIS3
• Each data record has a status field that will be used indicate state:– New: (default) generated and stored in M4 Client Database– Uploaded: transferred from M4 Client Database to Staging Database– Migrated: migrated into PTAGIS3 database– Compact: record is compacted in the Staging Database
• The PDMS service logs the success or failure of the migration session to be used for administrative reporting
January 11, 2007
Data Migration Step 5: Compacting the Staging Database
PDMS service will initiate a sub-service, either scheduled or user-driven, to compact the M4 data in the Staging Database:
– All message and topology data older than a designated period of time will lose all of their ancillary data, retaining only the minimum data (keys and state) to prevent duplication.
– Before data is compacted, PDMS will generate an XML file representing M4/MobileMonitor 2.0 data for possible future use.
– The staging database is designed to be a temporary store to facilitate data submission and migration. It is not intended to serve data to a web application.
– If end-users want to use M4/MobileMonitor 2.0 data, they should maintain it on the M4 Client Database.
January 11, 2007
M4 Failover Services
To meet continuous operational requirements, M4 can provide automatic failover with a redundant (clustered) server
• Supports two types of failover conditions:– System or application fault– Planned failover for server maintenance
• Failover service has specific use case scenarios:– Interrogation sites that perform Separation-by-Code operations– Interrogation sites that collect a large segment of PTAGIS data and require
operational redundancy
• Failover is integrated into M4 as a configurable option:– Does not require overhead of maintaining multiple software versions of the same
application– By default, Failover Services are disabled in M4 to reduce complexity for casual
end-user
• Failover Services should not impact system performance
January 11, 2007
Failover Service Architecture and Features
• Two redundant systems host independent M4 monitoring services
– Data is duplicated in separate local databases
– Both process SxC requests• Both systems capture same Serial I/O via
Ethernet using DeviceMaster• Only one system communicates to a PLC
device to provide SxC gate control• Two monitoring services communicate
health status via heartbeat channel– Uses private network with redundant NICs
• M4 Client provides management of failover configuration to end-user
• NTP synchronizes system time between two servers
– provides coarse synchronization of the two sets of data via TimeStamp field
Database
SxC.dll
Device.dll
M4 Site Monitor Service
Failover.dll
SxC.dll
Device.dll
M4 Site Monitor Service
Failover.dll
MS Operating System
Database
MS Operating System
Active Server Standby Server
Private Network
Heartbeat
NTP
RS-232 Devices
DeviceMaster
Public Network
Public or Device Time
Server
PLC
January 11, 2007
M4 Failover Assumptions
To reduce complexity and not impact system performance, the following assumptions for M4 Failover Services:
• System platforms should be identical and configured for high-performance:– Dual or Quad Core, 2GB RAM, RAID– Install transaction log of M4 Client Database on separate partition
• Data is not mirrored between two systems:– Data events are not synchronized and may not be recorded in same order– Data recovery from a failover requires manual user intervention– Data is synchronized with scheduled checkpoints to facilitate data recovery
• Separation-by-Code counters are computed independently on two systems– Counters could be synchronized if necessary
• Heartbeat communication channel represents the single point of failure– No guarantee of failover or gate control if this channel fails
• Topology Versions and SxC Configuration must be identical on both machines
– M4 will detect the topology version and will abort starting the monitor– M4 will provide utilities to push configuration changes between two machines
January 11, 2007
M4 Failover Service States and Cluster Roles
M4 Failover Service Operational States
• Active: monitoring service is controlling separation-by-code gates
• Standby: monitoring service is computing separation-by-code operations but is not controlling the gates
M4 Failover Cluster Roles
Two redundant monitoring services hosted on separate machines will be configured to start as one of two types:
• Primary: service attempts to start in the Active state
• Secondary: service attempts to start in the Standby state and will promote itself to Active if primary system does not respond
January 11, 2007
M4 Failover Service: Primary System Startup Procedures
When Primary server follows this startup procedure:
1. Sends heartbeat message proposing it is the Active service
2. Monitors heartbeat channel for messages from redundant service for a specified period of time (Discovery Period)
3. If it does not receive heartbeat message from an already Active service, it promotes itself as the Active service.
4. If it does receive heartbeat message from an already Active service, it demotes itself as Standby and continues operating in this state.
5. If communication channel fails or no heartbeat message is received at all, it will report failure and send alert, and continue operating in Active state.
January 11, 2007
M4 Failover Service: Secondary System Startup Procedures
When Secondary server follows this startup procedure:
1. Sends a heartbeat message proposing it is the Standby service
2. Monitors heartbeat channel for messages from redundant service for a specified period of time (Discovery Period)
3. If it receives a heartbeat message from an Active service, it resumes operations in Standby state.
4. If it receives a heartbeat message from an Standby service – or receives no message at all, it promotes itself as the Active service.
5. If the heartbeat communication channel fails, it will report the failure and send an alert, however, it will remain in the Standby state.
January 11, 2007
M4 Failover Service: Failover System Procedures
When an Active service fails, the following occurs:
• The failed active service stops sending heartbeat messages
• The standby service notices the active service has not sent a heartbeat message in a specified amount of time (Failover Interval) and promotes itself as active and takes control of the PLC.
• The new active service reports the error and sends any alerts indicating the condition.
When a Standby service fails, the following occurs:
• The standby service stops sending heartbeat messages
• The active service notices the standby service has not sent a heartbeat message in a specified amount of time (Failover Interval) and reports the error and sends any alerts indicating the condition.
January 11, 2007
M4 Failover Service: Configuration
The M4 Client provides the end-user with management of the following Failover Service Configuration Settings:
SETTING DESCRIPTION
Cluster Role Primary or Secondary: this determines which role a server will play in the Failover scheme.
Channel Configuration
TBD: this present transport and application level configuration for a network communication channel.
Heartbeat Interval How often heartbeat messages are sent to the standby server in seconds.
Discovery Period This period, defined in seconds, determines the active server using a promotion/demotion scheme.
Failover Alerts A list of email address to send alert message on failover. Empty setting disables failover alerts.
Failover Interval Period of time to wait to determine if a failover event has occurred.
Checkpoint Interval
Determines how often a checkpoint is sent between the two services
January 11, 2007
M4 Failover Service: Operational Control
• M4 Client provides user with simultaneous operational control of both clustered monitors (start, stop, pause)
– User selects the control commands from File Menu:– Prevents failover contention
• Users can enable/disable failover on both servers
• Topology Viewer displays both monitors– Identifies Active and Standby– Remote monitor has limited display features
• Right-clicking a monitor in Topology Viewer provides independent operational control with a context-menu:
– Allows for planned shutdown– Issues an immediate checkpoint– Failover will not report failure or send any alerts– Context-menu provides hint: ‘Stop this Monitor’
January 11, 2007
M4 Failover Service: Standard Operating Procedures
• User must take care to provide the same topology version to each server– M4 Client will provide utility to push topology and SxC changes to both servers
• User must configure Failover Service correctly– Servers must be identified with correct Primary and Secondary roles– Heartbeat communication will provide a test utility in the configuration manager
• Perform a manual failover for planned shutdown of an Active server
• Reporting concurrently with SxC processing should be performed on failover server to avoid impacting performance
• Only the Primary server should be configured to automatically upload data to PTAGIS
– Submitting data from the Secondary can result in duplicate data
• The Secondary server should be use for patching data after a failover event
• Normal startup and shutdown of systems should use dual operational controls from menu to start/stop both monitors simultaneously
January 11, 2007
M4 Failover Service: Data Recovery
• M4 Client will provide a Data Recovery tool to facilitate manual patching of data after a failover event
– Data Recovery tool will provide a side-by-side viewers of both databases– Viewers will be aligned by checkpoints and timestamps– User will select patch data from viewer and upload it to PTAGIS