Network Partition in Microservices: Theorie mit echten Incidents verbinden

Eine Network Partition in Microservices ist eine der unangenehmsten Störungsarten im Betrieb verteilter Systeme: Die Systeme laufen weiter, aber sie sehen sich gegenseitig nur noch teilweise oder gar nicht mehr. Das Ergebnis sind Fehlerbilder, die sich wie „sporadische Bugs“ anfühlen – Timeouts hier, erhöhte Latenz dort, unerklärliche Retries, plötzliches Wiederauftreten nach Minuten – und doch ist die Ursache rein netzwerk- bzw. verteiltsystembedingt. In modernen Cloud- und Kubernetes-Umgebungen ist eine Network Partition nicht nur „Kabel gezogen“, sondern häufig ein Zusammenspiel aus Routing-Änderungen, Firewall-/Policy-Regeln, überlasteten NAT- oder Load-Balancer-Komponenten, MTU/PMTUD-Problemen oder Kontrollplane-Störungen. Für DevOps- und SRE-Teams ist entscheidend, Theorie und Praxis zu verbinden: Welche Partition-Typen gibt es? Welche Architekturentscheidungen verschlimmern den Blast Radius? Und wie sehen echte Incidents aus, in denen Partitionen oder partition-ähnliche Zustände die eigentliche Wurzel sind? Dieser Artikel verbindet die Grundlagen (CAP, Quorum, Failure Modes) mit typischen Produktionsmustern, damit Sie Partitionen schneller erkennen, sauber eindämmen und vor allem: so designen, dass sie nicht in Kaskaden eskalieren.

Was „Network Partition“ im Microservice-Alltag wirklich bedeutet

Streng genommen ist eine Network Partition eine Aufteilung des Netzwerks in mindestens zwei Teilmengen (Partitions), die untereinander nicht oder nur eingeschränkt kommunizieren können. Wichtig ist: Eine Partition ist nicht zwangsläufig „alles down“. Häufig ist sie partiell, asymmetrisch oder zeitweise. In Microservices bedeutet das typischerweise:

• Service A erreicht Service B nicht, aber Service C erreicht Service B weiterhin.
• Nur ein Teil der Instanzen eines Services ist erreichbar (z. B. nur eine Zone, nur ein Subnetz, nur ein Node-Pool).
• Asymmetrie: Request geht durch, Response nicht (oder umgekehrt), oft durch stateful Middleboxes, NAT oder Routing.
• Kontrollplane vs. Datenebene: Die Datenebene kann funktionieren, während Service Discovery, Load Balancer oder das Control Plane-API „partitioniert“ wirkt.

Damit unterscheidet sich eine Partition von einem sauberen Crash: Bei einem Crash ist ein Knoten weg. Bei einer Partition sind Knoten da – aber sie können falsche Annahmen über den Zustand anderer Knoten treffen, was in verteilten Systemen deutlich gefährlicher ist.

Die Theorie, die Sie im Betrieb wirklich brauchen

Viele Theoriemodelle werden im Alltag zu abstrakt gelehrt. Für SRE-/DevOps-Praxis reichen wenige, aber konsequent angewandte Konzepte.

CAP ist kein Meme, sondern eine Betriebshaltung

Das CAP-Theorem wird oft missverstanden. Im Incident hilft eine pragmatische Lesart: Wenn es eine Partition gibt, müssen Sie sich entscheiden, ob Ihr System eher verfügbar bleibt (Antworten liefern, ggf. mit veralteten/inkonsistenten Daten) oder eher konsistent bleibt (Antworten verweigern, um falsche Zustände zu verhindern). Die Entscheidung ist selten global, sondern pro Daten- oder Funktionsdomäne unterschiedlich. Eine gute Einführung in Partitionen und ihre Effekte liefert die Jepsen-Reihe, z. B. „On the perils of network partitions“.

Quorum und Mehrheitslogik: Warum „halbe Erreichbarkeit“ oft „kein Fortschritt“ ist

Viele Systeme (z. B. Konsens-/Locking- und Coordination-Systeme) arbeiten nur dann korrekt, wenn eine Mehrheit der Mitglieder miteinander kommunizieren kann. Sobald eine Partition die Mehrheit trennt, stoppt ein Teil der Funktion absichtlich – und genau das ist gewollt, um Split-Brain zu verhindern. Ein greifbares Beispiel ist etcd: Bei einer Partition bleibt die Mehrheitsseite verfügbar, die Minderheitsseite wird unbrauchbar. Das ist in der Betriebsdokumentation klar beschrieben: etcd Failure modes – Network partition.

Warum Microservices Partitionen „verschlimmern“ können

Microservices erhöhen die Anzahl der Netzwerkgrenzen: mehr Hop-by-Hop-Kommunikation, mehr Service Discovery, mehr Sidecars/Proxies, mehr Policies. Dadurch steigt die Wahrscheinlichkeit, dass eine Störung irgendwo als Partition wahrgenommen wird – und gleichzeitig wächst das Risiko von Kaskaden.

• Retry-Stürme: Wenn Clients bei Timeouts aggressiv retryn, vervielfacht sich Last genau in der Störung.
• Queueing und Backpressure: Blockierte Downstreams führen zu Thread-Pool-Erschöpfung, Connection-Pool-Exhaustion und schließlich Total-Ausfällen.
• Synchroner Fan-out: Ein Request ruft viele Services parallel auf. Fällt einer partiell aus, steigt Tail Latency, bis auch „gesunde“ Pfade kollabieren.
• Shared Dependencies: Zentraler DNS/Service Mesh Control Plane/Config Store wird zum Single Point of Partition.

Partition-Typen, die in echten Incidents immer wieder auftauchen

Im Betrieb ist es hilfreich, Partitionen nicht als „ja/nein“, sondern als Muster zu klassifizieren. Das beschleunigt Triage und Runbook-Entscheidungen.

Zonen- oder Subnetz-Partition

Ein Teil der Workloads (z. B. eine Availability Zone, ein Node-Pool, ein Subnetz) verliert die Verbindung zu bestimmten Zielen: Datenbanken, Message Broker, Control Plane oder zu anderen Zonen. Symptome:

• Fehler konzentrieren sich auf eine Zone/Node-Gruppe
• Load Balancer verteilt weiter, aber ein Anteil der Requests timeouts
• Health Checks sind inkonsistent (einige grün, einige rot)

Control-Plane-Partition

Die Datenebene (bestehende Verbindungen) kann noch funktionieren, während Steuerung und Discovery ausfallen: API-Server nicht erreichbar, Sidecars bekommen keine Updates, neue Pods können keine Endpoints finden. Das wirkt wie „alles ist langsam“ oder „Deployments hängen“ – obwohl einzelne Services noch antworten.

Asymmetrische Partition

Request-Pakete erreichen das Ziel, aber Responses nehmen einen anderen Pfad und werden gedroppt. Häufige Ursachen sind stateful Firewalls/NAT, Policy-Routing oder unterschiedliche Route Preferences. Im Log sieht man dann oft „SYN gesendet, aber kein SYN-ACK“ oder TLS-Handshakes, die hängen.

Teil-Partition durch Überlast: Netzwerk ist da, aber nicht zuverlässig

Eine Partition kann sich als „grauer Ausfall“ zeigen: Paketverlust, Jitter, Queueing. Gerade bei Microservices führt das zu exponentiellen Effekten durch Timeouts und Retries. Diese Art ist besonders tückisch, weil einfache Ping-Tests manchmal „grün“ sind, während produktionsrelevante Protokolle (TLS/HTTP2/gRPC) scheitern.

Echte Incident-Muster: Wie Partitionen in der Praxis aussehen

„Echte Incidents“ müssen nicht immer als „Network Partition“ betitelt sein. Häufig steht im Postmortem eher „routing issue“, „control plane instability“ oder „connectivity loss“. Für SREs zählt das Muster: partieller Verlust von Erreichbarkeit zwischen Teilmengen.

Beispielmuster: Quorum-Verlust und livelock in Coordination-Systemen

Wenn ein Coordination-System (z. B. etcd, Consul, ZooKeeper) partiell partitioniert wird, kann ein Cluster in einen Zustand geraten, in dem Fortschritt stark eingeschränkt ist oder ausbleibt. In verteilten Systemen ist das oft „by design“, um Konsistenz zu schützen. Gleichzeitig kann es Folgeeffekte auslösen: Kubernetes kann keine Leases erneuern, Controller hängen, neue Pods starten nicht zuverlässig. Die etcd-Dokumentation erklärt, warum die Minderheitsseite unavailable wird und welche Konsequenzen das hat (etcd Failure modes). Für tiefergehende Analyse, wie Konsens-Algorithmen sich unter Teil-Partitionen verhalten, lohnt ein Blick in Forschungsarbeiten zu Raft-Verhalten bei partiellen Netzfehlern, z. B. „Examining Raft’s behaviour during partial network failures“.

Beispielmuster: Globaler Dienst wirkt „teilweise down“ durch Steuerungs- oder Routingfehler

Große Infrastrukturanbieter veröffentlichen Postmortems, in denen interne Routing-/Control-Plane-Probleme dazu führen, dass Dienste für Teile der Nutzer nicht erreichbar sind. Solche Ereignisse verhalten sich aus Kundensicht wie Partitionen: Einige Regionen/Edges erreichen Origins nicht, Dashboards sind weg, APIs schlagen fehl, während andere Pfade weiter funktionieren. Eine Sammlung vieler Postmortems ist hilfreich, um wiederkehrende Muster zu erkennen: A List of Post-mortems. Für Provider-nahe, aktuelle Beispiele sind die Postmortems auf dem Cloudflare Post-Mortem-Tag eine gute Quelle, um typische Kaskaden und interne Abhängigkeitsketten zu studieren.

Beispielmuster: DNS/Service-Discovery-Partition als Auslöser von Kaskaden

In Microservices ist „Discovery“ oft so kritisch wie die Netzwerkpakete selbst. Wenn DNS-Resolver, interne Zonen oder Discovery-Control-Planes partiell ausfallen, entstehen Symptome wie „random connect failures“ oder „nur manche Clients sehen Endpoints“. Besonders gefährlich ist, dass Caches und TTLs das Fehlerbild ungleichmäßig machen: Einige Instanzen cachen funktionierende Antworten, andere nicht. Auch wenn DNS nicht BGP ist, kann das Ergebnis identisch wirken: Eine Teilmenge kann nicht mehr zu einer anderen Teilmenge auflösen – faktisch eine Partition auf Namens-/Discovery-Ebene. Hintergrund zu DNS-Mechanik findet sich in RFC 1035.

Erkennen statt raten: Signale, die auf Network Partition hindeuten

Viele Teams verlieren Zeit, weil sie zu früh „Application Bug“ annehmen. Die folgenden Signale sprechen stark für Partition oder partition-ähnliche Zustände:

• Fehler sind „clustered“ nach Zone, Subnetz, Node-Pool, Region oder spezifischen Client-Gruppen.
• Timeouts dominieren gegenüber sofortigen Fehlern (z. B. kein schneller 5xx, sondern lange Hänger).
• Connect/TLS-Latenz steigt stark, während Server-Processing-Zeit unverändert ist.
• Retry-Rate explodiert und verstärkt Last auf Netzpfad, Proxies oder Downstreams.
• Health Checks widersprechen sich: synthetische Checks sind grün, echte Requests rot (oder umgekehrt).
• Asymmetrie-Indikatoren: SYN-Repeats, Retransmits, RST-Spikes, gRPC „Unavailable“ ohne klaren Serverfehler.

Runbook-Triage: Systematisch eingrenzen, welche Partition vorliegt

Ein gutes Runbook trennt zunächst „Pfad“ von „Service“. Dafür ist eine Latenzzerlegung hilfreich: DNS → TCP Connect → TLS Handshake → Request/Response. Wenn ein Schritt dominiert, ist die Ursache oft außerhalb der Applikation.

Schritt 1: Ist es DNS/Discovery oder Transport?

• Wenn DNS-Auflösung langsam/fehlschlägt: Resolver, private Zonen, TTL, Cache-Hitrate prüfen.
• Wenn TCP Connect hängt: Routing, Firewall/Policy, Security Groups, NACLs, NAT, LB, Port-Exhaustion prüfen.
• Wenn TLS hängt: MTU/PMTUD, Proxy-Interaktionen, Cipher/Handshake-Path prüfen.

Schritt 2: Ist es zonal, regional oder service-spezifisch?

• Dashboards/Logs nach Zone/Region/NodePool aufschlüsseln.
• Fehlerrate getrennt nach Upstream-Dependency (DB, Cache, MQ, Identity, Control Plane).
• Traffic-Muster prüfen: ein Endpoint betroffen oder viele?

Schritt 3: Kaskade stoppen, bevor Sie „perfekt“ verstehen

Bei Partitionen ist Zeit oft gegen Sie, weil Retrys und Queueing die Störung eskalieren. Drei schnelle, risikoarme Hebel sind:

• Retries begrenzen (max attempts, jitter, exponential backoff), besonders bei synchronen Calls.
• Circuit Breaker aktivieren oder Thresholds senken, um Downstreams zu schützen.
• Load Shed (Rate Limits, Priorisierung), damit Kernfunktionen überleben.

Design-Praktiken: Microservices partition-tolerant bauen

Partition-Toleranz ist kein einzelnes Feature, sondern das Zusammenspiel aus Timeouts, Idempotenz, Datenmodell und Degradationsstrategie.

Timeouts und Budgets: Ohne harte Grenzen gibt es kein stabiles System

In Microservices müssen Timeouts bewusst gesetzt werden: pro Hop, pro End-to-End-Request und pro Retries. „Unendlich warten“ ist in Partitionen gleichbedeutend mit Ressourcenleck. Eine praktikable Regel ist: Der Gesamtzeit-Budget eines Requests wird auf Downstream-Calls verteilt (inklusive Retries), sodass ein Teil-Ausfall nicht den gesamten Thread-Pool blockiert.

Idempotenz und sichere Retries

Retries sind nur dann ein Verfügbarkeitsgewinn, wenn sie semantisch sicher sind. Sonst erzeugen sie Doppelbuchungen, doppelte Side Effects und zusätzliche Incidents. Übliche Muster:

• Idempotency Keys für Schreiboperationen
• Outbox Pattern für zuverlässige Events statt direkter synchroner Kopplung
• At-least-once bewusst handeln: deduplizieren, genau-once nicht versprechen, wenn es nicht belegbar ist

Graceful Degradation: Wenn Abhängigkeiten partitionieren, muss das Produkt weiter „sinnvoll“ funktionieren

• Read-only-Fallback statt kompletter Fehler
• Stale Data mit klarer Kennzeichnung statt Timeout
• Feature Toggles zum Abschalten nichtkritischer Pfade
• Bulkheads: Isolation von Ressourcen (Pools) pro Dependency, damit ein Ausfall nicht alles mitreißt

Messbarkeit: Error Budgets getrennt nach Partition-Domänen

Partitionen treffen selten alle Nutzer gleich. Daher sollten SLOs nicht nur global, sondern segmentierbar sein (z. B. nach Region/Zone, nach Upstream, nach Protokollpfad). Ein nützliches Betriebsmaß ist „Burn Rate“: Wie schnell verbrennen wir das Error Budget, wenn ein Teilpfad ausfällt?

$\mathrm{BurnRate}=\frac{1–\mathrm{SLI}}{1–\mathrm{SLO}}$

Wenn Sie Burn Rates pro Segment (z. B. Zone A vs. Zone B) betrachten, erkennen Sie Partitionen schneller als mit einem einzigen globalen Wert.

Chaos Engineering: Partitionen gezielt testen, statt nur darüber zu sprechen

Partitionen sind schwer in Staging nachzustellen, weil reale Produktionspfade komplex sind. Trotzdem lassen sie sich gezielt testen: mit Fault Injection (Delay, Loss, Blackhole), zonalen Kill-Switches, Proxy-Fehlern oder kontrollierten Route-/Policy-Änderungen. Für verteilte Systeme ist Jepsen ein bekannter Ansatz, um Partitionen und Konsistenzannahmen zu testen: Jepsen Framework. Für Plattformteams lohnt sich außerdem, Control-Plane-Resilienz separat zu testen (z. B. Discovery/Config), weil viele echte Partitionen genau dort eskalieren.

Weiterführende Quellen für Praxis und Theorie

• Jepsen: On the perils of network partitions
• etcd Failure modes: Network partition
• Examining Raft’s behaviour during partial network failures
• RFC 1035: DNS
• RFC 9293: TCP (Timeouts, Retransmits, Failure-Symptome)
• A List of Post-mortems (Incidents und wiederkehrende Muster)
• Cloudflare Post Mortems (Beispiele für partiellen Erreichbarkeitsverlust)
• OpenTelemetry (Observability für Latenzzerlegung und Segmentierung)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.