[
https://issues.apache.org/jira/browse/HDDS-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123560#comment-17123560
]
Marton Elek commented on HDDS-3697:
-----------------------------------
Thanks to create [~maobaolong], very interesting idea. If I understood, the big
question is how the OMs and SCMs can be scaled up independent to each other.
I think it requires a broader design discussion, but let's start it:
Let's talk about the OM. Based on my understanding, here the OMs are not HA
instances but different instances responsible for different volumes. There
multiple available options in the existing systems:
1. Use a router which forwards the messages to the appropriate OM (in this
case the router can be the bottleneck and SPOF)
2. Use a service which maintains the mapping (volume name -> OM) and request
the information for each volume (same as 1 but request is not routed)
3. Use consistent hashing/rendezvous_hashing (similar to Crush in CEPH) and
find the right OM without additional query.
4. One variant for 3 is to propagate the full [volume-name -> OM] to all the
clients (and cache there) instead of propagate only the topology (which is
required for Crush)
I think we need to collect PRO/CON for each before we decide what should we
do...
> United Global namesystem by OzoneRouter
> ---------------------------------------
>
> Key: HDDS-3697
> URL: https://issues.apache.org/jira/browse/HDDS-3697
> Project: Hadoop Distributed Data Store
> Issue Type: New Feature
> Affects Versions: 0.7.0
> Reporter: maobaolong
> Priority: Major
> Labels: OzoneRouter
> Attachments: screenshot-1.png
>
>
> I involve a new role, we call it OzoneRouter(Concept from hdfs dfsrouter,
> maybe it can be use through modify the hdfs dfsrouter) as a frontend to
> client to supply a united global name system, furthermore, it maintains a
> mountable, some route policies and Ozone cluster information.
> The client talk to OzoneRouter through the ClientOzoneManager protocol. so it
> is a proxy between client and the real OM, change the mount point can route
> the rpc call to another OM.
> !screenshot-1.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]