Title
Author(s)
Semi-Symmetric Active-Active 型デュアルコントローラストレージ
システムに関する研究
松並, 直人
Editor(s)
Citation
Issue Date
URL
2015-02
http://hdl.handle.net/10466/14541
Rights
http://repository.osakafu-u.ac.jp/dspace/
大阪府立大学博士論文
Semi-Symmetric Active-Active 型
デュアルコントローラストレージシステム
に関する研究
２０１５年２月
松並 直人
2015/03/02 10:52:00
論文本編-089-最終原稿
18
目次
目次
第１章 序論 ........................................................................................................... 1
第２章 Semi-Symmetric Active-Active ストレージコントローラアーキテクチャの提唱 ............ 5
2.1 緒言 ........................................................................................................... 5
2.2 Asymmetric Active-Active 方式の課題 ............................................................. 7
2.3 Semi-Symmetric Active-Active 方式の提案 ...................................................... 13
2.4 提案方式の評価 .......................................................................................... 16
2.5 結言 .......................................................................................................... 23
第３章 高速メッセージ伝送技術による高性能化 .......................................................... 25
3.1 緒言 .......................................................................................................... 25
3.2 従来のメッセージ伝送技術と課題 ................................................................... 26
3.3 コマンドキャスティング方式の提案 ................................................................... 29
3.4 提案方式の評価 .......................................................................................... 36
3.5 考察 .......................................................................................................... 48
3.6 結言 .......................................................................................................... 53
第４章 自動負荷均衡技術による高運用化 ................................................................. 55
4.1 緒言 .......................................................................................................... 55
4.2 CPU 負荷均衡方式の提案 ............................................................................ 56
4.3 性能シミュレータの開発................................................................................. 60
4.4 提案方式の評価 .......................................................................................... 66
4.5 結言 .......................................................................................................... 79
第５章 自律型無停止マイクロコード交換技術による高可用化 ........................................ 81
5.1 緒言 .......................................................................................................... 81
5.2 自律型無停止マイクロコード交換方式の提案 .................................................... 83
5.3 評価方法 .................................................................................................... 87
5.4 提案方式の評価 .......................................................................................... 90
5.5 結言 .......................................................................................................... 97
i
目次
第６章 結論 .......................................................................................................... 99
6.1 本研究で得られた成果 ................................................................................. 99
6.2 今後に残された課題 ................................................................................... 101
謝辞 .................................................................................................................. 103
参考文献 ........................................................................................................... 105
ii
目次
図目次
図２.１ Asymmetric Active-Active デュアルコントローラアーキテクチャ ............................ 9
図２.２ Asymmetric Active-Active 方式の Read クロスアクセス動作 ................................ 10
図２.３ VM Load Balancing によるシステム性能低下の例 .............................................. 12
図２.４ コマンドキャスティング技術の概要 .................................................................. 13
図２.５ Semi-Symmetric Active-Active 方式の Read クロスアクセス動作 .......................... 14
図２.６ 提案方式の Read クロスアクセスのラダーチャート .............................................. 16
図２.７ 汎用アクセス確率分布モデル ........................................................................ 17
図２.８ 近似アクセス確率分布モデル ........................................................................ 17
図２.９ CPU サービス時間の計算モデル ................................................................... 18
図２.１０ 従来方式に比較した提案方式の改善効果 .................................................... 20
図２.１１ クロスアクセスの性能低下率 ........................................................................ 20
図２.１２ Read100% CPU 性能予測結果 ..................................................................... 21
図２.１３ Write100% CPU 性能予測結果 .................................................................... 22
図３.１ Asymmetric Active-Active 方式による LU 共有アクセス制御 .............................. 26
図３.２ CC 方式のハードウェア ................................................................................ 30
図３.３ CTL0/1 の LM の構成 ................................................................................. 32
図３.４ CC 方式の動作概念図 ................................................................................. 33
図３.５ Command Queue の管理 .............................................................................. 34
図３.６ 従来技術 （１）DS 方式 ................................................................................. 37
図３.７ 従来技術 (２)SM 方式 .................................................................................. 37
図３.８ 従来技術 （３）RM 方式 ................................................................................. 37
iii
目次
図３.９ 従来技術 （４）FS 方式 .................................................................................. 38
図３.１０ 従来技術 （５）RS 方式 ................................................................................ 38
図３.１１ 提案技術 （６）CC 方式 ............................................................................... 38
図３.１２ ストレージ専用接続型方式の CPU オーバヘッド評価結果 ................................ 43
図３.１３ 汎用ＮＷ接続型方式の CPU オーバヘッド評価結果 ....................................... 44
図３.１４ 64B メッセージ転送時の CPU オーバヘッド評価結果 ...................................... 45
図３.１５ メッセージ伝送時間評価結果 ...................................................................... 46
図３.１６ 64B メッセージ転送時のメッセージ伝送時間評価結果 ..................................... 47
図４.１ 提案方式の手順 ......................................................................................... 59
図４.２ 性能シミュレータ LB-Sim の構成 .................................................................... 61
図４.３ 実機と LB-Sim の性能比較結果..................................................................... 63
図４.４ 評価１の結果（CPU 負荷率判定閾値の評価） ................................................... 67
図４.５ 評価 2 の結果（従来技術と提案技術の性能比較）............................................. 69
図４.６ 評価２における IOPS 不均衡率の評価 ............................................................ 70
図４.７ 評価２における構成変更コストの評価.............................................................. 71
図４.８ 評価 3 におけるシミュレーション想定構成 ........................................................ 72
図４.９ 評価３の疑似実働負荷特性 .......................................................................... 73
図４.１０ 評価３の平均レスポンス時間測定結果 .......................................................... 74
図４.１１ 評価３の CPU 負荷率の評価結果 ................................................................ 76
図４.１２ 評価３の LU 移行回数推移 ......................................................................... 77
図５.１ コマンドキャスティング機能 ............................................................................ 84
図５.２ 提案方式の動作手順 ................................................................................... 86
図５.３ シミュレータの構成 ...................................................................................... 88
図５.４ シミュレーションの入力負荷特性 .................................................................... 89
図５.５ 低負荷時のスループット性能測定結果............................................................ 91
iv
目次
図５.６ 低負荷時の平均レスポンス時間測定結果 ........................................................ 91
図５.７ 低負荷時の CPU 負荷率測定結果 ................................................................. 91
図５.８ 中負荷時のスループット性能測定結果............................................................ 93
図５.９ 中負荷時のレスポンス時間測定結果 .............................................................. 93
図５.１０ 中負荷時の CPU 負荷率測定結果 ............................................................... 93
図５.１１ 総 CPU 負荷率の移動平均曲線 .................................................................. 94
v
目次
表目次
表２.１ 従来方式と提案方式の比較 .......................................................................... 15
表２.２ アクセス確率分布と CPU サービス時間の定義 ................................................. 19
表２.３ 最大 IO スループット性能の比較.................................................................... 19
表３.１ 従来のメッセージ伝送技術の形態別の分類結果 .............................................. 29
表３.２ 両コントローラから見たメモリマップの設計の例 ................................................. 31
表３.３ LU テーブル............................................................................................... 33
表３.４ 諸元データの取得のために用いた試作機の仕様.............................................. 39
表３.５ メモリアクセスに要する CPU オーバヘッドと転送時間 ........................................ 39
表３.６ 本計算に纏わる処理項目と処理時間 .............................................................. 39
表３.７ メッセージ伝送方式の評価結果（６４B 転送時） ................................................. 48
表３.８ ストレートアクセスとクロスアクセスの CPU オーバヘッド ....................................... 48
表３.９ HDD 性能仕様 （RAID5/1 構成時） ................................................................ 49
表３.１０ ストレート／クロスアクセスの性能対称性の評価 .............................................. 50
表３.１１ SSD 性能仕様（一例） ................................................................................. 51
表３.１２ メッセージ伝送技術の形態別まとめ .............................................................. 52
表４.１ 性能シミュレータ LB-Sim の性能検証に用いた評価環境 .................................... 64
表４.２ 評価環境一覧 ............................................................................................ 65
表４.３ 評価１の測定結果 (Cross:100%, Write:100%) .................................................... 68
表４.４ 評価 2 の測定結果 ...................................................................................... 70
表４.５ 評価 3 の測定結果 ...................................................................................... 74
表４.６ 過剰な負荷均衡動作の防止策の効果 ............................................................ 78
vi
目次
表５.１ 無停止マイクロコード交換方式比較 ................................................................ 85
表５.２ シミュレータの構成パラメータ一覧 .................................................................. 88
表５.３ 評価パラメータ一覧 ..................................................................................... 89
表５.４ コントローラ停止時間のシミュレーション測定結果 .............................................. 95
vii
第１章
第１章
序論
情報化社会が進展し、インターネット商取引の普及や、戦略的情報活用に対する機運の
高まりをうけ、情報量は増加の一途にある[HOR11][SAK12]。大量に増え続ける情報を安全か
つ高速に入出力する情報処理装置がストレージシステムである[GEN05][HOR10][KUB14]
[HIT04][YAM05b] [HIT08] [YAM05a]。
企業用途のストレージシステムとして、デュアルコントローラストレージシステムが普及して
いる[HIT02][KED05]。デュアルコントローラストレージは、数 100 台の HDD と 2 台のストレ
ージコントローラを搭載するストレージシステムで、LU オーナ権と呼ぶ機構を持つことが特徴
である[KOB97][MAT99]。2 台のストレージコントローラのうちの一方が特定の LU（Logical
Unit：論理ユニット）のオーナ権を占有し、独占的に LU をアクセスできる構造とすることで、コ
ントローラ間の排他制御を不要とし、高速な LU アクセス制御を実現している。以下、LU オ
ーナ権を所持するストレージコントローラをオーナコントローラと称する。
本論文では、このデュアルコントローラストレージシステムを研究対象とし、その新しいア
ーキテクチャとして Semi-Symmetric Active-Active 型デュアルコントローラ方式を提唱する。
以下、Semi-Symmetric Active-Active を sSAA と略記する。
本研究で明らかにした課題は次の通りである。クラウドコンピューティングの普及により、
仮想化されたサーバがネットワークで接続された物理サーバ上を自由に移動できるようになっ
た。その結果、サーバのシステム構成が動的に変化するようになり、サーバからストレージシス
テムへのアクセス経路も変化するようになった。サーバから特定の LU をアクセスする際に、2
台のコントローラのいずれからでも、オーナ権の所持の有無に関わらずアクセスできることが必
要となった。しかしながら、従来のデュアルコントローラストレージシステムは、コントローラのオ
ーナ権の有無により LU アクセス性能が非対称になるという特性があった。本研究では、この
特性に起因した以下に示す 3 つの課題を見出した。
1
第１章
（１） 高性能化の課題
システム構成変更に伴うアクセス経路の変更により、LU オーナ権を所持しない非オーナ
コントローラからの LU アクセスが必要になるが、その際、オーナコントローラへの処理委
託を行わなくてはならず、その委託オーバヘッドにより LU アクセスが低速化し、結果的に
システム性能が低下する。
（２） 高運用化の課題
クラウドコンピューティング環境における急激な負荷上昇や、仮想サーバの移動によるシス
テム構成の変更により、2 台のコントローラ間の負荷均衡状態が崩れるが、その対策のた
め、オーナ権とアクセス経路の関係を考慮した、多くの人手を要する負荷均衡化処理の実
施が必要となる。
（３） 高可用化の課題
24 時間無停止でストレージシステムのマイクロコードを交換することが求められるが、ストレ
ージコントローラを 1 台ずつ停止させながらマイクロコード交換作業を実施するため、1 台
を停止させる間、もう 1 台のコントローラに全 LU オーナ権を移行するとともに、全てのコマ
ンドを振り向けるよう、サーバのソフトウェアの操作によりアクセス経路を切り替える必要が
ある。このアクセス経路の切り替え作業のため、サーバ運用管理者の手助けと、多数のサ
ーバのソフトウェア操作が必要となり、多くの作業工数が発生する。
本論文では、定義した３つの課題を解決するｓSAA 型デュアルコントローラストレージシス
テムに関して論じる。以下、各章の要点を述べる。
第２章では、3 つの課題に対処するための基本アーキテクチャとして sSAA 型デュアルコ
ントローラ方式を提唱し、LU オーナ権の有無に関わらず実用上均質な性能対称性の実現を
目指す。ｓSAA 方式では、非オーナコントローラが受信したコマンドをオーナコントローラに高
速に移送するとともに、コマンド処理全体を委譲することで、従来発生していたオーナコントロ
ーラへの処理委託に要するコントローラ間の相互のやり取りに起因するオーバヘッド時間を低
減する。待ち行列理論を用いた CPU 性能予測手法を確立し、この手法を用いた基礎評価を
2
第１章
行う。評価の結果、提案方式は、非オーナコントローラの制御による IO スループット性能にお
いて、従来比 1.8～4.2 倍の性能改善を達成し、目標とする 250 台の HDD を動作可能とする、
実用上均質な性能対称性を実現できることを示す。
第３章では、非オーナコントローラによる LU アクセスの高性能化を実現するため、前述し
た非オーナコントローラがオーナコントローラへコマンドを高速に移送する技術として、コマンド
キャスティング方式を提案する。他系のメモリ空間を自系メモリ空間にアドレス変換してマッピン
グすることで、直接メモリアクセスを可能とするハードウェア回路と、他系メモリ空間上にコマン
ドを格納するためのコマンドキャストキューと呼ぶソフトウェア機構を設ける。各種メッセージ伝
送技術に対応した性能評価モデルを確立し、メッセージ伝送に要する CPU オーバヘッドとメ
ッセージ伝送時間の定量評価を行う。評価の結果、本提案技術によると、CPU オーバヘッドが
従来技術比 1/5～1/10 となる 2.0us に、メッセージ伝送時間が従来技術比 61%～89%となる
15.5us にそれぞれ低減でき、非オーナコントローラによる LU アクセスの高速化が達成できる
ことを示す。
第４章では、sSAA 型デュアルコントローラストレージシステムの高運用化を実現するため
に、システムが自動的にデュアルコントローラ間の負荷均衡状態を維持する技術として CPU
負荷均衡方式を提案する。コントローラ間の負荷均衡状態が崩れた際に、ｓSAA 方式が提供
する性能対称性を活用し、CPU 負荷率を負荷均衡化の指標として LU オーナ権をコントロ
ーラ間で移行することによって、デュアルコントローラ間の負荷均衡を実現する方式である。こ
の際、LU オーナ権の有無により生じるアクセスモードの差異と、Read/Write コマンドの制御の
差異の両方に起因する不均質な負荷特性を考慮することが特徴である。sSAA 型デュアルコ
ントローラの動作を模擬した性能シミュレータを開発し、CPU 負荷均衡方式の性能評価を実
施する。VM マイグレーションを模擬し、かつ、時間変動する実働負荷を用いたシミュレーショ
ンによる評価の結果、CPU 負荷均衡方式によると、24 時間平均レスポンス時間が 3.5ms であ
り、従来技術に対し 27%の性能向上効果があることを示す。また、提案方式の適用により、常
時、人手の介在なく、自動的なコントローラ間の負荷均衡化が可能となり、ストレージシステム
の運用性向上に有効であることを示す。
3
第１章
第５章では、sSAA 型デュアルコントローラストレージシステムの高可用化を実現するため
に、サーバ運用管理者の手助けと、サーバ上のパス切替ソフトウェアの操作を必要とせず、ス
トレージ運用管理者が単独で、無停止によりマイクロコード交換を行える技術として、自律型無
停止マイクロコード交換方式を提案する。ｓSAA 方式の提供する性能対称性を活用して、マイ
クロコード交換中のコントローラが受信した全てのコマンドを、もう一方の稼働コントローラに高
速に移送して処理全体を委譲することで、CPU をコマンド処理から解放し、その間に無停止マ
イクロコード交換を実施可能とする。時間変動する実働負荷を用いたシミュレーションによる評
価の結果、性能に関しては、最大許容負荷に対し 50％以下の環境下において、無停止マイ
クロ交換中の平均レスポンス時間の増加は最大 0.54ms であり、アプリケーションから見たオ
ーバヘッドの増加の影響は小さいことを示す。また、可用性に関しては、マイクロコード交換処
理中のコントローラ一時停止時間の最大値は約 150ms であり、目標とする 99.999%の高可用
性を達成できることを示す。
第６章では、本研究で得られた結果を総括するとともに、今後取り組むべき研究課題を述
べる。
4
第２章
第２章
Semi-Symmetric Active-Active ストレージコントローラア
ーキテクチャの提唱
2.1 緒言
デュアルコントローラストレージシステムの特徴の一つとして、仮想的なディスクを提供す
る機能がある。RAID 技術[PAT88]により複数の HDD の記憶容量が集合され、この集合された
容量空間を分割して複数の論理的なディスクが構成されサーバに提供される。この論理的な
ディスクのことを論理ユニット（Logical Unit：以降 LU と略記する）と呼び、ストレージ制御の基
本単位になる。
デュアルコントローラストレージシステムは、これまで基幹系トランザクションシステムなど
に使われてきた[WAN07][WAN08][ZHI10]。このようなシステム向けに、2 台のサーバに同一ソ
フトウェアを稼働させ、高性能化と耐障害性を両立させるクラスタ型ソフトウェアが登場した。ク
ラスタ型ソフトウェアは、2 台のサーバがデュアルコントローラストレージの別々のコントローラに
それぞれ接続したうえで、同一の LU を共有していた[PEI99]。
デュアルコントローラストレージシステムは、特定のコントローラが LU のオーナ権を有し、
独占的に LU をアクセスする構成とすることで、コントローラ間の排他制御を不要化し、高性能
化を実現していた[KOB97]。一方、クラスタ型ソフトウェアに対応するため、非オーナコントロ
ーラがオーナコントローラに処理を委託する方法で LU を共有する Data Sharing 方式が考案
された[MAT99]。処理委託のオーバヘッドにより性能は低下したため、オーナ権の有無に依
存し、LU のアクセス性能は非対称になった。この性能の非対称性ゆえ、Asymmetric ActiveActive 型デュアルコントローラ方式と呼ぶ。以下、Asymmetric Active-Active を AAA と略記
する。AAA 型デュアルコントローラ方式によるＬＵ共有は、上記クラスタ型ソフトウェアへの対応
などへの限定的な利用にとどまっていた。
一方、近年クラウドコンピューティングの普及により、１台の物理サーバ上に複数の仮想マ
シン（Virtual Machine、以下 VM と略記する）を搭載する技術の活用が主流になってきた。ま
たマルチコア CPU の発達により、物理サーバに搭載可能な VM 数が増加した。VM は仮想的
なサーバであるためネットワークで接続された複数の物理サーバ上を論理的に移動させられる。
5
第２章
この特性を活かし VM 毎の稼働負荷の増減に伴い VM を動的に移動し物理サーバ間の負荷
均衡を図る VM Load Balancing 技術が登場した。
しかしながら、AAA 型デュアルコントローラ方式を利用すると、VM が物理サーバ間を移
動した際に、サーバからストレージコントローラへのアクセス経路も変化することになり、物理サ
ーバが接続するコントローラが VM の扱う LU のオーナ権を持つか否かによって性能が大きく
変動してしまう。よってサーバの負荷均衡のために VM の移動を行ったものの、構成によって
はシステム全体の性能が以前よりも低下してしまうという問題が発生した。
本章では、VM が物理サーバ間を移動して接続するコントローラが変わっても、LU オ
ーナ権の有無に関わらず、実用上均質な性能対称性を得られる Semi-Symmetric ActiveActive（sSAA）型デュアルコントローラ方式と呼ぶ新ストレージコントローラアーキテクチャを提
唱する。
２．２節ではコントローラアーキテクチャの変遷を振り返り、従来方式の課題を提起する。２．
３節ではこの課題を解決する新方式のアーキテクチャと動作概要を述べる。２．４節では待ち
行列理論を用いた CPU 性能予測手法により提案方式の効果を検証する。
6
第２章
2.2 Asymmetric Active-Active 方式の課題
2.2.1
コントローラアーキテクチャの変遷
ストレージシステムは 1960 年代に発明された磁気ディスク駆動装置を黎明として、HDD
の記憶密度の向上によってその記憶容量を増大してきた。その後、顕著なトレンド転換を成し
遂げたのが 1988 年に発表され 1990 年代前半に普及した RAID (Redundant Arrays of
Inexpensive Disks)技術である[PAT88]。この技術によりストレージシステムの記憶容量は飛躍
的に増加した。RAID は、それまで主流であった大型の単体 HDD である SLED (Single Large
Expensive Disk)に替えて、小規模・低コストな複数台の HDD をグループにまとめ、記録デ
ータに加えて耐障害性のための冗長データを格納することで高信頼性を高め、また、複数ディ
スクを並列動作させることで高性能化を成し遂げるシステムアーキテクチャである。
本論文の対象とするデュアルコントローラストレージシステムも RAID アーキテクチャを採
用している。デュアルコントローラストレージシステムは、RAID の制御やデータ転送制御を司
るストレージコントローラを備える。
ストレージコントローラには、集中型ストレージシステムに要求される高い性能と、高度な
運用機能が要求されるため、サーバシステムに適用されるのと同様の最新型のマルチコア
CPU やメモリシステムが適用される。また、サーバシステムとの接続インタフェースには
FibreChannel や iSCSI (internet Small Computer System Interface)等、ディスクとの接続インタ
フェースには SAS (Serial Attached SCSI) 等のサーバ適用技術が共通利用される。このように
ストレージコントローラは、各種のサーバ技術が共通適用可能な計算機システムであると言え
る。これに加えて大容量のデータキャッシュの制御や、高信頼化・高可用化のためのコントロ
ーラ二重化のための専用ハードウェアが付設される
RAID によるライトペナルティの低減とアクセスレスポンスの向上のため、ストレージコントロ
ーラには Write After Cache 技術が用いられる。また、ストレージコントローラの障害時のデ
ータ喪失防止のため、ライトデータを両コントローラのキャッシュに二重書きする、フォールトト
レラント計算機などに用いられてきたキャッシュ二重化技術[AGG08]が適用される。
ところが二重化キャッシュを構築すると、キャッシュデータの整合性矛盾を防ぐため負荷
の重いコントローラ間の排他制御が必要になる。これを防止するための高速化技術として、前
述した LU オーナ権の概念が考案された[KOB97]。さらに、前述した LU 共有を要するクラスタ
7
第２章
型ソフトウェアに対応するため、Data Sharing 技術を用いた AAA 型デュアルコントローラ方式
が考案された[MAT99]。
以降の説明を簡単にするため、オーナコントローラが LU をアクセスすることを「ストレート
アクセス」、非オーナコントローラがオーナコントローラを経由して LU をアクセスすることを「クロ
スアクセス」と呼ぶことにする。
8
第２章
2.2.2
従来方式の概要
次に、従来方式である Data Sharing 技術を用いた AAA 型デュアルコントローラ方式につ
いて説明する[MAT99]。図２．１に AAA 型デュアルコントローラアーキテクチャの一例を示す。
CTL0 と CTL1 でデュアルコントローラを構成しており、データコントローラ DCTL がコント
ローラ内のデータ転送を制御している。また DCTL は、キャッシュデータの二重化のための
Duplication Engine を内蔵し、サーバから転送されたライトデータの両キャッシュへの二重書き
と、LU からリードしたデータの両キャッシュへの二重書きを行える。この機構により両コントロ
ーラが LU を共有できるため、これを Data Sharing 技術と呼ぶ。
またこの機構を活用しコントローラ間通信を行える。同図において、(1)CPU0 が PIO
（Programmed IO）により通信メッセージをキャッシュに格納すると、(2)Duplication Engine が他
系キャッシュ(CTL1 のキャッシュ）に通信メッセージを二重書きする。(3)その後 CPU0 は DCTL
の Communication Logic を起動し、(4)CPU1 に割り込みを発生させ、(5)CPU1 がそれを受信し、
キャッシュから通信メッセージを読み出すことで所望の通信が実現される。ここで、PIO とは
CPU がその命令セットを用いて IO メモリ空間からデータを入出力するアクセス方法のことであ
る。また同図で HIC とは Host I/F Controller の略で、サーバ等のホスト計算機とのデータ転
送を司るコントローラ回路である。
Server
CTL1
CTL0
HIC0
CPU0
(3)Com. Command
(1)PIO Write
to Cache
LU1 Owner
HIC1
Communication
Logic
Communication
Logic
Duplication
Engine
DCTL
(4)INT
(5)PIO Read
from Cache
Duplication
Engine
(2)Duplication
Memory0
CPU1
Cache0
Memory1
Cache1
: Communication Message
PIO: Programmed I/O
LU1
図２.１ Asymmetric Active-Active デュアルコントローラアーキテクチャ
9
第２章
2.2.3
従来方式の動作
AAA 方式の Read クロスアクセス動作図を図２．２に示す。コマンドを受領した CTL0 の
CPU0 は、(1)コマンド解釈や RAID 変換などのコマンド処理を実施する。ここで、オーナコント
ローラへの処理委託のため(A)メッセージ通信を実行する。CTL1 の CPU1 はこの要求を受信
し、(2)キャッシュ割り当て処理及び LU アクセス処理を実行する。LU からのデータ転送を完了
すると、(3)転送準備完了通知のため(B)メッセージ通信を実行する。CPU0 はこの転送準備完
了通知を受信し、(4)データ転送処理を実行し、(5)コマンド終了処理を実施のうえ、再度(C)メッ
セージ通信を実行し、CPU1 にコマンド終了を通知し、(6)CPU1 はコマンド終了処理を実行し
全処理が完了する。
AAA 型デュアルコントローラ方式では、クロスアクセスを行うと、ストレートアクセスに比べ
て性能が低下する。その理由は次の２点である。
(a)オーナコントローラにおける追加処理の発生
同図において、(1)コマンド処理、(2)キャッシュ割り当て処理及び LU アクセス処理、(4)デ
ータ転送処理、(5)コマンド終了処理はストレートアクセスの際にも実施する必要のある処理
CTL0
LU1 Owner
CTL1
(1)Command Process
(A)Communication
Request for
(2)Cache Allocation
proxy processing
& LU Access Process
Data Transfer
(LU -> Cache)
(3)Transfer Ready
Notification Process
(4)Data Transfer
Process
(B)Communication
Data Transfer
(Cache-> Server)
(5)Command End
(C)Communication
Process
Request for
(6)End Process
proxy processing
図２.２ Asymmetric Active-Active 方式の Read クロスアクセス動作
10
第２章
であるが、(3)転送準備完了通知処理、(6)終了処理は、オーナコントローラが非オーナコント
ローラから委託処理を実施するために追加になった処理である。この追加処理が必要となり、
ストレートアクセスに比べクロスアクセスは性能が低下する。
(b)コントローラ間メッセージ通信
委託処理の実施のため、数回のコントローラ間メッセージ通信が必要となる。同図の Read
処理の例では３回のメッセージ通信（同図(A),(B),(C)）が必要である。メッセージ送信元の
CPU は PIO を用いてキャッシュにメッセージを書きこむ必要があり、受信先の CPU は PIO
を用いてキャッシュからメッセージを読み込む必要がある。CPU から見るとキャッシュは IO 空
間に存在し、そのアクセス所要時間（アクセスレイテンシ）は長く、この間 CPU はアクセス完
了待ちとなり占有されるので、この PIO の CPU 負荷は大きなものとなる。このようにクロスアク
セスではストレートアクセスとは異なりコントローラ間メッセージ通信が必要となり、これにより
CPU 負荷が増加し性能が低下する。
2.2.4
従来方式の課題
次に、解決すべき従来方式の課題について、VM Load Balancing による性能劣化の例を
図２．３に示し説明する。左図は VM Load Balancing 実施前の状態である。Server0、Server1
が CTL0 に、Server2、Server3 が CTL1 に接続する。各サーバが扱う LU はストレートアクセス
100%になるよう初期設定されていて、この例ではトータルの IO スループットは 60,000IOPS で
ある。ここで、IOPS は、Input/Output Per Second の略であり、１秒間に発行される IO 負荷の
数を表す。このとき、Server0、Server2 の CPU 負荷が 80%に達し、高負荷の状態、Server1、
Server3 は CPU 負荷が 20%で低負荷の状態である。そこで、いくつかの VM の集合である
VM Chunk を Server0 から Server3 へ、Server2 から Server1 へ移動する VM Load Balancing
を実施する。すると、右図の通り Server0、Server2 の CPU 負荷は 60%に、Server1、Server3 の
CPU 負荷は 40%に均衡されるはずである。ところがストレージでは CTL0、CTL1 へのクロスア
クセスが 20%ずつ発生し、上述の性能劣化によりトータルの IO スループットは 2/3 の
40,000IOPS に低下する。サーバの CPU 負荷の余裕は出来たものの、ストレージシステムがボ
トルネックになり、サーバの性能は発揮できず、結果としてシステム性能は低下する。
このように、従来方式によれば、VM Load Balancing を行う環境において、クロスアクセス
が発生するとシステム低下を引き起こす。この課題を解決するために、クロスアクセスが発生し
11
第２章
ても実用上均質な性能対称性を備える新しい Active-Active 方式を実現することが本章の目
的である。
2.2.5
達成目標
一般にミッドレンジストレージの最大搭載 HDD 台数は最大 500 台程度である。そこでシ
ングルコア CPU を各々搭載したデュアルコントローラにより、この半数の HDD を動作可能と
することを目指す。実運用環境に合わせて事前設定も事後調整も必要ない実用上均質な性
能対称性を実現するため、クロスアクセス 100%時に達成すべき目標を以下の通り設定する。
なお、デュアルコア CPU を搭載すれば、さらなる性能向上が可能である。
(1)目標 1: ランダムリード／ライトともに HDD250 台を駆動可能な IO スループット性能を実現
(2)目標 2: ランダムリード／ライトともに HDD250 台駆動時にレスポンス時間増加が 10%以内
CPU
Load
server0 server1 server2 server3
CPU
Load
80%
60%
80%
VM
Chunk
Load
Balancing
40%
20%
App Load 20%
I/O Load
30000iops
CTL0
CTL1
Migration
0%
0%
30000iops
Migration
60%
40%
Straight
100%
server0 server1 server2 server3
20000iops
Straight
100%
Straight
80%
20000iops
CTL0
CTL1
Cross
20%
図２.３ VM Load Balancing によるシステム性能低下の例
12
Straight
80%
第２章
2.3 Semi-Symmetric Active-Active 方式の提案
2.3.1
コマンドキャスティング技術
従来方式の課題は非オーナコントローラからオーナコントローラへの処理委託により引き
起こされているので、この処理委託の削減を行うことを考える。コマンド受領した非オーナコント
ローラでは最低限の処理のみ実施し、それ以外の全ての処理はオーナコントローラで実施す
ればよい。その実現に向け、受領したコマンドを他系に移送する（Casting する）コマンドキャス
ティング技術を考案し、この技術を用いた Semi-Symmetric Active-Active (sSAA)方式を提案
する。コマンドキャスティング技術の詳細は、第３章で論じる。以下では同技術の概要のみ説
明する。
コマンドキャスティング技術の概要を図２．４に示す。図２．１に示した従来方式との構成上
の差異は、DCTL の内部の Communication Logic に替えて Bridge Logic を搭載したことであ
る。Bridge Logic は、他系コントローラのメモリ空間をあたかも自系のメモリ空間のようにアクセ
スすることが可能なアドレス変換およびメモリマッピング回路であり、これにより、CPU や HIC
が他系のメモリ空間をアクセスすることができる。
次にコマンドキャスティングの動作を説明する。サーバが発行したクロスアクセスコマンド
を非オーナコントローラの CTL0 が受信すると、CPU0 はこのコマンドを CTL1 のメモリ 1 上に
構成したコマンドキャスティングキューに「キャスト」する（移送する）。このメモリ１上のコマンドキ
ャスティングキューは Bridge Logic により CTL0 のメモリ空間にマッピングされるため CPU0 は
直接アクセス可能である。CPU1 はこのコマンドをキューから取り出し、以降 CPU1 がコマンド
を実行することでアクセスが完了する。
図２.４ コマンドキャスティング技術の概要
13
第２章
2.3.2
Semi-Symmetric Active-Active 方式の動作
ｓSAA 方式の Read クロスアクセスの動作図を図２．５に示す。CTL0 の CPU0 が実行する
のは、(0)コマンド解析処理だけである。コマンド解析の結果、クロスアクセスコマンドであるなら、
上記の通り、このコマンドを CTL1 のメモリに設置したコマンドキャスティングキューにキューイ
ングする方法でメッセージ伝送する（A）。以降の処理は全てオーナコントローラである CTL1
が実行する。CTL1 の CPU1 は、(1)コマンド処理、(2)キャッシュ割り当て処理及び LU アクセス
処理を実行する。LU からリードされたデータは両キャッシュに二重書きされる。(3)データ転送
処理において、CPU1 は BridgeLogic を経由して CTL0 の HIC0 を起動する。HIC0 は CTL0
の Cache からサーバへデータ転送を実行し、CPU1 に終了報告し、(4)終了処理の上、全コマ
ンド処理が完了する。
なお、コマンドキャスティング方式によるメッセージ伝送技術の詳細並びに評価結果は第
３章にて論じる。
CTL0
(0)Command Analysis
LU1 Owner
CTL1
(A)Command Casting
(1)Command Process
(2)Cache Allocation
& LU Access Process
Data Transfer
(LU -> Cache)
(3)Data Transfer
Process
Data Transfer
(Cache-> Server)
(4)Command End
Process
Transfer Execution by HIC0
(without CPU process)
図２.５ Semi-Symmetric Active-Active 方式の Read クロスアクセス動作
14
第２章
2.3.3
課題の解決
以上の動作により、クロスアクセスであっても処理の大部分はオーナコントローラで実行さ
れ、非オーナコントローラの処理負担増は(0)コマンド解析処理だけである。また、Data Sharing
方式で必要であった CPU にとって処理負担の重い PIO 処理は大幅に削減される。非オーナ
コントローラで(0)コマンド解析処理を実行しなくてはならないため、完全な性能対称には至ら
ないものの、ストレートアクセスとクロスアクセスとで実用上均質な性能対称性が得られると期待
される。これにより VM Load Balancing 実行時に従来発生していたシステム性能低下の課題
が解決できる。第２．４節でこれを評価する。表２．１に従来方式と提案方式の比較をまとめる。
Method
Conventional
Proposed
表２.１ 従来方式と提案方式の比較
Dual Controller
Technology
LU Sharing
Architecture
Asymmetric
Data Sharing
○
Active-Active
Semi-Symmetric
Command
○
Active-Active
Casting
15
VM Load
Balancing
×
○
第２章
2.4 提案方式の評価
2.4.1
評価指標
本節では提案方式の評価を行う。評価においては、小サイズデータ長 4KB 時のランダム
Read／Write を対象とする。Read クロスアクセスのラダーチャートを図２．６に示す。同図を参
照すると、サーバからの IO アクセス処理に要するレスポンスタイム T は式(2-1)で表せる。
=
ここで、
理時間、
+
+
+
は、HIC による処理時間、
（2-1）
は IO を受領した CTL0 の CPU による処
は CTL1 の CPU による処理時間、
は LU すなわちディスクの処理時間で
ある。クロスアクセスの際は両コントローラの CPU 処理を考慮する必要があるが、ストレートアク
セスの際には
は 0 となる。なお、キャッシュやメモリのハードウェア処理時間は他に比べ
て十分小さいできる時間であり、また
は
、
や
かっているのでそれぞれ無視する。よって、議論は
=
に比べ１桁以上小さいことが分
+
と
に集約される。
は HDD の処理時間ではるかに大きなミリ秒オーダの時間になるため、別途考慮すればよ
い。よって、
の評価が重要である。以下、
の評価方法について述べる。
T = Thic + Tcpu 0 + Tcpu1 + Tlu
Command
CTL0
Thic
HIC
Tcpu0
Memory
CPU
(1)
Cache
(A)Command
Casting
CTL1
Queuing
Memory
(2) Tcpu1
CPU
Cache
Tlu
LU
Data Status
HICの処理時間
CPU0の処理時間
(B)データ転送指示
(3)
(4)
CPU1の処理時間
LU（HDD）の処理時間
図２.６ 提案方式の Read クロスアクセスのラダーチャート
16
第２章
2.4.2
CPU 性能予測手法
(a)アクセス確率分布モデル
CPU の挙動解析に用いるアクセス確率分布モデルを図２．７に示す。ストレージに接続さ
れたサーバ群から確率 P0 で CTL0 に確率 P1 で CTL1 に IO 要求が発行される。CTL0 にお
いて、確率 Ps0 でストレートアクセス、確率 Pc0 でクロスアクセスが発生する。それぞれ確率 Pr0
でリード、Pw0 でライトのアクセスが発生する。CTL1 も同様である。
ここで、ストレージ固有の特性を考慮し、方式比較を行うのに必要十分な近似を行う。ま
ず、サーバ群が多数あり発行されるアクセスはランダムであると仮定すると、CTL0 と CTL1 に
は均等にアクセスが分散されるので、確率 P0 = P1 = 0.5 となる。同様の考えで、リード／ライト
アクセス、ストレート／クロスアクセスも均等に分散されるので両コントローラでその確率は一致
し、リード率＝Pr 、ストレート率＝α となる。また CTL0/1 は対称なので CTL0 のみを考える。こ
の近似確率分布モデルを図２．８に示す。以降、CTL0 のストレート／クロス、リード／ライトの
組み合わせによる確率 Pi （i は組み合わせを示す同図の領域(1)(2)(3)(4)に対応）を検討する
ことにする。
(b)CPU サービス時間計算モデル
CPU の挙動解析に用いる CPU サービス時間の計算モデルを図２．９に示す。ここで
CPU サービス時間とは、処理待ち時間を含まない各々のアクセス種毎の CPU 処理単価であ
り、t0s はストレートアクセスの CPU サービス時間、t0c はクロスアクセスの CPU サービス時間で
ある。ここで、CTL0 で受信したクロスアクセスの CPU サービス時間は、CTL0 側の CPU サ
Straight
CTL0
CTL1
Straight Cross Straight Cross
CTL0
CTL1
Cross Straight Cross
Pw0
1-Pr
(2)
(4)
Pr
(1)
(3)
α
1-α
Pw1
Pr0
Pr1
Ps0
Pc0
P0
Ps1 Pc1
0.5
P1
α
1-α
0.5
図２.８ 近似アクセス確率
分布モデル
図２.７ 汎用アクセス確率
分布モデル
17
第２章
ービス時間 t0c-a0 と CTL1 側の CPU サービス時間 t0c-b1 の合計である。CTL1 で受信したクロ
スアクセスの CPU サービス時間は、同様に t0c-a1 と t0c-b1 の合計である。前節で CTL0 と CTL1
の対称性を仮定したので、t0c-a0＝t0c-a1、t0c-b0＝t0c-b1 となり、よって、
′
=
+
=
となる。ここで、t’0c は、図２．９の破線で示す CTL0 における仮想的な CPU サービス時間
である。
すなわち、CTL0 と CTL1 のクロスアクセスは、それぞれの自系、他系における処理の断
片が各コントローラで合成されたと考えればよいので、計算上は仮想的な CPU サービス時間
t’0c を考えればよいことになる。CPU サービス時間は、ストレート／クロス、リード／ライトの各々
の組み合わせで、t0i （i は組み合わせを示す図２．８の領域(1)(2)(3)(4)に対応）と称し、以降こ
れらを検討する。なお、t0 は図２．６に示す通り時間的に分断されているが、近似して連続とみ
なし合算値で扱うことにする。
(c)CPU 性能予測計算式
以上求めたアクセス確率分布 Pi (i =1,2,3,4)と CPU サービス時間 t0i （i =1,2,3,4）を用い、
平均 CPU サービス時間(式(2-2))、分散(式(2-3))、変動係数(式(2-4))を求め、最後に M/G/1
待ち行列理論のポラチェック・ヒンチンの公式 [KLE79]を用い、平均 CPU レスポンス時間
を式(2-5)で求める。Pi (i =1 ,2,3,4)と t0i （i =1,2,3,4）の定義、ならびに、従来技術と提案技術
の双方の t0i の諸元を表２．２に示す。これらの数値には、従来機で実測した各 CPU 処理時間
から推定した値を使用する。λ は１秒あたりの平均コマンド到着率、すなわち IO スループット
性能である。以下、リード率 Pr 、ストレート率 α を評価パラメータとして設定し評価する。
(3)Read
(4)Write
(1)Read
(2)Write
t0c-a0
t0c-a1
t0s
t0s
t0c-b1
t0c-b0
t’0c
図２.９ CPU サービス時間の計算モデル
18
第２章
k
t=
∑ P ⋅t
i
(2-2)
0i
i =0
k
σ2 =
∑ ⋅ Pi ⋅ t
i =1 i
Cb =
2
0i
−t
2
(2-3)
σ
t
(2-4)
2
λ t (1 + Cb 2 )
Tcpu = t +
(2-5)
2(1 − λ t )
表２.２ アクセス確率分布と CPU サービス時間の定義
1
2
3
4
i
St/Cr
R/W
Read
Write
Read
Write
Pi
t
0i
αPr
(1-α)(1-Pr)
26.3 [us]
0SW
(1-α)Pr
Conventional
0SR
α(1-Pr)
138.3 [us]
141.3 [us]
265.7 [us]
Proposed
26.3 [us]
138.3 [us]
38.3 [us]
150.3 [us]
2.4.3
Straight
t
Cross
t
t’
0CR
t’
0CW
CPU 性能予測評価結果
(a) 最大 IO スループット性能
はじめに、CPU が処理可能な最大 IO スループット性能について評価する。最大 IO スル
ープット性能は式(2-2)で求められる平均 CPU サービス時間 t の逆数で算出できる。
従来方式、提案方式のストレートアクセス、クロスアクセス各々のコントローラ１台当たりの
最大 IO スループット性能を、HDD１台当たりの IO スループット性能で割った数値、すなわち
コントローラ１台が処理可能な最大 HDD 台数［HDDs Throughput］を表２．３に示す。
表２.３ 最大 IO スループット性能の比較
Straight
Cross
Method
Read
Write
Read
Write
Conventional
190 HDDｓ
140 HDDｓ
35HDDｓ
75 HDDｓ
Proposed
190 HDDｓ
140 HDDｓ
130 HDDｓ
130 HDDｓ
単位：HDDs Throughput
19
第２章
同表の通り、従来方式では、クロスアクセスの性能は、ストレートアクセスの性能に比べ大
幅に性能低下し 2.2.5 項で提示した目標１が達成できない。一方、提案方式では、クロスアク
セスの性能は、ストレートアクセスの性能に比べ、一定の性能低下は発生するが、目標１の
125 台の HDD を処理可能な IO スループット性能を達成できる。
従来方式に比較した提案方式の IO スループット性能の改善効果（Gain）を図２．１０に示
す。リード率に応じて 3.7 倍から 1.8 倍の改善効果を確認した。また、提案方式におけるストレ
ートアクセスに比べたクロスアクセスの性能低下率（Gap）を図２．１１に示す。リード率に応じて
31%から 8%の Gap が存在する。
この Gap のさらなる低減が今後の課題である。この性能低下が発生する理由は、2.3.2 項
で示した通り、クロスアクセスのコマンドを受信した非オーナコントローラが行うコマンド解析処
理が、オーナコントローラが行う通常コマンド処理に加えて必要となるためである。コマンド解
析処理が必要な理由は、コマンド解析を行わないと、ストレートアクセスなのか、クロスアクセス
なのか判別できないためである。しかし、もし、Host I/F Controller（HIC）にコマンド解析を行う
機能を搭載できるならば、CPU を介在させることなく、クロスアクセスの際に他系コントローラに
コマンドを振り分けることができ、CPU 処理時間を低減することが可能になる。今回の検討で
は、開発コスト低減の観点から、市場に流通する HIC の活用を前提にした。しかし、コマンド解
析機能を搭載した市販 HIC が存在しないため、CPU によりコマンド解析を行う方法を採用し
た。そして、HDD 処理可能台数の目標を設定することで、この処理時間増加を許容した。今
後の対応策としては、コマンド解析機能を搭載する HIC の独自開発、もしくは、同機能を搭載
した市販 HIC の適用が挙げられる。これにより、さらなる高速化が可能となる。
4.0
Cross/Straight Gap
Proposal/Conventional Gain
35%
3.5
30%
25%
2.5
Gap
Gain
3.0
2.0
1.5
20%
15%
1.0
10%
0.5
5%
0%
0.0
1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0
Read Ratio
1.0 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0
Read Ratio
図２.１０ 従来方式に比較
した提案方式の改善効果
図２.１１ クロスアクセス
の性能低下率
20
第２章
(b) レスポンス性能
式(2-5)を用い、IO スループットλに対する平均 CPU レスポンス時間
を評価する。リ
ード 100%時の CPU 性能予測結果を図２．１２に示す。
同図において、縦軸は、CPU 平均レスポンス時間を示し、IO 負荷≒０におけるストレート
アクセス時の平均レスポンス時間を１としたときの相対値で示す。横軸は、IO スループットを示
し、駆動可能な HDD 台数を HDDｓ Throughput を単位として示す。
2.2.5 項で設定した目標 2 で示された HDD 平均レスポンス時間の 10%を増加した値をタ
ーゲットラインとして同図に示し、目標１の 125HDDs Throughput が実現可能か否かを評価す
る。なお、上限のレスポンス時間を規定するので、ターゲットラインにおける IO スループットは、
表２．２に示した最大 IO スループット性能より低い値になる。
ターゲットラインにおいて、ストレート 100%では 185HDDs Throughput に対し、クロス 100%
では、従来方式が 30HDDs Throughput、提案方式が 125HDDs Throughput であった。なお、
従来方式に対する提案方式の高速化倍率は 4.2 倍であった。以上より、提案方式により目標
を達成できる見通しを得た。
図２.１２ Read100% CPU 性能予測結果
21
第２章
次に、ライト 100%時の CPU 性能予測結果を図２．１３に示す。同様に、1 台のコントローラ
当たり 125HDDs Throughput の実現が達成目標である。CPU がパリティ生成を含む平均
HDD レスポンス時間の 10%で応答できる IO スループットを評価する。ストレート 100%では
140HDDs Throughput に対し、クロス 100%では、従来方式が 70HDDs Throughput、提案方式
が 125HDDs Throughput であった。なお、従来方式に対する提案方式の高速化倍率は 1.8
倍であった。以上より、提案方式により目標を達成できる見通しを得た。
図２.１３ Write100% CPU 性能予測結果
22
第２章
2.5 結言
本章では、実用上均質な性能対称性を実現するデュアルコントローラ方式の実現を目的と
し、以下の知見を得た。
(1) デュアルコントローラ方式の達成目標として、クロスアクセス時にランダムリード／ライトと
もに HDD250 台を駆動可能な IO スループット性能を実現することと設定した。
(2) LU オーナ権の有無に関わらず実用上均質な性能対称性を実現する Semi-Symmetric
Active-Active 型デュアルコントローラ方式を提唱した。
(3) Semi-Symmetric Active-Active 方式を実現するために、非オーナコントローラが受信し
たコマンドをオーナコントローラに高速に移送するコマンドキャスティング技術を考案した
（コマンドキャスティング技術の詳細と評価結果は第３章にて論じる）。
(4) Semi-Symmetric Active-Active 方式の性能評価を行うために、待ち行列理論を用いた
CPU 性能予測手法を確立した。評価の結果、Semi-Symmetric Active-Active 方式によ
ると、クロスアクセスの IO スループット性能において、従来方式比 1.8～4.2 倍の性能改
善を達成し、目標とする HDD250 台を駆動可能な IO スループット性能をレスポンス時間
増加 10%未満で達成できる見通しを得た。
(5) 今後の課題は、ストレートアクセスに対するクロスアクセスの性能低下の改善である。
Host I/F Controller へのコマンド解析機能の搭載により、非オーナコントローラの CPU
で実施が必要だったコマンド解析処理時間を削減することが可能になる。
23
第３章
第３章
高速メッセージ伝送技術による高性能化
3.1 緒言
従来、LU 共有型クラスタサーバの出現により、１台の LU を２台のストレージコントローラ
から共有するニーズが生じ、これに対応するため、非オーナコントローラがオーナコントローラ
に LU 制御を委託し LU 共有を実現する Asymmetric Active-Active（AAA）方式が考案された
[MAT99] 。LU 制御を委託するために、コントローラ間でメッセージを伝送することが必要であ
り、そのメッセージ伝送技術として、Data Sharing 方式が考案された。コントローラが備える二
重化キャッシュ機構を通信路と見立て、CPU がキャッシュに格納したメッセージが二重化キャ
ッシュ機構の働きにより他系のキャッシュに伝送され、他系の CPU がこれを読み出すことでメ
ッセージ伝送が実現された。
しかしながら、この方式によれば、メッセージ伝送時に、両コントローラの CPU が介在する
必要があるため CPU オーバヘッドが増加した。これにより IO 処理時間の増大を招き、結果的
に IO スループット性能およびレスポンス性能が通常の LU アクセス時に比べ低下した。その
結果、同一の LU へのアクセスであっても、サーバが接続するコントローラの LU オーナ権の
有無に依存して LU アクセス性能の対称性が損なわれるという課題があった。
第２章では、非オーナコントローラからの LU アクセス性能を向上し LU 共有性能の対称
性を確保する技術として Semi-Symmetric Active-Active（sSAA）型デュアルコントローラ方式
を提唱した。本章では、同技術に適用するコントローラ間メッセージ伝送技術に注目し、上記
の課題を解決して、メッセージ伝送の高速化と両コントローラの CPU 負荷の軽減を図る「コマ
ンドキャスティング技術」の実現と評価について論じる。
以下、３．２節では、従来のコントローラ間メッセージ伝送技術として、上記の従来技術
[MAT99] に加え、他のストレージシステム向けメッセージ伝送技術[TAK03][YUL05]や、他分
野である制御用計算機向けメッセージ伝送技術[TAK87][AKI87][SAT99]について概観する。
３．３節では、課題解決に向けコマンドキャスティング方式を提案する。３．４節では、評価方法
および評価結果を述べ、提案方式の効果を検証する。３．５節では、LU アクセス性能の対称
性と SSD(Solid State Drive)の適用性について、３．４節の結果を元に考察する。
25
第３章
3.2 従来のメッセージ伝送技術と課題
本節では、デュアルコントローラ型ストレージシステムの LU 共有制御に不可欠となるメッ
セージ伝送技術に関し従来技術を列挙する。
3.2.1
従来のメッセージ伝送技術
（１）Data Sharing（DS）方式
LU 共有型クラスタソフトウェアに対応するため、デュアルコントローラ間で LU 共有制御を
行う AAA 型デュアルコントローラ方式が考案された[MAT99][RAN01]。図３．1 に同方式によ
る LU 共有アクセス制御の概要を示す。
この処理委託のため考案されたコントローラ間メッセージ伝送技術が、第２章で示した
Data Sharing 方式（以下 DS 方式）である[MAT99]。同方式は、コントローラ内に構成された二
重化キャッシュ機構を通信路に見立てメッセージ伝送を実現する。
しかし、DS 方式では、CPU がキャッシュにメッセージデータをリード／ライトする際に PIO
（Programed IO）と呼ばれる IO 空間上のメモリアクセスを CPU 命令で行う方法で実行しており、
低速な PIO は CPU オーバヘッドを増加させる。またメッセージ伝送の完了はコントローラ間割
込みによって他系に通知される。この割込み処理も CPU オーバヘッドが大きな処理である。こ
Server0
LU0
LU1
Cross
Access
CTL0
Server1
LU sharing
LU2
Straight
Access
FAST
Slow
CPU0
LU0 Owner
CTL1
CPU1
Cache0
Cache1
LU1 Owner
LU2 Owner
LU0
LU1
LU2
図３.１ Asymmetric Active-Active 方式による LU 共有アクセス制御
26
第３章
のように、DS 方式によるメッセージ伝送は、CPU オーバヘッドの増大とメッセージ伝送時間の
長期化を引き起こし、これによって、クロスアクセスの性能はストレートアクセスに比べて低下す
る。
（２）Shared Memory（SM）方式
複数台のコントローラを備え全コントローラが全ての LU を共有することを可能とした大規
模ストレージシステムが知られている[TAK03][YUL05]。複数の CPU が共有メモリ（SM）を介し
て制御情報を共有することで複数のコントローラ間で LU 共有を実現できる。この SM による制
御情報の共有機構もコントローラ間メッセージ伝送技術の一つとして捉えることができる。
しかし、SM 方式では、コントローラが SM に格納された制御情報を操作するのに先立ち、
SM の排他アクセス権の確保が必要である。また、DS 方式と同様に SM へのメッセージのリ
ード／ライトは PIO 処理である。これらの影響で、CPU オーバヘッドが増大しメッセージ伝送
時間も長期化する。
（３）Reflective Memory (RM）方式
次に、他分野にも目を転じ、複数のコントローラで構成された制御用計算機[MIT86] のメ
ッセージ伝送技術に注目する。その一つの技術としてメモリ転写方式（Reflective Memory：RM
方式）が知られている[TAK87] 。任意の複数のコントローラ間をリアルタイムでメッセージ交換
することを目的に、汎用ネットワーク技術[SAW88][OKA90][TAK00]を利用すべく考案された
技術である。
同方式は、ネッ ト ワーク に接続され た複数のコ ント ローラ が、転写 メモ リ （Reflective
Memory）と呼ばれるワークメモリ(Work Memory：以下 WM と略記する)を有する構成であり、
CPU が WM にメモリを格納すると、ネットワークコントローラ（NetWork Controller: 以下 NWC
と略記する）が他コントローラにブロードキャストしてメッセージを伝送する。他のコントローラは
自身が必要なメッセージを選択受領する。コントローラ間の排他制御は不要である。
しかし、RM 方式では、上記同様に CPU が WM 上のメッセージを PIO でリード／ライトす
る必要があり、また、メッセージ伝送にネットワークを用いるため、CPU は NWC 制御処理も行
う必要がある。
27
第３章
（４）Fault Tolerant with Shared Memory（FS）方式
制御計算機用メッセージ伝送技術として、機能の異なる異種コントローラをネットワークで
相互接続しつつ、可用性確保のためコントローラを二重化して、それらのコントローラ間で情報
共有を行う技術として、フォールトトレラント共有メモリ方式（FS 方式）が知られている[AKI87] 。
高信頼性が必要な大規模制御システムを構成することができる。
同方式は、上記（２）SM 方式と同様に複数のコントローラ間に共有メモリ SM を設置する。
SM をネットワークで接続した SM Controller(以下 SMC と略記する)として構成し、全コントロ
ーラと SMC をネットワークで接続した点が SM 方式との相違点である。NWC 制御が追加され
るので SM 方式に比してオーバヘッドは大きくなる。CPU オーバヘッドもメッセージ伝送時間も
全方式の中で最も大きくなることが推測される。
（５）Reflective Memory with Shared Local Memory（RS）方式
RS 方式[SAT99]は（３）メモリ転写方式(RM 方式) [TAK87] の改善型として知られている。
WS を廃止し、その機能を主記憶メモリ（Local Memory：以下 LM と略記する)上に配置したこと
が特徴である。同方式は、バスマスタ型の NWC を備えることが RM 方式との相違である。コン
トローラの CPU は、LM 上に構成した転写メモリ領域にメッセージを格納すると、NWC が LM
からメッセージを取得し、他コントローラにブロードキャストでメッセージを伝送する。
RS 方式では、RM 方式と異なりメッセージは CPU 隣接の LM に配置するので、そのリ
ード／ライトは高速であり、CPU オーバヘッドもメッセージ伝送時間も小さい。一方、NW 接続
型のため、NWC 制御を行う必要があることは RM 方式、FS 方式と同一である。
3.2.2
従来技術の整理
従来方式（１）（２）はストレージ専用のハードウェアを搭載したメッセージ伝送技術、（３）
（４）（５）は汎用のネットワークを活用した汎用のメッセージ伝送技術である。また別の観点では、
（１）（３）はメッセージ伝送専用のワークメモリ(WM)を使用した技術、（２）（４）はコントローラ間の
共有メモリ(SM)を使用した技術、（５）はメッセージ伝送用の主記憶メモリ（LM）を使用した技術
である。
28
第３章
表３.１ 従来のメッセージ伝送技術の形態別の分類結果
(a)Interface
Storage Dedicated
General Network
(b)Memory Type
Work Memory
(1)DS method [MAT99]
(3) RM method [TAK87]
Shared Memory
(2)SM method [TAK03]
(4) FS method [AKI87]
Local Memory
－
(5) RS method [SAT99]
従来のメッセージ伝送技術を形態別に分類した結果を表３．１に示す。(a)伝送手段の軸
（ストレージ専用接続路/汎用ネットワーク）、(b)メモリ形態の軸（ワークメモリ/共有メモリ/主記
憶メモリ）での２軸で、２×３の６件の組み合わせが考えられる。ここで、同表に示す通り(a)ストレ
ージ専用接続路×(b)主記憶メモリの組み合わせでは従来技術は存在していないことがわかる。
上記の通り、(5)RS 方式は、1987 年に開発された(3)RM 方式の改善型として 1999 年に開発さ
れたが、小型化・低価格化に対するニーズの出現と、LSI 技術の進化による実現性の向上の
両面の観点から、発展の経過の中で創生されたものである。このことからの類推によると、高速
化に対するニーズの出現と LSI 技術の進化による実現性の向上が見られる現時点において、
(a)ストレージ専用接続路と(b)主記憶メモリの組合せによる発展形態が同様に考えうる。これに
ついては３．３節にて考察する。
3.3 コマンドキャスティング方式の提案
3.3.1
課題解決の基本方針
課題解決に向けた基本方針を検討する。３．２節で検討した従来技術の特徴をまとめると、
(i)CPU オーバヘッドの低減、(ii)メッセージ伝送時間の低減、の 2 点が重要な技術課題である
と言える。
(i) CPU オーバヘッドの低減
３．２節の考察より、(ｱ)PIO 処理の削減、(ｲ)NW 制御処理の不要化、 (ｳ)排他制御の不要化、
を実現する方式を基本方針とする。
(ii)メッセージ伝送時間の低減
(ｱ）CPU 処理時間の削減((i)同様）、(ｲ)高速な専用ハードウェア活用による伝送処理時間の
低減、を実現する方式を基本方針とする。
29
第３章
ここで、前項の表３．１で整理した通り、従来技術では、(a)ストレージ専用接続路×(b)主
記憶メモリの組み合わせは考慮されていない。しかし、前項で示唆した通り、(5)RS 方式の登
場時と同様に技術発展の経過により、新しい技術が開発可能になると考えられる。また、本組
み合わせは、(5)RS 方式の特徴からの類推により、上記課題の解決にも効果的と推測される。
そこで、ストレージ専用接続ハードウェアと主記憶メモリの活用を念頭においた新メッセージ伝
送方式としてコマンドキャスティング方式（CC 方式）を提案する。
3.3.2
コマンドキャスティング方式の実現
（１）ハードウェア
CC 方式のハードウェア構成図を図３．２に示す。両コントローラ（CTL0/1）には Data
Controller と称するハードウェア回路を設ける。Data Controller はサーバ等のホスト計算機
（サーバ）とのコマンドやデータの送受信を行う Host I/F Controller、ディスクとのコマンドやデ
ータの送受信を行う Disk I/F Controller、大容量の Cache Memory、CPU と Local Memory を
接続する Bridge をそれぞれ接続し、これらの間のデータ転送制御を司る。また両コントローラ
間を双方向で直接接続する専用接続路の制御を司る。Cache Memory に格納されるデータは、
Local
Memory
0x0_00000000
0x0_7fffffff
0x0_00000000
0x0_7fffffff
Data Controller
Data Controller
0x1_00000000
0x1_7fffffff
Address
Address
Exchanger 0x6_00000000
Host
I/F
CTL
Disk
I/F
CTL
Data CTL
Registers
0x7_ffffffff
0x6_00000000 Exchanger
0x7_ffffffff
0x6_00000000
0x7_ffffffff
0x6_00000000
0x7_ffffffff
Host
I/F
CTL
Data CTL
Registers
0x1_80000000
0x1_80000000
0x1_ffffffff
0x2_00000000
0x5_ffffffff
CPU
1
Bridge
Registers
Bridge
Registers
Local
Memory
0x0_80000000
0x0_ffffffff
CPU
0
Bridge
0x0_80000000
0x0_ffffffff
Bridge
0x1_ffffffff
Cache
Memory
Cache
Memory
図３.２ CC 方式のハードウェア
30
0x1_00000000
0x1_7fffffff
0x2_00000000
0x5_ffffffff
CTL1
CTL0
Disk
I/F
CTL
第３章
高信頼化のため、Data Controller により専用接続路を経由して他系コントローラの Cache
Memory に二重書きされる。表３．２に両コントローラから見たメモリマップの設計の例を示す。
表３.２ 両コントローラから見たメモリマップの設計の例
Address
0x0_00000000-0x0_7fffffff
0x0_80000000-0x0_ffffffff
0x1_00000000-0x1_7fffffff
0x1_80000000-0x1_ffffffff
0x2_00000000-0x5_ffffffff
0x6_00000000-0x6_7fffffff
0x6_80000000-0x6_ffffffff
0x7_00000000-0x7_7fffffff
0x7_80000000-0x7_ffffffff
CTL0 Memory Map
CTL1 Memory Map
CTL0 Local Memory
CTL1 Local Memory
CTL0 Bridge Register
CTL1 Bridge Register
CTL0 Host I/F Controller Reg CTL1 Host I/F Controller Reg
CTL0 Disk I/F Controller Reg
CTL1 Disk I/F Controller Reg
CTL0 Data Controller Register CTL1 Data Controller Register
CTL0&1 Cache Memory
CTL0&1 Cache Memory
CTL1 Local Memory
CTL0Local Memory
CTL1 Bridge Register
CTL0 Bridge Register
CTL1 Host I/F Processor Reg CTL0 Host I/F Processor Reg
CTL1 Disk I/F Controller Reg
CTL0 Disk I/F Controller Reg
CTL1 Data Controller Register CTL0 Data Controller Register
Notes
Self
Shared
Other's
CTL0 の 0x0_00000000-0x1_ffffffff は自系コントローラの Local Memory、Bridge、Host
I/F Controller 、 Disk I/F Controller 、 Data Controller の メ モ リ 空 間 で あ る 。 一 方 、
0x6_00000000-0x7_ffffffff は他系コントローラ CTL1 の Local Memory、Bridge、Host I/F
Controller、Disk I/F Controller、Data Controller のメモリ空間がマッピングされている。このよ
うに、各々のメモリ空間が他方からも相互参照可能になるように Data Contorller を設計した。
これにより、CTL0 から CTL1 のメモリへの直接アクセスすることが可能である。CTL1 に関して
も同様である。
図３．２に戻り、このメモリマップの実現性について説明する。Local Memory(LM)、Bridge
Register のメモリマップは Bridge の機能により実現される。これらのアドレス値は CPU の初期
化時に Flash メモリ（図示されていない）から読み出され Bridge のレジスタに設定される。一方、
それ以外のメモリマップは Data Controller の機能により実現される。これらのアドレス値はソフ
トウェアの初期化時に Flash メモリから読み出され Data Controller のレジスタに設定される。
他系のメモリ空間を直接アクセス可能とするため、他系メモリへのアクセス要求は、Data
Controller がコントローラ間通信路を介し他系へ転送し、同図に示す他系の Data Controller
のアドレス変換回路(Address Exchanger)が他系コントローラの内部アドレスに変換する。
以上のハードウェア機能により CPU は他系の LM をあたかも自系の LM であるかのよう
に load、store 命令により直接アクセスできるようになる。
31
第３章
ここで、他系 LM アクセスについて説明する。CPU にとって他系 LM は論理的に遠距離
に配置されたメモリのため、一般にアクセス時間は長期化する。しかし Posted Write というハ
ードウェア機能を用いることで store 命令の CPU オーバヘッドに関してはその影響を極小化
できる。Posted Write とはデータライト時に近傍のバッファにデータ転送を終了した時点で
store 命令を終了させられる遅延書き込み機能である。他系 LM アクセス時にも CPU が隣接
する自系 Bridge のバッファにデータをライトした時点で store 命令は完了する。その後はハ
ードウェアが CPU 非介在でデータを他系 LM まで転送する。この特性の活用については
3.4.2 項で述べる。
（２）ソフトウェア
CTL0/1 の LM の構成を図３．３に示す。同図の通り、記憶領域を、自系コントローラ受信
コマンド格納領域、他系コントローラ受信コマンド格納領域、共有領域の３つの記憶領域に分
けて管理する。
自系コントローラ受信コマンド格納領域には Receive Queue 領域が設けられており、自系
の Hosｔ I/F Controller が受信したコマンドがこの Receive Queue 領域に格納される。また他
Receive Queue
Command Queue
Self CTL
Received Command
Storing Area
Receive Queue
Command Queue
Self CTL
Received Command
Storing Area
Command Cast
Queue
Other CTL
Received Command
Storing Area
Command Cast
Queue
Other CTL
Received Command
Storing Area
LU Table
Local Memory
Info Table
Cache Memory Info
Table
Shared Area
LU Table
Local Memory
Info Table
Cache Memory Info
Table
Shared Area
(A)CTL0 Local Memory
(B)CTL1 Local Memory
図３.３ CTL0/1 の LM の構成
32
第３章
系コントローラ受信コマンド格納領域には Command Cast Queue 領域が設けられており、他系
のコントローラの Host I/F Controller が受信したコマンドが格納される。両コントローラで共有
される領域には LU ごとのオーナコントローラを示す LU テーブルや、主記憶メモリ管理やキャ
ッシュメモリ管理のための情報テーブルが格納される。
表３.３ LU テーブル
Owner Controller
CTL0
CTL1
CTL1
・・・
LU#
0
1
2
・・・
Operation Flag
・・・
・・・
・・・
・・・
LU テーブルの例を表３．３に示す。図３．１の構成を示した例であり、LU0 は CTL0 が、
LU1, 2 は CTL1 がオーナコントローラであることを、この表の参照により判定できる。
CC 方式の動作概念図を図３．４に示す。ホスト計算機（サーバ）から LU2 をアクセスする
ホストコマンド（以下単にコマンドと略記）を受信すると、Host I/F Controller A は図３．３の自
系コントローラ受信コマンド格納領域の Receive Queue に格納する。CPU0 は表３．３の LU
Table を参照し対象 LU の担当が自系であるかどうかを判定する。この判定により否定結果を
得ると、CPU0 は図３．３の他系 LM の他系コントローラ受信コマンド格納領域に設定した
Command Cast Queue にコマンドをメッセージとして伝送（キャスト）する。CPU1 は定期的なポ
Host Command
to LU2
A
Host I/F
Controller
B
Receive
Queue
CTL0
C
D
Local
Memory
Local
Memory
CPU1
CPU0
Command
Queue
A' B' C' D'
A B C D
LU0
CTL1
Command
Cast Queue
LU1
図３.４ CC 方式の動作概念図
33
LU2
第３章
ーリングにより LM を 監視し ており、コマ ンドが格納されたこと を検出すると、CPU1 は
Command Cast Queue からこのコマンドを取り出し、オーナコントローラである CTL1 がコマン
ド処理を実行する。
Command Cast Queue の管理について図３．５を用い説明する。同キューは、コマンドの
入力を管理する In-Pointer と出力を管理する Out-Pointer の２つのポインタで制御する。InPointer は他系 CPU0 のみがインクリメント可能で、CPU0 がコマンドを入力後に当該エントリに
ポイントする。一方、Out-Pointer は自系 CPU1 のみがインクリメント可能で、CPU１がコマンド
を出力時に対象エントリをポイントする。ただし、In-Pointer≧Out-Pointer の条件を常に満た
す必要がある。これによりキューの入力・出力を独立化できるので、両コントローラ間での排他
制御は不要である。
前述のとおり CPU１は In-Pointer のポーリングにて新規コマンドのキュー入力を確認する。
確認時にキュー入力がすれ違いで検出できないときがあるが、翌ポーリング周期にて検出す
ればよい。このため、キューへの入出力において整合不良は発生しない。また、システムの処
理能力を超えたコマンドのキューイングがなされるとキューがオーバフローすることがある。これ
を防止するために、SCSI 仕様で定められた Queue Full 応答により、コマンドのキューイングを
抑止することが必要である。
このメッセージ伝送に要する両コントローラの CPU のオーバヘッドについて説明する。前
述のとおり、他系 LM にコマンドをメッセージとしてキャストする際には Posted Write の機能が
用いられる。CPU0 は近傍のバッファにデータを書き込んだ時点で store 命令を終了させられ
るので、ハードウェア論理段数から見て遠方にある他系 LM へのデータ書き込みの完了を待
つ必要がない。これにより CPU0 のオーバヘッドは最小に抑えられる。また CPU1 がメッセ
Command
Queue
A'
In-Pointer
[by CPU0]
Out-Pointer
[by CPU1]
図３.５ Command Queue の管理
34
第３章
ージとしてコマンドを受領する際には、自系 LM からメッセージをリードすればよいので、最小
のオーバヘッドでメッセージを受領できる。以上より、本方式により前記に示した技術課題の解
決の見通しが得られた。３．４節にて定量評価し検証する。
3.3.3
コストに関する検討
従来技術 Data Sharing 方式[MAT99]を実装したデュアルコントローラ型ストレージシステ
ム の 代 表 例 と し て 、 Hitachi Freedom Storage Thunder9200 が 知 ら れ て い る [RAN01] 。
Thunder9200 は Data Sharing 方式を実現するために、コントローラ間ブリッジ ASIC "D-CTL"
を備える。この D-CTL は、図３．２に示す本章の Data Controller と同様にキャッシュ二重化
回路を備え、表３．２の"CTL0&1 Cache Memory"のアドレス空間において自系キャッシュメモリ
と他系キャッシュメモリの両方にデータを二重書きする。
提案方式は、この従来技術に加え、同図、同表の通り、コマンドキャスティング方式を実
現するために、自系 CTL0 のメモリ空間に他系 CTL1 の"CTL1 Local Memory"をマッピング
する回路（またはその逆）を追加したものである。これらの追加回路は、DMA 回路、マルチプ
レクサ回路、レジスタ回路などで構成されるが、時代の変遷による ASIC 回路規模の拡大に伴
い、これらを１つの ASIC に搭載することはコスト的に問題のないレベルである。
他の部位に関しても、同 Thunder9200 と本章の基本アーキテクチャは同一であり、その
構成部品として、ホスト I/F コントローラ、ディスク I/F コントローラ、CPU、メモリなどがあるが、
時代の変遷により進化したトレンド上の技術・製品を用いることにより、コスト増加を伴うことなく
実装することが可能となる。
以上より、従来システム Thunder9200 との対比において、コスト面でも現実性の高い方式
であると言える。
3.3.4
技術的障害に関する検討
本方式の実現に際し新たに考慮しなくてはならないのは障害時の対応である。従来はコ
マンドを受信したコントローラが処理を主導するので、障害が発生した際には、
(a)同コントローラがエラー処理をする
(b)同コントローラがダウンしホスト計算機からのリトライに応じ他系が引き継ぐ
35
第３章
のいずれかであった。しかし本提案方式ではコマンドを受信したコントローラとは異なる他系コ
ントローラにコマンドをキャスティングするので、新たに他系での障害モードに関しても考慮が
必要となる。
コマンドキャスティング後に他系コントローラに障害が発生した場合には、同じく、(a')他系
コントローラがエラー処理を行う、(b')他系コントローラがダウンし自系が引き継ぐ、のいずれか
である。特に、(b')の場合、自系は他系にコマンドキャスティング後もコマンドの管理とキャッシ
ュデータの維持・管理を行っているので、自系コントローラが他系ダウンを検出し、他系を安全
停止の上、LU オーナ権を自系にて強制確保してデータを失うことなく対象コマンドの処理を
継続する。
以上のように、新たな障害モードへの対処についても、従来のエラー処理と同様に実行
できるので、このことが本方式の実現に際して技術的障害になることはない。
3.4 提案方式の評価
３．２節に示した従来技術と提案方式に関し、評価モデルを構築し、効果を定量評価する。
評価指標としては、（ａ）CPU オーバヘッド（以下 OH と略記する）、（ｂ）メッセージ伝送時間、
の２項目とし、メッセージ長をパラメータとする。
3.4.1
評価モデル
３．２節に示した 5 つの従来技術は、その使用目的や実装が各々異なることから、これら
技術の本質的な得失を対等に評価することは難しい。そこで本章では各技術を同一基準で模
式化した評価モデルを構築し、これらから評価計算式を導出する。そのうえで、同一基準のデ
ータを用いて、上記２つの評価指標を対等に評価することを試みる。従来方式および提案方
式の評価モデルを図３．６～１１に示す。図３．６～１０は従来方式である(1)DS 方式、(2)SM 方
式、(3)RM 方式、(4)FS 方式、(5)RS 方式をそれぞれ示す。図３．１１は提案方式である(6)CC
方式を示す。
36
第３章
(iii)ti
CPU ●
(i)t1r
B
●
LM
LM
●
(v)t1w
B
●CPU
(iv)t3r
(ii)t3w
WM ●
B
B
(ii')copy
●
WM
CTL0
CTL1
●:Message
図３.６ 従来技術 （１）DS 方式
(i)tl0
CPU
(i)tl1
(iv)ti
●
(ii)t1r
B
CTL0
B
●
LM
LM
●
(vi)t1w
B
(v)t3r
(iii)t3w
●
CPU
CTL1
B
●:Message
B
●
SM
SMC
図３.７ 従来技術 (２)SM 方式
CPU ●
(i)t1r
B
(ii)t3w
WM ●
B
●
LM
LM
(iii)tnwDs
NWC
●
(vi)t1w
B
(iv)tnwDr
(iii')Send
NWC
CTL0
●CPU
(v)t3r
B
●
WM
CTL1
●:Message
図３.８ 従来技術 （３）RM 方式
37
第３章
CPU ●
(i)t1r
B
(ii)t1w
(iii)tnwDs x2
CTL0
B
●:Message
●
●
LM
●
LM
●
(iv)int
NWC
(vii)t1w
B
(iv)t1r
B
NWC
(iii')Send
●
CPU
(v)tnwDr x2
CTL1
(v')Receive
NWC
CPU
B
●
SM
SMC
図３.９ 従来技術 （４）FS 方式
CPU
●
(i)t1r
B
(ii)t1w
●
●
LM
(iii)tnwDs
LM
●
●
(iv)t1w
B
(v)t1r
NWC
CPU
(iv)tnwDr
(iii')Send
B
●
NWC
B
CTL0
CTL1
●:Message
図３.１０ 従来技術 （５）RS 方式
●
CPU
(i)t1r
B
Bridge
Logic
●
LM
LM
●
(ii)t4w
B
CPU
Bridge
Logic
CTL0
CTL1
●:Message
図３.１１ 提案技術 （６）CC 方式
38
第３章
3.4.2
性能諸元データ
本計算に用いる諸元データの取得のために用いた試作機の仕様を表３．４に示す。表３．
５に同試作機にて測定した各諸元データの実測値を示す。表３．６は本計算に纏わる処理項
目と処理時間を示す。なお、ti, Tp, tl は同試作機による実測値である。tnwD, TnwC には文献
[FRE13]にて公表された試作機同等環境における実測値を用いた。
#
1
2
3
4
5
6
7
表３.４ 諸元データの取得のために用いた試作機の仕様
Parts
Specification
Remarks
CPU
1.67GHz
1 Core
L2 Cache
512KB
Local Memory
1GB
Internal Bus
PCIe Gen1
8 Lanes
Interconnect Bus
PCIe Gen1
8 Lanes, Duplex
Bridge Buffer Size
64words
NW Transfer Speed x: 100MB/s
表３.５ メモリアクセスに要する CPU オーバヘッドと転送時間
CPU Overhead
Transfer Time
Memory
read
write
read
write
Self Local Memory
t1r 0.1us t1w 6 ns
T1r 0.1 us T1w 0.1 us
Self Control Register
t2r 1.1us t2w 6 ns
T2r 1.1us T2w 0.6 us
Self Shared Memory
t3r 1.3us t3w 6 ns
T3r 1.3us T3w 0.7 us
Other Local Memory
t4r
2.3us
t4w
6 ns
T4r
2.3us T4w 1.1 us
ここで、t (小文字)は CPU の実行オーバヘッド（以下、OH と略記）を表す。T (大文字)は
データ転送処理の所要時間を表す。例えば自系 LM のリード時の CPU OH t1r とデータ転送
所要時間 T1r は同じで 0.1us であるが、ライト時の CPU OH t1w は Posted Write の効果に
より 6ns と極小であるがデータ転送時間 T1w は 0.1us と大きくなる。
#
ｔi
Tp
ｔl
ｔnwD
TnwC
表３.６ 本計算に纏わる処理項目と処理時間
Operation
Operation Time
Interrupt Process (CTL0-CTL1)
8us
Polling Process
5us
Exclusive Locking Process
self:ｔl0 : 6.2us
other:ｔl1: 3.6us
NW Driver CPU Process
Receive:ｔnwDｒ : 11us
Send:ｔnwDs :9us
NW Controller Internal Process
Receive:TnwCｒ : 6us
Send:TnwCs :9us
39
第３章
表３．６の、t (小文字)と T (大文字)の意味も表３．５と同様である。CPU OH と処理所要時
間が同一の場合は CPU OH t （小文字）で代表させた。
3.4.3
評価計算式
評価モデルを用い、評価指標毎に評価計算式を導出する。自系 CPU0 が自系の主記憶
に格納された n ワード（１ワード＝4Byte）のメッセージを、他系の主記憶にメッセージ伝送し他
系 CPU1 が当該メッセージを使用可能になるまでの期間において、両 CPU がその処理に要
する処理時間（CPU OH）、ならびにメッセージが伝送完了となるまでの所要時間（メッセージ
伝送時間）を導出する。なお、後述の式（3-9）（3-10）（3-11）において、n ワード×4 によりバイ
ト数に変換のうえ、ネットワークの転送速度 x [MByte/S]で割ることで伝送時間を算出する。
(a)CPU OH の評価計算式
各々の方式に対し自系 CPU(CPU0)、他系 CPU(CPU1)の OH の計算式を以下に示す。
(1)DS 方式
[1] = ( 1 + 3 ) ×
[1] = ( 3 + 1 ) ×
+
（3-1a）
（3-1b）
自系 CPU は自系 LM からメッセージをリードしキャッシュメモリ上の WM にライトすると二重
化機能により他系 WM にメッセージがコピーされる。その後、通知のため他系へコントローラ
間割込みを発行する。他系 CPU はポーリングで受信を検出し、WM からメッセージをリード
し LM にライトしメッセージ受領を完了する。なお、ポーリングの間は他のコマンド処理を実行
できるため、CPU OH に含めない。
(2)SM 方式
[2] = 0 + ( 1 + 3 ) ×
[2] = 1 + ( 3 + 1 ) ×
+
（3-2a）
（3-2b）
DS 方式と同様だが SM ライトの前に排他ロック処理が必要である。同処理により他系にも
OH が発生する。
40
第３章
(3)RM 方式
[3] = ( 1 + 3 ) ×
[3] =
+
（3-3a）
+( 3 + 1 )×
（3-3b）
自系では WM にメッセージ格納後 NW 転送を起動するため NW ドライバ処理が必要である。
他系も NW でメッセージ受領のため同様の処理が必要である。
(4)FS 方式
[4] = ( 1 + 1 ) ×
[4] =
+
×2
（3-4a）
×2+( 1 + 1 )×
（3-4b）
自系では共有メモリコントローラ(SMC)への NW データ転送と他系への通知処理のため NW
ドライバ処理が必要である。他系では自系からの通知処理と SMC からの NW データ転送の
ため NW ドライバ処理が必要である。なお NW 転送のバッファは LM に設置されている。
(5)RS 方式
[5] = ( 1 + 1 ) ×
[5] =
+
（3-5b）
+( 1 + 1 )×
（3-5a）
メッセージを自系 LM の WM に置く以外は RM 方式と同様である。
(6)CC 方式
[6] = ( 1 + 4 ) ×
（3-6a）
[6] = 0
（3-6b）
自系 CPU が自系 LM からメッセージをリードし、他系 LM に直接ライトする。他系 CPU は動
作不要である。
(b)メッセージ伝送時間の評価計算式
次にメッセージ伝送時間の計算式を示す。本計算式は CPU の所要時間だけでなくハ
ードウェアやネットワークによるメッセージ伝送時間や、他系 CPU によるメッセージ受領確認の
ためのポーリングによるディレイなど、メッセージ伝送に要する全所要時間を示すものである。
(1)DS 方式
[1] = ( 1 + 3 + 3 + 1 ) ×
+
+
（3-7）
他系がメッセージ受領を認識するためのポーリング処理時間 Tp を要する。
41
第３章
(2)SM 方式
[2] =
+( 1 + 3 + 3 + 1 )×
+
+
（3-8）
DS 方式の処理に加え、共有メモリにデータをライトするために排他ロック確保処置時間 tl を
要する。
(3)RM 方式
[3] = ( 1 + 3 + 3 + 1 ) ×
+
+
+
×
+
+
（3-9）
両系での LM と WM からのリード/ライト時間に加え、両系でのメッセージ送受信処理の NW
ドライバ処理時間と NW ボード処理時間と NW 上のデータ転送時間を要する[TAN10]
[OKA01]。
(4)FS 方式
[4] = ( 1 + 1 + 1 + 1 ) ×
+
+
+
+
+
×4
+
+
+
+
+
×2
×2
（3-10）
RM 方式の処理に加え自系/共有メモリ/他系間のメッセージ送受信、ならびに、SM にデ
ータ転送完了を他系に通知する通知処理、および、他系から SM へ転送を指示するための
通知処理の２回の通知処理のためのメッセージ伝送時間を要する。そこで、式（3-10）の第
３項でこれらを足しこんでいる。これら通知処理のためのメッセージ長はイーサネットにおける
最小長の１フレーム（６４バイト）で十分なので[OKA01]、１フレームの伝送時間 64/x が加算
されている。
(5)RS 方式
[5] = ( 1 + 1 + 1 + 1 ) ×
+
+
+
×
+
+
（3-11）
RM 方式との相違はメッセージ専用のバッファを設けず、それを主記憶上に設けたことである。
計算式の差はそれだけである。
42
第３章
(6)CC 方式
[6] = ( 1 + 4 ) ×
+
（3-12）
自系 LM・他系 LM アクセスのための実データ転送時間に加え、メッセージ受領を認識する
ためのポーリング処理時間 Tp を要する。
3.4.4
評価結果
以上述べた実測データならびに評価計算式によって、各方式の(a)CPU OH と(b)メッセ
ージ伝送時間を定量評価する。
(a)CPU OH
(i)ストレージ専用接続路型メッセージ伝送方式
ストレージ専用接続型方式の CPU オーバヘッド評価結果を図３．１２に示す。同図にお
いて、縦軸は、(1)DS 自系の 512Byte 時の CPU オーバヘッドを１とした際の、各方式の CPU
オーバヘッドの相対値を示す。横軸は転送長を示す。
CPU OH [Storage Dedicated]
100
(1)DS自系
(1)DS他系
Relative CPU OH
10
(2)SM自系
1
(2)SM他系
0.1
(6)CC自系
(6)CC他系
0.01
1
10
100
1,000
[Bytes]
図３.１２ ストレージ専用接続型方式の CPU オーバヘッド評価結果
43
第３章
(1)DS 方式：
自系 CPU OH がメッセージ長によらず安定している。しかし小サイズメッセージにおける
CPU OH は CC 方式に比べ１ケタ悪い。またメッセージ長が大きくなると他系へのインパクト
が大きい。
(2)SM 方式：
自系、他系ともにメッセージ長 64B 以下で CPU OH は安定であり対称性に優れる。しかし
CPU OH は CC 方式に比べ悪い。デュアルコントローラ型ストレージには適さない方式であ
るが、コントローラ枚数を拡張可能な長所があるため、大規模ストレージに適した方式である。
(6)CC 方式：
全メッセージ長で自系 CPU OH は他方式より優位である。また他系 CPU OH はゼロであり
他系へのインパクトがない点も長所である。
(ii)汎用 NW 型メッセージ伝送方式
汎用ネットワーク接続型方式の評価結果を図３．１３に示す。比較のため CC 方式も併せ
て掲載する。全体的に汎用 NW 型方式は CC 方式に比較し CPU OH が大きい結果である。
CPU OH [General NW]
100
(3)RM自系
(3)RM他系
Relative CPU OH
10
(4)FS自系
(4)FS他系
1
(5)RS自系
(5)RS他系
0.1
(6)CC自系
(6)CC他系
0.01
1
10
100
1,000 [Bytes]
図３.１３ 汎用ＮＷ接続型方式の CPU オーバヘッド評価結果
44
第３章
(3)RM 方式：
自系 CPU OH は安定した特性であるが、他系インパクトが全メッセージ長において大きい。
(4)FS 方式：
自系、他系ともにメッセージ長によらず CPU OH は安定であり対称性に優れる。
(5)RS 方式：
自系／他系ともに安定した CPU OH 特性である。CC 方式に比べ OH が大きいが、100 バイ
ト以内で自系・他系とも比較的優れた特性を示す。本章の主眼である限界性能を追求する
高性能なデュアルコントローラ型ストレージには適さないが、専用の WM や特殊なハードが
不要なため、コストを重視し高度の限界性能を必要としない用途に活用性があると考えられ
る。
(iii)CPU OH 比較（64 バイト転送時）
全方式における 64B メッセージ転送時の CPU OH 評価結果を図３．１４に示す。64B で
評価するのは、メッセージ内容として、SCSI プロトコル[SEA10]で受信したホストコマンドとその
制御情報の転送を想定したとき、通常 64B あれば送信可能であるためである。
CPU OH (64B)
4
Relative CPU OH
3
2
1
0
自系 他系 自系 他系 自系 他系 自系
(1)DS
(2)SM
(3)RM
他系 自系
(4)FS
他系 自系 他系
(5)RS
図３.１４ 64B メッセージ転送時の CPU オーバヘッド評価結果
45
(6)CC
第３章
CC 方式では CPU OH が他方式に比べ 1/5～1/10 と他の方式に比べ優位であることを
見出した。他系へのインパクトがない点も優位点である。
(b)メッセージ伝送時間
(i)メッセージ伝送時間比較
メッセージ伝送時間の評価結果を図３．１５に示す。縦軸は、(1)DS 自系の 512Byte 時の
メッセージ伝送時間を１とした際の、各方式のメッセージ伝送時間の相対値を示す。横軸は転
送長を示す。メッセージ長が 100Byte 以下であれば、他方式に比べ CC 方式は伝送時間を
低減できることを見出した。
Message Transfer Time
Relative Message Transfer Time
100
(1)DS
(2)SM
10
(5)RS
(3)RM
(4)FS
1
(6)CC
0.1
1
10
100
図３.１５ メッセージ伝送時間評価結果
46
1,000 [Bytes]
第３章
(ｉｉ)メッセージ伝送時間比較（64 バイト転送時）
全方式における 64B メッセージ転送時のメッセージ伝送時間の評価結果を図３．１６に示
す。64B で比較する理由は CPU OH の評価と同様である。
従来方式からのメッセージ時間の低減率（Reduction Rate）を式（3-13）により求める。結
果は後述する表３．７にまとめる。
メッセージ時間の低減率＝1 − [6]/ [ｉ]
（3-13）
但し、i=1～5
同表の通り、CC 方式のメッセージ伝送時間は従来方式の 61%～89%減となり、従来技術
に比べ大幅に低減できることを確認した。
Message Transfer Time (64B)
Relative Message Transfer Time
4
3
2
1
0
(1)DS
(2)SM
(3)RM
(4)FS
(5)RS
図３.１６ 64B メッセージ転送時のメッセージ伝送時間評価結果
47
(6)CC
第３章
3.4.5
評価まとめ
上記の評価結果を表３．７にまとめる。
(1)DS method
(2)SM method
(3)RM method
(4)FS method
(5)RS method
(6)CC method
表３.７ メッセージ伝送方式の評価結果（６４B 転送時）
(i)CPU OH [us]
(ii)Message Transfer Time [us]
Eva
Self
Other
Eva
Transfer Time Reduction Rate
10.1
20.8
44.6
65%
△
△
16.2
24.4
50.8
69%
×
×
11.1
31.8
67.5
77%
×
×
20.1
33.1
148.8
89%
×
×
11.1
11.2
39.9
61%
△
△
2.0
0.0
15.5
○
○
本章の対象とするデュアルコントローラ型ストレージシステム向けのコントローラ間メッセ
ージ伝送技術に関し、(i)CPU OH、(ii)メッセージ伝送時間の２つの観点から評価した結果、提
案する CC 方式が両評価指標において良好な性能を示すことを明らかにした。
3.5 考察
3.5.1
性能対称性の考察
本章で目標とするストレートアクセスとクロスアクセス間の性能対称性の実現について考
察する。ここで、ストレージシステムで最も一般的に用いられているデータ冗長化の方式には
パリティ方式(RAID5)とミラー方式(RAID1)がある。これら両者の構成について、Read/Write そ
れぞれに関し前述の試作機において測定したストレートアクセスとクロスアクセスの CPU OH と
ストレートに比べたクロスの CPU OH 増加率を表３．８にまとめる。
表３.８ ストレートアクセスとクロスアクセスの CPU オーバヘッド
CPU OH [us]
Straight
Cross
%
MSG
MSG%
Read (RAID5/1)
26.3
38.3
146%
2
108%
Write (RAID5)
138.3
150.3
109%
2
101%
Write (RAID1)
61.8
73.8
119%
2
103%
同表で、RAID5 においては、ストレートアクセス時の 4KB Read/Write の CPU OH は
26.3us および 138.3us であった。クロスアクセス時の CPU OH は、コマンドを受信したコントロ
ーラによる LU 判定に 10us、Command Cast によるメッセージ伝送に 2us の CPU OH 増加が
48
第３章
発生し、Read/Write 各々38.3us、150.3us であった。クロスアクセスのストレートアクセスに比べ
た CPU OH 増加率は各々46%、9%であった。また、メッセージ伝送自体の CPU OH = 2us のス
トレートアクセス時の CPU OH に対する増加率は各々8%、1%であった。
RAID1 においては、4KB Read に関しては RAID5 と同一である。ストレートアクセス時の
4KB Write の CPU OH は 61.8us、クロスアクセス時の CPU OH は、RAID5 と同様に CPU OH
増加が発生し、73.8us であった。クロスアクセスのストレートアクセスに比べた CPU OH 増加率
は 19%であった。また、メッセージ伝送自体の CPU OH = 2us の、ストレートアクセス時の CPU
OH に対する増加率は 3%であった。
以上の通り、メッセージ伝送自体の CPU OH 増加率は 10%以下に抑えられ問題とならな
いことが確認できたものの、クロスアクセスのストレートアクセスに比べた CPU OH 増加率は
RAID5/1 の Read 時と RAID1 の Write 時に 10%を上回った。これは無視できない値であり別
途評価が必要である。
そこで、このクロスアクセスの CPU OH 増加の影響について考察する。考察に際しては、
コントローラが HDD の最大スループット性能を引き出して制御可能な HDD 台数である最大
制御可能 HDD 数=N を指標に用いスループット性能を評価することにする。一般に、対象と
するストレージシステムの搭載ディスク台数は 500 台程度が上限であり、この半数にあたる 250
台を同時に制御可能であれば実用上十分なスループット性能と言える。そこでストレート、クロ
スそれぞれにおいて、システム当たりの最大制御可能 HDD 数=2N が 250 台以上であることを
性能対称性の評価項目として設定する。
評価に用いた HDD の仕様と RAID5 4D+1P 構成および RAID1 1D+1D 構成における
HDD 性能実測結果に基づく HDD 1 台当たりの性能試算値を表３．９に示す。
I/F
Type
SAS
I/F
Speed
4Gbps
表３.９ HDD 性能仕様 （RAID5/1 構成時）
Rotation
RAID5
RAID1 Responce
Capacity Read*1
*2
Speed
Write
Write*3
Time*4
15Krpm
146GB 200IOPS 50IOPS 100IOPS
5ms
*1: RAID5 もしくは RAID1 構成で HDD 全記憶領域を 4KB ランダムリードした
際の HDD１台当たりの性能試算値（HDD 性能実測結果に基づく）
*2: RAID5 4D+1P 構成で HDD 全記憶領域を 4KB ランダムライトした際の HDD
１台当たりの性能試算値（同上）
*3: RAID1 1D+1D 構成で HDD 全記憶領域を 4KB ランダムライトした際の HDD
１台当たりの性能試算値（同上）
*4: 4KB Read 時のレスポンス時間
49
第３章
ここで、最大制御可能 HDD 数= N は、表３．８のストレート、クロス各々における
Read/Write それぞれの CPU OH の逆数をとることでコントローラ 1 台の原理的な最大 IOPS
を求め、その数値を表３．９の HDD 1 台当たりの性能値で割り算することで算出する。CPU
OH を CPUOH、HDD1 台当たりの性能値を HDDIOPS と表記し、数式で表すと式（3-14）の通
りとなる。
=
（3-14）
式（3-14）によって表３．８、表３．９のデータを用いて求めた RAID5、RAID1 各々に関す
るコントローラ当たりの最大制御可能 HDD 数= N と、システム当たり（デュアルコントローラ構
成）の最大制御可能 HDD 数=2N を表３．１０に示す。
表３.１０ ストレート／クロスアクセスの性能対称性の評価
N (HDDs /CTL)
2N (HDDs /SYS)
Straight Cross
Straight
Cross
Read (RAID5/1)
190
130
380
260
Write (RAID5)
140
130
280
260
Write (RAID1)
160
140
320
280
表３．１０によると、システム当たりの最大制御可能 HDD 数は、RAID5 および RAID1 のリ
ード時には、ストレートが 380 台、クロスが 260 台である。また、RAID5 のライト時には、ストレ
ートが 280 台、クロスが 260 台、RAID1 のライト時には、ストレートが 320 台、クロスが 280 台で
ある。以上の通り、リード時、ライト時ともに、ストレート、クロスに関わらずシステム当たりの最大
制御可能 HDD 数=2N は 250 台以上であることを確認した。このことから HDD が 250 台まで
はストレートアクセス性能とクロスアクセスのスループット性能は同等であると言える。なお、この
結果は第２章における評価と同一の結果となった。以上より、スループット性能に関しては、ス
トレートアクセスとクロスアクセスが混在する LU 共有時においても、目標とする実用上十分に
均質な性能対称性を実現できることを確認した。
また、レスポンス性能に関しては、ホスト計算機のアプリケーションプログラムから最も厳し
く高いレスポンス性能が求められるのは Read アクセスである。これはストレージからデータ読
み出し完了するまでアプリケーションプログラムの処理が待たされてしまうためである。表３．
50
第３章
９の通り、HDD のリード時のレスポンス時間が約 5 ms であることから、表３．７に示したメッセ
ージ伝送時間 15.5us によるレスポンス時間の増加による影響は無視できると判断する。
3.5.2
SSD 適用性に関する考察
SSD(Solid State Drive)はフラッシュメモリデバイスを活用したストレージデバイスで、近年
ディスクアレイ型ストレージシステムにも一般適用が進みつつある。SSD は HDD に比較し高速
な IO 性能を有することが特徴である。一例として HGST 社 Ultrastar SSD800M/1000M の性
能仕様を表３．１１に示す[HGS13] 。
表３.１１ SSD 性能仕様（一例）
Maker I/F Type I/F Speed Command OH Capacity
Read*1
HGST
SAS 6 / 12 Gbps
45us
800GB
150kIOPS
Write*1
67kIOPS
Responce
100us
*1: Randam Access, 4KB, aligned, Queue Depth=32
同表によると、IO スループット性能は HDD の約 1000 倍であり、レスポンス性能は約
1/50 と高速なデバイスであることがわかる。表３．８によるとクロスアクセスのストレートアクセス
に対する CPU OH 増加分は Read/Write ともに 12us であり、SSD のレスポンス時間 100us の
約 10%を占め、レスポンス性能の観点からは無視できないインパクトを持つことが分かる。この
ような高速デバイスを扱うにあたり、まず、IO スループット性能の向上に関しては、CPU のコア
数増加により今後一層の改善を見込む。次に、レスポンス性能の向上に関しては、2.4 節で論
じた通り、今後の課題である。手段の一つとしては Host I/F Controller へのコマンド解析機能
の搭載による非オーナコントローラの CPU 非介在でのコマンドキャストの実現が挙げられる。
以上より、当面は、クロスアクセス時の CPU OH 時間の削減は困難につき、システム全体
観点から IO スループットとレスポンス性能の最適化を図ることが重要である。そのためには、
LU オーナ権をコントローラ間で適切に移行することで、性能効率の高いストレートアクセスの
比率を高めつつ、必要に応じてクロスアクセスの良好な性能特性も活用して、コントローラ間の
負荷を均衡させることにより、システム全体の最適化を図る自動チューニング技術の確立が重
要である。この自動チューニング技術の実現については、第４章にて論述する。
51
第３章
3.5.3
メッセージ伝送技術の形態別まとめ
以上より、提案する CC 方式がデュアルコントローラストレージのクロスアクセスを高速化
するための有効なメッセージ伝送技術であることを立証した。メッセージ伝送技術の形態別の
まとめ結果を表３．１２に示す。
表３.１２ メッセージ伝送技術の形態別まとめ
(a)Interface
Storage Dedicated
General Network
(b)Memory Type
Work Memory
(1)DS method
(3) RM method
Shared Memory
(2)SM method
(4) FS method
Local Memory
(0)CC method
(5) RS method
52
第３章
3.6 結言
本章では、デュアルコントローラ型ストレージシステムのクロスアクセスを高速化する高速メッ
セージ伝送技術の確立を目的とし、以下の知見を得た。
(1) メッセージ伝送技術に関して、(a)伝送手段（ストレージ専用接続路、汎用ネットワーク）と、
(b)メモリ形態（ワークメモリ、共有メモリ、主記憶メモリ）の組み合わせを検討した結果、従
来は存在しなかった、ストレージ専用接続路×主記憶メモリの組み合わせによって新し
いメッセージ伝送技術が構築可能になることを推測した。
(2) この推測に基づき、ストレージ専用接続路×主記憶メモリの組合せにより、コントローラ間
でコマンドを高速に移送する技術としてコマンドキャスティング方式（CC 方式）を提案し
た。他系のメモリ空間を自系メモリ空間にアドレス変換してマッピングすることで直接メモリ
アクセスを可能とするハードウェア回路と、他系メモリ空間上にコマンドを格納するための
コマンドキャストキューと呼ぶソフトウェア機構により実現する方式とした。
(3) メッセージ伝送技術に関して、従来技術と提案技術に関する評価モデルを確立し、メッ
セージ伝送に要する CPU オーバヘッドとメッセージ伝送時間を定量評価した。
(4) 提案技術により、CPU オーバヘッドが従来技術比 1/5～1/10 となる 2.0us に、メッセ
ージ伝送時間が従来技術比 61%～89%となる 15.5us にそれぞれ低減できることを確認し
た。
(5) RAID5、RAID1 のいずれの構成においても、ストレートアクセスとクロスアクセスの両者間
で実用上均質な性能対称性を実現できる見通しを得た。
(6) 今後の課題として、クロスアクセス時のメッセージ伝送オーバヘッドがシステム性能に影
響を及ぼす恐れのある、SSD 等の高速デバイスを搭載した環境への対応力の強化が挙
げられる。対応策の一つとして、システム構成やアクセス特性の動的な変動に追随して
LU オーナ権を適切に移行することによって、コントローラ間の性能バランスを自動で調
整する技術を確立し、運用性の高いデュアルコントローラ型ストレージシステムを実現す
ることが挙げられる。この技術の実現については第４章で論述する。
53
第４章
第４章
自動負荷均衡技術による高運用化
4.1 緒言
本論文の対象とするデュアルコントローラストレージシステムは、搭載する HDD 容量の増
加や接続できるサーバ台数の増加により大規模なシステムが構築できるようになった。反面、
クラウドコンピューティングに代表される仮想化技術の進展により、ストレージシステムに接続さ
れるサーバの構成は動的に変更され、システム構成変更に伴う人手による性能チューニング
は難易度が高く、多大な労力を要することから、システム運用性の向上が大きな課題になって
いた。
そこで、第２章、第３章では、システム運用性を向上するため、実用上十分な HDD 台数
に お い て 、 オ ー ナ 権 の 有 無 に 依 存 せ ず 実 用 上 均 質 な 性 能 対 称 性 を 実 現 す る SemiSymmetric Active-Active（sSAA） デュアルコントローラ方式を提唱し、その実現技術と性能評
価結果について論述してきた。
一方、クラウドコンピューティング型アプリケーションの台頭により、アプリケーションを使用
するユーザが飛躍的に増加することにより、負荷が急拡大するとともに、時間に伴いダイナミッ
クに変動するようになった。また、HDD に比較し高速な IO 性能を有する SSD(Solid State
Drive)のシステム適用も進み、コントローラ間に大きな負荷偏りも発生するようになった。その結
果、sSAA 型デュアルコントローラストレージシステム（以下、sSAA ストレージと略記する）が許
容する性能対称な LU アクセス可能範囲を超え、コントローラ間の性能偏りが顕在化することも
起きてきた。そこで、負荷偏りに追随してコントローラ間の性能バランスを自動で調整する技術
の実現が望まれた。
従来、複数のノード間で負荷均衡を図る技術としては、クラスタサーバ間の負荷均衡方式
[CAO00][RAY12][EMC11][QIN03][XUZ02][BOH02]、分散する複数のストレージノード間の
負荷均衡方式[KOB08][KUN08][WAT02]、クラウド環境におけるマルチディメンジョン負荷分
散方式[RAZ08][SIN08]、負荷パターン発見による先行予測型負荷均衡制御[GMA05] などが
提案されてきた。
しかしながら、従来の負荷均衡技術は各ノード間の処理が均質であるか、全く異なるノ
ードをシステムに追加設置することを前提としているため、本研究が対象とするｓSAA ストレ
55
第４章
ージのような、LU オーナ権の有無に起因し処理負荷特性が不均質になるストレージシステム
では十分な負荷均衡が実現できないという課題があった。
本章では、不均質な処理負荷特性を考慮した sSAA ストレージ向けコントローラ間負荷均
衡方式の提案を行う。４．２節では従来技術の課題を明らかにし、その課題を解決する負荷均
衡方式を提案する。４．３節では開発した性能シミュレータの機能として sSAA 方式の実現、負
荷均衡方式の搭載、負荷発行 IO ジェネレータの搭載が必要であることを示す。４．４節では
性能シミュレータを用いた提案方式の効果の検証結果を述べる。４．５節では本章の結論をま
とめる。
4.2 CPU 負荷均衡方式の提案
4.2.1
従来の負荷均衡技術
複数ノードで構成されたクラスタ型ストレージシステムの負荷均衡方式に関し、従来技術
として[KUN08] が提唱されている。(a) 負荷の計測、(b) Imbalance 検出、(c) 構成変更プランの
作成と評価、(d)構成変更の実行、の 4 部位で構成される負荷均衡フレームワークを備える。こ
の負荷均衡フレームワークでは、各ノードは均質であることが前提とされている。(c) 構成変更
プランの作成と評価において、均衡の対象負荷としては各ノードが処理する単位時間当たりの
IO 数である IOPS (Input/Output Per Second)を採用し、この IOPS 負荷をノード間で均衡化す
る。本章においてはこの従来方式を IOPS 均衡方式と称する(IOPS Load Balancing Method、
以下 ILB と略記する）。同従来技術は負荷不均衡量（Imbalance Factor）と構成変更コスト
（Reconfiguration Cost）を同時に最小化する構成変更パターンを、既知の発見的最適化アル
ゴリズムを適用して求めることが特徴である。
4.2.2
処理負荷特性が不均質になる場合の課題
本研究で提案する sSAA ストレージは、コントローラの LU オーナ権の有無により、第２章、
第３章で述べた、ストレートアクセス、クロスアクセスといった異なるアクセスモードでコマンド処
理を行う（以下、単にストレート、クロスと略記）。ストレート時には、コマンドを受信した自系コン
トローラが全コマンド実行処理を行うが、クロス時には、(a)自系コントローラが、コマンド受信お
よび委託処理（処理時間 T_rcv） (b)他系コントローラが委託されたコマンドの実行処理（処理
時間 T_op）を分担して行う。すなわち、クロス時には両コントローラによって処理が行われ、ま
た(a) T_rcv が増加するため全体の処理負荷も大きくなる。このようにストレートとクロスで処理
56
第４章
内容が異なるので、結果的に両コントローラの処理負荷特性は不均質になる。しかしながら、
従来技術は、全ノードの処理負荷特性が均質であることを前提としているため、このようなコン
トローラ間の不均質な処理負荷特性の下では、負荷均衡が十分図れないという課題がある。
さらに、本章の対象とする RAID5 を採用するストレージシステムにおいては、信頼性確保
のために Write 時に Parity と呼ぶ冗長データを生成・保存する必要があるため、Read 処理に
比べて Write 処理の処理負荷は大きい。しかしながら、従来技術は、処理負荷の大きさでは
なく、ノード間のコマンド処理数(IOPS)に注目して、その差を最小化するように均衡化するため、
sSAA 型デュアルコントローラストレージシステムのように、コマンド間の不均質な処理負荷特
性の下では、負荷均衡が十分図れないという課題がある。
4.2.3
CPU 負荷均衡方式の提案
(1)目標
本章の目標は、ストレージコントローラ間の処理負荷均衡化により自動性能最適化を実
現し、それを活用することで人手による性能チューニングを排除し、システム運用性を向上す
ることである。そこで、上記課題で言及した以下２点の不均質な負荷処理特性を考慮した負荷
均衡方式の実現を目標とする。
1) コマンドのアクセスモード（ストレート/クロス）の差異に起因するコントローラ間の不均質
な処理負荷特性
2) Read と Write のコマンド処理の差異に起因するコマンド間の不均質な処理負荷特性
(2)CPU 負荷均衡方式の提案
上記２点の不均質な処理負荷特性を考慮したコントローラ間負荷均衡方式として、CPU
負荷均衡方式（CPU Load Balancing Method、以下 CLB と略記する）を提案する。提案の基
礎をなす基本概念を説明する。
コマンドのアクセスモードやコマンド処理の差異があったとしても、各 CPU コアで処理す
るコマンド毎の処理時間を観測できれば、それらの大小により処理負荷の不均質性を考慮で
きる。CPU コア毎に単位時間あたりの全コマンド処理時間を積算し、単位時間で割ったものが
CPU 負荷率であることに注目すると、CPU 負荷率を観測することによって、不均質な処理負
荷特性を織り込んだ CPU コア間の負荷均衡状態を評価できる。すなわち、本章の目標とする
負荷均衡の実現に際し、負荷均衡の評価基準として、従来の単位時間当たりの IO 数（IOPS）
57
第４章
に代えて、CPU 負荷率（単位時間当たりの CPU 処理時間の和）を採用すれば、コントローラ
間やコマンド間に生じる不均質な負荷特性を考慮した負荷均衡を達成することができる。CPU
コア間で両者の CPU 負荷率に大きな偏りが検出されたら、CPU 負荷率の大きな CPU コアか
ら小さな CPU コアへ、負荷対象である LU のオーナ権を移行することで、当該 LU に関する
負荷を移動し、負荷均衡を図る。以上が提案する CPU 負荷均衡方式の基本概念である。
また、均衡化のために適切な移行 LU を選択するため、LU 毎に所要した CPU 負荷率を
算出し、これを用いて均衡性を評価する。上述の通り、自動性能最適化の実現、すなわち平
均レスポンス時間とシステムスループットを向上させることが目標になる。ここで、式(4-1)に示
す待ち行列理論 M/M/1 の公式[KLE79]を参考にすると、CPU 負荷率 L が一定値を超えると
平均 CPU レスポンス時間 T は急激に悪化することがわかる。よって、T を低減するには CPU
負荷率 L を一定値以下に下げることが重要になる。また、平均レスポンス時間 T が下がれば
システムスループットも向上する。
= 1+
（4-１）
但し、Ts ：平均 CPU サービス時間、L：CPU 負荷率
以上をまとめると、提案する CPU 負荷均衡方式（CLB）は、CPU 負荷率を評価基準とし
て、コントローラの CPU コア間で LU オーナ権を移行することにより CPU 負荷率の均衡化を
図り、これにより性能向上を実現する方式である。
(3)CPU 負荷均衡方式の制御手順
上記(2)の基本概念に従い、提案方式の制御手順を説明する。ここで、負荷均衡制御に
おける、1)制御対象、2)負荷対象、3)評価基準を次の通り定義する。
1)制御対象：Control Unit(CU) = {コントローラ, CPU コア}
2)負荷対象：Load Component(LC) = LU
3)評価基準：Evaluation Criterion(EC) = CPU 負荷率
提案方式の手順は、図４．１に示す以下 3 つの手順から構成され、これらの手順を定期
的に繰り返す。
58
第４章
(a) Observe Load
Imbalanced
and
Detect Imbalance
(b) Establish
Migration
Plan
(c) Execute
Migration
Balanced
図４.１ 提案方式の手順
(a) 負荷計測および性能不均衡の検出
定期モニタ周期（例：5 秒）の時刻 毎に制御対象 CU は評価負荷（CPU 負荷率）
を計
測し、短期の負荷変動の影響を排除するため式(4-2)により 時間の平均 CPU 負荷率
を計算する。この値により CU 間の性能不均衡の有無を検査する。
=
∑
（4-２）
性能不均衡を検出する判定アルゴリズムについて説明する。式(4-3)(4-4)を同時に満たす
とき移行元 CU（Origin CU：CU_O と略記）と移行先 CU（Destination CU：CU_D と略記）の間
で不均衡が発生していると判断し(b)移行計画の立案に移る。
≥
但し、
、
and
>
≤
（4-3）
（4-4）
は CU 間の性能不均衡を判定する CPU 負荷率判定閾値である。
(b) 移行計画の立案
アルゴリズム１に LC 移行の最適パターンを検索するアルゴリズムを示す。高負荷な CU_O
から低負荷な CU_D へ LC(LU)のオーナ権を移行することにより両者の CPU 負荷を均衡さ
せられる LC を探索する。アルゴリズムの実行結果として，o と d に CU_O と CU_D が示され
る。また同アルゴリズム 8 行目で検出された移行対象 LC が示される。ここでχ はある LC を
CU_O から CU_D に移行した際の CU_O の予想 CPU 負荷、χ は CU_D の予想 CPU 負荷
である。各々の算定式は次の式(5)(6)の通りである。
χ =
χ =
但し,
−
+
（4-5）
（4-6）
=
∑
59
−
/∆
（4-7）
第４章
ここで、
は時刻 における負荷対象 LC 毎の評価負荷（CPU 負荷率）であり、式(4-7)
により LC の制御に要する 時間の平均 CPU 負荷率
判定時間
+コマンド実行時間
で平均化したコマンド実行時間
を計算する。なお、
={コマンド
}/∆とも定義できる（∆は単位時間）。式(4-7)により n 時間
に要する CPU 負荷率、すなわち LU オーナ権移行で移動
できる CPU 負荷率を計算している。コマンド判定時間
に要する CPU 負荷率(
/∆)を減
じているのは LU オーナ権を移行してもコマンド判定処理は移行元 CU に残るためである。こ
うして式(4-7)によりクロスの影響を反映している。
Algorithm 1: load balancing by LC migration
1: let O be the Origin CU, let D be the destination CU
2: initialize O = {all CU}
3: for O ≠ 0 do
4:
initialize D={all CU}
5:
o ← CUmax (the CU with maximum load)
6:
for D ≠ 0 do
7:
d ← CUmin (the CU with minimum load in D)
8:
if found LC to balance and
after migrating
LC from CUmax to CUmin then
9:
goto end_of_algorithm:;
10:
remove d from D;
11: end for
12: remove o from O;
13: end for
14: end_of_algorithm:
(c) LU 移行の実行
(b)で決定した LC に関し CU_O から CU_D へ LU オーナ権切り替え処理を実行し、負荷
均衡処理が終了する。
4.3 性能シミュレータの開発
4.3.1
性能シミュレータ LB-Sim の開発
4.2 節で述べた通り、コントローラ間の処理負荷特性の不均質性や、コマンド間の処理負
荷特性の不均質性を考慮して、解析的に負荷均衡方式の性能評価を行うことは困難であった。
また、長期の工数を要する実機設計・開発に先立ち、各種アルゴリズムの得失判定や詳細性
能評価を行うことが必要であった。そこで、負荷均衡方式を評価することに主眼を置いたイベ
60
第４章
ントドリブン型待ち行列性能シミュレータ LB-Sim を開発することにした。以下、本シミュレータ
の構成・特徴を述べる。
(1) LB-Sim の構成
開発した LB-Sim の構成を図４．２に示す。同図において Cxxx はコントローラ内部の各
種制御 Component を表す。Component は一定の処理時間を伴うサービス施設と Queue を備
える。Request Packet は Component の Queue に入力され順番待ちの後に処理され、矢印で
示すフローに沿って次の Component に進む。これを各処理毎に定義した動作に沿って待ち
時間と処理時間をシミュレートすることで性能計測を行う仕組みである。
IO Definition
Exponential Distribution,
Command Trace,
SPC-1
P
(x)End
(ix)Cmd Cmp
(i)Cmd Gen
CCmndGenerator
CCmdResponder
(iii)Cross Access
(vii)Host Xfer Start
(ii)Cmd
Receive
(vi)LU Read End
(iv)LU Access
Child
Parent P
Dispatcher
CRAIDLUStart
CHDD
(viii)Host Xfer End
P
Parent
CRAIDLUEnd
CCreateParity
CHDD
(v)HDDs Access
図４.２ 性能シミュレータ LB-Sim の構成
61
Dispatcher
LUReadEnd
P Child
CRAID LU Mnager
CController(CPU0)
CHostDataTransfer
P
CmdReceive
...
CmdCmp
HostXferStart
...
CmdReceive
P
P
CController(CPU1)
第４章
(2)LB-Sim の特徴
1)sSAA 方式の実現
sSAA 方式の特徴である、(a)LU オーナ権、(b)ストレート／クロスアクセスモード、(c)LU 移行、
の各機能を実現した。またコマンド種毎の処理負荷の違いを表現するため、 (d)RAID 制御
機能（RAID5 制御、R/W コマンド動作、ライトアフタ、ライト纏め書き）も実現した。
2)各種負荷均衡方式の搭載
本提案方式 CLB と従来方式 ILB を搭載した。また性能影響のある CPU 負荷率判定閾値
等のパラメータの特性を評価可能とした。
3) 多種負荷発行 IO ジェネレータの搭載
サーバから発行される様々な IO パターンの影響を評価できるように各種の IO 負荷入力を
発行する IO ジェネレータを搭載した。具体的には、(a)指数分布を用いた基本 IO 負荷ジェ
ネレータ、(b)実環境で測定したトレースデータを入力できる実 IO 負荷ジェネレータ、(c)業界
標準ベンチマークテスト SPC-1[SPC15][GIL05]に準拠した SPC-1 負荷ジェネレータ、を搭
載した。ここで，SPC-1 負荷ジェネレータは，３つの ASU (Application Storage Unit)に対して，
ASU1 に４ストリーム，ASU2 に３ストリーム，ASU3 に１ストリームの合計８ストリームの負荷を発
行する。ここで，ASU とは，各 SPC-1 負荷ジェネレータがアクセス対象とする LU の集合体で
ある。SPC-1 の仕様に基づき，50IOPS 程度の業務負荷 BSU (Business Scale Unit）を複数
発行することで全体の負荷を調整する。また、想定するクラウドコンピューティング環境で、仮
想サーバ VM がマイグレーションして VM とコントローラの接続関係が時間的に変化する状
況を再現するため、模擬 VM マイグレーション機能も実現した。
4)HDD シミュレータの統合
開発済の HDD シミュレータ[KAN11] を統合し、コントローラと HDD を含むストレージシステ
ムの全体の総合評価を可能とした。
4.3.2 性能シミュレータ LB-Sim の評価
実機と性能シミュレータ LB-Sim とのストレートアクセス時における(a)4KB Read 100%、及
び、(b)4KB Write 100%の性能比較結果を図４．３に示す。この性能検証に用いた評価環境を
表４．１に示す。図４．３において、横軸には、性能シミュレータ LB-Sim の平均レスポンス時間
62
第４章
が Read では 6.0ms、Write では 1.3ms となる IOPS を 100 としたときの相対 IOPS を示す。ここ
で、同図において、Read よりも Write の平均レスポンス時間が小さい理由は、Read 時にはデ
ータを HDD から読み出す時間を要するのに対し、Write 時にはコントローラがサーバからデ
ータをキャッシュに格納した段階で終了報告を発行する Write After キャッシュ制御を実施し
ているためである。
LB-Sim に統合した HDD シミュレータにおける HDD 当たりの同時コマンド受領数は 1 で
ある。実機システムの HDD における経験的な平均同時コマンド受領数は 4 程度であり、これ
らのコマンドが HDD 内で実行順最適化制御が行われることから、LB-Sim で実機システムと近
似的に等価な HDD 性能を得るため HDD 台数を実機システムの 4 倍に設定した。両環境とも
コントローラの CPU を性能ボトルネックに追い込めるだけの十分な数の HDD を搭載している。
図４．３に示す通り、LB-Sim は(a)Read、(b)Write ともに実機性能をよく模擬していることを確認
した。以上の結果に基づき、以降の負荷均衡方式の評価は、この環境設定の下で LB-Sim を
用いて実施する。
3
Real Machine
Simulator
10
Response Time [ms]
Response Time [ms]
12
8
6
Real Machine
Simulator
2
1
0
4
0
50
100
Relative IOPS
150
0
200
50
100
Relative IOPS
150
（b）4KB Write 100%
（ａ）4KB Read 100%
図４.３ 実機と LB-Sim の性能比較結果
63
200
第４章
表４.１ 性能シミュレータ LB-Sim の性能検証に用いた評価環境
Real Machine
LB-Sim
IO
4KB Random Read
←
CPU
1.6 GHz Single Core
←
Cache
4GB / CTL
←
RAID
RAID5 4D+1P
RAID5 14D+1P
LU
48
64
Numbers
240 HDDs
960 HDDs
Type
SAS 146GB
←
HDD
R.P.M.
15,000
←
4.3.3 評価項目
(1)評価内容
次に示す３種類のシミュレーションによる評価を実施する。
1)評価 1：CLB 基本性能評価
負荷均衡制御の開始条件である LU 移行元/先 CPU の CPU 負荷率判定閾値（
、
）を変化させ CLB の基本性能特性を評価する。
2)評価 2：連続安定負荷における性能評価
コントローラ間負荷偏在、R/W 混在、ストレート/クロス混在のある連続安定負荷を用い、負
荷均衡無し NLB (No Load Balancing) 、および、従来技術 ILB との比較により CLB の性能
を評価する。
3)評価 3: 疑似実働負荷における性能評価
前述の IO 負荷ジェネレータにより長時間変動する「疑似実働負荷」を生成し、評価 2 同様
に負荷均衡無し NLB、および、従来技術 ILB との比較により CLB の性能を評価する。疑似
実働負荷に関しては、後述する。
64
第４章
(2)評価環境
評価 1～3 の評価環境を表４．２に示す。以下各項目を説明する。
#
1
2
3
4
5
6
7
表４.２ 評価環境一覧
Parameters
Evaluation1 Evaluation2
Evaluation3
IO Load
Continuous Stable Load
Simulated Actual Load
(Exponential Distributions)
(SPC-1)
VM
2
2
10 (total 5VMs migrated)
Load Bias
7:3
7:3
6:4
Cross Ratio
a)0%, b)100%
30%
30%
Read Ratio
a)100%, b)0%
70%
40%
Methods
a)NLB, b)CLB
a)NLB, b)ILB, c)CLB
3)ILB
Evaluation Metrics (a)RT: Average Response Time [ms]
(b)TP: System Throughput [IOPS]
(c)CIR: CPU Imbalance Ratio[%]
(d)IIR: IOPS Imbalance Ratio[%]
(e)RC: Reconfiguration Cost
1) IO Load ：
評価 1、2 では LB-Sim が備える基本 IO 負荷ジェネレータが、指数分布に基づく「連続安
定負荷(Continuous Stable Load)」が発行する IO 負荷を用いる。評価 3 では、実 IO 負荷
ジェネレータが発行した実負荷トレース情報に SPC-1 負荷ジェネレータの発行する SPC1 負荷を重畳させた「疑似実働負荷(Simulated Actual Load)」を用いる。ここで疑似実働負
荷について説明する。まず実働するファイルサーバの IO 負荷を 24 時間に渡り計測し、ト
レースデータを取得する。ここで、測定に使用したファイルサーバは、オフィス業務用途を
主たる目的としたものである。夜間から早朝にかけてバックアップや定型処理のためのバッ
チ処理が稼働し、高負荷が発生している。午後になり業務活動が活発化するのに伴い、
負荷が上昇する。取得したそのトレースデータを実 IO 負荷ジェネレータから出力し、その
負荷特性曲線を包絡線として SPC-1 負荷ジェネレータが SPC-1 の IO 負荷を重畳させる。
この方法により、実サーバで観測される大きく時間変動する負荷変化を模擬しつつ、標準
ベンチマークで用いられる典型的な負荷特性を加味することができ、負荷の動的特性（時
間変動）と静的特性（一般性）の両面を考慮した性能評価を実施することができる。
65
第４章
2) VM:
IO 負荷を発行する仮想サーバを模擬する。評価 1,2 では 2 台の VM 各々が CTL0、
CTL1 に対して IO 負荷を発行する。評価 3 では 10 台の VM が CTL0、1 に対し IO 負荷
を発行する。また、24 時間の期間内で計 3 回、のべ 5 台の VM が物理サーバ間をマイグ
レーションする。評価 3 の測定環境の詳細に関しては後述する。
3) Load Bias：
CTL0 と CTL1 が受領する IO 負荷の偏り率の初期値を表す。負荷が偏った状態から負
荷均衡していく能力を観測する。
4) Cross Ratio：
クロスアクセスモードで動作する IO 比率の初期値を示す。ストレート／クロスアクセスの影
響を観測する。
5) Read Ratio：
Read IO 数の総 IO 数に対する比率を示す。Read 率の相違による挙動差を観測する。
6) Methods ：
評価対象とする方式を示す。評価 1 では NLB の評価値を基準に、
と
の組合
せで(a)90%-70% (TH97)、(b)70%-90% (TH79)、(c)70%-40% (TH74)の 3 種類を評価する。
7) Evaluation Metrics :
計 5 種類の評価指標を用いる。(a) Average Response Time (RT)は全 IO の平均レスポン
ス時間、(b) System Throughput (TP)はシステム全体の総スループット、(c) CPU Imbalance
Ratio (CIR)はコントローラ間の CPU 負荷率不均衡率、(d) IOPS Imbalance Ratio (IIR)はコ
ントローラ間の IOPS 不均衡率、(e) Reconfiguration Cost (RC)は負荷均衡時の処理コスト、
をそれぞれ示す。以下、各指標は略号で記す。
4.4 提案方式の評価
4.4.1
評価１：CLB 基本性能評価
(1)測定結果
Cross 率 （0%, 100%）と Read 率 （100%, 0%）の組合せにおけるスループット-レスポンス時
間曲線の測定結果を図４．４に示す。スループット-レスポンス時間カーブとは、スループットの
指標として IOPS を変化させたときの平均レスポンス時間をプロットした曲線で、システムの応
答性能特性を示すものである。なお、(b)TP は、Read が 6.0ms、Write が 1.3ms となる同図の
66
第４章
Read 100%
Straight 100%
Average Response Time [ms]
7.0
NLB
TH97
TH79
TH74
6.5
-50%
Write 100%
0%
50%
CPU0
CPU1
100%
B
6.0
NLB
TH97
TH79
TH74
5.5
A
5.0
70
80
90
100
110
Relative IOPS
-100%
2.0
-27%
-18%
-2%
-25%
Average Response Time [ms]
-100%
1.5
-50%
120
6.5
0%
50%
CPU0
CPU1
A
A
80
100
Relative IOPS
100%
-100%
2.0
1.5
1.3
-50%
CPU0
NLB
TH97
TH79
TH74
80
90
100
110
Relative IOPS
120
120
140
130
50%
100%
B
1.0
NLB
TH97
TH79
TH74
0.5
A
60
(c) Cross100%, Read 100%
0%
CPU1
23%
18%
2%
24%
0.0
70
NLB
TH97
TH79
TH74
(b) Straight 100%, Write 100%
NLB
TH97
TH79
TH74
5.5
5.0
-2%
0.5
60
B
6.0
100%
1.0
130
14%
9%
1%
13%
NLB
TH97
TH79
TH74
-24%
0%
50%
CPU0
CPU1
0.0
Average Response Time [ms]
Cross 100%
Average Response Time [ms]
-100%
-27%
-22%
B
1.3
(a) Straight 100%, Read 100%
7.0
-50%
NLB
TH97
TH79
TH74
80
100
Relative IOPS
120
140
(d) Cross100%, Write 100%
図４.４ 評価１の結果（CPU 負荷率判定閾値の評価）
平均レスポンス時間 B のラインで評価し、このときの NLB の TP を 100 とした相対 IOPS で示
す。また、(a)RT、(c)CIR、(d)IIR は、NLB が平均レスポンス時間 B ラインを横切る相対 IOPS A
点で、各々評価する。また各々のグラフ上部に A 点における各 CPU の CPU 負荷率を棒グラ
フで、その不均衡率 CIR を折れ線グラフで示す。
(2) 考察
本評価では CLB の CPU 負荷率判定閾値 (TH) の設定の相違による性能特性差につい
て論じる。全ての結果の傾向は同一なので、代表例として図４．３(d)に示す Cross100%,
Write100%の結果を表４．３にまとめる。カッコ内の数値は NLB を 100 としたときの相対値を示
す。
67
第４章
表４.３ 評価１の測定結果 (Cross:100%, Write:100%)
No. Method (a) RT [ms] (b) TP (C) CIR [%] Appropriate Usage
1
NLB
1.30 (100)
100
23
2
TH97
1.14 (88)
109
18
Avoid Overload
3
TH79
0.92 (71)
112
2
Auto Balance
4
TH74
1.30 (100)
100
24
Large Imbalance
(a) 平均レスポンス時間 (RT)
全ケースにおいて、TH79 が良好な結果を示した。表４．３のケースでは、NLB に対し RT
が 29%低減した。TH97 は図４．４（ｄ）の通り、高負荷時に負荷均衡の効果が表出することが
特徴的で、A 点では RT は NLB に対しレスポンス時間が約 12%低減した。TH74 は図４．
４（ｄ）によると中負荷時に若干のレスポンス時間低減の効果があるもの高負荷時には NLB と
の有意な差はなかった。
(b) システムスループット (TP)
全ケースにおいて、TH79 が良好な特性を示した。表４．３の通り、NLB に比べ TP が 12%
向上した。他の TH の特徴は(a)と同様である。
(c) CPU 負荷率 不均衡率(CIR)
全ケースにおいて、TH79 では、CIR が 1～2%となり、ほぼ完全な負荷均衡化を実現でき
た。NLB に対する改善度は 13～25 ポイントと大きく改善し、この結果 RT の低減に寄与した。
TH97 では、A 点における NLB に対する改善度は 5～9 ポイントに止まったが、CPU 負荷率
90%を超える高負荷時には TH79 同等の効果を観測した。TH74 はこの条件下では効果が
観測されなかった。
(3) 評価 1 のまとめ
は負荷の大きい方のコントローラにおける負荷均衡起動判定条件となる。４．２節
に記載した式（4-1）とその説明に示した通り、CPU 負荷率が 70%程度まではレスポンス時間へ
の影響は相対的に小さく、
示された。一方、
は 70%程度に設定するのが合理的となり、実験によりそれが
は負荷の小さい方のコントローラにおける負荷均衡抑止判定条件とな
る。よって、大きな値ほど積極的な負荷均衡が実行される。
68
第４章
以上より、TH79 は、積極的に CPU 負荷均衡を図るため全ケースで最も良好な結果を示
した。システムによる自動的な LU 移行を許容できる場合には性能面で最良の選択となる。
TH97 は起動判定条件が最も厳しく高負荷時にならないと機能しない。通常は負荷均衡を作
動させず高負荷時のオーバロード防止のための安全弁として活用するのに適する。TH74 は、
通常は積極的な自動負荷均衡を行わず、人手による管理を重視した設定として適する。両コ
ントローラが大きく負荷バランスを崩したときのみ自動負荷均衡が実行される。以降の評価で
は、TH79 を CLB の代表設定として評価する。
今後の課題としては、様々なユーザ利用環境や、負荷特性の変化に応じた最適な CPU
負荷率判定閾値の自動選択機能の提供や、運用管理者への適切な設定のためのガイダンス
機能の実現が挙げられる。
4.4.2
評価 2：連続安定負荷における性能評価
(1)測定結果
測定結果として、NLB、ILB、CLB (TH79)のスループット-レスポンス曲線と、A 点における
CPU 負荷率および CIR を図４．５に示す。同図の横軸には、NLB による平均レスポンス時間
が 4.5ms となる IOPS を 100 とした相対 IOPS を示す。評価 1 と同様に、相対 IOPS A 点およ
び平均レスポンス時間 B ラインで評価指標(a)(b)(c)を評価する。また、A 点における IOPS と
(d)IOPS 不均衡率 IIR の評価結果を図４．６に示す。さらに、A 点における (e)構成変更コスト
-100%
Average Response Time [ms]
7.0
6.0
-50%
NLB
ILB
CLB
CPU0
0%
-32%
-12%
0%
CPU1
50%
100%
5.0
B
4.0
NLB
ILB
CLB
A
3.0
60
80
100
120
Relative IOPS
140
160
図４.５ 評価 2 の結果（従来技術と提案技術の性能比較）
69
第４章
の評価結果を図４．７に示す。
(2) 考察
本評価では CLB(TH79)と従来方式の ILB の比較により CLB の効果を評価する。全評価
指標の結果を表４．４にまとめる。カッコ内の数値は NLB を 100 としたときの相対値を示す。
表４.４ 評価 2 の測定結果
# Method (a) RT [ms] (b) TP (c) CIR [%] (d) IIR [%] (e) RC [ms]
1 NLB
4.5 (100)
100
32
50
2
ILB
4.0 (89)
123
12
0
58.6
3 CLB
3.9 (87)
141
0
15
42.6
(a) 平均レスポンス時間 (RT)
A 点における CLB の RT は 3.9ms で NLB 比 13%の性能向上が図った。ILB は 4.0ms であり
CLB は ILB に対し 2%優位であった。
(b) システムスループット (TP)
CLB が 141 相対 IOPS を示し NLB 比 41%の性能向上を図った。ILB は 123 相対 IOPS であ
った。CLB は ILB に対し 18%優位であった。
(c) CPU 負荷率不均衡率 (CIR)
CLB の CIR は 0%であり完全に負荷均衡できた。NLB からの改善度は 32 ポイントであった。
一方、ILB の CIR は 12%であり、NLB からの改善は 20 ポイントであった。
Relative IOPS
80
60
CPU0
CPU1
IOPS Imbalance Ratio
0%
50%
15%
40
20
0
NLB
ILB
CLB
図４.６ 評価２における IOPS 不均衡率の評価
70
第４章
(d) IOPS 不均衡率 (IIR)
ILB の IIR は 0%と、IOPS の評価基準では完全に負荷均衡が図られていることが図４．６から
わかった。一方 CLB では、IIR が 15%であり相対 IOPS の視点では不均衡であった。上記
(a)(b)(c)の結果と考え併せると、ストレージコントローラにおいては IOPS よりも CPU 負荷率を
評価基準として負荷均衡を行うことが重要であることが確認できた。
(e) 構成変更コスト (RC)
構成変更に要する内部処理は、(1)構成変更実行前に仕掛り中のコマンドの完了待ち、
(2)LU 移行に伴うキャッシュ管理キューのコントローラ間での引き継ぎ、の２点である。構成変
更に要する時間は、(1)に関しては負荷の状況とコントローラ内部の処理状態に依存し、(2)に
関しては Write 時に発生するキャッシュ上の HDD 未書き込みのデータセグメント数に依存
しそれぞれ変動する。これらの時間は構成変更起動後の過渡的な遷移動作になるので解析
的に解くのが難しい。そこで、本研究では上記(1)(2)の動作を模擬するシミュレーションにより
状況を再現し、構成変更コストを LU 移行回数と所要時間から評価する。結果を図４．７に示
す。
LU 移行の間はサーバからの IO が停止するので、LU 移行時間はシステムにとって重
要な指標である。CLB では LU 移行回数は 12 回、総 LU 移行時間は 42.6ms であった。
1LU あたりの平均 LU 移行時間は約 3.6ms である。
これらの数値は構成や環境に依存するので目安と考えるべきであるが、通常 30 秒程
度に設定されるサーバの IO タイムアウト時間に比べ無視できる値であり、また HDD の１回
40
70%
58.6
Cross I/O
Ratio
47%
60%
42.6
40%
30%
20
-
Number of
Migrations
NLB
50%
30%
18%
12
12
20%
10%
0%
ILB
CLB
図４.７ 評価２における構成変更コストの評価
71
Cross I/O Ratio
Total Migration Time [ms]
60
第４章
のアクセスレイテンシが数 ms であることに比べても同オーダである。このことから、この LU 移
行時間は十分許容可能なコストであると判断する。
(3)評価 2 のまとめ
提案方式 CLB は、従来方式 ILB に比べ、平均レスポンス時間で 2%、システムスループ
ットで 18%の性能向上効果を発揮できることを確認した。また本研究の対象とするストレージシ
ステムでは IOPS ではなく CPU 負荷率にて負荷均衡を図ることが重要であることを確認した。
4.4.3
評価 3：疑似実働負荷における性能評価
(1) 測定環境
評価 3 のシミュレーションの想定構成を図４．８に示す。同図において、物理サーバ、VM、
ストレージシステムなどの構成要素は、全てシミュレータ上の構成である。2 台の物理サーバに
は同図の通り 10 台の VM を搭載する想定であり、前述の通り、実サーバにより実測した負荷
VM
Migration
VM1 VM2 VM3
VM5 VM7 VM8 VM9
VM6 VM0 VM4
Physical Server 0
Physical Server 1
60%
45%
CTL0
15%
25%
15%
CPU0
60%
ASU1 ASU3 ASU7
(VM1) (VM3) (VM7)
ASU2 ASU5
(VM2) (VM5)
40%
CPU1
40%
ASU6
(VM6)
ASU8
(VM8)
CTL1
ASU0 ASU4
(VM0) (VM4)
ASU9
(VM9)
Legend
Storage
System
図４.８ 評価 3 におけるシミュレーション想定構成
72
: Low Load ASU
: Middle Load ASU
: High Load ASU
第４章
100
90
Relative IOPS
80
70
60
50
40
30
20
10
VM Migration
VM3, VM5
0
VM Migration
VM1
VM Migration
VM3, VM5
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 Time
図４.９ 評価３の疑似実働負荷特性
曲線を包絡線として SPC-1 負荷を重畳し、24 時間の長時間に渡り発行する。図４．９に発行し
た疑似実働負荷特性を示す。同図において、本ストレージシステムの処理可能な最大 IOPS
を 100 としたときの相対 IOPS を用いて負荷の大きさを表す。
図４．８に戻り、物理サーバ 0 には 7 台の VM を、物理サーバ 1 上には 3 台の VM を初
期設定として搭載した。両物理サーバは同図の通り、各々ストレージシステムの CTL0、CTL1
に接続している。物理サーバ 0 の総発行 IO 負荷は全体の 60%、物理サーバ１は 40%である。
物理サーバ 0 上の破線で示した VM8, 9、および物理サーバ 1 上の VM6 は、各々15%の負
荷を発行する。これらは同図の通りクロスアクセスとなり、他系コントローラを経由して対応する
ASU をアクセスする。ここで、ASU とは、各 VM がアクセス対象とする LU の集合体である。
各 ASU には負荷の大中小の 3 タイプを用意し、実際のばらつきのある環境を模擬すると
ともに、同図の通りの負荷配分になるように設定する。各々の ASU には通常 2 つの LU を割り
当て、特に負荷の高い ASU には 4 つの LU を割り当てる。各 VM 上ではそれぞれ独立の
SPC-1 負荷ジェネレータが動作し、それぞれの VM に割り当てた ASU に対して負荷を発行す
る。CTL0 がオーナとなる ASU への負荷は全体の 60%、CTL1 は 40%とし、初期状態としては
CTL0 に負荷が偏った状態に設定する。この負荷不均衡な初期状態から負荷均衡機能が LU
オーナ権を CTL 間で移行し負荷均衡を実施する様子を観測する。
さらに、VM が物理サーバ間をマイグレーションして負荷均衡が崩れる状況を模擬するた
め、24 時間の中で計 3 回、のべ 5 台の VM が物理サーバ間をマイグレーションする。マイグレ
ーション時刻は 7:31、12:59、17:30 である。以降の図中に、このマイグレーションのタイミングを
破線にて示す。
73
第４章
(2) 測定結果
平均レスポンス時間 (RT)を図４．１０に示す。ILB、CLB 両方式における各 CPU0、1 の
１分毎の CPU 負荷率の平均値を図４．１１に棒グラフで示す。
(3)考察
本評価では ILB との比較により CLB の効果を評価する。評価指標(a)(c)(e)の結果を表４．
５にまとめる。(a)RT のカッコの数値は ILB を 100 としたときの相対値を示す。以下(a)(c)(e)を考
察する。
#
1
2
表４.５ 評価 3 の測定結果
Method (a) RT [ms] (c) CIR [%] (e) RC [ms] (e-2) Number of LU Migrations
ILB
4.8 (100)
4.0
6,260
616
10.0
CLB
3.5 (73)
3,240
227
( 4.0 *1)
注)*1:CPU 負荷率 70%以上の際の CIR
(a) 平均レスポンス時間 (RT)
表４．５によると、24 時間平均 RT は CLB が 3.5ms、ILB が 4.8ms であった。CLB は ILB
比 27%の性能向上を達成した。なお図示していないが NLB の RT は 25.3ms であり、CLB は
86％の性能向上を達成した。次に図４．１０により平均レスポンス時間遷移を考察する。
CLB は、0:30 頃に 60ms という大きなレスポンス時間を観測した。図４．１１(b)を参照すると、
CPU0 の CPU 負荷が 100%に達していることがわかる。これは負荷不均衡状態において最初
の突発的な負荷急上昇に対応できなかったためである。しかし、その 1 分後には負荷均衡
Average Response Time [ms]
70
VM Migration
VM1
VM Migration
VM3, VM5
VM Migration
VM3, VM5
ILB
CLB
60
50
40
30
20
10
0
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 Time
図４.１０ 評価３の平均レスポンス時間測定結果
74
第４章
機能が効果的に作用し、10ms 以下までレスポンス時間は低下した。その後、2 度の 10ms 程
度への上昇は観測したが、全体的に安定した低レスポンス時間を実現した。
一方、ILB は、同図の通り、幾度か 40～60ms の大きなレスポンス時間を観測した。図４．
１１(a)を参照すると、このとき一方の CPU 負荷率が 95%を超えていることを観測した。ILB は
CPU 負荷率の観点で負荷均衡を図らないためである。この過大な CPU 負荷率によりレスポ
ンス時間が悪化したと考えられる。
以上より、24 時間の長期に渡り、VM マイグレーションを伴い大きく時間変動する負荷に対
しても CLB は、従来技術の ILB や負荷均衡未実施の NLB に比べ、顕著な性能優位性を
備えていることを確認した。
(c) CPU 負荷率不均衡率 (CIR)
表 4.5 によると、24 時間平均 CIR は、CLB では 10.0%、ILB では 4.0%であり、全体では
ILB の方が CLB より低かった。この差異はアルゴリズムの差に起因する。ILB は IOPS を負
荷均衡の指標に用いるため、IOPS の不均衡が発生すれば CPU 負荷率の大小に関わらず
均衡化を実行するため、多くの回数の LU 移行を実施した。その結果、図４．１１(a)の通り、
低 CPU 負荷率の時にも均衡化を行ったため、24 時間平均 CIR が低値となった。一方、
CLB は、TH79 の閾値パラメータを用いたので、移行元の CPU 負荷率が 70%を超えた場合
のみ均衡化処理を実行した。すなわち、これ以下の負荷の場合には、図４．１１(b)に見られる
通り、たとえ CPU0 と CPU1 の CPU 負荷率に不均衡があっても、式(4-1)の観点から、レスポ
ンス時間に大差ないと見切り、意図的に LU 移行は行わない。よって平均 CIR は大きくなる。
一方、CLB において負荷均衡化を実施した CPU 負荷率 70%以上の高い負荷の場合に
は、同表の通り、CIR は 4.0%であり、均衡化が達成できることが確認できた。
(e) 構成変更コスト (RC)
表４．5 によると、24 時間総 LU 移行時間は CLB では約 3.2 秒、ILB では約 6.3 秒であっ
た。また、総移行回数は、CLB では 227 回、ILB では 616 回であった。上述の通り CLB は
低 CPU 負荷率のときは負荷均衡を抑制し真に必要なときのみ実施するので、結果として総
LU 移行時間は ILB の約半分となった。また、1 回の平均 LU 移行時間は 14.3ms であった。
評価 2 で考察した通り、通常 30 秒程度に設定されるサーバの IO タイムアウト時間に比べ無
視できる値であることから、この LU 移行時間は許容可能なコストであると判断する。
75
第４章
100
CPU0
90
80
70
60
50
40
30
CPU Load [%]
20
10
0
0
0:00
0:00 1:00
1:00 2:00
2:00 3:00
3:00 4:00
4:00 5:00
5:00 6:00
6:00 7:00
7:00 8:00
8:00 9:00
9:00 10:00
10:00 11:00
11:00 12:00
12:00 13:00
13:00 14:00
14:00 15:00
15:00 16:00
16:00 17:00
17:00 18:00
18:00 19:00
19:00 20:00
20:00 21:00
21:00 22:00
22:00 23:00
23:00 Time
VM Migration
VM Migration
VM Migration
VM3, VM5
VM1
VM3, VM5
10
20
30
40
50
60
70
80
90
CPU1
100
(a) ILB
100
CPU0
90
80
70
60
50
40
30
CPU Load [%]
20
10
0
0
0:00
0:00 1:00
1:00 2:00
2:00 3:00
3:00 4:00
4:00 5:00
5:00 6:00
6:00 7:00
7:00 8:00
8:00 9:00
9:00 10:00
10:00 11:00
11:00 12:00
12:00 13:00
13:00 14:00
14:00 15:00
15:00 16:00
16:00 17:00
17:00 18:00
18:00 19:00
19:00 20:00
20:00 21:00
21:00 22:00
22:00 23:00
23:00 Time
VM Migration
VM Migration
VM Migration
VM3, VM5
VM1
VM3, VM5
10
20
30
40
50
60
70
80
90
CPU1
100
(b) CLB
図４.１１ 評価３の CPU 負荷率の評価結果
76
第４章
LU 移行の時間的推移を図４．１２に示す。同図において、VM マイグレーション起動時に
負荷均衡状態は一旦崩れるので CLB、ILB 共に負荷均衡状態を取り戻すため LU 移行を
起動している様子が見られた。一方、その他の局面に注目すると、先に述べた通り、CLB は
CPU 負荷率が 70%以下の場合には負荷均衡動作が作動していない。真に必要な時だけ負
荷均衡を起動させる本アルゴリズムの特徴が確認できた。
本評価では、式(4-2)に示す平均 CPU 負荷率算出式において、n=2、定期モニタ周期=5
秒を用いた。また、過剰な負荷均衡動作の防止策として LU 移行後 50 秒間は負荷均衡判
定を抑止した。
ここで、この過剰な負荷均衡動作の防止策について考察する。抑止時間を変化させた際
のシミュレーション結果を表４．６に示す。同表において、抑止時間が 5０秒と５秒の２ケース
に注目する。抑止時間を５０秒とした際は、RT が 3.5ms、移行回数が 227 回、総構成変更
時間が 3.2 秒、RC が 14.3ms であったのに対し、抑止時間を５秒とした際には、RT が
3.5ms、移行回数が 533 回、総構成変更時間が 9.2 秒、RC が 17.3ms であった。このように、
抑止時間を低減しても RT の改善は見られなかったのに対し、総構成変更時間は約 2.9 倍
に長時間化し、RC は約 1.2 倍に悪化した。また移行回数は約 2.3 倍に増加し、2.7 分に 1
回の高頻度で負荷均衡動作が起きる結果になった。以上より、この防止策により負荷均衡
動作回数を低減させることが RC 低減の観点で必要である判断する。
14
Number of Migrations
12
VM Migration
VM3, VM5
VM Migration
VM1
VM Migration
VM3, VM5
ILB
CLB
10
8
6
4
2
0
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 Time
図４.１２ 評価３の LU 移行回数推移
77
第４章
Prevention
Time [sec]
5
30
50
表４.６ 過剰な負荷均衡動作の防止策の効果
RT [ms]
Number of LU
Total Migration
Migrations
Time [sec]
3.5
533
9.2
3.5
282
4.6
3.5
227
3.2
RC [ms]
17.3
16.3
14.3
(4) 評価 3 のまとめ
24 時間の長時間に渡り、かつ、VM マイグレーションを伴い大きく時間変動する負荷に対
しても、CLB の 24 時間平均レスポンス時間は 3.5ms であり、ILB 比 27%、NLB 比 86％の性能
向上を達成し、顕著な性能優位性を備えていることが確認できた。
78
第４章
4.5 結言
本章では、ストレージコントローラ間の処理負荷均衡化の実現を目的とした以下の知見を得
た。
(1) LU オーナ権の有無により生じるアクセスモードの差異と、Read/Write コマンドの制御の
差異の両方に起因する不均質な負荷特性を考慮した sSAA 型デュアルコントローラスト
レージシステム向けコントローラ間負荷均衡方式として CPU 負荷均衡方式を提案した。
人手の介在なく自動的にコントローラ間の負荷均衡による性能チューニングが可能となり、
これにより運用性を向上できる見通しを得た。
(2) CPU 負荷均衡方式の性能評価を実施するため、sSAA 型デュアルコントローラの動作を
詳細に模擬したイベントドリブン型待ち行例性能シミュレータ LB-Sim を開発した。
(3) CPU 負荷均衡方式のアルゴリズムで規定する CPU 負荷率判定閾値の相違による特性
差と、それに応じた適切な使用法を明らかにした。特に TH79 の設定により、自動的にコ
ントローラ間の負荷均衡を図れることを確認した。
(4) 連続安定負荷において、CPU 負荷均衡方式は、従来技術の IOPS 負荷均衡方式に対
して、平均レスポンス時間で 2%、システムスループットで 18%の性能向上効果があること
を確認した。
(5) VM マイグレーションを伴う長時間の疑似実働負荷において、CPU 負荷均衡方式の 24
時間平均レスポンス時間は 3.5ms であり、IOPS 負荷均衡方式に対し 27%の性能向上効
果があることを確認した。
(6) 今後の課題として、ユーザ利用環境に合わせた最適な CPU 負荷率判定閾値の自動選
択機能や、運用管理者へのガイダンス機能の実現が挙げられる。
79
第５章
第５章
自律型無停止マイクロコード交換技術による高可用化
5.1 緒言
ストレージシステムは現代の 24 時間 365 日稼働する基幹系情報システムの根幹をなす
ことから、その信頼性、可用性は極めて重要である。ストレージシステムにとって高信頼化とは、
データ喪失率の低減を実現することを意味する。これを実現する基本アーキテクチャとして前
述のとおり Redundant Arrays of Inexpensive Disks (RAID) [PAT88]が普及している。多数のデ
ータディスクに加えてパリティディスクと呼ぶ冗長データを格納するディスクを備え、ディスク障
害時には、残るデータディスクのデータとパリティディスクの冗長データから障害ディスクの格
納データを再現することでデータ喪失を防止する。冗長データの配置方法やデータ再現方法
を 工 夫し デー タ 喪 失率を 低 減 さ せる た め の多 くの 研 究 が な され て き た[LEE90][LEE91]
[CHE94][ELE07][LON02][HEN07]。
一方、ストレージシステムにとって高可用化とは、システム稼働率の向上を実現することを
意味する。一般に基幹系情報システムでは"ファイブ・ナイン"と呼ばれる稼働率が 99.999%以
上の極めて高い可用性が求められる。上述したディスク障害への対策だけでなく、コントローラ
の冗長化、電源・ファンの冗長化、ケーブルの冗長化などハードウェアの冗長構成に加え、ホ
ットスワップと呼ぶシステム稼働中に障害部品を交換することを可能にする機構の搭載によっ
てハードウェア障害への対策がなされてきた。またソフトウェアに関しても、近年の情報システ
ムの大規模化・複雑化に伴い、品質維持や機能拡張が必要不可欠になっている。実態として、
近年の情報システムの障害に関する公的調査結果によると、システム障害の多くがソフトウェ
アの不具合が原因であることが報告されている[JOH09] 。このようにハードウェア障害への対
策に加えソフトウェアへの対策を並行して行う取組みが研究されてきた[TAK10][TOK03]。
本章では、高可用化の課題を解決する技術について論述する。目標は保守作業を含め
て、ファイブ・ナイン 99.999%の可用性を実現することが目標である。本章が研究対象とするデ
ュアルコントローラ型ストレージシステムは、高可用化を実現するため、ハードウェアに関しては、
コントローラの二重化に加え、電源・ファン、ケーブル等、すべてのハードウェアが冗長化され、
ハードウェア障害時にはホットスワップにより修復できる構成になっている。ソフトウェアに関し
ても、コントローラには、マイクロコードと称される大規模な制御ソフトウェアが実装されており、
81
第５章
ハードウェアと同様に、システム稼働中の交換が必要である。従来、マイクロコードを交換する
際には、一旦 1 台のコントローラを停止して、その間にマイクロコードの交換を実施し、同コント
ローラをオンラインに復帰後、他方のコントローラに関しても同様の手順を踏むことで作業を実
施していた。このマイクロコード交換作業中のストレージコントローラの停止をサーバに認識さ
せずにサービス無停止で実施しなくてはならない。そこで、サーバにマルチパスソフトウェアと
いわれるアクセスパスを切り替えるソフトウェアを搭載し、稼働中のストレージコントローラにコマ
ンドを振り向けることによって、マイクロコード交換対象のコントローラがコマンドを受信しないよ
う切り離し、この間にマイクロコード交換作業を実施していた[HPJ11][MIC14]。
しかしながら、このマルチパスソフトウェアの操作には、サーバ運用管理者が携わる必要
があることから、運用コストが上昇するという課題があった。特にクラウドコンピューティング環境
においては、１台のストレージシステムに数百台から数千台の物理サーバないしは仮想サ
ーバが接続されていることも珍しくなく、これらすべてのサーバに対して上記のマルチパスソフ
トウェアの設定変更を行うことは、手順の大幅な煩雑化を伴うと同時に、作業ミスによるシステム
ダウンのリスクも高く、運用管理者にとっては難易度の高い作業になった。そこで、しばしばそ
の煩雑さとリスクを回避するため、関連するシステム全系を計画停止してマイクロコード交換の
作業を行わなくてはならない場合もあった。
本章では、sSAA 型デュアルコントローラ型ストレージシステムにおいて、無停止マイクロコ
ード交換を実現するために、sSAA 方式の性能対称性の特徴を活用することにより、マルチパ
スソフトウェアの操作を行うことなく、マイクロコード交換中のストレージコントローラが受信したコ
マンドを、稼働中のストレージコントローラに移送して、同コントローラが全コマンドを実行するこ
とにより、サーバからは見かけ上無停止でマイクロコード交換を実現する技術を提案する。以
下、本技術を自律型無停止マイクロコード交換技術と称する。
以下、５．２節では、提案する自律型無停止マイクロコード交換技術の方式について説明
する。５．３節では、評価方法について説明する。５．４節では、評価結果を述べ、提案方式の
効果を検証する。
82
第５章
5.2 自律型無停止マイクロコード交換方式の提案
5.2.1
従来方式：パス切替型無停止マイクロコード交換方式
無停止でマイクロコードを交換する方法としてマルチパスソフトウェアを活用した方法があ
る[HPJ11][MIC14]。元来マルチパスソフトウェアは、高可用システムを構築するためにサーバ
に搭載するソフトウェアであり、ストレージコントローラの故障や、サーバ－ストレージ間アクセス
パスの故障による稼働停止を防ぐため、障害系統を切り離し正常稼働する他系統へのアクセ
スパスに経路を切替えることにより故障個所を回避する機構である。マイクロコード交換の際に
は、この機構を応用し、サーバ運用管理者が意図してアクセスパスを稼働中のストレージコント
ローラに向かうように切替え、全コマンドを振り向けることで、マイクロコード交換対象コントロ
ーラがサーバからのコマンドを受領しないように切り離し、この間にストレージ運用管理者は当
該コントローラのマイクロコード交換作業を行う。
しかし、この方法では、サーバ運用管理者とストレージ運用管理者の両者が協調して作
業を行う必要があるため、調整の煩雑さ、運用コストの上昇、人手によるパス切替作業の失敗
リスクなど、運用性に課題があった。また、特にクラウドコンピューティングのような大規模なシス
テム環境では、１台のストレージシステムに接続される物理サーバ数は数百台に及び、さらに
は仮想化技術により構築された仮想サーバ（以下 VM：Virtual Machin と称する）は数千台にも
及ぶ。またストレージシステムが扱う LU 数も同じく数千台にも及ぶ。これらの全 VM および全
LU に対して手作業でアクセスパス切替を実施するのは多大なる労力と時間を要し、現実的な
運用コストの下では実施が困難になるという課題があった。
5.2.2
提案方式：自律型無停止マイクロコード交換方式
(1) 基本概念
この課題を解決するため、ストレージ運用管理者が単独で、ストレージコントローラのマイ
クロコードの交換を行える方式を提案する。マイクロコードの交換は、ストレージシステムの運
用管理のための作業につき、サーバ運用管理者の手を借りずストレージ運用管理者が単独で
作業できることが望ましい。そこで、従来はサーバ運用管理者がサーバ上のマルチパスソフト
ウェアを操作することで行っていた、マイクロコード交換対象のストレージコントローラに発行さ
れたコマンドを他系コントローラへ振り向ける処理を、sSAA ストレージコントローラが備える性
能対称性とコマンドを高速に他系コントローラに移送する技術を活用して、サーバに依存せず
自律的に実施することを考える。
83
第５章
提唱する sSAA ストレージコントローラは、第３章で論述した通り、コマンドを受信した非オ
ーナコントローラが LU オーナ権を備える他系のオーナコントローラにコマンドを移送し処理を
代行させるコマンドキャスティング機能を備える。コマンドキャスティング機能の概念図を図５．
１に示す。同図において CTL0 をマイクロコード交換の対象コントローラとする。sSAA ストレ
ージコントローラは、コントローラ間が独自のデータ伝送経路で接続されており、CTL1 のメモリ
アドレス空間は、CTL0 にマッピングされている。その逆も同様である。このマッピング機能によ
り、同図の CTL1 の Local Memory 上の Receive Queue は、CTL0 の CPU や Host I/F
Controller（HIC)からもアクセス可能である。HIC は全コマンドを CTL1 の Local Memory 上の
Receive Queue に直接移送する。なお、第２章の論述との相違は、この場合にはクロスアクセス
かストレートアクセスかを判定する必要がなく、全コマンドを一律移送すれば良いので、CPU
の介在なく HIC が移送を実施できることである。この間に CPU0 はマイクロコード交換処理を
実行することができる。以上、従来方式と提案方式の比較を表５．1 にまとめる。
Host Command
to LU1
(Casting Command）
A
B
Host I/F Controller
(HIC)
CTL0
C
D
Local
Memory
Receive
Queue
AB C D
A B C D
Command
Queue
Microcode
Updating
Command
Queue
Receive
Queue
AB C D
LU0
図５.１ コマンドキャスティング機能
84
Local
Memory
CPU1
CPU0
A B C D
CTL1
LU1
第５章
表５.１ 無停止マイクロコード交換方式比較
Method
Non Stop
Path Switch
Administrators
Host Admin &
Conventional
Yes
Need
Storage Admin
Proposed
Yes
No Need
Storage Admin
(2) 動作手順
次に提案方式の動作手順について図５．２を用いて説明する。
(a) 全実行開始済コマンドの終了待ち
マイクロコード交換指示がストレージ運用管理者から管理端末を経由し CTL0 に発行され
る。CTL0 の CPU0 で稼働するマイクロコードは、これを契機にコマンドスレッドの新規生成を
抑止する。既に開始済みのコマンドスレッドはそのまま実行を継続する。サーバからのコマン
ド受領も通常通り行われるが、新規コマンドスレッド生成が抑止され実行されないので、受領
したコマンドは Command Queue に滞留する。この状態で全ての実行開始済コマンドの終了
を待つ。
(b) LU 割り当ての切替え
全ての実行開始済コマンドが終了すると、CPU0 で稼働するマイクロコードは全コマンドを
移行すべく CTL0 の HIC（以下、CTL0 の HIC のことを HIC0 と総称する）に LU 割り当ての
切替指示を発行する。この実施に際しては、コマンド実行順序の不整合が発生しないよう、こ
の切替えの期間のみサーバからのコマンド受領を抑止する。また CPU1 に LU オーナ権の
移行を指示する。オーナ権の移行に際しては、キャッシュの管理情報も引き継がれる。
(c) Command Queue のコピー
次に HIC0 用に設けられた Command Queue に滞留していた未実行コマンドを CTL1 の
Command Queue にコピーして CTL1 に引き継ぐ。
(d)マイクロコードアップデートの実行
以上の処理により、HIC0 が受領した全コマンドは CTL1 の Receive Queue にキャストされ
CTL1 により実行されるようになる。よってコマンド処理に際して CTL0 の CPU0 は一切関与
する必要がなくなる。これにより CTL0 でマイクロコード交換処理が開始できる。
85
第５章
Management
Console
Request
microcode
updating
CPU0
HPP0
CPU1
Receive request of LU
dispatch change
Receive request of LU
ownership change
Receive request for
microcode updating
Stop activation of
command threads
Request of LU dispatch
change
Stop I/Os reception
Change LU dispatch
Check Point
(b)Receive end of
LU dispatch change
Restart I/Os reception
Change LU ownership
Pause Time Tpause
Check Point (a)Wait for completion of
all executed commands
Copy of non-executed
commands in
command queue
Check Point
(c)Wait for empty
of command queue
(d)Ready for
microcode updating
(Execute microcode
updating)
図５.２ 提案方式の動作手順
マイクロコードの交換処理が終了すると同一の手順で CTL1 に集合された全ての LU オ
ーナ権が今度は CTL0 に移行され、続けて CTL1 のマイクロ交換処理が実行される。なお、
上記(a)、(b)、(c)は一連の処理手順におけるチェックポイントになり、処理がシリアル化される。
このチェックポイントをクリアしない限り次のステップに進めないため、処理の追い越しや抜け
もれなどは発生しない。
ここで、図５．２に示す通り、チェックポイント(a)の直前でコマンド処理スレッドを停止してか
ら、チェックポイント(c)のコマンドキューのコピーが完了し LU 制御権が他系コントローラに完全
に引き渡されるまでの時間を、コントローラの一時停止時間
と定義する。この間は、受信
したコマンドのアクセス処理は停止する。この停止時間の長さについては 5.4 節で評価する。
86
第５章
5.2.3
評価項目
この提案方式には以下の評価すべき項目がある。
(1) 性能の評価
本方式によると、無停止でマイクロコード交換処理を実施可能であるが、マイクロコード交
換処理中は片系に全コマンド処理が集中することになる。この際の負荷集中が運用の支障と
ならないか実環境に照らして評価することが必要である。
(2) 可用性の評価
本方式によると、コマンド実行を一旦停止させて LU オーナ権を移行したうえでマイクロコ
ードの交換を実施するが、この間サーバへのサービスが停止する。目標とするファイブ・ナイン
の可用性が実現可能か実環境に照らして評価することが必要である。
5.3 評価方法
5.3.1
性能シミュレータ LB-Sim の適用
sSAA ストレージコントローラの性能評価に特化したイベントドリブン型性能シミュレータ
LB-Sim を開発したことを第４章で論述した。LB-Sim は、sSAA の特徴である LU オーナ権移
行機能、コマンドキャスティング機能、クロスアクセス機能を全て網羅してある。また、サーバか
ら発行されるダイナミックな IO パターンの影響を評価できるように実働環境下で計測した IO
負荷をシミュレータに入力可能な IO ジェネレータ機構を搭載している。このように LB-Sim に
よるとストレージシステムの静的特性ならびに動的特性を考慮した性能評価を実施できる。こ
の特徴を活用し、本章の技術評価に際し、LB-Sim を適用することにする。
5.3.2
シミュレータの構成
評価に用いたシミュレータの構成パラメータを表５．２に示す。シミュレーションモデルにお
ける処理時間や動作を規定する数値には、サーバに一般的に使用される CPU と HDD を想
定した数値を使用した。また、HDD の台数は 960 台とした。この台数はコントローラの CPU を
性能ボトルネックにするのに十分な台数である。
87
第５章
表５.２ シミュレータの構成パラメータ一覧
Parameters
Configuration
IO
4KB Random Read
CPU
1.6 GHz Single Core
Cache
4GB / CTL
RAID
RAID5 14D+1P
LU
64
Numbers
960 HDDs
Type
SAS
146GB
HDD
R.P.M.
15,000
シミュレータの構成を図５．３に示す。同図において、物理サーバ、VM、ストレージシステ
ムなどの構成要素は、全てシミュレータ上の構成である。2 台の物理サーバには同図の通り 10
台の VM を搭載した環境とし、現実の場面を想定し負荷が偏った状態に設定した。物理サ
ーバ 0 には 7 台の VM を、物理サーバ 1 には 3 台の VM を搭載し、両物理サーバは同図の
通り、各々ストレージシステムのコントローラ CTL0、CTL1 に接続し、物理サーバ 0 の総発行
VM1 VM2 VM3
VM4 VM5 VM6 VM7
Physical Server 0
VM8 VM9 VM10
Physical Server 1
30%
70%
CTL0
CTL1
CPU1
CPU0
ASU1 ASU3 ASU5 ASU6
(VM1) (VM3) (VM5) (VM6)
ASU2 ASU4
(VM2) (VM4)
ASU8 ASU9 ASU10
(VM8) (VM9) (VM10)
ASU7
(VM7)
Storage
System
図５.３ シミュレータの構成
88
Legend
: Low Load ASU
: Middle Load ASU
: High Load ASU
第５章
IO 負荷は全体の 70%、物理サーバ１は 30%である。全てストレートアクセスを想定したため、
CTL0 がオーナとなる ASU への負荷は全体の 70%、CTL1 は 30%となる。ここで、ASU
(Application Storage Unit) とは、各 VM がアクセス対象とする LU の集合体である。各 ASU に
は負荷の大中小の 3 タイプを用意し、実際のばらつきのある環境を模擬するとともに、指定の
負荷配分になるように設定した。マイクロコード交換は２箇所のタイミングで実施した。１箇所目
は、およそ 8:40 ごろの低負荷時で、相対 IOPS は約 30 程度である。２箇所目は、およそ 6:50
ごろの中負荷時で、相対 IOPS は 50 程度である。後述する図５．４の入力負荷特性図中にこ
れら二度のマイクロコード交換のタイミングを破線にて示す。以上説明した評価パラメータの一
覧を表５．３に示す。
#
1
5.3.3
表５.３ 評価パラメータ一覧
Parameters
Explanation
Simulated Actual Load (SPC-1)
Load Type
(1)Low Load, (2)Mid Load
2
Number of VM
10
3
Load Bias
70 : 30
4
Read Ratio
40%
シミュレーションの入力負荷特性
シミュレーションの入力負荷特性を図５．４に示す。同図において、本ストレージシステム
の処理可能な最大 IOPS を 100 としたときの相対 IOPS を用いて負荷の大きさを表す。IO 負
荷には、実働環境で計測した実負荷トレース情報に SPC-1 負荷ジェネレータの発行する
100
90
Relative IOPS
80
70
60
②マイクロ交換
中負荷時
50
40
30
20
10
0
①マイクロ交換
低負荷時
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 Time
図５.４ シミュレーションの入力負荷特性
89
第５章
SPC-1[GIL05][SPC15]に準拠した負荷を重畳させた「疑似実働負荷(Simulated Actual Load)」
を用いる。ここで疑似実働負荷について説明する。まず、実働するファイルサーバの IO 負荷
を 24 時間に渡り計測しトレースデータを取得する。次に、トレースデータの負荷特性曲線を包
絡線として LB-Sim が備える SPC-1 負荷ジェネレータが SPC-1 の IO 負荷を重畳させる。この
方法により、実サーバで観測される大きく時間変動する負荷変化を模擬しつつ、標準ベンチ
マークで用いられる典型的な負荷特性を加味することができ、負荷の動的特性（時間変動）と
静的特性（一般性）の両面を考慮した性能評価を実施することができる。
5.4 提案方式の評価
5.4.1
性能の評価
低負荷時と中負荷時の２つのケースにて評価を行った。(1)に低負荷時、(2)に中負荷時
の結果および考察をそれぞれ示す。また、(3)でマイクロコード交換を実施可能な期間につい
て考察する。
(1) 低負荷時（時刻：8:40 付近、相対 IOPS：約 30）
(i)スループット性能
低負荷時のスループット性能の測定結果を図５．５に示す。グラフ(a)は CTL0、グラフ(b)は
CTL1、グラフ(c)はシステム全体の各々のスループット性能である。同図において観測開始 5
分後に CTL0 がマイクロコード交換を開始、10 分後に CTL1 がマイクロコード交換を開始、
15 分後に通常復帰する設定とした。以降、他のグラフも同様である。グラフには比較のため
マイクロコード交換未実施時の測定結果（図中 Usual と表記したグラフ）とマイクロコード交換
実施時の測定結果（図中 Microcode Updating と表記したグラフ）の両者を併記した。以下、
説明の簡単化のため、グラフ上での観測開始後の時刻を用いることにする。
同図グラフ(a)において、時刻 5 分から 10 分の間は CTL0 がマイクロコード交換を実行す
るため、CTL0 の性能は 0 となる。一方、CTL1 がすべてのコマンドを処理するため、CTL0
の負荷が CTL1 の元々の負荷に重畳された。
同図グラフ(b)において、時刻 10 分から 15 分の間は CTL1 がマイクロコード交換を実行
するため、今度は CTL1 の性能が 0 となり、CTL1 の負荷が CTL0 の元々の負荷に重畳さ
れた。時刻 15 分には両コントローラのマイクロコード交換が完了し、通常状態に復帰した。
90
第５章
同図グラフ(c)において、システム全体での処理 IOPS はマイクロコード交換の有無に関わ
らず完全に一致していることが観測された。すなわち、マイクロコード交換中に一方のコントロ
ーラに負荷集中してもスループット性能の劣化や処理欠損等の問題は発生していない。
(ii)平均レスポンス時間
低負荷時の平均レスポンス時間の測定結果を図５．６に示す。グラフ(a)は CTL0、グラフ(b)
は CTL1、グラフ(c)はシステム全体の各々の平均レスポンス時間である。
(ii)と同様に、時刻 5 分から 10 分の CTL0、時刻 5 分から 10 分の CTL1 の各々のマイク
40
20
0
5
10
15
20
[min]
Relative IOPS [%]
(a) CTL0
100
Usual
Microcode Updating
80
60
40
20
0
5
10
15
20
[min]
Usual
80
Microcode Updating
60
40
20
5
10
15
20
[min]
(c) System
4
3
2
Usual
1
Microcode Updating
0
5
10
3
2
Usual
1
Microcode Updating
0
5
10
15
4
3
2
Usual
1
Microcode Updating
0
5
10
15
(c) System
Usual
Microcode Updating
80
60
40
20
10
(a) CTL0
15
100
20
[min]
Usual
Microcode Updating
80
60
40
20
0
5
20
[min]
(b) CTL1
図５.６ 低負荷時の平均レ
スポンス時間測定結果
5
20
[min]
4
100
0
15
(a) CTL0
図５.５ 低負荷時のスループ
ット性能測定結果
CPU Load [%]
0
CPU Load [%]
Relative IOPS [%]
(b) CTL1
100
Response Time [ms]
60
Response Time [ms]
Usual
Microcode Updating
80
Response Time [ms]
Relative IOPS [%]
ロコード交換時にはコマンド処理が行われないので平均レスポンス時間は 0 と表記される。
100
10
(b) CTL1
15
20
[min]
図５.７ 低負荷時の CPU 負荷率測定結果
91
20
[min]
第５章
一方、稼働中のコントローラの平均レスポンス時間は他系からコマンドキャストされてきたコマ
ンドを追加で処理するため、オーバヘッドが増加することが観測された。同図グラフ(c)より、
システム全体で見ると最も高い平均レスポンス時間は時刻 10 分に 2.77ms から 2.91ms に約
5%増加した。しかしこの増加分は十分に小さい値でありアプリケーションへの影響は問題に
ならないと判断する。
(iii)CPU 負荷率
低負荷時の CPU 負荷率の測定結果を図５．７に示す。グラフ(a)は CTL0、グラフ(b)は
CTL1 の各々の CPU 負荷率である。(i)、(ii)と同様に、マイクロコード交換実施中はコマンド
処理は実行しないので CPU 負荷率は 0 と観測された。なお、マイクロコード交換処理の
CPU 負荷はカウントしていない。また、稼働中のコントローラの CPU 負荷率は同様に上昇す
ることが観測された。両コントローラとも CPU 負荷率は 60%以下であり、十分な余力を持って
実行された。
92
第５章
(2) 中負荷時（時刻：6:50 付近、相対 IOPS：約 50）
中負荷時のスループット性能の測定結果を図５．８に示す。平均レスポンス時間の測定結
果を図５．９に示す。CPU 負荷率の測定結果を図５．１０に示す。
中負荷時には、負荷が上昇したのに伴い振れ幅が大きくなったことを除くと、スループット
性能、平均レスポンス時間、CPU 負荷率は、ともに低負荷時と同様の傾向を示した。平均レス
ポンス時間は、システム全体で見ると、最も高い平均レスポンス時間は時刻 8 分に 2.79ms か
ら 3.33ms となり、増加幅は 0.54ms、増加率で約 19%増加した。しかし、このときの CPU 負荷
Usual
Microcode Updating
80
60
40
20
0
[min]
100
Usual
80
Microcode Updating
60
40
20
0
5
10
15
20
[min]
(b) CTL1
Usual
Microcode Updating
60
40
20
5
10
15
20
[min]
(c) System
2
Usual
1
Microcode Updating
0
5
2
Usual
1
Microcode Updating
0
5
10
3
2
Usual
1
Microcode Updating
0
5
10
Usual
Microcode Updating
40
20
10
(a) CTL0
15
100
20
[min]
Usual
Microcode Updating
80
60
40
20
5
20
[min]
4
60
0
15
15
図５.９ 中負荷時のレスポ
ンス時間測定結果
5
20
[min]
3
80
0
15
4
100
CPU Load [%]
10
(c) System
図５.８ 中負荷時のスル
ープット性能測定結果
CPU Load [%]
0
3
(b) CTL1
100
80
4
(a) CTL0
Response Time [ms]
Relative IOPS [%]
(a) CTL0
Relative IOPS [%]
Response Time [ms]
100
Response Time [ms]
Relative IOPS [%]
率は 90%以下であり、低負荷時と同様に十分に処理し切れていることが確認できた。
10
(b) CTL1
15
20
[min]
図５.１０ 中負荷時の CPU 負荷率測定結果
93
20
[min]
第５章
(3) マイクロコード交換を実施可能な期間
上記の通り、相対 IOPS が 50、すなわちシステムが処理できる最大 IOPS に対して 50%ま
での負荷に対しては、提案する無停止マイクロコード交換方式では、平均レスポンス時間の増
加幅は最大 0.54ms、増加率は 19%であり、アプリケーションへの影響は小さく、実用的である
ことを示した。一方、50%を超える負荷に対しては、短期的なものであれば CPU 負荷率が高い
値となり一時的にレスポンス時間が上昇しつつもこの状態を乗り越えることが期待されるが、高
負荷状態が継続する場合にはコマンドキューがフルとなり、コマンド受領が滞り、結果的にアプ
リケーションに対してタイムアウトエラーが報告されることも予想される。よって、一日のうちで負
荷の低い傾向のあるタイミングや、計画的なバッチ処理が行われていないタイミングでマイクロ
コード交換を実施する必要がある。
そこで、このようなマイクロコード交換を実施可能な期間がどのくらいあるかを評価する。
総 CPU 負荷率の移動平均曲線を図５．１１に示す。総ＣＰＵ負荷率とはＣＰＵ０、ＣＰＵ１の２台
のＣＰＵ負荷率を合計してトータル１００％として計算したものである。移動平均を計算する間
隔としては、5 分、10 分、30 分の 3 通りを示した。ここで、各コントローラのマイクロコード交換
処理をそれぞれ 5 分、通常への復帰処理を 5 分、前後に 5 分ずつの処理マージンを見て総
処理時間を 30 分と仮定する。システムの総 CPU 負荷率が 50%まではマイクロ交換処理が可
能となる。同図によると、CPU 負荷率の 30 分移動平均曲線が総 CPU 負荷率 50%を上回る期
間、すなわち 30 分にわたり平均的に負荷率が 50%を上回る期間は全時間の約 30%にすぎな
かった。すなわち、残り約 70%の時間はマイクロコード交換を実施可能な期間となる。このよう
100
5min
10min
30min
Total CPU Load [%]
90
80
70
60
50
40
30
20
10
0
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
図５.１１ 総 CPU 負荷率の移動平均曲線
94
第５章
に、一日のなかで作業可能な期間は十分あり、提案する無停止マイクロコード交換方式は実
用的であることが確認できた。
なお、上記の通り、今回の事例によれば十分な交換期間があることは検証できたが、どの
タイミングでストレージ運用管理者が作業を行えば確実にマイクロコード交換を行えるかを示
すには至っていない。今後の課題としては、ストレージシステムが内部で測定したアクセスログ
を統計処理して確実性の高い作業時間帯を示す等、ストレージ運用管理者の作業容易化を
支援する使い勝手良いガイダンス機能の実現が挙げられる。
5.4.2
可用性の評価
可用性がファイブ・ナインであるためには、式（5-１）を満たすことが必要である。
×
× 3 < (1 − 99.999%) × 365day
式（5-１）で、 は一年間にマイクロコード交換を行う回数、
（5-１）
はマイクロコード交換の
ためにコントローラが一時停止する時間である。また、左辺で３を乗じているのは、CTL0、
CTL1 の順でマイクロコード交換を行うとすると、LU オーナ権の移行は、(i)CTL0→CTL1、
(ii)CTL1→CTL0、(iii)通常回復、の３回必要になるためである。式（5-１）から
を求めると、
式（5-２）が導出される。
<
分
秒
（5-２）
具体的な許容時間を明らかにするため、仮に年間最大 12 回のマイクロコード交換を行う
と仮定すると、1 回あたりに許容されるコントローラの一時停止時間
は、計算上は約 8.8
秒となる。この値を目標値と設定し評価する。
前節の性能評価で実施したシミュレーションにおいて、(1)低負荷時、(2)中負荷時のそ
れぞれの場合のコントローラ停止時間を測定した。シミュレーション測定結果を表５．４に示す。
表５.４ コントローラ停止時間のシミュレーション測定結果
Load
Cases
Pause Time (T pause)
(1) Low Load
CTL0 -> 1 LU Migration
21.0 ms
CTL1 -> 0 LU Migration
138.8 ms
Return to usual
37.7 ms
(2) Mid Load
CTL0 -> 1 LU Migration
112.8 ms
CTL1 -> 0 LU Migration
150.0 ms
Return to usual
21.6 ms
95
第５章
同表によると、今回のシミュレーションケースにおいては、
は最大でも約 150ms で
あり、全てのケースにおいて上記目標値は満足できることを見出した。またこれらの値はアプリ
ケーションがディスク IO エラーと判定するタイムアウト時間（通常 30 秒程度）やフェイルオ
ーバソフトが異常と判定するタイムアウト時間（通常 15 秒程度）に比べ小さな数値であり、現実
的にはシステム停止とはみなされない。以上より、可用性の面でも提案する無停止マイクロコ
ード交換方式は実用的であることが確認できた。
96
第５章
5.5 結言
本章では、自律型無停止マイクロコード交換技術の確立を目的とし、以下の結論を得た。
(1) デュアルコントローラ型ストレージコントローラ向けに、アクセスパス切替とサーバ運用管理
者の介在を不要とした自律型無停止マイクロコード交換方式を提案した。マイクロコード交
換を実施するコントローラが受信した全てのコマンドを他系コントローラに移送して全コマ
ンド処理を実行することで、当該コントローラの CPU をコマンド処理から解放し、マイクロコ
ードの交換作業を実施可能とする。
(2) 自律型無停止マイクロ交換技術の評価を行うため、第４章で開発したイベントドリブン型性
能シミュレータ LB-Sim と実働負荷を用いた評価手法を確立した。変動する負荷をかけた
状態でマイクロコード交換動作を模擬することで、性能および可用性を評価可能とした。
(3) 性能の評価に関しては、マイクロコード交換処理中の総システム負荷が 50%までは、平均
レスポンス時間の増加は最大 0.54ms、増加率は約 19%であり、アプリケーションから見た
オーバヘッドの増加の影響は小さく、問題とはならないことを確認した。またマイクロコード
交換作業を行える期間は総時間の約 70%に及び、実用的であることを確認した。
(4) 可用性の評価に関しては、マイクロコード交換処理中のコントローラ一時停止時間の最大
値は約 150ms であり、目標とする可用率 99.999%を達成できる見通しを得た。
(5) 今後の課題として、ストレージシステムが内部で測定したアクセスログを統計処理して確実
性の高いマイクロコード交換交換可能な時間帯を示すガイダンス機能の実現が挙げられ
る。これにより、ストレージ運用管理者の作業容易化を支援することが可能になる。
97
第６章
第６章
結論
6.1 本研究で得られた成果
本論文では、デュアルコントローラストレージシステムの、高性能化、高運用化、高可用化
の３つの課題を明らかにし、これらを解決するデュアルコントローラストレージシステム向けの新
アーキテクチャとして Semi-Symmetric Active-Active（ｓSAA）方式を提唱し論述を行った。
１． 第２章では、３つの課題に対処するための基本アーキテクチャとして、LU オーナ権の有無
に関わらず、実用上均質な性能対称性を実現できるｓSAA 型デュアルコントローラ方式を
提唱した。非オーナコントローラが受信したコマンドをオーナコントローラに高速に移送す
るとともに、コマンド処理全体を委譲することで、従来発生していたオーナコントローラへの
処理委託に要するコントローラ間の相互のやり取りに起因するオーバヘッド時間を低減す
る方式とした。待ち行列理論を用いた CPU 性能予測手法を確立し評価した結果、クロス
アクセスのスループット性能において、従来方式比 1.8～4.2 倍の改善効果を確認し、目
標とする HDD250 台を駆動可能なスループット性能を、レスポンス時間増加 10%未満で達
成できる見通しを得た。
２． 第３章では、クロスアクセスの高性能化を実現するためのコントローラ間高速メッセージ伝
送技術として、コマンドキャスティング方式を提案した。他系のメモリ空間を自系メモリ空間
にアドレス変換してマッピングすることで、直接メモリアクセスを可能とするハードウェア回
路と、他系メモリ空間上にコマンドを格納するためのコマンドキャストキューと呼ぶソフトウェ
ア機構を設ける方式とした。従来技術と提案技術に関する性能評価モデルを確立し、メッ
セージ伝送に要する CPU オーバヘッドとメッセージ伝送時間を評価した結果、提案技術
により、CPU オーバヘッドが従来技術比 1/5～1/10 となる 2.0us に、メッセージ伝送時間
が従来技術比 61%～89%となる 15.5us に、それぞれ低減できることを見出した。これにより
RAID5、RAID1 のいずれの構成においても、クロスアクセスの高速化を達成し、ストレート
アクセスとクロスアクセスの両者間で実用上均質な性能対称性を実現できる見通しを得た。
99
第６章
３． 第４章では、sSAA 型デュアルコントローラストレージシステムの高運用化を実現するため
に、システムが自動的にデュアルコントローラ間の負荷均衡状態を維持する技術として
CPU 負荷均衡方式を提案した。コントローラ間の負荷均衡状態が崩れた際に、ｓSAA 方
式が提供する性能対称性を活用し、CPU 負荷率を負荷均衡化の指標として LU オーナ
権をコントローラ間で移行することによって、デュアルコントローラ間の負荷均衡を実現す
る 方 式と し た 。 こ の 際 、LU オ ー ナ 権 の有 無 に より 生じ る アク セ ス モ ー ドの 差 異 と 、
Read/Write コマンドの制御の差異の両方に起因する不均質な負荷特性を考慮することが
特徴である。sSAA 型デュアルコントローラの動作を模擬した性能シミュレータを開発し、
CPU 負荷均衡方式の性能評価を実施した。VM マイグレーションを模擬し、かつ、時間変
動する疑似実働負荷を用いたシミュレーション評価の結果、CPU 負荷均衡方式によると、
24 時間平均レスポンス時間が 3.5ms であり、従来技術に対し 27%の性能向上効果がある
ことを見出した。提案方式の適用により、常時、人手の介在なく、自動的なコントローラ間
の負荷均衡化が可能となり、ストレージシステムの運用性向上に有効であることを明らかに
した。
４． 第５章では、sSAA 型デュアルコントローラストレージシステムの高可用化を実現するため
に、サーバ運用管理者の手助けと、サーバ上のパス切替ソフトウェアの操作を必要とせず、
ストレージ運用管理者が単独で、無停止によりマイクロコード交換を行える技術として、自
律型無停止マイクロコード交換方式を提案した。ｓSAA 方式の提供する性能対称性を活
用し、マイクロコード交換中のコントローラが受信した全てのコマンドを、もう一方の稼働コ
ントローラに高速に移送して処理全体を委譲することで、CPU をコマンド処理から解放し、
その間に無停止マイクロコード交換を実施する方式とした。時間変動する実働負荷を用い
たシミュレーション評価の結果、性能に関しては、最大許容負荷に対し 50％以下の環境
下において、無停止マイクロ交換中の平均レスポンス時間の増加は最大 0.54ms であり、
アプリケーションから見たオーバヘッドの増加の影響は小さいことを見出した。また、可用
性に関しては、マイクロコード交換処理中のコントローラ一時停止時間の最大値は約
150ms であり、目標とする 99.999%の高可用性を達成できることを明らかにした。
100
第６章
6.2 今後に残された課題
1.
ストレートアクセスに対するクロスアクセスの性能低下の改善が挙げられる。一つの方策
として、Host I/F Controller へのコマンド解析機能の搭載により、非オーナコントローラ
の CPU が行う必要のあったコマンド解析処理時間を削減し、クロスアクセスの性能低下
を解消することが可能になる。
2.
自動負荷均衡に関する運用性の向上が挙げられる。ユーザ利用環境に合わせた最適
な CPU 負荷率判定閾値を自動設定する機能や、ストレージ運用管理者へガイダンスす
る機能を実現することで、ストレージ運用管理者の作業負担を軽減することが可能にな
る。
3.
ストレージ運用管理者のマイクロコード交換作業の容易化が挙げられる。ストレージシス
テムが内部で測定したアクセスログを統計処理し、マイクロコード交換に際し、確実性の
高い作業時間帯を提示するガイダンス機能の実現により、ストレージ運用管理者の容易
な作業を支援することが可能になる。
。
101
謝辞
謝辞
本研究は、株式会社日立製作所 横浜研究所と、同情報・通信システム社 IT プラットフォ
ーム事業本部の多くの方々の協力により実施された。本論文執筆に際しご支援、ご協力頂い
た両事業部の皆様に感謝申し上げます。
本論文を纏めるにあたってご指導を賜った、本論文の主査である大阪府立大学 辻 洋
副学長（大学院工学研究科 電気・情報系専攻 知能情報工学分野 教授）、副査である大
阪府立大学 大学院工学研究科 電気・情報系専攻 知能情報工学分野 宮本貴朗教授、
戸出英樹教授、また、副査であり大阪府立大学 大学院工学研究科の連携教授である株式
会社日立製作所 ディフェンスシステム社 主管技師長 新井利明博士に厚く御礼申し上げます。
博士後期課程への就学を勧めてくださった株式会社日立製作所 研究開発本部 技師長
山本 彰博士、および、株式会社日立製作所に在籍のまま就学を許可戴いた株式会社日立製
作所インフラシステム社 技師長（入学時 同社横浜研究所 所長） 堀田多加志博士に厚く御
礼申し上げます。
本論文で提唱した技術方式の研究開発に際し、多くの有益なご議論を戴くとともに、多大
なるご支援、ご協力を賜った、株式会社 日立製作所研究開発本部 主任研究員 野中裕介博
士、株式会社 日立製作所情報・通信システム社 IT プラットフォーム事業本部 主任技師 小川
純司氏、主任技師 小見門孝輔氏に厚く御礼申し上げます。
本研究で活用したストレージシステム性能シミュレータの開発と HDD シミュレータの統合
化の実現に際し、多くの有益なご議論を戴くとともに、多大なるご支援、ご協力を賜った、
Hitachi America Ltd. R&D Center 兼田泰典博士、株式会社日立ソリューションズ 部長 水森
源宏氏、主任 松尾嘉久氏、出雲 博氏に厚く御礼申し上げます。
本論文を纏めるにあたって、数々のご助言、ご支援を賜った、大阪府立大学 大学院工
学研究科 電気・情報系専攻 知能情報工学分野 佐賀亮介准教授、大阪府立大学 地域連
携・研究支援課 吉原美穂氏に厚く御礼申し上げます
最後に、筆者の大阪府立大学 大学院工学研究科 電気・情報系専攻 知能情報分野
博士後期課程における研究を心身両面にわたり支えてくれた家族、両親、兄弟に心から感謝
いたします。
103
参考文献
参考文献
[AGG08]
Nidhi Aggarwal, James E. Smith, Kewal K. Saluja, Norman P. Jouppi,
Parthasarathy Ranganathan: “Implementing High Availability Memory with a
Duplication Cache”, MICRO 41, Proceedings of the 41st annual IEEE/ACM
International Symposium on Microarchitecture, pp.71-82 (2008)
[AKI87]
秋田雄志，中村英夫: "マルチプロセッサ構成のフォールトトレラント駅
構内運転制御システムの開発"，電気学会論文誌 C，107 巻, 10 号,
pp.915-922 (1987)
[BOH02]
Christopher A. Bohna, Gary B. Lamontb: "Load balancing for heterogeneous
clusters of PCs", Future Generation Computer Systems 18, pp.389–400 (2002)
[CAO00]
Jiannong Cao, Graeme Bennett, Kang Zhang: "Direct execution simulation of
load balancing algorithms with real workload distribution", The Journal of
Systems and Software 54, pp.227-237 (2000)
[CHE94]
Peter M. Chen, Edward K. Lee, Garth A. Gibson, Randy H. Katz, David
A. Peterson: "RAID: High-Performance, Reliable Secondary Storage", ACM
Computing Surveys (1994)
[ELE07]
Jon G. Elerath, Michael Pecht: "Enhanced Reliability Modeling of RAID Storage
Systems", Dependable Systems and Networks, 2007. DSN '07. 37th Annual
IEEE/IFIP International Conference, pp.175-184 (2007)
[EMC11]
EMC Corporation: "EMC Powerpath Load Balancing and Failover, Comparison
with native MPIO operating system solutions",
https://www.emc.com/collateral/software/white-papers/h8180-powerpathload-balancing-failover-wp.pdf (2011)
[FRE13]
FREE STATION Inc.: "CCRN-EtherCAT Master (ver3.8) for QNX",
http://www.freestation.co.jp/pdf/EtherCAT_catalog_20130502.pdf (2013)
[FUJ09]
藤井啓明, 樋口達雄, 稲葉淳二, 高橋亮, 上野仁, 大枝高, 角田実: "クラウド
コンピューティング時代の企業情報システムを支えるプラットフォーム
技術", 日立評論 2009 年 7 月号, pp.42-47 (2009)
[GEN05]
Scott Genereux: "The United States Storage Market", 日立評論 2005 年 3 月
号, pp.41-46 (2005)
105
参考文献
[GIL05]
Binny S. Gill, Dharmendra S. Modha: "WOW: Wise Ordering for Writes Combining Spatial and Temporal Locality in Non-Volatile Caches",
https://www.usenix.org/legacy/event/fast05/tech/full_papers/gill/gill_html
/wow.html (2005)
[GMA05]
Daniel Gmach, Stefan Krompass, Stefan Seltzsam, Martin Wimmer, Alfons
Kemper: "Dynamic Load Balancing of Virtualized Data-base Services Using
Hints and Load Forecasting", In Proceedings of the 17th Conference on
Advanced Information Systems Engineering (CAiSE ’05), pp.23-37 (2005)
[HEN07]
John L. Hennessy, David A. Patterson: "Computer Architecture:
A Quantitative Approach Fourth Edition",
http://electro.fisica.unlp.edu.ar/arq/downloads/Bibliografia/HennessyPatterson%20-%20Computer.Architecture..A.Quantitative.Approach.4th.ed.2007.pdf (2007)
[HGS13]
HGST: "Solid State Drive Specification, Ultrastar SSD800M/1000M 2.5" Serial
Attached SCSI (SAS) Solid State Drive Version:1.2",
http://www.hgst.com/tech/techlib.nsf/techdocs/428E24D6C2FA344A88257B
FE0020763B/$file/USSSD800M_Spec_enc_V1.2.pdf (2013)
[HIT02]
日立製作所: "世界最高クラスの性能とスケーラビリティを誇るマルチネ
ットワーク対応のディスクアレイサブシステム", はいたっく 2002 年 6 月
号, pp.11-13 (2002)
[HIT04]
日立製作所: "世界で初めてディスクアレイ装置上で仮想化技術を実現
Hitachi Universal Storage Platform", はいたっく 2004 年 10 月号, pp.19-22
(2004)
[HIT08]
日立製作所: "IT プラットフォーム", 日立評論 2008 年 1 月号, pp.92-99
(2008)
[HIT14]
日立製作所: "IT プラットフォーム", 日立評論 2014 年 1 月号, pp.47-52
(2014)
[HOR10]
堀本徹, Michael C. Hay: "ストレージソリューションのグローバル展開",
日立評論 2010 年 5 月号, pp.64-67 (2010)
[HOR11]
堀内義章: "2011 年の HDD 業界展望 ～多様化するストレージの世界～",
IDEMA Japan News Vol.100, pp.1-14 (2011)
106
参考文献
[HPJ11]
日本 HP: "テクニカルホワイトペーパーミッションクリティカルの高可用
性 を 実 現 す る HP 3PAR StoreServ ス ト レ ー ジ シ ス テ ム ",
http://hp.com/go/getconnectedjp (2011)
[JOH09]
独立行政法人 情報処理推進機構: "情報システム障害発生の状況 調査報告
書", http://www.ipa.go.jp/files/000004526.pdf (2009)
[KAN11]
兼田泰典, 川口 智大, 松並 直人: "大規模集約型ストレージシステムにおけ
るボリュームの性能排他を実現するハードディスク装置の性能分割制御
方式の提案とシーケンシャルアクセス特性の評価", 電子情報通信学会論
文誌 D, Vol.J94-D(1), No.12, pp.290-302 (2011)
[KED05]
毛塚禎子, 加納東, 八木沢育哉, 森田星輝: "DLCM を実現するストレージ基
盤「SANRISE9500V シリーズ」", 日立評論 2005 年 3 月号, pp.55-58 (2005)
[KLE79]
Leonard Kleinrock: "Queueing Systems, Volume I: Theory", McGraw-Hill
(1979)
[KOB97]
小林利恵，松本佳子，村岡健司: "記憶サブシステム", 公開特許公報, 特開
平 9-146842 (1997)
[KOB08]
小林大, 横田治夫: "並列ストレージにおけるデータ再配置による長期的負
荷均衡化と短期的応答性能の両立", 情報処理学会論文誌:データベース,
Vol.49, No.SIG 7(TOD 37), pp.29-43 (2008)
[KUB14]
久芳靖, 福原恵美子, 斉藤達也, 真下祐一, 船生幸雄: "社会イノベーション
事業を支える IT プラットフォームソリューション", 日立評論 2014 年 10
月号, pp.56-59 (2014)
[KUN08]
Daniel Kunkle, Jiri Schindler: "A Load Balancing Framework for Clustered
Storage Systems", HiPC'08 Proceedings of the 15th international conference
on High performance computing, pp.57-72 (2008)
[LEE90]
Edward K. Lee: "Software and Performance Issues in the Implementation of a
RAID Prototype", Technical Report Identifier: CSD-90-573 May 17 (1990)
[LEE91]
Edward K. Lee, Randy H. Katz: "An Analytic Performance Model of Disk
Arrays and its Application", Technical Report Identifier: CSD-91-660
November 21 (1991)
[LON02]
Abraham Long, Jr.: "Assessing the Reliability of RAID Systems",
http://www.dell.com/content/topics/global.aspx/power/en/ps1q02_long?c=us
&l=en&cs=04 (2002)
107
参考文献
[MAT99]
松本佳子，村岡健司，高本賢一，小林正明: "記憶サブシステム", 公開特
許公報, 特開平 11-312058 (1999)
[MIC14]
Microsoft: " マ ル チ パ ス I/O の 概 要 ", http://technet.microsoft.com/jajp/library/cc725907.aspx (2014)
[MIT86]
三巻達夫, 桑原洋: "制御用計算機におけるリアルタイム技術", コロナ社
(1986)
[OKA90]
岡田政和，冨沢宏，大貫健，杉本則彦，中根啓一，小山行雄: "産業用統
合情報ネットワーク 100M ビット/秒 光 LAN ‘TRUNK NETWORK-100’",
日立評論 1990 年 4 月号, pp.29-36 (1990)
[OKA01]
岡部泰一: "ネットワーク技術解説講座 詳説 TCP/IP プロトコル 第 7 回 イ
ーサネット（その２）―イーサネットのフレーム構造 ３．イーサネッ
トのフレーム・フォーマット",
http://www.atmarkit.co.jp/fwin2k/network/tcpip007/tcpip03.html (2001)
[PAT88]
David A. Patterson, Garth Gibson, Randy H. Kat: "A Case for Redundant
Arrays of Inexpensive Disks (RAID)", Proceedings of the 1988 ACM SIGMOD
International Conference on Management of Data, pp.109-116 (1988)
[PEI99]
Parviz Peiravi, Norman Stalliviere: "Designing for High Availability: A
Dependable Solution Design for Enterprise and e-Business Applications Using
Oracle8i on Intel Architecture-based Server",
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.202.1581&rep=rep1
&type=pdf (1999)
[QIN03]
Xiao Qin, Hong Jiang, Yifeng Zhu, David R. Swanson: "Dynamic Load
Balancing for I/O-Intensive Tasks on Heterogeneous Clusters", T.M. Pinkston
and V.K. Prasanna (Eds.): HiPC 2003, LNCS 2913, pp.300–309 (2003)
[RAN01]
Gil Rangel, Bruce Bush: "Hitachi Freedom Storage Thunder 9200 Architecture
and Performance Configuration Guidelines",
http://www.availability.com/resource/pdfs/thunder9200_wp_final.pdf (2001)
[RAY12]
Soumya Ray, Ajanta De Sarkar: "Execution Analysis of Load Balancing
Algorithms in Cloud Computing Environment", International Journal on Cloud
Computing: Services and Architecture (IJCCSA), Vol.2, No.5, p.1-13 (2012)
108
参考文献
[RAZ08]
Shay Raz, Raz Lin, Onn Shehory: "Collaborative Load-Balancing in Storage
Networks Using Agent Negotiation", 12th International Workshop, CIA 2008,
Prague, Czech Republic, September 10-12, 2008. Proceedings, pp.306-320
(2008)
[SAK12]
坂下幸徳, 工藤裕, 名倉正剛, 草間隆人: "大規模クラウドデータセンターの
運用管理コスト削減を可能とする IT リソース管理技術", 日立評論 2012
年 4 月号, pp.54-57 (2011)
[SAT99]
佐藤美道，田中成弥，吉田昌司，大辻信也，堀田多加志，田中洋幸: "主
メモリ一体型転写機能を内蔵した高信頼コントローラ用システム制御
LSI", 電子情報通信学会論文誌 D-I，Vol.J82-D-I, No.2, pp.341-349 (1999)
[SAW88]
佐脇康之，加藤 登，栗田養逸，米満順一，宝田光洋: "電力情報パケット
網における二系列方式", 電気学会論文誌 C, 108 巻 11 号 , pp.902-908
(1988)
[SEA10]
Seagate: "SCSI Commands Reference Manual Rev.C",
http://www.seagate.com/staticfiles/support/disc/manuals/Interface%20manual
s/100293068c.pdf (2010)
[SIN08]
Aameek Singh, Madhukar Korupolu, Dushmanta Mohapatra: "Server-Storage
Virtu-alization: Integration and Load Balancing in Data Centers", The
International Conference for High Performance Computing, Networking,
Storage, and Analysis, SC 2008, pp.1-12 (2008)
[SPC15]
Storage
(2015)
[SUK11]
鋤柄力, 熊谷奈緒子: "クラウドコンピューティングを支えるストレージソ
リューション －Hitachi Virtual Storage Platform－", 日立評論 2011 年 7 月
号, pp.44-47 (2011)
[TAK87]
高橋正弘, 浜田卓志, 安元精一, 岡田政和: "分散制御用幹線ネットワークの
伝送制御方式",電気学会論文誌 D, 107 巻 12 号, pp.1455-1460 (1987)
[TAK00]
高橋正弘, 大倉敬規, 濱田卓志: "オンボード分散スイッチによるループ型
ATM-LAN の試作と伝送遅延時間の評価", 電気学会論文誌 C, 120 巻 10 号,
pp.1452-1457 (2000)
[TAK03]
高橋直也, 黒須康雄: "キャッシュメモリと共有メモリをもつディスクアレ
ー の 高 速 化 手 法 ", 電 子 情 報 通 信 学 会 論 文 誌 D-I, Vol.J86-D-I, No.6,
pp.375-388 (2003)
Performance
Council:
109
http://www.storageperformance.org/home/
参考文献
[TAK10]
高橋淳一, 得能貢一, 山田茂: "ソフトウェア信頼度成長を考慮したコンピ
ュータシステムの性能評価モデル", 数理解析研究所講究録 第 1682,
pp.225-232 (2010)
[TAN10]
田中信吾, 山浦隆博: "超高速 TCP/IP 通信ハードウェア処理エンジン
NPEngine™", 東芝レビューVOL.65, No.6, pp.40-43 (2010)
[TOK03]
得能貢一, 山田茂: "不完全デバッグ環境を考慮した間欠的に使用されるソ
フトウェアシステムの可用性解析", 日本ソフトウェア科学会 コンピュ
ータソフトウェア Vol.20, No. 4, pp.321-330 (2003)
[WAN07]
Yaping Wan, Dan Feng, Fang Wang, Bo Mao: "A Framework to Evaluate RAID
Dual Controller Reliability and Performance", ICCIT '07 Proceedings of the
2007 International Conference on Convergence Information Technology,
pp.145-150 (2007)
[WAN08]
Yaping Wan, Dan Feng, Tianming Yang, Ze Deng, Li Liu: "The Adaptive
Heartbeat Design of High Availability RAID Dual-Controller", MUE '08
Proceedings of the 2008 International Conference on Multimedia and
Ubiquitous Engineering, pp.45-50 (2008)
[WAT02]
渡邊 明嗣, 横田 治夫: "負荷均衡化とシステム再構成を統合する データ移
動制御手法", 日本データベース学会 Letters Vol.1, No.1, pp.3-6 (2002)
[XUZ2]
Zhiyong Xu, Yingwu Zhu, Rui Min, Yiming Hu: "Achieving Better Load Balance
in Distributed Storage System", PDPTA '02 Proceedings of the International
Conference on Parallel and Distributed Processing Techniques and Applications
- Volume 3, pp.1314-1322 (2002)
[YAM05a]
山本彰: "高信頼集中ストレージシステム", 日立評論 2005 年 5 月号,
pp.69-74 (2005)
[YAM05b]
山本康友, 兼田泰典, 佐藤雅英: "ストレージシステム技術の最新動向", 日
立評論 2005 年 3 月号, pp.71-74 (2005)
[YUL05]
Wang Yulin, Li Guangjun, Wu Xiaojun, Lin Shuisheng: "A write-prior
partitioning LRU algorithm for the multi-port cache in disk arrays",
Proceedings of the 2005 The Fifth International Conference on Computer and
Information Technology (CIT’05), pp. 322 - 326 (2005)
[ZHI10]
Liu Zhiming, Yang Xiaohua, Sha Jichang, Wan Yaping: "Fault Detection for
high Availability RAID System", In Proceedings of Networked Computing and
Advanced Information Management (NCM), pp.27-32 (2010)
110

All IP Computer Architecture

学籍番号 学年 年 氏名 オペレーティングシステムの構成 (9/24) レポート

BIOS設定を変更する

MX6S/6D/6Q-MX - テラソリューションについて

Express5800/R320c-E4, R320c

ZabbixとAWSの親和性

・仮想デスクトップとは・・・ パソコン本体の内蔵ディスクから OS

1 エラー内容一覧と起因定義

cwww.cs.shinshu

ナノ・アンペア級 倹約OPアンプの使い方