Lessons Learned VLAN70¶

Stand: 2026-05-26

Diese Seite fasst die wichtigsten technischen Erkenntnisse aus der VLAN70-Canary-Migration der Lanstyle AI Suite zusammen.

DNS-Upstreams und NPM/OpenResty¶

Die wichtigsten AI-/Streaming-Backends wurden zuerst mit internen DNS-Zielen vorbereitet. In der Praxis zeigte sich, dass DNS-basierte NPM/OpenResty-Upstreams für lange AI-/Streaming-Verbindungen nicht zuverlässig genug waren.

Beobachtungen:

ollama.ad.lanstyle.de wurde in der NPM/OpenResty-Laufzeit zeitweise falsch auf eine externe IP aufgelöst, obwohl die NPM-Shell korrekt auf 10.222.70.11 auflöste.
searxng.ad.lanstyle.de zeigte denselben Resolver-Effekt im Zusammenhang mit search.lanstyle.de.
Direkte Verbindungen zu den VLAN70-Ziel-IPs waren stabil.

Entscheidung:

Für AI-, Streaming- und Agent-Services werden in NPM aktuell direkte interne Upstream-IPs verwendet.
DNS bleibt trotzdem Source of Truth für Clients, Doku, NetBox-Kontext und direkte interne Tests.
Keine direkten SQLite-Manipulationen an NPM; Proxy-Änderungen erfolgen per NPM API.

AI Streaming Besonderheiten¶

AI-Dienste verhalten sich anders als klassische Web-UIs:

lange HTTP-Verbindungen
Chunked/SSE-Streaming
hohe Antwortzeiten bei großen Modellen
parallele Requests
große Antwortkörper und Embedding-Payloads

Für Canaries reicht deshalb kein reiner HTTP-Statuscheck. Validiert werden müssen:

Streaming-Antworten
längere Prompts
parallele Requests
NPM/OpenResty Logs
Backend-Logs
Browser-Konsole bei Open WebUI

LiteLLM Alias-Erfahrungen¶

Bewährter produktiver Default:

lanstyle/agent-stable auf qwen3-coder-next:latest

Spezialmodell:

lanstyle/architect auf gpt-oss:120b für Architektur, Reviews und längere Planung.

Auffälliger Alias:

lanstyle/agent auf qwen3.6:35b-a3b kann bei bestimmten Prompts finish=length mit leerem sichtbarem Content liefern, weil Tokens im Reasoning verbraucht werden.

Entscheidung:

lanstyle/agent-stable bleibt produktiver Default.
lanstyle/agent bleibt experimentell und wird weiter beobachtet.

MCP und OpenAPI Besonderheiten¶

OpenCode und Open WebUI nutzen Tooling unterschiedlich:

OpenCode nutzt MCPHub direkt.
Open WebUI nutzt OpenAPI-kompatible Toolserver.
MCPHub braucht persistente, schreibbare Konfiguration für OAuth-/Register-Zustände.
Toolserver müssen read-only oder plan-only bleiben, solange Approval-, Audit- und Rollback-Flows nicht produktiv sind.

Wichtig:

Read-only MCPs dürfen Inventar und Status abfragen.
Plan-only MCPs dürfen Änderungsvorschläge erzeugen, aber keine Live-Writes ausführen.
Live-Writes an AD, Exchange, Intune, Proxmox, NetBox, NPM oder Gitea bleiben gesperrt, bis Approval-ID-Enforcement produktiv ist.

Open WebUI Toolserver Verhalten¶

Open WebUI funktioniert stabil als Frontend, braucht aber echte E2E-Tests:

Login
Session-Persistenz
Modellliste
Chat mit Streaming
Toolserver-Initialisierung
Open-Terminal-Sessions
SearXNG-Suche
Browser-Konsole

Der ai.lanstyle.de-Canary zeigte nach Umstellung auf 10.222.70.10:8080 funktionierende Sessions, Modellliste, Chat und Tool-Endpunkte. Ein einzelner WebSocket-Eintrag lief am Cutover-Rand noch über den Altpfad; das passt zu einer bestehenden Browser-Session und bleibt in der Beobachtungsphase im Blick.

Canary- und Rollback-Strategie¶

Bewährt hat sich:

Dual-Homing je Komponente.
Alte IP beibehalten.
Ziel-IP direkt testen.
NPM-Backend nur einzeln umstellen.
Keine harten Deny-Regeln während Canary.
Rollback-Pfad je FQDN dokumentieren.
Logs und echte Funktionstests auswerten.

Aktiver Rollback-Grundsatz:

NPM-Proxy-Hosts können per NPM API auf die Alt-IP zurückgestellt werden.
Guest-IP-Entfernung, Firewall-Härtung und Cleanup erfolgen erst nach separater Freigabe.

Offene Beobachtungspunkte¶

sehr lange Open-WebUI-Chats
größere Uploads
mehrere gleichzeitige Benutzer
wiederkehrende WebSocket/SSE-Auffälligkeiten
SearXNG Engine-/CAPTCHA-Fehler getrennt von Proxy-Problemen bewerten
lanstyle/agent weiter als experimentell behandeln