Got XenDesktop? Want to know exactly what’s going on in your environment?
Check out EdgeSight. It’s great. And you can use it in your XenDesktop environment too. However, there are a couple of architecture decisions that you need to think about before you deploy EdgeSight into your XD environment – if you’re already familiar with EdgeSight, skip the warmup and go straight to the heart of this post.
EdgeSight’s been used to monitor XenApp environments for years – not only does it monitor your farms and your endpoints, but it also has planning and troubleshooting tools built in. And, if you’re feeling brave, it can automatically react to common problems like service failures by restarting them, or sending you an emergency email, or any number of other actions.
Almost all of what works with EdgeSight for XenApp and EdgeSight for Endpoints applies to XenDesktop as well – much of the same data is available and the architecture is the same, so there’s virtually no learning curve for the XenDesktop portion. If you’ve never tried EdgeSight before, be prepared for a deluge of information – the detail and the amount of data can be daunting. A great place to start is the EdgeSight for XenDesktop Best Practices Guide.
Now on to the architecture discussion.
So for this architecture discussion, I’m going to assume you’re using Provisioning Services or some other form of non-persistent disk. If you’re not, you should try it, because it makes the whole update process a whole lot easier. However, having a non-persistent disk means that data is flushed on reboot, and to not overload your network and your SQL server, the EdgeSight agent stores data on the local disk temporarily, before aggregating it up to the main EdgeSight server. With a default install, any data that hasn’t been uploaded gets flushed.
Ack. Clearly that’s not behavior that we want. Fortunately, you’re reading the right blog post, and we’ve got two options for you.
Option #1: Put the local Agent database on a static VM-Local drive.
Unless you have really strict requirements about data storage and retention, this is probably the option you want to use. To do this, you can attach additional storage to the XenDesktop images – either local storage or SAN storage. High availability shouldn’t be much of a requirement here as an hour of data on rare occasions isn’t a critical loss for most organization. If you’re using a secondary disk to store the PVS Write Cache (which is good practice and greatly enhances performance and scalability), you can collocate the EdgeSight database with the Write Cache.
Setting up this option is as easy as attaching the static drive, and during the EdgeSight Agent installation specifying a different drive letter. For more details, read the EdgeSight for XenDesktop Best Practices Guide.
Option #2: Put the Agent database an external server.
If you do have severe security requirements, or you can’t attach a static disk to your machines, you can put the EdgeSight Agent database on a separate server. This database server can be either a server or desktop OS, although we recommend a server OS as the scalability tends to be better. Basically, what happens is that all of the information pushed by the EdgeSight agent gets stored and aggregated at this “EdgeSight Agent Database server” instead of a local database before getting pushed up to the EdgeSight database.
Setup is simple – install the EdgeSight Agent Database from the install media onto an OS, define what Desktop group it will be a part of, and then you don’t need to manage that server anymore. When installing the agent. When installing the Agent, put the same desktop group. Both the Agent Database server and the Agent register with the EdgeSight server, and the EdgeSight server will tell them about each other. You can have more than one EdgeSight Agent Database server per pool , and EdgeSight will automatically load balance between them – this is a good thing, as you need one Agent Database server for each 80 active desktops if you’re using a server OS, and about 40 active desktops if you’re using a desktop OS (Note: those numbers can vary based on your hardware and settings, so please test before going into production. These numbers are provided as a baseline value).
One common concern with this option is the proliferation of additional VMs to act as EdgeSight Agent Database servers. Using sampling (through the Personality settings in PVS), you can reduce the amount to one Agent Database Server per desktop group and still have a good understanding of what’s occurring in your environment. Follow me at @mcbogo on Twitter or subscribe to my RSS feed to catch a future guide on how to do that.
That’s it. Easy.
So now that you’ve read this post, you should be able to set up EdgeSight in your XenDesktop environment successfully. As always, you should read up on the Install Guide and the Admin Guide, and you can get more detailed information on EdgeSight for XenDesktop architecture and good reports to take advantage of in the EdgeSight for XenDesktop Best Practices Guide.
To get more updates on XenDesktop, EdgeSight and Provisioning Services, follow @mcbogo on Twitter.