8.6. Cómo establecer satélites redundantes con la BD independiente
Así como la opción disponible de clonación para los satélites con la Embedded Database, usted puede limitar los errores de un Satélite con la Stand-Alone Database si prepara satélites redundantes. A diferencia de la clonación de un satélite con la Embedded Database, la redundancia de satélites con la Stand-Alone Database puede ejecutarse en modo activo o en espera. Esta desición depende enteramente de la topología de su red y es independiente de los pasos dados a continuación.
Para establecer esta redundancia, instale primero el Satélite primario de forma normal, exceptuando el valor dado en el campo "Common Name" para el certificado SSL. Éste debe representar su configuración de alta disponibilidad y no el nombre de host del servidor individual. Después:
- Prepare la Stand-Alone Database contra fallos usando las recomendaciones de Oracle para construir una base de datos tolerante a fallos. Consulte su administrador de base de datos.
- Instale el RHN Satellitecon la Stand-Alone Database (y una instalación base de Red Hat Enterprise Linux AS) en una máquina separada. Salte los pasos de configuración de la base de datos, los pasos de los espacios de tablas y la generación del certificado SSL y del script bootstrap. Incluya la misma cuenta RHN y la información de conexión de la base de datos proporcionada durante la instalación inicial del satélite y el registro del nuevo Satélite.Si su certificado SSL original no tiene en cuenta la solución de alta disponibilidad, usted debe crear ahora un nuevo certificado con un Nombre común más apropiado. En este caso, también deberá generar un nuevo script bootstrap que capture este nuevo valor.
- Después de la instalación, copie los siguientes archivos desde el Satélite primario al Satélite secundario:
/etc/rhn/rhn.conf
/etc/tnsnames.ora
/var/www/rhns/server/secret/rhnSecret.py
- Copie e instale los RPM de certificado SSL del servidor desde el Satélite primario al secundario. Consulte la sección Compartiendo certificados de la Guía de configuración de sistemas cliente RHN para obtener instrucciones precisas. Recuerde, el valor del Nombre común debe representar la solución satélite combinada y no el nombre de host de una única máquina.Si usted generó un nuevo certificado SSL durante la instalación del Satélite secundario para incluir un nuevo valor de Nombre común, copie los RPM desde el satélite secundario al primario y redistribuya el certificado del lado cliente. Si usted ha creado asimismo un nuevo script bootstrap, usted puede usar éste para instalar el certificado en los sistemas cliente.
- Si usted no creó un nuevo script bootstrap, copie el contenido de
/var/www/html/pub/bootstrap/
del Satélite primario al secundario. Si generó un nuevo script, copie el contenido de ese directorio al Satélite primario. - Apague el RHN Task Engine en el Satélite secundario con el siguiente comando:
/sbin/service taskomatic stop
/sbin/service taskomatic stop
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Puede usar un script personal o cualquier otro medio para establecer automáticamente el inicio/conmutación del RHN Task Engine en el Satélite secundario. A pesar de todo, se deberá iniciar después de la conmutación. - Comparta los datos del canal de paquetes (localizados por defecto en
/var/satellite
) entre los satélites a través de algún tipo de dispositivo de almacenamiento de red. Así elimina la repetición de datos y asegura un almacenamiento consistente de los datos de cada satélite. - Comparta los datos del canal de paquetes (localizados por defecto en
/var/cache/rhn
) entre los Satélites a través de algún tipo de dispositivo de almacenamiento de red. Así elimina la repetición de datos y asegura un almacenamiento consistente de los datos de cada satélite. - Deje los diferentes Satélites disponibles en su red a través de un Nombre común y un método que favorezca su infraestructura. Las opciones incluyen round-robin DNS, un balanceador de carga de red y una configuración reverse-proxy.