Hello @MARamius
Thanks for the details and questions.
Can you confirm if this is a library that has already been setup in low-bandwidth mode and CV is performing the deduplication of the data and then you are attempting to change it to high?
Or is this a fresh configuration? If so the following goes over the config steps:
https://documentation.commvault.com/2023e/expert/hpe_storeonce_catalyst_library_configuring_catalyst_store_as_commvault_hpe_catalyst_library.html
Kind regards
Albert Williams
Hello Albert,
we have the problem in both variants:
- fresh new catalyst store, configured for high-bandwidth only, then in CV a created a new library, to the COFC parameters to use this store.
- existing catalyst store, already connected to CV via COFC, already containing backups in low-bandwith (i.e. CV did the dedupe and not StoreOnce), then in Catalyst (HPE) change settings to use high-bandwidth only.
Yes, I followed the instructions. also about COFC.
I miss a setting in CV to select the bandwidth mode. Or, that CV would recongnize and accept the bandwidth prefereration set in the Catalyst Store (HPE).
Hello @MARamius
The change from low bandwidth to high i think will always cause you issues. Unless you tell Commvault to stop deduping the data we will always try to do that. When you disable dedup with data already associated it is generally a lot cleaner and safer to just make a new pool and associate the agents there.
In the case of a new config, the doco goes over it all, if you are finding the jobs failing then a support ticket is going to be the next step as it might be a bug.
Kind regards
Albert Williams
Hi Albert
in the docu I just can’t find any hint, how to tell CV to not DD but let the StoreOnce do it (i.e. to honour the high-bandwidth wish). If you can show me?
We also raised a ticked, however it’s ping-pong between HPE and CV, both claims it’s the other ones fault.
also, just to be sure, we created another “eco-system” from scratch (new Catalyst Store, set to high only, new CV Storagepolicy with new primary copy, new backup set, verified that everywhere in the chain (iDA, MA, SP, ...) everything about DeDupe/… by CV is disabled. Still same result
Error occurred in Disk Media, Path kCS_High_Test\YC1TF9_08.05.2024_08.12\CV_MAGNETIC\V_3664525] I-3203 OSCLT_ERR_INVALID_BANDWIDTH_MODE]. For more help, please call your vendor's support hotline.
Isn’t there any other customer here with Catalyst and CV in high-bandwidth?
Best Regards
Just to clarify here, in low bandwidth Commvalt does not do the dedupe. Its HPE binaries which are integrated into our software, so its still HPE dedupe. Please configure low bandwidth at Storeonce console.
Hi jitendran,
thx for clarification.
But what we need to achieve: The dedupe (HPE binaries) needs to happen at the HPE box (StoreOnce) and not already at the generic commvault media agent.
i.e. from iDA to MA and from MA to final destination (StoreOnce catalyst library, running on StoreOnce Box) we need the original data, uncompressed, not deduped. Only when it finally hits the destination there shall the HPE binaries do their magic.
Reason: StoreOnce Box is sized to properly do all that extra DD/compression tasks, but the mediaagents are NOT sized that way. and we have high bandwidth fibre channel between MA and StoreOnce Catalyst. So we do NOT need to save bandwidth between MA and S1/Cat. But when we let the MAs do the DD-job we have less throughput (CPU goes 100% on MA, as they are not meant to do DD).
When I do not use Catalyst but VTL then I get what I want: all data comes in raw over the FC, and then the StoreOnce box has to do all the tasks.
But Catalyst has some benefits over VTL, thus we want to achieve the same with Cat.
And that’s what HighBandwidth mode means (according to HPE).
But, I found no way yet to tell CV to use HighBandwidth and not LowBandwidth.
So, again. How to use/configure CV with HPE StoreOnce Catalyst (FC, but should be the same also for Ethernet) to use HIGH bandwith mode, i.e. DD shall only happen at the HPE box, not on the MAs.
As you can see from the error message which is coming from HPE that high bandwidth cannot be used:
Error occurred in Disk Media, Path CS_Test1\STYMSI_07.18.2024_13.35\CV_MAGNETIC\V_3663970] 9-3203 OSCLT_ERR_INVALID_BANDWIDTH_MODE]
thx for quick reply:
So, you are saying, from CV point of view: HPE is simply not supporting HighBandwidth with CV?
Because: HPE says: we fully support Catalyst with CV. as long as it is a valid mode it’s the task of the backup ISV to properly select a suiting mode.
I can make selections at HPE (preferred mode, secondary mode). for both modes I can select low or high bandwidth. together with HPE and CV the following choices are working:
- pri: low, sec:HIGH
- pri: HIGH, sec: low
- pri: low, sec. low
what is not working:
- pri: HIGH, sec: HIGH.
However, in the selections 1., 2., and 3. the negotiated mode is ALWAYS low.
But, we need HIGH
We know from consultants that HPE StoreOnce Catalyst works in HIGH with Veeam, with DataProtector
Thus we still hope to get CV also to use HIGH. But we found no knob, switch, parameter, setting, … to tell inside CV to use HIGH. only the “external” forcing of variant 4. But, that results in the OSCLT_ERR_INVALID_BANDWIDTH_MODE reply :-(
For us it’s unfortunately ping-pong blaming between HPE and CV. both sides says HIGH shall be working and it’s the fault of the other side :-(
We consulted the HPE engineers who were involved with the initial integration and this was their response (see below in quotes).
High bandwidth is not supported. So we recommend you to use low bandwidth and check performance.
“High BW mode is a legacy mode and does not support all Catalyst features that Commvault uses.
In our initial Commvault/Catalyst integration discussions we requested that Commvault only support Low BW mode, so it could make use of all Catalyst features without compromise.
Usage of fixed block chunking for VM and HANA backups has to be done with Low BW mode, as it is done by the Catalyst client.
Catalyst clone is also *much* less efficient if not done in Low BW mode.
Both these features enable backups to be completed much faster and more efficiently than could be achieved with High BW mode.
Furthermore since with Low BW mode (aka source-side dedupe mode) there is very little data to be transferred, backup across WAN and usage of IPSEC to secure data across the wire between Catalyst Client and Server are very viable.
High BW mode was only ever of value to customers running media servers, 10-15 years ago, on ancient proprietary unix platforms, whose CPUs had awful performance (so catalyst client-side variable chunking, hashing and compression was very slow). These platforms are now all obsolete. Today systems have many powerful CPU cores and the bottleneck is pretty much always the network BW achievable between Catalyst Client and Server, not the media server CPU.”