Hallo!

Brauchen Sie Hilfe? Wir sind hier!

Unterstützungssymbol
miniOrange E-Mail-Support
Erfolg

Vielen Dank für Ihre Anfrage. Unser Team wird sich in Kürze mit Ihnen in Verbindung setzen.

Wenn Sie innerhalb von 24 Stunden nichts von uns hören, senden Sie bitte eine Folge-E-Mail an info@xecurify.com

Search Results:

×


On-Premise Architektur

Standalone-Architektur


Standalone-Architektur


Die Standalone-Architektur ist für die lokale Installation der miniOrange Identity Platform auf einem einzelnen Knoten konzipiert. Sie bietet eine vereinfachte Einrichtung und stellt gleichzeitig die wesentlichen Komponenten einer Enterprise-Lösung bereit. IAM Lösung.

  • Komponenten:
    • NGINX: Fungiert als Reverse-Proxy und Einstiegspunkt für den Webzugriff.
    • Apache tomcat: Hostet den miniOrange Identity Server.
    • Mikrodienste: Bereitstellung eines modularen Identitäts- und Zugriffsmanagements (IAM) Funktionalität.
    • Caching-Server (Redis): Gewährleistet einen schnelleren Zugriff auf häufig genutzte Daten.
    • Datenbankserver: Speichert persistente Identitäts- und Konfigurationsdaten.
    • Nachrichtenwarteschlange (RabbitMQ): Verwaltet die Kommunikation zwischen internen Abteilungen.
  • Konnektivität:
  • Der externe Zugriff erfolgt über Standardanschlüsse:

    • 80 (HTTP): Web-Zugang
    • 443 (HTTPS): Sicherer Webzugriff
    • 1812 (UDP): RADIUS-Authentifizierung
    • 1813 (UDP): RADIUS-Buchhaltung
    • 10049 (TCP): Tacacs

    Die interne Verbindung zum Caching-Server, Datenbankserver und zur Message Queue wird aufrechterhalten, um eine effiziente Verarbeitung und einen reibungslosen Datenfluss zu gewährleisten.

  • Anwendungsfall:
  • Die Standalone-Konfiguration eignet sich am besten für Entwicklungs-, Test- oder kleine Produktionsumgebungen, in denen Hochverfügbarkeit (HA) und Disaster Recovery (DR) keine kritischen Anforderungen darstellen.


Standalone-Architektur mit Disaster-Recovery-Funktion (Standalone + DR)


Standalone-Architektur mit Disaster-Recovery-Architektur


Die Standalone + DR-Architektur erweitert die Standalone-Bereitstellung um eine dedizierte Disaster-Recovery-Umgebung zur Sicherstellung der Geschäftskontinuität.

  • Primäre Umgebung:
  • Führt den zentralen Identity Server, Microservices, Caching-Server, Datenbank und RabbitMQ-Nachrichtenwarteschlange aus.

  • DR-Umgebung:
    • Spiegelt die primäre Konfiguration wider.
    • Gewährleistet die Synchronisierung durch Datenbankreplikation und Datenkonsistenz über Caching- und Messaging-Schichten hinweg.
  • Ausfall:
    • Der gesamte Datenverkehr wird über einen Load Balancer geleitet.
    • Im Falle eines Ausfalls der primären Umgebung werden die Anfragen automatisch und ohne Unterbrechung für den Benutzer auf die DR-Umgebung umgeleitet.
  • Anwendungsfall:
  • Ideal für Organisationen, die Geschäftskontinuität und Ausfallsicherheit benötigen, um sicherzustellen, dass die Dienste auch bei Ausfällen des Rechenzentrums betriebsbereit bleiben.


Hochverfügbarkeitsarchitektur


Hochverfügbarkeitsarchitektur


Die HA-Architektur gewährleistet durch den parallelen Betrieb mehrerer Knoten Ausfallsicherheit und Fehlertoleranz.

  • Komponenten:
    • Zwei oder mehr miniOrange IDP-Knoten, jeweils mit NGINX, Tomcat, dem Identity Server und Microservices.
    • Gemeinsam genutzter Redis-Caching-Server, Datenbank und RabbitMQ-Nachrichtenwarteschlange.
  • Lastenausgleicher:
    • Verteilt Benutzeranfragen auf mehrere IDP-Knoten.
    • Bietet Skalierbarkeit und Redundanz und verhindert so Single Points of Failure.
  • Anwendungsfall:
  • Gut geeignet für mittlere bis große Implementierungen, bei denen Verfügbarkeit, Leistung und Skalierbarkeit kritische betriebliche Anforderungen darstellen.


Hochverfügbarkeit mit Notfallwiederherstellung (HA + DR)


Hochverfügbarkeit mit Notfallwiederherstellung


Die HA + DR-Architektur kombiniert Clustering und geografische Redundanz für maximale Ausfallsicherheit.

  • Primäre Umgebung:
    • Betreibt mehrere IDP-Knoten im HA-Modus hinter einem Load Balancer.
    • Verbunden mit Redis-Caching, einer primären Datenbank und einer RabbitMQ-Nachrichtenwarteschlange für Hochgeschwindigkeitsverarbeitung.
  • DR-Umgebung:
    • Enthält eine identische Konfiguration, die in Echtzeit synchronisiert wird.
    • Redis, die Datenbank, und RabbitMQ verwalten replizierte Daten für einen nahtlosen Übergang.
  • Globaler Load Balancer:
    • Leitet Anfragen zwischen der primären Umgebung und der DR-Umgebung weiter.
    • Führt Systemprüfungen durch und gewährleistet die automatische Umschaltung bei Ausfällen.
  • Anwendungsfall:
  • Ideal geeignet für unternehmenskritische Implementierungen, die hohe Verfügbarkeit, Notfallwiederherstellung und Geo-Resilienz über mehrere Rechenzentren hinweg erfordern.


Möchten Sie eine Demo planen?

Demo anfordern