3.1 初步拟定需求
首先需要初步规划集群的用途和目标，如计算需求、数据规模与存储性能、高速网络带宽、对外网络的带宽、预估需要多少算力，在同行中处于何种水平，或者想要在top500中取得多少排名。以下几点建议在这个阶段的工作中基本明确。
3.1.1 计算需求
明确计算需求是集群设计的必要工作。应考虑清楚集群未来主要应用场景和计算需求，如需要处理的数据量、计算规模、并行计算需求等。根据计算需求确定集群的规模和性能指标，如计算节点数量、每个计算节点的处理器核心数（当然也需要考虑拟选定cpu的每核心价格）、内存容量等。
并根据实际应用需求进行权衡和调整，以确保集群建设目标与应用需求相匹配，并能够满足未来的扩展和发展需求。
3.1.1.1 现有资源评估
如有已在运行的集群，应查看与统计当前计算资源的利用率和性能瓶颈，分析哪些资源经常会排队、队列排队的比例，平均每个作业排队的时间是多久。统计哪些资源未被充分利用，分析这部分资源未被充分利用的原因，考虑是否在新一代集群中减少占比或者有其他替代方案。
同时也可以收集有关当前系统性能状况的信息，如故障率较高、容易发生故障的组件等，这些部分应在新的集群中得到稳定性的加强。
3.1.1.2 校内调研
校内调研可以通过线上或线下的形式进行开展，如针对学院、学科、代表软件设计的线上调查问卷，或者针对原先用户的普遍性问卷调查。线下调研可以针对一些大课题组的用户或者用户数量大、用户活跃度踊跃的院系或者一些潜在用户群体进行调研，分析其在科学研究、工程模拟、数据分析等方面的需求。
当然在集群正式运行之后，应建立一个长期的反馈机制，以便用户可以定期更新他们的计算需求。
3.1.1.3 校外调研
校外调研可以优先参观当前具有代表性的高校集群，再考察国家超算、商业化集群。如果可以，建议在以下几个方面进行全方位的咨询，深度了解。
硬件方面：选址、建设规模、硬件配置、机房设计、配套设施设计等。
软件方面：运维管理软件栈，运维管理制度，用户管理方法，用户教育方法，用户计费结算方法，数据安全设施，网络安全设施，调度方法，主要计算软件，主要用户群体，作业时长分布，作业规模分布，集群软硬件故障率，软硬件故障处理方法等。
团队方面：管理团队、开发团队、运维团队、后勤保障团队等。
综合方面：询问经典的服务、管理、应急、招投标等案例等。
他山之石，可以攻玉。如有可能，尽量调研3家以上高校或单位，总结是否有共性的问题可以借鉴，规避明显的设计缺陷。
3.1.2 性能要求
根据实际需求确定集群的性能要求，包括计算的浮点能力、存储容量及性能、网络带宽等。同时考虑未来主要任务的工作负载特点和计算任务的特征，初步确定集群总体的性能指标，以支持高效的科学计算和数据处理。在初步拟定集群的性能要求后，可以考虑常规性能指标的验收标准,如HPL、IOZONE、OSUBENCHMARK等。
3.1.3 可扩展性
考虑未来集群的扩展需求和可能的发展方向，确保集群具备良好的可扩展性。根据计算规模和需求的增长预测，选择合适的硬件和网络设备，以便在需要时能够方便地进行扩展和升级，在基础建设时预留一定的空间及电力冗余。
3.1.3.1 硬件扩展性
在考虑集群的硬件扩展性方面应选择支持横向扩展的服务器和网络设备。如服务器是否支持且易于横向扩展，内部的组件是否通用且模块化设计，是否内存插槽留有余量，选用的Pcie是否可以支持更高速的组网。
3.1.3.2 软件扩展性
在考虑集群的软件扩展性方面应注重如下几个方面。
模块化设计：将HPC集群软件系统划分为模块，通过松耦合的方式设计模块之间的交互和通信。这样的设计可以使得在集群规模扩大时，能够更容易地对系统进行扩展和维护，同时也有利于保持系统的稳定性。如各类关键管理软件所在的节点物理或逻辑上可以尽量打散部署，但对有依赖关系的软件套件及数据库等中间件互相独立，方便对其分配的资源动态扩容。
水平扩展性：HPC集群软件应具备良好的水平扩展性，能够随着集群规模的增加而扩展其性能和容量。在设计时需要考虑如何有效地将新增的物理节点、计算资源或异构的设备整合到系统中，使其能够协同工作并提供线性的性能增益。
弹性伸缩性：HPC集群软件需要考虑在面对不同工作负载和需求变化时的弹性伸缩性。这意味着系统应能够动态地调整资源分配和任务调度，以适应不同计算需求的变化，保证系统在不同负载下能够高效运行。如作业调度系统可以支持大规模数量的并发使用，开源的slurm软件是一个不错的选择。
管理便利性：HPC集群通常由大量的节点和复杂的软件组成，软件扩展性设计也需要考虑如何简化管理和维护。如能提供可视化的管理界面、自动化的配置和部署工具等，可以帮助管理员更好地管理整个集群系统。
3.1.3.3 存储系统可扩展性
在考虑集群的存储系统扩展性方面应注重如下几个方面。
弹性的存储容量扩展：存储系统需要支持弹性的存储容量扩展，能够随着数据增长而扩展存储容量，而不会影响系统的性能和可用性。这可以通过使用可扩展的存储架构和技术来实现，例如分布式文件系统或对象存储系统。
水平的存储性能扩展：除了存储容量的扩展，存储系统的性能也需要能够随着存储规模的增加而线性扩展。通过采用并行存储架构和优化存储访问的方式，可以实现存储性能的水平扩展，确保系统在面对大规模计算和数据处理时能够提供高效的存储服务。
灵活的数据访问和共享：存储系统需要支持灵活的数据访问和共享，能够满足不同计算任务对数据的访问需求。这包括对不同数据访问模式（例如随机访问和顺序访问）的支持，以及跨节点、跨用户的数据共享能力。
可扩展的数据保护和恢复：存储系统需要具备可扩展的数据保护和恢复能力，能够有效地备份和恢复大规模数据，并确保数据的可靠性和一致性。这可能涉及到数据备份策略的设计、快照和镜像技术的应用等方面。
3.1.4 能耗效率
在建设新的集群时必须要考虑集群的能耗效率。PUE是Power Usage Effectiveness的简写，是评价集群能源效率的关键指标，集群消耗的所有能源与IT负载使用的能源之比。PUE越接近1，表明能效水平越好。
前期设计的服务器物理散热架构决定了PUE可以下探的极限，如风冷架构可以接近1.35，板载水冷架构约1.10，浸没式液冷架构约1.05，当然集群所在地区的自然环境差异也会对数值有些影响。选择节能的硬件设备和合理的能耗管理系统，降低能源消耗，达到节约成本和环保的目标，符合双碳政策，将PUE控制在相对的较好水平。
3.1.5 高可用性和可靠性
确保集群具备高可用性和可靠性，应采用冗余设计和容错机制，以保障集群的稳定运行，尽量减少全局性故障引起的停机时间，如电力系统、制冷系统、网络、存储等方面的单点故障隐患。
电力系统N+1架构：建议为存储、管理及核心网络部分应配备N+1电力设备，从ups到列头柜到PDU，再到服务器及交换机等末端设备均采用N+1的电源模块，在供电方面有所保障。在遇到市电波动或者一路市电维护的场景时可以让用户继续访问数据。
制冷系统冗余：如采用风冷架构则建议每个微模块有一台空调的冗余，如采用液冷的架构需要设计cdu、冷却塔及管道预留机柜的接口甚至是多回路的备份。
核心管理网络：核心管理网络建议可以采取堆叠的方式避免单点故障，堆叠式网络架构可以将两个或多个物理交换机堆叠成一个逻辑交换机，从而增加了内部交换带宽和吞吐量，提供更大的数据传输能力。当一个交换机发生故障时，堆叠中的其他交换机可以自动接管其功能，确保网络的连通性。同时，堆叠式网络架构能够提供统一的控制平面，对于整个堆叠中的交换机实现统一的管理和控制，简化了网络的运维管理。不过需要注意的是，当堆叠网络架构需要扩展或者更换物理设备时需要承受一定时间的断网。
存储系统冗余：HPC集群应存在多个存储系统，如一套较小的存储部署了nas文件系统，较大容量的热存储部署lustre或gpfs分布式文件系统，一定容量的冷存储以块或者nas的形式挂载在部分数据节点上。这些存储从物理及逻辑上尽可能都是高可用架构，避免出现单点故障导致作业或登陆异常，影响用户体验。
IB网络架构：由于价格较贵，一般IB网络采用树状架构即菊花链式连接，存在单点故障的风险。如预算足够且对于高速网络的要求较高可以考虑胖树组网的架构，胖树网络可以提供高带宽和低延迟的通信能力；也具有多条冗余路径，当出现链路或交换机故障时，可以快速切换到其他路径，保证通信的连续性和可靠性。同时，胖树网络还具有很好的扩展性。
3.1.6 成本效益
在建设目标中考虑到预算及后期设备质保、运维团队投入的因素，寻找性价比最高的硬件和软件配置，并进行合理的资源规划和使用，确保在合理的预算范围内实现建设集群并平稳运行的目标。
建设费用：主要是机房建设、基础设施建设及集群建设的成本，这些部分的预算需要细致、多轮的调整。
运行费用：主要考虑团队建设，需要配备多少辅助人员及运行的水电费测算。还需要考虑一定量的设备、存储的新增费用。
维保费用：在合同约定的维保期到后采购新的维保或者质保模式的费用，如果可以，建议在项目的验收报告内约定一个框架价格供未来参考。