This chapter provides information about the software and services installed on Oracle Big Data Appliance. It contains these sections:
An Oracle Enterprise Manager plug-in enables you to use the same system monitoring tool for Oracle Big Data Appliance as you use for Oracle Exadata Database Machine or any other Oracle Database installation. With the plug-in, you can view the status of the installed software components in tabular or graphic presentations, and start and stop these software services. You can also monitor the health of the network and the rack components.
Oracle Enterprise Manager enables you to monitor all Oracle Big Data Appliance racks on the same InfiniBand fabric. It provides summary views of both the rack hardware and the software layout of the logical clusters.
Note:
Before you start, contact Oracle Support for up-to-date information about Enterprise Manager plug-in functionality.After opening Oracle Enterprise Manager web interface, logging in, and selecting a target cluster, you can drill down into these primary areas:
InfiniBand network: Network topology and status for InfiniBand switches and ports. See Figure 2-1.
Hadoop cluster: Software services for HDFS, MapReduce, and ZooKeeper.
Oracle Big Data Appliance rack: Hardware status including server hosts, Oracle Integrated Lights Out Manager (Oracle ILOM) servers, power distribution units (PDUs), and the Ethernet switch.
The following figure shows a small section of the cluster home page.
Figure 2-1 YARN Page in Oracle Enterprise Manager
To monitor Oracle Big Data Appliance using Oracle Enterprise Manager:
Download and install the plug-in. See Oracle Enterprise Manager System Monitoring Plug-in Installation Guide for Oracle Big Data Appliance.
Log in to Oracle Enterprise Manager as a privileged user.
From the Targets menu, choose Big Data Appliance to view the Big Data page. You can see the overall status of the targets already discovered by Oracle Enterprise Manager.
Select a target cluster to view its detail pages.
Expand the target navigation tree to display the components. Information is available at all levels.
Select a component in the tree to display its home page.
To change the display, choose an item from the drop-down menu at the top left of the main display area.
Cloudera Manager is installed on Oracle Big Data Appliance to help you with Cloudera's Distribution including Apache Hadoop (CDH) operations. Cloudera Manager provides a single administrative interface to all Oracle Big Data Appliance servers configured as part of the Hadoop cluster.
Cloudera Manager simplifies the performance of these administrative tasks:
Monitor jobs and services
Start and stop services
Manage security and Kerberos credentials
Monitor user activity
Monitor the health of the system
Monitor performance metrics
Track hardware use (disk, CPU, and RAM)
Cloudera Manager runs on the ResourceManager node (node03) and is available on port 7180.
To use Cloudera Manager:
Open a browser and enter a URL like the following:
In this example, bda1
is the name of the appliance, node03
is the name of the server, example.com
is the domain, and 7180
is the default port number for Cloudera Manager.
Log in with a user name and password for Cloudera Manager. Only a user with administrative privileges can change the settings. Other Cloudera Manager users can view the status of Oracle Big Data Appliance.
See Also:
https://www.cloudera.com/documentation/enterprise/latest/topics/cm_dg_about.html provides information on Cloudera monitoring and diagnostics.
In Cloudera Manager, you can choose any of the following pages from the menu bar across the top of the display:
Home: Provides a graphic overview of activities and links to all services controlled by Cloudera Manager. See the following figure.
Clusters: Accesses the services on multiple clusters.
Hosts: Monitors the health, disk usage, load, physical memory, swap space, and other statistics for all servers in the cluster.
Diagnostics: Accesses events and logs. Cloudera Manager collects historical information about the systems and services. You can search for a particular phrase for a selected server, service, and time period. You can also select the minimum severity level of the logged messages included in the search: TRACE, DEBUG, INFO, WARN, ERROR, or FATAL.
Audits: Displays the audit history log for a selected time range. You can filter the results by user name, service, or other criteria, and download the log as a CSV file.
Charts: Enables you to view metrics from the Cloudera Manager time-series data store in a variety of chart types, such as line and bar.
Backup: Accesses snapshot policies and scheduled replications.
Administration: Provides a variety of administrative options, including Settings, Alerts, Users, and Kerberos.
Rhe following figure shows the Cloudera Manager home page.
As a Cloudera Manager administrator, you can change various properties for monitoring the health and use of Oracle Big Data Appliance, add users, and set up Kerberos security.
To access Cloudera Manager Administration:
Log in to Cloudera Manager with administrative privileges.
Click Administration, and select a task from the menu.
Cloudera Manager provides the interface for managing these services:
HDFS
Hive
Hue
Oozie
YARN
ZooKeeper
You can use Cloudera Manager to change the configuration of these services, stop, and restart them. Additional services are also available, which require configuration before you can use them. See "Unconfigured Software."
Note:
Manual edits to Linux service scripts or Hadoop configuration files do not affect these services. You must manage and configure them using Cloudera Manager.
You also have the option of using the native Hadoop utilities. These utilities are read-only and do not require authentication.
Cloudera Manager provides an easy way to obtain the correct URLs for these utilities. On the YARN service page, expand the Web UI submenu.
You can monitor MapReduce jobs using the resource manager interface.
To monitor MapReduce jobs:
Open a browser and enter a URL like the following:
http://bda1node03.example.com:8088
In this example, bda1
is the name of the rack, node03
is the name of the server where the YARN resource manager runs, and 8088
is the default port number for the user interface.
The following figure shows the resource manager interface.
Figure 2-3 YARN Resource Manager Interface
You can monitor the health of the Hadoop file system by using the DFS health utility on the first two nodes of a cluster.
To monitor HDFS:
Open a browser and enter a URL like the following:
http://bda1node01.example.com:50070
In this example, bda1
is the name of the rack, node01
is the name of the server where the dfshealth utility runs, and 50070
is the default port number for the user interface.
Figure 2-3 shows the DFS health utility interface.
Hue runs in a browser and provides an easy-to-use interface to several applications to support interaction with Hadoop and HDFS. You can use Hue to perform any of the following tasks:
Query Hive data stores
Create, load, and delete Hive tables
Work with HDFS files and directories
Create, submit, and monitor MapReduce jobs
Monitor MapReduce jobs
Create, edit, and submit workflows using the Oozie dashboard
Manage users and groups
Hue is automatically installed and configured on Oracle Big Data Appliance. It runs on port 8888 of the ResourceManager node. See the tables in About the CDH Software Services for Hue’s location within different cluster configurations.
To use Hue:
Log in to Cloudera Manager and click the hue service on the Home page.
On the hue page under Quick Links, click Hue Web UI
.
Bookmark the Hue URL, so that you can open Hue directly in your browser. The following URL is an example:
http://bda1node03.example.com:8888
Log in with your Hue credentials.
If Hue accounts have not been created yet, log into the default Hue administrator account by using the following credentials:
Username: admin
Password: cm-admin-password
where cm-admin-password
is the password specified when the cluster for the Cloudera Manager admin user was activated. You can then create other user and administrator accounts.
The following figure shows the Hive Query Editor.
The following sections identify the software installed on Oracle Big Data Appliance. Some components operate with Oracle Database 11.2.0.2 and later releases.
This section contains the following topics:
These software components are installed on all servers in the cluster. Oracle Linux, required drivers, firmware, and hardware verification utilities are factory installed. All other software is installed on site. The optional software components may not be configured in your installation.
Note:
You do not need to install additional software on Oracle Big Data Appliance. Doing so may result in a loss of warranty and support. See the Oracle Big Data Appliance Owner's Guide.
Base image software:
Oracle Linux 6.9 with Oracle Unbreakable Enterprise Kernel version 4 (UEK4). Oracle Linux 5 Big Data Appliance upgrades stay at 5.11 (UEK2).
Oracle R Distribution 3.2.0
Puppet, firmware, Oracle Big Data Appliance utilities
Oracle InfiniBand software (latest supported firmware is v2.2.6-2)
Mammoth installation:
Cloudera's Distribution including Apache Hadoop Release 5.11.1, including:
Apache Hive
Apache HBase
Apache Spark 2 and Spark 1.6. (Spark 1.6 is deployed as shipped with CDH 5.8.12, but Mammoth also deploys Spark 2 automatically.)
Kudu 1.4.0
Kafka 2.2.0
Key Trustee Server 5.12.1
Note that the Cloudera parcels for Kudu, Kafka, and Key Trustee Server are included for your convenience, but are not deployed or configured by default.
Oracle Big Data SQL 3.2. (optional)
Oracle NoSQL Database Community Edition 4.4.6 or Oracle NoSQL Database Enterprise Edition 4.5.12 (both optional)
Oracle Big Data Connectors 4.9 (optional):
Oracle Perfect Balance 2.10.0
Oracle Big Data Discovery 1.5 and 1.4 (1.4.0.37.1388 or greater).
Note:
Oracle Big Data Discovery lists version 1.4. 0 on the download page of the Oracle Software Delivery Cloud, but this is actually 1.4.0.37.1388 or greater. .If Oracle Big Data Discovery 1.4.0.37.1388 or greater was already enabled prior to an upgrade to the current Oracle Big Data Appliance release, then after the upgrade you must update several client libraries required by Oracle Big Data Discovery. For instructions, see Document 2215083.1 in My Oracle Support (https://support.oracle.com). This manual update is not necessary if you install Oracle Big Data Discovery after installing the current Oracle Big Data Appliance release.
Earlier releases of Oracle Big Data Discovery are not supported on this release of Oracle Big Data Appliance.
See Also:
Oracle Big Data Appliance Owner's Guide for information about the Mammoth utility
The following figure shows the relationships among the major components.
Figure 2-6 Major Software Components of Oracle Big Data Appliance
Firmware
See following documents in My Oracle Support My Oracle Support for current firmware information.
Doc ID 1542871.1 - Firmware Usage and Upgrade Information for BDA Software Managed Components on Oracle Big Data Appliance
Doc ID 1528190.1 - Firmware Upgrade Policy and Factory Ship Versions for Oracle Big Data Appliance Sun Fire X4270 M2, X3-2, X4-2 and X5-2
Your Oracle Big Data Appliance license includes all components in Cloudera Enterprise Data Hub Edition. All CDH components are installed automatically by the Mammoth utility. Do not download them from the Cloudera website.
However, you must use Cloudera Manager to add some services before you can use them, such as the following:
To add a service:
Log in to Cloudera Manager as the admin
user.
On the Home page, expand the cluster menu in the left panel and choose Add a Service to open the Add Service wizard. The first page lists the services you can add.
Follow the steps of the wizard.
See Also:
For a list of key CDH components:
http://www.cloudera.com/content/www/en-us/products/apache-hadoop/key-cdh-components.html
You can allocate resources to each service—HDFS, YARN, Oracle Big Data SQL, Hive, and so forth—as a percentage of the total resource pool. Cloudera Manager automatically calculates the recommended resource management settings based on these percentages. The static service pools isolate services on the cluster, so that a high load on one service as a limited impact on the other services.
To allocate resources among services:
Log in as admin
to Cloudera Manager.
Open the Clusters menu at the top of the page, then select Static Service Pools under Resource Management.
Select Configuration.
Follow the steps of the wizard, or click Change Settings Directly to edit the current settings.
All services are installed on all nodes in a CDH cluster, but individual services run only on designated nodes. There are slight variations in the location of the services depending on the configuration of the cluster.
This section describes the services in a default YARN configuration.
This section contains the following topics:
Oracle Big Data Appliance now enables the use of three-node clusters for development purposes.
Caution:
Three-node clusters are generally not suitable for production environments because all of the nodes are master nodes. This puts constraints on high availability. The minimum recommended cluster size for a production environment is five nodesTable 2-1 Service Locations for a Three-Node Development Cluster
Node1 | Node2 | Node3 |
---|---|---|
NameNode | NameNode/Failover | - |
Failover Controller | Failover Controller | - |
DataNode | DataNode | DataNode |
NodeManager | NodeManager | NodeManager |
JournalNode | JournalNode | JournalNode |
Sentry | HttpFS | Cloudera Manager and CM roles |
- | MySQL Backup | MySQL Primary |
ResourceManager | Hive | ResourceManager |
- | Hive Metastore | JobHistory |
- | ODI | Spark History |
- | Oozie | - |
- | Hue | - |
- | WebHCat | - |
ZooKeeper | ZooKeeper | ZooKeeper |
Active Navigator Key Trustee Server (if HDFS Transparent Encryption is enabled) | Passive Navigator Key Trustee Server (if HDFS Transparent Encryption is enabled) | - |
Kerberos Master KDC (Only if MIT Kerberos is enabled and on-BDA KDCs are being used.) | Kerberos Slave KDC (Only if MIT Kerberos is enabled and on-BDA KDCs are being used.) | - |
The following table identifies the services in CDH clusters configured within a single rack, including starter racks and clusters with five or more nodes. Node01 is the first server in the cluster (server 1, 7, or 10), and nodenn is the last server in the cluster (server 6, 9, 12, or 18). Multirack clusters have different services layouts, as do three-node clusters for development purposes. Both are described separately in this chapter.
Table 2-2 Service Locations for One or More CDH Clusters in a Single Rack
Node01 | Node02 | Node03 | Node04 | Node05 to nn |
---|---|---|---|---|
Balancer |
- |
Cloudera Manager Server |
- |
- |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
Failover Controller |
Failover Controller |
- |
Hive, Hue, Oozie |
- |
JournalNode |
JournalNode |
JournalNode |
- |
- |
- |
MySQL Backup |
MySQL Primary |
- |
- |
NameNode |
NameNode |
Navigator Audit Server and Navigator Metadata Server |
- |
- |
NodeManager (in clusters of eight nodes or less) |
NodeManager (in clusters of eight nodes or less) |
NodeManager |
NodeManager |
NodeManager |
- |
- |
SparkHistoryServer |
Oracle Data Integrator Agent |
- |
- |
- |
ResourceManager |
ResourceManager |
- |
ZooKeeper |
ZooKeeper |
ZooKeeper |
- |
- |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Kerberos KDC (if MIT Kerberos is enabled and on-BDA KDCs are being used) |
Kerberos KDC (if MIT Kerberos is enabled and on-BDA KDCs are being used) |
JobHistory |
- |
- |
Sentry Server (if enabled) |
- |
- |
- |
- |
Active Navigator Key Trustee Server (if HDFS Transparent Encryption is enabled) |
Passive Navigator Key Trustee Server (if HDFS Transparent Encryption is enabled) |
- |
- |
- |
- |
HttpFS |
- |
- |
- |
Note:
If Oozie high availability is enabled, then Oozie servers are hosted on Node04 and another node (preferably a ResourceNode) selected by the customer.When multiple racks are configured as a single CDH cluster, some critical services are installed on the second rack. There can be variations in the distribution of services between the first and second racks in different multirack clusters. The two scenarios that account for these differences are:
The cluster spanned multiple racks in its original configuration.
The resulting service locations across the first and second rack are described in Table 2-3 and Table 2-4. In this case, the JournalNode, Mysql Primary, ResourceManager, and Zookeeper are installed on node 2 of the first rack.
The cluster was single-rack in the original configuration and was extended later.
The resulting service locations across the first and second rack are described in Table 2-5 and Table 2-6. In this case, the JournalNode, Mysql Primary, ResourceManager, and Zookeeper are installed on node 3 of the first rack.
Note:
There is one variant that is determined specifically by cluster size – for clusters of eight nodes less, nodes that run NameNode also run NodeManager. This is not true for clusters larger than eight nodes.
Table 2-3 First Rack Service Locations (When the Cluster Started as Multirack Cluster)
Node01 | Node02 | Node03 | Node04 | Node05 to nn(1) |
---|---|---|---|---|
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
– |
Cloudera Manager Server |
– |
– |
– |
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
Failover Controller |
- |
- |
- |
- |
JournalNode |
JournalNode |
Navigator Audit Server and Navigator Metadata Server |
- |
- |
NameNode |
MySQL Primary |
SparkHistoryServer |
- |
- |
NodeManager (in clusters of eight nodes or less) |
NodeManager |
NodeManager |
NodeManager |
NodeManager |
– |
ResourceManager |
- |
- |
- |
ZooKeeper |
ZooKeeper |
- |
- |
- |
Kerberos KDC (Only if MIT Kerberos is enabled and on-BDA KDCs are being used.) |
Kerberos KDC (Only if MIT Kerberos is enabled and on-BDA KDCs are being used.) |
|||
Sentry Server (Only if Sentry is enabled.) |
||||
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Active Navigator Key Trustee Server (if HDFS Transparent Encryption is enabled) |
Footnote 1 nn includes the servers in additional racks.
Table 2-4 shows the service locations in the second rack of a cluster that was originally configured to span multiple racks.
Table 2-4 Second Rack Service Locations (When the Cluster Started as Multirack Cluster)
Node01 | Node02 | Node03 | Node04 | Node05 to nn |
---|---|---|---|---|
Balancer |
- |
- |
- |
- |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
Failover Controller |
- |
- |
- |
- |
JournalNode |
Hive, Hue, Oozie |
- |
- |
- |
MySQL Backup |
- |
- |
- |
- |
NameNode |
- |
- |
- |
- |
NodeManager (in clusters of eight nodes or less) |
NodeManager |
NodeManager |
NodeManager |
NodeManager |
HttpFS |
Oracle Data Integrator Agent |
- |
- |
- |
- |
ResourceManager |
- |
- |
- |
ZooKeeper |
- |
- |
- |
- |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Passive Navigator Key Trustee Server (if HDFS Transparent Encryption is enabled) |
Table 2-5 shows the service locations in the first rack of a cluster that was originally configured as a single-rack cluster and subsequently extended.
Table 2-5 First Rack Service Locations (When a Single-Rack Cluster is Extended)
Node01 | Node02 | Node03 | Node04 | Node05 to nn(2) |
---|---|---|---|---|
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
- |
- |
Cloudera Manager Server |
- |
- |
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
Failover Controller |
- |
Navigator Audit Server and Navigator Metadata Server |
- |
- |
JournalNode |
- |
JournalNode |
- |
- |
NameNode |
- |
MySQL Primary |
- |
- |
NodeManager (in clusters of eight nodes or less) |
NodeManager |
NodeManager |
NodeManager |
NodeManager |
- |
- |
ResourceManager |
- |
- |
ZooKeeper |
- |
ZooKeeper |
- |
- |
Kerberos KDC (Only if MIT Kerberos is enabled and on-BDA KDCs are being used.) |
Kerberos KDC (Only if MIT Kerberos is enabled and on-BDA KDCs are being used.) |
SparkHistoryServer |
- |
- |
Sentry Server (Only if Sentry is enabled.) |
- |
- |
- |
- |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Active Navigator Key Trustee Server (if HDFS Transparent Encryption is enabled) |
- |
- |
- |
- |
Footnote 2 nn includes the servers in additional racks.
Table 2-6 shows the service locations in the second rack of a cluster originally configured as a single-rack cluster and subsequently extended.
Table 2-6 Second Rack Service Locations (When a Single-Rack Cluster is Extended)
Node01 | Node02 | Node03 | Node04 | Node05 to nn |
---|---|---|---|---|
Balancer |
||||
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
Cloudera Manager Agent |
DataNode |
DataNode |
DataNode |
DataNode |
DataNode |
Failover Controller |
- |
- |
- |
- |
JournalNode |
Hive, Hue, Oozie, Solr |
- |
- |
- |
MySQL Backup |
- |
- |
- |
- |
NameNode |
- |
- |
- |
- |
NodeManager (in clusters of eight nodes or less) |
NodeManager |
NodeManager |
NodeManager |
NodeManager |
HttpFS |
Oracle Data Integrator Agent |
- |
- |
- |
- |
ResourceManager |
- |
- |
- |
ZooKeeper |
- |
- |
- |
- |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Big Data SQL (if enabled) |
Passive Navigator Key Trustee Server (if HDFS Transparent Encryption is enabled) |
Note:
When expanding a cluster from one to two racks, Mammoth moves all critical services from nodes 2 and 4 of the first rack to nodes 1 and 2 of the second rack. Nodes 2 and 4 of the first rack become noncritical nodes.
Yet Another Resource Negotiator (YARN) is the version of MapReduce that runs on Oracle Big Data Appliance, beginning with version 3.0. MapReduce applications developed using MapReduce 1 (MRv1) may require recompilation to run under YARN.
The ResourceManager performs all resource management tasks. An MRAppMaster performs the job management tasks. Each job has its own MRAppMaster. The NodeManager has containers that can run a map task, a reduce task, or an MRAppMaster. The NodeManager can dynamically allocate containers using the available memory. This architecture results in improved scalability and better use of the cluster than MRv1.
YARN also manages resources for Spark and Impala.
See Also:
"Running Existing Applications on Hadoop 2 YARN" at
http://hortonworks.com/blog/running-existing-applications-on-hadoop-2-yarn/
The NameNode is the most critical process because it keeps track of the location of all data. Without a healthy NameNode, the entire cluster fails. Apache Hadoop v0.20.2 and earlier are vulnerable to failure because they have a single name node.
Cloudera's Distribution including Apache Hadoop Version 4 (CDH5) reduces this vulnerability by maintaining redundant NameNodes. The data is replicated during normal operation as follows:
CDH maintains redundant NameNodes on the first two nodes of a cluster. One of the NameNodes is in active mode, and the other NameNode is in hot standby mode. If the active NameNode fails, then the role of active NameNode automatically fails over to the standby NameNode.
The NameNode data is written to a mirrored partition so that the loss of a single disk can be tolerated. This mirroring is done at the factory as part of the operating system installation.
The active NameNode records all changes to the file system metadata in at least two JournalNode processes, which the standby NameNode reads. There are three JournalNodes, which run on the first three nodes of each cluster.
The changes recorded in the journals are periodically consolidated into a single fsimage file in a process called checkpointing.
On Oracle Big Data Appliance, the default log level of the NameNode is DEBUG
, to support the Oracle Audit Vault and Database Firewall plugin. If this option is not configured, then you can reset the log level to INFO
.
Note:
Oracle Big Data Appliance 2.0 and later releases do not support the use of an external NFS filer for backups and do not use NameNode federation.
The following figure shows the relationships among the processes that support automatic failover of the NameNode.
Figure 2-7 Automatic Failover of the NameNode on Oracle Big Data Appliance
The ResourceManager allocates resources for application tasks and application masters across the cluster. Like the NameNode, the ResourceManager is a critical point of failure for the cluster. If all ResourceManagers fail, then all jobs stop running. Oracle Big Data Appliance supports ResourceManager High Availability in Cloudera 5 to reduce this vulnerability.
CDH maintains redundant ResourceManager services on node03 and node04. One of the services is in active mode, and the other service is in hot standby mode. If the active service fails, then the role of active ResourceManager automatically fails over to the standby service. No failover controllers are required.
The following figure shows the relationships among the processes that support automatic failover of the ResourceManager.
Figure 2-8 Automatic Failover of the ResourceManager on Oracle Big Data Appliance
Oracle Big Data Appliance dynamically allocates memory to YARN. The allocation depends upon the total memory on the node and whether the node is one of the four critical nodes.
If you add memory, update the NodeManager container memory by increasing it by 80% of the memory added. Leave the remaining 20% for overhead.
The effects of a server failure vary depending on the server's function within the CDH cluster. Oracle Big Data Appliance servers are more robust than commodity hardware, so you should experience fewer hardware failures. This section highlights the most important services that run on the various servers of the primary rack. For a full list, see "Where Do the Services Run on a Single-Rack CDH Cluster?."
Note:
In a multirack cluster, some critical services run on the first server of the second rack. See "Where Do the Services Run on a Multirack CDH Cluster?."
Each server has 12 disks. Disk partitioning is described in the table below.
The operating system is installed on disks 1 and 2. These two disks are mirrored. They include the Linux operating system, all installed software, NameNode data, and MySQL Database data. The NameNode and MySQL Database data are replicated on the two servers for a total of four copies. As shown in the table, in cases where Disk 1 and 2 are 4 TB drives these include a 3440 GB HDFS data partition. If Disk 1 and 2 are 8 TB, each includes a 7314 GB HDFS data partition.
Drive 3 through 12 each contain a single HDFS or Oracle NoSQL Database data partition
Table 2-7 Oracle Big Data Appliance Server Disk Partioning
Disks 1 and 2 (OS) | Disks 3 – 12 (Data) |
---|---|
8 TB Drives:
Number Start End Size File system Name Flags 1 1049kB 500MB 499MB ext4 primary boot 2 500MB 501GB 500GB primary raid 3 501GB 550GB 50.0GB linux-swap(v1) primary 4 550GB 7864GB 7314GB ext4 primary |
8 TB Drives:
Number Start End Size File system Name Flags 1 1049kB 7864GB 7864GB ext4 primary |
4 TB Drives:
Number Start End Size File system Name Flags 1 1049kB 500MB 499MB ext4 primary boot 2 500MB 501GB 500GB primary raid 3 501GB 560GB 59.5GB linux-swap(v1) primary 4 560GB 4000GB 3440GB ext4 primary |
4 TB Drives:
Number Start End Size File system Name Flags 1 1049kB 4000GB 4000GB ext4 primary |
Critical nodes are required for the cluster to operate normally and provide all services to users. In contrast, the cluster continues to operate with no loss of service when a noncritical node fails.
On single-rack clusters, the critical services are installed initially on the first four nodes of the cluster. The remaining nodes (node05 up to node18) only run noncritical services. If a hardware failure occurs on one of the critical nodes, then the services can be moved to another, noncritical server. For example, if node02 fails, then you might move its critical services node05. Table 2-2 identifies the initial location of services for clusters that are configured on a single rack.
In a multirack cluster, some critical services run on the first server of the second rack. See "Where Do the Services Run on a Single-Rack CDH Cluster?."
Some services have high availability and automatic failover. Other services have a single point of failure. The following list summarizes the critical services:
NameNodes: High availability with automatic failover
ResourceManagers: High availability with automatic failover
MySQL Database: Primary and backup databases are configured with replication of the primary database to the backup database. There is no automatic failover. If the primary database fails, the functionality of the cluster is diminished, but no data is lost.
Cloudera Manager: The Cloudera Manager server runs on one node. If it fails, then Cloudera Manager functionality is unavailable.
Oozie server, Hive server, Hue server, and Oracle Data Integrator agent: These services have no redundancy. If the node fails, then the services are unavailable.
The following table identifies where the critical services run in a CDH cluster. These four nodes are described in more detail in the topics that follow.
Table 2-8 Critical Service Locations on a Single Rack
Node Name | Critical Functions |
---|---|
First NameNode |
Balancer, Failover Controller, JournalNode, NameNode, Puppet Master, ZooKeeper |
Second NameNode |
Failover Controller, JournalNode, MySQL Backup Database, NameNode, ZooKeeper |
First ResourceManager Node |
Cloudera Manager Server, JobHistory, JournalNode, MySQL Primary Database, ResourceManager, ZooKeeper. |
Second ResourceManager Node |
Hive, Hue, Oozie, Solr, Oracle Data Integrator Agent, ResourceManager |
In a single-rack cluster, the four critical nodes are created initially on the first four nodes. See "Where Do the Services Run on a Single-Rack CDH Cluster?"
In a multirack cluster, the Second NameNode and the Second ResourceManager nodes are moved to the first two nodes of the second rack. See "Where Do the Services Run on a Multirack CDH Cluster?".
If the first NameNode fails or goes offline (such as a restart), then the second NameNode automatically takes over to maintain the normal activities of the cluster.
Alternatively, if the second NameNode is already active, it continues without a backup. With only one NameNode, the cluster is vulnerable to failure. The cluster has lost the redundancy needed for automatic failover.
The puppet master also runs on this node. The Mammoth utility uses Puppet, and so you cannot install or reinstall the software if, for example, you must replace a disk drive elsewhere in the rack.
If the second NameNode fails, then the function of the NameNode either fails over to the first NameNode (node01) or continues there without a backup. However, the cluster has lost the redundancy needed for automatic failover if the first NameNode also fails.
The MySQL backup database also runs on this node. MySQL Database continues to run, although there is no backup of the master database.
If the first ResourceManager node fails or goes offline (such as in a restart of the server where the node is running), then the second ResourceManager automatically takes over the distribution of MapReduce tasks to specific nodes across the cluster.
If the second ResourceManager is already active when the first ResourceManager becomes inaccessible, then it continues as ResourceManager, but without a backup. With only one ResourceManager, the cluster is vulnerable because it has lost the redundancy needed for automatic failover.
If the first ResourceManager node fails or goes offline (such as a restart), then the second ResourceManager automatically takes over to distribute MapReduce tasks to specific nodes across the cluster.
Alternatively, if the second ResourceManager is already active, it continues without a backup. With only one ResourceManager, the cluster is vulnerable to failure. The cluster has lost the redundancy needed for automatic failover.
These services are also disrupted:
Cloudera Manager: This tool provides central management for the entire CDH cluster. Without this tool, you can still monitor activities using the utilities described in "Using Hadoop Monitoring Utilities".
MySQL Database: Cloudera Manager, Oracle Data Integrator, Hive, and Oozie use MySQL Database. The data is replicated automatically, but you cannot access it when the master database server is down.
If the second ResourceManager node fails, then the function of the ResourceManager either fails over to the first ResourceManager or continues there without a backup. However, the cluster has lost the redundancy needed for automatic failover if the first ResourceManager also fails.
These services are also disrupted:
Oracle Data Integrator Agent This service supports Oracle Data Integrator, which is one of the Oracle Big Data Connectors. You cannot use Oracle Data Integrator when the ResourceManager node is down.
Hive: Hive provides a SQL-like interface to data that is stored in HDFS. Oracle Big Data SQL and most of the Oracle Big Data Connectors can access Hive tables, which are not available if this node fails.
Hue: This administrative tool is not available when the ResourceManager node is down.
Oozie: This workflow and coordination service runs on the ResourceManager node, and is unavailable when the node is down.
The noncritical nodes are optional in that Oracle Big Data Appliance continues to operate with no loss of service if a failure occurs. The NameNode automatically replicates the lost data to always maintain three copies. MapReduce jobs execute on copies of the data stored elsewhere in the cluster. The only loss is in computational power, because there are fewer servers on which to distribute the work.
If a server starts failing, you must take steps to maintain the services of the cluster with as little interruption as possible. You can manage a failing server easily using the bdacli
utility, as described in the following procedures. One of the management steps is called decommissioning. Decommissioning stops all roles for all services, thereby preventing data loss. Cloudera Manager requires that you decommission a CDH node before retiring it.
When a noncritical node fails, there is no loss of service. However, when a critical node fails in a CDH cluster, services with a single point of failure are unavailable, as described in "Effects of Hardware on Software Availability". You must decide between these alternatives:
Wait for repairs to be made, and endure the loss of service until they are complete.
Move the critical services to another node. This choice may require that some clients are reconfigured with the address of the new node. For example, if the second ResourceManager node (typically node03) fails, then users must redirect their browsers to the new node to access Cloudera Manager.
You must weigh the loss of services against the inconvenience of reconfiguring the clients.
Oracle NoSQL Database clusters do not have critical nodes and because the storage nodes are replicated by a factor of three, the risk of critical failure is minimal. Administrative services are distributed among the nodes in number equal to the replication factor. You can use the Administration CLI and Admin console to administer the cluster from any node that hosts the administrative processes.
If the node hosting Mammoth fails (the first node of the cluster), then follow the procedure for reinstalling it in "Prerequisites for Managing a Failing Node"
To repair or replace any failing Oracle NoSQL node, follow the procedure in "Managing a Failing Noncritical Node".
Ensure that you do the following before managing a failing or failed server, whether it is configured as a CDH node or an Oracle NoSQL Database node:
Try restarting the services or rebooting the server.
Determine whether the failing node is critical or noncritical.
If the failing node is where Mammoth is installed:
For a CDH node, select a noncritical node in the same cluster as the failing node.
For a NoSQL node, repair or replace the failed server first, and use it for these steps.
Upload the Mammoth bundle to that node and unzip it.
Extract all files from BDAMammoth-
version
.run
, using a command like the following:
# ./BDAMammoth-ol6-4.0.0.run
Afterward, you must run all Mammoth operations from this node.
See Oracle Big Data Appliance Owner's Guide for information about the Mammoth utility.
Follow the appropriate procedure in this section for managing a failing node.
Mammoth is installed on the first node of the cluster, unless its services were migrated previously.
Only CDH clusters have critical nodes.
To manage a failing critical node:
Log in as root
to the node where Mammoth is installed.
Migrate the services to a noncritical node. Replace node_name with the name of the failing node, such as bda1node02.
bdacli admin_cluster migrate node_name
When the command finishes, node_name is decommissioned and its services are running on a previously noncritical node.
Announce the change to the user community, so that they can redirect their clients to the new critical node as required.
Repair or replace the failed server.
From the Mammoth node as root
, reprovision the repaired or replaced server as a noncritical node. Use the same name as the migrated node for node_name, such as bda1node02:
bdacli admin_cluster reprovision node_name
If the failed node supported services like HBase or Impala, which Mammoth installs but does not configure, then use Cloudera Manager to reconfigure them on the new node.
Use the following procedure to replace a failing node in either a CDH or a NoSQL cluster.
To manage a failing noncritical node:
Log in as root
to the node where Mammoth is installed (typically node01).
Decommission the failing node. Replace node_name with the name of the failing node.
bdacli admin_cluster decommission node_name
Repair or replace the failed server.
As root
on the Mammoth node, recommission the repaired or replaced server. Use the same name as the decommissioned node for node_name:
bdacli admin_cluster recommission node_name
In the case of a CDH cluster, log into Cloudera Manager, and locate the recommissioned node. Check that HDFS DataNode, YARN NodeManager, and any other roles that should be running are showing a green status light. If they are not, then manually restart them.
See Also:
Oracle Big Data Appliance Owner's Guide for the complete bdacli
syntax
This section describes how to shut down Oracle Big Data Appliance gracefully and restart it.
You must have root
access. Passwordless SSH must be set up on the cluster, so that you can use the dcli
utility.
To ensure that passwordless-ssh is set up:
Log in to the first node of the cluster as root
.
Use a dcli
command to verify it is working. This command should return the IP address and host name of every node in the cluster:
# dcli -C hostname 192.0.2.1: bda1node01.example.com 192.0.2.2: bda1node02.example.com . . .
If you do not get these results, then set up dcli
on the cluster:
# setup-root-ssh -C
See Also:
Oracle Big Data Appliance Owner's Guide for details about these commands.
Follow these procedures to shut down all Oracle Big Data Appliance software and hardware components.
Note:
The following services stop automatically when the system shuts down. You do not need to take any action:
Oracle Enterprise Manager agent
Auto Service Request agents
Use Cloudera Manager to stop the services it manages, including flume
, hbase
, hdfs
, hive
, hue
, mapreduce
, oozie
, and zookeeper
.
Follow this procedure to stop Cloudera Manager Server.
After stopping Cloudera Manager, you cannot access it using the web console.
All nodes share an NFS directory on node03, and additional directories may also exist. If a server with the NFS directory (/opt/exportdir
) is unavailable, then the other servers hang when attempting to shut down. Thus, you must dismount the NFS directories first.
The Linux shutdown -h
command powers down individual servers. You can use the dcli -g
command to stop multiple servers.
To stop the network switches, turn off a PDU or a breaker in the data center. The switches only turn off when power is removed.
The network switches do not have power buttons. They shut down only when power is removed
To stop the switches, turn off all breakers in the two PDUs.
Follow these procedures to power up the hardware and start all services on Oracle Big Data Appliance.
If the servers do not start automatically, then you can start them locally by pressing the power button on the front of the servers, or remotely by using Oracle ILOM. Oracle ILOM has several interfaces, including a command-line interface (CLI) and a web console. Use whichever interface you prefer.
For example, you can log in to the web interface as root
and start the server from the Remote Power Control page. The URL for Oracle ILOM is the same as for the host, except that it typically has a -c
or -ilom
extension. This URL connects to Oracle ILOM for bda1node4:
http://bda1node04-ilom.example.com
Use Cloudera Manager to start all the HDFS services that it controls.
Oracle Big Data SQL is registered with Cloudera Manager as an add-on service. You can use Cloudera Manager to start, stop, and restart the Oracle Big Data SQL service or individual role instances, the same way as a CDH service.
Cloudera Manager also monitors the health of the Oracle Big Data SQL service, reports service outages, and sends alerts if the service is not healthy.
Oracle Big Data SQL is an optional package that can be installed on Oracle Big Data Appliance. You can use Cloudera Manager to determine if Oracle Big Data SQL is installed, but cannot use it to add or remove the service from a CDH cluster on Oracle Big Data Appliance.
A version of this software is included in the Mammoth bundle for each Oracle Big Data Appliance release. The bundled version can be installed with the other client software during the initial software installation or an upgrade. A more recent version of Oracle Big Data SQL than the one included with Oracle Big Data Appliance may be available. The Preface of the Oracle Big Data Appliance Owner’s Guide identifies the changes in each release, including which version of Oracle Big Data SQL is bundled with the release. See the Oracle Big Data SQL Master Compatibility Matrix (Doc ID 2119369.1) in My Oracle Support for up-to-date information on other versions of Oracle Big Data SQL that are compatible with your current release of Oracle Big Data Appliance.
To install the version of Oracle Big Data SQL that is included with Oracle Big Data Appliance, log in to the server where Mammoth is installed (usually the first node of the cluster). use the following commands in the bdacli
utility:
To enable Oracle Big Data SQL
bdacli enable big_data_sql
To disable Oracle Big Data SQL:
bdacli disable big_data_sql
To add or remove other versions of Oracle Big Data SQL, see the installation guide for that release.
A separate license is required for Oracle Big Data SQL. The license is not included with the Oracle Big Data Appliance license agreement.
For Oracle Big Data SQL, you can use the either the client Ethernet network or the InfiniBand network to connect Oracle Big Data Appliance and Oracle Database.
Note:
Ethernet networking for Oracle Big Data SQL between Oracle SPARC SuperCluster and Oracle Big Data Appliance is not supported at this time.There are three points at which you can specify either Ethernet and InfiniBand networking for Oracle Big Data SQL:
When using the Oracle Big Data Appliance Configuration Utility to prepare for the Mammoth installation.
After running Mammoth but prior to the deployment of the Oracle Database side of the Oracle Big Data SQL installation.
After Oracle Big Data SQL is fully deployed.
It is best to decide on the appropriate network at the earliest stage – when using the Configuration Utility.
Choosing InfiniBand or Ethernet in the Oracle Big Data Appliance Configuration Utility
Is Big Data SQL using InfiniBand?
If you bypass the question, then by default the InfiniBand network is used. InfiniBand is also used if you Respond Yes
. Respond No
in order to choose an Ethernet connection.
Switching to Ethernet Before Deploying Oracle Big Data SQL to Oracle Database Servers
After running the Mammoth installation, but before creating and deploying the Oracle Big Data SQL database-side installation bundle, you can use the following steps to reset to an Ethernet or InfiniBand connection.
If you had chosen to include Oracle Big Data SQL in the Mammoth installation, then as root
, disable Oracle Big Data SQL when Mammoth is done.
# bdacli disable big_data_sql
On the node where Configuration Manager is running, make a backup of the file /opt/oracle/bda/install/state/config.json
and then as root
, open the original file for editing.
BDS_IB_CONNECTION
. The possible values of this parameter are:
FALSE
– the IP adddress and mask of the Ethernet-based Client network is used.
TRUE
– the IP address and mask of the InfiniBand network is used.
By default, if the value is not specified, then the InfiniBand network is used.
To choose an Ethernet connection for Oracle Big Data SQL, set BDS_IB_CONNECTION
to FALSE
and save the file.
Re-enable Oracle Big Data SQL.
# bdacli enable big_data_sql
Generate and deploy the database-side installation bundle as described in Oracle Big Data SQL Installation Guide. The installer included the bundle will configure the InfiniBand connection on the database side (if that is the network that was selected in the previous steps). As mentioned in the installation guide, you must deploy the bundle to each database node.
Switching Between InfiniBand and Ethernet After Oracle Big Data SQL has been Deployed to the Oracle Database Servers
Switching networks after Oracle Big Data SQL has been fully deployed requires a reconfiguration of the installation on all nodes on the Oracle Database side. You must rebuild and re-deploy the database-side installation bundle.
As described in the first 4 steps above, disable Oracle Big Data SQL and on the node that runs Configuration Manager, edit config.json
. Set BDS_IB_CONNECTION
to use the desired network and then re-enable Oracle Big Data SQL.
In this case, before generating and deploying the database bundle, CD to the BDSSetup directory installed by Oracle Big Data SQL and run the following commands, which will build a reconfigured database-side installation bundle.
[root@myclustermgmtserver: BDSSetup] # ./setup-bds reconfigure bds-config.json [root@myclustermgmtserver: BDSSetup] # ./cd db [root@myclustermgmtserver: db] # ./bds-database-create-bundle.sh --reconfigure
Deploy and install this new bundle on all database nodes.
See Also:
The Oracle Big Data SQL Installation Guide provides complete information on installing and configuring Oracle Big Data SQL.You can modify the property values in a Linux kernel Control Group (Cgroup) to reserve resources for Oracle Big Data SQL.
To modify the resource management configuration settings:
Log in as admin
to Cloudera Manager.
On the Home page, click bigdatasql from the list of services.
On the bigdatasql page, click Configuration.
Under Category, expand BDS Server Default Group and click Resource Management.
Modify the values of the following properties as required:
Cgroup CPU Shares
Cgroup I/O Weight
Cgroup Memory Soft Limit
Cgroup Memory Hard Limit
See the Description column on the page for guidelines.
Click Save Changes.
From the Actions menu, click Restart.
The following figure shows the bigdatasql service configuration page.
Figure 2-10 Modifying the Cgroup Settings for Oracle Big Data SQL
See Also:
You can take precautions to prevent unauthorized use of the software and data on Oracle Big Data Appliance.
Every open-source package installed on Oracle Big Data Appliance creates one or more users and groups. Most of these users do not have login privileges, shells, or home directories. They are used by daemons and are not intended as an interface for individual users. For example, Hadoop operates as the hdfs
user, MapReduce operates as mapred
, and Hive operates as hive
.
You can use the oracle
identity to run Hadoop and Hive jobs immediately after the Oracle Big Data Appliance software is installed. This user account has login privileges, a shell, and a home directory.
Oracle NoSQL Database and Oracle Data Integrator run as the oracle
user. Its primary group is oinstall
.
Note:
Do not delete, re-create, or modify the users that are created during installation, because they are required for the software to operate.
The following table identifies the operating system users and groups that are created automatically during installation of Oracle Big Data Appliance software for use by CDH components and other software packages.
Table 2-9 Operating System Users and Groups
User Name | Group | Used By | Login Rights |
---|---|---|---|
|
|
Apache Flume parent and nodes |
No |
|
|
Apache HBase processes |
No |
|
|
No |
|
|
|
No |
|
|
|
Hue processes |
No |
|
|
ResourceManager, NodeManager, Hive Thrift daemon |
Yes |
|
|
Yes |
|
|
|
Oozie server |
No |
|
|
Oracle NoSQL Database, Oracle Loader for Hadoop, Oracle Data Integrator, and the Oracle DBA |
Yes |
|
|
Puppet parent (puppet nodes run as |
No |
|
|
Apache Sqoop metastore |
No |
|
Auto Service Request |
No |
|
|
|
ZooKeeper processes |
No |
Oracle Big Data Appliance supports Kerberos security as a software installation option. See Supporting User Access to Oracle Big Data Appliance for details about setting up clients and users to access a Kerberos-protected cluster.
The typical authorization model on Hadoop is at the HDFS file level, such that users either have access to all of the data in the file or none. In contrast, Apache Sentry integrates with the Hive and Impala SQL-query engines to provide fine-grained authorization to data and metadata stored in Hadoop.
Oracle Big Data Appliance automatically configures Sentry during software installation, beginning with Mammoth utility version 2.5.
See Also:
Cloudera Manager Help
Managing Clusters with Cloudera Manager at
HDFS Transparent Encryption protects Hadoop data that is at rest on disk. After HDFS Transparent Encryption is enabled for a cluster on Oracle Big Data Appliance, data writes and reads to encrypted zones (HDFS directories) on the disk are automatically encrypted and decrypted. This process is “transparent” because it is invisible to the application working with the data.
HDFS Transparent Encryption does not affect user access to Hadoop data, although it can have a minor impact on performance.
HDFS Transparent Encryption is an option that you can select during the initial installation of the software by the Mammoth utility. You can also enable or disable HDFS Transparent Encryption at any time by using the bdacli
utility. Note that HDFS Transparent Encryption can be installed only on a Kerberos-secured cluster.
Oracle recommends that you set up the Navigator Key Trustee (the service that manages keys and certificates) on a separate server, external to the Oracle Big Data Appliance.
See the following MOS documents at My Oracle Support for instructions on installing and enabling HDFS Transparent Encryption.
Title | MOS Doc ID |
---|---|
How to Setup Highly Available Active and Passive Key Trustee Servers on BDA V4.4 Using 5.5 Parcels | 2112644.1
Installing using parcels as described in this MOS document is recommended over package-based installation. See Cloudera’s comments on Parcels. |
How to Enable/Disable HDFS Transparent Encryption on Oracle Big Data Appliance V4.4 with bdacli | 2111343.1 |
How to Create Encryption Zones on HDFS on Oracle Big Data Appliance V4.4 | 2111829.1 |
Note:
If either HDFS Transparent Encryption or Kerberos is disabled, data stored in the HDFS Transparent Encryption zones in the cluster will remain encrypted and therefore inaccessible. To restore access to the data, re-enable HDFS Transparent Encryption using the same key provider.
See Also:
Cloudera documentation about HDFS at-rest encryption at http://www.cloudera.com for more information about managing files in encrypted zones.
HTTPS Network/Encryption on the Big Data Appliance has two components :
Web Interface Encryption
Configures HTTPS for the following web interfaces: Cloudera Manager, Oozie, and HUE. This encryption is now enabled automatically in new Mammoth installations. For current installations it can be enabled via the bdacli utility. This feature does not require that Kerberos is enabled.
Encryption for Data in Transit and Services
Encrypt Hadoop Services
This includes SSL encryption for HDFS, MapReduce, and YARN web interfaces, as well as encrypted shuffle for MapReduce and YARN. It also enable authentication for access to the web consoles for the MapReduce, and YARN roles.
Encrypt HDFS Data Transport
This option will enable encryption of data transferred between DataNodes and clients, and among DataNodes.
HTTPS/Network Encryption is enabled and disabled on a per cluster basis. The Configuration Utility described in the Oracle Big Data Appliance Owner’s Guide, includes settings for enabling encryption for Hadoop Services and HDFS Data Transport when a cluster is created. The bdacli utility reference pages (also in the Oracle Big Data Appliance Owner’s Guide ) provide HTTPS/Network Encryption command line options.
See Also:
Supporting User Access to Oracle Big Data Appliance for an overview of how Kerberos is used to secure CDH clusters.
About HDFS Transparent Encryption for information about Oracle Big Data Appliance security for Hadoop data at-rest.
Cloudera documentation at http://www.cloudera.com for more information about HTTPS communication in Cloudera Manager and network-level encryption in CDH.
If web interface encryption is enabled, each web browser accessing an HDFS, MapReduce, or YARN-encrypted web interface must be configured to authenticate with Kerberos. Note that this is not necessary for the Cloudera Manager, Oozie, and Hue web interfaces, which do not require Kerberos.
The following are the steps to configure Mozilla FirefoxFoot 3, Microsoft Internet ExplorerFoot 4, and Google ChromeFoot 5 for Kerberos authentication.
To configure Mozilla Firefox:
Enter about:config
in the Location Bar.
In the Search box on the about:config page, enter: network.negotiate-auth.trusted-uris
Under Preference Name, double-click the network.negotiate-auth.trusted-uris
.
In the Enter string value dialog, enter the hostname or the domain name of the web server that is protected by Kerberos. Separate multiple domains and hostnames with a comma.
To configure Microsoft Internet Explorer:
Configure the Local Intranet Domain:
Open Microsoft Internet Explorer and click the Settings "gear" icon in the top-right corner. Select Internet options
.
Select the Security tab.
Select the Local intranet zone and click Sites.
Make sure that the first two options, Include all local (intranet) sites not listed in other zones
and Include all sites that bypass the proxy server
are checked.
Click Advanced on the Local intranet
dialog box and, one at a time, add the names of the Kerberos-protected domains to the list of websites.
Click Close.
Click OK to save your configuration changes, then click OK again to exit the Internet Options panel.
Configure Intranet Authentication for Microsoft Internet Explorer:
Click the Settings "gear" icon in the top-right corner. Select Internet Options
.
Select the Security tab.
Select the Local Intranet zone and click the Custom level... button to open the Security Settings - Local Intranet Zone dialog box.
Scroll down to the User Authentication options and select Automatic logon only in Intranet zone
.
Click OK to save your changes.
To configure Google Chrome:
If you are using Microsoft Windows, use the Control Panel to navigate to the Internet Options dialogue box. Configuration changes required are the same as those described above for Microsoft Internet Explorer.
OnFoot 6 or on Linux, add the --auth-server-whitelist
parameter to the google-chrome
command. For example, to run Chrome from a Linux prompt, run the google-chrome command as follows
google-chrome --auth-server-whitelist = "hostname/domain"
Note:
On Microsoft Windows, the Windows user must be an user in the Kerberos realm and must possess a valid ticket. If these requirements are not met, an HTTP 403 is returned to the browser upon attempt to access a Kerberos-secured web interface.The following table identifies the port numbers that might be used in addition to those used by CDH.
To view the ports used on a particular server:
In Cloudera Manager, click the Hosts tab at the top of the page to display the Hosts page.
In the Name column, click a server link to see its detail page.
Scroll down to the Ports section.
See Also:
For the full list of CDH port numbers, go to the Cloudera website at
https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_ig_ports_cdh5.html
Table 2-10 Oracle Big Data Appliance Port Numbers
Service | Port |
---|---|
30920 |
|
3306 |
|
20910 |
|
Oracle NoSQL Database administration |
5001 |
5010 to 5020 |
|
Oracle NoSQL Database registration |
5000 |
111 |
|
8140 |
|
Puppet node service |
8139 |
668 |
|
22 |
|
6481 |
The puppet node service (puppetd
) runs continuously as root
on all servers. It listens on port 8139 for "kick" requests, which trigger it to request updates from the puppet master. It does not receive updates on this port.
The puppet master service (puppetmasterd
) runs continuously as the puppet user on the first server of the primary Oracle Big Data Appliance rack. It listens on port 8140 for requests to push updates to puppet nodes.
The puppet nodes generate and send certificates to the puppet master to register initially during installation of the software. For updates to the software, the puppet master signals ("kicks") the puppet nodes, which then request all configuration changes from the puppet master node that they are registered with.
The puppet master sends updates only to puppet nodes that have known, valid certificates. Puppet nodes only accept updates from the puppet master host name they initially registered with. Because Oracle Big Data Appliance uses an internal network for communication within the rack, the puppet master host name resolves using /etc/hosts
to an internal, private IP address.
Notice:
Audit Vault and Database Firewall is no longer supported for use with Oracle Big Data Appliance. It is recommended that customers use Cloudera Navigator for monitoring.If you need help from Oracle Support to troubleshoot CDH issues, then you should first collect diagnostic information using the bdadiag
utility with the cm
option.
To collect diagnostic information:
Log in to an Oracle Big Data Appliance server as root
.
Run bdadiag
with at least the cm
option. You can include additional options on the command line as appropriate. See the Oracle Big Data Appliance Owner's Guide for a complete description of the bdadiag
syntax.
# bdadiag cm
The command output identifies the name and the location of the diagnostic file.
Go to My Oracle Support at http://support.oracle.com
.
Open a Service Request (SR) if you have not already done so.
Upload the bz2
file into the SR. If the file is too large, then upload it to sftp.oracle.com
, as described in the next procedure.
To upload the diagnostics to ftp.oracle.com:
Open an SFTP client and connect to sftp.oracle.com
. Specify port 2021 and remote directory /support/incoming/
target
, where target
is the folder name given to you by Oracle Support.
Log in with your Oracle Single Sign-on account and password.
Upload the diagnostic file to the new directory.
Update the SR with the full path and the file name.
Footnote Legend
Footnote 3: Mozilla Firefox is a registered trademark of the Mozilla Foundation.