TPP多租户隔离之资源清理

本文涉及的产品
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
推荐全链路深度定制开发平台,高级版 1个月
OpenSearch LLM智能问答版免费试用套餐,存储1GB首月+计算资源100CU
简介: 利用ajdk实现jvm虚拟化,实现容器业务方案的热部署和资源隔离

  双11的时候TPP引入了ajdk多租户,对场景的cpu进行隔离,参考文章 《TPP稳定性之场景隔离和多租户》。文章中对tpp提供给算法方案的二方服务客户端进行改造,这些共享的二方服务注入root租户的threadfactory,将共享服务与方案进行隔离,共享服务运行在root租户中。 这样算法方案里不会有线程,这样不用担心资源泄漏,因为tpp方案是热部署的,新的方案instance构建并预热,然后替换旧的方案instance,旧的方案classloader没有被引用,系统会自动回收。

  随着场景的增多,除了算法团队,业务工程团队也开始接入,他们都有自己业务相关的二方服务或二方包的需求,tpp维护几千个场景和几百个二方服务是有点力不从心了。任何一个场景提出的二方服务接入或着二方服务jar包升级都需要tpp走发布流程发布glaucus容器,业务迭代速度明显要快于容器的更新速度,这种开发体验是很差的。因此tpp要开放二方服务的开发和接入能力,让场景owner自助完成,这样场景onwer就可以像开发aone独立应用一样去迭代,只是不用关心机器资源,接入层,服务provider等。在tpp容器上实现这种开发模式就需要解决这些问题:
  1.私有的二方服务的热部署,并且与方案有相同的生命周期:为什么不新起容器呢,还是上篇文章讲的,tpp方案本身是热部署的,一般机器运行最多几百个场景,本来一个docker就能满足要变成几百个docker肯定是很浪费资源的。
  2.二方服务有自由的行为,可以开启线程,热部署就要能够清理线程:否则老方案的资源无法卸载,多发布几次方案和二方服务就会出现oom。

  我们的方案是将原来的一层租户架构改成两层租户架构。回顾下原来的一层租户架构:
多租户隔离.png
  这里每个场景是一个租户,它们有自己有界的线程池,设置了cpu shares和cpu quota,mem limit,场景下的所有方案都受所属场景租户限制。ajdk的租户容器可以结束租户创建的所有线程,但是热部署的最小粒度是方案,因此不能直接destroy场景租户,需要把单层租户结构改成两层租户结构,即嵌套cgroup,如下图所示:

场景方案隔离.png
  第一层还是场景租户,用来控制场景的总cpu和mem。在场景租户下为每个方案创建一个方案子租户,目前不限制cpu和mem,因为对于cgroup来说子控制组总资源还是受父控制组的限制,还是匹配原来的场景资源隔离需求。方案租户用来清理方案的资源,方案租户容器生命周期和方案instance同步,方案下线/替换时,系统创建新的方案租户,切流到新方案租户,老方案租户destroy,ajdk会结束老方案的线程,老方案没有被引用会自动回收。容器新的classloader体系如下图所示:

tpp类加载体系.png
  私有插件和方案instance由同一个方案classloader加载,这里不会export,可以放心清理方案资源。对于广泛使用的插件可以升级为系统共享插件,由glaucus classloader加载,export给方案,避免大家都加载一份插件浪费metaspace。

  有了多租户的资源隔离和资源清理,我们将在tpp上构建新的开发模式,开发同学可以以接近独立应用的自由度去开发自己的业务逻辑,随时接自己需要的二方服务,随时变更自己的业务逻辑,不用关心代码跑在哪台机器,不用担心流量上涨需要扩容,不需要自己去接监控。后面我们会逐步改进,做得更完善

  参考文章:
  《TPP稳定性之场景隔离和多租户》
  《JVM虚拟化 重新定义Java容器热部署的资源管理机制》

目录
相关文章
|
2月前
|
资源调度 Kubernetes 调度
Flink 细粒度资源管理问题之细粒度资源请求满足问题如何解决
Flink 细粒度资源管理问题之细粒度资源请求满足问题如何解决
|
2月前
|
关系型数据库 分布式数据库 数据库
PolarDB资源隔离技术:在多租户环境中的应用与优化
随着云计算普及,多租户架构助力云服务商提供高效服务。阿里云PolarDB采用独特分布式设计,在多租户环境下确保每个用户数据独立与资源隔离。通过逻辑与物理隔离技术,如Schema和分区,结合分布式存储节点,实现资源独占及安全。此技术不仅保障数据安全,还能动态分配资源,满足高性能需求。通过优化资源分配、增强事务处理及监控机制,进一步提升PolarDB在多租户环境中的表现。
98 4
|
2月前
|
Kubernetes Cloud Native 应用服务中间件
Kubernetes 自动伸缩策略:优化资源利用率
【8月更文第29天】在现代云原生环境中,应用的流量往往具有不可预测性。为了应对这种变化,Kubernetes 提供了多种自动伸缩机制来动态调整应用实例的数量和每个实例分配的资源。本文将深入探讨两种主要的自动伸缩工具:水平 Pod 自动伸缩器 (HPA) 和垂直 Pod 伸缩器 (VPA),并提供实际的应用示例。
58 0
|
2月前
|
数据中心 容器
异步任务处理系统问题之任务资源隔离实现的问题如何解决
异步任务处理系统问题之任务资源隔离实现的问题如何解决
|
4月前
|
SQL OLAP 数据库
深入OceanBase内部机制:资源隔离实现的方式总结
深入OceanBase内部机制:资源隔离实现的方式总结
|
5月前
|
机器学习/深度学习 人工智能 安全
SentinelOne监测中隔离的文件,人工如何取消隔离
SentinelOne 的 Agent 在终端设备上实时监测系统的活动,包括文件操作、网络通信、内存访问等, SentinelOne 使用人工智能和机器学习技术对监测到的活动进行行为分析,识别潜在的威胁,包括已知的恶意软件和未知的零日攻击。 基于行为分析和实时监测,SentinelOne 快速识别出可能的威胁,并进行准确的威胁分类,包括病毒、勒索软件、恶意脚本等。 SentinelOne 可以自动采取响应措施,如隔离受感染的设备、终止恶意进程、删除恶意文件等,以尽快减轻威胁带来的影响。当技术人员发现隔离的文件没有危害时,可以手动隔离。文章阐述了怎么手动撤销的过程。
291 0
SentinelOne监测中隔离的文件,人工如何取消隔离
|
存储 Kubernetes 网络协议
k8s 【策略】【资源管理】ResourceQuota(1)
k8s 【策略】【资源管理】ResourceQuota(1)
k8s 【策略】【资源管理】ResourceQuota(1)
|
Kubernetes Cloud Native 安全
Koordinator 0.6:企业级容器调度系统解决方案,引入 CPU 精细编排、资源预留与全新的重调度框架
经过社区多位成员的贡献,Koordinator 0.6 版本正式发布。相较于上一个版本 0.5,新版本进一步完善了 CPU 精细化编排能力,更好的兼容原生用法;支持了资源预留的能力(Reservation),补齐了调度原子语意缺失;发布了全新的重调度框架,支持用户灵活的扩展自定义插件。这些特性源自于阿里巴巴内部的生产实践,并结合上游社区规划思考,为用户带来标准、强大、灵活的调度解决方案。
1040 0
Koordinator 0.6:企业级容器调度系统解决方案,引入 CPU 精细编排、资源预留与全新的重调度框架
|
Kubernetes 调度 Perl
k8s 【策略】【资源管理】ResourceQuota(2)
k8s 【策略】【资源管理】ResourceQuota(2)
|
运维 分布式计算 NoSQL
操作系统相关资源优化策略
一、影响Linux性能的各种因素 二、程序问题
下一篇
无影云桌面