This post is more than 5 years old

2 Intern

 • 

236 Posts

30331

December 3rd, 2014 06:00

What are the benefits of using ifgroups with DD BOOST?

Hi All,

What are the benefits of using ifgroups, rather than physical or virtual interfaces, with DD BOOST?

Thank you.

11 Legend

 • 

20.4K Posts

 • 

87.4K Points

December 3rd, 2014 11:00

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

December 3rd, 2014 06:00

NIC port utilization and auto balancing.

208 Posts

December 3rd, 2014 09:00

ifgroups is basically to hand the load balancing and speed to the DDBoost software - rather than LACP on your switches.

It's faster than LACP - less overhead.

It's more simple from a Networking perspective, they are just IP's on physical ports (potentially though can be tagged or virtual ports in theory) - so no Network people required to setup the LACP link.

It avoids VPc issues when an LACP group needs to be split over 2 physical switches.

These seem to be common things that people don't understand:

  • The IP's that you give to ifgroups do not need to be dedicated to that ifgroup.
  • The IP that you setup DDboost against needs to be resilient in it's own right or it's loss will break the ifgroup.
    • For this setup a simple failover Veth port for the first IP that you're configuring against (again, no need to get a network guy in for this) - this is tough when you're aiming for 10Gbe sometimes but still potentially faster than LACP if you have enough 10Gbe ports anyway.

So, hopefully nobody shoots me down for the last comment but that I believe is correct but happy to debate it if anybody disagrees.

Cheers,

Jonathan

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

January 12th, 2015 12:00

I don't use it (yet), but with ifgroups you assign to each interface.  You then group those into ifgroups.

2 Intern

 • 

236 Posts

January 12th, 2015 12:00

Thank you both of you, Jonathan and dynamox.

I am trying to understand the following: with LACP I configure 2, or 4 ports for example on the switch and on the DD box. Then, I configure a veth0, and assign the IP address to it. So I have the first interface on the DD box. Let's say, I want to use it for backup purposes: I then configure it on the backup server - either as a CIFS target or as an OST device. For example I am using backup exec. So there is only one route for the backup exec server to reach the DD box - via the veth0 IP address which is configured on the LACP link.

With ifgroups, I configure an ifgroup and assign DD physical interfaces to it. Does each of them have to have an IP address configured, or I can assign an IP to the ifgroup, similar to what I did for the LACP config above? I am new to the ifgroups, that is why I am asking, and there is no way I can test it out in the lab, as I do not have one.

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

January 12th, 2015 14:00

You associate it against one IP, but ddboost will do the load balancing across both (the way I understand this in theory is that this is done by ddboost module between source and target).  I can see what you mean, previous setup would allow failover between two ports/NICs in case of failure, but now since you specify one single IP how would that work.  It is obviously beneficial to create aggregate failover interface and to have that one registered, but such setup usually would disable kill individual IPs for ifgroup so that part is mystery to me as well.

Another vendor in Configuring Advanced Load Balancing and Link Failover - vRanger 6.1 Integration Guide for EMC Data... claims "It is not mandatory to have one of the interfaces in the ifgroup registered with . An interface that is not part of the ifgroup can also be used to register with ."  From that point, I can see benefit for quad cards/ports, but if you have two then you put those in aggregate and there is nothing more you can do with ifgroup as you would have that single aggregate in ifgroup so I'm lost there as well.  Perhaps someone else who did this before with similar setup can explain it better.

2 Intern

 • 

236 Posts

January 12th, 2015 14:00

OK. So let's say, on DD2500, where I have 2 x 10GBE and 4 x 1GBE on-board ports, I can have the following configuration:

ifgroup0 - production backups traffic - 2 x 10GBE interfaces with the following IPs, for example, 10.0.0.100 and 10.0.0.101

ifgroup1 - replication traffic - 4 x 1GBE interfaces with the following IPs: 10.0.0.102, 10.0.0.103, 10.0.0.104, 10.0.0.105.

When I am configuring my Backup exec server to access either a CIFS share, or a Storage Unit, which production backup IP interface do I specify on the backup server: 10.0.0.100 or 10.0.0.101? Or I may configure a DNS entry, let's call it dd2500.domain.com, associated with both: 10.0.0.100 and 10.0.0.101 (I do not think I can associate two IP addresses to a single A record though), and use the name to connect to the DD CIFS share or storage unit, and the DDBOOST software will distribute the traffic accross both links? I do not quite understand how that will work, and how will the backup traffic be load balanced across both links.

208 Posts

January 13th, 2015 01:00

OK, so your DD is perfect for an illustration of what I personally believe works best.

Your DD2500 has 4x 1Gbe onboard ports and 2x 10BaseT onboard ports (these can be used as 1Gbe also (RJ45 sockets)).

Lets stick with 4 in the discussion for now.

So, you have 4x 1gbe and 2x 10Gbe (optical or copper/twinax).

I would assign an IP address to each 10Gbe port and place them into an ifgroup.

Then you can either bond 2x 1gbe into either failover (will give you about ~80mb/s with TCP overhead) or you can put them into an LACP group (will give you a little less than double the failover speed - due to some LACP overhead to add).

Then configure backups against this IP/hostname (1gbe ports), then you have redundancy if a port fails - if you go down the LACP route, make sure you understand whether VPc is supported on the switches when you connect the interfaces to 2 different network switches - or only one port is likely to ever be used(!).

I would personally put the "default" gateway against this interface, it's more simple that way.

When DDboost backups are started they will discuss the backup over the 1gbe interface and then establish that ifgroups are in place and the traffic will be balanced by DDBoost software over these 2 interfaces but without the overhead of LACP.

Without the failover interface, you would configure against one of the 10Gbe interfaces (which is in an ifgroup) and if it is specifically lost, so too is your path to start the backup and your backs will fail.

In this other way (using a bonded 1gbe interface), the loss of a single 10Gbe port (from your ifgroup) would simply half your potential DDBoost backup speed to 10Gbe (minus TCP, latency, link quality, distance etc..).

For your replication, it is much more simple to setup another LACP or failover port on the remaining 2 ports and then assign that an IP address, assuming it does need to be in a seperate subnet from management.

If it doesn't just put all 4 into an LACP group with 1x IP and use it for management and replication - this is really simple to configure if your network is built that way, one gateway, no specific routes, one hostname etc....

Like I said before, the 10Gbe IP's are not dedicated to the ifgroup, they can be used for other work but DDBoost will have the option to use both ports from software (not via a network aggregation config).

I understand why you ask what you've asked, ifgroups are way smarter and more efficient than anyone expects

I think that covers your questions, I hope it helps.

Regards,

Jonathan

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

January 14th, 2015 08:00

It is simple - if you have ifgroups and n number of IPs inside, you can use one on your backup application.  If it fails - it fails until not fixed as there is no failover.  The failover could only exist if application side would be ifgroup aware and you could specify which alternative IPs to try in case one specified is broken.  To my knowledge, no backup application is using such approach.

If you wish to have failover guarantee you must create failover interface on DD (as EMC suggested, not to pay penalty here, you would use slower NIC for it and ifgroup mechanism would made sure those 10GBps are used as well).

What you described with DNS is something I would not even try as it would not work.

This also means that in case of myself, where I have 2x{2x10Gbps} where each pair is one separated network, I would not have any use of ifgroup as I would loose failover capability.

2 Intern

 • 

236 Posts

January 14th, 2015 08:00

Thanks Jonathan.

Your answer is detailed, but still confusing. I was asking about using the ifgroups specifically, without any LACP or failover. I am not interested in configuring and/or using LACP/failover, because I want to bypass any configuration on the switches, and I want to move away from the LACP/failover model for good, if at all possible, because EMC document, that dynamox provided, says:

  • Using ifgroup for DDBoost backups is the best practice as it is proprietary to DataDomain.
  • DDBoost understands the ifgroup better and load balancing and failover happens at the application level unlike LACP so it’s much faster and helps with better performance.
  • There is less overhead in configuring ifgroup compared to LACP. Ifgroup is a end to end connection and LACP is point to point and the connection points in the data path needs to be configured using LACP.
  • In a mixed load environment it’s better to keep the cifs/nfs traffic and DDBoost traffic on two different interfaces. If a customer cannot afford to create multiple interfaces it is ok to use ifgroup interface for CIFS/NFS traffic.
  • Using physical interfaces to be part of ifgroup is the best practice. If customer wants to add an LACP interface to ifgroup it is ok to do that but they need to consider the extra overhead of configuring LACP.

I am going back to my previous post with minor edits:

"Let's say, on DD2500, where I have 2 x 10GBE and 4 x 1GBE on-board ports, I can have the following configuration:

ifgroup0 - production backups traffic - 2 x 10GBE interfaces with the following IPs, for example, 10.0.0.100 and 10.0.0.101

ifgroup1 - replication traffic - 4 x 1GBE interfaces with the following IPs: 10.0.0.102, 10.0.0.103, 10.0.0.104, 10.0.0.105.

When I am configuring my Backup exec server to access either a CIFS share, or a Storage Unit, which production backup IP interface (10GBE) do I specify on the backup server: 10.0.0.100 or 10.0.0.101?

Or do I need to configure a DNS entry, let's call it dd2500.domain.com, associated with both: 10.0.0.100 and 10.0.0.101 (I am not 100% sure if I can associate two IP addresses to a single A record though), and use the name to connect to the DD CIFS share or storage unit via interfaces in ifgroup0, and the DDBOOST software will distribute the traffic accross both links?

How can I tell and be sure that the backup traffic is load balanced across both physical links?

Same questions will apply to replication:

When I am configuring a replication pair, which out of 4 ifgroup1 IPs do I go to: 10.0.0.102, 10.0.0.103, 10.0.0.104, 10.0.0.105?

How can I tell and be sure that the replication traffic is load balanced across all four physical links?"

2 Intern

 • 

236 Posts

January 14th, 2015 09:00

Thank you, Hrvoje.

If I am getting the concept correctly, this is what will happen on ifgroup0 - production backup ifgroup that has 2 x 10GBE links with separate IPs 10.0.0.100 and 10.0.0.101:

  1. When I am configuring my backup server I will use only one IP, fro example 10.0.0.100, to connect to DD CIFS share or Storage Unit.
  2. Since I have DDBOOST license on the DD and DDBOST OST plugin installed on the backup exec server, the backup traffic will utilize both 10GBE links in ifgroup0, theoretically giving me around 20GBE aggregate bandwidth.
  3. If I lose the physical connection that has 10.0.0.100 IP configured on it, I will lose connectivity from BE server to DD, and there will be no backups, until I fix this connection or reconnect using 10.0.0.101.


Am I correct?

208 Posts

January 14th, 2015 10:00

That's correct, that is why I suggest failover configuration on the 1Gbe ports to configure your backups (and DD hostname) against (this configuration does not need to specified on the switch end but is slower than LACP).

Then your ifgroup will run at ~20Gbe across both ports in DDBoost and if one port fails, you just lose it's payload - not your backups.

You can also use the 10Gbe interfaces for non-DDBoost traffic.

Yes, it's preferable to separate them out if you have the HBA's... but if you don't - you can still share them.

By all means try to work with routes and hostnames but it's messy, confusing and unreliable (IMHO).

My suggestions were to give you a larger view of your options and were representative of the EMC best practice guides you show here.

Regards,

Jonathan

208 Posts

January 14th, 2015 10:00

Hi,

No, I'm suggesting 2x 1gbe in failover mode for your backup configuration - for resilience of your backup configuration.

2x 10Gbe ports (individual IP's) in one DDBoost ifgroup.

The failover interface will essentially discuss the DDBoost backup (between backup host and the DD) and then find the ifgroup config and thus direct backup traffic over to that ifgroup - so will balance DDBoost backup data over those 2x 10Gbe interfaces via DDBoost software not via switch bonding.

Failover interface = initiation of DDBoost backup

ifgroup = data traffic for DDBoost (the ifgroup members must be the same interface speeds/type)

Regards,

Jonathan

2 Intern

 • 

236 Posts

January 14th, 2015 10:00

I am not quite following? Are you talking about configuring 2 x 10GBE ports in failover mode, and then adding them to the ifgroup? If so, wouldn't only one of them be active at a time, and one will be standby? In this case I will not be able to get 20 GB of bandwidth. And it does not follow EMC BP for ifgroups, which wants us to use physical interfaces, rather than LACP, or failover interfaces.

2 Intern

 • 

236 Posts

January 14th, 2015 10:00

Is there an EMC DD document that explains and supports what you are saying?

No Events found!

Top