“懒惰”Linux：“懒惰”集群管理员的 11 个秘诀

    8. 用队列调度程序控制/管理用户

    懒惰的管理员都知道，用户是所有问题的根源。因此，防止用户获得根权限是极其重要的。甚至可以这样说：您应该尽一切努力把用户挡在您的计算机之外。

    队列系统就提供这样的功能：用户提交作业，队列系统决定在哪些节点上运行此作业。除了运行作业之外，用户应该完全影响不了系统。

    当今流行的队列系统包括一些付费产品，比如 LSF 和 PBS Pro。许多商业客户、政府实验室和大学使用这些产品。但是，对于许多系统，一般的开放源码解决方案（比如 TORQUE 和 SLURM）就很好了。

    我们喜欢结合使用 TORQUE 和 Maui 调度程序来把用户挡在集群之外（除了运行作业）。在 Linux 上，这需要先设置 /etc/security/access.conf 文件，只允许根用户登录，拒绝其他任何人。例如，如果在每个节点上运行命令：

echo "-:ALL EXCEPT root:ALL" >>/etc/security/access.conf

    那么只有根用户能够登录此计算机。接下来，创建一个 TORQUE 序言脚本，它运行下面这样的命令：

perl -pi -e "s/:ALL$/ $USER:ALL/" /etc/security/access.conf

    （提示：$USER 变量是在运行脚本时 TORQUE 传递给脚本的第二个变量）。因为根用户运行序言脚本，所以此用户被允许登录集群。当作业完成时，运行收尾脚本，该脚本从 /etc/security/access.conf 中删除此用户，因此他无法再登录节点：perl -pi -e "s/ $USER\b//g" /etc/security/access.conf。这会防止用户相互冲突。

    我们在集群上看到的一些 “性能” 问题实际上与计算机本身无关；真正的问题是多个用户在同一台计算机上运行作业，而他们运行的作业都要求占用全部 CPU 时间。

    众所周知，用户管理是必需的。但是，在排除故障时，管理员常常没有认识到用户本身正是问题的根源。我们强烈建议把用户挡在系统之外，只允许他们通过受控的环境（比如资源调度程序）进入系统。另外，我们建议集群网络本身（千兆管理或用户网络）应该与公司或校园 WAN 的其余部分分开，只允许某些用户节点提供访问点。

    9. 执行基准测试！提前发现性能问题

    很多人只有在集群性能急剧下降、计算结果不正确时，才会意识到危险迫在眉睫。所以要记住，在判断集群的性能时硬件诊断常常是惟一的测试方法，但是硬件诊断提供的信息可能不完整。

    硬件诊断常常以厂商指定的阈值作为成功/失败的评判标准 —— 实际的阈值可能高些，也可能低些。如果硬件诊断测试失败了，那么您就遇到问题了；但是，即使没有失败，也不意味着没问题。

    下面的这些问题会对系统性能产生实质性影响，但厂商无法诊断出这些问题：

    ●双位内存错误
    ●单位内存错误
    ●SRAM 奇偶错误
    ●PCI 总线错误
    ●数字错误
    ●缓存错误
    ●磁盘错误
    ●性能不一致
    问题常常与硬件无关，而是与软件相关。应用程序、库、编译器、固件和操作系统的任何部分都可能是问题的根源，而硬件诊断探测不出这些问题。运行硬件诊断的运行时环境常常与应用程序的环境不一样，而且子系统承受的压力也不一样 —— 所以无法重现软件造成的问题。

    显然，需要在操作环境中运行某种相应的工作负载，从而检查集群的实际工作情况。这可以通过运行几个行业认可的基准测试来完成。基准测试的目的不是要获得最好的结果，而是要获得一致的、可重复的、精确的结果（当然，这也是最好的结果）。

    如何知道结果是否是最好的？集群可以划分为下面的主要子系统：

   ● 内存
    ●CPU
    ●磁盘
    ●网络
    ●硬件厂商应该有基准测试数据，这些数据说明预期的内存、CPU (FLOPS)、磁盘和网络性能。

    如何知道结果是否是一致的？

    采用统计学技术。在每个节点（对于多节点测试，是节点集）上运行每个基准测试一次或多次，然后把每个节点（或节点集）的最具代表性的数据集中在一起，并进行分析。结果的分布形态比结果本身更有意义。本文中所有基准测试的经验证明，结果都应该形成正态分布。正态分布是典型的钟形曲线，这在统计学中经常出现。它是更小的独立（可能无法察觉到的）恒等分布的变量或随机事件的综合结果。

    基准测试也有许多很小的独立（可能无法察觉到的）恒等分布的变量，这些变量可能会影响性能，比如：

    ●小的竞争进程
    ●上下文切换
    ●硬件中断
    ●软件中断
    ●内存管理
    ●进程/线程调度
    ●宇宙射线
    ●这些变量可能是不可避免的，但是它们是形成正态分布的原因之一。

    基准测试还可能有非 恒等分布的可观察到的变量，它们也会影响性能：

    ●大的竞争进程
    ●内存配置
    ●BIOS 版本和设置
    ●处理器速度
    ●操作系统
    ●内核类型（比如 NUMA、SMP 和 UNI）和版本
    ●坏内存（比如过多的 ECC）
    ●芯片组修订
    ●超线程或 SMT
    ●不均衡的竞争进程（比如在某些节点上运行 httpd，但是在其他节点上不运行）
    ●共享库版本
    这些变量是可避免的。可避免的不一致性可能导致多重模态分布或非正态分布，可能会对应用程序性能造成可度量的影响。

    由于我们的目标是一致的、可重复的、精确的结果，所以最好先尽可能减少变量。首先进行单节点基准测试，比如 STREAM。如果所有计算机都产生相似的 STREAM 结果，那么在其他基准测试出现异常时，就可以排除内存这个因素。接下来，做处理器和磁盘基准测试，然后是两节点（并行）基准测试，再执行多节点（并行）基准测试。在完成每个更复杂的基准测试阶段之后，检查结果是否是一致的、可重复的、精确的，之后才能执行下一个测试。

    下面是我们推荐的基准测试次序（报告组件性能的基准测试以粗体显示）。

    ●单节点（串行）基准测试：
    1 STREAM（内存 MBps）
    2 NPB Serial（单处理器 FLOPS 和内存）
    3 NPB OpenMP（多处理器 FLOPS 和内存）
    4 HPL MPI Shared Memory（多处理器 FLOPS 和内存）
    5 IOzone（磁盘 MBps、内存和处理器）
    ●并行基准测试（只针对 MPI 系统）：
    1 Ping-Pong（互连 microsec 和 MBps）
    2 NAS Parallel（多节点 FLOPS、内存和互连）
    3 HPL MPI Distributed Memory（多节点 FLOPS、内存和互连）
    等一下，听起来要做的工作太多了！

    是这样的，但是如果您希望以后清闲的话，这也是必要的。幸运的是，可以通过工具和文档简化这些工作。提前做一点儿计划，以后就能够避免许多麻烦。我们将在以后的一篇文章中讨论基准测试工具和图表；在未来的 xCAT RPM 中也会提供这些工具，这会极大地提高生产力。

上一页  [1] [2] [3] [4] [5] 下一页

【责编:Zenghui】