In the ongoing push toward server consolidation, lower costs and greater redundancy, many value-added resellers (VARs) are taking on Web server virtualization projects. If you're in the midst of such a project -- or want to be -- this tip lays out a path for successful implementation.
First, the advantages of such a deployment: Web servers can immediately benefit from server virtualization technology since it brings the ability to scale up or down hardware with little or no downtime. And, virtualized Web servers can be moved between physical hosts when maintenance is required. Beyond that, resources can be load-balanced across a pool of physical hosts at a level that is more efficient than simple Web traffic load balancing. With some careful planning and benchmarking, you can give your customers a flexible, highly available Web infrastructure.
If the resource needs are not carefully addressed in the implementation planning phase, you might end up with physical hardware that does not meet the needs of the virtualized environment. A mistake in a Web server virtualization project can be costly for the business and lead to a slow Web site or downtime. And you could be on the receiving end of political backlash from a customer who may not fully trust Web server virtualization technology if performance is lackluster.
Assessment phase
The first step in the implementation process of a virtualized Web server, as in any other client project, is to meet with the client; this meeting should determine what kind of environment the Web server will be operating in. Questions to be
asked: Will the Web server be public or an intranet server? What volume of load will be expected on the server -- small (up to 200,000 page views per month), medium (from 200,000 to 800,000 page views per month) or large (beyond 800,000 page views per month)? Will load balancers be used? Finally, will the Web sites served be static or dynamic?
The last question is an important one because there is a key difference between static and dynamic Web sites. Static (HTML-only) Web sites are the easiest to virtualize, since they usually rely on just one system: a Web server. Dynamic Web sites require a database server in addition to the Web server.
A Web server's performance is most impacted by the CPU and memory performance. A Web server produces less disk I/O than a database server. The CPU and memory are especially important if there is any server-side scripting taking place on the Web server. No matter whether you're setting up a database-driven Web site or a static one, you should assign as much CPU and memory as possible for large loads. If you are running VMware VI3 with a VMotion capable setup, you can use the company's unique VMware Dynamic Resource Scheduler (DRS). This feature will automatically load-balance resources among your pool of VMware ESX 3 servers. If the Web server will use load balancers, you should run the virtual Web servers on separate virtual server hardware, since it wouldn't make sense to load-balance the traffic onto one piece of hardware.
Dynamic approach
With a dynamic Web site, there are additional challenges for Web server virtualization: Database server performance is disk-bound, because there is a lot of disk I/O on a database server. With small or midsized loads, you may be able to virtualize the database server and the Web server. However, with large loads, you should use a separate physical machine for the database server while keeping the Web server as a virtual machine that connects to a database server over a high-speed network. This way, you can tune the storage for the database server for a database load instead of allocating generic storage for the Web server and the database server.
Security should, of course, be considered within the scope of the server virtualization project, and discussed with the client during the implementation planning process. If the virtual Web servers will be on the client's intranet, they will likely be subject to less stringent security requirements than if they were exposed to the external world. If the Web server will be public-facing, it will most likely be located in a DMZ (whereas the database server is typically within the internal LAN). To connect to the separate database server on a dynamic Web site, you could open ports on the internal LAN side of the DMZ. You could also segment the database server connection on a virtual LAN (VLAN) and connect to it.
If the virtual Web servers are on the same physical host machine as other applications, you should segment the Web servers into their own VLAN. This can be accomplished by assigning a dedicated physical network card on the host machine to the Web servers. This network card should be connected to the appropriate VLAN segment. In the case of VMware ESX Server, you can also create a new VLAN that is internal on the ESX server box. To do so, just segment the virtual switch into a VLAN.
Once these steps are completed, you're almost done with the Web server virtualization implementation, but you still need to test the performance of the Web site. You should perform two types of testing on the site: testing performance under different loads and testing Web server-specific performance. For the first type of test, VMware offers a virtual server performance benchmarking tool called VMmark, which can be used to test generic virtual server platform performance under many loads, including those from database servers and Web servers. (According to VMware, VMmark is platform-agnostic, so you should be able to use it to test virtual server platforms other than VMware.) For the second type of test, you can use a tool like Web Performance Load Tester, which sends requests from a workstation to the Web server based on definable parameters. Web Performance Inc., the maker of Web Performance Load Tester, published performance results of a virtual Web server running a Web application.
Harley Stagner is a veteran IT professional, with a wide range of knowledge in many areas of the IT field, including network design and administration, scripting and troubleshooting.
