ストレージ・アーキテクトになろう(1)

連載:ストレージ・アーキテクトになろう(5)

統合ストレージ調達のRFPをどう作るか


EMCジャパン株式会社
グローバル・サービス統括本部
マネージド・サービス部 部長
森山 輝彦
2009/2/13

 2. 運用要件

- PR -

■稼働監視、障害監視、性能監視

 統合ストレージ基盤構築完了後に、運用引き継ぎが行われ、IT基盤としての運用フェイズに移行されていきます。後述の管理要件にも類似の項目がありますが、IT基盤の監視業務として、統合ストレージ基盤を対象とした運用形態を検討しておく必要があります。統合ストレージ基盤のほとんどは、前回までの説明でも触れていますが、ベンダによるリモート監視の仕組みが基本です。ただ、ネットワーク・セキュリティ要件により、リモート監視が制限される場合、管理レベルを運用部門として、一定のレベルを確保する目的で、基盤の稼働監視、障害監視などを必要とする場合も多く見られます。これらの要件も、その監視レベルをある程度想定し、RFPに盛り込むことをご検討ください。

 特に、バックアップ業務の障害は、ハードウェア障害を伴わない場合、ベンダのリモート監視の対象にならないことが多いため、監視の仕組みを別途構築することが必要となります。

 性能監視に関しては、性能要件が非常に厳しい環境では検討すべきですが、瞬間的な性能遅延が発生し、アラートを検知した場合の次のアクションが決定できていない場合は、慎重に判断することお勧めします。日次レベルでの性能情報把握で、管理上問題がない程度であれば、監視の仕組みは必要ではないと思います。
過度の監視システム、管理システムの構築は、そのシステムの運用、維持管理まで考慮した場合、決して有用ではない場合があります。

■ジョブ管理

 統合ストレージ基盤でのジョブ管理は、バックアップ業務に代表されます。バックアップ業務のほとんどは、何かしらのジョブとして稼働します。ストレージ・ソリューションを利用した筐体内バックアップなどは、多くの場合、業務サーバ運用との連携でバックアップが起動されるため、スクリプトの組み込みや、バックアップ・サーバとのRPC、エージェント経由などによるジョブ連携となります。

 バックアップ・サーバにより、筐体外にバックアップを取得する場合は、バックアップ・サーバのスケジュール機能を利用する場合、ジョブ管理システムとのジョブ連携をとる場合等が考えられます。

 バックアップ業務の運用イメージを、ストレージ・サービス・カタログのメニューと合わせて検討し、その実現性や、他のより有効な手法などの提案を求めてください。また、実装の際の容易性や制限事項、他社実績、ベンダのサービス範囲なども合わせて確認しておくことをお勧めします。

■障害対応時のエスカレーション、サービスレベルなど

 運用フェイズへの移行後、(アウトソーシング契約でない限り)運用責任は利用者側になります。ストレージ基盤も他のIT基盤と同様、障害はある程度の頻度で発生することは想定しておいてください。当然、単一障害で、実業務へ影響することがないよう、基盤設計、構築がされているはずですが、いわゆる冗長化されている部分も、障害時は冗長化されていない状態になりますので、少しでも早い修復が重要です。

 障害発生〜検知〜障害部位の特定と対応方法の決定〜修復〜確認、の一連の流れが、どのような体制とサービスレベルで実施されるか、自社のサービスレベル要件との乖離はないかを確認できるよう、提案を求めてください。

 実際に障害が発生した場合を想定して、自社要員での対応が必要となる部分を確実にして、運用引き継ぎに盛り込む内容の精査、必要となるトレーニング計画の立案に役立ててください。

■案件対応時の構成変更の役割分担

 統合ストレージ基盤構築時の初期利用分で、その基盤のライフサイクルが完了することは、きわめて稀です。初期構築完了後も、追加のサーバの接続や、容量の拡張などが随時発生することが一般的です。このように、一度、商用化した統合ストレージ基盤に対する構成変更時を想定した、検討もあらかじめ実施しておくことをお勧めいたします。

 すべてベンダに任せることも1つの選択枝ですが、自社内である程度対応することも可能です。昨今では、外注費用の削減が大きく語られておりますので、自社内で対応できる部分は、積極的に対応を検討している企業も多く見られます。

 随時的に発生する構成変更案件に対する取り組み方、役割分担を想定し、必要に応じてトレーニング、OJTなどをベンダから受け、実際に必要となる運用ドキュメントの提示を求めることも重要な検討項目です。

 機能要件に盛り込まれるかもしれませんが、構成変更が発生した場合のリードタイムに関しても、提案要件として盛り込むか、あるいは、構成変更の内容とそのリードタイムの提示を受けることをお勧めします。

■必要となる文書の定義

 運用引き継ぎの際に必要となる文書類の提供を求めてください。サンプルの文書の提示を受ける方法も有効です。

 他のIT基盤の運用で利用している文書をカテゴライズして、それに相当するストレージ基盤運用のための文書の提示を求める方法も良いと思います。

 あらかじめ、必要となる文書の種類と内容(レベル感)を可能な限り、RFPに盛り込み、ベンダ側に調達側の期待値を伝えることが重要です。
もちろん、提案選定のプロセスの中で、不明確な部分に対して、さらなる提示を求めていく形式でも良いと思います。

■想定される内部工数、外注費用

 ストレージ基盤に限りませんが、新たなIT基盤を調達、構築、運用していく際には、ベンダ要員だけではなく、自社要員や、他の外注費用の検討も必要となります。

 ベンダの提案内容を吟味し、自社要員等を検討していく場合が多いですが、あらかじめ、自社で用意できる要員やスキルレベル、運用部門の体制などを明らかにして、それを補完するような提案を求める、もしくは、運用要員、内部プロジェクト要員を含めて提案を求めることも有効な方法の1つです。

2/4

Index
統合ストレージ調達のRFPをどう作るか
  Page1
統合ストレージの調達
1. 機能要件
Page2
2. 運用要件
  Page3
3. 管理要件
  Page4
4. 保守要件
5. プロジェクト要件
6. 運用管理支援要件

Server & Storage フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Server & Storage 記事ランキング

本日 月間