1.华为openEuler21.03版本怎么样
2.sysctl 参数防篡改 - 基于 ebpf 的容器容器实现 [一]
3.Linux内核源码解析---cgroup实现之整体架构与初始化
4.å¦ä½å¦ä¹ Docker
华为openEuler21.03版本怎么样
华为 openEuler .是华为发布的全新创新桌面选择。该版本属于全新的源码创新版本而不是 LTS (Long Term Support) 版本。全新的容器容器创新桌面为用户们带来的是更强的虚拟化功能和更多桌面选择支持。
华为 openEuler .介绍
全新的源码5.内核
1、深度优化调度、容器容器IO、源码功夫小子游戏源码内存管理,容器容器提供Arm、源码x、容器容器RISC-V等更多计算能力支持。源码
2、容器容器对调度程序进行了优化,源码以优化CFS任务的容器容器公平性,并添加了感知numa的源码异步调用机制,这在NVDIMM初始化方面有了显著的容器容器改进;优化了SCHED_IDLE的调度策略,显著提高了高优先级任务的调度延迟,降低了其他任务干扰的成本。
3、numa平衡机制的优化带来了更好的亲和性、更高的利用率和更少的无效迁移。
4、增强CPU隔离机制,支持中断隔离,支持非绑定线程隔离,增强CPU内核隔离,更好地避免业务间相互干扰。
5、优化了cgroup单线程迁移的性能,消除了对线程组读写信号量的依赖;时间名称空间的引入使得容器迁移更加方便。
6、系统容器支持限制容器中使用的文件句柄的数量。文件句柄包括普通的文件句柄和网络套接字。在启动容器时,可以指定——files-limit参数来限制容器中打开句柄的最大数量。
7、PSI能力支持。PSI (Pressure Stall Information)提供了一种评估系统资源(如CPU、vb界面美化源码内存和IO)压力的方法。准确的检测方法可以帮助资源用户确定合适的工作量,也可以帮助系统制定高效的资源调度策略,最大限度地利用系统资源,最大限度地提高用户体验。
8、进程间通信优化,pipe/epoll_wait唤醒机制优化,解决唤醒多个等待线程的性能问题。
9、增强内存管理、细化内存控制、统计、异构内存、热插拔、内存初始化等功能得到了改进,并提供了更有效的用户控制界面;热点锁和信号量优化,激进的内存调节和碎片整理,优化、vmap/vmalloc机制,显著提高内存应用效率;KASAN, kmemleak, slub_debug, oom和其他内存维护功能都得到了增强,以提高内存问题的定位和解决效率。
、提前发包时间模式开关解决了原有TCP框架在报文发送过程中的局限性。根据调度策略,为数据包设置EDT时间戳,避免了队列缓冲区过大造成的延迟,从而大大提高了TCP的性能。
、支持多路径TCP,可以提高移动和数据场景下的性能和可靠性,支持负载均衡场景下多个子流并行传输。
、引入了log fast commit方法,而EXT4引入了一种新的、更轻量级的烽火ol 源码 搭建日志记录方法——fast commit,它可以极大地加快耗时的操作,比如fsync,并带来更好的性能。
、支持dm写cache特性,提高SSD大容量顺序写性能,提高DDR持久化内存性能。
、io_uring是一个新的异步IO框架和实现,支持轮询模式。在轮询模式下,性能得到了与spdk类似的显著提高,队列深度越高,性能越好。
、支持ILP,在鲲鹏 Arm环境下支持位应用程序。
、IMA商业增强,基于开源IMA解决方案,增强安全性,提高性能,提高易用性,并帮助商业实现。
、支持单任务栈巡检,增强对ROP攻击的防范能力。
、MPAM资源管理和控制,支持Arm架构的缓存QoS和内存带宽控制技术。
、支持基于sedim的NMI机制和基于pmu的NMI机制,实现硬锁检测;启用perf nmi可以实现更准确的性能分析。
、Arm平台支持虚拟机CPU热插拔,提高了资源配置的天空网站源码灵活性。
、Arm kdump得到了增强,支持4G以上地址的内存预留,这样kdump可以预留更多的内存空间,并支持具有更大内存的机器。
、支持树莓派系列板。Raspberry Pi的支持已经集成到本地的openEuler .内核中,可以直接使用openEuler .内核源代码进行调试。
、RISC-V平台支持KVM虚拟化。
、支持智能网卡。
热内核升级
1、热内核升级是修复和升级操作系统漏洞的解决方案。实现了无服务意识的内核快速热替换。
2、Cpu Park和Quick Kexec的功能加速系统启动和停止,减少停机时间,提高系统可用性。
3、Pin存储器和Pmem功能可确保快速准确地恢复业务流程,并提高业务灵活性。
4、内核热升级控制器提供gRPC通讯接口,使用方便。
内存分层扩展
1、支持多内存和存储介质的统一管理,支持系统容量的平滑扩展。
2、冷热页识别,通过内核态内存页的空闲和空闲统计机制,准确识别进程内存页访问的冷热分布。
3、可以配置淘汰策略,提供配置界面,书奇小说源码自定义内存页面冷热分类策略。
4、平滑扩展,冷页自动切换到扩展内存,其上部署的软件兼容运行,无需改变或调整编程模式。
5、支持多媒体扩展,支持单片机、XL Flash、NVMe SSD等介质作为扩展内存,并根据介质本身的访问速度指定冷热内存分层方案,以达到扩展内存、降低性能损失的目的。
6、增强的虚拟化能力和可维护的测量能力。
7、增加了热迁移Pro的能力扩展,提高了可维护性和可测性。
8、热迁移专业版功能,增强热迁移多功能支持TLS,确保迁移过程中的数据安全;支持热迁移数据的并行压缩,提高迁移性能;增加数据页面访问频率的统计,支持热迁移数据的早期预测。
9、vmtop性能调试工具可以实时动态查看虚拟机的资源使用情况,包括CPU占用率、内存占用率等信息。增加了支持x_架构的扩展。
、支持IO挂起。默认情况下,当发生io错误时,IO会自动重试,超时后会报告警报。
、RISC-V架构支持虚拟化热迁移。
轻量级虚拟运行时
1、添加灵活的内存,大页面功能,系统调用过滤功能,增强IO子系统,提高性能和稳定性。
2、灵活的内存支持,根据工作负载的内存需求实现内存分配和恢复,virtio-balloon的内存恢复速度可达3GB/s。
3、大页面支持。在轻量级框架中提供大页面支持,可以为轻量级虚拟机提供连续的物理内存页面,提高虚拟机的内存访问效率。
4、系统调用过滤简化了设备模型,增加了对系统调用过滤的支持,只需要最简单配置的个系统调用,有效减少了系统攻击面。
5、输入输出子系统得到增强,以支持多通道并发输入输出能力并提高性能。支持IO- qos能力,增强虚拟机IO流量管理的灵活性和稳定性。open stack 维多利亚集成。
6、简单、可扩展、丰富、统一的云管理操作系统。更多功能见OpenStack Victoria官方发行说明。
7、通过集成openStack Vicoria版本实现IaaS(基础设施即服务)解决方案。
8、增强数据块存储的服务能力,并添加容量扩展、快照和虚拟机映像克隆等高级功能。
9、增强集装箱化部署和网络能力,以便更好地与集装箱集成。
、添加扩展服务支持,并支持扩展服务,如控制面板管理、裸机部署和云资源跟踪。
Kubernetes 1.集成
1、有关云本机操作系统自动部署、扩展和管理容器化应用程序的更多功能,请参考Kubernetes 1.的官方发行说明。
2、自动联机和回滚。Kubernetes会自动将应用程序或其配置更改的实例联机,并监控应用程序的运行状态。如果失败,将回滚以前的更改。
3、服务发现和负载均衡,支持基于容器IP和DNS名称的服务发现和负载均衡。
4、存储业务流程支持自动挂载多个存储后端,如本地存储、NFS、iSCSI、Gluster、Ceph等网络存储系统。
5、水平扩展,支持命令行扩展,用户界面手动扩展,根据CPU占用率自动扩展。
sysctl 参数防篡改 - 基于 ebpf 的实现 [一]
系统调用参数防篡改 - 基于ebpf的实现
本文基于内核代码版本5..0进行讨论。
ebpf能够修改某些函数的返回值,但仅限于允许错误注入的函数,这限制了其应用范围。系统tap能够作用于几乎任何函数,但由于内核API的不稳定,它在不同内核上可能无法运行。
ebpf的优势在于其与内核交互的API保持稳定,特别是用于“系统调用参数防篡改”的一组helper函数。在阅读代码实现时,发现中段插入了一个“BPF_CGROUP_RUN_PROG_SYSCTL”。
这一功能源于v5.2-rc1的commit,旨在限制容器对sysctl的错误写入,要求内核版本不低于5.2,且配置项包含“CONFIG_CGROUP_BPF”。
配套的4个helper函数记录在内核文档“Documentation/bpf/prog_cgroup_sysctl.rst”中,用于读取sysctl参数名称和值、在参数修改时获取写入的值以及覆盖准备写入的值。这些helper与内核原生路径中的过滤函数交互。
使用示例
通过Linux内核源码中的“tools/testing/selftests/bpf”目录下的测试用例可以学习ebpf的使用。在源码根目录下执行make命令编译。
针对sysctl部分,测试用例主体为“test_sysctl.c”,用于将ebpf程序加载至内核,并在对应的点位上附加。ebpf程序可以是直接以ebpf汇编语法写的,也可以是C文件编译成.o二进制文件的形式。
当判断为write操作时,返回0,内核源码中决定sysctl参数读写结果的点位返回“-EPERM”,使得修改不成功。
ebpf prog源文件中的“SEC”宏定义用于指示编译器将函数/变量放在特定的section中,便于用户态loader查找和解析。
为了实现加载和附加程序,使用了“sysctl_write_deny_prog.o”作为附加程序,类型为“BPF_CGROUP_SYSCTL”,方式为“BPF_F_ALLOW_OVERRIDE”。借助“fd”这样的整形数字,用户态程序可以深入内核态获取对应的结构体实例。
最终通过libbpf封装系统调用接口,用户态程序可以通过“bpf”系统调用入口与内核交互。使用strace工具可以追踪这一过程。
了解ebpf helper函数的使用,可以借助现成的工具进行学习,更多详情请参考后续文章。
Linux内核源码解析---cgroup实现之整体架构与初始化
cgroup在年由Google工程师开发,于年被融入Linux 2.6.内核。它旨在管理不同进程组,监控一组进程的行为和资源分配,是Docker和Kubernetes的基石,同时也被高版本内核中的LXC技术所使用。本文基于最早融入内核中的代码进行深入分析。
理解cgroup的核心,首先需要掌握其内部的常用术语,如子系统、层级、cgroupfs_root、cgroup、css_set、cgroup_subsys_state、cg_cgroup_link等。子系统负责控制不同进程的行为,例如CPU子系统可以控制一组进程在CPU上执行的时间占比。层级在内核中表示为cgroupfs_root,一个层级控制一批进程,层级内部绑定一个或多个子系统,每个进程只能在一个层级中存在,但一个进程可以被多个层级管理。cgroup以树形结构组织,每一棵树对应一个层级,层级内部可以关联一个或多个子系统。
每个层级内部包含的节点代表一个cgroup,进程结构体内部包含一个css_set,用于找到控制该进程的所有cgroup,多个进程可以共用一个css_set。cgroup_subsys_state用于保存一系列子系统,数组中的每一个元素都是cgroup_subsys_state。cg_cgroup_link收集不同层级的cgroup和css_set,通过该结构可以找到与之关联的进程。
了解了这些概念后,可以进一步探索cgroup内部用于结构转换的函数,如task_subsys_state、find_existing_css_set等,这些函数帮助理解cgroup的内部运作。此外,cgroup_init_early和cgroup_init函数是初始化cgroup的关键步骤,它们负责初始化rootnode和子系统的数组,为cgroup的使用做准备。
最后,需要明确Linux内一切皆文件,cgroup基于VFS实现。内核启动时进行初始化,以确保系统能够正确管理进程资源。cgroup的初始化过程分为早期初始化和常规初始化,其中早期初始化用于准备cpuset和CPU子系统,确保它们在系统运行时能够正常工作。通过这些步骤,我们可以深入理解cgroup如何在Linux内核中实现资源管理和进程控制。
å¦ä½å¦ä¹ Docker
å¦ä½å¦ä¹ Docker
对äºå¨æ ¡å¦çèè¨ï¼åºè¯¥å¦ä½å»å¦ä¹ dockerï¼æ¯ç«å¦æ ¡æ²¡æå ·ä½çåºç¨éæ±ä½ä¸ºå¼å¯¼ï¼æ以åºè¯¥å¦ä½å»ç 究Dockerï¼è¿æï¼Dockerçæºä»£ç æ没æå¿ è¦å»ç 究ï¼
é¦å æ说æä¸ï¼ææ¯ä¸ä½å¨æµæ±å¤§å¦VLISå®éªå®¤äºè®¡ç®é¡¹ç®ç»çå¦çï¼ä½¿ç¨è¿Dockerï¼ç 究è¿Dockeråå ¶æºç ï¼ä¹å®å¶è¿Dockerã
对äºå¦çå¦ä½å¦ä¹ Dockerï¼æ认为é¦å è¦çä¸ä¸å¦ç个人çç¥è¯èæ¯ãè½å©ç¨çèµæºèµæºã以åä¸ªäººå ´è¶£ååå±æ¹åã
1.å¦ä¹ Dockerï¼å¦æ没æäºè®¡ç®çåºæ¬ç¥è¯ï¼ä»¥åå æ ¸çåºæ¬ç¥è¯ï¼é£ä¹å¦ä¹ 并ç解起æ¥ä¼ç¨ååãä½ä¸ºå®¹å¨ï¼Docker容å¨çä¼å¿å¨åªï¼ä¸è¶³å¨åªï¼æ好äºè§£å®¹å¨çå®ç°æ¯ææ ·çï¼ç®åäºè§£ï¼ï¼æ¥æéå管çï¼Dockerå该å¦ä½ä½ç°è½¯ä»¶å¼åï¼éæï¼é¨ç½²ï¼åå¸ï¼åè¿ä»£ç软件çå½å¨æ管çä¼å¿ã以ä¸ä¸¤ç¹æ认为æä¸ºå ³é®ï¼æè¿ä¸¤æ¹é¢ç认è¯å¿å¿ ä¼å¯¹ä¹åçå·¥ä½å¸®å©å·¨å¤§ã
2.å ³äºå¦ä¹ èµæºï¼èµ·ç ç硬件设æ½æ»æ¯è¦æçãDockeråå ¶çæçåå±å¾å¿«ï¼ä¸ä½¿ç¨çº¯ç论è¯å®æ¶æçå¾®ãå¦å¤ï¼èµæºè¿å æ¬Dockerå®æ¹ï¼å大çµååªä½å¹³å°ï¼ææ¯è®ºåï¼å¼æºç¤¾åºçï¼å¾å¾å¤§æ¿çè§ç¹è½ç¹ç ´èªå·±çå°æï¼æè 让èªå·±ç¥éåªæ¹é¢ç认è¯è¿å¾æ¬ 缺ï¼ä»¥å让èªå·±å°èµ°å¾å¤ç弯路ã
3.ä¸ªäººå ´è¶£çè¯ï¼å½ç»ä¸ºå¼ºæççä¸çãèµ·ç åºè¯¥è®¤åDockerç设计价å¼ï¼ä»¥åDockerçæªæ¥æ½åï¼å½ç¶æä¾æ®çæ¹å¤Docker并带å¨å¤§å®¶çæèï¼ä¹æ¯æ·±åå ³æ³¨ç表ç°ã
4.个人åå±æ¹åï¼æ认为å¦æéè¦æDockerå½ä½è½¯ä»¶çå½å¨æ管çå·¥å ·çè¯ï¼é£ç¨å¥½Dockeræ为éè¦ï¼APIåå½ä»¤çç解ä¸ä½¿ç¨æ¯å¿ éçãå¦æä¸æ³¨ç³»ç»è®¾è®¡æ¹é¢ï¼é£ä¹é¤Docker以ä¸çç¥è¯ä¸ç»éªä¹å¤ï¼è¥æDockeræºç çå¦ä¹ ä¸ç解ï¼é£ä¹è¿äºè¯å®ä¼è®©ä½ çDockeræ°´å¹³æé«ä¸ä¸ªå±æ¬¡ã
-- 8 0
xds
å¦ä¹ Dockerï¼æ大ç好å¤æ¯è·è¿æ°ææ¯åå±æ¹åãæè§å¾å¨æ ¡çåºè¯¥æ²¡æå¤å°ç¡¬æ§éæ±å¨Dockerçç 究ä¸ï¼è¿ä¹æ¯ä¸ºä»ä¹å¦æ ¡æ²¡åå ·ä½åºç¨è¦æ±çåå ãæå®é çåæ³æ¯çä¸äºDocker使ç¨æ¡ä¾ï¼èªå·±å®è·µåºä¸äºç»éªåºè¯¥ä¼å以åç社ä¼å®è·µä¸èµ·å°ä½ç¨ã
ç 究dockerçæºä»£ç ï¼åºè¯¥å°ä½ ä¸å®å³å¿ä»äºäºè®¡ç®æ¹é¢çäºä¸æè ç 究ï¼é£ä¹ä½ å°±éè¦ä»¥ç 究è ç身份å»åä»ç»çæºç åæçå·¥ä½ã
-- 3 0
ååGTDer
æä½ä¸ºåå å·¥ä½çè¿æ¥äººæ¥è¯´ï¼æ认为åªæä½ çæ£åå å·¥ä½åï¼å¨å·¥ä½ä¸å¦ä¹ è·ææä¹ï¼æ¯ç«Dockerç¥è¯äºè®¡ç®å ¶ä¸çä¸ä¸ªè½¯ä»¶å¹³å°èå·²ï¼è¯´ä¸æ¥çä½ æ¯ä¸äºï¼æ°çææ¯åºç°Dockerä¸ä¸å®æ¯å¯ä¸éæ©ã
ä½ä¸ºå¦çäºè§£æ°ææ¯ç¡®å®æ å¯åéï¼ä¸å®è¦è½æç论转å为ç产åææ¯æ£éã
-- 3 0
9lives - ç±çæ´»ï¼ç±äºè®¡ç®ã
å¦ä¹ ä»»ä½ä¸ä¸ªå¼æºæ°ææ¯ï¼é¦å é®èªå·±å 个é®é¢ï¼
1. 为ä»è¦å¦ä¹ å®ï¼
2. å¦ä¹ å®éè¦äºè§£åªäºç¸å ³ç¥è¯ç¹ï¼
3. å¦ä½å¿«éå¦ä¹ ï¼
4. 该ææ¯ç使ç¨åºæ¯æ¯ä»ä¹ï¼
æ¿æ个人çå¦ä¹ ç»éªæ¥ä¸¾ä¾ï¼æ¬äººä¹åæ¯è¾äºè§£OpenStackï¼
为ä»è¦å¦ä¹ dockerï¼
åçï¼
dockeræ¯è½»é级èæåææ¯ï¼docker使linux容å¨ææ¯çåºç¨æ´å ç®ååæ åå
dockerçé度å¾å¿«,容å¨å¯å¨æ¶æ¯«ç§çº§ç
dockerå°å¼ååè¿ç»´èè´£åæ¸
docker解å³äºä¾èµå°ç±é®é¢
dockeræ¯æå ä¹æææä½ç³»ç»
dockeræçé£éåå±ççæå
å¾å¤IT巨头éæ¸å å ¥åæ¯æ
å¦ä¹ å®éè¦äºè§£åªäºç¸å ³ç¥è¯ç¹ï¼
åçï¼
äºè®¡ç®æ¦å¿µç¸å ³ï¼restapi, å¾®æå¡ï¼OpenStackï¼
Linux ç³»ç»ç®¡çï¼è½¯ä»¶å 管çï¼ç¨æ·ç®¡çï¼è¿ç¨ç®¡ççï¼
Linux å æ ¸ç¸å ³ï¼Cgroup, namespace çï¼
Linux æ件系ç»ååå¨ç¸å ³ï¼AUFSï¼BRFS,devicemapper çï¼
Linux ç½ç»ï¼ç½æ¡¥ï¼veth,iptablesçï¼
Linuxå®å ¨ç¸å ³ï¼Appmor,Selinux çï¼
Linuxè¿ç¨ç®¡çï¼Supervisord,Systemd etc)
Linux容å¨ææ¯ï¼LXCçï¼
å¼åè¯è¨ï¼Python, GO,Shell çï¼
3.å¦ä½å¿«éå¦ä¹ ï¼
åçï¼ä¸ªäººä½ä¼æ好æä¸ä¸ªå®é çéæ±æ项ç®æ¥è¾¹å®è·µè¾¹å¦ä¹ ï¼å ¥é¨å¯ä»¥åèï¼ç¬¬ä¸æ¬docker书ï¼åçä¸éï¼é常éåå ¥é¨ãé¤æ¤ä¹å¤ï¼é 读ç人çblogæ¯å¦å®æ¹blog /
BTW: ç读dockerææ¡£
-- 0 0
tuxknight
楼ä¸åä½è¯´çé½å¾å¥½ï¼æåè¡¥å ä¸ç¹ï¼
æ¾ä»½ç¸å ³çå®ä¹ å·¥ä½
-- 0 0
lancer
å·¥ä½åç 究æ¯ä¸¤ä¸ªæ¹åæ个人认为ï¼å·¥ä½éè¦éè¿ä½ çå®é æè½ä¸ºä¼ä¸å¸¦æ¥ç»æµæçï¼èç 究çè¯å¯ä»¥ä¸æ³¨æ个ç¹ãä½æ¯ç 究离ä¸å¼å·¥ä½ï¼å 为工ä½å¯ä»¥è®©ä½ æ´å¥½ççä¼ææ¯å¸¦æ¥çä»·å¼ï¼ä»¥åå¦ä½æä¾æ´å¥½çæå¡ï¼ç¨æ·ä½¿ç¨åºæ¯éè¦é£äºææ¯ççªç ´ãæäºè¿äºè®¤è¯ï¼ç¶åæ´å ä¸æ³¨çç 究æ个ææ¯ç¹ï¼è¿æ ·æ许å¯ä»¥è¯´ææ¯ååä¸æ¯åä¸å¼çã
-- 0 0
绿åè²å½±
dockerç°å¨ååç«çï¼å¼å¾å¦ä¹ ä¸ä¸ã