使用AFS, Active Directory和SSSD搭建用于集成电路设计的分布式存储系统 【一】

• 集成电路设计环境需要怎样的存储系统li>
• • 共享性
  • 位置无关(路径透明)
  • 安全性
  • 可靠性
  • 可伸缩性
  • 易用性
  • 可维护性
  • 高可访问性
  • 兼容性
  • 低成本
  • 足够的读写速度
  • 纪律性
  • 兼容流行的集群任务调度软件
• 集成电路设计环境需要怎样的用户系统li>
• • 统一账户管理
  • 统一密码管理
  • 账户移交
  • 强健的密码校验协议

集成电路设计环境需要怎样的存储系统h1>

在讨论解决方案以前我们先聊一聊需求。对于一个典型的集成电路设计环境，我们需要怎样的存储和用户系统们先看存储。

共享性

假如你是一位IC设计工程师，公司告诉你有30台Linux设计服务器可以供你和你的同事使用，你最先想到的需要是什么p>

我可不想管理30个Linux账 ！最好只用同一个账 ，最好只要管理一份自己的$HOME文件夹，对不对p>

如果要访问同事的设计库单元，最好只要知道一个路径，而不用管他的库存在哪台服务器上。

如果张三的库只能通过服务器A访问，李四的库只能通过服务器B访问，而你需要同时引用两个库里的设计单元，该使用哪台服务器呢p>

所以，最好所有的项目目录可以从任何一个设计服务器上访问。

你说，这不就好比一个公司内部的云文件夹嘛对了。

与此相反，如果用户在每一台服务器上都要管理一个独立的$HOME，当服务器增加时，一切很快就会失去控制。

同理，EDA软件和PDK的安装最好只有一份拷贝，无论从哪台服务器上调用HSPICE，需要的PATH环境变量都一样。这样一来，你就不用担心.cshrc文件在一台机器上有效，换台机器就没用了。

维持统一的设计环境不仅对普通用户有好处，对IT管理员而言也有巨大的吸引力：

IT只需要维护一份EDA安装拷贝，无论是版本升级、用户培训还是二次开发，都比维护多份安装并保持它们随时同步要容易许多。

共享性是几乎所有 络文件系统都能实现的目标。Linux世界里流行的另一种文件系统，NFS (Network File System)也能做到。但是AFS在实现共享性的同时，还照顾到了其他几样对集成电路设计团队很重要的需求。

位置无关(路径透明)

硬盘总是会坏的，服务器总是要淘汰的，系统是需要扩容的。我们希望在进行系统维护时，用户仍然可以访问原有的文件。

你说，这不难，可以通过将文件数据搬到其他文件服务器上实现。

但是IC设计环境有一个很特殊的要求，绝大多数IC工程师不希望数据的腾挪操作影响文件的路径。

以Virtuoso为代表的很多EDA软件通过路径来确定设计库的位置。如果一个设计库（Virtuoso library）的路径从

换成了

那么所有使用它的用户就不得不更改自己的环境配置文件（比如Virtuoso的cds.lib )，以避免引用关系失效。

当库的引用关系变得复杂，用户数量很大时，为了维护一台文件服务器，要求相关用户步调一致地临时更改配置，几乎是不可能的。

一种解决方案是虚拟化。用虚拟机来运行文件服务器。需要更换硬件时，利用虚拟平台提供的转移技术，将文件服务所在的虚拟机转移到其他物理主机，并保持文件服务的 络IP地址不变。然后就可以对原来的物理主机进行维护。

虚拟技术可以缓解路径依赖问题，但是在系统需要扩容时，仅仅依靠虚拟化难以解决所有问题。无论是选择扩充虚拟硬盘还是选择增加虚拟机的个数，在扩展性和维护性方面都会分别遇到其他瓶颈。

另一种解决方案，是让文件的路径与文件服务器的位置无关。

举个例子，同样是在server1上存储一个库，我们将它的路径设计成这样的格式:

和之前的例子不同，server1这串字符(或者其IP地址)并不出现在路径里。

这有什么好处呢p>

当我们需要将server1断电，而使用server2临时存储这个库时，我们可以

1. 将整个目录拷贝到server2
2. 告诉设计服务器，访问 /afs/abc/path/libm/，请移步server2的新位置。

于是对设计服务器的使用者而言，库文件读写的感觉上和原来是完全一样的，因为路径没有变化。

这时IT就可以在工作时间将server1断电下线进行维护。等server1维护完成重新上线，IT将libm迁移回server1，并将路径重新映射到server1的位置，就完成了无缝转换。

在用户看来，这一切似乎都没有发生，因为库文件一直可以访问，而且它的路径没有变化。

这用文件系统的术语就叫路径透明，或者位置无关性。用户不需要关心文件的具体存储位置，而只要知道其在文件系统里的路径，感觉这些文件是存储在云里。

当然上面例子里的server1和server2仍然可以是虚拟机。AFS可以和虚拟技术结合使用。这样可以进一步提高文件服务器的灵活性。

避免文件路径和服务器位置绑定，有很现实的意义。

如果做不到这一点，IT就只能等到所有人下班了才能对服务器进行维护操作。考虑到团队可能分布于不同时区，有些人可能在通宵运行仿真，找到这样的时间十分困难。也许是凌晨2点，也许是周末的凌晨2点，也许是节假日长周末的凌晨2点……

而如果路径透明，那么IT就可以在正常工作时间完成这个工作，IC工程师也不用担心旧的设计引用失效了。

我们将会看到，路径透明是AFS系统实现高伸缩性、高可靠性和高访问性的关键。

安全性

安全性对于IC设计企业至关重要。谁都不希望自己的RTL代码或者设计原理图因为未经授权的访问而泄露。

有些企业或组织为了安全性不得不实行物理隔绝，以摄像头监视服务器房间入口，以指纹或面部识别来控制房间的入口。然而当团队扩展到多个地域时，物理隔绝就会影响工作效率。

现实情况下，因为要支持多地区多团队的协作，或者因为单个服务器房间容量有限，所以设计服务器往往需要分散部署在多个楼层里或者多个分支办公室里，有一些甚至从公共的数据中心租赁。

这就带来了一个安全问题，如果恶意攻击者在一台服务器上获得root权限以后就能访问核心数据，那么安全性最差的设计服务器就决定了整个设计环境的安全。

我们并不希望这样。

这意味着什么呢味着IC设计组织需要的 络文件系统不应该信任任何一台设计服务器。

如果一台设计服务器告诉我们A是合法用户，我们不加鉴别就相信了，那么如果这台服务器被攻陷了，实际使用的人是B呢p>

相反，如果我们从一开始就不信任任何一台设计服务器本身的用户系统，那么即使攻击者将自己提升成了某台设计服务器的本地管理员(root)，在没有得到文件系统授权的情况下，他将仍然无法访问共享的核心设计数据。

采用这样的系统设计，我们就不再需要无差别地保护分布在各地每一台设计服务器，而可以集中资源保护和优化中央鉴权系统。

以上我们讨论了安全性的一个例子。安全性还包括访问控制和授权地设计。

在IC设计组织中，往往根据角色会定义不同的访问权限。

比如负责项目A的成员不应该访问项目B，或者为项目C雇佣的外包团队不应该访问项目D.

又比如，版图工程师不应该改动仿真目录，前端设计师不应该改写版图文件，等等。

我们希望系统在认清用户身份以后，可以支持访问控制。

不仅如此，我们还希望访问控制的授权可以下放。为什么要下放控制权p>

如果所有的访问授权都必须由系统管理员进行，那么芯片设计项目和用户增多后，系统管理员就会不堪重负，而且系统管理员并不一定能判断用户权限是否合理。能做出判断的是各项目的实际领导者或者各部门的经理。

另一个明显的事实是，每个用户都应有权决定自己$HOME下的目录分别可以被谁访问。

所以我们希望系统可以支持权力下放。

系统管理员创建了项目目录和存储空间，然后就将目录的管理权下放给一个或一组指定的用户，由这些用户决定谁能对目录做什么操作。如此对安全责任分包，不仅可以实现更大的安全性，也能让目录的实际所有者得到更多的尊重，实现权责一致。

可靠性

IC设计企业的核心资产和竞争力是人才与设计数据。我们希望存储的数据十分可靠。系统具备可以操作的灾难备份方案。

在硬盘使用寿命将至时，管理者可以将数据腾挪到其他硬盘或服务器上，而不影响正常使用。

我们希望这个系统永远在线，十年、二十年不掉链子，哪怕底层的文件服务器和 络设备早已陆陆续续全部更换。

可伸缩性

我们希望这个系统在起步的时候不需要很大的投资，最好只要一台文件服务器即可，甚至只要一台虚拟机。

当数据增多时，我们希望这个系统可以支持很大的集群，比如，支持几万甚至几十万台客户端（文件服务的客户端，即运行EDA软件的设计服务器或个人Linux工作站）。

当使用量减少时，我们可以将数据集中到一起，关停部分文件服务器，不影响访问。

易用性

我们不得不面对的一个现实是，不少IC工程师在启动了Virtuoso以后，都不用再回到命令行界面进行操作。

很多有十几甚至二十几年经验的IC设计工程师在Linux系统的操作上还是“小白”。对于母语不是英文的工程师，这种情况更为常见。

因此我们希望在绝大多数情况下， 络存储系统和IC设计工程师已经熟悉的Linux本地文件系统在体验上没有区别。访问 络文件时的感觉和访问Linux本地硬盘下的感觉一样。点下保存按钮就弹出保存对话框，输入文件路径就能保存文件，就好像数据是存在本地的。

我们希望用户在不得已需要掌握一些命令时，命令简单易懂，具有完善的提示与在线帮助。

新手们只需要记住一到两个主命令，就可以根据主命令 + help的方式，快速找到自己需要的所有子命令和它们的格式(对于AFS，这两个主命令分别是fs和pts)。

可维护性

我们希望管理员不用因为会影响用户访问，而只能通过凌晨加班或者周末加班的方式维护文件系统。我们希望他们能和其他同事一样按时上下班，在工作时间完成系统的维护、保养与升级，但同时不影响系统提供的服务。

我们希望管理员在大多数情况下只要以管理员身份登录任何一台客户端（设计服务器），就能管理部署在所有分部的文件服务器，而不用逐一登录到特定的文件服务器上进行维护操作。

我们希望系统具有完善友好且稳定的命令行支持，以便管理员根据需要开发相应的自动化脚本。

高可访问性

我们希望在保证安全的情况下，系统里的文件可以被不同地域甚至不同时区的IC工程师访问。

我们希望他们可以使用同一个路径下的 表做 VCS 或者 HSPICE 仿真，用同一个路径下的规则文件运行 Calibre DRC 或者寄生参数提取。

我们希望文件系统能够支持多地区间的安全协作，哪怕 络具有延时，通道存在拥堵，链路的中间存在防火长城。

另外，有一些程序和文件在高峰期会被大量用户频繁读取，比如 PDK 库文件或 EDA 软件的执行程序。

当大量用户需要同时读取一个文件时，我们希望文件服务器和带宽资源不会遭到挤兑。也就是说，我们希望存储系统的鲁棒性可以通过缓冲、镜像等机制得到增强。

兼容性

虽然当前主流的EDA软件供应商大多只会指定支持两三个Linux发行版，由此导致大多数IC设计服务器会运行 RHEL (Red Hat Enterprise Linux) 或者 CentOS 操作系统，但我们希望文件服务可以支持所有主流的 Linux/Unix 发行版，兼容Solaris/AIX, FreeBSD，甚至支持Windows和MacOS。

我们希望主流的EDA软件、开源程序和版本控制程序都能顺利运行在这样的 络文件系统上。

低成本

我们希望这个系统不依赖于特定存储供应商的特定硬件，而支持市面上能买到的最通用的服务器，甚至个人计算机或虚拟机。

我们甚至希望花几十块钱租用一个云服务器，就可以开始部署这个系统。

当我们资金充裕，需要扩展时，可以添加升级的通用硬件，进行和路径无关的数据迁移，完成系统扩容以后再淘汰旧的服务器，而不需要从头开始部署新的文件系统。

我们希望昂贵的SSD硬盘可以用于最需要的项目和客户端的缓存，而廉价的HDD磁盘可以存储已经完成的旧项目和大量不经常访问的验证数据。我们希望新旧转换的过程不涉及文件路径的改变，对用户完全透明。

我们希望将尽量多的软件和用户数据都存放在这个系统里。

这有什么好处呢p>

添置设计服务器时，因为不需要存储软件和项目数据，也不用存储用户个人数据，那么设计服务器的选型只需要考虑CPU与内存，其硬盘只要达到能够装下操作系统的容量即可，不需要昂贵的大容量硬盘或RAID组件。这样可以最大限度减少对昂贵的企业级硬盘的重复投资，提高企业级硬盘的利用效率。

足够的读写速度

和用作大规模机器学习、大数据分析、数据库服务或邮件服务的集群不同，大多数集成电路设计工程对文件读写速度的需要并不非常高，而对身份验证和安全性要求很高。即使如此，我们仍然希望有足够的读写速度能够支持波形文件的存储和读取。至少，读过一遍的大型文件，在遭到修改或删除之前不用再重新传输，而可以缓冲在本地。

纪律性

作为IC设计工程师，如果你对自己足够诚实，应该会承认这样一个事实: 如果公司给了你无限的存储空间供你使用，你不会考虑删除那些冗余的中间波形文件。你会用通配符或者 .save all 的形式保存所有节点的波形，以便”需要时”进行查询。

你承认其实绝大多数情况下，这些波形文件躺在那里只是在浪费空间。可是时间一久，你也忘了哪些波形文件十分重要，哪些文件可以删除。于是，干脆一起留存。

Linux的原生文件系统很少默认支持配额制。在没有配额约束的情况下，每个人都按照以上方式工作的结果，是IC设计项目的数据迅速膨胀，硬盘很快就被占满。

作为IC设计的老鸟，请你回忆一下，下面这种情况是否似曾相识p>

你运行了一个周末的仿真，周一检查结果的时候发现，另一个同事迅速膨胀的数据在周六早晨3点占满了硬盘的最后一个字节，而你重要的波形结果没有能够保存下来。当你试图联系这个同事的时候，发现他去休假了。

我们希望共享的文件系统具有一定的约束力。在不影响效率的前提下，能通过配额的方式督促用户有节制地使用存储资源，鼓励每个人以有纪律的方式工作，防止因为少数用户的疏忽而导致大部分人无法工作，最终影响团队的效率。

兼容流行的集群任务调度软件

中小规模集成电路企业较少会使用LSF这样的任务调度程序。但是如果企业很幸运地发展壮大，需要部署LSF时，我们希望这个系统可以兼容LSF和大规模集群计算环境。

讨论完存储，我们再来看看对于集成电路设计环境，我们又需要怎样的用户管理系统。

集成电路设计环境需要怎样的用户系统h1>

统一账户管理

我们希望用户账户能够统一管理，而不是分别存储在每一台设计服务器上。否则当组织有几十台设计服务器时，新人入职创建账 和老人跳槽删除账 就会占满系统管理员的工作时间。

统一密码管理

作为IT系统管理员，最不希望接到的服务台电话之一可能就是：

“喂，我忘记密码了。”

作为公司新人，入职时最头疼的手续之一就是创建各种账 和密码。

如果用户必须为每一台Linux设计服务器记忆一个单独的密码，忘记密码的几率就会大大提高。单是更改和重置密码就可能占满系统管理员的工作量。

账户移交

当员工离职或学生毕业时，他(她)的设计库文件可能仍然被很多人使用。我们不希望注销账户时这些数据也消失不见。最好，离职的IC设计师可以将个人目录托付给另一个员工或一组员工，让他们成为目录的新主人。这对于项目的延续和技术的沉淀十分重要。

强健的密码校验协议

一个IC设计工程师一天可能要进行几到几十次身份密码认证。当设计师进行身份认证时，我们希望她输入的密码不用经过 络传输，就能和管理系统完成身份认证与授权的过程。因为无论是明文还是密文传输密码，都存在可能的安全隐患。

能够实现上述目的的是这个领域内公认的 络认证协议，Kerberos

在希腊神话里，Kerberos(Cerberus) 是看守地下世界之门的三头犬的名字。这个协议由 MIT 领导开发。无论是作为 络安全协议的 Kerberos，还是作为看门犬的Cerberus，都在各自的世界大大有名。

也许你对Kerberos比较生疏，但是微软的Windows Server，以及构成其基础服务的Active Directory Domain Services (即中文Windows系统管理员经常挂在嘴边的”域”)大概你听说过。

Kerberos是Active Directory的基石之一。今天所有使用域来管理Windows计算机的企业，以及使用本地部署的Outlook Server管理邮件的企业，几乎都在自觉或不自觉地依赖Kerberos的安全性完成用户身份校验。

与Linux将本地用户密码存储于/etc/passwd文件不同，Kerberos协议将用户密钥存储在一个中心数据库里(Key Distribution Center, KDC)。用户登录设计服务器时，如果服务器支持Kerberos协议，则除了比较存储在/etc/passwd里的用户密码，服务器还会与KDC通信，确认用户是否是一个非本地的 络账户。

采用Kerberos登录用户有什么好处呢p>

• 密码不需要存储在分支节点，因此分支节点很难泄露用户密码。
• 密码不需要通过 络传输，因此也减少了监听获取密码的可能。

在2000年以前，因为Kerberos协议使用了当时最强劲的加密算法之一(DES)，该协议和软件被美国政府作为辅助军用设施禁止出口。解禁以后，该协议在世界范围内得到广泛使用。

今天的Kerberos支持更为安全的AES加密算法，DES已经不再被推荐为默认加密算法。

目前所有流行的Linux和Unix发行版，包括 MacOS 都支持Kerberos协议。

Kerberos协议最大的特点之一是身份验证过程不会出现密码的传输。因此即使客户端和KDC之间不存在加密的VPN 络链接，也不用担心密码在整个过程中泄露。

我们部署的系统对身份认证由很高的要求，所以希望以Kerberos为主要协议。

至此我们讨论了一个典型的IC设计环境对存储和用户系统的需求。在下一篇文章里，我们聊一聊AFS文件系统的特点。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8828 人正在系统学习中