Databases Reference
In-Depth Information
➤
Storage utilization
— This is an area often overlooked when designing virtual environ-
ments, yet it's an easy area to capture data about. The regular logical disk counters from
within Performance Monitor will help you size your host server requirements when you
know the average and peak period IOPS and MB/s demands of your current server in order
to deliver satisfactory query times. If available, also ensure that you capture the same data
from your storage subsystem. Both sets of data should show the same trends even if they
show slightly different values, and will be useful in your planning.
➤
Network utilization
— In the same way storage utilization is often overlooked, so is network
utilization. The most useful Performance Monitor counter you capture here is the Mb/s
throughput of the server's Network Interface Cards during peak periods, perhaps during
a ETL process, backup window, or busy business period.
Consideration must also be given if the physical server currently has, or if the virtual server
will have, iSCSI storage presented to it. In these situations, the iSCSI trafi c is likely to be far
higher than any which SQL Server itself requires, and it needs to be accommodated.
Sizing Tools
Several tools are available for gathering the data you will need to understand the resourcing
requirements of your future virtual servers. The Microsoft Assessment and Planning (MAPS)
toolkit can scan a specii c server or an entire network to report on the software and hardware
resources currently being both deployed and utilized. It even has a built-in feature to specii cally
advise on physical-to-virtual (P2V) migrations. VMware has a similar tool called the Capacity
Planner that also analyzes a workload over a period of time and advises on the best P2V approach.
Other than these tools designed to aid P2V migrations, you may be currently using others that are
already storing the kind of information you need. SQL Server's Management Data Warehouse and
Utility Control Point features might be performing such roles in your environment.
Non-Performance Related Requirements
Having collected data about how hard your server may or may not need to work once it is virtualized,
you should also collect information about when your server needs to work hard and, more
important, be available.
For these requirements I suggest collecting the following information:
➤
Peak workload periods
— If your database server operates according to a structured and
planned routine, then knowing when you need your server to be able to work especially
hard is important. Being able to plan this in a calendar format will help you visualize all
your different server workloads and prevent potentially negative conl icting workloads on
the same host server.
➤
Availability requirements
— Currently, your existing server is likely deployed in a way that
ensures it meets the business availability standards required of it. For example, it might be
standalone or it might be clustered. Knowing what level of availability is expected of the
server once it's virtualized plays a large role in determining the virtualization technologies
you adopt.
Search WWH ::
Custom Search