You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Marton Elek (Jira)" <ji...@apache.org> on 2020/06/02 09:26:00 UTC

[jira] [Commented] (HDDS-3697) United Global namesystem by OzoneRouter

    [ 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: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org