Usage Topics for Pervasive PSQL Vx Server
This section discusses the following topics for using Pervasive PSQL Vx Server:
•
Physical Machine To VM Migration
•
Configuration
•
VM Resource Pools and Templates
•
Failover Cluster Support
•
Performance
•
Data Backup
Physical Machine To VM Migration
You can install Pervasive PSQL Vx Server 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 MAC addresses and hostname remain the same and that Internet connectivity is maintained. Always document the MAC addresses for each NIC in your physical machine before performing the migration.
Some hypervisor migration utilities may automatically generate a new MAC addresses instead of letting you specify one. For such situations, you need to perform either of the following actions to ensure that Pervasive PSQL Vx Server runs on the VM.
•
Change the MAC addresses in the VM to the value of the MAC addresses on the physical machine. Depending on the hypervisor product, you may need to edit the VM properties for each network adapter.
•
Ensure that you deauthorize the Pervasive PSQL Vx Server key on the physical machine before performing the migration. See To Deauthorize a Key in Pervasive PSQL User's Guide. Reauthorize the key on the VM after the migration is complete and you verify that the VM is working properly. See To Authorize a Key in Pervasive PSQL User's Guide.
Pervasive PSQL Vx Server does not depend on IP address, but the VM itself might. Be aware that when a different MAC address is assigned to a network node, it is highly likely that the VM will be assigned a different IP address. 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.
Pseudo Interfaces
When you execute certain network commands such as “ipconfig /all” on Windows or “ifconfig -a” on Linux, you may see pseudo interfaces. For example, if you enable IPv6 on Windows, you can see the Teredo and ISATAP pseudo interfaces. On Linux, enabling IPv6 creates pseudo interface sit0. (Depending on the hypervisor product, you may also see pseudo interfaces on Linux such as vmnet0, vir0, vix0, or br0.)
If the pseudo interface does not have a MAC address (a physical address or an HWaddr), you can ignore the interface. Authorization of Pervasive PSQL Vx Server only involves interfaces that are assigned a MAC address.
Pervasive PSQL Vx Server attempts to determine which are real interfaces and which are pseudo interfaces. Hypervisor and platform vendors are making such a determination increasingly more difficult. If you encounter a situation where a pseudo interface is assigned a MAC address that you cannot specify or change, use the following steps.
1
Deauthorize the Pervasive PSQL Vx Server key. See To Deauthorize a Key in Pervasive PSQL User's Guide.
2
Install, enable, disable, or remove any network service (such as IPv6) or interface (such as a NIC).
Note that MAC addresses are assigned when the underlying service or interface is created. Once created, they do not change.
3
Reauthorize the Pervasive PSQL Vx Server key. See To Authorize a Key in Pervasive PSQL User's Guide.
The steps above apply to a permanent change to a VM. If you need to perform a temporary, short-term change to a network service or interface, you may skip the steps.
For example, suppose that you need to install an additional NIC for debugging purposes. Such an addition causes the Pervasive PSQL Vx Server key to change state to “failed validation.” For 30 days, Pervasive PSQL Vx Server functions normally while in failed validation state.
Once your debugging is completed, remove the additional NIC. With License Administrator, perform a repair. See To Repair a Key in Pervasive PSQL User's Guide. After the repair, the Pervasive PSQL Vx Server key will change state back to “active.”
If the VM network services and interfaces are restored to their original configuration in 30 days or less, Pervasive PSQL Vx Server remains fully functional while in failed validation state. See also Failed Validation and Failed-Validation Period in Pervasive PSQL User's Guide.
Configuration
No special steps are needed to configure Pervasive PSQL Vx Server to use hypervisor product features such as live migration, fault tolerance, high availability, paravirtualization, resource scheduling and disaster recovery. Pervasive PSQL Vx Server remains authorized and fully functional provided that the MAC addresses and hostname remain consistent and Internet connectivity is maintained.
Certain scenarios, such as for disaster recovery, may require network and hardware changes. You may change the following without adversely affecting Pervasive PSQL Vx Server:
•
IP 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 Pervasive PSQL Vx Server 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
Pervasive PSQL Vx Server may be used with VM resource pools and templates. For both uses, each copy of Pervasive PSQL Vx Server requires its own product key. See License Enforcement in Pervasive PSQL User's Guide.
Resource Pools
Pervasive PSQL Vx Server must be authorized in each VM within a resource pool that includes the database engine. The VM must also meet the operating requirements for Pervasive PSQL Vx Server. See Operating Requirements.
Templates
To authorize Pervasive PSQL Vx Server 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 Pervasive PSQL Vx Server key during the customizing of the guest operating system. Internet connectivity is required for the authorization. See License Administrator Command Line Interface in Pervasive PSQL User's Guide.
Remember to customize other properties of the guest operating system, such as hostname, that are independent of running Pervasive PSQL Vx Server.
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 Pervasive PSQL Vx Server 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.
Performance
To achieve the best performance for Pervasive PSQL Vx Server, ensure the following:
•
Adherence to the performance best practices recommendations from the hypervisor vendor.
•
The VM hosting Pervasive PSQL Vx Server 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 Pervasive PSQL Vx Server. If you use affinity rules, ensure that all cores are running on the same socket.
•
The Pervasive PSQL Vx Server data files reside on very fast physical storage and minimize spindle contention and controller contention for the physical storage device.
Data Backup
See Data Backup.