Scaling triplets with and without SSL with software encryption

The purpose of these test runs was to scale the number of triplets in use. We wanted to see how z/VM® was able to handle scalability as it reached a significant overcommitment of available resources. Also, we wanted to see the cost of using software encryption with SSL compared to using no encryption. We expected that encryption would cause either more CPU cost or less throughput than without using encryption.

Overcommitment

If each guest of a triplet were to be given one virtual CP, a z/VM system with eight physical CPs will have its CPs overcommitted when three triplets are reached, that is, nine CPs. Changing the number of CPs per triplet will only lower or raise the virtual number of CPs that the Linux® guest will think it has defined to it. In other words, the physical aggregate cannot be greater than eight CPs. The following table shows which scenarios were running with more virtual resources than physical resources available (overcommitment) and the grade of that overcommitment.

When we specify the overcommitment in this document, we specify the part the virtual resources exceed the physical resources. For example, with four triplets we have the CPUs overcommitted by 100% and no memory overcommitment.

The environment with 4 triplets uses all memory for the guests. Because there is some space needed for the z/VM operating system itself, this scenario is actually running with memory overcommitted. In any run with five triplets, the virtual CPU and memory exceeds the physical resources significantly. Be aware that the z/VM system has a very fast paging device with the 2 GB expanded storage.

Observations

The throughput continues to increase from one triplet to four triplets, even through the overcommitted case with five server triplets. Comparing the runs without SSL and the runs with encryption, we see that the additional effort for the encryption costs CPU and reduces the throughput between 25% and 30% (see Figure 1 and Figure 2).

With four triplets the system is already utilized above 90%. Surprisingly, the throughput with five triplets does not degrade, which would be expected. With five triplets and encryption, the CPUs were utilized to 100%.

The workload scaled well for two triplets. Considering that four triplets already has a CPU overcommitment by 100% and there was a slight memory overcommitment (all memory was used for the guests and some was needed for the z/VM control program), the scalability was still good. The result for five triplets is very good because the system ran completely overcommitted (CPU by 150%, memory by 25%) at nearly the same throughput level as four triplets.

Conclusions

z/VM manages resources very efficiently so the throughput does not degrade in the overcommitted scenarios. When exceeding the point where the system becomes overloaded, the throughput does not degrade. Here it would have been interesting to know how many more triplets would be needed until the total throughput goes down.