Find White Papers
Home About Contact Help
Free Membership Member Login
Search the Library                  Advanced Search

HP PolyServe Software for Microsoft SQL Server: A Simple Approach to SQL Server Consolidation

HP
By : HP
INFORMATION
Published : Nov 27, 2007
Length : 29
Type : White Paper
 
Download Now
Save for Later
  Email This Page
Overview :

The success of SQL Server in recent years has produced a phenomenon of SQL Server sprawl—the uncoordinated deployment of tens, hundreds or even thousands of database servers. The result has been low levels of utilization, poor availability and, most importantly, an enormous management burden inflicted on many IT departments. There is an acute need for a way to deploy SQL Server that allows capacity to be matched appropriately to need, that provides high availability without introducing extra complexity and extra cost, and that actually simplifies the life of administrators.

This paper describes an approach that provides these benefits, which we call the HP PolyServe Software for Microsoft® SQL Server.

View All Items By This Company
Browse Related Categories :

Infrastructure

,

Migration

,

Network Management

,

Servers

,

Windows Server

 
SQL Server provides a high degree of functionality and performance at a low cost. It is widely supported by third-party packaged applications and by a broad range of development tools. It runs on industry-standard servers that have unmatched price performance. As a result, it is unsurprising that its use has grown as much as it has. However, the very attributes that have made it attractive have given rise to problematic patterns of growth.

- One database, one server: In many environments, administrators deploy a new server each time a database is required. When a packaged application is implemented that requires a database, a new machine is purchased and provisioned with SQL Server. When an in-house application is developed that requires a database, a new server is used. This one database/one server approach has the merit of simplicity, and the relatively low cost of SQL Server and the hardware on which it runs makes it feasible. However, as we discuss in the following section, the result is a great deal of complexity and ongoing operational expense. (In some cases, further servers are purchased to support development and test environments—one database, multiple servers!)

- Proliferation at the departmental level: Because SQL Server is relatively easy to buy and implement, it has often been purchased and deployed in an uncoordinated way at a departmental level, even in organizations that have well-organized central IT facilities. Over time, the number of servers dedicated to running SQL Server can grow to an astonishing degree, with correspondingly high ongoing costs.

- Inadequate provision of high availability: There are well-established ways to implement high availability for SQL Server databases, typically using failover clustering in active-passive server pairs. However, as we discuss in the following section, these approaches introduce significant extra cost and much complexity compared to non-clustered SQL Server. The result, in many cases, is that the threshold required to justify a highly available implementation has been quite high. Consequently, it is commonplace to find databases that in fact are important for continuing business operations but are unprotected by high availability. This is a further consequence of the relatively uncoordinated deployment of SQL Server.

Together, these creeping patterns have created what many IT managers are calling SQL sprawl: widespread, relatively uncoordinated and/or unplanned database deployments, typically in the form of many individual servers and a smaller number of active-passive server pairs clustered for high availability. Depending on the size of the organization, SQL sprawl may affect tens, or hundreds, or even thousands of servers. Regardless of the absolute numbers involved, SQL sprawl represents a waste of resources and an ongoing burden on the IT infrastructure. The next section teases out some of the costs imposed by SQL sprawl.
Low levels of utilization
The one database/one server approach to database deployment has, inevitably, produced appallingly low levels of utilization. In our experience working with customers, it is not uncommon to find most database servers running at 5–15% CPU utilization—particularly with modern server hardware. Of course, low levels of utilization imply higher-than-necessary capital costs, or, looking at it another way, low levels of utilization mean there is a large amount of stranded capacity in the environment that could be put to better use.
While low utilization levels arise in some cases because of the simplicity of deploying a new server for each database, other factors can be at work. In a typical environment, the penalty for under-provisioning a machine for SQL Server is high. This often causes a last-minute procurement of a larger and faster server as a replacement and a weekend or evening spent configuring the new machine, copying the database to it, and testing that it works properly. Figure 2 illustrates just how painful this can be. To avoid this, it is simpler to buy a large server up front, even though that inevitably produces large amounts of stranded capacity.

Search the Library                  Advanced Search
About Us Contact Us List Your Papers Partner With Us Site Map