Blueprints for High Availability

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日

『クラスタ』という名称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

2005年12月14日

高可用性とバックアップ

 可用性にとってバックアップの持つ意味は重要だ。

 まず、故障のライフサイクルは以下のように考えられる。

故障発生(t1)→停止→切替え(t2)→デグレード状態→復旧のための停止(t3)→定常状態への復旧(t4)

この故障発生から定常状態までが一つのライフサイクルだが、実は停止時間はもっと長くなりうる。データが復旧出来なかった場合、バックアップからデータをリストアしなければならない。

 つまり、停止時間とは、故障が発生してから通常の状態に復旧するまでの時間ではなく、最後にバックアップした時(t0)から通常の状態に復旧するまでの時間となる。

最新バックアップ(t0)→故障発生(t1)→停止→切替え(t2)→デグレード状態→復旧のための停止(t3)→定常状態への復旧(t4)

 たとえハードウェアRAIDのレプリケーション機能などを使っていたとしても、重要なデータが失われる可能性は常にあり、バックアップは最後の防衛線となる。

 バックアップが企業の生き残りにとって極めて重要であるにもかかわらず、システムを設計する際には後回しにされがちだ。その結果、バックアップ用に専用ネットワークが必要になっても、PCIスロットに空きがないなどという馬鹿げた話になることすらある。

 バックアップにまつわる話も少し紹介していくことにする。

2005年12月01日

データセンターラックと高可用性

 データセンターの環境をめぐる実話から二題

 (今どきいないとは思うが)あるユーザーでは、クラスタを構成する二台のマシンのキャスターを外して縦に重ねて設置していた。
 下のマシンが故障して交換しなければならなくなった時、注意深く上のマシンを持ち上げたが、LANケーブルが外れ業務が停止してしまった。

 スペースを節約したいなら、当然きちんとしたラックマウント型のマシンを購入し、ちゃんとラックに格納するべきだ。

 別のユーザーでは、ちゃんとラックに格納していたが、故障が発生してシステムボードを交換する必要が生じた時、マシンの背面の扉を開けるだけのスペースがなく、結局マシンを停めて移動するしかなかった。

 マシンを設置する時には、取扱説明書などに書かれている保守エリアをちゃんと確保する必要がある。
 スペースのコストも馬鹿にならないし、マシンの設置スペースが足りなくなっても、すぐには広げて貰えないので、ついつい狭い空間に詰め込んでしまいがちだが、重要なシステムであるのなら十分な保守エリアを確保するべきだ。

 故障した時以外でも、十分なスペースを空けておかないと、通行人がケーブルを引っかけたり、思わぬ事故を招きやすい。

2005年11月22日

可用性とセキュリティ(2)

 名証の記事のタイトルを「可用性とセキュリティ」としたが、少しばかり羊頭狗肉気味だったので、少し"Blueprints for High Availability"という本の中でセキュリティに触れている箇所を紹介したい。

 高可用性設計原理の#17が「セキュリティの強化」になっている。内容は以下のようなもので、詳細はこの場では省略するが、それほど目新しいものではない。
 可用性というものは結局つまらないように思える小さな注意の積み重ねで達成されるものなのだ。

  • 不必要なユーザーのアカウントは削除する。

  • 特権ユーザーを制限する。また、ログを取る。

  • ファイアウォールを使う

  • 適切なパスワードを選ぶ

  • デフォルトのパスワードは使わない

  • 基本的なセキュリティーについてユーザーを教育する

  • 退職した従業員のアカウント/ファイルを削除する

  • ウィルスチェックソフトを使う

  • www.cert.orgのようなウェブをチェックする


 11章では、さらに

  • データの暗号化

  • パスワードの覚えやすく破られにくい選択方法

  • パスワードの保護

  • 監査機能の使用

  • パスワードの預託


 を上げ、ディザスター・リカバリー計画の文書のセキュリティーや、アクセス性とセキュリティーのバランスについて言及している。

 ウィルスやワームは、業務継続に対する脅威としては自然災害に匹敵する。むしろ、大きな地震のように何十年・何百年に1度しか襲ってこない自然災害よりも、セキュリティが甘かったらほぼ確実に被害を受けるという点で、脅威として大きいのではないだろうか。

2005年11月16日

高可用性と単一故障点をめぐる実例(その2)

 引き続き、高可用性と単一故障点をめぐる話題。

 あるユーザでは、停電に備えて二つの電力会社から電力を引いていた。
(これは、電力が自由化されているアメリカではよくある対策みたいだ。日本でもできる?)
 ただ、電線は建物の直前にある1本の同じ電柱を共用し、建物に引き込まれていた。理論上は、その電柱は単一故障点に相当するが、誰も気にはしなかった。
 ある日、そのまさかが起きてしまった。
 建物の近くの道路で交通事故が起り、衝突した車が「その」電柱をなぎ倒したのだ。

 あるユーザでは、停電に備えて*最新式のガスタービン発電機を屋上に備え付けていた。ある日、停電が起きたので管理者たちは屋上までせっせと階段を上って行った。(停電なので当然エレベーターは使えない)
 そして、いざ発電機を動かそうとした時、ある重大なことに気が付いた。
 なんと、ガスタービン発電機用のジェット燃料を誰も買っていなかったのだ。
 この話の教訓は、「何も仮定するな。すべてをテストしろ」でもある。実際にテストし、訓練していたなら、燃料がないことにすぐ気が付いただろう。

*)なぜか、この種の実例には停電・電力がらみの話題が多い。コンピュータ関連機器を除けば一番起りやすいからだろうか?
 恥ずかしながら、私のいる部門のメールサーバーの電源も、つい最近まで二重化されていなかった。何千人かの従業員が利用しているサーバーであるにも関わらずだ。
 あなたの会社は大丈夫ですか?

2005年11月10日

SPOF(Single Point Of Failure)−単一故障点4

 SPOF=Single Point Of Failureは日本語で何と言ったらいいだろう?
 「単一故障」では故障のことを言っているようだし「Point」であることが分からない。自分は「単一故障点」と訳しているのだが、どうでしょうか?

 さて、システムの可用性を高める上で、最も重要で最も分かりやすい一つが、「単一故障点を無くす」ということだ。つまり、あらゆるハード、あらゆるソフトを二重化・冗長化して、一つが故障しても業務が継続できるようにしなければならない。
続きを読む

Tales from the Field5

 Blueprints for High Availabilityという本には、Tales from the Fieldという囲み記事がたくさん載っている。経験豊富な二人の著者が実際に経験したり、見聞きした話だが、ためになる話、面白い話が多いのでいくつか紹介していくことにします。
 記事のカテゴリーが「Tales from the Field」となっているのがそうです。