Architecting a Login PI Deployment
I talk about this a lot when I meet with customers, but I thought I’d write up some information on preparing for a Login PI environment and deciding where to place the components. (If you need a quick overview of what Login PI is and does, go here).
Login PI deployment components
At the outset, a Login PI deployment is pretty straightforward. It looks like this:
The items on the right you should have already. That’s your production VDI/SBC environment. We don’t have any agents you need to install or really require much in the way of changes to the environment. Login PI does need some user accounts, groups, and a GPO in your AD. Login PI can generate a PowerShell script for you that creates them automatically, or you can do it manually. It’s one or more user accounts for the Login PI virtual users, a group they are all members of, and a GPO that sets their login script. There’s a Login PI service account as well. It’s pretty non-invasive, and nothing too surprising.
The left side of the illustration shows the Login PI components. Let’s talk about them a little more.
Login PI Server
The Login PI Server is where Login PI is installed. Here’s what is configured there:
- Login PI File Share: As part of the installation process, yu’ll need to create a share on that machine where the Login PI shared components can be accessed by both your target environment and the Login PI Launcher.
- Login PI Database: This is a Microsoft SQL Server install where Login PI results and configuration are stored. The simplest option is to install the free SQL Express Edition product directly on the Login PI Server, but if you already have some kind of SQL deployment in your environment, you can also put the Login PI database on that server. The Login PI Server, launchers, and your target environment all need TCP access to the database.
- Login PI Interface: the Login PI admin console is browser based. IIS is installed automatically when you run Login PI setup, and the console added and configured.
The Login PI Server will most typically be installed in your datacenter, but the placement will be influenced by the connectivity requirements – all the components need connectivity to the Login PI Server. This includes SMB access to the file share, TCP access to the database, and http access to the web interface. The Login PI Server can be installed on a physical or virtual server. We officially support Windows Server 2008 R2, Windows Server 2012 and 2012 R2. Microsoft SQL Server 2008, 2012, and 2014.
Login PI Launcher
The Login PI Launcher is a machine that will be initiating the virtual user test sessions. It needs to be able to access the Login PI file share, database, and your target environment. It also needs the connectivity software installed to access your VDI/SBC environment: this might be Citrix Receiver, the Horizon View client, or something else, depending on your VDI platform. The launcher agent runs on this machine, and it regularly polls the Login PI database to see if there are jobs scheduled that it needs to execute. The launcher can be configured on the same machine as the Login PI Server.
Launcher machines do not generally need to be high-end machines, unless you plan on running dozens of simultaneous tests from a single launcher. The launcher can be run in a virtual machine, and can be any Windows Server or desktop OS that is currently supported by Microsoft (Windows 7 or Server 2008 or newer).
Because the Login PI Launcher initiates the remote session, the login times that Login PI reports will be affected by where the launcher is located (read this blog to find out how to filter and organize your launchers). Generally speaking, you want to place launchers in the same location as your real users, so the test results generated by Login PI closely resemble the user experience that actual users are encountering. For example, if you have users in branch locations and you want to capture data on the experience from a branch location, you should place a launcher there.
A centralized VDI environment with launchers at remote locations
In the scenario depicted here, I have a centralized VDI environment on the East Coast of the US, but I have branch offices on the West Coast, the UK, and India. By placing launchers in those regions, Login PI will be able to report on the login time users are experiencing from those locations, as well as app start times. The launchers communicate regularly with the Login PI Server, and alerts will be generated if the connection goes down between the launcher and the Login PI Server, or the connection between the launcher and the VDI environment.
You can configure jobs so that your launcher either just connects in through the broker like a regular user, or you can configure jobs so that the launcher always initiates sessions to a specific server or virtual machine (VM). Configuring jobs for each server will generate a lot more data about performance, and allow you to see performance trends specific servers easily. Jobs that connect via the broker will give you the most accurate idea of what real end users are experience. In most cases, you’ll probably want a mix of both – a single launcher can initiate several sessions, so you could put a launcher in the datacenter with jobs configured for each server (to notify you if a particular server goes down or starts to underperform) and a launcher in one or more branch locations to report on the remote end user experience.
It’s pretty straightforward: Put a launchers where your users are, and maybe an additional launcher in the datacenter if you want individual performance reports for each server. If all your users are well connected to the datacenter, your launcher could be in the datacenter, installed on the same machine that Login PI is installed on.
The Login PI licensing allows for you to mix and match as many launchers, virtual users, and tests that you want to configure to get the performance insights you need for your environment.
Want to try it yourself? Register and download Login PI