cluster meta data

[cocalele]

cluster元数据，包括

• zookeeper上集群注册规则，这部分影响到节点启动后的注册行为
• MetaDB 里的数据， 这部分影响到pfconductor 创建volume， prepare volume的操作。

有三种可能的方法： 一、 所有的store 使用同一个store_id，这样 在zk上仍然是一个逻辑store node, 注册到zk上时节点只是把自己的IP作为一个数据portal增加上去。 这个方法好处是pfconductor不需要做任何的改动，看到的视图和原来完全一样。 坏处在于： 1） 掩盖了多个物理节点的实际情况 2） 无法支持每个节点私有数据盘

二、保持每个store ID唯一，允许共享盘出现在多个store 下面

• 为表示区别，要标识这个盘是shared。 这个方法和现有的注册机制最相似。但是conductor需要处理重复出现的盘。原来disk uuid在metadb里面是不允许重复的，现在出现了重复。conductor的处理原则： 1) conductor从zk上发现shared disk时，检查这个盘是否已经在t_tray表里被其他store拥有，如果是的话，不在创建新的t_tray记录，而是将新的store做为这个盘的共同拥有人加入到coowner字段。 2) coowner字段是t_tray表新增加的 这个方法的缺点是无法清晰呈现盘和节点的关系，

三、 为共享盘建立独立的注册管理体系

• 在zk上创建这样的结构：

  /cluster1/shared_disks/
                  + <disk1_uuid>
                         + stores
                         |   + <store1_id>
                         |    |   + dev_name := <device name, e.g. /dev/sdd>
                         |   + <store2_id>
                         |       + dev_name  := <device name>
                         + owner_store
                                  + <ephemeral_node1 := store_id>
                                  + <ephemeral_node2 := store_id>

  这样共享盘成为独立的一套信息，在metadb里面也为其创建单独的t_shared_disk表，而不是共享原来的t_tray表。 从代码结构上，这样做对原来的代码影响小，不容易引入bug。共享盘的代码独立于原来的代码，包括创建shard时的选盘逻辑，共享盘和原来的逻辑完全分开。 这里顺便也解决了共享盘的Owner问题，只有owner store可以修改这个盘的元数据。

只有单副本的shard可以选择共享盘作为承载盘。

[cocalele]

done in commit: a8046fb