Cloudera Manager Administration Guide

Transcription

1 Cloudera Manager Administration Guide

2 Important Notice (c) Cloudera, Inc. All rights reserved. Cloudera, the Cloudera logo, Cloudera Impala, and any other product or service names or slogans contained in this document are trademarks of Cloudera and its suppliers or licensors, and may not be copied, imitated or used, in whole or in part, without the prior written permission of Cloudera or the applicable trademark holder. Hadoop and the Hadoop elephant logo are trademarks of the Apache Software Foundation. All other trademarks, registered trademarks, product names and company names or logos mentioned in this document are the property of their respective owners. Reference to any products, services, processes or other information, by trade name, trademark, manufacturer, supplier or otherwise does not constitute or imply endorsement, sponsorship or recommendation thereof by us. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Cloudera. Cloudera may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Cloudera, the furnishing of this document does not give you any license to these patents, trademarks copyrights, or other intellectual property. For information about patents covering Cloudera products, see The information in this document is subject to change without notice. Cloudera shall not be liable for any damages resulting from technical errors or omissions which may be present in this document, or from use of this document. Cloudera, Inc Page Mill Road Bldg 2 Palo Alto, CA info@cloudera.com US: Intl: Release Information Version: 5.0.x Date: September 8, 2015

3 Table of Contents About this Guide...7 Managing the Cloudera Manager Server and Agents...9 Starting, Stopping, and Restarting the Cloudera Manager Server...9 Configuring Cloudera Manager Server Ports...9 Moving the Cloudera Manager Server to a New Host...9 Starting, Stopping, and Restarting Cloudera Manager Agents...10 Configuring Cloudera Manager Agents...11 Viewing Cloudera Manager Server and Agent Logs...13 Changing Hostnames...14 Backing up Databases...16 Backing Up PostgreSQL Databases...16 Backing Up MySQL Databases...17 Backing Up Oracle Databases...17 Cloudera Management Service...19 Managing Users and Authentication...23 Cloudera Manager User Accounts...23 Changing the Local Logged-In User Password...23 Adding a Local User Account...23 Changing a User Account Role and Password...24 Deleting Local User Accounts...24 Configuring External Authentication...24 Configuring Authentication Using Active Directory...25 Configuring Authentication Using an OpenLDAP-compatible Server...25 Configuring Authentication Using an External Program...26 Configuring Authentication Using SAML...27 Preparing Files...27 Configuring Cloudera Manager...28 Configuring the IDP...29 Verifying Authentication and Authorization...29 Configuring TLS Security for Cloudera Manager...31

4 Configuring TLS Encryption only for Cloudera Manager...31 Step 1: Create a Cloudera Manager Server certificate Step 2: Enable TLS encryption and specify Server keystore properties...32 Step 3: Enable and configure TLS on the Agent hosts...32 Step 4: Restart the Cloudera Manager Server...32 Step 5: Restart the Cloudera Manager Agents...32 Step 6: Verify that the Server and Agents are communicating...33 Configuring TLS Authentication of Server to Agents...33 Step 1: Configure TLS encryption...33 Step 2: Provide the Server's server certificate and CA certificate...33 Step 3: Copy the Server's server.pem file to the Agents...35 Step 4: Enable TLS Encryption in Cloudera Manager...36 Step 5: Restart the Cloudera Manager Server...36 Step 6: Restart the Cloudera Manager Agents...36 Step 7: Verify that the Server and Agents are communicating...36 Configuring TLS Authentication of Agents to Server...36 Step 1: Configure TLS encryption...36 Step 2: Configure TLS Authentication of Server to Agents...36 Step 3. Generate the private key for the Agent using openssl...37 Step 4: Generate a certificate for the agent...37 Step 5: Create a file that contains the password for the key...37 Step 6: Configure the Agent with its private key and certificate...37 Step 7: Import the Agent's certificate into the Server's truststore...37 Step 8: Repeat steps 3 through 7 for every agent in your cluster...37 Step 9: Enable Agent authentication and configure the Server to use the new truststore...37 Step 10: Restart the Server...38 Step 11: Restart the Cloudera Manager Agents...38 Step 12: Verify that the Server and Agents are communicating...38 Configuring TLS Encryption for Cloudera Manager Admin Console...38 Step 1: Create a Cloudera Manager Server certificate Step 2: Enable TLS encryption and specify Server keystore properties...39 Step 3: Restart the Cloudera Manager Server...39 Step 4: Restart the Cloudera Management Services...39 Step 5: Verify that the Server and browser are using TLS to communicate...39 Upgrading Cloudera Manager...41 Database Considerations for Cloudera Manager Upgrades...42 Back up Databases...42 Modify Databases to Support UTF Modify Databases to Support Appropriate Maximum Connections...43 Next Steps...44 Upgrading Cloudera Manager 5 to the Latest Cloudera Manager...44 Review Warning...44

5 Perform Prerequisite Steps...44 Stop Selected Services...44 Stop Cloudera Manager Server, Database, and Agent...45 (Optional) Upgrade JDK on Cloudera Manager Server Host and Agent Hosts...45 Upgrade Cloudera Manager Server Packages...45 Start the Cloudera Manager Server...47 Upgrade Cloudera Manager Agent Packages...48 Verify the Upgrade Succeeded...50 Start Selected Services...50 Deploy Updated Client Configurations...50 Test the Installation...50 (Optional) Upgrade CDH...50 Upgrading Cloudera Manager 4 to Cloudera Manager Review Warnings and Notes...51 Perform Prerequisite Steps...52 Stop Selected Services...53 Stop Cloudera Manager Server, Database, and Agent...53 (Optional) Upgrade JDK on Cloudera Manager Server Host and Agent Hosts...54 Upgrade Cloudera Manager Server Packages...54 Start the Cloudera Manager Server...56 Upgrade Cloudera Manager Agent Packages...56 Verify the Upgrade Succeeded...59 Add Hive Gateway Roles...59 Configure Cluster Version for Package Installs...60 Upgrade Impala...60 (Optional) Hard Restart Cloudera Manager Agents...60 (Optional) Restart All Services...60 Restart Roles of Audited Services...60 Start Selected Services...61 Deploy Updated Client Configurations...61 Test the Installation...61 (Optional) Upgrade CDH...61 Upgrading Cloudera Manager 3.7.x...61 Re-Running the Cloudera Manager Upgrade Wizard...61 Reverting a Failed Cloudera Manager Upgrade...62 Reinstall the Cloudera Manager Server Packages...62 Start the Server...64 Other Cloudera Manager Settings...65 Administration Settings...65 User Interface Language Settings...66 Managing Licenses...66 Managing Alerts...69

6 Configuring Alert Delivery...69 Configuring Alert SNMP Delivery...70 Kerberos...71 Sending Usage and Diagnostic Data to Cloudera...72 Managing Anonymous Usage Data Collection...72 Managing Hue Analytics Data Collection...72 Diagnostic Data Collection...72 Importing Cloudera Manager Settings...75 Backing up your Current Deployment...75 Building a Cloudera Manager Deployment...75 Uploading a Cloudera Manager 4.x Configuration Script...75

7 About this Guide About this Guide This guide is for system administrators who need to manage a Cloudera Manager server installation. This guide covers managing the Cloudera Manager Server and Agents, managing the Cloudera Management Service, adding and managing Cloudera Manager users, configuring TLS security, upgrading Cloudera Manager, adding or upgrading licenses, configuring the Alert Publisher, and other similar features. Cloudera Manager Administration Guide 7

8

9 Managing the Cloudera Manager Server and Agents Managing the Cloudera Manager Server and Agents This section covers information on managing the Cloudera Manager Server and Agents that run on each host of the cluster. Starting, Stopping, and Restarting the Cloudera Manager Server To start the Cloudera Manager Server: $ sudo service cloudera-scm-server start You can stop (for example, to perform maintenance on its host) or restart the Cloudera Manager Server without affecting the other services running on your cluster. Statistics data used by activity monitoring and service monitoring will continue to be collected during the time the server is down. To stop the Cloudera Manager Server: $ sudo service cloudera-scm-server stop To restart the Cloudera Manager Server: $ sudo service cloudera-scm-server restart Configuring Cloudera Manager Server Ports 1. From the Administration tab, select Settings. 2. Under the Ports and Addresses category, set the following options as described below: Setting HTTP Port for Admin Console HTTPS Port for Admin Console Agent Port to connect to Server Description Specify the HTTP port to use to access the Server via the Admin Console. Specify the HTTPS port to use to access the Server via the Admin Console. Specify the port for Agents to use to connect to the Server. 3. Click Save Changes. 4. Restart the Cloudera Manager Server. Moving the Cloudera Manager Server to a New Host You can move the Cloudera Manager Server if the database information is still available for either of the following reasons: The database server is still available. A current back up of the Cloudera Manager database is available. To move Cloudera Manager Server: Cloudera Manager Administration Guide 9

10 Managing the Cloudera Manager Server and Agents 1. Record the old host's name hostname and IP address. It is not absolutely necessary to have the old Cloudera Manager server hostname and IP address, but it simplifies the process. You could use a new hostname and IP address, but this would require updating the configuration of every Agent to use this new information. Because it is easier to use the old server hostname and address in most cases, using a new hostname and IP address is not described. 2. Identify a new host on which to install Cloudera Manager. Assign the failed Cloudera Manager Server's hostname and IP address to the new host. Note: If the Agents were configured with the server's hostname, you do not need to assign the old host's IP address to the new host. Simply assigning the hostname will suffice. 3. Install Cloudera Manager on a new host, using the method described under Install the Cloudera Manager Server Packages. Do not install the other components, such as CDH and databases. 4. If the database server is not available, a. Install the database packages on the host that will host the restored database. This could be the same host on which you have just installed Cloudera Manager or it could be a different host. The details of which package to install varies based on which database was initially installed on your system. If you used the embedded PostgreSQL database, install the PostgreSQL package as described in Embedded PostgreSQL Database. If you used an external MySQL, PostgreSQL, or Oracle database, reinstall that following the instructions in Cloudera Manager and Managed Service Databases. b. Restore the backed up databases to the new database installations. 5. Update /etc/cloudera-scm-server/db.properties with the necessary information so that the Cloudera Manager Server connects to the restored database. This information is typically the database name, database instance name, user name, and password. 6. Start the Cloudera Manager Server. At this point, Cloudera Manager should resume functioning as it did before the failure. Because you restored the database from the backup, the server should accept the running state of the Agents, meaning it will not terminate any running processes. The process is similar with secure clusters, though files in /etc/cloudera-scm-server must be restored in addition to the database. Starting, Stopping, and Restarting Cloudera Manager Agents To start stopped Agents, the supervisord process, and all processes managed by the supervisord process, use one of the following commands: Start $ sudo service cloudera-scm-agent start Clean Start $ sudo service cloudera-scm-agent clean_start The directory /var/run/cloudera-scm-agent is completely cleaned out; all files and subdirectories are removed and then the start command is executed. /var/run/cloudera-scm-agent contains on-disk running Agent state. Some Agent state is left behind in /var/lib/cloudera-scm-agent, but you shouldn't delete that. For further information, see Server and Client Configuration and Process Management. To stop or restart Agents while leaving the processes they manage running, use one of the following commands: Stop $ sudo service cloudera-scm-agent stop 10 Cloudera Manager Administration Guide

11 Managing the Cloudera Manager Server and Agents Restart $ sudo service cloudera-scm-agent restart To stop or restart Agents, the supervisord process, and all processes managed by the supervisord process, use one of the following commands: Hard Stop $ sudo service cloudera-scm-agent hard_stop Hard Restart $ sudo service cloudera-scm-agent hard_restart Hard restart is useful for the following situations: 1. You're upgrading Cloudera Manager and the supervisord code has changed between your current version and the new one. To properly do this upgrade you'll need to restart supervisor too. 2. supervisord is hung and needs to be restarted. 3. You want to clear out all running state pertaining to Cloudera Manager and managed services. Clean Restart $ sudo service cloudera-scm-agent clean_restart Runs hard_stop followed by clean_start. Warning: Running hard_stop, clean_restart, or hard_restart kills all running managed services on the host(s) where the command is run. To check the status of the Agent process, use the command: $ sudo service cloudera-scm-agent status Configuring Cloudera Manager Agents Cloudera Manager Agents can be configured globally using properties you set in the Cloudera Manager Admin Console and by setting properties in individual Agent configuration files. Configuring Agent Heartbeat and Health Status Options You can configure the Cloudera Manager Agent heartbeat interval and timeouts to trigger changes in Agent health as follows: 1. Select Administration > Settings. 2. Under the Performance category, set the following option: Property Send Agent Heartbeat Every Description The interval in seconds between each heartbeat that is sent from Cloudera Manager Agents to the Cloudera Manager Server. Default: 15 sec. 3. Under the Monitoring category, set the following options: Cloudera Manager Administration Guide 11

12 Managing the Cloudera Manager Server and Agents Property Set health status to Concerning if the Agent heartbeats fail Set health status to Bad if the Agent heartbeats fail Description The number of missed consecutive heartbeats after which a Concerning health status is assigned to that Agent. Default: 5. The number of missed consecutive heartbeats after which a Bad health status is assigned to that Agent. Default: Click Save Changes. Configuring the Host Parcel Directory To configure the location of distributed parcels: 1. Click Hosts in the top navigation bar. 2. Select Configuration > View and Edit. 3. Configure the value of the Parcel Directory property. The setting of the parcel_dir property in the Cloudera Manager Agent configuration file overrides this setting. 4. Click Save Changes. Agent Configuration File The Cloudera Manager Agent supports different types of configuration options in the /etc/cloudera-scm-agent/config.ini file. You must update the configuration on each host. Property server_host, server_port, listening_port, listening_hostname, listening_ip log_file Description Hostname and ports of the Cloudera Manager Server and Agent and IP address of the Agent. Also see Configuring Cloudera Manager Server Ports on page 9 and Ports Used by Cloudera Manager. The Cloudera Manager Agent configures its hostname automatically. However, if your cluster hosts are multi-homed (that is, they have more than one hostname), and you want to specify which hostname the Cloudera Manager Agent uses, you can update the listening_hostname property. If you want to specify which IP address the Cloudera Manager Agent uses, you can update the listening_ip property in the same file. To have a CNAME used throughout instead of the regular hostname, an Agent can be configured to use listening_hostname=cname. In this case, the CNAME should resolve to the same IP address as the IP address of the hostname on that machine. Users doing this will find that the host inspector will report problems, but the CNAME will be used in all configurations where that's appropriate. This practice is particularly useful for users who would like clients to use namenode.mycluster.company.com instead of machine1234.mycluster.company.com. In this case, namenode.mycluster would be a CNAME for machine1234.mycluster, and the generated client configurations (and internal configurations as well) would use the CNAME. The path to the Agent log file. If the Agent is being started via the init.d script, /var/log/cloudera-scm-agent/cloudera-scm-agent.out will also have a small amount of output (from before logging is initialized). Default: /var/log/cloudera-scm-agent/cloudera-scm-agent.log. 12 Cloudera Manager Administration Guide

13 Managing the Cloudera Manager Server and Agents Property lib_dir parcel_dir max_collection_wait_seconds metrics_url_timeout_seconds task_metrics_timeout_seconds use_tls,verify_cert_file, client_key_file, client_keypw_file, client_cert_file mgmt_home Description Directory to store Cloudera Manager Agent state that persists across instances of the agent process and system reboots. The agent's UUID is stored here. Default: /var/lib/cloudera-scm-agent. Directory to store unpacked parcels. Default: /opt/cloudera/parcels. Maximum time to wait for all metric collectors to finish collecting data. Default: 10 sec. Maximum time to wait when connecting to a local role's web server to fetch metrics. Default: 30 sec. Maximum time to wait when connecting to a local TaskTracker to fetch task attempt data. Default: 5 sec. Security-related configuration. See Configuring TLS Authentication of Agents to Server on page 36 Configuring TLS Authentication of Server to Agents on page 33 Specifying the Cloudera Manager Server Certificate Adding a Host to the Cluster Directory to store Cloudera Management Service files. Default: /usr/share/cmf. cloudera_mysql_connector_jar, cloudera_oracle_connector_jar, cloudera_postgresql_jdbc_jar Location of JDBC drivers. See Cloudera Manager and Managed Service Databases. Default: MySQL - /usr/share/java/mysql-connector-java.jar Oracle - /usr/share/java/oracle-connector-java.jar PostgreSQL - /usr/share/cmf/lib/postgresql-version-build.jdbc4.jar Viewing Cloudera Manager Server and Agent Logs To help you troubleshoot problems, you can view the Cloudera Manager Server and Agent logs. You can view these logs in the Logs page or in specific pages for the logs. Viewing Cloudera Manager Server and Agent Logs in the Logs Page 1. Select Diagnostics > Logs on the top navigation bar. 2. Click Select Sources to display the log source list. 3. Uncheck the All Sources checkbox. 4. Check the Cloudera Manager checkbox to view both Agent and Server logs, or click to the left of Cloudera Manager, and check either the Agent or Server checkbox. Cloudera Manager Administration Guide 13

14 Managing the Cloudera Manager Server and Agents 5. Click Search. For more information about the Logs page, see Logs. Viewing the Cloudera Manager Server Log 1. Select Diagnostics > Server Log on the top navigation bar. Note: You can also view the Cloudera Manager Server log at /var/log/cloudera-scm-server/cloudera-scm-server.log on the server host. Viewing the Cloudera Manager Agent Log 1. Click the Hosts tab. 2. Click the link for the host where you want to see the Agent log. 3. In the Details panel, click the Details link in the Host Agent field. 4. Click the Agent Log link. Note: You can also view the Cloudera Manager Agent log at /var/log/cloudera-scm-agent/cloudera-scm-agent.log on the Agent hosts. Changing Hostnames Important: The process described here requires Cloudera Manager and cluster downtime. After you have installed Cloudera Manager and created a cluster, you may need to update the names of the hosts running the Cloudera Manager Server or cluster services. To update a deployment with new hostnames, follow these steps: 1. Verify if SSL/TLS certificates have been issued for any of the services and make sure to create new SSL/TLS certificates in advance for services protected by TLS/SSL. Review Cloudera Manager and CDH documentation at Cloudera Documentation. Tip: Search for SSL and TLS in the documentation. 2. Export the Cloudera Manager configuration using one of the following methods: Open a browser and go to this URL Save the displayed configuration. From terminal type: $ curl -u admin:admin > cme-cm-export.json If Cloudera Manager SSL is in use, specify the -k switch: $ curl -k -u admin:admin > cme-cm-export.json where cm_hostname is the name of the Cloudera Manager host and api_version is the correct version of the API for the version of Cloudera Manager you are using. For example, 3. Stop all services on the cluster. 4. Stop the Cloudera Management Service. 5. Stop the Cloudera Manager Server. 6. Stop the Cloudera Manager Agents on the hosts that will be having the hostname changed. 14 Cloudera Manager Administration Guide

15 7. Back up the Cloudera Manager Server database using mysqldump, pg_dump, or another preferred backup utility. Store the backup in a safe location. 8. Update names and principals: a. Update the target hosts using standard per-os/name service methods (/etc/hosts, dns, /etc/sysconfig/network, hostname, and so on). Ensure that you remove the old hostname. b. If you are changing the hostname of the host running Cloudera Manager Server do the following: a. Change the hostname per step 8.1. b. Update the Cloudera Manager hostname in /etc/cloudera-scm-agent/config.ini on all Agents. c. If the cluster is configured for Kerberos security, do the following: a. In the Cloudera Manager database, set the merged_keytab value: PostgreSQL MySQL update roles set merged_keytab=null; update ROLES set MERGED_KEYTAB=NULL; Managing the Cloudera Manager Server and Agents b. Remove old hostname cluster service principals from the KDC database using one of the following: Use the delprinc command within kadmin.local interactive shell. From the command line: kadmin.local -q "listprincs" grep -E "(HTTP hbase hdfs hive httpfs hue impala mapred solr oozie yarn zookeeper)[^/]*/ [^/]*@" > cluster-princ.txt Open cluster-princ.txt and remove any non-cluster service principal entries within it. Make sure that the default krbtgt and other principals you created, or were created by Kerberos by default, are not removed by running the following: for i in `cat cluster-princ.txt`; do yes yes kadmin.local -q "delprinc $i"; done. c. Within the Cloudera Manager Admin Console recreate all the principals based on the new hostnames: a. Select Administration > Kerberos. b. Do one of the following: If there are no principals listed, click the Generate Principals button. If there are principals listed, click the top checkbox to select all principals and click the Regenerate button. 9. Start the Cloudera Manager database and Cloudera Manager Server. 10. Start the Cloudera Manager Agents on the newly renamed hosts. The Agents should show a current heartbeat in Cloudera Manager. 11. If one of the hosts that was renamed has a NameNode configured with High Availability and automatic failover enabled, reconfigure the ZooKeeper failover controller znodes to reflect the new hostname. Warning: Do not perform this step if you are also running JobTracker in a High Availability configuration, as clearing the hadoop-ha znode will negatively impact JobTracker HA. All other services, and most importantly HDFS, should not be running. Cloudera Manager Administration Guide 15

16 Managing the Cloudera Manager Server and Agents a. Start ZooKeeper services. Note: Make sure the ZooKeeper Failover Controller role is stopped within the HDFS service; start only the ZooKeeper Server role instances. b. On one of the hosts that has a ZooKeeper Server role, log into the Zookeeper CLI to delete the Nameservice znode: On a package-based installation zkcli.sh is found at: /usr/lib/zookeeper/bin/zkcli.sh On a parcel-based installation zkcli.sh is found at: $/opt/cloudera/parcels/cdh/lib/zookeeper/bin/zkcli.sh a. Verify that the HA znode exists: zkcli$ ls /hadoop-ha b. Delete the old znode: zkcli$ rmr /hadoop-ha/nameservice1 c. In the Cloudera Manager Admin Console, go to the HDFS service. d. Click the Instances tab. e. Select Actions > Initialize High Availability State in ZooKeeper For each of the Cloudera Management Service roles, go to their configuration and update the Database Hostname property. 13. Start all cluster services. 14. Start the Cloudera Management Service. Backing up Databases Cloudera recommends that you periodically back up the databases that Cloudera Manager uses to store configuration, monitoring, and reporting data and for managed services that require a database: Cloudera Manager - Contains all the information about what services you have configured, their role assignments, all configuration history, commands, users, and running processes. This is a relatively small database (<100MB), and is the most important to back up. A monitoring database contains monitoring information about service and host status. In large clusters, this database can grow large. Activity Monitor - Contains information about past activities. In large clusters, this database can grow large. Report Manager - Keeps track of disk utilization and processing activities over time. Medium-sized. Cloudera Navigator - Contains auditing information. In large clusters, this database can grow large. Hive Metastore - Contains Hive metadata. Relatively small. Backing Up PostgreSQL Databases The procedure for backing up a PostgreSQL database depends on whether you are using an embedded or external database. Backing up Embedded PostgreSQL Databases After stopping the database, back up the /var/lib/cloudera-scm-server-db directory. Backing up External PostgreSQL Databases Use the pg_dump utility: 1. Log in to the host where the Cloudera Manager Server is installed. 2. Run the following command as root: cat /etc/cloudera-scm-server/db.properties. The db.properties file contains: # Auto-generated by scm_prepare_database.sh 16 Cloudera Manager Administration Guide

17 Managing the Cloudera Manager Server and Agents # Mon Jul 27 22:36:36 PDT 2011 com.cloudera.cmf.db.type=postgresql com.cloudera.cmf.db.host=localhost:7432 com.cloudera.cmf.db.name=scm com.cloudera.cmf.db.user=scm com.cloudera.cmf.db.password=nnyfwijlbk 3. Run the following command as root using the parameters from the preceding step: # pg_dump -h localhost -p U scm > /tmp/scm_server_db_backup.$(date +%Y%m%d) 4. Enter the password specified for the com.cloudera.cmf.db.password property on the last line of the db.properties file. If you are using the embedded database, Cloudera Manager generated the password for you during installation. If you are using an external database, enter the appropriate information for your database. Backing Up MySQL Databases To back up the MySQL database, run the mysqldump command on the MySQL host, as follows: $ mysqldump -hhostname -uusername -ppassword database > /tmp/database-backup.sql For example, to back up the Activity Monitor database amon on the local host as the root user, with the password amon_password: $ mysqldump -pamon_password amon > /tmp/amon-backup.sql To back up the sample Activity Monitor database amon on remote host myhost.example.com as the root user, with the password amon_password: $ mysqldump -hmyhost.example.com -uroot -pcloudera amon > /tmp/amon-backup.sql Backing Up Oracle Databases For Oracle, work with your database administrator to ensure databases are properly backed up. Cloudera Manager Administration Guide 17

18

19 Cloudera Management Service Cloudera Management Service The Cloudera Management Service implements various management features as a set of roles: Activity Monitor - collects information about activities run by the MapReduce service Host Monitor - collects health and metric information about hosts Service Monitor - collects health and metric information about services and activity information from the YARN and Impala services Event Server - aggregates relevant Hadoop events and makes them available for alerting and searching Alert Publisher - generates and delivers alerts for certain types of events Reports Manager - generates reports that provide an historical view into disk utilization by user, user group, and directory, processing activities by user and YARN pool, and HBase tables and namespaces. Cloudera Manager manages each role separately, instead of as part of the Cloudera Manager Server, for scalability (for example, on large deployments it's useful to put the monitor roles on their own hosts) and isolation. In addition, for certain editions of the Cloudera Enterprise license, the Cloudera Management Service provides the Navigator Audit Server and Navigator Metadata Server (beta) roles for Cloudera Navigator. Displaying the Cloudera Management Service Status 1. Do one of the following: Select Clusters > Cloudera Management Service > mgmt. On the Status tab of the Home page, in Cloudera Management Service table, click the mgmt link. Starting the Cloudera Management Service 1. Do one of the following: 1. Select Clusters > Cloudera Management Service > mgmt. 2. Select Actions > Start. 1. On the Home page, click to the right of mgmt and select Start. 2. Click Start to confirm. The Command Details window shows the progress of starting the roles. 3. When Command completed with n/n successful subcommands appears, the task is complete. Click Close. Stopping the Cloudera Management Service 1. Do one of the following: 1. Select Clusters > Cloudera Management Service > mgmt. 2. Select Actions > Stop. 1. On the Home page, click to the right of mgmt and select Stop. 2. Click Stop to confirm. The Command Details window shows the progress of stopping the roles. 3. When Command completed with n/n successful subcommands appears, the task is complete. Click Close. Restarting the Cloudera Management Service 1. Do one of the following: 1. Select Clusters > Cloudera Management Service > mgmt. Cloudera Manager Administration Guide 19

20 Cloudera Management Service 2. Select Actions > Restart. 1. On the Home page, click to the right of mgmt and select Restart. 2. Click Restart to confirm. The Command Details window shows the progress of stopping and then starting the roles. 3. When Command completed with n/n successful subcommands appears, the task is complete. Click Close. Configuring Management Service Database Limits Each Cloudera Management Service role maintains a database for retaining the data it monitors. These databases (as well as the log files maintained by these services) can grow quite large. For example, the Activity Monitor maintains data at the service level, the activity level (MapReduce jobs and aggregate activities), and at the task attempt level. Limits on these data sets are configured when you create the management services, but you can modify these parameters through the Configuration settings in the Cloudera Manager Admin Console. For example, the Event Server lets you set a total number of events to store, and Activity Monitor gives you "purge" settings (also in hours) for the data it stores. There are also settings for the logs that these various services create. You can throttle how big the logs are allowed to get and how many previous logs to retain. 1. Do one of the following: Select Clusters > Cloudera Management Service > mgmt. On the Status tab of the Home page, in Cloudera Management Service table, click the mgmt link. 2. Select Configuration > View and Edit. 3. In the left-hand column, select the Default role group for the role whose configurations you want to modify. 4. Edit the appropriate properties: Activity Monitor - the Purge or Expiration period properties are found in the top-level settings for the role. Host and Service Monitor - see Data Storage for Monitoring Data. Log Files - log file size settings will be under the Logs category under the role group. 5. Click Save Changes. Adding and Starting Cloudera Navigator Roles 1. Do one of the following: Select Clusters > Cloudera Management Service > mgmt. On the Status tab of the Home page, in Cloudera Management Service table, click the mgmt link. 2. Click the Instances tab and click the Add button. The Customize Role Assignments page displays. 3. Customize the assignment of role instances to hosts. The wizard evaluates the hardware configurations of the hosts to determine the best hosts for each role. The wizard assigns all worker roles to the same set of hosts to which the HDFS DataNode role is assigned. These assignments are typically acceptable, but you can reassign services to hosts of your choosing, if desired. Click a field below a role to display a dialog containing a pageable list of hosts. If you click a field containing multiple hosts, you can also select All Hosts to assign the role to all hosts or Custom to display the pageable hosts dialog. The following shortcuts for specifying host names are supported: Range of hostnames (without the domain portion) Range Definition [1-4] Matching Hosts , , , Cloudera Manager Administration Guide

21 Cloudera Management Service Range Definition host[1-3].company.com host[07-10].company.com Matching Hosts host1.company.com, host2.company.com, host3.company.com host07.company.com, host08.company.com, host09.company.com, host10.company.com IP addresses Rack name Click the View By Host button for an overview of the role assignment by host ranges. 4. When you are satisfied with the assignments, click Continue. The Database Setup page displays. 5. Configure settings for required databases: a. Choose the database type: Leave the default setting of Use Embedded Database to have Cloudera Manager create and configure all required databases. Make a note of the auto-generated passwords. Select Use Custom Databases to specify external databases. Enter the database host, database type, database name, username, and password for the databases that you created when you set up databases for Cloudera Manager. 1. Provide information for the Activity Monitor (only needed when using MapReduce), Reports Manager, and Hive Metastore, and Cloudera Navigator databases. The value you enter as the database hostname must match the value you entered for the hostname (if any) when you created the database. b. Click Test Connection to confirm that Cloudera Manager can communicate with the databases using the information you have supplied. If the test succeeds in all cases, click Continue; otherwise check and correct the information you have provided for the databases and then try the test again. (For Hive, if you are using the embedded database, you will see a message saying the database will be created at a later point in the installation process.) The Review Changes page displays. 6. Review and accept any configuration changes (typically there are none). Click Accept. This returns you to the Instances page. 7. Check the checkboxes next to navigator and navigatormetaserver (Flex Edition or Data Hub Edition only). 8. Select Actions for Selected > Start and confirm Start in the pop-up. 9. Click Close. Cloudera Manager Administration Guide 21

22

23 Managing Users and Authentication Managing Users and Authentication This chapter covers managing user accounts, and configuring external authentication. Cloudera Manager User Accounts on page 23 Configuring External Authentication on page 24 Cloudera Manager User Accounts Access to Cloudera Manager features is controlled by user accounts. A user account identifies how a user is authenticated and determines what privileges are granted to the user. You manage user accounts through the Administration > Users page. When you are logged in to the Cloudera Manager Admin Console, the username you are logged in as is at the far right of the top navigation bar for example, if you are logged in as admin you will see. User Authentication User authentication can be done through a local database, through an external LDAP directory server (Active Directory or OpenLDAP-compatible), SAML, or through an external authentication program of your own choosing. Users accounts added in the Users page (which are stored in the local database) show Cloudera Manager in the User Type column. User accounts added from an LDAP directory or other external authentication mechanism will have External in the User Type column. See Configuring External Authentication on page 24 for information on configuring Cloudera Manager to use an external LDAP directory, SAML, or other authentication program for user authentication. User Roles A user role determines what Cloudera Manager features are accessible to the user and what actions the user can perform. A user account can be assigned one of three roles: Administrator - Allows the user to add, change, delete, and configure services or administer user accounts. Also, even if you are using an external authentication mechanism for user authentication, users with Administrator privileges can log in to Cloudera Manager using their local Cloudera Manager username and password. (This prevents the system from locking everyone out if the external authentication settings get misconfigured.) Limited Administrator - Allows the user to view service and monitoring information and decommission hosts, but cannot add services or take any other actions that affect the state of the cluster. Read-Only - Allows the user to view service and monitoring information but cannot add services or take any actions that affect the state of the cluster. Changing the Local Logged-In User Password 1. Right-click the logged-in username at the far right of the top navigation bar and select Change Password. 2. Enter the current password, and a new password twice and then click Submit. Adding a Local User Account 1. Select Administration > Users. 2. Click the Add User button. 3. Enter a username and password. 4. Optionally, specify the desired role for the new user. Cloudera Manager Administration Guide 23

24 Managing Users and Authentication 5. Click Submit. Changing a User Account Role and Password Changing An Account Role 1. Select Administration > Users. 2. Check the checkbox next to the username. 3. In the Assign Role: field, select a role from the drop-down list. 4. Click the Assign Role: button. Changing a Password for a Local User Account 1. Select Administration > Users. 2. Click the Change Password button next to a username with User Type Cloudera Manager. 3. Type the new password and repeat it to confirm. 4. Click the Submit button to make the change. Deleting Local User Accounts 1. Check the checkbox next to one or more usernames with User Type Cloudera Manager. 2. Click the Delete button. (There is no confirmation of the action.) Configuring External Authentication Important: This feature is available only with a Cloudera Enterprise license. For other licenses, the following applies: Cloudera Express - the feature is not available. Cloudera Enterprise Data Hub Edition Trial - the feature will not be available after you end the trial or the trial license expires. To obtain a license for Cloudera Enterprise, please fill in this form or call After you install a Cloudera Enterprise license, the feature will be available. Cloudera Manager provides several different mechanisms for authenticating users. You can add users in the Cloudera Manager Admin Console Users page, which adds them to the Cloudera Manager database (the default) or configure Cloudera Manager to authenticate against an external authentication service. This can be an LDAP server (Active Directory or an OpenLDAP compatible directory), or you can specify another external service. If you are using LDAP or an external service you can configure Cloudera Manager so that it can use both methods of authentication (internal database or external service), and you can determine the order in which it performs these searches. You can also restrict login access to members of specific groups, and can specify groups whose members will automatically be given administrator access to Cloudera Manager. Cloudera Manager also supports using the Security Assertion Markup Language (SAML) to enable single sign-on. Configuring an External Authentication Service for Authentication 1. Select Administration > Settings. 2. In the left-hand column, select the External Authentication category. 3. Select the order in which Cloudera Manager should attempt its authentication (Authentication Backend Order). Here you can choose to authenticate users using just one of the methods (using Cloudera Manager's own database is the default), or you can set it so that if the user cannot be authenticated by the first method, it will attempt using the second method. If you select External Only, users who are administrators in the Cloudera Manager database will still be able to log in with their database password. This is to prevent the 24 Cloudera Manager Administration Guide

25 system from locking everyone out if the authentication settings get misconfigured such as with a bad LDAP URL. 4. Go to the section for the type of authentication you want to configure, and follow the steps to set the properties appropriately: Configuring Authentication Using Active Directory on page 25 Configuring Authentication Using an OpenLDAP-compatible Server on page 25 Configuring Authentication Using an External Program on page 26 Configuring Authentication Using SAML on page 27 Managing Users and Authentication Configuring Authentication Using Active Directory 1. For External Authentication Type select Active Directory. 2. Provide the URL of the Active Directory server. 3. Provide the NT domain to authenticate against. 4. Optionally, provide a comma-separated list of LDAP group names in the LDAP User Groups property. If this list is provided, only users who are members of one or more of the groups in the list will be allowed to log into Cloudera Manager. If this property is left empty, all authenticated LDAP users will be able to log into Cloudera Manager. For example, if there is a group called "CN=ClouderaManagerUsers,OU=Groups,DC=corp,DC=com", add the group name ClouderaManagerUsers to the LDAP User Groups list to allow members of that group to log in to Cloudera Manager. The group names are case-sensitive. 5. In the LDAP Administrator Groups property, you can provide a list of groups whose members should be given administrator access when they log in to Cloudera Manager. (admin users must also be a member of at least one of the groups specified in the LDAP User Groups property or they will not be allowed to log in.) If this is left empty, then no users will be granted administrator access automatically at login administrator access will need to be granted manually by another administrator. 6. In the LDAP Limited Administrator Groups property, you can provide a list of groups whose members should be given limited administrator access when they log in to Cloudera Manager. Users who are members of one of the configured groups will be granted limited admin access upon logging in. Configuring Authentication Using an OpenLDAP-compatible Server For an OpenLDAP-compatible directory, you have several options for searching for users and groups: You can specify a single base Distinguished Name (DN) and then provide a "Distinguished Name Pattern" to use to match a specific user in the LDAP directory. Search filter options let you search for a particular user based on somewhat broader search criteria for example Cloudera Manager users could be members of different groups or organizational units (OUs), so a single pattern won't find all those users. Search filter options also let you find all the groups to which a user belongs, to help determine if that user should have login or admin access. 1. For External Authentication Type select LDAP. 2. Provide the URL of the LDAP server and (optionally) the base Distinguished Name (DN) (the search base) as part of the URL for example ldap://ldap-server.corp.com/dc=corp,dc=com. 3. If your server does not allow anonymous binding, provide the user DN and password to be used to bind to the directory. These are the LDAP Bind User Distinguished Name and LDAP Bind Password properties. By default, Cloudera Manager assumes anonymous binding. 4. To use a single "Distinguished Name Pattern," provide a pattern in the LDAP Distinguished Name Pattern property. Use {0} in the pattern to indicate where the username should go. For example, to search for a distinguished name where the the uid attribute is the username, you might provide a pattern similar to uid={0},ou=people,dc=corp,dc=com. Cloudera Manager substitutes the name provided at login into this pattern and performs a search for that specific user. So if a user provides the username "foo" at the Cloudera Manager login page, Cloudera Manager will search for the DN uid=foo,ou=people,dc=corp,dc=com. Cloudera Manager Administration Guide 25

26 Managing Users and Authentication If you provided a base DN along with the URL, the pattern only needs to specify the rest of the DN pattern. For example, if the URL you provide is ldap://ldap-server.corp.com/dc=corp,dc=com, and the pattern is uid={0},ou=people, then the search DN will be uid=foo,ou=people,dc=corp,dc=com. 5. You can also search using User and/or Group search filters, using the LDAP User Search Base, LDAP User Search Filter, LDAP Group Search Base and LDAP Group Search Filter settings. These allow you to combine a base DN with a search filter to allow a greater range of search targets. For example, if you want to authenticate users who may be in one of multiple OUs, the search filter mechanism will allow this. You can specify the User Search Base DN as dc=corp,dc=com and the user search filter as uid={0}. Then Cloudera Manager will search for the user anywhere in the tree starting from the Base DN. Suppose you have two OUs ou=engineering and ou=operations Cloudera Manager will find User "foo" if it exists in either of these OUs, that is, uid=foo,ou=engineering,dc=corp,dc=com or uid=foo,ou=operations,dc=corp,dc=com. You can use a user search filter along with a DN pattern, so that the search filter provides a fallback if the DN pattern search fails. The Groups filters let you search to determine if a DN or username is a member of a target group. In this case, the filter you provide can be something like member={0} where {0} will be replaced with the DN of the user you are authenticating. For a filter requiring the username, {1} may be used, as memberuid={1}. This will return a list of groups this user belongs to, which will be compared to the list in the LDAP User Groups and LDAP Administrator Groups, and LDAP Limited Administrator Groups properties (discussed in the section about Active Directory). Configuring Cloudera Manager to Use LDAPS instead of LDAP If the LDAP server certificate has been signed by a trusted Certificate Authority (that is, VeriSign, GeoTrust, and so on), steps 1 and 2 below may not be necessary. 1. Copy the CA certificate file (ca.cer, etc.) to the Cloudera Manager Server. 2. Import the CA certificate(s) from the CA certificate file to the local keystore. For example: /usr/java/latest/bin/keytool -import -alias <nt_domain_name> -keystore /usr/java/latest/jre/lib/security/cacerts -file <path_to_cert> Note: The default password for the cacerts store is changeit. The alias can be any name (not just the domain name). 3. Configure the LDAP URL in the Cloudera Manager configuration to use ldaps://<ldap_server> instead of ldap://<ldap_server>. Configuring Authentication Using an External Program You can configure Cloudera Manager to use an external authentication program of your own choosing. Typically, this may be a custom script that interacts with a custom authentication service. Cloudera Manager will call the external program with the username as the first command line argument. The password is passed over stdin. Cloudera Manager assumes the program will return the following exit codes: 0 for the successful authentication of a regular user 1 for the successful authentication of an admin user 2 for the successful authentication of a limited admin user a negative value for failure to authenticate. 1. For External Authentication Type select External Program. 2. Provide a path to the external program in the External Authentication Program Path property. 26 Cloudera Manager Administration Guide

27 Managing Users and Authentication Configuring Authentication Using SAML Important: This feature is available only with a Cloudera Enterprise license. For other licenses, the following applies: Cloudera Express - the feature is not available. Cloudera Enterprise Data Hub Edition Trial - the feature will not be available after you end the trial or the trial license expires. To obtain a license for Cloudera Enterprise, please fill in this form or call After you install a Cloudera Enterprise license, the feature will be available. Cloudera Manager supports the Security Assertion Markup Language (SAML), an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider (IDP) and a service provider (SP). The SAML specification defines three roles: the principal (typically a user), the IDP, and the SP. In the use case addressed by SAML, the principal (user agent) requests a service from the service provider. The service provider requests and obtains an identity assertion from the IDP. On the basis of this assertion, the SP can make an access control decision in other words it can decide whether to perform some service for the connected principal. The primary SAML use case is called web browser single sign-on (SSO). A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML SP. The SP, wishing to know the identity of the requesting user, issues an authentication request to a SAML IDP through the user agent. In the context of this terminology, Cloudera Manager operates as a SP. This topic discusses the Cloudera Manager part of the configuration process; it assumes that you are familiar with SAML and SAML configuration in a general sense, and that you have a functioning IDP already deployed. Note: Cloudera Manager supports both SP- and IDP-initiated SSO. The logout action in Cloudera Manager will send a single-logout request to the IDP. SAML authentication has been tested with specific configurations of SiteMinder and Shibboleth. While SAML is a standard, there is a great deal of variability in configuration between different IDP products, so it is possible that other IDP implementations, or other configurations of SiteMinder and Shibboleth, may not interoperate with Cloudera Manager. Setting up Cloudera Manager to use SAML requires the following steps. Preparing Files You will need to prepare the following files and information, and provide these to Cloudera Manager: A Java keystore containing: A private key for Cloudera Manager to use to sign/encrypt SAML messages Any public certificates needed to verify the sign/encrypt key used by your IDP The SAML metadata XML file from your IDP The entity ID that should be used to identify the Cloudera Manager instance How the user ID is passed in the SAML authentication response: As the NameID As an attribute. If so, what identifier is used. The method by which the Cloudera Manager role will be established: From an attribute in the authentication response: Cloudera Manager Administration Guide 27