Question

SOBR Designs


Userlevel 6
Badge +2

Hi Folks,

 

I have had a love/hate relationship with SOBRs. I am hoping I will be more on the love side going forward with the ability in V11 cloud connect to evacuate individual Tenants from a SOBR. I am finding that it is best to keep the number of extents down to low numbers, maybe even just 3. Also if using VMs, then one VM per extent otherwise your cpu and memory resources get divided by each extent. Keeping in mind that each concurrent task requires 1 core and 4gb of memory you don’t want this divided. Also if leveraging fast clone both on REFS and XFS you need even more memory.  What has been your experience with SOBRs?, especially for cloud connect? 


4 comments

Userlevel 6
Badge +2

Morning!

 

So I architected my company’s Cloud Connect offering and its been SOBR with ReFS all the way.

I am also of the stance that fewer extents is better if you can size those extents appropriately, more so because ReFS is going to give you the FastClone improvements and we want our customers to maximize on these as best they can.

We actually back our extents with scale-out namespaces too so that we have redundancy on our scalability.

 

It’d be good to have a chat about this at some point to see how you guys do things vs us but could be complicated as I believe we both have UK presence...

As long as we keep state secrets concealed we should be ok 🙂. The good thing is that when dealing with just the generic level of knowledge then there is not much to give away. Now if you guys have some great home grown method of rebalancing SOBR’s then 🙂 we might have to send our Canadian spies over there to woo you with cheap beer etc 😉 :) 

Userlevel 7
Badge +3

Morning!

 

So I architected my company’s Cloud Connect offering and its been SOBR with ReFS all the way.

I am also of the stance that fewer extents is better if you can size those extents appropriately, more so because ReFS is going to give you the FastClone improvements and we want our customers to maximize on these as best they can.

We actually back our extents with scale-out namespaces too so that we have redundancy on our scalability.

 

It’d be good to have a chat about this at some point to see how you guys do things vs us but could be complicated as I believe we both have UK presence...

Userlevel 7
Badge +3

Morning!

 

So I architected my company’s Cloud Connect offering and its been SOBR with ReFS all the way.

I am also of the stance that fewer extents is better if you can size those extents appropriately, more so because ReFS is going to give you the FastClone improvements and we want our customers to maximize on these as best they can.

We actually back our extents with scale-out namespaces too so that we have redundancy on our scalability.

 

It’d be good to have a chat about this at some point to see how you guys do things vs us but could be complicated as I believe we both have UK presence...

As long as we keep state secrets concealed we should be ok 🙂. The good thing is that when dealing with just the generic level of knowledge then there is not much to give away. Now if you guys have some great home grown method of rebalancing SOBR’s then 🙂 we might have to send our Canadian spies over there to woo you with cheap beer etc 😉 :) 

Had me at cheap beer...

Userlevel 6
Badge +2

When mixing ReFS and XFS it also seemed to be an issue even though Veeam documentation says it is ok. I suggest if mixing you are moving to XFS from ReFS or vice versa.  Also another thing with XFS is that I am finding it does not require quite as much memory as what ReFS does.

Comment