Welcome to the third installment of the Dynamic Delivery Center.  This time I will be showing you the Proof of Concept (PoC) we built to validate the DDC is possible.  If you haven’t done so already, I encourage you to review the first two blogs so you understand our business and requirements.

Now, the PoC.  First, let me show you the architecture diagram we’ve used.  (Visio Stencils for this diagram are located here).



(Select diagram for a larger view)

As you can see, it is fairly straightforward. I’m the type of person who prefers things simple. The whole purpose of the PoC is to see if we can use a web front end to dynamically deliver any number of “Test” environments to the users.  Now, as many of you reading this are techies, let’s get to the good stuff…

  • External Access: Every user will be remote. Even if you are sitting in the office next to the lab, you are considered a remote user (Ever hear of de-perimiterization?).   All users will connect through an HA Pair of NetScaler 7000s with the SSL-VPN functionality enabled in full VPN mode.  We are doing more than ICA so we need a full VPN connection.
  • Web Front End: Users will be able to connect to the Web Frontend when they connect with Access Gateway Enterprise .  The Web Frontend will allow the user to request any number of systems from the lab. 

  • XenServer Resource Pool: Currently, the XenServer Resource Pool contains a set of templates that users can request from the environment. Those templates are reflected in the Web Front End, allowing the user to customize their environment.
  • XenServer Template Library: For the PoC, the library only includes Windows 2003 R2 servers, XenApp 4.5 servers, Windows Vista SP1 workstations and Windows XP SP2 workstations.  New virtual machines are created based on the templates, which should only take a few seconds.  The library will grow as new requests come in and new systems are required. The longer the DDC is running, the more complete the library will become.
  • NetScaler: The NetScaler devices are setup to allow for either a one-arm or two-arm deployment (hence the reason for the two separate VLANs).  If the user only requires a one-arm setup, they just ignore the second connection.
  • WANScaler: The WANScaler devices are setup to allow the user to test any number of backend optimizations across any simulated WAN connection with the Apposite WAN Emulator.  The backend contains another XenServer Resource Pool allowing the user to test WAN optimization against any number of resources including file servers, web servers, media servers and XenApp servers, just to name a few.

We have the architecture, but how does it work?  How does the Web Frontend do it all?  In the PoC, we chose not to look into Workflow Studio (Sorry WFS Team) as we want to wait for the next beta release. But the lessons learned in the PoC will help us properly develop our workflows in the design phase.  In the PoC, we used the SDKs extensively to do the following:

  • Virtual Machines
    1. A user selects one or more templates on the Web Frontend and selects “Provision Servers”.
    2. The Web Frontend code will search for a virtual machine resource in the database that has not been marked as in use. Once an open virtual machine is found, the database will be updated and marked as in use by the user for a period of 3 days.
    3. The Web Frontend will establish a session with the XenServer host using root credentials.  The template the user selected will be cloned.  Once the clones are created, they will be sent a start command.
    4. Once the virtual machines are running, the IP address will be obtained. This information is used to generate an automated email to the requester using the SMTP service running on the Web Frontend server.
    5. The user will use the IP address to make a Remote Desktop connection to the console of the server, which is waiting for the user to enter a name for the virtual machine as part of the SID generation process.
  • NetScaler
    1. User selects “Provision NetScaler” from the Web Frontend
    2. The Web Frontend checks the database for an available NetScaler. Once one has been found, it is marked as in use by the particular user for a period of 3 days. In the event that all NetScalers are assigned, the user will receive an automated email.
    3. The Web Frontend will establish a session using XML API calls with the NetScaler using the “nsroot” credentials. The reset process involves using the XML API calls to get into the NetScaler shell to remove the ns.config file.  Simply deleting the NS.Conf will completely reset the NS config. That would be bad because that includes the IP Address.  We don’t want to go into the lab and connect a serial port and configure the device.  To solve this challenge, we  copy a base ns.config (which includes the NS IP configuration) over the current one.  We also have the code go through and remove any extra files that the previous user might have created (certificates, configuration files, etc).
    4. The Web Frontend will send code that will clear the NetScaler configuration, while keeping the IP address constant, so it is accessible from the network.
    5. The user will receive an automated email from the Web Frontend using the SMTP service.  The email informs the user on the connection information for the NetScaler.
  • WANScaler
    1. User selects “Provision WANScaler” from the Web Frontend
    2. The Web Frontend establishes an HTTP session with the WANScaler web console using the “admin” credentials.
    3. The Web Frontend sends a request to reset the WANScaler config back to factory defaults, while still preserving the IP address. Once the WANScaler has been set back to factory defaults, the WANScaler will be rebooted.
    4. The user will receive an automated email from the Web Frontend using the SMTP service.  The email informs the user on the connection information for the NetScaler.

Lessons Learned:

  • The biggest thing is that it is possible!!  The tricky part of the project was resetting the NetScaler and WANScaler back to factory defaults without losing the IP address. 
  • A more complete set of XenServer templates is required to anticipate any number of requests from the field

Next Steps:

  • Create a more detailed design that identifies the templates required for the initial release
  • Create a detailed set of workflows that are required to see how Workflow Studio can be leveraged to make this environment easier to build and maintain.
  • Create a way to hide Simpsons “Surprises” within the lab like logging into the lab and receive a warm welcome from Homer saying “D’oh!”

Hope you enjoyed this one.

Daniel

Homer Quote for the Blog “Look, the thing about my family is there’s five of us. Marge, Bart, Girl Bart, the one who doesn’t talk, and the fat guy. How I loathe him.”