Member since 
    
	
		
		
		09-29-2015
	
	
	
	
	
	
	
	
	
	
	
	
	
	
			
      
                63
            
            
                Posts
            
        
                107
            
            
                Kudos Received
            
        
                13
            
            
                Solutions
            
        My Accepted Solutions
| Title | Views | Posted | 
|---|---|---|
| 2985 | 05-04-2017 12:32 AM | |
| 4416 | 12-09-2016 07:58 PM | |
| 9887 | 12-09-2016 07:53 PM | |
| 1529 | 06-08-2016 09:26 PM | |
| 2099 | 06-08-2016 09:01 PM | 
			
    
	
		
		
		07-31-2017
	
		
		09:09 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 This is missing,  hdfs dfs -chown admin:hadoop /user/admin
 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		05-04-2017
	
		
		06:30 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 @Avijeet Dash, you may find this presentation useful, http://events.linuxfoundation.org/sites/events/files/slides/ambari_big_data_2017.pdf
Custom Services can be added to the stack, as long as they support lifecycle commands like stop, start, restart, status, etc., and can also contain Custom Commands.  Technology-wise, Ambari Server is all Java and supports multiple DB types (Postgres, MySQL, Oracle, Azure).
The Agents use Python for running, heartbeating, and executing the scripts for managing the Hadoop Services.
The Agents send heartbeat messages to the Server every 4-10 seconds (configurable).  The web UI uses AngularJS and Node.js to responsiveness and auto-refresh, and relies on the RESTful web service for all data. 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		05-04-2017
	
		
		12:32 AM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		2 Kudos
		
	
				
		
	
		
					
							 @Avijeet Dash  At its core, Ambari is able to perform the same common ops that DevOps are used to with Chef and Puppet.
Chef, Puppet, and Ansible are great for small clusters and limited operations, but as soon as you need to do perform complex operations like Kerberize, HA, Stack Upgrade, then those tools are not sufficient; this is where Ambari shines since it has deep knowledge about the cluster and Hadoop in order to perform things like:  
 Rolling Restart (pick any component, like DataNodes, and pick your batch size, sleep time, and failures tolerated)  High Availability for NameNode, Hive, Oozie, Resource Manager, etc (wizards to configure these and restart affected services)  Config Management (this is where it truly brings value; if a config changes, Ambari can suggest other configs to change, and validate dependent configs)  Kerberos Security: create and distribute keytabs, also handle use cases like adding hosts and more services  Rolling and Express Upgrade: the orchestration and config changes here alone, plus handling a downgrade, would easily take weeks to develop and test. Ambari has all of the tools to visualize the orchestration, auto-retry, handle failures, skip optional steps, etc.  Metrics: dashboards to visualize and analyze metrics, trends  Alerts: notifications, SNMP, port checks, liveliness checks, and UI to enable/disable  Maintenance Mode: put hosts and services in maintenance mode to suppress alerts and operations from running on certain hosts  LDAP: active directory for enterprise clusters  Service Auto-Start: automatically restart down services   and more.  Ambari was developed with scale in mind to minimize to support clusters with several thousand nodes. The agents heartbeat to the server with the status of commands and daemons; while the server sends commands down to the agents.  Blueprints is the mechanism to export an existing cluster and re-create it (or several others just like it) with a predefined topology, configs, etc. This is extremely useful in cloud environments.  I hope this answers your question. 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		05-03-2017
	
		
		10:01 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 Problem: There's a known bug in Ambari 2.4 and 2.5 that causes "ambari-server upgrade" to fail if the agent RPM is not upgraded first.  E.g. stack trace:  Using python /usr/bin/python Setup ambari-server Traceback (most recent call last): File "/usr/sbin/ambari-server.py", line 33, in from ambari_server.dbConfiguration import DATABASE_NAMES, LINUX_DBMS_KEYS_LIST File "/usr/lib/python2.6/site-packages/ambari_server/dbConfiguration.py", line 28, in from ambari_server.serverConfiguration import decrypt_password_for_alias, get_ambari_properties, get_is_secure, \ File "/usr/lib/python2.6/site-packages/ambari_server/serverConfiguration.py", line 36, in from ambari_commons.os_utils import run_os_command, search_file, set_file_permissions, parse_log4j_file ImportError: cannot import name parse_log4j_file  Cause: This occurs because os_utils.py and other python files inside of /usr/lib/ambari-agent/lib/ambari_commons are upgraded by the agent's RPM and are used by the server's scripts to find which database to use.  
Solution:
Note: Always back up your Ambari database before the upgrade.  If ambari-agent is also present on the Ambari Server host, run "yum upgrade ambari-agent" (or equivalent for your OS).
 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
		
			
				
						
							Labels:
						
						
		
	
					
			
		
	
	
	
	
				
		
	
	
			
    
	
		
		
		03-14-2017
	
		
		04:49 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 It's possible that the feature has not been maintained in the version of Ambari that you are using. 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		01-31-2017
	
		
		01:47 AM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		10 Kudos
		
	
				
		
	
		
					
							 
	Whether you're creating an Ambari cluster from scratch, taking over an existing cluster, or growing your cluster over time, it is imperative to tune Ambari and MySQL to work at a large scale of 1000-3000 Ambari Agents.  Ambari Server Configs  
	First, increase the memory used by Ambari. For large clusters, 8 GB of memory should be sufficient. If you have more than 10 concurrent users, increase it to 16 GB.  
	Edit /var/lib/ambari-server/ambari-env.sh and change the -Xmn setting. 
 export AMBARI_JVM_ARGS=$AMBARI_JVM_ARGS' -Xms2048m -Xmx8192m
  
	Edit /etc/ambari-server/conf/ambari.properties with the following configs 
 # The size of the Jetty connection pool used for handling incoming Ambari Agent requests.
# 10 hosts => 25
# 50 hosts => 35
# 100 hosts => 75
# 500 hosts => 100	
agent.threadpool.size.max=100
# Determines whether current alerts should be cached.
# Enabling this can increase performance on large cluster, but can also result in lost alert data
# if the cache is not flushed frequently.
alerts.cache.enabled=true
# The size of the alert cache.
# Less than 50 hosts => 50000
# More than 50 hosts => 100000
alerts.cache.size=100000
# The number of threads used to handle alerts received from the Ambari Agents.
# The value should be increased as the size of the cluster increases.
# Less than 50 hosts => 2
# More than 50 hosts => 4
alerts.execution.scheduler.maxThreads=4
  
	After performing these changes, restart Ambari Server.  Move an existing Ambari DB from a spinning disk to a SSD  
	It is highly suggested to use a Solid State Drive for the Ambari Database since this will be much faster.  
		Check the throughput of the disk in which Ambari’s database (Postgres, MySQL, MariaDB, or Oracle) is on.Ideally, it should be a Solid State Drive or support at least 200 IOPS and be either on the same host as Ambari or only a 1-2 hops away. 
 
 
 
	 
		Type
	 
	 
		Details
	 
	 
		IOPS
	 
	 
		Throughput
	 
 
 
	 
		HDD
	 
	 
		10,000 rpm SAS drive
	 
	 
		175-210
	 
	 
		100 MB/s
	 
 
 
	 
		SSD
	 
	 
		solid-state
	 
	 
		500+
	 
	 
		500+ MB/s
	 
 
 
  
	1. ambari-server stop  
	2. Take a backup of the Ambari database, 
 		mysqldump -u root ambari > /tmp/ambari.sql
  
	3. Stop MySQL server, copy its data, and change the directory. 
 service mysqld stop
cp -R -p /var/lib/mysql /mnt/disks/ssd/mysql
cat /etc/my.cnf
sed -ie 's/\/var\/lib\/mysql/\/mnt\/disks\/ssd\/mysql/g' /etc/my.cnf
  
	4. Create symlink for sock file and start MySQL 
 ln -s /mnt/disks/ssd/mysql/mysql.sock /var/lib/mysql/mysql.sock
service mysqldstart
  
	5. Ensure Ambari DB is accessible. 
 mysql -u root -p
show databases;
use ambari;
show tables;
select count(*) from hosts;
  MySQL Optimizations  
	First and foremost, if you're on an older version of MySQL, you can try to update it to MySQL 5.6 or 5.7, which has a lot of performance improvements.  
	Connect to the MySQL DB and inspect these variables. E.g.,  
	SHOW VARIABLES LIKE 'name';These suggested values assume that only Ambari Database’s is on the MySQL Server.If you have other databases in the same MySQL Server, increment by these values.  
	WARNING: Never stop MySQL server while Ambari Server is running. 
 
 
 
	 
		Variable
	 
	 
		Suggested Value
	 
 
 
	  innodb_log_buffer_size  
	 512M
	 
 
 
	 
		innodb_buffer_pool_size
	 
	 
		16G 
 
 
	 
		innodb_file_io_threads (deprecated in MySQL 5.5) 
	 16 
 
 
	 
		innodb_log_file_size
	 
	 
		5M
	 
 
 
	 
		innodb_thread_concurrency
	 
	 32 
 
 
	 
		join_buffer_size
	 
	 512M
	 
 
 
	 
		key_buffer_size
	 
	 16G 
 
 
	 
		max_connections
	 
	 
		500
	 
 
 
	 
		max_allowed_packet
	 
	 1024M
	 
 
 
	 
		max_heap_table_size
	 
	 
		64M
	 
 
 
	 
		query_cache_limit
	 
	 16M
	 
 
 
	 
		query_cache_size
	 
	 512M
	 
 
 
	 
		read_rnd_buffer_size
	 
	 128M
	 
 
 
	 
		sort_buffer_size
	 
	 128M
	 
 
 
	 
		table_open_cache
	 
	 
		1024
	 
 
 
	 
		thread_cache_size
	 
	 
		128
	 
 
 
	 
		thread_stack
	 
	 
		256K
	 
 
 
  
	To change these values.1. Stop MySQL: service mysqld stop  
	2. Edit the configs in /etc/my.cnf , under the “[mysqld]” section (note, it may be in a different location).  
	3. Start MySQL: service mysqld start 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
		
			
				
						
							Labels:
						
						
		
	
					
			
		
	
	
	
	
				
		
	
	
			
    
	
		
		
		12-09-2016
	
		
		07:58 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		2 Kudos
		
	
				
		
	
		
					
							 Thanks wbu,  What version of Ambari are you using? I'm guessing 2.4.x  I created https://issues.apache.org/jira/browse/AMBARI-19155 on your behalf. 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		12-09-2016
	
		
		07:53 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		6 Kudos
		
	
				
		
	
		
					
							 There's an API to remove older versions from the hosts.
Take a look at https://issues.apache.org/jira/browse/AMBARI-18435  E.g.,  curl 'http://c6401.ambari.apache.org:8080/api/v1/clusters/cl1/requests' -u admin:admin -H "X-Requested-By: ambari" -X POST -d'{"RequestInfo":{"context":"remove_previous_stacks", "action" : "remove_previous_stacks", "parameters" : {"version":"2.5.0.0-1245"}}, "Requests/resource_filters": [{"hosts":"c6403.ambari.apache.org, c6402.ambari.apache.org"}]}'   That removes all versions older than "2.5.0.0-1245"; the version mentioned in request remains intact. We also have checks that prevent removing the current version and the operation is idempotent.  That will not remove the version from Ambari's database, but will free up space. 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		09-23-2016
	
		
		07:07 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
				
		
	
		
					
							 The only relevant columns that are varchar(256) in the hosts table are host_name, cpu_info, os_arch, os_type, and rack_info.  You can try to figure out which one is exceeding the limit by printing out these values on the agent, or setting up wireshark to look at the traffic.  ambari=> select host_name, cpu_info, os_arch, os_type, rack_info from hosts;
        host_name        | cpu_info | os_arch | os_type |   rack_info
-------------------------+----------+---------+---------+---------------
 c6401.ambari.apache.org |          | x86_64  | centos6 | /default-rack
 c6402.ambari.apache.org |          | x86_64  | centos6 | /default-rack
 c6403.ambari.apache.org |          | x86_64  | centos6 | /default-rack
(3 rows)
  Or you can take a DB backup, increase the size of all of the varchar columns to 512 to find the offending value, fix it, and then restore your DB to perform the agent registration again.  http://sniptools.com/databases/resize-a-column-in-a-postgresql-table-without-changing-data 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		
			
    
	
		
		
		06-08-2016
	
		
		09:26 PM
	
	
	
	
	
	
	
	
	
	
	
	
	
	
		
	
				
		
			
					
	
		2 Kudos
		
	
				
		
	
		
					
							 The custom commands are actually defined at the service-level in the metainfo.xml file. E.g.,  HDFS: DECOMMISSION, REBALANCEHDFS
Hbase: DECOMMISSION
YARN: REFRESHQUEUES, CREATE_YARN_DIRECTORIES (needed for LLAP in a Kerberized cluster)
Knox: STARTDEMOLDAP, STOPDEMOLDAP
Hive: CLEAN, RESTART_LLAP
Kerberos: SET_KEYTAB, REMOVE_KEYTAB 
						
					
					... View more
				
			
			
			
			
			
			
			
			
			
		 
         
					
				













