Red Hat Training

A Red Hat training course is available for Red Hat Satellite

3.4. Creating Redundant Satellites with External Databases

In keeping with the cloning option available to Red Hat Satellite with an embedded database, you can limit outages on Satellite servers with external databases by preparing redundant Satellite servers. Unlike clones, you can run redundant Satellite servers with external databases in either active or standby mode. This is entirely up to your network topology and is independent of the steps listed here.

Important

Before you begin the following procedure, prepare the external database for failover using suitable recommendations for building a fault-tolerant database. Consult your database administrator.

Procedure 3.5. To Create a Redundant Satellite with an External Database:

  1. Install Red Hat Satellite on a separate machine, but omit 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 installation.
  2. Register the new Satellite server. See the Red Hat Satellite Installation Guide for more information.
  3. 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 The SSL Maintenance Tool in the Red Hat Satellite Client Configuration Guide). In this case, generate a new bootstrap script (as defined in Generating Bootstrap Scripts in the Red Hat Satellite Client Configuration Guide) that captures this new value. Ensure the Common Name value represents the combined Satellite solution, not a single machine's host name.
  4. After installation, copy the following files from the primary server to the secondary:
    • /etc/rhn/rhn.conf
    • /etc/tnsnames.ora (Oracle database only.)
  5. Copy the server-side SSL certificate RPMs from the primary server and install them on the secondary server.
    If, during the installation process, you generated a new SSL certificate that included a new Common Name value, copy the SSL certificate RPMs from the secondary to the primary server and redistribute the client-side certificate. If you also created another bootstrap script, use it to install the certificate on all client systems.
    • If you created a new bootstrap script, copy the contents of /var/www/html/pub/bootstrap/ to the primary server.
    • If you did not create a new bootstrap script, copy the contents of /var/www/html/pub/bootstrap/ from the primary server to the secondary server.
  7. Run the following command on the secondary server to stop the Red Hat Network Task Engine service: 
    # service taskomatic stop
    You can use custom scripting or other means to establish automatic start-up/failover of the Red Hat Network Task Engine on the secondary server. Regardless, you need to ensure that it starts in the event of a failure.
  8. Share channel package data (by default located in /var/satellite) and cache data (by default located in /var/cache/rhn) between the primary and secondary servers over some type of networked storage device. This eliminates data replication and ensures a consistent store of data for each server.
  9. Make the various servers available on your network using a suitable Common Name and a method that suits your infrastructure. Options include round-robin DNS, a network load balancer, and a reverse-proxy setup.