There are several general areas related to performance of IBM POWER LPARs on Kyndryl Cloud Uplift 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 Kyndryl Cloud Uplift, 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
- Kyndryl Cloud Uplift 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 Kyndryl Cloud Uplift or Azure networks. Kyndryl Cloud Uplift VPNs will rewrite the MSS values bi-directionally.
- The NICs of LPARs communicating across Kyndryl Cloud Uplift VPNs in Azure regions should be set to 1240 MTU.
- PHASE 2 ENCRYPTION
- For best possible throughput, the phase 2 encryption algorithm of Kyndryl Cloud Uplift VPNs should be configured as "aes_gcm", if the non-Kyndryl Cloud Uplift 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 Kyndryl Cloud Uplift 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"- Kyndryl Cloud Uplift recommends a queue depth setting value of 10 for each AIX hdisk. That value was derived from both theoretical math of involved Kyndryl Cloud Uplift components and real world testing. You can find further information in the Kyndryl Cloud Uplift WAF
- 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.
- 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 Kyndryl Cloud Uplift 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 Kyndryl Cloud Uplift 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
- In order to increase resilience and performance of the operating system and applications, the storage read/write timeout should be set appropriately:
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 Kyndryl Cloud Uplift cloud. See the following helpful backup/HA information links:
- Kyndryl Cloud Uplift makes implementing MIMIX For IBM i easy
- Kyndryl Cloud Uplift makes it possible to make a live clone of a running LPAR
- Copy a Kyndryl Cloud Uplift environment or template to a different Kyndryl Cloud Uplift region
- More examples of backup / HA concepts can be found here
Information in this document can help customers asking questions like:
- Why is my ExpressRoute or VPN slow?
- How do I make my Kyndryl Cloud Uplift VPN faster?
- Why are MIMIX transfers so slow?
- How do I speed up my connection from on-prem to Kyndryl Cloud Uplift?
- How to I make my VMs or LPARs transfer faster across a WAN?
- How do I make VM or LPAR storage faster?
- My database is too slow
- How can I make my disk I/O faster?
On a directly related topic for AIX LPARs, it is also very important that the storage read/write timeout be set correctly within the guest OS of AIX LPARs.
Comments
0 comments
Article is closed for comments.