「java连接ceph」java连接mysql数据库增删改查

本篇文章给大家谈谈java连接ceph，以及java连接mysql数据库增删改查对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、ceph（第二步） 三节点部署（ceph-deploy）
• 2、java如何操作librados获取集群的osd状态及mon状态？
• 3、⑩ OpenStack高可用集群部署方案(train版)—OpenStack对接Ceph存储
• 4、「精心整理」Ceph搭建硬件建议详解

ceph（第二步） 三节点部署（ceph-deploy）

使用 ceph-deploy 工具部署 ceph 存储集群。

使用虚拟机构建三节点 ceph 存储集群。

全篇使用 root 权限。

虚拟化软件：vmware

虚拟机操作系统：centos 7.6

每台虚拟机配置：2G内存，1块系统盘（50G），2块ceph将使用的硬盘（每块20G）

虚拟机网络：一条虚拟机间互通，并且可以上网的网络即可（NAT）。

总共三台虚拟机：ceph01、ceph02、ceph03

ceph 版本：nautilus

ceph-deploy 版本：2.0.1

当前时间： 2019.10

部署过程整体描述：

首先选出一台机器作为部署节点，部署节点负责为机器部署 ceph 软件。这里直接选择 ceph01 作为部署节点。

我这里 ceph01、ceph02、ceph03 对应的地址分别为：

10.10.10.31、10.10.10.32、10.10.10.33

所有机器均关闭掉防火墙。

所有机器均配置 yum 国内加速源：

所有机器均配置 pip 国内加速源：

这里配置的是部署节点到其它机器间的主机解析。

vim /etc/hosts 添加如下内容：

这里配置的是部署节点到其它机器间的免密登录。

注意：以下每行命令执行后都需要输入密码，不能直接全部复制粘贴。

命令参考如下，尽量每个节点都测试一下

所有机器执行如下命令：

注意！当前步骤十分重要。

在 ceph 中读取了 hostname 命令产生的结果。

因此在每个节点上均需修改自己的 hostname。命令参考：

进入到 ceph01 节点上：

按照此方法修改其它节点的 hostname。

主要分两步：

第一步，安装 ceph-deploy

第二步，使用 ceph-deploy 安装 ceph 组件。

该步骤所有命令均在部署节点上执行。

安装 ceph-deploy:

该步骤所有命令均在部署节点上执行。

vim /opt/ceph-deploy/ceph.conf

在 global 中增加：

当前命令执行以后，可以在当前目录下发现许多的 keyring 文件，这是连接其它节点的凭据。以后的 ceph-deploy 命令均在当前目录下执行才可正常使用。

将当前临时文件夹下的配置文件同步到所有节点的 /etc/ceph/ 下

我这个环境有三台虚拟机，每台虚拟机上有额外2块硬盘用于 ceph 集群，它们是 sdb、sdc。这个要根据自己的环境找到正确的硬盘。

命令参考如下：

其中 /dev/sdb ceph01 ，表示 ceph01 节点上的 /dev/sdb 硬盘。

命令执行完以后，基础的环境就算搭建完成了。可以执行如下命令查看集群的状态：

ceph 健康： ceph health

ceph 集群详细状态：ceph -s

ceph 集群 osd 状态：ceph osd tree

至此，该集群还处于一个基础的状态，并不能正常使用。

接下来需要配置 ceph pool 相关信息，以及安装配置 rgw 从而使用对象存储功能。

vim /opt/ceph-deploy/ceph.conf

在 global 中增加如下：

其中 pg num 需要计算得出，pgp num 与 pg num 保持一致。

粗略的计算方法：

( osd 数量 * 100 ) / 池副本数。

同步配置文件：

vim /opt/ceph-deploy/ceph.conf

增加如下内容:

整体配置如下：

安装 rgw：

至此，我们可以去创建一个 pool，并上传文件测试集群了。

这个时候执行 ceph -s

可以看到集群报了 warn 信息，如下：

这不是因为我们哪里配置有问题，这是 ceph 的某个告警配置。当某个 osd 的 pg 小于 30 时会发出告警。现在可以忽略这个问题。ceph 提供这个配置，可能是担心集群在未来使用中出现 pg 分布不均匀的情况。

参考：

查看池列表：ceph osd lspools

ceph 默认的池已经创建一些 pg。为了解决前面的告警，我们需要满足每个 osd 都有超过30个 pg，因此创建一个具有80个 pg 的池。

（此时用 ceph -s 可以看到集群状态又是 HEALTH_OK 了）

命令参考：

可以看到文件已经上传上去了，并且叫 test-object-1

rados get test-object-1 /tmp/test-object-1 -p mytest

可以看到两个文件的内容是一样的，到此，基本的部署及使用均正常了。

在 ceph 中，hostname 是一个非常重要的属性。

hostname 命令只可以临时改变当前主机的主机名，并不会永久生效。

目前已知两种方式会永久影响主机名。

第一种情况，很直观，不再多做介绍。

第二种情况时：

这样的配置，会让通过 10.10.10.31 地址访问进来的连接所识别到的主机名改为 ceph01。

在本环境中，不同的 ceph 节点之间通过 10.10.10.0/24 地址进行通信，所以只需要为该地址配置主机名。

在 ceph 中，如果主机名混乱，会发生什么？

ceph osd tree 这个命令可以让你看到主机名混乱带来的后果：

如果糟糕的事情已经发生了，我们只需要修改好主机名，然后重启机器，一切都会恢复正常：

第一种方式的优先级高于第二种。

因此只需要更改 /etc/hostname 即可。文件内容参考如下：

无

java如何操作librados获取集群的osd状态及mon状态？

一个Ceph客户端，通过librados直接与OSD交互，来存储和取出数据。为了与OSD交互，客户端应用必须直接调用librados，连接一个Ceph Monitor。一旦连接好以后，librados会从Monitor处取回一个Cluster map。当客户端的应用想读或者取数据的时候，它会创建一个I/O上下文并且与一个pool绑定。通过这个I/O上下文，客户端将Object的名字提供给librados，然后librados会根据Object的名字和Cluster map计算出相应的PG和OSD的位置。然后客户端就可以读或者写数据。客户端的应用无需知道这个集群的拓扑结构。

1. 给rados_create()使用的User ID和给rados_create2()使用的user name，其中后者更受推荐

2. Cephx authentication key

3. Monitor的ID和IP地址

4. 日志级别

5. 调试级别

所以，从你的app使用集群的步骤如下：1. 创建一个cluster handle，它将被用来连接集群；2. 使用这个handle来连接集群。为了连接集群，这个app必须提供一个monitor地址，一个用户名，还有一个authentication key。

⑩ OpenStack高可用集群部署方案(train版)—OpenStack对接Ceph存储

参考Ceph官方安装文档

Openstack环境中，数据存储可分为临时性存储与永久性存储。

临时性存储：主要由本地文件系统提供，并主要用于nova虚拟机的本地系统与临时数据盘，以及存储glance上传的系统镜像；

永久性存储：主要由cinder提供的块存储与swift提供的对象存储构成，以cinder提供的块存储应用最为广泛，块存储通常以云盘的形式挂载到虚拟机中使用。

Openstack中需要进行数据存储的三大项目主要是nova项目（虚拟机镜像文件），glance项目（共用模版镜像）与cinder项目（块存储）。

下图为cinder，glance与nova访问ceph集群的逻辑图：

ceph与openstack集成主要用到ceph的rbd服务，ceph底层为rados存储集群，ceph通过librados库实现对底层rados的访问；

openstack各项目客户端调用librbd，再由librbd调用librados访问底层rados；

实际使用中，nova需要使用libvirtdriver驱动以通过libvirt与qemu调用librbd；cinder与glance可直接调用librbd；

写入ceph集群的数据被条带切分成多个object，object通过hash函数映射到pg（构成pg容器池pool），然后pg通过几圈crush算法近似均匀地映射到物理存储设备osd（osd是基于文件系统的物理存储设备，如xfs，ext4等）。

CEPH PG数量设置与详细介绍

在创建池之前要设置一下每个OSD的最大PG 数量

PG PGP官方计算公式计算器

参数解释：

依据参数使用公式计算新的 PG 的数目:

PG 总数= ((OSD总数*100)/最大副本数)/池数

3x100/3/3=33.33 ;舍入到2的N次幕为32

openstack集群作为ceph的客户端；下面需要再openstack集群上进行ceph客户端的环境配置

在openstack所有控制和计算节点安装ceph Octopus源码包，centos8有默认安装，但是版本一定要跟连接的ceph版本一致

glance-api 服务运行在3个控制节点， 因此三台控制节点都必须安装

cinder-volume 与 nova-compute 服务运行在3个计算（存储）节点； 因此三台计算节点都必须安装

将配置文件和密钥复制到openstack集群各节点

配置文件就是生成的ceph.conf；而密钥是 ceph.client.admin.keyring ，当使用ceph客户端连接至ceph集群时需要使用的密默认密钥，这里我们所有节点都要复制，命令如下

※Glance 作为openstack中镜像服务，支持多种适配器，支持将镜像存放到本地文件系统，http服务器，ceph分布式文件系统，glusterfs和sleepdog等开源的分布式文件系统上。目前glance采用的是本地filesystem的方式存储，存放在默认的路径 /var/lib/glance/images 下，当把本地的文件系统修改为分布式的文件系统ceph之后，原本在系统中镜像将无法使用，所以建议当前的镜像删除，部署好ceph之后，再统一上传至ceph中存储。

※Nova 负责虚拟机的生命周期管理，包括创建，删除，重建，开机，关机，重启，快照等，作为openstack的核心，nova负责IaaS中计算重要的职责，其中nova的存储格外重要，默认情况下，nova将instance的数据存放在/var/lib/nova/instances/%UUID目录下，使用本地的存储空间。使用这种方式带来的好处是:简单，易实现，速度快，故障域在一个可控制的范围内。然而，缺点也非常明显：compute出故障，上面的虚拟机down机时间长，没法快速恢复，此外，一些特性如热迁移live-migration,虚拟机容灾nova evacuate等高级特性，将无法使用，对于后期的云平台建设，有明显的缺陷。对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt，因为 librbd 早已原生集成到其中。

※Cinder 为 OpenStack 提供卷服务，支持非常广泛的后端存储类型。对接 Ceph 后，Cinder 创建的 Volume 本质就是 Ceph RBD 的块设备，当 Volume 被虚拟机挂载后，Libvirt 会以 rbd 协议的方式使用这些 Disk 设备。除了 cinder-volume 之后，Cinder 的 Backup 服务也可以对接 Ceph，将备份的 Image 以对象或块设备的形式上传到 Ceph 集群。

使用ceph的rbd接口，需要通过libvirt，所以需要在客户端机器上安装libvirt和qemu，关于ceph和openstack结合的结构如下，同时，在openstack中，需要用到存储的地方有三个:

为 Glance、Nova、Cinder 创建专用的RBD Pools池

需要配置hosts解析文件，这里最开始已经配置完成，如未添加hosts解析需要进行配置

在cephnode01管理节点上操作 ；命名为：volumes，vms，images

记录：删除存储池的操作

在cephnode01管理节点上操作 ；

针对pool设置权限，pool名对应创建的pool

nova-compute与cinder-volume都部署在计算节点 ，不必重复操作,如果计算节点与存储节点分离需要分别推送；

全部计算节点配置；以compute01节点为例；

Glance 为 OpenStack 提供镜像及其元数据注册服务，Glance 支持对接多种后端存储。与 Ceph 完成对接后，Glance 上传的 Image 会作为块设备储存在 Ceph 集群中。新版本的 Glance 也开始支持 enabled_backends 了，可以同时对接多个存储提供商。

写时复制技术(copy-on-write) ：内核只为新生成的子进程创建虚拟空间结构，它们复制于父进程的虚拟空间结构，但是不为这些段分配物理内存，它们共享父进程的物理空间，当父子进程中有更改相应的段的行为发生时，再为子进程相应的段分配物理空间。写时复制技术大大降低了进程对资源的浪费。

全部控制节点进行配置；以controller01节点为例；

只修改涉及glance集成ceph的相关配置

变更配置文件，重启服务

ceph官网介绍 QEMU和块设备

对接 Ceph 之后，通常会以 RAW 格式创建 Glance Image，而不再使用 QCOW2 格式，否则创建虚拟机时需要进行镜像复制，没有利用 Ceph RBD COW 的优秀特性。

总结

将openstack集群中的glance镜像的数据存储到ceph中是一种非常好的解决方案，既能够保障镜像数据的安全性，同时glance和nova在同个存储池中，能够基于copy-on-write(写时复制)的方式快速创建虚拟机，能够在秒级为单位实现vm的创建。

全部计算节点进行配置； 以compute01节点为例；只修改glance集成ceph的相关配置

全部计算节点重启cinder-volume服务；

任意openstack控制节点上查看;

在任意控制节点为cinder的ceph后端存储创建对应的type，在配置多存储后端时可区分类型；

为ceph type设置扩展规格，键值 volume_backend_name ，value值 ceph

任意控制节点上创建一个1GB的卷 ；最后的数字1代表容量为1G

查看创建好的卷

openstack创建一个空白 Volume，Ceph相当于执行了以下指令

从镜像创建 Volume 的时候应用了 Ceph RBD COW Clone 功能，这是通过 glance-api.conf [DEFAULT] show_image_direct_url = True 来开启。这个配置项的作用是持久化 Image 的 location，此时 Glance RBD Driver 才可以通过 Image location 执行 Clone 操作。并且还会根据指定的 Volume Size 来调整 RBD Image 的 Size。

一直存在的cirros_qcow2镜像为对接ceph之前的镜像，现在已无法使用，所以将之删除

在openstack上从镜像创建一个Volume，Ceph相当于执行了以下指令

任意控制节点操作；

查看快照详细信息

在openstack上对镜像的卷创建快照，Ceph相当于执行了以下指令

如果说快照时一个时间机器，那么备份就是一个异地的时间机器，它具有容灾的含义。所以一般来说 Ceph Pool backup 应该与 Pool images、volumes 以及 vms 处于不同的灾备隔离域。

一般的，备份具有以下类型：

在虚拟磁盘映像的计算节点上使用本地存储有一些缺点：

Nova 为 OpenStack 提供计算服务，对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt ，因为 librbd 早已原生集成到其中。

如果需要从ceph rbd中启动虚拟机，必须将ceph配置为nova的临时后端；

推荐在计算节点的配置文件中启用rbd cache功能；

为了便于故障排查，配置admin socket参数，这样每个使用ceph rbd的虚拟机都有1个socket将有利于虚拟机性能分析与故障解决；

相关配置只涉及全部计算节点ceph.conf文件的[client]与[client.cinder]字段，以compute163节点为例

全部计算节点配置 ceph.conf文件相关的 [client] 与 [client.cinder] 字段，以compute01节点为例；

在全部计算节点配置nova后端使用ceph集群的vms池，以compute01节点为例；

在全部计算节点操作;

在全部计算节点操作，以compute01节点为例；

以下给出libvirtd.conf文件的修改处所在的行num

「精心整理」Ceph搭建硬件建议详解

Ceph是专为在商品硬件上运行而设计的，这使得构建和维护超大规模的数据集群在经济上是可行的。当规划出你的集群硬件时，你需要平衡一些考虑因素，包括故障域和潜在的性能问题。硬件规划应该包括将Ceph守护进程和其他使用Ceph的进程分布在许多主机上。一般来说，我们 建议在为该类型的守护进程配置的主机上运行特定的Ceph守护进程。我们建议使用其他主机来处理使用您的数据集群的进程（例如OpenStack、CloudStack）

Ceph元数据服务器会动态地重新分配负载，这对CPU来说是很有必要的。所以你的元数据处理器应该有相当大的处理能力（四核心或更高的CPU）。Ceph OSDs 运行RADOS服务，用CRUSH计算数据放置、复制数据，并维护自己的集群地图副本。因此，OSD应该有合理的处理能力（例如双核处理器）。监视器只是维护集群映射的主副本，所以监视器不需要CPU密集型的处理能力。

除了Ceph守护进程之外，你还必须考虑主机是否会运行CPU密集型进程，例如，如果您的主机将运行计算虚拟机（例如，OpenStack Nova)，您需要确保这些其他进程为Ceph守护进程留下足够的处理能力。我们建议在单独的主机上运行额外的CPU密集型进程。

一般来说，RAM越多越好

监视器和管理器守护进程的内存使用量一般会随着集群的大小而变化。

对于小型集群，一般来说，1-2GB就足够了。

对于大型集群，你应该提供更多（5-10GB）。

你可能还需要考虑调整设置，如mon_osd_cache_size或 rocksdb_cache_size

Bluestore使用自己的内存来缓存数据，而不是依赖操作系统的页面缓存。在BlueStore中，你可以通过osd_memory_target选项调整OSD_memory_target的内存量

•通常不建议将osd_memory_target设置为2GB以下，可能会将内存保持在2GB以下，同时也可能导致性能极慢。•将内存目标设置在2Gb和4Gb之间通常有效，但可能会导致性能下降，因为元数据可能在IO期间从磁盘读取，除非活动数据集相对较小。•4GB是目前默认的osd_memory_target大小，这样设置的目的是为了平衡内存需求和OSD的性能，以满足典型的使用情况•设置osd_memory_target高于4GB时，当有许多（小的）或大的（256GB/OSD)数据集被处理时，可能会提高性能。

重要：

OSD的内存自动调整是“尽力而为”。虽然OSD可能会解除内存映射，让内核回收内存，但不能保证内核会在任何特定的时间框架内实际回收释放的内存。这在旧版本的Ceph中尤其如此，因为透明的巨页会阻止内核从碎片化的巨页中回收内存。现代版本的Ceph在应用级禁用透明巨页以避免这种情况，但这仍然不能保证内核会立即回收未映射的内存。OSD有时仍然可能会超过它的内存目标。我们建议在系统中保留20%左右的额外内存，以防止OSD在临时高峰期或由于内核延迟回收空闲页而导致的OSD出现OOM。这个值可能会比需要的多或少取决于系统的具体配置。

在使用传统的FileStore后端时，页面缓存是用来缓存数据的，所以一般不需要调优，OSD的内存消耗一般与系统中每个守护进程的PG数量有关

仔细规划你的数据存储配置。在规划数据存储时，需要考虑重大的成本和性能权衡。同时进行操作系统操作，以及多个守护进程对单个驱动器同时请求读取和写入操作，会大大降低性能。

重要

由于Ceph在发送ACK之前必须先将所有数据写入日志（至少对XFS来说），所以日志和OSD的性能平衡真的很重要！在这里，Ceph的日志和OSD的性能是非常重要的。

OSD应该有足够的硬盘空间来存放对象数据。我们建议硬盘驱动器的最小容量为1T。考虑到较大磁盘的每GB的成本优势。我们建议将硬盘驱动器的价格除以千兆字节，得出每千兆字节的成本，因为较大的驱动器可能会对每千兆字节的成本有很大影响。例如，价格为75美元的1T硬盘，每千兆字节的成本为0.07美元。相比之下，价格为150美元的3T硬盘的成本为每千兆字节0.05美元。在上述例子中，使用1T硬盘通常会使每千兆字节的成本增加40%——使集群的成本效益大大降低。

Tips: 在一个磁盘上运行多个OSD，无论分区如何，都不是一个好主意

Tips: 在单一磁盘上运行OSD和显示器或者元数据服务器，无论分区如何，都不是一个好主意

存储驱动器在寻求时间、访问时间、读取和写入时间以及总吞吐量方面受到限制。这些物理限制会影响整体系统性能，特别是在恢复期间。我们建议为操作系统和软件使用一个专门驱动器，并且您在主机上运行的每个Ceph OSD daemon使用一个驱动器。大多数“慢OSD”问题的出现是由于在同一个驱动器上运行一个操作系统，多个OSD，或多个日志。由于在一个小型集群上排除性能问题的成本超过了额外的磁盘驱动器的成本，因此您可以通过避免过度消耗OSD存储驱动器的诱惑来优化您的集群设计规划。

您可以在每个硬盘驱动器上运行多个Ceph OSD Daemons，但这可能会导致资源征用，降低整体吞吐量。你可以在同一硬盘上存储日志和对象数据，但这可能会增加写日志和ACK到客户端所需要的时间。Ceph必须先写入到日志，然后再进行ACK写入。

ack写入：完成此类写入之后，将向客户端发送一个成功写入的ACK，所以称之为ACK写入

Ceph最佳实践规定，你应该在不同的驱动器上运行操作系统、OSD数据和OSD日志

提高性能的一个机会是使用固态硬盘来减少随机访问时间和读取延迟，同时加快吞吐量。与机械硬盘相比，固态硬盘每千兆字节的成本往往超过10倍以上，但固态硬盘的访问时间往往比机械硬盘至少快100倍。

固态硬盘没有活动的机械部件，所以他们不一定会受到与机械硬盘相同的限制。但固态硬盘确实有很大的局限性。在评估固态硬盘时，重要的是考虑顺序读取和写入的性能。当为多个OSD存储多个日志时，具有400MB/S顺序写入吞吐量的SSD可能比具有120MB/s顺序写入吞吐量的SSD性能要好的多。

重要

我们建议探索使用固态硬盘来提高性能。然而，在对SSD进行重大投资之前，我们强烈建议在审查SSD的性能指标和测试配置中测试SSD的性能

由于固态硬盘没有活动的机械部件，所以在Ceph中不需要使用大量存储空间的区域（如日志）使用固态硬盘是很有意义的。相对便宜的SSD可能会吸引你的经济意识。请谨慎使用。在选择使用Ceph的SSD时，仅有可接受的IOPS是不够的。日志和SSD有几个重要的性能注意事项：

•写入密集型语义：日志涉及到写密集型语义，因此您应该确保您选择部署的SSD在写入数据时的性能相当于或优于机械硬盘。廉价的固态硬盘在加速访问时间的同时，可能会引入写入延时，因为有时高性能硬盘的写入速度会比市场上一些更经济的固态硬盘快，因此，您应该确保您选择的固态硬盘在写入数据时的性能与机械硬盘相当或更好。•顺序写入：当您在SSD上存储多个日志时，您必须考虑到SSD的顺序写入限制，因为它们可能会同时处理对多个OSD日志的写入请求。•分区对齐：SSD性能的一个常见问题是，人们喜欢将硬盘分区作为最佳做法，但往往忽略了对SSD的正确分区对齐，这样会导致SSD的数据传输速度更慢。确保SSD分区正确对齐

虽然固态硬盘对于对象存储的成本较高，但通过将OSD的日志存储在固态硬盘上，并将OSD的对象存储存储在独立的机械硬盘上，可能会看到性能的显著提升。osd journal配置设置默认为/var/lib/ceph/osd/$cluster-id/journal。您可以将此路径挂载到SSD或者SSD分区，使其不只是与对象数据存储在同一硬盘上。

Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储隔离开来。Ceph为CephFS元数据提供了一个默认的元数据池。你永远不必为CephFS元数据创建一个池，但你可以为你的CephFS元数据池创建一个只指向主机的SSD存储介质的CRUSH映射层次结构。详情请参见将池映射到不同类型的OSDs。

•意思是可以将一个池的所有数据都存储到SSD类型的OSD

磁盘控制器对写入吞吐量也有很大影响。在选择磁盘控制器时要慎重考虑，确保不会造成性能瓶颈。

Tips：Ceph博客通常是对Ceph性能问题的一个很好的信息来源。更多详情请参加Ceph写吞吐量1和Ceph写吞吐量2

••

你可以在每台主机上运行多个OSD，但你应该确保你的OSD硬盘的总吞吐量之和不超过服务于客户端读取或写入所需的网络带宽。你还应该考虑集群在每台主机上存储的数据占整体数据的百分比。如果某个特定主机上的百分比很大，而该主机出现故障，可能会导致超过  full ratio 等问题，从而导致Ceph停止工作，作为防止数据丢失的安全规范措施。

当你在每个主机上运行多个OSD时，你还需要确保内核是最新的。请参阅OS建议中关于glibc和syncfs（2）的说明，以确保你的硬件在每个主机上运行多个OSD时，能按照预期的方式执行。

考虑从机架上的10Gbps+网络开始。在1Gbps网络上复制1TB的数据需要3个小时，而10TB需要30个小时！相比之下，使用10Gbps网络，复制时间分别需要20分钟和1小时。在petabyte规模的集群中，OSD磁盘的故障应该是一种预期，而不是例外。在考虑到价格/性能权衡的情况下，系统管理员会很欣赏PG能尽快从降级状态恢复到活动+清洁状态。此外，一些部署工具采用VLANS使硬件和网络布线更易于管理。使用802.1q协议的运营成本节省所抵消。当使用VLAN来处理集群和计算堆栈（例如OpenStack、CloudStack等）之间的VM流量时，也值得考虑10G以太网。每个网络的架上路由器还需要能够与吞吐量更快的骨干路由器进行通信，例如40Gbps到100Gbps。

您的服务器硬件应该有一个底层管理控制器（BMC）。管理和部署工具也可能会大量使用BMC，因此要考虑带外网络的管理成本/收益权衡。Hypervisor SSH访问、VM镜像上传、操作系统镜像安装、管理套接字等都会给网络带来巨大的负载。运行三个网络可能看起来似乎矫枉过正，但每个流量路径都代表了潜在的容量、吞吐量和/或性能瓶颈，在部署大规模数据集群之前，您应该仔细考虑。

BMC：Baseboard Management Controller，基板管理控制器

带外网络：OOB，全程Out Of Band，一套与任何业务数据网络没有关联的独立网络，在任何时候——即便是业务网络终端的情况下，网络控制中心都可以通过带外网络连接到各个服务器或者网络设备的管理接口或者console.

故障域是指任何阻止一个或多个OSD的故障。这可能是主机上的守护进程停止；硬盘故障、操作系统崩溃、网卡故障、电源故障、网络中断、断电等等。在规划硬件需求的时候，你必须平衡一下，把太多的责任放在太少的故障域中来降低成本，以及隔离每个潜在故障域所带来的额外成本

Ceph可以在廉价的商品硬件上运行。小型生产集群和开发集群可以用适中的硬件成功运行

进程类型硬件类型建议的最低标准

ceph-osd Processor最低一核

200-500MB/s 单核心

1000-3000IOPS 单核心

结果是复制之前的结果

结果可能会因为不同的CPU型号和Ceph功能而不同（纠删码池、压缩等）

ARM处理器可能会需要更多的核心

实际性能取决于许多因素，包括磁盘、网络、客户端吞吐量和延迟。我们强烈建议进行基准测试

RAM每个守护进程4GB以上（越多越好）

2-4GB 可以正常工作（可能会很慢）

低于2GB是不推荐的

Volume Storage每个守护进程对应一块硬盘

DB/WAL每个守护进程对应一个SSD分区（可选）

Network最少一块千兆以上的网卡（万兆网卡是被推荐的） ceph-mon Processor最低一核

RAM每个进程2GB以上的内存

Disk Space每进程10GB以上的硬盘空间

Network最少一块千兆以上的网卡 ceph-mds Processor最低一核

RAM每个进程2GB以上的内存

Disk Space每个进程1MB以上的硬盘空间

Network最少一块千兆以上的网卡

关于java连接ceph和java连接mysql数据库增删改查的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。