I'm looking into Availability Groups to see if i can benefit from them, but I struggle to understand if I can or not.

Today, we are running a traditional failover cluster with around 150 databases. It is a collection of a lot of different stuff that is in a lot of cases hardly used, but we can't throw it away for a million different reasons. But prolonged downtime is unacceptable. The environment looks like this:

• No single database is business critical (but the amount of DBs makes it critical)
• Databases ranging from 10 MB to 10 GB
• Avg. 30.000 Logical read/s, under 1 Physical read/s
• Low CPU usage (below 20%)
• Two physical servers in two data centers
• Storage is on two VMAX 10k, one in each center, shared volumes distributed with VPLEX, so looing one center will not affect uptime on storage
• No need for reporting or anything out of the ordinary
• Most DBs are in simple mode, with a nightly full backup, business have no problem accepting the nightly backup as restore point
• A rare few databases are running full mode and has 30 min transaction backups

The reason this solution was chosen at the time was licensing and administration reasons. We wanted to cut back on all the single SQL Servers doing nothing but cost us money. And we have removed about 60 SQL Server installations from the environment.

But now there is talk about how we should deal with this in the future, hardware replacement coming up in a year.

And the problem is, as I stated before, I can't quite get my head around if we can benefit from a change, maybe running Availability Groups on virtual machines instead?

So my question is: What would you think is the best solution to look at given these factors?

EDIT I was a bit sloppy with terms here, Failover clustering VS Availabillity Groups of course.

I'm looking into Availability Groups to see if i can benefit from them, but I struggle to understand if I can or not.

Today, we are running a traditional failover cluster with around 150 databases. It is a collection of a lot of different stuff that is in a lot of cases hardly used, but we can't throw it away for a million different reasons. But prolonged downtime is unacceptable. The environment looks like this:

• No single database is business critical (but the amount of DBs makes it critical)
• Databases ranging from 10 MB to 10 GB
• Avg. 30.000 Logical read/s, under 1 Physical read/s
• Low CPU usage (below 20%)
• Two physical servers in two data centers
• Storage is on two VMAX 10k, one in each center, shared volumes distributed with VPLEX, so looing one center will not affect uptime on storage
• No need for reporting or anything out of the ordinary
• Most DBs are in simple mode, with a nightly full backup, business have no problem accepting the nightly backup as restore point
• A rare few databases are running full mode and has 30 min transaction backups

The reason this solution was chosen at the time was licensing and administration reasons. We wanted to cut back on all the single SQL Servers doing nothing but cost us money. And we have removed about 60 SQL Server installations from the environment.

But now there is talk about how we should deal with this in the future, hardware replacement coming up in a year.

And the problem is, as I stated before, I can't quite get my head around if we can benefit from a change, maybe running Availability Groups on virtual machines instead?

So my question is:

What would you think is the best solution to look at given these factors?

I'm looking into Availability Groups to see if i can benefit from them, but I struggle to understand if I can or not.

Today, we are running a traditional failover cluster with around 150 databases. It is a collection of a lot of different stuff that is in a lot of cases hardly used, but we can't throw it away for a million different reasons. But prolonged downtime is unacceptable. The environment looks like this:

• No single database is business critical (but the amount of DBs makes it critical)
• Databases ranging from 10 MB to 10 GB
• Avg. 30.000 Logical read/s, under 1 Physical read/s
• Low CPU usage (below 20%)
• Two physical servers in two data centers
• Storage is on two VMAX 10k, one in each center, shared volumes distributed with VPLEX, so looing one center will not affect uptime on storage
• No need for reporting or anything out of the ordinary
• Most DBs are in simple mode, with a nightly full backup, business have no problem accepting the nightly backup as restore point
• A rare few databases are running full mode and has 30 min transaction backups

The reason this solution was chosen at the time was licensing and administration reasons. We wanted to cut back on all the single SQL Servers doing nothing but cost us money. And we have removed about 60 SQL Server installations from the environment.

But now there is talk about how we should deal with this in the future, hardware replacement coming up in a year.

And the problem is, as I stated before, I can't quite get my head around if we can benefit from a change, maybe running Availability Groups on virtual machines instead?

So my question is: What would you think is the best solution to look at given these factors?

I'm looking into Availability Groups to see if i can benefit from them, but I struggle to understand if I can or not.

Today, we are running a traditional failover cluster with around 150 databases. It is a collection of a lot of different stuff that is in a lot of cases hardly used, but we can't throw it away for a million different reasons. But prolonged downtime is unacceptable. The environment looks like this:

• No single database is business critical (but the amount of DBs makes it critical)
• Databases ranging from 10 MB to 10 GB
• Avg. 30.000 Logical read/s, under 1 Physical read/s
• Low CPU usage (below 20%)
• Two physical servers in two data centers
• Storage is on two VMAX 10k, one in each center, shared volumes distributed with VPLEX, so looing one center will not affect uptime on storage
• No need for reporting or anything out of the ordinary
• Most DBs are in simple mode, with a nightly full backup, business have no problem accepting the nightly backup as restore point
• A rare few databases are running full mode and has 30 min transaction backups

The reason this solution was chosen at the time was licensing and administration reasons. We wanted to cut back on all the single SQL Servers doing nothing but cost us money. And we have removed about 60 SQL Server installations from the environment.

But now there is talk about how we should deal with this in the future, hardware replacement coming up in a year.

And the problem is, as I stated before, I can't quite get my head around if we can benefit from a change, maybe running Availability Groups on virtual machines instead?

So my question is: What would you think is the best solution to look at given these factors?

EDIT I was a bit sloppy with terms here, Failover clustering VS Availabillity Groups of course.

I'm looking into AlwaysOn to see if i can benefit from it, but i struggle to understand if i can or not, and i never previously dealt with AlwaysOn. So i'm turning to here too see if i can grasp this.

Today, we are running a traditional failover cluster with around 150 databases. It is a collection of a lot of different stuff that is in a lot of cases hardly used, but we can't throw it away for a million different reasons. But prolonged downtime is unacceptable (sigh). The environment looks like this:

• No single database is business critical (but the amount of DB's makes it critical)
• Databases ranging from 10 MB to 10 GB
• Avg. 30.000 Logical read/s, under 1 Physical read/s
• Low CPU usage (below 20%)
• Two physical servers in two datacenters
• Storage is on two VMAX 10k, one in each center, shared volumes distributed with VPLEX, so loosing one center will not affect uptime on storage)
• No need for reporting or anything out of the ordinary
• Most DBs are in Simple mode, with a nightly Full backup, business have no problem accepting the nightly backup as restore point
• A rare few databases are running Full mode and has 30 min transaction backups

The reason this solution was chosen at the time, was licensing and administration reason. We wanted to cut back on all the single SQL-servers doing nothing but cost us money. And we have removed about 60 SQL-server installations from the environment.

But now there is talk about how we should deal with this in the future, hardware replacement coming up in a year.

And the problem is, as i stated before, i can't quite get my head around if we can benefit from a change, maybe running AlwaysOn on virtual machines instead?

So my question is: What would you think is the best solution to look at given these factors?

I'm looking into Availability Groups to see if i can benefit from them, but I struggle to understand if I can or not.

Today, we are running a traditional failover cluster with around 150 databases. It is a collection of a lot of different stuff that is in a lot of cases hardly used, but we can't throw it away for a million different reasons. But prolonged downtime is unacceptable. The environment looks like this:

• No single database is business critical (but the amount of DBs makes it critical)
• Databases ranging from 10 MB to 10 GB
• Avg. 30.000 Logical read/s, under 1 Physical read/s
• Low CPU usage (below 20%)
• Two physical servers in two data centers
• Storage is on two VMAX 10k, one in each center, shared volumes distributed with VPLEX, so looing one center will not affect uptime on storage
• No need for reporting or anything out of the ordinary
• Most DBs are in simple mode, with a nightly full backup, business have no problem accepting the nightly backup as restore point
• A rare few databases are running full mode and has 30 min transaction backups

The reason this solution was chosen at the time was licensing and administration reasons. We wanted to cut back on all the single SQL Servers doing nothing but cost us money. And we have removed about 60 SQL Server installations from the environment.

But now there is talk about how we should deal with this in the future, hardware replacement coming up in a year.

And the problem is, as I stated before, I can't quite get my head around if we can benefit from a change, maybe running Availability Groups on virtual machines instead?

So my question is: What would you think is the best solution to look at given these factors?