IMPROVEMENT OF COMPUTER SYSTEMS FOR J-PARC MR CONTROLNorihiko Kamikubota#,A), Susumu YoshidaB), Shigenobu MotohashiB), Takao IitsukaB), Hiroyuki NemotoC),
Daisuke TakahashiB), Noboru YamamotoA), Shuei YamadaA), Kenichi C.SatoA), Hidetoshi NakagawaA)
A)
J-PARC Center, KEK and JAEA, 2-4 Shirakata Shirane, Tokai-mura, Ibaraki, Japan, 319-1195
B)
Kanto Information Service (KIS), 8-21 Bunkyo, Tsuchiura, Ibaraki, Japan, 300-0045
C)
ACMOS Co. Ltd., 2713-7 Muramatsu, Tokai-mura, Naka-gun, Ibaraki, 319-1112

Abstract
In J-PARC MR, major components of computer systems for MR controls were introduced in 2008. Since them, they
have been improved year be year. In this report, we focused on three components; sever CPU, control network, and disk
system. Reviews of 5-year operation and future perspectives will be given.

J-PARC MR制御計算機システムの進展#表１１．はじめに現在(2012)と運転開始時(2008)の主要Blade型 x台数 役割
J-PARC MR加速器は、2008年5月にビーム運転を2012 HS20 x2
サーバ用(web, login)開始した。その後着実に加速器性能を向上しつつ、2008から存命、HS21に移行予定
実験施設（HadronおよびNeutrino）へのビーム供給
HS21 x8
SL4.4/SL6.2 アプリ用を続けてきた。2011年3月の東日本大震災も乗り越HS22 x3
え、現在(2012年)は本格的な実験施設向けビーム供HS22 x6
SL6.2 仮想マシンの親給を行っている[1]。
[6]
各種サーバ、vioc 、など
J-PARC加速器制御システムはEPICSで整備された[2]
HS21 x3
SL4/SL5 RCS simulation用が、本報告ではMR制御システムの計算機インフ
HS22 x2
ラ部分に注目する。MR向け制御計算機資源には、サーバ用 (web, RDB, ldap, dhcp,..)
計算サーバ、制御ネットワーク、ディスクシステム、 2008 HS20 x4
HS21 x9
SL4/SL3 アプリ用などがあるが、いずれもビーム運転開始直前の2007
HS21 x2
SL4 RCS simulation用
年頃に集中して導入された [3]。これらの計算機資源が過去5年間どのように使用されまた増強されたか、 HS20 = Pentium D Xeon64-LV 2.8GHz / 1GB-memory
経験を総括して報告する。また、次の5年を見据え
HS21 = DualCore Xeon 5110 1.6GHz / 2GB-memory
た進展の方向について議論する。
HS22 = 4Core2Cpu Xeon E5504 2GHz / 20GB-memory

２．計算サーバ（CPU）

2.2 進展（5年間の運用で出てきた新しい方向）

2.1 概要主要な計算サーバ(CPU)として、MR制御用にはIBM社Blade serverを採用している。2007年にHS20型
Blade 5枚で運用を開始した。現在（2012年）は、総数29枚（HS20型5枚、HS21型13枚、HS22型11枚）に ま で 増 加 し た 。 な お 、 IOC （ Input OutputController）のCPUについては[4]を参照されたい。
表１に、現在（2012年）とMRビーム運転開始時（2008年）に運転に使用されたBladeの型・役割・台数を示す（予備・特殊用途のものは除いた）。３
種類の型それぞれで各Bladeは全く同等の性能・環境を持たせ、局所的に負荷の高いBladeがあれば、アプリやサーバを別のBladeに移動させて負荷を平滑化できる。このような体制で、運転・開発業務の需要を満たしてきた。Bladeの運転時CPU負荷について、2010年時点の報告がある[5]。
#仮想OS環境を利用して1台の計算機に多数の仮想マシンを搭載し、計算機資源を有効利用することが出来る。我々のサーバ計算機の主力OSであるSL6ではKVM（仮想OS環境）が標準装備されている。
2008年、主たるサーバ（web, RDB, ldap, dhcp, ..）は1 Bladeで1機能づつ稼動していた。現在（2012年）、サーバ機能のほとんどは親仮想マシン（数台）で稼動する仮想マシン（多数台）で動作している。また、仮想マシン上で動作するEPICS仮想IOC (vioc)がMR加速器の運転に投入されている[4,6]。
MR加速器の大強度化に伴い、ビームの振る舞いやロスのシミュレーション計算が重要になってきた[7]。 特 殊 な 仕 様 （ 巨 大 メ モ リ /48GB や 多 重Core/64coreなど）が必要なため汎用仕様のBladeになじまず、2010年からシミュレーション専用の計算機が導入されている。現在(2012年)は、2機種で計10台まで台数が増えた。

E-mail: norihiko.kamikubota@kek.jp- 741 -

2.3 総括
最初にBlade型サーバ計算機を選択し、需要と予算に応じて臨機応変に枚数を増やした戦略は良かった。今後は初期モデルのHS20型を退役させ、OSは初期のSL4から最新のSL6へ移行を進めていく。一方、シミュレーション用計算機の比重が増しているが、機種統一するなど管理を楽にする方向を模索していきたい。

loopや故障による大量trafficを検出してportを遮断する機能を組み込んだ。
(4) 冗長を無効にする温度障害：（3.5節参照）

３．制御ネットワーク
3.1 概要図１ 2012年5月の故障カメラのbroadcast
J-PARC加速器制御用ネットワークは、先行するLINAC向けの整備が2004年頃から始まり、Extreme社のBlack-DiamondとSummit-switchの構成が採用さ3.3 運用時のネットワークトラフィック量れた。MR向けは、既存部を拡張する形で2006年かMR制御ネットワークのトラフィックは、2010年
ら整備を始め、2008年夏にはHadron棟・Neutrino棟
時点ではMR各電源棟（D1,D2,D3）で20-60Mbpsとを含むMR加速器全エリアをカバーするに至った。
[5]
報 告 さ れ て い る 。 2012 年 6 月 、 ビ ー ム運転中の2008 年 夏 、 MR 各 建 屋 （ 5 ヶ 所 =D1,D2,D3, HD,Neutrino向け(FX)とHadron向け(SX)の両運転モード
NU）に各1台の24port switch（計5台）、中央制御棟でのトラフィック量を計測した（表２）。また、同に2台の48port switch、を配備した。LINACと共通のじ時期、FX運転時のディスクシステムへのデータ冗長コア(Black-Diamond、中央制御棟)は、リング構
転送量はread/writeで55Mbps/60Mbpsであった。
造により1ヶ所の故障がシステムを止めないよう設計されている。冗長コアから各switchはスター形接
表２ 2012年6月 加速器運転時トラフィック(bps)
続（各switch2系統の配線、計1Gbpsの容量）である。
建屋

3.2 5年間の障害事例

FX (Neutrino向け)
User-run 160kW-> CER 140 M<- CER
5M-> CER
90 M<- CER
6M-> CER
95 M<- CER
22 M-> CER
3M<- CER
0M-> CER 17-25 M<- CER
5-7 M-> out230 M<- in460M

SX (Hadron向け)
User-run 3.5kW-> CER70 M<- CER
5M-> CER 160 M<- CER5M-> CER
45 M<- CER
15 M-> CER
4M<- CER
4M-> CER no data<- CER no data-> out230 M<- in400M

2008年以降の5年の運用で、印象的な障害を記す。 D1(1) Neutrino switch障害：Neutrinoへは2009年から
D2ビームを供給している。NU棟のswitchが2010年3月,2010年5月, 2011年8月, 2012年4月と、3年の運用で計D34回故障した。いずれもfirmwareが暴走するなどの症状である。このswitchは末端部なので、故障するとHDNU棟全域が全滅する。2012年4月の故障では加速器運転を2時間35分停止させ（Neutrino実験再開まではNUもっと長時間かかった）、深刻な影響を及ぼした。
繰り返し故障するのはNU棟特有の問題があると思
CER03
われるが、原因は判明せず、対応は電源系統の確認など対症療法に留まる。
CER=中央制御棟計算帰室、CER03=計算機室のswitch(2) MR server用switch障害：MR制御用の計算サーバ（Blade server）やディスクシステムのLAN配線を、FX運転時のトラフィックの流れを図２に示す。
当初トラフィックの閉じ込めを期待して1 switchに
MR 各 電 源 棟 か ら 中 央 へ の 転 送 量 は そ れ ぞ れ
集約した。2011年10月、このswitchが故障し、MR制~100Mbpsに達し、合流する計算機室switch (CER03)
御システムは約5時間壊滅状態となった。このswitch
では200-500Mbpsのデータが流れている。
は2010年に導入されたが、故障の数時間前に何回かrebootを起こした以外の事前兆候はなかった。
(3) 想定外の異常トラフィック：2012年2月、保守作業のミスで光メディコンで光回線をloopさせ、broadcast増殖によりMR制御ネットワークが麻痺した。このケースでは、光回線のloop先が別建屋（しかも放射線管理区域）で、発見までに4時間かかった。2012年5月、LINACトンネル内のネットカメラが故障し、大量のパケットを吐き出してLINAC制御を停め、（図１）その後加速器運転再開まで約5時間かかった。放射線による経年損傷と見られる。
2012年夏のネットワーク機器更新では、各switchで図２ FX運転時のトラフィックの流れ- 742 -

3.5 空調によるネットワーク障害

3.4 Switch機種更新と故障を想定した工夫

3.4節で述べた徹底的な冗長化の工夫で、1ヶ所の制御switchは信頼性の高い機器のはずであるが、故障では加速器運転が止まらない、また故障してもMRに限っても何度も故障している。冗長機能でシ復旧しやすい環境が実現した、と考えていた。とこステムは停止しなかったが、3.2節で紹介した以外
ろが2011年11月、計算機室の空調整備（2式のうち1にも2例のswitch故障がある。
式）が停止して室温が上がり、冗長を組んだ複数のLINACの機器は2011年から順次機種更新されていswitchが揃って同時に落ちるという事件が起こった。
ることから、MRの機器も2011年後半～2012年前半
建設から数年の時間がたって計算機室の熱源が増え、に最新機種への更新を進めた。MRでは各建屋switch
1式のみの空調では冷却能力不足となっていた。3式
1台から2台として故障時の回避ルートを確保すると目の空調を追加することを検討している。
ともに、中央制御棟との回線を1Gbpsから10Gbpsにさまざまな検討や対処で、ネットワーク障害の頻増強した（HD, NUを除く）。MR建屋（D1,D2,D3）
度を下げる努力を尽くしてきたつもりであった。つで各2台（計6台）の48port switch、HD,NU建屋で各2くづく現実は想定を超えることを思い知らされた事台（計4台）の24port switch、中央制御棟に3台の例であった。
48port switch、 を 配 備 し た。一連の更新の最後となった2012年7月の更新・増強の内容を図３に示す。
４．ディスクシステム
これら更新・増強と平行し、MRで運転に使用するswitchは常に2台ずつpairを組ませるよう工夫した。
4.1 概要例えば計算機室のサーバ用switch pairでは、一方は奇数番portのみ（他方は偶数portのみ）を使用し、MR制御用のディスクシステムとして、2008年3月奇数番のBladeのみ（他方は偶数番のBladeのみ）をにIBM N3600 (NetApp)を導入した。それまでのDell接続する。仮に1台のswitchが停止しても残った他方server (PE2650)の250GBから9TBになっただけでなく、で加速器運転を継続できる。また、ラック上下の拡張性・信頼性も格段に向上した。ディスクシステ
LAN配線の移動だけで仮復旧できる（図４参照）。
ム が 提 供 す る の は、(a) 運転アプリ領域(/jk)、(b)User領域(/home)、(c) データ領域(/jkdataなど)、である。MR運転開始時(2008年)と現在(2012年)の容量を表３に示すが、データ領域が増設されているのが分かる。このディスクシステムをmountしているNFSclient数は、MRサーバ 約40台、MR IOC 約150台、端末 約30台、その他 30台程度、と推定している。
表３

図３

2012年7月のMR制御ネット機器更新・増強

現在(2012)と運転開始時(2008)のDisk
アプリ・ホーム領域

データ領域

2012/jk/home

1TB
1TB

2008/jk/home

1TB
1TB

/jkdata/jkdata2/jkdata3/jkdata

11TB
8TB
7TB
7TB

4.2 運用（データ量と障害事例）
MR加速器では、加速器機器のdata archive systemが整備されている[8]。Archiveの中で、各種波形データ（DCCT, BPM, SX-Spill, など）を記録するcadump
データがディスクを消費する。2012年、ビーム運転中のNeutrino向け(FX)とHadron向け(SX)の両運転モー ド で デ ィ ス ク 消 費 率 を 計 測 し た 。 FX で は50GB/day（2012年5月、5月1ヶ月で1.5TB）、一方SXでは 110GB/day（2012年2月）であった。
SX運転モードで加速器運転中の2012年2月、ディスクシステムは深刻な障害に陥った。この時、ディスク容量残量が逼迫したためビーム運転中に大量の不 要 デ ー タ 削 除 を 行 っ た が 、 通 常 20-30% の disk
controller CPU負 荷が100％となって多数の計算機（NFS client）が反応しなくなった。ディスクシス
テム負荷が高くなりすぎたと考えられている。

図４

Switch pairでのサーバ配線工夫による冗長化- 743 -

4.3 将来の方向
MR運転の各種波形データをきちんとArchiveすれば、おおむね~2TB/月の量のディスク消費となる。
これほど巨大なデータすべてを記録する意味があるのか、高機能のN3600に巨大データファイルを置く整合の悪さ、などの議論がある。
1年以上古いデータはあまりアクセスされないと考えられる。2012年4月、相対的に安価・大容量の新ディスクシステム（IBM X3630）を導入し、新しくデータ領域15TBを提供した。MR運転時は波形データをN3600に記録し、古くなったデータは運転休止時にX3630に移動する、というシナリオを策定した。15TBではせいぜい1年分なので、毎年継続してX3630相当のディスクを増やしていくことになる。
さらに良いシナリオが無いか、今後も検討を続ける。

参考文献[1] 佐藤洋一 他、”J-PARC Main Ring における大強度運転”、第９回加速器学会(this meeting)
小関忠、”J-PARC MR の運転状況”、加速器学会誌
2012 年 9 巻 1 号 p.30-40 (2012)[2] N.Kamikubota, et al., “J-PARC Control toward Future
Reliable Operation”, Proceedings of the ICALEPCS 2011,
Grenoble, France, Oct. 2011, p.378-381(EPICS homepage) http://www.aps.anl.gov/epics/[3] 上窪田紀彦 他、”J-PARC 計算機制御システムのインフラ整備”、第 4 回加速器学会、和光、2007 年 8 月、
p.378-380[4] 根本弘幸 他、”J-PARC MR 加速器制御における IOC統合管理”、 第９回加速器学会(this meeting)[5] 高木誠 他、”J-PARC MR 制御システムの CPU 負荷とネットワークトラフィック”、第７回加速器学会、姫路、2010 年 8 月、p.693-695[6] N.Kamikubota, et al., “Virtual IO Controllers at J-PARC
MR using Xen”, Proceedings of the ICALEPCS 2011,
Grenoble, France, Oct.2011 p.1165--1167[7] 佐藤洋一 他、”J-PARCMain Ring 速い取出し運転のビームシミュレーション：実測ビームロスとの比較
ベンチマーク、高繰り返しによるビーム増強の要点”、第８回加速器学会、つくば、2011 年 8 月、p.199-203[8] N.Kamikubota, et al, “Data archive system for J-PARC mainring”, IPAC10, Kyoto, Japan, May 2010, p.2680-2682- 744 -