Scalent Systems

The Virtualization Stack

2008-04-28T14:12:00.001-07:00

The management of virtualized IT environments has become the latest technology issue due to the added burden of managing physical and virtual machines. In addition, each machine needs network and storage resources, and they may be part of a greater virtualized environment leveraging I/O virtualization, infrastructure virtualization, application virtualization and grid computing as well as umbrella management software orchestrating the various components into action.

There are a number of virtualization solutions which individually provide great flexibility, but a tradeoff of management complexity emerges, especially when these solutions are used together. It is useful to have a framework to think about these capabilities and map them to what you might need in your data center. We propose the following virtualization stack:

Server Virtualization:

Let's start at the beginning with an analogy of physical servers and a family residence to illustrate the power of server virtualization.

Server Virtualization is somewhat like moving from a home into a condo. If you own ten physical servers in your data center and want to consolidate down to one physical server, server virtualization software allows you to do just that. Companies including VMware, Xen/Citrix and Microsoft all provide solutions that allow a physical server to run multiple operating system instances and resulting families of applications. IBM, Oracle, Red Hat, Sun Microsystems, and Symantec are all invested in the open-source Xen hypervisor project.

For many companies, server virtualization has been the first big step into data center virtualization. It put VMware on the map with their IPO in August 2007, and has yielded cost savings and consolidation benefits over non-virtualized environments. When you enable multiple virtual servers and their associated applications to be consolidated onto fewer physical servers, you can more efficiently leverage a smaller number of machines, resulting in decreased expenses

Infrastructure Virtualization:

While server virtualization's hypervisors allow for a single physical machine to host multiple virtual machines, infrastructure virtualization reaches beyond the server into the data center resources outside of the control of server virtualization solutions.

Infrastructure Virtualization's emergence as a category is an acknowledgement by the industry that servers (virtual and physical) are not stand-alone resources, but rather require the leverage of network and storage resources from throughout greater data center.

Infrastructure Virtualization software products on the market today include Scalent Systems V/OE and Unisys's uAdapt. The purpose of Infrastructure Virtualization is to ensure that a server is given its required network and storage resources as needed based on the company’s business requirements and strategy. The solutions support existing bare-metal servers running Windows, Linux, and Solaris as well as full hypervisors such as VMware ESX, Xen, and Microsoft Hyper-V – with their VM load.

One effect of deploying Infrastructure Virtualization in your environment is that bringing a server on-line can be coordinated against the automated provisioning of network and storage resources to support that server. Boot storage can be allocated for diskless hosts and virtual network connectivity (VLANs) can be dynamically created to enable appropriate servers to connect with each other. This frees data center managers from having to pre-provision static associations of storage and network to servers, and breaks down silos of resources into freely available pools as needed.

Comparing server versus infrastructure virtualization reveals that the two solutions provide distinct and complementary functionality in the data center. Going back to our original analogy, server virtualization creates condos out of servers, and infrastructure virtualization dynamically moves families into and out of the appropriate units, and sets up the utilities required for occupancy, in real-time - connectivity to the network and storage. Depending on the number of physical and virtual servers that you manage, you probably need both server virtualization and infrastructure virtualization.

I/O virtualization:

I/O Virtualization consolidates the number of physical I/O connections to a given server, and also allows I/O and multiple virtual connections to tunnel through to network and storage resource across a consolidated physical infrastructure. The promise of I/O virtualization includes condensing network and storage connectivity with fewer physical cables to manage, fewer network interconnect cards deployed, and fewer switch ports consumed for the same amount of computer power.

Players in this space include Nuova, 3leaf, and Xsigo, and there is additional software specific to each solution which assigns SAN and network connectivity back to a given server. From an administrative standpoint, the physical layer becomes much easier to manage with fewer cables while the management of the virtualized connectivity to given machines becomes more complex as the virtual resources increase.

I/O virtualization complements server virtualization and infrastructure virtualization by aggregating the path to network and storage resources so that fewer components need to be touched overall. Using the condo analogy, I/O virtualization ensures that when the utilities leading to the complex become overloaded, certain tenants get priority use of those resources.

Infrastructure Virtualization software dynamically provisions a new I/O resource when bringing up a machine, and provides coordination between server virtualization and virtualized I/O resources.

Application Virtualization:

Gaining momentum but not widely deployed yet, application virtualization technologies help package, store, and distribute end-user software in an on-demand fashion across a network. This goes hand-in-hand with many of the standardized web services initiatives making waves in the tech world today.

Virtualized applications use a common abstraction layer, which defines a protocol, allowing them to communicate with one another in a standard messaging format. Thus, applications can invoke one another in order to perform requested functions. A virtualized application is not only capable of remotely invoking requests and returning results, but also ensuring that the application's state and other data are available and consistent on all resource nodes executing the application across a grid.

Application Virtualization vendors include Citrix Presentation Server, Microsoft SoftGrid, AppStream, and DataSynapse, to name a few. These solutions can run incompatible applications side-by-side at the same time, allow applications to run in environments that do not suit the native application, and improve overall security by isolating applications from the operating system. It may surprise you to find that application virtualization consumes fewer resources than deploying individual applications into separate virtual machines.

Again, Application Virtualization is complementary to the other forms of virtualization, running at the application layer on the others' virtualized infrastructure and OS.

Data Center Orchestration:

Data center orchestration provides an overarching category for coordinating the deployment of resources with the service level required by the business. If you're interested in learning more about data center orchestration, or want to learn more about how to gain efficiency in your data center via Infrastructure Virtualization, come talk with us!

Alana Achterkirchen, Director of Marketing, April 28, 2008

IT Cost Savings in a Recession

2008-04-02T15:22:00.000-07:00

You feel it at the gas station, see it in the housing crisis, and hear about the losses hitting the biggest banks on Wall Street, so don't ignore the current state of the economy. The government will most likely declare a recession, which sometimes occurs after the worst is over. A recent example was the recession in the 1990's which started in July 1990, but wasn't declared until April 1991, ended in March 1991 but wasn't declared over until December 1992 (Source: National Bureau of Economic Research). Don't wait for a recession notice before you look at ways to cut IT costs in a tight economy.

There are ways for companies to cut IT costs while gaining efficiencies and come out with a much more flexible IT environment. Let's consider a comparison between cars and data centers. There are a lot of Hummers and Land Rovers on the highway these days, which makes sense if you're always driving through the African Serengeti or are fully-burdened with kids, dogs, and camping equipment for a weekend getaway. But much of the time, large SUV owners are simply over-provisioned due to the cost-prohibitive nature of trading in and out from one vehicle to another. Similarly, data centers have big footprints and consume power at rates sized for peak, which more often than not delivers underutilized and inefficient results.

Further exacerbating the problem, many companies have deployed Veritas Cluster Server (VCS) software as their solution for server availability. VCS leverages a two or more dedicated servers to replace a single server, each with their own operating environment, applications, and resulting infrastructure, services, licensing, power and real estate consumption to go with it. With this solution, data center costs can double, but your service stays up in the event of a failure.

So, the question of the day is how many servers do you have doubled up right now?

At Scalent we have taken a different approach, one that does not require the static association of dedicated hardware to enable server failover. Scalent's infrastructure virtualization, applied to server fail-over, essentially allows for any production server to be replaced in boot time, or about 5 minutes. Rather than relying on static, pre-deployed backup machines, Scalent can failover your production servers, moving the storage and network from a failed server to a replacement server automatically, which eliminates the need for VCS licenses as well as the multiple copies of OS and applications being leveraged.

What about servers for which 5-minute replacement is not good enough?

Simple. Keep using your current HA solution for these servers. When failures actually occur, the service will keep running and Scalent V/OE can replace the failed server in boot time, which limits the time you are exposed to running in a degraded mode to about 5 minutes. You might be surprised looking through your deployed services to find that the vast majority of these services fall into the category of store-and-forward applications, for which boot time replacement is good enough.

Want to decommission a few servers with their associated software and support costs? Call us.

Alana Achterkirchen, Director of Marketing, Spring 2008

Turning Waste into Resource in Your Test Lab: A Conversation with Scalent CEO Ben Linder

2008-02-26T16:01:00.000-08:00

In an interview with Ben Liner, CEO and Co-Founder of Scalent Systems, this month we'll explore some of the traditional challenges that Test and Development labs face and how Scalent V/OE (Virtual Operating Environment) can help you build an automated, virtual test lab environment.

Alana Achterkirchen: Let's start off with a basic question. Tell us about the fundamental challenges that Test and Development labs face?

Ben Linder: Talking with our customers every day, there's some interesting facts that we observe. One thing is the preponderance of servers, the sprawl of servers, in the enterprise. An interesting factoid is that for every single production machine there are typically four other servers in the enterprise that are there in support of that machine.

So for every machine in production, there's usually one in development, there's usually one in test and QA, there's usually one pre-production, and there's another one in disaster recovery. So a very simple application can drag behind it tens if not hundreds of servers, and that's a huge challenge for our customers.

It's widely known that test and development processes are inefficient with regard to the number of systems. Once engineers set up a test cluster, they don't ever want to tear it down. As a result, you wind up with more and more test rigs being set up and they just never go away. Some of our customers have tens of thousands of servers in test and development. The old way of doing things is too inefficient: you'd install and configure everything directly onto each server, everything onto the local hard disk of the server. You'd install and configure all the network topologies and switches, and all of the access to storage. Once it's all done, nobody ever wants to take it down even if that application is only tested once every six months.

These underlying inefficiencies and the requirement of dedicated systems which are incredibly underutlized - sometimes less than 1% - is a huge contributor to waste in the enterprise and sprawl of servers. That's the issue that Scalent is set out to solve with creating higher efficiencies in test and development environments.

AA: Let's drill deeper into this problem. How would Test & Development labs benefit from infrastructure virtualization technologies?

BL: It's very simple: when you use systems, you use them, and when you're done, you can release them back into a shared pool. It's the concept of turning test and development labs from captive, static resources that sit around doing nothing most of the time to shared pools of infrastructure that can be effective used by whatever groups need them. So when a test is underway, machines are being used. When testing stops for an application, those machines can be returned to a pool of machines that can then be made available on a shared basis to any other application group.

The net result is that virtualization technology allows consolidation of test and development labs so you need fewer servers, it allows rapid reuse of the existing servers so you get higher utilization, and it lowers the overall cost and increases the overall reliability of test and development processes.

AA: How does Scalent specifically address Test and Development lab automation?

BL: We're able to come in and install our software in a shared test and development infrastructure, and create a pool of resources that are available to any group within the enterprise.

The beauty of this is that servers aren't statically assigned to application groups. Instead, servers are reserved by application groups. They're repurposed and provisioned by the Scalent Virtual Operating Environment into whatever role they need to be for that period of time. So, an application group might request 10 servers for 2 weeks and Scalent automatically provisions those as well as the network and storage connectivity for those servers. When the development group is done, they release those resources back into the pool.

The Scalent Virtual Operating Environment automates the assignment of resources, the provisioning of resources, and then the release of resources back into the shared pool. The result is a much more efficient, reliable, and timely implementation of the test processes.

AA: Thanks Ben, and thanks everyone for joining us. If you're interested in learning more about how you can create a highly efficient test lab environment, give us a shout. The direct phone number to our corporate headquarters is (650) 424-1222.

Alana Achterkirchen, Director of Marketing, February 2008

Evolving - Just Do It

2008-01-28T14:04:00.000-08:00

Sitting in a meeting today, somebody said 'Remember when cell phones were as big and heavy as a brick?' Everyone nodded with the mutual understanding of how backwards things were in the mobile phone industry 10 years ago. We could all come up with a massive list of 'remember when's' because the world is relentlessly dynamic to the peril of those who fear change. Who can afford to ignore the plight of the T. Rex with its large, almost monolithic structure and status as king of the dinosaur world. You can be massive, fierce, and carnivorous, but you'll perish if you fail to adapt to your surroundings. The business world isn't much different.

Today, there's a massive paradigm shift going on in data centers around the world. It's due to a disruptive technology that radically changes the way things have been done in data centers for decades. When you first hear about what virtualization technologies can do, it all sounds like a black art or maybe a crazy April fool's joke. But April is a few months away, and VMware's IPO was last August. Today, you can install server virtualization technology on a server, which masks server resources and allows administrators to create multiple virtual environments, with different applications and configurations, that can run on the server.

Scalent V/OE provides even more extensive functionality with Infrastructure Virtualization. By installing Scalent's controller on an x86-based server, you can manage pools of servers, their power state, and even transition entire pools of servers between different configurations along with their connectivity to their designated storage and network in five minutes or less. Applied to humans, this would be akin to teleporting yourself (and your connections, maybe some family members) at a touch of a button to a pre-designated location anywhere in the world in five minutes or less. To continue the analogy, Scalent's server repurposing capability applied to humans would mean that in the event of major disaster, you could bring up a new copy of yourself somewhere else in five minutes or less.

Questions?

In our customer meetings and at conferences, we commonly hear: 'What's wrong with booting stateful disks in my local servers? Isn't it more expensive and slower to boot from SAN?' Although Scalent doesn't force your storage connectivity decision, you can boot from local disk, over Ethernet via ISCSI or NAS, or SAN boot over fibre channel, we recommend booting stateless servers with external storage. That's not only because you get higher performance, higher reliability, and more resilient storage, but also because it's possible to failover a server with its connection to storage. The older paradigm of booting from local disk requires a lot of driver and BIOS work, which isn't easy to do. The disks take up your running environment and the tapes suck up time and energy. Worst of all, if the server dies, you're in big trouble. Local disk booting is a really stupid idea and has had its day.

Another question that people ask us all the time is: 'How does Scalent repurpose servers?' We can easily explain this with an example that contrasts the old paradigm with Scalent's server repurposing. For example, what if you wanted to leverage your daytime mail server to run a grid at night? But what if the grid runs on a different OS (Windows, Linux, Solaris) than what the server runs during the day? In the old paradigm, you'd have to manually swap out the disk card or put a new disk in to provision an image on the server. But the new grid server might also need to connect to a completely different network, which would require your data center administrator to make a connection to a SAN as well as a particular LUN on the SAN. As you can see, there are quite a few painful and time-consuming steps that you'd have to take to change the personality of the server.

Here's how Scalent's server repurposing capability works: (1) From a console (which could be a web services API, GUI, CLI, Java API, or a .NET API), you'd stop whatever the server was running during the day. (2) At a touch of a button, you'd change the server's personality from a mail server to a grid server. You're done. In five minutes or less, your newly provisioned grid server is ready for action. Think about how quick and simple life would be if you could do this! With Scalent software, you can do all of this as well as connect the server to a new network. (4) Just drag and drop a graphic representation of the 'cables' in Scalent's UI, and guess what, the server connects to a new network in your data center thousands of miles away. All the networking information is stored within the Scalent persona.

You might wonder 'Who else can do this?' The truth is, nobody else can take a running system, move it across the country, change its personality, and bring up the new image in a matter of minutes. Our software is up and running in Fortune 500 data centers today. We support your existing x86, SPARC, and PowerPC hardware running Windows, Linux, Solaris, and AIX as well as full VMware ESX and Xen hypervisors. What's unique about Scalent's technology is it can reconfigure networking as it moves personas geographically, and this applies to individual servers, or server pools, or your entire data center.

The old way of doing things entailed building brick walls and moats around under-utilized hardware resources. Some companies will also build brick walls, moats, and mines just to be sure. But virtualization technologies are taking the data center world by storm, and proving not only that this stuff works and can save you substantial amounts of money, but more importantly that it makes data centers adaptable. This adaptability means that you'll get higher utilization, more flexibility, and better responsiveness from your data center. As a result, your company will realize a competitive advantage over those that fail to make the transition. Got more questions? Come talk with us!

Alana Achterkirchen, Director of Marketing, January 2008

Going Green Is Universal

2007-12-18T13:58:00.000-08:00

Our customers are amazing. Everywhere they look, they find different use cases for Scalent V/OE whether it's local high availability, disaster recovery, managing a virtual environment, or building a shared pool of test and development servers. Last week, we visited a company that is looking to improve their DR processes after having already installed hypervisor technologies in their data center. "We don't care what you do for Disaster Recovery, we have a very immediate use case to test with your product..." the customer said. It ends up that they want to go green in their data center operations by eliminating 1:1 redundant servers, eliminating manual server failover, and powering on servers only when they're utilized. Since Scalent V/OE has always taken a heterogeneous view of the data center, we have the ability to power on and off servers from any manufacturer, and found a very happy customer.

Going green can yield benefits to companies in any industry or geography because data centers are the biggest energy hogs in most businesses with their built-in redundancies and staggering amounts of equipment. Simultaneously, some ambitious companies are building environmentally-friendly buildings to house their green data center. If that's in your corporate culture and budget, then all the power to you. For the majority of us, there are smaller steps you can take to save on your power and cooling costs for your server farms.

Most importantly, you should know that Scalent is a member of PG&E's virtualization program in California, making customers who install Scalent V/OE software eligible for a rebate for virtualization and consolidation projects. Please go to the following website for more information on PG&E's application and acceptance process: http://www.pge.com/biz/rebates/hightech/htee_incentives.html .

Additionally, Scalent's power management capabilities enable data center managers to power on and off servers as appropriate which will in turn drive down your energy costs when any particular server isn't utilized for hours, days, weeks, or more. When necessary, you can bring servers back online quickly and automatically.

Then if you upgrade to energy-efficient servers from major hardware manufacturers, you'll also see savings in the amount of kW/rack consumed. Newer technologies are more energy efficient, such as HP's BladeSystem c-Class servers which offer thermal logic technologies to reduce power consumption and insight controls to lower maintenance costs. Go to http://h18004.www1.hp.com/products/blades/components/c-class-components.html for more information. HP also offers trade-in, donation, and recycling programs which provide a simple way to make purchasing newer technology more affordable, while ensuring that older equipment is reused or recycled in an environmentally-friendly way.

The Unisys ES3000 family of blades, entry, and midrange servers can deliver high availability and excellent serviceability with their completely tool-less and modular components. Go to http://www.unisys.com/products/enterprise__servers/midrange__servers/index.htm for more information on their products.

With Scalent, you can leverage our product for any use case. You'll benefit from the flexibility and power of our infrastructure virtualization product, while going green at the same time. Sounds interesting? Come talk with us.

Alana Achterkirchen, Director of Marketing
Mahesh Natarajan, Director of Pre-Sales & Field Engineering

December 2007

What Do HP, Unisys, and EMC See in a Palo Alto Virtualization Startup? (No, not that one...)

2007-11-27T10:10:00.000-08:00

There's a virtualization party going on in Palo Alto lately. It's tangible everywhere, but the reliable indicator that it's a raging party is how long it takes to park your car downtown. No, it's not the Stanford marching band playing tricks, nor is it the new VMware campus, or the XenSource gang over near 101 and Oregon Expressway (thought that's close). Those guys are all server virtualization. We're talking about Scalent Systems, and how we're changing the infrastructure virtualization world as we know it today.

Are you already an expert on the server virtualization market? How much do you know about infrastructure virtualization? We won't throw you a pop quiz this time, but if you're going through a hypervisor installation in your data center, or even considering it, you should read on. It's likely that there are many other CIOs in your industry who are thinking about how they can drive up return on assets and utilization on their existing infrastructure by leveraging Scalent V/OE software.

Our partners: Back to the original question. EMC, Unisys, and HP are all world-class technology product and services vendors that have partnered with Scalent Systems in OEM and resell relationships within the past quarter. These partners recognize that infrastructure virtualization will be valuable to their install base, where the ability to efficiently manage a heterogeneous data center environment translates into dollars saved. Scalent is honored to have partners who can help spread the word, resell our product, and deploy our software in massive data center installations around the world.

Our product: Scalent V/OE software enables data centers to react in real-time to changing business needs by dynamically changing what servers are running and how those servers are connected to network and storage. [more here... it's about the connectivity!] We support existing x86, SPARC, and PowerPC hardware running Windows, Linux, Solaris, and AIX servers, as well as full VMware ESX and Xen hypervisors. We can take one or more physical computers, turn them on & off, and set their network topology. Our product is complementary to VMware and Xen, which allow lots of virtual machines to run simultaneously on one physical computer; Scalent manages physical and virtual machines and connectivity to network and storage of all stripes and colors.

Focus & Execution: In 2007, we've been all over the country engaging customers, building partnerships, and winning awards for our product:

InfoWorld 2007 Technology of the Year award
Scalent Systems named 2007 Virtualization Platform Technology of the Year

AlwaysOn 100 Winner
Scalent Systems named 2007 AlwaysOn 100 Top Company winner

LinuxWorld Product Excellence Awards
Scalent Systems named LinuxWorld Winner, Best Virtualization Solution

Red Herring 100 North America Award
Scalent Systems named Red Herring Top 100 Company

Network World Top 10 Companies to Watch
Scalent Systems named NetworkWorld Top 10 Virtualization Company

TechForum Best Practice Awards
Scalent Systems named TechForum Best Practice Award winner, Technology Innovation

So, join the party! We at Scalent have assembled a group of world-class partners who can help companies benefit from our infrastructure virtualization solution. We deliver is data center management, simplified and virtualized, via an open-standards-based software solution that runs on an x86 controller. You already have an invitation through your sales relationship with our partners.

Come talk with us!

Alana Achterkirchen, Director of Marketing, November 2007

We are not Virtualization. We are Virtualization.

2007-10-26T14:20:00.000-07:00

Leonard Nimoy, after years spent living in the shadow of his hit Star Trek alter ego, famously titled his first autobiography, I Am Not Spock. Fans were confused and angered by this apparent rejection of Nimoy's source of fame, even though Nimoy had merely hoped to explain the depth of his acting abilities above and beyond that single character.

After years of controversy, Nimoy ended up titling his second autobiography I Am Spock. Sometimes, it's better to accept the confusion to be part of the larger movement.

Here at Scalent Systems, we can relate to Leonard's situation.

Why? We've spent countless hours scrupulously avoiding the term "virtualization". Even though it's technically correct - virtualization refers to the separation of logical computing from the underlying physical resources - it was also confusing. What is virtualization anyway? Is Scalent a virtualization company?

Well . . . we surrender.

We admit it.

Scalent is, in fact, a provider of infrastructure virtualization software.

So why did we avoid the v-word for so long? Why did the graffiti "NON" appear in front of the v-word in our "LinuxWorld 2007 Best Virtualization Solution"?

We avoided the label for the same reason that Leonard Nimoy ran away from "Spock". We were afraid that if people looked at Scalent as a virtualization company, they would lump us together with VMware and XenSource and other companies that have perfected server virtualization.

Don't get us wrong. We have great admiration for these companies, and we work together with them as partners. In fact, some Scalent code ships in every VMware ESX server. But what we do is not what they do, and vice versa.

Again, Scalent's value-proposition is infrastructure virtualization.

What's the difference, you ask?

Well, hypervisors like VMware and Xen partition a physical machine. Installing the VMware or Xen hypervisor operating system on top of a bare metal server lets you run multiple "virtual machines" (servers) concurrently, in parallel.

Scalent's software, in contrast, enables data centers to transition between different configurations - or from dead bare metal to live connected servers - in five minutes or less, without physical intervention. Running Scalent off to the side of your data center lets you run different servers (OS + Apps; Windows, Linux, Solaris, AIX, or full VMware ESX or Xen) over time on the same machine, in serial (one from 9am-noon, the next from 12:05 to midnight, for example), adjusting the network and storage connectivity of the physical machine to match the server running at the time.

This isn't a radical concept. Donna Scott, an analyst at Gartner, recently gave a presentation in which she highlighted the difference between server virtualization and the rest of the virtualization space. While VMware and XenSource virtualize servers, many other companies perform valuable functions by virtualizing other aspects of the data center. 3Leaf virtualizes networks and reduce data center cabling. EMC is the leader in storage virtualization. Scalent's goal, and we think we're succeeding, is to tie these solutions together to enable customers to virtualize their entire data center.

Scalent dynamically deploys software to servers across the data center, as needed. And Scalent's ability to deploy Windows, Linux, and Solaris, as well as the VMware ESX and Xen virtualization platforms, enables companies to tie together their virtualization solutions under one umbrella. Similarly, Scalent helps companies dynamically connect their servers to virtualized storage and virtualized networks. Data center orchestration software, like OpsWare, informs companies as to what infrastructure to repurpose, and then Scalent provides the power to get the job done.

So again, we surrender. There's really no way to escape the virtualization label - it's what we do. Fortunately the world now realizes that virtualization is something that applies to more than just individual servers. Scalent's value proposition is that we enable companies to manage their entire infrastructure virtualization environment, from servers to network to storage, so that data centers can be faster, cheaper, and more reliable.

So if you're a big user of server virtualization (or tried it and couldn't use it on SPARC, or because of network or storage constraints), come chat. It's time. We are a virtualization company. We are Spock.

David Silver, Marketing Manager

5 minute recovery time objective for servers and data centers

2007-09-27T10:33:00.000-07:00

Recovering a failed server is hard. It's so difficult to recover a server that the industry practice is to over provision spare capacity such that when one or many servers fail there are backup servers available to pick up the slack while you spend the time required to re-rack, re-cable, restore, rebuild and ultimately recover failed devices before the customer notices. In the event of a server failure, complex layers of clustering, load-balancing, fail-over, virtualization, and data replication are at the ready to provide the perception that all is well, when at best you're running in a degraded mode, and at worst you're one server away from going off-line.

Recovering a failed datacenter is hard. It's so difficult to recover a data center that the industry practice is to pre-provision a replica of your "production" data center at a secondary site which is in an active or stand-by mode, available to pick up the slack while you spend the time required recover or replace your primary data center. In the event of a site failure, complex layers of clustering, load-balancing, fail-over, virtualization, and data replication are at the ready to provide the perception that all is well, when at best you're running in a degraded mode, and at worst you're one data center away from going off-line.

Servers do fail. Events do occur which require secondary site fail-over. The IT costs of keeping a business up and running are staggering both in terms of spend and in terms of efficiency of the deployed resources. A broad industry of availability solutions has evolved to compensate for the time and complexity associated with replacing a server - whether in the same location or from one site to another.

What would you change in the way you run your business if you could reliably and predictably replace a failed server along with its connection to network and storage in under 5 minutes (boot time)? What if you could replace an entire data center full of servers?

At a recent Disaster Recovery Journal trade show, we had the opportunity to speak with a wide array of industry experts who are tasked with the responsibility of keeping their business up and running when disaster strikes. Some leverage highly sophisticated IT strategies for always-on infrastructure, while others rebuild from backups when needed. Regardless of the different approaches, they are all closely looking at the managing the cost of delivering to their RTO (Recovery Time Objective.)

When you can replace a server along with its connection to network and storage in 5 minutes, you find that the requirement for high availability overlay solutions disappears for broad categories of applications. For the remaining applications, exposure while replacing a failed server from a high availability service is reduced to 5 minutes. Across the board, over-allocation of fail-over resources to service specific silos is eliminated, and replacement devices are pooled and available at a moment's notice.

Extending 5 minute server replacement to the needs of data center fail-over, some very interesting capabilities are created. For instance, servers added at one location can be automatically added in real time at a secondary location - keeping the two locations better in synch. Servers at the "DR" site may be turned off until needed, or re-deployed for more productive uses. One of our customers runs Dev/Test in their "fail-over" location with the ability to restore to a replica of their primary datacenter at the push of a button. Environments which previously included production, fail-over, development, test, and staging can condense down to two deployments - production and non-production (everything else.)

What would you change if you could reliably and predictably replace a failed server along with its connection to network and storage in under 5 minutes? What if you could replace an entire data center full of servers? How would this impact your business continuity planning?

If you're wondering how we do it, please request our rapid failover and data center efficiency case studies from www.scalent.com/failover. Or simply give us a call; it's a conversation we love to have.

Brian Korn, Director, Marketing, September 2007

Where were you when infrastructure management became "hot"?

2007-08-28T18:39:00.000-07:00

Imagine a future in which people ask the question, "Do you remember where you were when you realized that infrastructure management had become the hottest field in technology?"

Data center managers and IT staff have labored in obscurity for decades, safely tucked away in windowless server rooms, and finally we are getting our moment in the sun. VMware's IPO last week was the hottest tech offering since Google, HP recently acquired Opsware for $1.6 billion, and Citrix just purchased XenSource for $500 million. All of these deals were about improving the performance of the data center while putting IT managers in a position to adjust their infrastructure at a moment's notice.

So why has data center management become so hot? The answer is that a number of factors have begun to constrain the growth of traditional data centers, and IT managers are still grasping for solutions to overcome these challenges.

-- Power usage has skyrocketed, which is imposing significant costs, and, in some cases, restricting data center growth because companies lack the electrical infrastructure to bring more power into the data center. So companies will pay a premium for solutions that lower their power consumption while maintaining performance.

-- Environmental considerations are also important. Companies interested in reducing their carbon footprint are looking at the data center as a place to cut energy consumption. Noise in the data center is also an issues because of the safety and health concerns of IT operators.

-- Companies with data centers are focusing on the difficulty of rapid and reliable disaster recovery. Traditional backup-and-restore disaster recovery plans are insufficient for firms that rely on their data centers for mission-critical functions. These firms need to be confident that their IT systems will not suffer critical downtime in the event of a site failure - and they are looking for solutions that will help them meet this goal.

-- Data center management is becoming increasingly complex for companies that are unwilling to tie their data center to a specific vendor. Data centers that run multiple operating systems on multiple hardware platforms need third-party solutions to help them manage their infrastructure.

Scalent combats these problems by automating the process of server repurposing. This makes data centers easier to manage, improves the reliability of disaster recovery processes, raises IT utilization, and reduces power consumption. More and more companies are telling us that our ability to solve these problems is critical to their future growth.

So how are we at Scalent reacting to all the industry excitement? I like to think of my favorite Warren Buffett quote: "Get on the right train early." We got on the train early, and it looks increasingly like we got on the right one.

So if you're thinking about the same problems we're concerned with, why don't you give Scalent a call? Regardless of what the technological flavor of the day is, we're always looking for ways to make companies' data centers run more smoothly.

Does your data center drive revenue?

2007-07-27T13:33:00.000-07:00

Having worked in data center operations for most of the last decade, one of my chief frustrations has always been that companies tend to view operations as a cost center. The focus of most companies' data center operations efforts is on cutting costs while maintaining performance. Cost reduction is important -- a company that spends a dollar to cut three dollars in expenses is better off than a company that spends a dollar to make two dollars in revenue. But a myopic focus on the data center as a place to cut costs causes businesses to miss great opportunities to use their data center to drive revenue.

For example, a well-known medical company is using server repurposing software not only for cost-cutting on the disaster recovery and failover site, but also for revenue generation via development cycle acceleration. Using server repurposing software in their development and test lab deployment automation enables them to shorten their product lifecycle by 25%. The extra speed allows them to beat their competitors to the market and earn more revenue.

Does Time To Market really translate to revenue? Absolutely. At a recent conference out here in California, a panel of top level CIOs reiterated that TTM is one of their most important metrics. In fact, we could argue that in most business environments, success depends on being faster than competitors by weeks, or even days. Speeding up time to market through data center improvements can drive huge revenue for a company.

Companies that install Scalent to automate their development and test lab deployment often think in terms of the cost savings that Scalent offers them. With Scalent, they no longer have to manually reconfigure the data center and physically recable infrastructure. This reduces operational expense, which leads to profit.

But perhaps we should think more about revenue. The aforementioned medical company estimates that they will generate an extra $5 million dollars in revenue over the next three years by using Scalent software. So ask yourself -- how much is my IT group making for the company today -- then come chat with us. You won't regret it.

-- David Silver, Product Management

Considering the purchase of a $30mm Server?

2007-07-02T15:28:00.000-07:00

The need for the efficient use of data center resources was driven home to me recently by a comment from a colleague from Intel speaking at a local event: "The most expensive server you are going to buy is the one that causes you to build the next data center." The comment got the expected chuckles from the audience; followed by a moment of silence ...putting an exclamation point on everyone's own thought processes regarding their growing IT footprint.

During the event (which was focused on data center virtualization issues) I was presented with a number of survey results and speculation on where server virtualization has been and would be going in the next years. One data point was that 50% of the recent usage of server virtualization was deployed to address consolidation and gain efficiency in the data center. Seems obvious, given that server utilization rates have hovered in the ten percent range.

With growing power constraints and budget pressure, efficiency metrics are forefront in the mind of anyone working with large server counts. These metrics are gathered in terms of hardware, watts, and space consumed per transaction delivered. Increasing the utilization of any given component, such as leveraging virtualization to concurrently run multiple OS instances and workloads on a given server, has immediate positive results on that given server's workload processed.

For those companies that have already adopted server virtualization, the next frontier can be found outside the server, across the entire server infrastructure. Servers from a number of vendors, of various capabilities, both physical and virtual, are deployed without the ability to rebalance workload when needed. As demands change, this inability to rapidly re-provision data center assets, and the natural compensation through over-provisioning, results in the low server utilization rates viewed across the entire data center. The provisioning problem applies to virtualized hosts as well; after all, the virtualization solution runs on physical machines as an operating system, so you face the same challenges of deployment, networking, and storage as a physical machine running native Windows, Linux, or Solaris.

At Scalent, we've worked hard to address physical and virtual server efficiency through the implementation of adaptive infrastructure software. With Scalent, you can manage the ongoing allocation of resources and repurposing of servers across disparate virtual and physical machines without losing control over the environment. Our customers have gained agility, automated fail-over, achieved server consolidation, and reduced hardware counts while consolidating environments and dropping a datacenter along the way.

Perhaps the least expensive purchase you'll make this year is the one which eliminates the need for your most expensive server. Come talk to us.

-- Brian Korn, Director, Marketing, June 2007

Automate (re)provisioning for development and test

2007-05-31T12:27:00.000-07:00

This month included yet another trade show visit, the StarEast 2007 show. For those of you who I was not lucky enough to meet there, this show attracts and educates software testing professionals through speaker sessions while providing the opportunity to interact with contemporaries and vendors. It was our first time at this show, and the customer interaction was great.

As with many people whose job involves the use of technology, a lot of effort is being spent on context as opposed to core activities. As a primer, this model was outlined in Living on the Fault Line by Geoffrey Moore and adopted by a number of organizations. Simply put, core activities add real value, context is everything else. Context is important (perhaps even critical) to get right, it's just not what adds economic value to the organization.

Back to software testing. I heard over and over again confirmation from folks that they spend more time building up and tearing down their test/dev environments than they do running their actual tests. From my perspective, testing = core, infrastructure set-up = context. These organizations are allocating fewer resources to bottom-line value-add activities which differentiate them than they are to activities which simply must be done, but don't really drive value.

One way which test/dev has compensated is through the over-provisioning of resources (servers and such) which are wired up and left to idle waiting for the occasional test, but never re-deployed when not being used. Sure, this strategy leaves resources available when needed, but with the increased costs of hardware, software, power, space, and opportunity. This is essentially a shift from people cost to hardware associated costs, but not a shift from context to core value-add activities.

At Scalent we've taken a hard look at development and test internally. Our software builds are run multiple times throughout the day in an automated fashion, and incorporate the deployment of servers to support a given test along with the automated release of this hardware when no longer needed. One of our customers is leveraging Scalent to build out a shared multi-thousand server enterprise test lab for their organization, saving them $Millions.

Don't spend more time on context. Come chat with us.

-- Brian Korn, Director Marketing, May 2007

Unnecessary Idling: Trucks or Servers

2007-04-24T12:32:00.000-07:00

We spent time a week or two ago at the AFCOM Data Center World and met up with a number of industry contacts and customers. As with most any show, it's always good to get in front of the people who may need your product to get a first hand account of their unique challenges.

Data Center World attracts facilities people, folks who build, cable, rack, power, and cool the data center. It's very interesting the various approaches to power, racking, cabling, and cooling of the data center that were presented. Many of the people I spoke to were concerned with meeting the increased demands on the data center, especially those who constructed new facilities to meet the ever increasing demand for space, power, and cooling.

What surprised me, though, was consistent focus on increasing supply, as opposed to consideration of how they could become more efficient in their use of the assets they already have in their possession. eWeek this month covered a Google discussion on data center efficiency which stated that it costs $10-22 per watt to build a data center, and CNET coverage reminded us that the cost of power will outweigh the cost of the underlying server.

Let's see, $10-22 per watt to build a data center, $3000 to power a low end server over the next 4 years, yet the industry still averages 15% utilization rates on servers.

In California, The California Air Resources Board (CARB) passed a rule in 2005 limiting "unnecessary idling" of heavy-duty trucks to 5 minutes. With 15% server utilization averages still prevalent, is data center legislation far behind?

Coincidently, 5 minutes is about the time it takes for Scalent to repurpose a server.

The complexity and manual intervention previously associated with server repurposing have been resolved through software in various ways. For example, hypervisor solutions enable multiple virtual hosts to occupy a given piece of hardware, while collaboratively adaptive infrastructure software is available to repurpose hardware into service where and when needed.

Simply put, servers that are on should be busy; servers that are idle should be shut down until needed.

For us here at Scalent, it's second nature to consider a machine as a flexible resource. Scalent software can repurpose a server to physical machines, virtual machines or in between, enabling our customers to balance their environment, focus resources, and react faster when needed.

And, of course, end unnecessary idling.

So take 5 minutes. It's not a long time. And come chat.

-- Brian Korn, Director Marketing, April 2007

Dead Bare Metal, High Availability, and Being Clustered

2007-03-29T12:38:00.000-07:00

In the community of IT professionals, "being clustered" can take on whole new meaning when you're staring at failed server hardware (aka "dead bare metal") and wondering why you paid all that money for (and spent all that time configuring) clustering software, only to have it not save you from disaster.

We recently attended a disaster recovery trade show, and it became very clear to us that the industry is still fundamentally lacking a straightforward, reliable solution to "high availability" in the face of a hardware failure.

But let's start by defining high availability.

In every company, servers can be divided into three groups: clustered / mirrored, highly available, and important.

The "clustered / mirrored" servers are those who must present a single face to other servers / users (regardless of the number of actual machines doing processing) and who cannot suffer even a second of service interruption. Such servers include things like trade processors, or Automatic Teller Machine backend servers.

For such servers, clustering and mirroring software - software used to meld many physical instances of independent operating servers into a single functional unit, and replicate actions - makes sense. Clustering and mirroring software ensures that if there's the slightest hiccup in even the application (much less the OS or physical server) on any machine in the cluster, another machine will automatically "pick up" where the first left off.

Yet such software is exceptionally expensive and complex to correctly install and configure - and has significant limitations. For example, disaster recovery demands that there be at least one physical machine per clustered application stack. So clustering and mirroring would ideally be used only as absolutely necessary.

At the other end of the spectrum, the "important" servers are those who can suffer some downtime without significant adverse impact. For example, report generation servers can effectively be down without any repercussions as long as they're available when reports are needed (daily, weekly, monthly...?). Such servers can safely be backed up on tape, or associated with "cold standby" servers.

Yet 80% of company servers are in the midground: "highly available". These are the servers which don't need real-time coverage - they have store & forward approaches - but which must be recoverable to current state in five minutes or less. Such servers include Exchange or other email servers, ERP and CRM applications, file & print, and other daily operating servers.

For these servers, the goal is fast recovery - from dead bare metal to live, connected (to network and storage) servers in five minutes or less.

Yet too many companies still ignore these servers, judging them (correctly) to be too expensive to cluster. (See our prior month's blog on recovery time).

There is a better way. Scalent can take servers from dead bare metal to live connected servers, in five minutes or less, on disparate hardware. So there's less exposure and less cost, and yet high availability becomes a reality.

Come talk to us. Don't let yourself get clustered.

-- Kevin Epstein, VP Marketing, January 2007

It takes HOW long to recover?

2007-02-19T19:19:00.000-08:00

We recently commissioned the consulting firm of Brilliant Ideas, LLC to do a data center survey.

This survey, given to over 500 IT professionals of director-level or higher, was designed to examine prevailing attitudes towards virtualization, server failover, and management technologies in the enterprise data center.

We were shocked by some of the results - most specifically, by the results around Disaster Recovery and Server Failover.

According to our survey, 89% of these respondents (who include many of the world's leading organizations) test their DR recovery abilities only once a year... or less.

Almost 2/3 of the respondents stated that they were "minimally confident" that their systems would actually work as planned in the event of a real emergency.

70% said it would take at least four hours per server to restore operations. No-one said it was possible to restore operations in five minutes or less.

These numbers are completely unacceptable.

Would you knowingly work for (or do business with) an institution where your email could be down for half a day or more? Where you wouldn't be able to access your bank account, your medical records, your voicemail, for at least four hours at any point in time? Where the IT staff didn't test their restoration process, and was only minimally confident it would work?

Yet we are all living in that world.

And until recently, IT might (might) have had an excuse. "Software is hard to install and configure." "Hardware isn't easily procured, and it's often just different enough to make the software images incompatible." "Networking and storage connectivity is a nightmare to reconfigure." And so on.

But Scalent does away with those issues.

As we discuss in our recorded webinar, "From Dead Bare Metal to Live Networked Servers… in Five Minutes or Less", it is now possible to install software to create an adaptive infrastructure: an infrastructure which overcomes the traditional hardware, software, and connectivity limitations, so that any failed server and applications connected to any network linked to any storage can be brought back in the space of boot time.

We're not just talking about this concept - we're living it. (Or, as the phrase goes, "We're eating our own dogfood"). All of our corporate IT systems, from our Linux Apache webservers to our Microsoft Exchange email to our Sun Solaris SPARC test systems, are all running in an environment managed by the latest shipping version of Scalent V/OE.

So what are you waiting for? Give us a shout. We'll show you. Until then, I hope you're not in that "minimally confident" 67% (and if you are, good luck).

-- Kevin Epstein, VP Marketing, January 2007

2007-01-31T10:17:00.000-08:00

POWERLESS?

It's the latest craze that's sweeping the nation -- sitting in the dark, powerless.

From California, apparently trying to take the Sunshine State title away from Florida, where legislation was introduced to restrict homeowners from using anything except efficient fluorescent bulbs in their houses (really, no kidding), to federal subcommittees investigating practical restrictions on data center power utilization, the newest hot topic is how to use less electricity.

It's no small matter. Data center owners, long concerned about HVAC capacity, are now seeing situations where they are not only unable to climate-control their facilities -- but they also can't physically run enough power to the buildings to add more servers. Power bills have now outstripped other operational costs by orders of magnitude in some situations, wreaking havoc on operating budgets and incurring the ire of CFOs.

As always, the pressure is "do more with less".

This is yielding some odd behaviour, from the slightly misinformed to the downright odd.

On the slightly misinformed side, hypervisors (VMware, Xen, and Microsoft) are now being pushed beyond their rational limits.

Don't get me wrong, I am a huge fan of hypervisors -- and for data center owners who are still running full physical servers at 7-8% capacity, shame on you, why haven't you virtualized! Go, now, and save power by combining 5 of those servers into 5 virtual machines running on one physical server.

That said, there are the folks in those situations who try to run 20 virtual machines on one box. If one pauses and does the math, it's immediately evident that to make that work, the physical box has to be a larger, higher CPU, more power-hungry machine. So claiming 20-to-1 consolidation is misleading -- they're actually only reaching about a 4-to-1 power savings ratio... and significantly raising their risk of disaster if the physical machine fails (unless they're running two in tandem, at which point the power savings is cut by half!).

Add to this the downright desperate approaches, such as water-cooled machines. Shades of the 1980's and giant Cray systems with fishtank bubblers! Maybe it's me, but the idea of deliberately introducing water into a data center seems, well, odd. I know these systems can be very successful, but at the same time, well, I've also seen what happens when one (one) breaks.

So my question is whether we're overlooking the obvious: why not simply turn off machines that aren't being used, and turn them back on as needed?

While it may be somewhat heretical, consider that this is the premise that powers many a hybrid automobile now cruising our nation's highways: when they aren't moving, the engine (gas and electric) turns off.

Most server-class machines are equipped with lights-out power management modules -- and those that aren't are being plugged into IP power strips.

So why not turn them off and on?

At Scalent, we manage power state as well as server stack, network connectivity, and storage access. Several of our clients use Scalent to conserve power by turning off machines until they're needed (server failover, web site or email surge), then turning them on and "cabling" them in real-time to meet shifting demand and needs.

They're saving money, they didn't need to modify existing infrastructure... and it seems a lot safer than water, eh? In addition, our California customers can take advantage of our status as a certified vendor, eligible for PG&E's virtualization program rebate -- making Scalent virtually (sorry) free.

Give us a shout. We'll show you. Until then, don't forget to turn off the lights on your way out.

-- Kevin Epstein, VP Marketing, January 2007

2006-12-25T14:35:00.000-08:00

Smart computer data center Disaster Recovery planners are now thinking about the third generation of Disaster Recovery challenges: 100% remote, automated recovery.

They know that the future isn't about first-generation problems, like lightening strikes and floods. Those are old news to data center planners. From macroscopic approaches like redundant data centers in different states, to more micro precautions such as redundant power supplies and onsite power conditioning, planners are ready for the classic "act of God" scenarios. Through rain and hail and dark of night, computer systems will keep running, and no-one will notice a thing.

Planners are also well past second-generation problems, like terrorist attacks, sudden system outages, and man-made disasters. Again, backup copies of critical data and systems are made more frequently, and there are processes rivaling those of the White House as to which administrators will take over in the event that primary administrators are incapacitated. (Most even designate an "Al Haig").

But many planners are just now beginning to come to grips with the third generation of disaster; namely, the world of sudden loss of staff and change in business. At the risk of focusing too closely on one potential cause, let's call this the Pandemic world.

In the Pandemic world, the first part of the disaster happens obviously, if slowly. Staff starts to decrease. Whether it's people actually out sick, or commute-challenged due to increased health regulations, or simply afraid, there will be significantly fewer IT staff available on site to make changes to the computing data center. This adds risk to a bad situation, making the plans, infrastructure, and processes in place to deal with a first-generation or second-generation disaster possibly untenable.

Yet the staff issue is only the first part of the problem. The second part of the problem occurs when the business needs to alter its infrastructure to address the shifting worker demographic. With so many staff out or working remotely, the load on email, remote access systems like Citrix, and security / validation systems increases dramatically.

Ideally, the company would rebuild or reconfigure its computer data center to serve this mostly outsourced workforce, vs the previously in-house 9-5 workforce. But that goal runs straight into the challenges of the staff issue, making the situation exponentially harder.

Planners see the paradox. The business will need more onsite staff to reconfigure systems to make up for the lack of onsite staff... and we have a third generation "slow" disaster, where a company unravels in days or weeks instead of hours (but just as inexorably and fatally).

The solution, of course, is to plan; to start early, building an "adaptive" or rapidly reconfigurable data center, so that machines can be rapidly repurposed to meet business needs, in a remote and semi-automated way, as desired. (This has the added benefit of increasing efficiency and ability to respond to first and second generation disasters more effectively during normal operations as well).

So don't delay. Think and investigate the relevant technologies (such as "Virtualization", "Server Repurposing" and "Data Center Automation") now, while you can - for he (or she) who hesitates is lost, dragged into the death spiral of the "slow" disaster.

-- Kevin Epstein, VP Marketing, December 2006

Efficiencies and Emergencies

2006-11-21T14:50:00.000-08:00

I couldn't help but chuckle at a colleague's description of data center life lately.

In his words, "It's all about efficiencies and emergencies - finding efficiencies, and avoiding emergencies."

While the comment was said partially in jest, I think he's spot on.

No matter how hard we all work in IT, the truth is that at the end of the day, brilliant architecture and vision doesn't influence perceptions of your success as much as does cost savings (in people, power, machines - numerically measured efficiencies) and email staying up 24x7 (perceptually measured reliability - avoided emergencies).

So how do we obtain the desired FE&AE (finding efficiencies and avoiding emergencies)?

The first challenge, efficiencies, seems straightforward - it's about IT Consolidation. Reduce your hardware, reduce your HVAC and power needs, reduce your base staff so that you have less overhead, and try to automate to make up for the differences.

The second challenge, emergencies, unfortunately tends to work against the first challenge. Reduce your hardware - but what about backup servers? Consolidate operations - but what about failover, reliability, and the need for staff on call?

If your IT center is critical to your business, this seems like a paradox - until you can automate and virtualize sufficiently to mask hardware differences and make your data centers sufficiently flexible and autonomous to meet both challenges.

At Scalent, we believe we've achieved this goal. We've built software that enables rapid server infrastructure repurposing - so that you can in fact achieve FE&AE at the same time. In the spirit of the season and the feasts that accompany it, I'd say we can let you have your cake and eat it too. Happy Thanksgiving, and come talk to us when you're ready to make your data center more efficient (and take a real holiday vacation).

-- Kevin Epstein, VP Marketing, November 2006

Meet Your $2k, $70k, and $30mm Servers

2006-10-23T14:53:00.000-07:00

I'm amazed that when I chat with other IT professionals, I still hear people saying "...but after all, servers are cheap, I can get a 1u box for about $2-5k or less..."

Wrong.

Servers aren't cheap. Hardware is available at $2-5k or less... for equipment that you wouldn't necessarily want to put into your home office, much less your data center. (Really, you can buy cars for $1k too, but you wouldn't drive 'em anywhere where you needed reliability and durability.) So realistically, data center hardware with redundant power supplies and robust components is more expensive.

But let's call the hardware a gimme. Fine, it's $2k.

Let's talk about the other costs. Heating and cooling management. Rack space. Software licenses for all those standby servers. Administration (yes, Virginia, you have to patch your standby servers too). Power, power, and power.

You get the idea. According to Brad Day, a senior analyst and VP at Forrester research group, it costs about $70,000 per server for those "incidentals" over the (three to four year) life of the server.

So now your $2k server is a $70k server.

But wait, there's more...

A colleague was recently talking about building a (small) new data center. It was going to cost him $30mm. Why was he building it? He was out of space in his existing facility. So he was facing the $30mm server -- the one incremental machine that put him over the edge.

So we've moved from a $2k server, to a $70k server, to a $30mm server.

Suddenly, technologies that enable more efficient asset utilization and flexibility start looking very attractive.

At Scalent, we've built software that enables rapid server infrastructure repurposing -- so that your fixed investment in $2k hardware and $70k per machine isn't stuck running one server (or hypervisor) even at low utilization... and you shouldn't encounter the $30mm server any time soon.

-- Kevin Epstein, VP Marketing, October 2006

SOA without SOI = SOL

2006-09-26T13:43:00.000-07:00

There's been a lot of discussion over the past 12-24 months about Service Oriented Architecture (SOA).

SOA is one of those really great ideas that doesn't take into account the laws of physics. Much like AOL deciding in the late 1990's that it'd open up modem banks (promptly flooding their network), SOA creates a host of challenges for the underlying physical infrastructure, which in turn demands SOI - a Services Oriented Infrastructure.

Why is this so? To understand the challenge created, it's necessary to first consider the way SOA works.

With SOA, various business services publish their interfaces, which can then be arbitrarily used by other services. So, for example, if I have a server running a transaction processing app, I can send transactions "at" that server (from various other servers in my network) and assume that I'll get my transactions processes / get a confirmation message.

But since there's no hard link established between SOA elements - at any time, anyone in the network can start using that published transaction server - predicting load on the published SOA elements is almost an NP-complex problem. At any time, load on any element may be large or small. You may need one, small server running your transaction processor... or you may need fifty quad-cpu machines with a load balancer in front.

My contention, therefore, is that you need an SOI to complement your SOA - a way of creating and scaling up (or down) new server systems (or entire multi-tier application deployments) in near real-time, to match the needs of your SOA.

So in an ideal world, as SOA needs rose, your SOI would be turning on new servers, creating load-balancers and SOA server elements, linking in the appropriate LANs and storage networks, and scaling the system.

This vision - SOI - is what Scalent provides.

And what happens if you have an SOA without SOI, you may ask?

Well, in that case, you're just SOL*.

*("So Out-of Luck"... or something like that).

-- Kevin Epstein, VP Marketing, September 2006

Maslow in the Datacenter

2006-08-21T11:41:00.000-07:00

Maslow created a model for human needs. There is a strict hierarchy: our physiological needs must be met first, and then our needs for security, social acceptance and self-esteem. It is only after all these needs are met can we hope to reach the pinnacle of human achievement - self actualization. The state of becoming all you can become!

Transformation appears to be the key goal these days for datacenters. Every IT department is in the midst of some change, driven by compelling business and operational needs. Some of these are modest, like standardizing on one vendor for all their x86 server needs, while others are grandiose, like building an adaptive enterprise.

But before taking the leap, no matter how modest or how grandiose, IT managers should take a page out of Maslow's model for human needs. It seems that there is a hierarchy of needs for enterprise data centers as well. Implementing a single vendor strategy for x86 servers sounds like a basic need, while building an adaptive enterprise sure sounds like the datacenter equivalent of self-actualization! Can the datacenter become all it can become without satisfying the hierarchy of its needs?

Here's a useful model for datacenter hierarchy of needs. At the basic level is consolidation, followed by virtualization, standardization, automation and finally leading to a self-managed infrastructure.

The idea of consolidation is simple - reduced footprint. This applies to physical datacenter (fewer the better), equipment form factor (racked servers to blades), software (from multiple OSs and application platforms to a single one), vendors (from the hundreds to tens). By simply reducing footprint, the optics for datacenter operations improves tremendously.

Virtualization, whether at the processor, server, operating system, or application, is next. It aims to make the most of the resources available. By keeping the resources abstracted away from the actual hardware, manipulating them becomes easier. Consequently, resources can be allocated as needs, re-allocated when the needs shift. In other words, the utility of resources is maximized.

Life would be a lot simpler, if the datacenter infrastructure were made up of homogenous components. You need to learn how to manage one thing, and apply across the entire datacenter! But alas, that is not the case and never will be. The alternative is the next level in the IT hierarchy of needs - standardization. Standardization leads to simplicity. But, standardization at the infrastructure level does not come easy. Someone has to take on the challenge of providing the right abstraction or data model for the entire spectrum of infrastructure elements - server, storage, network and software.

Once standardization is in place, automation becomes so much easier. You could even go the extent of saying that without standardization, automation is like the dog chasing its own tail! It never ends, because change is the constant in any datacenter. With a standardized abstraction of the infrastructure, this vicious cycle can be broken.

It is only after a datacenter has gone though the steps of consolidation, virtualization, standardization and automation, can it even begin to think about building an adaptive or autonomic, self-managing, self-healing infrastructure. That is the pinnacle of datacenter achievement, and skipping steps in between is not the way to get there, just as human beings can never really become their best when they are still fighting for survival.

Maslow in the datacenter. Who would have thought? We at Scalent did. And each step we take in developing innovative technologies for datacenter management, is a step that moves the datacenter closer to self-actualization.

-- Chandy Nilakantan, CTO, August 2006

Covirtualize! With and Beyond Virtual Machines

2006-07-05T16:43:00.000-07:00

Having been indoctrinated in the ways of Virtual Machines by VMware, where I spent the last four years plus (from 2002 to 2006), I feel like I'm committing heresy when I say that VMs aren't the sole answer to Data Center ills.

Don't get me wrong. I like VMware, and I'm a huge believer in the power of Virtual Machines. I think that for development it's hard to beat the utility of having full multi-tier systems, virtually networked together, inside a single physical machine -- and it's super-convenient to have packaged VMs to trade to other folks for easy replication of scenarios.

But there are two challenges faced by all hypervisor vendors, that won't be solved any time soon: performance and networking (LAN and Storage). (No, VMware VI3 doesn't even touch, much less solve these issues). I joined Scalent because I love startups with bright ideas that meet a real need -- and Scalent is one of those.

The performance challenge is straightforward, and therefore not worth much discussion.

Hypervisors take up CPU cycles, are a potential point of failure (if the hypervisor fails, the whole set of VMs are lost), and due to the "round-robin" nature of their scheduling, can actually mask race conditions in tests. Honest hypervisor vendors will always admit this point quite openly -- in fact, I’m proud that during my tenure, VMware quite openly stated "don’t virtualize applications above a certain threshold CPU, network or disk I/O level".

The point? To test and run many multi-tier production applications, such as Citrix, SQL Server, SAP, etc, you want to run on bare metal. This unfortunately raises the challenge of movement between physical and virtual (P2V & V2P), as well as raising the second challenge, networking.

Networking is a more subtle challenge, because it's out-of-box. Hypervisors control in-box -- the moment data leaves the physical machine, bound out to another physical box via NIC to LAN or to storage via HBA to SAN (or NIC to NAS), it has left the hypervisor's control.

What does this mean, or matter? Well, envision your nice multi-tier application -- Webservers, App servers, databases -- built in VMs and "cabled" inside single physical machine "A".

Works great.

Now, take one of those VMs, and put it on a different physical machine "B" (running a hypervisor) that's somewhere else.

Unless that physical machine is on the same LAN subnet, with the same SAN access, you've just broken your data center. The server (VM) you just moved is reaching out to LAN and SAN paths that don't physically exist any more, because machine "B" doesn't have them.

Not to mention that little part about machine B already having to be running a hypervisor... (and if you can't get to machine B to turn it on and install that hypervisor, such as in a DR case, then what?). Don't say "oh gosh, that will all be fixed by virtual HBAs and NPIV", either -- NPIV requires a full data-center rollout, supported across all hardware (!)(got legacy switches, anyone?), and virtual HBAs make a bad problem worse... now you have even more bound HBAs. (Heaven forfend that you're allowed to change virtual HBAs like virtual MACs, that'd create an even worse problem, as without locking, people would duplicate HBAs and kill off entire SANs by accident...)

But what's the solution? Ideally you'd be able to do a few things:
* Move easily between physical and virtual
* Move what was running on your physical machines around as easily as what was running on your virtual machines. So you could remote-start machine B, above. (For bonus points, remote-start hypervisors like ESX Server or Xen, too)
* Take the network topology, LAN and SAN, with you. So no more SAN configuration adjustments, or opening all SAN LUNs to all machines (sheesh!)

Scalent lets you do those three things. That's why my colleagues in the virtualization space are impressed -- it's a technically tough thing to do, but our team seems to have gotten it right. Also, the technology has all sorts of interesting business uses (got standby DR machines? Use 'em for QA, rolling topologies on and off in minutes, then use for DR as needed!). But don't take my word for it -- try it for yourself. Give us a call, and take care of the rest of your datacenter. Covirtualize!

-- Kevin Epstein, VP Marketing, July 2006

Unshackling Servers

2006-06-09T11:49:00.000-07:00

There's a big pendulum swinging out there in IT land. It drives IT architecture - and constantly forces us to examine and re-examine the wisdom of our decisions. Some people say pendulums are driven by gravity, my experience is that hype also does a good job of driving pendulums.

Some of the IT pendulum swings of the last 20-30 years:
+ IBM Mainframes --> Mini computers
+ Mini computers --> Client / Server
+ Client / Server --> Unix Mainframe
+ Unix Mainframe --> Multi-tier / web based applications

Each one of these swings is driven by excitement around a technology that can cut costs by an order of magnitude. Unfortunately, what typically happens is that a few years later some of the veneer peels off and the dark underbelly of each pendulum swing shows itself. Dark underbellies usually take the form of complexity of operations and high Total Cost of Ownership (TCO).

We are at the apex of the current pendulum swing. Over the last 5 years more and more of IT has shifted to scale-out multi-tier applications running on small individual x86 or SPARC "pizza boxes". The promise was cheap computing for the masses. The reality has been server counts in the 1000's and an infrastructure that's impossible to manage and growth that's out of control.

Applications today are deployed in static configurations. Each tier is provisioned with a number of servers - usually the number needed to meet peak demand. Because peaks occur infrequently, the average utilization of most corporate application servers is under 10% - yet the idle resources cannot be used for anything else - they are shackled by their static configuration.

Customers I meet with tell me that for every production server, they buy 4 additional ones: 1 for development, 1 for testing, 1 for staging, and 1 for Disaster Recovery. This means that for a 20 server application they end up buying, racking, and cabling a total of 100 servers. The additional "overhead servers" are utilized in a very sporadic manner. Most of the time they are sitting idle.

The way to tackle these issues is to slow down server growth, or sprawl. They key is to stop provisioning each application silo for peak usage, and be able to rapidly shift available resources from one silo to another. For example, if you have 20 servers dedicated to QA for application A, you should be able to repurpose them to do QA for application B or C when they are idle. Similarly if you have servers standing idle in the event disaster strikes, wouldn't it be simple to use them to do performance testing on applications when there is no disaster going on?

The key is to create a system where servers can be repurposed on-the-fly. To do this, you have to "unshackle" the servers from their 3 main shackles:
1. Software image installed on them
2. Place in the LAN topology
3. Access to storage

Unshackling these 3 key elements creates an environment where any server can perform any function on any network with any storage at any time. This is where the pendulum is headed. This is what Scalent was built to achieve.

-- Ben Linder, CEO, June 2006