http://blogs.sun.com/fukumoto/date/20061109 2006年 11月 09日 木曜日

「Sun BC/DR Solution」トレーニング(続)


昨日は、Sun Cluster Geographic EditionとTrueCopyを
利用した「Sun BC/DR Solution」のトレーニングに参加した
お話を書きました。

後で思い出したのですが、そのトレーニングの中で、
災害発生でプライマリサイトが運用停止になった場合の
「セカンダリ・サイトでの速やかなサービス復旧」の指標の紹介
がありました。2つあります。

■高レベルな「目標復旧時間」の実現

 この「目標復旧時間」のことを、RTO、すなわち
  Recovery Time Objectiveといいます。
 これは、災害発生時に、どの程度の時間でサービス復旧を官僚させるか?
 という「目標値」。

 これには、整合性がとれたデータのすみやかな復元や、
 スタンバイサーバへのすみやかなプロセス・フェイルオーバー、
 さらに、クライアント(端末)からのすみやかなアクセスの復旧があげられます。

■高レベルな「目標復旧時点」の実現

 この「目標復旧時点」のことを、RPO、すなわち、
 Recovery Point Objectiveといいます。
 これは、災害発生時点から、どのくらい前の時点(どのくらい最新の)
 データを復元するか、という「目標値」。

 これは、可能な限り最新データを利用できる環境として復旧
 させることが望ましいといえます。


これら2つの指標、RTOとRPOを縦軸、横軸にスケールさせて、
どのくらいのビジネスインパクトがあり、どのくらいの
災害対策システムが必要なのか、を検討する図を描くことができます。

たとえば、ビジネス再開不可なのか、とか、データ保護重視対応なのか?
とか、サービス復旧重視なのか、とか、などさまざまな観点をプロットする
ことができます。

ところで、後から知ったのですが、この考え方は、コンサルティング会社
KPMGが、開発した指標のようです。

KPMG社のビジネスキーワードに詳しく掲載されています、と
いうことを、じっさいは、後で知りました。勉強不足です。



Posted by fukumoto [Solaris / Sun Plex] ( 11月 09, 2006 12:33 午後 ) Permalink

■ 「Sun BC/DR ソリューション」トレーニング


先日、サンがプレスしました、「Sun BC/DR ソリューション」(*1)の
トレーニングに、神宮前の旧STKオフィスのあるビル(*2)へ行ってきました。

正直に白状すると、私は、神宮前のオフィスへ行くのは今回が初めてで、
内心、用賀とか溜池山王でなく、神宮前オフィスを見てみたいという思いも
ありました。

(*1) サン、ディザスタリカバリーシステム構築ソリューション「Sun BC/DR ソリューション」を提供開始(10/10/2006)

(*2)神宮前オフィス

実際行ってみると、なんと、昔、私は別の会社にいたとき、このあたりにある
某お客様の新規にオープンするディーリングルームのシステムのインストールを
しに足しげく通った覚えのある場所でしたので、駅をあがって地上へ出たときには
とってもなつかしい感じがしました。

それはさておき。

さて、Sun BC/DRソリューションのトレーニングに参加の件です。

プレスにもありますように、コンプライアンスや、事業継続性(以下 BC,Business Continuity)、
広義の情報セキュリティという観点から見れば、ディザスター・リカバリー対策は必須のものに
なりつつあります。

そんな機運の中、サンも、かなり以前から、Solarisサーバ、Sun Clusterと、Sun StorageTek 9900シリーズ
などを用いて、サイト内クラスターから、キャンパス・クラスター、都市間メトロ
クラスターなどのソリューションを提案していました。

これらを実現するのは、基本的には、サイト間の距離によらず、ソフトウエアアーキテクチャと
しては、あくまでもノードが任意の距離に離れたSun  Clusterが稼動する環境という
位置づけでした。

ただ、たとえば、東京サイトと、ニューヨークサイトなど、地球レベルでのサイト間
のディザスターリカバリー(以下DR)には、既存のSun Cluster環境以上のソリューション
が必要となります。そんな中、Sun Cluster Geographic Edition 3.1が昨年リリース
されました。

Sun Cluster Geographic Edition 3.1は、Sun Cluster 3.1で構築されたクラスター
システムの上にplugin/addonするソフトウエアで、サイト間の距離は無制限です。
たとえば、東京のデータセンターに、2ノードのSolaris/Sun Clusterのシステム、
ロンドンにも同じ構成のクラスターシステムがあるとします。

このとき、東京をプライマリ、ロンドンのシステムをセカンダリとすると
した場合に、両方に、Sun Cluster Geographic Edition 3.1をinstall、構成し、
DR関係にする、というソリューションになります。

また、データ保護、データ複製は、基本的には、ST99xxのTrueCopyを使用し、
システム間で、同期/非同期にデータ複製を行うことができます。

特徴は、Sun Couster Geo Editionに、TrueCopyでデータ複製させたいデータ
の「塊」や、サービスを登録し事前に構成することによって、万が一
プライマリシステム(サイト)に災害が発生し、セカンダリサイトを
プライマリサイトとして、サービス、ビジネスを継続させる事態に陥った場合には、
手動ではありますが、プロセスの切り替えとデータ複製、切り替えを、効果的に
行うことができる点にあります。全部をマニュアルでやれば、ヒューマンエラー
が発生し、あらかじめ莫大なコストをかけて構築しておいた、DRのインフラサイト
も、無駄になる、というような泣けないリスクを最小限にすることができるはずです。

今回のトレーニングは、サン社内の各部署が連携し、フェーズ1として、
Sun Cluter Geographic Editionと、Sun StorageTek 9900 および遠隔データ複製
技術、ソリューションである、TrueCopy、それに、McDate Eclipse SAN Expander環境を
用いて、株式会社TOKAI様のご協力の下実証実験を行った成果です。

個人的には、ソリューションという観点からも、ビジネスの観点からも、また、
技術的な点でも、興味のあるソリューションでした。

今回、トレーニングに参加して、サン・サービスのサポートメニューや、
サン・プロフェッショナル・サービスのコンサルティングメニューも交えて、
総合的に提案、構築支援が可能なBC/DRソリューション・パッケージであることを
理解できて、今後のフェーズ2の進展が楽しみです。





Posted by fukumoto [Solaris / Sun Plex] ( 11月 09, 2006 12:07 午前 ) Permalink
http://blogs.sun.com/fukumoto/date/20061101 2006年 11月 01日 水曜日

「会社がやるなといってもオレはやる」~x86版Solarisを救った男


publishした後、http://blogs.sun.com を見ると
あ、大曽根さんがすでに書かれていましたね。
失礼しました。

[もっと読む]

Posted by fukumoto [Solaris / Sun Plex] ( 11月 01, 2006 03:34 午後 ) Permalink
http://blogs.sun.com/fukumoto/date/20050603 2005年 6月 03日 金曜日

"Linux World Expo 2005 Tokyo" (6/1-3)


なんか、行ってないんですよね。今日まで、東京ビッグサイトで。
本来は見に行くべきなんでしょうけどね・・・体調がね・・・。いいわけ。

でも、さっすが、ネット社会です。いけない方への力強い見方。

行けない人もこれで安心——LinuxWorldフォトリポート Vol.1

行けない人もこれで安心——LinuxWorldフォトリポート Vol.2

うんうん。これをみれば、腰痛もちの私でも、行った気になれますね。よかったよかった。



Posted by fukumoto [Solaris / Sun Plex] ( 6月 03, 2005 10:57 午前 ) Permalink | 投稿されたコメント[0]