SLO,SLI,SLA的含义

在SLA框架下,SLO 是系统必须要达到的目标;需要尽可能地保障调用方的成功。

有些人可能会对 SLI, SLO, SLA 有困惑,可以先来看下下面三者的关系图。

SLI 定义一个指标,来描述一个服务有多好算达到好的标准。比如 Pod 在 1min 内交付。我们通常从迟延,可

用性,吞吐率,成功率这些角度来制定 SLI。

SLO 定义了一个小目标,来衡量一个 SLI 指标在一段时间内达到好的标准的比例。比如说,99% 的 Pod 在

1min内交付。当一项服务公布了其 SLO 的以后,用户方就会对该服务的质量有了期望。

SLA 是 SLO 衍生出来的协议,常用于 SLO 定义的目标比例没有完成时,服务方要赔多少钱。通常来说,

SLA的协议会具体白纸黑字形成有法律效率的合同,常用于服务供应商和外部客户之间(例如阿里云和阿里云的使

用者)。一般来说对于内部服务之间的 SLO 被打破,通常不会是经济上的赔偿,可能更多的是职责上的认定。

所以,我们在系统内部更多关注的是 SLO。

Posted in 未分类 | Leave a comment

dragonfly 1.0.5 架构学习

dragonfly 1.0.5 架构学习

2.1 学习之前的认知困惑

dragonfly 使用的基于http p2p是如何实现的

  • 主要是文件的如何进行分割的?
  • supernode 的数据是否有重复?
  • 最终下载完毕了合并流程是什么样的。

supernode 在面临突发大流量请求是如何调度的。

比如 A,B,C 同时请求到supernode1上,这时supernode 没有数据源,需要回源请求。最终是同时给A,B,C 是三个实例下发,还是先下发给A,然后B,C 去A拉取。

答案:supernode会进行调度优化,只会给前N个peer进行CDN下载,下载完后进行做种,防止所有的beeget客户端同时下载,失去p2p的意义

supernode 的高可用

答案:目前supernode 的元数据并没有做集群存储,都是分别存储在各自内存map 维护。当一台实例出现故障,目前是通过一致性哈希来取下一台,会增加最大双倍的分发延迟。

2.2 dragonfly 的整体逻辑

2.3 dragonfly的缺点

supernode 在大流量中会是一个瓶颈,并且没有看到高可用方案

在小文件分发中,频繁调度会增加延迟。

2.3.1 kraken 对dragonfly的评价

Dragonfly cluster has one or a few “supernodes” that coordinates the transfer of every 4MB chunk of data in the cluster.

While the supernode would be able to make optimal decisions, the throughput of the whole cluster is limited by the processing power of one or a few hosts, and the performance would degrade linearly as either blob size or cluster size increases.

Kraken’s tracker only helps orchestrate the connection graph and leaves the negotiation of actual data transfer to individual peers, so Kraken scales better with large blobs. On top of that, Kraken is HA and supports cross-cluster replication, both are required for a reliable hybrid cloud setup.

Posted in 云原生 | Leave a comment