Jump to content

SQL Always On + Netapp Stuff

1 minute ago, Dark said:

You'll enjoy it once you get it under use.


We can't get away from snapmanager at the moment (it's too convenient), so the netapp will remain as our db storage for the long run.

Yea current plan is to use it for our SQL clusters. We're also super tied in to snapmanager, our DR totally relies on it.

 

We also have an SQL Always-On Async Mode cluster across two cities in a multi-subnet configuration, iSCSI stretched VLAN, with snapmanager. We were told that setup couldn't be done :P.

Link to comment
Share on other sites

Link to post
Share on other sites

1 minute ago, leadeater said:

Yea current plan is to use it for our SQL clusters. We're also super tied in to snapmanager, our DR totally relies on it.

 

We also have an SQL Always-On Async Mode cluster across two cities in a multi-subnet configuration, iSCSI stretched VLAN, with snapmanager. We were told that setup couldn't be done :P.

Holy crap!  I hate derailing the OP topic but how do you like the Always-On Async Mode?  We are literally talking about SQL redundancy next week.

Link to comment
Share on other sites

Link to post
Share on other sites

1 minute ago, leadeater said:

@Dark

Oh and we almost went with a SolidFire for out VDI PoC, you used one of those?

Haven't touched SolidFire yet.  Had many talks with Pure but they still seem a bit lacking on the software side and they require their own disks (like netapp).  I'll do some reading and maybe make a call to SF next week as we're always looking at Netapp replacement/variant.

Link to comment
Share on other sites

Link to post
Share on other sites

Just now, Dark said:

Holy crap!  I hate derailing the OP topic but how do you like the Always-On Async Mode?  We are literally talking about SQL redundancy next week.

Meh topic is slightly pointless.

 

It's really good, if your close enough/low latency Sync mode is better of course.

 

There is a couple of things I would change that we had to do with our network environment. Don't use multi-subnet if you can. Applications have to be aware that it is and set in the connection string, Skype for Business doesn't support it. So if you can use a single IP address for the SQL Listener and have it able to live in multiple datacenters then do that.

 

If using iSCSI all Netapp heads need to be directly visible during snapmanager install, it's not used after install but for what ever reason it wants to see them. This is why we had to stretch out iSCSI VLAN.

 

Basically Always On is what you want to use now days, the flexibility it gives in moving the workload around and the fact you can have secondary copies as read only is nice.

Link to comment
Share on other sites

Link to post
Share on other sites

4 minutes ago, Dark said:

maybe make a call to SF next week as we're always looking at Netapp replacement/variant.

Netapp brought SolidFire :P

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, leadeater said:

@Dark

There we go, no more derail :)

I'll have to do some reading on it over the weekend so that I have a clue during our meetings next week.  Our SQL guy has been giving some push back on SQL replication/redundancy and we have a fresh Lync/Skype roll out starting.

Link to comment
Share on other sites

Link to post
Share on other sites

Just now, Dark said:

I'll have to do some reading on it over the weekend so that I have a clue during our meetings next week.  Our SQL guy has been giving some push back on SQL replication/redundancy and we have a fresh Lync/Skype roll out starting.

We had our Skype for Business database originally on a multi-subnet Always On cluster originally but we were getting some were warnings in the logs, functionally it was fine. We talked to the software engineers, we were the first production SFB install in the world :), and they said that this database configuration wasn't supported.

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, leadeater said:

We had our Skype for Business database originally on a multi-subnet Always On cluster originally but we were getting some were warnings in the logs, functionally it was fine. We talked to the software engineers, we were the first production SFB install in the world :), and they said that this database configuration wasn't supported.

But it worked!  xD

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×