Posted by Pete Sorensen on Fri, Sep 25, 2009 @ 03:45 PM
VDI is a very useful concept that is starting to take hold in production desktop environments. In essence it is virtualizing desktop Operating Systems, Applications, and Data and moving it all to the data center with the user only accessing these resources via endpoint. This endpoint can be a thin/thick client or web browser and in some cases a smart phone. The idea is that the endpoint is stateless and ideally retains no user data as it only serves as an I/O conduit.
VDI like most concepts is quite broad. However I tend to view it this way:
As you can see the Operating System, Application layer and User Data are treated as separate and independent entities which align to give the user a seamless experience. This allows for easy modification of each layer without impacting the others. With this model the O.S. is just a stateless environment for applications to be launched and data to be generated and modified. But if the O.S. were to disappear, the applications and the user's data would not be affected. A new O.S. could then be provisioned for that user with a minimal outage.
On the application virtualization side, applications would launch from ‘file servers' and be managed by application virtualization technology such as InstallFree, App-V, and ThinApp. The advantage to this is if you want to push an updated version of an application to a user set you would virtualize that update and push it to the file server. Then the next time the user runs this application they would be running the new code. Inversely if you wanted to serve multiple versions of an application simultaneously this would also be supported as the applications would each be in their own virtual space on the O.S. they are executing on.
User data is a matter of re-direction to CIFS file servers (for windows clients). This means actual backups, snapshots and dedupe of user critical data is made accomplishable in an efficient and cost effective way. This also brings tiered storage into view. Having your actual VM's on low latency, high throughput storage (SAN) and your raw data on cheaper, higher density storage (NAS). This is an important cost savings element.
Endpoints do not have to be consistent over an environment. Repurposing Thick Clients, using various Thin Clients or just a web browser are all acceptable. There are a few things to consider with endpoints such as multimedia performance, USB redirection, VPN capability, Connection Broker compatibility and security being the ones that are of main concern.
VDI does a great job of taking the risk and load off of desktops; however it redistributes that load to your network infrastructure. You must look long and hard at your network to verify it is able to keep up with the increase and type of traffic. VDI traffic tends to be bursty as is the nature with remote display protocols. It is also sensitive to latency and packet loss which is a strong consideration on WAN deployments on the fringes of you network. VLANs and QoS are good measures to implement to keep this traffic segregated and at the right priority level. Redundancy for these systems and the networks they run on is key, as any outage affects many users simultaneously.
So the conclusion is that VDI's benefits are a great for cost savings, increasing quality, and managing your desktop infrastructure. It provides enhanced reliability, usability and security to your infrastructure. However implementation must be well thought out and engineered from the NICs to your storage and to the end points. Implementation in phases is a good practice as it allows you to ramp up your SA's skills and find trouble spots without large impacts.
Posted by Steve Putre on Thu, Sep 17, 2009 @ 09:03 PM
XVMOC adapts to a wide variety of customer environments through the use of proxy hosts and operating modes.
The architecture of XVMOC consists of a single Enterprise Controller which communicates with any number of proxy servers. The proxy servers communicate with the agents on the managed hosts. Proxy software can be co-located on the same host as the EC or can reside on separate hosts, commonly in geographically distant or security-isolated datacenters.
The other architectectural building blocks of the XVMOC system are the agents (one per managed host or Solaris Zone), and the web browser, which connects directly to the EC.
The EC does not communicate directly with agents. The proxy is responsible for all communication with the client agents. All communication among the layers is secure HTTP.
The net result of this architecture is a system which can scale to very large global deployments.
To accomodate customers operating in controlled environments, XVMOC supports three operating modes:
- Fully connected, where patches, packages, and active knowledge are downloaded directly from Sun over the internet and customer inventory data is uploaded to Sun's facilities,
- Semi-disconnected, which is the same as fully connected except that inventory data is not uploaded to Sun,
- Disconnected, where the EC is not connected to the internet and data is loaded into the EC's local database using CDs or DVDs
Posted by Steve Putre on Thu, Sep 17, 2009 @ 09:02 PM
Anyone who has managed the Solaris operating system knows that Solaris patch and update management has historically been a time-consuming, anxiety-provoking, and sometimes frustrating process. What has made Solaris patching painful? Let's dig up some bad memories...
- You had to spend hours reading README files, trying to figure out patch dependencies, special install instructions, and system requirements.
- You needed to download every possible patch from Sunsolve, copy them to every server, and attempt to install all of them on your systems, only to have the systems tell you that a good percentage of them are not applicable either because the corresponding package does not exist or the patch is already up-to-date.
- You had to schedule hours of downtime to patch your systems, and in many cases had to manually bring your systems into single-user mode just to add patches
The key to an efficient patching process is active knowledge. For the past three years, Sun has maintained a database of dependencies for every patch and package released not only by Sun, but also by RedHat Enterprise Linux and Suse SLES. Every patch which is released by these vendors is, within a day or two of its release, vetted and entered into a database which tracks all of the patch's dependents, dependencies, and requirements. The vetting process goes beyond the contents of the README file and reaches down to the level of each binary and library in the patch bundles to determine dependencies, conflicts, and requirements.
So Sun has done our patch research for us! How do we get our hands on this knowledge? Answer: Sun's XVM Ops Center (XVMOC) product. Ops Center has been evolving for a number of years now, starting with Sun's aquisition of Aduva and its OnStage product. This evolved into Sun Update Connection, and then to XVM Ops Center 1.0. XVMOC is now in its 2.1 release, with version 2.5 due to be released in the fall of this year.
Having spent much of my career managing, installing, and upgrading Solaris systems, it is clear that XVMOC 2.1 represents a new emphasis on systems management for Sun. It makes the process of patching and upgrading systems much easier and faster than ever before, by:
- Applying patches to many hosts simultaneously
- Determining in advance which patches need to be applied, downloading only the necessary ones from Sun, and copying only necessary packages to each individual host
- Providing the ability to perform dry-runs to reduce the chances of a problem during the patch process
- Enabling quick and clean rollback of any changes to a system
- Support of Sun-recommended and customer-custom patch baselines
Compared to many past products, the browser-based GUI is polished and easy to navigate. The core functionality of managing and installing patches has been augmented by a long list of additional features and capabilities, particularly:
- Bare-metal provisioning of Solaris, Redhat RHEL, and Suse SLES operating systems on Sun and non-Sun hardware.
- Ability to perform firmware upgrades on Sun servers
- Deep monitoring of Sun hardware, ala SunMC
- Direct communication with Sun ALOM, ILOM, and XSCF service processors
- Ability to provision arbitrary products, packages, and scripts onto Solaris, RHEL, and SLES systems
- Tracking of system capacity parameters such as historical CPU, memory, and filesystem usage
- Management of Sun Logical Domains (LDOMS)
XVMOC can integrate with various Enterprise Systems Management platforms, such as Openview, Netcool, and EMC Smarts through the use of Halcyon's Neuron integration module. System alerts captured by XVMOC can be forwarded to the ESM for action.
In future releases, XVMOC will have the ability to perform full lifecycle management of Solaris Containers. Stay tuned for more information.