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.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.
For one Oracle Big Data Appliance rack that forms one Hadoop cluster, 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 reinstall 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 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
Change to the BDAMammoth-version directory:
# cd BDAMammoth-2.0.1
Extract all files from BDAMammoth-version.run:
# ./BDAMammoth-2.0.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 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 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 to generate the configuration files.
Use the older version of the Mammoth Utility to install the software.
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.
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.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.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:
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.
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
Change to the BDAMammoth-version directory:
# cd BDAMammoth-2.0.1
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.
Change to the BDAMammoth directory.
# cd /opt/oracle/BDAMammoth
Run the mammoth command with the -p option:
./mammoth -p
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.
Stop Oracle Data Integrator and Oracle NoSQL Database.
Update the factory image.
Stop Cloudera Manager.
Install the new version of Cloudera Manager.
Start Cloudera Manager.
Upgrade the databases used by Cloudera Manager.
Stop and uninstall all Hadoop services.
Install the new version of Hadoop
Upgrade the cluster from CDH3 to CDH4 format and finalize the upgrade.
Delete the old CDH services (HDFS, MapReduce, and Hue) and create the new services (HDFS, MapReduce, Hue, Oozie, and ZooKeeper).
Mount the new shared directory from node03.
Set up MySQL Database.
Set up the new configuration files on all nodes for Cloudera Manager.
Move the Cloudera management service from node02 to node03. After this step, you access the Cloudera Manager web page on node03.
Restart Cloudera Manager.
Start all CDH services. This step enables High Availability and automatic failover.
Restart the Hive service.
Copy the source code of all open source packages to all nodes.
Upgrade the optional software components: Oracle Big Data Connectors and Oracle NoSQL Database.
Clean up the installation and run the cluster checks.
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.
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:
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 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.Establish an SSH connection to node01 and log in as root.
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 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 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
Change to the BDABaseImage-version_RELEASE directory created in the previous step, for example:
# cd BDABaseImage-2.0.1_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:
Ensure that /opt/oracle/bda/BdaDeploy.json exists and contains the customer network settings.
Execute the ./reimagerack command.
To reimage an appliance that still has the factory settings:
Ensure that /opt/oracle/bda/bdaShip.json exists.
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:
Ensure that /opt/oracle/bda/BdaDeploy.json exists and contains the customer 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.
Disconnect the rack from the network.
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.
Set up passwordless SSH for root:
# setup-root-ssh
See setup-root-ssh.
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
.
.
.
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]
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
This command generates a parameter file to add six servers in an 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 expansion kits.
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 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.
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:
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.
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 17.
Starts the Hive service on node03 and copies the Hadoop client configuration to /etc/hadoop/conf on all nodes.
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.
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
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