这学期给自己挖了个坑:由于觉得应该帮助学生了解分布式计算(现在的大数据是分布式计算在当下的典型代表),就在负责的操作系统中允诺梳理下所谓的 DOS (Distributed Operating System)的内容。其中比较费精力的就是梳理出计算机和操作系统的历史演变:因为操作系统的核心功能就是管控资源(硬件资源自然是主要的部件,此外也还有所谓的文件系统、数据结构等资源),那么,计算机变了,操作系统也就必须随之改变。
而之所以费精力,就是因为那些时间往往隐含在许许多多的网页、书籍等资料中,而且有时候不同资料中记录的时间信息也有冲突(有些体会到清末疑古派所做考据功夫的艰辛😀)。
临近期末,好赖也就这样了,也就有了下面的按照时间线梳理的相关事件的图例。
*1: 之所以有 Communication一列,是为了突出它,因为分布式系统的基础功能就是要支持远程进程间的相互协同,Communication自然是其中的关键;
*2: 查阅很多所谓的 分布式系统的视频,其实大量探讨的是 "分布式数据库管理系统" 的专题,所以,在梳理过程中于 DOS 应该包含哪些内容就很困惑。后来,觉得还是以"支持程序的运行"这一根本特征,也所以分布式数据库管理系统的内容就剔除了出去,如 2PC (2 Phase Commit) 和 3PC (3 Phase Commit)
也有一些有趣的体悟:
-
当下OS课程的专题,可概括为 "在von Neumann 架构(有限的资源 - 1个CPU和2个线性地址空间 [内存和硬盘])的计算机上支持多个程序的并发运行";类似的,DOS的专题可概括为"在分布式系统或并行计算机上支持多个程序的并发运行"
-
分布式环境下,操作系统的角色更多地对应Local OS + Job Scheduler 的方式 - 对于 Local OS,现在Linux 是主流 (从SuperComputer Top 500 中可窥一斑);而 Job Scheduler,早期有 UNIX集群上的 PBS,后来 Linux计算上的 LSF、SLURM,以及面向大数据环境的 Borg、K8S。国内华为的 Donau算是混合集群的调度器。
-
在 "操作系统的角色更多地对应Local OS + Job Scheduler 的方式" 的环境下,分散的 CPUs、内存和 分布式文件系统、分布式Naming、分布式事务管理等,也就只是起到了 被"Local OS + Job Scheduler"管控的"资源"
- 按照 Communication,TeleCommunication --> TCP/IP --> RPC (RMI等) --> 专门的 通信接口 (PVM和 MPI等) --> Middleware (CORBA, DCOM等) --> Web Service Middleware (Globus, SOA) --> Clouding
- 微内核其实是失败了的 - 不管是 Ameoba, MINIX, 还是Chorus。主要的原因是因为性能太差,而 UNIX 以及后来的 Linux很不错
- 而 Job 往往是 "MPI +" 的编程方式来实现的,如 "MPI + OpenMP"、"MPI + CUDA" 、"MPI + Deep Learning"等
-
保障集群节点的状态一致,PAXOS 是绕不过去的协议!由 Leslie Lamport 1989年以故事的形式撰文,但故事性太强不符合工科学者的思维,后来2003年"PAXOS made simple" 版本才妥协使用计算机术语来撰写。
- 看资料,有学者认为:在 Consensus 问题上,方案就两种,一种是 PAXOS,另一种是其他
- RAFT是 PAXOS的简化版本,发表于2014年
- PAXOS 等和 2PC、3PC 虽有相似之处,但应对的场景是不同的:后者的理解可以参考网上订票 - 涉及出票系统和扣钱系统,它们要遵循"要么都完成,要么啥也不能改变" 的事务的概念;而前者往往只用于状态的记录(也就多对应 "分散节点的日志要保障一致")
-
虽然相关概念和技术(计算机和操作系统) 的 "0-->1" 主要是国外完成的,但是,在"1 --> N" 的环节,国人奋起赶上,如操作系统有 华为的 鸿蒙、欧拉,阿里的 龙蜥;在大数据领域就更多了,Kylin、OceanDB、X-DB、TiDB、ShardingSphere、RoketMQ等等
网友评论