Choosing the right hardware for SQL Server virtualization

SQL Server and virtualization are inherently a pair, and they become more and more coordinated. The coordination between them is not only workload management and consolidation, but also high availability. New technologies can provide multiprocessor capabilities for SQL Server on multiple hosts, keeping virtual machine instances in sync with each other, so that 0 waiting for failover occurs when one instance is down.

But to do all this, you need some hardware, and buying hardware for a virtual host running SQL Server is a little different from choosing hardware for the SQL Server itself. You must also plan your SQL Server instance. Busy instances of working with large databases may own the entire virtual machine, while smaller instances may require multiple instances to be deployed together in a single virtual machine.

Keep in mind that the virtual machine has become your basic snap-in: You can move a virtual machine to a different host, or failover, and so on, but each instance of the virtual machine goes with the virtual environment. We need to focus on creating a virtual machine environment that requires as few processors as possible to complete tasks, which will enable each virtual machine to handle their workloads at a smaller granularity, which makes it easier for those virtual machines to collaborate with other virtual machines on the same host.

When equipped with a host, there are three things to consider: disk throughput, memory, and processor. In the beginning, your money is best invested in the processor. Whether it's a blade server and a compact 1U server who does the mainframe for SQL Server: You'll plug in more processor slots and the kernel to the 4U chassis, which typically runs more than similar 1U and 2U racks require less refrigeration and power requirements.

Find the "most effective point" for processor speed, you can use the money you spend to get the best performance, not just pick the fastest. The extra bit of MHz doesn't make you a great performance improvement. Of course, be aware of server-level processors. If you're the kind of person who believes in the ability to build a server with a motherboard based on the Centrino technology, then you might as well discard that view when selecting a hosting host for SQL Server.

Memory is the next expense. The more memory, of course, the better. Many of today's management programs often support excessive memory use, which means you can configure your virtual machine to use more memory, which may add up to more than the actual memory of the host itself. Many environments still perform well when configured to allow 50% overuse, but SQL Server is also the real memory devourer. Analyze SQL Server instances to see how much memory they typically consume, and then plan your overuse values, and if the virtual machine is running instances of SQL Server, do not put the virtual machines on the same host, which is often easier to exceed than the maximum memory allocation.

One thing to keep in mind is that SQL Server tries to use all the memory that the operating system can provide, which is more powerful than other server applications, so if Windows thinks it has 12GB of memory, SQL Server typically uses it to the fullest extent. This mechanism will cause problems with the excessive use of memory settings, so be cautious in handling them. In fact, most experienced database administrators don't like to use excessive memory at all when they virtualize SQL Server.

This means that when you buy a server, the amount of memory can be deducted. You can add it later, even if you have enough memory modules installed on the server, you have to set aside slots for future expansion. Of course, do not cheap you buy the memory, to make full use of. To use error-correcting memory, and make it match the speed of the server board. In other words, whichever server vendor you choose to recommend to your server, it's best to purchase memory from the same vendor. After all, if your memory is out of the question, the provider is most likely to support you.

Disks are the last, and in most SQL Server environments, people typically build storage area networks (Sans) rather than rely heavily on the internal storage of the server. (You might create a mirrored group of internal hard disks to run SQL Server and Windows itself, but not to store data.) For prioritization, build your SAN for fault tolerance, speed, and capacity; If you think you need a 10TB san, capacity is the last factor to consider.

First, make sure you can afford enough storage redundancy so that you don't lose data on a small number of disk failures, and you must establish fast enough I/O access to support SQL Server operations. The most common bottleneck in SQL Server is storage speed, so it is almost impossible to build "too fast" sans. This is especially true in virtual environments because of the I/O overhead when data is written to a virtual disk mirror.

Although SQL Server has the perfect ability to run on a virtual machine, it requires a certain amount of expertise to buy hardware for a SQL Server virtual host and configure a virtual machine. Simply migrating your existing instance of SQL Server to an improperly configured virtual machine or a poorly configured host can significantly degrade performance. We don't have to take this risk: as long as you keep these caveats in mind, you'll get the efficient virtual infrastructure that SQL Server needs to run.