Hello @sgenchev    While I am not familiar with building Charts to answer the Query, I shall share a few CLI approaches: (I) HBCK: Running "hbase hbck --details" prints [1] detailing the Regions per RegionServer. (II) Using JMX: Say, the HMaster UI is "http://HMaster1:22002/master-status".  Replace "master-status" with "jmx", which prints the JSON Output. Additional filtering can be done to capture the Regions per RegionServers.    Regards, Smarak   [1] HBCK Output: RegionServer: RegionServer1,22101,1655811831192 number of regions: 1 RegionServer: RegionServer2,22101,1655811830393 number of regions: 1 RegionServer: RegionServer2,22101,1655811832307 number of regions: 1 ... View more

Hello @LakshmiSegu    We hope your query was addressed by Shehbaz's response. In Summary, (I) Ensure you Username has an IDBroker Mapping (Actions > Manage Access > IDBroker Mappings).  (II) Include the "spark.yarn.access.hadoopFileSystems" Parameter to point to the S3 Path [1].    Regards, Smarak   [1] https://docs.cloudera.com/runtime/7.2.15/developing-spark-applications/topics/spark-s3.html   ... View more

Hello @caisch    Thanks for using Cloudera Community. Based on your Post, you wish to confirm if TTL for HDFS can be set to 90Days & other Services' TTL is set to 14Days.   Since you selected Solr, Let me answer your Post & you can let me know if I understood the Post differently. In Solr, We have Collections which may have Data on HDFS or Local. For Example, RangerAudits Collection may have Data on HDFS & Atlas Collection may have Data on Local. At each Collection Level, the "solrconfig.xml" captures the TTL [1] via DocExpirationUpdateProcessorFactory Class. You can configure the TTL at each Collection Level in Solr & they would Cleanup the Underlying  Data, be it on HDFS or Local. Using the above Example of RangerAudits using HDFS Storage & Atlas using Local Storage, We can set RangerAudits to expire at 90 Days & Atlas to expire at 14 Days, which in turn would remove the Underlying  Data from HDFS & Local respectively for RangerAudits & Atlas.    Kindly review & let us know if the above answers your Post. If No, You may clarify & we shall get back to you accordingly.   Regards, Smarak   [1] https://solr.apache.org/docs/8_4_0/solr-core/org/apache/solr/update/processor/DocExpirationUpdateProcessorFactory.html   ... View more

Hello @HiThere    Thanks for using Cloudera Community. To your Query, Kindly refer [1] & [2] for Resource Requirement for CDP v7.1.7. Note that Documentation refers to Hardware requirement in terms of Resources (CPU, Memory, Network, Disk) as opposed to Physical Machines or Virtual Machines. As long as your Team meet the Hardware requirement for Storage & Compute, the Virtualized & Bare-Metal choices shouldn't matter.   Regards, Smarak   [1] https://docs.cloudera.com/cdp-private-cloud-base/7.1.7/installation/topics/cdpdc-hardware-requirements.html [2] https://docs.cloudera.com/cdp-private-cloud-base/7.1.7/concepts/topics/cm-vpc-networking.html   ... View more

Hello @yagoaparecidoti    Thanks for using Cloudera Community. Based on the Post, You encountered "Master Is Initializing" & ended up fixing the same using Command found on Internet. You ended up with few Tables in Broken State, requiring you to delete & recreate them.   For documenting the Post, the Issue observed is tracked via [1]. In the HMaster Logs, We should see HBase:Meta & HBase:Namespace Region, which aren't being assigned. Sample tracing shared via [1]. Once the same happens, Using HBCK2 Jar to assign the Region being reported as Unassigned is required. The Command to be used via HBCK2 Jar to assign the Region is shared via [1] as well.    The HBCK2 Command has other Options, which (If performed without any oversight) may cause issues with HBase Table availability. The "Master Is Initializing" Error Fix as shared via [1] shouldn't cause any Table to be in Broken State & without knowing the explicit details into the Broken State, It's harder to confirm if Delete-Recreate was the ONLY Way Or, We could have restored the Table in other ways.   Having said that, the Post covers "Master Is Initializing" Error & the same has been addressed. As such, We shall mark the Post as Closed. Feel free to share your observation with the Tables in Broken State in a New Post, if you wish to engage for the Community observation & feedback.    Regards, Smarak   [1] https://github.com/apache/hbase-operator-tools/tree/master/hbase-hbck2#master-startup-cannot-progress-in-holding-pattern-until-region-onlined   ... View more

Greetings @yagoaparecidoti    Thanks for using Cloudera Community. Based on the Post, you wish to confirm if the  "maxClientCnxns" Parameter set via CDM (Assuming you mean CM) for ZooKeeper Service is referred in any file associated.    You may refer to the Value of "maxClientCnxns" in "zoo.cfg" file associated with the ZooKeeper Process. In CDP/CDH (Managed by CM), You may refer to the same within the ZooKeeper Process Directory under "/var/run/cloudera-scm-agent/process/<ZooKeeper-Process-Directory>/zoo.cfg". The concerned file would be referred in the "ps" Output of the ZooKeeper Process as well.    Regards, Smarak ... View more

Hello @dutras    As the Issue has been resolved via Support Case, We are marking the Post as resolved.    For reference, this Case required Repair & associated Steps, which are verbose to be documented in Community. For anyone facing such issues, Kindly submit a Support Case.   Regards, Smarak ... View more

Hello @AzfarB    Thanks for using Cloudera Community. Based on the Post, Your Team observed Solr-Infra JVM reporting WARNING for Swap Space more than 200MB being utilised. Restarting the Solr-Infra JVM ensured the WARNING went away.    Note that Swapping isn't Bad in general & the same has been discussed in detail by Community in [1] & [2]. Plus, Deleting RangerAudits Documents won't affect the same as Solr uses JVM as documented [3]. Indexed Documents aren't persisted in Memory unless Cached, thereby ensuring Deletion won't fix the Swapping guaranteed.    As your Screenshot shows, the Host itself is running short on Memory (~99% Utilised) & Overall Swap is ~80% at ~47GB, out of which Solr-Infra is contributing <1GB. As documented in the below Links, Your Team can focus on the Host Level Usage & Considering Increasing the Swap Threshold from 200MB to at least 10% of the Heap i.e. 2GB for a Warning.   01 additional point can be made as to why Solr-Infra Restart helped resolved the WARNING. This needs to be looked at from the Host perspective as to the amount of Memory freed & Whether the Overall Swap Usage reduced at Host Level after Solr-Infra Restart as opposed to Solr-Infra WARNING being suppressed only.    Regards, Smarak    [1] https://unix.stackexchange.com/questions/2658/why-use-swap-when-there-is-more-than-enough-free-space-in-ram [2] https://chrisdown.name/2018/01/02/in-defence-of-swap.html [3] https://blog.cloudera.com/apache-solr-memory-tuning-for-production/ ... View more