Site icon bintorosoft.com

Kapazitätsplanung: Wachstumsmodelle und Headroom-Strategien

Red Snapper

Kapazitätsplanung ist in Telco- und Provider-Netzen der Unterschied zwischen stabiler Servicequalität und wiederkehrenden Krisenprojekten. Während Topologie und Routing oft „richtig“ aussehen, scheitern viele Netze an einer simplen Realität: Traffic wächst nicht linear, er ist spiky, regional unterschiedlich, stark von Content-Events abhängig und im Störfall muss das Netz N-1 weiter funktionieren. Ohne systematische Wachstumsmodelle und klare Headroom-Strategien passiert typischerweise Folgendes: Links sind im Durchschnitt „nur“ zu 40% ausgelastet, aber in Peak-Minuten droppen Queues; ein IXP-Port ist im Normalbetrieb ok, aber beim Transit-Failover kollabiert er; ein BNG/CGNAT ist throughputseitig entspannt, aber CPS/Sessions und Logging-Pipeline laufen in Peaks an die Wand. Professionelle Kapazitätsplanung betrachtet daher nicht nur Bandbreite, sondern die gesamte Servicekette: Access->Metro->Core->Edge, inklusive Interconnect, Service Chains (CGNAT, Firewalls, DDoS) und Control Plane (BGP/IGP, Session-State). Der Kern ist ein wiederholbarer Prozess: messen, modellieren, Trigger definieren, rechtzeitig investieren – und dabei Headroom so zu planen, dass Wartungen und Störungen ohne SLA-Bruch überstanden werden. Dieser Artikel zeigt praxisnah, wie Sie Wachstumsmodelle aufbauen, welche Headroom-Strategien sich bewährt haben und wie Sie Upgrade-Entscheidungen mit Telemetry und SLOs belastbar machen.

Warum Kapazitätsplanung in Telco-Netzen schwierig ist

Kapazität ist mehr als „Gigabit“. Provider-Netze haben viele Engpassarten, die sich gegenseitig beeinflussen. Außerdem ist Traffic nicht gleichmäßig: Abendspitzen, Sports-Streams, Spiele-Updates, Cloud-Backups und DDoS-Ereignisse erzeugen Peaks, die in Durchschnittsmetriken verschwinden. Und weil Netze redundant sind, muss Kapazität auch im Ausfallfall reichen.

Leitprinzip: Kapazität ist ein End-to-End Budget

Sie planen nicht nur Links, sondern Servicepfade. Ein Upgrade am Core hilft wenig, wenn der Engpass am IXP-Port oder im BNG-Queueing liegt.

Die Kapazitätsdimensionen: Throughput, PPS, CPS, State und Speicher

Ein belastbares Modell betrachtet mehrere Achsen. Bandbreite (Throughput) ist sichtbar und wird deshalb oft überbetont. In der Praxis limitieren häufig andere Größen: Pakete pro Sekunde (PPS), neue Verbindungen pro Sekunde (CPS), Tabellen-/State-Limits (Sessions, NAT, BGP/EVPN), sowie Speicher/Collector-Kapazität für Telemetry und Logging.

Ein vereinfachtes Engpassmodell

Service_Capacity=min( Throughput, PPS, CPS, State, Queue_Budget, Telemetry_Pipeline )

Die kleinste Achse entscheidet. Deshalb muss Kapazitätsplanung multidimensional sein.

Messgrundlage: Welche Telemetry Sie für Kapazitätsplanung brauchen

Gute Modelle beruhen auf guten Daten. In Telco-Topologien sollten Sie nicht nur 5-Minuten-Interface-Averages speichern, sondern auch Peaks, Queue-Drops, Member-Visibility bei LAG/ECMP und Service-spezifische KPIs. Wichtig ist außerdem: Daten müssen topologisch labelbar sein (Region, PoP, Linkklasse, Serviceklasse), sonst sind Forecasts schwer nutzbar.

Designregel: Messen an Choke Points

Kapazitätsplanung braucht höchste Granularität dort, wo Engpässe real sind: Interconnect-Ports, DCI-Links, Hub-Uplinks, BNG/CGNAT-Edges. Im Core reichen oft Trends.

Wachstumsmodelle: Linear, exponentiell, stufenweise und eventgetrieben

Trafficwachstum ist nicht immer linear. In Telco-Realität gibt es mehrere Muster, die je nach Region, Produkt und Partner unterschiedlich auftreten. Ein gutes Modell erkennt diese Muster und verwendet passende Forecast-Methoden statt „eine Gerade durch alles“.

Praktischer Ansatz: Trend + Saison + Peak-Faktor

Viele Betreiber modellieren Wachstum als Kombination aus langfristigem Trend, saisonalen Mustern (Wochentag/Abendspitze) und einem Peak-Faktor für Events. Das ist oft realistischer als komplexe Statistik ohne Topologiekontext.

Forecasting pro Topologieebene: Access, Metro, Core, Edge

Kapazitätsplanung muss hierarchisch sein, weil Engpässe je Ebene anders entstehen. Access skaliert mit Anschlüssen und Oversubscription, Metro mit Aggregationspunkten, Core mit regionaler Lastverteilung und Edge mit Interconnect-Partnern und Internet-Exit-Strategien.

Designregel: Edge-Kapazität folgt Traffic-Mix, nicht nur Gesamttraffic

Ein neuer PNI kann Transit drastisch senken, ein IXP-Fabric-Problem kann Transit kurzzeitig erhöhen. Edge-Forecasts sollten deshalb immer die Verteilung PNI/IXP/Transit modellieren.

Headroom-Strategien: N-1, N-2 und „Failure-Aware Capacity“

Headroom ist die bewusst eingeplante Reserve, damit ein Service trotz Ausfall oder Wartung weiter funktioniert. In Telco-Netzen ist Headroom kein Luxus, sondern Voraussetzung für planbare Wartung, stabile Failoverpfade und SLO-Einhaltung. Die Frage ist nicht „ob“, sondern „wie viel und wo“.

Headroom ist ein SLO-Parameter

Wenn Ihr SLO Latenz/Loss in Peakzeiten fordert, müssen Sie Headroom auf Engpässen so planen, dass Queue-Drops im N-1 nicht regelmäßig auftreten.

Kapazitätsplanung an Engpässen: Interconnect, DCI, Hub-Uplinks

Die meisten spürbaren Incidents entstehen an wenigen Stellen. Deshalb lohnt es sich, für diese Zonen klare Port- und Upgrade-Strategien zu definieren: Portklassen, Schwellenwerte, Upgrade-Trigger und Failover-Simulationen. Besonders wichtig sind Interconnects (IXP/PNI/Transit), DCI-Links und Hub-Uplinks in Metro-Aggregationen.

Ein praktischer Upgrade-Trigger

Wenn ein Engpass regelmäßig Queue-Drops in priorisierten Klassen zeigt oder p99-Latenz in einer Region ansteigt, ist das oft ein stärkerer Trigger als „80% durchschnittliche Auslastung“.

Servicekapazität: BNG, CGNAT, Firewalls und Logging-Pipelines

In modernen Netzen sind viele Engpässe stateful. BNG/BRAS skaliert über Sessions, CGNAT über State/CPS/Port-Pools, Firewalls über PPS/Session-Table, und Logging/Telemetry über ingest/speicher. Kapazitätsplanung muss diese Plattformen genauso behandeln wie Links – mit Headroom, N-1 und Upgrade-Triggern.

Designregel: Plattformen brauchen eigene SLOs

Wenn CGNAT-Logging backpressured, oder BNG bei Churn kollabiert, ist das ein Kapazitätsproblem – auch wenn die Links „grün“ sind. Definieren Sie Plattform-SLOs und Upgradetrigger.

Konservativ vs. effizient: Headroom durch QoS und Traffic-Klassen

Headroom lässt sich nicht nur durch „mehr Bandbreite“ erreichen. Ein gängiger Ansatz ist serviceklassenbasierte Planung: Kritische Klassen (Voice, Timing, Control, Enterprise) werden im N-1 geschützt, Bulk-Traffic darf degradiert werden. Das senkt Kosten, muss aber transparent geplant und getestet sein.

Anti-Pattern: QoS als Ersatz für fehlende Kapazität

QoS kann Headroom effizienter nutzen, aber keine dauerhaft fehlende Kapazität kompensieren. Wenn Bulk dauerhaft die Prioritätsklassen verdrängt, braucht es Upgrades, nicht nur neue Queue-Profile.

Upgrade-Entscheidungen: Trigger, Lead Times und „Time to Exhaust“

Kapazitätsplanung wird operativ, wenn sie in klare Trigger übersetzt wird. Dazu gehört die Prognose: Wann erreicht ein Link/Cluster die Grenze? Und wie lange dauert ein Upgrade (Lead Time)? Die Differenz ist Ihr Handlungsspielraum. Ohne diese Logik entstehen Notfall-Upgrades.

Eine einfache Entscheidungsformel

Decision= (TimeToExhaust<LeadTime+SafetyMargin)

Wenn Sie voraussichtlich vor Abschluss der Maßnahme an die Grenze laufen, ist es bereits zu spät. Safety Margin ist besonders wichtig in spiky Umgebungen.

Kapazitätsplanung und Policy: Traffic kann durch Regeln „wachsen“

Ein häufiger Überraschungseffekt ist policybedingtes Wachstum: Peering-Änderungen, Traffic Engineering, neue Communities oder veränderte Inbound-Steuerung verschieben Traffic. Die Kapazitätsplanung muss daher Policy-Änderungen als Kapazitätsereignisse betrachten – mit Vorher/Nachher-Messung und Rollback-Regeln.

Designregel: Jede Policy-Änderung braucht Kapazitäts-Checks

Vor dem Rollout sollten Sie simulieren oder zumindest messen, welche Links/Ports stärker belastet werden. Nach dem Rollout sind Vorher/Nachher-Vergleiche Pflicht.

Typische Fehlerbilder und wie man sie vermeidet

Praktische Leitlinien: Wachstumsmodelle und Headroom-Strategien

Exit mobile version