Home > Intel Communities > Open Port IT Community > The Server Room > Blog > Authors > Raghu Yeluri

The Server Room Blog

3 Posts authored by: Raghu Yeluri
0

Whether it is public clouds, or private clouds, or internal clouds, or,…, One thing is very clear. Simple migration of current applications to cloud doesn’t work effectively. So, the question is what would be considered a good ‘application architecture’ for the cloud?  It may not be one, but there are some key design principles.   Before we look at those, let us look at the characteristics of cloud. These drive the application architecture for clouds, for the most part.

Any cloud operating environment (COE) would have the following minimal set of attributes.
  1. Multi-tenancy and shared infrastructure – more applications, users, transactions / compute host
  2. Elasticity & horizontal Scalability – Resource scaling up or down, depending on demand and usage. This helps capacity and demand planning.
  3. Pay as you go – Don’t need to procure entire capacity or pay for worst case demand planning… Pay by subscription or based on usage
  4. Automation and flexible management - Self service, flexible and dynamic assignment of workloads to optimal resource utilization

 

There may be multiple architectural approaches to leverage and “play well” in these COEs. Irrespective of the approach, the key design principles would be :
  1. Be a good tenant on a shared infrastructure – Applications have to be cognizant that they live in a shared environment. Ex: finer granularity (locks, etc.) optimized use of resources, proper authentication & isolation.
  2. Built for scalability – This is probably the hardest for application developers. It cannot be done in isolation. Applications would have to talk with infrastructure (COE) and vice versa, to be elastic. For the infrastructure to provide the elasticity, applications have to provide hooks for monitoring utilization by the infrastructure, and the management and administration of these applications.  This has far reaching implications. When you decide to use “Google Apps” or Microsoft Azure, you would be locked into a set of patterns for accessing data, code for scaling, etc.
  3. Parallelism - this might be obvious, but also one of the hard ones for application developers.  Most applications have constraints with either serial execution, single points of contention like session/application state, memory, file and dataset locks.. All these hamper parallelism.
  4. Configurability v/s Coding : The good apps on Cloud would be highly configurable… a lot of the behavior (including function and workflow) is driven by meta-data. Optimization based on “Locality” and Semantics are two other key concepts that should be configurable v/s hard-wired in applications.
  5. HW independence/Abstraction – so apps can run on the ‘best’ and optimal hardware from performance, scale and TCO perspective. Virtualization is a great model. This could be the basis for simpler federation between different cloud environments.
  6. Distributed and Composite architectures – Capabilities exposed as services. An app is a composition of bunch of services/apps (not objects and libraries like we are used to) that in turn adhere to the same set of design principles.

 

So, how do enterprises leverage the power of the Cloud?  Enterprises don’t have the luxury of re-writing all their applications to play well in the cloud. And, not all existing applications are architected with the above mentioned design principles.   Does this mean only new “green field” developments are well suited for the “Cloud”?  If enterprises have deployed SOA and the web2.0 architectures , do they have a head start with the cloud migration?  Are there other design principles that you see?

         

What do you think?

 

0 Comments Permalink
2

Virtualization 1.0 is yesterday’s news; the days of virtualization being used only as a tactical tool to drive consolidation and higher system utilization are quickly ending. For the most part, companies have figured out how to get improved utilization, and are using server virtualization in a wide range of usage models across development, testing and some rather interesting production/mission-critical scenarios.   Its use is gradually maturing from simple partitioning and encapsulation to leveraging the mobility of virtual machines to improve management and operations of IT environments. This is allowing the change in deployment models for virtualization from typical scale-up approach (SMP with large Memory servers) to a scale-out model.

Virtualization 2.0 includes a host of new use cases (shouldn’t be surprising to anyone) that include:

·         Load-balancing for SLA Mgt

·         Power-optimization

·         High availability (no downtimes)

·         Disaster recovery and business continuity

·         Hosted clients

·         SOA & Utility computing.

I see three key foundational tenets as the underpinnings for these usages.  First are the “abstraction” and the “convergence” of compute servers, storage and networks. It has been happening, but virtualization 2.0++ is driving (and will continue to drive) a seismic rethink in how Data centers are architected, and the data center would be a “Fungible” pool of infrastructural resources, for a wide variety of services that IT provides to run the businesses.   I will get deep into the implications of this to IT operations, etc, in a follow on blog, but will leave you with this thought.  The new control point in the data center, both architecturally and operationally, would be the integration of compute, storage and network virtualization architectures.  Key industry players like IBM, HP, Cisco, EMC, VMWare and Microsoft are introducing integrated solution architectures targeted at positioning themselves as the first vendor of choice for this emerging direction.  This foundational tenet, coupled with the merits of Service-Oriented Architectures (SOA), is providing an infrastructure for ‘Cloud Computing’.

The Second core tenet is the mobility of Virtual machines - The migrate-ability of the ‘encapsulated’ Virtual machines on this abstracted infrastructure for the best performance, operational cost and SLA management.  They are no longer tied to a server or a set of servers. In some cases they are not tied to a datacenter; hybrid models are emerging where these VMs would execute in the ‘enterprise’ data center, or on external clouds – the optimal place for the best TCO, and SLA management  (Yes, yes, there are security, compliance, accounting, performance concerns… I agree)

The third core aspect is Manageability.  The abstraction and the mobility, coupled with IT’s job of ensuring security, reliability and compliance brings a totally new set of requirements for Manageability.   

If done right, the benefits of Virtualization 2.0 (and 2.0++) to IT shops would be in the form of reduced administrative costs, improve productivity even as demand goes, reduce energy and cooling costs, etc,   however, there are quite a few challenges with the adoption of Virtualization 2.0.  Let us briefly look at these.

 

Challenges with Virtualization 2.0

1.      There is a significant challenge in the management of large scale virtual infrastructures. There are no clear boundaries and responsibilities in terms network, storage and datacenter management teams.  The emphasis on monitoring and management in Virtualization 2.0 is shifting from virtual machine (VM) management to service management; i.e., knowing how a business service is performing and which components of the Data Center (network, server, VM, applications) are working properly and which are not. Hence, it's no longer sufficient to just monitor the uptime or resource usage levels of virtual machines and physical servers and conclude that the entire IT infrastructure is working right.   More granular monitoring and management of resources would be needed to provide precise QoS and SLA management.

2.      VM Mobility – The Mobility of Virtual machines puts requirements on the underlying server CPU architectures, and has challenges with networks and storage.  Such mobility occurs via either a cold migration - which simply copies the virtual machine and restarts a copy somewhere else. Or a live migration, which moves a live running virtual machine, while maintaining state.  There are clear cases where cold migration is sufficient, but the flexibility and agility that is inherent with the virtualization 2.0 use-models requires the ‘live migration’ of VMs. 

·         VM Mobility and the ‘Compatible CPU Architecture’ requirements: Successful migration relies on compatibility between the processors of the host servers within a cluster. For live migration to take place, the source and destination servers must be in the same cluster and must have processors that expose the same instruction set., In the past, it has not been possible to mix servers based on different processor generations, each of which support different instruction sets, within the same cluster without sacrificing the ability to live migrate VMs across hosts supporting different instruction sets. As a result, IT organizations have needed to create separate clusters for different server generations. This has limited our ability to provide an agile data center environment because it creates islands of compute capacity, resulting in data center fragmentation.  Intel’s VT FlexMigration assist, together with VMWare’s Enhanced VMotion, provide a solution. These products are designed to allow IT to maximize flexibility by creating a single pool of compute and memory resources using multiple generations of Intel processor-based servers within the same cluster.  This can reduce the number of pools, increase the efficiency and utilization of servers.

·         VM Mobility & networks: Today, when Virtual machines move on the virtual infrastructure, its network properties and policies are not retained.  Connection state, ACL, Port Security properties, ACL Redirect, Qos Marking, etc are lost as these VMs move across hosts.   Technologies like the VMWare distributed switch, and Cisco’s Nexus 1000v are specifically targeted to address the ‘Network and Security’ aspects of VM Mobility.

  1. Licensing in Virtual environments:  Licensing rules for applications, development tools, data management tools and operating systems often make a completely virtual environment more costly than the organization expects.   Most all ISVs are looking at ‘virtualization’ friendly licensing models, but they are far from being there.  Example:  With Oracle database servers, if you have a 16core server as your host, it doesn’t matter if you database VM uses 4 vCPUs, you would still need the license for 16 cores.  If you would “Live Migrate” the VM, you would need the license on each of the host… This gets prohibitively expensive and impractical.

  1. 10G Networks and Converged Fabrics: The Compute power on the servers has increased dramatically, and with the advent of 8 core processors, the bottleneck clearly moves out of the server, and on to the network and storage bandwidths and throughput.  Virtualization 2.0 will require the consolidation of network traffic and will also increase the need for more bandwidth to the server, both of which will be possible as enterprises make the move to converge and consolidate data, storage, and inter process traffic on 10GbE networks.  10GbE and the converged networks need new switches, access cards, and also a rethink of how applications view the network I/O.  

  1. Security and Isolation guarantees – The hosting of multiple ‘services’ on an abstracted virtualized infrastructure has very specific needs on Security and isolation, multi-tenancy isolation, compliance and audit requirements..  In addition to providing these on a server (for a given service), the infrastructure has to guarantee these across the infrastructure – doesn’t matter on which server (and where) the service and data reside/execute, they need to be secure and isolated. 

In conclusion, Virtualization 2.0 would have a dramatic impact on the architecture of the data center, and also IT architectures and operations.  IT shops will use virtualization for administrative cost reduction, better resource allocation, and more flexibility in a mobile world.   Coupled with Service Oriented Architectures,, the promise of true service-oriented/utility computing might be closer than it has ever been with Virtualization.

Would love to hear your thoughts and views on this..

2 Comments Permalink
2

Server virtualization is becoming widely accepted and vendors and customers are beginning to explore usage models beyond support for legacy applications and server consolidation. Virtual Server load-balancing, disaster recovery (server and data center), dynamic creation and migration of virtual machines, to name a few, are fast becoming widely prevalent.

 

 

 

 

One of the newest uses for server virtualization that is beginning to garner attention is application portability, packing and distribution, a concept that is becoming more concrete with the advent of virtual appliances. Like the computer/HW appliances like TiVos, firewalls, IPS/IDS and NetApp filers, virtual appliances come pre-configured with applications and just enough operating software needed to perform their tasks, and delivered to the customer as a virtual machine file(s) ready to run atop a hypervisor. Every component of the virtual appliance is pre-configured and optimized and tested by the ISV who has the deepest understanding of the application, thereby eliminating interoperability issues and resulting in a better end user experience. Unlike hardware appliances which typically need specific hardware, virtual appliances run on top of any x86 hardware that has a hypervisor.

 

 

 

 

 

Could this be beginning of ‘Virtual-Appliance oriented architectures'? Too early to call, but in a virtualization-enabled world, the promise of an easy application deployment, distribution and maintenance/support is surely enticing. Just like any new technology or application model, there are a lot of challenges that ISVs and customers have to overcome with virtual appliances. We will get into details of these in the next set of blogs, but here is a quick summary of some questions customers and ISVs have to comprehend as they innovate in this space. We will also look at what Intel's doing here with its broad Virtualization Technology (VT) initiative.

 

 

 

 

 

 

 

  • - Security - Do you consider Virtual appliances as black boxes from a security perspective? Would you trust the ISV with both the app and the OS testing? Would there be any back doors? Will ISVs offload testing to third parties?

 

 

  • - Heterogeneous hypervisor environments - How do you package the virtual appliances for deployment and distribution on multiple hypervisor environments? OVF is a clear direction here.

 

 

  • - Performance of virtual appliances - Are there issues with virtual appliances sizes as we deploy and distribute business applications in virtual appliances? How do you deal with dependent appliances? Would there versioning issues with virtual appliances? Will there be a need for multiple versions of virtual appliances executing side-by-side?

 

 

  • - Software licensing - How does software licensing work in a virtual appliance model? How do you buy Microsoft OS licenses? Ubuntu, RedHat, etc are releasing stripped down versions of Linux for Virtual appliances usage. How would the Open source model evolve?

 

 

 

What do you think? You buy into the Virtual Appliance model? Will it work for you? Have you done anything with it yet? Let us know.

 

 

2 Comments Permalink

Filter Blog

By author: By date: By tag: