This chapter explains how to install, reinstall, and reconfigure the software on Oracle Big Data Appliance. It contains these sections:
Note:
If you did not enter the required passwords in the Oracle Big Data Appliance Configuration Generation Utility, then you are prompted to enter them during the software installation. Ensure that you know the current passwords for the operating system root and oracle users, the Cloudera Manageradmin user, and the MySQL administrator. If you are installing or 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 cluster on one or more racks.
Create multiple clusters on a Oracle Big Data Appliance rack.
Extend a cluster 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 plug-in for Oracle Big Data Appliance during or after the initial software installation.
Before you begin the software installation, ensure that these procedures are complete:
You have the configuration files generated by the Oracle Big Data Appliance Configuration Utility. See Chapter 4.
All racks of a multirack installation are cabled together. See Chapter 9.
All components of all new racks are configured. See Chapter 7.
The checkip script ran successfully with no remaining errors. See "Preparing the Network for Oracle Big Data Appliance".
The Oracle Audit Vault, Auto Service Request, and Oracle Enterprise Manager options require software on a remote server on the same network as Oracle Big Data Appliance. Those installations must be complete before you run Mammoth, or it will fail.
Similarly, you must complete several steps for Kerberos if the key distribution center (KDC) is installed on a remote server. There are no preliminary steps if you install the KDC on Oracle Big Data Appliance.
Oracle Audit Vault and Database Firewall Server Release 12.1.1 or later must be up and running on a separate server on the same network as Oracle Big Data Appliance
Auto Service Request Requirements:
Your My Oracle Support account is set up.
ASR Manager is up and running.
Enterprise Manager Requirements:
Oracle Management System (OMS) version 12.1.0.3.0 or higher is up and running.
The OMS agent pull URL is working.
The OMS emcli download URL is working.
Both the HTTPS upload port and the console port are open.
Note:
Double-check the OMS credentials and ensure that you enter them correctly when running Mammoth. Invalid credentials are the primary cause of failure in the Enterprise Manager discovery process.Kerberos Requirements for a Remote KDC:
Add cloudera-scm/admin as a user to the KDC database by running the following command from kadmin:
addprinc -randkey cloudera-scm/admin@<REALM NAME>
Grant cloudera-scm/admin all permissions to the Kerberos database. It must be able to add, modify, remove, and list principals from the database.
Create the cmf.keytab file by running the following command from kadmin:
xst -k cmf.keytab cloudera-scm/admin@<REALM NAME>
Move cmf.keytab to/opt/oracle/BDAMammoth.
To support Oozie and Hue, ensure that the remote KDC supports renewable tickets. If it does not, then follow these steps:
Open kdc.conf and set values for max_life and max_renewable_life. The max_life parameter defines the time period when the ticket is valid, and the max_renewable_life parameter defines the time period when users can renew a ticket.
Set maxrenewlife for the krbtgt principal. Use the following kadmin command, replacing duration with the time period and REALM NAME with the name of the realm:
modprinc -maxrenewlife duration krbtgt/REALM NAME
If the KDC does not support renewable tickets when Kerberos is configured, then Oozie and Hue might not work correctly.
Sentry Requirements
Create a Sentry policy file named sentry-provider.ini.
Copy the file to /opt/oracle/BDAMammoth on the first node in the cluster.
See Also:
For information about creating a policy file, "Configuring Sentry" in the CDH4 Security Guide atThe Mammoth bundle contains the installation files and the base image. Before you install the software, you must use Oracle Big Data Appliance Configuration Generation Utility to generate the configuration files, as described in "Generating the Configuration Files."
You use the same bundle for all procedures described in this chapter, regardless of rack size, and whether you are creating CDH or Oracle NoSQL Database clusters, or upgrading existing clusters.
To download the Mammoth bundle:
Log in to My Oracle Support and search the knowledge base for Information Center ID 1445745.2.
Locate the appropriate release number and patch.
Download the BDAMammoth ZIP files to any directory (such as /tmp) in 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.
The patch consists of two files:
Log in to the first node of the cluster as root.
Extract all files from the downloaded zip files. For example:
$ unzip p12345678_250_Linux-x86-64_1of2.zip Archive: p12345678_250_Linux-x86-64_1of2.zip inflating: README.txt creating: BDAMammoth-ol6-2.5.0/ inflating: BDAMammoth-ol6-2.5.0/BDAMammoth-ol6-2.5.0.run $ unzip p12345678_250_Linux-x86-64_2of2.zip Archive: p12345678_250_Linux-x86-64_2of2.zip creating: BDABaseImage-ol6-2.5.0_RELEASE/ inflating: BDABaseImage-ol6-2.5.0_RELEASE/biosconfig inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagecluster inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagerack inflating: BDABaseImage-ol6-2.5.0_RELEASE/makebdaimage inflating: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.iso inflating: BDABaseImage-ol6-2.5.0_RELEASE/README.txt extracting: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.md5sum inflating: BDABaseImage-ol6-2.5.0_RELEASE/ubiosconfig
Change to the BDAMammoth-version directory:
# cd BDAMammoth-ol6-2.5.0
Extract all files from BDAMammoth-version.run:
# ./BDAMammoth-ol6-2.5.0.run
Big Data Appliance Mammoth v2.5.0 Self-extraction
Checking for and testing BDA Base Image in /tmp
BDABaseImage-2.5.0_RELEASE.iso: OK
Removing existing temporary files
Generating /tmp/BDAMammoth.tar
Verifying MD5 sum of /tmp/BDAMammoth.tar
/tmp/BDAMammoth.tar MD5 checksum matches
Extracting /tmp/BDAMammoth.tar to /opt/oracle/BDAMammoth
Extracting Base Image RPMs to bdarepo
Moving BDABaseImage into /opt/oracle/
Removing temporary files
.
.
.
Please "cd /opt/oracle/BDAMammoth" before running "./mammoth -i <rack_name>"
#
The new version of the Mammoth software is installed in /opt/oracle/BDAMammoth, and the previous version (if you are upgrading) is saved in /opt/oracle/BDAMammoth/previous-BDAMammoth.
Follow the specific instructions for the type of installation you are performing.
Mammoth installs and configures the software on Oracle Big Data Appliance using the files generated by Oracle Big Data Appliance Configuration Generation Utility. A cluster can be dedicated either to CDH (Hadoop) or Oracle NoSQL Database.
For a CDH cluster, 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. If you have a license, Mammoth optionally installs and configures all components of Oracle Big Data Connectors.
For a NoSQL cluster, Mammoth installs Oracle NoSQL Database. CDH and Oracle NoSQL Database do not share a cluster, beginning with Oracle Big Data Appliance 2.2.
In addition to installing the software across all servers in the rack, Mammoth 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 clusters, follow the procedure in "Installing the Software on a Single or Primary Rack."
For multiple racks where each rack forms an independent 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 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.
To install the software on a single or primary rack:
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 6.
Download and unzip the Mammoth bundle, as described in "Downloading the Mammoth Software Deployment Bundle." You must be logged in as root to the first server in the cluster.
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 Software Installation and Configuration Utility." This sample command runs all steps:
./mammoth -i rack_name
If you installed support for Auto Service Request, then complete the steps in "Verifying the Auto Service Request Installation."
To configure another CDH 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 3 to 7. Each cluster has its own mammoth-rack_name.params file. Oracle Big Data Appliance Configuration Generation Utility creates the files in separate directories named for the clusters.
Note:
Mammoth stores the current configuration in the/opt/oracle/bda/install/state directory. Do not delete the files in this directory. Mammoth fails without this information if you must use it again, such as adding a rack to the cluster.Verifying the Auto Service Request Installation
Log in to My Oracle Support at http://support.oracle.com.
Search for document ID 1450112.1, ASR Exadata Configuration Check via ASREXACHECK, and download the asrexacheck script.
Although this check was originally intended for Oracle Exadata Database Machine, it is now supported on Oracle Big Data Appliance.
Copy asrexacheck to a server in the Oracle Big Data Appliance cluster.
Log in to the server as root.
Copy asrexacheck to all servers in the cluster:
# dcli -C -f asrexacheck -d /opt/oracle.SupportTools
See Chapter 13 for information about dcli.
Change the file access permissions:
# dcli -C chmod 755 /opt/oracle.SupportTools/asrexacheck
Run the script:
# dcli -C /opt/oracle.SupportTools/asrexacheck
File an Oracle Support Request (SR) to validate the ASR installation. Note the following choices:
Under "What is the Problem?" click the Hardware tab.
For Products Grouped By, select Hardware License.
For Problem Type, select My - Auto Service Request (ASR) Installation and Configuration Issues.
Include the output of asrexacheck.
Continue with Step 8 of the software installation procedure.
You can add servers to an existing cluster in groups of three servers. You add a full rack the same way that you add a smaller number of servers. However, Oracle Big Data Appliance Configuration Generation Utility 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 9.
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 Software Installation and Configuration Utility."
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 are using Oracle Enterprise Manager Cloud Control to monitor Oracle Big Data Appliance, then run rediscovery to identify the hardware and software changes.
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.
Mammoth 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 Mammoth fails.
About Software Version Differences
All servers configured as one Hadoop cluster must have the same image. A new Oracle Big Data Appliance rack or an in-rack expansion kit might 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 servers of a single Hadoop cluster have the same image version, you can install the software.
To synchronize the new servers 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 servers.
Run Mammoth 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 old version of the Mammoth utility, which is on the first server of the existing cluster, to extend the cluster onto the new rack.
If you add a newer server model, then you can downgrade only to the first software version available for that model. For example, if you add Sun Server X3-2L servers, then you must install Oracle Big Data Appliance software version 2.3 or higher.
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, Oracle Linux Unbreakable Enterprise Kernel (UEK), CDH, JDK, and Oracle Big Data Connectors (if previously installed). Two versions of the software bundle are available, one for Oracle Linux 5 and the other for Oracle Linux 6).
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.The Oracle Big Data Appliance 2.3 and later software runs on either Oracle Linux version 5 or version 6. When upgrading the software, you can choose whether to upgrade the operating system also:
Retaining Oracle Linux 5: Download the Mammoth bundle for Oracle Linux 5. It retains Oracle Linux 5, but upgrades Oracle Unbreakable Enterprise Kernel (UEK) to version 2. It installs all of the Oracle Big Data Appliance software for this release.
Upgrading to Oracle Linux 6: Download the Mammoth bundle for Oracle Linux 6. To upgrade the operating system, you must first reimage the servers. Reimaging erases all files and data, therefore Oracle does not recommend this type of upgrade for a production system, unless you have a second cluster functioning as a backup with the same data. After reimaging, you can install the software with Oracle Linux 6 and UEK version 2.
Follow these procedures to upgrade the software on an Oracle Big Data Appliance cluster from version 2.0 or later to version 2.5.
Earlier versions must first upgrade to 2.0.
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)
This upgrade migrates Oozie data from Apache Derby to MySQL Database. If there are Oozie jobs running, then the upgrade stops with an error. You can follow the instructions in "Migrating the Oozie Back End" before the upgrade if you know that Oozie is in use, or first start the upgrade and see if it fails.
Caution:
Oracle Big Data Appliance 2.2 and later versions do not support Oracle NoSQL Database in a CDH cluster. An upgrade completely removes Oracle NoSQL Database, including the data. You must create a separate cluster for Oracle NoSQL Database.Take these steps to upgrade the Oracle Big Data Appliance software to version 2.5:
If the cluster currently supports Oracle NoSQL Database, then complete the standard procedures for creating backup files for Oracle NoSQL Database.
Download and unzip the Mammoth bundle, as described in "Downloading the Mammoth Software Deployment Bundle." You must be logged in as root to the first server in the cluster.
Change to the BDAMammoth directory.
# cd /opt/oracle/BDAMammoth
Remove Oracle NoSQL Database, after you have backed up all your data:
# ./mammoth-reconfig remove nosqldb
Run the mammoth command with the -p option:
# ./mammoth -p
If the upgrade fails with errors concerning Oozie, then follow the instructions in "Migrating the Oozie Back End."
If you are using Oracle Enterprise Manager Cloud Control to monitor Oracle Big Data Appliance, then run rediscovery to identify the software changes.
Take these steps to migrate Oozie data from Derby to MySQL Database:
Open Cloudera Manager, check for any running Oozie jobs, and suspend them.
Migrate the data:
# mammoth-reconfig migrate oozie
Manually resolve any errors.
Continue the upgrade with step 5.
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.
This section provides examples of some reconfiguration options. It has the following topics:
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 ... . . .
Complete the steps in "Verifying the Auto Service Request Installation."
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 plug-in 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 following procedure configures disk encryption.
To support disk encryption:
Log into the first NameNode (node01) of the primary rack and change to the BDAMammoth directory:
cd /opt/oracle/BDAMammoth
Configure either TPM or password encryption on the current cluster. This example configures password encryption:
# mammoth-reconfig enable disk-encryption Use TPM (motherboard chip) Disk Encryption (y/n) : n Enter password to use for disk encryption Enter password: password Enter password again: password
See "Disk Encryption" for information about the encryption methods.
To change the password, use the mammoth-reconfig update command.
The following procedure configures Kerberos authentication.
To support Kerberos authentication:
Ensure that you complete the Kerberos prerequisites listed in "Installation Prerequisites."
Log into the first NameNode (node01) of the primary rack and change to the BDAMammoth directory:
cd /opt/oracle/BDAMammoth
Configure Kerberos:
# ./mammoth-reconfig add kerberos INFO: Logging all actions in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20131104072502.log and traces in /opt/oracle/BDAMammoth/bdaconfig/tmp/bda1node01-20131104072502.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... 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. Do you want to setup KDC on a BDA node (yes/no): yes Please enter the realm name: EXAMPLE.COM Enter password for Kerberos database: password Enter password again: password INFO: Executing changekrb5_kdc.sh on nodes bda1node01 #Step -1# SUCCESS: Executed changekrb5_kdc.sh on nodes bda1node01 #Step -1# SUCCESS: Successfully set the Kerberos configuration on the KDC INFO: Setting up Master KDC INFO: Executing setupKDC.sh on nodes bda1node01 #Step -1# . . .
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 Mammoth to install the Oracle Big Data Appliance software.
You can reimage all or 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 most recent base image patch from My Oracle Support or Oracle Automated Release Updates (ARU), and copy it to the server being reimaged. You can use the base image downloaded with the Mammoth bundle, or download the separate base image patch.
See "Downloading the Mammoth Software Deployment Bundle." You can take the same basic steps to download the base image patch from My Oracle Support.
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 Oracle Big Data Appliance Configuration Generation Utility. See "Generating the Configuration Files."
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 downloaded base image ZIP file (2 of 2). For example:
$ unzip p12345678_250_Linux-x86-64_2of2.zip
Archive: p12345678_250_Linux-x86-64_2of2.zip
creating: BDABaseImage-ol6-2.5.0_RELEASE/
inflating: BDABaseImage-ol6-2.5.0_RELEASE/biosconfig
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagecluster
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagerack
inflating: BDABaseImage-ol6-2.5.0_RELEASE/makebdaimage
inflating: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.iso
inflating: BDABaseImage-ol6-2.5.0_RELEASE/README.txt
extracting: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.md5sum
inflating: BDABaseImage-ol6-2.5.0_RELEASE/ubiosconfig
Change to the subdirectory created in the previous step:
$ cd BDABaseImage-ol6-2.5.0_RELEASE
Reimage the server using the makebdaimage command. The following example reimages server 4, including the internal USB, from the 2.5.0 base image to the custom settings in BdaDeploy.json. You must be logged in to the server being reimaged, which is server 4 in this example.
./makebdaimage -usbint BDABaseImage-ol6-2.5.0_RELEASE.iso /opt/oracle/bda/BdaDeploy.json 4
See makebdaimage for the complete syntax of the command.
If the makebdaimage command succeeds without errors, then 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 patch from My Oracle Support or Oracle Automated Release Updates (ARU), and copy it to the first (bottom) server of the rack being reimaged. You can use the base image downloaded with the Mammoth bundle, or download the separate base image patch.
See "Downloading the Mammoth Software Deployment Bundle." You can take the same basic steps to download the base image patch from My Oracle Support.
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 Oracle Big Data Appliance Configuration Generation Utility. See "Generating the Configuration Files."
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% /
.
.
.
Unzip the downloaded base image ZIP file (2 of 2). For example:
$ unzip p12345678_250_Linux-x86-64_2of2.zip
Archive: p12345678_250_Linux-x86-64_2of2.zip
creating: BDABaseImage-ol6-2.5.0_RELEASE/
inflating: BDABaseImage-ol6-2.5.0_RELEASE/biosconfig
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagecluster
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagerack
inflating: BDABaseImage-ol6-2.5.0_RELEASE/makebdaimage
inflating: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.iso
inflating: BDABaseImage-ol6-2.5.0_RELEASE/README.txt
extracting: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.md5sum
inflating: BDABaseImage-ol6-2.5.0_RELEASE/ubiosconfig
Change to the subdirectory created in the previous step:
$ cd BDABaseImage-ol6-2.5.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 Mammoth. 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. Reimaging is not required for a software upgrade.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 patch from My Oracle Support or Oracle Automated Release Updates (ARU), 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.
You can use the base image downloaded with the Mammoth bundle, or download the separate base image patch.
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 Oracle Big Data Appliance Configuration Generation Utility. See "Generating the Configuration Files."
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% /
.
.
.
Unzip the downloaded base image ZIP file (2 of 2). For example:
$ unzip p12345678_250_Linux-x86-64_2of2.zip
Archive: p12345678_250_Linux-x86-64_2of2.zip
creating: BDABaseImage-ol6-2.5.0_RELEASE/
inflating: BDABaseImage-ol6-2.5.0_RELEASE/biosconfig
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagecluster
inflating: BDABaseImage-ol6-2.5.0_RELEASE/reimagerack
inflating: BDABaseImage-ol6-2.5.0_RELEASE/makebdaimage
inflating: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.iso
inflating: BDABaseImage-ol6-2.5.0_RELEASE/README.txt
extracting: BDABaseImage-ol6-2.5.0_RELEASE/BDABaseImage-ol6-2.5.0_RELEASE.md5sum
inflating: BDABaseImage-ol6-2.5.0_RELEASE/ubiosconfig
Change to the subdirectory created in the previous step:
$ cd BDABaseImage-ol6-2.5.0_RELEASE
Reimage the cluster:
./reimagecluster
See reimagecluster for the complete syntax of the command.
Run Mammoth. See "Installing the Software on a Single or Primary Rack."
One-off patch bundles provide a fix to specific bugs in one or more releases. You use Mammoth to apply the patch to your cluster.
To install a one-off patch bundle:
Download the patch bundle from the Automated Release Update (ARU) system to a directory such as /tmp on the first node of the Oracle Big Data Appliance cluster.
The file is named BDA-patch-release-patch.zip. The examples in this procedure use the name BDA-patch-2.2.1-123456.zip.
Unzip the file. For example:
# unzip BDA-patch-2.2.1-123456.zip
Archive: BDA-patch-2.2.1-123456.zip
creating: BDA-patch-2.2.1-123456/
inflating: BDA-patch-2.2.1-123456/BDA-patch-2.2.1-123456.run
inflating: BDA-patch-2.2.1-123456/README.txt
Change to the patch directory created in Step 2. For example:
$ cd BDA-patch-2.2.1-123456
Extract the contents of the run file. For example:
$ ./BDA-patch-2.2.1-123456.run
Big Data Appliance one-off patch 123456 for v2.2.1 Self-extraction
Removing existing temporary files
Generating /tmp/BDA-patch-2.2.1-123456.tar
Verifying MD5 sum of /tmp/BDA-patch-2.2.1-123456.tar
/tmp/BDA-patch-2.2.1-123456.tar MD5 checksum matches
Extracting /tmp/BDA-patch-2.2.1-123456.tar to /opt/oracle/BDAMammoth/patches/123456
Removing temporary files
Please "cd /opt/oracle/BDAMammoth" before running "./mammoth -p 123456"
Change to the BDAMammoth directory:
$ cd /opt/oracle/BDAMammoth
Install the patch. For example:
$ ./mammoth -p 123456
You must log in as root on the first server and change to the /opt/oracle/BDAMammoth directory to use Mammoth. 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 10-1 Mammoth 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 runs steps 2 through 6 on the rack being set up:
./mammoth -r 2-6
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 syntax of the mammoth command supports the configuration of new racks and in-rack expansion kits. You can also use the Mammoth bundle to upgrade from earlier releases.
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.
Upgrades the software on the cluster to the current version or installs a one-off patch.
Run steps n through N of the Mammoth 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.
Following are descriptions of the steps that the Mammoth 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 is run as the puppet master node. For example, if you run the Mammoth from bda1node01 with an IP address 192.168.41.1, then a list of aliases for that IP address includes bda1node01-master. The Mammoth 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 also performs a variety of hardware and software checks. A failure in any of these checks causes the Mammoth 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 is being run, waits for the agents to submit their certificates, and automates their signing. This step also changes the root password on all nodes (optional). 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 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.
Mammoth does not copy the source code to Oracle NoSQL Database clusters.
Mammoth does not create logical volumes for Oracle NoSQL Database clusters.
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.
Mammoth does not install MySQL Database on Oracle NoSQL Database clusters.
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.
Mammoth does not install CDH or Cloudera Manager on Oracle NoSQL Database clusters.
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.
Mammoth does not install or start CDH services on Oracle NoSQL Database clusters.
Installs the server-side components of Oracle Big Data Connectors, if this option was selected in Oracle Big Data Appliance Configuration Generation Utility. Oracle Big Data Connectors must be licensed separately. Optional.
Installs Oracle NoSQL Database on clusters allocated to its use. Enterprise Edition requires a separate license.
Configures Kerberos authentication on Oracle Big Data Appliance, if this option was selected. No prerequisites are required if you set up the key distribution center on Oracle Big Data Appliance. Otherwise, see "Installation Prerequisites."
Installs and configures the Oracle Enterprise Manager agents. Optional.
This step does the following:
Creates following named credentials: Switch Credential, Host Credential, Cloudera Manager credential and ILOM credential.
In a cluster expansion, the same credentials are reused.
Updates the Oracle Big Data Appliance and Oracle Exadata Database Machine plug-in agents on the Oracle Big Data Appliance servers to the latest version deployed on the management servers.
Performs discovery of the cluster using the named credentials.
Note:
For this step to run successfully, Oracle Management System must be up and running. See Oracle Enterprise Manager System Monitoring Plug-in Installation Guide for Oracle Big Data Appliance.Installs and configures Auto Service Request (ASR). Optional.
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".
Note:
For this step to run successfully, the ASR host system must be up with ASR Manager running and configured properly. See Chapter 5.Performs the following:
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.
The bdacli command provides an alternative way to call mammoth-reconfig. See "bdacli".
Options
Adds or removes a service from the cluster.
This example adds Auto Service Request support to all servers in the cluster:
# cd /opt/oracle/BDAMammoth # ./mammoth-reconfig add asr
This example removes Oracle Enterprise Manager support from all servers in the cluster:
# cd /opt/oracle/BDAMammoth # ./mammoth-reconfig remove em
Table 10-1 describes the keywords that are valid parameters for add and remove.
Table 10-1 Mammoth Reconfiguration Utility ADD and REMOVE Keywords
| Component Keyword | Description |
|---|---|
|
|
Auto Service Request |
|
|
Oracle Audit Vault and Database Firewall plugin |
|
|
Oracle Big Data Connectors |
|
|
Automatically encrypt and decrypt data on disk and at rest |
|
|
Oracle Enterprise Manager Cloud Control agent |
|
|
Kerberos authentication; manual removal only |
|
|
Automatically encrypt data as it travels over the network |
|
|
Apache Sentry authorization |
Changes the configuration of a service from the cluster. The parameter is a keyword that identifies the service. See Table 10-2.
Table 10-2 Mammoth Reconfiguration Utility UPDATE Keywords
| Component Keyword | Description |
|---|---|
|
|
Changes the password used for password-based encryption. The command prompts for both the old password and the new password. A valid password consists of 1 to 64 printable ASCII characters. It cannot contain whitespace characters (such as spaces, tabs, or carriage returns), single or double quotation marks, or backslashes (\). |
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 internal USB drive contains a full Linux installation.
To use the --usbint option, you must be logged in to the target server; otherwise, you reimage the server using the wrong network information.
The reimaging process does not alter the Oracle ILOMs on the target servers.
One or more 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 used 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.json 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.