WHSを使ったリカバリ ― 2009/12/11 22:07
金曜日、天気予報通りの雨。
午前中に大量の未着信が携帯に残っていた。大学の秘書室のＰＣのうち１台が、ログオン出来ない状態になったとのこと。昼過ぎに行って確認してみると、確かにログインできない。「ユーザプロファイルの読み込みに失敗しました。」と出る。つまりレジストリ情報が壊れたかなにかで、読み取れない状態になっているようだった。
ちょうど、昨年の今頃に、Windows Home Server(WHS)でバックアップの体制を構築して、毎日正午にバックアップが行われるようにしておいた。サーバー、UPS込みで20万円くらいのコストをかけたわけだけれども、保険と同様に、何事もなければ全く無駄な費用にも思えるところである。それがついに活躍する機会がきたかと思い、本当に簡単にリカバリできるのかどうか、自分の目で確認するために作業をすることに。
しかし、リストア用のCDブート後、HDDもNICも問題なく認識しているように見えるのに、何故か「WHSのサーバを検出できませんでした。」とエラーになってしまう。
セーフモードで起動するとユーザプロファイルを読み込めない場合でも、既定のものを読んでくれてログインできたので、Administratorユーザを有効にしてログインすする。この時点ではWHSサーバにちゃんと接続できているようだった。しょうがないので、いったんフルリカバリは諦めて、ユーザプロファイルだけリカバリできないか試していろいろ試行錯誤するものの、うまくいかない。
MicrosoftのサポートFAQでは、ユーザプロファイルが読み込めなくなった場合は、そのアカウントとは別に新規にアカウントを作り直して、プロファイル以外のファイルを全部コピーして下さいと書いてあるが、これだと、Outlookとかのアカウント情報も初期化されて再度設定するのが面倒。
いろいろ調べて見ると、他にも同じ問題に当たっている人がいて、どうやら、最初CDブートした時にNICが認識できているように見えていても、ドライバをちゃんと読み込めていないケースがあるらしいとのこと。ということで、Realtekからドライバ(リストアCDはVista(PE)べースのようなので、Vista x86用のもの）を取ってきて、USBディスクから読み込ませたらうまくいった。結局、14時頃から作業していて、17時前までその試行錯誤。その後リストアが終わって18時。正味１時間程度で出来る作業だったところ、時間を無駄にしてしまった。でも初回なのでしょうがない。
http://social.technet.microsoft.com/Forums/ja-JP/windowshomeservergenericja/thread/8e526694-c68e-4eea-871a-002360b1f2d5
後で調べて見ると、NICやRAIDのドライバについて、WHSではそれぞれのバックアップとして、Windows Home Server Drivers for Restore、というフォルダに保存してくれているとのこと。これを普段（初回セットアップした時点で）から、USBディスクとかに待避して、リストア用CDと一緒に置いておかないとダメなんだな。
http://satsumahan.blog40.fc2.com/blog-entry-174.html
でもまあ、これで今度同じような障害が発生したときには、僕でなくても簡単にリカバリできることがわかった。他のPCでも同様にドライバなどを取り出して保存しておくことにしよう。
午前中に大量の未着信が携帯に残っていた。大学の秘書室のＰＣのうち１台が、ログオン出来ない状態になったとのこと。昼過ぎに行って確認してみると、確かにログインできない。「ユーザプロファイルの読み込みに失敗しました。」と出る。つまりレジストリ情報が壊れたかなにかで、読み取れない状態になっているようだった。
ちょうど、昨年の今頃に、Windows Home Server(WHS)でバックアップの体制を構築して、毎日正午にバックアップが行われるようにしておいた。サーバー、UPS込みで20万円くらいのコストをかけたわけだけれども、保険と同様に、何事もなければ全く無駄な費用にも思えるところである。それがついに活躍する機会がきたかと思い、本当に簡単にリカバリできるのかどうか、自分の目で確認するために作業をすることに。
しかし、リストア用のCDブート後、HDDもNICも問題なく認識しているように見えるのに、何故か「WHSのサーバを検出できませんでした。」とエラーになってしまう。
セーフモードで起動するとユーザプロファイルを読み込めない場合でも、既定のものを読んでくれてログインできたので、Administratorユーザを有効にしてログインすする。この時点ではWHSサーバにちゃんと接続できているようだった。しょうがないので、いったんフルリカバリは諦めて、ユーザプロファイルだけリカバリできないか試していろいろ試行錯誤するものの、うまくいかない。
MicrosoftのサポートFAQでは、ユーザプロファイルが読み込めなくなった場合は、そのアカウントとは別に新規にアカウントを作り直して、プロファイル以外のファイルを全部コピーして下さいと書いてあるが、これだと、Outlookとかのアカウント情報も初期化されて再度設定するのが面倒。
いろいろ調べて見ると、他にも同じ問題に当たっている人がいて、どうやら、最初CDブートした時にNICが認識できているように見えていても、ドライバをちゃんと読み込めていないケースがあるらしいとのこと。ということで、Realtekからドライバ(リストアCDはVista(PE)べースのようなので、Vista x86用のもの）を取ってきて、USBディスクから読み込ませたらうまくいった。結局、14時頃から作業していて、17時前までその試行錯誤。その後リストアが終わって18時。正味１時間程度で出来る作業だったところ、時間を無駄にしてしまった。でも初回なのでしょうがない。
http://social.technet.microsoft.com/Forums/ja-JP/windowshomeservergenericja/thread/8e526694-c68e-4eea-871a-002360b1f2d5
後で調べて見ると、NICやRAIDのドライバについて、WHSではそれぞれのバックアップとして、Windows Home Server Drivers for Restore、というフォルダに保存してくれているとのこと。これを普段（初回セットアップした時点で）から、USBディスクとかに待避して、リストア用CDと一緒に置いておかないとダメなんだな。
http://satsumahan.blog40.fc2.com/blog-entry-174.html
でもまあ、これで今度同じような障害が発生したときには、僕でなくても簡単にリカバリできることがわかった。他のPCでも同様にドライバなどを取り出して保存しておくことにしよう。
MySQL Clusterについて ― 2009/12/08 00:14
MySQL Cluster 7.0.8aの時点での現状について、僕の認識をメモ。
（使えるかどうかの観点）
（使えるかどうかの観点）
・地雷を踏みまくることを覚悟するのであれば使える。7.x系列はまだ枯れていない。最近でも、どんどんバージョンが上がっている。
・したがって、急いでいるときに早いレスポンスで応答してくれる、有償のテクニカルサポートは必須（でも、メールベースなので、やりとりを重ねると解決には結局、半日くらいはかかる。それ以上を求めるのであれば、コンサルティング契約を購入するか、あるいは自分でソースコードをデバッガで追うかが必要）。
・本当にMySQL Clusterでなければならないのか？バッチ処理や、大きなテーブル操作が中心になるのであればInnoDBの方が断然パフォーマンスが出る（特にテーブルがinnodb_buffer_pool_size以内で収まる場合）。
・件の可用性の話で、99.999%の稼働率を実現したいのであれば、SPOFを持たないシステムを構築できる点で、MySQL Cluster（というか、ベースとなっているNDB Cluster）を使う意味がある。
・しかし、構成要素が多くなるため(データノード、SQLノード、MGMノードの３種類）、それらをちゃんと組み合わせて、システムとして高い信頼性を確保するには監視機能とか、結構作り込みが必要になり大変だ。
・ちょっとしたこと（操作、条件）で、データノード全体が落ちてしまったりとか、要するにバグ的な不具合（まさに地雷）がある。
・パフォーマンスの点で、InnoDBと比べて、常に、圧倒的に高速であるとは言えないのが現状（逆に言えば、InnoDBの完成度が非常に高いレベルにあるということである）。
・OracleのSun買収が完了してしまうと、MySQL Clusterの立場はどうなる？というところが不透明である。
（ありえないと思うひどい点）
・特定の危険なクエリが原因で、データノード自体が落ちることが、まま有る（安全側に倒してキャンセルしてくれない。。）
・SQL文の最適化が、まだまだである（インデックスを使ってほしいところで使ってくれない、とか、特定のクエリでは何故かフルテーブルスキャンが走ってしまい激重であることなど）
・そもそも、Primary Key（主キー）に帰着できない、インデックスを使うSQL文を発行すると、すべてのデータノードに対してアクセスが行ってしまうという仕様（同様の理由でJOINも原則使えない）。
・したがって、データノードの性能向上について、スケールアウトできない（主キーで完結するクエリだけ投げるならばスケールアウトすると思われるが、そうであるならば、無理にMySQLとして使う必要はなく、NDB Clusterとして使うのが普通）。
・MySQLのテクニカルサポートを受けるためには、Commercial版のバイナリを使う必要があるのだが、これにはInnoDBのコードが入っていない（なので、NDBを使わない他のテーブルはMyISAMを使うことになる、あるいは、別個にMySQL Enterpriseを入れるか）。
（その他豆知識）
・InnoDBは元々GPLであり、フリーで公開されているGPL版のMySQL Clusterには入っているのだが、こちらのバイナリではサポートが受けられない。
・その一方で、通常の商用版のMySQL EnterpriseはGPLライセンスであり、こちらはそのバイナリでサポートが受けられる、という変則的なルールである。
・Carrier Grade Edtion(CGE)とStandard Editionの区別はversion 6.2から無くなった(CGEに統一された）。
・よく知られていることだけれど、元々はNDBと呼ばれていて、Ericssonの中で開発されていたものが、Alzato社という会社にスピンアウトして、それがMySQL ABに買収されたものである。だから、元々全く別に作られたデータベースエンジンにMySQLのレイヤーをかぶせた実装になっているので、MySQL的な機能に一部対応していないことも結構ある。
・したがって、急いでいるときに早いレスポンスで応答してくれる、有償のテクニカルサポートは必須（でも、メールベースなので、やりとりを重ねると解決には結局、半日くらいはかかる。それ以上を求めるのであれば、コンサルティング契約を購入するか、あるいは自分でソースコードをデバッガで追うかが必要）。
・本当にMySQL Clusterでなければならないのか？バッチ処理や、大きなテーブル操作が中心になるのであればInnoDBの方が断然パフォーマンスが出る（特にテーブルがinnodb_buffer_pool_size以内で収まる場合）。
・件の可用性の話で、99.999%の稼働率を実現したいのであれば、SPOFを持たないシステムを構築できる点で、MySQL Cluster（というか、ベースとなっているNDB Cluster）を使う意味がある。
・しかし、構成要素が多くなるため(データノード、SQLノード、MGMノードの３種類）、それらをちゃんと組み合わせて、システムとして高い信頼性を確保するには監視機能とか、結構作り込みが必要になり大変だ。
・ちょっとしたこと（操作、条件）で、データノード全体が落ちてしまったりとか、要するにバグ的な不具合（まさに地雷）がある。
・パフォーマンスの点で、InnoDBと比べて、常に、圧倒的に高速であるとは言えないのが現状（逆に言えば、InnoDBの完成度が非常に高いレベルにあるということである）。
・OracleのSun買収が完了してしまうと、MySQL Clusterの立場はどうなる？というところが不透明である。
（ありえないと思うひどい点）
・特定の危険なクエリが原因で、データノード自体が落ちることが、まま有る（安全側に倒してキャンセルしてくれない。。）
・SQL文の最適化が、まだまだである（インデックスを使ってほしいところで使ってくれない、とか、特定のクエリでは何故かフルテーブルスキャンが走ってしまい激重であることなど）
・そもそも、Primary Key（主キー）に帰着できない、インデックスを使うSQL文を発行すると、すべてのデータノードに対してアクセスが行ってしまうという仕様（同様の理由でJOINも原則使えない）。
・したがって、データノードの性能向上について、スケールアウトできない（主キーで完結するクエリだけ投げるならばスケールアウトすると思われるが、そうであるならば、無理にMySQLとして使う必要はなく、NDB Clusterとして使うのが普通）。
・MySQLのテクニカルサポートを受けるためには、Commercial版のバイナリを使う必要があるのだが、これにはInnoDBのコードが入っていない（なので、NDBを使わない他のテーブルはMyISAMを使うことになる、あるいは、別個にMySQL Enterpriseを入れるか）。
（その他豆知識）
・InnoDBは元々GPLであり、フリーで公開されているGPL版のMySQL Clusterには入っているのだが、こちらのバイナリではサポートが受けられない。
・その一方で、通常の商用版のMySQL EnterpriseはGPLライセンスであり、こちらはそのバイナリでサポートが受けられる、という変則的なルールである。
・Carrier Grade Edtion(CGE)とStandard Editionの区別はversion 6.2から無くなった(CGEに統一された）。
・よく知られていることだけれど、元々はNDBと呼ばれていて、Ericssonの中で開発されていたものが、Alzato社という会社にスピンアウトして、それがMySQL ABに買収されたものである。だから、元々全く別に作られたデータベースエンジンにMySQLのレイヤーをかぶせた実装になっているので、MySQL的な機能に一部対応していないことも結構ある。
高信頼性システムの目安としての99.9...%の意味するところ ― 2009/11/28 19:08
昔から、コンピュータ、ネットワークシステムについて高可用性の宣伝指標で謳われている、99.9...%というものの意味について。
この業界で言うところのこの数値は、要するに、１年間(24h365.25day)の稼働（時間）率をSLAという形で約束しているところに由来するようだ。だから、確率の話であるはずの信頼性とは異なるものであり、単なる割合の話である。だから、業界用語でも普通は高可用性(HA)と言っている。
それぞれの稼働率の期待するダウンタイムを計算してみると、こうなる。
99.9% 約9時間（8.766時間）
99.99% 約1時間(52.596分）
99.999% 約5分(5.2596分）
ここでのポイントは、この稼働時間率は１年間の平均値ということであり、障害の回数については評価の対象となっていない。そういう意味では、MTBF（平均故障間隔）、MTTR（平均復旧時間）の２点のほうがよほど厳しい指標であり、可用性についても、MTBFとMTTRをベースに計算されるべきものである。
可用性 =(MTBF / (MTBF + MTTR)) X 100
ただ、大量に製造する個々の部品はともかく、そもそも事例自体が数えるほどであり、また複雑なシステムの場合には、MTBFとMTTRを保証するのは非常に難しいだろう。だから、稼働率という、何となくキャッチフレーズとしても有効な99.9...%という数値が遊離して使用されているのだと思う。
この業界で言うところのこの数値は、要するに、１年間(24h365.25day)の稼働（時間）率をSLAという形で約束しているところに由来するようだ。だから、確率の話であるはずの信頼性とは異なるものであり、単なる割合の話である。だから、業界用語でも普通は高可用性(HA)と言っている。
それぞれの稼働率の期待するダウンタイムを計算してみると、こうなる。
99.9% 約9時間（8.766時間）
99.99% 約1時間(52.596分）
99.999% 約5分(5.2596分）
ここでのポイントは、この稼働時間率は１年間の平均値ということであり、障害の回数については評価の対象となっていない。そういう意味では、MTBF（平均故障間隔）、MTTR（平均復旧時間）の２点のほうがよほど厳しい指標であり、可用性についても、MTBFとMTTRをベースに計算されるべきものである。
可用性 =(MTBF / (MTBF + MTTR)) X 100
ただ、大量に製造する個々の部品はともかく、そもそも事例自体が数えるほどであり、また複雑なシステムの場合には、MTBFとMTTRを保証するのは非常に難しいだろう。だから、稼働率という、何となくキャッチフレーズとしても有効な99.9...%という数値が遊離して使用されているのだと思う。
この業界の常識としては、99%に満たないものは非商用のシステムで、99.5%以上が商用システムということらしい。そして、99.99%以上を、いわゆるミッションクリティカルと呼ぶようだ。99.99%（フォーナイン）の時点でシステムの復旧にかけられる時間は分単位となり、99.999%（ファイブナイン）の意味するところは、もはや手動での復旧作業が必要となるダウンをしないシステム、ということになる。
http://msdn.microsoft.com/ja-jp/library/aa291543%28VS.71%29.aspx
伝統的な情報通信産業でのシステムはこの99.999%をウリとして、メインフレームなどを高値で売ってきたわけだ。最近はGoogle Appsなどのクラウドシステムが成長してきているが、Googleはこれの月間の稼働率を2010年までに、99.99%を目指すらしい。
