Hi,
I'd like to suggest the ability to exclude some machines from being offloaded when using capacity tier.
Our jobs targeting the SOBR+Capacity Tier sometimes have many VMs and Agents that we actually do not need the extra copy to object storage.
I know with Ent+ license we can create as many SOBRs we want, but in Ent level we can create only two, so sometimes it is not enough.
Thanks.
-
- Service Provider
- Posts: 56
- Liked: 7 times
- Joined: Jul 25, 2018 5:08 pm
- Full Name: Eduardo Scheffer
- Location: Florianopolis - Brazil
- Contact:
FR: Exclusion machines from being offloaded
--
Best Regards.
Eduardo K. Scheffer - SE
Best Regards.
Eduardo K. Scheffer - SE
-
- Chief Product Officer
- Posts: 31804
- Liked: 7298 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: FR: Exclusion machines from being offloaded
Hi
The reality is that SOBR will never have such machine-specific logic, at least not in its current form. Simply because it was architected to be effectively a single repository - even if a very smart one (with multiple tiers, data redundancy etc.)
Effectively, SOBR = Storage Policy. And different storage policies require creating multiple different SOBR (even if all of them can and usually do still use the same physical storage).
I guess a less confusing way to explain the issue is the following. Imagine having a simple repository pointing to a LUN backed by a RAID-60 volume of a storage array. You cannot really tell some VMs going to this repository not to use the redundancy provided by RAID-60. Such flexibility would require a complete re-write of the entire storage stack, so not in this life.
What you can do however is create another, non-RAID volume on your storage array, and set up a different repository using this volume to use for such VMs. This is equivalent to creating a separate SOBR in our case.
I hear you regarding the issue with editions, and actually this is one of the reasons we don't carry them on our books any longer and are only selling the single, fully-functional "edition". I recommend you migrate to VUL, as currently you can get a good deal on such migrations - and stop thinking about your edition limitations altogether.
Thanks!
The reality is that SOBR will never have such machine-specific logic, at least not in its current form. Simply because it was architected to be effectively a single repository - even if a very smart one (with multiple tiers, data redundancy etc.)
Effectively, SOBR = Storage Policy. And different storage policies require creating multiple different SOBR (even if all of them can and usually do still use the same physical storage).
I guess a less confusing way to explain the issue is the following. Imagine having a simple repository pointing to a LUN backed by a RAID-60 volume of a storage array. You cannot really tell some VMs going to this repository not to use the redundancy provided by RAID-60. Such flexibility would require a complete re-write of the entire storage stack, so not in this life.
What you can do however is create another, non-RAID volume on your storage array, and set up a different repository using this volume to use for such VMs. This is equivalent to creating a separate SOBR in our case.
I hear you regarding the issue with editions, and actually this is one of the reasons we don't carry them on our books any longer and are only selling the single, fully-functional "edition". I recommend you migrate to VUL, as currently you can get a good deal on such migrations - and stop thinking about your edition limitations altogether.
Thanks!
-
- Service Provider
- Posts: 56
- Liked: 7 times
- Joined: Jul 25, 2018 5:08 pm
- Full Name: Eduardo Scheffer
- Location: Florianopolis - Brazil
- Contact:
Re: FR: Exclusion machines from being offloaded
Hi Gostev,
I totally get your explanation and thank you for it, it's all clear now regarding the complexity behind the scene.
Yeah, that's very cool of Veeam putting away the complexity of licensing editions e versions, that will put Veeam even higher regarding the simplicity of how everything is managed.
Thank you again!
I totally get your explanation and thank you for it, it's all clear now regarding the complexity behind the scene.
Yeah, that's very cool of Veeam putting away the complexity of licensing editions e versions, that will put Veeam even higher regarding the simplicity of how everything is managed.
Thank you again!
--
Best Regards.
Eduardo K. Scheffer - SE
Best Regards.
Eduardo K. Scheffer - SE
Who is online
Users browsing this forum: No registered users and 13 guests