iserver集群实践——普通集群

最近在使用超图的iserver集群，相对来说，在设计理念上比较符合中国人的思维，毕竟是国产软件，相对来说比较灵活，配置也较为简单，但是里面有不少名词可能会让人感觉比较绕，这几天一直在倒腾他，总结一下相关的使用心得。

测试环境：

• 操作系统：Ubuntu 14.04 LTS/RedHat 6.5
• 服务器组件：iserver 7.1.2 in Ubuntu
• 数据库：Oracle 11.2.0.4、MongoDB 2.6.9  in Redhat 6.5

网络规划：

• 数据库节点：192.168.195.134
• iServer节点1：192.168.195.131
• iServer节点2：192.168.195.135
• iServer节点3：192.168.195.136
• iServer节点4：192.168.195.137

iServer集群拓扑图

iServer的集群介绍

打开iServer的manager的集群选项，我们查看集群概览，这个图已经将iServer的集群结构说明的非常清楚了，如果我们以131的iserver为例，本机就是iserver，131的iserver可以使用某个集群，也可以加入某个集群；

加入集群服务，如上拓扑图所示，我以135为主体集群服务器，将136、137iServer可以加入到该集群环境中，使三台集群可以组成一个iserver集群。

我们可以通过136、137的manger的加入集群的操作来加入135集群中。

添加完毕之后，我们可以在135机器的集群概览可以看到如下信息

使用集群服务，如上拓扑图所示，我将135、136、137三台iserver组成了一个集群环境（cluster A)，那么131的iserver可以使用ClusterA，而且系统会默认将131也纳入cluster A集群的一个子节点。

我们在131的manager里面，点击使用集群，选择135为主体的集群环境clusterA 

然后，我们再查看135的集群概览，看到131已经成为集群的一个子节点了

为什么有使用集群的设计思路？

当然，用户可以直接将服务发布到135的Cluster集群环境中，那么用户就可以访问135服务器，发送相关的http请求，这样135机器的负载在并发量大的情况下就显得压力比较大，它既要相应其他客户端的服务请求，又要兼顾集群的负载均衡，或者监控并发切图的运行状态等等。

所以，我们添加了131集群，131集群可以使用135的ClusterA集群，我们将服务及发布在131上，又发布在135上，131使用135的集群，那么用户服务访问可以直接访问131即可，这样会对135集群环境减轻压力，也就是说使用集群提到了一个服务请求转发的作用。

但是，如果使用使用集群，那么用户在发布服务既需要在转发服务器131上发布服务，也需要在集群主体服务135发布服务，这样才能达到服务转发，减轻135负载的效果，不然，只发布到131上，我们在135上可以看到该服务，但是该服务为无效状态。如果该服务需要其他集群子节点参与处理，其他子节点都需要发布相关服务。