[
https://issues.apache.org/jira/browse/HDFS-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283795#comment-16283795
]
Daryn Sharp commented on HDFS-10285:
------------------------------------
*Philosophical aside – please refrain from debating*
My rhetorical question was only illustrating why end-user convenience or
support overhead isn't a valid argument for an internal service. Don't want to
get mired here but I'll quickly touch on the philosophical questions regarding
current services. For me, the most basic consideration for an internal service
is can hdfs effectively function w/o it?
* The repl monitor is unquestionably critical for durability. Not running for
a day or two would be disastrous.
* EZ already relies on an external KMS service. The "internal service" caches
EDEKs.
* Balancer is non-critical. Hdfs functions w/o it albeit with degraded
performance on full cluster.
By this standard: SPS is non-critical. Admittedly the HSM feature isn't very
useful w/o it but hdfs can function. I don't want to specifically
belabor/debate this point, but rather evaluate the feasibility of designs that
should make everyone happy.
*Strictly external*
Let's discuss how/why it's difficult to separate. Specifically, what new
interfaces will be required? {{listLocatedStatus}} probably returns most
necessary data. It's not the cheapest call but I have patches in the wing to
heavily optimize it. Now it feels like a different form of balancing. What am
I missing?
Or we can forego that evaluation and discuss:
*Hybrid design*
Let's consider how a hybrid approach might work: NN handles basic HSM duties to
satisfy the feature, with an adjunct service that provides an optional and
non-critical coordinator that can independently evolve and become more
sophisticated.
Conceptually, blocks violating the HSM policy are a form of mis-replication
that doesn't satisfy a placement policy – which would truly prevent performance
issues if the feature isn't needed. The NN's repl monitor ignorantly handles
the moves as a low priority transfer (if/since it's sufficiently replicated).
The changes to the NN are minimalistic.
DNs need to support/honor storages in transfer requests. Transfers to itself
become moves. Now HSM "just works", eventually, similar to increasing the repl
factor.
An external SPS can provide fancier policies for accelerating the processing
for those users like hbase.
> Storage Policy Satisfier in Namenode
> ------------------------------------
>
> Key: HDFS-10285
> URL: https://issues.apache.org/jira/browse/HDFS-10285
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: datanode, namenode
> Affects Versions: HDFS-10285
> Reporter: Uma Maheswara Rao G
> Assignee: Uma Maheswara Rao G
> Attachments: HDFS-10285-consolidated-merge-patch-00.patch,
> HDFS-10285-consolidated-merge-patch-01.patch,
> HDFS-10285-consolidated-merge-patch-02.patch,
> HDFS-10285-consolidated-merge-patch-03.patch,
> HDFS-SPS-TestReport-20170708.pdf,
> Storage-Policy-Satisfier-in-HDFS-June-20-2017.pdf,
> Storage-Policy-Satisfier-in-HDFS-May10.pdf,
> Storage-Policy-Satisfier-in-HDFS-Oct-26-2017.pdf
>
>
> Heterogeneous storage in HDFS introduced the concept of storage policy. These
> policies can be set on directory/file to specify the user preference, where
> to store the physical block. When user set the storage policy before writing
> data, then the blocks could take advantage of storage policy preferences and
> stores physical block accordingly.
> If user set the storage policy after writing and completing the file, then
> the blocks would have been written with default storage policy (nothing but
> DISK). User has to run the ‘Mover tool’ explicitly by specifying all such
> file names as a list. In some distributed system scenarios (ex: HBase) it
> would be difficult to collect all the files and run the tool as different
> nodes can write files separately and file can have different paths.
> Another scenarios is, when user rename the files from one effected storage
> policy file (inherited policy from parent directory) to another storage
> policy effected directory, it will not copy inherited storage policy from
> source. So it will take effect from destination file/dir parent storage
> policy. This rename operation is just a metadata change in Namenode. The
> physical blocks still remain with source storage policy.
> So, Tracking all such business logic based file names could be difficult for
> admins from distributed nodes(ex: region servers) and running the Mover tool.
> Here the proposal is to provide an API from Namenode itself for trigger the
> storage policy satisfaction. A Daemon thread inside Namenode should track
> such calls and process to DN as movement commands.
> Will post the detailed design thoughts document soon.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
