Data Domain Boost Interface Groups – Was können sie? Wie konfiguriere ich sie?

Dell EMC empfiehlt eindeutig die Verwendung von Data Domain Boost Interface Groups (DDboost ifgroups).
Jeder, der sich einmal die DDbbost Einstellungen angesehen hat, wird wohl schon mal darüber gestolpert sein.
Doch wofür sind die eigentlich genau da, was können sie und was nicht? Und was muss man dabei beachten?
Primär ist eine ifgroup für Load Balancing gedacht und stellt somit erst einmal eine Alternative zum klassischen LACP (oder Aggregate oder Bonding, je nachdem wie man es nennen möchte) dar, bei dem zwei oder mehr Netzwerkinterfaces logisch zu einem zusammengefasst werden.
Beim LACP hat dieses logische Interface eine IP-Adresse. Man kann natürlich durch VLANs weitere IPs darauf legen, aber das soll nicht Bestandteil dieses Beitrags sein.
Je nach Konfiguration des LACP hat man entweder den klassischen Failover (Interface A geht kaputt, stattdessen wird dann automatisch Interface B genutzt) oder auch zusätzlich die Möglichkeit des Load Balancings. Damit hat man also den Failover und, sofern noch mehr als ein Interface aktiv ist, werden die Daten auch über beide übertragen.
Baut man das LACP dann auch noch so, dass die Interfaces auf verschiedenen Netzwerkkarten liegen und auch noch an unterschiedliche Switches gehen, hat man so also eine relativ große Wahrscheinlichkeit, dass die Data Domain trotz mehrerer Hardware-Ausfälle im Rechenzentrum immer noch erreichbar ist.

Mittels dieser Konfiguration können wir einen Port-Ausfall, einen Netzwerkkarten-Ausfall und einen Switch-Ausfall kompensieren.

Jetzt mag man sich fragen: LACP ist doch super, was soll ich mit DDboost ifgroups?

Die Frage ist nicht ganz unberechtigt. Es gibt einen KB-Artikel bei Dell EMC, welcher als Entscheidungsmatrix dient, wann man LACP und wann man DDBOOST ifgroups nutzen sollte: https://support.emc.com/kb/182246

Um es einfach zu machen: LACP benötigt einen gewissen Performance-Overhead und erfordert mehr Konfigurationsaufwand auf dem Switch. Die ifgroups benötigen keine besondere Konfiguration auf dem Switch und der Overhead durch LACP entfällt. Laut Dell EMC bekommt man bei ifgroups bis zu 60% mehr Datendurchsatz im Vergleich zu LACP (siehe Seiten 4 & 8 hier). Zudem hat man mit ifgroups die Möglichkeit, Netzwerkinterfaces mit unterschiedlichen Geschwindigkeiten (oder Typen) zu vermischen, was bei LACP nicht möglich ist. So könnte man z.B. 10GBit optisch und 10GBit Kupfer in eine ifgroup packen.
Hat man eine DD3300 im Einsatz, kann man zudem gar kein LACP konfigurieren, außer man hat DDOS 6.2, aber selbst dort gibt es dann nur den LACP-Failover (siehe https://support.emc.com/kb/518492).

Wann sollte man jetzt ifgroups statt LACP nutzen?

Die Antwort darauf ist eigentlich einfach: Unterstützt die Applikation auf der anderen Seite DDboost, sind ifgroups das Mittel der Wahl.
Wenn da nicht ein “eigentlich” wäre… ifgroups sind primär für Backups gedacht und erfüllen ihren Zweck dabei gut.
Bei Replikation und Cloning auf nicht DDboost-Devices jedoch ziehen sie nicht. Klont man viel auf Tape oder auf AFTD, werden ifgroups nicht genutzt, was zur Folge hat, dass man dann vielleicht ein Interface der Data Domain hat, welches viel Daten transferiert und anderes, welches nichts macht.
Nutzt man die Data Domain auch noch für andere Dinge (z.B. NFS oder CIFS-Shares), werden die ifgroups ebenfalls nicht genutzt.
Diese sind rein für das DDboost Protokoll da.
Zudem bietet eine reine ifgroup-Konfiguration nur einen Failover über zwei Interfaces. Für Load Balancing jedoch können beliebig viele genutzt werden.
Eine ausführliche und wirklich lesenswert Beschreibung zu den ifgroups gibt es hier.

Wenn man dies jetzt liest, könnte man fast sagen, dass LACP eigentlich besser ist, weil man die oben genannten Einschränkungen nicht hat.
Die ifgroups sind jedoch bereits in der DDboost API eingebaut, welche von Backup-Applikationen wie NetWorker oder Veeam genutzt wird. Bei DDboost fällt der LACP-Overhead weg und es bietet ein besseres Load Balancing, da dies auf Stream-Ebene erfolgt und so für jeden einzelnen Backup-Stream geschaut wird, welches Interface gerade weniger zu tun hat.

LACP und ifgroups schließen sich jedoch nicht aus! Eine Kombination aus beidem ist ebenfalls möglich und macht je nach Umgebung Sinn.
Daher gilt hier: Bevor man die Netzwerkkonfiguration fertig stellt, sollte man sich auf jeden Fall Gedanken dazu machen, was man genau mit der Data Domain machen möchte. Ich habe schon Unternehmen gesehen, welche ihre DD als CIFS-Storage für die Home-Laufwerke ihrer Mitarbeiter nutzen.
Als es für NetWorker noch kein SAP HANA Modul gab, haben wir uns auch damit beholfen, dass die HANA ihre Logs auf einen NFS-Share der Data Domain schreibt und ich habe auch schon ein Enterprise Vault (E-Mail-Archivsystem) gebaut, welches seine Daten auf der Data Domain speichert, weil die Data Domains relativ leer waren und man daher keine (ggf. besser geeigneten oder günstigeren) Storage Systeme dafür anschaffen wollte.

Whew, viel Text.
Wenn man sich letztendlich für die Nutzung von ifgroups entscheidet… Was muss ich jetzt eigentlich machen?

In unserem am Anfang genannten Beispiel (Data Domain mit zwei Netzwerkinterfaces ohne VLAN) nicht viel. Mit VLANs wird es allerdings auch nicht viel komplizierter, denn bei den ifgroups trägt man nur IPs ein, keine Interfaces. Ob sich hinter der IP ein VLAN, ein LACP oder ein normales Interface verbirgt, ist der ifgroup egal. In meinem Beispiel habe ich den physikalischen Interfaces der DD jeweils eine IP zugeordnet, so dass meine DD zwei IPs hat.

Wichtig hierbei:
Die beiden IPs müssen natürlich auch einen DNS-Eintrag bekommen, welcher selbstverständlich vorwärts und rückwärts aufgelöst werden kann! Die erste IP kann man vom Prinzip her benennen wie man möchte (z.B. dd1.meinedomain.de). Die zweite jedoch muss exakt wie die erste heißen, nur mit einem “-failover” hinter dem Namen. Also: dd1-failover.meinedomain.de
Im DDboost Protokoll ist nämlich im Failover-Fall hart verdrahtet (und es lässt sich auch nicht ändern), dass er nach name-failover sucht.
Im NetWorker hat man die Data Domain ja über dd1.meinedomain.de angelegt, also sucht er automatisch nach dd1-failover.meinedomain.de

Dies ist wirklich wichtig! Denn sonst funktioniert der Failover nicht. Das zweite Interface sollte somit im Idealfall natürlich auch auf einer anderen Netzwerkkarte der DD liegen und an einen anderen Switch angebunden sein.
Die beiden IPs müssen sich nicht im gleichen Subnetz befinden. Allerdings müssen beide IPs natürlich von jedem Client aus erreichbar sein. Wenn ein Client nur die IP A erreicht und die IP B nicht, funktionieren weder Load Balancing, noch Failover. Im Idealfall befindet sich beide IPs also im gleichen Subnetz und bekommen auch die gleichen Firewall-Regeln zugewiesen.

Von Hause aus gibt es bereits eine default ifgroup, welcher der Client “*” zugeordnet ist. Nutzt man die DD nur für einen Kunden, oder nur für eine Backup Umgebung, ist dies auch vollkommen ausreichend. Hat man jedoch z.B. Backup Server in unterschiedlichen VLANs stehen, muss man hier auch für jedes dieser VLANs eine ifgroup erstellen und ihr die IPs der Interfaces aus dem jeweiligen VLAN zuordnen.
Darüber hinaus muss man natürlich auch die Client-Liste anpassen. “*” bedeutet, dass alle Clients diese ifgroup nutzen. Hier muss man dann die Liste anpassen, so dass in Gruppe 1 nur Clients mit dem Subnetzen von Kunde A sind und in Gruppe 2 die Subnetze von Kunde B.
Beispiel für solch einen Eintrag: 10.100.4.0/24

In meinem Beispiel habe ich die default-Gruppe genutzt, ihr meine beiden IPs zugeordnet und die Client-Liste bei “*” gelassen.

Und das war’s auch schon an Konfigurationsaufwand. Das DDboost Protokoll nutzt nun automatisch die konfigurierte ifgroup für sämtliche Backups.

Man kann natürlich auch mehr als zwei IPs in eine ifgroup packen. Das Load Balancing erstreckt sich automatisch über alle IPs in der Gruppe.
Allerdings (wie bereits oben schon erwähnt) gibt es den Failover nur für zwei IPs, dämlich dd1 und dd1-failover.
Die restlichen IPs benötigen keinen DNS-Eintrag, da die weitere Kommunikation über IP-Adressen und nicht über Namen abgehandelt wird.