Video Screencast Help

configuring SSO or FT client for Exchange DAG NBU7.5

Created: 13 Dec 2012 • Updated: 20 Oct 2013 | 5 comments
Jomy's picture
This issue has been solved. See solution.

configuring SSO or FT client  for  Exchange DAG

we have 1.6 TB of exchange backup and it takes 12 hours to complete.

how we can reduce the backup window.

Thanks in advance for ALL

Comments 5 CommentsJump to latest comment

RLeon's picture

Wow this is complicated.

Let's do this one by one. If we get confused with any of these, then the rest of the post would not make any sense at all. So if you decide to skip any of my wordy bits (i.e., all of them), then reading the rest would probably not help.

Before we talk about Exchange, and how DAG is different to "traditional" clusters, let's start with agreeing on some NetBackup terms.

Media Server and SAN Media Server:
They are mostly the same, except that with a SAN Media Server, it can only backup itself.
For example, you can backup its volumes/folders to tape drives that it is directly connected to. However, if you try to backup other clients through a SAN Media Server, you will receive errors. A SAN Media Server's license enforces that it can only backup itself.
The tape drives can be SSO shared with other Media Servers or SAN Media servers in the same Nbu domain. If you want to backup that other client to the SSO shared tape drives, you will have to do it through a Media Server that is also connected to these shared tape drives.
How that relates to your query:
Most of the time with failover clusters, you can simply setup a SAN Media Server on each node and achieve the desired result. Which ever node the virtual name (and its resources) fails over on to, the backup would use the SSO tape drives that are connected locally to the current node. The result is that nothing goes over LAN and the backup is fast.
This special behavior requires the use of some commands to setup the "app cluster" feature that cannot be configured in the GUI. You can find out more from the Nbu HA guide.
I talked some more about this "app cluster" feature in this thread:

FT Media Server and SAN Client:
A Media Server and a FT Media Server are mostly the same, except that the latter can also receive backup traffic from clients via its FC port, which should be faster than receiving through LAN the traditional way; in most cases.
SAN Clients are clients that can also send backup traffic out of its FC port to a FT Media Server's FC port. For details, please refer to the Nbu FT Media Server & SAN Client guide.
How that relates to your query:
You are considering sending backup traffic over FC SAN from SAN Clients to a FT Media Server to reduce the backup window.

Don't get mixed up between SAN Media Servers and FT Media Servers. By design, a FT Media Server backs up other clients (other than itself), which a SAN Media Server cannot do.
A SAN Media Server is named because it can backup itself to directly connected SAN storage devices.

With those out of the way, let's talk about Exchange and DAG.

Failover clusters and Share Nothing clusters:
Older Exchange/SQL clusters used to be failover clusters. In simple terms, nodes A and B both have access to the same disk, typically shared via SAN connections. Only one node can have active access to the disk at any time. If the active node A fails, then node B would take over and become the active node. The clients connected to the cluster (via the cluster virtual name) will experience minimum down time, if any. This is sometimes referred to as a Shared Everything Architecture because the nodes share the resources that the cluster serves.
The Exchange DAG mode (And the AlwaysOn mode in SQL 2012) do not share access to disk resources between the nodes. In simple terms (leaving out CAS and stuff), Nodes A and B each has their own disks (SAN connected or not) that store the node's own data, while also acting as a replication target for the other node. Under a virtual name, both nodes could serve clients at the same time. If node A fails, the clients that were using it would be redirected to node B, where node A's data could still be found because it would have been replicated to node B before node A's failing. (There are many exceptions. Please refer to MS TechNet for details about DAG)
This is sometimes referred to as a Shared Nothing Architecture because the nodes do not have to share access to the same resources to achieve high availability. More info here:
How that relates to your query:
While the "app cluster" feature and the SAN Client transfer mode work well with traditional failover clusters, there are special considerations to take into account when applying them to Shared Nothing clusters like the Exchange DAG.

Using app_cluster with DAG:
Know that the Exchange 2010 DAG is mostly the same as the Exchange 2007 CCR. (Refer to TechNet for details.)
Next, recall that the Nbu "app cluster" feature is for forcing direct-to-SAN (LAN free) backups with a virtual name that moves around cluster nodes.
The following technote about how to setup "app cluster" with CCR should also work with DAG:
Please be aware that this technote skipped alot of steps on setting up the app cluster. You will have to refer to the Nbu HA guide for the full list of the steps, and explanations.
The problem with the methodology sugguested by this technote is that the direct-to-SAN backup would actually only work on a single node at any given time. This fact is actually pointed out in the "Functional overview" section, if you read into it.
Say we follow the technote's setting which is to backup passive databases. In a typical DAG configuration, Node A's passive database would reside on Node B. And if the new cluster name (the new one created for the app cluster storage unit) is also on Node B, then Node A's passive database would indeed be backed up direct-to-SAN style via Node B. However, NetBackup would also attempt to backup Node B's passive database, which resides on Node A (We told NetBackup to back all passive database in the DAG, remember?), but since the new cluster name is not on Node A, in this case, Node B's passive database would travel across LAN from Node A to Node B because the new cluster name is on Node B. You could use the MS cluster management tool to move the new cluster name from Node B to Node A, but that would not solve the problem. The travel-across-LAN backup would still occur as described above, but in the other direction.
And then this whole thing would not even work if you are running SAN Media Servers on your DAG nodes. Recall that unlike Media Servers, the SAN Media Servers do not accept backup traffic from other clients. That includes other nodes in the same DAG.

Using SAN Client and FT Media Server with DAG:
I couldn't found anything that says it wouldn't work with DAG. And seeing how SAN Clients should work exactly the same as "normal" clients (except for the fibre transport part), I would think the SAN Client plus DAG config is supposed to work.
I haven't tested it, but this post suggests that there could be problems:
It would seem that the SAN Client side of things wants the Nbu service to run the "local system" account, but the Exchange side of things wants it to run another account with Exchange permissions.

Using SAN based off-host althernate client backup with DAG:
According to the Nbu Snapshot Client Compatibility document, off-host backup with CCR/DAG is not supported.

The Deduplication option:
This is not going through SAN, and does not involve having to install (SAN)Media Servers or FC HBAs on your DAG nodes.
If you use NetBackup Deduplication, you may want to try running client-side-deduplication for the Exchange DAG jobs. After the initial backup, subsequent backups should give you some very nice speed increases unless your mailbox nodes have high change rates. Curiously, Backup Exec does not recommend using client-side-deduplication in DAG environments. I wonder if NetBackup has similar recommendations:

I hope that helped.

RLeon's picture

If your Exchange DAG environment is built on VMware VMs, you may think that you could utilize the vStorage SAN transport mode to help reduce the backup window backing up DAG nodes. That is actually another can of w.... warm and fuzzy NetBackup goodness.

Since you referred to SSO and FT, I assumed your environment runs on physical nodes.

Jomy's picture

Thank you for comment on the issue.

My exchange server is in active /active mode

sharing 50% of mail box on each node

can i configure this servers  as  LAN free backup or shall i go for EVault as a solution.

kindly suggest

Jomy's picture

if i go for   symantec E vault is via ble  solution

RLeon's picture

Using EV would help to shrink your Exchange DBs that will be backed up.
So yes it will reduce your backup window, without you having to necessarily go through with any of that SAN backup stuff.

Another way to approach this problem would be to try to increase the Exchange servers' performance, network performance (nic teaming, 10Gb LAN, etc.) and general NetBackup performace tuning.

The following guide would be a good place to start:
NetBackup Planning and Performance Tuning Guide

It was written for 7.1, but the points still apply to 7.5.