Archive for October, 2009

h1

Tech Notes: XenServer and Neverfail

October 27, 2009

Neverfail is a wonderful business continuity product. I’ve been deploying it for a few years now, primarily for Microsoft SQL and Microsoft Exchange protection, and earlier this year, I had the opportunity to deploy Neverfail for Exchange to a virtualized environment.

My client has used Neverfail for the last couple of years with physical server pairs and crossover cabling for the Neverfail Channel, which is the traditional way to deploy this solution. So I deployed Neverfail for SQL 2005 and Neverfail for Exchange 2003 for them on separate projects a couple of years ago and away we happily went.

The main objective behind a virtualization intitiative, was to lay the foundation to allow for fast growth by leveraging virtualization technologies to conserve server resources and provision those resources quickly. We began planning a series of core infrastructure hardware upgrades to put them in a position to deliver these resources to the existing campuses and to new campuses as they came online. In addition, a planned upgrade (including virtualization) of the CampusVue architecture, the main Line of Business application, was in the planning stages and laying the groundwork now would be critical to ensuring success for that project. (I will post a Tech Note on CampusVue 11, n-tier virtualization deployment using XenServer in the near future).

Initially, I was concerned that we were going to have to select a different hypervisor and given the scope of the overall virtualization effort, was not really keen on that. But Citrix XenApp just plain outperforms the competition on XenServer and since the main Line of Business application for this client is delivered using Citrix Presentation Server 4.5, the choice was to go with XenServer 5.

Some months prior to planning these infrastructure upgrade initiatives it became apparent that there was one server in the Neverfail for Exchange server pair that was past end-of-life and the client was preparing to buy a new server. In fact, the Primary Server failed completely and was shut down for several months. I suggested that given the virtualization efforts, why not simply install the Neverfail Secondary server into a VM? In theory, it should work, but I began researching this as a viable option, since there was already a budget for virtualization server hardware, storage, core switching, etc.

Neverfail has quite an extensive knowledge base and I found several articles and spoke with several folks over there about this solution, but there just wasn’t much data. They have information in their KB regarding VMware but not much was published on XenServer. But since the product could work in ESX, it was a pretty safe bet that it would work on XenServer, so I began planning this during the initial virtualization deployment.

The initial deployment was a 2-node XenServer 5 resource pool using a Lefthand Networks iSCSI SATA SAN (pre-HP) that I had deployed during the initial Neverfail implementation. Originally that SAN had been used as a backup target and subsequently Exchange databases were moved to one of those LUNs (no, I didn’t do that part). I surmised that as long as we didn’t push any serious I/O through those LUNs, then we should be fine. In addition, I put in a temporary HP Gigabit switch to ensure that his throughput was a bit more reliable. These measures were temporary since we were expecting new hardware specifically ordered for this purpose.

After the nodes were deployed, I created the VM for the Neverfail for Exchange Secondary and began the re-deployment of Neverfail. I won’t go into the gory details from the Neverfail procedure (and it is quite detailed and wonderful), but I will abbreviate it here:

Build Secondary Server

1. Must have the same OS version, Service Packs & hotfixes
2. Must have same drive letter configuration with volume sizes => Primary Server
3. Must have same network configuration for LAN deployment

Deploy Neverfail software to Primary server. This process does the following:

1. Installs Neverfail software
2. Clones Primary Server using NT Backup
3. Reboot and server is again ready to provide services to users

Deploy Neverfail to Secondary server. This process does the following:

1. Installs Neverfail software
2. Restores “clone” to Secondary
3. Configure network appropriately
4. Reboot and servers will synch (a lengthy process)

This procedure is incredibly well documented by Neverfail. The only changes that I had to make on the fly are explained below. In addition, the XenServer Tools (PV drivers) MUST be installed prior to beginning ANY work on the Secondary. The IP configurations get all hosed if you don’t.

During the course of this implementation, I created VLANs on the client network, creating one for the Neverfail Channel. Since the XenServer NIC bonds were trunked to the switch, I had to do this to ensure that there was protected layer 2 communication between the physical Primary Server and the virtual Secondary Server network interfaces. Plus, it’s a standard practice when deploying XenServer ;-) .

The network portion of the XenServer resource pool, by default, is essentially a shared switch configuration. So, if viewed from that perspective, it’s quite easy to configure “virtual networks” with assigned VLANs for tagging traffic out the trunked NIC bonds (I used bonds in this scenario for most traffic, but a single NIC for the Neverfail Channel).

The “gotcha” comes during the portion of the Neverfail installation that asks you to ” disconnect the network cables from all network adapters on the Secondary server (the cables Must be disconnected rather than disabling the network adapters to proceed)”. I worked around this by disconnecting the Primary Server NICs, since that cannot be done in a XenServer VM. Since the restore process will actually overwrite IP configurations, this is critical to ensure that two Active servers are connected and visible to the network simultaneously, which could cause data loss and/or corruption.

During a Neverfail deployment, the Neverfail Primary server down-time window is equal to the time to install the Neverfail software + time to clone + one reboot. In a deployment to a virtual machine, this time is extended to include deployment of the Neverfail Secondary server to ensure there is no data loss. I am sure there are alternate ways to achieve the same result, but this is the way that I chose to ensure the integrity of the environment. If you have an alternate solution, then please chime in!

In any case, it’s quite a nifty little setup . When the remaining hardware was shipped and I built out the remaining components: 7 XenServer nodes, HP LeftHand P4500 and a Cisco 3750g stack (two nodes) and these components were deployed, we switched over to the Secondary (virtual) server for testing and it’s been running “virtually” ever since. Surprisingly enough, we were able to correct a memory problem by virtualizing this without service interruption. (More on Free Memory PTEs and Neverfail at a later time)

So all-in-all, Neverfail on XenServer is quite a nice leverage of virtualization technology and equals happiness for my client.

Posted in Tech Notes, The Business of Technology | Tagged , , , | Leave a Comment »

h1

VDI and User-installed Applications: The way I see it.

October 23, 2009

There has been much ado about whether or not to allow users to install their own applications in a VDI environment on Brian Madden’s site here , Dan Feller’s blog here and Chris Fleck’s blog here. I’ve tweeted back and forth a bit, but nothing serious and started pondering the reasons why this appears to be such an involved discussion when I don’t believe it should be. Yes, it does impact design of the solution. Yes, it can increase TCO. So maybe not such a trivial argument at all, eh?

Here are my thoughts and opinions on the matter.

You should ask the questions “Why are you considering a virtual desktop solution” ? What are your business objectives here? Is it for better control of the desktop? Security? Scalability? Is it just plain cool? (yes, this is a reason folks deploy things, surprisingly enough) What is driving the effort?

The very next question to ask is “What do you allow now?” Do you have your workstations locked down such as to prevent local application installation or do the users have quite a bit of lattitude?

And the final question: “Is there a valid business reason to allow this for all, or even some, of your users?” Do you allow it now because you can’t stop it easily? Do you disallow it because the management and policing is too much time spent?

If you answer those questions for your organization, then you’ve likely answered the question of whether or not to allow users to install applications on their VM. And if the question isn’t answered 100%, you at least have a solid starting point from which to move forward.

You can then begin to have conversations with management, IT staff and users on what the solution should be. End users really needs to be part of these conversations, pilots, proofs-of-concept, deployment & user acceptance testing. This is critical to the success of the effort and if you fail to account for this, then you’ll likely be faced with the perception that the project has failed in some form or fashion.

So do you or don’t you? You know, allow users to install their own applications?

Well, only the organization can answer that (see above). And remember, Mr. Architect, in ANY technology initiative: One size does NOT fit all!

I would guess that many organizations will allow some of their users that ability, and some not. So, a hybrid solution is likely to be the case for most implementations, but once again, it really depends on the organization’s business drivers, management capabilities and expectations that will be deciding factors in the debate.

Posted in My Opinions and Editorials | Tagged , | Leave a Comment »

h1

Technology Decisions for Business Owners

October 22, 2009

I began working on this post as a result of interactions with business owners over the years when talking with them about technology solutions or services they were interested in implementing. I realized that many business owners, especially small businesses, have a good understanding of their business, but are not “techies”. Also, truly vetting a product or service was not something that was commonly done.

Most relied on marketing information, what could be “Googled” or a sales pitch on specific benefits that “may” be provided to their respective business. I noticed this often led to misinterpretation or misrepresentation of the technology or service and that subsequently led to a customer satisfaction problem for the vendor or provider.

Because of this, I decided to write up some considerations that small business owners can use to help them make better decisions. Vendors and providers, take head, as this could also be viewed from your perspective as a “what not to do” or “how to ensure the customer gets what they expect”.

Upgrades/Maintenance

This is the most common scenario since most businesses have some form of technology already deployed, which could range from a single site with a couple of workstations and bookkeeping software to multiple servers and workstations deployed over multiple sites with multiple Line of Business and office productivity applications.

Upgrading applications, workstations, servers, etc is a regular process that has a couple of drivers. One, the software/hardware manufacturer no longer supports the software version or hardware that your business is using. Two, the new software version or hardware has capabilities that would help increase productivity in your business.

Most businesses plan on using their hardware (i.e., servers, workstations, firewalls, etc.) for up to 5 years. Some business owners even consider it a one-time capital expenditure that should not have to be repeated and the software often goes unaccounted for with regards to budgeting. Problem is, new hardware comes out quite frequently (new processor chips, new types of memory, new PC models, etc) and software manufacturers have major releases every year or so.

Putting these costs in your business plan is a way to avoid the sticker shock. Upgrading software, which often requires better hardware, can drastically increase your expenditures if the hardware requirements are not accounted for.

Does this mean you shouldn’t upgrade your software? It depends. Does the manufacturer still support the version that you’re on? Does your business require a feature that is only available in the newer version? Will productivity be improved if you upgrade? These are questions you need to answer to help determine your path.

New Technology

Whether it be a new phone system, network infrastructure or a new software solution to help with your business productivity, new technology has hidden costs you may not be aware of.

Deployment cost is sometimes unaccounted for. You buy a solution from a vendor, but now you have to pay to have it installed.

Management cost is the most often overlooked. You have this brand new solution, but who is going to perform the day-to-day maintenance? Perhaps you have a dedicated IT staff that does this. Perhaps you do not have dedicated staff, but have someone whose primary job is something else. Management of a solution is an important part of the overall cost consideration.

Training cost is often neglected since any new technology will likely require training for your users. And training your users on a new technology takes them out of the day-to-day, which means decreased productivity. And of course there is technical training required to ensure that someone on your staff can maintain your new system. Things like performing backups, adding/removing user accounts or new staff training.

In addition to these costs, the upgrade/update costs should subsequently be added to your business plan as I mention above in “Upgrades/Maintenance”.

So, who’s going to install it? Who’s going to maintain it? Who’s going to train my users? How much are upgrades? Can I buy a subscription that gets me the upgrades for no additional charge?

These are questions you should ask to help you make better decisions for the long term goals of your organization. Be skeptical. Require proofs of concept or live demos, not mock-ups. If possible, speak to someone who’s already using the technology. This gives you a clearer understanding of what it’s really like to own a product/technology and will go a long way towards making your business more profitable.

Posted in The Business of Technology | Leave a Comment »