高可用

案例说明 为解决memcached单点故障，需要实现memcached缓存的高可用。 首先，需要实现 Memcached的主主复制 ，指任意一台memcached服务器修改数据都会被同步到另外一台，但是memcached API无法判断连接哪一台服务器，因此需要VIP。 其次，通过 Keepalived 产生的VIP连接memcached服务器，提供高可用架构。 案例拓扑 案例环境 主机 IP地址 操作系统 主要软件 Memcached 1 192.168.37.128 Centos7 libevent；memcached；keepalived；magent Memcached 1 192.168.37.130 Centos7 libevent；memcached；keepalived 安装软件包 链接： https://pan.baidu.com/s/1tHnxoldZoX7U0aHnx6GlRg 密码：vl6l 案例实施 一、主从服务器安装memcached 1、安装环境包 yum install gcc gcc-c++ make -y systemctl stop firewalld.service setenforce 0 2、解压libevent、memecached包 tar zxvf libevent-2.1.8-stable.tar.gz -C /opt tar

随着越来越多的应用架构解耦变为分布式的，在组件横向扩展能力提高的同时对负载均衡设备的要求和依赖性也越来越高，同时更要求负载均衡设备有强大的横向扩展能力。负载均衡集群技术变得越来越重要。虽然很多厂商提供各种Cluster技术，但是能够真正简化管理、实现智能流量调度的唯有Netscaler是做的最独特的。 在讨论集群技术之前，我们先聊一下负载均衡高可用技术： 高可用技术包含以上这么几大类 主/备：很常见的方案，就是两台ADC做双机部署，同一时间只有一台工作，另一台做热备。缺点是有点浪费资源，不支持同时故障2台以上的设备。 主/主：基于VRRP的技术，相对较少的方案。如果还是2台设备，只是心里上感觉设备利用率提高了，殊不知每台的吞吐量依旧不能超越50%，否则故障一台会出现丢弃业务的情况。如果是多台的话可以做所谓的M:N，但是配置复杂，业务切换受网络收敛时间（arp表老化及交换机卡死）的影响，存在短时丢失业务的风险。 GSLB：基于Site的高可用，不能解决站点内部的高可用。 Cluster：新兴的高可用技术。 首先了解一下什么是集群？这个就很简单了，不清楚的请问一下度娘。今天重点要讨论的是Netscaler的集群。 Netscaler于2007年将架构彻底转变为nCore，尽管当时依旧是传统的HA部署模式，但这已转变为日后Cluster的技术领先奠定了坚实的技术基础

前言： AWS 已有ALB (Application Load Balancer) 和 NLB (Network Load Balancer)，可滿足大部分業務需求，但某些業務場景仍需要自建高可用環境。 此文便是基於AWS EC2 自建高可用主機。 準備： EC2 host1：192.168.10.10 EC2 host2：192.168.10.20 Float IP：192.168.10.30 思路： AWS EC2 主機支持分配輔助IP，可使用AWS CLI 創建輔助IP，基於此方式，只要當主機或服務出現故障時，將輔助IP 分配給另一臺正常的主機即可。 那麼要解決的就是對主機及服務的判斷，最初的想法是寫個腳本做存活判斷，即： 1. 主機讀取指定status文件內字符，判斷是否屬於master，然後檢測自身的服務是否處於存活狀態，存活則pass，否則檢查另一臺主機及服務狀態，存活則將Float IP 分配給另一個存活的主機並改寫status文件內容。 2. 不屬於master，則檢測自身的服務是否處於存活狀態，存活則檢查master服務是否存活，存活則pass，否則將Float IP 分配給自己並改寫status文件內容。 將腳本加入crontab，並每3秒執行一次 後來感覺還是用keepalived 做更省事些…… 正文： 這裏不做keepalived 安裝說明

前言  近些年阿里云可以说是非常火爆的一个话题，相信熟悉阿里云产品的朋友都知道阿里云的这句代言： “阿里云让高可用更简单”  实际是确实是这么回事，而近几年也越来越多的企业都在普及阿里云的使用。  所以，很多朋友在面试的时候也感受到了很多企业都要求运维工程师必须要熟悉阿里云的产品和服务。  有些朋友可能也了解过阿里云，也使用过阿里云的其中一些产品，如果企业让你设计一套阿里云的环境，阿里云有这么多的产品（ECS、CDN、RDS等等），我们该如何把这些产品和服务优美的融合在一起呢？这也是很多朋友比较关心的话题，笔者和大家一起来讨论一下。 说明：以下的技术内容仅供参考、技术交流及分享，希望大家多提宝贵的意见。 看下环境A的架构 如果你所在的企业对安全、***的要求相对较低，而且公司的（web、app）业务量也不大，又想省点钱，那么下面这套环境可供你参考一下。 适用行业 适用于制造业、服务业、能源等传统企业。只是想展示公司的业务，满足简单的业务需求； 部署架构 SLB（入口层）-> 源站（ECS/VPC） -> 数据库（RDS），即对应关系为：  域名解析SLB  SLB负载ECS  云监控对ECS/RDS/SLB监控 预算费用 以下只是做为参考，需要根据自己公司的业务情况来配置开通。 产品 数量 规格 费用/年 阿里云ECS服务器 1 CPU4C/内存8G/硬盘/100G 大约4500

proxmox是一款开源的虚拟化管理平台，在服务器虚拟化方面有不俗的表现。曾经有个单cpu 4线程、16G内存、300G硬盘开20多个centos，并且上面的应用都是tomcat的交易系统，稳定运行大半年的记录（公司倒闭，服务器被下架）。后来，陆续迁移一些陈旧物理服务器上的应用到proxmox虚拟化平台，也是受益多多。从proxmox5.版本开始，整合了分布式文件系统ceph，并对其进行了改进。官方的用语是：Compute, network and storage in a single solution。字面理解是计算、网络、存储一体化解决方案。用流行的术语就是“超融合”嘛！不知道这个词是不是国人发明的，可能外国鬼子不晓得？ 没有比较就没有伤害，下边我来列举一些自己认为比较有用的特征： 去中心化 ：集群节点去中心化、分布式存储也去中心化。这意味着，只要节点之间能组成最基本的集群，哪个物理节点发生故障都不会影响可用性。比如三个节点的集群，可以任意死掉一个。而传统方式的虚拟化高可用方案，多采用昂贵的、高性能的外挂存储来解决问题，但是存储本身也是单点，一旦它发生故障，一定是全军覆没。 超融合 ：操作系统、存储、虚拟化平台、网络一体化，无需外挂共享存储。除此之外，还可以充分利用剩余的计算资源，用于桌面系统的虚拟化，外购云终端盒子，直接取代耗能、占空间、不易于维护的台式电脑主机。 易于实施

转载自：中华石杉公众号 关键词 ：高性能、动静分离、热点优化、系统优化、一致性（库存扣减准确性）、高并发读写、高可用（流量削峰、）、缓存失效和命中率 前言 秒杀大家都不陌生。自2011年首次出现以来，无论是双十一购物还是 12306 抢票，秒杀场景已随处可见。 简单来说，秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过程。 从架构视角来看，秒杀系统本质是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量的秒杀系统需要进行哪些关注，就是本文讨论的话题。 整体思考 首先从高维度出发，整体思考问题。秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。 关于秒杀系统的设计思考，本文即基于此 3 层依次推进，简述如下： 高性能。 秒杀涉及高读和高写的支持，如何支撑高并发，如何抵抗高IOPS？核心优化理念其实是类似的：高读就尽量"少读"或"读少"，高写就数据拆分。 本文将从动静分离、热点优化以及服务端性能优化 3 个方面展开 一致性。 秒杀的核心关注是商品库存，有限的商品在同一时间被多个请求同时扣减，而且要保证准确性，显而易见是一个难题。 如何做到既不多又不少？本文将从业界通用的几种减库存方案切入，讨论一致性设计的核心逻辑 高可用。 大型分布式系统在实际运行过程中面对的工况是非常复杂的，业务流量的突增、依赖服务的不稳定

原文链接 NameNode 高可用整体架构概述 在 Hadoop 1.0 时代，Hadoop 的两大核心组件 HDFS NameNode 和 JobTracker 都存在着单点问题，这其中以 NameNode 的单点问题尤为严重。因为 NameNode 保存了整个 HDFS 的元数据信息，一旦 NameNode 挂掉，整个 HDFS 就无法访问，同时 Hadoop 生态系统中依赖于 HDFS 的各个组件，包括 MapReduce、Hive、Pig 以及 HBase 等也都无法正常工作，并且重新启动 NameNode 和进行数据恢复的过程也会比较耗时。这些问题在给 Hadoop 的使用者带来困扰的同时，也极大地限制了 Hadoop 的使用场景，使得 Hadoop 在很长的时间内仅能用作离线存储和离线计算，无法应用到对可用性和数据一致性要求很高的在线应用场景中。 所幸的是，在 Hadoop2.0 中，HDFS NameNode 和 YARN ResourceManger(JobTracker 在 2.0 中已经被整合到 YARN ResourceManger 之中) 的单点问题都得到了解决，经过多个版本的迭代和发展，目前已经能用于生产环境。HDFS NameNode 和 YARN ResourceManger 的高可用 (High Availability，HA) 方案基本类似

数据库相关的知识，看了《高性能MySQL》和《数据库系统实现》两本。两本书综合看效果更好。 《高性能MySQL》从使用的角度入手，《数据库系统实现》从原理的角度入手。以前学习数据库相关的知识时有个执念，一定要弄明白它是怎么实现的，就直接买了一个《MySQL内核:Innodb存储引擎》,结果看不懂，束之高阁。 数据库的知识，个人觉得如下的顺序比较合理。 硬盘 《数据库系统实现》在第二章就单独用一章的篇幅讲解磁盘的存储原理。这是因为计算机内置组件中具备持久存储能力的只有硬盘，软件屈从于硬件。因此理解磁盘的存储特点才能理解软件设计背后的逻辑。磁盘存储有如下的特点: 特性A:相比CPU的延迟，磁盘延迟非常非常大。 在《性能之巅》中有做过对比，对于3.3GHz的CPU, 一个指令周期为0.3ns；机械硬盘一次I/O的延迟为1～10ms。这个差距有多大，如果一个CPU指令周期为1s, 那么机械硬盘一次I/O的延迟为1～12个月。真是等到花儿都谢了。 特性B:磁盘是块设备，每次写入都是按块来的。通常一个块为512byte。即使用硬盘，得注意 不能用轮船只运输一个土豆到美国 。 特性C:顺序IO的性能远远高于随机IO的性能。因为顺序IO避免了寻道时间和旋转延迟。 上述的特性不仅影响了数据库的设计，更是深刻影响了操作系统的设计，例如 page cache 读写 数据库的操作基本上就是更高阶的读写:

前言 Redis是一个高性能的key-value数据库，现时越来越多企业与应用使用Redis作为缓存服务器。楼主是一枚JAVA后端程序员，也算是半个运维工程师了。在Linux服务器上搭建Redis，怎么可以不会呢？下面楼主就带着大家从0开始，依次搭建：Redis单机服务器 -> Redis主从复制 -> Redis-Sentinel高可用。逐步搭建出高可用的Redis缓存服务器。 搭建Redis 1. 下载并解压 首先从Redis官网下载Redis并解压，楼主使用的版本是4.0.2。依次执行如下命令： cd /usr/local/ wget http://download.redis.io/releases/redis-4.0.2.tar.gz tar -zxvf redis-4.0.2.tar.gz 如果没有安装gcc依赖包，则安装对应依赖包 yum install -y gcc-c++ tcl 2. 编译并安装 下载并解压完毕后，则对源码包进行编译安装，楼主的Redis安装路径为/usr/local/redis，同学们可以自行修改语句：make install PREFIX=你想要安装的路径 cd /usr/local/redis-4.0.2/ make install PREFIX=/usr/local/redis 复制Redis相关命令到/usr/sbin目录下

服务器为什么要做双机热备？双机热备的好处？ 双机热备特指基于高可用系统中的两台服务器的热备（或高可用），因两机高可用在国内使用较多，故得名双机热备，双机高可用按工作中的切换方式分为：主-备方式（Active-Standby方式）和双主机方式（Active-Active方式），主-备方式即指的是一台服务器处于某种业务的激活状态（即Active状态），另一台服务器处于该业务的备用状态（即Standby状态)。而双主机方式即指两种不同业务分别在两台服务器上互为主备状态（即Active-Standby和Standby-Active状态）。 方案 组成双机热备的方案主要的三种方式分别为：基于共享存储（磁盘阵列）的方式，全冗余方式和复制方式。 对于服务器管理员来说，服务器出现故障可能是最严重的问题，因为服务器故障的原因有很多，有可能是设备故障，有可能是操作系统故障，还有可能是软件故障，当服务器出现故障时，要一一对故障进行排除，让服务器正常运行，少则几十分钟，从则几十小时，这还不是挽回服务器故障所带来的损失，这时，双机热备对服务器就起着关键作用。 双机热备特指基于高可用系统中的两台服务器的热备（或高可用），因两机高可用在国内使用较多，故得名双机热备，双机高可用按工作中的切换方式分为：主-备方式（Active-Standby方式）和双主机方式（Active-Active方式），主