分时与实时操作系统

转自网上的一些资讯。

裸机

没有运行操作系统的计算机称之为“裸机”,操作系统是在裸机上建立的一个最基础的工作环境,为其上运行的各种支撑软件和应用软件提供最基础的系统服务。

设有一个计算任务可分解为输入、处理、打印等三个子任务,为了使它们能并行工作,可引入缓冲技术,即输入子任务从输入设备读一批数据到输入缓冲区,处理子任务把输入缓冲区中的数据处理后放入输出缓冲区,打印子任务打印输出缓冲区中的内容,这样,输入子任务可以与打印子任务并行工作。因为处理器处理数据的速度很快,可以忽略其计算时间,这样就使完成一批数据加工的总时间近似等于较慢的设备输入或输出的时间。

批处理系统

Batch Processing

回想一下计算机历史,当操作系统开始出现的时候,当时的需求是解决人机矛盾及CPU和I/O设备之间速度不匹配的矛盾,此时出现了批处理系统。

在批处理系统中,用户将作业交给系统操作员,系统操作员将许多用户的作业组成一批作业,输入到计算机中,在系统中形成一个自动转接的连续的作业流,然后启动操作系统,系统自动、依次执行每个作业。最后由操作员将作业结果交给用户。

批处理操作系统的主要特点是:脱机、多道和成批处理

脱机是指用户提交作业之后直到获得结果之前几乎不再和计算机打交道。

多道是指按多道程序设计的调度原则,从一批后备作业中选取多道作业调入内存并组织它们运行。

成批处理是指操作员把用户提交的作业组织成一批,由操作系统负责每批作业间的自动调度。

批处理系统自动化程度比较高,系统吞吐量大,资源利用率高,系统开销小,但各作业周转时间长,不提供用户与系统的交互手段,适合大的成熟的作业。

可以看到批处理系统对机器来说资源利用率高,吞吐量大,但对人效率低的系统。问题的根源在于用户无法与系统交互获得反馈。根据操作系统所管理的资源以及所提供服务方式的不同,在此之后的操作系统可以分为两大类型:

  • 分时操作系统 Time Sharing Operating System
  • 实时操作系统 Real Time Operating System,RTOS

实时操作系统

例如:uCOS/VxWorks/RTLinux。

实时操作系统往往是专用的,在特定的应用中作为一种控制系统来使用。实时操作系统的一个主要特点在于有严格的时间限制,即每一个信息接收、分析处理和发送的过程必须在规定的时间内完成。这就要求系统的一切活动都必须在一个严格的计时程序的控制下运行。

  1. 高精度计时系统:计时精度是影响实时性的一个重要因素。在实时应用系统中,经常需要精确确定实时地操作某个设备或执行某个任务,或精确的计算一个时间函数。这些不仅依赖于一些硬件提供的时钟精度,也依赖于实时操作系统实现的高精度计时功能。
  2. 多级中断机制:一个实时应用系统通常需要处理多种外部信息或事件,但处理的紧迫程度有轻重缓急之分。有的必须立即作出反应,有的则可以延后处理。因此,需要建立多级中断嵌套处理机制,以确保对紧迫程度较高的实时事件进行及时响应和处理。
  3. 实时调度机制:实时操作系统不仅要及时响应实时事件中断,同时也要及时调度运行实时任务。但是,处理机调度并不能随心所欲的进行,因为涉及到两个进程之间的切换,只能在确保“安全切换”的时间点上进行,实时调度机制包括两个方面,一是在调度策略和算法上保证优先调度实时任务;二是建立更多“安全切换”时间点,保证及时调度实时任务。

实时操作系统是保证在一定时间限制内完成特定功能的操作系统。实时操作系统有硬实时和软实时之分,

  • 硬实时要求在规定的时间内必须完成操作,这是在操作系统设计时保证的;
  • 软实时则只要按照任务的优先级,尽可能快地完成操作即可。
  • 我们通常使用的操作系统在经过一定改变之后就可以变成实时操作系统。

例如,可以为确保生产线上的机器人能获取某个物体而设计一个操作系统。在“硬”实时操作系统中,如果不能在允许时间内完成使物体可达的计算,操作系统将因错误结束。在“软”实时操作系统中,生产线仍然能继续工作,但产品的输出会因产品不能在允许时间内到达而减慢,这使机器人有短暂的不生产现象。

分时操作系统

例如:Linux/Windows/OSX,基于时间片轮转的操作系统。

分时操作系统允许多个用户同时运行自己的程序。操作系统接收每个用户的服务命令,采用时间片轮转的方式处理用户的服务请求。对每个用户而言,都仿佛自己“占有”了整个计算机。

分时系统具有多路性、独立性、及时性和交互性,与批处理相比,系统开销大,资源利用率与系统接纳的作业有关,适合小的不成熟的作业。批处理和分时是以作业为单位进行处理的系统,是一个通用系统。

多路性是指一台计算机与若干台终端相连接,终端上的这些用户可以同时或基本同时使用计算机;

交互性是指用户的操作方式是联机方式,即用户通过终端采用人-机会话的方式直接控制程序运行,同程序进行交互;

独占性是指由于系统采用时间片轮转的办法使一台计算机同时为许多终端用户服务,因此客观效果是这些用户彼此间都感觉不到别人也在使用这台计算机,好像只有自己独占计算机一样;

及时性是指用户请求能在很短时间内获得响应。

分时系统和实时系统的比较

img

实时操作系统,它是可抢占性的内核。高优先级任务就绪而低优先级任务正在执行没有sleep的时候,高优先级任务会打断低优先级任务而立即得到执行。如图,当优先级更高的任务2就绪的时候,即便任务1正在运行中,也必须立刻交出CPU的使用权,就跟中断一样,先执行任务2,等任务2执行完或者主动挂起(sleep)让出CPU的时候,任务1才能接着运行。

img

在分时操作系统中,CPU是不可抢占的,即便高优先级的任务就绪了,也不能马上中断低优先级任务而得到执行,必须要等到低优先级任务主动挂起(sleep)或者时间片结束才能得到执行。

分布式计算、平行计算

并行计算(Parallel Computing)

  并行计算是相对于串行计算来说的。并行计算(Parallel Computing)是指同时使用多种计算资源解决计算问题的过程。为执行并行计算,计算资源应包括一台配有多处理机(并行处理)的计算机、一个与网络相连的计算机专有编号,或者两者结合使用。并行计算的主要目的是快速解决大型且复杂的计算问题。

  并行计算可以划分成时间并行和空间并行。时间并行即流水线技术,空间并行使用多个处理器执行并发计算,当前研究的主要是空间的并行问题。以程序和算法设计人员的角度看,并行计算又可分为数据并行和任务并行。数据并行把大的任务化解成若干个相同的子任务,处理起来比任务并行简单。

  空间上的并行导致两类并行机的产生,按照Michael Flynn(费林分类法)的说法分为单指令流多数据流(SIMD)和多指令流多数据流(MIMD),而常用的串行机也称为单指令流单数据流(SISD)。MIMD类的机器又可分为常见的五类:并行向量处理机(PVP)、对称多处理机(SMP)、大规模并行处理机(MPP)、工作站机群(COW)、分布式共享存储处理机(DSM)。

分布式计算(Distributed Computing)

  分布式计算这个研究领域,主要研究分散系统(Distributed system)如何进行计算。分散系统是一组计算机,通过计算机网络相互链接与通信后形成的系统。把需要进行大量计算的工程数据分区成小块,由多台计算机分别计算,在上传运算结果后,将结果统一合并得出数据结论的科学。

  目前常见的分布式计算项目通常使用世界各地上千万志愿者计算机的闲置计算能力,通过互联网进行数据传输。如分析计算蛋白质的内部结构和相关药物的Folding@home项目,该项目结构庞大,需要惊人的计算量,由一台电脑计算是不可能完成的。即使现在有了计算能力超强的超级电脑,但是一些科研机构的经费却又十分有限。

分布式计算比起其它算法具有以下几个优点:

  1. 稀有资源可以共享。
  2. 通过分布式计算可以在多台计算机上平衡计算负载。
  3. 可以把程序放在最适合运行它的计算机上。其中,共享稀有资源和平衡负载是计算机分布式计算的核心思想之一。

并行计算与分布式计算的区别

并行计算与分布式计算都是运用并行来获得更高性能,化大任务为小任务。简单说来,如果处理单元共享内存,就称为并行计算,反之就是分布式计算。也有人认为分布式计算是并行计算的一种特例。

分布式的任务包互相之间有独立性,上一个任务包的结果未返回或者是结果处理错误,对下一个任务包的处理几乎没有什么影响。因此,分布式的实时性要求不高,而且允许存在计算错误(因为每个计算任务给好几个参与者计算,上传结果到服务器后要比较结果,然后对结果差异大的进行验证。

分布式要处理的问题一般是基于寻找模式的。所谓的寻找,就相当于穷举法!为了尝试到每一个可能存在的结果,一般从0~N( 某一数值)被一个一个的测试,直到我们找到所要求的结果。事实上,为了易于一次性探测到正确的结果,我们假设结果是以某个特殊形式开始的。在这种类型的搜索里,我们也许幸运的一开始就找到答案;也许不够走运以至于到最后才找到答案,这都很公平。

并行程序并行处理的任务包之间有很大的联系,而且并行计算的每一个任务块都是必要的,没有浪费的分割的,就是每个任务包都要处理,而且计算结果相互影响,就要求每个的计算结果要绝对正确,而且在时间上要尽量做到同步。

分布式的编写一般用的是C++(也有用JAVA的,但是都不是主流),基本不用MPI接口。并行计算用MPI或者OpenMP。

集群计算、超算

集群计算(Cluster Computing)

计算机集群将一组松散集成的计算机软件或硬件连接起来高度紧密地协作完成计算工作。在某种意义上,他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点,通常通过局域网连接,但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机,比如工作站或超级计算机性价比要高得多。

根据组成集群系统的计算机之间体系结构是否相同,集群可分为两种。

  • 同构
  • 异构

集群计算机按功能和结构可以分为:

  • 高可用性集群(High-availability (HA) clusters)、
  • 负载均衡集群(Loadbalancing clusters)、
  • 高性能计算集群(High-performance (HPC)clusters)、
  • 网格计算(Grid computing)。

高可用性集群,一般是指当集群中有某个节点失效的情况下,其上的任务会自动转移到其他正常的节点上。还指可以将集群中的某节点进行离线维护再上线,该过程并不影响整个集群的运行。

负载均衡集群,负载均衡集群运行时,一般通过一个或者多个前端负载均衡器,将工作负载分发到后端的一组服务器上,从而达到整个系统的高性能和高可用性。这样的计算机集群有时也被称为服务器群(Server Farm)。一般高可用性集群和负载均衡集群会使用类似的技术,或同时具有高可用性与负载均衡的特点。Linux虚拟服务器(LVS)项目在Linux操作系统上提供了最常用的负载均衡软件。

高性能计算集群,高性能计算集群采用将计算任务分配到集群的不同计算节点儿提高计算能力,因而主要应用在科学计算领域。比较流行的HPC采用Linux操作系统和其它一些免费软件来完成并行运算。这一集群配置通常被称为Beowulf集群。这类集群通常运行特定的程序以发挥HPC cluster的并行能力。这类程序一般应用特定的运行库, 比如专为科学计算设计的MPI库。HPC集群特别适合于在计算中各计算节点之间发生大量数据通讯的计算作业,比如一个节点的中间结果或影响到其它节点计算结果的情况。

网格计算,通过利用大量异构计算机的未用资源(CPU周 期和磁盘存储),将其作为嵌入在分布式电信基础设施中的一个虚拟的计算机集群,为解决大规模的计算问题提供一个模型。网格计算的焦点放在支持跨管理域计算 的能力,这使它与传统的计算机集群或传统的分布式计算相区别。网格计算的目标是解决对于任何单一的超级计算机来说仍然大得难以解决的问题,并同时保持解决 多个较小的问题的灵活性。这样,网格计算就提供了一个多用户环境。

参考资料


MacOS homebrew 更改为阿里源

简介

Homebrew 是一个软件包管理系统,用以简化 macOS 和 linux 系统上的软件安装过程。它拥有安装、卸载、更新、查看、搜索等很多实用的功能,通过简单的一条指令,就可以实现包管理,十分方便快捷。

Homebrew 主要有四个部分组成: brewhomebrew-corehomebrew-bottleshomebrew-cask

名称 说明
brew Homebrew 源代码仓库
homebrew-core Homebrew 核心软件仓库
homebrew-bottles Homebrew 预编译二进制软件包
homebrew-cask 提供 macOS 应用和大型二进制文件

替换为阿里源

# 查看 brew.git 当前源
$ cd "$(brew --repo)" && git remote -v
origin    https://github.com/Homebrew/brew.git (fetch)
origin    https://github.com/Homebrew/brew.git (push)

# 查看 homebrew-core.git 当前源
$ cd "$(brew --repo homebrew/core)" && git remote -v
origin    https://github.com/Homebrew/homebrew-core.git (fetch)
origin    https://github.com/Homebrew/homebrew-core.git (push)

# 修改 brew.git 为阿里源
$ git -C "$(brew --repo)" remote set-url origin https://mirrors.aliyun.com/homebrew/brew.git

# 修改 homebrew-core.git 为阿里源
$ git -C "$(brew --repo homebrew/core)" remote set-url origin https://mirrors.aliyun.com/homebrew/homebrew-core.git

# zsh 替换 brew bintray 镜像
$ echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.aliyun.com/homebrew/homebrew-bottles' >> ~/.zshrc
$ source ~/.zshrc

# bash 替换 brew bintray 镜像
$ echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.aliyun.com/homebrew/homebrew-bottles' >> ~/.bash_profile
$ source ~/.bash_profile

# 刷新源
$ brew update

重置为官方源

# 重置 brew.git 为官方源
$ git -C "$(brew --repo)" remote set-url origin https://github.com/Homebrew/brew.git

# 重置 homebrew-core.git 为官方源
$ git -C "$(brew --repo homebrew/core)" remote set-url origin https://github.com/Homebrew/homebrew-core.git

# 重置 homebrew-cask.git 为官方源
$ git -C "$(brew --repo homebrew/cask)" remote set-url origin https://github.com/Homebrew/homebrew-cask

# zsh 注释掉 HOMEBREW_BOTTLE_DOMAIN 配置
$ vi ~/.zshrc
# export HOMEBREW_BOTTLE_DOMAIN=xxxxxxxxx

# bash 注释掉 HOMEBREW_BOTTLE_DOMAIN 配置
$ vi ~/.bash_profile
# export HOMEBREW_BOTTLE_DOMAIN=xxxxxxxxx

# 刷新源
$ brew update

Kubernetes的Kata Containers 与 gVisor - ghostwritten

原文:https://blog.csdn.net/xixihahalelehehe/article/details/119942945

1. 容器发展

使用虚拟化技术来做一个像 Docker 一样的容器项目,并不是一个新鲜的主意。早在 Docker 项目发布之后,Google 公司就开源了一个实验性的项目,叫作 novm。这,可以算是试图使用常规的虚拟化技术来运行 Docker 镜像的第一次尝试。不过,novm 在开源后不久,就被放弃了,这对于 Google 公司来说或许不算是什么新鲜事,但是 novm 的昙花一现,还是激发出了很多内核开发者的灵感。

所以在 2015 年,几乎在同一个星期,Intel OTC (Open Source Technology Center) 和国内的 HyperHQ 团队同时开源了两个基于虚拟化技术的容器实现,分别叫做 Intel Clear ContainerrunV 项目。

而在 2017 年,借着 Kubernetes的东风,这两个相似的容器运行时项目在中立基金会的撮合下最终合并,就成了现在大家耳熟能详的 Kata Containers 项目。 由于 Kata Containers 的本质就是一个精简后的轻量级虚拟机,所以它的特点,就是“像虚拟机一样安全,像容器一样敏捷”。

而在 2018 年,Google 公司则发布了一个名叫 gVisor 的项目。gVisor 项目给容器进程配置一个用 Go 语言实现的、运行在用户态的、极小的“独立内核”。这个内核对容器进程暴露 Linux 内核 ABI,扮演着“Guest Kernel”的角色,从而达到了将容器和宿主机隔离开的目的。

难看到,无论是 Kata Containers,还是 gVisor,它们实现安全容器的方法其实是殊途同归的。这两种容器实现的本质,都是给进程分配了一个独立的操作系统内核,从而避免了让容器共享宿主机的内核。这样,容器进程能够看到的攻击面,就从整个宿主机内核变成了一个极小的、独立的、以容器为单位的内核,从而有效解决了容器进程发生“逃逸”或者夺取整个宿主机的控制权的问题。这个原理,可以用如下所示的示意图来表示清楚。

在这里插入图片描述 而它们的区别在于,Kata Containers 使用的是传统的虚拟化技术,通过虚拟硬件模拟出了一台“小虚拟机”,然后在这个小虚拟机里安装了一个裁剪后的 Linux 内核来实现强隔离。

而 gVisor 的做法则更加激进,Google 的工程师直接用 Go 语言“模拟”出了一个运行在用户态的操作系统内核,然后通过这个模拟的内核来代替容器进程向宿主机发起有限的、可控的系统调用。接下来,我就来为你详细解读一下 KataContainersgVisor 具体的设计原理。

2. KataContainers原理

在这里插入图片描述

我们前面说过,Kata Containers 的本质,就是一个轻量化虚拟机。所以当你启动一个 Kata Containers 之后,你其实就会看到一个正常的虚拟机在运行。这也就意味着,一个标准的虚拟机管理程序(Virtual Machine Manager, VMM)是运行 Kata Containers 必备的一个组件。在我们上面图中,使用的 VMM 就是 Qemu

而使用了虚拟机作为进程的隔离环境之后,Kata Containers 原生就带有了 Pod 的概念。即:这个 Kata Containers 启动的虚拟机,就是一个 Pod;而用户定义的容器,就是运行在这个轻量级虚拟机里的进程。在具体实现上,Kata Containers 的虚拟机里会有一个特殊的 Init 进程负责管理虚拟机里面的用户容器,并且只为这些容器开启 Mount Namespace。所以,这些用户容器之间,原生就是共享 Network 以及其他 Namespace 的。

此外,为了跟上层编排框架比如 Kubernetes 进行对接,Kata Containers 项目会启动一系列跟用户容器对应的 shim 进程,来负责操作这些用户容器的生命周期。当然,这些操作,实际上还是要靠虚拟机里的 Init 进程来帮你做到。而在具体的架构上,Kata Containers 的实现方式同一个正常的虚拟机其实也非常类似。这里的原理,可以用如下所示的一幅示意图来表示。

在这里插入图片描述 可以看到,当 Kata Containers 运行起来之后,虚拟机里的用户进程(容器),实际上只能看到虚拟机里的、被裁减过的 Guest Kernel,以及通过 Hypervisor 虚拟出来的硬件设备。

而为了能够对这个虚拟机的 I/O 性能进行优化,Kata Containers 也会通过 vhost 技术(比如:vhost-user)来实现 GuestHost 之间的高效的网络通信,并且使用 PCI Passthrough (PCI 穿透)技术来让 Guest 里的进程直接访问到宿主机上的物理设备。这些架构设计与实现,其实跟常规虚拟机的优化手段是基本一致的。

3. gVisor原理

相比之下,gVisor 的设计其实要更加“激进”一些。它的原理,可以用如下所示的示意图来表示清楚。

在这里插入图片描述 gVisor 工作的核心,在于它为应用进程、也就是用户容器,启动了一个名叫 Sentry 的进程。 而 Sentry 进程的主要职责,就是提供一个传统的操作系统内核的能力,即:运行用户程序,执行系统调用。所以说,Sentry 并不是使用 Go 语言重新实现了一个完整的 Linux 内核,而只是一个对应用进程“冒充”内核的系统组件。

在这种设计思想下,我们就不难理解,Sentry 其实需要自己实现一个完整的 Linux 内核网络栈,以便处理应用进程的通信请求。然后,把封装好的二层帧直接发送给 Kubernetes 设置的 Pod 的 Network Namespace 即可。

此外,Sentry 对于 Volume 的操作,则需要通过 9p 协议交给一个叫做 Gofer 的代理进程来完成。Gofer 会代替应用进程直接操作宿主机上的文件,并依靠 seccomp 机制将自己的能力限制在最小集,从而防止恶意应用进程通过 Gofer 来从容器中“逃逸”出去。

而在具体的实现上,gVisorSentry 进程,其实还分为两种不同的实现方式。这里的工作原理,可以用下面的示意图来描述清楚。 在这里插入图片描述 第一种实现方式,是使用 Ptrace 机制来拦截用户应用的系统调用(System Call),然后把这些系统调用交给 Sentry 来进行处理。这个过程,对于应用进程来说,是完全透明的。而 Sentry 接下来,则会扮演操作系统的角色,在用户态执行用户程序,然后仅在需要的时候,才向宿主机发起 Sentry 自己所需要执行的系统调用。这,就是 gVisor 对用户应用进程进行强隔离的主要手段。不过, Ptrace 进行系统调用拦截的性能实在是太差,仅能供 Demo 时使用。

而第二种实现方式,则更加具有普适性。它的工作原理如下图所示。

在这里插入图片描述

在这种实现里,Sentry 会使用 KVM 来进行系统调用的拦截,这个性能比 Ptrace 就要好很多了。当然,为了能够做到这一点,Sentry 进程就必须扮演一个 Guest Kernel 的角色,负责执行用户程序,发起系统调用。而这些系统调用被 KVM 拦截下来,还是继续交给 Sentry 进行处理。只不过在这时候,Sentry 就切换成了一个普通的宿主机进程的角色,来向宿主机发起它所需要的系统调用。

可以看到,在这种实现里,Sentry 并不会真的像虚拟机那样去虚拟出硬件设备、安装 Guest 操作系统。它只是借助 KVM 进行系统调用的拦截,以及处理地址空间切换等细节。值得一提的是,在 Google 内部,他们也是使用的第二种基于 HypervisorgVisor 实现。只不过 Google 内部有自己研发的 Hypervisor,所以要比 KVM 实现的性能还要好。

4. 对比

通过以上的讲述,相信你对 Kata Containers 和 gVisor 的实现原理,已经有一个感性的认识了。需要指出的是,到目前为止,gVisor 的实现依然不是非常完善,有很多 Linux 系统调用它还不支持;有很多应用,在 gVisor 里还没办法运行起来。 此外,gVisor 也暂时没有实现一个 Pod 多个容器的支持。当然,在后面的发展中,这些工程问题一定会逐渐解决掉的。

另外,你可能还听说过 AWS 在 2018 年末发布的一个叫做 Firecracker 的安全容器项目。这个项目的核心,其实是一个用 Rust 语言重新编写的 VMM(即:虚拟机管理器)。这就意味着, FirecrackerKata Containers 的本质原理,其实是一样的。只不过, Kata Containers 默认使用的 VMM 是 Qemu,而 Firecracker,则使用自己编写的 VMM。所以,理论上,Kata Containers 也可以使用 Firecracker 运行起来。

在性能上,KataContainers 和 KVM 实现的 gVisor 基本不分伯仲,在启动速度和占用资源上,基于用户态内核的 gVisor 还略胜一筹。但是,对于系统调用密集的应用,比如重 I/O 或者重网络的应用,gVisor 就会因为需要频繁拦截系统调用而出现性能急剧下降的情况。此外,gVisor 由于要自己使用 Sentry 去模拟一个 Linux 内核,所以它能支持的系统调用是有限的,只是 Linux 系统调用的一个子集。

不过,gVisor 虽然现在没有任何优势,但是这种通过在用户态运行一个操作系统内核,来为应用进程提供强隔离的思路,的确是未来安全容器进一步演化的一个非常有前途的方向。值得一提的是,Kata Containers 团队在 gVisor 之前,就已经 Demo 了一个名叫 Linuxd 的项目。这个项目,使用了 User Mode Linux (UML) 技术,在用户态运行起了一个真正的 Linux Kernel 来为应用进程提供强隔离,从而避免了重新实现 Linux Kernel 带来的各种麻烦。