[ 
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]

Reply via email to