Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0Activity
0 of .
Results for:
No results containing your search query
P. 1
Virtualizing Business-Critical Applications: Foundational Components

Virtualizing Business-Critical Applications: Foundational Components

Ratings: (0)|Views: 0 |Likes:
Proper configuration of virtual infrastructure environments is key to ensure availability and scalability of business-critical applications in the emerging world of software-defined data centers. We offer a game plan for working with iSCSI gateways and other elements in the virtual architecture to handle the abstraction layers and other crucial issues.
Proper configuration of virtual infrastructure environments is key to ensure availability and scalability of business-critical applications in the emerging world of software-defined data centers. We offer a game plan for working with iSCSI gateways and other elements in the virtual architecture to handle the abstraction layers and other crucial issues.

More info:

Published by: Cognizant Technology Solutions on Oct 13, 2013
Copyright:Traditional Copyright: All rights reserved

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
See more
See less

10/13/2013

 
Virtualizing Business-Critical Applications:Foundational Components
Separating “run-the-business” rom other business applications and thenidentiying the IT inrastructure necessary to ensure their high availabil-ity, scalability and perormance are a must or organizations that seek toreap the greatest operational benefts rom emerging virtual computingarchitectures.
Put another way, not succeeding at getting themost complex and compute-intensive workloadsto thrive in virtual infrastructure such that theyare as easily deployed as any other application isone of the greatest barriers to achieving the goalof the SDDC.
One Size Does Not Fit All
When most organizations rst deploy virtualinfrastructure environments, they do so with thegoal of reducing their data center footprint byconsolidating server workloads onto fewer hard-ware components. This results in immediate andtangible savings. Then, over time, they begin torealize that the average virtual infrastructureenvironment, when properly tuned and managed,will provide notably higher levels of availabilityfor those applications running on them. Whencombined with the initial cost savings achieved,organizations are often drawn to virtualize asmuch as they can.… And then they hit the wall.
Executive Summary
It should come as no surprise that the jour-ney to the software dened data center (SDDC)requires fundamental shifts in how applicationsare deployed and managed. To fully realize thevision of SDDC, organizations must rst embracethe fact that the journey includes not onlymoving 100% of their servers into the virtualworld, but also 100% of the storage and networkcomponents that support them.As a practical matter, this becomes a journeythat is far from easy. Getting all applicationsmigrated into a virtual infrastructure platformalone requires new skills and ways of managingcapacity. In addition, licensing issues require spe-cial attention as vendors also stay current withthe idea that compute workloads will no longerbe directly tied to physical hardware components.But most important to this journey is understand-ing and successfully migrating the most business-critical applications onto virtual infrastructuresuch that they not only function well, but thrive.cognizant 20-20 insights|august 2013
Cognizant 20-20 Insights
 
cognizant 20-20 insights
2
Virtualization andvirtual inrastructureenvironmentsdo add a layero abstraction oresources, and thisabstraction layerchanges the way inwhich applicationscan be run. Butthe way in whichvirtual inrastructureenvironments createthis abstractionlayer is exactly thesame regardlesso the applicationsrunning in thatenvironment.
The rst time a business-critical applicationrequires higher levels of availability — or fargreater compute resources — than is traditionallymade available on basic virtual infrastructure,problems quickly arise. At rst, the business-critical application runs slowly and can becomemuch more unstable. It is then moved back to itsoriginal physical infrastructure at least as quicklyas it was moved onto the virtual infrastructureenvironment in the rst place. Then the virtualenvironment is blamed.To be fair, the virtual infrastructure environmentactually is to blame when this happens. But that’susually due to a combination of the way thevirtual infrastructure environment was cong-ured and how the business-critical application wasthen deployed on top of it. Generally speaking, it’snot because virtual infrastructure platforms areill equipped to handle these applications.
What Makes an Application Business-Critical?
Of note, the qualities that make an applicationbusiness-critical often have little to do with thetechnology or platform said application uses. Inthe end, business-criticality is best determinedby answering a simple question: Can I run mybusiness without this application? From there, acorollary question emerges: How long can I runmy business without this application?If the answers to these questions are “no,” or “notfor very long,” then that application is critical tothe business.Nevertheless, most business-critical applicationsshare key technological characteristics. Theyinclude:
High compute loads – either with heavy thread-ing or heavy math processing.
High RAM utilization.
High and specialized I/O – particularly storage.
High availability congurations – often requir-ing OS or application clustering.
Complex networking congurations – public andprivate networks, often to support clustering.Applications with any of these qualities will needextra care and attention to conguration andresource management in order to virtualize themsuccessfully. Moreover, the majority of applica-tions that do fall into the business-critical cate-gory have more than one of these qualities in play.Because every application has something uniqueabout the way it runs in any given environment,it’s easy to quickly reach a conclusion that everyapplication will then have its own set of best prac-tices that need to be explicitly dened to makethat application thrive in a virtual infrastructureenvironment. In reality, this is not actually thecase. The fact is that virtu-alization and virtual infra-structure environments doadd a layer of abstraction ofresources, and this abstrac-tion layer changes the wayin which applications canbe run. But the way inwhich virtual infrastruc-ture environments createthis abstraction layer isexactly the same regard-less of the applications run-ning in that environment.Thus, there exists a set ofcommon practices thatmust be accounted for thatwill enable every business-critical application to runsuccessfully on virtualinfrastructure. What’s actu-ally different is the way inwhich these common ele-ments are expressed. Thisexpression is indeed asunique as any application.Virtualization software vendor VMware identi-es the following six key applications that areconsidered business-critical:
Oracle – and Oracle RAC.
Microsoft SQL Server.
Microsoft Exchange.
Microsoft SharePoint.
SAP.
Custom Java on Linux.Most organizations run at least one of these sixapplications; all exhibit a subset of at least someof the characteristics listed above. Again, whilethey are not the only business-critical applicationsin use at most organizations, the independentresearch commissioned by VMware shows theyare the most common ones. In addition, a secondand less often found set of applications exist thatbusinesses will often identify as business-critical.Again, these applications also share qualities thatcan make virtualization more difcult.
 
cognizant 20-20 insights
3
As the Star Trekcharacter Mr. Scott or “Scotty” — onceput it, “The morecomplicated theplumbing, the easierit is to stop up thedrain.”
These “honorable mention” business-critical apps:
DB2.
WebSphere.
WebLogic.
Hadoop/HBase.
Cassandra.
Tomcat.
Message queue systems such as Tibco, RabbitMQ, MQ Series, etc.
Custom, in-house built and maintained “home-grown” applications.Again, each of these applications will havespecic, individual ways in which they shouldbe tuned to thrive on a virtual infrastructureplatform. This is no different than how theyare optimized when running on bare metalhardware. But compute resources themselvesare very consistent. Therefore, if an organiza-tion properly accounts for how an applicationwill make use of its compute resources, commonthemes begin to emerge.
The Four Food Groups o Computing
When planning a virtual infrastructure envi-ronment, architects are taught to consider thefollowing four types of compute resources,which are sometimes referred to as the “fourfood groups” of computing:
CPU.
RAM.
Disk – including both disk space and disk I/O.
Network – including number of connectionsand bandwidth.All applications (not just business-critical ones)consume different quantities of these computeresources at any given point in time depend-ing on the tasks at hand. The difference is thatmost business-critical applications will consumedisproportionate amounts of one or more ofthese resources compared with other applica-tions. They also will have requirements for higherlevels of redundancy, availability and recoverabil-ity compared with other applications. Remember,we answered “no” and “not for very long” to thequestions about if, and for how long, we could runthe business without these applications.The following set of general guidelines will helporganizations assemble applications that thriveon virtual infrastructure:
 
AlwaysollowtheKISSprinciple:
As the
Star Trek 
character Mr. Scott – or “Scotty” – onceput it, “The more complicated the plumbing,the easier it is to stop up the drain.” There iselegance in simplicity of design. But more thanthat, simple designs aregenerally more stable,more scalable and easierto maintain. Business-critical applications arealready inherently morecomplex, so addingcomplexity when virtu-alizing them only makesthings worse. Examplesof mistakes in this areainclude:»Needlessly adding disks and spreadingthem across multiple data stores. Justbecause your physical server splits out aseparate drive letter for each class of data,logs, etc., isn’t necessarily a reason to dothe same in a virtual world. More than onedisk — and even more than one data store— is often necessary, but take an eyes-open approach that stresses less ratherthan more.»Splitting out base les that are part ofa virtual machine’s (VM’s) core compo-nents, including vswap and others, is not aneffective way of increasing efciency, per-formance or storage management. Sadly,it is a good way of introducing complexity,loss of function and loss of portability intoyour environment.»Duplicating features for high availabilityor redundancy through external or home-grown tools that are already present inthe base systems or architecture. Thisoften leads to managing or implementingabstracted features that don’t actually dowhat they are intended to. They also maketroubleshooting more difcult.
 
Architecthardwareroma“totalperor-mance”perspective:
Your virtual environ-ment should always be optimized from bottomto top – not top to bottom or from the middleout. High school and college students seemto be the most willing to put $6,000 stereosinto $3,000 cars. This doesn’t work nearlyas well with high-compute, business-critical

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->