为超融合架构选择合适的数据中心冷却系统

简介:

虽然超融合基础架构会带来很多好处,比如精简的IT管理方法,但从数据中心散热的角度来看,它也同时带来了一些特殊的挑战。

当把超融合基础架构的机器安装到机柜上的时候,会在密集的冷却环境中制造出高热量密度。保持散热通道的畅通无阻非常重要,但是要保证正常的温度下给予机器足够的散热风,还要让热量尽量远离这些机器是比较困难的。

其实对于其他IT硬件来说这个原则是一样的,但是鉴于高度融合基础架构(HCI)的密集性以及安装的简易性,你会发现要在数据中心打造一个有效率的散热系统其实是很困难的。很多数据中心在建立之初并没有考虑到这种高度融合的系统的散热问题,但是只要你使用合适的技术,你还是可以让你的数据中心尽可能地有效。

HCI的电源通常来说可以达到1000瓦(W)以上,这会产生很多热量。一个2U高的HCI机器可能会达到25-30KW的功耗,相对来说传统的1U服务器只会产生350-500瓦的功耗而已。即使你已经做了很多减少空气混合的改造(例如分离热通道和冷通道,使用空白面板和保持密闭度),可能理论上已经能够达到冷却的要求,但是实际上你可能还是达不到要求的温度,

什么冷却系统对于HCI系统来说是最好的呢?
美国采暖、制冷与空调工程师学会(ASHRAE)建议的入风温度是80.6华氏度(或27度摄氏度),这不仅仅能节省能源,还能增加空调的制冷能力。更高的进风温度会导致空调的回风温度也会更高。一台典型的20吨机房空调(CRAC)运行在84 kW功率和75华氏度进风温度的情况下会提供137kW的冷却能力以及90华氏度的回风。这里的差异还是蛮大的,但是这并不能保证这些冷却的能力最终都能利用到计算机设备上去。

有效的数据中心冷却系统要考虑性能以及风道。如果环境中空气不够的话,服务器风扇会尝试从其他地方吸收空气——这包括了机柜的顶部、机柜设备之间没有固定的空间、临近的机柜或者机柜与地板的空隙。这会带来两个问题,第一个问题是服务器风扇会加速并且消耗额外的能源。

这样的结果是,被服务器风扇抽取的空气的地方会比空调处的空气热很多。 如果你的入风温度已经非常高了,那么这些昂贵的设备会比他们预想的更热,从轻的层面上讲,这会带来一些数据错误。这还会减少这些设备的寿命,并且也会一定程度损坏这些设备。

对于HCI我需要多少空气呢?

有了以下这个公式,你就能快速决定你的数据中心内的空气数量是否满足你设备的需求了。

CFM = BTU/1.08 x TD

CFM是每立方尺每分钟的空气流量

BTU是每小时英热量单位的热负荷

(BTU = Watts x 3.414)

1.08是在正常情况下的空气校正常数

TD是温差,或者叫做Delta温度或ΔT

进风的温度和出风的温度差异大概在25华氏度左右。

做一个快速的计算,假设电源是在几乎满负载的情况下运作的,那么1600瓦单元等效于5460 BTU。假设温差是25华氏度,那么设备需要202 CFM的空气才不会出现问题。

如果你在一个机柜内装满了HCI系统,那么你需要4000 CFM的空气。如果你的空调是普通的20吨机房空调的话,那么它能提供12000 CFM,那么结果是你只能冷却3个机柜的设备。即使你假设服务器的利用率平均有75%,那么每个机柜你还是需要3000 CFM的空气。

如果我无法提供那么多空气怎么办?以下的公式可以帮你解决温差的问题:

TD = BTU / 1.08 x CFM

4个利用率75%的机柜会需要12000 CFM,但是如果附近的机柜需要额外的6000W功率的话,那么你就需要等效的6个HCI机柜的功耗,即至少18000 CFM。你的机房空调可能只能提供12000 CFM。假设你的服务器群是在全速运行的,但是又不能从其他地方抽取更多的空气,那么你的温差会变成53华氏度。这个时候计算设备很可能无法忍受这个温度,从而会导致机器被关闭,或者失效。

其他空气气流限制

如果我们有很多机房空调,那么它们可以将空气直接排放到每一列机柜中去。如果你使用的是地板下的空调,格子型的瓷砖也只能提供56%的开放空间,根据不同的地下压力它可以提供900-1600 CFM,或者5-9 kW的制冷功率。如果你安装了过多的这些瓷砖或者风扇助力的瓷砖,会导致地下的空气压力变小,从而会抽取其他排机柜的空气。风道的大小限制了空气在空中的传递——也就是说即使你有足够的空调来传递足够的空气,但是传递的过程中也会受到一定的限制,从而有一些空气无法到达计算机硬件。

当每一个机柜达到7500 W~10000 W的功率的时候,你可能需要额外的数据中心冷却系统。有很多冷却系统是专门用来对付高密集型计算数据中心的。其中包括地面的和架空冷却器,后门热交换器,甚至液体冷却系统。在未来我们可能会看到越来越多高性能系统设计成支持直接水冷。

本文转自d1net(转载)

目录
相关文章
|
3天前
|
监控 持续交付 API
深入理解微服务架构:构建高效、可扩展的系统
【10月更文挑战第14天】深入理解微服务架构:构建高效、可扩展的系统
17 0
|
2月前
|
Ubuntu Linux
查看Linux系统架构的命令,查看linux系统是哪种架构:AMD、ARM、x86、x86_64、pcc 或 查看Ubuntu的版本号
查看Linux系统架构的命令,查看linux系统是哪种架构:AMD、ARM、x86、x86_64、pcc 或 查看Ubuntu的版本号
503 3
|
5天前
|
存储 监控 负载均衡
|
13天前
|
传感器 存储 架构师
构建基于 IoT 的废物管理系统:软件架构师指南
构建基于 IoT 的废物管理系统:软件架构师指南
46 9
|
16天前
|
存储 安全 开发工具
百度公共IM系统的Andriod端IM SDK组件架构设计与技术实现
本文主要介绍了百度公共IM系统的Andriod端IM SDK的建设背景、IM SDK主要结构和工作流程以及建设过程遇到的问题和解决方案。
37 3
|
19天前
|
Kubernetes Cloud Native 云计算
云原生时代的技术演进:Kubernetes与微服务架构的完美融合
随着云计算技术的飞速发展,云原生概念逐渐深入人心。本文将深入探讨云原生技术的核心——Kubernetes,以及它如何与微服务架构相结合,共同推动现代软件架构的创新与发展。文章不仅剖析了Kubernetes的基本工作原理,还通过实际案例展示了其在微服务部署和管理中的应用,为读者提供了一条清晰的云原生技术应用路径。
36 2
|
1月前
|
监控 Android开发 iOS开发
深入探索安卓与iOS的系统架构差异:理解两大移动平台的技术根基在移动技术日新月异的今天,安卓和iOS作为市场上最为流行的两个操作系统,各自拥有独特的技术特性和庞大的用户基础。本文将深入探讨这两个平台的系统架构差异,揭示它们如何支撑起各自的生态系统,并影响着全球数亿用户的使用体验。
本文通过对比分析安卓和iOS的系统架构,揭示了这两个平台在设计理念、安全性、用户体验和技术生态上的根本区别。不同于常规的技术综述,本文以深入浅出的方式,带领读者理解这些差异是如何影响应用开发、用户选择和市场趋势的。通过梳理历史脉络和未来展望,本文旨在为开发者、用户以及行业分析师提供有价值的见解,帮助大家更好地把握移动技术发展的脉络。
59 6
|
1月前
|
网络协议 安全 中间件
系统架构设计师【第2章】: 计算机系统基础知识 (核心总结)
本文全面介绍了计算机系统及其相关技术,涵盖计算机系统概述、硬件、软件等内容。计算机系统由硬件(如处理器、存储器、输入输出设备)和软件(系统软件、应用软件)组成,旨在高效处理和管理数据。硬件核心为处理器,历经从4位到64位的发展,软件则分为系统软件和应用软件,满足不同需求。此外,深入探讨了计算机网络、嵌入式系统、多媒体技术、系统工程及性能评估等多个领域,强调了各组件和技术在现代信息技术中的重要作用与应用。
48 4
|
1月前
|
缓存 运维 NoSQL
二级缓存架构极致提升系统性能
本文详细阐述了如何通过二级缓存架构设计提升高并发下的系统性能。
109 12
|
1月前
|
运维 Kubernetes Cloud Native
探索云原生技术:容器化与微服务架构的融合之道
【9月更文挑战第18天】在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性成为企业创新的强大引擎。本文将深入探讨云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同推动现代应用的开发与部署。通过实际代码示例,我们将揭示这些技术如何简化运维,加速产品上市时间,并提高系统的可靠性和弹性。无论你是开发人员、架构师还是IT决策者,这篇文章都将为你提供宝贵的洞见和实践指导。
37 2