2013年12月31日
このブログについて
このブログは高可用性、ディザスター・リカバリー、業務継続、クラスタなどの高可用ソフトウェアについて、ニュースなどのインターネットリソースをブログ形式で提供するものです。
個々の体系だった情報は、本宅のウェブサイトで公開する予定です。(まだ工事中ですが…)
本宅のサイトマップは以下のようになっています。
続きを読む
個々の体系だった情報は、本宅のウェブサイトで公開する予定です。(まだ工事中ですが…)
本宅のサイトマップは以下のようになっています。
続きを読む
kxa00121 at 21:12|Permalink│Comments(1)│
2011年03月31日
東北関東大震災
大震災から3週間が過ぎました。
余りにショッキングな出来事で、ディザスターリカバリーに思いを致す余裕もありませんが、教訓や事例などの情報が入ってきたら紹介しましょう。
ITよりも福島原発の各設備の冗長性や災害対策がどうなっていたのか気になりますね。
被災した場合の影響が直接人命に関わる施設なので、安全係数は最大限に取られていたと思いますが。
こればかりはコストと効果のトレードオフではなく、十分な安全を確保した上でコストがかかるならそのコストを受容すべき場合もあるのです。
余りにショッキングな出来事で、ディザスターリカバリーに思いを致す余裕もありませんが、教訓や事例などの情報が入ってきたら紹介しましょう。
ITよりも福島原発の各設備の冗長性や災害対策がどうなっていたのか気になりますね。
被災した場合の影響が直接人命に関わる施設なので、安全係数は最大限に取られていたと思いますが。
こればかりはコストと効果のトレードオフではなく、十分な安全を確保した上でコストがかかるならそのコストを受容すべき場合もあるのです。
2006年12月04日
セキュリティー パスワード管理
Blueprints for High Availabilityにも書かれていたが、セキュリティー上、パスワード管理がけっこう重要だったりする。
IT Mediaの記事から二題。
安易なパスワードのトップ10(英国の場合)
優れたパスワードの選定と記憶法
Blueprints for High Availabilityの中にも、適切なパスワードの選び方について書かれているので御参考に。
IT Mediaの記事から二題。
安易なパスワードのトップ10(英国の場合)
優れたパスワードの選定と記憶法
Blueprints for High Availabilityの中にも、適切なパスワードの選び方について書かれているので御参考に。
2006年11月28日
アイデンティティ管理ツール
キーマンズネットの記事から、
【1】退職社員の亡霊IDを退治せよ!「アイデンティティ管理ツール」
…製品購入ウラづけガイド
だそうです。
『Blueprints for High Avalilability』にも、退社した社員のアカウント管理について書かれていましたが、こういうツールも出ているんですね。
このサーバー自身がSPOFにならないようにご注意を。
【1】退職社員の亡霊IDを退治せよ!「アイデンティティ管理ツール」
…製品購入ウラづけガイド
だそうです。
『Blueprints for High Avalilability』にも、退社した社員のアカウント管理について書かれていましたが、こういうツールも出ているんですね。
このサーバー自身がSPOFにならないようにご注意を。
2006年11月09日
連邦政府における業務継続性確保の取り組み
NTTデータの
米国マンスリーニュース 2005年8月号
連邦政府における業務継続性確保の取り組み
政府のビジネス継続計画「COOP」
災害やテロ攻撃など、緊急時にも政府業務やITシステムの稼動を継続させるためには、ビジネス継続計画(BCP: Business Continuity Plan)の存在が欠かせない。米国政府では、BCPを業務継続計画(Continuity of Operations: COOP)と呼ぶことが多い。政府関係者は、いかなる危機的状況においても政府の主要業務が停止することがないよう、業務継続計画の作成、状況変化などに合わせた見直し、そして計画が実行可能であるかどうかのテストを実施する必要がある。本レポートでは、連邦政府におけるCOOP導入に向けたさまざまな枠組みや取り組み、そして現状について紹介する。
御参考まで。
米国マンスリーニュース 2005年8月号
連邦政府における業務継続性確保の取り組み
政府のビジネス継続計画「COOP」
災害やテロ攻撃など、緊急時にも政府業務やITシステムの稼動を継続させるためには、ビジネス継続計画(BCP: Business Continuity Plan)の存在が欠かせない。米国政府では、BCPを業務継続計画(Continuity of Operations: COOP)と呼ぶことが多い。政府関係者は、いかなる危機的状況においても政府の主要業務が停止することがないよう、業務継続計画の作成、状況変化などに合わせた見直し、そして計画が実行可能であるかどうかのテストを実施する必要がある。本レポートでは、連邦政府におけるCOOP導入に向けたさまざまな枠組みや取り組み、そして現状について紹介する。
御参考まで。
2006年09月29日
ディザスタリカバリで強い企業を作る
2006年09月14日
ベリタスのSTORAGE COMPASS
ベリタス社(今はノベル?)がホームページで掲載している(いた?)STORAGE COMPASS連載講座というのが、ディザスターリカバリー+ストレージに関して参考になる。
STORAGE COMPASS
もう二年近く更新されていない(このブログみたい)が、過去の目次は以下のような感じ。
例のニューヨーク商品取引所の話も書かれてますね。
現在連載中の講座
全1回読みきり: ディザスタリカバリ プランのテスト (2004年11月から掲載)
「よくわかる」シリーズ (2002年10月から掲載)
過去に連載された講座
全2回連載シリーズ: ディザスタリカバリ サイト (2004年9月〜10月連載)
全3回連載シリーズ: ディザスタの管理 (2004年6月〜8月連載)
全5回連載シリーズ: 企業の回復能力 (2004年1月〜5月連載)
全2回連載シリーズ: ディザスタとリカバリ プラン (2003年11〜12月連載)
全4回連載シリーズ: ディザスタリカバリ事例研究 (2003年10〜11月連載)
全3回連載シリーズ: アプリケーションをディザスタから守る (2003年8月〜9月連載)
全3回連載シリーズ: ディザスタからのデータファイルの保護 (2003年5月〜7月連載)
全6回連載シリーズ: ストレージ ネットワークとディザスタ リカバリ (2003年2月〜5月連載)
全6回連載シリーズ: データベースをディザスタから守る (2002年11月〜2003年1月連載)
全3回連載シリーズ: オラクルのバックアップとリカバリ (2002年9〜10月連載)
全6回連載シリーズ: バックアップとディザスタ リカバリ (2002年8〜10月連載)
全8回連載シリーズ: SQL Server のベーシック アベイラビリティ (2002年4〜8月連載)
全6回連載シリーズ: ニューヨーク商品取引所の DR 対策から学ぶ (2002年4〜7月連載)
全4回連載シリーズ: IT 管理者の効率を高めるためのガイドライン (2001年11月〜2002年1月連載)
全8回連載シリーズ: ファイバチャネルとストレージ エリア ネットワーキング (2001年10月〜2002年2月連載)
STORAGE COMPASS
もう二年近く更新されていない(このブログみたい)が、過去の目次は以下のような感じ。
例のニューヨーク商品取引所の話も書かれてますね。
現在連載中の講座
全1回読みきり: ディザスタリカバリ プランのテスト (2004年11月から掲載)
「よくわかる」シリーズ (2002年10月から掲載)
過去に連載された講座
全2回連載シリーズ: ディザスタリカバリ サイト (2004年9月〜10月連載)
全3回連載シリーズ: ディザスタの管理 (2004年6月〜8月連載)
全5回連載シリーズ: 企業の回復能力 (2004年1月〜5月連載)
全2回連載シリーズ: ディザスタとリカバリ プラン (2003年11〜12月連載)
全4回連載シリーズ: ディザスタリカバリ事例研究 (2003年10〜11月連載)
全3回連載シリーズ: アプリケーションをディザスタから守る (2003年8月〜9月連載)
全3回連載シリーズ: ディザスタからのデータファイルの保護 (2003年5月〜7月連載)
全6回連載シリーズ: ストレージ ネットワークとディザスタ リカバリ (2003年2月〜5月連載)
全6回連載シリーズ: データベースをディザスタから守る (2002年11月〜2003年1月連載)
全3回連載シリーズ: オラクルのバックアップとリカバリ (2002年9〜10月連載)
全6回連載シリーズ: バックアップとディザスタ リカバリ (2002年8〜10月連載)
全8回連載シリーズ: SQL Server のベーシック アベイラビリティ (2002年4〜8月連載)
全6回連載シリーズ: ニューヨーク商品取引所の DR 対策から学ぶ (2002年4〜7月連載)
全4回連載シリーズ: IT 管理者の効率を高めるためのガイドライン (2001年11月〜2002年1月連載)
全8回連載シリーズ: ファイバチャネルとストレージ エリア ネットワーキング (2001年10月〜2002年2月連載)
2006年09月13日
クラスタの切替え時間
ずいぶん久しぶりの更新になってしまって申し訳ないです。
最近、クラスタの切替え時間について人から聞かれる機会があったのですが、結論は、
「クラスタの切替え時間を保証することは誰にもできない」
です。
少し乱暴な言い方かも知れませんが、30秒なり3分なり、絶対この時間内に切替えが完了するなど、誰にも保証できない。私はそう思ってます。
「多くのケースでは○○分(秒)以内に切替えが行われます」とは言えても、ハードが故障してホットI/O状態になったり、ディスクのI/Oエラーでリトライが多発したりする(レアな)ケースで切替えに時間がかかることは、可能性としては十分あり得ます。これは、確率の問題なのです。
もちろん、可用性を高めるための不断の努力は必要だし、
だからこそ、あらゆるケース(ワーストケース)を想定して準備する(例えば手動で切替えを行うなどエスカレーション手順を準備する)ことが重要なのです。
最近、クラスタの切替え時間について人から聞かれる機会があったのですが、結論は、
「クラスタの切替え時間を保証することは誰にもできない」
です。
少し乱暴な言い方かも知れませんが、30秒なり3分なり、絶対この時間内に切替えが完了するなど、誰にも保証できない。私はそう思ってます。
「多くのケースでは○○分(秒)以内に切替えが行われます」とは言えても、ハードが故障してホットI/O状態になったり、ディスクのI/Oエラーでリトライが多発したりする(レアな)ケースで切替えに時間がかかることは、可能性としては十分あり得ます。これは、確率の問題なのです。
もちろん、可用性を高めるための不断の努力は必要だし、
だからこそ、あらゆるケース(ワーストケース)を想定して準備する(例えば手動で切替えを行うなどエスカレーション手順を準備する)ことが重要なのです。
2006年02月23日
デマルコ『ゆとりの法則』
可用性とは離れますけど、前に触れたデマルコに関して。
おととしにデマルコが来日した時、かくゆう私もミーハー根性丸出しで講演を聞きにいってサインまで貰って来ました。
その時にサインを貰った『ゆとりの法則』をパラパラめくってたら、管理されることを嫌うエンジニアを、聖書の創世記のアダムとイブの話のイブに例えた下りが目にとまった。
「イブは、人間の尊重すべき資質をすべて備えている。抑えきれない好奇心、勇気、権威を恐れない豪胆さ。なによりも自分自身の成長に意欲的であり、少しだけでなくすべての約束を果たそうと決めている。
イブの「堕落」の話を思い出してほしい。神は、楽園のものはなにを食べてもよいが、ただ一つ、善悪を知る木の実は食べてはならないと言い渡す。この木の実はそもそも食べ物ではなく、「理解」である。それを食べれば、知るべきではないことを知ることになり、楽園から追放される。
これに対するイブの態度は「おことわり!」である。自分自身の成長を狭い枠の中にとどめるつもりはなかった。イブは木の実を食べ、その結果を受け入れる。私も同様の立場に立ったとき、同じような勇気を持てたらと思う。」(下線筆者)
いかにもソフトウェア開発の現場でのヒューマン・ファクターの重要性を一貫して主張してきたデマルコらしい文章で、何か自分のことを言われてるような気がして、ぐっとくるものがある。
(しかも、これは何もソフトウェアやコンピューターに限った話ではなく、クリエイティブで創造的な職業すべてに当てはまる。そしてクリエイティブでない職業なんて実は存在しない。)
もっとも、宮仕えの悲しさというか何というか、ただ言われたことに歯向かっているだけでは仕事は進まない。そこのバランス感覚というものも必要だ。
先の「ダンプが必要なOSを作った覚えはない」についても、色んな人のブログを見てると「これが、これからの新しい設計思想なんだ!素晴らしい!」とかただ讃美するだけのバカがいて、本当にどうしようもない。人知れず世の中を支えているLinuxシステムもあることが分かっていない。そんな人は本当にクリティカルなシステムに関わったことがない日曜プログラマなんだろうな。
おととしにデマルコが来日した時、かくゆう私もミーハー根性丸出しで講演を聞きにいってサインまで貰って来ました。
その時にサインを貰った『ゆとりの法則』をパラパラめくってたら、管理されることを嫌うエンジニアを、聖書の創世記のアダムとイブの話のイブに例えた下りが目にとまった。
「イブは、人間の尊重すべき資質をすべて備えている。抑えきれない好奇心、勇気、権威を恐れない豪胆さ。なによりも自分自身の成長に意欲的であり、少しだけでなくすべての約束を果たそうと決めている。
イブの「堕落」の話を思い出してほしい。神は、楽園のものはなにを食べてもよいが、ただ一つ、善悪を知る木の実は食べてはならないと言い渡す。この木の実はそもそも食べ物ではなく、「理解」である。それを食べれば、知るべきではないことを知ることになり、楽園から追放される。
これに対するイブの態度は「おことわり!」である。自分自身の成長を狭い枠の中にとどめるつもりはなかった。イブは木の実を食べ、その結果を受け入れる。私も同様の立場に立ったとき、同じような勇気を持てたらと思う。」(下線筆者)
いかにもソフトウェア開発の現場でのヒューマン・ファクターの重要性を一貫して主張してきたデマルコらしい文章で、何か自分のことを言われてるような気がして、ぐっとくるものがある。
(しかも、これは何もソフトウェアやコンピューターに限った話ではなく、クリエイティブで創造的な職業すべてに当てはまる。そしてクリエイティブでない職業なんて実は存在しない。)
もっとも、宮仕えの悲しさというか何というか、ただ言われたことに歯向かっているだけでは仕事は進まない。そこのバランス感覚というものも必要だ。
先の「ダンプが必要なOSを作った覚えはない」についても、色んな人のブログを見てると「これが、これからの新しい設計思想なんだ!素晴らしい!」とかただ讃美するだけのバカがいて、本当にどうしようもない。人知れず世の中を支えているLinuxシステムもあることが分かっていない。そんな人は本当にクリティカルなシステムに関わったことがない日曜プログラマなんだろうな。
2006年02月09日
ライブドアが意外と技術系っぽいことについて
このブログの趣旨からは少し外れますが、「虚業」とか言われて叩かれてるライブドアが「意外(?!)」と技術系であることを援護する記事をいくつか読みました。
ITmediaニュース:こんな時だからこそ安定したサービスを」――ライブドアの技術者魂
はてなCTO伊藤さんのブログ「ライブドアの技術の話」
ライブドアが意外と技術系っぽいことについて - 圏外からのひとこと
ライブドアが普通に技術系であることについて -- 圏外からのひとこと
404 Blog Not Found:TVではかき消せない、permalinkの威力
一般の新聞や週刊誌では虚業だ何だって論調が目立ちます(確かに発行株式とか時価総額は大分水増しされたものだったけど)が、ライブドアの技術陣は地道にそして先鋭的にウェブビジネスのインフラを構築し運用しているのだ。偉いんだ!って記事です。
「自社でサーバーを設計するなどレイヤ0から独自の技術を持っており、連日のテレビ放映による影響でも落ちないサイトを維持し、オープンソースの自社製フレームワークで大規模なサイトを超短期で構築して自分たちで運用している。オープンソースのライブラリ開発者、メディア執筆者を多数輩出した企業であり、特に Lightweight Language を活用するウェブプログラマに与えた影響は非常に大きい...ライブドアはそういう技術的な側面を持っている企業です。(中略)
一日何億もあるページビュー、何万というトランザクションをエラーを出さずにさばき続けるのにいったいどんな技術が必要か、想像したことはありますか。」(上記伊藤さんのブログ)
「だから、「中の人」として「数の暴力」に対抗する方法は、サービスを遺漏無く走らせ続けるという点に尽きる。「止めぬが勝ち」であり、そして価値なのだ。どんなOBの証言より、そのことは雄弁なのだ。少なくとも、「東証は止まったけどうちのサービスは止まりませんでしたよ」ぐらいは、言う資格があると思う。」(404 Blog Not Found)
私も可用性には設計やら日頃の運用が大切だとか偉そうなことを書いてますが、会社的にも個人的にも大変な時期なのに、こうやって大規模なサーバー群をノーダウンで維持し続け黙々と仕事を続けているエンジニアたちの事を考えるとすごく偉いなと思って、ちょっと涙が出てきます。(少しプロジェクトX風)
正直、今までライブドアが技術的にどうかとか余り評価してなかったんですが、24/356システムを維持している方々の技術力と努力を分かってないのは私自身でした。かなり反省です。
広い意味でのIT業界の端くれにいる人間としては陰ながら応援しちゃいましょう。
そういえば、このサーバもほとんどタダみたいな金額で使わせてもらってるんだから、もっと応援しなくちゃね。
堀江さん自身、本当は経営オンチの技術屋さんで、そんで変な方向に行っちゃったんじゃないでしょうかね。
ITmediaニュース:こんな時だからこそ安定したサービスを」――ライブドアの技術者魂
はてなCTO伊藤さんのブログ「ライブドアの技術の話」
ライブドアが意外と技術系っぽいことについて - 圏外からのひとこと
ライブドアが普通に技術系であることについて -- 圏外からのひとこと
404 Blog Not Found:TVではかき消せない、permalinkの威力
一般の新聞や週刊誌では虚業だ何だって論調が目立ちます(確かに発行株式とか時価総額は大分水増しされたものだったけど)が、ライブドアの技術陣は地道にそして先鋭的にウェブビジネスのインフラを構築し運用しているのだ。偉いんだ!って記事です。
「自社でサーバーを設計するなどレイヤ0から独自の技術を持っており、連日のテレビ放映による影響でも落ちないサイトを維持し、オープンソースの自社製フレームワークで大規模なサイトを超短期で構築して自分たちで運用している。オープンソースのライブラリ開発者、メディア執筆者を多数輩出した企業であり、特に Lightweight Language を活用するウェブプログラマに与えた影響は非常に大きい...ライブドアはそういう技術的な側面を持っている企業です。(中略)
一日何億もあるページビュー、何万というトランザクションをエラーを出さずにさばき続けるのにいったいどんな技術が必要か、想像したことはありますか。」(上記伊藤さんのブログ)
「だから、「中の人」として「数の暴力」に対抗する方法は、サービスを遺漏無く走らせ続けるという点に尽きる。「止めぬが勝ち」であり、そして価値なのだ。どんなOBの証言より、そのことは雄弁なのだ。少なくとも、「東証は止まったけどうちのサービスは止まりませんでしたよ」ぐらいは、言う資格があると思う。」(404 Blog Not Found)
私も可用性には設計やら日頃の運用が大切だとか偉そうなことを書いてますが、会社的にも個人的にも大変な時期なのに、こうやって大規模なサーバー群をノーダウンで維持し続け黙々と仕事を続けているエンジニアたちの事を考えるとすごく偉いなと思って、ちょっと涙が出てきます。(少しプロジェクトX風)
正直、今までライブドアが技術的にどうかとか余り評価してなかったんですが、24/356システムを維持している方々の技術力と努力を分かってないのは私自身でした。かなり反省です。
広い意味でのIT業界の端くれにいる人間としては陰ながら応援しちゃいましょう。
そういえば、このサーバもほとんどタダみたいな金額で使わせてもらってるんだから、もっと応援しなくちゃね。
堀江さん自身、本当は経営オンチの技術屋さんで、そんで変な方向に行っちゃったんじゃないでしょうかね。
2006年01月26日
SunGardの移動データセンター
面白い映像を見つけました。
SunGardが運用している移動データセンターです。(iPIXプラグインが必要)
大型トレーラーの中にデータセンターがそっくり収まっていて、災害が発生すると出動するようです。
SunGardが運用している移動データセンターです。(iPIXプラグインが必要)
大型トレーラーの中にデータセンターがそっくり収まっていて、災害が発生すると出動するようです。
2006年01月25日
オープンソースの品質
以前、Linuxのビジネスユースに関して、オープンソースコミュニティーとの品質に関する認識論的切断(!?)について触れましたが、もう少し考えてみました。
私は仕事柄、海外(米国&ヨーロッパ)のソフトウェア開発者を相手にする機会があるのですが、彼らは割といい加減というか良い加減で、再現しないんならいいじゃないかとか、回避できればいいじゃないかとか良く言います。(プロセスの見直しはやって欲しいんですが・・・)
実際、ドイツなんかだと2000年問題の時も、まぁ手を尽くしてダメだったらしょうがないじゃないかというのが社会的コンセンサスになっていて、日本ほどピリピリしてなかったみたいです。
オープンソースコミュニティーの感覚に近いですね。
日本では過剰に品質を求めすぎるのかもしれません。
「ピープルウェア」や「ゆとりの法則」で有名なデマルコも、おととし日本に来た時の講演で過剰な品質は必要ないと言っていました。
「効率化しすぎると、作業が遅くなり変化にも対応できない」とトム・デマルコ氏――“デブサミ2004”開幕
「“早さ”と“クオリティー”の過剰な要求は開発者やその企業をダメにする 」なんだそうです。
デマルコに関しては、こんなブログも御参考。
ただ、ディザスター・リカバリーとか業務継続の分野だとどうなんでしょうね???
私は仕事柄、海外(米国&ヨーロッパ)のソフトウェア開発者を相手にする機会があるのですが、彼らは割といい加減というか良い加減で、再現しないんならいいじゃないかとか、回避できればいいじゃないかとか良く言います。(プロセスの見直しはやって欲しいんですが・・・)
実際、ドイツなんかだと2000年問題の時も、まぁ手を尽くしてダメだったらしょうがないじゃないかというのが社会的コンセンサスになっていて、日本ほどピリピリしてなかったみたいです。
オープンソースコミュニティーの感覚に近いですね。
日本では過剰に品質を求めすぎるのかもしれません。
「ピープルウェア」や「ゆとりの法則」で有名なデマルコも、おととし日本に来た時の講演で過剰な品質は必要ないと言っていました。
「効率化しすぎると、作業が遅くなり変化にも対応できない」とトム・デマルコ氏――“デブサミ2004”開幕
「“早さ”と“クオリティー”の過剰な要求は開発者やその企業をダメにする 」なんだそうです。
デマルコに関しては、こんなブログも御参考。
ただ、ディザスター・リカバリーとか業務継続の分野だとどうなんでしょうね???
2006年01月18日
東証の成長曲線
14時40分から株式全銘柄の売買停止=東証
東京証券取引所は18日の14時25分時点で注文件数が700万件程度、約定件数が400万件程度に増加。処理能力の限界に接近したため、14時40分以降、全銘柄の株式やCB、社債などを終日売買停止にすると発表した。(H.K)
[ラジオNIKKEI2006年01月18日]
これは結果論ですが、近いうちに取引量が処理能力を越えることが見えていたのでしょうから、もっと効果的な手が打てたのではないでしょうか?
予想以上にネット取引が急増(ホリエモン的には「想定外」?)したとはいえ、見通しが甘かったのかなぁと思います。
Blueprints for High Availabilityの高可用性設計原理#7が「成長をデザインしろ」でした。(本宅参照)
CPU、メモリ、I/O、ディスクはいつかは必ず枯渇するし、関連して電源容量や空調の容量も増やす必要が出てきます。そして、もしかしたらデータセンターも。
システムを設計する時のゆとりや将来のスケーラビリティーを考えさせる事例です。
東京証券取引所は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: 上場企業会計改革及び投資家保護法」という長ったらしい名前の法律だ。)
参考:DR/BCに関連する法律
これらはアメリカでの話ですが、日本で言えば1977年告示の「電子計算機 システム安全対策基準」なんかがあります。正直言って余り詳しくないので識者の方におまかせします。
"Blueprints for High Availability(BHA)"でも、可用性やディザスター・リカバリーに関連するいくつかの法律を挙げている。
(ちなみに、SOX法とは法案を提出した二人の議員の名前であるSarbanes-Oxley actの略で、正式には「Public Company Accounting Reform and Investor Protection Act of 2002: 上場企業会計改革及び投資家保護法」という長ったらしい名前の法律だ。)
- 1996年の健康保険ポータビリティー・アカウンタビリティー法(HIPAA)
この法律はセキュリティーの話題で引き合いに出されることが多いが、患者のプライバシー権及び患者、手続き、保険記録に関連するデータの格納、管理、保護の方法について、患者のプライバシーとデータ保有に特別の注意を払うように求めている。
- 1977年の海外腐敗行為防止法(Foreign Corrupt Practices Act of 1977: FCPA)
この法律は、ロッキード事件のような外国の公務員への贈賄の禁止で有名。
BHAでは、この法律で「正式なDR計画を持つことを要求している」とある。
下の参考サイトでは「株式公開会社は情報システムに対し適切な保護をする責任がある」となってます。
(DRについて、どこまで具体的に規定されているのか、詳細は法律の原文を読んでいないので不詳→調査中)
- 1934年の証券及び取引所法
公開会社とその監査法人はすべての記録を最低7年間保管しなければならないことなどが規定されている。
当然、データがハードディスクにあろうが災害に遭おうが斟酌してくれるはずもない。
- 内国税収入庁(IRS)規則71-20
法人税の記録はそれらが関連している限り保管されなければならないと規定している。
なお、IRS規則86-19では税務上のデータのバックアップ・リカバリーについて規定している。
参考:DR/BCに関連する法律
これらはアメリカでの話ですが、日本で言えば1977年告示の「電子計算機 システム安全対策基準」なんかがあります。正直言って余り詳しくないので識者の方におまかせします。
2006年01月11日
ディザスター・リカバリーと業務継続の違い???
ちょっとググっていたら、ITマネージメントについて解説しているIT Management Reference Guideというのを見つけた。
当然のようにBusiness Continuity Managementという章もあるわけだが、その中でディザスター・リカバリーと業務継続の違い(Differences Between Disaster Recovery and Business Continuity)を語っていたりして興味深い。
英語ですが、興味がある人は御覧あれ。
ちなみに、両者の違いを簡単な表にすると、こんな感じになるそうです。
(ちょっと一面的という気もしないではないですが)
当然のようにBusiness Continuity Managementという章もあるわけだが、その中でディザスター・リカバリーと業務継続の違い(Differences Between Disaster Recovery and Business Continuity)を語っていたりして興味深い。
英語ですが、興味がある人は御覧あれ。
ちなみに、両者の違いを簡単な表にすると、こんな感じになるそうです。
(ちょっと一面的という気もしないではないですが)
カテゴリ | DR | BC |
---|---|---|
重要視されるエリア | データセンター | 企業 |
アプローチ | 反応 | 順応 |
志向 | テクノロジー | ビジネス |
起源 | 70年代 | 90年代 |
顧客の関わり合い | 最小 | 広範囲 |
サポートグループの種類 | 小 | 多様 |
関与するユーザの数 | 無 | 多 |
主要なメトリクス | MTBF/MTTR | RPO/PTO |
マネージメントスタイル | 独裁的 | 協力的 |
主導する重役 | CFO/CIO | CEO/CRO |
監督する管理者 | オペレーション・マネージャー | ビジネス・コンティニュティー・マネージャー |
認証 | 補助的 | 多数 |
キャリア・パッシング | 限定的 | 広い |
『クラスタ』という名称
さて、よく使われている用語だが、単に「クラスタ」といっても、目的・形態によっていくつかに分類される。キャリアグレード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に相当する。
この言葉も技術的に中立で、機能を端的に表している。
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』
今までキチンとした紹介をしてなかったので、あらためて『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
以下は、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
kxa00121 at 12:13|Permalink│Comments(0)│TrackBack(0)│
│Tales from the Field | Blueprints for High Availability
2006年01月04日
Linuxと高可用性〜ダンプが必要なOSを作った覚えはない〜
Linuxと高可用性というのも、本質的に相容れない物のような気がしている。
こちらの記事「ダンプが必要なOSを作った覚えはない」を読んで頂きたい。
もちろん、ダンプ機能はキャリアグレードLinuxでも色々な要件があがっているビジネス・ユースでは必須の機能だが、正直これがオープンソース・コミュニティーの本音だろう。
実際、自分のPCの調子が悪くなっても、それが回避さえできれば根本的な原因が何であるかは二の次だ。例えば、ソフトをインストールし直して問題なく動けば、根本原因を探ることなど詮なきこと、時間の無駄ですらあるかもしれない。
しかし、ビジネスの世界ではそうも言っていられない。不具合の原因が何なのか徹底的に究明して、必要ならば対策を取るのが当たり前だ。それが、ビジネスのプロセスというものだからだ。
このプロセスの違い、根本的な行動原理の差が、たとえLinuxをビジネスに使うメリットがデメリットを上回るとしても、どうも引っかかるのである。
こちらの記事「ダンプが必要なOSを作った覚えはない」を読んで頂きたい。
もちろん、ダンプ機能はキャリアグレードLinuxでも色々な要件があがっているビジネス・ユースでは必須の機能だが、正直これがオープンソース・コミュニティーの本音だろう。
実際、自分のPCの調子が悪くなっても、それが回避さえできれば根本的な原因が何であるかは二の次だ。例えば、ソフトをインストールし直して問題なく動けば、根本原因を探ることなど詮なきこと、時間の無駄ですらあるかもしれない。
しかし、ビジネスの世界ではそうも言っていられない。不具合の原因が何なのか徹底的に究明して、必要ならば対策を取るのが当たり前だ。それが、ビジネスのプロセスというものだからだ。
このプロセスの違い、根本的な行動原理の差が、たとえLinuxをビジネスに使うメリットがデメリットを上回るとしても、どうも引っかかるのである。
2005年12月23日
SAフォーラム(サービス・アベイラビリティー・フォーラム)
可用性に関してはSAフォーラムという団体もある。
一言で言うと、通信・ネットワーク・コンピューター関係の標準化団体だが、サービスレベルで可用性を達成するのに必要な様々なインターフェース仕様を標準化しようという団体だ。
オープンの世界では今まで、システム・インターフェースのようなカーネルに近い所から徐々に標準化が進んできたが、ついに可用性の切り口で標準を作ろうという所まで来たということだろうか。
SAフォーラムでは次の3つの切り口で仕様を作っている。
詳細はSAフォーラムのWebを参照。
SAフォーラムは基本的に仕様を決めるだけの団体なので、OSDLが密接に絡んで技術的な検討や実装(OpenHPIやOpenAIS)を行っている。
SAフォーラムの仕様書についても、徐々に本宅の方で解説していきたいと思います。(いつになることやら分かりませんが・・・)
続きを読む
一言で言うと、通信・ネットワーク・コンピューター関係の標準化団体だが、サービスレベルで可用性を達成するのに必要な様々なインターフェース仕様を標準化しようという団体だ。
オープンの世界では今まで、システム・インターフェースのようなカーネルに近い所から徐々に標準化が進んできたが、ついに可用性の切り口で標準を作ろうという所まで来たということだろうか。
SAフォーラムでは次の3つの切り口で仕様を作っている。
- HPI: ハードウェア・プラットフォーム・インターフェース
- AIS: アプリケーション・インターフェース仕様
- SMS: システム・マネージメント仕様
詳細はSAフォーラムのWebを参照。
SAフォーラムは基本的に仕様を決めるだけの団体なので、OSDLが密接に絡んで技術的な検討や実装(OpenHPIやOpenAIS)を行っている。
SAフォーラムの仕様書についても、徐々に本宅の方で解説していきたいと思います。(いつになることやら分かりませんが・・・)
続きを読む
2005年12月21日
キャリアグレードLinux
OSDL(Open Source Development Laboratory)というLinuxのビジネス利用を推進している業界団体が開発している仕様に『キャリアグレードLinux』というものがある。
キャリアというのは電話会社などの通信事業者のことで、当然そのシステムには極めて高い可用性が求められる。許される停止時間はコンマ数秒という世界である。そのような水準の高信頼性・高可用性がキャリアグレードと呼ばれる。
キャリアグレードLinuxとは、現在のLinuxをその水準に引き上げるために不可欠な機能の標準として仕様化したものだ。
今のところ、次の仕様書が存在する。
詳細についてはOSDLのサイトを参照。
本宅の方で仕様書も少し訳してみようかとも思っています。
続きを読む
キャリアというのは電話会社などの通信事業者のことで、当然そのシステムには極めて高い可用性が求められる。許される停止時間はコンマ数秒という世界である。そのような水準の高信頼性・高可用性がキャリアグレードと呼ばれる。
キャリアグレードLinuxとは、現在のLinuxをその水準に引き上げるために不可欠な機能の標準として仕様化したものだ。
今のところ、次の仕様書が存在する。
- 可用性
- クラスタリング
- サービスアビリティー
- 標準適合
- セキュリティー
- ハードウェア
- 性能
詳細についてはOSDLのサイトを参照。
本宅の方で仕様書も少し訳してみようかとも思っています。
続きを読む