[
https://issues.apache.org/jira/browse/HDFS-10967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563882#comment-15563882
]
Konstantin Shvachko commented on HDFS-10967:
--------------------------------------------
This could be good optimization of placement policy for other than the first
replicas when some nodes are close to full.
This should only be turned on though in heterogeneous environment. With
homogeneous nodes where node usage is balanced this will be just a performance
overhead.
Few suggestions on the patch
# Set the default for remaining capacity threshold that triggers new behavior
to {{0.00}}. Homogeneous clusters should not require reconfiguration.
# The config variable is more like a "threshold" rather than a "factor" as in
{{considerLoad}}. So may be call it
{{dfs.namenode.replication.considerCapacity.threshold}}.
# I would suggest to use only one configuration variable. The Boolean
{{considerCapacity}} is essentially redundant.
# Would be good to have a JavaDoc for the new config variable and for the
method, where the feature is triggered.
# Did you try to add {{isNearFull()}} call into {{isGoodDatanode()}}? Then you
will not need to retry 3 times.
# JavaDoc for the unit test would be also useful.
A separate discussion point whether we should add a separate admin command for
every configuration nob we introduce? This doesn't feel right. May be we should
have a command, say {{refreshConfiguration()}}, which re-reads config, updates
variables and logs what it updated. The main problem with admin command is that
it does not change configuration and when you restart the service or fail it
over you loose the set value. So may be anything that is controlled by
configuration should be updated through configuration and the
{{refreshConfiguration()}} call. We could have merged this with
{{setBalancerBandwidth()}} some time.
Alternatively, we can use failover to take effect of new configuration values.
Then we don't need new admin commands at all.
> Add configuration for BlockPlacementPolicy to avoid near-full DataNodes
> -----------------------------------------------------------------------
>
> Key: HDFS-10967
> URL: https://issues.apache.org/jira/browse/HDFS-10967
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
> Reporter: Zhe Zhang
> Assignee: Zhe Zhang
> Labels: balancer
> Attachments: HDFS-10967.00.patch, HDFS-10967.01.patch,
> HDFS-10967.02.patch, HDFS-10967.03.patch
>
>
> Large production clusters are likely to have heterogeneous nodes in terms of
> storage capacity, memory, and CPU cores. It is not always possible to
> proportionally ingest data into DataNodes based on their remaining storage
> capacity. Therefore it's possible for a subset of DataNodes to be much closer
> to full capacity than the rest.
> This heterogeneity is most likely rack-by-rack -- i.e. _m_ whole racks of
> low-storage nodes and _n_ whole racks of high-storage nodes. So It'd be very
> useful if we can lower the chance for those near-full DataNodes to become
> destinations for the 2nd and 3rd replicas.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
