8/12/2019 PI-System Avanzado.pdf
1/19
Virtualiza ion nd t e PI yst
ersionovember
m
1.22010
8/12/2019 PI-System Avanzado.pdf
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
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
8/12/2019 PI-System Avanzado.pdf
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
8/12/2019 PI-System Avanzado.pdf
4/19
8/12/2019 PI-System Avanzado.pdf
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
8/12/2019 PI-System Avanzado.pdf
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.
8/12/2019 PI-System Avanzado.pdf
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/12/2019 PI-System Avanzado.pdf
8/19
Virtualization and the PI System
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
8/12/2019 PI-System Avanzado.pdf
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
8/12/2019 PI-System Avanzado.pdf
10/19
Virtualization and the PI System
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
8/12/2019 PI-System Avanzado.pdf
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:
http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/downloadcenter.aspx?down
load_file=8d7f6f38-2ed3-43f3-a7f5-a15789e6bca7
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
8/12/2019 PI-System Avanzado.pdf
12/19
Virtualization and the PI System
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.
8/12/2019 PI-System Avanzado.pdf
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
8/12/2019 PI-System Avanzado.pdf
14/19
8/12/2019 PI-System Avanzado.pdf
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
8/12/2019 PI-System Avanzado.pdf
16/19
8/12/2019 PI-System Avanzado.pdf
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
redundancy thru a PI
Server secondary node
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
redundancy thru a PI
Server secondary node
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
8/12/2019 PI-System Avanzado.pdf
18/19
Virtualization and the PI System
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.
8/12/2019 PI-System Avanzado.pdf
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
http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/downloadcenter.aspx?down
load_file=8d7f6f38-2ed3-43f3-a7f5-a15789e6bca7
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
Top Related