forked from daos-stack/daos
-
Notifications
You must be signed in to change notification settings - Fork 0
/
input
77 lines (74 loc) · 6.42 KB
/
input
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
引擎可扩展性加强, https://daosio.atlassian.net/wiki/spaces/DC/pages/11442552865/DAOS+engine+scalability+improvements
DAOS 存储集群应该能够扩展到数千个存储服务器并处理来自数百万个客户端进程的 I/O 请求。DAOS使用的所有分布式协议都可以支持这种级别的可扩展性，但是，从软件设计和实现的角度来看，如果引擎侧没有资源控制，不断地向所有引擎的所有目标发送广播，或者处理来自所有引擎的RPC，客户端进程可以立即消耗存储节点上的所有内存，服务最终将被 OOM Killer 杀死。
要求
提高 DAOS 引擎可扩展性有几个要求：
收集指标并了解每个 I/O RPC 的内存消耗
定义正在处理的并发 RPC 的上限
应预留一定的资源用于重建系统、聚合服务和其他应急服务
当达到阈值时开始拒绝 RPC。
客户端可以在一定时间间隔后重试被拒绝的 RPC
重试间隔应该是随机的，否则如果所有客户端同时开始重试，它们将再次被拒绝
被拒绝的 RPC 可能比常规 RPC 具有更高的优先级
给 RPC 添加优先级？
SWIM RPC始终具有最高优先级，最高优先级的RPC不应被拒绝
常规 RPC 和高优先级 RPC 的单独阈值。
重试时客户端堆栈可能会提高 RPC 优先级
查看其他引擎组件的内存消耗
ULT 堆栈大小
您的缓存
常规数据结构大小
引擎端的通用内存消耗减少。
设计概述
DAOS 服务器 RPC 限制
DAOS 服务器上的资源是有限的，如果服务线程不断为传入的 RPC 创建 ULT，其处理能力将在某个时刻跟不上接收速度，DAOS 引擎将被 OOM Killer 杀死。
为了控制引擎端的资源消耗：
DAOS 引擎应该跟踪传入 RPC 和创建的 ULT 的数量，这些计数器是每个 xstream 的。
ULT 计数器：正在处理 RPC
排队的 RPC 计数器：RPC 已排队（还没有 ULT）
达到一定阈值后，引擎应停止处理传入的 RPC，并简单地拒绝它们。新的错误代码返回给客户端，也可以返回提示（可选）
例如，提示基于过去 10 秒内正在处理、排队和拒绝的 RPC 数量
提示可以是重试时间间隔：5-10秒、10-20秒、20-30秒。
根据返回的错误代码，如果没有提示，DAOS 客户端将在随机时间间隔（在一定范围内）后重试 RPC，或者在服务器提示的时间间隔后重试。
客户端决定重试间隔，或者服务器暗示重试间隔不应该以某种方式随机化，否则结构或服务器将过载，并且 RPC 可能会因拥塞而再次超时。
helper xstream 上的 ULT 管理
如今，每当 I/O xstream 将 RPC 转发卸载到 helper xstream 时，它总是在 helper xstream 上创建一个新的 ULT，这是昂贵的，因为每个 ULT 消耗数十千字节，并且 ULT 的上下文切换也会消耗 CPU 周期。
因为 RPC 转发有一个非常简单的状态机，而不是为每个 RPC 批次创建数千甚至更多的 ULT：
每个助手 xstream 创建一个 RPC 转发 ULT
它还维护一个用于RPC转发任务的队列
其他 xstream 可以在其中一个辅助 xstream 上对 RPC 转发任务进行排队
RPC转发ULT可以处理排队的RPC转发任务
大物体集体打拳
详细信息可以在这里找到：DAOS-14105：集体冲压大型物体
审查中
SWIM 消息的低延迟流量类别
根据与 HPE 的讨论，我们应该为 SWIM 使用“低延迟流量类别”，但这尚未由 Mercury 导出。
SWIM RPC 决不应该被 DAOS 引擎限制。
跟踪票：DAOS-14262：对 SWIM 使用低延迟流量类别
进行中
新的重发检查机制
目前，DAOS 服务器依赖 DTX 表来检测重新发送的 RPC。但是从客户端到服务器没有用于 RPC 回复 ACK 的机制，因此 DAOS 服务器必须保存相关的已提交 DTX 条目，直到通过 DTX 聚合将其删除。主要有两个问题：
DTX表会占用大量资源，尤其是DRAM。如果DTX聚合不能及时清除它们，可能会导致服务器OOM。
DTX 聚合处理大量提交的 DTX 条目将影响常规 IO 进度，因为性能会定期波动。
为了减少DTX表中已提交的DTX条目的数量，关键点是减少维护已提交的DTX条目的时间。基本思想是引入从客户端到服务器的间接 RPC 回复 ACK，该 ACK 通过后续 RPC 捎带至同一目标。一些关键想法：
当线程向目标发送 RPC（任何类型）时，它将检查先前的修改 RPC 是否已回复，如果是，则通过当前 RPC 捎带其信息到目标。然后服务器可以知道相关的DTX条目可以从提交的DTX表中删除。
在服务器端，如果某个 RPC 包含以前的 RPC 回复 ACK 信息，则将相关的 DTX 条目设置为可删除，然后后续的 DTX 聚合稍后会将它们从提交的 DTX 表中删除。另一方面，如果服务器无法及时获得某些DTX的回复ACK，则当早于某个基于时间的阈值时，相关的DTX条目将最终被DTX聚合删除。
为了支持同时向同一目标发送多个 IO 请求，客户端将为每个线程维护一些积分数组。线程在向相关目标发送（修改）RPC之前，需要获得信用并保持该信用直到RPC被回复或失败。
另一个重要因素是 DTX 聚合。目前，DTX聚合是VOS目标本地独立行为。这无法满足上述基于 RPC-reply-ACK 的 RPC 重发检测的要求。关键原因是DTX不是本地事务，而是可能跨越多个目标（对于复制对象或EC对象，或者对于分布式事务）。这意味着具有相同ID的DTX条目可能存在于多个目标上，但是具有前一个ACK的相关RPC仅发送到一个目标。那么当前收到ACK的目标需要让其他相关目标知道这个ACK。请注意，当前的 DTX 可能会与另一个冗余组一起工作，该冗余组与 RPC 中搭载的 ACK 不同，因此我们不能通过当前 DTX 的常规 IO 转发直接搭载它。在这种情况下，将DTX聚合改为全局操作更合适。这会导致服务器之间出现更多的RPC。但我们会将其作为批量操作，因此全局 DTX 聚合的相对开销可能不会太严重。
此功能可能包括 RPC 格式更改，因此也应考虑互操作性。
跟踪票：DAOS-14231：根据 RPC 回复 ACK 重新实现重新发送 RPC 的逻辑
打开
相关页面
渐进式重返社会
渐进式重返社会
DAOS 社区
经常一起读书
蠕虫功能
蠕虫功能
DAOS 社区
页面树图标
一起组织
新的日志记录和错误宏。
新的日志记录和错误宏。
DAOS 社区
经常一起读书
成为第一个添加反应的人