OpenVPN verspreidt multicast naar elke client, niet naar abonnees

"Ondersteunt multicast" beantwoordt een protocolvraag en laat de capaciteitsvraag onaangeroerd. Operationeel belangrijk is hoeveel kopieën de server voor één groepspakket uitzendt en welke tunnels ze dragen. Eén geabonneerde toepassing die de stream ontvangt, bewijst alleen dat levering ergens werkt. Ze bewijst niet dat onbetrokken clients de bandbreedte bespaard bleef.

Drie vragen binnen één functieclaim

Groepslidmaatschap vraagt of de ontvanger zich bij de groep heeft aangesloten. Tunnellevering vraagt of het pakket de tunnel überhaupt heeft gepasseerd. Replicatiebeleid vraagt hoeveel kopieën de server maakte en voor wie. Een leveranciersverklaring kan waar zijn voor het eerste en zwijgen over het derde, en daar zit de kostenpost.

Houd ze gescheiden wanneer u een verbinding dimensioneert. Alleen de derde vraag bepaalt het uitgaande budget aan de serverkant.

Wat de server in gebruikersruimte met een groepspakket doet

In de traditionele server in gebruikersruimte van OpenVPN 2.6 wordt een aankomend broadcast- of multicastpakket in het TUN/TAP-invoerpad geclassificeerd en aan de broadcast-uitwaaieringsroutine overhandigd in plaats van aan een zoekopdracht per groep. Die routine loopt langs de clientinstanties, slaat de afzender en elke gestopte instantie over, past de VLAN-controle toe waar er een is geconfigureerd, en zet een kopie in de wachtrij voor elke resterende client. Geen enkele stap in die lus raadpleegt een lidmaatschapstabel. Dat is replicatie in broadcaststijl, en dat is het hele mechanisme.

Beschouw dit als een eigenschap van dat codepad, niet als een universele wet. Versnelde datapaden, andere implementaties en verschillende versies kunnen zich anders gedragen, en niets hiervan maakt TAP een vereiste of een reparatie.

Begroot de kopieën voordat u iets meet

Neem de payloadsnelheid en vermenigvuldig die met het aantal geschikte clients. Een stream die één megabit per seconde naar twintig clients stuurt, produceert twintig megabit per seconde payload die de server verlaat, vóór inkapseling, herverzending en enige overhead per client. Die rekenkunde is een budget, geen meting van uw uitrol.

ip -s link show tun0

Lees de teller van verzonden bytes voor en na een vast interval met één bekende actieve afzender. Deel door het interval en vergelijk met de payloadsnelheid vermenigvuldigd met het aantal clients. Een getal dicht bij de snelheid van één stream betekent dat de replicatie beperkt is; een getal dicht bij de vermenigvuldigde snelheid betekent dat elke client een kopie ontvangt.

De teller omvat ook uw eigen tunnelverkeer, dus houd het testvenster kort en de host verder stil. Precisie is minder belangrijk dan de orde van grootte, en dat is alles wat u nodig hebt om één kopie van twintig te onderscheiden.

Een test met twee clients die de omvangsvraag beslecht

Verbind één client die de stream zou moeten ontvangen en een tweede die dat niet zou moeten. Start de afzender en kijk vervolgens naar de tunneltellers van de tweede client over hetzelfde interval. Groei bij de tweede client is direct bewijs van brede replicatie, wat de functielijst ook zei.

Filter de opname op het groepsadres zodat u geen ongerelateerd verkeer leest, en beperk haar tot de tunnelinterface. Het opnemen van de fysieke interface op een drukke host levert een bestand op dat niemand kan interpreteren en kan gebruikersgegevens bewaren die u niet wilde verzamelen.

Draai dan de rollen om. Als het resultaat de ontvanger volgt in plaats van de groep, kijkt u naar iets dat lidmaatschap kent, en de eerdere aanname was onjuist in uw voordeel.

Een beperkt ontwerp kiezen in plaats van grenzen weghalen

Wanneer de uitwaaiering te breed is, is de oplossing een ondersteunde beperkte distributieopstelling, niet het verwijderen van elke controle die u hebt. Opties zijn het distributiepunt dichter bij de ontvangers brengen, een bronspecifiek abonnementsmodel gebruiken dat de bronidentiteit samen met de groep draagt, of de stream splitsen zodat onbetrokken locaties nooit op dezelfde distributiegrens zitten.

Houd de identiteit van bron en groep gescheiden van het kale feit dat een bestemming multicast is. Een ontvanger die de groep herkent maar niet de bron, is een andere abonnee dan een die een specifiek kanaal aanvroeg. Beide vermengen maakt latere capaciteitsplanning giswerk.

Het bronspecifieke multicastkanaalmodel is de referentie voor dat onderscheid. Welk ontwerp u ook kiest, noteer de set geschikte peers, de replicatie-eigenaar en de teller die u de volgende keer leest; dat verslag is wat een bandbreedteverrassing in bekende kosten verandert.