At Citrix Synergy this year, Citrix stressed their commitment to partnering with Google on a variety of projects. One of the biggest areas of cooperation between the two companies has always been the ability to deploy XenApp servers to Google Cloud Platform hosting. Citrix is releasing updated toolsets to be able to use common processes and procedures, like Machine Creation Services, to fill the gaps that exist today, compared to other Cloud platforms like Azure and AWS. Additionally, this testing took place before the Google Deployment Manager scripts really existed, so a lot of it had to be built by hand.
That’s all great, but the question most organizations are going to ask is: “How much this is going to cost?!” And the easy answer to that question is… it depends. I know, that answer sounds a lot like consultant-speak for “I want to charge you a bunch of money to figure out what I should just know.” But as I hope you will see throughout this article, there are a LOT of factors that make determining an actual cost per user per hour really difficult. What we tried to do instead was set a good baseline that can be used for your own testing and cost analysis, eliminating the need to test every permutation under the sun.
My team went in to this with a simple question: What default instance type provides the best cost per user per hour with XenApp on Google Cloud while maintaining stability and manageability? And we answered that question pretty conclusively. Unfortunately, that answer led to a bunch of other questions and we have a lot more testing to do. But as you read through this blog post, keep that question in mind, because it’s what drove all of our decisions.
Testing Configuration
LoginVSI was chosen as the tool to determine maximum density per server type (it’s industry standard and easily understood data). For the purposes of our testing, we created a new VPC in Google Cloud Platform and connected it back to an existing Active Directory infrastructure with a Site to Site VPN tunnel. A new Active Directory Site was created specifically for the Google VCP. The following infrastructure servers were all built within the VCP itself:
- 2 Active Directory Domain Controllers to process the logon/logoff events
- 1 StoreFront server
- 2 Citrix Cloud Connectors
- 6 LoginVSI launcher machines
- 2 LoginVSI console servers
- 2 Citrix XenApp VDAs
- 1 file server for user profiles, LoginVSI data
- Citrix Cloud was used as the Platform layer
Why that configuration? For starters, it let us run two tests at the same time. We were churning through all the viable default standard instance types as fast as we could (we were under a bit of a time crunch) and being able to run concurrent tests was critical. The purpose of our testing wasn’t any sort of bandwidth or network performance data; it was strictly to determine the best cost per seat. Putting the launchers in the same zone as the VDAs allowed us to eliminate those variables. The standard instance types can be found here:
https://cloud.google.com/compute/docs/machine-types
Looking at that list, we immediately ruled out the 1vCPU machines. Additionally, we realized over time with the test results that the 64vCPU and 96vCPU instances were beyond our capabilities to test (we could only go up to about 125 users) and as the data showed, servers that big were somewhat irrelevant. So, the following instance types were our test bed:
n1-standard-2
n1-standard-4
n1-standard-8
n1-standard-16
n1-standard-32
Each instance was tested multiple times to find the general VSI Max. This was done to define the range that test would be run in. For instance, if you had a max number of sessions for the test set at 100 and tried to run that on a 2vCPU machine the test would end up hung and produce irrelevant data. So, once we established a maximum number that wouldn’t cause the whole test to fail, we ran at least 3 instances of each test to determine the VSI Max. Those results were then compiled into a high-tech (hah) spreadsheet to tell us exactly where the average break point was in each case.
Our LoginVSI test parameters were configured as show in Figure 1:
All tests were run at the Knowledge worker level — the heaviest workload out of the box (keep that in mind when you look at the maximum session count). Obviously, task worker would result in a higher session count, so this should be considered worst-case scenario. Testing consisted of a Server 2016 image fully patched with only the optimizations that the VDA installation performs. This was done as the result of an incompatibility discovered between the LoginVSI scripts and something that the Citrix Optimizer was applying (we did not have time to fully figure out what). Windows Defender was used as the AV product and the Windows Firewall was disabled.
In cases where there were extreme outliers due to things like stuck sessions, the test was run again to make sure the results were more in line with the average. Stuck Sessions are an important number because they indicate that the system is actually overloaded whether it’s theoretical VSI max has been reached or not. 2-3 stuck sessions are fine, more than that indicates a system that is stressed beyond what a normal user would consider an acceptable experience.
As you can see from the above chart, the 32vcpu testing resulted in a large number of stuck sessions and would be considered inappropriate for all but the most extreme use cases. The 16vcpu tests also resulted in a few stuck sessions with a reasonably high number of users. The best test results came from the 8vcpu instance testing (N1-standard-8), which averaged 33 sessions with no sessions hung. It scored a Good on the Baseline testing and was very consistent in the results. This instance sizing also fits nicely within Citrix’s own recommended sizing. With 8vcpus, 30GB of RAM and a 100GB SSD disk backing it there were plenty of resources available to the tests.
Figure 3 shows an example of the VSI Max chart for one of the N1-Standard-8 test runs:
Google RightSizing Recommendations
One of the interesting things about Google is that it has a feature called Rightsizing that you can read about here. Essentially, it analyzes the performance of a virtual machine and makes recommendations about potential ways to increase performance. Because we were curious about what Google would recommend for a VDA under load, we conducted a steady state load test against a VDA sized at the Optimum workload (N1-Standard-8) for a period of time long enough to get the following recommendations:
Google clearly thinks that additional RAM would help this instance type. Doing that, however, turns this into a custom instance with its own price point, which was not tested or calculated for this round of testing. Additional testing would be required to validate the recommendations being made and what their overall system impact would be. It is also important to note that we are conducting synthetic workload testing. Under actual use, Google might have different recommendations for the environment. It was also interesting to see in the test environment that Google recommended increasing the RAM on the StoreFront server as well.
Minimum CPU Specifications
Another interesting feature Google offers is the ability to specify a minimum CPU platform for virtual machines. Every region that Google Cloud Platform offers has a range of available CPUs based on hardware refresh (Sandy Bridge, Ivy Bridge, Haswell, Broadwell). If you just spin up an instance, you will be given whatever the default CPU is for that region. In many cases however there might be newer, beefier CPU platforms with better clock speeds and performance available for use if you know to specify them. The availability is not just based on the region you specify, but also the zone within that particular region as shown on Google’s Regions and Zones documentation.
Using the Minimum CPU Platform configuration in conjunction with Google’s RightSize recommendations could represent a true “sweet spot” for performance tuning. Keep in mind, however, that this would be a custom instance and not one of the standard offerings, so cost calculations would need to be done to prove out the $/user/hr metrics once an optimum size was determined. It’s also important to note that Google periodically does under the cover hardware refresh sweeps of their Regions and Zones, and if you are running on obsolete hardware you will always be upgraded to the current default. Over time, your density may grow on a XenApp server just from that process with no intervention. For our testing, we utilized the default CPU platform for our Region (US West).
So, What Does it Cost?
The million-dollar question is what is the best $/user/hr instance. Figure 5 shows us the calculated raw pricing as of the date of these tests in May 2018:
Looking at the above pricing, the first reaction would be that the N1-Standard-8 is clearly the price winner. It clocks in at .0185per user per hour. However, a closer look reveals some significant caveats to that GCP price. The Google cost calculator automatically assumes you are using the instance 24×7 and, as a result, they give you a 30% discount on the instance price. If the customer is more of an 8-6 5 days a week, the instance pricing looks more like this:
GCP explains Sustained Use pricing as follows:
Sustained use discounts
If you run an instance for a significant portion of the billing month, your VM instances will automatically qualify for a sustained use discount. When you use an instance for more than 25% of a month, Compute Engine automatically gives you a discount for every incremental second you use for that instance. The discount increases with usage and you can get up to a 30% net discount for instances that run the entire month.
Sustained use discounts are applied automatically and will be calculated and added to your bill as your project earns them. There is no action needed on your part to enable sustained use discounts.
To learn more about sustained use discounts, see the Sustained Use Discounts documentation.
Essentially, the more hours a month you use the instance, the steeper the discount that gets applied to the hours as they are used. So, determining the actual usage the customer will have is incredibly important to determining the final instance price on Google Cloud Platform.
As a final note on pricing, Google offers the ability to reserve an instance for a minimum of 1 year. This results in dramatically lower instance rates per hour on both platforms, but assumes you are leaving it running essentially 24×7. It also locks you in to a minimum 1-year contract, which impacts the flexibility of a Cloud solution. Ultimately if you want the instances to be spun up or down as needed you will likely achieve a better price point in many customer environments.
Conclusions
Like I said, we started with the simple question: What defaultStandard instance type provides the best cost per user per hour with XenApp on Google Cloud while maintaining stability and manageability? And clearly, we answered that question (N1-Standard-8 if you skipped to the end). But what if we had taken Google’s RightSize recommendations? What if we created a custom instance type? What if we had tested a n1-highmem-8instance type, or tried Compute-Heavy resources? We will 😊. I personally suspect that the absolute best price point will be a custom image with a higher memory count, much like what the RightSize tool suggests. But that all will have to wait for another day to prove out.
I’d like to give a huge thank you to the entire team that helped with this effort, especially my co-worker John Bythrowwho spent a lot of sleepless nights getting this testing done in a very short window. The results are interesting (to me at least) and provide a great foundation for additional testing moving forward. Hopefully, this will help those of you looking at using a GCP environment with XenApp and proves that it is a cost-effective cloud platform with a lot of potential for customer use cases. You can always contact me on Twitteror at my blog CitrixTips.com
Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more TechBytes and subscribe.
Want specific TechBytes? Let us know! tech-content-feedback@citrix.com
