July 3, 2013 at 5:51 am
If you have production environment that is a fail over cluster is it a best practice to have your development environment be the same configuration for testing reasons? I would think so, but can't really find many definite answers on the the web.
July 3, 2013 at 6:55 am
It depends on how available you need your dev system to be. What is your SLA for dev systems?
Failover clustering provides instance level availability, not database availability
July 3, 2013 at 6:59 am
What if the DB mirroring is involved on the production box?
July 3, 2013 at 7:04 am
Then your production database has high availability. It depends on business requirements. There is no best practice for how close Dev needs to be to Production.
July 3, 2013 at 7:10 am
Sounds good, thanks for the help
July 3, 2013 at 10:09 am
i'd say that you should definitely have a clustered environment in dev for the admins, so they can test changes or deployments and understand the impacts to production. It doesn't have to be an environment that's used all the time, but you should have one available.
July 11, 2013 at 12:25 pm
Assuming you have a DR (damage recovery) site and some sort of backup that runs nightly (RedGate for instance) then it's not 100% required to have your Devl environment equal to Prod.
Delving deeper into your question-- How large is your infrastructure ? Do you ONLY have a Devl and Prod environment ?
I run the following instances: Prod, Devl, Test, DR.
Application testing is done in test.
Devl is equal to Prod and has development done on it before moving it to Prod.
Prod is self explanatory.
DR matches Prod nightly.
July 24, 2013 at 5:18 pm
Not a requirement, but ideal.
In terms of permissions and schema changes, any non Clustered environment should do the trick, as long as you exactly recreate the same permissions you have on Pro on Dev (database and instance level).
Having said that, a Clustered environment is clearly different than a regular SQL instance. Patching, for example, is different. And taking the SQL instance down to test DR scenarios and coordinate with developer(s) will also be different.
I personally have a small VMware Cluster (running on an SSD external drive) where I test simple things. It is virtually impossible for me to accommodate all my user databases there but I can test simple things like adding or removing disks prior implementing on Pro. Same goes for patches.
August 6, 2013 at 10:49 pm
I find with clusters it's nice to have a cluster to play around in so you can test and understand changes better.
We run a Active/Passive 2 node Windows 2008 R2 with SQL 2008 R2 cluster.
Recently i purchased a "cheap" HP DL160G8 with just 2 x 6 core CPUs 32gb of ram and 6 x 600GB 10k 2.5inch drives. I installed Windows 2012 Std installed the hyper-v and windows storage server roles into the host OS. Then i just created 2 Windows 2008 R2 guests, Created some ISCSI LUNS on the host OS created a private network between the host and the guests and presented these disks as the "SAN". Created a private network between the two Guests for cluster traffic and then gave them access to the real network.
Built the cluster and installed SQL 2008 R2, seems to work great for testing and learning. The performance actually isn't toooooooo bad either. All 6 disks are just in one large raid 5 LUN but it's only used for testing how the cluster responds to changes etc so yeah.
August 6, 2013 at 11:54 pm
greg.celentano (7/3/2013)
If you have production environment that is a fail over cluster is it a best practice to have your development environment be the same configuration for testing reasons? I would think so, but can't really find many definite answers on the the web.
Some DBA team doesnt support development or QA(test) environments , in case DBA team supports these environments as well then all prod checklist will have to be followed. hope people will agree to it.
Regards
Durai Nagarajan
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply