IT Troubleshooter | Harper Mann » July 2006

July 19, 2006 | Comments: (0)

Virtual Machines - "Another Thing you Have to Manage"

TAGS: Virtualization

InfoWorld recently launched their first Virtualization Executive Forum -- taking place later this year in New York (fitting, considering how entrenched virtualization is in the financial services world). Looking at the program, it appears that the program is primarily concentrated on the benefits of virtualization ... but I'd be interested to see a little more discussion surface about the nuances / challenges of actually managing virtual environments.

As another InfoWorld blogger discussed nearly a year ago, sometimes it gets lost in the shuffle that virtual machines themselves are not the cure-all for IT management ... and in fact are another layer of complexity and themselves must be managed.

I recently touched base with Levanta's product and marketing manager, David Dennis, who drilled down a bit more on the management challenges when you start bringing virtual machines into your environment:

"People are using VM's in tandem with physical hardware ... and that reality presents management challenges on a number of levels.

While XenSource has the Xen Optimizer to manage Xen, and VMware has VirtualCenter and VMotion -- neither can manage the other. In addition, neither can manage non-virtualized machines. And further complicating the matter, the management tools from the non-virtualized distributions are going to be different from how an organization will want to manage their VMs. Technologies like YaST, yum, and Red Hat Network can provide content for a virtual container, but do nothing for portability.

So the problem is, very few of the management approaches out there today take into account the idea that people will want to move their virtual machines around wherever they want to, or in some cases, flip between the virtual world and the physical world. The challenge is being able to move the virtual container from a rack to a blade to a box or from a development environment to a production environment."

The trick is for the individual lowest-level servers to be simple and quick to change. Virtualization doesn't seem to help that and it tends to require larger servers which are more complicated to deal with as well. The successful grids seem to be comprised of small, often blade, servers that are managed as commodity. You basically roll out 100's at a time and you target them with images. With a virtualized machine, you tend to have more complexity and problems with resource sharing than if the servers are physically separate.

Posted by Harper Mann on July 19, 2006 07:31 PM

July 17, 2006 | Comments: (0)

SmokePing Adds Great Latency Measurement to the Open Source Monitoring Equation

TAGS: Open Source

A few months ago, I wrote about Tobias Oetiker's MRTG and RRDTool services -- which are really leading the charge in collecting / visualizing network monitoring data.

Another tool by Oetiker and his colleagues that's seeing a lot of traction these days is SmokePing, a latency measurement tool that uses RRDtool as the database and graphing back-end.

Usually, networking pros use pinging as a diagnostic approach. You experience a problem connecting with a service or machine on the network, so you go into command line, and you try to ping that location. If it answers, then you know that at least the network parts are communicating with each other, and you can use that information as one of the preliminary data points for figuring out the source of the problem.

With SmokePing, you can set up different locations on the network to be pinged at the time intervals you specify. With the great graphing / visualization capabilities of RRDTool, you can see over time what the latency is at different points on the network. And you can easily set up alarms correlated with certain thresholds, and by consolidating your different pings, you get a more cohesive / manageable view of all your different latency measurement points in one place.

There are other types of open source ping tools out there -- such as the popular check-ping in Nagios. But I've been finding the SmokePing service to be extremely easy to set up and maintain, and the great graphing capabilities have made it the current leader in open source approaches to pinging services, in my opinion. It's definitely worth checking out if you're seeking an easier way to track latency trends across your network.

Posted by Harper Mann on July 17, 2006 06:14 AM

July 06, 2006 | Comments: (0)

Keeping Tabs on Open Source Mixing and Matching

TAGS: Open Source

The degree of choice and customization that open source affords is one of the key selling points that sets it apart from proprietary solutions (every bit as appealing as the lower cost of acquisition, from many organizations' perspectives).

But when organizations start mixing and matching different open source technologies, they find that "open" doesn't necessarily mean "interoperable" -- and incompatibility between different open source technologies can take down systems just as easily as interoperability issues between different proprietary products can take down systems or applications.

"With open source projects we can sometimes get seduced by their promise and skim over the effort it takes to get it all to work together, the license issues for dozens of applications included in a particular stack, or even the complexities of mixing open source with proprietary and commercial software," according to Steven Grandchamp, CEO of OpenLogic, a company that provides software and support to help enterprises manage open source. "Often different teams, groups or divisions are using very different sets of open source solutions. Large companies often don't know where it is, how it's used, or what license it is under."

In the Windows world, Microsoft has a great deal of control over their operating system, database tools, software. While that doesn't mean that there aren't common failures and problems -- there is a single point of control over the discreet components. Today's news that Microsoft was taking efforts to interoperate with ODF was an interesting example of how a proprietary vendor's customers can pressure that vendor to create better interoperability with open source solutions.

In the open source world, typically there is no single point of control, and no assurance that one technology will work with another. People generally start out with Red Hat Enterprise Linux, Novell SUSE, or another popular Linux distro. Then they go onto the open Internet and start playing with individual open source projects (on SourceForge, there are currently more than 122,000 registered open source projects).

Over time, an organization can accumulate a ton of different open source technologies under its umbrella, and when incompatibility issues start popping up, the user often doesn't know who to call when a system or application goes down. Further, the company likely does not have a very disciplined understanding of all the different license restrictions on the open source technologies they're using, which introduces new liabilities in an audit scenario.

The point isn't to induce a sort of hand-wringing anxiety about open source use in enterprise. Open source is a fact of life today, and ultimately these interoperability issues are much easier to solve between open source solutions than they are between proprietary solutions.

With the news that Sun is open sourcing Java, we're going to see the open source integration and compatibility issues continue to become more complex. As Sun exec Rich Green said in a CNET Q&A that ran today, "Java is more advanced than, I think, any other open-source software in terms of compatibility testing, the availability of (testing suites) and other things like that." So what does that mean for the organizations whose employees start tinkering around with open source Java, and building new applications with complex dependencies on the JVM?

When Red Hat announced earlier this year that it was kicking off its own open source certification efforts, a lot of media outlets suggested it would be the death of the crop of start-ups that are addressing compatibility and certification for open source stacks. But I think with the degree of customization that takes place with open source adopters -- and the sheer volume of open source point solutions being adopted -- the complexity of keeping a handle on these systems will support a pretty large ecosystem of vendors like OpenLogic, SpikeSource, SourceLabs and the like.

Posted by Harper Mann on July 6, 2006 01:35 PM