【6.2.1】服务器安装 Docker Swarm中搭建 Redis集群

>Servers1和Server2作为实际配置MySQL集群的服务器。
对于作为管理节点的Server3则要求较低，只需对Server3的系统进行很小的调整并且无需安装MySQL，Server3可以使用一台配置较低的计算机并且可以在Server3同时运行其他服务。

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。
将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。
当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。
什么是Microsoft集群服务器
MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。
这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。
MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。
在集群服务器上的SQL Server
SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。
SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”
注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。
单个的大的SQL Server集群还是小的集群
下面是大的、由更多的节点组成的集群的优点：
◆更高的可用新(更多的节点来灾难恢复)。
◆更多的负载均衡选择(更多的节点)。
◆更低廉的维护成本。
◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。
◆增强的管理性和简化环境(需要管理的少了)。
◆更少的停机时间(灾难恢复更多的选择)。
◆灾难恢复性能不受集群中的节点数目影响。
下面是单个大的集群的缺点：
◆集群节点数目有限(如果需要第9个节点怎么办)。
◆在集群中SQL实例数目有限。
◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。
◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。
虚拟化和集群
虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。
在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。
集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

安装方式有两种选择： 安装在物理机，安装在虚拟机 图中你这种是几乎不可能成功的 安装在物理机，需要准备一个至少8G的U盘 将镜像不要解压，用U盘制作工具写入镜像到U盘 插上物理机，开机选择从U盘启动 然后按照提示一步步安装即可 第二种是安装

在单个物理服务器上运行2个或多个Percona XtraDB Cluster(PXC)节点这样没有什么意义，除了教育和测试目的,但在这种情况下这样做仍然是有用的。最受欢迎的实现方式似乎是服务器的虚拟化,比如利用流浪盒子。但是同样的方式你可以运行多个MySQL实例在并行 *** 作系统级别上，还有并发的mysqld的形成过程,因此你也可以有多个Percona XtraDB Cluster节点。而且实现这一目标的方法是恰恰相同的:使用专用的datadirs和为每个节点设置不同的端口。

参考我之前的文章即可（ >  提取码: gd8t

这一步主要参考官网的步骤，具体如下：

创建 /etc/yumreposd/rabbitmq_erlangrepo 文件，内容如下：

安装erlang

221 导入mq签名

222 添加rabbitmqrepo文件-此处可参看官网（ >

），我这边服务器是centos7，故rabbitmqrepo写入如下内容：

223 安装rabbitmq服务

224 启动服务并设置开机自启动

225 开启管理界面

这一点 方便我们通过url访问查看运行情况，阿里云服务器安全里一定要开启15672端口

在此我们还需要新增一个用户作为管理员

添加用户 -用户名 密码自己定

修改用户角色为管理员- 把下面username改成自己的用户名

修改用户权限

自此 你可以通过ip:15672的方式访问RabbitMQ后台

目前我是有两台阿里云的，同一区的服务器，内网可访问。

231 修改hostname -服务器别名，方便我们后面两个mq服务连接

vi /etc/hosts  新增node1和node2 两个内网ip

原以为OK了，重启还是老样子，其实centos7 还提供了一步方法

直接修改成功了！

232 Erlang cookie设置，这里最坑，困了我好久，有必要总结一下

确保node1与node2两个服务器的erlangcookie保持一致

找到node1服务器的erlangcookie，位置如下：

/var/lib/rabbitmq/erlangcookie

然后复制内容到node2服务器对应的erlangcookie

修改好后，记得还原权限400

修改完后 一定要重启node1与node2服务器，这样修改才能生效。之前一直困扰我的node2连接不上node1的mq服务，一直提示cookie有问题，重启mq服务也没用，重启服务器 reboot后问题就可以解决，切莫少了这步。

出现的问题如下：

TCP connection succeeded but Erlang distribution failed

Authentication failed (rejected by the remote node), please check the Erlang cookie

那就执行重启命令吧！一切解决！

233 加入mq集群

node1 mq服务设置后台执行

可以查看目前 node1的mq状态

node2 加入node1的MQ集群，关键时刻了！

配置好MQ集群后，可以在 node1、node2服务器上任意执行 rabbitmqctl cluster_status 来查看MQ集群是否配置成功

如下图所示：

这里就彻底成功了！现在直接通过url访问看一下是否正常可以显示两个mq服务：

---