Yuchen You

Plan 9 System (Bell Lab) 硬件设备 目标环境: 便宜的小型机(办公室个人使用)+ 集中管理的大型服务器(file server, cpu server) 分布式环境设计, 强调网络互联和资源共享 UTF-8 /proc rfork 硬件存储抽象 软件文件系统抽象 包括网络的分布式一致性 创新点 设计目标 maintainence: 分布式的个人 pc 进行 administer 一个系统的开销太大太困难了 也就是通过 centralized administration 来实现集中管理 统一接口: 一切皆文件, 通过 9P 协议访问 每个进程拥有独立的命名空间, 可通过 bind 和 mount 重新组合 支持透明分布式: 远程资源与本地资源无差别 简洁内核, 核心任务是 9P 消息的 multiplex/demultiplex File System 层次化文件系统 (hierarchical file system): 所有资源挂入统一目录树 9P 协议: 核心协议, 提供 attach/walk ...

Motivation 和论文目标 守旧派往往认为, 第一代 μ\muμ-kernel 微内核具有非常低的 performance/flexibility, 但是本文希望能测试第二代微内核的性能和灵活性, 实验手段是测试一些老的系统性能测试以及加上一些新的有针对的测试 微内核的优点之一是, 内核小巧, 部件坏的概率小 微内核只提供 mechanism 但是不提供 policy, 但是也需要上面一层安全控制的 pager, FS 等资源, 这些往往依赖于 UNIX Server 实现 Introduction L4 kernel 本身是一个第二代微内核, 拥有 lean & fast 的特性 最初的 L4 kernel 是开发于 Pentium Platform 的, 但是为了证明这个内核抽象能够独立于硬件平台, 所以本文将 L4 在 Alpha21164 平台上重新完整实现了一次并且保留了传统 L4 的接口 (interface); L4 当下是支持 Pentium, Alpha 和 MIPS 三个架构, 后两者为新开发的功能 Pentium 内存空间优化 L4/Pentium ...

Goroutine 在 java/c++ 中我们要实现并发编程的时候, 我们通常需要自己维护一个线程池, 并且需要自己去包装一个又一个的任务, 同时需要自己去调度线程执行任务并维护上下文切换, 这一切通常会耗费程序员大量的心智;那么能不能有一种机制, 程序员只需要定义很多个任务, 让系统去帮助我们把这些任务分配到 CPU 上实现并发执行呢? goroutine 的概念类似于线程, 但 goroutine 是由 Go 的运行时(runtime)调度和管理的;Go 程序会智能地将 goroutine 中的任务合理地分配给每个 CPU; 它在语言层面已经内置了调度和上下文切换的机制 在 Go 语言编程中你不需要去自己写进程, 线程, 协程, 你的技能包里只有一个技能–goroutine, 当你需要让某个任务并发执行的时候, 你只需要把这个任务包装成一个函数, 开启一个 goroutine 去执行这个函数就可以了, 就是这么简单粗暴; 用法 只需要在调用函数的时候在前面加上 go 关键字, 就可以为一个函数创建一个 goroutine; 一个 goroutine 必定对应一个函数, 可以创建多 ...

什么是分布式系统? 一个分布式系统, 从物理上说是 用户 -network- 多台服务器主机 形成的一个特殊的系统 如果对这个模型进行抽象, 其实就是 单个terminal 和 多个 process 之间的通信, 其中, 这些 process 空间上分离, 通过网络进行通信, 不应该存在明显延迟, 并且命运不同(一台主机挂了不应该影响其他主机) 从上面的抽象系统目标, 我们还可以更加抽象出分布式系统的设计目标: High availability: 整体的分布式系统应当永远可用 Low latency: 用户请求的响应时间应当足够低 Scalability: 系统支持同时服务多个用户 … 银行后端为例 分布式系统设计的困难可以分为以下几个难点: concurrency: 多个 process 之间的并发控制, 但是之间的网络不可靠, 主机状态不可靠 inconsistency: 数据交换一定会存在可见延迟 ambiguity: 一个存款请求需要等待下游主机反馈 ACK, 但是如果没有收到, 如何判断是哪一步出了问题? 存款是否成功? channel 管道实现的同步 rendez ...

DBMS (Database Management System) A software package designed to store and manage databases. Often loosely called a database. 传统的数据管理, 往往是结合 csv 格式文件来将数据存储起来, 并且允许通过各种约束条件查找, 但是假设存在一个学生数据库系统, 包括 姓名, 年龄, id, 成绩等字段, 如果原始数据的存储方式是分成两个 文件, 一个存储 姓名到 id 的映射, 另一个存储 id 到成绩的映射, 那么采用传统的 c++ 等语言来查找数据, 会存在很多问题, 例如, atomic 的操作, 很难在确保 performance 的前提下能保证 consistency 因此, 为了避免上述问题, 需要一个软件系统来管理数据的存储和访问,确保有以下设计目标: Data Independence: 即客户端需要看到的只是数据的逻辑结构而非实际存储结构 Efficiency Centralized Management Security adn integri ...

Introduction 这篇文章系统性地提出并定义了云计算系统中的"灰色故障"(Gray Failure)问题, 认为它是当前云基础设施高可用性的一大障碍 gray failure component failures whose manifestations are fairly subtle and thus defy quick and definitive detection 系统某部分发生了轻微但持续的问题, 这些问题不易被传统故障检测机制发现, 但已经影响了应用层的性能和可用性;它不同于"失败即停" (fail-stop) 故障, 后者更易被监测和处理 Gray Failure的特征 Differential Observability (差异性可观测性) 对于 gray failure, 不同的组件对于同一个问题的感知是不同的, 尤其是一个实体受到消极影响但是其他实体感受不到这个影响 检测模块可能认为系统还是健康的, 但是实际上应用已经受损 Cloud Anomalies with Gray Failure High redund ...

Introduction 背景问题缺陷 Byzantine 模型假设组件可能出现任意错误甚至恶意行为, 过于复杂难以实施; Fail-stop 模型假设组件要么正常工作, 要么完全停止, 虽然简单易用, 但忽视了现代硬件中常见的"性能故障"; 本文特点 Fail-Stutter 模型: a realistic and yet tractable fault model that accounts for both absolute failure and a new range of performance failures common in modern components. 引入了一个更现实但可操作的故障模型, 结合 fail-stop 和"性能故障"(performance faults); 性能故障指的是组件虽然没完全失效, 但表现不稳定或变慢, 如磁盘速率下降, 缓存命中率降低等; 这种模型认为组件既可以"失败", 也可以"卡顿"或"表现异常"; 需要的模型性质 ( ...

Introduction 这篇论文 Fail-Slow at Scale: Evidence of Hardware Performance Faults in Large Production Systems 由Haryadi S. Gunawi等人发表在第16届USENIX文件与存储技术会议(FAST 2018)上 系统性地揭示了在大规模生产系统中"fail-slow"(故障-缓慢)硬件现象的存在与影响;这类故障指的是硬件仍在运行, 但其性能严重退化, 未达到应有的标准; 硬件类型包括: disk, SSD CPU memory network components 几十年来, 系统领域已经形成了如下成熟的硬件故障模型 (fault model) • Fail-stop(故障停止): 设备完全停止工作并发送明确的错误信号; • Fail-partial(部分失效): 设备部分失效, 部分功能仍然正常; • Fail-transient(瞬时性失效): 偶尔出现错误但会自行恢复; • Corruption fault(数据损坏) 和 Byzantine fau ...

Introduction metastable failures 亚稳态故障 a failure pattern in distributed systems Currently, metastable failures manifest themselves as black swan events(黑天鹅事故) they are outliers(异常事故) because nothing in the past points to their possibility have a severe impact much easier to explain in hindsight(事后) than to predict. Although instances of metastable failures can look different at the surface, deeper analysis shows that they can be understood within the same framework. By reviewing experiences fr ...

Introduction 这篇文章是基于 MetaStable Failures in Distributed Systems 的升级, in the wild 指的是不可控的实际世界 In this work, we study the prevalence(患病率) of such failures in the wild by scouring(冲刷) over publicly available incident reports from many organizations, ranging from hyperscalers to small companies In this paper, we make four contributions that extend the work of Bronson et al. and increase our understanding of metastable failures: A study of metastable failures in the wild that confirms metastable fai ...