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.Mammoth is a command-line utility for installing and configuring the Oracle Big Data Appliance software. Using Mammoth, you can:
Create a CDH cluster on one or more racks.
Create multiple CDH clusters on a Oracle Big Data Appliance rack.
Extend a CDH cluster on to new servers.
Update a cluster with new software.
Deploy Auto Service Request during or after the initial software installation.
Deploy the Oracle Enterprise Manager system monitoring plugin for Oracle Big Data Appliance during or after the initial software installation.
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.
Complete the appropriate instructions for your installation:
For an Oracle Big Data Appliance rack that forms one or more Hadoop clusters, follow the procedure in "Installing the Software on a Single or Primary Rack."
For multiple racks where each rack forms an independent Hadoop cluster, follow the procedure in "Installing the Software on a Single or Primary Rack" for each rack.
For multiple racks that form a single, multirack Hadoop cluster:
Identify the primary rack of the cluster, then follow the procedure in "Installing the Software on a Single or Primary Rack."
For the other racks of the cluster, follow the procedure in "Adding Servers to a Cluster."
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.
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."
Verify that the software is not installed on the rack already. If the software is installed and you want to upgrade it, then use the mammoth -p option in Step 9.
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.
Log in as root and extract all files from the downloaded zip file:
# unzip p16694238_211_Linux-x86-64.zip
Archive: p16694238_211_Linux-x86-64.zip
inflating: README.txt
creating: BDAMammoth-2.1.1/
inflating: BDAMammoth-2.1.1/bda-configurator-2.1.1.ods
inflating: BDAMammoth-2.1.1/BDAMammoth-2.1.1.run
Change to the BDAMammoth-version directory:
# cd BDAMammoth-2.1.1
Extract all files from BDAMammoth-version.run:
# ./BDAMammoth-2.1.1.run
Change to the BDAMammoth directory.
# cd /opt/oracle/BDAMammoth
Copy mammoth-rack_name.params to the current directory. See "About the Configuration Files."
Run the mammoth command with the appropriate options. See "Mammoth Utility Syntax." This sample command runs all steps:
./mammoth -i rack_name
To configure another Hadoop cluster on the server:
Copy the BDAMammoth zip file to any directory on the first server of the cluster, which is either server 7 or server 13.
Repeat Steps 4 to 9. Each cluster has its own mammoth-rack_name.params file. The file names are identical, but the Oracle Big Data Appliance Configuration Utility creates the files in separate directories named for the cluster.
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 must use it again, such as adding a rack to the cluster.
You can add servers to an existing cluster in groups of three servers, as defined in the Oracle Big Data Appliance Configuration Worksheets. You add a full rack the same way that you add a smaller number of servers. The spreadsheet does not generate the configuration file. Instead, you use Mammoth to generate the configuration file and then use it to configure the servers.
To install the software on additional servers in a cluster:
Ensure that all servers are running the same software version. See "About Software Version Differences".
Ensure that all racks that form a single Hadoop cluster are cabled together. See Chapter 8.
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.
Generate a parameter file for the server group. The following example adds six servers beginning with node13:
./mammoth -e node13 6
See the -e option in "Mammoth Utility Syntax."
If you are prompted for an expansion number, enter an integer from 1 to 5.
Install the software. The following example begins installing software on the servers in bda3 with an expansion number of 1:
./mammoth -i bda3 1
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.
Run the Mammoth Utility with the -p option to upgrade the software on the cluster to the latest version. See "Upgrading the Software on Oracle Big Data Appliance."
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, which is on the first server of the existing cluster, to extend the cluster onto the new rack.
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. You cannot skip steps or run them out of order.
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 themammoth command is executing.Following is a summary of the changes an upgrade makes to the software on a cluster:
CDH4 replaces CDH3, and Cloudera Manager 4.5 replaces Cloudera Manager 3.7.
Cloudera Manager 4.5 manages Hive, so you use Cloudera Manager to start, stop, and configure Hive.
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 are 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.Follow these procedures to upgrade the software on an Oracle Big Data Appliance cluster from version 2.0 or 1.1 to version 2.1.
Note:
This procedure upgrades version 1.1 software from CDH3 to CDH 4. You do not need to upgrade your mapreduce programs, but you do need to recompile them after this upgrade.You must know the passwords currently in effect for the cluster, which the Mammoth utility will prompt you for:
oracle
root
Cloudera Manager admin
MySQL Database admin
MySQL Database for Oracle Data Integrator (if Oracle Data Integrator agent is installed))
To upgrade the software:
Download the BDAMammoth zip file to any directory (such as /tmp) on the first node of the cluster. Depending on the configuration of the rack, this node can be the first, seventh, or thirteenth server from the bottom of the rack. For multirack clusters, this server is in 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.1.1 to upgrade your appliance to 2.1.1 software.
Log in to the first node of the cluster as root.
Extract all files from the downloaded zip file:
# unzip p16694238_211_Linux-x86-64.zip
Archive: p16694238_211_Linux-x86-64.zip
inflating: README.txt
creating: BDAMammoth-2.1.1/
inflating: BDAMammoth-2.1.1/bda-configurator-2.1.1.ods
inflating: BDAMammoth-2.1.1/BDAMammoth-2.1.1.run
Change to the BDAMammoth-version directory:
# cd BDAMammoth-2.1.1
Extract all files from BDAMammoth-version.run:
# ./BDAMammoth-2.1.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.
Change to the BDAMammoth directory.
# cd /opt/oracle/BDAMammoth
Run the mammoth command with the -p option:
./mammoth -p
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:
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.
Log into the first NameNode (node01) of the primary rack and change to the BDAMammoth directory:
cd /opt/oracle/BDAMammoth
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:
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.
Log into the first NameNode (node01) of the primary rack and change to the BDAMammoth directory:
cd /opt/oracle/BDAMammoth
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 ... . . .
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.
You can reimage all of part of a rack. However, all the servers in a cluster must have the same image. Follow the appropriate instructions:
Follow this procedure to reimage one server, for example, following replacement of a failed server.
Caution:
If you reimage a server, then all files and data are erased.To reinstall the base image on one server:
Download the latest Oracle Big Data Appliance Base Image tarball from My Oracle Support, and copy it to the server to be re-imaged.
If you are reimaging the server to the current customer settings, verify that /opt/oracle/bda/BdaDeploy.json reflects the intended network configuration. If it does not, then generate a new file using the Oracle Big Data Appliance Configuration Utility. See Chapter 4.
Ensure that 4 GB or more disk space are free in the partition:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md2 161G 23G 130G 15% /
/dev/md0 194M 40M 145M 22% /boot
tmpfs 24G 0 24G 0% /dev/shm
/dev/sda4 1.7T 197M 1.7T 1% /u01
/dev/sdb4 1.7T 197M 1.7T 1% /u02
/dev/sdc1 1.8T 199M 1.8T 1% /u03
/dev/sdd1 1.8T 199M 1.8T 1% /u04
.
.
.
Unzip the base image zip file:
# unzip p16685583_210_Linux-x86-64.zip
Archive: p16065021_201_Linux-x86-64.zip
inflating: README.txt
creating: BDABaseImage-2.1.0_RELEASE/
inflating: BDABaseImage-2.1.0_RELEASE/reimagerack
inflating: BDABaseImage-2.1.0_RELEASE/BDABaseImage-2.1.0_RELEASE.iso
inflating: BDABaseImage-2.1.0_RELEASE/reimagecluster
extracting: BDABaseImage-2.1.0_RELEASE/BDABaseImage-2.1.0_RELEASE.md5sum
inflating: BDABaseImage-2.1.0_RELEASE/makebdaimage
inflating: BDABaseImage-2.1.0_RELEASE/ubiosconfig
inflating: BDABaseImage-2.1.0_RELEASE/biosconfig
Change to the BDABaseImage-2.1.0_RELEASE directory created in the previous step:
$ cd BDABaseImage-2.1.0_RELEASE
Reimage the server using the makedbaimage command. The following example reimages server 4, including the internal USB, from the 2.1.0 base image to the custom settings in BdaDeploy.json
./makebdaimage -usbint BDABaseImage-2.1.0_RELEASE.iso /opt/oracle/bda/BdaDeploy.json 4
See makebdaimage for the complete syntax of the command.
If the makedbaimage command succeeded without errors, reboot the server.
Follow this procedure to reimage an entire rack.
Caution:
If you reimage an entire rack, then all clusters, files, and data on the rack are erased.To reinstall the base image on all servers in a rack:
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.
Download the most recent base image from My Oracle Support and copy it to the first (bottom) server of the rack being reimaged. For the download location, see My Oracle Support Information Center ID 1445745.2. You can copy the file to any directory, such as /tmp.
Establish an SSH connection to the first server and log in as root.
If you are reimaging to existing customer network settings, then verify that /opt/oracle/bda/BdaDeploy.json reflects the intended network configuration. If it does not, then generate a new file using the Oracle Big Data Appliance Configuration Utility. See Chapter 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 must run without errors and return the host names of all 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.
Check all Oracle Big Data Appliance servers for hardware issues:
# dcli bdacheckhw | grep -v SUCCESS
Resolve any hardware errors and warnings before reimaging the rack.
Verify that at least 4 GB are available in the root (/) partition of all servers:
# 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% /
.
.
.
Extract all files from the base image zip file:
# unzip p16685583_210_Linux-x86-64.zip
Archive: p16685583_210_Linux-x86-64.zip
inflating: README.txt
creating: BDABaseImage-2.1.0_RELEASE/
inflating: BDABaseImage-2.1.0_RELEASE/reimagerack
inflating: BDABaseImage-2.1.0_RELEASE/BDABaseImage-2.1.0_RELEASE.iso
inflating: BDABaseImage-2.1.0_RELEASE/reimagecluster
extracting: BDABaseImage-2.1.0_RELEASE/BDABaseImage-2.1.0_RELEASE.md5sum
inflating: BDABaseImage-2.1.0_RELEASE/makebdaimage
inflating: BDABaseImage-2.1.0_RELEASE/ubiosconfig
inflating: BDABaseImage-2.1.0_RELEASE/biosconfig
Change to the BDABaseImage-version_RELEASE directory created in the previous step, for example:
# cd BDABaseImage-2.1.0_RELEASE
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, execute the ./reimagerack command.
To reimage an appliance that still has the factory settings:
Ensure that /opt/oracle/bda/BdaDeploy.json does not exist.
Execute the ./reimagerack command.
To restore the factory network settings on a rack configured with custom network settings:
Copy /opt/oracle/bda/BdaDeploy.json to a safe location outside Oracle Big Data Appliance.
Ensure that /opt/oracle/bda/BdaShip.json exists.
Reimage the rack:
./reimagerack deploy ship
See reimagerack for the complete syntax of the command.
Run the Mammoth Utility. See "Installing the Software on a Single or Primary Rack."
Follow this procedure to reimage a group of servers that the Mammoth utility has deployed as a cluster. The existing network settings are automatically reapplied after reimaging.
Caution:
If you reimage a cluster, then all files and data on the cluster are erased.To reinstall the base image on all servers in a cluster:
Save the /opt/oracle/BDAMammoth/mammoth-rack_name.params file to a safe place outside Oracle Big Data Appliance.
Download the most recent base image from My Oracle Support and copy it to the first server of the cluster being reimaged.You can copy the file to any directory, such as /tmp. For the download location, see My Oracle Support Information Center ID 1445745.2.
Depending on the configuration of clusters in the rack, the first server might be 1, 7, 10, or 13, counting from the bottom
Establish an SSH connection to the first server and log in as root.
Verify that /opt/oracle/bda/BdaDeploy.json reflects the intended network configuration. If it does not, then generate a new file using the Oracle Big Data Appliance Configuration Utility. See Chapter 4.
Ensure that passwordless SSH is set up:
# dcli -C hostname
192.168.41.37: bda1node01.example.com
192.168.41.38: bda1node02.example.com
192.168.41.39: bda1node03.example.com
.
.
.
This command must run without errors and return the host names of all Oracle Big Data Appliance servers in the cluster. If not, then follow the steps in "Setting Up Passwordless SSH". Do not continue until the dcli -C hostname command runs successfully on all servers.
Check all Oracle Big Data Appliance servers for hardware issues:
# dcli -C bdacheckhw | grep -v SUCCESS
Resolve any hardware errors and warnings before reimaging the rack.
Verify that at least 4 GB are available in the root (/) partition of all servers:
# dcli -C 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% /
.
.
.
Extract all files from the base image zip file:
# unzip p16685583_210_Linux-x86-64.zip
Archive: p16685583_210_Linux-x86-64.zip
inflating: README.txt
creating: BDABaseImage-2.1.0_RELEASE/
inflating: BDABaseImage-2.1.0_RELEASE/reimagerack
inflating: BDABaseImage-2.1.0_RELEASE/BDABaseImage-2.1.0_RELEASE.iso
inflating: BDABaseImage-2.1.0_RELEASE/reimagecluster
extracting: BDABaseImage-2.1.0_RELEASE/BDABaseImage-2.1.0_RELEASE.md5sum
inflating: BDABaseImage-2.1.0_RELEASE/makebdaimage
inflating: BDABaseImage-2.1.0_RELEASE/ubiosconfig
inflating: BDABaseImage-2.1.0_RELEASE/biosconfig
Change to the BDABaseImage-version_RELEASE directory created in the previous step:
# cd BDABaseImage-2.1.0_RELEASE
Reimage the cluster:
./reimagecluster
See reimagecluster for the complete syntax of the command.
Run the Mammoth Utility. See "Installing the Software on a Single or Primary Rack."
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] [extension_number]
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[-extnumber].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
This command generates a parameter file to add six servers in an in-rack expansion kit, beginning with node07, to an existing cluster:
./mammoth -e node07 6
The next command runs steps 2 through 6 on the rack being set up:
./mammoth -r 2-6
The syntax of the mammoth command supports the configuration of new racks and in-rack expansion kits. You can also use the Mammoth 2.1.1 bundle to upgrade from 2.0 or 1.1.
Run the Oracle Big Data Appliance cluster checks.
Generates a parameter file for a group of servers being added to a cluster. The file is named mammoth-rack_name.params if the new servers are in a rack outside the cluster. Otherwise, Mammoth prompts for an in-rack expansion number from 1 to 5 that it uses in the name, such as mammoth-bda1-1.
start_node is the client network host name for the first server in the group being added.
number_of_nodes is the number of servers being added to the cluster. The number must be a multiple of three.
No passwords are included in the parameter file, so you must enter them when running Mammoth.
Displays command Help including command usage and a list of steps.
Runs all mandatory steps, equivalent to -r 1-18 for a full rack. Use this option when configuring a new rack or adding a group of servers to a cluster.
rack_name identifies the location of new servers being added to a cluster when they are outside the primary rack.
expansion_number identifies the mammoth-rack-name.params file when an expansion number is included in the name. See the -e option.
List the steps of the Mammoth Utility.
Upgrades the software on the cluster to the current version.
Run steps n through N of the Mammoth Utility while no errors occur
Runs step n on the primary rack. Enter the rack_name to identify another rack in the same cluster, and an expansion_number if needed. See the -e option.
Displays the version number of the Mammoth Utility.
Following are descriptions of the steps that the Mammoth Utility and the Mammoth Reconfiguration Utility perform when installing the software.
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.
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.
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?".
Installs the most recent Oracle Big Data Appliance image and system parameter settings.
Copies third-party licenses to /opt/oss/src/OSSLicenses.pdf on every server, as required by the licensing agreements.
Copies third-party software source code to /opt/oss/src/ on every server, as required by the licensing agreements.
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. Each cluster size (6, 9, or 12 servers) offers a choice in the number of terabytes allocated to Oracle NoSQL Database. For example, a full rack of 18 servers offers a choice of 54 or 108 terabytes.
0 terabytes: This step does nothing.
Smaller number of 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.
Larger number of 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.
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.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.
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.
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.
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 16.
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, and Oracle Big Data Connectors must be licensed separately.
Installs and configures the Oracle Enterprise Manager agent.
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".
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.
Removes passwordless SSH for root that was set up in Step 1.
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
Note:
Where parameter is a node name in the syntax examples, bda1 is the rack name, node is the server base name, and -adm is the administrative access suffix.
This utility uses the configuration settings stored in /opt/oracle/bda/install/state/mammoth-saved.params. When the utility makes a change, it modifies this file to reflect the new configuration.
Options
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.
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
The following utilities are distributed in the base image bundle. To run the utilities, you must be logged in as root.
Reinstalls the base image on a single server, a cluster, or an entire rack. Both reimagecluster and reimagerack call this utility.
The makedbaimage utility has this syntax:
makebdaimage [--usb | usbint] [--noiloms] /path/BDABaseImage-version_RELEASE.iso /path/BDdaDeploy.json target_servers
Options
Identifies the USB port that will be used for reimaging. Use --usb for the external USB drive, or --usbint for the internal drive.
The reimaging process does not alter the Oracle ILOMs on the target servers.
The servers where the image will be installed, which you specify using one of these formats:
node_number
Identifies one server for reimaging. Enter the position of the server in the rack, from 1 to 18, counting from bottom to top.
from.json to.json
Identifies the current configuration (from.json) and the desired configuration (to.json). The JSON files can be either the factory configuration in BdaShip.json or a custom configuration in BdaDeploy.json. You can find them in /opt/oracle/bda on configured servers.
to.json: Concatenation of JSON files similar to BdaDeploy.json and BdaShip.json, but containing an extra ETH0_MACS array entry. The first entry in the concatenated file with a matching eth0_mac entry is used when reimaging. The to.json file is taken as is.
Reimages all servers in the cluster in parallel using dcli and makebdaimage.
The reimagecluster utility has this syntax:
reimagecluster [--no-iloms] [from.json [to.json]]
Prerequisites
Verify that the following command returns the list of servers in the cluster:
$ dcli -C hostname
Ensure that exactly one BDABaseImage-version_RELEASE*.iso file is in the current directory.
Options
The reimaging process does not alter the Oracle ILOMs on the target servers.
The full path to the current configuration file, either BdaShip.json or BdaDeploy.json.
This option defaults to /opt/oracle/bda/BdaDeploy.json. If BdaDeploy.son is missing, then the option defaults to /opt/oracle/bda/BdaShip.json. The servers must already be set to the values in the JSON file used by reimagecluster.
The full path to the new network configuration in effect after reimaging. It can be either a BdaDeploy.json or a BdaShip.json file.
Reimages all servers in the rack in parallel using dcli and makedbaimage.
The reimagerack utility has this syntax:
reimagerack [--no-iloms] [--no-macs] [--hosts n1, n2...] [from.json [to.json]]
Prerequisites
Verify that the following command returns the list of servers in the rack:
$ dcli -hostname
Ensure that exactly one BDABaseImage-version_RELEASE*.iso file is in the current directory.
Options
The reimaging process does not alter the Oracle ILOMs on the target servers.
The utility does not retrieve the server MAC addresses. Instead, it uses the InfiniBand cabling. Use this option only when restoring the factory settings; you must include both JSON files (from.json and to.json) in the command line.
Restricts reimaging to the servers identified by a comma-delimited list of host names or IP addresses, whichever one dcli accepts. All servers must be in the list of target servers identified by the dcli -t command.
This option enforces the --no-macs option, so its restrictions also apply.
The full path to the current configuration file, either BdaShip.json or BdaDeploy.json.
This option defaults to /opt/oracle/bda/BdaDeploy.json. If BdaDeploy.son is missing, then the option defaults to /opt/oracle/bda/BdaShip.json. The servers must already be set to the values in the JSON file used by reimagerack.
The full path to the new network configuration in effect after reimaging. It can be either a BdaDeploy.json or a BdaShip.json file.