9.6. Establishing Redundant Satellites with Stand-Alone Database

In keeping with the cloning option available to Satellite with Embedded Database, you may limit outages on Satellites with Stand-Alone Database by preparing redundant Satellites. Unlike cloning a Satellite with Embedded Database, redundant Satellites with Stand-Alone Database may be run as active, as well as standby. This is entirely up to your network topology and is independent of the steps listed here.

Procedure 9.1. Creating Redundant Satellites with Stand-Alone Database

  1. Prepare the Stand-Alone Database for failover using Oracle's recommendations for building a fault-tolerant database. Consult your database administrator.
  2. Install Red Hat Network Satellite with Stand-Alone Database on a separate machine, skipping the database configuration, database schema, SSL certificate, and bootstrap script generation steps. Include the same Red Hat Network account and database connection information provided during the initial Satellite install and register the new Satellite. For more information, see Section 4.3, “Installer Script Process”.
    If your original SSL certificate does not take your high-availability solution into account, create a new one with a more appropriate Common Name value (see 3.2. The RHN SSL Maintenance Tool in the Red Hat Network Satellite Client Configuration Guide). In this case, generate a new bootstrap script (as defined in 5.2. Generating RHN Bootstrap Scripts in the Red Hat Network Satellite Client Configuration Guide) that captures this new value. Ensure the Common Name value represents the combined Satellite solution, not a single machine's hostname.
  3. After installation, copy the following files from the primary Satellite to the secondary Satellite:
    • /etc/rhn/rhn.conf
    • /etc/tnsnames.ora
    • /var/www/rhns/server/secret/rhnSecret.py
  4. Copy and install the server-side SSL certificate RPMs from the primary Satellite to the secondary.
    If you generated a new SSL certificate during Satellite installation that included a new Common Name value, copy the SSL certificate RPMs from the secondary to the primary Satellite and redistribute the client-side certificate. If you also created another bootstrap script, use it to install the certificate on client systems.
  5. If you did not create a new bootstrap script, copy the contents of /var/www/html/pub/bootstrap/ from the primary Satellite to the secondary. If you did generate a new one, copy that directory's contents to the primary Satellite.
  6. Turn off the Red Hat Network Task Engine on the secondary Satellite with the following command:
    /sbin/service taskomatic stop
    
    You may use custom scripting or other means to establish automatic start-up/failover of the Red Hat Network Task Engine on the secondary Satellite. Regardless, it will need to be started upon failover.
  7. Share channel package data (by default located in /var/satellite) between the Satellites over some type of networked storage device. This eliminates data replication and ensures a consistent store of data for each Satellite.
  8. Share cache data (by default located in /var/cache/rhn) between the Satellites over some type of networked storage device. This eliminates data replication and ensures a consistent store of cached data for each Satellite.
  9. Make the various Satellites available on your network via Common Name and a method suiting your infrastructure. Options include round-robin DNS, a network load balancer, and a reverse-proxy setup.