V400 and SQL 2012 (not in VM environment)

[JasonAntes]

I'm looking at the best way to deploy SQL 2012/2014 with my v400 3PAR arrays. I have a production and DR array. All the white papers I've been able to find so far deal with SQL 2012 in VMWare which hasn't been as helpful as I'd have liked. My 3PAR is not licensed for much (no DO, AO, snapshots, etc).

My general questions are:

Replication - use replication or just use a LAG node in DR with DAS? The business removed Exchange 2010 from SAN except for the node used for backup (it's a lot faster to backup directly over fiber) in order to go with the MS recommended JBOD DAS setup. They may push for DAS here too and only have 1 node on the SAN for backup purposes.

CPG's - Currently we use a RAID 5+1 layout for everything (political battle I couldn't influence before). Should I push for a RAID 1 CPG layout for Logs or leave as is. I understand it isn't the huge difference that it is with a normal RAID controller and it'd still be the same disks but I'd like some other opinions.

Is there some licensing for the v400 that I should be pushing for that would be a boon to a SQL 2012 rollout knowing that VMWare is not where SQL will reside? It will be either on HP c-class 680 blades or Proliant 380's built with Server 2012 R2.

Thanks,
Jason

[zQUEz]

There is no SQL2012 specific features/licensing that come to mind, though, depending on your priorities and disk availability, I would push for AO more than anything else.

In terms of RAID, my personal preference with 3PAR is to always go with Raid5 until I see a reason otherwise based on performance you are getting and what you want. LOG drives are generally heavy writes, which is all going to cache anyway, so it depends on the size of your cache vs. the peak amount of data writes to your log files.

I prefer to check SVCTMs on the VLUN's and what the OS os saying also to decide where to go from there.

[Richard Siemers]

Array based replication for 3PAR is expensive for the initial license and increases your annual maintenance as well. Futher more it adds complexity to the environment in the form of scheduling and managing the syncs/splits/updates outside of SQL and doing it in such a way to maintain perfect consistency. If all you need to replicate is SQL, then use SQL to do it... if you have applications that do not include their own native replication, then array based replication comes into play.

Since the application in question has its own replication options (SQL 2012 has at least 3), I think you will be best served using a SQL based replication to the DR SQL server/storage. This keeps all of the support under one roof (Microsoft DBAs) and avoids duplication of effort/features.

[hdtvguy]

Some things to keep in mind when looking at 3par Replication, there are some limitations for mission critical workloads. The 3par can only replication 20 volumes at a time concurrently. Also there is no concept of consistency groups with replicated volumes. So depending on how many volumes you are replicating and the frequency you may have trouble keeping things up to date unless you have a large enough pipe and even then if too many volumes need to replicate frequently you may find yourself lagging. We have SQL in VMs and are learning this the hard way right now. We still do log shipping, but were trying to move to SRM to be able to bring up exact copies n DR. If you looks for my threads I explain in detail the current issues that we faced with replication.

[Cleanur]

See my post on the link below, consistency absolutely is guaranteed, it's just the old documentation was pretty ambiguous about how consistency was guaranteed.

viewtopic.php?f=18&t=471&start=10

But like any other consolidated replication technology, If you don't have the bandwidth, you don't have the bandwidth........

[skumflum]

Array based replication for 3PAR is expensive for the initial license and increases your annual maintenance as well. Futher more it adds complexity to the environment in the form of scheduling and managing the syncs/splits/updates outside of SQL and doing it in such a way to maintain perfect consistency. If all you need to replicate is SQL, then use SQL to do it... if you have applications that do not include their own native replication, then array based replication comes into play.

Since the application in question has its own replication options (SQL 2012 has at least 3), I think you will be best served using a SQL based replication to the DR SQL server/storage. This keeps all of the support under one roof (Microsoft DBAs) and avoids duplication of effort/features.

I second that. If the application have built-in high availability, use it. It is a trend we will see more and more. A good example is the move from traditional cluster to DAG in Exchange

[JasonAntes]

Ok, thanks for the input. The v400 is already licensed for replication and is used for that with SQL2008. I knew 2012/2014 changed over to the Exchange model for clustering so that was the reason for the replication question. I don't have a problem with letting SQL deal with the replication as it releases me from being responsible for it and with the issues in getting our DBA's to understand how that works in a fail-over scenario I think it's just better all around to let them handle it.

As background info on my v400, it has 144x 400GB SAS drives with replication and reporting being licensed along with capacity. Other than that there is little else on the array so we don't use all the more interesting features of this array. Our DR site has a 1-1 matching array. Right now I only have a RAID5 5+1 CPG in use for hosts.

[hdtvguy]

See my post on the link below, consistency absolutely is guaranteed, it's just the old documentation was pretty ambiguous about how consistency was guaranteed.

viewtopic.php?f=18&t=471&start=10

But like any other consolidated replication technology, If you don't have the bandwidth, you don't have the bandwidth........

Consistency across replication within a Remote Copy Group does NOT exist in 3par, any references to consistency are not around a RC Group. Test it you will see. Start an RC group with 2 volumes in it. Let one volume finish replicate and while the other is still replicating break the link. The volume that finished replicating will stay replicated while the volume in flight will roll back to the snap taken at the beginning of replication. Find me many systems that will deal with that if they have multiple volumes as part of the system. Trust me we have been fighting this battle for a year now, I replicate over 500 volumes every day and have some legacy systems that have 10-15 volumes as part of their system.

[skumflum]

Are you using Adaptive Optimization?

[Richard Siemers]

Consistency across replication within a Remote Copy Group does NOT exist in 3par, any references to consistency are not around a RC Group. Test it you will see. Start an RC group with 2 volumes in it. Let one volume finish replicate and while the other is still replicating break the link. The volume that finished replicating will stay replicated while the volume in flight will roll back to the snap taken at the beginning of replication. Find me many systems that will deal with that if they have multiple volumes as part of the system. Trust me we have been fighting this battle for a year now, I replicate over 500 volumes every day and have some legacy systems that have 10-15 volumes as part of their system.

Hold on HDTVguy, take a moment to re-read what Cleanur posted back in August of last year. Also checkout the Remote Copy Users Guide page 237. I suspect you may have been overlooking some details and shamelessly spreading doom and gloom where it wasn't deserved.

Your scenario: Start RC group with 2 volumes, let 1 volume sync and then break the link before the 2nd finishes (I assume you really mean after initial syncs have been established). What you see with the admin tool is 1 up to date replica, and 1 rolled back. I'm with you thus far, but what you're not telling us about is the snapshots of the replica base volumes that would be promoted in the event a real DR was needed of this group in its current state. If the rc group were to be put into failover mode, it is suppose to promote those snaps and revert to a state of "exactly what you want". The previous consistent set of snaps will be promoted, reverting all VVs in the group the last consistent sync. Can you witness/confirm this by listing snapshots while a resync is in progress?