大型IC设计中心的IT环境 / 开普饭

原创作者：王光辉（本文由作者发表在EETOP论坛）

从2004年开始，我写过几次小型IC设计中心的IT环境。比较多的论述了创业类型的芯片设计公司，应该怎么去设计自己的IT环境。这10多年间，有不少初创型的公司来咨询过如何更好的规划IT系统，我都尽力协助解决。

我本人也在这期间经历过各种类型的公司，包括提供EDA平台的苏州ICC，做交换机芯片的CentecNetworks，已经被收购的Broadcom，做嵌入式CPU的China-Core，以及过去两年为其工作的初创大型CPU设计公司，IBM Power8在中国的落地项目中晟宏芯。以上工作经历，给了我很多锻炼，让我在面对各种大小类型的IC设计公司的时候，变得更加成熟。但是，在这个过程中，深感国内的IC设计公司在IT环境的建设方面，跟国际大公司比较，差距依然非常大。

如何将自己的经验分享出来，以提高中国IC设计公司的IT水平，变得越来越重要，也越来越紧迫。希望本文有助于目前在中国逐渐兴起的IC设计行业，在国家的大基金项目下，少走弯路，缩小跟国外的大公司之间的差距。

全文分为11个章节论述：

1. 基础设施建设(机房，弱电间，接入机房，实验室机房及实验室)

2. 网络结构

3. 系统及存储布局

4. 接入及登陆环境

5. 设计Job的管理

6. 数据管理

7. 版本管理

8. 邮件系统

9. EDA软件管理

10. 多site协同

11. 安全

基础设施建设

1. 供电

2. 制冷

3. 布线（水、电、弱电）

4. 环控

5. 空间及位置考虑

6. 交换机布局,ipmi 布局

7. 消防

基础设施主要包含网络、机房等方面，我这里主要介绍的是机房的建设。过去十多年，我建过几台服务器的小机房，也建过几百台服务器的小型数据中心。考量的东西很多，因为本篇主要论述大型IC设计中心的IT环境，所以主要讲的是几百台服务器的机房。

首先，我们来看一张机房的示意图：

我们可以看到这个数据中心分成了多个部分：接入机房，实验室机房，消防钢瓶间，UPS配电间，电池间，主机房，值班室。

供电

建设机房的首要任务是计算出你到底需要多少功率的负荷，然后对接入电源

跟供电方核对，是否有满足需求的电力接入。然后可以确定UPS容量，最后通过设备的断电后备时间要求，计算出需要多少电池。供电系统是一个很复杂的设计，需要机房设计方认真核对，一旦错误，后期很难补救。

作为用户方:我们提供的信息主要有：总机房设备的最大负载、供电冗余要求、每机柜多少KW、电池的后备时间。

制冷

目前机房空调主要有两种类型：一种是大型的精密空调，通过上送风或者下

送风的方式，经过机房地板形成一个冷热回路。这种方式在很多地方使用，优点是送风集中，运维方便。缺点就是噪音大，空调冷热路径长，能耗损失多。另外一种，就是行间空调。行间空调顾名思义，就是空调就位于机柜旁边，空调出来的冷风就被机柜上放置的服务器吸入，然后从服务器后端排出热空调，形成循环。

水冷还是风冷？

这也是一个难以取舍的选择。整体来说，风冷技术成熟，能耗比水冷高。但是水冷风险高，因为管路的安装和维护要求高，一旦漏水，对机房来说都是大事故。但是，水冷真的可以很大程度降低能耗。

基于自己的条件，我们选择了行间空调风冷方式。

布线

机房布线的考虑，经常受到环境的限制，经常我们不得不取舍。主要需要考虑的是水管如何布置，包括加湿器的进水管和冷凝水的排水管。强电线缆如何布局以及弱电（双绞线及光纤线缆）布局。

水管的布局，需要考虑漏水的情况下，对机房的影响。机房漏水从来不是小问题，任何处置不当，就可能导致机房停止运行。主要有两方面的水路需要处理，一边为冷凝水的排出，另外就是加湿器的进水。建设机房的时候，建设方提出想把顶楼的排水管在中间开口，通过这个排水口去释放空调的冷凝水，听起来不错吧？可如果大雨的情况下，排水管堵塞或者来不及排出去的时候，水就会从排水管的开口处，直接往机房排放。加湿器进水一定要前置阀门，随时将其管理。否则，自来水的突然高压，可能会导致机房大面积过水。由于进水管的安装问题，我甚至不得不将加湿器进水管完全关闭，以免发生意外。水管一般都是从机房地板下走。

强电的安装需要注意跟弱电分开，因为强电会干扰弱电信号。这就提出了一个现实的问题：强电到底应该走顶部还是地下？因为顶部往往会走弱电线缆。弱电走顶部的一个好处是后期维护和排错更加方便。我这里设计方选择了走地下，地板下有40cm，强电在架设的桥架上走。但是，因为排水管需要有一定高度，不得不走了强电桥架的上部，这应该是一个失败的设计。但是，如果强电走顶部，弱电怎么办？两者之间需要隔离。整体的通道和机柜设计已经解决这个问题，所以建议选择冷通道和机柜的时候，选择好顶部可以分割强弱电布线的产品。这样可以很好的解决强弱电分离的问题，同时避免了强电跟水路一起走的尴尬。

环控

机房环控需要做到几个方面：视频监控，温湿度，漏水检测，电话报警，PUE

的实时显示。

空间及位置考虑

为什么要将接入机房单独出来

接入机房负责跟外界的沟通，包括各家运营商的接入线路：电信的互联网，电信的电话，联通的互联网，专线等。
这个地方经常要开放给电信联通的维护人员，办公网络的核心设备也需要放在这里。外网防火墙，门禁系统，OA服务器等都需要，类似一般公司的小机房。各办公楼层的汇聚。这个机房设计，一般可以考虑单独的UPS，空调。

为什么要建一个单独的实验室机房？

我们都知道，IC设计公司是要做出硬件产品的，而很多工作需要的服务器，不是IT人员去管理，而是设计人员自己做各种测试使用。如果没有一个独立的空间，是无法做好隔离的。这样测试环境会让整个IT系统不稳定。仿真器等设备需要大功率的制冷和独立空间，所以实验室机房采取传统的精密空调，采用下送风的方式制冷。

主机房

我们主机房按照标准模式，设计了独立的消防管网系统，气体灭火。UPS配电间跟电池间。UPS设备目前有模块化的，可以考虑，避免机房设备不足的时候，UPS浪费电力严重的情况发生。

机房的位置选择

这个涉及的考量很多，很多时候我们不得不折中考量，这让人感觉很无奈。比如，我们需要考虑楼层的承重，一旦我们考虑建设机房的地方，如果楼下是空的，就需要建筑设计单位拿出承重设计数据，不能满足我们需求的情况下，我们需要加固。一般情况下，都是不能满足的，没有哪家建筑设计院会将普通的办公楼设计为承重达到机房的要求，除非是厂房设计。一般建筑的承重为250kg—500kg，而我们机房一般要求1000kg-2000kg之间。特别是UPS电池间，这个地方要求的承重非常高。

如果我们选择地下没有架空的一楼做机房，当然就不需要重新加固建筑承重了，但是一楼往往会面临另外一个问题。机房空调的外机往哪儿放？现在的建筑一般都是空调放在顶楼，如果一楼的机房到顶楼的距离过长，会影响制冷效果，能耗也会损失更多。另外，一楼还需要防水，特别是暴雨来临，如果地势低洼，很可能导致倒灌，一旦进入机房，整个机房就可能完全停止工作。

所以，机房的位置选择起来非常难。建议一定要提前选择好地方，且不可将就。

网络布局

机房网络设备主要是交换机，目前主要采用的有集中式布局和分布式布局。

两种各有优缺点。

集中式布局，一般在一个冷通道采用一台大型多插槽的交换机，这样的布局方式，机房布线是一个难点，因为几百根网线要布局到核心交换机处，线缆的连接非常麻烦，好处是解决问题的时候简单，且由于交换机多采用了个冗余部件，很少出现故障。各个机柜之间也基本是线速连接的。

分布式布局，多采用TOR交换机模式，即每个机柜顶部安装一台交换机，然后各交换机通过上联到核心交换机处实现连接。这样的连接方式，交换机数量比较多，可能不得不浪费很多端口，因为我们一个机柜里边很难会完全用完交换机端口（现在一般交换机都是24口-48口）。这种方式的优点是：布线非常简洁，只要每机柜到核心交换机机柜布置2根6芯的光纤+2根六类线即可。

建议新建的机房采用10G TOR交换机+40G上联，这是趋势，服务器之间采用10G连接的成本已经降到足够低了。可以满足一段时间的需求。

无论采用分布式还是集中式，都推荐在每个机柜上放一台简单2层交换机，用于设备的远程管理口，比如服务器的ipmi端口。这样可以不用随时进出机房去开启关闭服务器。

消防

机房的消防，目前主要采取的是七氟丙烷气体消防。主要考虑的是，提前在

消防部门审批方案和报备，必须是当地有资质的建设方。另外，气体释放的方式最好是经过监控室人工确认，否则可能导致机房人员没有按时撤离，窒息而死。

网络结构

首先让我们来看一个网络的结构示意图，因为这部分涉及到实际内容，我只能通过示意图的方式来简单讲一下基本的要求。无法提供真实的网络结构图给大家看了。

1.内外网隔离

2.研发网络跟办公网络隔离

3.研发网络客户端跟服务器隔离

4.MPLSVPN网络

内外网络隔离

我们通过多层防火墙对网络进行了隔离，公司总出口有一个上网的防火墙，

用于隔离互联网跟办公网。我们对外提供的有限服务位于防火墙后面，这也是最容易被外部攻击的区域。在这里，我们通过ACL等措施隔离办公网络流量，防火墙部署入侵检测和杀毒等服务。

研发网络跟办公网络隔离

研发网络指的是我们设计芯片的网络。这里一般采用两种方式隔离，一种

是物理隔离，另一种是逻辑隔离，各有优缺点，按需采用即可。物理隔离的优点是安全，任何通过网络入侵的机会将为零。但是缺点是实用性和方便性遇到困难，无法做到多个异地site协同工作。逻辑隔离是采用各种安全规范，严格限制研发网络跟办公网络的交互，实现即时办公网络被入侵，依然可以保证研发网络安全的网络设计。这种优点是可以多site协助，跟外部交流容易。缺点就是存在安全错误导致的安全风险存在可能。

研发网络的客户端跟服务器分离

研发网络的服务器端一般位于机房内，而客户端位于工位。两者之间如果不

能有效隔离，就会造成安全风险点大面积增加。同时，对内的安全防护就无从谈起。使用，我们一般会在登陆客户端跟设计服务器之间采用防火墙来隔离。同时，登陆服务器也需要采取各种安全措施，避免被内部用户入侵控制。

MPLS VPN网络

专线网络有多种，常用的可能有MSTP/SDH
MPLS。SDH专线主要用在国内

点对点电路上，相当于给提供物理链路给你。这种方式优点是点对点，只要电路不断，你的网络一定不会跟其他共享带宽。MPLS VPN是用的更多的专线方式，其特点是环状组网，使用逻辑隔离，将数据从一个大的带宽网络中隔离出来，运营商采用各种方式尽量保证你的带宽符合你申请的带宽。

如果只是两点，可以考虑SDH，如果是多点，建议还是用MPLS VPN比较合适。专线方式可以提供比互联网ipsec vpn更好的稳定性，建议研发的工作环境采用。而对于稳定性要求不高的应用，建议还是采用传统的ipsec vpn方式节省费用，比较专线每月都需要付出一大笔钱。

额外提示一点：目前研发设计网络，经常需要使用google等搜索引擎查询资料。国内的网络连接国外有防火墙封锁，同时两大运营商的问题导致访问国外异常慢，丢包率非常高。解决这类问题，目前有几个办法：方法一,购买一些vpn服务账号，适合个人使用。方法二、公司拉一条专线到香港，通过香港本地上internet。适合公司一起使用的，但是这种方式成本很高，差不多1000元/M，一条10M的线路需要每个月一万了。方法三、通过上面所述的MPLS VPN，路由到国外再上internet，类似方法二，只是成本更高，如果刚好有上下线非对称应用，比如国外分部主要通过MPLS访问总部资源的时候，主要是下行带宽，总部可以利用其上行带宽。方法四、采用SDN的方式和云计算结合，通过公有云实现这类应用，成本在100-300RMB/兆
之间，非常适合小公司。

系统和存储布局

1. CPU架构及OS考虑

2. 认证（NIS AD LDAP及其他）

3．DNS/NTP

4.Email

5. 存储：zfs/netapp

6.NFS v3/v4 和AFS GPFS之间的优缺点

CPU架构及OS

看过我以前文章的朋友，一定会记得，2004年，我推荐Solaris8。2008年推荐的OS是RHEL3和RHEL4，到了2013年我写的文章，已经推荐RHEL5了。今天（2015年底）我推荐的是RHEL6.7。推荐OS必须跟当时所处的情况有关，目前三大软件商cadence synopsys mentor都已经支持RHEL6，所以采用RHEL6毫无问题。我们目前全部都采用的是RHEL6.7的OS。

CPU架构方面，依然推荐Intel的E5-2600v3和v4双路服务器，特殊情况可以考虑E7的4路服务器。作为一家主要引入IBM Power8处理器设计的公司来说，采用intel的CPU是不是有些特别的意味？一点也不奇怪，因为EDA vendor的主要软件都是支持x86的处理器，只有少量软件会支持AIX+Power。而从性价比来说，显然x86更有优势。

OS安装需要采用kickstart实现一致性安装，即所有服务器跑的系统和软件包都一样。实现本地的OS image和epel库，然后通过pssh等分布式管理工具实现软件安装的一致性要求。

认证

用户认证，必须实现统一账号，在任何系统下，最好是同一个账号和密码。

目前能够实现这个条件，需要windows的Active Directory和NIS或者LDAP统一。

我这里采用了windows 2008R2 + NIS来实现，使用NIS这么古老的认证技术主要是考虑了其简单方便性，没有过多考虑其他如安全等特性。

Windows 2008R2，集成可SFU的功能，可以为unix用户设置一些特性，比如uid gid shell home，另外，还提供NIS服务器功能，可以实现windows账号和unix账号的统一。

采用NIS的原因是我们会在后面实现autofs功能，这样PXE安装的Linux服务器就不需要挂载很多文件系统，而直接采用autofs的方式挂载。

在未来，Unix下认证应该会跟逐步LDAP集成。

DNS/NTP

实现内部DNS服务功能可以提供内部服务器之间的便捷访问，从而摆脱记忆

ip地址的麻烦。某些服务器在采用了内部dns后，可以更容易使用。目前提供dns服务器的主要有两个程序：bind和dnsmasq。前者是传统的dns服务器，功能强大。后者是简单的dns+dhcp服务，一般用于小型环境。优点就是便捷，使用方便。具体服务器搭建，这里不再详细介绍，提醒一点是dnsmasq默认不提供跨vlan的dns服务，需要绑定interface。

内部ntp服务在这种环境下几乎是必须的。Ntp可实现内部时间的统一，避免认证失败或者文件时间冲突等问题。Ntp服务器的实现非常简单，不做介绍，注意要周期性跟ntp服务器同步时间。

Email系统

Email依然是当前企业通信的最主要方式，所以email系统的选择也是一个重

要的工作。由于我们公司采用了内外网隔离的方式，所以我们的平时跟外部联系的邮件系统跟内部邮件系统是完全独立的两套。

外部邮件系统主要考虑的是防病毒，防垃圾邮件，安全，可维护性及尽量少的中断时间。基于以上考虑，我们最终选择了托管出去的方式。以前在多家公司，都用了自己搭建的邮件系统，包括exchange或者其他专业的邮件软件，开放25端口来跟外部通信。其中最麻烦的事情不是安全，而是垃圾邮件太多。如果公司自己购买一台垃圾邮件过滤系统，费用很高且可能一定程度误报误删，这样对公司来说是无法接受的。由于新建公司没有多少邮件迁移的任务，我们最终采用了托管出去的方式，按用户付费，这样完全避免了垃圾邮件的困扰。

内部邮件系统，我们采用了postfix来自己搭建一套。考虑到有需求，我们采取措施，让托管出去的邮件可以直接转发到内部邮件服务器上。这里涉及到了一个中转服务器。

存储

存储系统的选择非常重要，几乎决定了后期整个系统性能的关键因素。在IC

设计行业中，有几个重要因素需要考虑：实时压缩、高速SSD做缓存、重复数据删除、snapshot、NFS v4 ACL、Backup。

对于以上特点，我这里简要介绍需要的原因：

实时压缩，可以很大程度减少存储容量的使用。在IC设计中，经常可以做到2倍的压缩率，即容量提升了一倍。同时，还提升了IO能力，因为压缩后的数据更小，有利于读写。现代的CPU都很快，压缩不会带来太大的负担。所以，可以放心使用。

高速SSD缓存，全闪存太贵，而采用SSD做缓存的方案，可以很大程度上将热点数据放在高速SSD上，遇到调用的时候不再去磁盘中寻找，这样可以很大程度上提供IOPS，是一种利用较低成本提供了较大效益的方案。

重复数据删除，重复数据删除功能可以在很大程度上减少磁盘空间的使用量，特别是针对某些应用，比如虚拟化及多版本开发环境。

Snapshot，这里的snapshot一定要跟SAN盘阵的区分开来，也跟LVM的不一样。基于netapp和zfs的snapshot功能，允许用户自我管理不小心删除的数据，随时自己去恢复，减少管理员的麻烦。提高了用户的满意度。

NFSv4 ACL，由于其提供了很多高级特性，可以实现项目的管理方式，让项目经理去管理目录的权限，将IT从权限管理的繁琐中解脱，同时，给项目经理足够大的自由度，让他们更快捷的实现自己的要求。

备份，是一个重要的话题，数据备份可能永远都是在做后备，但是一旦需要恢复，备份就显得格外重要。目前主要考虑采用D2D的备份+磁带归档的方式实现长期的数据备份需求。

由于我们的环境主要是NAS存储的NFS共享，满足以上要求的主要有netapp的存储及基于zfs的存储系统，如oracle ZS4
nexentastor等。

目前在国内做支持最好的依然是netapp存储，但是netapp的销售策略要小心，存在销售控制价格的行为特别严重，甚至可以做到价格差异30%-50%的情况。因为是区域控价，你如果选定了必须用它，几乎无任何的议价能力，被迫接受高价。在大厂商面前，用户很弱势。唯一的反击就是绝对不要选择某一家厂商的产品作为采购要求。

NFS v3/v4 及AFS GPFS文件系统的优缺点

NFS v3是过去和当前依然在大量使用的协议，几乎所有的系统都能支持，使

用和配置也很简单。但是，nfsv3 缺乏一些特性，如安全性不足，缺乏更严格的acl支持，缺乏并行支持等。所以，后来开发了nfs v4，提供了更加先进的一些功能。我们主要会使用到nfs v4的功能就是nfs v4 acl支持。目前很多测试环境下，nfs v3的性能依然比nfs v4更快。所以，除了需要设置acl的时候，否则其他地方应该挂载nfs v3为主。

AFS文件系统是另外一种主要的网络文件系统，其提供了很多优秀的功能，比如本地cache，acl，quota，分布式等。但是，国内很少用到，商业化支持也不足，所以不建议使用。

GPFS是IBM开发的商业产品，可以实现分布式，如果不考虑费用问题，可以考虑在某些关键的应用中采用。

--------------------------

网友提问：

IC行业中，存储对IOPS的要求是非常高的(实际生产环境中的发现)，对存储容量要求相同的情况下，如果获得更高的IOPS，除了存储控制器的IOPS限制外，还要考虑单个硬盘的容量问题。一般情况下单盘更小容量，更多的盘，可以带来更高的IOPS。
另外可以提一下存储的空间利用率，往往存储的利用率超过85%(有说90%)，读写效率将大幅下降。
实际生产环境中，磁带归档是否是一个效率(备份和恢复)很低的办法？

----------------------------------------

非常好的问题，你肯定是业内人士。
-------------------------------------------------------------------------------------
回复如下：
要想获得高的IOPS，机械硬盘已经无法应对了。以前的做法一般是raid卡带cache（write back）+ 15000RPM的硬盘。
cache的好处是写入小文件加速，因为直接返回，但是读取依然会很慢。现在大量采用的10000转 2.5 SAS盘，已经算是不错的了，但是IOPS依然不高。
唯一能解决IOPS的只有SSD，nvme的SSD会更快。
存储超过85% 90%，读写效率大量下降的根本原因是写入算法的改变。
以zfs文件系统举例，zfs文件系统在80%之前，是write anywhere，就是只要有空的地方就写。80%以后，马上改变算法，需要找一个比较合适的位置写，显然速度一下就下降了。netapp的WALF也有一样的问题。

我写的是磁带归档，而不是主要用于备份。磁带的缺点很多，比如速度慢，无法online方式查询恢复。最大的问题是：你需要找回数据的时候，可能根本读不出来！所以，它只适合归档，因为一盘一盘磁带，拿出去放银行保险柜，依然是最方便的做法。
当然，如果你可以做到磁盘方式归档，更好。
目前建议的是D2D2T（即磁盘到磁盘备份，然后从备份磁盘归档到磁带）。

因为全闪存太贵，建议大家设计系统的时候，以project的方式分流。将iops要求很高的项目才放入SSD，而普通项目，依然放入大容量的7200RPM或者10000RPM的磁盘系统。

备份系统则毫无疑问，采用7200RPM 3.5寸的大容量磁盘。

--------------------------

接入及登陆环境

1. VPN是否可以？VPN至少要做到双因素验证

2．如何避免设计人员copy&paste。

3. 登陆软件的选择：VNC Xenapp NX Go-global EoD等

4. 桌面系统：GNOME KDE ICEWM FVWM XFCE

如何考虑移动VPN接入

提供移动VPN接入就相当于在内部网络开放了一个接口，让外部的用户可以

随时随地访问内部网络。所以，首先要评估是否可以做到足够的安全级别，让非法的用户无法通过窃取账号等方式登录你的网络。

VPN接入，需要至少做到双因素的认证。主流的做法包括RSA SecureID这种基于时间的双因素或者USB Key基于证书的双因素。当前，还需要考虑VPN支持移动客户端和MAC OSX系统。因为，这两方面的用户越来越多了，有更多的接入需求。

如何避免设计人员copy&Paste数据

IC设计中，一般都在服务器完成，但是也需要用户从终端登录服务器。如果用户可以将服务器的文本copy到本地终端，那么就存在带走的可能性。我对于数据安全的主要观点是：数据需要位于服务器上，用户无法物理接触的数据才是安全的。数据分级，防止一个用户拥有所有数据的权限，可以防止被某人获得全部数据。带出数据需要审核及归档，这样做到有据可查。

目前的登陆软件，很多可以禁止用户剪切板的数据copy到用户端。同时，采用防火墙，防止用户直接从内部服务器主动连接客户端获取数据。

登陆软件的选择

目前小公司普遍采用的登录软件有Xmanager/Exceed/VNC/FreeNX，而大公司普遍采用的有Xenapp/NX/EoD/Go-Global等。对于以上软件，我都有一定程度的接触，所以在此做一个简单评价。

Xmanger和Exceed，属于利用X协议，在windows平台实现的X Server，优点是使用方便，使用的人很多，性能在局域网也不错。缺点就是，一旦用户端跟服务器之间的网络意外终端，或者客户端关机，所有正在服务器上运行的job丢失。

VNC免费版使用非常广泛，其实现了网络断开也不会丢失正在运行的工作。但是免费版限制很多，比如需要用户设置专用的vnc登陆密码，无法禁止用户Copy&Paste服务器数据到本地。另外，VNC协议实现对网络带宽消耗很大，不适合于WAN网络连接。

FreeNX是基于No-Machine免费开源的library实现的免费远程登陆软件。目前有另外一个如日中天的类似软件，叫做X2Go。FreeNX基于SSH协议，实现了压缩传输等功能，效率比VNC提高很多。但是其基于SSH协议实现，给系统安全留下了隐患。

VNC Enterprise，实现了更高级的功能，包括验证集成了系统验证，不需要额外设置vnc登陆密码，也可以禁用剪切板等高级功能，还可以通过policy设置。对于小型设计环节，目前是一个非常值得考虑的选择。

Xenapp是citrix基于ICA协议实现的登陆方式，最新的基于Unix的是2008年前后发布的Unix 4.0 FP2版本。Citrix的中心已经转向了windows，及时是最新发布xendesktop linux版本，也并没认真去做，集成很困难。不过，当年Broadcom是基于solaris 10+ citrix for unix fp2实现的登陆环境，不知道五年过去了，是否已经改变。

Nomachine公司发布的NX商业版本可以支持更多功能，国内有几个公司在使用，具体功能不了解，比如如何实现及时采用SSH协议，也不担心被设置转发隧道，从而解决安全问题的。

EoD的全称是Exceed On Demand。软件费用昂贵，国内使用的人很少，目前我知道的是IBM基于EoD实现登陆。EoD软件可以禁用Copy&Paste，同时gateway模式可以让用户无法直接在EoD服务器上工作，让EoD服务器实现gateway转发即可。EoD可实现share 桌面，对于远程会议共享桌面和需要远程协助debug的时候非常有用。推荐不差钱的大公司选择EoD，是我见过最佳的登陆软件了。

Go-Global是另外一个登陆软件，分为for windows和for unix版本。实现上比VNC要快，国内也有商业支持，也比较成熟和稳定。不过其客户端目前只支持windows系统，这点需要注意。如果是中小型公司，可以考虑采用。

桌面系统的选择

我一直反对使用重型桌面环境，比如Gnome和KDE，毕竟几百人的公司，登陆服务器就那么两台，一旦使用GNOME和KDE，整个系统负载是非常高的。而我们的设计工程师，根本不需要那么复杂的桌面环境，最简单的才是最高效的。

在我的工作中，我推荐过使用fvwm，自定义过一个非常简洁的桌面环境，但是由于定制要求很高，用户使用起来感觉不是很好。不过fvwm可定制性很高，可实现非常棒的一些效果。

后来我选择使用过XFCE，另外一个比较其GNOME和KDE较轻量级的桌面。在2008年-2013年，我都认为这是一个不错的桌面环境，在很多地方推荐使用过。但是，xfce的安装包很多，最好通过yum自动安装。我们也逐渐在考虑一个更加合适的窗口管理器。

2015年，一个新的同事推荐了icewm。我认为目前这个是最合适IC设计公司工程师的窗口管理器了。

可以实现多个桌面，添加需要的一些xterm 和 gnome-terminal firefox 等工具。

推荐：大公司首选icewm，其次可以考虑xfce。小公司建议多考虑xfce。

设计Job的管理(SGE/LSF)

1. LSF

2. SGE

3. Openlava

LSF

LSF 是目前主要采用的任务管理软件，目前归属于IBM，最新的版本是9。几乎所有大的IC设计公司都采用的是LSF的软件来做负载均衡。不过，这个软件是商业软件，授权费比较贵，大约要1-2万一台服务器(以core计费）。

下图为lsload命令所显示的结果，大家可以看到各台服务器的负载，CPU利用率，剩余内存等信息。

LSF会自动去调度，找出最佳的后台服务器，尽量做到负载均衡。所有的后台服务器，用户都不能直接登录去run，这是由系统和网络结构限制的。但是，对于用户，要让所有的操作做到最简单，用户不需要去了解复杂的后台设计。

这里介绍一下LSF的一些使用

提交job

$bsub my_job
Job <1234> is submitted to default queue <normal>
上面输出中1234是分配给my_job的ID, normal即系统默认queue

提交并行job

$ bsub -n 8 myjob
myjob以并行JOB的方式执行，且需要8个cpu cores。比如在脚本中，hspice使用了-mt 8的情况下。用上面的命令会让lsf帮你找到空闲的8个cpu core之后才提交给具体执行的主机。

查看当前自己或者其他人的job

$bjobs
(只查询自己的) $bjobs –u all（所有人的）

然后可以得到jobID

$ bjobs -u all
JOBID USER STAT QUEUE    FROM_HOST EXEC_HOST JOB_NAMESUBMIT_TIME
1004 user1 RUN short    hostA hostA    job0 Dec 16 09:23
1235 user3 PEND priority hostM             job1    Dec 11 13:55
1234 user2 SSUSP normal hostD    hostM    job3    Dec 11 10:09
1250 user1 PEND short    hostA             job4    Dec11 13:59

Kill掉自己的某个job

$ bkill 1234
Job <1234> is being terminated

挂起和恢复job

$ bstop 3421
Job <3421> is being stopped

$ bresume 3421
Job <3421> is being resumed

查看job的输出

$ bpeek 1234
<< output from stdout >>

查看服务器负载

$lsload

查看服务器状态

$bhosts

查看job的详细信息

$bjobs –l 1234

SGE

目前SGE是免费且开源的，国内也有不少公司在使用。但是使用起来，感觉差异很大，可能是习惯问题，我始终无法适应SGE。我也不推荐使用sge。

Openlava

前面介绍了LSF是商业软件，授权费比较昂贵。这里推荐一个兼容LSF命令的软件，Openlava，其基于LSF 4.2发布的开源版本，目前最新的是3.3，由Teraproc公司主要开发和支持。推荐国内的大公司采用，只需要少量的支持费即可。目前主要基于x86的linux环境，如果你有其他异构系统，需要联系厂家获取是否可以支持。如果大家对于采用openlava感兴趣，可以联系我，我可以协助测试。前面LSF的示例完全可以通过openlava实现。

设计Job的管理(SGE/LSF)

1. LSF

2. SGE

3. Openlava

LSF

下图为lsload命令所显示的结果，大家可以看到各台服务器的负载，CPU利用率，剩余内存等信息。

这里介绍一下LSF的一些使用

提交job

$bsub my_job
Job <1234> is submitted to default queue <normal>
上面输出中1234是分配给my_job的ID, normal即系统默认queue

提交并行job

查看当前自己或者其他人的job

$bjobs
(只查询自己的) $bjobs –u all（所有人的）

然后可以得到jobID

Kill掉自己的某个job

$ bkill 1234
Job <1234> is being terminated

挂起和恢复job

$ bstop 3421
Job <3421> is being stopped

$ bresume 3421
Job <3421> is being resumed

查看job的输出

$ bpeek 1234
<< output from stdout >>

查看服务器负载

$lsload

查看服务器状态

$bhosts

查看job的详细信息

$bjobs –l 1234

SGE

目前SGE是免费且开源的，国内也有不少公司在使用。但是使用起来，感觉差异很大，可能是习惯问题，我始终无法适应SGE。我也不推荐使用sge。

Openlava

数据管理

1. 上传数据考虑因素

2. 下载数据如何审核及自动备份归档数据

3．数据访问的Audit

4. 数据分级及权限控制

数据上传

在一个公司，内外网隔离的情况下，必然有大量的数据上传需求。如何实现

上传呢？这是一个大问题。我们设计了一个数据中转站，允许公司内的用户登录，将数据放入home目录下，然后每隔一个小时，内网服务器通过rsync去获取数据，并sync到内网。

这里主要的问题是：防火墙一定要严格过滤，只允许内网服务器sync中转站的某个模块数据。

Upload.sh

#!/bin/bash

ProcNumber=`ps aux |grep rsync|grep -v grep|wc -l`

if [ $ProcNumber -eq 0 ];then

/usr/bin/rsync -acvz --delete --password-file=/root/rsync.pass root@10.x.x.100::home/exchange/upload/ >> /root/rsync.log

下载数据如何审核及自动归档

对于下载数据，我们要求进行人工任何。分多个层级，每一步需要审核人写审核意见，批准还是拒绝。任何一步拒绝，都将无法完成。

主要实现是：用户准备数据，发邮件给ithelp，然后ithelp会根据情况，分配审核数据的人员，其审核完成后，将数据放在第一级审核的目录dirA，然后由第二级审核人进行二次审核，完毕后将数据放入预备下载目录dirB，最后程序自动先备份数据，然后sync到数据中转站，并删除本地数据。DirA和dirB通过ACL设置了用户的访问权限，只有审核人员可以进入。

以上步骤，还可以插入数据检查及核实的程序，比如查看是否下载了源代码数据。

数据访问Audit实现

使用audit实现任何人访问源代码都将被记录，通过程序每天统计一次用户的访问记录，排序统计后自动发送邮件给相关的人员。

目前测试环境实现了5万个源代码的控制，但是只能在本地文件系统实现。否则会带来性能的问题。这样可以实现某个人一直查看的记录追踪，以及一段时间内比如离职前一周或者某一天将所有允许查看的文件都copy到其他目录的行为，可以当天晚上发送邮件给其安全部门的人员。

[root@dcs004 audit]# cat audit.rules |wc -l

51573

[root@dcs004 audit]# cat audit.rules|more

# This file contains the auditctl rulesthat are loaded

-w/test/test/linux-4.3/.get_maintainer.ignore -p r
-k kernelfiles

-w /test/test/linux-4.3/security/inode.c -pr
-k kernelfiles

-w /test/test/linux-4.3/security/Makefile-p r
-k kernelfiles

-w /test/test/linux-4.3/security/selinux/Makefile-p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/netlink.c -p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/.gitignore -p r
-k kernelfiles

-w /test/test/linux-4.3/security/selinux/hooks.c-p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/Kconfig -p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/selinuxfs.c -p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/nlmsgtab.c -p r
-k kernelfiles

-w /test/test/linux-4.3/security/selinux/netnode.c-p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/netif.c -p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/netport.c -p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/netlabel.c -p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/exports.c -p r
-k kernelfiles

-w/test/test/linux-4.3/security/selinux/xfrm.c -p r
-k kernelfiles

Audit结果如下，通过分析处理后可以实现监控的目的。

ype=PATH msg=audit(11/03/201510:43:13.610:198339) : item=0 name=test/linux-4.3/drivers/infiniband/hw/cxgb4/t4fw_ri_api.hinode=73185587 dev=00:14 mode=file,664 ouid=root ogid=root rdev=00:00nametype=NORMAL

type=CWD msg=audit(11/03/201510:43:13.610:198339) :
cwd=/tools

type=SYSCALL msg=audit(11/03/201510:43:13.610:198339) : arch=x86_64 syscall=open success=yes exit=3 a0=0x181ede0a1=O_RDONLY|O_NOFOLLOW a2=0x0 a3=0x666e692f73726576 items=1 ppid=39759pid=40352 auid=root uid=root gid=root euid=rootsuid=root fsuid=root egid=root sgid=root fsgid=root tty=pts2 ses=13728 comm=mv exe=/bin/mv key=kernelfiles

----

type=PATH msg=audit(11/03/201510:43:13.617:198340) : item=0 name=(null) inode=73185587 dev=00:14mode=file,664 ouid=root ogid=root rdev=00:00 nametype=NORMAL

type=SYSCALL msg=audit(11/03/201510:43:13.617:198340) : arch=x86_64 syscall=flistxattr success=noexit=-95(Operation not supported) a0=0x3 a1=0x0 a2=0x0 a3=0x0 items=1ppid=39759 pid=40352 auid=root uid=root gid=root euid=root suid=root fsuid=rootegid=root sgid=root fsgid=root tty=pts2 ses=13728 comm=mv exe=/bin/mvkey=kernelfiles

数据分级及权限控制

主要是通过NFS ACLv4来实现项目的权限控制，通过将特定人员加入访问许

可，项目经理可以自我控制任何公司的人员是否具有访问权限。但是，数据的分级，需要数据拥有人员去判断，IT只是提供一种手段，并不具有分级的能力。

IT提供合适的手段，让用户在系统内部，知道如何申请和如何控制权限即可。

以下是通过nfs v4设置权限示例：

$nfs4_setfacl -e /proj/xuesen

## Editing NFSv4 ACL for directory:/proj/xuesen

A::OWNER@:rwaDxtTnNcCy

A:g:GROUP@:tncy

A::EVERYONE@:tncy

A::projectmanagerA@powercore.com.cn:rwaDxtTnNcCy

添加下面行即可

A::username@powercore.com.cn:rxtncy ###read only###

A::username@powercore.com.cn:rwaDxtTnNcy ###rwx###

这里的projectmanager是由管理员设置的某个项目经理的账号，username是你期望设置的用户名

版本管理

1. CVS

2. Subversion

3. Clisoft SOS

4. IC
Manage

5. Git

CVS用于代码的管理

CVS作为unix系统下非常经典的版本管理系统，适合于代码的简单管理。对权限控制很差，基本上只能按照group的方式来控制谁可以check out,check in.CVS没有二进制管理能力，无法对各种非文本的文档，比如word进行管理，只能用于代码。

CVS是一个C/S模式的版本控制系统，用于在软件开发过程中记录文件版本，协调开发人员保证文件同步，从而保证项目正确的进行并行开发，并支持版本回滚、bug 跟踪和补丁生成。使用CVS可以有效地对软件开发的源代码和开发文档进行统一的管理和组织。

主要功能如下：

同步的最新修改

文件的版本回溯

多人同时修改同一个文件产生的冲突

项目的分支开发

文件权限控制

Redhat Enterprise默认安装有cvs，如果没有，请安装cvs的rpm包。

CVS的基本使用：

创建一个仓库

#groupadd cvs

#useradd –d /data/cvsroot -gcvs cvs

#cvs –d /data/cvsroot init

配置环境

$vi ~/.cshrc

$setenv CVSROOT /data/cvsroot

项目的初始导入

进入到你准备到如的初始源代码目录

$cvs import -m "somecomments" project_name vendor_tag release_tag

执行后：会将所有源文件及目录导入到/data/cvsroot/project_name目录下

vender_tag: 开发商标记

release_tag: 版本发布标记

这个project可以给某个unix group授权chmod 775 root:asic/data/cvsroot/project_name，这样所有asic group的人都可以check in和check out了。

项目的CheckOut

$cvs co project_name

同步到最新

$cvs update

修改文件后CheckIn

$ cvs ci -m "somecomments" file_name

添加新文件

创建好新文件后，比如：touch newfile

cvs add newfile

对于图片，Word文档等非纯文本的项目，需要使用cvs add –kb 按二进制文件方式导入(k表示扩展选项，b表示binary)，否则有可能出现文件被破坏的情况

比如：

cvs add -kb newfile.gif

cvs add -kb readme.doc

查看修改历史

cvs log file_name

cvs history file_name

其实CVS还有一种pserver的方式，可以使用客户端来进行管理。这样，即时/data/cvsroot没有被nfs 共享出来在其他服务器上也可以通过cvs进行版本控制。

分两步建立：

首先，建立xinetd启动服务

cat >>/etc/xinetd.d/cvspserver << "EOF"

service cvspserver

{

port
= 2401

socket_type = stream

protocol
= tcp

wait
= no

user
= root

passenv
= PATH

server
= /usr/bin/cvs

server_args = -f --allow-root=/data/cvsrootpserver

}

EOF

其次，客户端设置.cshrc (csh forexample)

$vi ~/.cshrc

setenv CVSROOT:pserver:username@192.168.x.x:/data/cvsroot

这里的username请换成自己的，后面的ip地址和路径，请换成符合实际服务器的路径。

Subversion

以下文档是很早的时候写的，跟最新版本可能存在一定差异，请注意。

subversion简介

多年来，版本控制系统一直都是CVS(Concurrent Versions System)的天下。CVS作为基

于RCS上建立，可以实现多用户协同工作的系统，可以记录文件的修改信息。这对于开发人员是非常有用的。

然而，CVS经过这么多年，也逐渐显示出一些不足，这个时候出现了一些商业的版本控制软件，比如Rational的ClearCase就是一个功能强大的商业软件，但是其价格也是非常昂贵的。

Subversion就是一种设计来解决CVS的局限性的软件。从2000年开始，Subversion开始开发，2001年8月开始用Subversion来管理Subversion的开发工作，到目前位置，subversion已经发展到了1.9.3版。

Subverion的主要特点有：

a.保留大多数CVS 特性，很多命令的选项基本通用

b.目录、重命名和文件meta-data都已经版本化，以前的CVS只能对文件版本化。

c.不可分隔的原子化提交，版本的变化是每次提交所有的文件版本都变化。

d.可以选择Apache作为网络服务器，集成于现有Apache控制的权限管理等。

e. 分支和标签是代价低廉（固定不变的）的操作

f.本地化的客户端/服务器，分层的库设计

g.消耗和修改部分的大小成比例，而不是数据的大小

h.Unix下的链接也可以实现版本化控制了

i.更加有效的处理二进制文件

j.更加人性化的命令输出

k.本地化提示信息。

Subversion的安装

Subversion是建立在一个可移植的APR（Apacheportable Runtime）上，所以Subversion可以建立在Apache的支持上，但是不仅限于必须使用Apache。Subversion可以做为Apache 2.0的一个模块，以WebDAV/DeltaV协议运行，也可以采用其自带的svnserver小型服务器运行。我们这里将采用Apache下WebDAV/DeltaV方式运行，所以需要检查Apache2.0是否已经安装好。

# yum install subversion

RHEL6默认安装的是1.6.11版本的subversion

Subversion和CVS的比较

1．不同的修订版本号。CVS将每个修改文件都赋予一个版本号，因此在CVS中，所有的文件版本号是不同的。

2．Subversion将目录版本化了。Subversion也开始跟踪目录的结构，任何对目录的svn操作都将会被记录，但是任何操作都必须提交后才生效。

3．离线工作更加方便。Subversion的工作原始副本在本地也有保留，任何对本地文件的修改，不需要连接到服务器去，就可以对比知道自己做了哪些修改。并且，提交修改的时候Subversion只将差异部分提交给服务器。

4．二进制文件和文本文件。CVS对二进制文件的版本化做的非常差，对于每次修改的二进制文件，CVS都会将更新的副本储存下来，大量占用了空间。而Subversion就不管是二进制文件还是文本文件，它都采用差异比较算法来表示更新的部分。CVS提交二进制文件需要带-kb标记，subversion不需要任何标记就可以识别二进制文件。

实例介绍

目前有一家公司，有两个不同的Group在进行开发，也就是说，两个项目组的成员是不允许获得另外一个项目组的开发代码的。当时，为了某些模块的协同工作，两个项目组的Project Manager又不得不互相取得对方的代码。

现在我们设计一个Subversion来做版本控制的系统，假设一共有6个用户，group1有user1，user2，manager1;group2有user3,user4,manager2.项目组分别为project1,project2.

由于我们的权限方面控制比较复杂，而适合权限复杂控制以及更好授权选择的方式，我认为以Apache+mod_dav_svn比采用独立的svnserve更加方便。

建立Apache+mod_dav_svn的subversion版本控制

(1)．安装mod_dav_svn

#yum install mod_dav_svn

(2）．基本的Apache配置

#cd /etc/httpd/conf

#vi httpd.conf

找到LoadModule部分，在LoadModule dav_module后面加入两行

LoadModule dav_module modules/mod_dav.so

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

在配置文件中，需要告诉Apache在什么地方保存的Subversion版本库，Location就是告诉Apache在特定的URL以及子URL下需要的特殊处理。

在文件的最后部分建立<Location>区块

DAV svn

SVNParentPath
/data/svn

</Location>

注意，任何Apache的web目录下不能存在svn这样的目录，否则会导致Apache不知道怎么解析。

(3)．配置认证部分

前面的配置会让所有能访问你web的人都可以获得你的文件，并且可以提交他的修改。所以，为了安全，也为了一个很好的秩序，我们必须添加认证。

DAV svn

SVNParentPath
/data/svn

# access control policy

AuthzSVNAccessFile/etc/httpd/conf/access-control-file

# Only authenticatedusers may access the repository

Require valid-user

# Howto authenticate a user

AuthType Basic

AuthName"Subversion repository"

AuthUserFile/etc/httpd/conf/svn-auth-file

</Location>

其中的svn-auth-file是做用户名和密码认证的，这个文件采用htpasswd来生成和修改。

$htpasswd –cm /etc/httpd/conf/svn-auth-file user1
(第一次使用需要带-c)

New passwd:*****

Re-type new password:*****

Adding password for user user1

$htpasswd –m /etc/httpd/conf/svn-auth-file user2

New passwd:*****

Re-type new password:*****

Adding password for user user2

…..

access-control-file文件的格式：

[groups]

project1 = user1 user2 manager1

project2 = user3 user4 manager2

[project1:/]

@project1 = rw

manager2 =rw

[/project2:/]

@project2 = rw

manager1 = rw

[/project2:/secret]

manager1 =

以上配置允许user1,user2,manager1,manager2访问project1的所有文件，并且都可以读写；user3,user4,manager2访问project2的所有文件可以读写，但是manager1只允许读写除了secret目录下的所有其他文件。

建立过程及基本使用

(1)．CreatRepository

基本语法：

$svnadmin create
/data/svn/project1

#chmod 755 /data/svn

$svnadmin create /data/svn/project1

$svnadmin create /data/svn/project2

建立两个项目组的库，我们采用了默认的FSFS存储方式。

$ls /data/svn/project1

conf/ dav/ db/ format hooks/ locks/README.txt

(2)．导入文件到Repository

我们已经建立了库，所以该我们导入我们的源文件到库里边的时候了。我们首先来准备一下两个项目组的文件，然后导入到库里。

A．准备需要导入的文件

$cd /home/svn

建立project1的文件目录结构，源文件在/somepath/source1/下面，是project1的项目源代码。

$mkdir source1

$mkdir source1/trunk

$mkdir source/branches

$mkdir source/tags

$ls source1

$mv /somepath/source1/*
source1/trunk/

project2的建立方法和上面类似

B．导入项目文件到库里

$cd source1

$svn import --message “Intial files for Project1”
file:///data/svn/source1

Adding
config.txt

Adding
xconnect_config.txt

Adding
ASIC_ADDR_SYNC

……

Project2的导入方法类似

导入完毕后，可以删除刚才准备的源文件了。

$rm –rf source1 source2

(3)．获取一份源文件的拷贝

以用户user1的身份登陆系统，在自己的Home目录下，可以用命令svn checkout

的方式获得一份subversion控制下的源文件。如果不特别指名，获得的文件在本地目录

和在subversion下面的目录结构一致。所以，我们为了区分，应该指定一个本地的目录

名。

$svn checkouthttp://domain/project1/trunk
project1_trunk

[user1@server ~/test]$svn co http://domain/svn/project1/trunk project1_trunk

Authentication realm: <http://domain:80> Subversionrepository

Password for 'user1':

A
project1/trunk/config.txt

A
project1/trunk/xconnect_config.txt

A
project1/trunk/ASIC_ADDR_SYNC

A
project1/trunk/ASIC_ADDR_SYNC/SW2ASIC_20051103

A
project1/trunk/ASIC_ADDR_SYNC/SW2ASIC_20051103/addr.txt

(4)．编辑和提交修改

编辑文的文件，可以用你喜欢的任何编辑器，我们现在添加一个文件.

$touch test.txt

Add a line for this file

$svn add test.txt
添加一个文件到subversion，但是直到后面提交后才才库中生效

$svn status
查看哪些文件有变化

A
test.txt

$svn diff test.txt
比较本地文件和库中的不同

Index: test.txt

================================

--- test.txt
(revision0)

+++ test.txt
(revision0)

@@ -0,0 +1 @@

+Add a line for this file

$svn ci –m “add a line for test.txt”
提交修改了的文件

Adding
test.txt

Transmitting file data .

Committed revision 3.

$svn log test.txt 查看变化历史

---------------------------------------------------------------------

r3 | admin | 2005-11-12 14:43:36+0800 (Sat, 12 Nov 2005) | 1 line

add a line

---------------------------------------------------------------------

$svn update 获得最新的版本，使用这个命令获得他人的最新更改。

如果发生冲突，使用svn resolve解决

(5)．Svn客户端常用命令

svn add
//添加一个文件

svn checkout(coi)
//从苦衷获取一个工作拷贝

svn cimmit(ci)
//提交当前工作拷贝的更改到代码苦，如果出现冲突需要解决。

svn copy(cp)
//做一个工作的拷贝

svn delete(del,remove,rm)
//删除本地或者svn库中的文件或者目录

svn diff(di)
//比较某个文件和库中对应的文件的不同，和系统的diff命令类似

svn export
//导出一个无版本控制的目录树拷贝，用于可以运行的版本需要导出。

svn import
//将当前目录下的文件导入到库中

svn info
//查看当前目录下的某个文件或者文件夹的信息

svn list(ls)
//列出当前拷贝的文件

svn mkdir
//在本地或者库中新建一个文件夹

svn move(mv,rename,ren) 类似于系统的mv命令

svn status(stat,st)
//svn工作拷贝的当前状态，和上次提交或者update后的对比

svn update(up)
//将svn库中的文件同步到本地

(6)．创建一个Tag和Branch

Subversion创建Tag和Branch和CVS不一样，它采用的是copy方式。

A．创建一个Tags，只能这个项目的Project Manager负责，下面以manager1用户登陆操作。

$svn copy –m “Create Tag version1” [url=]file:///data/svn/project1/trunk/[/url][url=]file:///data/svn/project1/tags/version1[/url]

$svn list [url=]file:///data/svn/project1/tags[/url]

version1

B．创建一个Branch

$svn
copy –m “createBranch a” [url=]file:///data/svn/project1/trunk/[/url][url=]file:///data/svn/project1/branches/brancha[/url]

以user1登陆

$svn switch http://domain/svn/project1/branches/brancha

这样以后user1就以brancha作为工作的库目录，从这里开始作为分支。

(7)．Merging a Branch

(8)．Windows客户端的安装和使用

下载TortoiseSVN-xxx.msi，安装，然后CheckOut一个库的拷贝。

Clisoft SOS介绍

a.
业界最完整的版本控制工具. 具有动态连结及智能快取等强大功能

完整得知所有使用者档案修改, 增减, 开启等记录...
节省硬件的支出, 让系统管理员更有效控制数据的管理与储存
对于硬件和软件设计资源 (design resouce), 设计者可以更有效的取得及运用
单键标注(Tag)整个工作目录下所使用的版本.
数据库快照(Snapshot)及最完整的安全控管机制.
可任意任务分组¸ 控制组员可擦写之目录及档案
最简易的操作接口, 无需管理员. 工程师一小时上手
提供命令模式, 易于与EDA工具整合.
内建 Bug Tracking 功能, 可通知同组伙伴所须修改之错误.
提供丰富的管理工具及 Trigger 功能.
与 Cadence DFII 完整结合
提供工作交接及内部教育训练一个最佳平台环境.
提供最佳异地开发功能

这个软件主要是针对全定制IC设计的，可以嵌入：

Cadence Virtuoso

Custom IC

Agilent Advanced Design System(ADS)

Mentor Pyxis

Synopsys Laker

Synopsys Custom Designer

SOS是商业软件，只要购买了，安装和配置完全由厂家支持，这里就不再做详细的介绍了。

IC Manage

没有接触过，据说也是一个不错的IC公司喜欢用的版本管理软件。

git

很好的一个分布式版本管理软件，在开源软件开发行业使用非常广泛。不过目前在IC设计行业所见不多，也许我们IC行业太落后了，没互联网和开源界对新技术的接受能力强。我们习惯用我们熟悉的东西。

搭建：

(1) yum install git

[root@eda ~]# git --version

git version 1.8.3.1

(2)创建git用户

[root@eda ~]# git --version

git version 1.8.3.1

[root@eda ~]# cd

[root@eda ~]# pwd

/root

[root@eda ~]# useradd git

[root@eda ~]# passwd git

Changing password for usergit.

New password:

Retype new password:

passwd: all authenticationtokens updated successfully.

[root@eda ~]# su - git

[git@eda ~]$ mkdir srv

[git@eda ~]$ ls

srv

[git@eda ~]$ cd srv

(3)初始化项目

[git@eda srv]$ git init--bare proj.git

Initialized empty Gitrepository in /home/git/srv/proj.git/

[git@eda srv]$ ls

proj.git

(4)Clone

[git@eda work]$ git clonegit@localhost:srv/proj.git

Cloning into 'proj'...

git@localhost's password:

(5)添加文件

[git@eda work]$ ls

proj

[git@eda work]$ cd proj/

[git@eda proj]$ touch abc.txt

[git@eda proj]$ vi abc.txt

wgh

test

"abc.txt" 2L, 9Cwritten

[git@eda proj]$ ls

abc.txt

[git@eda proj]$ pwd

/home/git/work/proj

[git@eda proj]$ git addabc.txt

[git@eda proj]$ git commitabc.txt -m "test file"

*** Please tell me who youare.

Run

git config --global user.email"you@example.com"

git config --global user.name "YourName"

需要设置提交者的个人信息

[git@eda proj]$ git config--global user.name "Guanghui"

[git@eda proj]$ git config--global user.email "wanggh@gmail.com"

(6)提交文件

[git@eda proj]$ git commitabc.txt -m "test file"

[master (root-commit)0455f79] test file

1 file changed, 2 insertions(+)

create mode 100644 abc.txt

[git@eda proj]$ git pushorigin master

git@localhost's password:

Counting objects: 3, done.

Writing objects: 100% (3/3),215 bytes | 0 bytes/s, done.

Total 3 (delta 0), reused 0(delta 0)

To git@localhost:srv/proj.git

* [new branch]
master -> master

[git@eda proj]$

(7)查看变化是否提交

我们需要重新git clone一份

[git@eda ~]$ git clonegit@localhost:srv/proj.git

[git@eda ~]$ cd proj/

[git@eda proj]$ ls

abc.txt

[git@eda proj]$ git log

commit0455f7997a895e5ffea3f016ec04bf2bdb7b25ad

Author: Guanghui <wanggh@xmail.com>

Date:
Fri Apr 15 21:44:12 2016 +0800

test file

发现已经存在我们刚才添加进入的一个文件了。

权限管理

要方便管理公钥，用Gitosis；

要像SVN那样详细地控制权限，用Gitolite

大型IC设计中心的IT环境

相关推荐