向上に関する研究

(1)

交換システムへ既製コンピュータを適用するための可用性と実時間性の

向上に関する研究

池邉隆

電気通信大学大学院情報システム学研究科博士（工学）の学位申請論文

2008 _年 3 _月

(2)

交換システムへ既製コンピュータを適用するための可用性と実時間性の向上に関する研究

博士論文審査委員会

主査本多弘樹教授

委員曽和将容教授

委員加藤聰彦教授

委員多田好克教授

委員吉永努准教授

(3)

著作権所有者

池邉隆 2008

(4)

The switching system provides lifeline network service such as telephony service, and is required to serve more than 99.999% time of a year. Typical network service requires to be performed as real time; the call control should be performed within deadline. Therefore switching system of PSTN (Public Switched Telephone Networks) had been developed by using specialized hardware and software in order to satisfy service availability and real time capability.

Though, the cost of the specialized switching system is high, the most of the specialized switching system is aging, and hard to obtain the repair parts. Consequently, the demand of replace aging specialized switching system by using cost effective COTS (Commercial off-the-shelf) such as Intel Architecture computer, is so high. However, it is difficult to satisfy the requirements of the switching system by just applying COTS system. Especially, availability and real time capability are missing on COTS system.

In this paper, I propose the approaches that improve availability and real time capability of COTS system, using Intel x86-64 CPU SMP machine and Linux, in order to satisfy requirements of the switching system.

First, I propose the live patching approach that enables dynamic modiﬁcation of process and kernel without restarting. The proposed approach enables to ﬁx the software without restarting, within deadline, and without disrupting real time service.

Then I propose the priority control of disk IO that reduces the maximum response time of high-priority write system call. The adoption of COTS components causes the call processing to record transaction log to hard disk drive, and that recording increase in the service response time. The proposed approach reduces bottlenecks of write mechanism in the kernel.

The proposed approaches enable to adopt COTS system to switching system. The approaches are not only for switching system but also for the system which use COTS system and improve the availability and the real time capability.

(5)

近年ライフラインたるネットワークサービスの交換システムに既製コンピュータであるIA サーバ(Intel Architecture)に代表されるデファクトスタンダードたるCOTS (Commercial

oﬀ-the-shelf)を適用することが要望されている．交換システムが提供するネットワークサー

ビスはライフラインたるサービスであり，年間99.999%以上のサービス稼働時間であることが要求される．同時に実時間性が要求され，サービス処理を要求される時間以内に実施することが求められる．PSTN (Public Switched Telephone Network)及びISDN(Integrated Services Digital Network)に代表される電話サービスを提供するデジタル交換システムには，

従来，専用コンピュータによるシステムが適用され，要求される可用性と実時間性を実現してきた．

専用コンピュータの多くは製造から長い歳月が経過し，ハードウェアが老朽化，保守部品の製造が困難となっている．このため専用コンピュータは更改の必要性に迫られている．

しかし，単純に交換システムに既製コンピュータを適用するだけでは，交換システムに要求される可用性及び実時間性をはじめとした要件を満たせない課題が存在する．特に可用性と実時間性はサービス提供上優先度を高く取り組むべき課題である．そこで本論文ではCOTSで

あるIAサーバとLinuxを用いて特にサービス提供に直結する可用性と実時間性を向上させ，

交換システムに既製コンピュータを適用するための方式を研究する．

第一にLinuxを使用したシステムの可用性の向上技術として，ソフトウェア修正方法に着

目する．既製コンピュータのソフトウェア修正では，修正されたロードモジュールを再ロードする必要があり，クラスタを用いた稼動系切換を行なったとしても，稼動系切換時間が長期化しサービスの可用性が低下する．そこでプログラムを再起動させることなく，かつサービスの実時間性を損なわずにソフトウェアをオンライン修正することで，サービスの可用性を向上させる．本論文ではシステム上の主要ソフトウェアであるユーザプロセスとカーネルを，サービスのタイムアウト値以内の停止時間で，稼働中のまま修正するライブパッチ方式を提案しており，ソフトウェアの再起動に伴うサービスの停止時間を削減し，サービスの可用性を向上させる．第二にサービス処理の高優先化による実時間性の改善として，ディスクIOの優先度制御技術を提案する．電話サービスでは障害復旧時にも途切れなくサービスを継続するために，

個々のセッションの状態遷移のトランザクションログをディスクに記録する．しかしLinux のディスクIOは十分な優先度制御技術を有しておらず，ディスクが輻輳する場合，優先度が高い書込み処理が遅延しサービスの実時間性に影響を及ぼす．本論文で提案するディスクIO 優先度制御技術では，IO 処理を優先度に応じた順序で処理することで，システムコール単位の処理レスポンスタイムを低減し，サービスの実時間性向上を行なう．

本論文で有効性が実証された技術は交換システムへ既製コンピュータ適用可能とするが，これら技術は交換システムにしか適用できないわけでない．これら技術は様々な領域のシステムへと適用可能であり，コストに優れる標準的な既製コンピュータを使用したシステムにより提供されるサービスの可用性及び実時間性を向上することが可能である．

(6)

図目次

2.1 伝送路でのデジタル交換システムの配置. . . 5

2.2 伝送路及び信号路でのデジタル交換システムの配置. . . 6

2.3 VoIPでの交換システム . . . 8

2.4 専用コンピュータによる交換システムのアーキテクチャ . . . 12

2.5 既製コンピュータを用いた交換システムのアーキテクチャ . . . 18

2.6 COTSベースの交換システムのアーキテクチャ . . . 19

3.1 jump命令上書きによる修正関数の実行例 . . . 32

3.2 ライブパッチ方式を使用したシステムの運用 . . . 35

3.3 ライブパッチ方式によるオンライン修正. . . 36

3.4 カーネルのメモリ管理を介した特権メモリアクセス. . . 37

3.5 コンパイルによるシンボル情報の出力 . . . 39

3.6 jump命令の上書き. . . 42

3.7 PLT及びGOTによる実行遷移 . . . 43

3.8 修正対象プロセスの実行状態停止 . . . 45

3.9 ターゲットソフトウェアのスタック確認による実行アドレスとの競合確認 . . 46

3.10 カーネルライブパッチでのカーネルの停止と分岐命令の上書き. . . 48

3.11 ライブパッチ方式のシーケンス . . . 49

3.12 プロセスライブパッチ実施時の修正対象プロセスの停止時間 . . . 53

3.13 プロセスライブパッチにてスケジューラ上のプロセス実行状態を停止するまでの時間 . . . 55

3.14 プロセスライブパッチでのjump命令上書き時間 . . . 56

3.15 プロセスライブパッチにてスケジューラ上のプロセス実行状態を復旧するまでの時間 . . . 57

3.16 カーネル修正時のカーネル停止時間 . . . 59

4.1 永続データの記録方法 . . . 62

4.2 セッションの状態遷移とトランザクションログ記録. . . 64

4.3 OSのページキャッシュとディスクキャッシュ，同期書込みと非同期書込みの関係. . . 66

(10)

4.4 Linuxの同期書込みの概要 . . . 68

4.5 EXT3ファイルシステムの書込み処理. . . 70

4.6 IOスケジューラの処理 . . . 71

4.7 IOアクセス輻輳時の問題 . . . 76

4.8 既存IOスケジューラを使用した場合の高優先Writeシステムコールのレスポンスタイム . . . 77

4.9 IOスケジューラの問題 . . . 79

4.10 IOスケジューラの改善 . . . 81

4.11 EXT3ファイルシステムの問題 . . . 82

4.12 EXT3ファイルシステムの改善 . . . 84

4.13 高優先Writeシステムコールのレスポンスタイム. . . 86

4.14 実験中の平均IOスループット. . . 87

4.15 レスポンスタイムの頻度グラフ . . . 89

4.16 レスポンスタイムのパーセンタイルグラフ . . . 90

(11)

表目次

2.1 要求条件と達成技術のまとめ . . . 26

3.1 既存のオンライン修正方法の比較 . . . 31

3.2 評価環境 . . . 52

4.1 評価環境 . . . 78

(12)

第 1 _章

序論

1.1 本論文の目的と意義

近年のコンピュータ技術の発展，とりわけIAサーバやCOTS(Commercial oﬀ-the-shelf) に代表される既製コンピュータを使用したシステムの技術進歩は，従来専用コンピュータや汎用コンピュータにて実現されてきた様々なコンピューティングを既製コンピュータで代替可能としている．

例えば従来極めて高性能なスーパーコンピュータに代表される専用コンピュータにて実現されてきたバッチ型の大規模計算は，複数のIAサーバをローカルネットワークで接続するHPC クラスタリングや，広域ネットワークで多数のパーソナルコンピューターを接続するGridコンピューティングにより代替されつつある．

また，従来メインフレーム等に代表される汎用コンピュータにて実現されてきた企業内の人事システムや給与システムといった業務管理システムのみならず，銀行の勘定系システムや，

交通機関の座席予約システム，証券取引システム等，企業の営利活動に直接関係するソフトリアルタイムかつミッションクリティカルなコンピューティング処理に，既製コンピュータを使用したシステムによる代替が進んでいる．

このようにIAサーバに代表される既製コンピュータの技術進歩による，専用コンピュータや汎用コンピュータからのマイグレーションは，ソフトウェアの開発効率を向上させ，ハードウェアにかかるコストを下げ情報化社会の発展に大きく貢献している．

さて，専用コンピュータの１つである交換システムは，独自の技術により以下に示す要件を満たし，ライフラインたるサービスである電話サービスを提供してきた．

可用性通信事業者では一般的に年間99.999%以上のサービス稼働時間であることが要求される．

実時間性電話サービスは実時間性を要求されるサービスであるため，サービスの処理を一定の処理時間以内に実施することが要求される．

問題解析性問題発生時には原因を確実に解析できるよう十分な障害情報を収集できること，

同時にこの障害情報収集によりサービス提供へ影響を与えないことが要求される．

(13)

保守性サービス提供時に異常が発生した場合には即座に対応が行えるよう，迅速な障害通知を行えることが要求される．また異常時の制御は保守者によって行われるだけでなく，

ある程度までシステム自律で障害回復を試みることも要求される．

生産性サービス追加や変更が頻繁に発生してもソフトウェアの生産性を高く保ち，維持管理コストを低く抑えることが要求される．

性能上述の実時間性を保ちながら数百から数千のセッション制御を多重処理で実施することが要求される．

PSTN (Public Switched Telephone Network)及びISDN(Integrated Services Digital Net-

work)に代表される電話サービスを提供する従来の交換システムでは，専用に研究開発された

独自技術を有する専用コンピュータにより前述の要件を満たし，信頼性の高いサービスを提供可能とするが，非常にシステムのコストが高い．今日の電話サービスをはじめとしたネットワークサービスには，より安いコストで従来と同様もしくは従来以上の信頼性を持つサービスを提供することが求められている．

更に専用コンピュータによる交換システムの多くは製造から長い歳月が経過しておりハードウェアの老朽化や保守部品の製造が困難となっており，早急な対応が必要である．

しかし，単純に今日の代表的な既製コンピュータであるIAサーバと，昨今通信系システムに適用されるOSであるLinuxを交換システムに適用するだけでは，前述の要件を満たすことは困難である．特に可用性と実時間性は，今日既製コンピュータが適用されているコンピューティング領域で必要とされるレベルよりもはるかに厳しいものであり，交換システムのサービス提供上外す事のできない要件である．

IAサーバでも専用コンピュータのようなベンダ独自のハードウェアの高可用化技術を有したハードウェアも存在し，このようなハードウェアを適用することも一案ではあるが，高価である。更に独自のハードウェアの高可用化技術に依存したシステムアーキテクチャを選択すると，そのハードウェアが製造困難となった際に新たなシステムへの更改のコストが増加する．

またそのハードウェアを製造するベンダしか選択できず，ベンダロックインが発生し調達コストが増大する．コストダウンのためには極めて一般化・標準化されたハードウェア及びソフトウェアを調達し，それら標準的かつデファクトスタンダードである既製製品をベースに交換システムに要求される要件を満たすべく課題を解決する事が重要である．

今後既製コンピュータにて，専用コンピュータによる交換システムを更改するためには，既製コンピュータの可用性および実時間性を始めとする課題の解決が必要である．特にサービス提供に直接影響を与える可用性と実時間性は優先度を高く課題解決に取り組む必要がある．そこで本論文では交換システムに既製コンピュータを適用するために可用性と実時間性を向上させる研究に取り組む．

(14)

1.2 本論文で取り組む課題

今日のハードウェアの処理能力はプロセッサの進歩をはじめとする技術進歩により，交換システムのサービス処理である呼処理へ十分適用可能な処理性能を有している．しかし交換システムの要件は処理性能だけではなく，上述した各種要件を満たすことが求められる．

特にこれら要件の中でも，サービスの提供に密接に関係する可用性と実時間性は，交換システムにとって重要な要件である．

しかし既製コンピュータのソフトウェアの可用性は，ハードウェアの可用性にはるかに劣る．これは今日の高度なソフトウェアの状態遷移はハードウェアの状態遷移よりも圧倒的に複雑かつ大規模であり，ソフトウェアのデバッグにて全ての状態の組み合わせでの走行ルートを試験することは極めて困難である．このため数多くのバグを内包したままリリースされる事が多く，バグが顕在化した際，システムを停止しての対応が必要となり，結果としてサービスの可用性が低下する．

また実時間性は，タスクの実行や割り込みを制御するソフトウェアによって実現される．現在の既製コンピュータではハードディスクのIO処理においてタスク単位の優先度は考慮せず，ディスク全体の最適化を最優先とするため，呼処理に伴うディスクIO処理が遅延し，結果としてサービスの実時間性を著しく低下させてしまう．そこで本論文では上記課題を以下に示す取り組みにて解決する．

第一にシステムの可用性の向上技術として，システム上の主要ソフトウェアであるユーザプロセスとカーネルを稼働中のまま修正することで，ソフトウェア修正時の再起動に伴うサービスの停止時間を削減するライブパッチ技術を提案し，その有用性を示す．

第二にIO処理の高優先化による実時間性の改善に取り組む．電話サービスでは障害復旧時にも途切れなくサービスを継続するために，個々のセッションの状態遷移をディスクに記録する動作を行なう．しかし既製コンピュータのディスクIO処理は十分な優先度制御技術を有しておらず，IO処理が競合する場合優先度が高いサービス処理が遅延する．本論文ではIO処理を優先度に応じた順序で処理することで，システムコールあたりのレスポンスタイムを削減するディスクIO処理の優先度制御技術を提案し，その有用性を示す．

1.3 本論文の構成と範囲

本論文は5つの章から構成される．第1章は本章であり，本研究の目的と意義について述べた上で，本研究で取り組む課題を明らかにする．第2章では，本研究で取り組む交換システムへのCOTS適用に向けた技術動向を示した上で，本研究の位置付けを明らかにする．第3章では従来技術では可用性に課題を持つソフトウェア修正を対象に，提案したライブパッチ方式について詳細に述べる．第4章では従来方式では実時間性に課題を持つディスクIO制御処理を対象に提案したディスクIOの優先度制御方式について詳細に述べる．第5章は本研究の結論として，研究成果の概要についてまとめる．また，本研究の今後の課題についても述べる．

(15)

第 2 _章

交換システムへの既製コンピュータ適用にむけた技術動向と本研究の位置づけ

2.1 交換システムの概要

交換とは多数の端末が接続される通信網において，任意の端末間に通信のための回線及びセッション（呼）を設定することであり，この回線及びセッションの接続を行なうものが交換システムである．

2.1.1 デジタル交換システムの概要

デジタル交換システムにおいて，通信のための回線は電話番号の値により選択される．一般に加入者を直接収容する加入者交換システム(Local switch system)は市単位などの地域単位で配置され数万〜10万人程度を収容する．この加入者交換システム間を中継交換システム (Tool switch system)が結びつけ(図2.1)，ホップ・バイ・ホップで回線（トランク）を確立し，確立された回線に音声・データ等が伝送される．この際，End-to-End間で何らかの理由で1箇所でも回線が確保できない場合は，そのサービスセッションである呼は確立されず呼損となる．

またデジタル交換システムでは，回線を割り当てるために交換システム間で制御信号である共通線信号を伝送路とは別の専用の通信網と専用の交換システムであるSTP（Signal Transport Point）を用いてやりとりする(図2.2 )．

デジタル交換システムはこれらセッション制御に加えて，輻輳時の制御，課金管理，付加サービス管理をリアルタイムかつ多重に行うことができ，かつ遠隔地からの集約監視，各種制御を行うことが可能である．

端末間の距離が長距離になるほど，端末間の回線は複数の交換システムを経由して設定され，音声・データは設定された多数の回線を経由して伝送される．このため個々の交換シス

(16)

LS LS LS

TS

Local switch layer Toll switch layer

Terminal

LS LS

LS TS TS

Terminal

Terminal Terminal

・・・・・・・・・・・・・・・・

LS:Local Switch TS:Toll Switch

LS LS

LS TS

Local switch layer Toll switch layer

Terminal

LS LS

LS TS TS

Terminal

Terminal Terminal

・・・・・・・・・・・・・・・・

図2.1.伝送路でのデジタル交換システムの配置

(17)

LS LS LS

TS TS

LS LS LS

TS SEP SEP SEP

SEP

SEP SEP

SEP SEP SEP STP

Transport Network

Signaling Network

SEP:Signal End Point STP:Signal Transfer Point STP

STP

LS LS

LS

TS TS

LS LS LS

TS SEP SEP SEP

SEP

SEP SEP

SEP SEP SEP STP

Transport Network

Signaling Network

SEP:Signal End Point STP:Signal Transfer Point STP

STP

図2.2.伝送路及び信号路でのデジタル交換システムの配置

(18)

テムが十分な可用性と実時間性を実現できなければ，サービス自体提供することができなくなる．

2.1.2 VoIP での交換システムの概要

VoIP(Voice Over Internet Protocol)とは，音声を各種符号化方式で圧縮しパケットに変換した上でIP（Internet Protocol：インターネットプロトコル）ネットワークでリアルタイム伝送する技術である．

VoIPにおいてはパケットの伝送を行うルータ及びスイッチと，SIP[1] 等のプロトコルを用いてセッション制御を行う交換システム（ソフトスイッチやCall Agentと呼ばれる場合もある）が存在する．ユーザは交換システムに対して接続要求を出し，交換システムは複数の交換システム間で制御情報を通信し，対向のユーザの呼び出しを行い通信のためのセッションを確立する．ユーザ間の通信に用いられる音声データの伝送には一般的にRTPプロトコルを用いてEnd-to-Endで伝送される (図2.3)．また音声データをEnd-to-Endで直接伝送するのではなく，一旦中継の交換システムにて音声データのセッションを終端して伝送する B2BUA(Back to Back User Agent)[1]方式も存在する．VoIPにおいてはSIP等の制御信号もIPプロトコルを用いる．またデジタル交換システムとは異なり，音声データと制御信号が同一のネットワーク上を流れる．

一般的にVoIPでは交換システムと伝送装置は連携しないため，伝送路にて音声データの優先度が管理されていない場合や，音声データが複数事業者間のネットワークを中継して伝送される場合，伝送路の品質確保が困難となる場合がある．

このため，サービス種別によっては交換システムと伝送装置が連携を行なう場合や，外乱要因のないVoIPサービス専用のIP網を用いてサービスを構成する場合もある．

VoIPは基盤となるネットワークにIP技術を使用するため，様々な装置へCOTSの適用が容易であるが，１つの機器の故障が大規模な障害につながる可能性があり，各装置の品質や管理・運用面での課題が存在する．

2.1.3 交換システムの要求条件

電話サービスに代表される交換システムが提供するネットワークサービスは，社会のライフラインとしての役割を担っており，交換システムの障害は社会に甚大な影響を及ぼす．

このため電話サービスを提供する交換システムには，特に可用性が重要視される．またその他の要件として実時間性，保守性，生産性，性能が求められる．

これら要求条件について説明する．

• 可用性

可用性(Availability)とは，平均故障間隔(MTBF:Mean Time between Failure)

(19)

Terminal

IP Network

Terminal

TA

1. Encode to digital data

3. IP routing by router/switch 2. Find destination IP

address from phone number, reserve network resources

CA

4.Decode to analog data

Analog data Voice data on IP packet

CA

TA: Terminal Adapter CA: Call Agent

Router/Switch

Terminal

IP Network

Terminal

TA

1. Encode to digital data

3. IP routing by router/switch 2. Find destination IP

address from phone number, reserve network resources

CA

4.Decode to analog data

Analog data Voice data on IP packet

CA

TA: Terminal Adapter CA: Call Agent

Router/Switch

図2.3.VoIPでの交換システム

(20)

と平均復旧時間(MTTR:Mean Time To Recover)によって示される．

Availability = M T BF M T BF +M T T R

交換システムは，年間99.999%以上のサービス稼働時間であることが求められる [2]．障害やサービス追加・修正にともなうソフトウェア修正のためのファイル更新作業によってサービス停止が許容される時間はおよそ5分程度である．またサービス提供中は要求されるすべてのセッションのサービス処理を遅滞なく処理することが要求される．

一般にこの平均故障間隔は信頼性を表す値でもある．交換システムでは上述の平均故障間隔が長いことに加えて，系切り替えの際に，コールデータと呼ばれる各ユーザのセッション状態を可能な限り待機系へ引き継ぎ，障害発生によりフェイルオーバーした後も，可能な限り処理中のサービスをそのまま継続することが要求される．

• ^実時間性

実時間性とはリソースに限りがある状態でジョブの実行が命令された時，その処理を要求時間内に終了することができることである．実時間性を持つシステムとして以下の分類が存在する．

ハードリアルタイムシステムシステムに課せられたある処理が要求される時間内に終了しない時（タイムアウト），システム全体にとって致命的ダメージが生じる．

ファームリアルタイムシステムシステムに課せられたある処理が要求される時間内に終了しない時（タイムアウト），システム全体に致命的なダメージを与えることはないが，その処理自体の価値は即座に0となる．

ソフトリアルタイムシステムシステムに課せられたある処理が要求される時間内に終了しない時（タイムアウト），システム全体に致命的なダメージを与えることはなく，その処理自体の価値も，終了時間などにより徐々に落ちていく．

交換システムはファームリアルタイムシステムである．呼処理ではセッション制御を多重処理として処理する．あるセッションの呼処理がタイムアウトした場合そのセッションは確立することのない呼損となる．呼処理のタイムアウトまでの時間は処理内容およびサービス仕様によって異なるが，おおむね数ミリ秒から１秒程度である．またこのタイムアウトにより，システム全体の動作が継続できなくなるわけではない．ただし障害発生時の影響を最小にするため障害検出の観点より，セッション単位のタイムアウトが多発する場合，ソフトウェアまたはハードウェアのいずれかに何らかの障害が発生したとみなし，障害処理や待機系へのフェイルオーバーを行う場合もある．

また実時間性は上述した要件である可用性と密接な関係にある．交換システムが提供する電話サービスは実時間性を必要とするサービスである．輻輳等の要因でタイムアウトが発生しサービスの実時間性が満たされていない場合，そのセッション

(21)

は呼損となりサービスの可用性が低下する．ゆえに実時間性もサービスを提供する上で重要な要件であり，定められたタイムアウト値以内に遅滞なく呼処理を行なうことが要求される．

• ^保守性

サービス提供時にハードウェア，ソフトウェア問わず何らかの異常が発生した場合には，即座に保守者による対応が行えるよう，迅速な障害検出と通知が行えることが要求される．また異常時の回復に向けた制御は保守者によって行われるだけでなく，ある程度までシステム自律で障害回復を試みることも要求される．

• ^生産性

サービスを開発する場合及び，運用中にサービス追加や変更が頻繁に発生しても，高いソフトウェアの生産性を保ち，維持管理コストを低く保つことが要求される．

• 障害解析性

何らかの原因で障害が発生した場合，解析のための情報を確実に取得することが求められる．またこれら情報取得に当たっては提供中のサービスに与える影響が最小限であることが要求される．

• 性能

上述した実時間性を保ちながら，おおむね数百から数千のセッション制御を多重処理で実施することが求められる．さらにサービス及びシステムによって異なるが，おおむね数万から１０万人程度のユーザ数を収容可能，最頻時にはセッション制御を一時間当たり数十万件程度処理することが求められる．一般に１０万〜５０万BHCA(Busy Hour Call Attempt)程度の処理能力を有することが求められる．

BHCAとは最煩時呼数であり，電話網が最も混雑する時間帯（busy hour）での回線呼び出し（call）の回数の総量のことである．BHCAでは実際に受話された呼び出しに加えて受話されなかった呼び出し（attempt）も含める．

2.2 専用コンピュータによる交換システム

2.2.1 _{システム構成}

以下では典型的な専用コンピュータによる交換システムを例として説明する．専用コンピュータによる交換システムは，可用性と実時間性をはじめ，求められる要件を満たすために独自に開発されたハードウェアとOS，ユーザソフトウェアを用い，稼動系と待機系の間に共有バスを有しすべてのハードウェアコンポーネント単位で冗長化が行われている．専用コンピュータによる交換システムはデュプレックスシステム構成であり，ソフトウェア・インスタンスは稼動系・待機系間で１つとなる．(図2.4 )．

専用コンピュータによる交換システムの特徴として，いくつかの特筆すべき特徴を以下に示す．なお性能については，CPU及びサービス仕様に依存する点が多いため以下の説明では割

(22)

愛する．

2.2.2 _{可用性を高める技術}

専用コンピュータを用いた交換システムには高可用性を実現するための技術として以下の特徴的な実装・機能が存在する．

• メモリ交絡による完全メモリ同期

専用コンピュータによる交換システムでは稼動系と待機系ハードウェア間で共有バスを介してメモリが冗長化されており，稼動系のメモリ状態と待機系のメモリ状態を同期することができる．このため稼動系にてハードウェア障害が発生し，待機系へ処理切換時には旧稼動系にて直前まで実行していた処理を，新稼動系にて継続可能である．

本機能により極めて迅速に稼動系の切換が可能であるとともに，ある程度までのソフトウェア障害においても，メモリ上に存在するコールデータを消失することなく処理継続が可能である．

またメモリ交絡による同期の有効無効はソフトウェアから制御でき，冗長系においては任意のポイントのメモリ状態を待機系のメモリに保持することも可能である．

• 再開エスカレーションによる局所初期化

専用コンピュータによる交換システムでは，ソフトウェア障害に対して可用性を向上させるために再開エスカレーション機能を有している．再開エスカレーションとは，致命的なソフトウェア障害が発生時に，既製コンピュータの一般的なソフトウェアのようにプロセス全体を終了するのではなく，障害が発生したタスクの一部の処理のみを初期化し再実行することである．

交換システムの多くのソフトウェア障害は，多重実行されるタスク内の特定の処理が想定外に重なった場合に発生することが多い．またこのようなケースが事前に検知することが難しく洗い出しきれない現状がある．障害が発生した処理のみを局所的に初期化し再実行することで，障害発生時の状態とは異なる状態となり処理が成功する可能性が高い．この再実行でうまく動作しない場合には，初期化及び再実行を行なうタスクの範囲を徐々に拡大することで可能な限り短時間でサービス処理を再開させる機能である．

また専用コンピュータによる交換システムではソフトウェア・インスタンスは単一であり，ソフト障害時には本機能による復旧時間がサービス復旧時間となる．

• ソフトウェアのオンライン修正

専用コンピュータによる交換システムのソフトウェアのオンライン修正方法として，専用のOSと専用のハードウェア上で実現されるC++言語のオンライン修正[3]が存在する．サービス処理部分及びカーネル部分等，サービスに使用される

(23)

CPU Memory

Active-Node Standby-Node

(Duplex system) Processor B lock

Other

Function Block Disk I/O Function Block HDD

. . .

S ystem file

Memory dump

Real-time memory synchronization by cross circuit.

Rapid switch over without service interruption

Real-time memory synchronization by cross circuit.

Rapid switch over without service interruption

Automatic escalating initialization mechanism using multi-backups.

A utomatic escalating initialization mechanism using multi-backups.

Snap-shot of all memory images by hardware.

Firm real-time kernel for 1000s of multi-tasks.

Prioritized processing for critical operations.

Firm real-time kernel for 1000s of multi-tasks.

Prioritized processing for critical operations.

New Function JUMP

Runtime software modification without service Interruption.

(Both for kernel and application programs) Runtime software modification without service Interruption.

(Both for kernel and application programs)

図2.4.専用コンピュータによる交換システムのアーキテクチャ

(24)

ソフトウェアの全域をオンライン修正可能であり，ソフトウェアを再ロードすることなく実行中のまま修正することが可能である．本機能によりサービスを停止させず，軽微な機能追加とソフトウェアのバグ修正を実施することが可能である．

メモリ交絡によるリアルタイムでのメモリの冗長化によりMTTRを限りなく0に近づけることができる効果的な手法である．メモリ交絡機能を持つ専用コンピュータを用いた交換システムでは，稼動系と待機系のメモリ状態が完全に同期されるため，系切換を瞬時に行える．今日の既製コンピュータには，メモリ交絡機能は存在せずシリアライズされたデータをネットワーク経由で同期するしかできない．このため，完全にリアルタイムでの全データの同期は困難であり，この点が系切換に時間を要する原因である．また後に示す障害解析性の課題の原因でもある．

ソフトウェアのオンライン修正はMTBFを長期化できる効果的な手法である．交換システムは巨大なメモリを使用するため，ソフトウェアの修正によりディスクから修正されたロードモジュールを再ロードする際，再起動に長時間を要し可用性が低下する．またソフトウェア・

インスタンスは単一であるため修正のためにロードモジュールを再ロードすることは許容されない．ハードウェアの活線挿抜が可能なように，ソフトウェアにおいてもサービスを停止することなくオンライン修正を行うことは可用性を保つためには極めて重要なことである．

2.2.3 実時間性を向上する技術

専用コンピュータによる交換システムには実時間性を向上するための技術として以下の特徴的な実装・機能が存在する．

• リアルタイムスケジューラによるタスク割り当てと，タスクでのCPU実行権開放の実装

専用コンピュータによる交換システムではタスクへの実行権割り当てにシンプルな優先度ごとのFIFOキューを持ったリアルタイムスケジューラを使用している．

交換システムに搭載されるソフトウェアの大多数がリアルタイムタスクとして動作するため，個々の処理ロジックの処理時間をあらかじめ考慮して設計・実装が行なわれており，その処理が長時間に及ぶ場合には，タスク側にて処理途中で他の処理にCPU実行権限を明け渡すよう実装されている．またCPUの実行権限の開放が適切に行われているかを後述のメーズ監視機構にてチェックしている．

既製コンピュータでは，タイムシェアリング型のスケジューラが使用可能であり，ドライバやカーネル等の低レベルソフトウェアを除く一般的タスクでは，CPU の実行権開放を意識する実装は稀である．

• メモリ固定割付によるメモリアクセスレイテンシーの排除

専用コンピュータによる交換システムでは，ソフトウェアが使用するメモリは全て物理メモリと１：１にマッピングされている．このため，システムの状態によって，ソフトウェアが使用するメモリが仮想メモリ等に退避されることはなく，メモ

(25)

リアクセス速度を常に一定に保つことが可能である．また論理メモリアドレスがマッピングされる物理メモリアドレスも固定であるため，メモリ交絡によるメモリ同期においても待機系で同期されたメモリ内容をそのまま使用し，処理継続を行うことが可能である．

専用コンピュータによる交換システムにおいては，ソフトウェアの設計思想が実時間性を考慮したものであった．メモリ操作においてもシステムコール単位でタイムアウト機能を有しており，タイムアウトする場合には操作をあきらめる設計思想である．一方，今日の既製コンピュータにおいては，たとえばメモリ操作においても，可能な限り遅延操作を行い，システムとしてリソースの最適使用や動作継続性を優先する．OS上のタスクの動作が完全にコントロール可能であることを前提としたOSの設計と，どのようなタスクが動作するかを予期不能であることを前提に設計される汎用OSとでは，実時間性に差がでる．

2.2.4 _{保守性を向上する技術}

専用コンピュータによる交換システムには保守性を向上するための技術として以下の特徴的な実装・機能が存在する．

• 迅速なハードウェア異常検出

専用コンピュータによる交換システムでは，ハードウェアはパッケージ単位で管理されており活線挿抜が可能となっている．またパッケージ単位での正常性の自己判断がハードウェアレベルで実施でき，何らかの異常が発生した際にはCPUに即座に割り込みをかけ異常を通知することができる．割り込まれたCPUでは，ハードウェア異常のハンドラに処理を受け渡す．通常，ハンドラでは障害が発生したパッケージを切り離す，もしくは稼動系の切換を行い，異常を保守システムへ迅速に通知する．

• メーズ監視機構による迅速なソフトウェア異常検出

2.2.3で示したように，専用コンピュータを用いた交換システムでは，大多数の

タスクがリアルタイムタスクであり，タスク側にてCPU実行権を開放することを意識した実装がされている．仮に優先度の高いタスク側で無限ループを生じるようなバグが存在しても，他のタスク及びシステム全域に影響を与えないよう，各タスクの実行時間は厳密に管理されている．

専用コンピュータによる交換システムが有していたメーズ監視機構は，タスク毎にソフトウェア的なWDT（Watch Dog Timer）を持たせるものである．タスクが一定時間を越えても実行権を手放さず，かつメーズをクリアしない場合，該当タスクを暴走したものとみなしカーネルは異常系の処理を行う．そのため長時間動作しなければならないタスクは適時メーズをクリアし，正常に実行し続けていることをメーズ監視機構に通知する必要がある．

専用コンピュータによる交換システムでは，このメーズの間隔は8ms程度であ

(26)

り，大部分のタスクは一度実行権を割り当てられれば8ms以内にその処理を終了できるよう，設計・実装されている．

2.2.5 _{生産性を向上する技術}

専用コンピュータによる交換システムにおいて生産性を向上するための試作として，C++

言語によるソフトウェア開発が行われた．これによりソフトウェア開発効率が向上したが，既製コンピュータ環境に存在する豊富なライブラリや実装例，POSIXに準ずるインタフェースがあるわけではなく，既製コンピュータのソフトウェア開発環境と比べると十分ではない．

2.2.6 障害解析性を向上する技術

専用コンピュータによる交換システムには障害解析性を向上するための技術として以下の特徴的な実装・機能が存在する．

• サービス無停止での全メモリ領域ダンプ機能

専用コンピュータによる交換システムでは，システムが稼動中に使用するOSを含むメモリ領域が稼動系・待機系で同期されている．全メモリ領域のダンプを取得したい場合には，待機系のメモリをディスクにダンプすることで，稼動系の動作を妨げることなく障害発生瞬間のダンプを取得することが可能である．

高度に専用化されたハードウェアにより，サービスの可用性を妨げることなく障害解析情報を取得することが可能である．

2.3 通信交換システムへの既製コンピュータ適用実現の技術動向

専用コンピュータによる通信交換システムでは交換システムに求められる要求条件を満たすよう，コストをかけて設計・実装されていた．

しかしこれらの交換システムは設計・開発時より長期間経過しており，ハードウェアの老朽化や保守部品が製造困難となっている．またソフトウェアも専用のハードウェアアーキテクチャを前提としており，異なるアーキテクチャへの対応が困難である．

更に昨今の激しいサービスの価格競争により，従来の交換システムの更改に用いるシステムと新たなサービスに用いるシステムをコストに優れる標準に準拠したコンポーネントを用いて構築する事が要望されている．

このような状況から，今日，既製コンピュータに代表されるCOTSを，交換システムへ適用するために，世界中の様々なキャリア，ベンダ，団体にて，研究が行なわれている．以下に標準化動向，既製コンピュータによる交換システムのアーキテクチャ，交換システムの要件に対する既製コンピュータの充足度を示す．

(27)

2.3.1 _{標準化動向}

COTSベースの既存コンピュータによる交換システムの構築に対する標準化として次に示す団体による標準化が主流である．

• Open Communications Architecture Forum (OCAF)[4]

OCAFはITU-Tにて，COTSで容易にNGN を構成できるようにすること，

とくに通信用ソフトウェアの標準コンポーネントを確立することを目指し，交換システムを含む通信システムのソフトウェアアーキテクチャの参照モデルや具体的なコンポーネントの検討を行い，勧告化することを目的としている．

特定のコンポーネントに関するものではなく，システム全体のアーキテクチャに対する検討，標準化を目指している．

• Service Availability Forum (SA Forum)[5]

SA Forum は通信/コンピュータ業界のコンソーシアムであり，高可用性のネットワーク基盤製品，システム，サービスの開発に利用可能な高可用クラスタリングソフトウェア (High Availability Clustering) のインタフェース仕様 [6] を開発し，業界での採用と普及を促進している．SA Forum においては，アプリケーションの高可用性を実現する AIS(Application Interface Speciﬁcation)[7][8][9][10][11][12][13][14][15][16][17][18][19]，ハードウェアを制御・監視する HPI(Hardware Platform Interface Speciﬁcation)[20][21]，モニタリングインターフェースであるSMI(Systems Management Interfaces)を定義しており，準拠製品によりこれら仕様を満たす実装が行われている．

• Carrier Grade Linux Working Group (CGL-WG)[22]

CGL-WGはOSDL(Open Source Development Laboratories)にて，活動が開始され，通信事業者向けLinuxの仕様，特にカーネル等，OSの基本的な機能部分で通信事業者に必須の仕様を規定している．OSDLは2007年1月にFSG(Free Standards Group)と統合されLinux Foundationとなった．

CGL-WGにおいては，Linuxに必要なソフトウェアとしての機能を，可用性，

標準準拠性，保守性，ハードウェアの対応，クラスタリング，性能，セキュリティといった7つの要件の観点から定義している[23][24][25][26][27][28][29][30]．

• Advanced Telecom Computing Architecture（ATCA）[31]

ATCAは，PCI Industrial Computer Manufacturers Group（PICMG）のガイドラインの元で，100社を超える業界サプライヤおよび通信機器メーカによって開発された，通信事業者向けのハードウェア仕様である．この標準に基づくプラットフォームは通信業界独自のニーズに応えることを目的としており，通信事業者での使用に必要なラック・サイズ，電源，および環境の条件に対応し，IAサーバの技術の多くを取り込んだ実装が多く行われている．

(28)

これらの標準化団体によって定義される代表的なシステムアーキテクチャを図2.5に示す．

ハードウェアコンポーネントについてATCAを，OSについてはCGL準拠のLinuxを，ミドルウェアについてはSAF準拠コンポーネントを適用し，アプリケーションについては独自のサービスロジックを開発するモデルが一般的である．

またこれら標準は完成されたものではなく，まだ発展途上のものであり，今後標準品のみで一定の品質が保たれるよう，多くのベンダ，通信事業者がこれら標準化にて検討を行っている．また本研究の成果の一部もLinux FoundationのCGL-WGに貢献している．

2.3.2 _{システム構成}

上述の標準化動向を踏まえ，交換システムに既製コンピュータを適用する場合，図2.6に代表されるシステム構成がとられる．SA Forumに準拠するミドルウェアを用い，稼動系・待機系のシステム単位での冗長化がとられる．この場合，ソフトウェア・インスタンスは稼動系・

待機系で２つ存在する．

ハードウェアはATCAに代表される通信事業者での使用に耐えうる信頼性を有し，1.1に示したように標準規格に準拠し複数のベンダから調達可能な，コストに優れるハードウェアが適用される．

ソフトウェアコンポーネントにおいては，OSのLinuxのようにオープンソースであることは極めて重要である．ブラックボックスであるソフトウェアコンポーネントを用いた場合，障害発生時，障害解析のターンアラウンドタイムが長く，迅速な対応が困難となるケースが多い．また最悪の場合には障害を解析できない場合も存在する．専用システム上のソフトウェアのソースコードは通信事業者側で有しており，障害解析を迅速に行なうことが可能であった．

オープンソースであればCOTSのソフトウェアコンポーネントであっても通信事業者側で障害解析可能であり，実運用に向けた課題を少なくできる．

以下に交換システムの要求条件に対する，それぞれの到達点と課題について説明する．なお性能については，CPUとサービス仕様に依存する点が多いため以下の説明では割愛する．

2.3.3 _{可用性の現状と課題}

現状

交換システムに既製コンピュータを適用する場合，可用性についてはSA Forumにて定義されるミドルウェアベースのHAクラスタリングによる高可用化が主である．

• HAクラスタリングによる可用性向上

SA Forumが定めるAIS仕様により，従来専用コンピュータによる交換システ

ムが有していたメモリの同期機能がソフトウェア処理にて実現されている．本機能により稼動系に障害が発生した場合でも，待機系にて処理を引き継いでサービスを継続することが可能である．

一方，専用コンピュータではハードウェアにて実現されていた機能をソフトウェ

(29)

ATCA, Blade server, Rack mount server

Software Development

tools Carrier Grade Linux

HA Clustering (SAF based)

Components (etc) Components

(Protocols) Components

(Call control) Applications

ATCA, Blade server, Rack mount server

Software Development

tools Carrier Grade Linux

HA Clustering (SAF based)

Components (etc) Components

(Protocols) Components

(Call control) Applications

図2.5.既製コンピュータを用いた交換システムのアーキテクチャ

(30)

Memory

(Cluster system) Processor

Block

Network Interface Function Block Disk I/O

Function Block HDD

. . .

Memory dump

Snap-shot of crashed software memory by OS.

Network Interface Function Block Non-real-time Important data synchronization through network.

Non-real-time Important data synchronization through network.

Load

module Swap file CPUCPU CPUCPU

Soft real-time Linux kernel.

Symmetric Multi Processing/Threading.

Use HDD as part of virtual memory.

Virtual memory allocation that excess physical memory size.

Reload process from load module whenever process fails.

Memory

(Cluster system) Processor

Block

Network Interface Function Block Disk I/O

Function Block HDD

. . .

Memory dump

Snap-shot of crashed software memory by OS.

Network Interface Function Block Non-real-time Important data synchronization through network.

Non-real-time Important data synchronization through network.

Load

module Swap file CPUCPU CPUCPU

CPUCPU CPUCPU

Use HDD as part of virtual memory.

Virtual memory allocation that excess physical memory size.

Reload process from load module whenever process fails.

図2.6.COTSベースの交換システムのアーキテクチャ

(31)

アにて実現するため，遥かにその速度及び転送量には制約があり実時間性は低い．

またユーザプロセスが使用する一部のメモリ領域を引き継ぐに過ぎないため，より低レイヤのプロトコル処理されるセッション情報などは引き継ぐことが困難である．このため障害時に引継ぎ・継続可能なサービス種別が制限される．

課題

交換システムに求められる可用性とは，サービスの可用性を保つことである．このためには MTTRの短縮とMTBFの長期化が重要である．

サービスの一時的な中断が，サービスのタイムアウト時間内であれば，ユーザのセッションは処理継続され，サービスの可用性には影響を与えない．このタイムアウトまでのサービス中断許容時間は処理内容によって異なるが，おおむね数ミリ秒から１秒程度である．

既製コンピュータの場合HAクラスタリングによる稼動系の切換時間が主なMTTRとなるが，この稼動系の切換は多くのデータ転送や状態遷移処理を必要とし数秒〜１０秒程度を要し，大幅にタイムアウト値を超過する．このため稼動系切換はサービスの可用性低下の一因となる．

HAクラスタリングを用い交換システムに要求される可用性を低下させないためには，より高速な系切換を行ない，MTTRを短縮させる必要がある．この取り組みの一環として Inﬁniband[32][33]やEthernetを使用したRDMA(Remote Direct Memory Access)[34]の仕様化が行なわれ，通信事業者向けに標準化されたハードウェアへの適用も検討されている．しかしこれら技術を搭載したハードウェアは高価であり主流ではない．現時点ではCPUブレードにはリリースからある程度年月が経過した比較的安定したコントローラチップを搭載したものが主流であり適用可能である．本研究では，今すぐに商用サービスに適用可能な熟成された技術及びATCA等の通信事業者向けに標準化されたハードウェアを用いることを前提としており，現時点でこれら技術は商用へ適用可能な状況ではない．このため系切換の契機自体を削減するMTBFの長期化が極めて重要となる．

今日の既製コンピュータ及び専用コンピュータではソフトウェアのMTBFはハードウェアに比べて劣っている．これはソフトウェアがハードウェアに比べて遥かに複雑な状態遷移をもち大規模であるからである．このためあらゆる状態の組み合わせの試験は困難であり，特殊条件化で発動するバグが発見されないまま運用されてしまう．Linux，上述のミドルウェア，アプリケーションコンポーネントにおいても潜在的に数多くのバグを有し，更に専用コンピュータにおいても同様である．これらバグに遭遇した場合、サービス提供に影響を及ぼす場合もありMTBFは低下する．

通常これらバグが発見されれば開発者によって速やかに修正され，一般的なコンピューティング用途であれば，バグ修正されたロードモジュールに差し替え，ソフトウェアを再起動することで修正を行なう．

交換システムは同一のシステムが全国に多数分散配置される．あるシステムでバグが発見された場合，その修正を他システムに迅速に展開することが重要である．更に交換システムは

(32)

ライフラインサービスを提供し，24時間365日サービスを提供し続ける必要がある．ソフトウェア修正によりサービスの可用性が低下することは許容されない．単にソフトウェアを再起動する場合，サービス復旧までに長時間を要しサービスの可用性が低下する．

既製コンピュータに適用されるHAクラスタリングにより稼動系切換を用い，待機系にてソフトウェアを更新し系切換を行う場合，仮に系切換時間が十分短縮化されたとしても，待機系がソフトウェアを再ロードする間一時的にクラスタから切り離されるため，冗長化されていない状態となり可用性が低下する．更に稼動系切換は複雑な状態遷移を行うため，場合によっては想定外の障害が発生する可能性もある．

また専用コンピュータはデュプレックスシステムによる冗長化構成であり，ソフトウェア・

インスタンスは単一である．このためソフトウェアバグはサービスへ重大な影響を及ぼす恐れがあり，同様に可用性に影響を与えないソフトウェア修正方法であるオンライン修正が適用されてきた．

交換システムには可用性に影響を与えないサービスのタイムアウト値以内の停止時間でソフトウェアを修正することが必要であり，既製コンピュータにて可用性に影響を与えないソフトウェア修正方法を確立することが求められる．

2.3.4 _{実時間性の現状と課題}

交換システムに既製コンピュータを適用する場合，実時間性についてはOSにて制御される資源割り当ての処理に依存する．ここではLinuxの資源割り当てについて現状と課題について示す．

現状

ハードウェアとしてCPUはSMP(Symmetric Multi Processor)やSMT(Symmetric Multi

Threading)構成を適用可能であり，多数の並列プロセスを同時に処理可能である．一方，こ

のCPUやメモリ，DISK，ネットワーク等の資源はOSによって制御され，各タスクにソフトリアルタイムでの資源割り当てが行われる．

• CPUスケジューラでの実時間性向上

今日のLinuxのCPUスケジューラでは，タスクに対して1ms単位でのCPU割り当て変更可能となっている．本機構により優先度が高いタスクが実行可能になった際にも，既存のタスクが一般的な実行領域を走行中であれば，より優先度の高い処理が実行権限を得ることが可能である．

またタスク数が増大した際にも，適切なタスクを高速に選択可能な O(1)スケジューラにより，多大なスケジューリング遅延を出さずに実行権を受け渡すことができる．

• プリエンプティブ性向上による実時間性向上

上述のCPUスケジューラにおいてタスクの実行権を細かい粒度で受け渡し可能

向上に関する研究

交換システムへ既製コンピュータを 適用するための可用性と実時間性の