Información de referencia › Guía de referencia del catálogo de dispositivos › Catálogo del sistema › Puertas de enlace › INSSLR2: puerta de enlace de entrada HTTP redundante compatible con SSL.

INSSLR2: puerta de enlace de entrada HTTP redundante compatible con SSL.

Última versión: 1.0.1-2

El dispositivo INSSLR2 es una puerta de enlace de 7 niveles para solicitudes de HTTP seguras. Convierte las solicitudes en solicitudes HTTP no codificadas. Se puede utilizar esta funcionalidad para que sea compatible con HTTP seguro en el lado del cliente.

Sin embargo, la infraestructura de procesamiento de back-end no es compatible con SSL, incluidas las siguientes características:

• El uso de un servidor HTTP rápido y ligero que no admita SSL.
• El uso de varios servidores de back-end para mejorar el rendimiento u obtener redundancia, conectados a través de un conmutador de equilibrio de carga.
• El uso de varios servidores de back-end para funciones no relacionadas conectados a través de un conmutador de URL.
• La descarga de cifrado o descifrado SSL a un servidor independiente para mejorar el rendimiento.

Si se configura, INSSLR2 también es compatible con la autenticación de certificados de cliente. En caso de autenticación SSL mutua, tanto el cliente como el servidor intercambian sus certificados y las claves públicas correspondientes. El cliente se puede poner en contacto con la autoridad certificadora (CA) que emitió el certificado del servidor y confirmar que el certificado sea auténtico antes de continuar.

En su configuración predeterminada, INSSLR2 actúa como puerta de enlace de 7 niveles para solicitudes HTTP seguras. También proporciona un punto de entrada de cortafuegos para el tráfico de red en una aplicación. Esto se puede configurar con una dirección IP estática accesible desde Internet.

Si se configuran, se pueden usar dos dispositivos INSSLR2 en modo de conmutación por error para proporcionar un servicio redundante. En este caso, la dirección IP de INSSLR2 se ejecuta solamente en uno de los nodos y se transfiere automáticamente al otro dispositivo INSSLR2 en caso de error. Solamente uno de los dispositivos de INSSLR2 está activo durante un tiempo. Al ejecutarse en modo de conmutación por error se puede configurar INSSLR2 de modo que se ejecute en varios modos:

• Asimétrico: uno de los dispositivos es el primario. Cuando el dispositivo primario está en línea, asumirá la dirección IP y se activará.

  Si el nodo primario produce un error o se detiene, el dispositivo de copia de seguridad se activará. Cuando el dispositivo primario vuelva a estar disponible, asumirá la dirección IP y se activará. El dispositivo primario es el que tiene la dirección IP más baja (comparación de cadenas), como se haya establecido en la interfaz de fover.

• Simétrico: los dos dispositivos son primarios. Cualquier dispositivo que se inicie primero, asumirá la dirección de IP y se activa. El otro dispositivo se activa solamente si el primer dispositivo falla o se detiene.

  Cuando el primer dispositivo vuelve a estar disponible, no asume automáticamente la dirección IP.

Al ejecutarse en modo redundante, INSSLR2 proporciona una interfaz en su terminal ctl para:

• Forzar a INSSLR2 a ser dispositivo primario.
• Forzar a INSSLR2 a ser dispositivo de respaldo.
• Comprobar el estado del primario o realizar una copia de seguridad de INSSLR2.

INSSLR2 constantemente controla el estado del dispositivo de back-end conectado a su terminal http. Los controles de estado realizados por INSSLR2 pueden incluir una comprobación de la conexión TCP sencilla o una solicitud HTTP más compleja (especificada en el límite de INSSLR2).

En caso de error del dispositivo conectado, INSSLR2 comunica un error al cuadro de mandos del grid o, si está en modo redundante y configurado para hacerlo, hace una conmutación por error al dispositivo INSSLR2 de respaldo.

Para ser compatible con aplicaciones que tienen que aparecer en una sola dirección IP para más de un servicio, se puede configurar INSSLR2 para dirigir tráfico no HTTP de forma transparente a un terminal de salida aparte. Para este tipo de conexiones, el dispositivo actúa como un enrutador de cortafuegos/NAT de capa 3.

Límite

Recursos

Notas

• Cuando utilice INSSLR2 en el modo de conmutación por error (fover_mode no está establecido como ninguno), la memoria mínima es de 192 MB.
• La cantidad de memoria proporcionada a INSSLR2 no afecta al rendimiento. Utilice más memoria solamente para poder admitir más solicitudes simultáneas en los casos en los que los servidores de back-end se queden con las solicitudes durante períodos de tiempo demasiado largos.

Terminales

Propiedades

path/to/keys/ca_list_client.pem. 

path/to/keys/ca_list_client.pem. 

Propiedades de los controles de estado

Propiedades avanzadas utilizadas en escenarios de conmutación por error

Volúmenes

Mensajes de error

Los mensajes siguientes pueden aparecer en el archivo de registro del dispositivo o en el registro del sistema del controlador de grid cuando el dispositivo falla al iniciarse:

• 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

Rendimiento

Conmutación por error de aplicación

INSSLR2 detecta el error del INSSLR2 en aproximadamente 10 segundos y requiere unos 10 segundos adicionales para realizar la conmutación por error a la otra aplicación. El tiempo total desde que se produce el primer error de la aplicación hasta que la otra aplicación asume el tráfico es de unos 20 segundos.

Tasa de solicitudes

INSSLR2 enruta no menos de 3000 transacciones (pares de solicitud/respuesta) por segundo, según el tamaño de los documentos y el ancho de banda de red disponible.

Rendimiento de los datos

INSSLR2 enruta no menos de 7 MB/segundo, según el tamaño de los documentos y el ancho de banda de red disponible.

Conexiones simultáneas

Con la memoria predeterminada INSSLR2 es compatible con no menos de 500 solicitudes pendientes simultáneas. Una solicitud pendiente es una conexión TCP abierta del cliente, donde hay una o varias solicitudes HTTP sin completar en curso.

El número máximo de conexiones simultáneas depende de la memoria libre disponible. Cada 16 MB más de memoria aumenta por 500 el número de transacciones http simultáneas.

Por ejemplo, si ejecuta el modo redundante y se desean dar servicio a 2000 conexiones simultáneas, se necesitan 100 MB + 3*16 MB = 148 MB. La memoria mínima cuando se ejecuta el modo redundante es 100 MB.

Notificaciones

Cuando se ejecuta en el modo redundante (fover_mode no está definido como ninguno), INSSLR2 activa las notificaciones siempre que pase a ser activo o pasivo. Esto se realiza en inicio del nodo activo o cuando se produce una conmutación por error. Cada nodo envía una notificación se convierte en activa o pasiva.

INSSLR2 envía dos notificaciones:

• Una notificación al cuadro de mandos del grid: INSSLR2 appliance APP_NAME:COMP_NAME <acquired|gave up=""> resource ip_addr
• Solicitud HTTP utilizando el terminal nfy. Depende del extremo de recepción el tomar las medidas necesarias según la notificación.

  La URL solicitada es:

  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

Se puede utilizar fover_nfy_prefix para cambiar la ubicación del script remoto que se llama o para agregar más parámetros.

Ejemplos de valores fover_nfy_prefix:

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

Notas:

• Cuando utilice fover_nfy_prefix con un valor distinto al predeterminado, asegúrese de que termina con el signo ? si fover_nfy_prefix es solo la ruta al script o con el signo & si fover_nfy_prefix incluye más parámetros.
• Si un nodo ya no está disponible, es posible que no pueda enviar una notificación de que ha pasado a ser pasivo. Solo el nodo que pasa a estar activo envía la notificación.
• El tiempo de espera para la solicitud http es de 5 segundos para que la conmutación por error no se ralentice.

Control de estado

INSSLR2 ejecuta un cronjob cada minuto que comprueba:

• Si el espacio libre del volumen de datos es inferior al 20 %.
• Si el daemon de rsync se está ejecutando (solamente si se configura como secundario).
• Si el proceso de replicación está en ejecución (solamente si se configura como principal). En caso contrario, se reinicia el proceso de replicación.

Si se cumplen cualquiera de las condiciones anteriores, se envía un mensaje de error al cuadro de mandos del grid. Si más de una prueba es incorrecta, se publicará un mensaje en el cuadro de mandos del grid que resuma todos los errores.

Cada error se enviará solamente una vez cada hora al cuadro de mandos del grid. No se informará de ningún error en los primeros 5 minutos después de que se inicie el dispositivo. Esto impide que se produzcan falsas alarmas cuando no se haya iniciado el otro nodo en la replicación.

Certificados del servidor

Para utilizar SSL se necesita tanto el certificado firmado como la clave privada con la que se ha encriptado. La clave y el certificado deben estar en formato PEM y colocarse en un único archivo especificado por la propiedad cert_file.

Generación de certificados de servidor

Se puede generar un certificado de servidor que una autoridad certificadora de confianza (CA) puede firmar pagando o crear un certificado autofirmado.

Siga los pasos siguientes:

1. Genere una clave privada mediante el comando siguiente:

   openssl genrsa -out privkey.pem 2048 
   

   Se puede generar también una clave protegida por contraseña utilizando el siguiente comando. Sin embargo, si se crea una clave protegida por contraseña, es necesario eliminar la contraseña antes de utilizar en INSSLR2. INSSLR2 requiere una clave sin contraseña.

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. Cree un certificado mediante una de las opciones siguientes:
   • Cree una solicitud de certificado y haga que la firme una CA de confianza pagándole.

     Ejecute el siguiente comando:

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

     Después de enviar el archivo .csr a la autoridad certificadora de confianza, se le devolverá un certificado firmado (archivo .crt) que puede utilizar.

   • Cree un certificado autofirmado con fines de prueba. Los exploradores que solicitan que su sitio emitirán advertencias de que el certificado lo ha firmado una CA de confianza.

     Ejecute el siguiente comando:

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

Uso de certificados de servidor

Se puede colocar ahora el certificado y la clave en un archivo y utilizarlo en INSSLR2 ejecutando el comando siguiente:

cat privkey.pem  server.crt > server.pem 

Si la clave está protegida mediante contraseña, esta se puede eliminar ejecutando lo siguiente:

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

Uso de certificados de servidor apache+mod_ssl existentes

INSSLR2 permite utilizar un certificado existente que se utilice en Apache. Verifique que la clave no está protegida por contraseña siguiendo los pasos anteriores; a continuación, coloque el certificado privado y guárdelo en un solo archivo.

Por ejemplo:

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

Si está usando un certificado encadenado, debería incluir también el certificado intermedio proporcionado por el emisor. Coloque la clave privada, el certificado y el certificado intermedio en un solo archivo (en ese orden).

Por ejemplo:

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

Importante: La clave de firma del servidor es la prueba de identidad de su sitio web. También es vulnerable, ya que no está encriptada mediante contraseña para que el dispositivo la pueda leer sin ayuda.

Al instalarlo en el volumen de datos, tome las medidas necesarias para proteger el archivo de clave. No utilice el mismo volumen de datos con otros fines y no lo haga visible en un servidor web. Para, por ejemplo, alojar datos web accesibles, como páginas HTML y scripts.

Certificados del cliente

Los ejemplos siguientes describen cómo puede crear su propia autoridad certificadora y utilizarla para firmar sus propios certificados mediante OpenSSL. Esto se probó mediante OpenSSL 0.9.8b, la misma versión que se instaló en INSSLR2.

Creación de una autoridad certificadora

Si ya tiene una autoridad certificadora propia que se utiliza para crear certificados autofirmados, puede omitir este paso y utilizar esa autoridad certificadora. Al crear los instrumentos de la autoridad de confianza para la aplicación, es importante que el entorno sea seguro.

Importante: La clave privada para autoridad certificadora es la base de confianza de la aplicación. No la pierda ni la proporcione a otras personas.

Siga los pasos siguientes:

1. Cree un directorio de trabajo en un host seguro y lo siguiente en dicho directorio:
   • mkdir CA
   • mkdir CA/private
2. Cree una clave RSA protegida con contraseña para la autoridad certificadora que tenga una longitud de 2048 bits:

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

3. Cree, a partir de la clave privada, el certificado público clave de la autoridad certificadora:

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

Creación de certificados de cliente firmados por la autoridad certificadora

Se pueden crear certificados de cliente firmados por la autoridad certificadora.

Siga los pasos siguientes:

1. Genere una clave privada RSA:

   openssl genrsa -out clientA_privkey.pem 2048 
   

   Para crear una clave protegida de contraseña, utilice el conmutador -des3.

2. Genere una solicitud de firma de certificado (CSR) de la clave privada:

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

3. Firme el certificado contenido en CSR mediante el certificado generado para CA:

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

Notas:

• El conmutador -CAcreateserial permite asignar números de serie únicos a certificados emitidos. Como este es el primer certificado emitido por la autoridad certificadora, se crea el archivo CA/CA_cert.srl para realizar el seguimiento de los números de serie. Si se crean subsiguientes certificados de cliente, el conmutador -CAserial se usa en lugar del conmutador -CAcreateserial.

  Por ejemplo:

  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 
  

• Para crear un solo archivo con formato PEM que incluya tanto el certificado de cliente como de clave, ejecute lo siguiente:

  cat clientA_privkey.pem clientA.cer > clientA.pem 
  

• Para crear el archivo equivalente en formato pkcs12 (que lo pueden utilizar la mayoría de los exploradores):

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

Creación de archivos de la lista de CA utilizadas por INSSLR2

Revocación de certificados de cliente firmados por CA

Para revocar un certificado de cliente emitido por la CA, utilice el comando siguiente:

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

Donde un archivo openssl.conf de ejemplo se muestra a continuación y el parámetro crl_reason es uno de los siguientes: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold o removeFromCRL. El valor de "reason" no distingue entre mayúsculas y minúsculas.

Para volver a generar la lista de revocación de certificados (CRL), ejecute lo siguiente:

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

En este ejemplo crl.pem es el archivo que se debe proporcionar a INSSLR2 como la propiedad cert_revocation_list.

El archivo de configuración de muestra que se utiliza en el anterior ejemplo es: 

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

      [ 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

Creación de archivos de la lista de autoridades certificadoras utilizadas por INSSLR2

Se puede crear archivos de la lista de autoridades certificadoras utilizadas por INSSLR2.

Para crear el archivo identificado por la propiedad ca_list_client, lleve a cabo los pasos siguientes:

1. Acceda al siguiente archivo:

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

2. Coloque este archivo en el volumen de clave o en el volumen montado en nfs mediante el terminal fs.

   Si se desea, también se puede crear el certificado de servidor de INSSL2 (por ejemplo, server.pem) de la misma forma que los certificados de cliente, así como firmarse de igual modo por la autoridad certificadora creada. No utilice una contraseña para este certificado.

3. Una vez que server.pem y ca_list_client.pem están en su lugar, la autenticación del certificado del cliente se puede probar de la siguiente manera:
   • Para hacer la comprobación desde un explorador, importe un certificado de cliente formateado pkcs12 en FireFox siguiendo estos pasos:

     Herramientas=>Opciones=>Ver certificados=>Sus certificados=>Importar. Apunte el explorador a la dirección IP de INSSLR2.

   • Para probar el protocolo de enlace de SSL desde un host remoto, ejecute lo siguiente:

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

Encabezados de los certificados del cliente

Si un cliente se conecta a INSSLR2 mediante HTTPS, y si presenta un certificado de cliente, INSSLR2 agrega los encabezados siguientes a la solicitud que suministra al servidor de back-end:

• X-SSL-Subject: proporciona información sobre el propietario del certificado.
• X-SSL-Issuer: proporciona información sobre el emisor del certificado (autoridad certificadora).
• X-SSL-serial: indica el número de serie del certificado (decimal).
• X-SSL-cipher: indica el encriptado que se está utilizando.
• X-SSL-certificate: indica el certificado completo del cliente (multilínea en formato PEM).

La aplicación tiene la responsabilidad de utilizar o no estos encabezados. INSSLR2 solamente transfiere esta información sin verificarla de ninguna manera (excepto la corrección del encriptado y la firma).

Uso típico

Aplicaciones Web

Para proporcionar acceso de http(s) a su aplicación, conecte el terminal http directamente al dispositivo de WEB.

Aplicación web escalable con el terminal http conectado a un dispositivo HALB.

Los ejemplos de configuración enumeran solamente propiedades establecidas como valores no predeterminados.

Aplicaciones web con servicios adicionales

Si tiene más servicios además de http en su aplicación, puede utilizar INSSLR2 para pasar el tráfico http al terminal http y usar el terminal aux para otros servicios.

Aplicaciones web con varios servicios adicionales

Si se disponen de varios servicios de TCP/UDP y HTTP, se puede utilizar INSSLR2 para transferir tráfico de HTTP al terminalHTTP, así como utilizar el terminal aux para suministrar el tráfico restante a PS8. A continuación, PS8 suministra el tráfico deseado a los servidores de back-end.

Aplicaciones Web redundantes

Si se necesita proporcionar una aplicación web redundante, puede copiar la aplicación y utilizar INSSLR2 para proporcionar capacidades de conmutación por error a la dirección IP externa.

Nota: Si dos dispositivos de INSSLR2 de la misma aplicación se configuran para ejecutarse en el modo redundante, se mostrará un mensaje de advertencia cuando se configura la misma dirección IP en dos interfaces diferentes. Ignore ese error.

Aplicación web de copia de seguridad

Si se desea una aplicación de copia de seguridad que notifique a los usuarios el tiempo de inactividad, se puede utilizar INSSLR2 para generar una aplicación de copia de seguridad que requiera unos recursos mínimos.

Dispositivos en uso:

• usuario: puerta de enlace de entrada para solicitudes de usuario.
• web: servidor web que muestra un mensaje de mantenimiento.

INSSLR2 en la aplicación primaria

INSSLR2 en la aplicación de copia de seguridad:

Nota: Se pueden configurar los atributos de la interfaz conectada al terminal fover utilizando la ficha Interfaces del editor de configuración de la aplicación. Por ejemplo, las propiedades fover_local_ip y fover_netmask.

Aplicación web redundante en una sola aplicación

Para ejecutar la aplicación en el modo redundante sin crear una nueva aplicación, se pueden duplicar los dispositivos y ejecutarlos en modo redundante. Dado que esto implica utilizar como mínimo dos servidores web y dos dispositivos de base de datos en el modo normal, se utilizan todos los que proporcionan escalabilidad. Sin embargo, cada uno de ellos puede dar servicio únicamente a la aplicación en caso de que se produzca un error en el otro dispositivo.

Si necesita más escalabilidad, puede agregar más dispositivos web y base de datos. En este ejemplo la mitad de los dispositivos (in1, sw1, web1, db1) se ejecutan en un grupo de conmutación por error y el resto (in2, sw2, web2, db2) están en otro grupo de conmutación por error, de forma que la aplicación puede sobrevivir en caso de que se produzca un error en el servidor. Esta aplicación proporciona redundancia a un coste muy bajo, puesto que todos los dispositivos (excepto en el caso de un dispositivo INSSLR2 y otro HALB, que requieren recursos muy bajos) están en estado activo y no se consume ningún recurso para una aplicación de copia de seguridad que se ejecuta solamente si se produce un error en la primaria.

in1

in2

db1

db2

Aplicación web redundante con dos aplicaciones idénticas

Por ejemplo, se pueden ejecutar dos aplicaciones idénticas en el mismo grid pero en servidores independientes, o bien en grids diferentes si la dirección IP es accesible desde los dos grids. Esto permite que el error de un servidor afecte solamente a una de las aplicaciones.

Nota: Si dos dispositivos de INSSLR2 de la misma aplicación se configuran para ejecutarse en el modo redundante, se mostrará un mensaje de advertencia cuando se configura la misma dirección IP en dos interfaces diferentes. Ignore ese error.

El siguiente ejemplo muestra una aplicación que utiliza un dispositivo de base de datos que también se ejecuta en el modo redundante. Si una aplicación produce un error, la otra aplicación puede tomar el control sin que se pierdan datos.

Dispositivos en uso:

• insslr: puerta de enlace de entrada redundante para solicitudes de usuario.
• admin: puerta de enlace de entrada para acceso a los archivos de registro.
• sw: vuelva a dirigir el puerto 8080 desde admin hasta ui en db.
• repl_in: entrada para que la aplicación remota se conecte al dispositivo db para replicar la base de datos.
• web_lb: equilibrador de carga Web para solicitudes de usuario.
• web1, web2: servidores web con contenido activo (por ejemplo, scripts de CGI).
• db: MYSQLR64 se configura para ser tanto principal como secundario al mismo tiempo.
• content: almacenamiento para archivos de registro de errores de base de datos, contenido web y registros web.
• logs: almacenamiento para archivos de registro de errores de base de datos.
• repl_out: puerta de enlace de salida para que el dispositivo db se conecte a la aplicación remota para replicar la base de datos.
• mon: dispositivo MON.

Las solicitudes de cliente llegan a la puerta de enlace de insslr. La puerta de enlace reenvía las solicitudes al equilibrador de carga web_lb, el cual las dirige a uno de los servidores web: web1 o web2.

Los servidores Web acceden a la base de datos db. El dispositivo db se conecta a la aplicación remota. Para replicar la base de datos, la aplicación remota es una copia idéntica, con la única diferencia de que es la configuración de server_id de db y de red.

La aplicación remota se conecta al dispositivo db mediante la puerta de enlace repl_in que se configura para permitir solamente la conexión de la puerta de enlace repl_out de la aplicación remota. Los dispositivos db de las dos aplicaciones se ejecutan en la configuración principal-principal para garantizar que siempre tienen datos idénticos.

Configuración de una propiedad de ejemplo

Las propiedades que no se especifican deberían dejarse con sus valores predeterminados. El acceso Web a db está disponible mediante la puerta de enlace admin en el puerto 8080.

insslr

db

Importante: Solamente una de las aplicaciones está activa en todo momento; la otra se está ejecutando solo para la conmutación por error y se utiliza cuando la aplicación activa produce un error.

Notas:

• INSSLR2 es compatible con HTTP 1.0 y HTTP 1.1; sin embargo, si el cliente se identifica así mismo como MSIE, se desactiva la compatibilidad con HTTP 1.1 para esa conexión. De esta forma, se evitan errores en algunas versiones de MSIE.
• Si el cliente no es MSIE, INSSLR2 es compatible con HTTP 1.1 para el cliente (incluidas varias solicitudes por capacidad de sesión TCP). Esto sucede aunque el servidor de back-end sea solamente compatible con HTTP 1.0.
• INSSLR2 admite una sola IP externa y, por lo tanto, solamente se puede utilizar un solo certificado SSL.

El dispositivo incluye software de código fuente y software de terceros.

INSSLR2 utiliza los siguientes paquetes de código abierto de terceros, además de los paquetes de código abierto de terceros que utiliza su clase base LUX6.