Let me start off by saying that this and upcoming
blog entries are not a sales pitch but rather my experiences (good
and/or bad) with a software solution that we selected to better manage
our Microsoft SQL Server
systems. We have just installed it over the past three days and I am
on the flight back home so we are starting to learn really learn the
application and what it can do for us. This first post will be about
our decision and why and a bit about the selected solution. Then, I
will have one or two posts about the installation and initial tests.
As well, I will do additional posts when I see a need or come across
something that would be beneficial knowing before purchasing (ah yes,
those infamous if I only knew THAT before, I wouldn't have done it that
way).
Polyserve
is a high availability solution for a variety of Linux and Windows
environments in either 32 bit or 64 bit versions. We are using ours
for the management of our growing SQL Server farm so we have installed
the Polyserve Matrix Server and the Polyserve Matrix SQL Server
applications. We had several different SQL environments for each of
our product lines and each one had its own unique failover and
management requirements. Since several of our business lines were
growing so rapidly and could see what senior management was planning
for future growth, we laid out a plan to control the SQL proliferation
for the entire company before it attacked us.
Our current environment is a series of active/passive clusters using Double-Take
for the mirroring and failover on one end of the spectrum to stand
alone SQL server with log shipping (using a manually built-in system
for log shipping and one using Red-Gate’s SQL Backup
software for failover on the other end of the spectrum. So about half
of the machines were really just sitting idle and basically collecting
dust and that was a serious chunk of money to waste in my opinion.
Also, we have been doubling our business activity every year for the
last four years and our current design was starting to reach the limits
of the current solutions we had in place. We knew we had to scale out
or up
To make matters worse, we never really fully
liked our failover system as the failback was rather painful and could
require some downtime--thankfully it rarely happened. Also, we are in
the midst of developing a new transaction processing system that we
believe would really tax our current structure and we are starting to
use SQL Server Reporting Services for all of our reporting needs
whereas previously the data was exported and MS Access was used for our
reports.
So we did a fair amount of research about high
available solutions for SQL Server from MSCS to Virtualization to
Partitioning to Replication to Mirroring. We talked with quite a few
vendors but in the end we thought Polyserve would best meets our needs
and goals. Our high level goals were pretty simple and are listed in
order of importance:
- provide scalability and extensibility for our rapid growth for the next several years,
- allow us to better utilize our existing hardware (i.e. not require us to have any or very few idle machines),
- reduce administration and associated costs.
- create a failover system that we could trust and help us meet our demanding SLA's,
- allow
us to move to 64 bit SQL Server 2005 on Windows 2003 for the bulk of
our system and SQL Server 2000 and Windows 2003 (both 32 bit) for about
4 systems and upgrade them easily at a later date.
So why did we choose Polyserve? Well, it was the
one solution that we felt met all of our listed goals. The price was
within our budget (sorry I will not tell what we paid, let’s just say
it isn’t cheap but should pay for itself in less than one year) and we
were able to secure the necessary funding.
With Polyserve it is very easy to move SQL Server
instances around from one server that is being over utilized to another
server that is not as busy. We were also able to consolidate several
servers with smaller volumes of transaction onto on server by stacking
instances so that each one still maintained it own environment and
configuration without affecting the others. Simply put, we were able
to better manage our load volume better. Instead of managing a single
server, we are managing resources or pools to provide better up-time
and responsiveness of the system overall.
All servers can see the same data via their
shared Cluster File System. This basically eliminates the need to
mirror the data and subsequently reduces network traffic. Data
integrity is also protected with their distributed lock manager. Since
the data is all shared, each node in the cluster can manage the other
nodes and since your SQL databases are all stored in one location on
your SAN. This makes your backups much easier to manage.
Their Matrix Volume Manager manages the LUNS from
our SAN (a SAN is a requirement for their solution and while they are
compatible with most, you should check their compatibility section on
their website). As such, it is simply a matter of creating additional
LUNS and publishing them to your network and the Matrix Volume Manager
can quickly add that additional space into the existing system and you
have just extended your disk space.
You are allowed up to 16 servers of various
processor sizes and OS configurations in a matrix. A matrix is a
grouping of servers that are all actively running SQL but have each
other as a failover. Therefore, unlike MSCS where all your hardware
needs to be exactly alike, you can mix and match servers to create your
matrix. So you can consolidate your existing systems into your
solution and rotate in newer machines more powerful machines as you
purchase them.
Their software allows us to bring a new server
online and easily install all the appropriate SQL instances on the
server. A new server can be added to the matrix in a very short amount
of time. The software also has features that all you to push SQL
Updates and Hotfixes to all your servers in one shot. For example, we
installed 10 instances of SQL Server in our matrix. If I had to do
that manually on each server, it would have taken more than a day.
However with their tools, it took about 10-15 minutes.
Ok, so know you know what we were looking for and
why we chose Polyserve. In my next post, I will start talking about
our experiences as we installed the solution and start using it.
As a side note, when we purchased the software,
Polyserve was an independent company. However, after about 1 month of
our signing the agreement, they were acquired by Hewlett Packard.