AppLogic 2
.1 Streamlines Grid Computing”>
Server virtualization is growing at a breakneck pace, powered by the promise that the technology can eliminate some of the complexity of working with physical hardware and leave administrators free to focus on the workloads that drive their business. However, constructing the sort of virtual platform required to deliver on these utility computing promises is no small task, and its one that resides outside the reach of organizations lacking in significant virtualization virtuosity.
Enter 3Tera and its AppLogic 2.1, which brings server virtualizations lofty promises within closer reach for more organizations by streamlining the process of combining physical servers into a grid for hosting virtual machines and providing a framework for assembling complex, multiserver applications out of standardized VM building blocks.
For companies running server applications based on the LAMP (Linux, Apache, MySQL and PHP/Python/Perl) stack, AppLogic 2.1 offers a route to getting up and running with a virtualization platform that delivers load-balancing, failover and resource allocation functionality with fairly low management overhead.
AppLogic currently lacks support for other operating systems, so companies that need to serve Windows workloads must look elsewhere for a virtual solution. However, AppLogics Xen hypervisor core allows for the possibility of Windows support, and Windows and other operating systems are on the AppLogic road map, according to 3Tera officials.
AppLogic 2.1 is available through 3Teras hosting service partners or in a subscription-based model for companies that want to self-host their grids.
3Tera partner GridLayer offers AppLogic-based Virtual Private Data Center plans that range in price from $996 to $3,996 per month for four nodes, based on hardware specs, storage and networking resources. The self-hosted version of AppLogic costs $1,250 per month for a 10-server AppLogic grid license.
How It Works
As with other server virtualization products, such as those from VMware, Virtual Iron and XenSource, AppLogic 2.1 provides a platform for running virtual machines on commodity server hardware.
Unlike these other platforms, however, AppLogic operates at a level of abstraction above individual VMs. AppLogics atomic unit is the “application,” which consists of a group of specialized virtual machines that together carry out a server role.
Click here to read more about virtualizations success story.
For instance, a basic LAMP application under AppLogic consists of separate Web, database, file, network gateway and monitoring server VMs, all of which start up and shut down as a unit.
AppLogic ships with a set of reference applications, as well as a catalog of VM components, that administrators assemble into complete applications by dragging and dropping these elements onto an AppLogic design canvas.
The application designer is accessible via a rich Web interface served from the grid, as are a set of tools for controlling, managing and allocating resources among the applications and application components.
AppLogic in Action
I tested AppLogic version 2.1 on a four-node grid provided for my use by 3Tera. The test grid was composed of four dual-core servers with 2GB of RAM and about 700GB of storage each.
To create a Mediawiki server instance, I made a copy of a reference LAMP application that ships with AppLogic and copied the Mediawiki 1.11 code onto my new guest Web sever.
However, I found that the Web server component of the reference LAMP application was running Fedora Version 3, a rather old and unsupported revision of Red Hats enthusiast-focused Linux distribution. In addition to lacking available security updates, Fedora 3 does not include PHP Version 5, which I needed to run the most recent Mediawiki release.
To read a review of Fedora 7, click here.
Fortunately, the AppLogic VM catalog contained a CentOS 5-based Web server, which I simply dragged from the catalog side pane on AppLogics Web interface. I then used the Web interface to reroute the network, database, file storage and monitoring terminals from my original Fedora 3 Web server to my newly added CentOS 5 server.
Page 2: AppLogic 2.1 Streamlines Grid Computing
Page 2
I was pleased to find that since the Mediawiki source files Id copied onto my original server had been stored not on the server component itself but on a virtual NAS (network-attached storage) device within my application, my Mediawiki files were waiting for me when I fired up my application.
I also had the option of swapping out my single Web server with a four- or eight-pack of virtual servers, complete with an integrated virtual load balancer. In this way, I could take advantage of the four separate physical machines in my test grid while spending as little time as possible fiddling with the particulars of each component. This makes load-sharing fairly transparent and allows for practically built-in failover in case of hardware crashes.
In fact, at one point during my tests, one of the four physical machines in my grid went down, and, while I could see from the AppLogic Web interface that I was down a machine, the outage did not affect my testing.
As with other virtualization products, AppLogics individual VMs run only on one physical machine at a time. If the machine thats hosting a VM goes down, that VM goes down as well. When that happens, AppLogic restarts the interrupted VM on another machine in the grid—much like VMware ESX or Virtual Iron do.
Unlike VMware ESX or Virtual Iron, however, AppLogic provides for the shared storage necessary to enable VM migrations by aggregating the local storage on each of a grids physical servers into a mirrored RAID. 3PAR sells a product that adds this functionality to VMware ESX server, but, out of the box, ESX and most other virtualization products either ignore local storage or make it available only to the host on which its installed.
Its possible to connect an iSCSI SAN (storage area network) to an AppLogic grid by linking it to the virtual network interfaces of individual VMs within an application, but, according to 3Tera officials, few AppLogic customers use this configuration.
Software Support
AppLogic relies on Xen for its virtualization, so as long as the servers that comprise an AppLogic grid include processors with hardware-assisted virtualization, its technically possible to run any x86 or x86-64 operating system.
For now, AppLogic supports only Linux. According to 3Tera officials, the next operating system in line for official support is Solaris, followed by FreeBSD and then Windows.
While Xen can run unmodified operating systems, AppLogic guest machines do require some particular software to partake in the products grid environment.
In my tests, I encountered a snag related to these services. After I applied all available updates to my CentOS 5-based VM and restarted my Mediawiki application, the application failed to start properly. As it turns out, the update broke the services required to participate in the grid.
Based on my tests with AppLogic, it appears that tending to your application component templates will be the most time-consuming part of deploying workloads on AppLogic.
Id love to see 3Tera forge partnerships with companies focused on delivering software appliances–such as rPath, Red Hat, VMware or (eventually, at least) Microsoft–to make it easier to deploy AppLogic grids on the software appliances that these companies provide or aggregate.
Check out eWEEK.coms for the latest news, views and analysis on servers, switches and networking protocols for the enterprise and small businesses.