failover swarm 故障转移

#故障转移 Failover

#当其中一个节点关闭宕机时,其节点中的service会转移到另一个节点上。
Swarm会检测到node1发生故障并把此故障节点的状态标记为Down; docker node ls 可查看 node1的STATUS 为Down
同时 Swarm会把node1上的service调度到其它有资源的节点上来运行;docker service ps web_server 可查看其过程和状态

#访问server

#便于分析,重新部署一个
docker service create --name=htdocs_nginx --replicas=3 nginx
docker service ps htdocs_nginx 可查看副本数
--replicas可直接指定副本数 ,不需要再用docker scale命令

#现在我们要访问server
在以上操作中,我们每个节点都有运行service, node1、node2、node3 容器里是监听80端口的,但我们并没有映射端口到Host,所以要进行以下操作

#进入容器查看:
docker exec 容器ID /bin/sh 也可使用 /bin/bash
容器IP 为172.12.0.5, 实际上连接的是Docker的bridge网络
crul 172.12.0.5 可以访问
但是这是在容器内部,需要实现在外部也可访问,也就时暴露80端口

#外部访问
docker service update --publish-add 80:80 htdocs_nginx
这样就映射端口了,外部也可访问。
当然新建service时也可直接指定
docker service create --name htdocs_nginx --replicas=3 --publish-add 80:80 nginx

#routing mesh
我们访问每个节点的80端口都可以返回结果; swarm 内部的 load balancer 会将请求转发给 web_server 其中的一个副本。这就是 routing mesh 的作用。

注:当我们使用 --publish-add 80:80 时 swarm会重新配置副本,容器内的网络就会发生改变
器的网络与 --publish-add 之前已经大不一样了,现在有两块网卡,每块网卡连接不同的 Docker 网络。
实际上:

eth0 连接的是一个 overlay 类型的网络,名字为 ingress,其作用是让运行在不同主机上的容器可以相互通信。

eth1 连接的是一个 bridge 类型的网络,名字为 docker_gwbridge,其作用是让容器能够访问到外网。

ingress 网络是 swarm 创建时 Docker 为自动我们创建的,swarm 中的每个 node 都能使用 ingress。
通过 overlay 网络,主机与容器、容器与容器之间可以相互访问;同时,routing mesh 将外部请求路由到不同主机的容器,
从而实现了外部网络对 service 的访问。

#service与service通信 内部的
为了不暴露端口 增加安全性 ,我们可以用一下方法:
服务发现:
如果不 publish,那么 swarm 就要提供一种机制,能够:
让 service 通过简单的方法访问到其他 service。
当 service 副本的 IP 发生变化时,不会影响访问该 service 的其他 service。
当 service 的副本数发生变化时,不会影响访问该 service 的其他 service。
这其实就是服务发现(service discovery)。Docker Swarm 原生就提供了这项功能,通过服务发现,
service 的使用者不需要知道 service 运行在哪里,IP 是多少,有多少个副本,就能与 service 通信。

#创建overlay网络
docker network create --driver overlay app_net
docker network ls

#部署
docker service create --name my_web --replicas=5 --network app_net nginx
docker service create --name database --network app_net mysql

docker service ps database 查看容器 然后进入容器
docke exec 容器ID /bin/sh ping my_web 发现可通
同时ping所得到的my_webIP是VIP 虚拟IP ,swarm 会将对 VIP 的访问负载均衡到每一个副本。

原文地址:https://www.cnblogs.com/luoyan01/p/9734290.html

时间: 2024-10-13 15:07:20

failover swarm 故障转移的相关文章

MariaDB数据库介绍三、MHA(Master HA)实现主节点故障转移

一.MHA MHA是开源的MySQL的高可用程序,它为MySQL的主从复制架构提供了主节点故障自动转移的功能,它会监控master节点故障的时候,会提升其中的拥有最新数据的slave节点称为新的master节点,同时它还提供了master节点的在线切换的功能,按需切换master/slave节点. MHA服务有两种角色,MHA Manager和MHA Node: MHA Manager(管理节点):单独部署在一台独立机器上管理多个master/slave主从复制集群, 每个master/slav

第7章 性能和可靠性模式 Failover Cluster(故障转移群集)

上下文 您已经决定在设计或修改基础结构层时使用群集以提供高度可用的服务. 问题 您应该如何设计一个高度可用的基础结构层,来防止因单台服务器或它所运行的软件出现故障而导致的服务丢失? 影响因素 在设计高度可用的基础结构层时,请考虑下列影响因素: 硬件组件.应用程序或服务出现故障可以使应用程序无法使用或不可用. 例如,设想一台正在提供应用程序的服务器出现了电源故障. 如果这是唯一的服务器或服务器中的唯一电源,则存在故障单点,并且应用程序将不可用. 计划内的服务器停机时间可以影响应用程序的可用性. 例

部署AlwaysOn第一步:搭建Windows服务器故障转移集群

在Windows Server 2012 R2 DataCenter 环境中搭建集群之前,首先要对Windows服务器故障转移集群(Windows Server Failover Cluster,简称WSFC)有基本的了解.WSFC必须部署在域管理环境中,由多台服务器组成,每台服务器称作一个"结点"(Node),每个结点上都运行了Windows服务器故障转移集群服务,整个集群系统允许部分结点掉线.故障或损坏而不影响整个系统的正常运作.集群自动检测结点的健康状态,一旦活跃结点发生异常,变

修改故障转移群集心跳时间

Windows Server Failover Clustering is a high availability platform that is constantly monitoring the network connections and health of the nodes in a cluster.  If a node is not reachable over the network, then recovery action is taken to recover and

案例分享:数据库镜像故障转移失败

案例分享:数据库镜像故障转移失败 对于关键性数据库,我们配置了带有见证服务器的同步数据库镜像,来允许自动故障转移.一切运行正常,直到有一次数据中心的突然断电.数据库镜像执行了故障转移,但是运维反馈说应用程序挂起了.当我们手动切换回来,应用程序又正常工作.为什么应用程序没有也故障转移呢? 这是使用数据库镜像的合理的常见问题,像这样的生产应用失败,是因为在镜像部署后没有做故障转移测试.在失败的故障转移之后我们感到棘手. 为了避免生产应用停机,我们在测试环境复制了线上的镜像环境.在确认应用和数据库镜像

redis演练(7) redis Sentinel实现故障转移

书接上文<redis演练(6) redis主从模式搭建>. <redis演练(6) redis主从模式搭建>中仅仅配置了redis主从环境.分别配置了2个主从结构. 分别是1.有向无环,2星型模型.配置起来非常简单.但是,遗留了一个尾巴,没有阐述.如果master宕掉了怎么办?redis如何实现fail-over故障转移?本文,就重点说一下这块.主要内容 手动实现fail-over效果 sentinel实现自动fail-over效果 手动实现fail-over效果 #有向无环模型(

MySQL 高可用MHA安装部署以及故障转移详细资料汇总 转

http://blog.itpub.net/26230597/cid-87082-list-2/ 1,简介 1.1mha简介 MHA,即MasterHigh Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性. MHA(Master High Availability)是自动的master故障转移和Sl

SQL Server数据库镜像基于可用性组故障转移

SQL Server数据库镜像基于可用性组故障转移 微软从SQL Server 2005开始引入数据库镜像,很快成为一个流行的故障转移解决方案.数据库镜像的一个大的问题是故障转移是基于数据库级别的,因此,如果某个数据库故障,镜像只会针对这个数据库切换,但是,其他数据库都仍然在主服务器上.缺点是越来越多的应用程序是基于多个数据库来构建,所以,如果某一个数据库故障转移而其他数据库仍然在主服务器上,那应用程序将无法工作.当这种情况发生的时候,我如何知晓?并执行该应用程序调用的所有数据库一起故障转移呢?

MHA mysql主从故障转移

MHA 一.MHA介绍 1 二.部署MHA 2 1.部署MHA Node 2 2.安装MHA Manager 3 3.配置SSH登录无密码验证 3 4.搭建主从复制环境 3 5.配置MHA 4 6.检查SSH配置 8 7.检查SSH配置 8 8.检查MHA Manager状态 8 9.开启MHA Manager监控 8 10.关闭MHA Manager监控 8 11.MHA引入VIP 8 三.自动Failover 17 四.手动Failover(MHA Manager必须没有运行) 19 五.在