能提问题一下uvent是啥么?

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了能提问题一下uvent是啥么?相关的知识,希望对你有一定的参考价值。

更新里面多了uvent,不太明白是什么所以请求各位指点一下。

1. Uevent的功能
Uevent是Kobject的一部分,用于在Kobject状态发生改变时,例如增加、移除等,通知用户空间程序。用户空间程序收到这样的事件后,会做相应的处理。
该机制通常是用来支持热拔插设备的,例如U盘插入后,USB相关的驱动软件会动态创建用于表示该U盘的device结构(相应的也包括其中的kobject),并告知用户空间程序,为该U盘动态的创建/dev/目录下的设备节点,更进一步,可以通知其它的应用程序,将该U盘设备mount到系统中,从而动态的支持该设备。
2. Uevent在kernel中的位置
Uevent的机制是比较简单的,设备模型中任何设备有事件需要上报时,会触发Uevent提供的接口。Uevent模块准备好上报事件的格式后,可以通过两个途径把事件上报到用户空间:一种是通过kmod模块,直接调用用户空间的可执行文件;另一种是通过netlink通信机制,将事件从内核空间传递给用户空间。

3. Uevent的内部逻辑解析
3.1 Source Code位置
Uevent的代码比较简单,主要涉及kobject.h和kobject_uevent.c两个文件,如下:
include/linux/kobject.h
lib/kobject_uevent.c
3.2 数据结构描述
kobject.h定义了uevent相关的常量和数据结构
kobject_action定义了event的类型
4.uevent是sysfs向用户空间发出的消息。
5.uevent用户空间部分
uevent的用户空间程序有两个,一个是udev,一个是mdev。 udev通过netlink监听uevent消息,它能完成两个功能: 自动加载模块 ;根据uevent消息在dev目录下添加、删除设备节点。
另一个是mdev,mdev在busybox的代码包中能找到,它通过上节提到的uevent_helper函数被调用。
6.其他
kobject代表sysfs中的目录。

ktype代表kobject的类型,主要包含release函数和attr的读写函数。
kset包含了subsystem概念,kset本身也是一个kobject,所以里面包含了一个kobject对象。另外,kset中包含kset_uevent_ops,里面主要定义了三个函数
int (*filter)(struct kset *kset, struct kobject *kobj); const char *(*name)(struct kset *kset, struct kobject *kobj);
int (*uevent)(struct kset *kset, struct kobject *kobj, struct kobj_uevent_env
*env);
这三个函数都与uevent相关。filter用于判断uevent是否要发出去。name用于得到subsystem的名字。uevent用于填充env变量。
参考技术A 解决Windows 系统下,出现 ioerror:cannot watch more than 1024 sockets的。实验性功能,要看测试反馈的效果 参考技术B 是一个带DOS命令的设置工具,具体使用方法看“电脑DOS命令使用方法”。 参考技术C 解决Windows 系统下,出现 ioerror:cannot watch more than 1024 sockets的。实验性功能,要看测试反馈的效果。 参考技术D 解决Windows 系统下,出现 ioerror:cannot watch more than 1024 sockets的。实验性功能,要看测试反馈的效果

天天叨叨云原生,你知道云原生是啥么?

1. 现代应用的需求

早期人们对于互联网的依赖还不是很强烈,数字体验这个词还没有诞生,大家对于数字体验还不是那么敏感,应用程序是否总是可用也没有那么重要。对于互联网产品来说,用户量少,并发量低,数据量也很小,只需要单个服务器即可满足需求,数据库和文件服务器什么的可用部署在另外的服务器上,这就是早期的单体架构。

天天叨叨云原生,你知道云原生是啥么?

后来随着各大互联网公司业务的增长,访问量和数据量也暴增,由于单个服务器的资源有限,性能显着下降,所以不得不对 IT 架构进行改造。开始只是在应用本身动刀子,比如对数据库进行读写分离、分库分表等优化,以缓解数据库的访问压力;对应用进行动静分离,将静态资源放到 CDN 以加速访问。

这是一个恶性循环,如此一来,各大公司的用户规模和业务量还会继续飞速增长,业务场景会越来越复杂,规模越来越庞大,不得不分而治之,采用分布式架构,往更细粒度的方向通过 SOA 进行垂直拆分。

随着 4G 的普及,高速的网络让视频缓存变得不易察觉,使用数据流量观看视频不再是一种极度炫富的行为,移动支付也借着网速提升的大潮迅速普及。如今数字体验已经不再是我们生活中的一个配角,它们在我们日常生活中的许多活动中都扮演着重要的角色,我们希望应用程序总是可用的,不能容忍短暂的不可用,并且还得经常更新,防止审美疲劳。

面对用户的这种变态需求,必须对架构继续进行优化,主要从两个方面来入手:

保证服务一直可用

要想保证服务一直可用,首先需要优化对状态信息的处理,比如会话状态、应用配置数据等。传统应用的状态一般都保存在本机实例上,如何使用负载均衡器的会话绑定来确保同一个用户的请求始终被转发到同一个后端服务实例上。一但访问实例发生故障,负载均衡器会建立新的会话,将请求转发到另一台实例,但另一台实例没有之前的状态信息,从而导致状态不一致。

要想解决这个问题,需要让应用无状态化。这里的无状态并不是指应用不处理数据,而是在设计时就面向失败和面向恢复设计,例如将状态外部化,存储到外部存储中,同时应用需要能够快速重启,快速弹性伸缩。最好能保证在外部系统故障情况下依然可用。

加速迭代流程

如果产品的进化速度太慢,不能根据用户的反馈快速迭代,就会引起用户不满。但交付速度的提高不能以降低可用性为代价,传统企业提升可用性的一种方法就是尽量少交付,尽量多审核,这和快速迭代是背道而驰的。现代互联网公司需要做的是快速迭代的同时又要保证可用性,而“云原生”就是用来解决这个问题的良药。

2. 何为云原生

计算机领域每过几年就会涌现出一批新的概念出来,细分到云计算领域也是如此,这两年时常蹦跶在大家眼前的就是“云原生”这个词。

云原生的英文原文叫“Cloud Native”,我们不妨从英文的角度来理解,Native 表示与生俱来,就是亲生的。把 Cloud 和 Native 放到一起又该如何理解?说白了就是云亲生的!详细的解释是:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势,享受云的特点。如果嫌太长不看可以直接理解为“云亲生的”!

云原生这个词看起来比较新鲜,其实从开发人员的角度来理解是很简单的,就是应用在开发的时候就考虑到云上提供的各种服务,充分利用云的动态调度、自恢复、通过 API 访问服务等基本特性,以及敏捷高效的特性。传统的应用开发方式都是闷头开发,不管应用跑在哪个基础设施环境中,也不用考虑基础设施提供的各种能力,我只管让我的应用能正常运行就好。

上面都是从广义上来理解云原生,有点空洞,对应到具体的方法论就是大家耳熟能详的三板斧:容器化、微服务和 DevOps。

天天叨叨云原生,你知道云原生是啥么?

容器化

Docker 为代表的容器化直接对云的世界进行降维打击,它提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统,从而保证了本地环境和云端环境的高度一致,避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程。同时它的颗粒度比虚拟机更小,部署更灵活,简直是红的发紫啊。

将应用托管到容器中,就注定了应用本质上是无状态的,为了保证应用无状态的同时又不影响用户体验,容器平台的做法是将状态信息保存到外部存储中,将日志采集从业务中剥离,使用 Sidecar 拉抓取业务容器日志。同时需要应用提供探针,以便让平台实现应用的生命周期管理。

对于数据库应用来说,它们对 IO 和吞吐的性能要求很高,如果要跑在容器中,对于外部存储的挑战会非常大,各大公司也在极力优化其外部存储性能。例如金山云就推出了一种全新极速云盘(ESSD)。ESSD 是 Enhanced SSD,即在 SSD 云盘的基础上,提供更高的突破与创新,主要体现在:

  • 极简架构:NVMe SSD 作为存储介质,配合 RDMA 组网,超简洁软件架构,发挥云盘高效性能。
  • 高效性能:100W IOPS 4GBps 吞吐,时延低至 200 微秒。
  • 稳定可靠:三副本保存,可靠性 9 个 9,可用性 99.99%,支持加密,支持本地快照、普通快照等多种数据备份方式。
  • 弹性部署:支持在线扩容随时调整云盘大小,可利用快照实现云盘的批量复制,大大增强业务的敏捷性。
天天叨叨云原生,你知道云原生是啥么?

从图上可以看出 ESSD 相对普通 SSD 的性能提升:ESSD IOPS 单盘高达 100w,相比上一代提升 40 倍;吞吐性能达到 4GBps,提升 16 倍;时延低至 0.2ms(即 200us),为前代 SSD 时延的 1/15。

如果将 ESSD 和容器服务结合使用,用户就无需再担心核心数据库部分能否真正迁移到云的数据库上,能否有金融级的数据库的能力。利用 ESSD 的高效性能,完全满足云上数据库对 IO 和吞吐的性能要求。

微服务

随着数据量的不断增大,吞吐量不断增加,业务越来越复杂,服务的数量会越来越多,分层会越来越细。久而久之,单体应用渐渐被拆分成功能相互独立的微应用,实现业务架构解耦,大家各司其职,报团取暖,这就是微服务。

微服务区别于单体架构的地方就在于“分而治之”,即通过切分服务以明确模块或者功能边界。然而,仅有“分”是不行的,软件系统是一个整体,很多功能来自若干服务模块的配合,因此必然要有“合”的手段,这对矛盾会体现在多个方面。

如果使用 Docker,由于每个服务打包可以封装为一个 Docker 镜像,每个运行时的服务都表现为一个独立容器,我们之前建立的容器依赖就可以很容易的对应到服务依赖上,基于这种统一性,系统升级就很容易配合一些自动化工具实现“整体升级”(甚至还可以“整体降级”)。将微服务应用放置在容器中,可以在开发、测试和上线流程中实现“一次编写,到处运行”。

DevOps

得益于容器和 Docker 技术的红利,开发人员可以轻松地与 IT 操作和生产环境共享他们的软件和依赖项,同时消除典型的“适用于计算机”的借口,间接地将开发人员和运维人员更紧密地结合在一起,使他们更能高效地协作。运维和开发小哥表示现在他们的关系很融洽,没事还能一起出去喝两杯,即使线上环境出了问题,也能够一起愉快地背锅。

虽然云原生有三板斧,但主角其实还是 Kubernetes,它是云原生领域的当红小生,甚至成为了云原生的代名词。Kubernetes 从诞生之初便一路飙升,将对手甩开了十几条街,未来也将会以火箭的速度保持上升。

天天叨叨云原生,你知道云原生是啥么?

为了推动 Kubernetes 产品的一致性和可移植性,践行 Kubernetes 被创立时的初心,CNCF 还启动了 Kubernetes 一致性认证计划,目前几乎所有的互联网巨头都通过了这个一致性认证:

天天叨叨云原生,你知道云原生是啥么?

除了这些,Kubernetes 的行业成功案例也数不胜数:

  • 超过 20 个知名的集群管理平台从自研架构迁移到 Kubernetes,包括阿里巴巴的 Sigma、亚马逊的 Apollo、Apache Mesos、百度的 Matrix、Cloud Foundry 的 Diego/Garden 等
  • 欧洲核子研究中心(CERN)正在使用 Kubernetes 管理着超过 200 个云计算中心,运行着 40 多万个工作负载,每秒处理着高达 30GB 的数据。
  • 中国移动使用容器取代虚拟机,以轻量级的方式在其平台上运行各种应用程序,利用 Kubernetes 提高资源利用率。
  • 金山云已经开始为金蝶软件提供的物理机自建分布式存储服务,为小米支撑 FDS 容器、全套基础运维平台,为金山 WPS 在线文本处理提供支持。

3. 云原生的未来

大型企业将会在 Kubernetes 上加倍投入

2018 年 1 月,Red Hat 收购 CoreOS 公司,在随后的一年中,Red Hat 将 CoreOS 优秀的功能和组件迅速融合到 OpenShift 中。2019 年 7 月 9 日,IBM 又收购了 Red Hat,将其并入混合云部门。未来,IBM 会将 Red Hat 开放式混合云技术的强大功能和灵活性与 IBM 创新和行业专业知识的规模和深度相结合,共同推出下一代混合多云平台,该平台基于 Linux 和 Kubernetes 等开源技术,允许企业在本地以及私有和多个公共云上安全地部署、运行和管理数据与应用。

无独有偶,2020 年 7 月 8 日,开源公司 SUSE 宣布收购 Kubernetes 管理平台创建者 Rancher Labs。这让 SUSE 在云原生领域拿到一张重要的门票,同时,Rancher 团队的加入也弥补了 SUSE 在云原生方面的研发能力。SUSE 并购 Rancher 之后未来发展的方向更多的会是云原生技术和 2B 客户的需求场景的结合,加速对非云原生软件类产品的替代,加速对传统 IT 市场的云化过程。

而国内的金山云则从基础设施层面着手,推出了三款全新的产品:金山云星曜裸金属服务器、新一代高性能云服务器和全新极速云盘 ESSD。ESSD 前面已经介绍过了,这里主要介绍下裸金属服务器。星曜裸金属服务器是一种专属、独享的云上物理服务器,提供超高性能计算服务。它跟云服务器、容器一样,享受到云的统一管理。并且,在多层安全防护等级下,它的采购、运维、管理跟分布式云计算现有的服务互通,可以同时享受到物理服务器的优秀性能和云服务器的弹性能力。性能方面主要体现在:

  • 原生裸金属服务器,不产生性能损耗,无资源抢占现象,服务安全、稳定、可靠。
  • 最大可支持 50Gbps 带宽,原生网络性能可达到 3000W PPS。
  • 支持与客户托管 IDC 区域的裸金属服务器通过 10Tbps 专线互通,形成一个延迟和收敛比可控的内网,网络效果等同于在同一 IDC 内互通。

除了性能优势外,弹性能力也不容小觑:

  • 可作为传统 IDC 的逻辑扩展部分。
  • 支持云容器一体化管理,托管资源与云资源统一管理。
  • 单个可用区支持超过 10 万台裸金属云资源扩展,突破了机柜不足的限制。

如果你很关心虚拟机的性能损耗问题,希望将物理服务器的性能全部发挥出来,可以选择金山云的裸金属服务器,它默认已经集成了监控、容器、大数据等 PaaS 层服务,均支持插件式安装。其他 PaaS 层服务也在持续集成中。

作为用户,你也无需担心迁移成本,只需要接入裸金属服务器的控制台 API,就可以像管理本地服务器一样管理裸金属服务器了。

利用这三大法宝,金山云提供了一站式的商用方案,数据库、大数据什么的上云从未如此简单,不再需要自己瞎折腾,老牛拉破车,越拉肾越虚。。。

混合云、多云趋势凸显

在公有云的 IaaS 层,先发者 AWS 是事实上的标准制定者。所有的公有云厂商推出的云服务器,都相当于“兼容机”。出于不想被单一厂商锁定、以及数据敏感性等的考虑,用户在使用云的过程中,越来越呈现混合云、多云的趋势。

由于 IaaS 层相当于形成了标准化,各用户也可以利用第三方厂家实现混合云多云管理。微软、谷歌 和 AWS 都提供了跨云和混合云的方案。例如谷歌的 Anthos

天天叨叨云原生,你知道云原生是啥么?

Anthos 允许你在私有云中部署,并安装一个代理,保持与 Google Cloud Platform(GCP)的加密连接。该代理允许你从 GCP 控制台管理 Anthos 集群及其工作负载,部署和扩展应用程序。

微软的 Azure Stack 也有类似的服务:

天天叨叨云原生,你知道云原生是啥么?

它允许你在自己的数据中心部署 Azure 服务,有了 Azure 和 Azure Stack 组成的混合云,开发者就可以基于统一的 Azure 服务和 DevOps 敏捷开发流程和工具,开发最适合业务、技术和合规要求的应用。

金山云也不甘落后,一方面,金山云提供的银河专有云,可以满足用户将兼容机方便地部署在自己机房的诉求;另一方面,金山云利用开源社区技术,提供了较为简便的、基于容器的混合云、多云管理方案,便于用户将 IaaS 层实现跨云的统一管理。

如果你觉得这种专有云起步太大了,那也完全不用担心,金山云已经把专有云做的越来越小型化,从原来的 50 台服务器压缩到了现在的 10 台,同时服务可以选配。这种解决方案在很多场景下对小型私有云平台有碾压式的优势,实现了无缝扩展,而且混合云的管理也会非常简单,因为本地和远程资源基本上是一致的。

随着云原生的理念越来越深入人心,利用金山云的专有云,客户可以轻松部署各种高性能的云原生应用到私有数据中心中,数据库和大数据应用也不在话下,把云原生的价值最大化,真香!

云原生实验室 发起了一个读者讨论 大家可以在这里留言啦~~ 精选讨论内容