数据中心 · aiwiki.page

数据中心是指用于容纳计算机系统及相关设备，以处理、存储和交换数字信息的房间、建筑物或建筑群。它将信息技术（包括服务器、存储设备和网络设备）与电力供应、制冷冷却、物理防护及运维管理等配套支持系统结合在一起。数据中心为企业级应用、互联网服务和云计算提供了物理基础；“云”只是一种提供计算资源的方式，而非承载这些资源的物理设施的替代品。(ibm.com)

数据中心形态多样，既有机构内部的计算机机房，也有大型园区级设施以及靠近用户部署的小型边缘设施。其运营融合了计算机工程、电信、建筑机电与设施工程以及可靠性工程。随着对数字服务和人工智能需求的不断攀升，数据中心的发展也与电力供应、水资源保障及环境核算紧密关联。因此，全面了解数据中心既要关注其计算架构，也要审视支撑其运转的基础设施、运营规程与资源消耗体系。(ibm.com)

历史发展

20世纪40年代，随着房间大小的电子计算机的出现，专用的计算机机房应运而生。由宾夕法尼亚大学的 J·普雷斯珀·埃克特（J. Presper Eckert）和约翰·莫奇利（John Mauchly）研制的埃尼阿克（ENIAC）于1945年建成，并于1946年2月公之于众。它包含约18,000只电子管，重达30吨，占地超过1,500平方英尺。安放这样的设备需要专用的场地设施，而非普通办公空间：机器的占地面积和支撑性基础设施对其运行至关重要。这些设施即是数据中心的前身，不过当时它们容纳的是独立的计算系统，而非服务器网络。(computerhistory.org)

20世纪50年代和60年代，大型计算机成为企业和政府数据处理中心的核心资源。IBM 于1964年4月7日发布的 System/360 展现了向可扩展计算平台演进的趋势。其首批六款处理器型号在共享通用架构的同时，性能跨度达五十倍之多，使客户能够在不彻底重写软件的情况下扩展处理能力。计算机房作为集中运行设施的一部分，容纳着处理器和外围设备。随后的分时技术允许终端上的多个用户共享计算处理资源，从而使用户所处的位置与为其提供服务的中央主机相分离。(ibm.com)

20世纪80年代和90年代，客户机-服务器计算模式将应用程序功能分散在用户计算机与联网服务器之间，其中包括提供共享数据库的服务器。较小型的机器可以分散部署，但成批的服务器同样占据了专门的计算机房，包括原先用于安置大型机的空间。互联网和万维网的兴起进一步扩大了对面向外部访问的托管服务及网络互联的需求。商业机房托管将计算设备的所有权与其物理场地的运维分离开来：客户将自身硬件安装在提供空间、电力、制冷和网络连接的设施中。成立于1998年的 Equinix 展现了伴随而来的运营商中立设施的发展，竞合网络无需依赖单一电信运营商即可在此实现互联。(ibm.com)

虚拟化改变了这些设施内部计算资源的分配方式，但它的起源比商业云计算服务的诞生要早数十年。IBM 的实验性 CP-40 系统于1967年投入运行，VM/370 则于1972年8月2日正式发布。VMware 于1999年通过 VMware Workstation 将虚拟化技术引入商业 x86 产品中。通过允许多个隔离的操作系统环境共享物理硬件，虚拟化支持了服务器整合，从而无需为每个应用程序单独配备服务器。计算能力可以通过软件进行分配和重新配置，减少了对物理安装工作的依赖，并创造了利用原本闲置资源的机会。(vm.ibm.com)

商业云计算将资源池化扩展为按需服务模式。亚马逊于2006年3月14日推出了 S3 存储服务，随后于同年8月开放了 EC2 的小规模公测。早期的 EC2 服务采用 Xen 虚拟化技术，收费标准为每实例小时0.10美元；其宣传的配置包括 1.75 GB 内存和 160 GB 本地存储。客户无需采购底层服务器即可获得计算能力，而物理基础设施则由服务提供商负责运维。美国国家标准与技术研究院（NIST）在2011年的定义中，正式确立了按需自助服务、资源池化、快速弹性以及可计量的服务作为云计算的核心特征。大型共享资源池为超大规模部署奠定了基础，而规模较小的边缘设施则将特定服务部署在更贴近用户的位置，以降低通信延迟。这些发展带来的是集中化与地理分布化相辅相成的形态，而非完全淘汰企业计算机房或主机托管设施。(press.aboutamazon.com)

设施类型与所有权模式

企业自有设施主要服务于拥有它的组织自身，而非对外出售托管容量。企业拥有其中的计算设备与场地基础设施，并负责其部署、监控、维护和管理。托管（Colocation）则将这些职责分离开来：客户将自身的服务器、存储和网络设备放置在由第三方运营的空间内，第三方负责提供电力、制冷、物理安全及网络连接等配套支撑服务。例如在 Equinix，客户可以在共享设施内租用机柜或独立的机笼隔离区。因此，企业自建与托管的主要区别在于场地的提供与运营方是谁，而不在于内部部署的应用或硬件本身。(ibm.com)

管理型托管将更多的 IT 运营职责移交给了服务提供商。在典型模式下，客户租用专用的服务器、存储和网络硬件，由提供商负责这些设备的日常管理与监控。相比之下，在基础的托管服务中，客户仍对其自身的软硬件负全责；即便采购了可选的技术支持服务，这种责任也不会自动发生转移。Equinix 的“Smart Hands（现场技术支持）”服务就体现了现场协助如何作为托管服务的补充。合同约定的范围比业务名称更为关键：提供场地、按需更换部件以及管理操作系统是截然不同的服务，可以分别采购。(ibm.com)

云服务商设施容纳的是用于交付云计算服务的基础设施，而不仅仅是出租设备摆放空间。服务商负责运营底层硬件及服务基础设施，客户的责任则取决于所使用的具体服务类型。以 Amazon EC2 为例，AWS 负责管理物理基础设施和虚拟化层，而客户则负责管理客户机操作系统及应用程序。对于 Amazon S3 和 DynamoDB 等服务，AWS 还负责操作系统和平台的运维。物理位置并非界定这种交付模式的唯一标准：AWS Outposts 能够将由 AWS 管理的计算容量部署在客户自主管理的建筑中，此时建筑的所有者必须提供适宜的场地设施、电力和网络。因此，“本地部署”（On-premises）并不必然等同于由企业自主运营的 IT。(aws.amazon.com)

超大规模（Hyperscale）描述的是一种以极大体量部署和扩展计算基础设施的方式，它既不是一种独立的所有权形态，也不能简单等同于所有云设施。它强调横向扩展能力、广泛的自动化、可重复的基础设施设计以及规模经济。大型运营商既可以自主兴建大型园区，也可以向托管服务商租赁容量；因此，超大规模客户与托管机房房东可以共同参与同一处设施的运营。反之，云服务同样可以在规模较小的设施中运行。虽然业界描述中经常出现“5000 台服务器”等量化指标，但单纯的服务器数量门槛既无法解释其运维架构，也无法将云服务交付与其他大规模计算用途区分开来。(ibm.com)

边缘设施是根据其相对于用户、设备或数据源的物理位置来分类的。其目的是将数据处理能力部署在更靠近这些终端节点的位置，从而降低通信延迟或减少向中心节点传输数据的需求。边缘设施既可用于支持本地工业处理，也可用于内容分发，且不局限于某种特定所有权模式或建筑形式。AWS Outposts 正是这种为了实现本地处理和更低延迟而部署的集中式管理云基础设施的具体范例。因此，“边缘”描述的是分布式计算体系中的一种部署拓扑关系，而非界定建筑由谁拥有或服务器由谁管理。(ibm.com)

模块化设施采用可重复的构建单元；其预制版本在出厂交付前便已完成各子系统的组装与测试。模块内部可容纳 IT 设备、供电基础设施、制冷系统或这些系统的组合。集装箱式单元是一种具体的物理形态，通常采用标准 ISO 货运集装箱外壳；而模块化系统的形态还包括撬装式设备和定制外壳。2014 年，施耐德电气曾介绍过位于安哥拉的一处设施，该设施由 8 个模块组成，其中包括 6 个组合在一起的 ISO 集装箱模块。这些类型之间存在重叠：集装箱式设施既可服务于企业的边缘节点，预制供电模块也可用于支持超大规模云园区。无论是模块化建造还是集装箱外壳，都不能决定其托管业务的具体商业模式。(blog.se.com)

服务、工作负载与系统边界

事务处理通过接收请求、更新记录以及在多用户并发操作时维护数据完整性，为购物结算、银行转账和酒店预订等业务提供支撑。数据库提供持久化存储与检索功能；它是应用程序使用的一项组件，而非仅局限于事务的单一工作负载类型。联机事务处理通常涉及大量微小的插入、更新和删除操作，其响应时间以毫秒计。与之相对，数据分析则通过按地区和季度汇总销售额等操作来考察累积数据。因此，同一家机构可能同时运行面向事务的数据库以及由其记录供给的数据分析系统，两者的计算与存储访问模式截然不同。(ibm.com)

Web 服务通过网络交付应用程序响应，而内容分发则负责分发图像、视频片段等可复用对象。这些功能并不一定在同一处设施内执行：内容分发网络将对象缓存在地理上分散的各个节点，在缓存命中时直接提供内容，无需再次向源站请求该对象。例如，Amazon CloudFront 会明确区分由其自身缓存响应的请求与转发至源站服务器的请求。科学计算代表了另一种工作负载模式：气候模型、分子模拟和工程计算可以在多台机器间采用并行计算。紧耦合计算在执行过程中会频繁交换中间结果，而松耦合任务大多可以彼此独立运行。这些差异决定了系统性能究竟主要取决于计算能力、存储访问速度，还是机器间的通信开销。(docs.aws.amazon.com)

数据中心的物理系统由两个相互作用的层面构成。IT 设备包括负责处理、留存和传输信息的服务器、存储系统及网络设备。配套设施基础设施则负责供应电力、导出热量并维持物理运行环境；它包括电能转换与配电设备、制冷机房及相关控制系统。服务器内部的风扇和电源尽管在单机内部承担保障功能，但仍属于 IT 设备的一部分。美国能源部在 2024 年 7 月发布的设计指南中，将 IT 系统、环境工况、气流管理、制冷以及电气系统作为整体一并考量，因为 IT 需求的变化会间接引起设施能源消耗的连锁改变。计算设备功耗的降低，同时也能减少带走其热量所需的制冷能耗。(ibm.com)

在报告容量与资源消耗时，划分上述边界至关重要。处理器数量、内存、存储容量和网络吞吐量描述的是不同的 IT 能力；而供电与制冷容量描述的则是设施支撑已安装设备的能力。无论是占地面积还是服务器数量，单凭其一都无法衡量一座设施能承担多少应用层工作。能源核算同样会严格区分输送至 IT 设备的电量与设施的总用电量，后者还包含配套系统消耗和电力传输损耗。例如，一套持续 24 小时平均负载为 1 兆瓦的 IT 设备耗电量为 24 兆瓦时；但若制冷和配电损耗未计入该测量边界，这便不能代表整个园区的总用电量。因此，开展能耗对比的前提是具备统一的设备覆盖范围和测量周期。(energy.gov)

物理设施与部署在其中的服务同样有所区别。借助分布式计算，单个应用程序可以使用多处设施中的计算资源，而单处设施也可以托管众多应用程序的组件。在云计算中，服务的地理分布可以抽象为超越单一建筑的概念：例如，Amazon Web Services 将“区域”（Region）定义为一个独立的地理区域，将“可用区”（Availability Zone）定义为由一个或多个物理上分离的数据中心构成的集合。因此，一项被称为区域级或多可用区的服务不能等同于单栋建筑。其运行边界涵盖所有参与协同的 IT 系统和跨设施连接，而每个参与节点依然依赖于本地的电力、制冷与网络连通性。数据复制机制与故障转移能力，则决定了当部分基础设施发生故障时该服务能否持续可用。(docs.aws.amazon.com)

选址与地理分布

电力供应状况制约着数据中心的选址以及投运时间。一个合适的场地不仅需要廉价的能源，当地电网还必须具备充足的发电、输电与并网接入容量，以承载庞大且持续的电力负荷。国际能源署（IEA）在其2025年发布的《能源与人工智能》（Energy and AI）报告中预计，到2030年，电网瓶颈可能会导致约20%规划建设的数据中心产能延期投运。因此，可用土地的评估不能脱离市政公用基础设施。在荷兰埃姆斯哈芬，谷歌将可开发的工业用地、完善的能源基础设施以及熟练的技术工人列为其选址的主要原因。(iea.org)

网络接入构成了另一项独立的地理约束。电信服务的可用性、带宽、质量以及管线延伸成本，直接决定了一块地块能否支撑其预定的工作负载。土地的适宜性还取决于实际可建面积，而非单纯的占地面积：地形、土壤、排水、进出道路以及施工堆料与作业场地都会影响地块的实际可开发程度。当地的土地利用许可也可能进一步限制设备的安置与扩建。汤姆·维达夫斯基与汤姆·克拉夫特在电信工业协会（TIA）2019年12月发表的选址研究论文中明确指出了这些因素。(tiaonline.org)

当地气候与水基础设施与冷却方案的设计密切相关。凉爽的室外环境可以增加利用环境空气进行自然冷却（无需机械制冷）的运行时长；因此，除了年平均气温外，温湿度条件也至关重要。在采用蒸发冷却进行散热的场景下，可靠的供水成为另一项选址约束，在干旱易发地区尤为如此。水质、水储存及废水排放同样会影响方案的可行性。采用替代水源可能需要在场区外开展大量工程：据报道，谷歌投资4500万欧元建设了长达28公里的管道与净化系统，以在格罗宁根实现工业用水冷却，这表明场地的适宜性有时也取决于红线之外的基础设施建设。(energy.gov)

灾害风险评估既涉及建筑本身，也涵盖其外部依赖项。洪泛区分布与排水条件影响场地布局，而地震、强风暴、火灾及极端气温则可能威胁设备安全或中断配套保障服务。附近的危险品设施和交通走廊也会带来额外风险，包括事故发生后现场交通受阻。单纯的地理区隔并不等同于系统的独立性：不同的建筑仍可能因共用变电站、供水中断或光纤切断而同时受损。亚马逊网络服务（AWS）称其可用区（Availability Zones）采用独立的电力基础设施和不同的变电站，不共用发电机或冷却设备。同一区域内的各可用区之间距离可相距约100公里，同时仍能保持个位数毫秒级的网络延迟以支持同步复制。(tiaonline.org)

由此形成的地理分布格局，反映了“集中化”与“邻近性”之间的权衡。大型园区能够汇聚规模化算力，而对延迟敏感的应用则要求在靠近用户或设备端进行处理；后者的需求促使人们建设规模较小的边缘设施，即使当地的市政公用基础设施条件并不理想。此外，集中化还会对电网产生局部效应，而这一效应往往被全球能源总量的统计所掩盖。IEA在2025年的基准情景分析中预测，2024至2030年间，数据中心在全球电力需求增量中的占比不足10%，但调查发现，美国在建的数据中心中约有半数集中在现有的大型集群中。即使这些新建设施对全球能源需求增长的贡献相对有限，但在这些集群内部扩建设施仍可能遭遇当地并网的接入瓶颈。(tiaonline.org)

建筑布局与物理基础设施

设备大厅用于容纳计算、存储和网络设备的机架，而辅助空间则用来布置具有不同出入和维护要求的基础设施。配电室安装有开关柜和不间断电源（UPS）；暖通设备区则布置空气处理机组、水泵及相关机械设备。服务通道与机电管井沿大厅两侧延伸，提供人员通行与管线分布路由。专用电信空间用于接入外部运营商线路并进行内部缆线分配。这些功能分区均属于2024年5月发布的 ANSI/TIA-942-C 标准中所统筹协调的建筑、电气、机械及电信设计范畴。(fm.com)

在大厅内部，设备机架提供标准化的安装位置，并将设备规整排列成列。例如，IBM 的 42U Enterprise V2 Dynamic 机架采用19英寸安装规格，并设有用于放置配电单元（PDU）和交换机的侧舱，从而为主服务器保留主要的安装空间。机列间距并不能仅由机架尺寸决定：通道还必须容纳技术人员操作、柜门开启、设备抽拉以及更换整个机柜所需的转弯半径。美国国立卫生研究院（NIH）2013年发布的设计指南明确将通道无阻碍通行以及可从列中移出机架列为布局的刚性要求。(ibm.com)

结构设计需要统筹考虑设备自重、荷载分布以及在安装和维护期间产生的荷载。全室平均荷载并不能完全反映局部的真实受力情况：机柜支脚点荷载、设备搬运路线以及架空地板组件都需要进行独立评估。NIH 指南区分了设备重量、人员与检修设备荷载，以及架空地板和线缆荷载。该指南还为各类基础设施预留了垂直空间：其初步规划预留量包括架空地板0.61米、照明与消防系统0.305米，以及高度至少为2.13米的机架空间。这些数据属于早期的规划参考范例，并非适用于所有设施的通用尺寸。(wbdg.org)

走线通道与气流分配空间之间存在直接的相互影响。架空活动地板形成的下部空间可用于敷设强弱电缆线，在某些设计中还可用作送风静压箱。上方走线架则提供了替代的下垂布线方式，使得地板下无需同时兼顾走线与送风功能。美国能源部2024年发布的设计指南指出，地板下拥挤的缆线会阻碍气流，影响经由开孔地板送出的风量，进而导致局部热点的产生。针对架空地板系统，该指南建议有效净高至少应达到24英寸（约0.61米）。因此，缆线管理工作不仅包括清理废弃缆线，还包括确保设备进风口、排风口和气流通道畅通无阻。(energy.gov)

防火分隔能够限制火势在设备区与辅助区域之间蔓延。FM 全球的《数据手册 5-32》指出，耐火内墙应从结构楼板一直向上延伸至上一层楼板或屋顶，而不是止于吊顶处。火灾探测必须兼顾高速气流和通道封闭系统的影响：极早期空气抽样系统通过采样管网抽取空气样本，而高灵敏度点型探测器则针对特定重点区域进行监控。灭火手段包括自动喷水灭火、细水雾灭火和气体灭火系统，各系统具有不同的防护特性。因此，通道封闭隔板及其他空间障碍物的布置必须与探测器的点位及灭火系统的喷洒覆盖范围协同设计。(fm.com)

在引入水冷系统的区域，漏水检测构成了另一道关键屏障。IBM 的机房规划技术文档列举了能够检测并精确定位液体泄漏的地板下监测系统。空间的物理协调同样延伸到了机柜内部：例如 IBM 的 7965-S42 水冷分水器安装在机架右侧，这会导致该侧对应的 PDU 安装槽位无法使用。诸如此类的接口问题表明，建筑净空、管道走向、走线路径、供电设备和消防设施绝不可彼此孤立地设计；它们之间的相对空间关系直接决定了设备日后是否便于维护，以及各类安全防护系统能否有效发挥作用。(ibm.com)

计算硬件与存储

机架式服务器将处理器、主内存、本地硬盘、网络接口和管理电子器件集成在一个机箱内，专为在设备机架中进行安装和维护而设计。中央处理器（CPU）执行操作系统与应用程序指令；内存模组保存运行中的工作数据，而挂载的硬盘则提供持久化存储。戴尔（Dell）的 PowerEdge R760 是一个代表性配置：这是一款 2U、双路服务器，其第四代英特尔至强（Intel Xeon）配置支持每颗处理器最高 56 个核心，并配有 32 个 DDR5 内存插槽，标称最大内存容量为 8 TB。该机型使用纠错码（ECC）内存，并提供包含 SAS、SATA 或 NVMe 硬盘的配置选项，同时配备板载或扩展卡形式的网络接口。这些数值代表配置上限，并不意味着每台服务器都必定安装了这些部件。(i.dell.com)

基板管理控制器（BMC）提供了一条独立于宿主操作系统的管理通路。诸如戴尔 iDRAC 之类的实现方案通过带外接口公开硬件状态和远程管理功能，使管理员能够在不依赖应用程序正常运行的情况下检查设备并执行受支持的恢复操作。该控制器是对服务器主处理器及面向应用程序的网络接口的补充，而非替代。(downloads.dell.com)

通用 CPU 擅长处理多样的指令序列和控制密集型任务，而加速器则将更多资源投入到特定的计算模式中。图形处理器（GPU）通过并发执行大量线程来实现高吞吐量，非常适合处理高度并行的数值计算以及机器学习中使用的矩阵运算。GPU 加速通常作为异构系统的一部分存在：CPU 运行主机端代码、启动设备端任务，并协调主机内存与加速器内存之间的数据传输。因此，其性能不仅取决于算力，还取决于并行度和数据传输能力。(docs.nvidia.com) 加速器服务器还会将巨大的电力需求集中在单个机箱内。例如，英伟达（NVIDIA）DGX H100 的规格说明书标明其配备 8 颗 H100 GPU（共计 640 GB GPU 显存）、双路 x86 CPU、2 TB 系统内存，以及约 10.2 kW 的系统最大功耗。该最大值属于设备硬件规格，并不代表持续运行时的实际功耗。(nvidia.com)

存储的连接方式与访问方式属于两个不同的分类维度。直连存储（DAS）无需经由存储网络即可将硬盘直接连接到单个服务器；网络化存储则通过网络连接向主机提供存储资源。存储区域网络（SAN）通常呈现为块设备，而网络附加存储（NAS）通常呈现为共享文件。(ibm.com) 块访问提供可寻址的块，主机可以在其上构建文件系统或存放数据库数据。文件访问通常通过 NFS 或 SMB 协议，提供目录中具名的文件。**对象访问**通过应用程序编程接口（API）利用标识符对数据对象进行寻址，元数据则随同存储的内容一起保存。因此，块、文件和对象描述的是接口形式与组织结构，并非互斥的物理介质：对象存储服务最终完全可以将内容存储在普通存储服务器内的硬盘上。(ibm.com)

存储容量、吞吐量、延迟和冗余度描述的是不同的属性。容量用于衡量存储的数据量；吞吐量用于衡量每秒传输的字节数；每秒输入/输出操作次数（IOPS）用于统计已完成的操作数；延迟用于衡量单次操作所需的时间。请求大小关联着吞吐量与 IOPS，而并发量和队列深度则影响系统能否达到其标称极限。大块数据传输可能在达到最大 IOPS 之前就已耗尽吞吐量上限，而低并发应用可能两者都无法达到峰值。(cloud.ibm.com) 冗余机制通过镜像或奇偶校验等手段占用额外的存储空间，因此可用容量与已安装硬盘的物理总容量并不等同。不同的 RAID 级别在容量开销、读写性能以及对硬盘故障的容忍度上各不相同；RAID 0 仅提供条带化，不具备容错冗余能力。RAID 并不等同于备份，因为在单盘故障后保持阵列正常运行并不能提供独立的历史数据副本。(ibm.com)

网络与外部连通性

数据中心网络承载着服务器与存储系统之间的东西向流量，以及进出机房设施的南北向流量。来自外部客户端的单次请求可能会在应用服务器、缓存和数据库之间触发多次内部交互，因此仅凭外部带宽并不能完整描述网络需求。支持分布式计算的内部通信往往需要庞大的总带宽和持续的低延迟；大容量数据传输则更注重持续吞吐量。外部服务延迟还包含了设施与用户之间的网络路径耗时。这些需求取决于具体的工作负载，而非简单划分为“快速”的内部网络与“缓慢”的外部网络。(ibm.com)

交换机用于连接服务器并在设施内转发流量，而路由器则在各 IP 网络之间以及朝向外部目标转发数据包；单一交换平台亦可同时承担这两项功能。物理连接方面，适于短距连接的铜缆与配合光收发模块使用的高容量或长距离光纤各司其职。综合布线系统通过主干光缆/电缆、配线架和可更换跳线来组织这些链路，将永久性的线缆基础设施与设备连接分离开来。这使得在重新部署服务器与交换机时，无需更换期间的所有线缆。(cisco.com)

传统的层级网络由连接服务器的接入交换机、汇聚接入网络的汇聚交换机，以及连接各汇聚模块与外部网络的核心交换机组成。而叶脊网络则在两层网络架构中将每个叶交换机连接到每个脊交换机。服务器接入叶交换机；不同叶交换机之间的流量经过脊交换机，形成一致的“叶–脊–叶”路径。三层等价多路径路由（ECMP）将数据流分发到各个可用的脊路径上，使并行链路能够共同承载流量，而无需仅保留为非活动备份。在受制于可用交换机端口和上行链路的前提下，增加脊交换机可扩充网络矩阵容量，增加叶交换机则可提供更多面向服务器的端口。(cisco.com)

端口速率本身并不能直接决定可用网络容量。超配比（Oversubscription）衡量的是面向服务器的总带宽与上行链路带宽的比值：思科 2024 年的网络架构设计白皮书给出了一个包含 48 个 25 Gbit/s 下行链路和 8 个 100 Gbit/s 上行链路的示例，其计算结果为 $1{,}200/800 = 1.5:1$ 。因此，若同时发往该叶交换机外部的流量过大，可能会超过其上行链路容量。冗余路径可在发生故障后提供备用路由，但物理多样性（路由物理隔离）则是另一回事：两条连接可能共用同一线缆路由或中间基础设施。例如，Equinix 明确将不保证路由物理隔离的普通楼内交叉连接与采用独立路由的园区连接区分开来。(cisco.com)

外部连通性负责将客户设备接入电信运营商、专用网络、云平台或互联网服务提供商。交叉连接（cross-connect）是设施内不同参与方之间的专用物理线缆连接；它仅提供物理链路，并不等同于自动提供互联网服务。互联网转接（Internet transit）通过提供商提供向下游的连接，而对等互联（peering）则在参与网络之间直接交换流量。对等互联可以采用专用的私有交叉连接，也可以通过共享的互联网交换中心交换平台实现。数据中心是容纳设备的物理设施；交换中心是一个互联平台，可能跨越一个或多个设施；而运营商网络则延伸至更广阔的范围。(docs.equinix.com)

机房互联链路通过租用传输服务、托管城域光纤连接或配合客户传输设备使用的暗光纤等方式，将不同的数据中心连接起来。这些链路承载着站点间的数据复制、存储传输及其他通信。其带宽决定了可达到的传输速率，而距离与中间设备则会导致延迟。同步存储复制便很好地说明了这种区别：当写入操作需要远程系统发回确认时，即便链路带宽充裕，站点间的往返延迟也会直接计入写入完成时间。(equinix.com)

虚拟化与资源编排

虚拟机监视器（hypervisor 或 virtual machine monitor）负责调解对服务器处理器、内存、存储和网络接口的访问，为每个虚拟机（VM）提供虚拟硬件，使其上可以运行独立的客户操作系统。它将虚拟处理器调度到物理处理器上，维持内存隔离，并调解设备访问。裸机型虚拟机监视器直接运行在硬件之上，而宿主型实现则运行在宿主操作系统之上。这种抽象使得具有不同操作系统要求的应用程序能够共享同一台物理服务器，而无需共享客户机内核。美国国家标准与技术研究院（NIST）于 2011 年 1 月发布的《完全虚拟化技术安全指南》（Guide to Security for Full Virtualization Technologies）对这些架构进行了区分，并将虚拟机监视器描述为核心隔离边界。(nist.gov)

相比之下，容器提供操作系统层面的隔离：应用程序进程拥有相互独立的资源视图，但通常共享宿主机内核。在 Linux 上，命名空间用于隔离进程标识符和网络接口等资源，而控制组则用于统计并限制资源消耗。容器镜像打包的是应用程序及其用户空间依赖项，而非完整的客户机内核。因此，容器避免了为每个应用实例启动和维护一套独立操作系统的开销，但共享内核中的安全漏洞可能会波及多个容器。NIST 于 2017 年 9 月发布的《应用容器安全指南》（Application Container Security Guide）还探讨了在虚拟机内部运行容器的做法，将基于容器的部署与工作负载组之间的独立虚拟化边界相结合。(nvlpubs.nist.gov)

资源编排负责在服务器资源池中协调这些执行环境。资源置备将请求转换为具体操作，例如选择镜像、预留资源、创建实例、挂载存储以及连接网络接口。放置则根据可用容量与策略约束来匹配需求；资源池化并不能使物理上不兼容或已耗尽的资源变得互换通用。OpenStack 体现了这种职责划分：Nova 负责置备计算实例，Placement 跟踪资源清册及候选分配，Glance 提供镜像，Neutron 则置备网络连通性。Cinder 提供持久化虚拟块设备，其生命周期独立于具体的计算实例，从而使应用程序所分配的存储在其虚拟机被替换后仍能保留。(docs.openstack.org)

在容器编排中，Kubernetes 将 Pod（由一个或多个容器组成的集合）调度到工作节点上。CPU 和内存的请求值（request）为放置提供依据，而限制值（limit）则约束运行时的使用：CPU 限制通过节流来强制执行，而超出内存限制则可能导致因内存不足而被终止。一个 Kubernetes CPU 单位代表一个物理核心或一个虚拟核心（取决于具体节点）；因此，500m 的请求值表示半个 CPU 单位，而不是固定的处理器主频。请求值和限制值区分了用于调度承诺的容量与允许的实际消耗量。它们还有助于控制共享同一节点的应用之间的资源争用，不过它们本身并不能在租户之间建立起完全的安全隔离。(kubernetes.io)

软件定义基础设施将程序化控制扩展到了计算、存储和网络领域。计算服务通过 API 提供实例创建功能；存储服务提供独立于具体服务器的逻辑卷；虚拟交换机和覆盖网络则在物理链路之上提供逻辑连通性。这些抽象使得配置工作流能够协同多种类型的资源，而无需为每项工作负载手动配置每台设备。它们还将关键的安全边界转移到了软件层面：同一宿主机上虚拟机之间的流量可以仅停留在虚拟交换机内部，而无需经过外部物理防火墙。因此，2016 年 3 月发布的 NIST SP 800-125B 将虚拟网络分段、路径冗余、基于防火墙的流量控制以及虚拟机流量监控视为需要分别考虑的配置要点。(docs.openstack.org)

管理系统拥有超出普通工作负载的特权：根据角色的不同，它们能够创建或删除客户机、更改虚拟连通性，以及访问已存储的镜像或快照。因此，一旦该管理平面遭到攻破，攻击便可能跨越原本相互隔离的应用程序或租户边界。虚拟机监视器隔离、管理授权以及虚拟网络策略分别应对该暴露面的不同部分；健全的虚拟机边界无法弥补管理员将访问权限误授予错误租户所带来的风险。NIST 的虚拟化指南指出，限制管理访问、保护管理通信以及分离管理职责，是专门针对这一特权基础设施层的控制措施。(nvlpubs.nist.gov)

电力供应与配电

传统的供电回路始于市电电网接入点，经由变压器和开关柜，再穿过不间断电源（UPS）、配电柜或母线槽，最终通过机架配电单元送达IT设备。变压器负责降低供电电压；开关柜提供电路切换、隔离与故障保护。具体的降压级数与先后顺序因机房设计而异。机架配电系统为服务器、存储设备和网络设备供电，这些设备的电源模块将输入的交流电转换为电子元器件所需的直流电。制冷及其他机械负载同样需要电力容量，不过它们并不一定全部采用与IT负载相同的UPS供电路径。(energy.gov)

双变换在线式UPS将输入的交流电整流为直流电，再通过逆变器输出交流电供给受保护负载。当输入电源发生故障时，相连的电池组为直流母线供电，使逆变器能够不间断地持续运行。这一架构在正常市电运行期间还能起到稳压和稳频的作用。电池储能主要提供过渡支撑，而非无限期替代市电：其供电时长取决于可用储能量和所连接负载的功率需求。举例来说，若不考虑转换损耗和运行备用容量，按能量平衡计算，100 kWh的可用储能供给1 MW负载只能维持6分钟。增加电池容量可延长后备时间，但单纯提高逆变器的额定功率则无法做到这一点。(origin-edge.eaton.com)

备用发电机用于应对更长时间的停电事故。市电发生故障后，发电机启动并达到合格的电压与频率，在此期间UPS负责承担受保护负载。自动转换开关持续监测供电电源，一旦应急电源稳定，便将负载切换至发电机；当市电恢复且满足控制器设定的条件后，再将负载切回市电供电。转换开关仅负责选择供电回路，本身并不储存电能，因此无法取代UPS的过渡桥接功能。发电机支撑的运行时间受燃料储备量、设备工况以及是否能兼顾所有关键配套负荷（而非仅仅是服务器电路）等因素的制约。(eaton.com)

电力在转换与分配过程中会产生损耗。美国能源部2024年7月发布的设计指南指出，双变换在线式UPS在2023年的效率已达到95%甚至更高，而20世纪90年代这一数值仅为85%至90%左右。在95%的效率下，输出1 MW的有效功率需要UPS输入端提供约1.053 MW的电能，其中约53 kW转化为损耗。此外，变压器损耗和导线发热还会增加额外的电能消耗。电气冗余设计同样会影响负载率：多台并联UPS共同分担负载时，单台设备的运行功率往往远低于其额定功率，从而影响其转换效率。因此，装机设备容量的增加并不意味着可用有效输出或用电量也会按比例同步增加。(energy.gov)

**装机容量、运行需量与用电量代表着不同的物理量。**容量表示额定能力，有功功率通常以兆瓦（MW）为单位，视在功率通常以兆伏安（MVA）为单位；运行需量则是特定时刻实际汲取的功率。全年用电量是功率需量随时间的累积，即 $E=\int P(t)\,dt$ 。因此，假设某机房在一年365天内的平均负荷为10 MW，其年用电量即为87.6 GWh，这与其装机容量是否远高于该数值无关。在描述容量指标时，还必须明确其指的是IT负载容量、整个机房总容量，还是计入冗余设备的总容量。新增容量在土建完工后并不一定能立即通电：电网并网评估、变电站建设、输电线路扩建改造以及电气设备采购周期等都会左右并网投运的进度。国际能源署在其2025年发布的《能源与人工智能》报告中估算，电网限制可能会导致全球计划在2030年前建设的数据中心容量中有约20%延期投运；不过这属于有前提条件的预测评估，而非已发生的实际延期比例。(energy.gov)

制冷与热管理

IT设备消耗的几乎所有电能最终都会转化为热量，因此一个耗电 20 kW 的机柜大约会产生 20 kW 的热负荷。对于显热冷却，排热量遵循公式 $\dot Q=\dot m c_p\Delta T$ ，其中 $\dot m$ 为冷却剂质量流量， $c_p$ 为其比热容， $\Delta T$ 为其温升。因此，提高机柜功率就需要增加冷却剂流量、承受更大的温升，或者采用不同的制冷架构。即使整个机房的总制冷量看起来足够，集中式的高负荷也可能超出局部制冷能力；而且设备铭牌功率并不一定等同于其实际热输出。(handbook.ashrae.org)

风冷机柜通常采用面对面的冷通道与背对背的热通道交替布置。冷通道向设备进风口提供冷空气，热通道则收集排出的热空气。通过门、顶棚和隔断将其中一种气流进行物理封闭，同时用盲板封闭未使用的机架位置，从而遏制排风再循环和送风旁路现象。机房空调处理机组（CRAH）利用风机驱动回风流经冷冻水盘管，随后供给设备。冷冻水回路将热量带至冷水机组或节能器；在水冷冷水机组系统中，独立的冷却水回路进一步将热量输送至冷却塔。这些配置通过多级热交换器逐步向外传输热量，而非单纯地“制造冷气”。(energy.gov)

在室外条件允许时，利用节能技术（自然冷却）可以减少压缩机运行时间。风侧节能器引入经适当过滤的室外空气，并排出室内暖空气，但这一过程受湿度和污染物指标的限制。水侧节能器利用热交换器将热量从冷冻水回路传递至温度更低的冷却塔水回路，从而部分或完全旁通冷水机组。其可用性取决于室外气象条件以及设备所需的进水温度。因此，“自然冷却”（Free cooling）意味着减少了机械制冷做功，并不等同于零能耗——风机、水泵和控制系统仍需运转。(energy.gov)

基于液体的制冷方式可在不同节点捕获热量。机柜后门热交换器将液冷盘管置于机柜排风通道中，服务器内部仍保留风冷。芯片级直接液冷系统通过贴附在 CPU、GPU 或其他发热部件上的冷板循环冷却液；其余部件可能仍需气流冷却。浸没式系统则直接将电子设备浸泡在绝缘液体中。单相浸没在液体不沸腾的情况下换热，而两相浸没则使液体沸腾并通过冷凝其蒸汽来排热。(energy.gov) 冷却液分配单元（CDU）通常通过热交换器将设备侧冷却回路与厂务二次水隔离，并提供泵送动力、温度调节和监测功能。分集水器、软管和快换接头将冷却液分流至机柜和服务器；收集到的热量最终仍需排放至室外或其它散热汇。(handbook.ashrae.org)

环境指标限制针对的是设备进风口处的条件，而不仅是机房温控器的读数。ASHRAE 2021年指南规定，A1–A4 级机房的推荐进风温度范围为 18–27 °C；允许运行范围更宽，且取决于具体级别，它与推荐范围是有区别的。(energy.gov) 湿度控制旨在解决腐蚀、静电放电（ESD）及凝露问题。当裸露的冷却剂管道表面温度低于周围空气的露点温度时，就会产生冷凝水。ASHRAE 的《水冷服务器》（Water-Cooled Servers）指南建议，设备回路的供水温度应至少保持在机房露点温度以上 2 °C，以为传感器误差预留余量；CDU 可以独立于温度更低的厂务侧循环水来调节该供水温度。(ashrae.org)

内部冷却循环不同于排热过程中的水资源消耗。闭式设备回路反复循环同一种流体，其本身并不需要发生蒸发。然而，配套的冷却塔通过蒸发来排出热量并需要补充水；为控制溶解矿物质浓度进行的排污也会带走额外的水。干冷器在没有蒸发过程的情况下将热量排放至室外空气中，但其性能高度依赖于环境温度和所需的冷却液温度。因此，单凭“风冷服务器”或“液冷服务器”本身并不能决定整座设施的耗水量：下游的末端排热系统同样起着决定性作用。(energy.gov)

可用性、冗余与容灾

单点故障是指某个组件或依赖项发生故障时，即使其他设备仍正常运行，也会导致其支撑的服务中断。例如，两台服务器若连接到同一个配电单元（PDU），该配电单元发生故障时两台服务器都会受到波及。故障域是指可能受某一特定故障影响的资源集合：它可以是一个机架、一条配电线路、一套制冷系统或整个园区。故障隔离则负责将故障的影响限制在这些边界之内。当冗余系统具有共同的暴露面时，共模故障会打破表面上的独立性，比如水灾、共用同一个控制器或安装了同一个存在缺陷的软件更新。AWS 的故障隔离文档详细描述了如何在各可用区之间实现发电机与制冷设备的物理隔离，以及通过分批交错部署软件来降低相关性故障的风险。(docs.aws.amazon.com)

冗余标记法用于描述容量相对于实际负载的关系。N 表示满足设计负载所需的基准容量；N+1 则是在此要求之上额外增加一个容量组件。举例来说，若某设施需要四台额定容量均为 250 kW 的不间断电源（UPS）模块来支持 1 MW 负载，那么配置五台模块即可提供 N+1 容量：此时即使一台模块出现故障，其余四台仍能继续承担全部负载。2N 则提供两套完整的容量系统，每套系统均能独立承担全部负载。这些配置代表了不同的保护级别，而非简单的备用设备数量叠加。N+1 模块级冗余并不意味着下游的开关柜或配电路径也具备双重冗余，并且如果负荷需求增长超出了剩余模块的承载上限，原有的冗余保护就会失效。(product-help.schneider-electric.com)

设备冗余不同于在线维护能力与容错能力。在线维护是指可以在不中断 IT 运行的前提下，对任意所需的容量或配电组件进行主动隔离以开展维护。容错则进一步涵盖了设计规范范围内的突发故障，确保这些故障不会导致受保护的 IT 负载发生中断。如果检修一根共用管道必须关停所有水泵，那么即使多配一台水泵也无法使制冷系统具备在线维护能力；同理，若电气故障会沿着公共连接通道扩散，仅增加重复的电气设备也无法实现故障隔离。因此，Uptime Institute 依据系统成效与拓扑架构而非单纯的组件数量来进行等级评定：无论是 N+1 还是 2N 架构，都可以设计出具备在线维护能力的系统。(journal.uptimeinstitute.com)

场地可用性关注的是基础设施服务（尤其是供电和制冷）的持续性；应用可用性关注的则是用户能否成功访问并使用正常运行的服务。由于数据库故障、网络依赖中断或软件组件不可用，即便数据中心大楼完好无损，应用程序也可能彻底瘫痪。相反，采用跨独立场地分布式部署的应用，在单个场地瘫痪时仍能继续为用户提供服务。故障转移负责将计算处理或网络流量切换至存活资源，但其有效性取决于故障检测的准确性、数据的可访问性、存活资源的充裕程度以及依赖服务的正常运转。AWS 公布的管理实践清晰体现了这一区别：它既说明了基础设施层面的冗余，又阐明了如何将核心应用分布于多个站点，并保留足够的富余容量以吸收单站点故障带来的负荷。(docs.aws.amazon.com)

容灾致力于应对超出常规业务连续性保障机制范畴的严重中断。备份用于保留可恢复的历史状态数据；数据复制用于为动态变化的数据维护额外的副本；故障转移则用于激活备用处理环境。数据复制能够缩短中断时间并减少更新丢失，但同时也可能会同步复写误删除或逻辑错误。因此，历史备份或时间点恢复可以解决仅凭当前数据副本无法化解的问题。此外，灾难恢复所依赖的不仅是复制好的用户数据，还需要应用程序代码、系统配置以及配套基础设施。AWS 的容灾文档根据恢复特性，将容灾方案明确划分为备份与还原、部分配置的温备环境以及全功能运行的多站点架构等不同模式。(docs.aws.amazon.com)

有两项指标用于区分恢复速度与数据丢失量。**恢复时间目标（RTO）**规定了系统恢复所需的目标时间跨度；**恢复点目标（RPO）**规定了数据必须恢复到的时间点，通常体现为可容忍的最大数据丢失时间跨度。例如，某项服务的 RTO 为两小时、RPO 为 15 分钟，这意味着恢复服务运行与找回最新数据各自有着独立的指标要求：快速重启服务并不能弥补丢失数小时业务记录所造成的损失。玛丽安·斯旺森（Marianne Swanson）及其同事于 2010 年发布的 NIST《联邦信息系统应急规划指南》将这些目标纳入了业务影响分析与恢复规划框架，并要求通过实战演练和恢复测试来评估既定方案的实际执行能力。(csrc.nist.gov)

标准、等级评定与认证

Uptime Institute 的 Tier 等级分类体系描述了场地基础设施能力的四个级别，每个级别都在前一级别的要求基础上层层递进。**Tier I——基本容量（Basic Capacity）**提供专用的 IT 空间、不间断电源（UPS）、持续制冷系统，以及用于应对长时间市电停电的发电机组。**Tier II——冗余容量组件（Redundant Capacity Components）**增加了备用电力和制冷组件（如水泵或 UPS 模块），但并未在整个配电与输送系统中实现同步可维护性。**Tier III——可同步维护（Concurrently Maintainable）**要求保障 IT 环境所需的每一个容量组件和分配输送元件，都可以在不中断 IT 运行的前提下退出运行以进行计划性维护。**Tier IV——容错（Fault Tolerant）**进一步具备抵御单处设备故障或分配路径中断而不影响系统运行的能力。这些均属于性能结果指标，而非强制性的设备配置配方：单凭冗余组件的数量本身并不能确立相应的 Tier 等级。(journal.uptimeinstitute.com)

由电信工业协会（TIA）制定的 ANSI/TIA-942 所涵盖的物理基础设施要求，远比其标题《数据中心电信基础设施标准》（Telecommunications Infrastructure Standard for Data Centers）所体现的更为宽泛。其规范范围包括建筑、电信、电气、制冷、消防、物理安防、安全以及监控系统。2024 年 5 月编制并于 2024 年 5 月 9 日发布的 C 版（Revision C）就体现了这一范围的最新演进。修订内容包括纳入边缘数据中心的相关要求、认可新增线缆介质与连接要求、修订楼板荷载与机柜最小宽度规定，以及调整与选址和空间相关的附录。该标准普遍适用于企业级、主机托管和超大规模设施，而非按不同的产权归属模式分别制定标准。(tiaonline.org)

TIA 设立的四个等级分别为：Rated-1——基本场地基础设施（Basic Site Infrastructure）、Rated-2——冗余容量组件场地基础设施（Redundant Capacity Component Site Infrastructure）、**Rated-3——可同步维护场地基础设施（Concurrently Maintainable Site Infrastructure）**以及 Rated-4——容错场地基础设施（Fault Tolerant Site Infrastructure）。尽管其名称与 Uptime 的类别相似，但 TIA 等级与 Uptime Tier 属于完全独立的分类体系，具有不同的评估准则和认证机制；获得其中一种评级并不等同于获得了另一体系的认证。TIA 体系采用经 TIA 授权的认证机构开展工作，而 Uptime Institute 则直接依据其自身的 Tier 标准对设施进行认证。标准规定技术要求；等级评定界定被评估的性能类别；认证则记录通过相应评估程序确立的合规事实。单纯的数字标识或声称设施“按某等级设计”，都不能替代正式的评估认证。(tiaonline.org)

认证机制还对具体审查的内容进行了区分。Uptime 的**设计文档 Tier 认证（Tier Certification of Design Documents）评估的是文件化的规划设计；而建造设施 Tier 认证（Tier Certification of Constructed Facility）则实地审查已安装的基础设施，并包含对所需规定功能的现场验证。例如，Tier III 现场验证必须证明在每一种要求的维护配置状态下，基准电力和制冷容量均保持可用——而绝非仅仅停留在图纸上标注了备用设备。其后续的运营可持续性 Tier 认证（Tier Certification of Operational Sustainability）**则进一步评估管理实践、人员配置、培训机制、运行工况以及维保流程。TIA 同样将基于文档的设计认证与包含现场审查的设施认证区分开来。因此，这些自愿性评估体系在设施生命周期的不同阶段提供了性质各异的佐证：设计合规性、实际落地的硬件能力与运营实践之间存在关联，但结论绝不可相互混淆替代。(uptimeinstitute.com)

场地设施等级分类并不等同于对应用层业务运行时间的绝对预测。Uptime Institute 已于 2009 年从其 Tier 标准中删除了关于“每年预期停机时间”的表述，其拓扑标准也并未向各 Tier 等级挂钩任何具体的可用性预测指标。因此，将某一 Tier 等级直接换算为固定的年度停机容限配额，是对其真实含义的曲解。该等级分类针对的是场地物理基础设施；而软件配置、IT 系统架构和日常运维实践还会引入额外的故障诱因。即便是拓扑结构完全达标的基础设施，也必须得到得当的操作与维保，这正是运营能力评估必须独立于图纸审核或施工验收的原因所在。(journal.uptimeinstitute.com)

物理安全、网络安全与数据保护

物理防护采用层层递进的访问边界，而非将进入建筑物的许可等同于接触所有服务器的权限。周界围栏、门卫出入口、入侵检测与监控系统控制对场地的访问；经过身份认证的门禁随后限制人员进入设备区域。权限可按角色、地点和有效时间进行限制，对访客和承包商则进行单独授权。例如，AWS 记录了要求具备业务合理性的限时访问申请、限制仅可进入批准区域、保留访问日志，并在机房出入口实现摄像头全覆盖。这些记录通过将个人授权与记录的进入事件关联起来，为调查提供支持，但它们并不能替代预防性屏障。(aws.amazon.com)

网络安全还取决于对管理平面的保护，管理平面即管理员用于配置主机、网络、存储和虚拟机的接口。这些接口比普通应用程序连接拥有更高的权限。NIST（美国国家标准与技术研究院）于 2011 年 1 月发布的《完全虚拟化技术安全指南》（Guide to Security for Full Virtualization Technologies，作者包括 Karen Scarfone、Murugiah Souppaya 和 Paul Hoffman）阐述了受限的管理访问权限、专用管理网络以及受保护的管理通信。防火墙规则限制了哪些系统可以访问管理接口，而基于角色的权限机制则区分了查看权限与配置权限。虚拟机监控程序（Hypervisor）与客户机系统（Guest System）的补丁修复分别针对不同的软件层；更新其中一方并不会自动更新另一方。一旦虚拟机监控程序遭到入侵，后果将尤为严重，因为正是它在协调并调解多个虚拟机共享的资源访问。(csrc.nist.gov)

租户隔离既需要在外部网络边界设立控制措施，也需要在共享硬件内部进行控制。虚拟机监控程序负责隔离各虚拟机的执行过程，并协调对处理器、内存、存储和网络资源的访问。NIST 于 2018 年 6 月发布的基于服务器的虚拟机监控程序平台指南，将运行时隔离与保密通信明确列为虚拟机监控程序的重要职责。网络分段与流量过滤则进一步限制了工作负载之间的通信。监控工作还必须考虑到留在主机内部的流量：通过虚拟交换机连接的两个虚拟机可以在不经过物理网络传感器的情况下进行通信。因此，在需要检查此类流量的场景下，虚拟交换机监控或其他合理部署的控制机制必不可少。(csrc.nist.gov)

设施安全与应用数据保护具有不同的责任边界。在云计算中，AWS 的责任共担模型规定服务商负责物理设施、硬件及底层虚拟化基础设施，而基础设施即服务（IaaS）客户则负责管理客户操作系统、应用软件以及相关的访问和防火墙设置。托管服务将更多运维任务转移给服务商，因此责任边界会随服务类型的不同而有所变化。加密技术可以保护传输中和静态存储的数据，但其配置、密钥管理与访问权限仍属各自独立的控制措施。仅靠加密存储服务本身，并不能确保每个获准访问的用户或应用程序都有权获取明文。(aws.amazon.com)

承载数据的设备在维修、转移和报废过程中均应处于安全边界之内。资产标识、受控操作以及有据可查的移交过程构成了监管链；数据清除记录将每台设备与执行的操作及其结果关联起来。NIST 于 2025 年 9 月发布的 SP 800-88 第 2 版将数据处置细分为：清除（clear），用于防止通过常规接口恢复数据；净化（purge），在可能保留介质重复使用价值的同时，使利用先进实验室技术恢复数据变得不可行；以及销毁（destroy），在净化的基础上进一步使介质完全无法用于存储。在带有预留单元和磨损均衡机制的闪存设备中，普通的覆写操作无法可靠地覆盖每个曾经使用过的物理位置。相比之下，加密擦除技术通过清除恢复加密数据所需的密钥来达到净化目的，但前提需满足加密覆盖范围和密钥处置的相关条件。校验（verification）用于检查操作是否成功完成；确认（validation）则用于判定其结果是否满足该数据的保密性要求。(nvlpubs.nist.gov)

运营、监控与人员配置

数据中心的运营职责由多个相互依赖的团队共同分担。设施工程师负责运营和维护配电、备用电源、制冷系统及楼宇控制系统；IT 运维人员负责管理服务器与存储设备的运行状况、操作系统以及工作负载的执行；网络人员维护交换、路由、网络连通性及网络配置；安防人员负责监督物理出入与视频监控；现场技术人员则负责安装设备、更换故障组件、检查线缆，并执行远程操作人员请求的现场物理任务。这些职责边界因机构而异，但团队间的紧密协同至关重要：例如，更换一台服务器需要确认正确的资产、获得操作授权、断开相应连接并在完成后验证服务是否恢复。谷歌（Google）曾指出，其监控和控制范围涵盖服务器、存储、网络、配电、机械制冷与安全，现场工程团队与运维人员紧密协作。(ibm.com)

监控系统将物理环境状态与设备及服务的运行状况关联起来。楼宇管理系统监控机械设备与环境控制；电气监控系统跟踪供电状态、设备负荷以及电力系统告警；IT 管理工具则观察服务器健康状况、存储系统、网络性能及应用程序表现。数据中心基础设施管理（DCIM）将设备资产清单、机架物理位置与电力、制冷、空间占用及设备健康信息结合，打通了上述各个领域。这种统合视角有助于甄别具体问题，例如区分单一硬件故障还是影响多台机器的共享基础设施故障。马修·哈贝尔（Matthew Hubbell）及其同事在 2015 年发表的一篇论文中介绍了一套监控实践方案，该方案整合了大约 5,000 个环境传感器和超过 3,500 个 IT 数据点，使运维人员能在 100 多英里外的指挥中心实现集中可视化。这种集成是对设施控制与 IT 监控功能的有效补充，而非将两者合二为一。(ibm.com)

预防性维护将设备规范转化为定期的巡检、保养、测试以及完成记录。Uptime Institute 的运营准则要求维护流程必须完全形成书面规程，而不是依赖技术人员的个人记忆。文档体系统筹规范了用于常规活动的标准作业程序、针对特定介入操作的操作方法规程（MOP），以及用于异常情况的应急操作规程。操作方法规程明确了改变关键设备状态的一系列操作步骤；该规程在变更控制体系下运作，后者负责协调授权、操作时间窗口、受影响系统及验证流程。在维护操作会暂时打破冗余配置时，这一点尤为关键：若缺少规范，一项原本常规的介入操作可能会使剩余设备暴露在常规配置下本可承受的单点故障风险之中。(uptimeinstitute.com)

当常规运营受到冲击时，事件响应机制能够引入明确的协调指挥。谷歌公开的事件管理指南将指挥、操作响应和对外沟通三个角色明确分离，确保技术层面的故障恢复不依赖于每个响应人员各自独立做出的优先级判断。恢复完成后，事后复盘会记录事件影响、时间线、诱发因素及整改措施，其中不仅包括更换故障组件，还涵盖改进故障检测机制与团队协调流程。谷歌公开的复盘示例包括 2014 年 8 月 11 日的一起事件：一套存在缺陷的设备退役自动化脚本本应清除单个机架上的磁盘，却错误选中并清除了某一卫星环境中的全部机器。该案例生动说明了运维工具如何放大操作失误的影响范围，也解释了为何事后复盘必须同时审查自动化机制、安全防护措施以及个人操作行为。(sre.google)

人员配置水平决定了监控、维护和应急预案能否真正落地执行。工作覆盖范围包括日常运营、计划性维护以及突发干预；随着站点复杂度和可用性目标的提升，人员培训要求也水涨船高。Uptime Institute 的 2024 年韧性调查显示，在 418 名受访者中，有 39% 表示其所在机构在过去三年内发生过涉及人为错误的重大、严重或特大 IT 服务中断。在指出此类中断原因的受访者中，48% 选择了“未遵守操作规程”，45% 选择了“流程或规程本身不正确”（受访者最多可选三项原因）。这些数据属于问卷统计结果，而非全部故障的绝对发生比例，但它们清楚反映出两项运营短板：工作流程界定不充分，以及未能正确执行已明确制定的规程。(journal.uptimeinstitute.com)

容量规划、建设与资产全生命周期

容量规划将预测的工作负载转化为随时间变化的基础设施需求。交易率、并发用户数、存储增长和处理时限确立了计算需求；工作负载实测和硬件基准测试则为处理器、内存、存储吞吐量及网络需求提供依据。由此确定的设备配置决定了机柜占用情况，以及设施必须支撑的电力和制冷负荷。规划工作会区分初始部署、预期增长与终期容量，而非将建筑的最大容量视为即时需求。施耐德电气于 2011 年发布的规划框架明确区分了初始 IT 负荷、最小和最大终期负荷以及预期的扩容周期。

这些需求在各物理系统之间必须保持一致：如果配电线路、制冷供给或网络连接已耗尽，闲置的机位并不能代表可用容量。举例而言，100 台机柜各以 10 kW 运行，在计入制冷设备和电气损耗之前就会产生 1 MW 的 IT 负荷；若将相同的负荷集中到 25 台机柜中，平均每台机柜的功率将升至 40 kW，而总排热需求并未减少。因此，容量规划既要明确总负荷，也要明确其空间分布。美国能源部 2024 年 7 月的设计指南强调，IT 设备的选择会影响支撑系统的规模，更高密度的设备可能需要直接液冷，而非仅仅增加机房占地面积。

项目开发流程包括场地获取、市政可用性确认、概念设计、施工图深化设计、采购、建设、测试及运营移交。调试始于需求与设计审查阶段，而非仅仅在施工完成后才开展：其目的在于验证已安装的设备和各交互系统是否达到预期性能。测试从单一组件逐步推进至协同运行，在生产设备完全部署之前，利用假负载模拟用电需求和发热量。故障模拟可以检验供电、制冷与控制系统如何协同响应。移交内容包括测试记录、运行文档、人员培训以及遗留缺陷的整改。分期建设可根据需求增长逐步将后续机房或基础设施模块投入使用；每次扩建都需要测试其与既有运行设施之间的接口。

建筑物及固定配套基础设施通常需要承载数代 IT 设备。因此，硬件更替不仅是一项更换任务，也是一个兼容性难题：一个总电力容量充足的机房，可能缺乏适合更高密度设备部署的机柜级配电、气流组织、管道或排热配置。改造工程可能需要在相邻设备保持运行的同时，重新调整机柜布局、更换配电设备或引入冷却液分配系统。更换周期并非绝对的技术寿命极限。2022 年 7 月，微软重新评估了其服务器和网络设备，以软件效率提升和技术进步为由，自 2023 财年起将其会计预估使用年限从 4 年延长至 6 年；这并不等同于确立了 6 年的物理故障阈值。

资产管理贯穿设备首次部署之后的完整生命周期。资产清单记录将设备的标识、位置、配置和服务状态与后续的移交、测试、维修和报废关联起来。仍可用的设备可以重新部署，而从退役服务器中拆解回收的组件可用于机群其他设备的维修。微软 2025 年 4 月发布的循环硬件白皮书描述了在运输、接收、测试、仓储和处置过程中追踪组件的做法，经再认证的零部件会重返现役服务。其循环中心（Circular Centers，于 2020 年率先在阿姆斯特丹建立）据报告在 2024 年支持了超过 320 万件组件的再利用。最终退役阶段将剩余设备和材料导入再利用或回收利用渠道，并通过外部回收合作伙伴保持全程可追溯性；对承载数据的存储介质的安全管控则构成了一项单独的安全合规要求。

经济特性与基础设施供应链

数据中心投资将用于土地、建筑物、机电基础设施和IT设备的资本性支出，与经常性运营支出区分开来。设施预算包括建筑施工、变压器、配电开关柜、备用电源、制冷站及安装工程；IT预算则涵盖服务器、存储设备与网络设备。运营成本包括电力、人员薪资、维护合同、备件更换、网络连通性及软件订阅。这些支出的更新周期和成本驱动因素各不相同：建筑物落成后，依然需要定期更换服务器并维护配套机电系统。IBM研究院于2009年发表的一项研究将建筑施工、电力与制冷基础设施、服务器采购、电力消耗以及服务器管理列为算力成本的五大核心组成部分。(research.ibm.com)

资源利用率决定了装机容量成本由多少实际生产工作共同分摊。针对偶尔出现的峰值需求采购设备，会导致资本在业务低谷期闲置；而将具有不同需求模式的工作负载整合在一起，则能把这笔成本分摊到更多的业务活动中。规模经济也源于大批量采购硬件，以及将采购、工程和运维专业能力复用到更庞大的设备基数上。这些效应彼此独立：规模庞大的设施虽能获得批量采购折扣，但其内部仍可能存在利用率低下的服务器。冗余设计又引入了另一层经济维度的考量，因为备用设备、双路连接和容灾恢复能力均需持续投资与维护，却并不必然提升日常的生产吞吐量。因此，经济性评估既取决于工作负载的利用率，也取决于所满足的可用性等级要求。(d0.awsstatic.com)

电力将运营支出与设备负荷及设施能效直接挂钩。计算设备以及配套的制冷和电气系统都会消耗电能，因此无法仅凭服务器的标称功率来推算总电费。以理论测算而非实测数据为例，一座持续用电负荷为 10 MW 的设施在一年 365 天内将耗电 8760 万千瓦时（kWh）；若假定固定电价为每千瓦时 0.10 美元，其电费支出将达 876 万美元。这还不包括需量电费及其他计费组成部分。人员与维护费用则是独立的成本：即便应用需求下降，保持设施连续运转依然需要不间断的监控、技术保障、保养与维修。(energy.gov)

不同的资产权属模式是对这些义务与成本的重新分配，而非将其消除。自建自营数据中心的企业需自行出资并管理建筑基础设施及IT设备。在传统主机托管模式下，服务商提供机房物理空间及配套基础设施，客户则拥有并管理自身的服务器、存储和网络设备；增值管理服务可按需另行签约。托管主机服务则将专用硬件的提供和特定的运维管理任务转移给了服务提供商。在云计算模式下，客户直接采购计算服务，无需建造底层设施，云服务商则通过服务收费来收回基础设施建设和运营成本。这些合作模式改变了客户的前期资本投入、经常性付款结构以及所承担的责任，但并未让底层物理资源的成本凭空消失。(ibm.com)

扩建不仅取决于算力需求，还依赖于供应链与建设周期。服务器必须在具备运转正常的建筑物、制冷系统、配电设施并完成市政电网受电接入后，方可提供服务。设备的供货周期可能会制约这一流程：国际能源署（IEA）在《世界能源投资2025》报告中指出，输电电缆的采购周期为2至3年，大型电力变压器更长达4年之久。这些只是电力系统关键设备的供货交期，并不代表数据中心所有组件的普遍交付周期。此外，IEA在2025年《能源与人工智能》专题分析中估算，电网限制可能会导致全球计划在2030年前建成的约20%数据中心容量面临延期。该数据反映的是预期的并网风险，而非已实际发生的项目取消率；旺盛的客户需求与充裕的可用资金本身，并不能单方面决定新增容量何时能够正式投入运营。(iea.blob.core.windows.net)

能源、水资源与环境核算

电能利用效率（PUE）用于衡量在同一报告期内，整个数据中心设施总能耗相对于 IT 设备能耗的比例：

\mathrm{PUE}=\frac{E_{\mathrm{facility}}}{E_{\mathrm{IT}}}.

分子包括设施边界内的 IT 设备、制冷系统、电力转换与分配损耗以及其他辅助负载；分母则涵盖服务器、存储和网络设备。进行对比时，必须保证电表安装位置、报告周期以及对共享基础设施的处理方式保持一致。例如，某设施年总耗电量假设为 12 GWh，其中 IT 设备消耗 10 GWh，则其 PUE 为 1.2。PUE 并不能衡量有效计算产出：它的分母是能量，而非已完成的交易量或科学计算任务量。因此，还需要配合评估设备利用率以及单位能量计算产出的辅助指标。(energy.gov)

国际能源署在其 2025 年 4 月发布的《能源与人工智能》报告中估计，数据中心在 2024 年共消耗约 415 TWh 的电力，约占全球电力消费量的 1.5%。该数据是对历史能耗的估算，而非全球范围内的完整抄表普查。该报告还在基准情景下预测，2030 年这一数字将达到约 945 TWh。该预测基于对设备部署、利用率、效率和未来需求的一系列假设，并非既定事实或无条件预测。全球总数也掩盖了地域集中的特征：报告估计，2024 年美国占全球数据中心耗电量的 45%，中国占 25%，欧洲占 15%。(iea.org)

水资源核算严格区分取水量（从水源抽取的体积）与消耗量（因蒸发等过程而未返回水源的部分）。冷却塔的水分蒸发属于水消耗，而排出的水通常不直接计入消耗量。相关报告必须明确其“用水量”具体指代哪一项。基于场址的水利用效率（WUE）定义为设施年用水量除以 IT 设备年能耗，通常以升/千瓦时（L/kWh）为单位。若将核算边界扩展到源头端，则还需计入发电过程所消耗的水资源。因此，即便现场用水量较低，也不代表总体水足迹必然较低；与发电相关的环境影响发生在设施外部，完全取决于其电力供应来源。(usgs.gov)

碳足迹清单同样取决于组织边界与生命周期边界的划定。运营期排放包括现场燃料燃烧，以及外购电力所产生的间接排放；隐含碳排放则来自建筑材料生产和设备制造阶段。根据《温室气体核算体系》2015 年发布的《范围 2 指南》，基于位置的电力核算方法采用所在地理区域的平均排放因子，而基于市场的核算方法则反映符合资质的合同机制，如绿电合同和能源属性凭证。两者解决的问题截然不同：合同层面的可再生能源声明，并不能等同于各小时内实际向设施供电的物理发电量测算。碳利用效率（CUE）表达了运营排放相对于 IT 能耗的比值，但其本身并不反映隐含碳排放的影响。(ghgprotocol.org)

制冷与余热回收在这些环境核算指标之间引入了权衡。蒸发散热会消耗水，但可以降低电力需求；干式冷却避免了水蒸发，但其能效表现高度取决于当地气候和运行工况。废热可用于满足附近的供暖负荷，较高的冷却剂回水温度有助于提高直接利用的潜力。采用热泵可以将热量提升至更实用的温度，但这会增加额外的电力消耗。美国能源部 2024 年版设计指南将回收的能量与 PUE 分开处理，采用能源再利用效率（ERE）指标，而不是直接从传统 PUE 分子中扣除输出的热量。(energy.gov)

生命周期评价还将硬件制造、再利用和报废处置纳入考量，而不仅仅将环境表现等同于运行阶段的效率。例如，微软在 2025 年 4 月发布的循环硬件白皮书中介绍，退役的服务器和零部件会通过循环中心分类流转，用于内部再利用、进入其他电子产品供应链，或用于技术培训项目。该方案将这些路径与材料级回收区分开来，并将拆解零部件再利用开展的维修纳入跟踪体系。此类核算使得退役硬件的最终去向与持续使用情况得以显现，与电力和水耗指标共同构成了全面的环境档案。(datacenters.microsoft.com)

人工智能与高性能计算基础设施

分布式机器学习训练通过反复的计算与通信将加速器紧密耦合在一起。在同步数据并行训练中，各个工作节点处理批次（batch）的不同分片，并在更新各自的模型副本前合并参数梯度；例如，PyTorch 的 DistributedDataParallel 会将梯度划分为若干分桶，使全归约（all-reduce）通信与反向计算重叠进行。因此，单凭加速器数量并不能决定训练速度：通信延迟可能导致原本可用的处理器陷入等待。高度耦合的作业还要求所有参与进程协同运行，因此需要进行协同资源分配，而非将每个加速器视为独立调度的服务器。这些需求将 AI 训练与并行计算中的调度及通信问题紧密联系在一起。(docs.pytorch.org)

神经网络推理执行的是已训练完成的模型，但其对基础设施的需求取决于模型的提供方式。对于自回归大语言模型，预填充（prefill）阶段处理输入的提示词，而解码（decoding）阶段则逐一生成后续的输出词元（token）。长预填充通常属于计算密集型任务；而解码阶段则往往受限于内存带宽，以及模型权重与注意力键值缓存（KV cache）所占用的存储容量。因此，交互式服务需要兼顾并发请求、内存分配和响应延迟，而非单纯缩短单个训练作业的完成时间。NVIDIA Dynamo 展示了一种将预填充和解码分别交由不同加速器池处理的方案，并在两池之间传输注意力键值缓存。这种方法本身会产生网络流量，且分离加速器池并非在所有场景下都具备优势：在低并发、传输开销大或各池利用率不均的情况下，将两阶段合并执行可能更为有利。(docs.nvidia.com)

加速器集群将 GPU 或其他专用处理器与互连架构及存储系统相结合，以维持其协同运行。例如，NVIDIA DGX GB200 参考架构将 72 块 GPU 部署在单个机架级 NVLink 域内，并采用 InfiniBand 实现节点与机架之间的通信。其管理架构将计算网络与专用存储网络进行了区分。共享存储用于提供数据集和检查点（checkpoint），而本地 NVMe 设备则可用于缓存或暂存数据，以减少重复的网络读取。保存检查点带来的瓶颈与读取数据集不同：快照大小可达数太字节（TB），且同步写入检查点会暂停训练进程。因此，总存储容量、读取吞吐量、检查点写入性能以及互连带宽，都是限制加速器有效利用率的独立约束因素。(docs.nvidia.com)

这类设备的高密度集约化部署，使机房设施规划的最小单元从单个服务器转变为整套机架及其配套基础设施。在 2024 年 10 月发布的 GB200 NVL72 设计说明中，NVIDIA 明确单机架散热需求为 120 kW，并采用直接液冷技术；而 DGX 实现方案则将液冷与辅助风冷相结合。这属于特定产品的参数示例，而非通用的 AI 机架额定指标。此类部署要求在机架所在具体位置提供相应的配电与排热能力，而不仅是在建筑物其他区域留有足够的富余容量。因此，该参考架构对计算机架、电源机架、散热系统、网络以及机房管理系统的集成进行了统筹规划。在部署规划中，必须综合考量这些相互关联的系统，而不能简单假定只需将现有机架位置上的低密度服务器替换为新型加速器即可。(developer.nvidia.com)

未来的电力需求同时取决于工作负载的增长速度以及完成单项任务所需的资源量。因此，硬件与软件效率、利用率、模型普及程度，以及部署的地域与节奏，都属于情景假设，而非确切的定论。国际能源署（IEA）在 2025 年发布的《能源与人工智能》（Energy and AI）分析报告充分展示了这种敏感性：其对 2035 年全部数据中心（而非仅限 AI）用电量的预测，从“逆风情景”（Headwinds Case）下的约 700 TWh 到“腾飞情景”（Lift-Off Case）下的 1,700 TWh 以上不等；其“高效情景”（High Efficiency Case）在满足与基准情景相同服务需求的前提下，用电量约为 970 TWh。这些差异反映了对效率、需求、供应链和部署约束条件的不同假设，而非对未来消耗量的测量。(iea.org)

参考来源

February 14: John Mauchly and J. Presper Eckert Unveil The ENIACcomputerhistory.org
What Is a Data Center? | IBMibm.com
The S/360: A turning point in mainframe historyibm.com
The IBM System/360 | IBMibm.com
Time-sharing | IBMibm.com
20 Years of Being Customer-Inspired and Customer-Drivenblog.equinix.com
IBM: VM 50th Anniversaryibm.com
VMware Celebrates Seven Years of Continual Innovation and Executionnews.broadcom.com
Amazon-Web-Services-Launchespress.aboutamazon.com
Amazon EC2 Beta | AWS News Blogaws.amazon.com
Final Version of NIST Cloud Computing Definition Publishednist.gov
What is Colocation? Data Center Comparison & FAQs | Equinixequinix.com
Colocation Products and Services | Equinix Product Documentationdocs.equinix.com
Shared Responsibility Model - Amazon Web Services (AWS)aws.amazon.com
What is AWS Outposts? - AWS Outpostsdocs.aws.amazon.com
What is a hyperscale data center? | IBMibm.com
Hyperscale vs Colocation Data Centers | IBMibm.com
OLAP vs. OLTP: What’s the Difference? | IBMibm.com
Use Amazon CloudFront Origin Shield - Amazon CloudFrontdocs.aws.amazon.com
Caching and availability - Amazon CloudFrontdocs.aws.amazon.com
What is High-Performance Computing (HPC)? - HPC Explained - AWSaws.amazon.com
Scenarios - High Performance Computing Lensdocs.aws.amazon.com
Best Practices Guide for Energy-Efficient Data Center Designenergy.gov
Cooling Water Efficiency Opportunities for Federal Data Centersenergy.gov
AWS Regions and Availability Zones - AWS Regions and Availability Zonesdocs.aws.amazon.com
AI and energy security – Energy and AI – Analysis - IEAiea.org
Eemshaven, Netherlands – Google Data Center Locationdatacenters.google
Site Selection Considerations for Edge Data Centerstiaonline.org
Availability Zones - AWS Fault Isolation Boundariesdocs.aws.amazon.com
Energy demand from AI – Energy and AI – Analysis - IEAiea.org
Executive summary – Energy and AI – Analysis - IEAiea.org
TIA-942tiaonline.org
NIH Sustainable Data Center Design Guidewbdg.org
Cooling recommendations for the roomibm.com
Model 7965-S42 water cooling manifold (Feature codes ECR3 and ECR4)ibm.com
PowerEdge R760dell.com
In-band or out-of-band: Advantages of iDRAC and iSM compared to OMSAdownloads.dell.com
Systems managementi.dell.com
CUDA Programming Guidedocs.nvidia.com
2. Programming Model — CUDA Programming Guidedocs.nvidia.com
NVIDIA DGX H100 — Datasheetnvidia.com
What Is Data Storage?ibm.com
What Is a Storage Area Network (SAN)?ibm.com
Object vs. File vs. Block Storage: What’s the Difference?ibm.com
What Is File Storage?ibm.com
Cloud Object Storage as a Service: IBM Cloud Object Storage from Theory to Practiceredbooks.ibm.com
SDN and its Role in Automating & Scaling in the Data Center - Ciscocisco.com
Cisco Data Center Infrastructure 2.5 Design Guide - Data Center Architecture Overviewcisco.com
Enterprise Networks Structured Cabling | CommScopecommscope.com
Fiber Cable Assemblies for Data Centers | CommScopecommscope.com
Cisco Massively Scalable Data Center Network Fabric Design and Operation White Papercisco.com
Cross Connect | Equinix Product Documentationdocs.equinix.com
Internet Exchange | Equinix Product Documentationdocs.equinix.com
Internet Exchange FAQs | Equinix Product Documentationdocs.equinix.com
Physical Interconnection | Equinixequinix.com
Data Center Interconnect Design Guide for Virtualized Workload Mobility with Cisco, EMC, and VMware - Cisco Virtualized Workload Mobility Introductioncisco.com
Guide to Security for Full Virtualization Technologiesnist.gov
NIST Special Publication 800-125, Guide to Security for Full Virtualization Technologiesnvlpubs.nist.gov
Application Container Security Guidenvlpubs.nist.gov
OpenStack Compute (nova)docs.openstack.org
Nova System Architecturedocs.openstack.org
Scheduling, Preemption and Evictionkubernetes.io
Resource Management for Pods and Containerskubernetes.io
Compute service architecturedocs.openstack.org
Secure Virtual Network Configuration for Virtual Machine (VM) Protectionnvlpubs.nist.gov
Best Practices Guide for Energy-Efficient Data Center Designenergy.gov
UPS Fundamentals & FAQs | How to choose the right backup power solutionorigin-edge.eaton.com
Automatic transfer switches (ATS) fundamentals | Eatoneaton.com
CHAPTER 20. DATA CENTERS AND TELECOMMUNICATION FACILITIEShandbook.ashrae.org
Water-Cooled Servers Common Designs, Components, and Processesashrae.org
REL 10. How do you use fault isolation to protect your workload?docs.aws.amazon.com
AWS Fault Isolation Boundariesdocs.aws.amazon.com
UPS system redundancy typesproduct-help.schneider-electric.com
Myths and Misconceptions Regarding the Uptime Institute’s Tier Systemjournal.uptimeinstitute.com
AWS Fault Isolation Boundariesdocs.aws.amazon.com
Data Center Controlsaws.amazon.com
Disaster recovery options in the clouddocs.aws.amazon.com
Recovery Point Objective - Glossarycsrc.nist.gov
Recovery Time Objective - Glossarycsrc.nist.gov
SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systemscsrc.nist.gov
Explaining the Uptime Institute’s Tier Classification System (April 2021 Update)journal.uptimeinstitute.com
TIA Unveils Revision C of the Global Data Center Infrastructure Standardtiaonline.org
Telecommunications Industry Association 942 Certifications & Ratingstiaonline.org
ANSI/TIA-942 Audit Servicestiaonline.org
Uptime Institute Publications — Tier Certificationuptimeinstitute.com
Tier Certification for Modular and Phased Constructionjournal.uptimeinstitute.com
Tier Certification Operational Sustainabilityuptimeinstitute.com
AWS Data Centersaws.amazon.com
SP 800-125, Guide to Security for Full Virtualization Technologiescsrc.nist.gov
NIST Special Publication 800-125, Guide to Security for Full Virtualization Technologiesnvlpubs.nist.gov
SP 800-125A Rev. 1, Security Recommendations for Server-based Hypervisor Platformscsrc.nist.gov
Amazon Web Services: Risk and Compliance - AWS Whitepaperdocs.aws.amazon.com
Guidelines for Media Sanitizationnvlpubs.nist.gov
What is Data Center Management? | IBMibm.com
Data Center Facilities Technician, Controls — Google Careersgoogle.com
Advancing security – Google Data Centersdatacenters.google
Google shares data center security and design best practicescloud.google.com
IBM Control Desk documentationibm.com
Big Data Strategies for Data Center Infrastructure Management Using a 3D Gaming Platformarxiv.org
Data Center Management and Operations Criteria - Uptime Instituteuptimeinstitute.com
The Making of a Good Method of Procedurejournal.uptimeinstitute.com
Start With the End in Mind!journal.uptimeinstitute.com
Google SRE - Incident Management Guidesre.google
Google SRE - Postmortem Practices for Incident Managementsre.google
Data center staffing is key to operating a data centerjournal.uptimeinstitute.com
5 Essential Components of Data Center System Planningblog.se.com
Improve Project Success Through Mission Critical Commissioningjournal.uptimeinstitute.com
Microsoft 2022 Annual Reportmicrosoft.com
Four pillars of a successful circular datacenter hardware programdatacenters.microsoft.com
Sustainable by design: Innovating for zero wastemicrosoft.com
True value: Assessing and optimizing the cost of computing at the data center levelresearch.ibm.com
The Economics of AWSaws.amazon.com
The Economics of the AWS Cloud vs. Owned IT Infrastructured0.awsstatic.com
Cloud Financial Management with AWSaws.amazon.com
World Energy Investment 2025iea.blob.core.windows.net
Water-Use Terminology | U.S. Geological Surveyusgs.gov
Water Usage Effectiveness (WUE): A Green Grid Data Center Sustainability Metricthegreengrid.org
GHG Protocol Scope 2 Guidanceghgprotocol.org
2022 Environmental Sustainability Reportcdn-dynmedia-1.microsoft.com
Circular Datacenter Infographic Spreaddatacenters.microsoft.com
DistributedDataParallel — PyTorch documentationdocs.pytorch.org
Performance Tuning Guide — PyTorch Tutorialsdocs.pytorch.org
Slurm Workload Manager — Gang Schedulingslurm.schedmd.com
Disaggregated Serving — NVIDIA Dynamo Documentationdocs.nvidia.com
Key Components of the DGX SuperPODdocs.nvidia.com
Overview — NVIDIA Mission Control Software with GB200/GB300 NVL72 Systems Administration Guidedocs.nvidia.com
Storage Architecture — NVIDIA DGX SuperPODdocs.nvidia.com
NVIDIA Contributes NVIDIA GB200 NVL72 Designs to Open Compute Projectdeveloper.nvidia.com
DGX SuperPOD Architecturedocs.nvidia.com