集群服务器

redis 安装 下载地址：http://redis.io/download 安装步骤： # 安装gcc yum install gcc # 把下载好的redis‐5.0.2.tar.gz放在/usr/local文件夹下，并解压 wget http://download.redis.io/releases/redis‐5.0.2.tar.gz tar xzf redis‐5.0.2.tar.gz cd redis‐5.0.2 # 进入到解压好的redis‐5.0.2目录下，进行编译与安装 make # 启动并指定配置文件 src/redis‐server redis.conf（注意要使用后台启动，所以修改redis.conf里的daemonize改为yes) # 验证启动是否成功 ps ‐ef | grep redis # 进入redis客户端 /usr/local/redis/bin/redis‐cli # 退出客户端 quit # 退出redis服务： 1）pkill redis‐server 2）kill 进程号 3）src/redis‐cli shutdown redis集群搭建 redis集群需要至少要三个master节点，我们这里搭建三个master节点，并且给每个master再搭建一个slave节点，总共 6个redis节点，这里用三台机器部署6个redis实例

最上层通过Apache或F5作接入端负载均衡 AR1,AR2,AR3,..., ARn负责做Web接入端 SC是Server Central的缩写，一个环境中一般一个就够了，为了避免单点，也可以提供多台 AS1与AS2,AS3,...,ASn是应用服务器，一个一环境中可以有N台。 服务中心的职责： 接受请求服务器和应用服务器的注册 向其它服务器推送服务器注册信息 向其它服务器推送服务注册表 最终达到的效果： 请求服务器不用关心应用服务器 应用服务器不用关心请求服务器 请求服务器可以在线水平扩展--只要加一台机器即可，已经存在的机器不必做任何人为调整。 应用服务器可以在线水平扩展--只要加一台机器即可，已经存在的机器不必做任何人为调整 支持多服务中心，避免服务中心单点故障 服务中心宕机不影响已经注册服务器运行 部分应用服务器宕机不影响服务提供 请求服务器访问任意应用服务器上的服务都不需要中转 整个环境中的任何一个环境都不存在单点 即使只有一台AR和AS存在，就可以继续提供服务。 调用服务时，需要在所有提供服务的机器上进行负载均衡，并能根据应用服务器的增减自动调整 真正做到永不中断服务（没有电、网络中断除外） 来源： oschina 链接： https://my.oschina.net/u/1245989/blog/166930

摘要： 据了解，借助阿里云，上汽乘用车实现了工程开发仿真能力升级，仿真计算效率提升了25%，使工程开发人员更加专注于产品设计和性能优化，打造出世界级产品的高品质。今年北京车展上全球首秀的概念车MG X-Motion，其量产车的卓越整车性能正是经过上汽仿真计算云平台反复验证和优化的。 随着上汽集团与阿里云的合作开展，阿里云各项技术逐步深入到上汽汽车研发领域的核心业务实现落地。其中上海汽车集团股份有限公司乘用车分公司（以下简称上汽乘用车）与阿里云共建的仿真计算混合云就是新制造产业升级的典型代表项目。 上汽乘用车作为上汽集团全资子公司，承担着上汽自主品牌汽车的研发、制造与销售，拥有荣威、MG两大品牌，上海、南京和英国三地技术研发中心，上海临港、南京浦口和英国长桥三个制造基地。伴随上汽乘用车的市场表现强劲，车型研发工作也在持续加速升级，而为工程仿真服务的的计算资源供应开始远远落后于现实需求，具体表现为： 【研发需求强烈】 当前CAE仿真计算已经承担非常重要的任务，普遍出现计算任务工况多、规模大、时间紧的情况，迫切需要快速获取高性能计算资源； 【资源迭代滞后】 当前上汽乘用车建设的本地HPC集群虽然经历多次扩建，但是硬件资源严重老化，硬件资源故障率居高不下，计算性能难以满足业务需求，且资源更新迭代速度缓慢，严重影响仿真研发业务进度； 【 用户体验欠佳】

https://my.oschina.net/itshare/blog/775466 http://blog.51cto.com/467754239/1700828 日志系统 日志就是程序产生的，遵循一定格式（通常包含时间戳）的文本数据 通常日志由服务器生成，输出到不同的文件中，一般会有系统日志、 应用日志、安全日志。这些日志分散地存储在不同的机器上。 通常当系统发生故障时，工程师需要登录到各个服务器上，使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。在没有日志系统的情况下，首先需要定位处理请求的服务器，如果这台服务器部署了多个实例，则需要去每个应用实例的日志目录下去找日志文件。每个应用实例还会设置日志滚动策略（如：每天生成一个文件），还有日志压缩归档策略等。 这样一系列流程下来，对于我们排查故障以及及时找到故障原因，造成了比较大的麻烦。因此，如果我们能把这些日志集中管理，并提供集中检索功能，不仅可以提高诊断的效率，同时对系统情况有个全面的理解，避免事后救火的被动。 日志数据在以下几方面具有非常重要的作用： 数据查找：通过检索日志信息，定位相应的 bug ，找出解决方案 服务诊断：通过对日志信息进行统计、分析，了解服务器的负荷和服务运行状态 数据分析：可以做进一步的数据分析，比如根据请求中的课程 id ，找出 TOP10 用户感兴趣课程。

一、k8s的UI访问界面-dashboard 在dashboard中，虽然可以做到创建、删除、修改资源等操作，但通常情况下，我们会把它当做健康k8s集群的软件。 作为Kubernetes的Web用户界面，用户可以通过Dashboard在Kubernetes集群中部署容器化的应用，对应用进行问题处理和管理，并对集群本身进行管理。通过Dashboard，用户可以查看集群中应用的运行情况，同时也能够基于Dashboard创建或修改部署、任务、服务等Kubernetes的资源。通过部署向导，用户能够对部署进行扩缩容，进行滚动更新、重启Pod和部署新应用。当然，通过Dashboard也能够查看Kubernetes资源的状态。 1、Dashboard提供的功能 在默认情况下，Dashboard显示默认(default)命名空间下的对象，也可以通过命名空间选择器选择其他的命名空间。在Dashboard用户界面中能够显示集群大部分的对象类型。 1）集群管理 集群管理视图用于对节点、命名空间、持久化存储卷、角色和存储类进行管理。 节点视图显示CPU和内存的使用情况，以及此节点的创建时间和运行状态。 命名空间视图会显示集群中存在哪些命名空间，以及这些命名空间的运行状态。角色视图以列表形式展示集群中存在哪些角色，这些角色的类型和所在的命名空间。 持久化存储卷以列表的方式进行展示

博文大纲： 一、Kafka概述 1）消息队列 2）为什么要使用消息队列？ 3）什么是Kafka？ 4）Kafka的特性 5）Kafka架构 6）Topic和Partition的区别 7）kafka流程图 8）Kafka的文件存储机制 9）数据的可靠性和持久性保证 10）leader选举 二、部署单机Kafka 1）部署Kafka 2）测试Kafka 三、部署Kafka群集 1）环境准备 2）部署zookeeper群集 3）部署Kafka群集 一、Kafka概述 1）消息队列 1）点对点模式 （一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此； 2）发布/订阅模式 （一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。 2）为什么要使用消息队列？ 1）解耦 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2）冗余 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险

-------------------LVS专题------------------------ LVS原理详解及部署之一：ARP原理准备 LVS原理详解及部署之二：LVS原理详解（3种工作方式8种调度算法） LVS原理详解及部署之三：手动部署LVS LVS原理详解及部署之四：keepalived介绍 LVS原理详解及部署之五：LVS+keepalived实现负载均衡&高可用 ------------------------------------------------- 一、集群简介 什么是集群 计算机集群 简称 集群 是一种 计算机系统 ，它通过一组松散集成的 计算机软件 和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。 集群系统 中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。 集群计算机 通常用来改进单个计算机的计算速度和/或可靠性。一般情况下 集群计算机 比单个计算机，比如工作站或 超级计算机 性能价格比要高得多。 集群就是一组独立的计算机，通过网络连接组合成一个组合来共同完一个任务 LVS在企业架构中的位置： 以上的架构只是众多企业里面的一种而已。绿色的线就是用户访问请求的数据流向。用户-->LVS负载均衡服务器--->apahce服务器--->mysql服务器&memcache服务器&共享存储服务器

01 引言 随着用户的增长、业务的发展，大型企业用户的业务系统的数据量越来越大，超大数据表的性能问题成为阻碍业务功能实现的一大障碍。其中，流水表作为最常见的一类超大表，是企业级用户经常碰到的性能瓶颈。 本文就以流水类的超大表，探讨基于SequoiaDB巨杉数据库存储的超大表进行的性能调优。SequoiaDB 巨杉数据库，作为新一代 OLTP 的分布式数据库，被广泛使用于海量数据存储与高并发操作场景中。对于海量数据的存储和高并发操作，分布式数据库相较于传统数据库有着天然的优势，合理利用SequoiaDB巨杉数据库多种特性，轻松解决超大表的性能问题。 02 数据存储规划很重要 对于流水类超大表，前期的数据存储规划尤为重要，合理的数据存储规划能有效利用数据库集群硬件资源，提供更高性能、更高效率的数据服务。 1. 集群规模评估与硬件配置搭配 在数据库集群规划伊始，需要通过调研数据库集群支撑应用规模、系统定位和业务长期发展规划进行摸底，用以评估集群规模以及各服务器的CPU、内存、硬盘、网卡的合理搭配。 精准的评估一个数据库集群规模，是一个宏大且复杂的综合工程，需要有的业务需求评估数据加以支持。通常情况下，由于业务需求变化快、业务增长普遍高于预期，小集群规划可以按照业务调研信息的1.5~2倍进行评估，大集群规划可以按1~1.5倍进行评估。 集群规模需要通过业务规模、数据存储规模

一、概述 （1）版本历程 0.x 起步节点 1.x 支持复制集和分片 2.x 更加丰富的数据库功能 3.x 合并了一家专门做数据库引擎的Wired Tiger公司，更加完善的周边生态环境 4.x 支持 分布式事务 MongoDB的正式版本都是 偶数版本 ，x.x.x，主要版本（x.x）大约每年升级一次，小版本主要是修复问题，通常1-2个月发布一次。 MongoDB支持原生高可用：Application通过Driver连接到Primary节点，一个Primary节点连接多个Secondary节点。 MongoDB支持 水平扩展，分片集群 ：Driver连接多个Mongos，Mongos连接多个Shard，每个Shard都是一个Primary和多个Secondary。 二、复制集 主要用于 实现服务的高可用 （1）特征 MongoDB的复制集主要具备如下特征： 快速复制 ：数据写入时将数据迅速复制到另一个节点。 故障转移 ：在接受写入的节点发生故障的时候自动选择另一个新的节点代替。 其他作用：数据分发、读写分离、异地容灾。 （2）MongoDB的数据复制原理 一个修改 操作会被记录到oplog ，有一个 线程监听oplog ，如果有变动就会将这个变动应用到其他的数据库上。 从节点在主节点上打开一个 tailable游标 ，不断获取新加入的oplog，并在从库上 回放 。 （3

InfluxDB Enterprise集群安装实验01-简介 前言 近期公司打算采购InfluxDB的企业版集群，正好抽空自己搭一套练练手，测试下基本功能。 实验环境 操作系统：CentOS Linux release 7.3.1611 (Core) influxdb版本：1.7.9 机器： 机器名 ip influxdb01 10.11.100.73 influxdb02 10.11.100.74 influxdb03 10.11.100.75 前置条件 1.秘钥配置要求 influxdb的秘钥配置有license key和license file两种方式，如果使用license key进行秘钥验证，则必须保证所有节点都能访问门户网站portal.influxdata.com的80端口或443端口。如果超过4小时无法连接到门户网站将导致秘钥验证失败的问题，整个集群将不可用。 注意：个人建议在生产中使用license file的验证方式，可以避免由于外部网络波动导致的集群故障 2.确保各主机的连接 集群中的所有机器需要确保主机名与ip的相互解析，并确保网络通畅。 在所有机器的hosts文件加上主机名： [root@influxdb01 opt] # cat /etc/hosts 10 . 11 . 100 . 73 influxdb01 10 . 11 . 100 . 74