XPLN/Lernbereiche

E12 · Architektur · Bewertung

Architektur entwerfen und begründen

Kapitel in dieser Lernstufe

Das lernst du

  • Ein Mehrstandortkonzept aus Anforderungen ableiten.
  • Mehrere gültige Lösungen mit überprüfbaren Kriterien bewerten.

Voraussetzungen: E03 · Relay-Architektur und Option 82E04 · Hochverfügbarkeit und FailoverE05 · DHCP-Sicherheit am ZugangsnetzE06 · Dynamische DNS-IntegrationE08 · Kapazität und BetriebsplanungE09 · Wiederholbare AutomatisierungE10 · Migration und WiederherstellungE11 · DHCPv6, SLAAC und Router Advertisements

Nordlicht wächst auf drei Standorte. Die Aufgabe ist nicht, überall dieselbe Konfiguration zu kopieren, sondern Verfügbarkeit, Betrieb und Fehlerfolgen bewusst zu entwerfen.

Zwei Server heilen keinen gemeinsamen WAN-Ausfall

Redundante Dienste, gemeinsamer EngpassZentraleAußenstelleZwei DHCP-ServerWANunterbrochenNeuer ClientBeide unerreichbarLokale Vergabe wäre eine eigene Architekturentscheidung.
Grafik vergrößern
Redundante Dienste, gemeinsamer EngpassZentraleAußenstelleZwei DHCP-ServerWANunterbrochenNeuer ClientBeide unerreichbarLokale Vergabe wäre eine eigene Architekturentscheidung.
Zwei zentrale Server teilen aus Sicht der Außenstelle den WAN-Pfad. Fällt dieser aus, erreicht ein neuer Client keinen der beiden. Eine eigenständig geplante lokale Vergabe kann diese Abhängigkeit reduzieren; vorhandene gültige Leases und neue Bezüge müssen getrennt getestet werden.

Anforderungen vor Produktwahl

Erfasse Gerätezahl und Wechselrate je Netz, Dauer tolerierbarer Ausfälle, Verhalten bei WAN-Störung, bestehende Betriebskenntnisse, Sicherheitsanforderungen und Wiederherstellungsziele. Unterscheide neue Clients von bereits versorgten: Gültige Leases können einen kurzen Ausfall überbrücken, neue Geräte benötigen einen erreichbaren Vergabedienst.

Eine zentrale HA-Lösung reduziert verteilte Pflege, bleibt aber von Relay- und WAN-Pfaden abhängig. Lokale Dienste erhöhen Standortautonomie, benötigen dafür mehr Instanzen, Überwachung und konsistente Konfiguration. Eine lange Lease allein ist kein Ersatz für Neuvergabeverfügbarkeit.

Vergleich und Abnahme

Bewerte mindestens zwei technisch plausible Varianten anhand derselben Kriterien. Dokumentiere Poolplanung, Reserve, Relaypfade, Partnerbeziehungen, DNS-Updateidentitäten, Schutzports, Monitoring, Sicherungen und Rollback. Benenne nicht modellierte Abhängigkeiten statt sie implizit als funktionierend anzunehmen.

Die Umsetzung braucht konkrete Artefakte: Adressplan, Konfiguration, Diagramm, Messprotokoll und Wiederherstellungsnachweis. Prüfe Normalbetrieb, Partnerausfall, WAN-Unterbrechung, Rückkehr und einen fehlerhaften Parameter. Kosten umfassen nicht nur Lizenzen, sondern auch Wartungszeit und Diagnoseaufwand.

Eine Entscheidung anhand eines konkreten Ausfalls treffen

Nordlicht besitzt eine Zentrale und zwei Außenstellen. Ein zentraler DHCP-Dienst vereinfacht die Verwaltung, macht neue Bezüge in den Außenstellen aber vom erreichbaren Weg zur Zentrale abhängig. Zwei zentrale Server können einen einzelnen Dienstausfall abfangen, ohne einen gemeinsamen WAN-Ausfall zu lösen. Lokale Dienste verändern diese Abhängigkeit, erzeugen jedoch zusätzlichen Betriebs- und Sicherungsaufwand.

Beschreibe deshalb für jede Variante den Ausfall von Dienst, Serverhost, Standortverbindung und Stromversorgung. Frage jeweils getrennt nach bestehenden Leases und neu startenden Clients. Ein achtstündiger Leasepuffer hilft einem bereits konfigurierten PC, aber keinem erstmals angeschlossenen Gerät. Erst diese konkreten Fälle zeigen, ob die Architektur die geforderte Verfügbarkeit erfüllt.

Aus Anforderungen messbare Abnahmekriterien machen

Die Forderung „hochverfügbar“ ist ohne Prüfmaßstab unvollständig. Formuliere stattdessen beispielsweise: Neue Büroclients erhalten bei Ausfall eines Partners weiterhin passende Konfiguration; ein falscher Anbieter am Benutzerport wird blockiert; eine DNS-Änderung wird auf beiden verantwortlichen Servern wirksam; nach Rückkehr eines Partners entstehen keine widersprüchlichen Zuordnungen. Jeder Satz verlangt einen beobachtbaren Test.

Dokumentiere für die gewählte Variante Topologie, Adressmengen, Zuständigkeiten, Vertrauensgrenzen, Versionsbezüge und Wiederherstellung. Nenne auch bewusst akzeptierte Grenzen, etwa eingeschränkte Neuaufnahme während eines WAN-Ausfalls. Eine gute Begründung behauptet keine grenzenlose Verfügbarkeit, sondern zeigt, welche Anforderungen erfüllt werden, wie das nachgewiesen wird und welche betrieblichen Konsequenzen die Entscheidung hat.

DURCHGEARBEITETES BEISPIEL

Zentrale HA gegen lokale Standortdienste

  1. Anforderung: Standort B muss bei zweistündigem WAN-Ausfall neue Gastgeräte versorgen. Zentrale Server am Hauptstandort sind in dieser Zeit nicht erreichbar.
  2. Variante A nur zentral: bestehende gültige Leases können fortbestehen, neue Gäste scheitern. Die Anforderung ist damit ohne zusätzliche lokale Fähigkeit nicht erfüllt.
  3. Variante B lokale Vergabe mit definierter Redundanz und zentral gepflegten Konfigurationsdaten: Neuvergabe bleibt möglich, Betriebsaufwand steigt. Pools und Zuständigkeiten dürfen nicht unkoordiniert überlappen.
  4. Im Labor WAN-Pfad unterbrechen, neuen Client starten, Vergabe/DNS/erlaubte Dienste prüfen, anschließend Pfad wiederherstellen. Ergebnis und verbleibende Abhängigkeiten protokollieren.

Ergebnis: Eine begründete Architektur ist eine nachgewiesene Antwort auf konkrete Anforderungen. Unterschiedliche Produkte und Poolgrenzen können dafür gültig sein.

Typische Fehler

  • „Zwei Server“ ist keine vollständige Verfügbarkeitsanforderung.
  • Ein guter Normalbetriebstest ersetzt keinen Wiederherstellungstest.
  • Betriebskosten und benötigte Kompetenzen gehören in die Entscheidung.

Praktisch anwenden

P38 öffnen P25 öffnen P32 öffnen P36 öffnen

Offizielle Quellen

Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.