[
https://issues.apache.org/jira/browse/HDFS-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16293927#comment-16293927
]
Chris Douglas commented on HDFS-10285:
--------------------------------------
bq. Would it be possible to extract an API for the SPS to other NN components
(particularly the namesystem, block manager, and datanode manager)? That might
make the couplings more explicit, ideally so the interface would be sufficient
as an RPC protocol, if the SPS were moved outside the NN.
Sorry, I phrased this proposal poorly. Can we write an API for the SPS, so one
could configure the NN to e.g.,
# run it internally (similar to the current implementation)
# expose an RPC service to an external SPS client
# load a noop plugin (disabling it)?
The traversal machinery and most of the queries could be more abstract and/or
reuse existing NN protocols. This might imply that the client-facing SPS RPC
would be its own protocol, rather than being an extension to a NN protocol.
Making a plugin of the mover- and maybe the rebalancer- logic might be a
reasonable choice for some sites.
In HDFS-12911, I tried a naive patch that wrapped some of the read operations
for the SPS, so it doesn't explicitly retain handles to the namespace and block
manager. We could cut that API down and wrap types where necessary, so the SPS
implementation could perform the same calculations and scheduling, but
potentially live outside the NN. For example, while the {{IntraNNSPSContext}}
simply redirects calls to internal NN modules, an external context could
execute RPC calls. "Writes" (i.e., block move operations) could also be
delegated to an SPS module that communicates directly with DNs (like the
mover/rebalancer), or with a proxy RPC running in the SPS plugin on the NN, or
invokes the existing code.
Would this be a plausible path forward? It would require additional work to
make the SPS more modular, but for the most part it's refactoring.
> 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]
