PI-System Avanzado.pdf

8/12/2019 PI-System Avanzado.pdf

1/19

Virtualiza ion nd t e PI yst

ersionovember

m

1.22010


2/19

OSIsoft, Inc.777 Davis St., Suite 250San Leandro, CA 94577 USA(01) 510-297-5800 (main phone)(01) 510-357-8136 (fax)(01) 510-297-5828 (support phone)

http://techsupport.osisoft.com

[email protected]

Houston, TXJohnson City, TNLongview, TXMayfield Heights, OHPhiladelphia, PAPhoenix, AZSavannah, GASeattle, WAYardley, PA

OSIsoft AustraliaPerth, Australia

Auckland, New Zealand

OSI Software GmbHAltenstadt, Germany

OSI Software Asia Pte Ltd.Singapore

OSIsoft Canada ULCMontreal, Canada

Calgary, Canada

OSIsoft , Inc. Representative OfficeShanghai, Peoples Republic of China

OSIsoft Japan KKTokyo, Japan

OSIsoft Mexico S. De R.L. De C.V.

Mexico City, MexicoOSIsoft do Brasil Sistemas Ltda.Sao Paulo, Brazil

Sales Outlets/Distributors

Middle East/North AfricaRepublic of South AfricaRussia/Central Asia

South America/CaribbeanSoutheast AsiaSouth Korea Taiwan

www.osisoft.com

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means,

mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, Inc.

OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, Sigmafine, Analysis Framework, IT Monitor,

MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Manual Logger, PI ProfileView, ProTRAQ,

RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, Inc. All other trademarks or tradenames used herein are the property of their respective owners.

RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Dataand Computer Software clause at DFARS 252.227-7013

Published: 4.10.2009


3/19

Contents

Virtualizing PI .............................................................................................................................. 4

Best Practices ............................................................................................................................. 6

Not Recommended ................................................................................................................................. 6Virtualization on a PI Server ............................................................................................................ 6

Recommended Architectures ................................................................................................................. 7PI System on a Single Virtualization Host........................................................................................ 7PI System on Multiple Virtualization Hosts ...................................................................................... 8

Processor ................................................................................................................................................ 9Disk .................................................................................................................................................... 9Memory ................................................................................................................................................. 10Networking ............................................................................................................................................ 10

Configuration and Fault Tolerance ....................................................................................................... 11

Figure 1 .......................................................................................................................................... 12

Product Specific Recommendations ...................................................................................... 13

References ................................................................................................................................. 17


4/19


5/19

Best Practices

1

Virtualizing PIOSIsoft supports the virtualization of the PI System on the enterprise class virtualization platforms of

Microsoft Hyper-V and VMWare ESX Server. A PI System that is sized using the PI Server Installation

and Upgrade Guide and Hardware and System Sizing Recommendations Spreadsheet will operate

within a virtualized platform when using the recommended configurations. The recommendedvirtualization configurations are:

PI Server and additional PI System components running on a single virtualization host.

NOTE: A single virtualization host is a single point of failure; if the host is non-functional or

problematic, data may not be available or buffered, resulting in lost data

PI Server and additional PI System components running across multiple virtualization hosts


6/19

Virtualization and the PI System

2

In addition to the recommended architectures, there are five core principles that should be adhered to

when implementing the PI System on a virtualized platform.

Principle 1 A Virtual Machine is just another brand of machine

The sizing of the PI System on a virtual or physical implementation must adhere to the sizing

requirements for CPU, memory, disk, and network.

Principle 2 Enterprise solutions must use enterprise class virtualization and hardware

When virtualizing the PI System, only the use of enterprise class virtualization products and enterprise

class server and SAN hardware should be used. Enterprise class virtualization products include Microsoft

Hyper-V and VMWare ESX. Other virtualization products may be used for test and development

environments, but not for production.

Principle 3 Do not mix virtual and physical implementations on the same host.

PI System components should not be installed on the host system that is running a virtualization platform.

For the implementation, applications should only be run within the virtual machines and not on the hostas applications running on the host system may use resources that are needed by the virtual machines.

Principle 4 Ensure qualified support of the virtual environment

IT/Server support personnel should be properly trained in maintaining and managing virtualization

platforms. OSIsoft supports the PI System, not the platform upon which it is installed.

Principle 5 Testing of the PI System on a physical and virtual platform using custom configuration

should be completed

There are varying degrees of performance deltas between a physical and virtual implementation. Thesevariances depend upon the type of applications installed, configurations of the application, and the

workload. Prior to a virtualized implementation, a test to determine the delta between a virtualized and

physical implementation using the custom configuration should be completed to understand the

performance deltas. Microsoft provides best practices for running MS SQL Server 2008 on a Hyper-V

environment and these fundamentals for testing may be applied to test practices for PI Systems.


7/19

Best Practices

3

Best PracticesThere are several factors that must be considered when building a PI system on a physical or virtual

environment. The hardware, whether physical or virtual, that is required for the system is dependent on

many variables. The accumulation of these variables determines the processor, disk, memory, and

network configuration necessary for a well performing PI system. In addition to the hardware

requirements, a highly available system adds another layer of complexity in determining a virtualizationstrategy. All of these factors are used to determine the total system architecture.

The following information provides a guide to determining an appropriate approach for virtualization of a

PI System. It should be noted that all PI System components are capable of being virtualized; however,

each component should be individually considered for virtualization as it delivers a specific function to

the whole PI System.

All OSIsoft products should be sized in accordance with the recommendations in the installation

documents prior to determining a virtualization strategy. A PI Server has some particular

recommendations regarding sizing which can be found in the PI Server Installation and Upgrade Guide

document. This document can be found at the following URL:

http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/documentation/streamfiles.aspx?file_id=1c0ec4c0-d9fb-4a8c-80f1-d21da2d0d5b0.

All of the recommendations included in the document apply to individual, physical PI Servers and those

that are being virtualized.

Additional information for sizing may be found in the Hardware and System Sizing Recommendations

Spreadsheet located at the following URL:

http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/downloadcenter.aspx?down

load_file=8d7f6f38-2ed3-43f3-a7f5-a15789e6bca7

System performance is key when designing a PI System and the resultant sizing of the system may then

be placed on a virtualization platform. There are three (3) general approaches to virtualization of the PI

System, of which one (1) is not recommended and two (2) are recommended.

Not Recommended

Virtualization on a PI Server

The first approach is to install the PI Server on a physical server and then install the virtualization

software within the same operating system. The additional PI System components (e.g. interfaces, ACE

server, etc.) are subsequently installed as guests within the virtualization host running on the PI Server.

This implementation method for virtualization is not recommended because:

The design puts unnecessary processor and memory strains on the single physical server

oInability to configure the PI Server resources (CPU and memory); resources constrainedor split only by what has been allocated to the virtualization guests

o Inability to manage the local and virtualized resources independently

A single point of failure; if the PI Server experiences issues, the operating system supporting thePI Server cannot be rebooted without shutting down the virtualized PI System components that

are running as virtualization guests


8/19


4

The performance and single point of failure issues outweigh the benefits received by virtualizing the

additional PI System components on the PI Server; this configuration isNOT RECOMMENDED.

Recommended Architectures

The recommended architectures achieve scalability, reliability, and efficiency through virtualization.

PI System on a Single Virtualization Host

The second design is to use a single virtualization host with PI Server and PI System components running

within their own virtualization guests.

Pros:

Reduced hardware cost to a single server

Each PI component within their own virtualization guest isolates processes from each other

Cons:

Single hardware point of failure


9/19

Best Practices

5

PI System on Multiple Virtualization Hosts

The final approach is to use multiple virtualization hosts and load the PI System components across the

hosts. The performance of the PI Server will be least likely impacted by loading no additional or only

low resource consuming PI System components on the virtualization host that is hosting the PI Server

virtualization guest.

Pros:

PI Server may be isolated from any virtualization guests; performance of PI Server is not directlyimpacted

Reduced hardware costs to two servers

Increased fault tolerance through multiple virtualization hosts (additional software or licensingmay be required for automatic fault tolerance)

Cons:

Additional hardware required for additional virtualization hosts


10/19


6

ProcessorThe processor requirements for a virtualized system will need to be the same as or greater than a physical

system when using a virtualized system. During the configuration of the guest machine, the system

hardware settings are stored in the hypervisor configuration. The configuration for the virtualization host

will determine the quantity of processors as well as the total allowable percent of utilization that the guest

may use. In the case where the processor(s) may be shared across multiple virtualization guests, the total

configured processors allocated to the PI System guest will need to meet or exceed the physical hardware

requirements to ensure that the necessary processing capability is available to the PI system.

For example, in a physical system with 200,000 points there is a requirement for a minimum of two (2)

processors running at 2.93 GHz. If the system is virtualized and there are four (4) processors running at

2.93 GHz on the virtualization host, an allocation of 50% utilization across all four processors for the PI

System virtualized guest will be approximately equal to the physical configuration requirements.

As an alternative to a percent processing capacity allocation, a processor may be isolated to a specific

guest. With this configuration, the need to allocate a part of a processor resource capacity is no longer

required. As with a percentage of processing capacity, the same or equivalent process capability required

of the physical implementations must be allocated in the entire processor allocation method. The

downside to allocating an entire processor in the configuration, is that, in the event the resource

requirement for the PI System guest is low, the processor resources may not be allocated or shared to

other virtualized guest systems and an over allocated, underutilized host system may result.

Disk

The disk requirements for the virtualized PI System have the same sizing requirements as a physical PI

system. The keys to building an efficient PI System in a virtual environment depends on the virtualtechnology being implemented; however, there are some universal principles that will help in determining

the disk requirements.

First, the type of disk to be implemented for the guest must be decided upon. Both platforms support

fixed and dynamic disk configurations. A fixed disk is a predefined and pre-allocated physical partition

that is created on the connected volume for the virtual machine. A dynamic disk is predefined, but the

total partition size is not pre-allocated on the volume. As the data requirements grow for the partition, the

partition will grow up to the maximum pre-allocated size. In general, fixed disks perform better than


11/19

Best Practices

7

dynamic disks due to the additional overhead required for dynamic disks to be able to expand as

necessary. Therefore, it is better to select a fixed disk over a dynamic disk.

Second, an important factor to consider is the logical disk layout. The same logical disk layout would be

applied as if it were a physical server. Therefore, if the configuration required a C, D and E

partition, these would also be necessary in the virtual machine.

Next, a decision must be made if those partitions can be part of one virtual disk or multiple virtual disks.Generally, performance is better if disk I/O is divided into multiple virtual disks and then distributing

those disks among several arrays. However, PI is not a disk intensive application and as such, can be

maintained with success on a single array with a few virtual disks. Normally, it is recommended to

separate the operating system, archive disk and snapshot, and event queues onto 3 separate virtual disks.

The use of multiple partitions is for performance considerations, although many PI Systems run perfectly

with fewer partitions. In addition, an important reason to use multiple virtual disks is to support the

ability to grow each disk individually according to the need and to provide a minimum level of fault

tolerance to each of the systems dependant on the disk.

Finally regarding disk requirements, most organizations will be using a Storage Area Network (SAN) for

supporting the virtual environment. With the virtualization guests systems files residing on the SAN,

there should be SAN switching redundancy, fast and reliable I/O, and an easy disk method for accessing

the files for backup purposes.

Memory

The PI Server is a memory intensive application with frequently accessed data structures being kept in

memory. Memory utilization is directly related to point count with the overall rate as well as the number

of points affecting the amount of memory required. The memory recommendations for a PI Server are

found in the document PI Server Installation Guide which can be found at the following URL:

http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/documentation/streamfiles.

aspx?file_id=1c0ec4c0-d9fb-4a8c-80f1-d21da2d0d5b0

Regardless of which component of the PI System is considered, virtualization adds an additional memory

requirement to maintain the virtual machine components. This varies depending on which virtualizationhost platform the organization is using. In any case, consider adding additional memory to the virtual

machine for virtual machine management overhead; how much to add will depend on the virtualization

host platform that the organization will deploy; however, a good starting point is to add a minimum of

10% more virtual memory to the guest machine than the organization would have for a physical machine

to account for virtual machine overhead.

Additional information for sizing may be found in the Hardware and System Sizing Recommendations

Spreadsheet located at the following URL:



NetworkingThe networking configuration in a virtual environment is often forgotten. However, getting data in and

out of the virtualization host and guest hosting the virtual application is as important as the memory and

disk environment. Simply stated, the single network adapter environment generally wont be sufficient

for a production virtualization host system. In production virtual environments running the PI System, it

is required that special attention be given to the networking infrastructure and communications design.

In a production virtualization host system, a good rule to follow is to dedicate an adapter to the console,

another adapter to the storage and backup network, and multiple adapters to the guest systems. This


12/19


8

approach will provide the flexibility to use adapter teaming for load balancing and fault tolerance while

segmenting network I/O for guests to a single adapter or team of adapters to provide the best throughput.

Additionally, make sure the network devices (e.g. switches) that these adapters are connected to are

redundant to create a completely fault tolerant environment from the endpoint to the PI System on the

virtual host.

Configuration and Fault ToleranceThere are several factors to making any system implementation successful and a key factor for most is

providing fault tolerance for highly available, business critical systems. Fault tolerance provides the

ability for a system to continue to function in the event of a hardware or software failure. Without a fault

tolerant implementation, a single component outage may bring down the entire system and application

structure and processes would cease to function.

Figure 1 depicts an example of a fault tolerant configuration of a virtualization host on either the

VMWare or Microsoft platform. There are two virtual machines running on a single virtualization host

server with multiple hardware redundant components. On each virtual machine, there are two network

cards: one connecting to the virtual switch on the guests network and one connecting to the virtual switch

on the storage/backup network. The traffic for the backup processes are isolated from the normal network

traffic by binding the virtual switch for the storage/backup network to an independent physical networkcard, Physical NIC 3, on the host. For the normal network traffic, the virtual network switch is teamed to

two physical network cards, Physical NIC 2 and Physical NIC 4, providing fault tolerance and increased

bandwidth. As with the storage/backup configuration, the console connection to the virtualization host

server is connected to an independent physical network card, Physical NIC 1, to isolate the traffic from

the other networks.

For additional fault tolerance, the physical network cards connected to the virtual switch of the guest

network, Physical NIC 2 and Physical NIC 4, are connected to separate production network switches.

Finally, any Logical Unit Numbers used to address the SAN, LUNs, that are connected to the

virtualization host are connected through redundant host bus adapter (HBA) connections. The two

connections will provide volume access in the event of physical card failure of the HBA.


13/19

Best Practices

9

Figure 1

Virtualization Host

Host SAN Storage Adapters

Host Network Adapters

Virtualization Hypervisor

Physical

NIC 1

Virtual SwitchConsole

Production Network Switch 2

HBA 1

Physical

NIC 2

Physical

NIC 3

HBA 2

Virtual Machine

Virtual SwitchStorage Network -

Backups

Virtual SwitchGuests

OPERATING SYSTEM

APPLICATION

Production SAN Switch 1

Host

CPUs

Host

MEMORY

Host

DISK

Virtual Machine

OPERATING SYSTEM

APPLICATION

Physical

NIC 4

Production Network Switch 1

Production SAN Switch 2


14/19


15/19

Virtualization High Availability Strategies vs. PI High Availability

11

Virtualization High Availabili ty Strategies vs. PI HighAvailabilityMany customers ask: Why do I need PI high availability (PI HA) when Im using a high availability

strategy in my virtual environment? There are a few things to consider when thinking about using a

virtual high availability strategy (Virtual HA) vs. a PI high availability strategy.

Virtual High Availability Strategies all strive for the same common goals regardless of the virtual

platform, they are:

1. Improved Service Levels

2. Improved utilization of computing resources

3. Reduction in the footprint of systems thru better utilization

In contrast, PI high availability has slightly different goals which can complement a virtual high

availability strategy, those goals are:

1. Improved Service Levels

2. Data Duplication

3. Data Availability

A key differentiator between PI high availability and virtual high availability strategies is that PI is

capable of replicating datasets among several servers to provide duplicate data sets that can be used for

client failover. This strategy provides a level of data availability and improved service level when

combined with PI N-way buffering.

PI System Considerations PI High Availability Virtual high availability

Operating System Updates Achieves availability byproviding data redundancy thru a

secondary PI Server during an

update

Does not achieve availabilityduring the system update cycle

Software Upgrades Achieves availability by

providing PI data redundancy

thru a PI Server secondary node

Does not achieve availability

during the system upgrade cycle

Software Failure Achieves availability by

providing data redundancy thru a

PI Server secondary node no

process data is lost

Has the ability to provide

recoverability during a software

failure via snapshots. This

provides the last known goodconfiguration but some PI data

will likely be lost.

Hardware Failure Achieves availability by

providing data redundancy thru a

PI Server secondary node

Provides availability thru virtual

high availability by moving the

VM to another VM host


16/19


17/19

Virtualization High Availability Strategies vs. PI High Availability

13

Software Upgrades Achieves availability by

providing PI data

redundancy thru a PI

Server secondary node

Does not achieve

availability during the

system upgrade cycle

Combined solution would

use PI HA to provide

availability during an

update

Software Failure Achieves availability byproviding data



no process data is lost

Has the ability toprovide recoverability

during a software

failure via snapshots.

This provides the last

known good

configuration but

some PI data will likely

be lost.

Provides data availabilitythru PI HA secondary

nodes and snapshots thru

virtual high availability

Hardware Failure Achieves availability by

providing data

redundancy thru a PIServer secondary node

Provides availability

thru virtual high

availability by movingthe VM to another VM

host

Increases the availability

of any PI HA enabled

node without complicatedoperating system

clustering. Combined

with PI HA, virtual high

availability can provide

very high levels of uptime

with zero data loss

Hardware Migration Achieves availability by

providing data



Provides availability

thru virtual high

availability by moving

the VM to an alternate

host

Utilizing Virtual high

availability simple

hardware migration with

no configuration changes

to PI HA, data is alwaysavailable

Network Failure Achieves availability by

providing data

redundancy thru a

secondary node, network

failures cause clients to

connect to other nodes

Redundant connections

provided thru virtual

high availability or by

moving the VM to an

alternate host

Minimizes network

failures as a cause of data

loss thru the use of virtual

networking and PI HA

data duplication

Load Distribution Achieves load

distribution thru multiple

servers, data duplication

and client distribution

Achieves load

distribution thru virtual

host software that has

the ability to migrate

the guest to a host with

the required resources

Combines client affinity

thru PI HA and

computing resource

loading from virtual high

availability to provide

efficient utilization of

computing resources


18/19


14

Class of Service (Users) Users/clients can be

assigned to connect to

any server in the

collective providing the

ability to segregate users

based on required service

levels. PI HA can also be

used to replicate data

across security zones

Defines class of service

by availability of

computing resources.

Through resource

management software

virtual machines migrate

to hosts with available

resources.

Combines client

affinity thru PI HA

and computing

resource loading

from virtual high

availability to

ensure the quality

of service for users.

Geographic Separation Collectives across WAN

links can be configured

Virtual high availability

in most cases cannot be

implemented across

WAN links

N/A

Virtualization Best Practices

Customers virtualizing production PI Systems should keep in mind the following best practices during

implementation.

Failover Rules

When using PI HA and virtual high availability its important to take time to define how the virtual

environment will handle failover. This is especially important when virtualizing the PI Server collective.

1. Create failover rules that prevent the primary and secondary server from running on the same

physical host. This will ensure that a PI Server is active if one of the host servers fails.

2. Review rules for resource scheduling. Moving PI System virtual machines when theyrequire additional resources is a good practice; however it would be better to move other

guests from the virtual machine to provide more resources to the PI System. This is an

important strategy when virtualizing interface nodes as the migration process will stop

data collection during the migration.


19/19

References

15

References

VMware Configuration Maximums

http://www.vmware.com/pdf/vi3_301_201_config_max.pdf

Microsoft Hyper-V TechNet Library

http://technet.microsoft.com/en-us/library/cc730764.aspx

PI Server Installation and Upgrade Guide

http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/documentation/streamfiles.

aspx?file_id=1c0ec4c0-d9fb-4a8c-80f1-d21da2d0d5b0

Hardware and System Sizing Recommendations Spreadsheet



Microsoft Hyper-V Planning and Deployment Guide

http://download.microsoft.com/download/8/1/5/81556693-1f05-494a-8d45-

cdeeb6d735e0/HyperV_Deploy.doc

VMWare Infrastructure 3 Primer

http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_prim.pdf

Running SQL Server 2008 in a Hyper-V Environment Best Practices and Considerations

http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-

5bfcf076d9b9/SQL2008inHyperV2008.docx

PI-System Avanzado.pdf

Documents

Transcript of PI-System Avanzado.pdf