Aucune remarque pour cette diapositive
Speaking Points:General introduction to explain what Business Critical Applications are and for the purpose of this deck they have been split into two main areas―Business Applications and Server Software as follows:Business Applications include:Enterprise Applications such as ERP, CRM, SCM and PLMLine of Business (LOB) Applications such as HR, Finance, and MarketingServer Software include:DatabaseCollaboration CommunicationAdditional Information―Industry Definitions:IDC Definition of Business Critical Applications: Business Critical Applications typically includes Enterprise Applications such as ERP, CRM, SCM, or Industry/Vertical Applications that require a highly secure platform with a high level of performance and continuitySource: IDC August 2007 Mission Critical North American Application Platform StudyGartner Definition of Business Critical Applications:“Gartner defines “mission-critical” applications as business applications, excluding email, that would bring your company to a stop if they were not running. Mission-critical applications are typically supported and managed by a central IT staff. Examples of such applications are airline reservation systems and order processing for a retail store chain. “
Scenariid’usage :Consolidation C’est le cas de la haute disponibilité pour les PMEs.Exchange se prêtebien à la consolidation, maissi le nombred’utilisateursdevienttrès important, la virtualisationn’apportequepeu de “consolidation” du fait du dimensionnementconséquent des Machines Virtuelles et donc à l’impossibilitéd’enexécuterplusieurssur un mêmehôte.Il estrecommandé de commencer par consoliderl’architecture Exchange en elle-même, puisensuite, d’envisager la virtualisation pour “pousser” la consolidation plus loin,Commencer alors par virtualiser les rôles “HUB” et “CAS” sous utilisés de votreorganisation Exchange,Il estaussi possible d’associer du fait de leurprofil de machine virtuelle et leurpositionnement en DMZ, le rôle “EDGE” et les serveurs ISAUnesecondeplateforme à moindrecoûtC’est le scénario “Site de secours “chaud” pour Plan de Reprise d’ActivitéC’estaussi le scénario de la Plateforme de Pré-Production
Lorsqu’onvirtualise des serveursapplicatifs, ilestnécessaire de biencomprendreleurprofil de consommation de ressourcesafin de dimensionnercorrectementl’hôte Hyper-V et de ne pas créer de gouletsd’étranglement des performances.
Le rôle UM utilise (entre autres) le protocole “Real Time Protocol” qui s’accommodeassez mal de la vue “temps relatif” de la machine virtuelle = tranchesdiscrète de temps machine de l’hôte.
Le rôle UM utilise (entre autres) le protocole “Real Time Protocol” qui s’accommodeassez mal de la vue “temps relatif” de la machine virtuelle = tranchesdiscrète de temps machine de l’hôte.
Speaking Notes:The aim of this slide is to explain some background information on what a SharePoint® Server farm is and the key components that make up the farm. It is important to understand this background of SharePoint Server farms before progressing with virtualization options for SharePoint.Why Virtualize?Traditional application architecture models focused on defining how many servers would be required to deploy a specific technology. Depending on availability and redundancy requirements, number of users, and other factors, occasionally, multiple servers would be required even if they were not heavily utilized. This is often the case for SharePoint products and technologies. Many deployment models provided for multiple redundant Web front-ends, dedicated index and/or application servers, “warm&quot; stand-by servers, and additional farms for test and development environments. This could quickly lead to a proliferation of SharePoint servers in an organization, many of which would go unutilized or underutilized for long periods of time. Virtualization provides for the ability to consolidate multiple virtual guests within a single physical server, sharing the physical resources across the virtual machines. For SharePoint administrators, virtualization also allows for the flexibility to quickly provision new farm members to handle specific functions or to provide for redundancy of a specific server role—a key design advantage over physical server models. Virtualizing the Web Front End (WFE) roleThe web role’s responsibility in a SharePoint farm is to respond to user requests for pages. This involves fetching content from the SharePoint databases and “look and feel” from the database and file system and then rendering, caching (depending on settings), and returning the page to the user. It is a good candidate for virtualization, as long as SharePoint architects take a few key factors into consideration:Do not put all your eggs in one basket! Do not host all your WFE’s on the same physical host. Split these virtual machines over a minimum of two physical host machines. This ensures hardware redundancy. If one physical host fails, the remaining web front end server can take over the load. Dedicate virtual network adaptors and virtual switch to internal and external MOSS farm communication. For example, ensure separate virtual network adaptors are provisioned to enable you to dedicate virtual network adapters to transport different types of traffic. Consider using hardware load balancing over software load balancing: Hardware load balancing offloads CPU and I/O pressure from the WFE’s to hardware layer thereby improving availability of resources to SharePoint. Examples of Hardware: F5 BIG IP, Citrix®Netscaler®, Cisco® Content Switch. Software load balancing examples are Windows Network load balancing, Round Robin load balancing with DNS. It&apos;s a trade-off between cost and performance.Why consider virtualizing your SharePoint farm?The following is a list of the main drivers we have experienced in existing customer environments: Data Center issues such as limited or no power and rack space available Saving your company money by reducing your infrastructure footprint and reducing the power and cooling costs required Green IT: reduce carbon footprint by reducing the power consumption of your organization The need for greater mobility, flexibility and manageability in your data centerSource: http://blogs.msdn.com/uksharepoint/archive/2009/02/26/virtualizing-sharepoint-series-introduction.aspxWhitepaper: Virtualization of Microsoft SharePoint Products and Technologies
Speaking Notes:The aim of this slide it to explain from a SharePoint® Server perspective what the best candidates for virtualization are. So, ideally when thinking about virtualization for SharePoint you would first consider virtualizing the Web and Application Roles and then the Query, Index and Database roles if the environment allows it. The following considerations and requirements give guidelines on when you should consider virtualizing the Query, Index, and Database roles – further details are outlined below.Virtualization of the SharePoint Web RoleThe Web Role is the most commonly virtualized role in a SharePoint farm, by nature of its smaller memory and disk requirements and by the ease in which a new web front-end can be added into an existing farm.The SharePoint Web Role, responsible for the rendering of content, is the most ideal virtualization candidate in a SharePoint farm. Each front-end has comparatively lower memory requirements, and there is a generally a lower amount of disk activity that occurs on web front-ends than on some of the other roles. Subsequently, many organizations are finding it highly useful to virtualize Web Role servers in farms of many sizes and configurations.Virtualization of the SharePoint Query RoleThe Query role, responsible for searches performed by users, is another possible candidate for virtualization, as long as SharePoint architects take a few key factors into consideration. First and foremost, each Query Server in a farm must have a propagated copy of the Index stored on a local drive. Depending on the amount of data that is being indexed, both within SharePoint and outside of SharePoint, the Index size can be quite large. Query PropagationIf the Query role resides on the same server as the Index Role, there cannot be any additional Query Servers in the farm as SharePoint will not propagate the Index. For virtualized environments, this can mean fewer disk requirements for the Index corpus.The Index Corpus can vary in size from 10% to 30% of the total size of the documents being indexed, so SharePoint architects will need to take this into account when designing a virtual server solution. For large indexes, it is generally recommended that each index server use a physical disk volume that is dedicated to the individual Query Server, rather than a virtual disk (VHD) file. Hyper-V™ fully supports this scenario, and it provides for faster disk performance than a VHD file. SharePoint architects often combine the web and the query role onto the same servers, and this model is supported in a virtualization environment as well, as long as the propagated index considerations listed above are taken into account. Because of the ease of provisioning new servers, and the ability to deploy multiple servers on a small number of physical hosts, many SharePoint architects find it advantageous to break off the query role from the web role and virtualize them as separate sessions. For example, a pair of Web/Query servers in a physical farm could instead become four separate servers, two web and two query. The key is that Hyper-V provides for this type of flexibility, and if the Query role performance suffers in the future, the SharePoint architect can always break the role off onto a separate server in the future if needed.Virtualization of Application RolesThe Application Roles of Excel® Services and Infopath® Forms services are sometimes installed on dedicated servers, depending on their usage. These roles are similar to the web server role in that they also can be easily virtualized in many environments. As the resource requirements of the individual application increase, additional servers to assist with that application can simply be added into the farm. Indeed, the flexibility of the virtualization model makes it easier for SharePoint architects to simply break out the application roles onto their own dedicated servers without having to invest in additional hardware.Index RoleThe Index Server role in a SharePoint® Server farm is often the most memory intensive role, making it a less ideal candidate for virtualization. This by no means rules it out as a candidate to be virtualized, it simply reduces the advantages that can be gained by virtualizing the server, as more of the host’s resources will need to be dedicated to the task.Crawling RecommendationIt can be advantageous to have the Index Server be the dedicated crawl server for a farm, as it eliminates the extra hop required to crawl content in a traditional scenario when other web servers are used. To do this, the web role must be added to the server and the farm must be configured to use a dedicated server.As with the Query role, the Index role requires enough drive space to store the index corpus. Depending on the size of documents being indexed, this could be a volume of significant size. If large enough and for performance reasons, it is often best to attach directly to a physical volume directly connected to the host server, rather than to a VHD virtual disk file. If the environment is small, is a test or development environment, or does not crawl significant amounts of content, then it is perfectly viable to use virtual disk files for the Index role.For very large production SharePoint farms, or for farms that are crawling a significant amount of content, the memory requirements and disk IO activity may prompt SharePoint architects to install the Index role on a physical server. SharePoint architects can start an environment with a physical server and then virtualize at a later time using Physical to Virtual (P2V) tools that are part of the System Center Virtual Machine Manager (VMM) product discussed later in this document.Source: http://blogs.msdn.com/uksharepoint/archive/2009/03/08/virtualizing-sharepoint-series-recommendations-for-each-server-role-in-the-virtualized-sharepoint-environment.aspx
Speaking Notes:This scenario looks at how you can use SharePoint® plus virtualization to achieve benefits in a non-production Development, Test and QA environment. Virtualization means you are able to place multiple SharePoint farms onto fewer physical servers. All roles can be virtualized and you can use Microsoft® System Center Virtual Machine Manager 2008 to create a library of templates to use for quick provisioning. It is also important to remember to isolate the development environment within the VLAN.Benefits virtualization can bring in this type of scenario include rapid provisioning and teardown of virtual machines. The ability to reduce hardware costs by increasing physical server utilization. Testing becomes much easier and more flexible with functions such as High Availability and you are also able to improve the software development and testing lifecycle.Virtualization of SharePoint Server Farms for QA and Test Environments Explained:One of the most common and widely used virtualization models for SharePoint is one where smaller test and development farms are virtualized. Since the resource requirements for these types of farms are typically quite low, quick and easy virtualization and provisioning of new farms is facilitated through the use of Hyper-V™ technologies. In these environments, typically all of the server roles, including the SQL Server® database role can be virtualized, as disk I/O and memory requirements are quite low. In certain cases, some organizations build test environments that exactly match the specifications of the production environment. For these environments, it may be the case that not all of the components are virtualized, depending on whether they are in production. In many cases, however, an approximate virtual sample infrastructure is created to roughly equate to what is currently in production. Additional Information:Multiple SharePoint Farms: Many SharePoint environments are installed not just on a single farm, but on multiple farms. Farms for QA, Test, and Development are one reason, but other reasons may include security isolation, content in different locations across a Wide Area Network, or for Disaster Recovery. Virtualization of many of these environments can greatly decrease the overhead required to run multiple farms.Virtual Memoryperformance is governed by performance of NUMA nodes, which are memory boundaries on the physical hosts that virtual sessions can be spread across. Virtual Memory is also affected by CPU and disk contention.Source: http://blogs.msdn.com/uksharepoint/archive/2009/03/08/virtualizing-sharepoint-series-recommendations-for-each-server-role-in-the-virtualized-sharepoint-environment.aspx
Speaking Notes:This scenario looks at SharePoint® Server virtualization in a virtual only production environment and the benefits that can be achieved. In this type of scenario virtualization can be used to provide a failover cluster with a passive node to meet SLA requirements. With multiple web front-end roles in place to handle requests, there is also a dedicated Index role to ensure optimal query search. There are two host servers with one failover server and all of the roles are virtualized.Benefits of virtualization in this scenario are the ability to reduce hardware costs by reducing the number of physical servers through consolidation, which in turn, saves on power and space. You are also able to achieve easier set up and provisioning.Additional Information: Virtualizing the database role The database role’s responsibility is to store, maintain, and return data to the other roles in the farm. This role has the highest amount of disk IO activity and can often have very high memory and processor requirements. Virtualization of SQL Server® 2005 and 2008 is supported. The requirements of your environment will determine whether you choose physical or virtual deployment options.If you decide to virtualize the database layer: Assess first using Microsoft Assessment and Planning Toolkit (www.microsoft.com/map)Implement SQL Aliases in your SharePoint farm Assign as much RAM as needed and as much CPU as possibleOffload the Disk I/O from the virtual machines and favor pass through or fixed size disks over dynamically expanding disks. Split SQL cluster over two physical hosts for minimum data layer availability (hardware redundancy and load distribution) Check the SQL CAT whitepaper on virtualizing SQL on Hyper-V™: http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docxVirtualizing the Query roleThe Query role’s responsibility is to respond to search requests from the web role and to maintain a propagated copy of the index stored on the Query servers local file system. It is a good candidate for virtualization, as long as SharePoint® architects take a few key factors into consideration:For best performance, use the fastest disk infrastructure possible: Choose dedicated physical volumes on underlying SAN infrastructure using the “pass through” disk feature of Hyper V™ or fixed disk VHDs on the LUN over dynamically expanding virtual hard disks. Performance of a fixed size VHD is practically on par with pass-through disks and has management and backup advantages. Don’t put your Query and Index server on the same underlying physical disk: Index server is heavy read write while Query server is constantly updating its own copy of the index. Therefore contention to underlying disk will slow read I/O for your Query servers in your MOSS Farm. Combine or split the Web/Query role: SharePoint architects often combine web and query roles. In virtualized environments this can be a good practice, but it largely depends on your environment and performance requirements. Virtualization environments provide the flexibility to split combined web/query roles onto separate machines. SQL Clustering – Do not virtualize the passive node of a SQL cluster: It defeats the reason you clustered in the first place, which is high availability of your databases. Either virtualize the entire database layer or keep all physical! Virtualizing the passive node of the active-passive SQL Server cluster is not recommended. Why? Typically you lose about 15-25% percent in performance using virtualized database hardware and over time portal usage will grow resulting in greater database load requirements. Eventually your physical host will get squeezed by the other virtual slices until the point when the virtual passive node may not handle physical node’s load. Source:http://blogs.msdn.com/uksharepoint/archive/2009/03/08/virtualizing-sharepoint-series-recommendations-for-each-server-role-in-the-virtualized-sharepoint-environment.aspx
Speaking Notes:This scenario focuses on looking at using a mix of both physical and virtual roles and is best suited to high-end production models. Index and Database roles are kept on dedicatedphysical servers, whilst Web, Query and Application roles are all virtualized. In this scenario all servers are managed by Microsoft® System Center.The benefits virtualization brings in this type of scenario include unified management (the ability to manage both physical and virtual from one central point) and the ability to scale dynamically with on-demand provisioning by using the dynamic data center.Additional Information: The difference between a physical and virtual resourceThere are some subtle differences between the virtual and physical resource. Why does this matter? Each server role in the virtual SharePoint® Server farm behave differently using virtual resources compared to physical resources. CPU:Physical CPU performance is governed by the number of processors and cores, processor efficiency, power draw, and heat output. Virtual CPU performance is governed by physical CPU and bus contention.Memory:Physical Memoryperformance is governed by memory available on the server and the page/ swap file, which is disk bound.Virtual Memoryperformance is governed by performance of NUMA nodes, which are memory boundaries on the physical hosts that virtual sessions can be spread across. Virtual Memory is also affected by CPU and disk contention. Disk:Physical Disk performance (Disk I/O) is governed by type of physical disk (E.g. SAN), the speed of the disk (E.g. 15000 RPM, the RAID configuration and the type of controller (E.g. SCSI). Virtual Disk performance consists of virtual fixed size disks, dynamically expanding disks, and pass through disks. Virtual Disk performance is affected by the physical network (if you use an external storage solution, such as SAN), CPU performance, and underlying physical disk contention. Network:Physical Network (NIC) performance is governed by number and speed of Ethernet adaptors and switches, and network bandwidth available in your environment. Virtual Network performance is governed by physical NIC,your CPU, I/O, and the bandwidth available, regardless of using emulated or synthetic network drivers. Source: http://blogs.msdn.com/uksharepoint/archive/2009/03/04/topic-1-recommendations-for-optimizing-the-performance-of-a-virtualized-sharepoint-environment.aspx
Speaker Notes:This slide is designed to explain the performance benefits that can be achieved with SharePoint Server® when enabled by Microsoft Hyper-V™. Details about the study:a. All users were run against a Microsoft heavy user profile―that is 60 requests per hour.b. “0% think time” was applied to all tests. “0% think time” is the elimination of typical user decision time when browsing, searching, or modifyingin Office SharePoint Server. For example, a single complete user request is completed from start to finish without user pause, therefore,creating a continuous workload on the system.c. The maximum user capacity is derived from the following formula:# = seconds per hour / RPH / Concurrency% * RPSExample: 3600 / 60 / 1% * 54 = 324,000Example: 3600 / 60 / 10% * 54 = 32,400 (supported user capacity for 10% concurrency)The CLARiiON CX3-40c was not stressed during maximum user testing: SP utilization did not exceed 35% and LUN utilization was within acceptable parameters.Additional Information:This reference architecture depicts a validated virtualized Microsoft® Office SharePoint Server® 2007 farm that is enabled by SQL Server® and Hyper-V™ technology. The solution utilizes EMC® CLARiiON® CX3-40c array for storage and consolidation of the content data types.Sizing and configuring an Office SharePoint Server 2007 farm can be a complex activity as many requirements and aspects must be considered during the planning phase.Time and attention should be invested to fully gather the current and future requirements of a customer’s Office SharePoint Server 2007 farm. How a customer intends to utilize the infrastructure, coupled with the nature of the customer&apos;s business, will dictate where resources should be spent to eliminate future possible bottlenecks in the environment.Windows Server® 2008 Hyper-V technology and Microsoft® System Center Virtual Machine Manager on EMC CLARiiON CX3-40c provide a very valuable proposition in offering greater flexibility by evenly spreading the load and optimizing the utilization of the physical hardware.The solution also provides the following benefits:Illustrates real-world expectations for realistic CLARiiON storage requirements and provisioning for a typical Office SharePoint Server 2007 enterprise farmIllustrates how to design and scale an Office SharePoint Server 2007 farm to support a large number of usersReduces the amount of physical servers: maintaining the same cumulative number of CPU cores and memory ensures similar performance levels. In addition, the solution promotes a more eco-friendly environment through the use of virtualization technology.Enhances the ability to correctly size and sell a storage and Hyper-V solution based on a given Office SharePoint Server 2007 farm configurationReduces configuration timelines by documenting key design considerationsEMC can help accelerate assessment, design, implementation, and management while lowering the implementation risks and cost of creating a virtualized Office SharePoint Server 2007 farm.To learn more about this SharePoint solution, contact an EMC representative or visit the Solutions section of EMC Powerlink (http://powerlink.emc.com).Source: EMC Virtual Architecture for Microsoft Office SharePoint Server 2007 Enabled by Hyper-V (whitepaper)http://www.emc.com/collateral/hardware/technical-documentation/h5926-virtual-architecture-ms-sharepoint-clariion-cx3-40-hyper-v-ref-arch.pdf
Speaking Notes:When contemplating virtualization for SharePoint® Server there are a number of considerations to take into account―here is a list of best practices and recommendations:Recommendations for configuring SharePoint and optimizing Hyper-V™Tests conducted at the Enterprise Engineering Center (EEC) indicated that the following optimizations were of importance for deployment of SharePoint in a Hyper-V environment:CPU:Optimize host CPU use. If you use multiple Hyper-V images on the same host, conduct tests to ensure that the physical processors are used efficiently. Depending on hardware and workloads, the ratio of virtual processors to physical processors can have a significant effect on the host CPU. For the SharePoint tests, the ratio of virtual processors to physical processors was 1:2. It is recommended that you use the Microsoft Assessment and Planning (MAP) toolkit (http://go.microsoft.com/fwlink/?LinkId=132840&clcid=0x409) to obtain an assessment of your computer&apos;s performance metrics. For more information about CPU topology, read Ben Armstrong&apos;s blog post, Processor topology inside of Hyper-V virtual machines (http://go.microsoft.com/fwlink/?LinkId=132839&clcid=0x409).Memory:Configure the correct amount of memory for Hyper-V guests:During testing, no change had a greater impact on performance than modifying the amount of RAM allocated to an individual Hyper-V image. Because memory configuration is hardware-specific, you need to test and optimize memory configuration for the hardware you use for Hyper-V.The initial goal of the testing was to make the Hyper-V image as similar as possible to the physical hardware image against which it was being compared. Based on that goal, the Hyper-V images were originally allocated 32 gigabytes (GB) of RAM, which was the same amount of RAM as was on the physical servers being tested. However, the initial test results showed that with that configuration, the Hyper-V images could sustain a load that was only about 70 percent of the load on the physical hardware. After investigating the Event Viewer on the Hyper-V host machine in the Windows Server® 2008 Custom Views, Server Roles, Hyper-V Events, it was discovered that the RAM for the Hyper-V images was being spread across multiple non-uniform memory access NUMA nodes. This information confirmed that performance declined when memory was allocated across nodes. After trying different configurations it was determined that for the hardware being used, 8 GB of RAM was the maximum that could be allocated to a Hyper-V image without crossing NUMA nodes.NUMA nodesIn most cases you can determine your NUMA node boundaries by dividing the amount of physical RAM by the number of logical processors (cores). It is recommended that you read the following articles:Hyper-V Performance Counters – Part five of many – &quot;Hyper-V VM Vid Numa Node&quot; (http://go.microsoft.com/fwlink/?LinkID=132805&clcid=0x409)Looking for that last ounce of performance? Then try affinitizing your virtual machines (VM) to a NUMA node (http://go.microsoft.com/fwlink/?LinkId=132829&clcid=0x409)Use Windows Server 2008 as the guest operating system:The guest operating system used on the Hyper-V images for the tests was Windows Server 2008. Windows Server 2008 is not only required to host Hyper-V; it also contains a series of enlightenments aimed at making it the best possible Hyper-V guest operating system. Enlightenments are enhancements to the operating system to help reduce the cost of certain operating system functions such as memory management. For more information about enlightenments, see Tony Voellm’s blog post, Hyper-V: Integration Components and Enlightenments (http://go.microsoft.com/fwlink/?LinkId=132837&clcid=0x409).Install and test integration components:The Hyper-V integration components were installed on all of the Hyper-V images used for testing. Integration Components (ICs) are sets of drivers and services that help your virtual machines (VMs) achieve a more consistent state and perform better by enabling the guest to use synthetic devices. Examples of ICs that come with Hyper-V are the VMBus (the transport for synthetic devices), time sync (used to keep VM clocks in sync with the root partition (also called the host), video driver, network driver, and storage driver. For tips that you can use to verify that the ICs are installed and working correctly, see Hyper-V: How to make sure you are getting the best performance when doing performance comparisons (http://go.microsoft.com/fwlink/?LinkId=132838&clcid=0x409).Install the Hyper-V update for Windows Server 2008 (KB950050) on the host and guests:This update to the Hyper-V role provides improvements to security, stability, performance, user experience, forward compatibility of configurations, and the programming model. Install this download on the Hyper-V hosts and the Hyper-V guests if the guest operating system is Windows Server 2008. Installing this update on the guest ensures that you can take full advantage of all available enlightenments. For more information, see Description of the update for the release version of the Hyper-V technology for Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=132841&clcid=0x409).Disk:Make the right disk choice. In a SharePoint implementation where the only roles on Hyper-V are front-end Web servers or Query servers, the disk performance is not as important as it would be if the image was hosting the Index role or a SQL Server® database. If the image hosts the Index role, using a fixed-size virtual hard disk (VHD) for the image delivers acceptable performance. A fixed-size virtual disk typical provides better performance than a dynamically-sized disk. For more information, see Hyper-V and VHD Performance - Dynamic vs. Fixed (http://go.microsoft.com/fwlink/?LinkId=132842&clcid=0x409).You can also choose to add one or more drives and connect to it by means of a virtual SCSI controller. The only real limitation here is that you cannot use the SCSI controller to connect to the drive that contains the guest operating system, which must be installed on a drive that uses an IDE controller. If disk speed is a high priority, consider adding physical drives to the host computer. To the Hyper-V guest system, you can add a virtual hard drive and map it to an unused physical drive on the host. This configuration, called a pass-through disk, is likely to give you the best overall disk throughput.Network:Use IPv4 as the network protocol for Hyper-V guests. During the tests, better performance was observed when IPv4 was used exclusively. IPv6 was disabled on each network card for both the Hyper-V host and its guest VMs.Do not use unnecessary host roles. Remove any unnecessary roles from the host server. For example, if your host is not serving Web pages, the Web server (IIS) role should not be installed.Source:http://blogs.msdn.com/uksharepoint/archive/2009/03/04/topic-1-recommendations-for-optimizing-the-performance-of-a-virtualized-sharepoint-environment.aspxhttp://www.microsoft.com/virtualization/solutions/business-critical-applications/default.mspx
Microsoft ITManaging 1800+ VMs on ~100 servers
Speaking Notes:Microsoft virtualization also provides seamless integration with a diverse and growing number of industry leading business critical applications; such as Enterprise applications like SAP® and Oracle®, Line of Business (LOB) Customer Applications and more than 30 of Microsoft&apos;s top applications (a full list of these applications can be found in the appendix of this deck)Additional Information: Microsoft Virtualization and SAPBusinesses are under pressure to ease management and reduce costs while retaining and enhancing competitive advantages, such as flexibility, reliability, scalability, and security. Microsoft provides a complete suite of technologies to help enable an interoperable, end-to-end, virtualized infrastructure that can help IT departments maximize ROI and save costs across the enterprise. By consolidating application services on less hardware and simultaneously increasing flexibility and availability, you can lower the TCO of SAP infrastructures.Windows Server® 2008 Hyper-V™ provides a low-cost, scalable and highly available platform for server consolidation of SAP solutions. Whether the solution comprises components of a SAP ERP system or middleware components such as SAP BW, SAP Enterprise Portal, SAP Process Infrastructure, SAP Master Data Management or SAP Mobile Infrastructure, the resource utilization of the SAP infrastructure’s physical servers can be optimized by moving the components into virtual environments. Microsoft solutions also improve availability, flexibility, and manageability of SAP applications in production, as well as test and development environments―with technologies such as clustering, Quick Migration and the end-to-end management capabilities of Microsoft® System Center products.