目录
声明
摘要
多节点集群
参考文献
声明
官网的文档一直在变化,可能翻译时的文档跟目前文档有出入,请以官网文档为准。
摘要
集群是使多个进程和程序作为一个整体工作的机制。举例,当在google.com网站上查询资料时,查询请求好像只有一台web服务器在处理。实际上,查询请求是被一个集群中多台相互连接的web服务器处理的。类似地,OpenDaylight也可以有多个实例作为一个整体对外提供服务。
集群的优势:
- 可伸缩性:如果有多个OpenDaylight实例在运行,一般情况下比仅有一台实例会做更多的任务和存储更多的数据。也可以把数据分解成块(片),然后把数据散布到整个集群,或者在集群中的某个实例执行某个操作。
高可用性:如果有多个OpenDaylight实例在运行,其中一个实例宕机,其它实例仍然可以工作和提供服务。
数据持久化:手动重启或者宕机,不会丢失存储在OpenDaylight的任何数据.
下面这部分描述如何搭建集群。
多节点点集群
以下部分描述了如何用OpenDaylight搭建多节点集群。
部署注意事项
实现集群,需要注意如下事项:
推荐最少3台机子来搭建多节点集群。也可以搭建只有两个节点的集群。但是,如果2台中有一台宕机,则集群就不可用。
注意:这是因为OpenDaylight要求大部分节点需要运行,而一个节点显然不能称作是大部分节点。
集群中的每个实例都需要有一个标识符。OpenDaylight通过使用节点role来达到这个目的。当在akka.conf文件中定义第一个节点的role为member-1时,OpenDaylight就使用member-1来标识该节点。
数据片(译注:这个概念对于文章理解很重要,请查看wiki Share)用于存储OpenDaylight MD-SAL数据库所有数据或者某个片段的数据。例如,一个数据片可以存储所有的inventory数据,而另外一个数据片可以存储所有的topology数据。
如果没有在modules.conf文件中指定一个module,且在module-shards.conf文件中也没有指定一个分片。默认所有的数据存放在default数据片中(该default分片必须在module-shares.conf文件预先定义好)。每个分片都有一个可配置的replicas。在module-shares.conf中可以指定replicas详情,replicas表示分片位于哪个节点(译注:比如memeber-1,memeber-2)。
如果有一个3节点的集群,想要能够容忍任意节点的宕机,那么每个数据片的副本必须运行在3节点的集群上。(译注:意思是如果想在集群中某台机子宕机的情况下还能正常服务,没有数据缺失,那么你必须把每一个数据片复制到3个节点上)
注意:这是因为OpenDaylight的集群实现要求大部分数据片都运行才能提供服务。如果只在集群中的2个节点定义数据片副本(译注:即该数据片只有两个复制)且其中一个节点宕机,相应的该数据片无法运作(译注:一个数据片无法成为大部分。虽然还有一个节点正常运行,但是也不运行的意思)
如果有3个节点的集群且某个数据片在所有节点上定义副本,即使该集群只剩下两个节点在运行,该数据片仍然能够运行。注意如果剩下的两个节点又宕机一个,则该数据片将不可操作。
推荐配置多个节点。集群中的某个节点启动,它会发送一个消息给所有的节点。然后该节点会发送一个加入命令给第一个响应它的节点。如果没有节点回应,该节点重复这个过程直到成功建立一个连接或者自己关闭这个过程。
集群中某个节点持续一段时间(默认10秒,可配置)还是不可达后(译注:不能连接),该节点自动下线。一旦节点下线,你需要重新启动它才能再次加入集群。一旦重新启动的节点加入集群,它将自动从主节点同步数据。
集群脚本
OpenDaylight包含一些用于配置集群的脚本。
注意:脚本是位于OpenDaylight distribution/bin 目录下,该脚本在仓库的位置是distribution-karaf/src/main/assembly/bin/
使用集群脚本
这个脚本被用于设置控制器集群中某个节点的集群参数(指akka.conf,module-shares.conf中的参数)。用户重启节点才能生效设置的参数。
注意:这个脚本可以在任意时刻使用,甚至在控制器第一次被启动之前。
用法:
bin/configure_cluster.sh <index> <seed_nodes_list>
index:1..N之间的整数,N是节点的数量。这个表示脚本配置的是哪一个控制器节点。
seed_nodes_list:集群中所有节点组成的ip地址列表,用逗号或者空格分隔。
index指向的IP地址应该是正在执行脚本的节点的ip地址。当在多个节点运行这个脚本时,保证seed_node_list这个参数值一样,而index在1到N之间改变。
可选,数据片可以通过修改“custom_shard_configs.txt”文件,在更多粒度进行配置,该文件和该脚本在同一个目录下。想要更多信息可以查看此文件。
举例:
bin/configure_cluster.sh 2 192.168.0.1 192.168.0.2 192.168.0.3
上面的命令将配置节点2(ip地址192.168.0.2),该节点位于由192.168.0.1 192.168.0.2 192.168.0.3三台机子组成的集群中
搭建多节点集群
译注:这里需要注意一下步骤顺序,第10个步骤需要移到第2个步骤的下面进行,不然你将找不到第3步所说的配置文件。即你需要先启动karaf,然后运行feature:install odl-mdsal-clustering,退出karaf命令行界面后,在继续进行下面的步骤。
为了运行3节点集群的OpenDaylight,执行如下步骤:
首先选择3台机子用于搭建集群。之后在每台机子下做如下操作:
1.拷贝OpenDaylight发布文件zip(译注:linux为tar.bz2)到机子上。
2.解压发布版本文件。
3.打开下面的.conf文件:
configuration/initial/akka.conf configuration/initial/module-shards.conf
4.每个配置文件做如下修改(译注:这里说的是akka.conf这个文件):
每个文件找到如下行的情况,然后用该配置文件所在机子即OpenDaylight运行所在机子的主机名或者ip地址替换127.0.0.1:
netty.tcp { hostname = "127.0.0.1"
注意:对于集群中的每个节点该值是不一样的。
5.找到如下所示的行,然后用集群中的所有节点的机子的主机名或ip地址替换127.0.0.1(译注:这里的意思是集群有几个节点,数组中就有几个记录,只是ip做相应的修改):
cluster { seed-nodes = ["akka.tcp://opendaylight-cluster-data@127.0.0.1:2550"]
6.找到如下部分,给每一个节点指定一个角色名。这里我们用member-1赋值给第一个节点,第二节点用member-2,第三个节点用member-3:
roles = [ "member-1" ]
注意:这个步骤,在每个节点应该使用不同的节点名。
7.打开configuration/initial/module-shards.conf文件,修改replicas属性,让每一个数据片复制到所有的节点
replicas = [ "member-1", "member-2", "member-3" ]
仅供参考,可以查看下面给出的==配置文件示例==
8.切换到/bin目录下。
9.运行如下命令:
JAVA_MAX_MEM=4G JAVA_MAX_PERM_MEM=512m ./karaf
10.在karaf命令行中运行如下命令启用集群功能(译注:这步移到第三步)
feature:install odl-mdsal-clustering
OpenDaylight此时应该运行在3个节点的集群上。你可以通过任意的节点访问存储在数据库中的数据。
配置文件示例
==akka.conf== 示例文件:
odl-cluster-data {
bounded-mailbox {
mailbox-type = "org.opendaylight.controller.cluster.common.actor.MeteredBoundedMailbox"
mailbox-capacity = 1000
mailbox-push-timeout-time = 100ms
}
metric-capture-enabled = true
akka {
loglevel = "DEBUG"
loggers = ["akka.event.slf4j.Slf4jLogger"]
actor {
provider = "akka.cluster.ClusterActorRefProvider"
serializers {
java = "akka.serialization.JavaSerializer"
proto = "akka.remote.serialization.ProtobufSerializer"
}
serialization-bindings {
"com.google.protobuf.Message" = proto
}
}
remote {
log-remote-lifecycle-events = off
netty.tcp {
hostname = "10.194.189.96"
port = 2550
maximum-frame-size = 419430400
send-buffer-size = 52428800
receive-buffer-size = 52428800
}
}
cluster {
seed-nodes = ["akka.tcp://opendaylight-cluster-data@10.194.189.96:2550",
"akka.tcp://opendaylight-cluster-data@10.194.189.98:2550",
"akka.tcp://opendaylight-cluster-data@10.194.189.101:2550"]
auto-down-unreachable-after = 10s
roles = [
"member-2"
]
}
}
}
odl-cluster-rpc {
bounded-mailbox {
mailbox-type = "org.opendaylight.controller.cluster.common.actor.MeteredBoundedMailbox"
mailbox-capacity = 1000
mailbox-push-timeout-time = 100ms
}
metric-capture-enabled = true
akka {
loglevel = "INFO"
loggers = ["akka.event.slf4j.Slf4jLogger"]
actor {
provider = "akka.cluster.ClusterActorRefProvider"
}
remote {
log-remote-lifecycle-events = off
netty.tcp {
hostname = "10.194.189.96"
port = 2551
}
}
cluster {
seed-nodes = ["akka.tcp://opendaylight-cluster-rpc@10.194.189.96:2551"]
auto-down-unreachable-after = 10s
}
}
}
==module-shards.conf== 示例文件:
module-shards = [
{
name = "default"
shards = [
{
name="default"
replicas = [
"member-1",
"member-2",
"member-3"
]
}
]
},
{
name = "topology"
shards = [
{
name="topology"
replicas = [
"member-1",
"member-2",
"member-3"
]
}
]
},
{
name = "inventory"
shards = [
{
name="inventory"
replicas = [
"member-1",
"member-2",
"member-3"
]
}
]
},
{
name = "toaster"
shards = [
{
name="toaster"
replicas = [
"member-1",
"member-2",
"member-3"
]
}
]
}
]
集群监控
OpenDaylight通过MBeans暴露数据片信息,可以通过JConsole,VisualVM或者其他JMX客户端来查看数据片信息,也可以通过使用Jolokia的REST API来暴露数据片信息,该API是安装karaf feature ==odl-jolokia==组件才有。
列出所有的可用的MBeans方案的URI:
GET /jolokia/list
使用下面REST,查询OpenDaylight实例的本地数据片信息。
比如config数据库信息:
GET /jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config
比如operational数据库信息:
GET /jolokia/read/org.opendaylight.controller:type=DistributedOperationalDatastore,Category=ShardManager,name=shard-manager-operational
以下输出显示了该节点数据片信息:
{
"request": {
"mbean": "org.opendaylight.controller:Category=ShardManager,name=shard-manager-operational,type=DistributedOperationalDatastore",
"type": "read"
},
"value": {
"LocalShards": [
"member-1-shard-default-operational",
"member-1-shard-entity-ownership-operational",
"member-1-shard-topology-operational",
"member-1-shard-inventory-operational",
"member-1-shard-toaster-operational"
],
"SyncStatus": true,
"MemberName": "member-1"
},
"timestamp": 1483738005,
"status": 200
}
当需要进一步的查看来自“LocalShards”列表中的某个分片信息,可以把该分片的完整名称当作URI的一部分,来查询该分片的详细信息。如下是member-1-shard-default-operational信息输出的例子:
{
"request": {
"mbean": "org.opendaylight.controller:Category=Shards,name=member-1-shard-default-operational,type=DistributedOperationalDatastore",
"type": "read"
},
"value": {
"ReadWriteTransactionCount": 0,
"SnapshotIndex": 4,
"InMemoryJournalLogSize": 1,
"ReplicatedToAllIndex": 4,
"Leader": "member-1-shard-default-operational",
"LastIndex": 5,
"RaftState": "Leader",
"LastCommittedTransactionTime": "2017-01-06 13:19:00.135",
"LastApplied": 5,
"LastLeadershipChangeTime": "2017-01-06 13:18:37.605",
"LastLogIndex": 5,
"PeerAddresses": "member-3-shard-default-operational: akka.tcp://opendaylight-cluster-data@192.168.16.3:2550/user/shardmanager-operational/member-3-shard-default-operational, member-2-shard-default-operational: akka.tcp://opendaylight-cluster-data@192.168.16.2:2550/user/shardmanager-operational/member-2-shard-default-operational",
"WriteOnlyTransactionCount": 0,
"FollowerInitialSyncStatus": false,
"FollowerInfo": [
{
"timeSinceLastActivity": "00:00:00.320",
"active": true,
"matchIndex": 5,
"voting": true,
"id": "member-3-shard-default-operational",
"nextIndex": 6
},
{
"timeSinceLastActivity": "00:00:00.320",
"active": true,
"matchIndex": 5,
"voting": true,
"id": "member-2-shard-default-operational",
"nextIndex": 6
}
],
"FailedReadTransactionsCount": 0,
"StatRetrievalTime": "810.5 μs",
"Voting": true,
"CurrentTerm": 1,
"LastTerm": 1,
"FailedTransactionsCount": 0,
"PendingTxCommitQueueSize": 0,
"VotedFor": "member-1-shard-default-operational",
"SnapshotCaptureInitiated": false,
"CommittedTransactionsCount": 6,
"TxCohortCacheSize": 0,
"PeerVotingStates": "member-3-shard-default-operational: true, member-2-shard-default-operational: true",
"LastLogTerm": 1,
"StatRetrievalError": null,
"CommitIndex": 5,
"SnapshotTerm": 1,
"AbortTransactionsCount": 0,
"ReadOnlyTransactionCount": 0,
"ShardName": "member-1-shard-default-operational",
"LeadershipChangeCount": 1,
"InMemoryJournalDataSize": 450
},
"timestamp": 1483740350,
"status": 200
}
输出信息标识分片状态(主/从,投票中/非投票中)、同级节点信息、从节点信息,分片是否是主节点、其他统计信息和计数信息。
集成团队正在维护一个基于Python开发的工具,这个工具通过Jolokia组件,使用了上文提到MBeans暴露的接口,且systemmetrics项目也提供了一个基于DLUX UI来显示相同的信息。
空间分布式的active/backup设置
节点之间的延迟时间最小的时候OpenDaylight集群工作在最佳状态,实践表明它们应该在同一个数据中心(译注:指在同一个机房)。但是假设所有节点宕机,能够在不同的数据中心实现故障转移更满足需求。为了获的这种效果,在不影响主数据中心节点(译注:这里应该是主数据中心,即同一个机房的所有节点)的延迟时间的方法下,集群可以通过在不同数据中心扩展节点的方式来达到目的。如果这样做,备份数据中心节点必须处在“non-voting” 状态。
在controller项目cluster-admin.yang中定义了一个RPCs,用于修改分片的voting状态的API;该API已经很好地被文档化。该API的概要如下:
注意:除非另外指出,下面的POST请求都被发送到集群中的任意一个节点。
创建一个6个节点集群的active/backup设置(分别位于两个机房,3个活跃和3个备份节点)。这里有一个RPC可以根据给定状态设置指定节点中的所有分片的投票状态:
POST /restconf/operations/cluster-admin:change-member-voting-states-for-all-shards
这个RPC需要一个节点列表和期望的投票状态作为输入。为了创建备份节点,如下输入示例可以被使用:
{
"input": {
"member-voting-state": [
{
"member-name": "member-4",
"voting": false
},
{
"member-name": "member-5",
"voting": false
},
{
"member-name": "member-6",
"voting": false
}
]
}
}
当一个active/backup部署存在时,且备份节点处于non-voting状态,这些被用于从active子集群到backup子集群的故障转移的分片将翻转每一个分片(包含每一个节点,活跃和备份)的投票状态。通过下面的RPC调用可以很容易实现这个过程(无需参数):
POST /restconf/operations/cluster-admin:flip-member-voting-states-for-all-shards
如果是主投票节点(译注:这里应该指的是active数据中心机房)因意外断电导致宕机,“flip” RPC请求必须被发送到某个非投票状态的备份节点(译注:backup数据中心机房的某个节点)。这种情况下,没有分片进行投票选举。但是这里有一个特例,如果收到RPC请求的这个节点处在non-voting状态,且即将改变为voting状态,且没有主节点,则这个节点将状态改为voting并尝试成为主节点。如果成功,该节点保存状态并复制这些变动信息给其余的节点。
当主中心被修复且你想要自动恢复到之前状态,你必须谨慎对待主中心的恢复。因为次级中心的投票状态被翻转的时候,主中心是处于下线状态,主中心的数据库并没有保存这些变化。如果主中心在这种状态被恢复,主中心的节点将仍然处于投票状态。如果主中心节点连接到次级中心,它们找出次级中心的主节点并同步。但是如果没有发生这种情况,主中心将可能选举出它们自己的主节点,从而被分割出2个集群,这种情况会导致不可预测的结果。因此推荐在恢复主中心时,先清除主中心节点数据库数据(例如,日志和快照目录)。另外一种选择是从次级中心一个最新备份中恢复主中心的数据(详情查阅Backing Up and Restoring the Datastore)
如果想要从集群中温和的移除一个节点也是可以的,查看如下RPC API:
POST /restconf/operations/cluster-admin:remove-all-shard-replicas
请求的示例数据:
{
"input": {
"member-name": "member-1"
}
}
或者仅仅是移除一个特定的分片:
POST /restconf/operations/cluster-admin:remove-shard-replica
请求的实例数据:
{
"input": {
"shard-name": "default",
"member-name": "member-2",
"data-store-type": "config"
}
}
注意在运行时某个故障节点被移除,也可以添加一个新的节点,不用修改正常节点的配置文件(需要重启)。
POST /restconf/operations/cluster-admin:add-replicas-for-all-shards
该请求不需要任何请求数据,但是这个RPC需要被发送到新的节点,指示该节点去集群中复制所有分片数据。
注意
虽然集群admin API允许动态地添加和移除分片,但是module-shard.conf和modules.conf文件仍然使用启动时定义的初始化配置。使用API修改并不会存储到这些静态文件中,但是会存到journal中。