高可用

k8s默认在控制平面节点上的kubelet管理的静态pod中运行单个成员的etcd集群，但这不是高可用的方案。 etcd高可用集群至少需要三个成员组成。 etcd默认端口为2379,2380，三个节点的这两个端口都要能通。 可以在kubeadm配置文件更改默认端口。 这个实验有五个服务器。 我开的腾讯云香港服务器做的实验，网速很快，ssh稳定。 百度云没测。 阿里云测试不给力。 推荐 腾讯云 。 k8s1: master1 k8s2: node1 k8s3: haproxy k8s4: master2 k8s5: master3 1.首先在k8s master1上安装kubeadm,kubelet,kubectl,然后kubeadm init,最后kubectl get nodes,确认k8s1 master1准备就绪。 k8s安装: ubuntu18安装kubernetes v1.15 2.分别在k8s node1,k8s master2，k8s master3上安装kubeadm,kubectl,kubelet k8s安装: ubuntu18安装kubernetes v1.15 3.在k8s master1上的kubeadm-init.out文件找到join worker node和 join control-plane node的命令。 4.分别在k8s

目前，为了使web能适应大规模的访问,需要实现应用的集群部署. 而实现集群部署首先要解决session的统一，即需要实现session的共享机制。 目前，在集群系统下实现session统一的有如下几种方案： (1) 应用服务器间的session复制共享（如tomcat session共享） (2) 基于cache DB缓存的session共享 应用服务器间的session复制共享 session复制共享，主要是指集群环境下，多台应用服务器之间同步session，使session保持一致，对外透明。 如果其中一台服务器发生故障，根据负载均衡的原理，web服务器（apache/nginx）会遍历寻找可用节点，分发请求，由于session已同步，故能保证用户的session信息不会丢失。 此方案的不足之处： 技术复杂,必须在同一种中间件之间完成(如:tomcat-tomcat之间). session复制带来的性能损失会快速增加.特别是当session中保存了较大的对象,而且对象变化较快时, 性能下降更加显著. 这种特性使得web应用的水平扩展受到了限制。 Session内容序列化（serialize），会消耗系统性能。 Session内容通过广播同步给成员，会造成网络流量瓶颈，即便是内网瓶颈。 基于cache DB缓存的session共享 即使用cacheDB存取session信息

为了搭建日志收集系统LEK，需要搭建一套Redis高可用集群，确保日志正常从各个应用服务器流转到ElasticSeach服务器，最终通过Kabana显示出来。Redis高可用集群采用redis自带的sentinel实现，具有主备和故障转移功能。 一、安装环境说明 两台机器：master(192.168.2.52),slave(192.168.2.53) 操作系统：CentOS 6.5 Redis：2.8.17，下载地址：http://download.redis.io/releases/redis-2.8.17.tar.gz 二、安装Redis 安装前准备 1、安装c++编译器 yum install gcc-c++ 2、安装依赖tcl yum install -y tcl 安装 1、下载 wget http://download.redis.io/releases/redis-2.8.17.tar.gz 2、解压 tar -zxvf redis-2.8.17.tar.gz 3、安装 先创建一个软链接，然后进入链接目录，安装。 ln -s redis-2.8.17 redis cd redis make install 安装完成之后，在/usr/local/bin目录下会出现redis相关的脚本文件（不包含redis-sentinel.sh）。如下图所示： 配置 1、创建相关目录

一.firewalld防火墙 1.firewalld简述 firewalld:防火墙，其实就是一个隔离工具：工作于主机或者网络的边缘。 对于进出本主机或者网络的报文根据事先定义好的网络规则做匹配检测， 对于能够被规则所匹配的报文做出相应处理的组件(这个组件可以是硬件，也可以是软件): 主机防火墙 网络防火墙 2.具体操作 (1).filter表 限制所有主机(0.0.0.0)拒绝ping本主机 iptables -t filter -A INPUT -s 0.0.0.0 -d 192.168.254.24 -p icmp -j REJECT 显示所有主机(0.0.0.0)拒绝通过ens33网卡ping本主机 　　 iptables -t filter -A INPUT -d 192.168.254.24 -i ens33 -p icmp -j REJECT (2).nat表 #源地址为192.168.250.0网段的ip地址经过防火墙都转换成192.168.31.100这个ip地址（SNAT:源地址转换） iptables -t nat -A POSTROUTING -s 192.168.250.0/24 ! -d 192.168.250.0/24 -j SNAT --to-source 192.168.31.100 #访问目标地址为192.168.31

介绍 在MySQL高可用架构中，目前使用比较多的是Percona的PXC，Galera以及MySQL 5.7之后的MGR等，其他的还有的 MHA ，今天介绍另一个比较好用的MySQL高可用复制管理工具： Orchestrator （orch）。 Orchestrator （orch）：go编写的MySQL高可用性和复制拓扑管理工具，支持复制拓扑结构的调整，自动故障转移和手动主从切换等。后端数据库 用MySQL或SQLite存储元数据，并提供Web界面展示MySQL复制的拓扑关系及状态，通过Web可更改MySQL实例的复制关系和部分配置信息，同时也提供命令行和api接口，方便运维管理。 相对比MHA来看最重要的是解决了管理节点的单点问题，其通过raft协议保证本身的高可用。GitHub的一部分管理也在用该工具进行管理。 关于 Orchestrator 更详细的介绍可以看Github的介绍，大致的特点有： ① 自动发现MySQL的复制拓扑，并且在web上展示。 ② 重构复制关系，可以在web进行拖图来进行复制关系变更。 ③ 检测主异常，并可以自动或手动恢复，通过Hooks进行自定义脚本。 ④ 支持命令行和web界面管理复制。 部署如下 试验环境 mysql服务器 orchestrator & master：10.72.16.112 slave1：10.72.16.50 slave2

一、问题描述 由于namenode 是HDFS的大脑，而这个大脑又是单点，如果大脑出现故障，则整个分布式存储系统就瘫痪了。HA（High Available）机制就是用来解决这样一个问题的。碰到这么个问题，首先本能的想到的就是冗余备份，备份的方式有很多种，前辈们设计的有元数据备份方案，secondary namenode以及avatarnode等方案。而这些方案中最有优势的自然是能够让HDFS以最短的时间完成故障切换的方案。也就是我们今天要讨论的avatarnode。 二、基本结构 primary：负责正常业务namenode，也就是为client提供元数据查询和操作。 standby：热备的namenode，完全备份primary的元数据，并对primary做checkpoint（一种元数据持久化机制，后面会介绍到）。 NFS：网络文件服务器，primary会将日志实时同步一份到该服务器，来保证primary出故障时备份元数据的完整性。 三、数据持久化机制——checkpoint primary管理着所有的元数据，通常元数据都保存在内存里，这样对元数据的访问能够高效。但是有个隐患，就是如果primary节点宕机了，或者掉电了，那么所有的元数据就一去不复返了。如果我们能够把元数据在内存里保存一份，同时在硬盘上也保存一份，那么即使掉电也能将数据再恢复过来。

前言 Kubernetes（k8s） 凭借着其优良的架构，灵活的扩展能力，丰富的应用编排模型，成为了容器编排领域的事实标准。越来越多的企业拥抱这一趋势，选择 k8s 作为容器化应用的基础设施，逐渐将自己的核心服务迁移到 k8s 之上。 可用性对基础设施而言至关重要。各大云计算厂商纷纷推出了高可用、可扩展的 k8s 托管服务，其中比较有代表性的有 Amazon EKS、Azure Kubernetes Service (AKS)、Google Kubernetes Engine、阿里云容器服务 Kubernetes 版等。 虽然公有云托管的 k8s 服务百花齐放，但很多企业仍有自建集群的需求。正是这样的原因，促进了一大批出色的 k8s 集群部署方案的诞生，他们的特点如下表所示。 上述方案中，RKE 在易用性和灵活性上占有优势。本文接下来将介绍如何通过 RKE 部署一套高可用 k8s 集群，文中使用的 RKE 版本为v0.2.2。 高可用 k8s 集群架构 首先需要了解高可用 k8s 集群的架构特点，下图是官方推荐的高可用集群架构图。 其核心思想是让 k8s master 节点中的各类组件具备高可用性，消除单点故障。 kube-apiserver - 对外暴露了 k8s API，是整个集群的访问入口。由于 apiserver 本身无状态，可以通过启动多个实例并结合负载均衡器实现高可用。

转自： https://www.cnblogs.com/jasontec/p/9699242.html 介绍：Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API的非关系型数据库。 传统数据库遵循 ACID 规则。而 Nosql（Not Only SQL 的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称） 一般为分布式而分布式一般遵循 CAP 定理。 Github 源码：https://github.com/antirez/redis Redis 官网：https://redis.io/ Redis支持的数据类型？ String字符串： 格式: set key value string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。 string类型是Redis最基本的数据类型，一个键最大能存储512MB。 Hash（哈希） 格式: hmset name key1 value1 key2 value2 Redis hash 是一个键值(key=>value)对集合。 Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。 List（列表） Redis

1、什么是 nginx 高可用？ “高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。Nginx于Keepalived可以实现高可用，实现双机热备+自动切换； 2、但是怎么实现 实现双机热备+自动切换 呢？ 　　需要在服务器安装 keepalive，以及编写脚本；以下开始搭建 3、环境准备 3.1　　 （1）需要两台 nginx 服务器 （2）需要 keepalived （3）需要虚拟 ip 3.2 配置高可用的准备工作 　　（ 1）需要两台服务器 192.168.2.112 和 192.168.2.113 　　 （2）在两台服务器安装 nginx （3）在两台服务器安装 keepalived 4、在两台服务器安装 keepalived 　　 （1）使用 yum 命令进行安装 yum install keepalived –y （2）安装之后，在 etc 里面生成目录 keepalived，有文件 keepalived.conf 5、完成高可用配置（主从配置） （1）修改/etc/keepalived/keepalivec.conf 配置文件 global_defs { notification_email { acassen@firewall.loc failover@firewall.loc

一，Redis作缓存服务器 ​ 本篇博客是接着 上一篇 博客未分享完的技术点。 ​ redis作为缓存服务器是众多企业中的选择之一，虽然该技术很成熟但也是存在一定的问题。就是缓存带来的缓存穿透，缓存击穿，缓存失效问题，继而引用分布式锁。 1.1，缓存穿透 ​ 在如今的项目中大多采用垂直的MVC架构，由service层去调用DAO层，然后DAO层再去查询数据库。而redis作为缓存服务器就是在service层去调用DAO层去查询时先去缓存服务器查询，如果存在则直接返回该数据，否则再去查询数据库。由此可知，这么做大量减少了对磁盘I/O的操作，减轻了数据库的压力。 ​ 现在我们假设一种情况，在数据库中存在有id为1到1000的数据。现在如果有人手动去模拟一个id为1001的请求，那么该数据在缓存服务器中是不存在的，因而便会去查询数据库。那么问题来了，如果是一个大量无效的请求去查询数据库。则势必会对数据库造成难以承受的压力，这种情况就是所谓的缓存穿透。 ​ 那如何解决呢？ ​ 1，将查询到的null值直接保存到缓存服务器中，但是这种做法并不推荐，因为如果是大量不同的请求id同样会去查询数据库。 ​ 2，接口的限流，降级与熔断 ​ 在项目中对于重要的接口一定要做限流，对于以上恶意攻击的请求除了要限流，还要做好降级准备，并且进行熔断，这种做法可以有效控制大量无效请求。 ​ 3，布隆过滤器 ​