Usage Topics for PSQL

Usage Topics for PSQL

This section discusses the following topics for using PSQL:

•

Physical Machine To VM Migration

•

•

VM Resource Pools and Templates

•

Failover Cluster Support

•

•

Physical Machine To VM Migration

You can install a PSQL engine, PSQL Server, PSQL Vx Server, or PSQL Workgroup, on physical machines initially and transition to VMs as your business needs change. For migrations from physical machines to VMs, you must ensure that the hostname remains the same.

The PSQL engine does not depend on IP address, but the VM itself might. If your VMs depend on raw IP addresses, or on the hosts file, rather than on the Domain Name System (DNS), ensure that you also take appropriate actions concerning IP addresses.

No special steps are needed to configure PSQL to use hypervisor product features such as live migration, fault tolerance, high availability, paravirtualization, resource scheduling and disaster recovery. PSQL remains authorized and fully functional provided that the hostname remains consistent.

Certain scenarios, such as for disaster recovery, may require network and hardware changes. You may change the following without adversely affecting PSQL:

•

IP or MAC address of the VM

•

Hardware in the VM, such as CPU type, CPU speed, amount of memory, and type and size of storage.

Note that PSQL is not aware of certain hardware changes, such as increasing memory or physical storage, if the database engine is running. You must stop and restart the database engine if you want it to be aware of such changes.

VM Resource Pools and Templates

PSQL may be used with VM resource pools and templates. For both uses, each copy of PSQL requires its own product key. See License Enforcement in PSQL User's Guide.

PSQL must be authorized in each VM within a resource pool that includes the database engine.

To authorize PSQL in a VM launched from a template, you may use a configuration script. The script can invoke the CLI License Administrator utility to authorize the PSQL key during the customizing of the guest operating system. See License Administrator Command Line Interface in PSQL User's Guide.

Remember to customize other properties of the guest operating system, such as hostname, that are independent of running PSQL.

Failover Cluster Support

As a general guideline, if you use affinity rules, ensure that all cores are running on the same socket. This aids performance of PSQL because of its multi-core support. Anti-affinity rules may also be used depending on your configuration.

If you use Raw Device Mapping (RDM) as the data drives for MSCS configurations, be aware of the considerations. Refer to the vendor documentation for RDM.

If you use fault tolerance/high availability with Distributed Resource Scheduler (DRS), be aware that load balancing can be done only after failover. Refer to the vendor documentation for DRS.

To achieve the best performance for PSQL, ensure the following:

•

Adherence to the performance best practices recommendations from the hypervisor vendor.

•

The VM hosting PSQL has ample memory (RAM).

•

The hypervisor host has enough virtual CPUs to minimize virtual CPU contention among all of the VMs on the same machine. This prevents contention with the VM running PSQL. If you use affinity rules, ensure that all cores are running on the same socket.

•

The PSQL data files reside on very fast physical storage and minimize spindle contention and controller contention for the physical storage device.

See Data Backup with Backup Agent and VSS Writer.