Top Banner

Click here to load reader

© 2008 OSIsoft, Inc. | Company Confidential High Availability Michael Jakob Colin Breck Colin Breck Michael Jakob Colin Breck Colin Breck

Dec 29, 2015

ReportDownload

Documents

  • 2008 OSIsoft, Inc. | Company Confidential

    High AvailabilityMichael Jakob Colin Breck

    * 2008 OSIsoft, Inc. | Company Confidential

    IntroductionPI High Availability (HA) has been available for approximately two yearsAdoption has been rapidHA has greatly enhanced the PI InfrastructureOutlineReview HA InfrastructureHighlight HA adoption and deploymentAnswer common questionsFuture development directions

    * 2008 OSIsoft, Inc. | Company Confidential

    SecondaryMetadataReplicationSecondaryMetadataReplicationPI Server CollectiveTime-SeriesDataPI ServerPI InterfaceTime-SeriesDataPI SDKSystemManagement ToolsPI High Availability: InfrastructureProcessBook, DataLink, RtWebParts,Notifications, ACE, etc.Primary

    * 2008 OSIsoft, Inc. | Company Confidential

    PI High Availability: ReleasesPI Server PR1 and Buffer Subsystem PR1 (3.4.375.38)December, 2006PI Server PR1 SP1a (3.4.375.80)May, 2008Buffer Subsystem SP1 (3.4.375.84)September, 2008

    * 2008 OSIsoft, Inc. | Company Confidential

    PI High Availability: AdoptionHard to provide accurate numbersbut we can provide minimum numbersIndependent customer downloadsPI Server PR1 1000+PI Server PR1 SP1 1000+Buffer Subsystem PR1 500+Buffer Subsystem PR1 SP1 200+Licenses for PI Server Collectives1 secondary 250+2 secondary 15+3+ secondary 5+

    * 2008 OSIsoft, Inc. | Company Confidential

    Deployment: High AvailabilityPI ServerTime-SeriesDataPI ClientsAnalyticsPI Server Collective

    * 2008 OSIsoft, Inc. | Company Confidential

    Deployment: Server ReplicationPI ServerPI Server CollectiveControl NetworkCorporate NetworkFirewallAnalyticsOperator, EngineerEngineer,Business Analyst,Operations, etc.Business Systems

    * 2008 OSIsoft, Inc. | Company Confidential

    Deployment: Backup/Disaster RecoveryWANPI ServerPI Server CollectivePrimary Control CenterBackup Control Center

    * 2008 OSIsoft, Inc. | Company Confidential

    Deployment: Load DistributionSecondarySecondaryPrimaryPI Server CollectiveSystem AdministratorEngineersData MiningOperators

    * 2008 OSIsoft, Inc. | Company Confidential

    Deployment: All of the AboveWANPI Server CollectiveOperatorsEngineersEngineers

    * 2008 OSIsoft, Inc. | Company Confidential

    Common QuestionsBufserv or Buffer Subsystem?Two options for interface buffering: Bufserv and Buffer Subsystem Buffer Subsystem is OSIsofts flagship data buffering technologyUse Bufserv when:Operating System is UNIX, Linux, Windows NT4PI Server is pre-PR1 (3.4.375)Buffering to multiple, non-HA PI Servers

    * 2008 OSIsoft, Inc. | Company Confidential

    Common QuestionsBuffer Subsystem AdvantagesCompression is performed on the data collection node, guaranteeing identical data among collective serversBuffering capacity is limited only by disk spacePI3 protocol between data collection node and PI serverAutomatic HA configurationHigher data throughput (~10 times)Performance CountersTools for examining/recovering buffer files

    * 2008 OSIsoft, Inc. | Company Confidential

    Common QuestionsDo I still need PI backups?HA expands the options for backup and recoveryBackups remain importantDisaster recovery (e.g., delete tags or data)Local backups when PI Collective is geographically distributedVirtual machine snapshots are not sufficient

    * 2008 OSIsoft, Inc. | Company Confidential

    Common QuestionsHow do I size the hardware for HA servers?What is the network bandwidth required for HA?Size each server as you would todayUse an existing installation to provide sizing estimatesPI ServerPI Interface & BufferingPI ServerSecondaryMetadata Change(e.g., tag edit)MetadataReplication

    * 2008 OSIsoft, Inc. | Company Confidential

    Common QuestionsAre my third-party applications compatible with HA?Read data/metadata from PI using the PI SDKWrite data to PI using the PI API and the Buffer Subsystem

    * 2008 OSIsoft, Inc. | Company Confidential

    Common QuestionsCan archives be shared among collective servers?Yes, when on shared storage and marked read-only

    SecondaryPI ServerPrimaryPI ServerLocalArchivesLocalArchivesHistorical, Read-OnlyArchivesShared Storage(e.g., SAN)

    * 2008 OSIsoft, Inc. | Company Confidential

    Common QuestionsHow does HA change technical support?Affords time to investigate issues thoroughlyProvides a system of referenceExpands the options for recovery (e.g., repair vs. server re-initialization)

    * 2008 OSIsoft, Inc. | Company Confidential

    Common QuestionsWhat about manual data entry?Use PI-to-PI InterfaceWrite data to all serversA number of limitationsWhat about PI Batch data?PR1 does not support HA for PI BatchFuture developments

    * 2008 OSIsoft, Inc. | Company Confidential

    Future Development: Data ReplicationServer Side Buffering(Data Mirroring)PrimaryPI ServerSecondaryPI ServerSecondaryPI Server MetadataReplicationMetadata ReplicationPrimarySecondarySecondaryPI-to-PIInterfacePI Collective PR1PI Collective withServer Side Buffering

    * 2008 OSIsoft, Inc. | Company Confidential

    SummaryAdoption of HA has been strongHA has greatly enhanced the PI Infrastructure

    * 2008 OSIsoft, Inc. | Company Confidential

    High Availability (HA) has greatly enhanced the PI Infrastructure with regard to system architectures, availability, redundancy, backup, security, troubleshooting and technical support.

    This presentation will briefly review the components of the PI HA Infrastructure and then focus on customer adoption and deployment. We will then address some common questions regarding PI HA. We will conclude with a brief look at some limitations and highlight future development directions.The PI High Availability Infrastructure.Step 1:A typical PI Server with independent data collection nodes (PI Interfaces) with data buffering services. Step 2:Many PI Interfaces support redundancy through various means (e.g., clustering, integration with the control system vendors software).Should one interface become unavailable (e.g., routine maintenance, unexpected failure) a second interface will assume responsibility for data collection.PR1 introduced a standardized redundancy mechanism in UNIINT (UNIINT is OSIsofts core PI Interface library).UNIINT redundancy requires synchronization through the data source.PR1 also introduced Interface Disconnected Startup, where a Interface will start from a local cache if the corresponding PI Server is unavailable.The cache can also facilitate a fast startup for situations when the PI Server is across a network with significant latency.Step 3:PR1 introduced PI Server Replication where changes to metadata (e.g., creating a new tag, editing a module from the Module Database) can only be performed on one PI Server the Primary PI Server.The metadata changes are replicated to a Secondary PI Server.The Secondary PI Server is functionally equivalent to the Primary PI Server with the exception that the metadata may not be modified.When metadata is modified on the Primary PI Server (e.g., a new tag is created) a Change Record is queued by the Update Manager on the Primary PI Server and is persisted to disk.With the default configuration the Secondary PI Server will request the Change Records from the Primary PI Server in real-time.It is also possible to synchronize the Secondary PI Server on demand or on a custom schedule (e.g., once a day).Step 4:PI Server replication is not limited to one Secondary PI Server there may be multiple Secondary PI Servers.Step 5:A PI Server Collective is a set of functionally equivalent PI Servers.There are no explicit hardware requirements for the servers in PI Collective each server may have different hardware specifications.The servers in the PI Collective may be separated by a WAN to facilitate geographic availability and/or redundancy.We will discuss deployment architectures in more detail later in this presentation.Step 6:Identical time-series data are replicated to each server in the PI Collective via PI Buffer Subsystem on the data collection nodes.If a server in the Collective is unavailable, data are buffered locally by the PI Buffer Subsystem.Data are buffered interpedently by the PI Buffer Subsystem for each server in the PI Collective.The PI Buffer Subsystem performs data compression to guarantee identical, discreet time-series events in the PI Archive across all Collective servers.To perform compression, the Buffer Subsystem must maintain the snapshot. This is why the snapshot is locked and can only be updated by the Buffer Subsystem.Performing compression on the data collection nodes (essentially scaling out the data compression processing) will have an impact on performance as demand grows for larger systems with higher data rates.It is important to note that replicating time-series data from the data collection node is more robust than replicating time-series data among Collective servers. One tenant of PI HA is that any one node may be lost without adversely affecting the operational integrity of the system. This is almost impossible to guarantee if time-series data collection and replication are performed from a PI Server.Step 7:PI Client access is abstracted through the PI SDK.The majority of PI Clients (e.g., ProcessBook, DataLink, RtWebParts, etc.) should interact with the Collective abstractly. There is no need to know how many servers are in the Collective or which server the application is connected to.PI Client access to the Collective can be controlled by the SDK Server Priority to provide different views of the Collective. The initial connection and subsequent server failover will happen based on this priority. Some users may be able to access all servers in the Collective while other users may only be able to access a subset of servers. We will describe this feature in more detail later in this presentation.When t