[Feature Request]: Support custom key prefix for etcd to enable multi-tenancy

[uniqueni]

Describe your feature request

Problem Statement

Currently, when using etcd as the metadata backend, Mooncake uses a hardcoded key prefix mooncake/ for all metadata entries. This creates challenges in the following scenarios:

1. Multi-environment deployment: Running multiple Mooncake instances (dev/test/prod) on the same etcd cluster causes key conflicts
2. Multi-tenancy: Different applications or tenants sharing the same etcd cluster cannot isolate their metadata
3. Namespace collision: Cannot run multiple independent Mooncake clusters on shared infrastructure

Example of current etcd keys:
mooncake/ram/segment_name
mooncake/rpc_meta/server_name

Before submitting a new issue...

• Make sure you already searched for relevant issues and read the documentation

[uniqueni]

submitted a pr for this issue #958

[xiaguan]

Maybe you could try P2PHANDSHAKE instead of etcd.

[uniqueni]

Maybe you could try P2PHANDSHAKE instead of etcd.

Master is HA mode. CanP2PHANDSHAKE also be used?

[xiaguan]

Sure.

[uniqueni]

我重新阐述下我的问题 在我们的场景中
使用 k8s 部署 mooncake 想用 etcd 来进行高可用的选举 以及 metadata 的持久化存储 但是我们集群是分租户的，我们一个租户可能会部署多个 mooncake，当前项目中的 etcd 的使用 都是写死了 path
这导致我们一个 mooncake 只能用一个 etcd 这个该怎么解决呢

[xiaguan]

@ykwd 可以帮忙看下吗？

[ykwd]

@ykwd 可以帮忙看下吗？

没问题。

@uniqueni Thanks for raising this issue. However, after reviewing PR #958, I noticed that it modifies the metadata server section in the transfer engine, which is unrelated to the HA election logic. The HA election uses the key defined in ha_helper.h:

inline const char* const MASTER_VIEW_KEY = "mooncake-store/master_view";

Currently, on the master side, it’s already possible to specify the cluster name via the --cluster-id option. Could we leverage this mechanism to change MASTER_VIEW_KEY so that it’s determined by the cluster ID, for example:

mooncake-store/<cluster id>/master_view

The client side could then specify this via an environment variable.

As for the multi-tenant scenario, on the transfer engine side, when using etcd as the metadata server, although there’s currently no isolation between tenants, it doesn’t seem to affect correctness at the moment. If we plan to modify this part, it might be good to discuss it with @alogfans .

[uniqueni]

@ykwd sorry 关于#958 我开始只是提交了 metadata 相关的 prefix 的修改
刚刚重新提交了下关于 etcd 选主的 key prefix逻辑

关于cluster_id 来做集群隔离也可以 但其实针对于多集群 多租户的场景下 我个人认为还是自定义 prefix 比较灵活

@alogfans 也请大佬帮忙看看 因为我不知道为什么 etcd 的路径要写死 不知道是不是by design

[ykwd]

Solved with #958