• State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 28 subscribers
  • Views 8362 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Multiple transport modes? SAN transport mode with Agent?

jallen_41683
over 7 years ago

I am re-configuring our server and now have the option to do Agent-less on the majority of our VMs. Our Core is a physical box, and has 10gbE access to one of our NASes on the san, but not the other, so some VMs cannot be transported over that method.

 

My question is two fold: Can SAN be used for Agents as well as Agent-less? IE our Exchange and SQL servers will want to remain Agent for the Log Truncation - can they still take advantage of SAN transport? And that brings up - can one core do both, on a per-vm basis or is it all or nothing? IE 90% of our VMs are accessible via 10gbE to our physical core, but several are not (local storage on ESXi hosts). 

 

Ideally we'd have a mix of Agent and Agent-less, using SAN Transport unless they're on an unreachable datastore and then they'd use LAN NBD. Is there any way to tell which vms are using which policy, other than opening the VM and looking at NIC traffic during a backup?

Parents
  • +1 over 7 years ago
    I'll try to tackle this as best as I can, if I miss something let me know and I'll try to fill in what blanks that I can.

    The 'advanced' transport options, which is what the industry refers to HotAdd and LAN-Free SAN as, are only available for agent-lessly protected VMware VMs. If you are protecting your VMs with an agent installed on the local operating system you transport method will be over the lan (NBD) through the OS back to the Core. The transport will use whatever IPs/networks you have the agent exposed to the Core as, so if you wanted it to use a 10.1.x network and not a 10.10.x network then you'd need to add another nic to the agent machine and expose the agent to the core using the other IP scheme. Even if you did that however it would still be agent to Core via the operating systems.

    I'll stick to LAN-Free SAN since your core is a physical (Hot-Add applies to a virtual Core). The KB for that is here:

    support.quest.com/.../195634

    Basically it applies to shared ESXi storage - if your .vmdks reside on shared datastores that can be exposed to the Core in the same manner that they are exposed to your ESXi hosts, then we will read/write to those datastores in the same manner. So if you use iSCSI datastores on 10.10.x network, then using a separate/dedicated NIC on your Core expose those same iSCSI datastores to your Core using that 10.10.x network. Refer to the KB article above that goes over this (same for FC datastores).

    The agent-lessly protected nodes will auto-detect with each backup if hotadd/san/nbd is available, so you don't have to 'tell' the core to check for you, it will scan to see if it is available and if not (regardless of reason) it will failover and attempt an NBD backup.

    Currently our UI does not indicate which transport was used, our logs show us which, or as you mention the adapters tell a good story as well. This is currently a feature request that has not been implemented into the UI as of yet.

    Also want to mention (since you brought up Exchange and SQL) the agent-less log truncation functionality is currently being tested for future releases, it however is not in the currently build as of yet.

    If I missed something let me know, however that is what I have at the moment. Have a good one.
Reply
  • +1 over 7 years ago
    I'll try to tackle this as best as I can, if I miss something let me know and I'll try to fill in what blanks that I can.

    The 'advanced' transport options, which is what the industry refers to HotAdd and LAN-Free SAN as, are only available for agent-lessly protected VMware VMs. If you are protecting your VMs with an agent installed on the local operating system you transport method will be over the lan (NBD) through the OS back to the Core. The transport will use whatever IPs/networks you have the agent exposed to the Core as, so if you wanted it to use a 10.1.x network and not a 10.10.x network then you'd need to add another nic to the agent machine and expose the agent to the core using the other IP scheme. Even if you did that however it would still be agent to Core via the operating systems.

    I'll stick to LAN-Free SAN since your core is a physical (Hot-Add applies to a virtual Core). The KB for that is here:

    support.quest.com/.../195634

    Basically it applies to shared ESXi storage - if your .vmdks reside on shared datastores that can be exposed to the Core in the same manner that they are exposed to your ESXi hosts, then we will read/write to those datastores in the same manner. So if you use iSCSI datastores on 10.10.x network, then using a separate/dedicated NIC on your Core expose those same iSCSI datastores to your Core using that 10.10.x network. Refer to the KB article above that goes over this (same for FC datastores).

    The agent-lessly protected nodes will auto-detect with each backup if hotadd/san/nbd is available, so you don't have to 'tell' the core to check for you, it will scan to see if it is available and if not (regardless of reason) it will failover and attempt an NBD backup.

    Currently our UI does not indicate which transport was used, our logs show us which, or as you mention the adapters tell a good story as well. This is currently a feature request that has not been implemented into the UI as of yet.

    Also want to mention (since you brought up Exchange and SQL) the agent-less log truncation functionality is currently being tested for future releases, it however is not in the currently build as of yet.

    If I missed something let me know, however that is what I have at the moment. Have a good one.
Children
No Data