Informations de référence › Manuel de référence du catalogue d'appliance › Catalogue système › Passerelles › INSSLR2 - Passerelle d'entrée HTTP redondante avec prise en charge SSL

INSSLR2 - Passerelle d'entrée HTTP redondante avec prise en charge SSL

Dernière version : 1.0.1-2

L'appliance INSSLR2 est une passerelle de couche 7 pour les requêtes HTTP sécurisées. Elle convertit les requêtes en requêtes HTTP non codées. Vous pouvez utiliser cette fonctionnalité pour prendre en charge les connexions HTTP sécurisées sur le client.

Toutefois, l'infrastructure de traitement d'arrière-plan ne peut pas prendre en charge SSL :

• car elle utilise un serveur HTTP rapide et léger sur lequel SSL n'est pas pris en charge
• car elle utilise plusieurs serveurs principaux, pour des raisons de performance ou de redondance, connectés via un commutateur à équilibrage de charge.
• car elle utilise plusieurs serveurs principaux, pour des fonctions dissociées, connectés via un commutateur URL.
• car elle décharge le chiffrement/déchiffrement SSL sur un serveur distinct pour accroître le débit.

Si elle est configurée pour, INSSLR2 prend également en charge l'authentification des certificats client. En cas d'authentification mutuelle SSL, le client et le serveur échangent leurs certificats et leurs clés publiques correspondantes. Le client et/ou le serveur peuvent contacter l'autorité de certification (CA) qui a publié le certificat et confirmer son authenticité avant de continuer.

Dans sa configuration par défaut, INSSLR2 est utilisée comme une passerelle de couche 7 pour des demandes HTTP sécurisées. Elle fournit également un point d'entrée derrière un pare-feu pour le trafic réseau dans une application. Vous pouvez la configurer avec une adresse IP statique accessible via Internet.

Si vous effectuez la configuration nécessaire, vous pouvez utiliser deux appliances INSSLR2 en mode de basculement pour fournir un service redondant. Dans ce cas, l'adresse IP d'INSSLR2 ne s'exécute que sur l'un des noeuds et est automatiquement transférée vers l'autre appliance INSSLR2 en cas d'échec. Une seule appliance INSSLR2 est active à la fois. En mode de basculement, vous pouvez configurer INSSLR2 pour qu'elle s'exécute en plusieurs modes :

• Asymétrique : une des appliances est l'appliance principale. Lorsque l'appliance principale est en ligne, elle prend l'adresse IP et devient active.

  En cas d'échec ou d'arrêt du noeud principal, l'appliance de sauvegarde devient active. Lorsque l'appliance principale redevient disponible, elle reprend l'adresse IP et devient active. L'appliance principale est celle disposant de l'adresse IP la plus basse (comparaison de chaîne), telle que définie dans l'interface fover.

• Symétrique : les deux appliances sont principales. La première appliance à démarrer prend l'adresse IP et devient active. L'autre appliance ne devient active que si la première échoue ou est arrêtée.

  Lorsque la première appliance redevient disponible, elle ne reprend pas automatiquement l'adresse IP.

En cas d'exécution en mode redondant, INSSLR2 fournit une interface sur son terminal ctl pour :

• forcer INSSLR2 à devenir l'appliance principale ;
• forcer INSSLR2 à devenir l'appliance de sauvegarde ;
• vérifier l'état de la passerelle INSSLR2 principale ou de sauvegarde.

INSSLR2 surveille constamment l'état d'intégrité de l'appliance principale connectée à son terminal http. Les contrôles de l'état d'intégrité réalisés par INSSLR2 peuvent inclure un simple test de connexion TCP ou une requête HTTP plus complexe spécifiée dans le périmètre d'INSSLR2.

En cas d'échec de l'appliance connectée, INSSLR2 renvoie une erreur dans le tableau de bord de grille ou, si elle est exécutée en mode redondant et configurée pour, elle bascule vers l'appliance INSSLR2 de sauvegarde.

Pour prendre en charge des applications qui doivent s'afficher à une adresse IP unique pour plusieurs services, configurez INSSLR2 pour diriger le trafic non HTTP de façon transparente vers un terminal de sortie distinct. Pour les connexions de ce type, l'appliance agit comme un routeur NAT/pare-feu de couche 3.

Périmètre

Ressources

Notes

• Lors de l'utilisation d'INSSLR2 en mode de basculement (fover_mode n'est pas Aucun), la mémoire minimum est de 192 Mo.
• La quantité de mémoire attribuée à INSSLR2 n'affecte pas son débit. Utilisez une plus grande quantité de mémoire uniquement pour prendre en charge plus de requêtes simultanées lorsque les serveurs principaux peuvent conserver les requêtes pour des périodes excessivement longues.

Terminaux

Propriétés

path/to/keys/ca_list_client.pem. 

path/to/keys/ca_list_client.pem. 

Propriétés de contrôle de l'intégrité

Propriétés avancées utilisées dans les scénarios de basculement

Volumes

Messages d'erreur

Les messages suivants peuvent s'afficher dans le fichier journal de l'appliance ou dans le journal système du contrôleur de grille lorsque l'appliance ne parvient pas à démarrer :

• Failed to mount data volume
• Failed to set permissions on the data share
• Samba failed to start
• NFS failed to start
• Apache failed to start

Performances

Basculement d'applications

INSSLR2 détecte l'échec de INSSLR2 dans les 10 secondes et requiert 10 autres secondes supplémentaires pour basculer vers l'autre application. La durée totale entre l'échec de l'application et la reprise du trafic sur l'autre application est d'environ 20 secondes.

Taux de requêtes

INSSLR2 n'achemine pas moins de 3000 transactions (paires requête/réponse) par seconde, en fonction de la taille de document et de la bande passante réseau disponible.

Débit des données

INSSLR2 n'achemine pas moins de 7 Mo/seconde, en fonction de la taille de document et de la bande passante réseau disponible.

Connexions simultanées

Avec sa mémoire par défaut, INSSLR2 prend en charge pas moins de 500 demandes en attente simultanément Une demande en attente étant une connexion TCP ouverte à partir du client, sur laquelle une ou plusieurs demandes HTTP sont en cours, mais pas terminées.

La quantité maximum de connexions simultanées dépend de la mémoire disponible. Chaque supplément de mémoire de 16 Mo augmente le nombre de transactions http simultanées de 500.

Par exemple, en cas d'utilisation du mode redondant, si vous voulez pouvoir traiter 2 000 connexions simultanément, vous avez besoin de 100 Mo + 3*16= 148 Mo. La mémoire minimum requise pour l'exécution en mode redondant est de 100 Mo.

Notifications

Lorsqu'elle est exécutée en mode redondant (fover_mode est défini), INSSLR2 déclenche des notifications lorsqu'elle devient active ou passive. Cela se produit lors du démarrage du noeud actif ou lors d'un basculement. Chaque noeud envoie une notification informant de son statut actif ou passif.

INSSLR2 envoie deux notifications :

• Une notification au tableau de bord de grille : INSSLR2 appliance APP_NAME:COMP_NAME <acquired|gave up=""> resource ip_addr
• Demande HTTP via le terminal nfy. Il appartient au destinataire de la notification d'agir en conséquence.

  L'URL demandée est la suivante :

  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

Vous pouvez utiliser fover_nfy_prefix pour modifier l'emplacement du script distant invoqué et/ou ajouter des paramètres supplémentaires.

Exemples de valeurs pour fover_nfy_prefix :

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

Remarques :

• Si vous utilisez un autre préfixe fover_nfy_prefix que celui par défaut, veillez à ce qu'il se termine par ? si fover_nfy_prefix est uniquement le chemin d'accès au script et si fover_nfy_prefix inclut éventuellement des paramètres supplémentaires.
• En cas d'indisponibilité d'un noeud, il se peut qu'il ne puisse pas envoyer de notification indiquant qu'il est devenu passif. Seul le noeud devenu actif envoie une notification.
• Le délai d'expiration pour la requête HTTP est de 5 secondes de sorte que le basculement n'est pas ralenti.

Outil de contrôle de l'intégrité

INSSLR2 exécute un cronjob toutes les minutes pour vérifier les aspects suivants :

• Si l'espace disponible sur le volume de données est inférieur à 20 %
• Si le démon rsync est en cours d'exécution (uniquement s'il est configuré en tant qu'esclave)
• Si le processus de réplication est en cours d'exécution (uniquement si configuré en tant que maître). Dans le cas contraire, il redémarre le processus de réplication.

Si l'une des vérifications est vraie, un message d'erreur est envoyé au tableau de bord de grille. Si plusieurs tests échouent, un message reprenant toutes les erreurs est publié dans le tableau de bord de la grille.

Chaque erreur ne sera signalée dans le tableau de bord de la grille qu'une fois par heure. Aucune erreur n'est signalée durant les 5 premières minutes après le démarrage de l'appliance. Cela permet de n'obtenir aucune fausse alarme tant que l'autre noeud dans la réplication n'a pas démarré.

Certificats de serveur

Pour utiliser SSL, vous avez besoin du certificat signé et de la clé privée avec laquelle il a été chiffré. La clé et le certificat doivent être au format PEM et utiliser un fichier unique spécifié par la propriété cert_file.

Génération de certificats de serveur

Vous pouvez générer un certificat de serveur qui peut être signé par une autorité de certification approuvée en payant des frais ou créer un certificat autosigné.

Procédez comme suit :

1. Générez une clé privée à l'aide de la commande suivante :

   openssl genrsa -out privkey.pem 2048 
   

   Vous pouvez également générer une clé protégée par mot de passe à l'aide de la commande suivante. Toutefois, si vous créez une telle clé, vous devez supprimer le mot de passe avant de l'utiliser dans INSSLR2. INSSLR2 requiert une clé sans mot de passe.

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. Créez un certificat à l'aide de l'une des options suivantes :
   • Créez une demande de certificat et faites-le signer par une autorité de certification approuvée en payant des frais.

     Exécutez la commande suivante :

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

     Après avoir envoyé le fichier .csr à votre autorité de certification approuvée, vous recevrez en retour un certificat signé (fichier .crt) que vous pouvez utiliser.

   • Créez un certificat autosigné à des fins de test. Les navigateurs accédant à votre site enverront des avertissements indiquant que le certificat n'est pas signé par une autorité de certification approuvée.

     Exécutez la commande suivante :

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

Utilisation des certificats de serveur

Vous pouvez placer le certificat et la clé dans un fichier et l'utiliser dans INSSLR2 en exécutant la commande suivante :

cat privkey.pem  server.crt > server.pem 

Si votre clé est protégée par un mot de passe, vous pouvez supprimer ce dernier en exécutant la commande suivante :

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

Utilisation des certificats de serveur apache+mod_ssl existants

INSSLR2 vous permet d'utiliser le certificat existant utilisé dans Apache. Vérifiez que la clé n'est pas protégée par mot de passe en suivant les étapes mentionnées ci-avant, puis placez le certificat privé et la clé dans un fichier unique.

Par exemple :

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

Si vous utilisez un certificat en chaîne, vous devriez également inclure le certificat intermédiaire fourni par son émetteur. Placez la clé privée, le certificat et le certificat intermédiaire dans un fichier unique dans cet ordre.

Par exemple :

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

Important : La clé de signature du serveur est la preuve de l'identité de votre site Web. Votre site est vulnérable aussi parce qu'il n'est pas chiffré par mot de passe de sorte que l'appliance peut le lire sans votre assistance.

Lorsque vous l'installez sur le volume de données, prenez des mesures pour protéger le fichier de clé. N'utilisez pas le même volume de données à d'autres fins et ne le rendez pas visible pour un serveur Web. Par exemple, pour héberger des données accessibles sur le Web (pages HTML, scripts, etc.)

Certificats client

L'exemple suivant décrit comment créer votre propre autorité de certification et l'utiliser pour signer vos propres certificats à l'aide d'OpenSSL. Il a été testé à l'aide d'OpenSSL 0.9.8b, la même version que celle installée dans INSSLR2.

Création d'une autorité de certification

Si vous disposez déjà de votre propre autorité de certification pour créer des certificats de serveur auto-signés, vous pouvez ignorer cette étape et utiliser cette autorité de certification. Lors de la création des instruments de l'autorité approuvée pour votre application, veillez à ce que l'environnement soit sécurisé.

Important : La clé privée pour l'autorité de certification est la base de l'approbation pour l'application. Ne la perdez pas et ne la fournissez à aucun autre parti.

Procédez comme suit :

1. Créez un répertoire de travail sur un hôte sécurisé et dans ce répertoire, exécutez les commandes :
   • mkdir CA
   • mkdir CA/private
2. Créez une clé RSA protégée par mot de passe pour l'autorité de certification avec une longueur de clé de 2048 bits :

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

3. Créez le certificat de clé publique pour l'autorité de certification à partir de la clé privée :

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

Création de certificats clients signés par l'autorité de certification

Vous pouvez créer des certificats clients signés par une autorité de certification.

Procédez comme suit :

1. Générez une clé privée RSA :

   openssl genrsa -out clientA_privkey.pem 2048 
   

   Pour créer une clé protégée par mot de passe, utilisez le commutateur -des3.

2. Générez une demande de signature de certificat (CSR) à partir de la clé privée :

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

3. Signez le certificat contenu dans CSR à l'aide du certificat généré pour l'autorité de certification :

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

Remarques :

• Le commutateur -CAcreateserial permet d'affecter des numéros de série uniques aux certificats publiés. S'il s'agit du premier certificat publié par l'autorité de certification, le fichier CA/CA_cert.srl est créé pour effectuer le suivi des affectations de numéro de série. Lors de la création des certificats clients suivants, le commutateur -CAserial est utilisé à la place du commutateur -CAcreateserial.

  Par exemple :

  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 
  

• Pour créer un seul fichier au format PEM qui inclut à la fois la clé et le certificat client :

  cat clientA_privkey.pem clientA.cer > clientA.pem 
  

• Pour créer un fichier équivalent au format pkcs12 pris en charge par la plupart des navigateurs, exécutez la commande :

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

Création des fichiers de liste de l'autorité de certification utilisés par INSSLR2

Révocation des certificats clients signés par l'autorité de certification

Pour révoquer un certificat client publié par l'autorité de certification, exécutez la commande :

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

Dans laquelle un exemple de fichier openssl.conf est affiché ci-dessous et le paramètre crl_reason est l'un des suivants : unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold ou removeFromCRL. Reason n'est pas sensible à la casse.

Pour regénérer la liste de révocation des certificats (CRL) :

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

Dans cet exemple, crl.pem est le fichier qui doit être fourni à INSSLR2 en tant que propriété cert_revocation_list.

Exemple de fichier de configuration utilisé pour les exemples ci-dessus : 

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

      [ 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

Création des fichiers de liste de l'autorité de certification utilisés par INSSLR2

Vous pouvez créer des fichiers de liste de l'autorité de certification utilisés par INSSLR2.

Pour créer un fichier identifié par la propriété ca_list_client :

1. Accédez au fichier suivant :

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

2. Placez ce fichier sur le volume clé ou sur le volume sur lequel nfs est monté via le terminal fs.

   Si vous le souhaitez, le certificat de serveur INSSLR2, tel que server.pem, peut également être créé de la même manière que les certificats de client et signés par l'autorité de certification créée. N'utilisez pas de mot de passe pour ce certificat.

3. Une fois que server.pem et ca_list_client.pem sont en place, vous pouvez tester l'authentification du certificat client comme suit :
   • Pour effectuer le test à partir d'un navigateur, importez un certificat de client au format pkcs12 dans Firefox en cliquant sur :

     Tools > Options > View Certificates > Your Certificates > Import. Faites pointer le navigateur sur l'adresse IP d'INSSLR2.

   • Pour tester l'établissement d'une liaison SSL à partir d'un hôte distant, exécutez la commande suivante :

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

En-têtes de certificats client

Si un client se connecte à INSSLR2 à l'aide de HTTPS et s'il présente un certificat client, INSSLR2 ajoute les en-têtes suivants à la requête renvoyée au serveur d'arrière-plan :

• X-SSL-Subject : informations sur le propriétaire de certificat.
• X-SSL-Issuer details : informations sur l'émetteur du certificat (Autorité de certification).
• X-SSL-Serial : numéro de série du certificat (décimale).
• X-SSL-Cipher : chiffrement actuellement en cours d'utilisation.
• X-SSL-Certificate : certificat complet du client (plusieurs lignes au format PEM).

Il est de la responsabilité de l'application d'utiliser ou pas ces en-têtes. INSSLR2 transfère simplement ces informations sans effectuer aucune vérification, à l'exception de la signature et de l'exactitude du chiffrement.

Utilisation standard

Applications Web

Pour fournir un accès http(s) à votre application, connectez le terminal http directement à l'appliance WEB.

Pour une application Web évolutive, connectez le terminal HTTP à une appliance HALB par l'intermédiaire d'un crochet.

Les exemples de configuration ne reprennent que les propriétés définies sur des valeurs autres que celles par défaut.

Applications Web avec des services supplémentaires

Si votre application dispose d'autres services que http, vous pouvez utiliser INSSLR2 pour transférer le trafic http vers son terminal http et utiliser le terminal aux pour les autres services.

Applications Web avec des services supplémentaires multiples

Si vous avez plusieurs services TCP/UDP et HTTP, vous pouvez utiliser INSSLR2 pour transférer le trafic HTTP vers son terminal HTTP et utiliser le terminal aux pour transférer le trafic restant à PS8. PS8 transfère alors le trafic restant aux serveurs d'arrière-plan.

Applications Web redondantes

Pour fournir une application Web redondante, copiez l'application et utiliser INSSLR2 pour fournir des fonctionnalités de basculement à l'adresse IP externe.

Remarque : Si deux appliances INSSLR2 dans la même application sont configurées pour s'exécuter en mode redondant, un message d'avertissement s'affiche lorsque vous configurez la même adresse IP sur deux interfaces différentes. Ignorez cette erreur.

Application Web de sauvegarde

Si vous souhaitez uniquement une application de sauvegarde pour notifier les indisponibilités aux utilisateurs, vous pouvez utiliser INSSLR2 pour créer une application de sauvegarde qui requiert des ressources minimales.

Appliances en cours d'utilisation :

• user : passerelle d'entrée pour les demandes utilisateur
• web : serveur Web affichant un message de maintenance

INSSLR2 sur l'application principale :

INSSLR2 sur l'application de sauvegarde :

Remarque : Vous pouvez configurer les attributs de l'interface connectée au terminal fover à l'aide de l'onglet Interfaces dans l'éditeur Configuration de l'application. Par exemple, les propriétés fover_local_ip et fover_netmask.

Application Web redondante dans une application unique

Pour exécuter votre application en mode redondant sans créer une application, vous pouvez doubler les appliances et les exécuter en mode redondant. Dans la mesure où cela implique d'utiliser deux serveurs Web et deux appliances de base de données au minimum, ils sont tous utilisés en mode normal et fournissent ainsi la modularité attendue. Toutefois, chacun d'entre eux peut servir l'application seule en cas d'échec de l'autre appliance.

Si vous avez besoin d'une plus grande modularité, vous pouvez ajouter davantage d'appliances Web et de base de données. Dans cet exemple, la moitié des appliances (in1, sw1, web1, db1) s'exécutent dans un groupe de basculement et le reste (in2, sw2, web2, db2) dans un autre groupe de basculement pour que l'application puisse résister à un arrêt brutal du serveur. Cette application fournit de la redondance à très faible coût étant donné que toutes les appliances (à l'exception d'une appliance INSSLR2 et d'une appliance HALB qui requièrent très peu de ressources) sont dans un état actif et qu'aucune dépense n'est effectuée pour une application de sauvegarde qui s'exécute en cas d'échec de la principale.

in1

in2

db1

db2

Application Web redondante comprenant deux applications identiques.

Vous pouvez exécuter deux applications identiques sur la même grille, mais sur des serveurs distincts ou sur des grilles différentes, si l'adresse IP est accessible à partir des deux grilles. En cas d'échec d'un serveur, cela permet de n'affecter qu'une application.

Remarque : Si deux appliances INSSLR2 dans la même application sont configurées pour s'exécuter en mode redondant, un message d'avertissement s'affiche lorsque vous configurez la même adresse IP sur deux interfaces différentes. Ignorez cette erreur.

L'exemple ci-dessous présente une application qui utilise une appliance de base de données qui s'exécute également en mode redondant. En cas d'échec d'une application, l'autre application prend le relais sans perdre de données.

Appliances en cours d'utilisation :

• insslr - Passerelle d'entrée redondante pour les demandes utilisateur
• admin - Passerelle d'entrée pour l'accès aux fichiers journaux
• sw - Redirige le port 8080 de l'administrateur vers ui sur db
• repl_in - Entrée pour que l'application distante se connecte à l'appliance de base de données afin de répliquer la base de données
• web_lb - Equilibreur de charge Web pour les requêtes utilisateur
• web1, web2 - Serveurs Web hébergeant du contenu actif, tel que des scripts CGI.
• db - MYSQLR64 configuré pour être simultanément maître et esclave
• content - Stockage des fichiers journaux d'erreurs de base de données, du contenu Web et des journaux Web
• logs - Stockage des fichiers journaux d'erreurs de base de données
• repl_out - Passerelle de sortie pour que l'appliance de base de données se connecte à l'application distante afin de répliquer la base de données
• mon - Appliance MON

Les demandes client arrivent sur la passerelle insslr. Cette dernière envoie les demandes à l'équilibreur de charge web_lb, qui les transmet à un des serveurs Web, web1 ou web2.

Les serveurs Web accèdent à la base de données db. L'appliance de base de données se connecte à l'application distante. Pour permettre la réplication des données, l'application distante est une copie identique, la seule différence étant l'ID de serveur de la base de données et la configuration réseau.

L'application distante se connecte à l'appliance de base de données via la passerelle repl_in qui est configurée pour n'autoriser la connexion que de la passerelle repl_out de l'application distante. Les appliances de base de données des deux applications s'exécutent dans une configuration maître-maître afin que leurs données soient toujours identiques.

Exemple de configuration de propriété

Les propriétés qui ne figurent pas dans les tableaux ci-dessous doivent être définies sur leurs valeurs par défaut. L'accès Web à la base de données est disponible à l'aide de la passerelle admin sur le port 8080.

insslr

db

Important : Seule une des applications doit être active. L'autre s'exécute seulement pour le basculement et est utilisée en cas d'échec de l'application active.

Remarques :

• INSSLR2 prend en charge les protocoles HTTP 1.0 et HTTP 1.1, mais si le client s'identifie lui-même comme MSIE, la prise en charge de HTTP 1.1 est désactivée pour cette connexion. Cela d'éviter les bogues dans certaines versions de MSIE.
• Si le client n'est pas MSIE, INSSLR2 prend en charge le protocole HTTP 1.1 pour le client, y compris les demandes multiples par capacité de session TCP. Cela se produit même si le serveur d'arrière-plan prend en charge uniquement le protocole HTTP 1.0.
• INSSLR2 ne prend en charge qu'une seule adresse IP externe. Par conséquent, vous ne pouvez utiliser qu'un seul certificat SSL.

Logiciels tiers et libres utilisés au sein de l'appliance

INSSLR2 utilise les packages tiers libres suivants en plus des packages tiers libres utilisés par sa classe de base LUX6.