什么样的服务器可以定义为高性能服务器？高性能服务器是指一类服务器还是某款服务器？

1、内存RAM(随机存取存储器)
服务器内存的大小会影响服务器处理命令的速度。处理更复杂和更多种命令时，需要更高的内存。例如，动态的电子商务网站、数据库服务器等，需要对数据库运行各种查询和检索，更大的内存将使您获得更高的性能优势。

2、CPU(处理器)
独立服务器的CPU执行诸如服务网页、运行数据库查询或处理计算命令等指令。CPU和内核的数量会影响可执行多少个并发指令。CPU架构和功能也影响执行指令的速度，特别是在围绕这些功能设计程序的网站或应用。

3、硬盘存储空间
服务器的硬盘存储是本地数据库大小和文件(如图像)的本地存储的限制因素。配置RAID磁盘阵列可有效增加数据可靠性，增加读取/写入(I/O)性能，RAID需要两个以上单独的存储卷。存储还可以采取网络存储的形式，如NAS(网络连接存储)或SAN(存储区域网络)。

4、硬盘类型(如SATA，SDD)
服务器中的固态硬盘(SSD)比SATA硬盘驱动器提供更高的磁盘读/写速度，也称为输入/输出(I/O)性能。具有SSD读取和写入磁盘的服务器速度更快，但定价显著高于同等存储容量的SATA硬盘。

5、带宽
带宽数据传输限制，指的是可以并发到您的服务器的数据量。服务器带宽价格较高，通常提供5Mbps、10Mbps国际带宽。像并发视频流、游戏和大数据处理等工作任务都需要高带宽。

6、网络延迟
网络延迟是服务器和用户之间发送信息的延迟的毫秒。网络延迟的高低由服务器提供商决定，但受到服务器和用户之间的距离和网络质量的影响。

7、可用性
服务器的高可用性(HA)可能指网络和电源可用性，这反映在托管服务提供商的维护正常运行时间的实际记录以及其SLA(服务级别协议)中，以保证一定的正常运行时间。还可以通过以系统中单独的主动地添加RAID配置引入冗余来实现可用性保障，在发生隔离故障的情况下进行故障转移。感兴趣的话点击此处，了解一下

高可用性（HA），顾名思义，就是尽可能地减少系统不能提供服务的时间；如果一个系统能够一直保持工作状态，可以对外提供服务，那么我们就说系统的可用性是100%；大部分公司不会把话说这么满，所以经常会提出三个9、四个9的目标，也就是全年系统可用性为999%、9999%。

那么如何保证系统的高可用呢？我认为核心的思想就是防止单点，增加冗余，先让我们看看传统的架构是什么样的，哪里会有风险。

可以看到，架构的每一个部分都是单点的话，简直是风险重重，任何一个环节出现了问题，可能会造成整个系统垮掉（缓存部分可能不会直接影响系统，但往往缓存失去效果之后，会拖垮数据库），解决方法也很容易，其实就是把系统的每个部分都增加冗余：

客户端到Web应用：要增加Web应用，首先要增加反向代理层，也就是负载均衡，比如Nginx；不过如果只部署一个Nginx的话，它又是一个单点了，通常我们会部署多台，一台提供服务，另外的相当于“备胎”，通过keepalived的方式监控工作中的Nginx是否存活，当主服务器发生故障无法对外提供服务时，动态将virtualIP(虚IP)切换到备用机，继续提供服务。

负载均衡到Web应用：搭建多个Web应用，在负载均衡如Nginx中配置多个Web端的地址，并且可以监控多个Web端的存活性，当监控到某台应用挂掉，那么Nginx不在将请求分发到这台机器上。

Web应用到服务层：这里有很多种实现方式，比如服务层前端也挂负载均衡，或者走客户端内的负载均衡（这里Web应用就是客户端，相当于配置多个服务层的地址，每次请求按照一定规则，选取连接来访问下游服务，并使用service-connection-pool监控服务层应用的存活性）；也可以使用服务注册发现的方式（可提供服务的应用才会出现在注册中心）。

服务层到缓存：缓存的存在，本身就是一种冗余；缓存层也可以通过集群来解决缓存层的高可用问题。以Redis为例，支持主从同步，而且有sentinel哨兵机制，来做Redis的存活性检测。

服务层到数据库：数据库一般会采用主从架构；数据库读的高可用，通常使用db-connection-pool来保证自动故障转移；而写 *** 作，通常需要keepalived+virtualIP(虚IP)自动切换。

以上都是保证系统高可用的方案，尽量做到客户端所有的请求都可以响应，但是系统资源不可能无限投入，所以需要一些方案保证系统的高可用，不过需要牺牲部分用户：

限流：我们接口只能支持200的并发，我们的页面只能支持一万人同时访问，那么多余的部分，对不起，我需要限制你们进入；常见的限流算法有：漏桶、令牌桶；

降级：牺牲非核心的业务功能，保证核心功能的稳定运行；

熔断：当服务链路中（A调B，B调C，C调D），某个服务响应时间过长或失败，会进行服务的降级，进而熔断该节点服务的调用，快速返回错误信息；不过嘛，我从来没有见过谁敢用熔断

灰度发布：将部分流量导到新上线的应用上，来验证新的功能修改，如果上线后有BUG，也可以快速回滚，尽可能降低发布的风险。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

存储服务器和计算服务器都是两种类型的服务器，它们以不同的方式用于支持不同类型的工作负载。
存储服务器是一种主要负责存储和管理数据的服务器。这包括存储文件、备份数据以及为其他服务器和客户端提供数据访问等任务。存储服务器使用多种存储技术，例如直连存储（DAS）、网络附加存储（NAS）和存储区域网络（SAN）等。
计算服务器是主要负责处理数据的服务器。这包括运行应用程序、执行计算以及为其他服务器和客户端提供计算资源等任务。计算服务器可以有不同的形式，例如物理服务器、虚拟机或云实例。
存储服务器和计算服务器相互连接并协同工作以提供完整的解决方案。数据存储在存储服务器中，然后由计算服务器进行处理，然后将输出存储回存储服务器，依此类推。
存储服务器和计算服务器之间的确切关系可能因组织的具体需求而异，但一般来说，存储服务器用于存储和管理数据，而计算服务器用于处理和分析数据。
在许多情况下，单个服务器可以同时提供计算和存储功能，称为融合基础架构。这些服务器通常包括 CPU 和内存等计算资源，以及磁盘驱动器或 SSD 等存储资源，并且可以作为一个单元进行管理。
存储服务器和计算服务器都是用于支持不同类型工作负载的服务器类型，但它们具有不同的主要功能和特性。
相似之处：
存储服务器和计算服务器都是在网络环境中使用的服务器，它们使用标准网络协议与其他服务器和客户端进行通信。
存储服务器和计算服务器都是更大系统的一部分，该系统包括硬件、软件和网络基础设施。
存储服务器和计算服务器都可以具有内置的冗余和高可用性功能，以确保数据和服务的可用性。
区别：
存储服务器的主要功能是存储和管理数据，而计算服务器的主要功能是处理和分析数据。
存储服务器通常使用直连存储 (DAS)、网络附加存储 (NAS) 和存储区域网络 (SAN) 等存储技术来存储数据，而计算服务器则使用 CPU 和内存等计算技术来执行计算。
存储服务器用于长期存储数据，通常具有较大的存储容量；而计算服务器用于实时处理数据，通常具有多CPU、大内存等高性能硬件。
存储服务器针对数据保留、备份和数据可访问性进行了优化，而计算服务器针对计算能力进行了优化，例如高速 CPU、大内存和多核。
综上所述，存储服务器和计算服务器的主要区别在于它们的主要功能，存储服务器用于存储数据，计算服务器用于处理数据。它们共同提供了一个完整的解决方案，它们之间的具体关系

本教程用官网最近的cephadm来搭建ceph集群。

第一周作业：1ceph的组件和功能2ceph的数据读写流程3使用ceph-deploy安装一个最少三个节点的ceph集群 推荐3个或以上的磁盘作为专用osd 4测试ceph的rbd使用

1·Ceph组件和功能

组件

Ceph OSDs : ( Ceph OSD ）object storage daemon的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有2个副本时，至少需要2个 OSD 守护进程，集群才能达到 active+clean 状态（ Ceph 默认有3个副本，但你可以调整副本数）。

Monitors : 维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。 Ceph 保存着发生在Monitors 、 OSD 和 PG上的每一次状态变更的历史信息（称为 epoch ）。

MDSs : Ceph 元数据服务器为 Ceph 文件系统存储元数据（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）。元数据服务器使得 POSIX 文件系统的用户们，可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基本命令。

CephMgr ：在一个主机上的守护进程，负责运行指标，运行状态，性能负载，

其他术语：

RADOS：多个主机组成的存储集群，即可靠，自动化，分布式的对象存储系统。

File:  就是普通文件，ObjectRADOS看到的对象，Object与File的区别是， Object的最大尺寸由RADOS限定(通常为2MB或4MB) ，以便实现底层存储的组织管理。因此，当上层应用向RADOS存入尺寸很大的File时，需要将File切分成统一大小的一系列Objet (最后一个的大小可以不同)进行存储。

librados：RADOS集群的API，支持大部分主流语言。

Pool：存储池，大小取决于底层的存储空间。

PG：placeholder group，一个pool（存储池）内可以有多个PG，pool个pg都是抽象的逻辑概念，可以通过公示计算。PG的用途是对Object的存储进行组织和位置映射的。具体而言，一个PG负责组织若干个Object，但一个Obiect只能被映射到一个PG中，即PG和Object之间是“一对多”的映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即PG和OSD之间是“多对多”的映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG可达到数百个。事实上， PG数量的设置关系到数据分布的均匀性问题。

OSD daemon：默认每2秒发送状态数据给monitor，（同时监控组内其他OSD的状态）（up 可以提供IO，down不能提供，in有数据，out没有数据）

PG和OSD之间的关系通过CRUSH算法得出的。常规这三个 OSD daemon 可以在一台机器上，也可以在不同机器上；那么根据 CRUSH 算法会尽可能的保证一个平衡，就是不在同一个机器上；毕竟Ceph中的数据是一个为平衡的状态，一切都是通过CRUSH 算法来实现的数据平衡，而 PG 本身是个有序列表，位于第一的位置是 master；这个列表的产生是由 monitor 来产生的；

寻址流程

File->Object映射 这次映射的目的是，将用户要 *** 作的File映射为RADOS能够处理的Object，其十分简单，本质上就是按照Object的最大尺寸（默认4M）对File进行切分，相当于磁盘阵列中的条带化过程。这种切分的好处有两个:一是让大小不限的File变成具有一致的最大尺寸、可以被RADOS高效管理的Object;二是让对单一File实施的串行处理变为对多个Object实施的并行化处理。每一个切分后产生的Object将获得唯一的oid,即Object ID,其产生方式也是线性映射,极其简单。 Object →PG映射 在File被映射为1个或多个Object之后,就需要将每个Object独立地映射到1个PG中去。这个映射过程也很简单,如图所示,其计算公式如下:Hash(oid) & mask -> pgid由此可见,其计算由两步组成。首先,使用Ceph系统指定的一个静态哈希算法计算oid的哈希值,将oid映射为一个近似均匀分布的伪随机值。然后,将这个伪随机值和mask按位相与,得到最终的PG序号(pgid) 。根据RADOS的设计,给定PG的总数为m(m应该为2的整数幂),则mask的值为m-1。因此,哈希值计算和按位与 *** 作的整体结果事实上是从所有m个PG中近似均匀地随机选择1个。基于这一机制,当有大量Object和大量PG时, RADOS能够保证Object和PG之间的近似均匀映射。又因为Object是由File切分而来的,大部分Object的尺寸相同,因此,这一映射最终保证了各个PG中存储的Object的总数据量近似均匀。这里反复强调了“大量” ,意思是只有当Object和PG的数量较多时,这种伪随机关系的近似均匀性才能成立, Ceph的数据存储均匀性才有保证。为保证“大量”的成立,一方面, Object的最大尺寸应该被合理配置,以使得同样数量的File能够被切分成更多的Object;另一方面, Ceph也推荐PG总数应该为OSD总数的数百倍,以保证有足够数量的PG可供映射。 PG→ OSD映射 第3次映射就是将作为Object的逻辑组织单元的PG映射到数据的实际存储单元OSD上。RADOS采用一个名为CRUSH的算法,将pgid代入其中,然后得到一组共n个OSD。这n个OSD共同负责存储和维护一个PG中的所有Objecto前面提到过, n的数值可以根据实际应用中对于可靠性的需求而配置,在生产环境下通常为3。具体到每个OSD,则由其上运行的OSD Daemon负责执行映射到本地的Object在本地文件系统中的存储、访问、元数据维护等 *** 作。和“Object →PG"映射中采用的哈希算法不同, CRUSH算法的结果不是绝对不变的,而会受到其他因素的影响。其影响因素主要有两个。一是当前系统状态,也就是在前面有所提及的集群运行图。当系统中的OSD状态、数量发生变化时,集群运行图也可能发生变化,而这种变化将会影响到PG与OSD之间的映射关系。二是存储策略配置。这里的策略主要与安全相关。利用策略配置,系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器或机架上,从而进一步改善存储的可靠性。因此,只有在系统状态和存储策略都不发生变化的时候, PG和OSD之间的映射关系才是固定不变的。在实际使用中,策略一经配置通常不会改变。而系统状态的改变或是因为设备损坏,或是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持,因而,即便PG与OSD之间的映射关系发生了变化,也并不会对应用产生影响。事实上, Ceph正是利用了CRUSH算法的动态特性,可以将一个PG根据需要动态迁移到不同的OSD组合上,从而自动化地实现高可靠性、数据分布再平衡等特性。之所以在此次映射中使用CRUSH算法,而不使用其他哈希算法,一方面原因是CRUSH算法具有上述可配置特性,可以根据管理员的配置参数决定OSD的物理位置映射策略;另一方面原因是CRUSH算法具有特殊的“稳定性" ,也即,当系统中加入新的OSD,导致系统规模增大时,大部分PG与OSD之间的映射关系不会发生改变,只有少部分PG的映射关系会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通哈希算法所能提供的。因此, CRUSH算法的设计也是Ceph的核心内容之一。 至此为止, Ceph通过3次映射,完成了从File到Object Object到PG,PG再到OSD的整个映射过程。从整个过程可以看到,这里没有任何的全局性查表 *** 作需求。至于唯一的全局性数据结构:集群运行图。它的维护和 *** 作都是轻量级的,不会对系统的可扩展性、性能等因素造成影响 。

存储过程总结：

1计算文件到对象的映射

2通过哈希算法计算计算出文件对应的pool的PG

3通过CRUSH把对象映射到PG中的OSD

4PG种的OSD将对象写入到磁盘

5主OSD将数据同步到备份OSD，待备份OSD返回确认

6主OSD的到备份OSD写完 *** 作以后给客户的返回写入成功

2 ceph的读写流程

当某个客户端需要向Ceph集群写入一个File时，首先需要在本地完成寻址流程，将File变为一个Object，然后找出存储该Object的一组共3个OSD，这3个OSD具有各自不同的序号，序号最靠前的那个OSD就是这一组中的Primary OSD，而后两个则依次Secondary OSD和Tertiary OSD。找出3个OSD后，客户端将直接和Primary OSD进行通信，发起写入 *** 作(步骤1)。 Primary OSD收到请求后，分别向Secondary OSD和Tertiary OSD发起写人 *** 作(步骤2和步骤3)。当Secondary OSD和Tertiary OSD各自完成写入 *** 作后，将分别向Primary OSD发送确认信息(步骤4和步骤5)。当Primary OSD确认其他两个OSD的写入完成后，则自己也完成数据写入，并向客户端确认Object写入 *** 作完成(步骤6)。之所以采用这样的写入流程，本质上是为了保证写入过程中的可靠性，尽可能避免出现数据丢失的情况。同时，由于客户端只需要向Primary OSD发送数据，因此在互联网使用场景下的外网带宽和整体访问延迟又得到了一定程度的优化。当然，这种可靠性机制必然导致较长的延迟，特别是，如果等到所有的OSD都将数据写入磁盘后再向客户端发送确认信号，则整体延迟可能难以忍受。因此， Ceph可以分两次向客户端进行确认。当各个OSD都将数据写入内存缓冲区后，就先向客户端发送一次确认，此时客户端即可以向下执行。待各个OSD都将数据写入磁盘后，会向客户端发送一个最终确认信号，此时客户端可以根据需要删除本地数据。分析上述流程可以看出，在正常情况下，客户端可以独立完成OSD寻址 *** 作，而不必依赖于其他系统模块。因此，大量的客户端可以同时和大量的OSD进行并行 *** 作。同时，如果一个File被切分成多个Object，这多个Object也可被并行发送至多个OSD上。从OSD的角度来看，由于同一个OSD在不同的PG中的角色不同，因此，其工作压力也可以被尽可能均匀地分担，从而避免单个OSD变成性能瓶颈。

问：为什么要设计三层映射而不是一层？

答：如果将object直接映射到一组OSD上，如果这种算法是固定的哈希算法，则意味着一个object被固定映射在一组OSD上，当其中一个OSD损坏时，object也无法部署到新的OSD上(因为映射函数不允许)。

如果设计一个动态算法(例如CRUSH算法)来完成这一映射，结果将是各个OSD所处理的本地元数据暴增，由此带来的计算复杂度和维护工作量也是难以承受的。

综上所诉，引入PG的好处至少有二：一方面试下呢object和OSD之间的动态映射，从而为Ceph的可靠性、自动化等特性的实现留下了空间；另一方面也有效简化了数据的存储组织，大大降低了系统的维护管理开销。

1准备工作

时间同步`

安装ntpdate（时间同步工具）

# apt install ntpate

0 ntpdate time1aliyuncom

echo'0 ntpdate time1aliyuncom'>> /var/spool/cron/crontabs/root

或者 可以通过

ansible all-mshell-a"echo  '0 ntpdate time1aliyuncom' >> /var/spool/cron/crontabs/root"

关闭 selinux 和防火墙

root@node1:~# sudo ufw status  ##查看状态

Status: inactive

root@node1:~# sudo ufw disable

Firewall stopped and disabled on system startup##禁用

root@node1:~#

配置域名解析或通过 DNS 解析

root@node1:~# cat /etc/hosts

127001 localhost

root@node1:~# hostnamectl set-hostname 对应的名称

## 以下是新增的 可以按照自己的习惯配置

192168106101  node1

192168106102  node2

192168106103  node3

安装python

root@node1:~# apt install python  ##python2

源修改成国内源  -- 具体步骤自行百度

>WindowsServer2012R2供给非常丰富的新增和增强功用和特性，规模掩盖服务器虚拟化、存储、软件界说网络、服务器和自动化、Web和应用程序渠道、拜访和信息保护、虚拟桌面根底结构等。win2012serverr2的文件服务器高可用装备能够协助用户在一台服务器宕机的时分，另一台能够持续为用户服务。1、首先装置“DFS复制”与“DFS命名空间”,点击“下一步”，断定挑选内容项;2、装置完结，点击“封闭”,点击“工具”挑选“DFSManagement”;3、右击“命名空间”挑选“新建命名空间(N)”，指定命名空间服务器的核算机名，下一步，点击“创立”;4、如果在完成高可用一台DFS服务器是不行的，这时分需求再增加一台服务器，右击新建的命名空间，点击“增加命名空间服务器(N)”，经过编辑设置能够设置权限，点击“断定”5、这时分咱们来拜访一下同享一下，能够正常拜访，装备成功。

1、分布式存储优势

分布式存储可以使生产系统在线运行的情况下进行纵向扩展（Scale-Up）或横向扩展（Scale-Out），且存储系统在扩展后可以达到容量与性能均线性扩展的效果。其具有以下特性：

高性能

分布式存储系统能够将所有存储节点的处理器资源、硬盘资源、网络资源进行整合，将任务切分给多台存储节点，进行并发数据处理，避免了单个硬盘或设备造成的瓶颈，提升整个集群的处理能力。分布式存储系统具有良好的性能扩展能力，可以满足应用程序对存储性能不断增长的要求。

高扩展性

分布式存储系统通过扩展集群存储节点规模从而提高系统存储容量、计算和性能的能力，通过增加和升级服务器硬件，或者指通过增加存储节点数量来提升服务能力。分布式存储系统支持在线增加存储节点，对前端业务透明，系统整体性能与存储节点数量呈线性关系。

高可用性

分布式存储系统同时基于硬件及软件设计了高可用机制，在面对多种异常时（如存储节点宕机、网络中断、硬盘故障、数据损坏等）仍可提供正常服务，提高分布式存储系统硬件的可用性可以通过增加存储节点数量或者采用多种硬件冗余机制保证。分布式存储系统多采用副本机制或纠删码机制保证数据的高可用性，副本机制可以提供较高的数据冗余度，但会降低存储系统有效空间的利用率，纠删码机制可以在保证一定数据冗余度的情况下，大幅提高存储系统的有效空间利用率。

高安全性

分布式存储系统支持可靠的权限控制及互信确认机制，同时采用私有的数据切片及数据编码机制，可以从多重角度保证集群系统不受恶意访问和攻击，保护存储数据不被窃取。

2、分布式存储应用场景

分布式的“四高”特性，使得其在高性能计算、大数据视频云及大数据分析等应用场景中有着广泛的应用。

高性能计算场景

在如气象气候、地质勘探、航空航天、工程计算、材料工程等领域，基于集群的高性能计算，已成为必需的辅助工具。集群系统有极强的伸缩性，可通过在集群中增加或删减节点的方式，在不影响原有应用与计算任务的情况下，随时增加和降低系统的处理能力。根据不同的计算模式与规模，构成集群系统的节点数可以从几个到成千上万个。这些业务对后端的存储系统提出了新的需求，包括统一的存储空间、高效率的文件检索、高带宽的吞吐性能，高可靠的数据安全保障等。

大数据视频云应用场景

随着视频高清技术及超高清技术的普及，视频大数据应用场景，如雪亮工程、平安城市、广电媒资、影视制作、视频网站等领域，对存储设备提出了大容量、高读写性能、高可靠性、低延时及可扩展性等需求。针对这样大规模视频数据应用场景，就需要一个技术先进、性能优越的存储系统作为后端数据存储的支撑者。

大数据分析应用场景

伴随着互联网技术及人工智能的发展，各种基于海量用户/数据/终端的大数据分析及人工智能业务模式不断涌现，同样需要充分考虑存储功能集成度、数据安全性、数据稳定性，系统可扩展性、性能及成本各方面因素。

在数据爆发增长的“数字时代”，软件定义的分布式存储是存储技术高速发展的结晶，并具有着很大的成长空间，必将应用于更广泛的大数据业务场景。

---