节点服务器

MySQL的高可用(MHA) MHA简介 MHA:Master High Availability,对主节点进行监控，可实现自动故障转移至其他从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主二从，即一台充当master，一台充当备用master，另外一台充当从数据库，出于机器成本的考虑，淘宝进行了改造，目前淘宝TMHA已经一主一从。 MHA架构 MHA的工作原理 MHA是由一台manager服务器远程监控主服务器,当主服务器挂了提升一台从服务器作为主服务器。 当主节点挂了，manager首先要查看哪台从节点，同步的数据最多，然后提升同步最多的从节点为主节点，再将其余的MySQL服务器对他做从节点。 如果原主节点没彻底死透，manager会让新的主机通过ssh协议远程连接到原先的主节点，拉取二进制日志进行同步。如果主节死透了那就放弃。　　 MHA搭建 环境准备 一、准备4台主机，管理节点1台，主节点MySQL服务器1台，从节点MySQL服务器2台 主机 IP Manager 192.168.73.111 Master 192.168.73.110 Slave1 192.168.73.112 Slave2 192.168.73.113 二、将Manager管理节点配置为时间服务器，向所有MySQL服务器提供时间同步。 1

1、引言 关于“负载均衡”的解释，百度词条里：负载均衡，英文叫Load Balance，意思就是将请求或者数据分摊到多个操作单元上进行执行，共同完成工作任务。 负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 负载均衡有两方面的含义： 1）首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间； 2）其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 简单来说就是： 1）其一是将大量的并发处理转发给后端多个节点处理，减少工作响应时间； 2）其二是将单个繁重的工作转发给后端多个节点处理，处理完再返回给负载均衡中心，再返回给用户。 目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。 总之，它的目的就通过调度集群，达到最佳化资源使用，最大化吞吐率，最小化响应时间，避免单点过载的问题。 内容概述：本文将从负载均衡技术的分类、技术原理、常见实现算法、常用方案等入手，为您详细讲解负载均衡技术的方方面面。这其中，四层和七层负载均衡技术最为常用，它们也是本文介绍的重点。 内容点评

在之前的一篇文章已经介绍了 Redis Cluster及其部署 ，下面说下Redis Cluster日常操作命令： 一、以下命令是Redis Cluster集群所独有的，执行下面命令需要先登录redis： [root@manage redis]# redis-cli -c -p 6382 -h 192.168.10.12 （客户端命令：redis-cli -c -p port -h ip） 192.168.10.12:6382> 登录redis后，在里面可以进行下面命令操作 集群 cluster info ：打印集群的信息 cluster nodes ：列出集群当前已知的所有节点（ node），以及这些节点的相关信息。 节点 cluster meet <ip> <port> ：将 ip 和 port 所指定的节点添加到集群当中，让它成为集群的一份子。 cluster forget <node_id> ：从集群中移除 node_id 指定的节点。 cluster replicate <master_node_id> ：将当前从节点设置为 node_id 指定的master节点的slave节点。只能针对slave节点操作。 cluster saveconfig ：将节点的配置文件保存到硬盘里面。 槽(slot) cluster addslots <slot> [slot ...]

mongodb是最常用的noSql数据库，在数据库排名中已经上升到了前五。这篇文章介绍如何搭建高可用的mongodb（分片+副本）集群。 在搭建集群之前，需要首先了解几个概念：路由，分片、副本集、配置服务器等。 相关概念 mongodb集群架构图： 从图中可以看到有四个组件：mongos、config server、shard、replica set。 mongos，数据库集群请求的入口，所有的请求都通过mongos进行协调，不需要在应用程序添加一个路由选择器，mongos自己就是一个请求分发中心，它负责把对应的数据请求请求转发到对应的shard服务器上。在生产环境通常有多mongos作为请求的入口，防止其中一个挂掉所有的mongodb请求都没有办法操作。 config server，顾名思义为配置服务器，存储所有数据库元信息（路由、分片）的配置。mongos本身没有物理存储分片服务器和数据路由信息，只是缓存在内存里，配置服务器则实际存储这些数据。mongos第一次启动或者关掉重启就会从 config server 加载配置信息，以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态，这样 mongos 就能继续准确路由。在生产环境通常有多个 config server 配置服务器，因为它存储了分片路由的元数据，防止数据丢失！ shard，分片（sharding

1. Zookeeper 概念简介： Zookeeper 是一个分布式 协调服务；就是为用户的分布式应用程序提供协调服务 A、zookeeper 是为别的分布式程序服务的 B、Zookeeper本身就是一个分布式程序 （只要有半数以上节点存活， zk 就能正常服务） C、Zookeeper 所提供的服务涵盖：主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统一名称服务…… D、 虽然说可以提供各种服务，但是 zookeeper 在底层其实只提供了两个功能： 管理 ( 存储，读取 ) 用户程序提交的数据； 并为用户程序提供数据节点监听服务； Zookeeper 集群的角色： Leader 和 follower （ Observer ） 只要集群中有半数以上节点存活，集群就能提供服务 zookeeper 集群机制 半数机制：集群中半数以上机器存活，集群可用。 zookeeper 适合装在 奇数台机器上！！！ 安装 1.虚拟机准备 安装到 3 台虚拟机上 安装好JDK 2. 解压 su – hadoop （切换到 hadoop 用户） tar -zxvf zookeeper-3.4.5.tar.gz（解压） 3. 修改环境变量 1 、 su – root( 切换用户到 root) 2 、 vi /etc/profile( 修改文件 ) 3 、添加内容： export

原文链接：https://blog.csdn.net/qq_35902689/article/details/78113317 Eureka的优势 1、 在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。（多个zookeeper之间网络出现问题,造成出现多个leader，发生脑裂）当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。 2、 正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在Eureka中注册的服务，它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围（这点有点像ZooKeeper的做法）。这是个很好的功能

Kippo是一个中等交互的SSH蜜罐，提供了一个可供攻击者操作的shell，攻击者可以通过SSH登录蜜罐，并做一些常见的命令操作。 当攻击者拿下一台服务器的权限后，很可能会进行小范围的端口探测或者批量的端口扫描，以便横向扩展，获取更多服务器的控制权，因此部署内网SSH蜜罐，把攻击者引诱到蜜罐里来，触发实时告警，即可让安全人员及时知道已经有攻击者渗透内网、知道哪台服务器已被控制、以及攻击者在蜜罐上做了哪些操作。 如何把攻击者引诱到蜜罐里来，除了要看蜜罐是否具备主动欺骗能力外，还要看蜜罐在公司网络中的部署密度。网络安全域通常会要求不同的网段是隔离的，而且攻击者很可能是先在同一网段进行扫描，不会上来就扫描全网。所以如果只有一台蜜罐服务器，攻击者的扫描行为很可能不会触碰到蜜罐，也就不会触发蜜罐告警，所以理想情况是在所有网段均部署诱捕节点，但如果都用服务器部署的话，又太浪费资源，所以我们通过端口转发的方式，利用虚拟机、虚拟vlan网卡、现有服务器等方式来充当诱捕节点。 一、蜜罐架构图 二、蜜罐的搭建 1、Kippo 1.1 Kippo的安装 GitHub地址：https://github.com/desaster/kippo 安装环境：centos7 为确保蜜罐服务器的安全，建议在windows服务器上安装vmware，然后安装centos。 下载代码、安装相关的依赖 复制代码 1 git

本片文章主要是关于使用Kettle的UI界面： Spoon来实现基于集群的对数据库中的数据表数据进行排序的试验。 以及在实验过程中所要开启的Carte服务的一些配置文件的设置， 还有基于Windows cmd 的相关Carte命令。 文章主要分为六个部分： 1.介绍carte 　　 2.carte相关配置文件的设定 3.carte服务的开启命令 4.在kettle的图形界面中对集群进行相关的设定 　　 5.使用kettle集群模式对相关的数据进行排序 6.有关于集群调用子服务器的java源代码调用实现 1.介绍carte carte是由kettle所提供的web server的程序， carte也被叫做子服务器（slave） 在kettle调用集群（cluster）来进行分布式分发、处理任务的时候， 可以开启多个carte服务进程 来进行分发ETL（master）任务和接收，运行，提交ETL任务（slave）。 就像是《pentaho kettle solutions》中对Carte的定义： "Carte a lightweight server process allows for remote monitoring and enables the transformation clustering capabilities ". "Carte是一个轻量级的服务器进程

一、资料文档 Kafka：中。有kafka作者自己写的书，网上资料也有一些。rabbitmq：多。有一些不错的书，网上资料多。zeromq：少。没有专门写zeromq的书，网上的资料多是一些代码的实现和简单介绍。rocketmq：少。没有专门写rocketmq的书，网上的资料良莠不齐，官方文档很简洁，但是对技术细节没有过多的描述。activemq：多。没有专门写activemq的书，网上资料多。 二、开发语言 Kafka：Scala rabbitmq：Erlang zeromq：c rocketmq：java activemq：java 三、支持的协议 Kafka：自己定义的一套…（基于TCP） rabbitmq：AMQP zeromq：TCP、UDP rocketmq：自己定义的一套… activemq：OpenWire、STOMP、REST、XMPP、AMQP 四、消息存储 Kafka：内存、磁盘、数据库。支持大量堆积。 kafka的最小存储单元是分区，一个topic包含多个分区，kafka创建主题时，这些分区会被分配在多个服务器上，通常一个broker一台服务器。分区首领会均匀地分布在不同的服务器上，分区副本也会均匀的分布在不同的服务器上，确保负载均衡和高可用性，当新的broker加入集群的时候，部分副本会被移动到新的broker上。根据配置文件中的目录清单

一.哨兵机制 任务： 　　有了主从复制的实现以后，如果想对主服务器进行监控，那么在redis2.6以后提供了一个"哨兵"的机制。顾名思义， 哨兵的含义就是监控redis系统的运行状态 。可以启动多个哨兵，去监控redis数据库的运行状态。其主要功能有两点: 　　a、监控所有节点数据库是否在正常运行。 　　b、master数据库出现故障时，可以自动通过投票机制，从slave节点中选举新的master，实现将从数据库转换为主数据库的自动切换。 　　一个一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健。此时，不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会相互监控。在这里，建议大家哨兵至少部署3个，并且使用奇数个哨兵。 　　Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务: a、 监控 (Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。 b、 提醒 (Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。 c、 自动故障迁移 (Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作