|
|
|
Aktuelle Version: 2.0.2-1
|
Auf einen Blick |
|
|
Katalog |
System |
|
Kategorie |
Gateways |
|
Benutzer-Volumes |
ja |
|
Min. Speicher |
160 M |
|
Betriebssystem |
Linux |
|
Einschränkungen |
no |
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:
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 (CA Technologies) 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 3Tera 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:
Wenn INSSLR im redundanten Modus ausgeführt wird, wird eine Schnittstelle auf dem zugehörigen Terminal "ctl" bereitgestellt, um:
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 Dienst angezeigt werden müssen, können Sie INSSLR so konfigurieren, dass Nicht-HTTP-Datenverkehr transparent an einen separaten Ausgabe-Terminal geleitet wird. Für solche Verbindungen fungiert die Appliance als Layer-3-Firewall/NAT-Router.
Ressourcen
|
Ressource |
Minimum |
Maximum |
Standard |
|
CPU |
0.05 |
4 |
0.05 |
|
Speicher |
160 M |
2 G |
160 M |
|
Bandbreite |
1 Mbit/s |
2 Gbit/s |
200 Mbit/s |
Der Standardspeicher für die CA 3Tera AppLogic 2.7-Version wurde in 128 MB geändert. Der minimale Speicher bleibt 64 MB.
Hinweise
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
|
Name |
dir |
gesch. |
Beschreibung |
|
ctl |
in |
HTTP |
Erhalten von Benachrichtigungen, wodurch die Appliance primary/Sicherungs-Appliance wird. Dieses Terminal akzeptiert Verbindungen nur dann, wenn "fover_mode" auf "none" gesetzt ist. Eine gültige HTTP-Anfrage sieht folgendermaßen aus: /?action=<active|passive|kill|status>. Mit "active/passive" wird die Appliance aktiv bzw. passiv. Hinweis: Dieser Vorgang kann fehlschlagen (wenn der andere Knoten nicht aktiv ist und Failover nicht durchgeführt werden kann), und kein Fehler wird zurückgegeben. Die aufrufende Anwendung muss den Status der Appliance mithilfe der Anfrage /?action=status überprüfen. Der Status gibt den aktuellen Status der Appliance zurück (aktiv/passiv). kill bewirkt ein erzwungenes Herunterfahren der Appliance, das zur Übernahme durch den anderen Knoten führt (falls dieser läuft). |
|
http |
out |
HTTP |
HTTPS und/oder HTTP-Anfragen, die über die konfigurierte externe IP-Adresse eingehen, werden an das Ausgabe-HTTP als einfache HTTP-Anfragen auf dem standardmäßigen HTTP-Port 80 geleitet. Zusätzlich zu den vom Client bereitgestellten HTTP-Headern enthalten die weitergeleiteten Anfragen auch die folgenden Informations-Header: X-Forwarded-For: die IP-Adresse des Remote-Client. Dies muss von den serverseitigen CGI-Skripten anstelle der Remote-IP-Adresse verwendet werden. X-Forwarded-Proto: https Dieser Header ist vorhanden, wenn der Client eine Verbindung über HTTPS hergestellt hat. Die Backend-Anwendung hat die Aufgabe, anhand dieses Headers zwischen HTTP- und HTTPS-Verbindungen zu unterscheiden. |
|
fs |
out |
NFS |
Liefert eine NFS-Bereitstellung als alternativen Speicherort zum lokalen Schlüssel-Volume für das Speichern von Schlüsseln. Wenn sowohl das lokale Schlüssel-Volume als auch eine Verbindung mit dem Terminal "fs" bereitgestellt werden, startet die Appliance nicht. Dieses Terminal kann unverbunden gelassen werden. |
|
aux |
out |
Alle |
Ausgabe für andere Protokolle, wenn konfiguriert - siehe die Eigenschaften "l3_accept_*". |
|
nfy |
out |
HTTP |
Sendet Benachrichtigungen, wenn ein Failover auftritt. Siehe auch fover_nfy_prefix. Dieses Terminal kann unverbunden gelassen werden. |
|
mon |
out |
CCE |
Sendet Leistungs- und Ressourcenverwendungsstatistik. |
Eigenschaften
|
Name |
type |
Beschreibung |
|
ip_addr |
ip_owned |
externe IP-Adresse des Gateways. Diese Eigenschaft hat keinen Standardwert und muss festgelegt werden. Standard: (leer) |
|
netmask |
IP-Adresse |
Netzmaske. Diese Eigenschaft hat keinen Standardwert und muss festgelegt werden. Standard: (leer) |
|
gateway |
IP-Adresse |
Standard-Gateway für ausgehenden Datenverkehr. Standard: (leer) |
|
l7_accept |
enum |
Dies gibt an, welche Arten von HTTP-Datenverkehr für die Weiterleitung an das HTTP-Terminal akzeptiert werden. Zulässige Werte: "https", "http", "both", "none". Wenn "none" festgelegt ist, wird der gesamte Datenverkehr nur gemäß den Eigenschaften für l3_accept_* umgeleitet. |
|
l3_accept_proto |
enum |
Gibt an, welche Protokolle zum aux-Terminal weitergeleitet werden sollen. Zulässige Werte: "none", "tcp", "udp", "raw", "all". |
|
l3_accept_port |
string |
Eine durch Kommas (oder ein Leerzeichen) getrennte Liste von Protokollen, um das durch l3_accept_proto angegebene Protokoll an das Terminal "aux" umzulenken; Protokolle in der Liste können entweder als Portnummern oder als standardmäßige Protokollnamen angegeben werden (zum Beispiel, ftp, smtp und so weiter) bei Verwendung von tcp/udp-Ports oder gre, tcp und so weiter bei Verwendung von RAW-Protokollen). Es können auch Port-Bereiche angegeben werden (1024:10000, 0:1024). Wenn dies leer gelassen wird, werden alle Ports des angegebenen Protokolls weitergeleitet. |
|
allowed_hosts |
String |
Liste von Hosts und/oder Teilnetzen, die Verbindungszugriff haben. Trennen Sie mehrere Einträge mit Leerzeichen oder Kommas. Beispiel für das unterstützte Format: 192.168.1.2 192.168.1.0/24 192.168.2.0/255.255.255.0. Standard: 0.0.0.0/0 (alle erlaubt). |
|
key_on_fs |
string |
Gibt an, ob Schlüssel auf einem nfs-Mount über das fs-Terminal (on) oder auf dem lokalen Schlüsselvolume (off) gespeichert werden. Zulässige Werte: on und off. Standard: "off" |
|
cert_file |
string |
Dateiname (relativ zum Daten-Volume-Stamm) des Serverzertifikats, das diese Gateway-Instanz dem Client überreichen muss. Hinweis: Ein zulässiges Zertifikat muss auf dem konfigurierten Daten-Volume (siehe "Volumes" unten) an dem von dieser Eigenschaft angegebenen Speicherort vorhanden sein, wenn Sie "l7_accept" auf "https" oder "both" festlegen, andernfalls kann INSSLR nicht gestartet werden. |
|
unsafe_ssl |
string |
Aktiviert die Verwendung von unsicheren SSL-Chiffren für die Kompatibilität mit älteren Browsern. Mit dem Standardwert "disabled" werden SSLv2-Chiffren sowie einige andere SSLv3- und TLSv1-Chiffren, die nicht als sicher gelten, deaktiviert. Es wird empfohlen, die Einstellung dieser Eigenschaft auf "disabled" zu belassen und nur dann zu ändern, wenn für ältere Browser, die nur mit SSLv2 funktionieren, https-Sitzungen unterstützt werden müssen. Bei Aktivierung von "enabled" können alle verfügbaren SSL-Chiffren auf dem System (einschließlich SSLv2) für https-Sitzungen verwendet werden. |
|
keepalive |
int |
Geben Sie die größtmögliche Keepalive-Zeit zwischen INSSLR und dem Client an (angegeben in Sekunden). Standard: 15. |
|
Zeitlimit |
int |
Gibt an, wie viele Sekunden INSSLR auf eine Ausgabe vom Backend-Server wartet. Wenn der Backend-Server über die für die Zeitüberschreitung festgelegte Anzahl von Sekunden hinweg keine Ausgabe sendet, wird die Verbindung geschlossen. |
|
max_request_size |
int |
Größtmögliche Größe (in MB) der Clientanfrage. Erhöhen Sie den Wert, wenn Ihre Anwendung große Client-Uploads verarbeitet. Standard: 10. |
|
adv_config |
string |
Fügt eine Rohkonfiguration hinzu, die in die nginx-conf innerhalb der location-Blöcke für sowohl http- als auch https-Listener (je nachdem, welcher aktiviert ist) einzufügen ist. Um zum Beispiel benutzerdefinierte Header hinzuzufügen, legen Sie "adv_config" auf "proxy_set_header myport $proxy_port;" fest. Dies fügt myport: 80 zur an den Backend-Server gesendeten Anfrage hinzu. "adv_config" kann auf eine beliebige zulässige Anweisung für einen location-Block festgelegt werden (sehen Sie in der nginx-Dokumentation nach für mehr Details). Sie können mehrere durch ; abgetrennte Konfigurationszeilen hinzufügen. Falls festgelegt, muss diese Eigenschaft eine zulässige nginx-Syntax aufweisen (die mit ; endet), oder die Appliance kann nicht gestartet werden. Standard: (leer) |
|
client_cert |
string |
Aktiviert die Client-Zertifikatsauthentifizierung. Zulässige Werte: on, ask und off. Wenn auf "on" festgelegt, wird die Client-Zertifikatsauthentifizierung erzwungen und nur Clients mit zulässigen Zertifikaten können eine erfolgreiche Anfrage an INSSLR stellen. Wenn auf "ask" festgelegt, werden Clients zum Vorlegen von Zertifikaten aufgefordert, aber die Verbindung wird auch hergestellt, wenn kein zulässiges Zertifikat vorgelegt wird. Standard: "off" |
|
client_depth |
int |
Die Tiefe der Prüfung für ein verkettetes Client-Zertifikat. Diese Eigenschaft hat keine Auswirkungen, wenn "client_cert" nicht festgelegt ist. Werte: 1 bis 9. Standard: 1 |
|
ca_list_client |
string |
Eine Datei, die eine Sequenz von CA Technologies-Zertifikaten im PEM-Format enthält. Die Namen der aufgelisteten CA Technologies-Zertifikate werden an den verbundenen Client gesendet. Dies informiert den Client, welches Client-Zertifikat gesendet werden soll. Die gleiche Liste wird für das Überprüfen des Client-Zertifikats verwendet. Der Dateiname ist relativ zum Stamm des geladenen Schlüsselvolumes oder zum Stamm des nfs-Mounts, der über das fs-Terminal vorgenommen wurde, und kann einen Pfad enthalten, zum Beispiel path/to/keys/ca_list_client.pem. Standard: ca_list_client.pem. |
|
cert_revocation_list |
string |
Eine Datei, die die Zertifikatsaufhebungsliste (CRL), wie von CA generiert, enthält. Diese Liste identifiziert von CA aufgehobene Client-Zertifikate. Es wird nach jedem bei INSSLR vorgelegten Client-Zertifikat gesucht und, wenn das Zertifikat aufgehoben wurde, gibt INSSLR eine "SSL-Zertifikatsfehler"-Antwort an den Client aus. Wie bei "ca_list_client" ist der Dateiname relativ zum Stamm des geladenen Schlüsselvolumes oder zum Stamm des nfs-Mounts, der über das fs-Terminal vorgenommen wurde, und kann einen Pfad enthalten, zum Beispiel path/to/keys/ca_list_client.pem. Standard: "".) |
|
Name |
type |
Beschreibung |
|
healthcheck_method |
String |
Die Methode, die für die Systemintegritätsprüfung der Backend-Webserver verwendet wird. |
|
healthcheck_url |
String |
Die URL, die verwendet wird, um die Systemintegritätsprüfung der Backend-Webserver mit den Systemintegritätsprüfungs-Methoden "http_get" und "http_head" durchzuführen. Sie kann als eine vollständige URL (http://host.name/file/to/check/for.php) oder als ein relativer Pfad (/file/to/check/for.php) angegeben werden. Wenn eine URL angegeben wird, verwendet INSSLR das HTTP/1.1-Protokoll während der Durchführung der Systemintegritätsprüfungen und setzt den aus UR extrahierten Hostnamen im Header Host: ein. Dies ermöglicht die Verwendung von virtuellen Hosts. Wenn sie als ein relativer Pfad angegeben wird, verwendet INSSLR das HTTP/1.0-Protokoll und sucht nach dem von dieser Eigenschaft angegebenen Dokument. |
|
healthcheck_agent |
String |
Zeichenfolge, die als Agentbezeichner für die Methoden http_get und http_head der Systemintegritätsprüfung verwendet wird |
|
healthcheck_regexp |
String |
Eine für den http_head- und http_get-Systemintegritätsprüfungs-Modus verwendete Testzeichenfolge. Kurze oder häufig vorkommende Werte (z. B. OK) ergibt wahrscheinlich falsche positive Übereinstimmungen. Diese Zeichenfolge ist ein regulärer Perl-Ausdruck, mehr Details über reguläre Perl-Ausdrücke sind hier verfügbar. |
|
healthcheck_interval |
Int. |
Intervall zwischen Systemintegritätsprüfungen der Backend-Webserver (in Sekunden angegeben). |
|
healthcheck_timeout |
Int. |
Die maximale Zeit in Sekunden, die eine Systemintegritätsprüfung dauern kann. Wenn die Zeitüberschreitung erreicht wird, wird die Überprüfung als fehlgeschlagen beachtet und beendet (eine neue Überprüfung wird gestartet). Standard: 10. |
|
healthcheck_alert |
Int. |
Anzahl von aufeinanderfolgenden Systemintegritätsprüfungs-Fehlern, nach denen INSSLR anfängt, Fehler auf dem Grid-Dashboard auszugeben. Wenn "0" festgelegt ist, werden keine Fehler im Dashboard angezeigt (aber die Systemintegritätsprüfungen sind noch aktiviert). Legen Sie diesen Wert nicht zu niedrig fest, um unnötige Fehlermeldungen beim Starten/Beenden der Anwendung zu vermeiden. Lesen Sie auch unter "fover_on_healthcheck" nach, wenn Sie INSSLR im redundanten Modus ausführen möchten und im Fall eines Fehlers des Backend-Servers auf den Sicherungsknoten umschalten möchten. Standard: 3. |
|
fover_mode |
String |
Failover-Modus. Mögliche Werte sind "none" (kein Failover), "symmetric" und "asymmetric". |
|
fover_local_ip |
IP- Adresse |
Lokale IP-Adresse, die im Failover-Modus für die Kommunikation mit der anderen INSSLR-Appliance verwendet wird. Dies kann eine beliebige verfügbare IP sein, einschließlich einer reservierten privaten Adresse (wie von rfc1918 definiert). Diese Adresse wird nur für die Überwachung des Status der anderen INSLLR-Appliance verwendet. Dies sollte auf die gleiche IP wie die fover_remote_ip-Eigenschaft der anderen INSSLR-Appliance festgelegt werden. Lassen Sie dies leer, wenn Sie fover_mode auf "none" festgelegt haben. |
|
fover_remote_ip |
IP-Adresse |
Remote-IP-Adresse der anderen INSSLR-Appliance, die im Failover-Modus verwendet wird. Wichtig! Dies sollte auf die gleiche IP wie die fover_local_ip-Eigenschaft der anderen INSSLR-Appliance festgelegt werden. Lassen Sie dies leer, wenn Sie fover_mode auf "none" festgelegt haben. |
|
fover_netmask |
IP-Adresse |
Netzmaske für fover_local_ip. |
|
fover_nfy_prefix |
String |
URL-Präfix, das angefordert wird, wenn ein Failover auftritt. Die angeforderte URL lautet 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 und passiert das nfy-Terminal. |
|
fover_on_healthcheck |
Int. |
Geben Sie an, ob INSSLR ein Failover zum Sicherungsknoten vornehmen sollte, wenn eine Systemintegritätsprüfung auf dem http-Terminal fehlschlägt. Wenn dies auf einen Wert ungleich Null festgelegt wird, nimmt INSSLR einen Failover nach der durch diesen Wert festgelegten Anzahl an Systemintegritätsprüfungen vor. Legen Sie diesen Wert nicht zu niedrig fest, um unnötige Fehlermeldungen beim Starten/Beenden der Anwendung zu vermeiden. Lesen Sie auch unter "healthcheck_alert" nach, wenn Sie nur Benachrichtigungen für Fehler benötigen. Standard: 0 (deaktiviert). |
Volumes
|
name |
Beschreibung |
|
key |
Ein schreibgeschütztes Daten-Volume (Platzhalter), das mindestens den SSL-Serversignaturschlüssel enthält. Die Datei sollte im PEM-Format vorliegen. Das Zertifikat sollte sich im Stammverzeichnis des Schlüsselvolumes (server.pem) befinden, es sei denn, die cert_file-Eigenschaft wurde in einen anderen Namen geändert. |
Fehlermeldungen
Im Fall von Appliance-Startfehlern können die folgenden Fehler im Systemprotokoll protokolliert werden:
|
Fehlermeldung |
Beschreibung |
|
Fehler: SSL-Serverzertifikat [cert_file] kann nicht gefunden werden |
SSL-Serverzertifikat, wie von der cert_file-Eigenschaft angegeben, kann nicht gefunden werden. Geben Sie einen zulässigen Zertifikatspfad an oder deaktivieren Sie sichere HTTP-Anfragen durch Festlegen von "l7_accept" auf "http" oder "none". |
|
Fehler: Der private RSA-Schlüssel ist kennwortgeschützt |
Das SSL-Serverzertifikat ist kennwortgeschützt; Sie benötigen ein Zertifikat, das nicht kennwortgeschützt ist. |
|
Fehler: Ungültiger Wert [client_cert] für client_cert |
Zulässige Werte sind "on", "off" und "ask". |
|
Fehler: Ungültiger Wert [client_depth] für client_depth |
Zulässige Werte sind 1-9. |
|
Fehler: CA Technologies-Clientliste [ca_list_client] kann nicht gefunden werden |
CA Technologies-Clientliste kann nicht gefunden werden. Geben Sie eine CA Technologies-Clientliste an, oder deaktivieren Sie Client-Zertifikate durch das Festlegen von client_cert auf "off". |
|
Fehler: Sie haben das RAW-Protokoll l3 angegeben, aber keine Protokollnummer (l3_accept_port) |
Beim Festlegen von "l3_accept_proto" auf "raw" ist die l3_accept_port-Eigenschaft erforderlich. |
|
Fehler: Ungültiger Wert für Eigenschaft [Eigenschaft]: [Wert] |
Der Wert für die Eigenschaft ist nicht zulässig. |
|
Fehler: Der minimal benötigte Speicher bei der Ausführung im redundanten Modus beträgt 100 MB |
Bei der Ausführung im redundanten Modus ("fover_mode" ist nicht "none") beträgt der minimal benötigte Speicher 100 MB. |
|
Fehler: Failover für Systemintegritätsprüfung ist aktiviert, aber die Appliance wird nicht im redundanten Modus ausgeführt |
Failover für Systemintegritätsprüfung ist aktiviert (fover_on_healthcheck > 0), aber die Appliance wird nicht im redundanten Modus ausgeführt ("fover_mode" ist "none"). |
|
Fehler: healthcheck_url muss festgelegt werden, wenn healthcheck_method "http_get" oder "http_head" lautet |
Die Eigenschaft "healthcheck_url" sollte nicht leer sein, wenn healthcheck_method "http_get" oder "http_head" lautet. |
|
Fehler: healthcheck_regexp muss festgelegt werden, wenn healthcheck_method "http_get" oder "http_head" lautet. |
Die Eigenschaft "healthcheck_regexp" sollte nicht leer sein, wenn healthcheck_method "http_get" oder "http_head" lautet. |
|
Fehler: Failover für Systemintegritätsprüfung ist aktiviert, aber Systemintegritätsprüfung ist deaktiviert |
Failover für Systemintegritätsprüfung ist aktiviert (fover_on_healthcheck > 0), aber Systemintegritätsprüfung ist nicht aktiviert (healthcheck_method ist "off"). |
|
Fehler: Ungültiger Wert [healthcheck_method] für healthcheck_method |
Zulässige Werte sind off, tcp_connect, http_get, http_head. |
|
Fehler: Firewall-Konfiguration fehlgeschlagen |
Fehler beim Starten von Firewall; prüfen Sie die Werte von 3_accept_proto, l3_accept_port, l3_accept_proto, allowed_hosts, l7_accept. |
|
Fehler: Fehler bei der Konfiguration von Nginx |
Fehler bei der Konfiguration des nginx-Service; prüfen Sie die adv_config-Eigenschaft, falls Sie sie verwenden. |
|
Fehler: Systemintegritätsprüfung konnte nicht gestartet werden |
Fehler beim Starten von Systemintegritätsprüfung; prüfen Sie die healthcheck_-Eigenschaften. |
|
Fehler in Systemintegritätsprüfung-URL: [url] |
Die angegebene healthcheck_url ist nicht zulässig. |
|
Fehler: Das Heartbeat-Signal konnte nicht gestartet werden |
Der Heartbeat-Service 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).
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:
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!
Die Zeitüberschreitung für die HTTP-Anfrage beträgt 5 Sekunden, sodass das Failover nicht verlangsamt wird.
INSSLR führt eine grundlegende Überprüfung auf seinem HTTP-Terminal durch. Fehler werden auf dem Grid-Dashboard gemeldet (bei maximaler Rate von 1 pro 10 Minuten). Wenn INSSLR im redundanten Modus ausgeführt wird und für fover_on_healthcheck ein Wert festgelegt wird, der nicht Null ist, versucht INSSLR, nach der Anzahl fehlgeschlagener Systemintegritätsprüfungen für fover_on_healthcheck ein Failover auf der Sicherungs-Appliance durchzuführen. Das Failover schlägt u. U. fehl, wenn die INSSLR-Sicherungs-Appliance nicht ausgeführt wird oder nicht korrekt konfiguriert ist.
Wichtig! Wenn Sie für fover_on_healthcheck den Wert 1 festlegen, führt INSSLR ein Failover bei jeder fehlgeschlagenen Systemintegritätsprüfung durch, was nicht immer wünschenswert ist. Mithilfe eines höheren Werts werden Falschmeldungen (wie beim Anhalten der Anwendung) vermieden.
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.
Serverzertifikate generieren
Mit CA 3Tera AppLogic können Sie Serverzertifikate generieren.
Generieren von Serverzertifikaten
openssl genrsa -out privkey.pem 2048
Um einen kennwortgeschützten Schlüssel zu generieren, verwenden Sie den folgenden Befehl (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 vor der Verwendung in INSSLR entfernen):
openssl genrsa -des3 -out privkey.pem 2048
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.
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.
Das folgende Beispiel zeigt, wie Sie Ihren eigenen CA Technologies erstellen und sie zum Unterzeichnen eigener Zertifikate mit OpenSSL verwenden können. Dies wurde mithilfe von OpenSSL 0.9.8b getestet, die gleiche Version, die in INSSLR 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.
Erstellen einer Zertifizierungsstelle
mkdir CA mkdir CA/private
openssl genrsa -des3 -out CA/private/CA_key.pem 2048
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 3Tera AppLogic können Sie Client-Zertifikate erstellen, die von der Zertifizierungsstelle unterschrieben werden.
Erstellen eines von der Zertifizierungsstelle unterschriebenen Client-Zertifikats
openssl genrsa -out clientA_privkey.pem 2048
openssl req -new -key clientA_privkey.pem -out clientA_request.csr
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:
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
cat clientA_privkey.pem clientA.cer > clientA.pem
openssl pkcs12 -export -in clientA.cer -inkey clientA_privkey.pem -out clientA.p12
Widerrufen der von der Zertifizierungsstelle signierten Client-Zertifikate
So widerrufen Sie ein von der Zertifizierungsstelle herausgegebenes Client-Zertifikat:
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 certificate revocation list (Certificate Revocation List, CRL) neu:
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 3Tera AppLogic können Sie Zertifizierungsstellen-Listendateien erstellen, die von INSSLR verwendet werden.
Erstellen der von der Eigenschaft "ca_list_client" identifizierten Datei
cat CA/private/CA_key.pem CA/CA_cert.pem > ca_list_client.pem
openssl s_client -host IP-address -port 443 -showcerts -ssl3 -cert clientA.cer -key clientA_privkey.pem -state
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:
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).
|
Eigenschaft |
Value |
Hinweise |
|
l7_accept |
http/https/both |
Gibt an, welches l7-Protokoll verwendet wird. Hinweis: Wenn https oder beides festgelegt ist, muss das Schlüssel-Volume das SSL-Zertifikat enthalten, das mit der Eigenschaft "cert_file" festgelegt wurde. |
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.
|
Eigenschaft |
Value |
Hinweise |
|
l7_accept |
http/https/both |
Gibt an, welches l7-Protokoll verwendet wird. Hinweis: Wenn https oder beides festgelegt ist, muss das Schlüssel-Volume das SSL-Zertifikat enthalten, das mit der Eigenschaft "cert_file" festgelegt wurde. |
|
l3_accept_proto |
tcp |
Tcp-Ports 25.110.143 an Terminal "aux" umleiten. |
|
l3_accept_port |
25.110.143 |
Tcp-Ports 25.110.143 an Terminal "aux" umleiten. |
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.
|
Eigenschaft |
Value |
Hinweise |
|
l7_accept |
http/https/both |
Gibt an, welches l7-Protokoll verwendet wird. Hinweis: Wenn https oder beides festgelegt ist, muss das Schlüssel-Volume das SSL-Zertifikat enthalten, das mit der Eigenschaft "cert_file" festgelegt wurde. |
|
l3_accept_proto |
all |
Leiten Sie den geamten IP-Datenverkehr (ausgenommen ICMP), der nicht an das HTTP-Terminal übergeben wird, an das Terminal "aux" weiter. |
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:
INSSLR auf primärer Anwendung:
|
Eigenschaft |
Value |
Hinweise |
|
ip_addr |
1.2.3.4 |
Öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
netmask |
255.255.0.255.0 |
Netzmaske für die öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
gateway |
1.2.3.254 |
Gateway für die öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
fover_mode |
asymmetric |
Ausführung im asymmetrischen Modus, da die Sicherungsanwendung nur verwendet werden soll, wenn die primäre Anwendung ausgefallen ist. |
|
fover_local_ip |
192.168.100.1 |
Private IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. Die lokale IP-Adresse ist niedriger als die Remote-Adresse, daher ist dies die primäre Appliance, solange sie ausgeführt wird. |
|
fover_remote_ip |
192.168.100.2 |
Remote-IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. |
|
fover_netmask |
255.255.0.255.0 |
Netzmaske für fover_local_ip. |
INSSLR auf Sicherungsanwendung:
|
Eigenschaft |
Value |
Hinweise |
|
ip_addr |
1.2.3.4 |
Öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
netmask |
255.255.0.255.0 |
Netzmaske für die öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
gateway |
1.2.3.254 |
Gateway für die öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
fover_mode |
asymmetric |
Ausführung im asymmetrischen Modus, da die Sicherungsanwendung nur verwendet werden soll, wenn die primäre Anwendung ausgefallen ist. |
|
fover_local_ip |
192.168.100.2 |
Private IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. |
|
fover_remote_ip |
192.168.100.1 |
Remote-IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. |
|
fover_netmask |
255.255.0.255.0 |
Netzmaske für fover_local_ip. |
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
|
Eigenschaft |
Value |
Hinweise |
|
ip_addr |
1.2.3.4 |
Öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
netmask |
255.255.0.255.0 |
Netzmaske für die öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
gateway |
1.2.3.254 |
Gateway für die öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
fover_mode |
symmetric |
Im symmetrischem Modus ausführen. |
|
fover_local_ip |
192.168.100.1 |
Private IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. |
|
fover_remote_ip |
192.168.100.2 |
Remote-IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. |
|
fover_netmask |
255.255.0.255.0 |
Netzmaske für fover_local_ip. |
in2
|
Eigenschaft |
Value |
Hinweise |
|
ip_addr |
1.2.3.4 |
Öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
netmask |
255.255.0.255.0 |
Netzmaske für die öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
gateway |
1.2.3.254 |
Gateway für die öffentliche IP-Adresse der Anwendung, muss für die primäre und die Sicherungsanwendung gleich sein. |
|
fover_mode |
symmetric |
Im symmetrischem Modus ausführen. |
|
fover_local_ip |
192.168.100.2 |
Private IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. |
|
fover_remote_ip |
192.168.100.1 |
Remote-IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. |
|
fover_netmask |
255.255.0.255.0 |
Netzmaske für fover_local_ip. |
db1
|
Eigenschaftsname |
Value |
Hinweise |
|
auto_create |
1 |
Datenbank erstellen, wenn die Volumes leer sind. |
|
server_id |
1 |
Masterserver 1, muss von der Remote-Anwendung abweichen |
|
rpl_mode |
master_and_slave |
Master und Slave |
db2
|
Eigenschaftsname |
Value |
Hinweise |
|
auto_create |
1 |
Datenbank erstellen, wenn die Volumes leer sind. |
|
server_id |
2 |
Masterserver 1, muss von der Remote-Anwendung abweichen |
|
rpl_mode |
master_and_slave |
Master und Slave |
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:
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 beodem 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
|
Eigenschaft |
Value |
Hinweise |
|
ip_addr |
1.2.3.4 |
Öffentliche IP-Adresse der Anwendung, muss für beide Anwendungen gleich sein. |
|
netmask |
255.255.0.255.0 |
Netzmaske für die öffentliche IP-Adresse der Anwendung, muss für beide Anwendungen gleich sein. |
|
gateway |
1.2.3.254 |
Gateway für die öffentliche IP-Adresse der Anwendung, muss für beide Anwendungen gleich sein. |
|
fover_mode |
symmetric |
Im symmetrischem Modus ausführen. |
|
fover_local_ip |
192.168.100.1 |
Private IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. Ändern Sie diese in 192.168.100.2 auf der Remote-Anwendung. |
|
fover_remote_ip |
192.168.100.2 |
Remote-IP-Adresse, die für die Kommunikation zwischen INSSLR-Appliances in den zwei Anwendungen verwendet werden soll. Ändern Sie diese in 192.168.100.1 auf der Remote-Anwendung. |
|
fover_netmask |
255.255.0.255.0 |
Netzmaske für fover_local_ip. |
db
|
Eigenschaftsname |
Value |
Hinweise |
|
auto_create |
1 |
Datenbank erstellen, wenn die Volumes leer sind. |
|
error_log_filename |
db.error |
Name der Fehlerprotokolldatei, die auf dem Protokolldaten-Volume gespeichert werden soll. |
|
error_log_level |
Fehler |
Fehlerprotokollierungs-Ebene |
|
server_id |
1 |
Masterserver 1, muss auf der zweiten Anwendung abweichen |
|
rpl_mode |
master_and_slave |
Master und Slave |
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.
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 Drittanbieter-Software
INSSLR verwendet zusätzlich zu den Drittanbieter-/Open-Source-Paketen der jeweiligen Basisklasse LUX5 die folgenden Drittanbieter-/Open-Source-Pakete.
|
Software |
Version |
Geändert |
Lizenz |
Hinweise |
|
PyXML |
0.8.4-4 |
Nein |
Fourthought |
Nicht vorhanden |
|
gnutls |
1.4.1-2 |
Nein |
LGPLv2.1 |
Nicht vorhanden |
|
heartbeat |
2.1.3-3 |
Nein |
LGPLv2.1 |
Nicht vorhanden |
|
heartbeat-pils |
2.1.3-3 |
Nein |
LGPLv2.1 |
Nicht vorhanden |
|
heartbeat-stonith |
2.1.3-3 |
Nein |
LGPLv2.1 |
Nicht vorhanden |
|
iptables |
1.3.5-4 |
Nein |
GPLv2 |
Nicht vorhanden |
|
libgcrypt |
1.2.3-1 |
Nein |
GPLv2 |
Nicht vorhanden |
|
libgpg-error |
1.4-2 |
Nein |
LGPLv2.1 |
Nicht vorhanden |
|
lighttpd |
1.4.18-1 |
Nein |
BSD |
Nicht vorhanden |
|
nginx |
0.7.62-1 |
Ja |
BSD |
Nicht vorhanden |
|
sudo |
1.6.8p12-10 |
Nein |
BSD |
Nicht vorhanden |
|
telnet |
0.17-38 |
Nein |
BSD |
Nicht vorhanden |
| Copyright © 2011 CA. Alle Rechte vorbehalten. | Senden Sie CA Technologies eine E-Mail zu diesem Thema. |