Referenzinformationen › Appliance-Katalog-Referenzhandbuch › Systemkatalog › Gateways › INSSLR2 - Redundantes HTTP-Eingabe-Gateway mit SSL-Unterstützung

INSSLR2 - Redundantes HTTP-Eingabe-Gateway mit SSL-Unterstützung

Aktuelle Version: 1.0.1-2

Die INSSLR2-Appliance ist ein Layer-7-Gateway für sichere HTTP-Anfragen. Konvertiert die Anfragen in unverschlüsselte HTTP-Anfragen. Sie können diese Funktion verwenden, um sicheres HTTP auf der Client-Seite zu unterstützen.

Allerdings wird SSL von der Backend-Infrastruktur nicht unterstützt. Hierzu zählen:

• Verwendung eines schnellen und schlanken HTTP-Servers, über keine SSL-Unterstützung verfügt
• Verwendung mehrerer Backend-Server aus Leistungs- oder Redundanzgründen, die durch einen Lastenausgleichs-Switch verbunden sind
• Verwendung mehrerer Backend-Server für nicht verwandte Funktionen, die durch einen URL-Switch verbunden sind
• Auslagerung der SSL-Verschlüsselung oder -Entschlüsselung auf einen separaten Server, um einen höheren Durchsatz zu erzielen

Sofern konfiguriert, unterstützt INSSLR2 auch die Client-Zertifikatauthentifizierung. Bei der gegenseitigen SSL-Authentifizierung tauschen der Client und der Server ihre Zertifikate und zugehörigen öffentlichen Schlüssel aus. Der Client und/oder der Server können die Zertifizierungsstelle (CA), die das Zertifikat ausgegeben hat, kontaktieren und vor dem Fortfahren bestätigen, dass das Zertifikat authentisch ist.

In der Standardkonfiguration agiert INSSLR2 als Layer-7-Gateway für sichere HTTP-Anforderungen. Es stellt außerdem einen Einstiegspunkt mit Firewall für Netzwerkverkehr in eine Anwendung bereit. Dies kann mit einer über das Internet zugänglichen statischen IP-Adresse konfiguriert werden.

Sofern konfiguriert, können zwei INSSLR2-Appliances im Failover-Modus verwendet werden, um einen redundanten Dienst bereitzustellen. In diesem Fall wird die IP-Adresse von INSSLR2 auf nur einem der Knoten ausgeführt und im Falle eines Fehlers automatisch auf die andere INSSLR2-Appliance übertragen. Es ist immer nur eine der INSSLR2-Appliances gleichzeitig aktiv. Im Failover-Modus kann INSSLR2 so konfiguriert werden, dass eine Ausführung in mehreren Modi möglich ist:

• Asymmetrisch - eine der Appliances ist die primäre Appliance. Wenn die primäre Appliance online ist, übernimmt sie die IP-Adresse und wird aktiv.

  Wenn der Primärknoten fehlschlägt oder angehalten wird, wird die Sicherungs-Appliance aktiv. Wenn die primäre Appliance erneut verfügbar ist, übernimmt sie wieder die IP-Adresse und wird aktiv. Die primäre Appliance ist die Appliance mit der kürzesten IP-Adresse (Zeichenfolgenvergleich) der Fover-Schnittstelle.

• Symmetrisch - beide Appliances sind primäre Appliances. Die zuerst gestartete Appliance übernimmt die IP-Adresse und wird aktiv. Die andere Appliance wird nur aktiv, wenn die primäre Appliance fehlschlägt oder angehalten wird.

  Wenn die primäre Appliance erneut verfügbar ist, übernimmt sie nicht automatisch die IP-Adresse.

Wenn INSSLR2 im redundanten Modus ausgeführt wird, wird eine Schnittstelle auf dem zugehörigen Terminal "ctl" bereitgestellt, um:

• zu erzwingen, dass INSSLR2 primäre Appliance wird
• zu erzwingen, dass INSSLR2 Sicherungs-Appliance wird
• den Status von INSSLR2 (primär/Sicherung) zu überprüfen

INSSLR2 überwacht kontinuierlich den Integritätsstatus der Backend-Appliance, die an das HTTP-Terminal angeschlossen ist. Die von INSSLR2 durchgeführten Prüfungen des Integritätsstatus können eine einfache TCP-Verbindungsprüfung oder eine komplexere HTTP-Anfrage umfassen, sofern auf der Begrenzung von INSSLR2 angegeben.

Im Falle eines Fehlers der angeschlossenen Appliance sendet INSSLR2 eine Fehlermeldung an das Grid-Dashboard oder führt, wenn es sich im redundanten Modus befindet und entsprechend konfiguriert wurde, einen Failover auf die INSSLR2-Sicherungs-Appliance durch.

Um Anwendungen zu unterstützen, die an einer einzelnen IP-Adresse für mehr als einen Service angezeigt werden müssen, konfigurieren Sie INSSLR2 zur transparenten Weiterleitung von einem anderen Datenverkehr als HTTP-Datenverkehr zu einem separaten Ausgabe-Terminal. Für solche Verbindungen fungiert die Appliance als Layer-3-Firewall/NAT-Router.

Begrenzung

Ressourcen

Hinweise

• Wenn Sie INSSLR2 im Failover-Modus verwenden ("fover_mode" ist ungleich "none"), beträgt der minimale Speicher 192 M.
• Die Speichermenge, die INSSLR2 zugewiesen ist, wirkt sich nicht auf den Durchsatz aus. Verwenden Sie nur dann mehr Speicher, um mehr gleichzeitige Anfragen zu unterstützen, wenn die Backend-Server die Anfragen übermäßig lange zurückhalten.

Terminals

Eigenschaften

path/to/keys/ca_list_client.pem. 

path/to/keys/ca_list_client.pem. 

Eigenschaften der Systemintegritätsprüfung

Erweiterte Eigenschaften für Failover-Szenarien

Volumes

Fehlermeldungen

Die folgenden Meldungen können entweder in der Appliance-Protokolldatei oder im Systemprotokoll der Grid-Steuerung angezeigt werden, wenn die Appliance nicht startet:

• Daten-Volume konnte nicht geladen werden
• Berechtigungen für die Datenfreigabe konnten nicht festgelegt werden
• Samba konnte nicht gestartet werden
• NFS konnte nicht gestartet werden
• Apache konnte nicht gestartet werden

Leistung

Anwendungs-Failover

INSSLR2 erkennt den Ausfall von INSSLR2 nach etwa 10 Sekunden und benötigt weitere 10 Sekunden für das Failover zur anderen Anwendung. Die Gesamtdauer vom ersten Anwendungsfehler bis zu dem Zeitpunkt, an dem die andere Anwendung den Datenverkehr übernimmt, beträgt ca. 20 Sekunden.

Anforderungsrate

INSSLR2 leitet mindestens 3.000 Transaktionen (Anfrage/Antwort-Paare) pro Sekunde weiter, abhängig von Dokumentgröße und verfügbarer Netzwerkbandbreite.

Datendurchsatz

INSSLR2 leitet mindestens 7 MB/Sekunde weiter, abhängig von Dokumentgröße und verfügbarer Netzwerkbandbreite

Gleichzeitige Verbindungen

Mit seinem Standardspeicher unterstützt INSSLR2 mindestens 500 gleichzeitig ausstehende Anfragen. Eine ausstehende Anfrage ist eine offene TCP-Verbindung vom Client, auf der eine oder mehrere unvollständige HTTP-Anfragen vorhanden sind.

Die maximale Zahl der gleichzeitigen Verbindungen hängt vom verfügbaren Speicher ab. Die Anzahl an gleichzeitigen http-Transaktionen wird pro 16 MB Speicher um 500 erhöht.

Beispiel: Wenn Sie im redundanten Modus 2.000 Verbindungen gleichzeitig aufrechterhalten möchten, benötigen Sie 100 M + 3*16 M = 148 M. Der im redundanten Modus mindestens benötigte Speicher beträgt 100 M.

Benachrichtigungen

Beim Ausführen im redundanten Modus ("fover_mode" ist nicht "none"), gibt INSSLR2 bei Aktivität/Passivität Benachrichtigungen aus. Dies erfolgt beim Starten des aktiven Knotens bzw. bei der Durchführung eines Failovers. Jeder Knoten sendet eine Benachrichtigung darüber, dass er aktiv oder passiv wurde.

INSSLR2 sendet zwei Benachrichtigungen:

• Eine Benachrichtigung zum Grid-Dashboard: INSSLR2 appliance APP_NAME:COMP_NAME <acquired|gave up=""> resource ip_addr
• HTTP-Anforderung mithilfe des Nfy-Terminals. Die Empfangsseite muss anhand der Benachrichtigung Maßnahmen ergreifen.

  Die angeforderte URL ist:

  http://nfy/ fover_nfy_prefix fover_mode= fover_mode &state= <start|stop> &ip_addr= ip_addr &fover_local_ip= fover_local_ip &fover_remote_ip= fover_remote_ip &fover_netmask= fover_netmask

Mit "fover_nfy_prefix" können Sie den Speicherort des aufgerufenen Remote-Skripts ändern und/oder zusätzliche Parameter hinzufügen.

Beispiele für Werte vom Typ "fover_nfy_prefix":

/path/to/script.php?, /path/to/script.php?username=user&password=pass&. 

Hinweise:

• Wenn Sie keine Standardwerte für "fover_nfy_prefix" verwenden, stellen Sie sicher, dass diese mit "?" enden, wenn "fover_nfy_prefix" nur der Pfad ist, oder mit "&", wenn "fover_nfy_prefix" zusätzliche Parameter umfasst.
• Wenn ein Knoten nicht mehr verfügbar ist, wird unter Umständen keine Benachrichtigung gesendet, dass er passiv geworden ist. Nur der Knoten, der aktiv wurde, sendet eine Benachrichtigung.
• Die Zeitüberschreitung für die HTTP-Anfrage beträgt 5 Sekunden, sodass das Failover nicht verlangsamt wird.

Systemintegritätsprüfung

INSSLR2 führt einen Cronjob pro Minute aus, der das Folgende überprüft:

• Beträgt der freie Speicherplatz auf dem Daten-Volume weniger als 20 %?
• Wird Rsync-Daemon ausgeführt (nur wenn als Slave konfiguriert)?
• Wird der Replikationsprozess ausgeführt (nur wenn als Master konfiguriert)? Falls nicht - Replikationsprozess neu starten.

Wenn eine der Aussagen zutrifft, wird eine Fehlermeldung an das Grid-Dashboard gesendet. Wenn mehr als ein Test fehlschlägt, wird eine zusammenfassende Meldung mit allen Fehlern im Grid-Dashboard platziert.

Jeder Fehler wird nur ein Mal pro Stunde an das Grid-Dashboard gesendet. In den ersten 5 Minuten nach dem Start der Appliance werden keine Fehler gemeldet. Dies verhindert Fehlalarme, wenn der andere Knoten in der Replikation noch nicht gestartet wurde.

Serverzertifikate

Um SSL zu verwenden, benötigen Sie sowohl das Zertifikat mit Signatur als auch den privaten Schlüssel, mit dem es verschlüsselt wurde. Der Schlüssel und das Zertifikat sollten im PEM-Format vorliegen und in einer von der Eigenschaft "cert_file" angegebenen Datei gespeichert sein.

Serverzertifikate generieren

Sie können ein Serverzertifikat generieren, das gegen eine Gebühr von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert werden kann. Alternativ erstellen Sie ein selbstsigniertes Zertifikat.

Führen Sie folgende Schritte aus:

1. Generieren Sie mithilfe des folgenden Befehls einen privaten Schlüssel:

   openssl genrsa -out privkey.pem 2048 
   

   Mithilfe des folgenden Befehls können Sie außerdem einen kennwortgeschützten Schlüssel generieren. Wenn Sie einen kennwortgeschützten Schlüssel generieren, müssen Sie allerdings das Kennwort entfernen, bevor Sie ihn für INSSLR2 verwenden. INSSLR2 benötigt einen Schlüssel ohne Kennwort.

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. Erstellen Sie ein Zertifikat, indem Sie wie folgt vorgehen:
   • Erstellen Sie eine Zertifikatsanfrage und lassen Sie diese gegen eine Gebühr von einer vertrauenswürdigen CA signieren.

     Führen Sie den folgenden Befehl aus:

     openssl req -new -key privkey.pem -out server.csr 
     

     Wenn Sie die CSR-Datei an Ihre vertrauenswürdige Zertifizierungsstelle gesendet haben, erhalten Sie ein signiertes Zertifikat (CRT-Datei), das Sie verwenden können.

   • Erstellen Sie ein selbstsigniertes Zertifikat für Testzwecke. Browser, die Ihre Website anfordern, geben Warnungen mit dem Hinweis aus, dass das Zertifikat nicht von einer vertrauenswürdigen CA signiert wurde.

     Führen Sie den folgenden Befehl aus:

     openssl req -new -x509 -key privkey.pem -out server.crt -days 1095 
     

Verwenden von Serverzertifikaten

Sie können jetzt Zertifikat und Schlüssel in einer Datei speichern und in INSSLR2 verwenden, indem Sie den folgenden Befehl ausführen:

cat privkey.pem  server.crt > server.pem 

Wenn Ihr Schlüssel kennwortgeschützt ist, können Sie das Kennwort durch die Ausführung des folgenden Befehls entfernen:

openssl rsa -in key_with_pass.pem -out privkey.pem 

Verwenden vorhandener apache+mod_ssl-Serverzertifikate

INSSLR2 ermöglicht es Ihnen, ein vorhandenes Zertifikat zu verwenden, das in Apache verwendet wird. Überprüfen Sie anhand der obigen Schritte, ob der Schlüssel kennwortgeschützt ist, und speichern Sie anschließend das private Zertifikat und den Schlüssel in einer Datei.

Zum Beispiel:

• cat privkey.pem server.csr > server.pem

Wenn Sie ein verkettetes Zertifikat verwenden, sollten Sie auch das vom Aussteller bereitgestellte vorübergehende Zertifikat einschließen. Speichern Sie den privaten Schlüssel, das Zertifikat und das vorläufige Zertifikat in dieser Reihenfolge in einer Datei.

Zum Beispiel:

• cat privkey.pem server.csr sf_issuing.crt > server.pem

Wichtig! Der Serversignaturschlüssel ist der Identitätsnachweis Ihrer Website. Er ist angreifbar, weil er ist nicht kennwortverschlüsselt ist, sodass die Appliance ihn ohne Ihre Hilfe lesen kann.

Achten Sie bei der Installation auf dem Daten-Volume darauf, die Schlüsseldatei zu schützen. Verwenden Sie das Daten-Volume nicht für andere Zwecke, und machen Sie es nicht sichtbar für einen Webserver, beispielsweise, um Daten mit Webzugriff, wie HTML-Seiten oder -Skripte, zu hosten.

Client-Zertifikate

Das folgende Beispiel zeigt, wie Sie Ihre eigene Zertifizierungsstelle erstellen und sie zum Unterzeichnen eigener Zertifikate mit OpenSSL verwenden. Dies wurde mithilfe von OpenSSL 0.9.8b getestet, die gleiche Version, die in INSSLR2 installiert ist.

Zertifizierungsstelle erstellen

Wenn Sie bereits über eine eigene Zertifizierungsstelle verfügen, mit der ein selbstsigniertes Serverzertifikat erstellt wird, können Sie diesen Schritt überspringen und diese Zertifizierungsstelle verwenden. Wenn Sie die Instrumente der vertrauenswürdigen Zertifizierungsstelle für Ihre Anwendung erstellt haben, ist es wichtig, dass die Umgebung sicher ist.

Wichtig! Der private Schlüssel für die Zertifizierungsstelle bildet die Vertrauensgrundlage für die Anwendung. Sie sollten also immer wissen, wo er sich befindet und ihn nicht an Dritte weitergeben.

Führen Sie folgende Schritte aus:

1. Erstellen Sie ein Arbeitsverzeichnis auf einem sicheren Host und innerhalb dieses Verzeichnisses:
   • mkdir CA
   • mkdir CA/private
2. Erstellen Sie einen kennwortgeschützten RSA-Schlüssel für die CA mit einer Schlüssellänge von 2048 Bit:

   openssl genrsa -des3 -out CA/private/CA_key.pem 2048 
   

3. Erstellen Sie mit dem privaten Schlüssel das Zertifikat für öffentliche Schlüssel für die CA:

   openssl req -new -key CA/private/CA_key.pem -x509 -days 365 -out CA/CA_cert.pem 
   

Von der Zertifizierungsstelle signierte Client-Zertifikate erstellen

Sie können Client-Zertifikate erstellen, die von einer Zertifizierungsstelle signiert werden.

Führen Sie folgende Schritte aus:

1. Generieren Sie einen privaten RSA-Schlüssel:

   openssl genrsa -out clientA_privkey.pem 2048 
   

   Um einen kennwortgeschützten Schlüssel zu erstellen, verwenden Sie den "-des3"-Schalter.

2. Generieren Sie eine Zertifikatsignieranfrage (Certificate Signing Request, CSR) vom privaten Schlüssel:

   openssl req -new -key clientA_privkey.pem -out clientA_request.csr 
   

3. Unterschreiben Sie das in der Zertifikatsignieranfrage enthaltene Zertifikat mit dem für CA generierten Zertifikat:

   openssl x509 -req -days 365 -in clientA_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAcreateserial -out clientA.cer 
   

Hinweise:

• Der Schalter "-CAcreateserial-" aktiviert die Zuweisung eindeutiger Seriennummern für herausgegebene Zertifikate. Falls es sich um das erste von der CA herausgegebene Zertifikat handelt, wird die Datei "CA/CA_cert.srl" erstellt, um die Zuweisungen der Seriennummern zu verfolgen. Beim Erstellen nachfolgender Client-Zertifikate wird der Schalter "-CAserial-" anstelle des Schalters "-CAcreateserial-" verwendet.

  Zum Beispiel:

  openssl genrsa -out clientB_privkey.pem 2048 
  

  openssl req -new -key clientB_privkey.pem -out clientB_request.csr 
  

  openssl x509 -req -days 365 -in clientB_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAserial CA/CA_cert.srl -out clientB.cer 
  

• So erstellen Sie eine einzelne Datei im PEM-Format, die sowohl das Client-Zertifikat als auch den Schlüssel enthält:

  cat clientA_privkey.pem clientA.cer > clientA.pem 
  

• So erstellen Sie die entsprechende Datei im Format "pkcs12", das mit den meisten Browsern kompatibel ist:

  openssl pkcs12 -export -in clientA.cer -inkey clientA_privkey.pem -out clientA.p12 
  

Erstellen der von INSSLR2 verwendeten CA-Listen-Dateien

Widerrufen der von der Zertifizierungsstelle signierten Client-Zertifikate

Um ein von der CA herausgegebenes Client-Zertifikat zu widerrufen, verwenden Sie den folgenden Befehl:

openssl ca. -config openssl.conf -revoke clientB.cer -crl_reason keyCompromise 

Unten sehen Sie ein Beispiel für "openssl.conf". Der Parameter "crl_reason" kann entweder "unspecified", "keyCompromise", "CACompromise", "affiliationChanged", "superseded", "cessationOfOperation", "certificateHold" oder "removeFromCRL" sein. Bei der Abstimmung des Grunds wird die Groß-/Kleinschreibung nicht beachtet.

So generieren Sie die Zertifikatsaufhebungsliste (Certificate Revocation List, CRL) neu:

openssl ca. -config openssl.conf -gencrl -out CA/crl.pem 

In diesem Beispiel ist "crl.pem" die Datei, die als Eigenschaft "cert_revocation_list" an INSSLR2 übergeben werden muss.

Dies ist eine Beispielkonfigurationsdatei für das obige Beispiel: 

      ####################################################################

      [ ca ]

      default_ca      = CA_default            # The default ca section

      ####################################################################

      [ CA_default ]

      dir       = ./CA         # Where everything is kept

      certs      = $dir/certs      # Where the issued certs are kept

      crl_dir     = $dir/crl       # Where the issued crl are kept

      database    = $dir/index.txt    # database index file.

      #unique_subject = no          # Set to 'no' to allow creation of

                                        # several ctificates with same subject.

      new_certs_dir  = $dir/newcerts     # default place for new certs.

      certificate   = $dir/cacert.pem    # The CA certificate

      serial     = $dir/serial      # The current serial number

      crlnumber    = $dir/crlnumber    # the current crl number

                                        # must be commented out to leave a V1 CRL

      crl       = $dir/crl.pem     # The current CRL

      private_key   = $dir/private/cakey.pem# The private key

      RANDFILE    = $dir/private/.rand  # private random number file

      default_days  = 365          # how long to certify for

      default_crl_days= 30          # how long before next CRL

      default_md   = sha1         # which md to use.

      preserve    = no          # keep passed DN ordering

      policy     = policy_anything

      [ policy_anything ]

      countryName       = optional

      stateOrProvinceName   = optional

      localityName      = optional

      organizationName    = optional

      organizationalUnitName = optional

      commonName       = supplied

      emailAddress      = optional

Erstellen der von INSSLR2 verwendeten Zertifizierungsstellen-Listendateien

Sie können Zertifizierungsstellen-Listendateien erstellen, die von INSSLR2 verwendet werden.

Erstellen der von der Eigenschaft "ca_list_client" identifizierten Datei:

1. Greifen Sie auf die folgende Datei zu:

   cat CA/private/CA_key.pem CA/CA_cert.pem > ca_list_client.pem 
   

2. Legen Sie diese Datei auf dem Schlüssel-Volume oder auf dem Volume ab, das von nfs über das fs-Terminal bereitgestellt wird .

   Bei Bedarf kann das Serverzertifikat von INSSLR2, z. B. "server.pem", wie die Client-Zertifikate erstellt und ebenso von der erstellten Zertifizierungsstelle signiert werden. Verwenden Sie für dieses Zertifikat kein Kennwort.

3. Wenn "server.pem" und "ca_list_client.pem" eingerichtet sind, können Sie die Client-Zertifikatauthentifizierung wie folgt testen:
   • Zum Testen mit einem Browser importieren Sie ein Client-Zertifikat im Format "pkcs12" in Firefox:

     Wählen Sie hierzu "Tools" => "Options" => "View Certificates" => "Your Certificates" => "Import". Richten Sie den Browser auf die IP-Adresse von INSSLR2.

   • Testen Sie den SSL-Handshake von einem Remote-Host, indem Sie den folgenden Befehl ausführen:

     openssl s_client -host IP-address -port 443 -showcerts -ssl3 -cert clientA.cer -key clientA_privkey.pem -state 
     

Client-Zertifikat-Header

Wenn sich ein Client über HTTPS mit INSSLR2 verbindet, und es sich um ein Client-Zertifikat handelt, fügt INSSLR2 die folgenden Header in die Anfrage ein, die an den Backend-Server ausgegeben wird:

• X-SSL-Subject - Details über den Zertifikatseigentümer
• X-SSL-Issuer - Details über den Zertifikatsaussteller (Zertifizierungsstelle)
• X-SSL-Serial - Seriennummer des Zertifikats (Dezimalzahl)
• X-SSL-Cipher - die derzeit verwendete Chiffre
• X-SSL-Certificate - das vollständige Client-Zertifikat (mehrzeiliges PEM-Format)

Die Anwendung kann selbst entscheiden, ob diese Header verwendet werden oder nicht. INSSLR2 gibt diese Informationen einfach weiter, ohne sie zu überprüfen. Geprüft werden ausschließlich die Richtigkeit von Signatur und Verschlüsselung.

Typische Verwendung

Webanwendungen

Um den http(s)-Zugriff auf Ihre Anwendung zu ermöglichen, schließen Sie das HTTP-Terminal direkt an die NET-Appliance an.

Wenn Sie eine skalierbare Webanwendung benötigen, verbinden Sie das HTTP-Terminal mit einer HALB-Appliance.

In den Konfigurationsbeispielen werden nur Eigenschaften aufgeführt, die auf Nicht-Standard-Werte festgelegt sind.

Webanwendungen mit Zusatzdiensten

Wenn Sie abgesehen von http über weitere Dienste in Ihrer Anwendung verfügen, können Sie HTTP-Datenverkehr mithilfe von INSSLR2 an das HTTP-Terminal weiterleiten und das Terminal "aux" für andere Dienste verwenden.

Webanwendungen mit mehreren Zusatzdiensten

Wenn Sie mehrere TCP/UDP-Dienste und HTTP haben, können Sie den HTTP-Datenverkehr mithilfe von INSSLR2 an das HTTP-Terminal weiterleiten und das Terminal "aux" für die Weiterleitung des übrigen Datenverkehrs an PS8 verwenden. PS8 übergibt den gewünschten Datenverkehr anschließend an die Backend-Server.

Redundante Webanwendungen

Wenn Sie eine redundante Webanwendung bereitstellen möchten, können Sie die Anwendung kopieren und mithilfe von INSSLR2 Failover-Funktionen für die externe IP-Adresse bereitstellen.

Hinweis: Wenn zwei INSSLR2-Appliances in der gleichen Anwendung für die Ausführung im redundanten Modus konfiguriert werden, wird eine Warnmeldung angezeigt, wenn Sie die gleiche IP-Adresse auf zwei unterschiedlichen Schnittstellen konfigurieren. Ignorieren Sie diesen Fehler.

Sicherungswebanwendung

Wenn Sie nur eine Sicherungsanwendung benötigen, die Benutzer über Ausfallzeiten benachrichtigt, können Sie mithilfe von INSSLR2 eine Sicherungsanwendung erstellen, die minimale Ressourcen benötigt.

Verwendete Appliances:

• "user": Eingabe-Gateway für Benutzeranfragen
• "web": Webserver, der Wartungsmeldungen anzeigt

INSSLR2 auf primärer Anwendung

INSSLR2 auf Sicherungsanwendung

Hinweis: Sie können die Attribute der mit dem Fover-Terminal verbundenen Schnittstelle im Anwendungskonfigurations-Editor auf der Registerkarte "Schnittstellen" konfigurieren. Beispiel: Eigenschaften "fover_local_ip" und "fover_netmask".

Redundante Webanwendung (einzelne Anwendung)

Wenn Ihre Anwendung im redundanten Modus ausgeführt werden soll, ohne dass eine neue Anwendung erstellt wird, können Sie die Appliances verdoppeln und im redundanten Modus ausführen. Da dies bedeutet, mindestens zwei Webserver und zwei Datenbank-Appliances im normalem Modus zu verwenden, werden sie alle verwendet, was eine zusätzliche Skalierbarkeit ermöglicht. Allerdings können beide auch getrennt voneinander von der Anwendung verwendet werden, falls eine der Appliances ausfällt.

Wenn Sie zusätzliche Skalierbarkeit benötigen, können Sie weitere Web- und Datenbank-Appliances hinzufügen. In diesem Beispiel wird die Hälfte der Appliances (in1, sw1, web1, db1) in einer Failover-Gruppe ausgeführt. Die übrigen Appliances (in2, sw2, web2, db2) befinden sich in einer anderen Failover-Gruppe, sodass die Anwendung einen Serverabsturz überstehen kann. Diese Anwendung bietet Redundanz zu sehr geringen Kosten, da alle Appliances (außer einer INSSLR2- und einer HALB-Appliance, die sehr geringe Ressourcen benötigen) sich im aktiven Zustand befinden und keine Ressourcen für die Sicherungsanwendung benötigt werden. Diese wird nämlich nur ausgeführt, wenn die primäre Appliance fehlschlägt.

in1

in2

db1

db2

Redundante Webanwendung (zwei identische Anwendungen)

Sie können zwei identische Anwendungen auf dem gleichen Grid, aber auf getrennten Servern, oder auf unterschiedlichen Grids ausführen, wenn von beiden Grids auf die IP-Adresse zugegriffen werden kann. Dies bewirkt, dass der Ausfall eines Servers nur eine der Anwendungen betrifft.

Hinweis: Wenn zwei INSSLR2-Appliances in der gleichen Anwendung für die Ausführung im redundanten Modus konfiguriert werden, wird eine Warnmeldung angezeigt, wenn Sie die gleiche IP-Adresse auf zwei unterschiedlichen Schnittstellen konfigurieren. Ignorieren Sie diesen Fehler.

Das Beispiel unten zeigt eine Anwendung, die eine Datenbank-Appliance verwendet, die auch im redundanten Modus ausgeführt wird. Wenn eine Anwendung fehlschlägt, kann die andere Anwendung ohne Datenverlust übernehmen.

Verwendete Appliances:

• "insslr" - redundanter Eingabe-Gateway für Benutzerabfragen
• admin - Eingabe-Gateway für Protokolldateizugriff
• sw - Umleitungs-Port 8080 von admin an ui auf db
• repl_in - Eingabe für die Remote-Anwendung für die Verbindung mit der db-Appliance zur Replikation der Datenbank
• web_lb - Web-Lastenausgleichsmodul für Benutzeranfragen
• "web1", "web2" - Webserver mit aktivem Inhalt (z. B. CGI-Skripte)
• db - MYSQLR64 für gleichzeitig einen Master und einen Slave konfiguriert
• "content" - Speicher für Datenbank-Fehlerprotokolldateien, Webinhalt und Webprotokolle
• logs - Speicher für Datenbank-Fehlerprotokolldateien
• repl_out - Ausgabe-Gateway für die db-Appliance für die Verbindung mit der Remote-Anwendung zur Replikation der Datenbank
• mon - MON-Appliance

Clientanfragen treffen auf dem Insslr-Gateway ein. Das Gateway leitet die Anfrage an das Lastenausgleichsmodul "web_lb" weiter, das die Anfrage an den Webserver "web1" oder "web2" leitet.

Die Webserver greifen auf die db-Datenbank zu. Die Db-Appliance stellt eine Verbindung zur Remote-Anwendung her. Damit die Datenbank reproduziert werden kann, ist die Remote-Anwendung eine identische Kopie, wobei der einzige Unterschied in der "server_id" von "db" und der Netzwerkeinrichtung besteht.

Die Remote-Anwendung ist mit der db-Appliance über das Gateway "repl_in" verbunden, das so konfiguriert ist, dass nur die Verbindung vom Gateway "repl_out" der Remote-Anwendung möglich ist. Die db-Appliances in den beiden Anwendungen werden in einer Master-Master-Einrichtung ausgeführt, sodass sie immer über identische Daten verfügen.

Beispiel für eine Eigenschaftskonfiguration

Eigenschaften, die nicht aufgelistet werden, sollten mit den Standardwerten belassen werden. Webzugriff auf db ist über den admin-Gateway auf Port 8080 verfügbar.

insslr

db

Wichtig! Nur eine der Anwendungen ist jederzeit aktiv, die andere wird einfach für Failover ausgeführt und verwendet, wenn die aktive Anwendung fehlschlägt.

Hinweise:

• INSSLR2 unterstützt HTTP 1.0 und HTTP 1.1. Wenn der Client sich jedoch als MSIE identifiziert, wird die HTTP 1.1-Unterstützung für diese Verbindung deaktiviert. So werden Fehler in einigen MSIE-Versionen vermieden.
• Wenn der Client nicht MSIE ist, unterstützt INSSLR2 HTTP 1.1 für den Client. (einschließlich mehrerer Anfragen pro TCP-Sitzung). Dies tritt auch dann auf, wenn der verwendete Backend-Server nur HTTP 1.0 unterstützt.
• INSSLR2 unterstützt einen einzelnen externen IP, daher kann nur ein einzelnes SSL-Zertifikat verwendet werden.

In der Appliance verwendete Open Source- und Drittanbietersoftware

INSSLR2 verwendet zusätzlich zu den Drittanbieter-Open-Source-Paketen der jeweiligen Basisklasse LUX6 die folgenden Drittanbieter-Open-Source-Pakete.