前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >浅谈数据中心应急冷源

浅谈数据中心应急冷源

作者头像
腾讯数据中心
发布于 2018-03-16 09:04:48
发布于 2018-03-16 09:04:48
3.2K0
举报
文章被收录于专栏:腾讯数据中心腾讯数据中心

一.引言

数据中心作为信息通讯的中枢,持续运转的服务器将产生大量的热量,若不及时将热量排出,聚集的热量将会引起服务器高温,从而影响设备稳定运行。

精密空调系统作为数据中心制冷的重要基础平台系统,是数据中心安全、稳定运行的保障。但是在实际运行过程中,空调系统并无法保证“全勤”,空调系统偶然的故障或者电力供应问题均有可能导致空调系统停机。空调系统从停机到再次恢复工作需要一定的响应时间,在该时间段内,服务器依旧处于工作状态,此时仍需要对机房温度进行控制,所以在除了原有空调系统外,还需配备额外的制冷系统,即数据中心的应急制冷系统。

二.应急制冷系统

应急制冷系统,顾名思义,是在紧急状况下对数据中心进行控温的制冷系统。在主空调系统因故障发生短暂停机时,应急制冷系统可立即“接管”控温的工作。因而也被誉为数据中心的第二道“保险”。对大功率、高热流密度的数据中心而言,配备应急制冷系统可进一步提高系统运行的可靠性。

一般而言,应急制冷系统主要由冷源、热交换器、送水/风管路、电源等组成,根据冷源的不同,应急制冷系统可分为两大类:一是双冷源空调系统;二是蓄冷式制冷系统。本文将对两种不同类型的应急制冷系统进行介绍。

1.双冷源空调系统

双冷源空调系统其本质为两套并联的空调系统,如图1所示, 一套为冷冻水空调系统,一套为风冷直接蒸发式系统。两套系统均可以独立为数据中心提供充足的冷量,二者互为备份可极大的提高制冷系统的可靠性。

通常来说,冷水机组具有制冷效率高、设备集中、便于维护、故障率低等诸多优势,因此是数据中心控温的首选。当冷冻水系统制冷中断时,风冷直接蒸发制冷系统将自动开启,对主系统进行“补偿”。值得注意的是,由于冷水机组启动较慢,当风冷系统切换为水冷系统需要更长的响应时间;而水冷系统则可较为顺畅地切换至风冷系统。因此,风冷直接蒸发式系统可扮演应急制冷系统的角色。还需指出,在机房运行初期,上架服务器数量较少,数据中心热负荷较轻,此时常采用风冷系统模式;随着上架服务器数量的增多,热负荷增大,择机切换至水冷系统模式。

图1 双冷源空调系统

2.蓄冷式应急制冷系统

虽然双冷源系统已经大幅度提高了系统的可靠性,但当电力系统发生故障,将引起冷机系统制冷中断,此时需要后备电力系统(如柴油发电机系统)将投入运行。从柴油发电机启动送电到制冷机组重启并到恢复所需的供水温度至少需要数分钟。因此,在该时间段内,数据中心需要启动另外一种制冷系统,即蓄冷式应急制冷系统。

①蓄冷式应急制冷系统简介

蓄冷式应急制冷系统其原理是通过介质将数据中心空调系统运行中的冷量进行储藏,在需要时再将冷量释放出来用于数据中心制冷需求。根据蓄冷介质的不同,目前蓄冷系统主要分为蓄水和蓄冰两种模式,水蓄冷系统是利用水的显热储存冷量(图2),而冰蓄冷系统是利用相变潜热来储存冷量(图3)。与冰蓄冷相比,水蓄冷单位体积内的蓄冷量较小,所需蓄冷罐容积较大。尽管如此,水蓄冷依然是数据中心常用的蓄冷形式。

图2 水蓄冷系统示意图

为什么选择水蓄冷而不选择冰蓄冷呢?数据中心蓄冷装置用于保证制冷系统短时故障期间的供冷,其瞬时用冷量很大,由于冰蓄冷技术的融冰速度有限,不适用于数据中心快速释放储存冷量的要求。相比之下,水蓄冷技术则具有如下优势:

(1)响应快:水蓄冷系统的冷水温度与原系统的空调冷水温度相近,可考虑直接使用,即与原空调系统进行“无缝”连接。

(2)安全系数高:水蓄冷系统结构简单,环节较少,故障率低。

(3)成本低:水蓄冷系统耗电量低,技术要求低,运行费用低。

图3 冰蓄冷系统示意图

②蓄冷设备的连接方式

蓄冷罐作为附加的冷冻水储备设备,是蓄冷系统重要组成之一。它具有应急冷源功能,可保障冷源系统失电后数据机房区的正常供冷。当冷水机组因失电停机后,蓄冷罐将作为应急冷源与冷冻水系统构成应急制冷系统。当柴油发电机正常运行且冷水机组恢复供电后, 蓄冷罐停止供冷,重新切换为蓄冷工况。蓄冷罐与冷水机组主要有两种方式连接:

(1) 冷水机组与蓄冷罐串联

图4 冷水机组与蓄冷罐串联

蓄冷罐串联接入用于空调系统的容灾备份,冷冻水流经蓄冷罐以保证随时供应冷量 (图4) 。该连接方式控制相对简单, 冷冻水直流过蓄冷罐无旁路冷损失。其缺点是蓄冷罐会增加管路系统的流动阻力,从而致使水泵能耗升高。

(2) 冷水机组与蓄冷罐并联

蓄冷罐并联接入主空调系统:蓄冷模式时,冷水机组对蓄冷罐进行充冷;放冷模式时,蓄冷罐为末端负荷提供冷源。该连接方式控制相对复杂,冷冻水需要经旁路流入蓄冷罐会产生一定冷损失,但此方式对系统阻力的影响较小。

③蓄冷罐结构形式

鉴于水蓄冷在数据中心的广泛应用,此处重点阐述水蓄冷罐。一般地,水蓄冷主要有开式、闭式两种形式。开式蓄冷罐与外界环境连通,具有气液界面:其体积较大,不利于灵活布置,因此通常至于室外。相比之下,闭式蓄冷罐体积小,因此可以方便的在室内布置。

蓄冷罐的设计取决于数据中心所需要的额定制冷量,而该冷量取决于水的比热、体积等,还与罐体与周围环境的热交换有关。在忽略罐体热损失的情况下,蓄冷罐容积可根据热平衡进行估算:

其中,V为蓄冷水量(m3);Q为额定蓄冷量(kw);η为蓄冷装置的容积效率,一般取0.96~0.99;ρ为蓄冷水密度,取1000kg/m3;为释冷回水温度与蓄冷进水温度间温度差;Cp为水的定压比热容,4.2kJ/kg/℃。

图5 某数据中心水蓄冷罐

④蓄冷设备的其他用途

蓄冷罐等蓄冷设备不仅可以用作数据中心应急制冷,同时也具备了其他辅助功能,如峰谷电价运营调优、早期低负载运行调优等。

(1)峰谷电价运营调优:当蓄冷罐容量较大时,我们可以利用峰谷电力价格的差异,选择在夜间蓄冷,白天通过蓄冷罐给数据中心制冷的模式进行调优。尤其在电力缺乏的区域,具有较大的潜力。除了数据中心行业,其他领域也有广泛的应用,如图6为某机场配置的蓄冷罐系统。

图6 蓄冷罐系统

(2)早期低负载运行调优:大型数据中心通常采用大型冷水机组,但在上架初期,由于上架量少,机房热负荷较低,此时既可采用风冷系统,亦可采用水冷系统。当采用水冷系统时,冷机系统长期处于低负载运行状态,甚至有可能无法正常运行。因此,部分机房在除配备大型冷水机组以外,还增加了1~2套螺杆机组(容量较小),以用于早期低负载运行。待上架量提升和稳定后,再采用大型机组作为日常运行方式,螺杆机作为备份机组。这无疑增大了制冷系统的复杂性。若在制冷系统中配置蓄冷罐,则可很好地解决该问题:先通过大型冷水机组向蓄冷罐提供冷量,再通过蓄冷罐为早期低热负荷的机房进行温度控制。该方案既可以实现峰谷电价调优运行,还可以简化机房制冷系统配置。

3.其他应急冷源

双冷源系统、带蓄冷设备的冷水系统基本可以解决数据中心制冷的主要痛点。但在一些特殊情况下,如对水冷系统的主管阀门进行维护或更换、MDC末端Y型阀门故障更换等。在这个过程中,虽然末端CRAC仍然可以保持运转,但冷冻水的供应出现中断,机房温度面临骤升的紧急情况。另外,当数据中心开展计划性维护作业,尽管我们可以协调业务侧对非关键设备实施停机维护。但对于重要的网络核心、DB等核心节点设备,我们仍需要重点保障。在这种场景下,我们仍需要探索一些新的冷源。最简便的办法是与制冰厂进行协调,提前调用冰砖(图7),并辅以大功率风扇制冷。

图7 某数据中心应急备用冰砖

有数据中心同仁也提出将干冰作为数据中心备用冷源。因为干冰运输方便、使用过程中由固态转化为气态,不会在机房内产生液体从而对服务器的运行造成不良影响。因此干冰可作为机房应急制冷的备选。但是,干冰的大量使用,可能导致机房内二氧化碳浓度在短时间内急剧升高,可能对机房运维人员产生不利影响,因而在目前的数据中心鲜有采用干冰作为应急冷源。后续我们也将对干冰作为应急冷源的可靠性、可行性进一步研究和探讨。

三.总结

随着大型数据中心基础设施架构设计的不断优化和完善,蓄冷罐已经作为水冷系统中应急备份的重要冷源而被广泛使用。但也有些机房由于内部规范的要求,对一定规模以下的数据中心仍主推双冷源系统,同时也将冰砖等移动式冷源作为数据中心最后的制冷保障手段纳入到数据中心的应急响应中。

无论哪种模式,都是在基础设施架构层面进行充分的考量。但要真正实现制冷系统间平滑切换而不影响业务运营,仍然需要经过大量的运营培训和实操。在数据中心验证测试阶段,运营团队需要充分验证制冷系统是否可以覆盖各种场景,并形成相关的应急预案;还需定期开展模拟演练。只有真刀真枪的演练,方能临危不乱,应对有序。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-05-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯数据中心 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
领域驱动设计(DDD)概念入门
模型是用来解决特定的问题,一般我们只讲“模型对于这个领域是否更有用”,而不是那个模型更好。
爬蜥
2022/03/09
7990
领域驱动设计(DDD)概念入门
万字长文助你上手软件领域驱动设计 DDD
作者:faryrong,腾讯 CSIG 后台开发工程师 最近看了一本书《解构-领域驱动设计》,书中提出了领域驱动设计统一过程(DDDRUP),它指明了实践 DDD 的具体步骤,并很好地串联了各种概念、模式和思想。因此,我对书本内容做了梳理、简化,融入自己的理解,并结合之前阅读的书籍以及实践经验,最终形成这篇文章。希望可以帮助大伙理顺 DDD 的各种概念、模式和思想,降低上手 DDD 的门槛。 1.背景 领域驱动设计(DDD)由 Eric Evans 提出,并一经《领域驱动设计:软件核心复杂性应对之道》的发布
腾讯技术工程官方号
2022/03/29
2.1K0
领域基本概念字典
领域驱动设计中定义了超多的概念,如果不多找几篇资料综合的去看,正确的理解比较困难,下面搜集整理了大部分的领域驱动中的概念,并加以理解描述。
IT大咖说
2021/01/27
1.2K0
领域基本概念字典
DDD领域驱动设计的概念解析
在学习 DDD领域驱动设计 的过程中,这种方法包括特别的抽象概念,晦涩难懂,本文结合作者理解,对其方法论中的一些概念进行解析。
憧憬博客
2021/06/02
1.2K0
「查缺补漏」,DDD 核心概念梳理
DDD 是什么,DDD 的英文全称是 Domain-Driven Design,翻译过来就是领域驱动设计。
悟空聊架构
2022/05/13
8510
「查缺补漏」,DDD 核心概念梳理
领域驱动实践总结(基本理论总结与分析V+架构分析与代码设计+具体应用设计分析)
2.实现方式:DDD 分层架构、整洁架构、CQRS 和六边形架构等 (我们采用DDD 分层架构)
全栈程序员站长
2022/08/10
8120
领域驱动实践总结(基本理论总结与分析V+架构分析与代码设计+具体应用设计分析)
领域驱动设计之我见
2004年,Eric Evans 发表了《Domain-Driven Design –Tackling Complexity in the Heart of Software 》(领域驱动设计)这本书,简称Evans DDD,书里对领域驱动做了开创性的理论阐述。它为我们提供了设计软件的一个全新视角,同时也给开发者留下了一大难题:如何将领域驱动设计付诸实践?
saintyyu
2021/11/22
4980
领域驱动设计之我见
领域驱动设计(DDD)理论启示
过去几年通天塔一直处于快速的业务能力建设和架构完善的阶段,以应对不断增长的业务需求和容量、高可用等技术需求,现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力,主流程的新需求越来越少,个性化需求和非标准化流程的数据源和服务接入的需求越来越多,有些甚至是京东零售体系外的,同时通天塔技术和产品也在积极主动寻求变化和创新,这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目:通天塔积木,旨在构建一个基于完全开放的前端SDK和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方IT环境的活动搭建解决方案,这套方案的初衷和设计理念也契合了京东国际化赋能和PaaS化的战略。目前通天塔积木已经取得阶段性成果,已开始赋能京东国内和国际站,但如何应对异常复杂的积木业务逻辑和不可预知的业务变化,构建业务和底层技术基础实施的完全解耦的系统,一直是我们面对的巨大挑战。也是时候从更高视角来看清问题和源头,思考一种能应对和控制业务复杂度、具备强扩展性和弹性的解决方案。纵观我们的目标,DDD这个词不知不觉映入了我的眼帘。
物流IT圈
2020/03/16
1.8K0
领域驱动设计(DDD)理论启示
大家一直在谈的领域驱动设计(DDD),我们在互联网业务系统是这么实践的
前言 至少30年以前,一些软件设计人员就已经意识到领域建模和设计的重要性,并形成一种思潮,Eric Evans将其定义为领域驱动设计(Domain-Driven Design,简称DDD)。在互联网开发“小步快跑,迭代试错”的大环境下,DDD似乎是一种比较“古老而缓慢”的思想。 然而,由于互联网公司也逐渐深入实体经济,业务日益复杂,我们在开发中也越来越多地遇到传统行业软件开发中所面临的问题。本文就先来讲一下这些问题,然后再尝试在实践中用DDD的思想来解决这些问题。 问题 过度耦合 业务初期,我们的功能大都
美团技术团队
2018/03/13
2.5K0
大家一直在谈的领域驱动设计(DDD),我们在互联网业务系统是这么实践的
领域驱动设计-上
随着软件系统越来越庞大,需求越来越模糊,代码越来越混乱,测试越来越困难,技术演进基本不可能,而其中大型复杂的软件项目更容易走向系统老化的过程,形成需求难、开发难、测试难、创新难,单体架构局部业务膨胀可以拆成微服务,那么微服务局部业务膨胀又应该怎么做?DDD之所以火,即能解决微服务解决不了的问题。DDD是为了解决快速变化、复杂系统的设计问题。
用户7353950
2022/06/23
4830
领域驱动设计-上
DDD 领域驱动设计落地实践系列:战略设计和战术设计
通过前面的文章介绍,相信大家对于什么是 DDD 有了初步的了解,知道它是一种微服务的架构设计方法论,为我们解决如何建立领域模型,如何实现微服务划分等提供了方向和指导。但是对于如何具体落地使用 DDD,可能大家还是一脸懵 B 的状态,因此从本文开始以及后面的文章将对如何进行 DDD 落地进行详细的阐述。在这其中还是会涉及到 DDD 中的一些重要概念,原本想着在一篇文章中介绍所有的概念,但是我觉得,概念总是在它该出现的时候出现才会让大家印象深刻,否则这些概念只是死板的概念,我们不清楚他为什么出现以及可以解决什么问题。
慕枫技术笔记
2023/03/20
9300
DDD 领域驱动设计落地实践系列:战略设计和战术设计
领域驱动设计-下
分层架构设计就是为了帮助我们达到高内聚、低耦合复用性设计和扩展性设计。整洁架构、CQRS、六边形架构等微服务架构都旨在实现“高内聚低耦合”,而分层架构基本原则是每层只能与位于其下方的层发生耦合。分层架构又分为两种:
用户7353950
2022/06/23
8170
领域驱动设计-下
领域驱动设计_01_基本概念
(1)边界 限界上下文是一个显示的边界,领域模型边存在于这个边界之内。 在边界内,每一个概念模型,包括其属性和操作,都具有特定的含义。
shirayner
2022/03/11
4620
领域驱动设计_01_基本概念
领域驱动设计
本文对《领域驱动设计-软件复杂性应对之道》一书进行高度凝练,梳理了领域驱动设计的架构图、基本要素和重要概念。从细节入手,以小见大,你想知道的定义,这里都有。
kaiwest
2025/01/16
850
领域驱动设计精粹(中)
领域驱动设计学习拦路虎之一就是众多的概念,第一次接触这些概念会有一定的理解成本,不过正是这些概念支撑起的领域驱动设计,接下来会以电商为例对其中的核心概念做介绍。
知一
2022/09/23
9430
领域驱动设计精粹(中)
后端开发实践系列——领域驱动设计(DDD)编码实践
的确,很多时候软件的业务逻辑是无法通过推理而得到的,有时甚至是被臆想出来的。这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解。而在具体编码实现时,除了应付业务上的复杂性,技术上的复杂性也不能忽略,比如我们要讲究技术上的分层,要遵循软件开发的基本原则,又比如要考虑到性能和安全等等。
ThoughtWorks
2019/08/01
1.3K0
后端开发实践系列——领域驱动设计(DDD)编码实践
领域驱动设计概览
领域驱动设计(Domain Driven Design,DDD)是由Eric Evans最早提出的综合软件系统分析和设计的面向对象建模方法,如今已经发展为一种针对大型复杂系统的领域建模与分析方法。它完全改变了传统软件开发工程师针对数据库进行的建模方法,从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为,通过合理运用面向对象的封装、继承、多态等设计要素,降低或隐藏整个系统的业务复杂性,并使得系统具有更好的扩展性,应对纷繁多变的现实业务问题。
张逸
2018/10/24
8300
领域驱动设计概览
一文带你落地DDD
hello,everyone,好久不见。最近几周部门有个大版本发布,一直没有抽出时间来写博。由于版本不断迭代,功能越做越复杂,系统的维护与功能迭代越来越困难。前段领导找我说,能不能在架构上动手做做文章,将架构迁移到DDD。哈哈哈哈,当时我听到这个话的时候瞬间来了精神。说实话,从去年开始从大厂的一些朋友那里接触到DDD,自己平时也会时不时的阅读相关的文章与开源项目,但是一直没有机会在实际的工作中实施。正好借着这次机会可以开始实践一下。
柏炎
2022/08/23
8250
一文带你落地DDD
领域驱动设计——术语篇
随着微服务架构的普及,领域驱动设计(DDD)又重回软件设计战场。虽然团队内不少项目已经开始尝试,使用DDD指导项目的设计与开发,但还是有不少同学对DDD缺乏基础了解。因此,本文结合书本的定义及个人理解,对DDD中关键概念进行梳理,避免沟通时的歧义。毕竟DDD提倡使用通用语言,业务层面应该使用通用语言,技术层面也应该统一术语。
liliane
2022/07/27
8450
领域驱动设计DDD核心思想
限界上下文是语义和语境上的边界。这意味着边界内的每个代表软件模型的组件都有着特定的含义并处理特定的事务。限界上下文中的这些组件有特定的上下文语境和语义理据。 当限界上下文被当作组织的关键战略举措进行开发时,即被称之为核心域。
在下是首席架构师
2022/08/01
8970
相关推荐
领域驱动设计(DDD)概念入门
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档