Selbstgehostetes Keyright über mehrere Knoten für Hochverfügbarkeit betreiben

Ein Lizenzserver hat eine unscheinbare, aber unerbittliche Aufgabe: Er sitzt auf dem Aktivierungspfad Ihrer Kunden, und wenn er im falschen Moment nicht erreichbar ist, kann jemand die Software, für die er bezahlt hat, nicht starten. Ein gutes Client-Design mildert das mit Offline-Kulanz ab — ein zwischengespeichertes Lease überbrückt einen kurzen Ausfall — aber „kurz” leistet in diesem Satz viel Arbeit. Wenn Ihr einziger Lizenzknoten einen Nachmittag lang zum Einspielen von Patches ausfällt, oder seine VM gerade migriert wird, oder er einfach umgekippt ist, verlassen Sie sich darauf, dass das Kulanzfenster jedes Kunden länger ist als Ihr Ausfall. Das ist kein Plan. Hochverfügbarkeit schon.

Die gute Nachricht ist, dass es fast antiklimaktisch ist, selbstgehostetes Keyright hochverfügbar zu machen, weil die App dafür gebaut wurde. Dieser Beitrag erklärt genau, warum, und wie man ein Deployment mit zwei oder drei Knoten aufsetzt.

Kernaussage: Selbstgehostetes Keyright ist ein zustandsloser ASP.NET-Core-Dienst — der gesamte Zustand liegt in Ihrem PostgreSQL — Hochverfügbarkeit bedeutet damit nur, zwei oder drei Replicas hinter einem Load Balancer ohne Session-Affinität zu betreiben. Was Sie wirklich hochverfügbar machen müssen, ist Postgres. Mehrknoten-HV ist ein Pro- oder Enterprise-Deployment (beide decken bis zu drei Produktionsknoten ab); Standard deckt einen einzelnen Knoten ab.

Warum ein Lizenzserver von Anfang an HV braucht

Überlegen Sie, wo der Dienst tatsächlich sitzt. Jede frische Aktivierung, jeder Sitzanspruch, jede Online-Neuprüfung eines Lease läuft über ihn. Für die meisten Ihrer Kunden ist dieser Verkehr stoßweise und unsichtbar — bis zu dem Moment, in dem er es nicht mehr ist, weil jemand eine neue Maschine in Betrieb nimmt oder ein Lease abgelaufen ist und der Client es erneuert. Ist der Server dann ausgefallen, ist genau diese Person blockiert, und bei-der-Aktivierung-blockiert ist der denkbar schlechteste Zeitpunkt dafür. Daraus wird binnen Minuten ein Support-Ticket.

Den Normalfall entschärfen Sie bereits mit Offline-Validierung zwischen Aktivierungen und Kulanzfenstern bei Ausfällen. HV ist die andere Hälfte: Statt zu hoffen, dass ein Ausfall innerhalb der Kulanz aller bleibt, entfernen Sie den Single Point of Failure, sodass es gar keinen Ausfall zu überbrücken gibt. Zwei Knoten bedeuten, dass einer sterben, gepatcht oder umgeplant werden kann, während der andere weiter antwortet.

Die Architektur, die das einfach macht

Selbstgehostetes Keyright hat genau zwei bewegliche Teile: eine zustandslose App und Ihre Datenbank.

Die App ist das Image ghcr.io/delta1-labs/keyright — ein ASP.NET-Core-Dienst, der auf Port 8080 lauscht. Das Image ist nur die App: Es gibt keine Datenbank darin. Es hält zwischen Anfragen keinen Zustand. Lizenzen, Aktivierungen, Sitze, Guthaben, das Audit-Log, die Signierschlüssel — all das liegt in PostgreSQL, auf das Sie die App mit der Verbindungszeichenfolge KEYRIGHT_DB richten. Die App erstellt und migriert ihr eigenes Schema beim ersten Start, es gibt also kein SQL, das Sie von Hand ausführen müssten.

Diese eine Entwurfsentscheidung — zustandslose App, der gesamte Zustand in Ihrer Datenbank — ist es, die HV trivial macht. Weil nichts an einen bestimmten Prozess geheftet ist, können Sie so viele Kopien der App ausführen, wie Sie wollen, und jede Kopie kann jede Anfrage beantworten. Keine Session im Speicher, kein knotenlokaler Wahrheits-Cache, nichts, was verloren geht, wenn ein Knoten verschwindet. Die App herauszuskalieren heißt nur, denselben Container mehr als einmal auszuführen.

Mehrere Replicas betreiben

Mit Docker Compose ist das Skalieren der App-Schicht ein Flag:

docker compose up -d --scale keyright=3

Das gibt Ihnen drei identische App-Container, die alle dasselbe KEYRIGHT_DB lesen und dieselbe Konfiguration tragen. Stellen Sie einen Load Balancer davor (siehe unten), und Sie haben ein Deployment mit drei Knoten.

Auf Kubernetes mit dem Helm-Chart ist es ein Wert:

# values.yaml
replicaCount: 3

helm upgrade --install keyright delta1/keyright -f values.yaml

Kubernetes plant drei Pods, der Service verteilt die Last auf sie, und weil die Pods zustandslos sind, können Sie sie frei hinzufügen oder entleeren. Verteilen Sie sie mit Pod-Anti-Affinität über Knoten oder Verfügbarkeitszonen, wenn Sie den Verlust einer ganzen Maschine oder Zone überstehen wollen.

Eines bleibt über jedes Replica hinweg identisch: der Selbstlizenz-Schlüssel. Keyright ist fail-closed — es braucht einen gültigen Selbstlizenz- (oder Test-)Schlüssel, um überhaupt Verkehr zu bedienen — und jeder Knoten läuft mit demselben Schlüssel. Es gibt keine Registrierung pro Knoten und keinen Handshake zur Knotenzählung; eine Verlängerung oder ein Editionswechsel ist nur der Austausch des Schlüssels in Ihrer Konfiguration und ein Neustart der Knoten. Den Schlüssel auszurollen ist eine Konfigurationsänderung, kein Lizenzierungstanz.

Der Load Balancer und die Health-Probes

Stellen Sie irgendeinen HTTP-Load-Balancer vor die App-Knoten — den L7-Balancer Ihrer Cloud, einen Ingress-Controller, nginx, HAProxy, was auch immer Sie bereits betreiben. Zwei Dinge gilt es richtig zu machen:

Keine Session-Affinität. Aktivieren Sie keine Sticky Sessions. Weil die App zustandslos ist und Clients offline zwischen Aktivierungen validieren, gibt es nichts, was an einen Knoten gebunden wäre und das die Affinität bewahren müsste. Schicken Sie jede Anfrage an jeden Knoten. Affinität einzuschalten konzentriert nur die Last und untergräbt den Sinn. Nebenläufigkeit über Knoten hinweg ist auch ohne sie sicher: Sitze und Guthaben nutzen ein serialisierbares Prüfen-und-Abbuchen in Postgres, sodass zwei Knoten physisch denselben Sitz oder dasselbe Guthaben nicht doppelt ausgeben können.

Health-Probes. Keyright stellt genau dafür zwei Endpunkte bereit:

• GET /health — Liveness. Ein statisches 200, das einen Knoten niemals wegen eines vorübergehenden Datenbank-Aussetzers aus dem Pool nimmt. Nutzen Sie es, um zu entscheiden, ob der Prozess lebt.
• GET /health/ready — Readiness. Dieser prüft zusätzlich die Datenbankverbindung und gibt 503 zurück, wenn Postgres nicht erreichbar ist. Nutzen Sie es, um zu entscheiden, ob ein Knoten Verkehr erhalten soll.

Eine typische Balancer-Probe:

health check: GET /health/ready   interval 10s   healthy 2   unhealthy 3

Terminieren Sie TLS am Balancer und leiten Sie X-Forwarded-For (die echte Client-IP) und X-Forwarded-Proto (damit Dashboard und Portal https-URLs erzeugen) weiter — die App berücksichtigt beides. Geben Sie öffentlich nur den :443 über den Balancer frei; halten Sie /admin/* und /internal/* nur aus Ihrem Netz heraus erreichbar. Ihre Kunden brauchen nur den Pfad /v1/*.

PostgreSQL ist der wahre Engpass

Hier ist der Teil, den man verkehrt herum angeht. Die App zu skalieren ist nahezu kostenlos, dort sollte Ihre Aufmerksamkeit also nicht hingehen. Was zuverlässig sein muss — und was tatsächlich begrenzt, wie weit Sie skalieren — ist PostgreSQL, denn dort liegt jedes Byte Zustand.

Investieren Sie also dort. Für alles jenseits der Evaluierung betreiben Sie nicht die mitgelieferte Datenbank, die die Kits der Bequemlichkeit halber anbieten; richten Sie KEYRIGHT_DB auf ein verwaltetes oder hochverfügbares Postgres — ein Primär mit einem Standby, automatischem Failover und echten Backups. Eine zustandslose App vor einer einzigen zerbrechlichen Datenbank ist nicht hochverfügbar; Sie haben den Single Point of Failure nur eine Schicht tiefer verschoben. Machen Sie die Datenbank zur HV-Komponente, und die App-Schicht folgt kostenlos. In sehr großem Maßstab (hin zu Millionen aktiver Lizenzen) fügen Sie PgBouncer für Verbindungs-Pooling hinzu und geben Postgres mehr Kerne — die Skalierungsrichtlinien in der Betriebsdokumentation enthalten konkrete Dimensionierung pro Stufe.

Der Grund, warum die App es sich leisten kann, so leicht zu sein, ist die Form der Last. Der heiße Pfad — /v1/activate und /v1/validate — ist eine Signaturprüfung plus eine Sitzzählung, und Clients halten ein signiertes Lease im Cache und validieren offline zwischen Aktivierungen. Sie erhalten nicht bei jedem App-Start eine HTTP-Anfrage; Sie erhalten eine bei der Aktivierung und dann periodisch, wenn ein Lease erneuert wird. Das ist eine kleine, stoßweise, CPU-leichte Last, was genau der Grund ist, warum zwei oder drei bescheidene Knoten ein Deployment mit Hunderttausenden aktiver Lizenzen bequem abdecken.

Ein kostenloser Bonus: Updates ohne Ausfallzeit

Sobald Sie 2+ Knoten betreiben, hören Updates auf, ein Ausfall zu sein. Weil die App innerhalb einer Minor-Linie abwärtskompatibel ist und Migrationen beim Start automatisch angewendet werden, können Sie einen Knoten nach dem anderen erneuern: entleeren, das neue Image ziehen, ihn zurückkommen und ready werden lassen, dann zum nächsten gehen. Der Balancer bedient die ganze Zeit von den gesunden Knoten aus. Dieselbe Eigenschaft, die Ihnen HV gegen Ausfälle gibt, gibt Ihnen HV gegen Wartung — die in der Praxis der Ausfall ist, den Sie tatsächlich am häufigsten einplanen.

Welche Edition Sie brauchen

Selbstgehostetes Keyright wird pro Deployment lizenziert, und die Editionen unterscheiden sich in der Knotenanzahl:

• Standard deckt einen einzelnen Produktionsknoten ab — in Ordnung für ein unkompliziertes Deployment, aber per Definition nicht hochverfügbar.
• Pro und Enterprise decken beide bis zu drei Produktionsknoten ab — was Mehrknoten-HV verlangt.

Standard und Pro betreiben die exakt gleiche Funktions-Engine; die Knotenanzahl ist das Einzige, was sie trennt, „ich will HV” ist also schlicht ein Grund, auf Pro statt auf Standard zu sein. Enterprise ergänzt SSO, White-Label-Branding und air-gapped-Guthabenblöcke auf derselben Drei-Knoten-Zuteilung. Die Knotenanzahl ist eine vertragliche Größe — die Software zählt oder erzwingt keine Knoten, und derselbe Selbstlizenz-Schlüssel läuft auf allen Replicas. Die aktuellen Zahlen finden Sie in den Preisen.

Wo Keyright hineinpasst

Weil Keyright in beiden Deployment-Modi ein einziges Produkt ist, ist die Architektur aus zustandsloser App plus Ihrer Datenbank dieselbe, ob Sie auf einem Laptop evaluieren oder drei Knoten in Produktion betreiben — nichts an Ihrer Integration ändert sich, während Sie herausskalieren. Wenn Sie noch unentschieden sind, ob Sie überhaupt selbst hosten, legen die Abwägungen zwischen selbstgehostet und Cloud die Entscheidung dar, und wenn Sie von einem Eigenbausystem umsteigen, ist migrieren, ohne Kunden zu brechen das Drehbuch. Wenn Sie bereit sind, HV aufzusetzen, enthält der Betriebsleitfaden die Details zu Backup, Update und Dimensionierung, die aus zwei laufenden Knoten ein Produktions-Deployment machen, hinter dem Sie ruhig schlafen können.