從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連接的成本已經降到足夠低了?？梢詽M足一段時間的需求。

無論采用分布式還是集中式，都推薦在每個機柜上放一臺簡單2層交換機，用于設備的遠程管理口，比如服務器的ipmi端口。這樣可以不用隨時進出機房去開啟關閉服務器。

消防

機房的消防，目前主要采取的是七氟丙烷氣體消防。主要考慮的是，提前在

消防部門審批方案和報備，必須是當地有資質的建設方。另外，氣體釋放的方式最好是經過監控室人工確認，否則可能導致機房人員沒有按時撤離，窒息而死。

網絡結構

首先讓我們來看一個網絡的結構示意圖，因為這部分涉及到實際內容，我只能通過示意圖的方式來簡單講一下基本的要求。無法提供真實的網絡結構圖給大家看了。

1.內外網隔離

2.研發網絡跟辦公網絡隔離

3.研發網絡客戶端跟服務器隔離

4.MPLSVPN網絡

內外網絡隔離

我們通過多層防火墻對網絡進行了隔離，公司總出口有一個上網的防火墻，

用于隔離互聯網跟辦公網。我們對外提供的有限服務位于防火墻后面，這也是最容易被外部攻擊的區域。在這里，我們通過ACL等措施隔離辦公網絡流量，防火墻部署入侵檢測和殺毒等服務。

研發網絡跟辦公網絡隔離

研發網絡指的是我們設計芯片的網絡。這里一般采用兩種方式隔離，一種

是物理隔離，另一種是邏輯隔離，各有優缺點，按需采用即可。物理隔離的優點是安全，任何通過網絡入侵的機會將為零。但是缺點是實用性和方便性遇到困難，無法做到多個異地site協同工作。邏輯隔離是采用各種安全規范，嚴格限制研發網絡跟辦公網絡的交互，實現即時辦公網絡被入侵，依然可以保證研發網絡安全的網絡設計。這種優點是可以多site協助，跟外部交流容易。缺點就是存在安全錯誤導致的安全風險存在可能。

研發網絡的客戶端跟服務器分離

研發網絡的服務器端一般位于機房內，而客戶端位于工位。兩者之間如果不

能有效隔離，就會造成安全風險點大面積增加。同時，對內的安全防護就無從談起。使用，我們一般會在登陸客戶端跟設計服務器之間采用防火墻來隔離。同時，登陸服務器也需要采取各種安全措施，避免被內部用戶入侵控制。

MPLS VPN網絡

專線網絡有多種，常用的可能有MSTP/SDHMPLS。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設計中，經?？梢宰龅?倍的壓縮率，即容量提升了一倍。同時，還提升了IO能力，因為壓縮后的數據更小，有利于讀寫?，F代的CPU都很快，壓縮不會帶來太大的負擔。所以，可以放心使用。

高速SSD緩存，全閃存太貴，而采用SSD做緩存的方案，可以很大程度上將熱點數據放在高速SSD上，遇到調用的時候不再去磁盤中尋找，這樣可以很大程度上提供IOPS，是一種利用較低成本提供了較大效益的方案。

重復數據刪除，重復數據刪除功能可以在很大程度上減少磁盤空間的使用量，特別是針對某些應用，比如虛擬化及多版本開發環境。

Snapshot，這里的snapshot一定要跟SAN盤陣的區分開來，也跟LVM的不一樣?；趎etapp和zfs的snapshot功能，允許用戶自我管理不小心刪除的數據，隨時自己去恢復，減少管理員的麻煩。提高了用戶的滿意度。

NFSv4 ACL，由于其提供了很多高級特性，可以實現項目的管理方式，讓項目經理去管理目錄的權限，將IT從權限管理的繁瑣中解脫，同時，給項目經理足夠大的自由度，讓他們更快捷的實現自己的要求。

備份，是一個重要的話題，數據備份可能永遠都是在做后備，但是一旦需要恢復，備份就顯得格外重要。目前主要考慮采用D2D的備份+磁帶歸檔的方式實現長期的數據備份需求。

由于我們的環境主要是NAS存儲的NFS共享，滿足以上要求的主要有netapp的存儲及基于zfs的存儲系統，如oracle ZS4nexentastor等。

目前在國內做支持最好的依然是netapp存儲，但是netapp的銷售策略要小心，存在銷售控制價格的行為特別嚴重，甚至可以做到價格差異30%-50%的情況。因為是區域控價，你如果選定了必須用它，幾乎無任何的議價能力，被迫接受高價。在大廠商面前，用戶很弱勢。唯一的反擊就是絕對不要選擇某一家廠商的產品作為采購要求。

NFSv3/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的好處是寫入小文件加速，因為直接返回，但是讀取依然會很慢?，F在大量采用的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_jobJob <1234> is submitted to default queue 上面輸出中1234是分配給my_job的ID, normal即系統默認queue

提交并行job

$ bsub -n 8 myjobmyjob以并行JOB的方式執行，且需要8個cpu cores。比如在腳本中，hspice使用了-mt 8的情況下。用上面的命令會讓lsf幫你找到空閑的8個cpu core之后才提交給具體執行的主機。

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

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

然后可以得到jobID

$ bjobs -u allJOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAMESUBMIT_TIME1004 user1 RUN short hostA hostA job0 Dec 16 09:231235 user3 PEND priority hostM job1 Dec 11 13:551234 user2 SSUSP normal hostD hostM job3 Dec 11 10:091250 user1 PEND short hostA job4 Dec11 13:59

Kill掉自己的某個job

$ bkill 1234Job <1234> is being terminated

掛起和恢復job

$ bstop 3421Job <3421> is being stopped

$ bresume 3421Job <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

LSF是目前主要采用的任務管理軟件，目前歸屬于IBM，最新的版本是9。幾乎所有大的IC設計公司都采用的是LSF的軟件來做負載均衡。不過，這個軟件是商業軟件，授權費比較貴，大約要1-2萬一臺服務器(以core計費）。

下圖為lsload命令所顯示的結果，大家可以看到各臺服務器的負載，CPU利用率，剩余內存等信息。

LSF會自動去調度，找出最佳的后臺服務器，盡量做到負載均衡。所有的后臺服務器，用戶都不能直接登錄去run，這是由系統和網絡結構限制的。但是，對于用戶，要讓所有的操作做到最簡單，用戶不需要去了解復雜的后臺設計。

這里介紹一下LSF的一些使用

提交job

$bsub my_jobJob <1234> is submitted to default queue 上面輸出中1234是分配給my_job的ID, normal即系統默認queue

提交并行job

$ bsub -n 8 myjobmyjob以并行JOB的方式執行，且需要8個cpu cores。比如在腳本中，hspice使用了-mt 8的情況下。用上面的命令會讓lsf幫你找到空閑的8個cpu core之后才提交給具體執行的主機。

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

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

然后可以得到jobID

$ bjobs -u allJOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAMESUBMIT_TIME1004 user1 RUN short hostA hostA job0 Dec 16 09:231235 user3 PEND priority hostM job1 Dec 11 13:551234 user2 SSUSP normal hostD hostM job3 Dec 11 10:091250 user1 PEND short hostA job4 Dec11 13:59

Kill掉自己的某個job

$ bkill 1234Job <1234> is being terminated

掛起和恢復job

$ bstop 3421Job <3421> is being stopped

$ bresume 3421Job <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實現。

數據管理

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.passroot@10.x.x.100::home/exchange/upload/ >> /root/rsync.log

Fi

下載數據如何審核及自動歸檔

對于下載數據，我們要求進行人工任何。分多個層級，每一步需要審核人寫審核意見，批準還是拒絕。任何一步拒絕，都將無法完成。

主要實現是：用戶準備數據，發郵件給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=0name=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=rootuid=rootgid=root euid=rootsuid=root fsuid=root egid=root sgid=root fsgid=root tty=pts2 ses=13728 comm=mvexe=/bin/mvkey=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. ICManage

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下需要的特殊處理。

在文件的最后部分建立區塊

DAV svn

SVNParentPath/data/svn

注意，任何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

其中的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

Addingconfig.txt

Addingxconnect_config.txt

AddingASIC_ADDR_SYNC

……

Project2的導入方法類似

導入完畢后，可以刪除剛才準備的源文件了。

$rm –rf source1 source2

(3)．獲取一份源文件的拷貝

以用戶user1的身份登陸系統，在自己的Home目錄下，可以用命令svn checkout

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

和在subversion下面的目錄結構一致。所以，我們為了區分，應該指定一個本地的目錄

名。

$svn checkouthttp://domain/project1/trunkproject1_trunk

[user1@server ~/test]$svn cohttp://domain/svn/project1/trunkproject1_trunk

Authentication realm: Subversionrepository

Password for 'user1':

Aproject1/trunk/config.txt

Aproject1/trunk/xconnect_config.txt

Aproject1/trunk/ASIC_ADDR_SYNC

Aproject1/trunk/ASIC_ADDR_SYNC/SW2ASIC_20051103

Aproject1/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查看哪些文件有變化

Atest.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”提交修改了的文件

Addingtest.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

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

以user1登陸

$svn switchhttp://domain/svn/project1/branches/brancha

這樣以后user1就以brancha作為工作的庫目錄，從這里開始作為分支。

(7)．Merging aBranch

(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

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

test file

發現已經存在我們剛才添加進入的一個文件了。

權限管理

要方便管理公鑰，用Gitosis；

要像SVN那樣詳細地控制權限，用Gitolite