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

INSSLR: Redundantes HTTP-Eingabe-Gateway mit SSL-Unterstützung

Sehen Sie sich das Video an

Aktuelle Version: 3.1.2-1

Funktionsübersicht

Die INSSLR-Appliance ist ein Layer-7-Gateway für sichere HTTP-Anfragen. Konvertiert die Anfragen in unverschlüsselte HTTP-Anfragen. Kann bei Bedarf verwendet werden, wenn auf der Clientseite sicheres HTTP unterstützt werden muss, die Backend-Verarbeitungsinfrastruktur aber SSL nicht unterstützt oder nicht unterstützen kann, einschließlich:

• 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/Entschlüsselung auf einem getrennten Server, um einen höheren Durchsatz zu erzielen

Sofern konfiguriert, unterstützt INSSLR 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 kann sich mit der Zertifizierungsstelle in Verbindung setzen, die das Zertifikat des Servers ausgegeben hat, und vor dem Fortfahren bestätigen, dass das Zertifikat authentisch ist. Der Server kann dies ebenfalls tun.

In seiner Standardkonfiguration fungiert INSSLR als Layer-7-Gateway für sichere HTTP-Anfragen und stellt einen Einstiegspunkt mit Firewall für Netzwerkverkehr in eine CA AppLogic®-Anwendung bereit, die mit einer über das Internet zugänglichen statischen IP-Adresse konfiguriert werden kann.

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

• Asymmetrisch - Eine Appliance ist die primäre Appliance. Wenn sie online ist, übernimmt sie die IP-Adresse und wird aktiv. Die Sicherungs-Appliance wird nur aktiv, wenn der Primärknoten fehlschlägt (oder angehalten wird). Wenn die primäre Appliance erneut verfügbar ist, übernimmt sie die IP-Adresse und wird aktiv. Die primäre Appliance ist die mit der kürzesten IP-Adresse (Zeichenfolgenvergleich), wie in der Eigenschaft "fover_local_ip" festgelegt.
• Symmetrisch - Beide Appliances sind primäre Appliances. Die Appliance, die zuerst gestartet wird, ü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 INSSLR im redundanten Modus ausgeführt wird, wird eine Schnittstelle auf dem zugehörigen Terminal "ctl" bereitgestellt, um:

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

INSSLR überwacht kontinuierlich den Integritätsstatus der Backend-Appliance, die an das HTTP-Terminal angeschlossen ist. Die von INSSLR durchgeführten Prüfungen des Integritätsstatus können eine einfache TCP-Verbindungsprüfung oder eine komplexere HTTP-Anfrage umfassen (auf der Begrenzung von INSSLR angegeben). Im Falle eines Fehlers der angeschlossenen Appliance sendet INSSLR eine Fehlermeldung an das Grid-Dashboard oder führt, wenn es sich im redundanten Modus befindet und entsprechend konfiguriert wurde, einen Failover auf die INSSLR-Sicherungs-Appliance durch.

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

Begrenzung

Ressourcen

Der Standardspeicher für die CA AppLogic® 2.7-Version wurde in 128 MB geändert. Der minimale Speicher bleibt 64 MB.

Hinweise

• Wenn Sie INSSLR im Failover-Modus verwenden (fover_mode ist ungleich "none"), ist der minimale Speicher 100 M.
• Die Speichermenge, die INSSLR 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

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 Daten-Freigabe konnten nicht festgelegt werden
• Samba konnte nicht gestartet werden
• NFS konnte nicht gestartet werden
• Apache konnte nicht gestartet werden

Leistung

Anwendungs-Failover

INSSLR entdeckt den Fehler des anderen INSSLR in ca. 10 Sekunden. Es dauert zusätzlich 10 Sekunden, bis ein Failover zur anderen Anwendung vorgenommen wird. Die Gesamtdauer vom ersten Anwendungsfehler bis zu dem Zeitpunkt, zu dem die andere Anwendung den Datenverkehr übernimmt, beträgt ca. 20 Sekunden.

Anforderungsrate

INSSLR leitet nicht weniger als 3000 Transaktionen (Anfrage/Antwort-Paare) pro Sekunde weiter, abhängig von Dokumentgröße und verfügbarer Netzwerkbandbreite.

Datendurchsatz

INSSLR leitet nicht weniger als 7 MB/Sekunde weiter, abhängig von Dokumentgröße und verfügbarer Netzwerkbandbreite

Gleichzeitige Verbindungen

Mit seinem Standardspeicher unterstützt INSSLR nicht weniger als 500 gleichzeitig ausstehende Anfragen. (Eine ausstehende Anfrage ist eine offene TCP-Verbindung vom Client, auf der ein oder mehr unvollständige HTTP-Anfragen vorhanden sind). Die maximale Zahl an gleichzeitigen Verbindungen hängt vom verfügbaren freien Speicher ab. Die Anzahl an gleichzeitigen http-Transaktionen wird pro 16 MB Speicher um 500 erhöht. Wenn Sie zum Beispiel den redundanten Modus aktiviert haben und gleichzeitig 2.000 Verbindungen bedienen möchten, benötigen Sie 100 MB + 3*= 148 MB (der Mindestspeicher für den redundanten Modus beträgt 100 MB).

Benachrichtigungen

Beim Ausführen im redundanten Modus (fover_mode is not none), gibt INSSLR bei Aktivität/Passivität Meldungen aus. Dies erfolgt beim Start des aktiven Knotens oder wenn ein Failover auftritt (jeder Knoten sendet eine Meldung, wenn er aktiv/passiv wird).

INSSLR sendet zwei Meldungen:

• Eine Meldung zum Grid-Dashboard: INSSLR appliance APP_NAME:COMP_NAME <acquired|gave up> resource ip_addr
• Eine HTTP-Anfrage über das Terminal "nfy". Die Empfangsseite muss anhand der Meldung Maßnahmen ergreifen. Die angeforderte URL ist:

  http://nfy/fover_nfy_prefixfover_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 Remote-Skripts ändern, das aufgerufen wird, oder/und zusätzliche Parameter hinzufügen. Beispielwerte für fover_nfy_prefix: /path/to/script.php?, /path/to/script.php?username=user&password=pass&.

Wichtig!

• Wenn Sie keine Standardwerte für fover_nfy_prefix verwenden, achten Sie darauf, dass diese mit ? enden, wenn fover_nfy_prefix der Pfad ist, oder mit &, wenn fover_nfy_prefix zusätzliche Parameter umfasst.
• Wenn ein Knoten nicht mehr verfügbar ist, wird u. U. keine Meldung gesendet, dass er passiv geworden ist, sondern dann sendet nur der Knoten, der aktiv wird, eine Meldung.
• Die Zeitüberschreitung für die HTTP-Anfrage beträgt 5 Sekunden, sodass das Failover nicht verlangsamt wird.

Systemintegritätsprüfung

INSSLR 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 obigen 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 Appliance-Start werden keine Fehler angezeigt (um Fehlalarme zu verhindern, wenn der andere Knoten in der Replikation 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 Datei gespeichert sein, die durch die Eigenschaft cert_file festgelegt ist.

Dieser Abschnitt enthält die folgenden Themen:

Serverzertifikate generieren

Verwenden von Serverzertifikaten

Verwenden vorhandener apache+mod_ssl-Serverzertifikate

Serverzertifikate generieren

Mit CA AppLogic® können Sie Serverzertifikate generieren.

Generieren von Serverzertifikaten

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

   openssl genrsa -out privkey.pem 2048 
   

   Um einen kennwortgeschützten Schlüssel zu generieren, verwenden Sie Folgendes (um den Schlüssel mit INSSLR zu verwenden, benötigen Sie einen Schlüssel ohne Kennwort, wenn Sie einen kennwortgeschützten Schlüssel erstellen, müssen Sie das Kennwort entfernen, bevor der Schlüssel in INSSLR verwendet wird):

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. Als nächstes benötigen Sie ein Zertifikat. Sie haben hier zwei Optionen: Erstellen Sie eine Zertifikatsanfrage, und lassen Sie sie von einer vertrauenswürdigen CA unterschreiben (kostenpflichtig), oder erstellen Sie ein automatisch signiertes Zertifikat zu Testzwecken. (In diesem Fall geben Browser, die Ihre Website anfragen, Warnungen aus, dass das Zertifikat von keiner vertrauenswürdigen CA unterschrieben wurde.)

   Um eine Zertifikatsanfrage zu generieren, führen Sie Folgendes 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.

3. Um ein automatisch signiertes Zertifikat zu generieren, führen Sie Folgendes aus:

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

Verwenden von Serverzertifikaten

Sie können das Zertifikat und den Schlüssel jetzt in einer Datei platzieren und in INSSLR verwenden:

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

Wenn Sie ein bereits vorhandenes Zertifikat in Apache verwenden, können Sie es auch in INSSLR verwenden. Stellen Sie sicher, dass der Schlüssel nicht kennwortgeschützt ist (siehe oben), und speichern Sie den privaten Schlüssel und das Zertifikat in dieser Reihenfolge in einer Datei.

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 vorübergehende Zertifikat in dieser Reihenfolge in einer Datei.

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 es die Appliance ihn ohne Ihre Hilfe lesen kann). Ergreifen Sie die notwendigen Maßnahmen, um die Schlüsseldatei zu schützen, wenn sie sie auf dem Daten-Volume installieren. Verwenden Sie dieses Daten-Volume nicht für andere Zwecke, und machen Sie es nicht für einen Webserver sichtbar, z. B. um Daten mit Webzugriff (HTML-Seiten, Skripte usw.) 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 INSSLR installiert ist.

Dieser Abschnitt enthält die folgenden Themen:

Zertifizierungsstelle erstellen

Von der Zertifizierungsstelle signierte Client-Zertifikate erstellen

Erstellen der von INSSLR verwendeten CA-Listen-Dateien

Client-Zertifikat-Header

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.

Erstellen einer Zertifizierungsstelle

1. Erstellen Sie auf einem sicheren Host-System ein Arbeitsverzeichnis und ein privates Verzeichnis innerhalb des Arbeitsverzeichnisses. Verwenden Sie dazu die folgenden Befehle:

   mkdir CA 
   mkdir CA/private 
   

2. Erstellen Sie einen kennwortgeschützten RSA-Schlüssel für die Zertifizierungsstelle mit einer Schlüssellänge von 2048 Bit:

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

• Erstellen Sie mit dem privaten Schlüssel das Zertifikat für öffentliche Schlüssel für die Zertifizierungsstelle:

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

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.

Von der Zertifizierungsstelle signierte Client-Zertifikate erstellen

Mit CA AppLogic® können Sie Client-Zertifikate erstellen, die von der Zertifizierungsstelle unterschrieben werden.

Erstellen eines von der Zertifizierungsstelle unterschriebenen Client-Zertifikats

1. Generieren Sie einen privaten RSA-Schlüssel (um einen kennwortgeschützten Schlüssel zu erstellen, verwenden Sie den -des3-Schalter):

   openssl genrsa -out clientA_privkey.pem 2048 
   

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 
   

Beachten Sie Folgendes:

• Der Schalter "-CAcreateserial-" aktiviert die Zuweisung eindeutiger Seriennummern für herausgegebene Zertifikate. Da es sich um das erste von der Zertifizierungsstelle herausgegebene Zertifikat handelt, wird die Datei "CA/CA_cert.srl" erstellt, um Seriennummernzuweisungen 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 pkcs12-Format (kann von den meisten Browser verwendet werden):

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

Erstellen der von INSSLR verwendeten CA-Listen-Dateien

Widerrufen der von der Zertifizierungsstelle signierten Client-Zertifikate

So widerrufen Sie ein von der Zertifizierungsstelle herausgegebenes Client-Zertifikat:

• 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 einer der folgenden sein: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold oder removeFromCRL. 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 INSSLR als Eigenschaft "cert_revocation_list" bereitgestellt 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 INSSLR verwendeten Zertifizierungsstellen-Listendateien

Mit CA AppLogic® können Sie Zertifizierungsstellen-Listendateien erstellen, die von INSSLR 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 .
3. Bei Bedarf kann das Serverzertifikat von INSSLR (z. B. server.pem) wie die Client-Zertifikate erstellt und ebenso von der erstellten Zertifizierungsstelle unterschrieben werden. Verwenden Sie für dieses Zertifikat kein Kennwort.
4. Wenn server.pem und ca_list_client.pem eingerichtet sind, können Sie die Client-Zertifikatauthentifizierung folgendermaßen testen:
   • Zum Testen von einem Browser importieren Sie ein Client-Zertifikat im pkcs12-Format in Firefox mithilfe von "Tools" (Extras) > "Options" (Optionen) > "View Certificates" (Zertifikate anzeigen) > "Your Certificates" (Eigene Zertifikate) > "Import" (Importieren). Richten Sie den Browser auf die IP-Adresse von INSSLR.
   • So testen Sie den SSL-Handshake von einem Remote-Host:

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

Client-Zertifikat-Header

Wenn ein Client sich über HTTPS mit INSSLR verbindet, und es sich um ein Client-Zertifikat handelt, fügt INSSLR 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 entscheidet, ob diese Header verwendet werden oder nicht. INSSLR gibt diese Informationen einfach weiter, ohne sie zu überprüfen (außer die Richtigkeit von Signatur und Verschlüsselung).

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.

Konfiguration für Webanwendungen

Bei den Konfigurationsbeispielen werden nur Eigenschaften aufgeführt, für die Nicht-Standardwerte festgelegt sind und die keine Netzwerkkonfiguration haben (ip_addr, netmask, gateway).

Webanwendungen mit Zusatzdiensten

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

Webanwendungen mit mehr als einem Zusatzdienst

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

Redundante Webanwendungen

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

Sicherungswebanwendung

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

Verwendete Appliances:

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

INSSLR auf primärer Anwendung:

INSSLR auf Sicherungsanwendung:

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 darin enthaltenen Appliances einfach verdoppeln und sie im redundanten Modus ausführen. Da dies bedeutet, dass (mindestens) zwei Webserver und zwei Datenbank-Appliances verwendet werden, werden sie alle im normalen Modus verwendet (Skalierbarkeit vorausgesetzt), aber jeder Server bzw. jede Appliance kann die Anwendung allein bedienen, wenn die andere Appliance fehlschlägt. 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 INSSLR- und einer HALB-Appliance, die sehr geringe Ressourcen benötigen) sich im aktiven Zustand befinden und keine Ressourcen für eine Sicherungsanwendung aufgewendet werden, die nur ausgeführt wird, 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 ausführen (allerdings auf separaten Servern, sodass sich der Ausfall bei einem Server nur auf eine der Anwendungen auswirkt), oder auf unterschiedlichen Grids, vorausgesetzt, auf die verwendete IP-Adresse kann von beiden Grids aus zugegriffen werden. Das nachstehende Beispiel zeigt eine Anwendung, die eine Datenbank-Appliance verwendet, die auch im redundanten Modus ausgeführt wird, sodass bei einem Ausfall einer Anwendung die andere Anwendung ohne Datenverlust übernehmen kann.

Verwendete Appliances:

• in1 - 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 (zum Beispiel 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

Clientanfrage kommt auf dem Gateway "in1" an. Die Gateway leitet die Anfrage an das Lastenausgleichsmodul "web_lb" weiter, das die Anfrage an einen der Webserver "web1" und "web2" leitet. Die Webserver greifen auf die db-Datenbank zu. Die db-Appliance ist mit der Remote-Anwendung verbunden (die eine identische Kopie ist, der einzige Unterschied besteht in der server_id von db und der Netzwerkeinrichtung), um die Datenbank zu replizieren. Die Remote-Anwendung ist mit der db-Appliance über das Gateway "repl_in" verbunden, das so konfiguriert ist, dass nur der Anschluss 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-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.

in1

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

INSSLR 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 (um Fehler in einigen MSIE-Versionen zu vermeiden).

Wenn der Client nicht MSIE ist, unterstützt INSSLR HTTP 1.1 für den Client (einschließlich mehrerer Anfragen pro TCP-Sitzung), auch wenn der Backend-Server nur HTTP 1.0 unterstützt.

INSSLR unterstützt einen einzelnen externen IP, daher kann nur ein einzelnes SSL-Zertifikat verwendet werden.

In der Appliance verwendete Open Source- und Drittanbietersoftware

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