FT Media Server needs 2 hba?

[Steppan]

Hi,

We're still in deployment phase for NB8 and we're facing some strange behavior from FT Media server.
The guy who is deploying the environment forwarded the information that he received (don't know if its true) from Veritas support, where they say I should have 2 HBA's in my server, one for connecting to my tapelibrary and another to connect to other SAN devices (storage, other servers, etc) because the media server cannot map the two ports from a single hba separated as "initiator mode" and "target mode", once you change the mode, it changes for two ports. I've been searching the Netbackup forum here in the community and I found lots of messages about FT Media Server, SAN Zoning and never found nothing about that.

How much is true? I really don't believe this "story". Never had a single experience with Netbackup but used many other backup products in the last 15 years, and never heard of anything like that. The actual backup software here is Data Protector and we make "OK but slow" SAN backups using a poor old 4Gb SAN HBA with it's 2 ports. It can communicate with tapelibrary, storages, servers, datastores from vmware and other devices without any issue.

I told him I'll only take this "story" if they point me to an official white paper, KB or official statement from Veritas support team because the "sales" guy who we meet and did the solution sizing prior the purchase does not told us anything regarding the need for two hba devices.

Thanks

Steppan

[manatee]

not particulary sure but my master/media server have 2 HBA and the reason provided to me is to use one for the tape library and the other for the LAN.

hth.

[RiaanBadenhorst]

Hi,

Its true.

The reason for this is that the target mode is set on the chip, so if the HBA has 2 ports, both port usually get affected by setting it to Target Mode (required for FT). So if you have a single card with 2 ports, it will change both ports to Target. 

[Steppan]

OK, that makes sense but, how much it will compromise my backup strategy? Just to clear things, meaning SAN based backups I have:

My master server is a virtual machine (2012 R2) with NB 8.0, hosted in the vmware cluster.
My FT media server is a physical machine with rhel 7.2 and 7.7.3 installed (8.0 media server has bugs).

The FT Media server is connected to SAN and we have the current zoning configuration:

- 5 VMware hosts (with 4 datastores) zoned the storage, which provide these 4 datastores, to the media server and presented their datastores LUNs to FT media server.
- 2 Exchange nodes in DAG (zoned the two ports from each node to the media server hba as per instructions from the guy who is implementing NB8 - server to server zoning is weird to me)
- 2 SQL server in Cluster (same crazy zoning from Exchange - server to server)
- 1 Tapelibrary with two LTO-7 drives zoned to the media server

We also have a Dell DR4100 appliance (10Gb Lan) where all backups are store first (to use accelerator, dedup, etc.)

When we run backups from VMware infrastructure, it shows "Transport mode: LAN" at Detailed Status, but shows "Info bpbkar (pid=xxxxxx) INF - Transport Type =  san" inside the status window. Weird, but seems OK.

When we run backups from Exchange, the transport type is showing "LAN", I can see throughput increasing at the switch SAN port where the exchange node is connected to (as it should be reading from SAN storage the content from Exchange databases), but when I run "nbftconfig -listclients -verbose" while Exchange backups up, it shows "FT Server Connections: 0".

When we run backups from SQL servers, transport type is LAN and the throughput is ridiculous slow.

This lack of 2 hba's is somewhat compromising the media server hability to read information directly from SAN storage and forwarding it to the tapelibrary or DR4100 appliance (which is LAN)?

[vtas_chas · Accepted solution]

Be careful not to mix apples and oranges.  There isn't just a single 'SAN' backup type in NBU like there are in some other applications.

VMware SAN-based backups aren't the same as SAN client or SAN media server backups.  SAN client backups send data to a target mode port on a media server, using a specific target mode driver installed on the media server.  VMware VADP SAN transport backups mount the datastores as another initiator in the mix, and the backup host just looks like another ESXi server.  

SAN Media server puts the media server bits on an application host and treats it like a media server in the NBU architecture but it only performs backups for that given application host.

The Exchange and SQL servers will be initiators connected to the target mode port on the media server (your "weird" zoning) as it is set up to see the media server as storage, essentially.  That allows the data to go over the SAN and metadata over the IP network.

Your comment about LAN vs SAN showing in the Activity monitor is a long-standing issue.  Always look in the job details to get an understanding of where the data is flowing.  

[Steppan]

Thank you for clarifying. Everyday's a new disapointment with the software. Never heard of any other backup software working like that. When the "solutions engineer" from Veritas was validating the hardware and licenses for this solution he never told us that the media server to make backups from san needed to be Linux. That was the first shock. The second shock was the bug when we're in the middle of FT Media Server implementation and the server was rebooting itself at "nbhba -l", and Veritas declared that was a bug and would be fixed in 8.0.1, solution is to use media server 7.7.3 (for god sake why they release a software that can't even pass the instalation process of a such simple feature like backup from san). Now, the third shock, with 7.7.3 we could make the media server work with FT feature but we discovered that we should have ordered a server with 2 hba's instead of 1 if we want do use our brand new LTO-7 Tapelibrary in parallel with the disk backup appliance. That great "solutions engineer" strikes again. Now we will have to return that server because it's a blade type that don't allow us to add another hba unless we add two new brocade switches at enclosure rear slots. The solution: a rack type server with 2 hba's.

Things get worse everyday, sincerely.