2006年01月

2006年01月26日

SunGardの移動データセンター3

 面白い映像を見つけました。

 SunGardが運用している移動データセンターです。(iPIXプラグインが必要)

 大型トレーラーの中にデータセンターがそっくり収まっていて、災害が発生すると出動するようです。

2006年01月25日

オープンソースの品質2

以前、Linuxのビジネスユースに関して、オープンソースコミュニティーとの品質に関する認識論的切断(!?)について触れましたが、もう少し考えてみました。
私は仕事柄、海外(米国&ヨーロッパ)のソフトウェア開発者を相手にする機会があるのですが、彼らは割といい加減というか良い加減で、再現しないんならいいじゃないかとか、回避できればいいじゃないかとか良く言います。(プロセスの見直しはやって欲しいんですが・・・)

実際、ドイツなんかだと2000年問題の時も、まぁ手を尽くしてダメだったらしょうがないじゃないかというのが社会的コンセンサスになっていて、日本ほどピリピリしてなかったみたいです。
オープンソースコミュニティーの感覚に近いですね。

日本では過剰に品質を求めすぎるのかもしれません。

「ピープルウェア」や「ゆとりの法則」で有名なデマルコも、おととし日本に来た時の講演で過剰な品質は必要ないと言っていました。
「効率化しすぎると、作業が遅くなり変化にも対応できない」とトム・デマルコ氏――“デブサミ2004”開幕
「“早さ”と“クオリティー”の過剰な要求は開発者やその企業をダメにする 」なんだそうです。

デマルコに関しては、こんなブログも御参考。

ただ、ディザスター・リカバリーとか業務継続の分野だとどうなんでしょうね???

2006年01月18日

東証の成長曲線2

14時40分から株式全銘柄の売買停止=東証

 東京証券取引所は18日の14時25分時点で注文件数が700万件程度、約定件数が400万件程度に増加。処理能力の限界に接近したため、14時40分以降、全銘柄の株式やCB、社債などを終日売買停止にすると発表した。(H.K)
[ラジオNIKKEI2006年01月18日]


 これは結果論ですが、近いうちに取引量が処理能力を越えることが見えていたのでしょうから、もっと効果的な手が打てたのではないでしょうか?
 予想以上にネット取引が急増(ホリエモン的には「想定外」?)したとはいえ、見通しが甘かったのかなぁと思います。

 Blueprints for High Availabilityの高可用性設計原理#7が「成長をデザインしろ」でした。(本宅参照)

 CPU、メモリ、I/O、ディスクはいつかは必ず枯渇するし、関連して電源容量や空調の容量も増やす必要が出てきます。そして、もしかしたらデータセンターも。
 システムを設計する時のゆとりや将来のスケーラビリティーを考えさせる事例です。

2006年01月13日

高可用性、DR/BCに関連する法律

 最近、あちこちで日本版SOX法の話題で盛り上がっているが、当然SOX法以前にもITシステムに関係してくる法律は存在する。
 "Blueprints for High Availability(BHA)"でも、可用性やディザスター・リカバリーに関連するいくつかの法律を挙げている。

(ちなみに、SOX法とは法案を提出した二人の議員の名前であるSarbanes-Oxley actの略で、正式には「Public Company Accounting Reform and Investor Protection Act of 2002: 上場企業会計改革及び投資家保護法」という長ったらしい名前の法律だ。)

  1. 1996年の健康保険ポータビリティー・アカウンタビリティー法(HIPAA)

     この法律はセキュリティーの話題で引き合いに出されることが多いが、患者のプライバシー権及び患者、手続き、保険記録に関連するデータの格納、管理、保護の方法について、患者のプライバシーとデータ保有に特別の注意を払うように求めている。

  2. 1977年の海外腐敗行為防止法(Foreign Corrupt Practices Act of 1977: FCPA)

     この法律は、ロッキード事件のような外国の公務員への贈賄の禁止で有名。
     BHAでは、この法律で「正式なDR計画を持つことを要求している」とある。
     下の参考サイトでは「株式公開会社は情報システムに対し適切な保護をする責任がある」となってます。
    (DRについて、どこまで具体的に規定されているのか、詳細は法律の原文を読んでいないので不詳→調査中)

  3. 1934年の証券及び取引所法

    公開会社とその監査法人はすべての記録を最低7年間保管しなければならないことなどが規定されている。
    当然、データがハードディスクにあろうが災害に遭おうが斟酌してくれるはずもない。

  4. 内国税収入庁(IRS)規則71-20

    法人税の記録はそれらが関連している限り保管されなければならないと規定している。
    なお、IRS規則86-19では税務上のデータのバックアップ・リカバリーについて規定している。


参考:DR/BCに関連する法律

 これらはアメリカでの話ですが、日本で言えば1977年告示の「電子計算機 システム安全対策基準」なんかがあります。正直言って余り詳しくないので識者の方におまかせします。

2006年01月11日

ディザスター・リカバリーと業務継続の違い???2

 ちょっとググっていたら、ITマネージメントについて解説しているIT Management Reference Guideというのを見つけた。
 当然のようにBusiness Continuity Managementという章もあるわけだが、その中でディザスター・リカバリーと業務継続の違い(Differences Between Disaster Recovery and Business Continuity)を語っていたりして興味深い。

 英語ですが、興味がある人は御覧あれ。

ちなみに、両者の違いを簡単な表にすると、こんな感じになるそうです。
(ちょっと一面的という気もしないではないですが)

カテゴリDRBC
重要視されるエリアデータセンター企業
アプローチ反応順応
志向テクノロジービジネス
起源70年代90年代
顧客の関わり合い最小広範囲
サポートグループの種類多様
関与するユーザの数
主要なメトリクスMTBF/MTTRRPO/PTO
マネージメントスタイル独裁的協力的
主導する重役CFO/CIOCEO/CRO
監督する管理者オペレーション・マネージャービジネス・コンティニュティー・マネージャー
認証補助的多数
キャリア・パッシング限定的広い


『クラスタ』という名称4

 さて、よく使われている用語だが、単に「クラスタ」といっても、目的・形態によっていくつかに分類される。キャリアグレードLinuxの仕様書では以下の4種類に分類している。

1.High Availability Cluster (HAC)
2.Scalability Cluster
3.Server Consolidation Cluster
4.High Performance Computing (HPC) Cluster

1.が、単に「クラスタ」と言った場合、一番よく使われている高可用クラスタだ。2.はOracle10g RACなどの並列クラスタ、4.が科学技術計算などで使われる大規模並列クラスタ。3.は少し毛色が変わっているが、複数のノードをあたかも1台のノードであるかのように扱うことができる仮想化だ。

 「高可用クラスタ」を実現するソフトの名称だが、「クラスタ・ソフト」「クラスタリング・ソフトウェア」などと呼ばれている。新しもの好きでキャッチーな名称が好きで本質はどうでもいいと考える人たちは「クラスタウェア」などという酷い呼び方すらする。

 "Blueprints for High Availability"の著者達は、そういう名前を好まない。
「クラスタ」という名称が長年の間にマーケッティング部門によって酷使され、クラスタリング・ソフトウェアをインストールさえすれば、すぐに「高可用性」が実現でき、「ファイブ・ナイン」が達成できるかのようなセールス・トークが蔓延していると考えているからだ。

 彼らは、それを単に「フェールオーバー管理ソフトウェア(FMS: Failover Management Software)」と呼んでいる。
 つまりは、「可用性」とはすぐに結びつかない無味乾燥な純粋に技術的な言葉を使うことで、単にフェールオーバーを管理するソフトに過ぎませんよ。その他のたくさんのことをやらなければ高可用性は達成できませんよ。と言ってるわけだ。

(何しろ、"Blueprints for High Availability"のミッション・ステートメントは、「クラスタリング・ソフトウェアをインストールし設定しただけでは、高可用性は実現できない」だそうだから。)

 ちなみに、SAフォーラムの仕様書で「可用性管理フレームワーク(Availability Management Framework)」と呼ばれている実体が、FMSに相当する。
 この言葉も技術的に中立で、機能を端的に表している。

2006年01月05日

高可用性に関する書籍、『Blueprints for High Availability』5

 今までキチンとした紹介をしてなかったので、あらためて『Blueprints for High Availability』という本を紹介したい。

 以下は、Amazonのレビューに書いた文章だが、少し大げさに書いているものの、恐らく可用性について書かれた現在最も優れた本であることは確かだ。
 著者達は、ベリタスのEvan MarcusとSun MicrosystemsのHal Sternという人だが、別に自社製品の解説や宣伝ではない。固有の製品名も出てくるが、どのベンダーであれ推奨するわけではなく、あくまで公平に、現在入手可能なソリューションの一つとして出てくるだけだ。
 残念ながら邦訳は出ていないが、平易な文章で書かれているので、それほど難しくはないと思う。
 もう少し詳しい紹介と、部分訳は本宅を参照して欲しい。


 この本は、高可用性とディザスターリカバリーについて書かれた、もっとも包括的で優れた本だ。高可用性やディザスターリカバリーとは何か、そしてシステムを高可用に設計し、高可用に維持するためには何を考えなければならないか、この本一冊で学ぶことができる。
 また、社会システムほど可用性が求められないシステムであっても、限られた費用と資源の中で可用性を最大にしなければならないのも事実だ。つまり、どんなシステムであれ、システムを設計しインプリメントし運用するすべての人は、この本から多くのことを学ぶことができるだろう。
 第二版で追加されたニューヨーク商品取引所(NYBOT)の物語は感動的ですらある。NYBOTは9.11のテロで壊滅的な被害を受けたにも関わらず、8時間後にはディザスター・リカバリーが完了した。そこにあるのは、必要なものは単なる技術ではなく、準備、考え方、注意、細部への気配りであり、そして何よりも重要なのはシステムを高可用に保とうという強い意志だということだ。
 この本を貫いているのは、いかに高可用を実現するか、ITシステムを構築する人間が本当に考えなければならないのは何か、という哲学だ。


Blueprints for High Availability
Evan Marcus, Hal Stern 著
Publisher: John Wiley & Sons Inc
ISBN: 0471430269

2006年01月04日

Linuxと高可用性〜ダンプが必要なOSを作った覚えはない〜3

 Linuxと高可用性というのも、本質的に相容れない物のような気がしている。

 こちらの記事「ダンプが必要なOSを作った覚えはない」を読んで頂きたい。

 もちろん、ダンプ機能はキャリアグレードLinuxでも色々な要件があがっているビジネス・ユースでは必須の機能だが、正直これがオープンソース・コミュニティーの本音だろう。

 実際、自分のPCの調子が悪くなっても、それが回避さえできれば根本的な原因が何であるかは二の次だ。例えば、ソフトをインストールし直して問題なく動けば、根本原因を探ることなど詮なきこと、時間の無駄ですらあるかもしれない。

 しかし、ビジネスの世界ではそうも言っていられない。不具合の原因が何なのか徹底的に究明して、必要ならば対策を取るのが当たり前だ。それが、ビジネスのプロセスというものだからだ。

 このプロセスの違い、根本的な行動原理の差が、たとえLinuxをビジネスに使うメリットがデメリットを上回るとしても、どうも引っかかるのである。