Cisco Blogs

Server Life cycle

- May 11, 2012 - 0 Comments

The terms “life cycle” conjure up an image of a biology class on butterflies for me.  The metamorphosis that a butterfly undergoes is very interesting. Every stage has a specific purpose:

In the data center, life cycle of servers is something we deal with all the time.  For analysis we could consider physical, virtual or software servers just like I did in a previous blog. I drew the life cycle of the 3 servers and the resulting diagram is below.  Interestingly a physical server is the only one that can be truly re-purposed, more like the stages in the life cycle of a butterfly.

We generally think of software as versatile and malleable, but an application server is written for a specific purpose and may change a little over time with patches and enhancements.  The life cycle of a software server starts with the development of the application and moves into a steady state production till it is finally retired.  The life of these applications could be years or decades long. A generic virtual machine (server) with a basic operating system can surely be used for any purpose, but is less useful than one that has the entire software stack built up for a specific workload.  Virtual machines with specific workloads could have long lives as well, but they are relatively new in production environments. The point however is that virtual machines will be usually requisitioned for a specific purpose and more likely never be re-purposed. The end of the virtual server life cycle occurs when the disk image is deleted.  Physical servers on the other hand may be completely re-purposed during their life cycle.  One day the server may be fastest server handling mission critical workload and after perhaps a year it is relegated to handling less important workloads and later used as a test machine for the production environment or application development. Eventually the server may be retired to make way for faster machines and recycled.

Although physical servers can theoretically be re-purposed often, IT departments tend not to do so, because of the cost and effort involved. Production servers must typically be placed in specific racks and on specific Local Area Networks (LANs). They may also need to be attached to a specific storage devices or storage area networks (SANs) in which case the cabling may have to be changed. All this takes time and administration effort.  I recall waiting for weeks just to get the IP addresses of servers and access to the VLANs to start performance testing of applications.  If manual tasks are involved, errors can occur and this can lead to loss of even more precious time.  Application capacity planners therefore size server needs based on peak load. Adding server capacity in a timely manner, as demand spikes, may not be feasible.  A physical server can also be re-purposed by running a completely different virtual machine with a different application on it. The constraints really depend on the workload. Can the workload (or application) run in a virtual machine?  Can the application access the data and storage resources needed to complete the tasks at hand?

An ideal physical server is one that is open and versatile enough to run physical and virtual workloads efficiently. This is where the Cisco UCS with management capabilities provided by the Cisco UCS Manager shines. Re-purposing of servers is a breeze with the notion and definition of Service Profiles.  These profiles extend the server identity all the way to LAN, SAN and thus data access. Cisco Unified Management goes beyond server re-purposing and takes into account the entire life cycle of servers, and provides workflow management functions to extract maximum value from server systems.

Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.