点击围观  ...

管理和定制CRUSH Map CRUSH和目标放置策略 Ceph 通过一种称为 CRUSH(可伸缩哈希下的受控复制)的放置算法来计算哪些osd应该持有哪些对象，对象被分配到放置组(pg)， CRUSH 决定这些 放置组 应该使用哪个 osd来存储它们的对象,即 crush 决定了 pg 到 osd 的映射关系。 CRUSH的算法 CRUSH算法 使 Ceph客户端能够直接与 osd通信，这避免了集中式服务瓶颈，Ceph客户端和 osd使用CRUSH 算法高效地计算对象位置的信息，而不是依赖于一个中央查找表。 Ceph 客户端检索集群映射，并使用 CRUSH Map 从算法上确定如何存储和检索数据，通过避免单点故障和性能瓶颈，这为Ceph 集群提供了大规模的可伸缩性 CRUSH算法 的作用是将 数据统一分布在对象存储中，管理复制，并响应系统增长和硬件故障，当 新增OSD或已有OSD或OSD主机故障 时，Ceph通过CRUSH在主OSD间实现集群对象的再平衡 CRUSH Map 组件 从概念上讲，一个CRUSH map包含两个主要组件： CRUSH层次结构 这将列出所有可用的 osd，并将它们组织成树状的桶结构 CRUSH层次结构通常用来表示osd的位置，默认情况下，有一个root桶代表整个层次结构，其中包含每个OSD主机的一个主机桶 [root@clienta ~]# ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.09796 root default -3 0.03918 host serverc 0 hdd 0.00980 osd.0 up 1.00000 1.00000 1 hdd 0.00980 osd.1 up 1.00000 1.00000 2 hdd 0.00980 osd.2 up 1.00000 1.00000 9 hdd 0.00980 osd.9 up 1.00000 1.00000 -5 0.02939 host serverd 3 hdd 0.00980 osd.3 up 1.00000 1.00000 4 hdd 0.00980 osd.4 up 1.00000 1.00000 5 hdd 0.00980 osd.5 up 1.00000 1.00000 -7 0.02939 host servere 6 hdd 0.00980 osd.6 up 1.00000 1.00000 7 hdd 0.00980 osd.7 up 1.00000 1.00000 8 hdd 0.00980 osd.8 up 1.00000 1.00000 OSD是树的叶子节点，默认情况下，同一个OSD主机上的所有OSD都放在该主机的桶中，可以自定义树状结构，重新排列，增加层次，将OSD主机分组到不同的桶中，表示其在不同的服务器机架或数据中心的位置 至少有一条CRUSH规则 CRUSH 规则决定了如何从这些桶中分配放置组的osd，这决定了这些放置组的对象的存储位置。不同的池可能会使用不同的CRUSH规则 CRUSH  桶类型 CRUSH 层次结构将 osd 组织成一个由不同容器组成的树，称为桶。对于大型安装，可以创建特定的层次结构来描述存储基础设施：数据中心、机架、主机和OSD设备。 通过创建一个CRUSH map规则，可以使 Ceph 将一个对象的副本放在独立服务器上的osd上，放在不同机架的服务器上，甚至放在不同数据中心的服务器上 总而言之，桶是 CRUSH层次结构中的容器或分支。osd设备是CRUSH等级中的叶子 一些最重要的桶属性有: 桶ID，这些id为负数，以便与存储设备的id区分开来 桶的名称 桶的类型，默认映射定义了几种类型，可以使用ceph osd crush dump命令检索这些类型 [root@clienta ~]# ceph osd crush dump | grep type_name "type_name": "root", "type_name": "root", "type_name": "host", "type_name": "host", "type_name": "host", "type_name": "host", "type_name": "host", "type_name": "host", 桶类型包括root、region、datacenter、room、pod、pdu、row、rack、chassis和host，但你也可以添加自己的类型、位于层次结构根的桶属于根类型 Ceph 在将 PG 副本映射到 osd 时选择桶内物品的算法。有几种算法可用:uniform、list、tree和straw2。每种算法都代表了性能和重组效率之间的权衡。缺省算法为straw2 Uniform（均等分配）：Uniform 算法简单地将数据均匀地分配给存储集群中的 OSD（Object Storage Device）。优点是实现简单，能够提供基本的负载均衡效果。然而，它无法考虑 OSD 的实际负载情况，可能导致一些 OSD 负载过高而其他 OSD 负载较轻。 List（列表调度）：List 算法根据预定义的 OSD 列表顺序来分配数据。优点是可以根据需求灵活地配置 OSD 列表，适用于特定的负载均衡需求。然而，如果 OSD 列表中的 OSD 负载不均匀，可能导致一些 OSD 过载而其他 OSD 闲置。 Tree（树状调度）：Tree 算法使用树状结构来分配数据，将数据在多个层级的 OSD 中进行选择。优点是可以根据 OSD 的性能和负载情况进行智能调度，将数据分配给性能较好的 OSD。然而，实现相对复杂，需要维护和调整树状结构，适用于较大规模的负载均衡场景。 Straw2（稻草算法）：Straw2 算法考虑了 OSD 的负载和权重指标，并根据这些指标计算出一个权重值，然后根据权重值来分配数据。优点是可以根据 OSD 的实时负载情况进行智能调度，将数据分配给负载较轻的 OSD。然而，计算权重值需要一定的计算资源，且可能导致数据在短时间内频繁迁移。 自定义故障和性能域 CRUSH 映射是 CRUSH算法 的 中心配置机制，可以编辑此 map 以影响数据放置并自定义CRUSH算法 配置 CRUSH 映射和创建单独的 故障域 允许 osd 和集群节点发生故障，而不会发生任何数据丢失。在问题解决之前，集群只是以降级状态运行 配置 CRUSH Map并创建单独的性能域可以减少使用集群存储和检索数据的客户机和应用程序的性能瓶颈。 定制  CRUSH Map 的典型用例 针对 硬件故障 提供额外的保护。可以配置 CRUSH Map 以匹配底层物理基础设施，这有助于减轻硬件故障的影响 默认情况下，CRUSH算法将复制的对象放置在不同主机上的osd上。可以定制CRUSH map，这样对象副本就可以跨osd放置在不同的架子上，或者放置在不同房间的主机上，或者放置在具有不同电源的不同架子上 将带有 SSD驱动器的 osd  分配给需要快速存储的应用程序使用的池，而将带有传统hdd的osd分配给支持要求较低的工作负载的池 CRUSH map可以包含多个层次结构，你可以通过不同的CRUSH规则进行选择。通过使用单独的 CRUSH 层次结构，可以建立单独的性能域。例如，CRUSH 可以为 hdd 创建一个层次结构，为 ssd 创建另一个层次结构 配置单独性能域的用例示例如下： 分离虚拟机使用的块存储和应用使用的对象存储 将包含不经常访问的数据的“冷”存储区与包含经常访问的数据的“热”存储区分开 一个实际的CRUSH map定义，它包含： 所有可用物理存储设备的列表 所有基础设施桶的列表，以及每个桶中存储设备或其他桶的id。请记住，bucket是基础结构树中的容器或分支，例如，它可能表示一个位置或一块物理硬件 将pg映射到osd的CRUSH规则列表 其他CRUSH可调参数及其设置的列表 集群安装过程部署一个默认的CRUSH映射，可以使用ceph osd crush dump命令打印JSON格式的crush map。你也可以导出映射的二进制副本，并将其反编译为文本文件: [ceph: root@node /]# ceph osd getcrushmap -o ./map.bin [ceph: root@node /]# crushtool -d ./map.bin -o ./map.txt 自定义OSD CRUSH设置 CRUSH Map包含集群中所有存储设备的列表。对于每台存储设备，已获取如下信息: 存储设备的ID 存储设备的名称 存储设备的权重，通常以tb为单位。 例如，4tb的存储设备重量约为4.0。这是设备可以存储的相对数据量，CRUSH算法使用这一数据来帮助确保对象的均匀分布 host serverc { id -3 # do not change unnecessarily id -4 class hdd # do not change unnecessarily # weight 0.039 alg straw2 hash 0 # rjenkins1 item osd.0 weight 0.010 item osd.1 weight 0.010 item osd.2 weight 0.010 item osd.9 weight 0.010 } 可以通过ceph osd crush reweight命令设置OSD的权重。CRUSH的树桶权重应该等于它们的叶子权重的总和。 如果手动编辑 CRUSH Map权重，那么应该执行以下命令来确保CRUSH树桶的权重准确地反映了桶内叶片osd的总和 [ceph: root@node /)# ceph osd crush reweight-all reweighted crush hierarchy 存储设备的类别，存储集群支持多种存储设备，如hdd、ssd、NVMe ssd等。 存储设备的类反映了这些信息，可以使用这些信息创建针对不同应用程序工作负载优化的池。osd自动检测和设置它们的设备类。ceph osd crush set-device-class命令用于显式设置OSD的设备类。 使用ceph osd crush rm device-class 从 osd 中删除一个设备类 ceph osd crush tree命令显示crush map当前的层级： [ceph: root@clienta /]# ceph osd crush tree ID CLASS WEIGHT TYPE NAME -1 0.08817 root default -3 0.02939 host serverc 0 hdd 0.00980 osd.0 1 hdd 0.00980 osd.1 2 hdd 0.00980 osd.2 。 -5 0.02939 host serverd 3 hdd 0.00980 osd.3 5 hdd 0.00980 osd.5 7 hdd 0.00980 osd.7 -7 0.02939 host servere 4 hdd 0.00980 osd.4 6 hdd 0.00980 osd.6 8 hdd 0.00980 osd.8 设备类是通过为每个正在使用的设备类创建一个“影子”CRUSH层次结构来实现的，它只包含该类设备。 然后，CRUSH规则可以在影子层次结构上分发数据。 你可以使用ceph osd crush tree –show-shadow命令查看带有影子的crush 层级` [ceph: root@serverc /]# ceph osd crush tree --show-shadow ID CLASS WEIGHT TYPE NAME -2 hdd 0.09796 root default~hdd -4 hdd 0.03918 host serverc~hdd 0 hdd 0.00980 osd.0 1 hdd 0.00980 osd.1 2 hdd 0.00980 osd.2 9 hdd 0.00980 osd.9 -6 hdd 0.02939 host serverd~hdd 3 hdd 0.00980 osd.3 4 hdd 0.00980 osd.4 5 hdd 0.00980 osd.5 -8 hdd 0.02939 host servere~hdd 6 hdd 0.00980 osd.6 7 hdd 0.00980 osd.7 8 hdd 0.00980 osd.8 使用ceph osd crush class create 命令创建一个新的设备类 使用ceph osd crush class rm 命令删除一个设备类 使用ceph osd crush class ls 命令列出已配置的设备类 [ceph: root@serverc /]# ceph osd crush class ls [ "hdd" ] [ceph: root@serverc /]# ceph osd crush class create ssd created class ssd with id 1 to crush map [ceph: root@serverc /]# ceph osd crush class ls [ "hdd", "ssd" ] [ceph: root@serverc /]# ceph osd crush class rm ssd removed class ssd with id 1 from crush map [ceph: root@serverc /]# ceph osd crush class ls [ "hdd" ] 使用CRUSH规则 CRUSH map还包含数据放置规则，决定如何将pg映射到osd，以存储对象副本或 erasure coded块 ceph osd crush rule ls命令在已有的规则基础上，打印规则详细信息。 ceph osd crush rule dump rule_name命令打印规则详细信息， [ceph: root@serverc /]# ceph osd crush rule ls replicated_rule ecpool [ceph: root@serverc /]# ceph osd crush rule dump ecpool { "rule_id": 1, "rule_name": "ecpool", "ruleset": 1, "type": 3, "min_size": 3, "max_size": 5, "steps": [ { "op": "set_chooseleaf_tries", "num": 5 }, { "op": "set_choose_tries", "num": 100 }, { "op": "take", "item": -1, "item_name": "default" }, { "op": "choose_indep", "num": 0, "type": "osd" }, { "op": "emit" } ] } 编译后的CRUSH map也包含规则，可能更容易阅读: [ceph: root@node /]# ceph osd getcrushmap -o . /map.bin [ceph: root@node /]# crushtool -d . /map.bin -o . /map.txt [ceph: root@node /]# cat . /map.txt . . . output omitted ... rule replicated_rule { AA id 0 BB } type replicated min_size 1 CC max_size 10 DD step take default EE step chooseleaf firstn 0 type host FF step emit GG . . . output omitted ... AA 规则的名称。使用 ceph osd pool create 命令创建池时，使用此名称来选择规则 BB 规则ID。有些命令使用规则ID而不是规则名称。例如ceph osd pool set pool-name rush_ruleset ID，为已存在的池设置规则时使用规则ID CC 如果一个池的副本数少于这个数字，那么CRUSH不选择此规则 DD 如果一个存储池的副本数超过这个数字，那么CRUSH不选择此规则 EE 接受一个桶名，并开始沿着树进行迭代。在本例中，迭代从名为default的桶开始，它是缺省CRUSH层次结构的根。对于由多个数据中心组成的复杂层次结构，可以为数据创建规则，用于强制将特定池中的对象存储在该数据中心的osd中。在这种情况下，这个步骤可以从数据中心桶开始迭代 FF 选择给定类型(host)的桶集合，并从该集合中每个桶的子树中选择一个叶子(OSD)。本例中，规则从集合中的每个主机桶中选择一个OSD，确保这些OSD来自不同的主机。 支持的类型 # types type 0 osd type 1 host type 2 chassis type 3 rack type 4 row type 5 pdu type 6 pod type 7 room type 8 datacenter type 9 zone type 10 region type 11 root 集合中桶的数量通常与池中的副本数量(池大小)相同: 如果firstn后面的数字为0，则根据池中有多少副本选择多少桶 如果桶的数量大于零，且小于池中的副本数量，则选择相同数量的桶。在这种情况下，规则需要另一个步骤来为剩余的副本绘制桶。可以使用这种机制强制指定对象副本子集的位置 如果这个数字小于零，那么从副本数量中减去它的绝对值，然后选择这个数量的桶 GG 输出规则的结果 例如，可以创建以下规则来在不同的机架上选择尽可能多的osd，但只能从DC1数据中心: rule myrackruleinDC1 { id 2 type replicated min_size 1 max_size 10 step take DC1 step chooseleaf firstn 0 type rack step emit } 使用CRUSH可调参数 还可以使用可调参数修改CRUSH算法的行为。可调项可以调整、禁用或启用CRUSH算法的特性。 Ceph在反编译的 CRUSH Map的开始部分定义了可调参数，你可以使用下面的命令获取它们的当前值: [ceph: root@clienta /]# ceph osd crush show-tunables { "choose_local_tries": 0, "choose_local_fallback_tries": 0, "choose_total_tries": 50, "chooseleaf_descend_once": 1, "chooseleaf_vary_r": 1, "chooseleaf_stable": 1, "straw_calc_version": 1, "allowed_bucket_algs": 54, "profile": "jewel", "optimal_tunables": 1, "legacy_tunables": 0, "minimum_required_version": "jewel", "require_feature_tunables": 1, "require_feature_tunables2": 1, "has_v2_rules": 0, "require_feature_tunables3": 1, "has_v3_rules": 0, "has_v4_buckets": 1, "require_feature_tunables5": 1, "has_v5_rules": 0 } 调整CRUSH可调项可能会改变CRUSH将放置组映射到osd的方式。当这种情况发生时，集群需要将对象移动到集群中的不同osd，以反映重新计算的映射。在此过程中，集群性能可能会下降。 可以使用ceph osd crush tunables profile 命令选择一个预定义的配置文件，而不是修改单个可调项。 [ceph: root@serverc /]# ceph osd crush tunables profile Invalid command: profile not in legacy|argonaut|bobtail|firefly|hammer|jewel|optimal|default osd crush tunables legacy|argonaut|bobtail|firefly|hammer|jewel|optimal|default : set crush tunables values to <profile> Error EINVAL: invalid command [ceph: root@serverc /]# [ceph: root@serverc /]# ceph osd crush tunables optimal adjusted tunables profile to optimal 将配置文件的值设置为optimal，以启用Red Hat Ceph Storage当前版本的最佳(最优)值。 CRUSH Map 管理 集群保持一个编译后的CRUSH map的二进制表示。你可以通过以下方式修改它: 使用ceph osd crush命令 提取二进制 CRUSH Map并将其编译为纯文本，编辑文本文件，将其重新编译为二进制格式，然后将其导入到集群中 通常使用ceph osd crush命令更新CRUSH Map会更容易。但是，还有一些不太常见的场景只能通过使用第二种方法来实现。 使用Ceph命令定制CRUSH Map 下面的例子创建了一个新的桶: [ceph: root@node /]# ceph osd crush add-bucket name type 例如，这些命令创建三个新桶，一个是数据中心类型，两个是机架类型: [ceph: root@node /)# ceph osd crush add-bucket DC1 datacenter added bucket DCl type datacenter to crush map [ceph: root@node /)# ceph osd crush add-bucket rackA1 rack added bucket rackAl type rack to crush map [ceph: root@node /)# ceph osd crush add-bucket rackB1 rack added bucket rackBl type rack to crush map 然后，可以使用以下命令以层次结构组织新桶 [ceph: root@node /]# ceph osd crush move name type=parent 还可以使用此命令重新组织树。例如，将上例中的两个机架桶挂载到数据中心桶上，将数据中心桶挂载到默认的根桶上 [ceph: root@node /]# ceph osd crush move rackA1 datacenter=DC1 moved item id -10 name ' rackA1' to location {datacenter=DCl} in crush map [ceph: root@node /]# ceph osd crush move rackB1 datacenter=DC1 moved item id -11 name ' rackB1' to location {datacenter=DC1} in crush map [ceph: root@node /)# ceph osd crush move DC1 root=default moved item id -9 name ' DC1' to location {root=default} in crush map ID CLASS WEIGHT TYPE NAME -1 0.09796 root default -9 0 datacenter DC1 -10 0 rack rackA1 -11 0 rack rackB1 -3 0.03918 host serverc 0 hdd 0.00980 osd.0 1 hdd 0.00980 osd.1 2 hdd 0.00980 osd.2 9 hdd 0.00980 osd.9 -5 0.02939 host serverd 3 hdd 0.00980 osd.3 4 hdd 0.00980 osd.4 5 hdd 0.00980 osd.5 -7 0.02939 host servere 6 hdd 0.00980 osd.6 7 hdd 0.00980 osd.7 8 hdd 0.00980 osd.8 设置 osd 位置 在创建了自定义桶层次结构之后，将 osd 作为该树的叶子放置。每个 OSD 都有一个位置，它是一个字符串，定义从树的根到该OSD的完整路径。 例如，挂在 rackA1 桶上的 OSD 的位置为: root=default datacenter=DC1 rack=rackA1 当Ceph启动时，它使用ceph-crush-location工具来自动验证每个OSD都在正确的CRUSH位置。 如果OSD不在CRUSH Map中预期的位置，它将被自动移动。默认情况下，这是root=default host=hostname。 可以用自己的脚本替换ceph-crush-location实用程序，以更改osd在CRUSH Map中的位置。 为此，在/etc/ceph/ceph.conf中指定crush_ location_hook参数 [osd] crush_location_hook = /path/to/your/script Ceph使用以下参数执行该脚本: --cluster cluster-name --id osd-id --type osd。 脚本必须在其标准输出中以一行的形式打印位置。Ceph文档有一个自定义脚本示例，该脚本假设每个系统都有一个名为/etc/rack的包含所在机架名称的机架文件: #! /bin/sh echo "root=default rack=$(cat /etc/rack) host=$(hostname -s)" 特定osd的位置定义 可以在/etc/ceph/ceph.conf中设置crush_location参数。重新定义特定osd的位置。 例如，设置osd.0和osd.1，在文件中各自的部分中添加crush_ location参数: [osd.0] crush_location = root=default datacenter=DC1 rack=rackA1 [osd.1] crush_location = root=default datacenter=DC1 rack=rackB1 添加CRUSH Map规则 复制池 创建了一个Ceph可以用于复制池的规则: [ceph: root@node /]# ceph osd crush rule create-replicated name \ root failure-domain-type [class] 其中: Name 为规则的名称 root 是CRUSH Map层次结构中的起始节点 failure-domain-type 是用于复制的桶类型 类是要使用的设备的类，例如SSD或hdd。可选参数 下面的示例创建新的inDC2规则来在DC2数据中心存储副本，将副本分发到各个机架: [ceph: root@node /]# ceph osd crush rule create-replicated inDC2 DC2 rack [ceph: root@node /]# ceph osd crush rule ls replicated_rule erasure-code inDC2 定义规则后，在创建复制池时使用它: [ceph: root@node /]# ceph osd pool create myfirstpool 50 50 inDC2 pool 'myfirstpool' created 纠删码池 对于erasure code，Ceph自动为您创建的每个erasure code池创建规则。规则的名称为新池的名称。 Ceph使用您在创建池时指定的erasure code配置文件中定义的规则参数 下面的例子首先创建新的myprofile erasure code配置文件，然后基于这个配置文件创建myecpool池: [ceph: root@node /]# ceph osd erasure-code-profile set myprofile \ k=2 m=1 crush-root=DC2 crush-failture-domain=rack crush-device-class=ssd [ceph: root@node /)# ceph osd pool create myecpool 50 50 erasure myprofile [ceph: root@node /]# ceph osd crush rule ls 通过编译二进制版本自定义CRUSH Map 你可以用以下命令来反编译和手动编辑CRUSH Map: ceph osd getcrushmap和ceph osd setcrushmap命令提供了一种备份和恢复集群CRUSH Map的有效方法 优化放置组PG 放置组(pg)允许集群通过将对象聚合到组中以可伸缩的方式存储数百万个对象。根据对象的ID、池的ID和池中放置组的数量将对象组织成放置组。 在集群生命周期中，pg个数需要根据集群布局的变化进行调整 CRUSH 试图确保对象在池中osd之间的均匀分布，但也存在pg变得不平衡的情况。 放置组自动缩放器可用于优化PG分发，并在默认情况下打开。如果需要，还可以手动设置每个池的pg数量 对象通常是均匀分布的，前提是池中比osd多一个或两个数量级(十个因子)的放置组。 如果没有足够的pg，那么对象的分布可能会不均匀。 如果池中存储了少量非常大的对象，那么对象分布可能会变得不平衡 配置pg，以便有足够的对象在集群中均匀分布。如果 pg的数量设置过高，则会显著增加CPU和内存的使用。Red Hat建议每个OSD大约100到200个放置组来平衡这些因素 计算放置组的数量 对于单个池的集群，可以使用以下公式，每个OSD 100个放置组 Total PGs = (OSDs * 100)/Number of replicas Red Hat推荐使用每个池计算Ceph放置组，https://access.redhat.com/labs/cephpgc/manual/ 手动映射PG 使用 ceph osd pg-upmap-iterns 命令手动将pg映射到指定的osd，因为以前的Ceph客户端不支持，所以必须配置ceph osd set-require-min-compat-client启用pg-upmap命令 [ceph: root@node /]# ceph osd set-require-min-compat-client luminous 下面的例子将PG 3.25从ODs 2和0映射到1和0: [ceph: root@node /]# ceph pg map 3.25 osdmap e384 pg 3.25 (3.25) -> up [2,0) acting [2,0) [ceph: root@node /]# ceph osd pg-upmap-items 3.25 2 1 set 3.25 pg_ upmap items mapping to [2->1) [ceph: root@node /]# ceph pg map 3.25 osdmap e387 pg 3.25 (3.25) •> up [1,0) acting [1,0) 以这种方式重新映射数百个pg是不现实的 osdmaptool 命令在这里很有用，它获取一个池的实际 Map，分析它，并生成ceph osd pg-upmap-items命令来运行一个最优分布: 将映射导出到一个文件，下面的命令将映射保存到./om文件: [ceph: root@node /]# ceph osd getmap -o ./om got osdmap epoch 387 使用osdmaptool命令的--test-map-pgs选项显示pg的实际分布。打印ID为3的池的分布信息: [ceph: root@node /]# osdmaptool ./om --test-map-pgs --pool 3 osdmaptool: osdmap file './om' pool 3 pg_num 50 #osd count first primary c wt wt osd.0 34 19 19 0.0184937 1 osd.1 39 14 14 0.0184937 1 osd.2 27 17 17 0.0184937 1 ... output omitted . .. 输出显示了osd.2只有27个PG而osd.1有39 PG 生成重新平衡pg的命令。 使用osdmaptool命令的--upmap选项将命令存储在一个文件中: [ceph: root@node /]# osdmaptool ./om --upmap ./cmds.txt --pool 3 osdmaptool: osdmap file './om' writing upmap command output to: ./cmds.txt checking for upmap cleanups upmap, max-count 100, max deviation 0.01 [ceph: root@node /]# cat ./cmds.txt ceph osd pg-upmap-items 3.1 0 2 ceph osd pg-upmap-items 3.3 1 2 ceph osd pg-upmap-items 3.6 0 2 ... output omitted ... 执行命令: [ceph: root@node /]# bash ./cmds.txt set 3.1 pg upmap items mapping to [0->2] set 3.3 pg upmap_items mapping to [1->2] set 3.6 pg_upmap_items mapping to [0->2] ... output omitted ... 2管理OSD Map 描述OSD Map 集群OSD map包含每个OSD的地址、状态、池列表和详细信息，以及OSD的接近容量限制信息等。Ceph使用这些最后的参数来发送警告，并在OSD达到满容量时停止接受写请求 当集群的基础设施发生变化时，比如 osd 加入或离开集群，MONs 会相应地更新相应的映射。Mons保持着map修订的历史。 Ceph使用一组被称为epoch的有序增量整数来标识每个map的每个版本 ceph status -f json-pretty 命令显示每个 map 的 epoch。使用ceph map dump子命令显示每个单独的映射，例如 ceph osd dump [ceph: root@clienta /]# ceph status -f json-pretty { "fsid": "2ae6d05a-229a-11ec-925e-52540000fa0c", "health": { "status": "HEALTH_OK", "checks": {}, "mutes": [] }, "election_epoch": 48, "quorum": [ 0, 1, 2, 3 ], "quorum_names": [ "serverc.lab.example.com", "clienta", "serverd", "servere" ], "quorum_age": 1961, "monmap": { "epoch": 4, "min_mon_release_name": "pacific", "num_mons": 4 分析OSD Map更新 每当有 OSD 加入或离开集群时，Ceph 都会更新 OSD 的map。一个OSD可以因为OSD故障或硬件故障而离开 Ceph 集群 虽然整个集群的分布式映射（map）由监控器（MONs）来维护，但是对象存储设备（OSD）并不使用监控器的领导者（leader）来管理存储器的映射。 相反，OSD之间会直接交换它们所持有的映射，并且每次交换都会标记(epoch)出来。当一个 OSD 检测到自己的运行速度落后时，会触发对其对等 OSD 执行映射的更新，以确保所有的 OSD 都具有最新的映射信息。 在大的集群中，OSD map更新频繁，所以总是分发完整的map是不现实的。相反,接收 OSD 的节点执行增量映射更新 Ceph 还将 osd 和客户端之间的消息标记为epoch。每当客户端连接到OSD时，OSD就会检查 epoch。 如果 epoch 不匹配，那么OSD将响应正确的增量，以便客户机可以更新其OSD映射。这就不需要主动传播，因为客户端只有在下一次联系时才会了解更新后的映射 使用Paxos更新集群Map 要访问Ceph集群，客户机首先要从MONs获取集群映射的副本。为了使集群正常运行，所有的MONs必须具有相同的集群映射。 MONs使用Paxos算法作为一种机制来确保它们对集群状态达成一致。Paxos是一种分布式共识算法。 每当MON修改map时，它就通过Paxos将更新发送给其他监视器。Ceph只有在大多数监控器都同意更新后才会提交新版本的map。 MON向Paxos提交map更新，只有在Paxos确认更新后才将新版本写入本地键值存储。读操作直接访问键值存储。 OSD Map 传播 osd 定期向监控器报告其状态。此外，OSD还可以通过交换心跳来检测对等体的故障，并将故障报告给监视器。 当leader监视器得知OSD出现故障时，它会更新Map，增加epoch，并使用 Paxos 更新协议通知其他监视器，同时撤销它们的租约。 在大多数监控器确认更新后，集群有了仲裁，leader 监控器发出新的租约，以便监控器可以分发更新的OSD映射。 OSD Map命令管理员使用以下命令管理 OSD Map: 命令 动作 ceph osd dump 将OSD映射转储到标准输出 ceph osd getmap -o binfile 导出当前映射的二进制副本 osdmaptool --print binfile 在标准输出中显示人类可读的映射副本 osdmaptool --export-crush crushbinfile binfile 从OSD map 中提取CRUSH map osdmaptool --import-crush crushbinfile binfile 嵌入一个新的CRUSH map osdmaptool --test-map-pg pgid binfile 验证给定PG的映射 ...

Json介绍 Json（JavaScript Object Notation）是一种轻量级的数据交换格式，常用于前后端数据传输和存储。 它使用简洁的文本格式来表示结构化的数据，易于阅读和编写，并且可以被多种编程语言解析和生成。 Json的基本语法包括键值对（key-value pairs）和数据类型。 键值对由一个键（key）和一个值（value）组成，中间用冒号（:）分隔。 多个键值对之间用逗号（,）分隔。值可以是字符串、数字、布尔值、数组、对象或null。 以下是一个Json对象的示例： { "name": "Raysen", "age": 27, "isStudent": true, "hobbies": ["唱", "RAP", "篮球"], "address": { "street": "23号大街", "city": "杭州", "country": "China" }, "favoriteFruit": null } 键值对的键是字符串，值可以是字符串（如”name”和”Raysen”）、数字（如”age”和30）、布尔值（如”isStudent”和true）、数组（如”hobbies”）或对象（如”address”）。键值对之间用逗号分隔，整个Json对象用花括号括起来。 Json的优点包括易于理解和编写、数据结构清晰、可读性强、支持多种编程语言等。它广泛应用于Web开发、API接口设计、配置文件等场景。 Json格式弊端 缺乏类型信息：Json格式的数据没有明确的类型信息，只能通过字段名来推断数据类型。这导致在处理复杂数据结构时，需要额外的逻辑来解析和处理数据。 不支持注释：Json格式不支持注释，这使得在复杂的数据结构中添加注释变得困难。注释对于代码的可读性和维护性非常重要，但在Json中无法直接添加注释。 不支持多行字符串：Json格式中的字符串必须在一行内表示，不支持多行字符串。这在处理较长的文本或包含换行符的字符串时，会导致可读性下降。 不支持原生日期类型：Json格式没有原生的日期类型，日期通常以字符串的形式表示。这使得在处理日期相关的操作时，需要额外的转换和处理。 不支持引用和循环引用：Json格式不支持引用其他对象或循环引用。这在处理复杂的数据关系时，可能会导致数据冗余和难以维护。 Json格式在一般的数据交换和存储场景中表现良好，但在处理复杂数据结构和需要更多元信息的情况下，存在一些不足之处。 Json弊端优化方案 使用压缩算法：可以使用压缩算法对Json格式进行压缩，减小数据的存储空间占用。 使用二进制格式：可以将Json格式转换为二进制格式，减少数据的存储空间和传输带宽。 使用Schema验证：可以使用Schema验证Json数据的结构和类型，提高数据的可靠性和可读性。 使用更紧凑的数据格式：可以考虑使用其他更紧凑的数据格式，如MessagePack、Protocol Buffers等，减小数据的存储空间和传输带宽。 ...

电源侧信道攻击利用CPU功耗的数据相关变化来泄露机密信息。本文展示了在现代英特尔（和AMD）x86 CPU上，可以将电源侧信道攻击转化为时序攻击，而无需访问任何功耗测量接口，这源自于动态电压和频率调整（DVFS, Dynamic Voltage & Frequency Scaling）。在某些情况下，DVFS引起的CPU频率变化取决于毫秒级的当前功耗。这些变化可以被远程攻击者观察到，因为频率差异会转化为绝对时间差异。频率侧信道从理论上来说比当今密码工程实践中考虑的软件侧信道更强，但由于其粗粒度导致很难被利用。然而，现在这一新信道对密码软件的安全构成了真正威胁。本研究首先对现代x86 CPU上的数据、功耗和频率之间的依赖关系进行了逆向工程，发现了一些细微差别，例如一个字中设置位的位置可以通过频率变化来区分。其次提出了一种针对（恒定时间实现）SIKE的新型选择密文攻击，通过远程时序将单个密钥位的猜测放大为成千上万次高功耗或低功耗操作，从而允许通过远程时序进行完整密钥提取。0x01 简介功耗分析攻击几十年来一直被认为是侧信道信息泄露的一个主要源头。在历史上，这些攻击被用来从嵌入式设备（如智能卡）中使用物理探针泄露密码密钥。最近，功耗分析攻击也被证明可以通过软件功耗测量接口来利用。这些接口在许多现代通用处理器上都可用，已被滥用于网站指纹识别、恢复RSA密钥、破解KASLR，甚至恢复AES-NI密钥。幸运的是，基于软件的功耗分析攻击可以通过阻止（或限制）对功耗测量接口的访问来减轻并且容易检测。直到今天，这样的缓解策略将有效地减少攻击面至仅限于物理功耗分析，这在现代通用x86处理器的环境中是一个明显较小的威胁。DVFS是一种常用的技术，它包括动态调整CPU频率以降低功耗（在低CPU负载时）以及确保系统在功耗和热量极限下保持稳定（高CPU负载）。在某些情况下，DVFS引起的CPU频率调整取决于毫秒级的当前功耗。因此，由于功耗与数据相关，CPU频率调整也是与数据相关的。此外，数据相关的频率调整可以被远程攻击者观察，而无需任何特殊权限。原因是CPU频率差异直接转化为执行时间差异（因为1赫兹=1秒内的1个周期）。这一发现的安全影响是重大的。它从根本上破坏了恒定时间编程，自1996年以来一直是抵抗时序攻击的基础防御措施。恒定时间编程的前提是通过编写一个只使用“safe”指令的程序，其延迟与数据值无关，程序的执行时间将是与数据无关。然而若是通过频率信道，即使仅使用安全指令，时序也会成为数据的函数。 尽管其理论上具有很大的威力，但如何构建实际的频率侧信道攻击并容易。这是因为DVFS更新取决于数百万CPU周期内的总功耗，只反映了粗粒度的程序行为。本研究展示了频率侧信道对加密软件安全构成了真正的威胁，通过：（i）在现代x86英特尔CPU上逆向工程的精确泄露模型，（ii）展示一些加密原语能够将单个密钥位的猜测放大成数千次高功耗或低功耗操作，足以引发可测量的时序差异。为了构建泄露模型，对现代x86英特尔CPU上正在计算的数据与功耗/频率之间的依赖关系进行了逆向工程。研究结果显示，功耗和CPU频率取决于数据的汉明权重（HW, Hamming weight）以及跨计算的数据的汉明距离（HD, Hamming distance），这两种影响在现代英特尔CPU上是不同且可累加的。此外，HW效应是非均匀的。也就是说，处理具有相同HW的数据会导致功耗/频率因数据值内个别1的位置而不同。因此，根据秘密进行不同位模式数据的计算可以导致功耗和频率取决于该秘密。然后，本文描述了一种新的攻击，包括新的密码分析技术，针对恒定时间实现的SIKE（Supersingular Isogeny Key Encapsulation）。SIKE已经有十年的历史，被广泛研究的密钥封装机制。与NIST的后量子密码竞赛中的其他入围者不同，SIKE具有较短的密文和较短的公钥。当攻击者提供一个经过特别制作的输入时，SIKE的解密算法会产生依赖密钥的单个位的异常值。这些值会导致算法卡住，并在剩下的解密过程中操作中间值，这些值在剩余的解密中也都是0。当这种情况发生时，处理器的功耗较低，运行频率较高，因此解密所需的绝对时间较短。这种时序信号非常稳定，以至于可以在网络中进行密钥提取，最后，还展示了频率侧信道也可以用来进行无需计时器的时序攻击，例如KASLR破解和隐蔽信道。0x02 研究背景Intel P-States：在英特尔处理器中，动态电压和频率调整（DVFS）以P-states的粒度工作。P-states对应于不同的操作点（电压-频率对），以100 MHz频率递增。不同CPU型号的P-states数量各不相同。现代英特尔处理器提供两种控制P-states的机制，即SpeedStep和Speed Shift / Hardware Controlled Performance States (HWP)。使用SpeedStep，P-states由操作系统（OS）使用硬件协调反馈寄存器进行管理。使用HWP时，P-states完全由处理器进行管理，提高了整体响应性。HWP是在Skylake微架构中引入的。启用HWP时，操作系统只能向处理器的内部P-state选择逻辑提供提示，包括限制可用P-states的范围。否则，可用的P-states范围仅取决于活动内核的数量以及是否启用了“Turbo Boost”。本文的P-state命名约定遵循Linux中使用的约定。最低的P-state对应于支持的最低CPU频率。最高的P-state对应于处理器的“最大睿频”频率。然而，当禁用Turbo Boost时，最高可用的P-state是基本频率，将P-state和频率视为可以互换使用的术语。P-state管理也与功耗管理相关。每个英特尔处理器都有一个热设计功耗（TDP），表示在持续工作负载下的稳定状态下的预期功耗。在最大睿频模式下，处理器可以超过其名义TDP。然而，如果CPU在最大睿频模式下达到一定的功耗和热量极限，硬件将自动减小频率以保持TDP在工作负载的持续时间内。数据相关功耗：众所周知，处理器的功耗取决于正在处理的数据。数据和功耗之间的精确依赖关系取决于处理器的实现，但可以使用泄露模型进行近似。两种常用的泄露模型是汉明距离（HD）和汉明权重（HW）模型。在HD模型中，功耗取决于计算过程中数据中发生的1 → 0和0 → 1位转换的数量。在HW模型中，功耗仅取决于正在处理的数据中位为1的位数。功耗侧信道攻击：功耗侧信道攻击针对加密系统首次在1998年公开讨论，引入了分析技术，利用功耗与数据依赖性来揭示秘密密钥。随后的工作展示了针对多个加密算法的功耗分析攻击，包括AES、DES、RSA和ElGamal。然而，所有这些攻击都针对智能卡，需要物理接触设备。最近，功耗侧信道攻击也被应用于更复杂的设备，如智能手机和PC。其中一些攻击仅依赖于软件功耗测量接口，这意味着它们不需要接近设备。然而，尽管其中一些工作使用了HW和HD泄露模型，但其中没有一个对现代英特尔x86 CPU上功耗和数据之间的依赖关系进行了系统逆向工程。此外，所有这些攻击都可以通过限制对这类功耗测量接口的访问来阻止。0x03 CPU频率泄露信道实验设置：在多台不同的计算机上运行实验。每台计算机的CPU特性都在下表中。所有计算机都运行Ubuntu，版本为18.04或20.04，内核为4.15或5.4，并安装了最新的微码补丁。除非另有说明，使用默认的系统配置，不限制P-states。为了监视CPU频率，使用了MSR_IA32_MPERF和MSR_IA32_APERF寄存器，就像Linux内核中所做的那样。为了监视功耗，使用RAPL接口的MSR。A. 指令区分作为分析的第一步，需要着手了解运行不同工作负载如何影响CPU的P-state选择逻辑。从stress-ng基准测试套件中选择了两个工作负载。第一个工作负载包括32位整数和浮点运算（int32float方法），而第二个工作负载仅包括32位整数运算（int32方法）。在所有内核上运行这两个基准测试，从空闲状态开始。在基准测试的执行过程中，每5毫秒采样一次CPU频率和（包域）功耗。上图a显示了在i7-9700 CPU上进行int32float测试的结果。频率开始时为4.5 GHz，在CPU上，当所有内核都处于活动状态时，这是最高的P-state。在大约8秒的时间内，允许功耗超过TDP。然后，CPU降至较低的P-state，将功耗降至TDP（在CPU上为65W）。从那时开始，CPU保持在稳态，并在工作负载的持续时间内保持功率在TDP水平左右。示例中在稳态下，频率在两个P-states之间波动，分别对应3.9 GHz和4.0 GHz的频率。上图b显示了int32压力测试的结果。这里，频率也从4.5 GHz开始，然后降至较低的P-state。但与图a相比，降低发生在10秒后，且降低后使用的P-states更高，分别对应4.0 GHz和4.1 GHz。这是因为int32测试的功耗较低。因此，处理器不仅可以更长时间地维持最高可用的P-state，而且可以在稳态下使用更高的P-states，而不会超过TDP。以上结果的关键要点是：（i）处理器可以在最大可用P-state上花费的时间，（ii）稳态下P-states的分布都取决于CPU功耗。由于CPU功耗取决于工作负载，根据传递属性，可以得出P-states也取决于工作负载。这意味着P-states的动态调整会泄露有关处理器上当前运行的工作负载的信息。B. 数据区分已经看到P-state信息泄露了有关正在执行的指令（即工作负载）的信息。现在探讨频率泄露信道是否可以泄露有关指令正在处理的数据的信息。问题是由于已知x86处理器上的功耗与数据相关，数据相关的功耗差异是否会在P-states的分布中显示出来？为了回答这个问题，在执行相同的指令时，只改变输入寄存器的内容，同时监视CPU频率。例如使用shlx指令不断将源寄存器的位向左移动，并将结果写入循环中的不同目标寄存器，只变化源寄存器的内容。在所有内核上运行这个实验，并比较稳态下P-states的分布。下图a显示了将源寄存器的内容设置为16、32或48个1时的结果。在所有情况下，P-state在4.3 GHz和4.4 GHz之间波动。然而，汉明权重越大，频率停留在较低的P-state上的时间越长。从空闲状态开始，频率降至稳态的时间也会随着汉明权重的增加而减少（参见下图b）。汉明权重越大，频率降至稳态的速度越快。这是因为，处理具有较大汉明权重的数据消耗的功率比处理具有较低汉明权重的数据要多。也使用其他指令获得类似的结果。例如，当运行or、xor、and、imul、add、sub以及处理从内存加载的数据时，观察到了数据相关的影响。唯一需要注意的是，对于某些指令，仅在所有内核上运行目标指令的功耗不足以导致P-state降至稳态。这些情况下在后台运行了额外的固定工作负载，以增加总功耗。以上结果的关键是，P-states的动态调整会泄 ...

Fedora Silverblue是 一款基于 Fedora Linux 构建的面向桌面的操作系统。 这款操作系统非常适合日常使用、开发和容器化的工作流程。 它有许多优势，例如可以在发生问题时轻松回滚操作。 如果你想在 Fedora Silverblue 系统上更新或将系统 重定位rebase 到 Fedora Linux 39，本文会提供帮助。 文章不仅会指导你执行操作，还会教你如何在遇到意外情况时撤销操作。 更新你目前的系统 在实际重定位至 Fedora Linux 39 前，你需要先安装所有待处理的更新。 你可以在终端中使用下面的命令： $ rpm-ostree update 或者你也可以通过 GNOME “软件”应用安装更新，然后重新启动系统。 使用 GNOME “软件” 重定位 在 GNOME “软件”应用的更新页面上，你可以看到 Fedora Linux 的新版本已经可以使用。 首先，你需要点击 “下载Download” 按钮来下载新的操作系统镜像。这个过程可能需要一些时间。完成后，你会发现更新已经准备好进行安装。 接下来，点击 “重新启动 & 升级Restart & Upgrade” 按钮。这个过程只需要几分钟，一旦更新完成，计算机将会重新启动。重启后，你会看到崭新的 Fedora Linux 39 的系统环境，看起来很简单，是吧？ 使用终端进行重定位 如果你更喜欢在终端操作，那么这部分指南就是为你准备的。 首先你需要确认 39 版本是否已经可以使用： $ ostree remote refs fedora 在命令输出中你应该看到如下内容： fedora:fedora/39/x86_64/silverblue 如果你想保留当前的部署（这意味着这个部署将会持续在 GRUB 中显示为一个选项，直到你手动移除它），你可以通过运行下面的命令实现： # 0 是在 rpm-ostree 状态中的条目位置 $ sudo ostree admin pin 0 如果你想移除已经固定的部署，你可以使用下面的命令： # 2 是在 rpm-ostree 状态中的条目位置 $ sudo ostree admin pin --unpin 2 然后，将你的系统重定位至 Fedora Linux 39 镜像。 $ rpm-ostree rebase fedora:fedora/39/x86_64/silverblue 最后，重启你的电脑，启动进入 Fedora Linux 39 版本。 如何进行回滚 如果遇到任何问题（例如，如果你无法启动 Fedora Linux 39），回滚是非常容易的。 在系统启动时，在 GRUB 菜单中选择 Fedora Linux 39 之前的版本，然后你的系统就会启动这个更早的版本而非 Fedora Linux 39。 如果你在启动过程中看不到 GRUB 菜单，那么在启动时尝试按下 ESC键。 如果你想让更早版本的选择永久生效，你可以使用下面的命令： $ rpm-ostree rollback 现在，你已经了解如何将 Fedora Silverblue 系统重定位到 Fedora Linux 39，以及如何进行系统回滚了。那么何不今天就试试看呢？ 常见问题解答 在每篇关于重定位 Silverblue 到新版本的文章的评论中，总会有相似的问题，因此我会在这个部分尝试解答这些问题。 问题：在 Fedora 的重定位过程中我能跳过某些版本吗？例如直接从 Fedora 37 Silverblue 更新到 Fedora 39 Silverblue。 答案：虽然有时可能可以在重定位过程中跳过某些版本，但并不推荐这样操作。你应当始终更新到紧邻的新版本（例如从 38 更新到 39），以避免不必要的错误。 问题：我安装了 rpm-fusion，在重定位过程中出现错误，我应当怎样进行重定位？ 答案：如果你在 Silverblue 安装上加入了 rpm-fusion，你在重定位前应当执行以下操作： rpm-ostree update \ --uninstall rpmfusion-free-release \ --uninstall rpmfusion-nonfree-release \ --install rpmfusion-free-release \ --install rpmfusion-nonfree-release 执行完上述操作后，你可以按照本篇博文的步骤完成重定位过程。 问题：这个指南是否适用于其他的 ostree 版本（例如 Kinoite， Sericea）？ 答案：是的，你可以照着本指南的 使用终端进行重定位部分的操作来完成所有的 Fedora ostree 版本的重定位过程。只需要使用对应的分支即可。例如对于 Kinoite，你可以使用 fedora:fedora/39/x86_64/kinoite 而非 fedora:fedora/39/x86_64/silverblue </div> ...

点击围观  ...

HTTPS是HTTP的安全版本，两者都用于在客户端和服务器之间传输数据，但HTTPS添加了加密和安全性层，以保护数据的机密性和完整性。 区别： 安全性： HTTP：HTTP是一种不安全的协议，数据在传输过程中以明文形式传输，容易受到窃听和篡改的风险。 HTTPS：HTTPS通过使用加密机制（通常是TLS/SSL）来保护数据的机密性，使数据在传输过程中加密，从而提供更高的安全性。 端口： HTTP：HTTP默认使用端口80进行通信。 HTTPS：HTTPS默认使用端口443进行通信。 加密： HTTP：HTTP不提供加密，数据可以在网络上传输时被窃听。 HTTPS：HTTPS使用TLS/SSL协议进行数据加密和解密，确保数据在传输过程中的保密性。 证书： HTTP：HTTP不涉及数字证书的使用。 HTTPS：HTTPS需要服务器获得数字证书，并由权威的证书颁发机构（CA）签发，以验证服务器的身份。客户端可以使用证书来确保它们正在连接到合法的服务器。 认证和身份验证： HTTP：HTTP不提供身份验证机制，任何人都可以发送HTTP请求。 HTTPS：HTTPS提供了对服务器和（可选）客户端的身份验证，确保双方的合法性。 SEO（搜索引擎优化）： HTTP：搜索引擎可能更喜欢使用HTTPS的网站，因为它们提供了更高的安全性，可以影响搜索排名。 ...

关系： HTTP建立在TCP之上：HTTP是一个应用层协议，而TCP是传输层协议。HTTP通常使用TCP作为它的传输层协议，以在网络上传输数据。HTTP与TCP之间的关系可以类比为在实体之上建立一个通信通道。 HTTP利用TCP的可靠性：TCP提供了可靠的、面向连接的数据传输。HTTP利用TCP的可靠性来确保数据的正确传递，包括数据的分段和重新组装、错误检测和重传等。 区别： 层次：TCP是传输层协议，负责在两台计算机之间建立连接、可靠地传输数据流，以及处理数据分段和重传等传输细节。HTTP是应用层协议，负责定义数据的格式和如何在客户端和服务器之间传输数据。 功能：TCP关注于数据传输的可靠性和流控制，而HTTP关注于定义如何呈现和传输文档、图像、视频等内容。HTTP通过请求-响应模型允许客户端请求网络资源，并服务器响应这些请求。 端口：TCP使用端口来标识不同的应用程序或服务，允许多个不同的应用程序在同一台计算机上共享网络连接。HTTP默认使用TCP端口80（HTTP）或443（HTTPS）。 通信模式：TCP是一种点对点的通信协议，即两台计算机之间的通信。HTTP是一种客户端-服务器通信模式，客户端发送请求，服务器返回响应。 状态：TCP是无状态的协议，它不保留关于连接的持久状态信息。HTTP也是无状态的，每个HTTP请求和响应之间是相互独立的，不保留客户端之间的状态。 ...

HTTP：80（HTTP）和443（HTTPS）。 80端口用于HTTP通信，通常是未加密的。 443端口用于HTTPS通信，加密的HTTP通信。 FTP：21（控制连接）和20（数据连接）。 21端口用于FTP的控制连接，用于命令和控制操作。 20端口用于FTP的数据连接，用于实际文件传输。 SSH：22端口用于安全的远程登录和文件传输。 SMTP：25端口用于发送电子邮件。 POP3：110端口用于接收电子邮件。 IMAP：143端口也用于接收电子邮件，但提供了更多的功能和灵活性。 DNS：53端口用于域名解析，将域名映射到IP地址。 Telnet：23端口用于远程终端连接，通常是明文传输。 SMTPS：465端口用于通过加密通信的SMTP。 SNMP：161（SNMP）和162（SNMP Trap）。 161端口用于SNMP通信，允许管理和监视网络设备。 162端口用于SNMP陷阱，用于通知管理站点的事件。 HTTP Proxy：3128（常见代理端口）端口通常用于HTTP代理服务器。 RDP：3389端口用于远程桌面连接。 ...

两名南加州男子因涉嫌在暗网上销售提供含有芬太尼的药丸和甲基苯丙胺而面临数十年甚至终身监禁的联邦监禁。 美国司法部在一份新闻稿中表示，来自洛杉矶南部38岁的奥马尔·纳维亚(Omar Navia)和来自加登格罗夫27岁的阿丹·鲁伊斯(Adan Ruiz)被指控提供“含有芬太尼和其他麻醉品的假冒M30羟考酮药丸”在暗网上出售。 他们上个月被起诉，并于周四被捕。美国司法部表示，两人均对“串谋分发和持有并意图分发芬太尼和甲基苯丙胺”的指控表示不认罪。鲁伊斯还面临分销芬太尼的额外指控。 据检察官称，纳维亚和鲁伊斯充当贩毒组织的供应商，在暗网上并通过“Session”和“Signal”等加密消息应用程序进行交易。他们与两名已经认罪的人合作：38岁的休斯顿人拉吉夫·斯里尼瓦桑(Rajiv Srinivasan)和25岁的威斯敏斯特人迈克尔·塔(Michael Ta)，他们去年因相关指控被联邦大陪审团起诉。检察官称，他们今年认罪，预计明年被判刑。 美国司法部表示，斯里尼瓦桑和塔均承认从事贩毒活动，并“承认他们的贩毒活动导致三人死亡，并且他们向另外两人出售了含有芬太尼的药片，两人很快就因吸毒过量死亡”。 据称，斯里尼瓦桑和塔从纳维亚和鲁伊斯那里采购毒品，然后使用在各个暗网市场上运营的供应商帐户“redlightlabs”将毒品出售给全美国50个州的买家。 调查人员发现的文件显示，该团伙据称在2022年销售了近124,000粒芬太尼药丸，以及20磅冰毒和“根据起诉书，少量芬太尼粉末、黑焦油海洛因和可卡因”。 纳维亚和鲁伊斯被关押，不得保释。他们的审判定于12月26日开始。 对于共谋罪，他们可能被判处终身监禁联邦监狱，而鲁伊斯的分配罪可能被判处最高20年徒刑。 据称，他们作为毒品供应商的报酬是通过各种货币渠道获得的。这些渠道包括加密货币、通过加密货币交易所传输的资金以及Apple Cash、CashApp、PayPal、Venmo和Zelle等移动支付​​应用程序。斯里尼瓦桑和塔将于明年在美国圣安娜地方法院法官戴维·卡特(David O. Carter)面前接受宣判。 斯里尼瓦桑和塔维护的一份电子文档记录了交付给全美国约1400个独特客户的约3800笔药品交易。该记录反映了2022年5月至11月的销售情况，包括123,688颗芬太尼药丸、略低于20磅的甲基苯丙胺以及少量的芬太尼粉末、黑焦油海洛因和可卡因。 对纳维亚和鲁伊斯的起诉是持续打击贩毒工作的一部分。由FBI管理的阿片类暗网犯罪联合执法小组(JCODE)为打击暗网供应商提供了大力帮助。FBI领导的团队自2018年成立以来，已逮捕了300多名在暗网上活动的毒贩，没收了超过4200万美元的毒品相关资金，缴获了800多公斤毒品，并查获了约145支枪支。这些统计数据可以在美国司法部新闻稿中找到。...

根据美国司法部DoJ 周三发布的一份声明，一名 33 岁的塞尔维亚男子承认在暗网上经营一个名为“垄断市场Monopoly Market的贩毒平台，该市场通过出售超过 30 公斤的冰毒和大量其他毒品来换取各种加密货币，从而赚取了 1800 万美元。 33 岁的 Milomir Desnica 据称从 2019 年底开始启动并运营暗网市场 Monopoly Market，根据法庭记录，该市场是一个典型的网上贩毒商店，用户可以在其中浏览并购买大麻、摇头丸、阿片类药物、处方药和兴奋剂等类别的毒品。 客户被要求用加密货币（例如比特币或门罗币）从个体供应商那里购买药物，这些供应商对每笔销售都收取佣金。Milomir Desnica 的职责包括批准想要在暗网市场成为“供应商”的毒品供应商。 Desnica正在哥伦比亚特区受审，定于明年2月宣判。他可能面临最高终身监禁和经济处罚。 警方使用加密货币购买毒品并找到暗网市场的经营者 2021 年，美国执法部门在Monopoly Market中向不同供应商提交订单，当局在Monopoly Market暗网市场上订购了 100 多克甲基苯丙胺。通过调查，FBI 确定Monopoly Market在全球范围内促成了价值超过 1800 万美元的毒品销售，其中包括向美国客户出售了超过 30 公斤的甲基苯丙胺。 2021 年 12 月，美国执法部门与德国和芬兰的外国执法合作伙伴协调，查获了托管“Monopoly Market”暗网市场的计算机服务器并将其下线。通过对被扣押的服务器的分析，执法部门确定了毒品销售记录、记录Monopoly Market（与Monopoly Market相关的在线论坛）上加密货币支付的财务记录、Monopoly Market运营者与供应商的通信记录、佣金付款发票等。通过对这些记录的广泛分析，Desnica被确定为大富翁的运营商。 尽管Monopoly Market试图混淆其轨迹，但联邦调查局随后能够使用比特币支付的供应商发票来追踪非法资金。 奥地利当局于 2021 年 11 月找到并逮捕了 Desnica，没收了他的房子、汽车、超过 18,000 欧元、866 美元的 Tether (USDT) 和超过 400 美元的 ETH。Desnica承认，他被扣押的资金与加密货币全部来自Monopoly Market的收益。 这次取缔行动是针对暗网市场采取的最大规模的执法行动之一，最终逮捕了 288 名供应商，超过了 2021 年取缔 DarkMarket 后逮捕的 150 名供应商和 2019 年取缔 Wall Street Market 后逮捕的 179 名商贩。 执法部门除了没收了超过 5340 万美元的现金和虚拟货币，还查获了 850 公斤毒品。 Desnica去年 11 月在奥地利被捕，2023 年 6 月 23 日，Desnica被从奥地利引渡到美国，面临贩毒指控。 据称，Desnica至少使用了两种加密货币兑换服务来洗钱其非法收益。检察官在 6 月份的一份声明中表示，他随后将加密货币出售给塞尔维亚的点对点交易员，以换取法定货币，以“清洗”自己的收入。...

点击围观  ...

点击围观  ...

在 Arch Linux 上安装 Docker 很简单。它可以在 Extra 仓库中找到，你可以简单地 执行 pacman 魔法： sudo pacman -S docker 但要在 Arch Linux 上正确运行 Docker，还需要执行更多步骤。 让 Arch Docker 做好准备 这一切都归结为以下步骤： 从 Arch 仓库安装 Docker 启动 Docker 守护进程并在每次启动时自动运行 将用户添加到 docker组以运行docker命令而无需sudo 让我们看看详细步骤。 步骤 1：安装 Docker 包 打开终端并使用以下命令： sudo pacman -S docker 输入密码并在询问时按 Y。 这可能需要一些时间，具体取决于你使用的镜像。 ? 如果你看到找不到包或 404 错误，那么你的同步数据库可能是旧的。使用以下命令更新系统（它将下载大量软件包并需要时间）： sudo pacman -Syu 步骤 2：启动 docker 守护进程 Docker 已安装但未运行。你应该在第一次运行 Docker 命令之前启动 Docker 守护进程： sudo systemctl start docker.service 我还建议启用 Docker 服务，以便 Docker 守护进程在系统启动时自动启动。 sudo systemctl enable docker.service 这样，你就可以开始运行 docker命令了。你不再需要手动启动 Docker 服务。 步骤 3：将用户添加到 docker 组 Docker 已安装并且 Docker 服务正在运行。你几乎已准备好运行 docker命令。 但是，默认情况下，你需要将 sudo与docker命令一起使用。这很烦人。 为了避免在每个 docker命令中使用sudo，你可以将自己（或任何其他用户）添加到docker组，如下所示： sudo usermod -aG docker $USER 你必须注销（或关闭终端）并重新登录才能使上述更改生效。如果你不想这样做，请使用以下命令： newgrp docker 现在已经准备好了。我们来测试一下。 步骤 4：验证 docker 安装 Docker 本身提供了一个很小的 Docker 镜像来测试 Docker 安装。运行它并查看是否一切正常： docker run hello-world 你应该看到类似这样的输出，表明 Docker 成功运行： 恭喜！ 你已经在 Arch Linux 上成功安装了 Docker。 可选：安装 Docker Compose Docker Compose 已经成为 Docker 不可或缺的一部分。它允许你管理多个容器应用。 较早的经典 Compose 由 docker-composePython 软件包提供。Docker 还将其移植到 Go 中，并通过docker compose提供，但该软件包附带Docker Desktop。 在这个阶段，我建议使用经典的 docker-compose插件并使用以下命令安装它： sudo pacman -S docker-compose 故障排除技巧 以下是你可能遇到的一些常见问题以及可能的解决方案： 制表符补全不适用于 docker 子命令 如果你想对 docker命令选项使用制表符补全（例如将im补全到images等），请安装bash-completion包： sudo pacman -S bash-completion 关闭终端并启动一个新终端。你现在应该能够通过 docker命令使用制表符补全功能。 无法连接到 Docker 守护进程错误 如果你看到以下错误： docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. See 'docker run --help'. 那是因为 Docker 守护进程没有运行。参考步骤 2，启动 Docker 服务，确保其正在运行并启用它，以便 Docker 守护进程在每次启动时自动运行。 sudo systemctl start docker.service sudo systemctl enable docker.service 尝试连接到 Docker 守护程序套接字时权限被拒绝 如果你看到此错误： ddocker: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create": dial unix /var/run/docker.sock: connect: permission denied. See 'docker run --help'. 这是因为你需要使用 sudo运行docker命令，或者将用户添加到docker组以在不使用sudo的情况下运行docker命令。 我希望这篇简短的文章可以帮助你在 Arch Linux 上运行 Docker。 ...

浅拷贝 浅拷贝仅复制对象本身，而不会递归复制其内部包含的对象或数据结构。 对于复杂对象，如包含指针或引用的对象，浅拷贝会导致多个对象共享相同的内部数据。 浅拷贝通常是通过复制对象的成员变量来实现的，但对于内部指针或引用，只是复制了指针或引用本身，而不是它们引用的对象。 深拷贝 深拷贝会递归地复制对象本身及其内部的所有对象和数据结构，确保每个复制的对象都是全新的，没有共享内部数据。 对于复杂对象，深拷贝可以消除共享数据的问题，每个对象都有自己的拷贝。 深拷贝需要在拷贝过程中为每个内部对象或数据结构创建全新的副本，通常需要更多的时间和内存。 总结 使用浅拷贝时，多个对象可能会出现数据不一致的问题，因为它们共享相同的内部数据。 深拷贝确保了每个对象都是独立的，但可能需要更多的资源。 ...

使用函数或运算符处理列 当在查询条件中对列进行函数调用或进行运算时，索引通常会失效。 例如，WHERE DATE_FORMAT(column, '%Y-%m-%d') = '2023-11-10'，这种情况下，无法使用列上的索引。 使用通配符前缀 当在查询条件中使用通配符前缀（如LIKE 'prefix%'）时，通常无法使用索引。 使用OR条件 在WHERE子句中使用多个OR条件时，如果每个条件都没有适用的索引，那么索引可能会失效。 不等于条件 当使用不等于条件（!=或<>）时，索引通常会失效。 数据分布不均匀 如果索引列上的数据分布极不均匀，即某些值出现非常频繁，而其他值出现很少，索引可能会失效。这会导致查询优化器认为扫描整个表更快。 大数据表 当表非常大时，即使索引存在，查询优化器可能会选择执行全表扫描，因为扫描整个表可能比使用索引更快。 列数据类型不匹配 当查询条件中的列数据类型与索引列数据类型不匹配时，索引可能会失效。例如，对字符串列应用数值函数。 连接操作（JOIN） 在连接操作中，如果没有适用的索引来支持连接条件，索引可能会失效。 类型转换 当查询条件中的列需要进行类型转换以与索引列匹配时，索引通常会失效。 子查询 子查询可能会导致索引失效，尤其是当子查询结果集非常大时。 ...

定位慢查询 数据库监控工具：使用数据库监控工具，如MySQL的Slow Query Log或PostgreSQL的pg_stat_statements，来识别慢查询。这些工具可以记录执行时间较长的查询。 查询执行计划：对于关系型数据库，查看查询执行计划是一种重要的方式来定位性能问题。通过EXPLAIN或EXPLAIN ANALYZE命令，可以查看数据库是如何执行查询的，以及是否有性能问题。 应用层监控：使用应用层性能监控工具来识别慢查询的来源。这些工具可以告诉你哪些查询正在导致性能下降。 监控索引：确保表上使用了适当的索引。缺少索引或者使用不当的索引可能导致查询变慢。 检查服务器负载：如果服务器负载过高，可能导致查询变慢。检查服务器的CPU、内存和磁盘使用情况。 优化慢查询 索引优化：确保数据库表上的列有适当的索引，这有助于加速检索。但不要过度索引，因为索引也会增加写操作的开销。 重写查询：有时，可以通过重写查询语句来优化查询性能。使用合适的WHERE子句、JOIN条件和ORDER BY子句等。 缓存：使用缓存来减少数据库查询的频率。可以使用缓存中间件（如Redis或Memcached）或应用程序级别的缓存。 升级硬件：如果服务器性能不足，可以考虑升级硬件，包括CPU、内存和存储。 分区：对于大型表，可以考虑分区，以减小查询的范围。 定期维护：定期执行数据库维护操作，如索引重建、表优化和统计信息更新，以确保数据库性能不下降。 限制结果集大小：通过限制查询返回的结果集大小，可以减轻数据库负担。 异步处理：将某些查询从同步操作改为异步操作，以提高应用程序的响应速度。 数据库分片：对于大型数据库，可以考虑数据库分片，将数据分散到多个服务器上以提高查询性能。 使用合适的数据库引擎：不同的数据库引擎具有不同的性能特点。根据应用程序需求选择合适的数据库引擎。 ...

数据存储方式 B树：B树的每个节点既存储数据也存储索引。这意味着B树的非叶子节点既包含索引键也包含对应的数据。 B+树：B+树的非叶子节点仅存储索引键，而数据全部存储在叶子节点。B+树的所有叶子节点通过指针连接成一个有序链表，便于范围查询。 叶子节点关联性 B树：B树的叶子节点和非叶子节点没有直接关联，各自独立存在。 B+树：B+树的叶子节点之间通过链表相连，形成了一个有序的链表。这有助于范围查询，因为数据按顺序排列。 范围查询效率 B树：在B树上进行范围查询相对较慢，因为需要访问非叶子节点和叶子节点。 B+树：B+树在范围查询时非常高效，因为只需遍历叶子节点的链表。 非叶子节点的索引键 B树：非叶子节点的索引键可以是重复的，可能导致不必要的冗余数据。 B+树：B+树的非叶子节点的索引键一般是不重复的，确保了索引的唯一性。 叶子节点个数 B树：B树的叶子节点数量和数据记录数量相等。 B+树：B+树的叶子节点数量比数据记录数量多，因为叶子节点主要用于存储数据和维护链表，而非叶子节点用于索引。 B+树 B树 ...

连接导向 vs 无连接 TCP是一种面向连接的协议，它在数据传输前需要建立连接，确保数据的可靠性和有序性，然后在传输完成后释放连接。 UDP是一种无连接的协议，它不需要在传输数据前建立连接，也不维护连接状态，数据包之间相互独立，不会保证数据的可靠性和有序性。 可靠性 TCP提供可靠的数据传输。它使用序号、确认和重传机制来确保数据包的正确性，确保数据不丢失和按顺序传输。 UDP不提供可靠性。它只是简单地将数据包从源发送到目标，不提供确认、重传或错误检查。 数据量 TCP适用于大量数据的可靠传输，如文件传输、网页访问等。 UDP适用于需要快速传输和可以容忍一些数据丢失的应用，如实时音视频流、在线游戏等。 开销 TCP协议在建立和维护连接时有较高的开销，因为它需要进行三次握手、四次挥手等操作，以确保可靠性。 UDP协议的开销较低，因为它不涉及连接的建立和维护。 适用场景 TCP适用于需要可靠数据传输和流控制的场景，如HTTP、FTP等传统应用。 UDP适用于对实时性要求较高、可以容忍一些数据丢失的应用，如音频/视频流、在线游戏、DNS查询等。 总结 ...

数据传输方式 GET：通过URL将数据附加在请求中，数据暴露在URL中，通常用于请求数据，对请求参数有长度限制，通常在2048字符以内。 POST：通过请求正文传输数据，数据不暴露在URL中，通常用于发送数据，对请求参数没有固定的长度限制，可以传输大量数据。 安全性 GET：传输的数据在URL中可见，因此不适合传输敏感信息，如密码。 POST：传输的数据在请求正文中，相对更安全，适合传输敏感信息。 缓存 GET：请求可以被缓存，对相同URL的多次GET请求可以从缓存中获取响应，具有幂等性（多次请求产生相同结果）。 POST：请求不能被缓存，每次POST请求都会向服务器发送数据，不具有幂等性。 幂等性 GET：GET请求通常应该是幂等的，即多次执行相同的GET请求应该产生相同的结果。 POST：POST请求通常不是幂等的，多次执行相同的POST请求可能会导致不同的结果。 书签和浏览器历史 GET：可以被添加为书签，可以在浏览器历史中记录。 POST：通常不会被添加为书签，不会出现在浏览器历史中。 数据类型 GET：通常用于请求资源，如网页、图片等。 POST：通常用于提交表单数据、上传文件等。 总结 ...