Skip Headers
Oracle® Big Data Appliance Owner's Guide
Release 2 (2.0.1)

Part Number E36962-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

9 Installing the Oracle Big Data Appliance Software

This chapter explains how to install, reinstall, or reconfigure the software on Oracle Big Data Appliance. This chapter contains these sections:

Note:

Because Mammoth does not store passwords, you are prompted to enter each one. Ensure that you know the current passwords for the operating system root and oracle users, the Cloudera Manager admin user, and the MySQL administrator. If you are reinstalling Oracle Big Data Connectors, then you also need the MySQL password for Oracle Data Integrator.

9.1 Installing the Software on a New Rack

The Mammoth Utility installs and configures the software on Oracle Big Data Appliance using the files generated by the Oracle Big Data Appliance Configuration Utility. At a minimum, Mammoth installs and configures Cloudera's Distribution including Apache Hadoop. This includes all the Hadoop software and Cloudera Manager, which is the tool for administering your Hadoop cluster. Mammoth optionally installs and configures Oracle NoSQL Database and, if you have a license, all components of Oracle Big Data Connectors.

In addition to installing the software across all servers in the rack, the Mammoth Utility creates the required user accounts, starts the correct services, and sets the appropriate configuration parameters. When it is done, you have a fully functional, highly tuned, up and running Hadoop cluster.

You must run the Mammoth Utility once for each rack.

9.1.1 Installing the Software on a Single or Primary Rack

Follow this procedure to install and configure the software on a single Oracle Big Data Appliance rack or on the primary rack of a multiple-rack cluster.

To install the software: 

  1. Verify that the Oracle Big Data Appliance rack is configured according to the custom network settings described in /opt/oracle/bda/BdaDeploy.json. If the rack is still configured to the factory default IP addresses, first perform the network configuration steps described in "Configuring the Network."

  2. Verify that the software is not installed on the rack already. If the software is installed and you want to reinstall it, then use the mammoth -p option in Step 9.

  3. Download the BDAMammoth zip file to any directory on node01 (such as /tmp). For the download location, see My Oracle Support Information Center ID 1445745.2.

  4. Log in to node01 as root and extract all files from the downloaded zip file:

    # unzip p16069298_201_Linux-x86-64.zip
    Archive:  p16069298_201_Linux-x86-64.zip
      inflating: README.txt
       creating: BDAMammoth-2.0.1/
      inflating: BDAMammoth-2.0.1/bda-configurator-2.0.1.ods
      inflating: BDAMammoth-2.0.1/BDAMammoth-2.0.1.run
    
  5. Change to the BDAMammoth-version directory:

    # cd BDAMammoth-2.0.1
    
  6. Extract all files from BDAMammoth-version.run:

    # ./BDAMammoth-2.0.1.run
    
  7. Change to the BDAMammoth directory.

    # cd /opt/oracle/BDAMammoth
    
  8. Copy mammoth-rack_name.params to the current directory. See "About the Configuration Files."

  9. Run the mammoth command with the appropriate options. See Table 9-1. This sample command runs steps 1 and 2 on rack bda2:

    ./mammoth -r 1-2 bda2
    

The Mammoth Utility stores the current configuration in the /opt/oracle/bda/install/state directory. Do not delete the files in this directory. The Mammoth Utility fails without this information if you need to use it again, such as adding a rack to the cluster.

9.1.2 Adding a Rack to an Existing Cluster

Each multirack cluster has one rack designated as the primary rack. Whether a rack is the primary one is indicated in the Oracle Big Data Appliance Configuration Worksheets and specified in the mammoth-rack_name.params file. Each rack of a multirack Hadoop cluster has a separate mammoth-rack_name.params file.

To install the software on additional racks in the same cluster: 

  1. Install the software on the primary rack of the Hadoop cluster. See "Installing the Software on a Single or Primary Rack".

  2. Ensure that all racks are running the same software version. See "About Software Version Differences".

  3. Ensure that all racks that form a single Hadoop cluster are cabled together. See Chapter 8.

  4. Copy the mammoth-rack_name.params files of the non-primary racks to node01 (the bottom server) of the primary rack. Do not copy them to the non-primary racks.

  5. Connect as root to node01 of the primary rack and change to the BDAMammoth directory:

    cd /opt/oracle/BDAMammoth
    

    Note: Always start Mammoth from the primary rack.

  6. For each non-primary rack, enter the mammoth command with the appropriate option. See "Mammoth Utility Syntax". For example, this command starts the installation on rack bda4:

    ./mammoth -i bda4
    

The primary rack of a multirack Hadoop cluster is configured the same as a single Hadoop cluster. It runs the NameNodes, Hue, Hive, and other key services. The other racks of a multirack Hadoop cluster are configured differently. They only run the DataNodes and TaskTrackers.

If you have a license for Oracle Big Data Connectors, they are installed on all nodes of the non-primary racks, although the services do not run on them. Oracle Data Integrator agent still runs on node03 of the primary rack. You cannot add nodes to an Oracle NoSQL Database cluster after it is set up. However, a logical volume is created on the additional rack for future use when nodes can be added to an Oracle NoSQL Database cluster.

The Mammoth Utility obtains the current configuration from the files stored in /opt/oracle/bda/install/state. If those files are missing or if any of the services have been moved manually to run on other nodes, then the Mammoth Utility fails.

About Software Version Differences

All racks configured as one Hadoop cluster must have the same image. A new Oracle Big Data Appliance rack may be factory-installed with a newer base image than the previously installed racks. Use the imageinfo utility on any server to get the image version. When all racks of a single Hadoop cluster have the same image version, you can install the software on the new rack.

To synchronize the new rack with the rest of the Hadoop cluster, either upgrade the existing cluster to the latest image version or downgrade the image version of the new rack.

To upgrade the image version: 

To downgrade the image version: 

  • Reimage the new rack to the older version installed on the cluster. See My Oracle Support Information Center ID 1445745.2.

  • Use the older version of the Oracle Big Data Appliance Configuration Utility to generate the configuration files.

  • Use the older version of the Mammoth Utility to install the software.

9.2 What If an Error Occurs During the Installation?

Each step generates a detailed log file listing the actions performed on each server and whether the step completed successfully. If an error occurs, the script stops. You can then check the log files in /opt/oracle/BDAMammoth/bdaconfig/tmp. The log files are named in this format:

STEP-i-yyyymmddhhmmss.log

In this format, i is the step number and yyyymmddhhmmss identifies the time that the file was created, as the year, month, day, hour, minute, and second.

After fixing the problem, you can rerun all steps or a range of steps. Except for steps 1 to 3, you cannot skip steps or run them out of order.

9.3 Upgrading the Software on Oracle Big Data Appliance

The procedure for upgrading the software is the same whether you are upgrading from one major release to another or just applying a patch set. The procedure is also the same whether your Hadoop cluster consists of one Oracle Big Data Appliance rack or multiple racks.

The process upgrades all components of the software stack including the firmware, operating system, CDH, JDK, and Oracle Big Data Connectors (if previously installed).

Software downgrades are not supported.

Note:

Because the upgrade process automatically stops and starts services as needed, the cluster is unavailable while the mammoth command is executing.

9.3.1 About the Changes from Version 1.1 to Version 2.0.1

Following is a summary of the changes an upgrade makes to the software on a cluster:

  • CDH4 replaces CDH3, and Cloudera Manager 4.1.2 replaces Cloudera Manager 3.7.

  • Some services are located on different nodes:

    • The Cloudera Manager service runs on node03 instead of node02.

    • The primary and backup MySQL databases switch positions. The primary database runs on node03, and the backup database runs on node02.

    • The directory that is mounted on all nodes of a cluster is exported from node03 instead of node04.

  • Namenode high availability and automatic failover is turned on:

    • There are two namenodes, which run on node01 and node02. There is no secondary namenode.

    • There are two failover controllers, which run on node01 and node02.

    • There are three journal nodes, which run on node01, node02, and node03.

    • The ZooKeeper service is configured with servers running on node01, node02, and node03.

    • The Oozie service is configured with a server running on node03.

  • A mounted directory is not used to backup NameNode or secondary NameNode data.

See Also:

Oracle Big Data Appliance Software User's Guide for more detailed information about the version 2.0 software.

9.3.2 Upgrading from Software Version 1.1

Follow these procedures to upgrade the software on an Oracle Big Data Appliance cluster from version 1.1 to version 2.0.1.

To upgrade the software: 

  1. Download the BDAMammoth zip file to any directory (such as /tmp) on node01 of the primary rack. For the download location, see My Oracle Support Information Center ID 1445745.2.

    You upgrade to the version of the Mammoth Utility, and so you need Mammoth 2.0.1 to upgrade your appliance to 2.0.1 software.

  2. Log in to the HDFS node (node01) as root and extract all files from the downloaded zip file:

    # unzip p16069298_201_Linux-x86-64.zip
    Archive:  p16069298_201_Linux-x86-64.zip
      inflating: README.txt              
       creating: BDAMammoth-2.0.1/
      inflating: BDAMammoth-2.0.1/bda-configurator-2.0.1.ods  
      inflating: BDAMammoth-2.0.1/BDAMammoth-2.0.1.run 
    
  3. Change to the BDAMammoth-version directory:

    # cd BDAMammoth-2.0.1
    
  4. Extract all files from BDAMammoth-version.run:

    # ./BDAMammoth-2.0.1.run
    

    The new version of the Mammoth software is installed in /opt/oracle/BDAMammoth, and the previous version is saved in /opt/oracle/BDAMammoth/previous-BDAMammoth.

  5. Change to the BDAMammoth directory.

    # cd /opt/oracle/BDAMammoth
    
  6. Run the mammoth command with the -p option:

    ./mammoth -p
    

9.3.3 About the Mammoth Steps in an Upgrade

An upgrade is a multistep process. Various messages are displayed to let you know what the upgrade is actively doing to your cluster. The following steps run automatically, but they can help you identify where Mammoth is in the upgrade process.

  1. Stop Oracle Data Integrator and Oracle NoSQL Database.

  2. Update the factory image.

  3. Stop Cloudera Manager.

  4. Install the new version of Cloudera Manager.

  5. Start Cloudera Manager.

  6. Upgrade the databases used by Cloudera Manager.

  7. Stop and uninstall all Hadoop services.

  8. Install the new version of Hadoop

  9. Upgrade the cluster from CDH3 to CDH4 format and finalize the upgrade.

  10. Delete the old CDH services (HDFS, MapReduce, and Hue) and create the new services (HDFS, MapReduce, Hue, Oozie, and ZooKeeper).

  11. Mount the new shared directory from node03.

  12. Set up MySQL Database.

  13. Set up the new configuration files on all nodes for Cloudera Manager.

  14. Move the Cloudera management service from node02 to node03. After this step, you access the Cloudera Manager web page on node03.

  15. Restart Cloudera Manager.

  16. Start all CDH services. This step enables High Availability and automatic failover.

  17. Restart the Hive service.

  18. Copy the source code of all open source packages to all nodes.

  19. Upgrade the optional software components: Oracle Big Data Connectors and Oracle NoSQL Database.

  20. Clean up the installation and run the cluster checks.

9.4 Changing the Configuration of Optional Software

During the initial configuration of Oracle Big Data Appliance, the optional software components may or may not be installed. Using the Mammoth Reconfiguration Utility, you can reverse some of those decisions. You must provide the relevant server names, ports, user names, and passwords. See the mamoth-reconfig add and remove options.

The following procedure shows how to add support for Auto Service Request.

To support Auto Service Request: 

  1. Set up your My Oracle Support account and install ASR Manager. You must do this before activating Auto Service Request on Oracle Big Data Appliance. See Chapter 5.

  2. Log into the first NameNode (node01) of the primary rack and change to the BDAMammoth directory:

    cd /opt/oracle/BDAMammoth
    
  3. Turn on Auto Service Request monitoring and activate the assets:

    # cd /opt/oracle/BDAMammoth
    # ./mammoth-reconfig add asr
    INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205075303.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205075303.trc
    INFO: Checking configuration file /opt/oracle/bda/install/state/mammoth-saved.params...
    INFO: Using saved configuration file /opt/oracle/bda/install/state/mammoth-saved.params
    INFO: To use the generated configuration file, remove /opt/oracle/bda/install/state/mammoth-saved.params
    INFO: Loading configuration file /opt/oracle/bda/install/state/mammoth-saved.params...
    INFO: Reading component versions from /opt/oracle/BDAMammoth/bdaconfig/COMPONENTS
    INFO: Creating nodelist files...
    Enter the value for ASR_HOST [Default: ]: asr-host.example.com
    Enter the value for ASR_PORT [Default: 162]:
    Enter the value for ASR_SERVER_USER: jdoe
     
    Please Check the values you entered for the ASR parameters
     
    ASR_HOST = asr-host.example.com
    ASR_PORT = 162
    ASR_SERVER_USER = jdoe
     
    Are these values correct (y/n): y
    Enter password for user jdoe on machine asr-host.example.com
    Enter password: password
    Enter password again: password
    INFO: Creating environment.pp file ...
    INFO: Making sure all puppet agents can be accessed.
    INFO: Pinging puppet agents
    INFO: Setting up ASR on all nodes. This will take some time ...
         .
         .
         .
    

The next procedure shows how to add support for Oracle Enterprise Manager Cloud Control:

To support Oracle Enterprise Manager Cloud Control: 

  1. Install the system monitoring plugin for Oracle Big Data Appliance in an Oracle Enterprise Manager Cloud Control installation on the same network. See the Oracle Enterprise Manager System Monitoring Plug-in Installation Guide for Oracle Big Data Appliance.

  2. Log into the first NameNode (node01) of the primary rack and change to the BDAMammoth directory:

    cd /opt/oracle/BDAMammoth
    
  3. Add support for Oracle Enterprise Manager Cloud Control:

    # cd /opt/oracle/BDAMammoth
    # ./mammoth-reconfig add em
    INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205082218.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20130205082218.trc
    INFO: Checking configuration file /opt/oracle/bda/install/state/mammoth-saved.params...
    INFO: Using saved configuration file /opt/oracle/bda/install/state/mammoth-saved.params
    INFO: To use the generated configuration file, remove /opt/oracle/bda/install/state/mammoth-saved.params
    INFO: Loading configuration file /opt/oracle/bda/install/state/mammoth-saved.params...
    INFO: Reading component versions from /opt/oracle/BDAMammoth/bdaconfig/COMPONENTS
    INFO: Creating nodelist files...
    Enter the value for EM_HOST [Default:]: oem-host.example.com
    Enter the value for EM_PORT [Default: 4473]:
    Enter the value for EM_USER [Default: sysman]:
     
    Please Check the values you entered for the EM parameters
     
    EM_HOST = oem-host.example.com
    EM_PORT = 4473
    EM_USER = sysman
     
    Are these values correct (y/n): y
    Enter password for user sysman on machine oem-host.example.com
    Enter password: password
    Enter password again: password
    Enter agent registration password for em setup on machine oem-host.example.com
    Enter password: password
    Enter password again: password
    INFO: Checking passwordless ssh setup
    INFO: Executing checkRoot.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
    SUCCESS: Executed checkRoot.sh on nodes /opt/oracle/BDAMammoth/bdaconfig/tmp/all_nodes #Step -1#
    SUCCESS: Password-less root SSH is setup.
    INFO: Creating environment.pp file ...
    INFO: Making sure all puppet agents can be accessed.
    INFO: Pinging puppet agents
    INFO: Creating directories for em download This will take some time ...
         .
         .
         .
    

9.5 Reinstalling the Base Image

The operating system and various utilities are factory installed on Oracle Big Data Appliance, as described in "Oracle Big Data Appliance Management Software". You may need to reinstall this base image if, for example, you want to return Oracle Big Data Appliance to its original state, or you want to upgrade the base image to a more recent version before using the Mammoth Utility to install the Oracle Big Data Appliance software.

Following is the procedure for reimaging an entire rack.

Caution:

If you reinstall the base image, then all files on the server are erased.

To reinstall the base image on all servers in a rack: 

  1. If the Oracle Big Data Appliance software was installed previously on the rack, then save the /opt/oracle/BDAMammoth/mammoth-rack_name.params file to a safe place outside Oracle Big Data Appliance.

  2. Download the patch file that contains the correct version of the base image and copy it to node01 (bottom server). For the download location, see My Oracle Support Information Center ID 1445745.2. You can copy the file to any directory, such as /tmp.

    Note:

    You can download the Mammoth Utility patch file from the same My Oracle Support Information Center to a safe location outside of Oracle Big Data Appliance. You must use the Mammoth Utility after reimaging to reinstall the end-user software.
  3. Establish an SSH connection to node01 and log in as root.

  4. Ensure that passwordless SSH is set up:

    # dcli hostname
    192.168.41.37: bda1node01.example.com
    192.168.41.38: bda1node02.example.com
    192.168.41.39: bda1node03.example.com
         .
         .
         .
    

    This command should run without errors and return the host names of all 18 Oracle Big Data Appliance servers. If not, then follow the steps in "Setting Up Passwordless SSH". Do not continue until the dcli hostname command runs successfully on all servers.

  5. Check all Oracle Big Data Appliance servers for hardware issues:

    # dcli bdacheckhw | grep -v SUCCESS
    
  6. Resolve any hardware errors and warnings before reimaging the rack.

  7. Verify that at least 4 GB are available in the root (/) partition of all servers:

  8. [# dcli df -h /
    192.168.41.37: Filesystem            Size  Used Avail Use% Mounted on
    192.168.41.37: /dev/md2              161G   21G  132G  14% /
    192.168.41.38: Filesystem            Size  Used Avail Use% Mounted on
    192.168.41.38: /dev/md2              161G   19G  135G  12% /
    192.168.41.39: Filesystem            Size  Used Avail Use% Mounted on
    192.168.41.39: /dev/md2              161G   23G  131G  15% /
         .
         .
         .
    
  9. Extract all files from the zip file, for example:

    # unzip p16065021_201_Linux-x86-64.zip
    Archive:  p16065021_201_Linux-x86-64.zip
      inflating: README.txt
       creating: BDABaseImage-2.0.1_RELEASE/
      inflating: BDABaseImage-2.0.1_RELEASE/BDABaseImage-2.0.1_RELEASE.iso
      inflating: BDABaseImage-2.0.1_RELEASE/reimagerack
      inflating: BDABaseImage-2.0.1_RELEASE/ubiosconfig
      inflating: BDABaseImage-2.0.1_RELEASE/biosconfig
      inflating: BDABaseImage-2.0.1_RELEASE/makebdaimage
     extracting: BDABaseImage-2.0.1_RELEASE/BDABaseImage-2.0.1_RELEASE.md5sum
    
  10. Change to the BDABaseImage-version_RELEASE directory created in the previous step, for example:

    # cd BDABaseImage-2.0.1_RELEASE
    
  11. Complete one of the following procedures:

    • To reimage an Oracle Big Data Appliance that was configured for a customer network to the same customer network settings:

      1. Ensure that /opt/oracle/bda/BdaDeploy.json exists and contains the customer network settings.

      2. Execute the ./reimagerack command.

    • To reimage an appliance that still has the factory settings:

      1. Ensure that /opt/oracle/bda/bdaShip.json exists.

      2. Ensure that /opt/oracle/bda/BdaDeploy.json does not exist.

      3. Execute the ./reimagerack command.

    • To restore the factory network settings on a rack configured with custom network settings:

      1. Ensure that /opt/oracle/bda/BdaDeploy.json exists and contains the customer network settings.

      2. Copy /opt/oracle/bda/BdaDeploy.json to a safe location outside Oracle Big Data Appliance.

      3. Ensure that /opt/oracle/bda/BdaShip.json exists.

      4. Disconnect the rack from the network.

      5. Reimage the rack:

        ./reimagerack deploy ship
        

    The reimagerack utility creates an ISO image, copies it to the internal USB drive of each server in the rack, reboots each server, and initializes the installation. Reinstalling the base image on all servers takes about an hour.

  12. Set up passwordless SSH for root:

    # setup-root-ssh
    

    See setup-root-ssh.

  13. Using dcli, manually reboot all servers in the cluster, and ensure that the BDA_IMAGING_SUCCEEDED and BDA_REBOOT_SUCCEEDED files exist in the /root directory:

    ]# dcli ls /root/BDA_*
    192.168.42.37: /root/BDA_IMAGING_SUCCEEDED
    192.168.42.37: /root/BDA_REBOOT_SUCCEEDED
    192.168.42.38: /root/BDA_IMAGING_SUCCEEDED
    192.168.42.38: /root/BDA_REBOOT_SUCCEEDED
    192.168.42.39: /root/BDA_IMAGING_SUCCEEDED
    192.168.42.39: /root/BDA_REBOOT_SUCCEEDED
         .
         .
         .
    
  14. Run the Mammoth Utility. See "Installing the Software on a Single or Primary Rack."

9.6 Mammoth Utility Syntax

You must log in as root on the first server and change to the /opt/oracle/BDAMammoth directory to use the Mammoth Utility. It has this syntax:

./mammoth option [rack_name]

In this command, rack_name is the name of an Oracle Big Data Appliance rack. You must enter the rack name in the first command exactly as it appears in the configuration file name (mammoth-rack_name.params). Afterward, rack_name defaults to the rack specified in a previous mammoth command.

You must finish installing one rack before starting the installation of another rack.

Example 9-1 Mammoth Utility Syntax Examples

This command displays Help for the Mammoth Utility:

./mammoth -h

This command does a complete install on rack bda3:

./mammoth -i bda3

The next command runs steps 2 through 6 on the rack being set up:

./mammoth -r 2-6

9.6.1 Mammoth Utility Options

Table 9-1 lists the Mammoth Utility options.

Table 9-1 Mammoth Utility Options

Option Description

-h

Displays command Help including command usage and a list of steps.

-i

Runs all mandatory steps, equivalent to -r 1-18.

-l

List the steps of the Mammoth Utility.

-p

Upgrades the software on the cluster to the current version.

-r n-N

Run steps n through N of the Mammoth Utility while no errors occur

-s n

Runs step n.

 

-v

Displays the version number of the Mammoth Utility.


9.6.2 Mammoth Installation Steps

Following are descriptions of the steps that the Mammoth Utility and the Mammoth Reconfiguration Utility perform when installing the software.

Step 1   SetupClusterAccess

This step performs several tasks:

  • Validates the configuration files and prompts for the passwords.

  • Sets up a Secure Shell (SSH) for the root user so you can connect to all addresses on the administrative network without entering a password.

  • Sets up passwordless SSH for the root user on the InfiniBand network.

  • Generates /etc/hosts from the configuration file and copies it to all servers so they use the InfiniBand connections to communicate internally. The file maps private IP addresses to public host names.

  • Sets up an alias to identify the node where the Mammoth Utility is run as the puppet master node. For example, if you run the Mammoth Utility from bda1node01 with an IP address 192.168.41.1, then a list of aliases for that IP address includes bda1node01-master. The Mammoth Utility uses Puppet for the software installation.

  • Checks the network timing on all nodes. If the timing checks fail, then there are unresolved names and IP addresses that will prevent the installation from running correctly. Fix these issues before continuing with the installation.

Step 2   PreInstallChecks

This step performs a variety of hardware and software checks. A failure in any of these checks causes the Mammoth Utility to fail:

  • The ARP cache querying time is 2 seconds or less.

  • All server clocks are synchronized within 10 seconds of the current server.

  • All servers succeeded on the last restart and generated a /root/BDA_REBOOT_SUCCEEDED file.

  • The bdacheckhw utility succeeds.

  • The bdachecksw utility succeeds.

Step 3   SetupPuppet

This step configures puppet agents on all nodes and start them, configures a puppet master on the node where the Mammoth Utility is being run, waits for the agents to submit their certificates, and automates their signing. After this step is completed, Puppet can deploy the software.

Puppet is a distributed configuration management tool that is commonly used for managing Hadoop clusters. The puppet master is a parent service and maintains a Puppet repository. A puppet agent operates on each Hadoop node.

A file named /etc/puppet/puppet.conf resides on every server and identifies the location of the puppet master.

Puppet operates in two modes:

  • Periodic pull mode in which the puppet agents periodically contact the puppet master and asks for an update, or

  • Kick mode in which the puppet master alerts the puppet agents that a configuration update is available, and the agents then ask for the update. Puppet operates in kick mode during the Mammoth Utility installation.

In both modes, the puppet master must trust the agent. To establish this trust, the agent sends a certificate to the puppet master node where the sys admin process signs it. When this transaction is complete, the puppet master sends the new configuration to the agent.

For subsequent steps, you can check the Puppet log files on each server, as described in "What If an Error Occurs During the Installation?".

Step 4   PatchFactoryImage

Installs the most recent Oracle Big Data Appliance image and system parameter settings.

Step 5   CopyLicenseFiles

Copies third-party licenses to /opt/oss/src/OSSLicenses.pdf on every server, as required by the licensing agreements.

Step 6   CopySofwareSource

Copies third-party software source code to /opt/oss/src/ on every server, as required by the licensing agreements.

Step 7   CreateLogicalVolumes

Creates a logical volume if physical disks are allocated to Oracle NoSQL Database. This step varies depending on the amount of disk space allocated to Oracle NoSQL Database during configuration:

  • 0 terabytes: This step does nothing.

  • 54 terabytes: The disk space is allocated across the cluster using one disk on each node. The disk mounted at /u12 is used for the logical volume.

  • 108 terabytes: The disk space is allocated across the cluster using two disks on each node. The disks mounted at /u11 and /u12 are used for the logical volume.

The logical volume is mounted at /lv1 and corresponds to device /dev/lvg1/lv1.

After this step finishes, the Linux file systems table in /etc/fstab shows the logical disk instead of /u12, or /u11 and /u12.

Step 8   CreateUsers

Creates the hdfs and mapred users, and the hadoop group. It also creates the oracle user and the dba and oinstall groups.

The various packages installed in later steps also create users and groups during their installation.

See Also:

Oracle Big Data Appliance Software User's Guide for more information about users and groups.
Step 9   SetupMountPoints

The NameNode data is copied to multiple places to prevent a loss of this critical information should a failure occur in either the disk or the entire node where they are set up.

Step 10   SetupMySQL

Installs and configures MySQL Database. This step creates the primary database and several databases on node03 for use by Cloudera Manager. It also sets up replication of the primary database to a backup database on node02.

Step 11   InstallHadoop

Installs all packages in Cloudera's Distribution including Apache Hadoop (CDH) and Cloudera Manager. It then starts the Cloudera Manager server on node03 and configures the cluster.

Step 12   StartHadoopServices

Starts the agents on all nodes and starts all CDH services. After this step, you have a fully functional Hadoop installation.

Cloudera Manager runs on port 7180 of node03. You can open it in a browser, for example:

http://bda1node03.example.com:7180

In this example, bda1node02 is the name of node02 and example.com is the domain. The default user name and password is admin, which is changed in Step 17.

Step 13   StartHiveService

Starts the Hive service on node03 and copies the Hadoop client configuration to /etc/hadoop/conf on all nodes.

Step 14   InstallBDASoftware

Installs Oracle NoSQL Database Community Edition and the server-side components of Oracle Big Data Connectors, if these options were selected in the Oracle Big Data Appliance Configuration Worksheets. Oracle NoSQL Database must be allocated disk space (54 or 108 TB), and Oracle Big Data Connectors must be licensed separately.

Step 15   SetupEMAgent

Installs and configures the Oracle Enterprise Manager agent.

Step 16   SetupASR

Installs and configures Auto Service Request (ASR).

Note:

For this step to run successfully, the ASR host system must be up with ASR Manager running and configured properly. See Chapter 5.

This step does the following:

  • Installs the required software packages

  • Configures the trap destinations

  • Starts the monitoring daemon

To activate the assets from ASR Manager, see "Verifying ASR Assets".

Step 17   CleanupInstall

Performs the following:

  • Changes the root password on all nodes (optional).

  • Changes the Cloudera Manager password if specified in the Installation Template.

  • Deletes temporary files created during the installation.

  • Copies log files from all nodes to subdirectories in /opt/oracle/bda/install/log.

  • Runs cluster verification checks, including TeraSort, to ensure that everything is working properly. It also generates an install summary. All logs are stored in a subdirectory under /opt/oracle/bda/install/log on node01.

Step 18   CleanupSSHroot (Optional)

Removes passwordless SSH for root that was set up in Step 1.

9.7 Mammoth Reconfiguration Utility Syntax

You must log in as root on the first server and change to the /opt/oracle/BDAMammoth directory to use the Mammoth Reconfiguration Utility. It has this syntax:

./mammoth-reconfig option parameter

Options 

add

Adds a service to the cluster. The parameter is a keyword that identifies the service:

  • asr: Turns on Auto Service Request monitoring on Oracle Big Data Appliance and activates assets on ASR Manager. The installation process prompts you for the ASR Manager host name, port number, user, and password. See Chapter 5 for more information about Auto Service Request.

  • em: Installs support for the Oracle Enterprise Manager system monitoring plug-in for Oracle Big Data Appliance. The installation process prompts you for the Oracle Management System (OMS) host name and port number, the Enterprise Manager super-administrative user and password, and the Enterprise Manager agent registration password.

This example adds Auto Service Request support to all servers in the cluster:

# cd /opt/oracle/BDAMammoth
# ./mammoth-reconfig add asr

See "Software Configuration" for detailed descriptions of the required information, and "Changing the Configuration of Optional Software" for example output.

remove

Removes a service from the cluster. The parameter is a keyword that identifies the service.

  • em: Removes support for the Oracle Enterprise Manager system monitoring plug-in. You must provide the Enterprise Manager super-administrative user password.

This example removes Oracle Enterprise Manager support from all servers in the cluster:

# cd /opt/oracle/BDAMammoth
# ./mammoth-reconfig remove em