OpenVPN verteilt Multicast an jeden Client, nicht an Abonnenten

"Unterstützt Multicast" beantwortet eine Protokollfrage und lässt die Kapazitätsfrage unberührt. Operativ zählt, wie viele Kopien der Server für ein Gruppenpaket aussendet und welche Tunnel sie tragen. Eine abonnierte Anwendung, die den Strom empfängt, belegt nur, dass die Zustellung irgendwo funktioniert. Sie belegt nicht, dass unbeteiligten Clients die Bandbreite erspart blieb.

Drei Fragen innerhalb einer Funktionsaussage

Die Gruppenmitgliedschaft fragt, ob der Empfänger der Gruppe beigetreten ist. Die Tunnelzustellung fragt, ob das Paket den Tunnel überhaupt passiert hat. Die Replikationspolitik fragt, wie viele Kopien der Server erzeugt hat und an wen. Eine Herstelleraussage kann für das erste wahr und zum dritten schweigen, und dort sitzt der Aufwand.

Halten Sie sie getrennt, wenn Sie eine Leitung dimensionieren. Nur die dritte Frage setzt das Ausgangsbudget auf der Serverseite.

Was der Userspace-Server mit einem Gruppenpaket tut

Im traditionellen Userspace-Server von OpenVPN 2.6 wird ein ankommendes Broadcast- oder Multicast-Paket im TUN/TAP-Eingangspfad klassifiziert und an die Broadcast-Fan-out-Routine übergeben statt an eine gruppenweise Suche. Diese Routine läuft über die Client-Instanzen, überspringt den Absender und jede angehaltene Instanz, wendet ihre VLAN-Prüfung an, wo eine konfiguriert ist, und stellt eine Kopie für jeden verbleibenden Client in die Warteschlange. Kein Schritt in dieser Schleife befragt eine Mitgliedschaftstabelle. Das ist Replikation im Broadcast-Stil, und das ist der ganze Mechanismus.

Betrachten Sie das als Eigenschaft dieses Codepfads, nicht als allgemeines Gesetz. Beschleunigte Datenpfade, andere Implementierungen und verschiedene Versionen können sich anders verhalten, und nichts davon macht TAP zur Voraussetzung oder zur Reparatur.

Kalkulieren Sie die Kopien, bevor Sie etwas messen

Nehmen Sie die Nutzlastrate und multiplizieren Sie sie mit der Zahl der geeigneten Clients. Ein Strom, der ein Megabit pro Sekunde an zwanzig Clients sendet, erzeugt zwanzig Megabit pro Sekunde Nutzlast, die den Server verlässt, vor Kapselung, Weitersendung und jeglichem Aufwand pro Client. Diese Arithmetik ist ein Budget, keine Messung Ihrer Bereitstellung.

ip -s link show tun0

Lesen Sie den Sende-Bytezähler vor und nach einem festen Intervall mit einem bekannten aktiven Absender. Teilen Sie durch das Intervall und vergleichen Sie mit der Nutzlastrate mal Clientzahl. Ein Wert nahe der Einzelstromrate bedeutet, dass die Replikation begrenzt ist; ein Wert nahe der multiplizierten Rate bedeutet, dass jeder Client eine Kopie erhält.

Der Zähler enthält auch Ihren eigenen Tunnelverkehr, halten Sie das Testfenster daher kurz und den Host sonst ruhig. Genauigkeit zählt weniger als die Größenordnung, und mehr brauchen Sie nicht, um eine Kopie von zwanzig zu unterscheiden.

Ein Zwei-Client-Test, der die Umfangsfrage klärt

Verbinden Sie einen Client, der den Strom empfangen soll, und einen zweiten, der es nicht soll. Starten Sie den Absender und beobachten Sie dann die Tunnelzähler des zweiten Clients über dasselbe Intervall. Wachstum beim zweiten Client ist der direkte Beleg für eine breite Replikation, was auch immer die Funktionsliste sagte.

Filtern Sie die Aufzeichnung auf die Gruppenadresse, damit Sie keinen fremden Verkehr lesen, und beschränken Sie sie auf die Tunnelschnittstelle. Das Aufzeichnen der physischen Schnittstelle auf einem ausgelasteten Host erzeugt eine Datei, die niemand auswerten kann, und kann Nutzerdaten behalten, die Sie nicht sammeln wollten.

Drehen Sie dann die Rollen um. Folgt das Ergebnis dem Empfänger statt der Gruppe, sehen Sie etwas Mitgliedschaftsbewusstes, und die frühere Annahme war zu Ihren Gunsten falsch.

Ein begrenztes Design wählen, statt Grenzen zu entfernen

Ist die Verteilung zu breit, ist die Lösung eine unterstützte begrenzte Verteilungsanordnung und nicht das Löschen jeder Kontrolle, die Sie haben. Optionen sind, den Verteilungspunkt näher an die Empfänger zu rücken, ein quellenspezifisches Abonnementmodell zu verwenden, das die Quellenidentität ebenso wie die Gruppe trägt, oder den Strom aufzuteilen, sodass unbeteiligte Standorte nie auf derselben Verteilungsgrenze sitzen.

Halten Sie Quellen- und Gruppenidentität getrennt von der bloßen Tatsache, dass ein Ziel Multicast ist. Ein Empfänger, der die Gruppe, aber nicht die Quelle erkennt, ist ein anderer Abonnent als einer, der einen bestimmten Kanal angefordert hat. Beides zu vermischen macht die spätere Kapazitätsplanung zum Raten.

Das quellenspezifische Multicast-Kanalmodell ist die Referenz für diese Unterscheidung. Welches Design Sie auch wählen, schreiben Sie die geeignete Peer-Menge, den Replikationsverantwortlichen und den Zähler auf, den Sie nächstes Mal lesen werden; dieser Eintrag verwandelt eine Bandbreitenüberraschung in bekannte Kosten.