If you were using NFS on Linux, then that is a limitation due to Linux NFS shares needing to be mounted locally. 

Since you are using cloud, it is a HTTP path and thus the same path will be used by both MA’s, giving you HA. You just have to share the mount path to both MA’s and have both MA”s configured under data path on the storage policy copy.

Hi,

As Jordan explained, it’s much easier using Cloud libraries this way. That’s the key point of Cloud libraries.

And you can share this library to more servers, but if you use DDB, those outside of the Gridstor will have to reach out to the MAs that host the DDB to compare signatures and then write unique blocks to the Cloud library.

About Gridstor or shared DDBs, well, you’ll have some kind of failover or load balancing, but when you use Deduplication, the DDB will be extended to both MAs, then if you lose one of the 2 MAs, then you’d lose access to one part of this shared Deduplication Database. It’s not a real problem for backups (and none for restores) but you have to be aware that it’s not a ‘my backups will perform smoothly if I lose 1 MA’ situation.

To be honest I never experienced 2 MAs and a Cloud library as storage, without deduplication. So if you won’t use deduplication I can’t tell you more.

What are you expecting by what you call ‘HA’ ?

High availability for backups ? (this one you mentionned it)

For restores ?

For Load balancing ?

Else ?

Regards,

Laurent.

As Laurent pointed out already there are some things to take into account. By default adding another MA to an existing cloud library will by default only deliver some form of HA in case you'd have to restore. But for backup you will have to alter the config so it is allowed to use the cloud library in case one or more partitions are down. When you allow jobs to proceed with one or more partitions being down than you'll end-up writing duplicatie data to the cloud library for as long as the data is in retention and for as long as those are being referenced in that partition. 

It will not really perform load balancing, because jobs will by default always pick the MA that was selected when the first job ran.

Hi @Jordan  and @Laurent ,

How do we use the same path for both MAs? Do you mean we add two cloud libraries by giving the same bucket for both MA? Or there is another method to achieve that?

Hi @Adel BOUKHATEM 

If you need to have both MAs accessing the same data of the same cloud library, then after the Cloud library is created in Commvault, just review its configuration and share it to the 2nd MA, and that’s all :)

On my screenshot of a Cloud library, you can see at the top right a SHARE button, that will allow you to share that library to some other MA.

If you need to use the same storage device but want to share its usage to 2 different MAs, then it’s a different case, better create 1 cloud library for each MA. But I think this is not was was requested at first.

Hi @Laurent 

The main purpose of the gridstor implementation is to still be able to aux copy/restore the data saved by both MAs.

In our case, we want to achieve the HA on the aux copies, in case of one of the MAs fails, the jobs will failover to the second one, same thing goes for the restore, if one of the MAs is down, I can still restore the data backed up by the MA that is down through the one that is still up and running, I don’t know if this is possible, since the MA that run the aux copy is the one owning the DDB, Index Cache … ?

If Loadbalancing (Round-robin) between the two MAs is possible to be achieved, it would also be great, that way, we’ll not overload only one MA with aux copies, while the second one remains idle.

@Commvault Engineer , what @Laurent describes will provide your desired results.

Hi @Laurent , I did the test and confirm your says. Thanks again !