Skip to main content

Skytap Power Workload Best Practices

Dylan Schneider
Updated

There are several general areas related to performance of IBM POWER LPARs on Skytap that should be considered when running critical workloads. This article touches on some of the most common items that should be carefully considered as a part of ensuring workload success.

 

NETWORK CONSIDERATIONS WHEN SENDING DATA ACROSS WANs

To move data efficiently across VPNs or ExpressRoutes that terminate in Skytap, AIX or IBM i LPARs in-guest network settings should be optimized. Depending on specific network path conditions, optimizing can result a significant increase of TCP stream performance. Additionally, sending the data in multiple simultaneous TCP streams instead of a single stream can often result in the overall throughput doubling, tripling, or more. See the following networking tuning documents:

 

VPN SPECIFIC CONSIDERATIONS

  • PACKET SIZE
    • Skytap VPN endpoints that are within Azure regions should be configured with MSS clamping enabled and set to a value of 1200. This will rewrite the MSS values in the TCP three way handshakes passing within the VPN tunnel, thus resulting in overall TCP packet sizes that will avoid fragmentation within the Skytap or Azure networks. Skytap VPNs will rewrite the MSS values bi-directionally.
    • The NICs of LPARs communicating across Skytap VPNs in Azure regions should be set to 1240 MTU.
  • PHASE 2 ENCRYPTION
    • For best possible throughput, the phase 2 encryption algorithm of Skytap VPNs should be configured as "aes_gcm", if the non-Skytap side VPN device supports it.

 

LPAR EC/CPU/vCPU

The EC setting on an LPAR is a critical consideration in LPAR performance. The EC setting reserves the CPUs on the physical host so that the LPAR is guaranteed to always have the CPUs available for the LPAR. If the EC is set too low, it can result in inconsistent performance or workloads not completing within the required timeframes.

CPU use should be monitored from within the guest OS of critical LPARs. If the LPAR is using 95% or more of its configured CPU (EC) on a regular basis then to ensure workloads complete a desired and predictable duration, it's advised you increase the EC setting of the LPAR.

In regards to vCPU settings, the correct value can vary depending on specific of the workload, but it is advised to never exceed 1.5 times the EC setting. For example if the EC of an LPAR is set to 2.0, then the vCPU should not exceed 3 because: 2.0 EC x 1.5 = 3.0

 

STORAGE TUNING

For storage intensive workloads, the storage configuration should be optimized. There are several aspects of storage tuning to consider:

  • LPAR DISK SIZES
    • In IBM i, databases are generally stored spread across all of the LPARs disks. For optimal performance, all the disks attached to the LPAR should be exactly the same size.
    • In AIX, databases are generally stored spread across the disks of a volume group. All the disks of a volume group should be exactly the same size.
  • LPAR DISK COUNT
    • An LPAR disk has maximum in terms of the amount of storage requests that it can process at a given moment. Adding additional disks that are read from or written to simultaneously, can increase the LPARs overall maximum read and write capacity. If the workload is not able to achieve sufficient storage I/O, you likely need to increate the number of disks the workload is using.
  • LPAR DISK CONTROLLERS
    • Similar to disks, LPAR disk controllers have a maximum in terms of the amount of storage request that it can process at a given moment. For optimal read/write performance of storage intensive LPARs, the disks of an IBM i LPAR, or disks of an AIX volume group may need to be distributed across multiple LPAR storage controllers. For assistance with adding additional controllers to LPARs, or customizing LPAR disk and disk controller configurations, feel free to contact Skytap Support.
  • QUEUE DEPTH
    • Queue depth is the maximum number of queued I/O storage requests a storage related device can support. Once that queue value is exceed, the OS/application will have to resend that request, causing significantly slower read/writes.
      • In IBM i, the queue depth of each disk is set to 32 and cannot be changed
      • In AIX, the queue depth value for each disk can be set independently:
        • Get the current queue depth of a disk:
        • lsattr -E -l hdisk2 -a queue_depth
        • Set the queue depth of a disk:
        • chdev -l hdiskN -a "queue_depth=VALUE"
        • Skytap recommends a queue depth setting value of 10 for each AIX hdisk. That value was derived from both theoretical math of involved Skytap components and real world testing. You can find further information in the Skytap WAF
  • BLOCK SIZE
    • Oversimplified, block size is the payload size of a single chunk of data that is being read or written from/to a storage device. The optimal block setting to use for an application in a Skytap LPAR can vary depending on workload type and other requirements. Keep in mind not all applications have a block size setting. You can learn more on the topic of block size in the Skytap WAF
  • READ/WRITE TIMEOUT
    • In order to increase resilience and performance of the operating system and applications, the storage read/write timeout should be set appropriately:
      • In IBM i the storage read/write timeout is not a settable option
      • In AIX the read/write timeout should be set to 120 seconds. You can find further details here

 

BACKUP AND HIGH AVAILABILITY

The very same backup concepts and strategies used to protect data on-prem, are also applicable to the cloud. Ask yourself for example: What would the result of one of your users accidentally deleting a critical production LPAR be? How long would it take for production to be back up and running after that event? Backup strategies and planning including full data backups, incremental backups as well as possible high availability strategies should be part of initial implementation of production in Skytap cloud. See the following helpful backup/HA information links:

Related articles

Comments

0 comments

Article is closed for comments.