2005年12月14日

高可用性とバックアップ

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

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

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

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

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

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

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

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

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


kxa00121 at 15:28|PermalinkComments(0)TrackBack(0) バックアップ | Blueprints for High Availability

2005年12月01日

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

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

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

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

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

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

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


kxa00121 at 18:44|PermalinkComments(0)TrackBack(0) Tales from the Field | Blueprints for High Availability

2005年11月22日

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

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

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

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

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

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

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

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

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

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

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

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


 11章では、さらに

  • データの暗号化

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

  • パスワードの保護

  • 監査機能の使用

  • パスワードの預託


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

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


kxa00121 at 22:30|PermalinkComments(0) セキュリティー | Blueprints for High Availability

2005年11月21日

技術者スキルとしての高可用性

 こんなサイトが目に付いた。

■情報サービス業界の各職種×レベルに求められる経験/スキル

 この中で、技術者に必要なスキルの一つとして『高可用性』を上げている。
 世間的にだいぶ認知されるようになって、企業ニーズもあるということでしょう。

 ただ、カテゴリーが「複雑性」の所になっているのは、いかがなものでしょうか?
 しごく単純なもののような気もするのですが。

 もっとも、低可用なシステムに比べれば、クラスターにしたり冗長化したりして、相対的に複雑なことは確かですが。


kxa00121 at 12:35|PermalinkComments(0)TrackBack(0)

2005年11月20日

ITpro:名証システム障害、原因は外注先オペレータの“操作ミス”(ヨミウリの記事はガセでした)

 先日の名証のトラブルの原因は、どうも単純なパスワード入力ミスとかじゃないみたいだ。(ヨミウリの記事はガセでした)

 詳しくはITproの記事参照。

ITpro:名証システム障害、原因は外注先オペレータの“操作ミス”

 キャンセルって、CTL-Cですかね?
 Oracleって、コマンドが中断されてもロールバックしてくれないの?
 Oracle始め、今どきのミドルウェアはパラメータ設定ミスとかあっても、ほとんどノーチェックで突っ走りますからね。しかも、原因が容易に特定できるようなエラーメッセージは絶対に出力しないし。

 運用する側にも問題があったみたいだけど、もっと人に優しいソフトにしてくれないと、ヒューマン・エラーはなくなりません。(これをヒューマン・エラーと言うのなら。ですけど)


kxa00121 at 16:06|PermalinkComments(0)TrackBack(0) ニュース 

2005年11月19日

可用性とセキュリティ

 名古屋証券取引所で11/4にシステムが起動できなかった件も、人為ミスが原因のようだ。

富士通がまた原因、陳謝

 名古屋証券取引所で4日午前の取引を停止させたシステム障害は、システム管理を委託されている富士通の関連会社社員が前々日にシステムの終了処理をした際、パスワードの入力を誤ったことが原因とわかった。(YOMIURI ONLINE)

 セキュリティも、やりすぎは考え物ということか?
 いや、人間が誰しもがミスを犯すものと考え、あらゆる自体が起こり得ると想定していれば、こんなことにはならなかっただろう。

 パスワードを変えた後の変更手順はどうなっていたか?
 次回にシステムを立ち上げる人が立ち会わなくて良かったのか?
 パスワードが分からなくて起動できない場合の対処方法は考えてあったのか?

教訓:何も仮定するな


kxa00121 at 10:11|PermalinkComments(0)TrackBack(0) ニュース | セキュリティー

2005年11月16日

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

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

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

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

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


kxa00121 at 12:03|PermalinkComments(0)TrackBack(0) Tales from the Field | Blueprints for High Availability

2005年11月12日

冗長化の一つの方法

 東証のニュースについて、同じソフトを二重化するだけではなく、異なったソフトを用意する方法について触れた。
 この「多様化」が可用性を高める上では有効だ。

 こちらの記事(米人気サイトでアクセス障害」,その真相は?)を読んで頂きたいが、DNSの階層のもっともトップにあるルート・サーバが世界には13台あるそうだが、どのように冗長化されているかの一端が知れて興味深い。続きを読む

kxa00121 at 10:24|PermalinkComments(0)TrackBack(0) ニュース 

2005年11月10日

「ソフトは二重化できない」?????

「ソフトは二重化できない」――東証の取引停止、原因はプログラムミス

 東証のシステムは、ハードを二重化してバックアップ体制を整えているが、ソフトは富士通に委託して構築した独自仕様品。「ソフトのバックアップを整えることは、現実的には不可能」(天野富夫常務取締役)。今後はテスト態勢を見直し、チェックを厳重にするなどして障害を防ぐとした。

 「ソフトは二重化できない」と言っているのが何を言おうとしているのか良く分かりませんね。何か誤解を招く表現だし。
続きを読む

kxa00121 at 22:12|PermalinkComments(0)TrackBack(0) ニュース 

意外なところにあったNTT Comの「単一故障点」

意外なところにあったNTT Comの「単一の障害点」

NTTコミュニケーションズのネットワーク障害は、分電盤の故障が原因。電源系統については十分な冗長化を図っていたが、障害が起きたのはそれ以外の部分だった。

 大分前の話ですが、こんな話もありました。
 単一故障点を無くすのがいかに難しいかの実例です。
(もっとも、この例はそれほど難しくないような気もしますが・・・)


kxa00121 at 21:56|PermalinkComments(0)TrackBack(0) ニュース 

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

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

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

kxa00121 at 11:30|PermalinkComments(0)TrackBack(0) Tales from the Field | Blueprints for High Availability

Tales from the Field5

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


kxa00121 at 10:52|PermalinkComments(0)TrackBack(0) Tales from the Field | Blueprints for High Availability

2005年11月04日

ディザスター・リカバリー以前

 今週は立て続けに社会システムがダウンしました。
 詳細はまだ明らかになっていないものの、テスト不足やら運用方法の問題など基本的なところができていないとしか思えません。
 これでは、DRどころの話じゃないですね。まずは可用性というものを勉強し直した方がいいのでは?

名証でもシステム障害、午前の取引中止

 名古屋証券取引所で11月4日、相場報道システムに障害が発生し、午前の市場取引が中止された。障害の原因は不明だが、その後システムは復旧し、午後の取引は通常通り12時30分から行われる予定。

東証、システム障害で株売買停止

 東京証券取引所で11月1日、システム障害が発生し、午前9時から株式の全銘柄、転換社債型新株予約権付き社債全銘柄、交換社債全銘柄の立会取引を一時停止している。復旧のめどは立っていない。

kxa00121 at 12:43|PermalinkComments(0)TrackBack(0) ニュース 

2005年10月18日

テストの重要性3

このブログにもRSSを貼ってある上野さんのブログ、今回は「テストの重要性」です。
私は元々テスト部門の人間なので、「テストは重要だ」と言ってくれる人がいると何だか嬉しくなります。
中身は少しあっさり気味ですが、Blueprints for High Availabilityという本に書かれている基本原理で言うと、
「#19 何も仮定するな」
「#10 すべてをテストしろ」
という事でしょうか。
Blueprints for High Availabilityの詳細については、本宅を参照してください。(まだまだ工事中ですが)

それにしても共用のDRサイトというのは、どんなもんなんでしょうね?
SunGuardの共用サイトも災害時には早い者勝ちになるので、キャパが溢れるような大きめの自然災害が発生すると確実にリカバリーできる保証はなくなります。
まぁ、自社のデータセンターだけが火事で失われた場合などには有効なのでしょうが・・・


kxa00121 at 23:41|PermalinkComments(2)TrackBack(0)

2005年09月28日

9.11同時多発テロ

kxa00121 at 16:24|PermalinkComments(0)TrackBack(0) 実例に見るディザスター・リカバリー 

【新潟県中越地震】被災企業に聞いたディザスタ・リカバリの実際

【新潟県中越地震】被災企業に聞いたディザスタ・リカバリの実際

少し古くなるが、新潟中越地震の話題から。


kxa00121 at 14:13|PermalinkComments(0)TrackBack(0) 実例に見るディザスター・リカバリー 

『カトリーナ』におけるディザスター・リカバリー3

「カトリーナ」で被災したITシステムの復旧――ホテルの場合

カトリーナについては発生から日が浅いため、ディザスター・リカバリーに関する情報(どのようにディザスター・リカバリーしたか、あるいは出来なかったか)がまだ少ない。
以下の記事は、ディザスター・リカバリーの当事者以外が災害に当たって貢献できる方法の一例だ。

『カトリーナ』被災者救援でネットが活躍
LUGのボランティアがカトリーナの惨禍に見たもの



kxa00121 at 14:10|PermalinkComments(0)TrackBack(0) 実例に見るディザスター・リカバリー 

「直下型」でも行政・金融機能維持を…地震対策大綱2

「直下型」でも行政・金融機能維持を…地震対策大綱

 大綱は、維持すべき首都中枢機能として、国会や主要行政機関のほか、日銀や都市銀行などを挙げた。行政機関は、建物の耐震化や非常用電源、食糧などの備蓄を進め、「地震発生後3日間程度は外部の援助なしで機能すること」を目標とした。金融機関はデータを支店と重複させるなどして機能を維持し、国際的な信用不安を避けるため、決済システムは24時間以内に回復させる必要があるとした。

24時間では遅すぎる。せめて12時間位を目標にして欲しい。
ちなみに24時間に触れた報道は読売のみ。



kxa00121 at 09:26|PermalinkComments(0)TrackBack(0) ニュース 

2005年05月16日

エスティアという迷惑電話ばかりする会社

 今年に入ってから、エスティアとかいう会社から、マンション購入の勧誘電話がしつこくかかってきて非常に迷惑している。
 あまりに迷惑しているので、本題の邪魔にならない程度に文句を書いておく。

 このエスティアの営業の人、断っても断ってもしつこくかかってくる。いちおうモロ法律に触れるのを避けるため、直接商品の説明はせず、税金対策の話をしたいとか遠回しに言ってくる。
(それでも、これは宅建業法違反である。)

 しかも、電話の最初から、いきなり面会の場所の段取りの話になってる。「俺がいつあんたと会うって言ったよ?あんた、バカぁ?」という感じでバカ丸出しなんだが、しつこい。バカの唯一の取り柄はしつこいことかも知れない。
 迷惑電話されて買うはずもないのにしつこくかけてくるのは、恐らくマニュアルにそう書いてあるからだが、マニュアルを鵜呑みにして何度も迷惑電話してくるほど頭が悪いということだ。

 一体、こういう会社に勤めてるのはバカ以外にいるのだろうか?他の職に付けないほど頭悪い人たちか、犯罪性向のある人たちとしか思えない。
 心ある社員たちには、すぐにこんな会社やめて欲しいものである。
(そうすると、他人に迷惑をかけても心が痛まない犯罪者だけの会社になっちゃうんだが)

 そもそも、今どき高価な新築マンションを賃貸用に買ってペイするはずがない。この商売、テレアポしまくって月に数人カモを見つければペイするのだから、どれだけ暴利を貪っているか知れたものではない。
 悪質リフォームと一緒で、余りものを知らない人とか、お年寄りを騙しているのに違いない。
 ちなみに、必ず利益が出るようなことを言って不動産を買わせるのも宅建業法違反である。懲役刑である。

と、こんなサイトを見つけたので紹介しておく。(電話番の憂鬱


kxa00121 at 12:40|PermalinkComments(0)