Skip to main content
  • EN

Anyone have a need for this:

Currently customers have 2 options when connecting a Tape Server to a Tape Library

1: Physical Tape Server: attached to the Library/FC
2: Multiple Virtual Tape Servers: partitioning the tape library so each Tape Server (VM) will see only select drives, and slots.

Either way would maximize the throughput of data transference. Currently having 1 VM as Tape Server does not maximize the libraries efficiency throughput.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

You can add multiple tape servers to the same installation of Veeam Backup & Replication. But mind that you cannot add one tape library to two different tape servers and write data to it from both tape servers.


Would this work:  Ability to have multiple tape servers within single VBR see and manage same multi-drive tape library
To optimize the use of libraries and drives, it should be supported between multiple Tape Servers within a single VBR. Although the library’s media changer is controlled by 1 Tape Server, all of the additional Tape Servers would have access to the media changer through centralized management. Thereby all Tape Servers can see all drives, and slots, and the Primary Tape Server coordinates drive and slot access, all to maximize throughput of data streams

As far as I am aware and know you can only have one tape Library per tape server with no multi access based on the help page you posted too.  Veeam tends to want to control the entire tape Library.

Correct - I have asked for Feature Enhancement, so just wanted to get comments if this would be beneficial - Single VM controlling a large library with numerous drives would never be able to efficiency transfer enough data consistently to keep the drives spinning.

I gotcha. Yeah that would be a good suggestion for sure.

Ok, you are asking for a construct like a library manager and library clients in Spectrum Protect.

Yes, I would be glad if this would work with Veeam, too. Then you could maximize the usage of your libs and drives

 

I think you have to write such a feature suggestions into the Veeam forums. There is product management reading.

I support this request. :sunglasses::thumbsup_tone3:

Sounds good. To understand you right: do you talk about multiple physical tape server?

Just stumbled upon this.

We regulary do connect the individual drives of a single library to different tape servers. Reason is - as stated - to circumvent a bandwidth bottleneck at the tape server. LTO8 wants to have up to 360MB/s. So four drives would be too much for 10G already.

The only thing to keep in mind is: you have to partition the library. So to VBR they look as if they are individual single drive libraries. Most libraries with multiple drives offer that option.

We don’t use virtual tape servers though - as it would only work with iSCSI anyways. I like to combine the tape server role with a Windows repository. So e.g. each extent of a SOBR can become a tape server as well. This ensures maximum speed during tape out. We use SAS or FC for the drives.

Sounds good. To understand you right: do you talk about multiple physical tape server?

i will add a +1 to this feature specially with the increase of bandwith rate of LTO9, didn’t see a bottleneck for the moment but our FC infra is brand new with 32gb ports.

I will deploy a library on ethernet with 10gb/s in short term, now i’m little bit affraid. The controller doesn’t support for the moment 25gb port.

Just stumbled upon this.

We regulary do connect the individual drives of a single library to different tape servers. Reason is - as stated - to circumvent a bandwidth bottleneck at the tape server. LTO8 wants to have up to 360MB/s. So four drives would be too much for 10G already.

The only thing to keep in mind is: you have to partition the library. So to VBR they look as if they are individual single drive libraries. Most libraries with multiple drives offer that option.

We don’t use virtual tape servers though - as it would only work with iSCSI anyways. I like to combine the tape server role with a Windows repository. So e.g. each extent of a SOBR can become a tape server as well. This ensures maximum speed during tape out. We use SAS or FC for the drives.

I like your approach with a tapeserver per repository server. I think this brings good performance.

The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.

A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else. 😎

 

I like your approach with a tapeserver per repository server. I think this brings good performance.

The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.

A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else. 😎

Correct. That’s a weak point. But with per-VM-chains VBR more or less equalizes the amount of data being driven to a single library. Good point is, you still have the drive parallelity available for your jobs. Once you reach 3 drives there is no other option anyways. Despite you have >10G at the tape server.

 

I like your approach with a tapeserver per repository server. I think this brings good performance.

The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.

A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else. 😎

Correct. That’s a weak point. But with per-VM-chains VBR more or less equalizes the amount of data being driven to a single library. Good point is, you still have the drive parallelity available for your jobs. Once you reach 3 drives there is no other option anyways. Despite you have >10G at the tape server.

I have direct fibre channel connections to the library at my tape servers and the repository direct on them. So I can send the data via FC to the drives and these connections are at least 16Gb, the newer ones 32Gb. And I can utilize several FC connection in parallel.

With a suitable disk solution more than three drives can be utilized.

Comment


Terms & Conditions