集群服务器

1.1 集群运行 1.1.1 集群运行步骤 (1)打包 打作业jar包发送给集群，hadoop通过搜索驱动程序的类路径（驱动程序中通过setJarByClass设置）自动查找作业的的jar文件，打包命令： mvn package –DskipTests //–DskipTests 跳过测试的意思 （2）设置路径 作业jar包路径，依赖库路径，HADOOP_CLASS定义的类路径。 （3）启动作业 hadoop jar hadoop-examples.jar v2.MaxTempertureDrive –conf conf/Hadoop-cluster.xml -jt local input/ncdc/all output 1.1.2 作业ID任务ID和任务尝试ID 作业ID由资源管理器创建的YARN的应用ID生成。Application_14112131314234_0003，资源管理器开始时间戳，0003是资源管理器自动分配的增量ID，下一个应用就是0004。将application替换为job，即为作业ID：job_14112131314234_0003。任务属于作业，任务ID: task_14112131314234_0003_m_000004表示作业的第5个map任务（000004，从0开始计数）；任务执行会失败，所以有多个任务尝试ID，attempt

1.CentOS6.4安装 (1) 下载镜像文件 使用如下网址： https://pan.baidu.com/s/1Ajpcb-W8b-Kwh6I9Hqh4gw 提取码: s57r 。下载镜像文件，也可到官网中进行下载 (2) 创建虚拟机 打开Virtual Box或者VMware，点击“新建”按钮；输入虚拟机名称为spark1，选择操作系统为Linux，选择版本为Red Hat(32bit)；分配1024MB内存；后面所有选项全部用默认的设置；注意，在Virtual disk file location and size中，一定要自己选择一个目录来存放虚拟机文件；最后点击“create”按钮，开始创建虚拟机 (3) 设置网卡 设置网卡（桥接网卡）：选择创建好的虚拟机，点击“设置”按钮，在网络一栏中，连接方式中，选择“Bridged Adapter”，即桥接网卡 (4) 安装CentOS 6.4操作系统 选择创建好的虚拟机，点击“开始”按钮；选择安装介质（即本地的CentOS 6.4镜像文件）；选择第一项开始安装-Skip-欢迎界面Next-选择默认语言-Baisc Storage Devices-Yes, discard any data-主机名:sparkproject1-选择时区-设置初始密码为hadoop-Replace Existing Linux System

容器 容器与虚拟机对比图(左边为容器、右边为虚拟机)   容器技术是虚拟化技术的一种，以Docker为例，Docker利用Linux的LXC(LinuX Containers)技术、CGroup(Controll Group)技术和AUFS(Advance UnionFileSystem)技术等，通过对进程和资源加以限制，进行调控，隔离出来一套供程序运行的环境。 我们把这一环境称为“容器”，把构建该“容器”的“只读模板”，称之为“镜像”。   容器是独立的、隔离的，不同容器间不能直接通信，容器与宿主机也是隔离开来的，容器不能直接感知到宿主机的存在，同时宿主机也无法直接窥探容器内部。   虽然容器与宿主机在环境上，逻辑上是隔离的，但容器与宿主机共享内核，容器直接依赖于宿主机Linux系统的内核，这与虚拟机不同，后者是在宿主机的操作系统上，虚拟化一套硬件环境，然后在此环境上运行需要的操作系统。容器技术常用来在宿主机上隔离出环境来部署应用（用容器化技术部署的应用称为 ***“容器化应用”*** ），而虚拟机常用来运行一个与宿主机不同的操作系统，从而运行特定的软件。   容器非常轻量级，无论是启动速度，资源占用情况，灵活性等均优于虚拟机。容器的特性给开发生产提供了非常大的便利： * DevOps理念，开发者可以使用同一个镜像，在开发环境、测试环境和生产环境构建相同的容器

目录 node_exporter监控集群节点 1.node-exporter.yaml 2.查看DaemonSet字段 3.启动 prometheus.yaml文件说明 1.Pod的安全策略 2.监控master节点 3.启动参数 4.映射端口 5.服务发现 热更新: prometheu_configmap 配置文件 容器监控 Api-Service 监控 Service 监控 1.添加service监控 2.service添加prometheus标签 3.kube-state-metrics node_exporter监控集群节点 通过prometheus来采集节点的监控指标，可以通过node_exporter获取，node_exporter就是抓取用于采集服务器节点的各种运行指标，目前node_exporter几乎支持所有常见的监控点，比如cpu、distats、loadavg、meminfo、netstat等，详细的监控列表可以参考github repo 这里使用DeamonSet控制器来部署该服务，这样每一个节点都会运行一个Pod，如果我们从集群中删除或添加节点后，也会进行自动扩展 1.node-exporter.yaml # cat >>prometheus-node-exporter.yaml apiVersion: apps/v1 kind: DaemonSet

zookeeper分布式锁原理： https://my.oschina.net/u/3492343/blog/2992492 zookeeper的树形结构 zookeeper节点特性 1.同级节点唯一性 2.临时节点和持久化节点 3.有序节点和无序节点 4.临时节点下不能存在子节点 集群搭建 server.id = ip:port:port 在zoo.cfg里面加入以下 server.1=192.168.182.128:2888:3888 server.2=192.168.182.129:2888:3888 server.3=192.168.182.130:2888:3888 192.168.182.128:2888是完成数据同步的节点 192.168.182.128:3888是选举leader的节点 自己练习的话关闭防火墙service iptables stop，生产就开放相关端口， 在data目录下创建myid（id一定要和上面id对应的ip对应） vim /tmp/zookeeper/myid 里面加入：1或2或3 zoo.cfg里面的参数 1.tickTime=2000 心跳时间 2.initLimit=10 初始化同步数据的时候10个心跳时间 3.syncLimit=5 心跳检测的最大延迟 4.dataDir = /x 同步数据存储的位置 5.clientPort

RabbitMq本身支持集群，但其本身并不支持负载均衡。 说一下我自己的理解： RabbitMQ的集群分为两种模式：默认模式、镜像模式 默认模式： 将多个service连接在一起，变成一个集群，可以从任意一台service上生产消息和消费消息，客户端可以连接任意一个service，如果要生产或者消费的消息不在当前连接的service上，集群会从所在的service上获取或生产消息。 当一个service意外停止后，再向这个server生产或消费消息则会报错。 镜像模式： 镜像模式是在默认模式上增加，创建镜像后会根据镜像的规则将一个消息复制到所有的集群上，消息被确认后所有集群上的消息会被清除掉，不会重复消费。（queues在哪个service上哪个service就是主节点） 当主service意外停止后，RabbitMQ会从集群中提出一个创立时间最早的子节点作为主节点，当service重新加入集群后会变为从节点。 主节点停止后，从节点变为主节点，这个转换的时间内如果生产新的消息会丢失。 镜像模式相对于默认模式的一点弊端是浪费带宽，镜像模式的消息在集群中复制会浪费带宽，默认模式则是在消费或生产消息时在集群内部传输。 windows上配置RabbitMQ集群+镜像 Erlang的集群中各节点是经由过程一个magic cookie来实现的，两台服务器上的cookie要一致

写在前面 在当今信息爆炸的时代，单台计算机已经无法负载日益增长的业务发展，虽然也有性能强大的超级计算机，但是这种高端机不仅费用高昂，也不灵活，一般的企业是负担不起的，而且也损失不起，那么将一群廉价的普通计算机组合起来，让它们协同工作就像一台超级计算机一样地对外提供服务，就成了顺其自然的设想，但是这又增加了软件的复杂度，要求开发的软件需要具备横向扩展能力，比如：Kafka、Elasticsearch、Zookeeper等就属于这一类软件，它们天生都是"分布式的"，即可以通过添加机器节点来共同地分摊数据存储和负载压力。 为什么需要集群？ 分布在不同区域的计算机，彼此之间通过网络建立通信，相互协作作为一个整体对外提供服务，这就是集群，如果我们开发的系统具备这样的能力，那么理论上就具备无限横向扩容的能力，系统的吞吐量就会随着机器数增加而增长，那么未来当系统出现高负载的时候，就可以很好地应对这种情况。 为什么CAP不能同时满足？ 通过上面分析，我们知道实现集群，其实就是采用多台计算机来共同承担和负载系统压力，那么就涉及到多台计算机需要参与一起处理数据，为了保证可用性，一般都会在每台计算机上备份一份数据，这样只要有一个节点保持同步状态，那么数据就不会丢失，比如kafka分区多副本、Elasticsearch的副本分片，由于同一数据块及其副本位于不用的机器，随着时间的推移，再加上不可靠的网络通信

注：本文使用的Traefik为1.x的版本 在生产环境中，我们常常需要控制来自互联网的外部进入集群中，而这恰巧是Ingress的职责。 Ingress的主要目的是将HTTP和HTTPS从集群外部暴露给该集群中运行的服务。这与Ingress控制如何将外部流量路由到集群有异曲同工之妙。接下来，我们举一个实际的例子来更清楚的说明Ingress的概念。 首先，想象一下在你的Kubernetes集群中有若干个微服务（小型应用程序之间彼此通信）。这些服务能够在集群内部被访问，但我们想让我们的用户从集群外部也能够访问它们。因此，我们需要做的是使用反向代理将每个HTTP（S）（例如， service.yourdomain.com ）路由与相应的后端关联，并在该服务的不同实例之间（如，pod）进行负载均衡。与此同时，由于Kubernetes的性质会不断发生变化，因此我们希望跟踪服务后端的更改，以便能够在添加或删除新Pod时将这些HTTP路由重新关联到新Pod实例。 使用Ingress资源和关联的Ingress Controller，你可以实现以下目标： 将你的域 app.domain.com 指向你的私有网络中的微服务应用程序 将路径 domain.com/web 指向你的私有网络中的微服务web 将你的域 backend.domain.com 指向你的私有网络中的微服务后端

作者：至尊宝 cnblogs.com/aspirant/p/5697807.html 在IDF05（Intel Developer Forum 2005）上，Intel首席执行官Craig Barrett就取消4GHz芯片计划一事，半开玩笑当众单膝下跪致歉，给广大软件开发者一个明显的信号，单纯依靠垂直提升硬件性能来提高系统性能的时代已结束，分布式开发的时代实际上早已悄悄地成为了时代的主流。 吵得很热的云计算实际上只是包装在分布式之外的商业概念，很多开发者（包括我）都想加入研究云计算这个潮流，在google上通过“云计算”这个关键词来查询资料，查到的都是些概念性或商业性的宣传资料，其实真正需要深入的还是那个早已被人熟知的概念——分布式。 分布式可繁也可以简，最简单的分布式就是大家最常用的，在负载均衡服务器后加一堆web服务器，然后在上面搞一个缓存服务器来保存临时状态，后面共享一个数据库，其实很多号称分布式专家的人也就停留于此，大致结构如下图所示： 这种环境下真正进行分布式的只是web server而已，并且web server之间没有任何联系，所以结构和实现都非常简单。 有些情况下，对分布式的需求就没这么简单，在每个环节上都有分布式的需求，比如Load Balance、DB、Cache和文件等等，并且当分布式节点之间有关联时，还得考虑之间的通讯，另外，节点非常多的时候

目录 Redis集群 理论 安装 管理 增加新-主节点 　增加新-从节点 删除节点 我叫张贺，贪财好色。一名合格的LINUX运维工程师，专注于LINUX的学习和研究，曾负责某中型企业的网站运维工作，爱好佛学和跑步。 个人博客： 传送阵 笔者微信： zhanghe15069028807 ，非诚勿扰。 Redis集群 理论 Redis集群起码是三个服务器做，每个服务器里面都有两个实例，两个实例并不能是单纯的一主一从，而是错开，防止一个服务器挂了之后，数据丢失，如下图所示： 当集群安装好之后，会生成16384个槽位用于存储键值，其中0--5500在master1这个槽位上，5501--11000在master2槽位上，11001--16384在第三个槽位上，如下所示： 当我们存储一个键值的时候，redis会通过一个公式计算出一个值，假如这个值 是6666的话，那么这个键值就存储到master2这个实例上，依次类推，存的时候是这样存，取的时候同样也是这样取。 客户端在连接的时候无论连接哪一个节点都可以，如果本节点上没有要存取的键值的话，本节点会帮客户端转发，客户端不需要重新连接。 万一其中的一个主挂了，并不是从立马主顶上，而是剩下的两个主一同投票来决定，并不是利用了“哨兵sentinel”的机制。 安装 我们操作的时候用一台服务器，然后开6个实例：7000-----7005 [root