Member since
04-22-2014
1218
Posts
342
Kudos Received
157
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 28544 | 03-03-2020 08:12 AM | |
| 18977 | 02-28-2020 10:43 AM | |
| 5251 | 11-12-2019 03:28 PM | |
| 7641 | 11-01-2019 09:01 AM | |
| 7362 | 08-12-2019 11:06 AM |
07-22-2019
02:15 PM
@Roroka, We need to make sure that your Cloudera Manager configuration matches with the agent configuration. Based on the below configuration, your agent is configured to use TLS but will perfom no validation of the Cloudera Manager certificate. In order for a heartbeat to work, then, you would need to have this configured in Cloudera Manager: You will also need to have configured Cloudera Manager to listen via TLS. The 'sslv3 alert bad certificate' message indicates that CM did not receive the certificate it expected from the agent (for authentication). I believe this indicates you have Use TLS Authentication of Agents to Server enabled in CM so CM expects agents will present a certificate. If you are just installing, though, I would not expect TLS to be involved at all. Did you enable "Auto-TLS" during installation. If so, do you have Cloudera Express? We need more of an understanding of the steps you used to install and also the current configuration of CM. Also, we need to know what your goal is at this stage and if you were trying to enable TLS in some way... Thanks!
... View more
07-22-2019
09:35 AM
@dennisli, If you are using parcels, you need to start the server from Cloudera Manager's UI. In fact if you are using Cloudera Manager to manage your cluster, you need to use CM to start your services.
... View more
07-19-2019
04:23 PM
1 Kudo
@Kevin_Z, The trick is knowing which structure stores the values. In the case of mapreduce.job.split.metainfo.maxsize you can find it via the REST api like this: (assuming your cluster was named cluster and your YARN service wasnamed yarn) http://cm_host:7180/api/v32/clusters/cluster/services/yarn/roleConfigGroups/yarn-GATEWAY-BASE/config?view=full You can see the configuration: { "name" : "mapreduce_jobtracker_split_metainfo_maxsize", "required" : false, "default" : "10000000", "displayName" : "JobTracker MetaInfo Maxsize", "description" : "The maximum permissible size of the split metainfo file. The JobTracker won't attempt to read split metainfo files bigger than the configured value. No limits if set to -1.", "relatedName" : "mapreduce.job.split.metainfo.maxsize", "sensitive" : false, "validationState" : "OK" }, See the comparable command for the REST call above: https://archive.cloudera.com/cm6/6.2.0/generic/jar/cm_api/swagger-html-sdk-docs/python/docs/RoleConfigGroupsResourceApi.html#read_config Cloudera Manager the following: Service Configuration (configuration items apply to every role for that service) Role Configuration Groups (Each role will use a role configuration group which defines configuration for all roles belonging to that role config group Overrides (A configuration value can be set for a specific role (overriding other configurations) In the case of "mapreduce.job.split.metainfo.maxsize" it is defined in the default Role Configuration Group for the YARN Gateway Role type. The default value is: 10000000 Via Python, I used the following to ad a "value" that was not None: #!/usr/bin/env python
import cm_client
from cm_client.rest import ApiException
from pprint import pprint
# Configure HTTP basic authorization: basic
cm_client.configuration.username = 'admin'
cm_client.configuration.password = 'lizard'
cm_client.configuration.verify_ssl = True
# Path of truststore file in PEM
cm_client.configuration.ssl_ca_cert = '/opt/cloudera/security/cacerts/ClouderaSEC_combined.pem'
# Create an instance of the API class
api_host = 'https://host-10-17-100-224.coe.cloudera.com'
port = '7183'
api_version = 'v30'
# Construct base URL for API
# http://cmhost:7180/api/v30
api_url = api_host + ':' + port + '/api/' + api_version
api_client = cm_client.ApiClient(api_url)
cluster_api_instance = cm_client.ClustersResourceApi(api_client)
# This lists all clusters, so if you have more than one, set "cluster_name" to it. Otherwise, last one wins
api_response = cluster_api_instance.read_clusters(view='SUMMARY')
for cluster in api_response.items:
cluster_name = cluster.name
# Get a list of all services and set myserive if the service type is "YARN"
services_api_instance = cm_client.ServicesResourceApi(api_client)
services = services_api_instance.read_services(cluster.name, view='FULL')
for service in services.items:
if service.type == 'YARN':
myservice = service
# Get a list of roles and get the GATEWAY type
roles_api_instance = cm_client.RolesResourceApi(api_client)
roles = roles_api_instance.read_roles(cluster_name, myservice.name)
for role in roles.items:
if role.type == 'GATEWAY':
myrole = role
# default is summary... this is only relevant if printing out information since full shows all values
# regardless if they have a non-default value or not
view = 'full'
# Uses RoleConfigGroupsResourceApi to retrieve all YARN role config groups
# Sets yarnGatewayBase to be the name of the role config group we want to update
rcg_api_instance = cm_client.RoleConfigGroupsResourceApi(api_client)
rcg_api_response = rcg_api_instance.read_role_config_groups(cluster_name, myservice.name)
pprint(rcg_api_response)
for cfg in rcg_api_response.items:
if cfg.name == "yarn-GATEWAY-BASE":
yarnGatewayBase = cfg.name
# read the config and iterate over each config till we find the one we want
# print out the config before update
yarn_gateway_base = rcg_api_instance.read_config(cluster_name, yarnGatewayBase, myservice.name, view=view)
for config in yarn_gateway_base.items:
if config.related_name == 'mapreduce.job.split.metainfo.maxsize':
print "mapreduce.job.split.metainfo.maxsize before update:\n===================\n"
pprint(config)
print "mapreduce.job.split.metainfo.maxsize after update:\n====================\n"
config_to_update = config.name
# Set message and new config values where "value" is what we want the new value to be
# use update_config() to update the value
message = 'testing update of mapreduce.job.split.metainfo.maxsize' # str | Optional message describing the changes. (optional)
new_config = cm_client.ApiConfig(name=config_to_update, value="20000000")
new_config_list = cm_client.ApiConfigList([new_config])
try:
# Updates the config for the given role config group.
res = rcg_api_instance.update_config(cluster_name, yarnGatewayBase, myservice.name, message=message, body=new_config_list)
pprint(res)
except ApiException as e:
print("Exception when calling RoleConfigGroupsResourceApi->update_config: %s\n" % e) If you have questions about anything, let us know.
... View more
07-19-2019
02:06 PM
@viha, If that is the first time you have started Cloudera Manager, those tables should not exist. CM, when first started, will create the necessary tables and populate them accordingly. Maybe there was an error or problem during install previously that led to the tables being created but not populated with any data? Seems like we are in a strange state either way. I would recommend starting over with an empty database and then try starting CM. The exception you get indicates that the VERSION column (in CM_VERSION table) value is "null". That should not be possible, so startup fails.
... View more
07-18-2019
06:31 PM
@Debashish, yup, stderr.log looks good. Please check your Region Server log file on that host (usually it is in /var/log/hbase with the name REGIONSERVER in it). I am guessing you will see an attempt to start up and then a failure of sorts.
... View more
07-17-2019
10:23 PM
1 Kudo
@Debashish, let's make sure that we can confirm the cause of your problem first, though, before pursuing the znode stuff.
... View more
07-17-2019
10:22 PM
@Debashish, The "supervisor_status" file is not used by hbase, so this message should be non-fatal. I'd check to see if the stderr.log file for the region server process and see if there were any other messages after that Permission Denied. My guess is that the region server log file may contain errors regarding znodes. If Hbase created an Zookeeper znodes while Kerberos was enabled, then the znodes will require auth and will need to be recreated. I think the solution I mentioned here should help: https://community.cloudera.com/t5/Cloudera-Manager-Installation/Disabling-Kerberos-on-Cloudera-EXpress-5-5-1-HBase-issue/m-p/42535/highlight/true#M7642
... View more
07-17-2019
10:09 PM
@TCloud, The configuration we want is the one that got us the following: WrongHost: Peer certificate subjectAltName does not match host, expected srv-c01.mws.mds.xyz, got DNS:cm-r01nn01.mws.mds.xyz This error means that the Cloudera Manager certificate only contains a SAN or CN subject value of cm-r01nn01.mws.mds.xyz. Since the agent is configured to connect to srv-c01.mws.mds.xyz, it attempts to validate that the certificate is valid for srv-c01.mws.mds.xyz. This situation is addressed here: https://www.cloudera.com/documentation/enterprise/latest/topics/admin_cm_ha_tls.html#cloudera-manager-server-cert-requirements-for-HA In order to make sure that clients can connect to CM by using both srv-c01.mws.mds.xyz and cm-r01nn01.mws.mds.xyz, we need to create a self-signed certificate that contains both in Subject Alternative Name. For a self-signed certificate, you could use: keytool -keystore testkeystore.jks -storepass password -keypass password -alias cm-r01nn01.mws.mds.xyz -genkeypair -keysize 2048 -keyalg RSA -dname "CN=cm-r01nn01.mws.mds.xyz" -ext san=dns:cm-r01nn01.mws.mds.xyz,dns:srv-c01.mws.mds.xyz If you do recreate the CM certificate like that, you will need to also replace the previous certifiate with this one in any trust store you created since a new key pair was created. Although it might require a bit more doing, the above should address the error you get when using TLS pass-through in HAProxy. Next, we need to make sure that HAProxy routes requests to your primary CM host every time and only routes to the other host in the event of the primary host's failure. I believe this can be achieved by removing "balance roundrobin" but I'm not sure. I feel like it may make sense to use "backup" directives in the server configuration for nn02 but I'm not sure... seems our example doesn't feel it is necessary.
... View more
07-17-2019
10:37 AM
@TCloud, Have you tried it and it failed? If so, what was the problem. You configure the agent with a hostname and a port that it will use to send heartbeats to that host and port. If you have TLS enabled, then the same rules apply: If the client (agent) is doing validation, then it must be able to trust the signer of the CM certificate and it must be able to validate that the hostname it connected to is included in the certificate (in Subject Alt Name or CN subject). If you are doing agent authentication to CM, then CM must trust the signer of the certificate presented by the agent. I don't know if TLS termination at the balancer will work unless the balancer can authenticate. I'd recommend against termination with heartbeats.
... View more
07-17-2019
09:43 AM
@Roroka, Since the agent has not been able to heartbeat to Cloudera Manager, it does not know what parcels it needs, so the error you observe regarding "active_parcels.json" is occurring due to an earlier problem. Can you take a closer look at the cloudera-scm-agent.log to see what the first exception (probably mentions "heartbeat"). If you can include that and 10 or more lines before and after, that should help give us some context for the problem. If you can, also share with us the output of the following command when run on the host that is not able to heartbeat: grep -v -e '^[[:space:]]*$' -e '^#' /etc/cloudera-scm-agent/config.ini Thanks!
... View more