「Amazon Web Services負荷試験入門」の書評

技術評論社より「Amazon Web Services負荷試験入門」を献本いただいていて、やっと一通り目を通すことができましたので僭越ながら書評させていただこうと思います。(遅くなって申し訳ありません;;)

Amazon Web Services負荷試験入門―クラウドの性能の引き出し方がわかる (Software Design plusシリーズ)

■総評

まずは総評です。実践的で実用的に役に立つ本だなあと感じました。私の中で良い本と思っているのは、実際に手を動かしたことがある人が自身の経験を基に、重要なことは懇切丁寧に、逆に重要でないことはさらっと触れるかもしくはばさっと切り捨てながら、著者のメッセージを読者が読みやすい形で最大限凝縮しているような本です。その意味では本書は著者のメッセージを十分感じますし、とても実用的な本だと感じました。

内容としては、負荷試験の失敗事例、負荷試験の一般的な話し、そしてAWS環境下でいろいろ負荷試験しながらサーバスペックを決めていく具体的な手順と、書いてあってほしい内容が一通り押さえられていました。

■失敗事例

1章に失敗事例が書いてあります。負荷テストをしないという事例や間違いだらけの（意味のない）負荷テストなどが書かれています。「あ～わかるわかる」と共感を覚える内容です。(苦笑)

■負荷試験の一般的な話し

3章から9章がそれにあたるかと思います。負荷試験で使われるツールの紹介、負荷試験の手順、負荷試験で得られたデータとその扱い方、そして負荷試験レポートの作成方法などが記されています。ここの内容は必ずしもAWSだけでなくて他のクラウドやオンプレ環境でも十分役に立つ内容です。

これまでなんとなく負荷試験してきた人が体系的に負荷試験の手順を学ぶのに良いと感じました。

■AWS環境下でいろいろ負荷試験しながらサーバスペックを決めていく具体的な手順

重複する部分もありますが7章から10章がそれにあたるかと思います。こういう結果が得られたからこの部分のサーバスペックを変更しましょう、といったことが書かれています。適当にサーバスペックを決める開発者がとても多い(個人的意見)ので、みんなこういう手順を経てサーバスペックを決めてくれたらいいのになあと感じる内容です。

以上、簡単ではありますが書評とさせていただきます。著者の皆さん、良書を書いていただきありがとうございます。また執筆お疲れさまでした!

Baculaの設定でハマったこと

オープンソースのバックアップソフト「Bacula」コミュニティ版の設定でハマッたところをメモ書きとして残しておきます。

・設定ファイルにはホスト名ではなくてIPで書く。例えばlocalhostではなくて127.0.0.1とか。どうしてもホスト名を使いたいときは/etc/hostsに書いてもOK。

・設定ファイルにPasswordを書くところが多いが、自分のパスワードの場合と、接続先のパスワードの場合が混在しているので気をつける。

・もしdirectorサーバとstorageサーバを兼ねるのであれば、bacula-dir.confのStorageディレクティブにあるAddressは127.0.0.1ではなくて自分のIPアドレスを書く。何故ならここで設定するIPアドレスはバックアップ対象サーバがStorage daemonサーバに接続するときのIPアドレスとなるから。

・bacula-dir.confの設定が終わったあと、必ずbconsole上で「label」コマンドを使ってVolumeを作ることを忘れないこと。これを忘れても画面上は特にエラーメッセージが出ないのでわかりづらい。・・・と思ったが、bacula-dir.confの設定中poolに「Label Format」を書いておくと、その名前で自動インクリメントされるようになるのでlabelコマンド実行は必ずしも必須ではないことが判明。

・bconsole上でTerminated Jobが残っているのが嫌なときは、director daemonサービスとstorage daemonサービスを止めた後に/var/spool/bacula/bacula-dir.9101.state と bacula-sd.9103.stateを削除すればよい。

・ストレージサーバ毎に1Jobしか走らないように設定する方法がなかなかわからず苦労した。結果的にbacula-dirのdirectory、storage,poolディレクティブにそれぞれ記載することでうまくいった。

・MySQLが認識しない問題。5.0.xのときは問題なかったのに、5.2.xからdefaultがPostgreSQLになっていた。

「インフラエンジニアの教科書2 スキルアップに効く技術と知識」という本を書きました

2016年8月26日に「インフラエンジニアの教科書2 スキルアップに効く技術と知識」という本が出版されますので、ご紹介させていただければと存じます。

自分が若かりし頃に、こういった内容の本があったら良かったのになあ、という内容を詰め込みました。この本に書かれている内容はどれも日常業務に必要なものばかりなんですが、ネットもくまなく検索してみても、未だにまとまって整理されているものをほとんど見かけないんですよねえ。。。

インフラエンジニアの教科書2 スキルアップに効く技術と知識

■書評
書評いただきました。どうもありがとうございます。

• 「インフラエンジニアの教科書 2」はすべてのエンジニアに読んでほしい良書
• 「インフラエンジニアの教科書２」を読んだ
• インフラエンジニアの教科書2を読んだ

■章立て

CHAPTER-01 プロトコル

CHAPTER-02 OS

CHAPTER-03 ネットワーク

CHAPTER-04 データベース

CHAPTER-05 WEBのサーバサイド開発言語

CHAPTER-06 共通鍵暗号方式と公開鍵暗号方式

CHAPTER-07 障害対策と障害対応

CHAPTER-08 よく知られたセキュリティ攻撃

CHAPTER-09 インターネットの運用と発展をつかさどる組織や団体

CHAPTER-10 RFCの読み方と作られ方

CHAPTER-11 世界規模のインターネットサービス運営

CHAPTER-12 インフラエンジニアとして目指す方向

■アピールポイント 

・障害対応時に重要なOSの仕組みについて、ものすごく丁寧に書きました。OS上のプロセスがCPU、メモリ、ディスクなどのハードウェアとどのように連携しながら動作しているのかがわかるようになると思います。このあたりインフラ運用上すごく重要な基礎知識なんですが、最近はこういった内容が書かれた本をあまり見なくなりましたね。開発者の方にもこの章だけはインフラエンジニアだけでなくとも是非読んでいただきたいです。

・ネットワークに苦手意識を持っている人が多いので、最低限これだけ押さえておけば業務上困らないのではないか、という内容を書いてみました。

・データベースは、DBA視点ではなくてインフラエンジニア視点で書いてみました。ちょっと他の本とは書き方が違います。

・RFCの読み方を日本語で説明している本って意外とないので今回書いてみました。

・開発言語とWEBサーバ(Apache/Nginx/IISなど)の間をつなぐものについて、整理された情報があまりなくて今回整理してみました。この切り口で書かれた本は意外と他にない気がします。

・Javaの世界をインフラエンジニア視点で必要最小限に簡略化した上でわかりやすく説明しました。（開発者向けJava本だとインフラエンジニア視点で余分な情報がほとんどですから）

・SSL証明書の世界がどんどん変化していっていますが、昔勉強したきりで最新状況を押さえていない人も多いかとおもって、中間証明書、クロスルート証明書、EV証明書、ワイルドカード証明書などの内容を含めて書いてみました。

・インターネット関連組織であるISOC,IAB,IETFなどについても意外と日本では知られていないので今回書いてみました。

・WEB系企業に勤めるインフラエンジニアは概してWindowsに弱い人が多い(と思う)ので、普段あまり聞くことがないだろう内容(MFT、ファイル名文字コードの動的変化など)を書いてみました。

・世界規模のインターネットサービス運営に関わっている中で日々感じていることや実際に体験したことなどをまとめてみました。他であまり書かれない内容なので、面白く読んでいただけると思います。

■裏話

・前作「インフラエンジニアの教科書」が出版されるまで、インフラエンジニアというカテゴリーで出版された本がほとんどなかったと聞きます。結果的に前作がそれなりに多くの方に買っていただけたことで、結果的に各社からインフラエンジニアというカテゴリーの本が出されるようになった、らしいです。

・続編を書くことは全く考えてなかったですが、今回多くの読者の方や、各書店の店員さんからも名指しで続編の要望があったと聞きました。こういうことは珍しいらしく、結果的に引き受けることになりました。

・当初半年くらいで書き上げるつもりが、かなり丁寧に書いたために、1年近くかかりました。

・出版社のほうから「副題がないと売りにくいので副題つけてください」と言われて印刷所に入れるぎりぎりまで議論が続いてました。たしかに「インフラエンジニアの教科書2」だけだと前作との違いが購買を検討される方にとってもわかりづらいですよね。

■最後に

普段、新人インフラエンジニアを教育したり他部署から質問を受けたりしている中でいつも感じるのが、コンピュータの基本的な知識が不足しているので悩んでしまうのかな、ということです。そんな経験を踏まえつつ、他の本ではさらっと流されてしまう内容を丁寧に書いていたり、もしくは他の多くの本で書かれているような内容は省略したりとメリハリをつけながら、図を増やしたり文章を読みやすくしたりして極力理解してもらえるように丁寧に書きました。

これまで関わってきた本の中でもっとも愛着があり、また苦労した本でもあるので是非多くの方々に読んでいただければと思います。

どうぞよろしくお願いいたします。

ライブマイグレーションに失敗した話

VMwareサーバの老朽化に伴って新しい物理サーバを用意して次々とライブマイグレーションしていたとき、1VMのみライブマイグレーションに失敗するという症状に見舞われました。

よくあるライブマイグレーションに失敗する事例としては、マイグレーション先のハードウェアリソース不足、異なったCPUを使っている、実は移行先のハードウェアが壊れていた等いろいろあると思いますが、今回の場合はちょっと違いました。

結論から言うと、このVM（仮想サーバ）のみ割り当てCPUコア数が1となっていたからでした。

ライブマイグレーション実行後しばらくは順調に行ってましたが、しばらくするとVMに一切アクセスができなくなる、いわゆるフリーズ状態となってしまいました。そこでもう一度vmstatを回しながらライブマイグレーションを行うと、「r」の列が高い数値を見せて、その後固まりました。「r」列というのは実行中プロセス数と実行待ちプロセス数の総和ですが、この数値が高いということはCPUリソースが足りていないことを意味します。これを手掛かりに原因がわかったのでした。

Hyper-V環境からVMware環境への移行

Hyper-V環境とVMware環境が混在していて、今後VMware環境に統合しようと、せっせとHyper-V上のゲストOSを(サーバオーナーと交渉して)撤去していました。しかしふと思いつきました。「ひょっとしてHyper-VのゲストOSイメージをVMwareのゲストOSイメージに変換するツールがあるのでは?」と。ということで探してみたら「Vmware vCenter Converter Standalone」というツールがあっさりと見つかりました。

ということで今回はHyper-V環境からVMware環境への移行したときのことを書いてみます。

【移行手順】

1. 「Vmware vCenter Converter Standalone」(無料)をダウンロードしてきてインストールして起動します。すると非常にシンプルな画面が現れますので、「Convert machine」をクリックします。

2. Hyper-Vの管理ツールであるSCVMM(System Center Virtual Machine Manager)のログイン情報を入力します。

3. 移行するゲストOSを選択します。

4. 移行先であるvCenterもしくはVMwareサーバのログイン情報を入力します。

5. 移行先のクラスタやハイパーバイザーを選択します。

6. オプションを設定します。ここで特に注意すべきは、「Data to copy」でThick->Thin provisioningにすることと、NICのVLAN情報を正しいものに変更しておくことです。

【やってみて気づいたこと】

(1) 移行後ネットワークがつながらなかったです。どうやらHyper-V用NICが消えて新たにVMware用NICが付与されるようです。よってWindowsの場合はIPを再度振り直し、Linuxの場合は設定ファイルからMACアドレス情報とUUID情報を書き換えるか削除する必要があります。

(2) Windowsの場合、移行前と移行後のActive Directoryの所属ドメインを変える必要があります。移行前にlocal account(administrator権限必須)を生成後ドメインからワークグループに変更して移行し、移行先で再度ドメインに加入するのが良さそうです。

(3)Linuxにて「udev: renamed interface eth0 to eth1」のようなメッセージが出て、eth0が使えなくなってしまうことがあります。これはHyper-V用NIC情報が残ってしまっているからです。この場合、「/etc/udev/rules.d/70-persistent-net.rules」を書き換えたりいろいろしなければならなそうです。

書評「Webエンジニアが知っておきたいインフラの基本」

ハードビーツCTOの馬場さんから「Webエンジニアが知っておきたいインフラの基本」を献本いただきました。どうもありがとうございます！　馬場さんは拙著「インフラエンジニアの教科書」で校正いただいたりと、普段大変お世話になっております。

章立ては以下の通りです。
1章 Webサービスでのインフラの役割
2章 Webサービスを支えるインフラ技術の基礎知識
3章 Webサービスのサーバ構成ベストプラクティス
4章 Webサービスを始めるときのインフラ手配の基礎知識
5章 Webサービスの運用(1) システム監視の基本
6章 Webサービスの運用(2) ステータス モニタリング
7章 Webサービスのチューニング(1) ボトルネックの見つけ方
8章 Webサービスのチューニング(2) チューニングレシピ

インフラエンジニアという点では同業なのですが、私は自社サービスでのインフラエンジニアなのに対して馬場さんはBtoBを中心としたインフラエンジニアという立場の違いを感じて個人的にとても楽しく読ませていただきました。例えば自社サービスの場合はその時々で自分たちが使いたいものを割と自由に選定して使えるのに対して、BtoBの場合はまずは顧客に説明して了承を得なければならないためまずは要件定義が必須となります。本書では要件定義のときに気にすべきことが丁寧に書かれているように思いました。

そして後半部分(5章以降)では、実経験を踏まえた、具体的なインフラ運営方法が丁寧に書かれています。監視ツールや各種コマンドの見方や使い方、チューニングやボトルネックの見つけ方などが、豊富な具体例を使って大変わかりやすく記されています。このあたりの内容は一般的には日々の業務の中でいろいろな経験をしたり先輩に教わったりしながら少しずつ身につけていくものですが、本書ではそういった内容が具体的に示されていてとても参考になると思います。

私が思うに、本書のレベル感としては、普段Linux上でApacheやMySQLなどを使ったことはあるが特に設定変更等はしたことはなく障害が起こっても何をどう直せばいいかわからないくらいの人が大変役に立ちそうです。また中級あたりの人にとっては他のインフラエンジニア（今回の場合は馬場さん）が日々どのようにインフラ運営を行っているか知ることができて参考になりそうです。インフラ運営手法って一般的にあまり体系化されてなくてある意味皆自己流なので他の人が普段どのように運営しているかは私個人的に大変興味があるところでした。

ということで、馬場さん、執筆お疲れ様でした。

特別編: インフラエンジニアの教科書の翻訳本が韓国で発売されました

拙著「インフラエンジニアの教科書」の翻訳本が韓国で2014/6/20から発売開始されます。これを記念して韓国語でコメントさせていただきます。

안녕하세요. 사노라고 합니다.

이번엔 한국의 출판사에서 "인프라 엔지니어의 교과서" 한국어판이 발매되었습니다. 저자는 대학생때 우연히 한국어를 배우고 현재는 일상적으로 한국어를 사용하는 직장에서 인프라엔지니어 업무하고 있습니다. 평소 인연이 깊은 한국과 새로운 기회가 생기고 아주 기쁩니다.

한국에서는 일반적으로 IT관련책의 번역해이 많지 않는다고 알고 있습니다. 이유는 일본보다 인구가 적다는 것으로 듣습니다. 일본에서는 유명한 책이라면 어느정도 일본어판으로 구입할 수 있습니다. 이번에 제 책이 한국어로 번역돼 시판된다고 해서 정말 놀랐습니다.

인프라엔지니어의 교과서는 기술책라는것 보다는 인프라 및 인프라엔지니어를 소개하는 책이라는 평가를 잘 받습니다. 기술을 깊이 배우고 싶은 분은 다른 책으로 공부하시는 게 좋을지도 모릅니다만 원래 무엇을 공부해야 좋을지 모르는 분은 본서에서 전체상을 이미지 하는 것이 유효할지도 모릅니다.

감사합니다

dmマルチパスを用いたDELLストレージ設定方法(MD30xx編)

今回はいつもと趣向を変えて、DELL社DASストレージの設定方法をご紹介します。今回ご紹介するMD3xxx系はマニュアルがわかりにくいだけでなくネット上で設定例をあまり見かけないので役に立つ方は役に立つかと思います。

さて、本題に入ります。

DELL PowerVault MD3000系DASストレージではマルチパスを扱うときに専用のMPPドライバーを使います。それに対してMD32xx系ではDM-RDAC(dm-multipath)と呼ばれるネイティブLinux kernelデバイスマッパーを使います。ここではMD3000系でもdm-multipathを使えるようにする設定方法を記します。

【Storage ManagerとHBA board用ドライバーのインストール】
Linuxサーバ上にStorage ManagerとHBA board用ドライバーをインストールします。それらはMD3xxxに付属しているCDROMに含まれています。

※MD3xxx系では、サーバにRAIDボードではなくHBAボードを挿します。RAIDボードを使う場合はRAIDボード上でRAID関連処理をしますが、MD3xxx系ではストレージ側のコントローラーでRAID関連処理をします。

【MD3000でdm-multipathを使うための事前準備】
/etc/multipath.confを以下の内容に置き換えてリブートするとmultipathから見えるようになります。

defaults {
        getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
}
devices {
        device {
                vendor DELL*
                product MD3000*
                path_grouping_policy failover
                getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
                features "1 queue_if_no_path"
#               path_checker readsector0
                path_checker rdac
                prio_callout "/sbin/mpath_prio_tpc /dev/%n"
                hardware_handler "1 rdac"
                failback immediate
        }
}
blacklist {
       device {
               vendor Dell.*
               product Universal.*
       }
       device {
               vendor Dell.*
               product Virtual.*
       }
}

【MDSM(Modular Disk Storage Manager)の起動と設定】
MDSMはバージョンによって操作性が多少異なるので注意です。大雑把に以下の手順を実施します。

$ SMclient

1. マシン名をつける。
2. HotSpare HDDを指定する。
3. ディスクグループを作成する。（例： VG01）
4. 仮想ディスク(LUN)を作成する。（例： VG01_lun1, VG01_lun2）　※注：ディスクグループ1つに対して2つの仮想ディスクを作るようにすべし。すると各々の仮想ディスクが各パスに分散されるのでパフォーマンスが上がる\!
5. 仮想ディスク(LUN)とホストをマッピングする。

【ストレージとうまく接続できているか確認する方法】
DASを接続しているサーバからストレージが正しく認識しているか以下のように確認することができます。

$ multipath -ll
mpathc (36f01faf000dd7c2a000002513aaa3f5b) dm-1 DELL,MD30xx
size=1.5T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=14 status=active
| `- 1:0:0:1 sdc 8:32 active ready running
`-+- policy='round-robin 0' prio=9 status=enabled
  `- 1:0:1:1 sde 8:64 active ready running
　
mpathb (36f01faf000dd7ba2000002a0529257a6) dm-0 DELL,MD30xx
size=1.5T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=14 status=active
| `- 1:0:1:0 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=9 status=enabled
  `- 1:0:0:0 sdb 8:16 active ready running

いずれも「status=active」であれば正常。

【サーバ内で仮想ボリュームを作る】

■1. pvcreate

pvcreate /dev/dm-1

pvcreate /dev/dm-2

　

■2. vgcreate

vgcreate vg1 /dev/dm-1 /dev/dm-2

　

■3. lvcreate

lvcreate -n lv01 -L 100GB vg1

lvcreate -n lv02 -L 100GB vg1

lvcreate -n lv03 -L 100GB vg1

・

・

・

$ fdisk -l

Disk /dev/mapper/vg01-lv01: 8589 MB, 8589934592 bytes

255 heads, 63 sectors/track, 1044 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00000000

OSからLUNがデバイスとして見えていれば正常。(LUN:Logical Unit Number。サーバから見えるデバイスのこと。一般PCでは1台のHDDを指すが、仮想化されたストレージの場合は切り出された領域が見える)

LinuxでのNIC冗長化(bonding)を少し深く考えてみる

サーバNIC(Network Interface Card)の可用性向上や負荷分散にはNIC冗長化が有効です。NIC冗長化については拙著「インフラエンジニアの教科書」にも記しましたが、bonding、チーミング、リンクアグリゲーションなど様々な呼び名があります。今回はLinux上でのNIC冗長化の話しとなりますので、bondingについての話題となります。

【bondingとは】
bondingとは、複数のNICが搭載されているマシンのNICを束ねて1つの仮想的なNICとして扱うことのできる技術です。例えば1GbpsのNICポートが4つ搭載されているサーバとL2スイッチの間を4本のLANケーブルで接続してbonding設定を有効にさせると、冗長化が行われて最低1本が正常であれば1～3本に問題があっても通信が継続できたり、負荷分散が行われて通信帯域幅を4Gbpsに拡張されたりといった使い方ができます。

Linux Kernelに標準搭載されているbondingでは以下のように7つのmodeがあります。

mode	名称	負荷分散		冗長性	primary 指定	Switch 機能	監視 モード
		送信	受信				MII	ARP
0	balance-rr	○	SW依存	○	×	Ether Channel	○	○
		全スレーブを順繰り(ラウンドロビン)に使ってパケットを送信。 送信のみ負荷分散。
1	active-backup	×	×	○	○	不要	○	○
		1つのスレーブのみを active interfaceとしパケットを送信。 active interfaceに障害が発生した場合、他の backup slave を active interfaceに切り替え、冗長性を確保。
2	balance-xor	△	SW依存	○	×	Ether Channel	○	○
		送信元/先 MACアドレスを元に送信スレーブを決定しパケットを送信。 送信のみ負荷分散。
3	broadcast	○	SW依存	○	不明	要(設定不明)	○	○
		全スレーブに同一パケットを送信。 このモードは通常の用途で使用されないので無視。
4	802.3ad	△	SW依存	○	△	802.3ad	○	×
		IEEE 802.3ad(LACP)に準拠したリンクアグリゲーション。
5	balance-tlb	○	SW依存	○	○	不要	○	×
		スレーブの負荷に応じて送信スレーブを決定しパケットを送信。 送信のみ負荷分散。
6	balance-alb	○	○	○	○	不要	○	×
		balance-tlbの機能に加え、受信も負荷分散。

参考文献: bondingドライバの違いについて

【負荷分散する際気を付けること】
「1Gbpsを4本を束ねると4Gbpsになる」という理屈は理解しやすいですが、適切なmodeを選び適切に設定しないと、例えば送信側は4Gbpsのままだけど受信側は1Gbpsのままといったようなことが起こりがちなので注意が必要です。

bondingを設定する際、ネットワークスイッチ側でも設定が必要な場合とネットワークスイッチ側の設定が特に不要な場合があることにも注意が必要でしょう。

ただしネットワークスイッチ側の設定が特に不要な場合だと言われているmodeにおいてもネットワークスイッチやそのファームウェアバージョンによってはまれに正常に動作しなくなる場合も見受けられるので、本番環境に投入する際には事前検証が必須です。著者の所属する会社のネットワークエンジニア某氏によるとmode4をお勧めしていました。

【Linux Kernelのbondingは実運用に耐えうるものか?】
著者の経験ではLinux Kernelのbondingはどこの会社でも一般的に使われているものなので、適切に設定されていれば安定性についてはそれなりに信頼できそうです。他のホームページでは2つのNICポートでの事例ばかりですが、4つのNICポートでも8つのNICポートでも普通に動作します。

bondingを可用性向上目的で用いる場合は、mode1にてそれぞれのNICポートの配線を別々のネットワークスイッチに接続することをお勧めします。一方bondingを帯域幅増強目的で行う際は、全ての配線を同一ネットワークスイッチに接続するのが一番安定するはずです。ただしこれはネットワークスイッチの挙動に依存する部分でもありますので、複数ネットワークスイッチでも安定的に動作する可能性を否定するものではありません。このあたりはネットワークスイッチベンダーに問い合わせみると良いでしょう。

RAID5のパリティ生成アルゴリズム

「RAIDという仕組みは本当に安全なのか？」という懸念が昔からあったので、今回RAID5のParity algorithmについて研究してみました。(RAID6のParity algorithmについて研究しましたが、それはまた今度)

【RAID5の特徴】
RAID5の特徴について改めて整理すると以下のようになるかと思います。

•Block単位でパリティ分散記録する。
•水平パリティを1つ用いる。水平パリティにはXOR方式を用いることが一般的。
•HDDが1本壊れても復旧できる。

【XOR(排他的論理和)について】
RAID5ではXORを用いてパリティを生成しますので、まずはXORについておさらいしておきます。

A	B	A XOR B
0	0	0
0	1	1
1	0	1
1	1	0

【RAID5のパリティ生成の仕組み】
例えばデータが「1111 0101 1100 1010 0000 1111」の場合は以下のようになります。

HDD-A	HDD-B	Parity
1111	0101	1010
1100	1010	0110
0000	1111	1111

仮にB列が消失した場合はどうなるでしょうか。

HDD-A	HDD-B	Parity
1111	?	1010
1100	?	0110
0000	?	1111

この場合はHDD-AとParityでXORを適用するとBが復元できます。

HDD-A	HDD-B	Parity
1111	0101	1010
1100	1010	0110
0000	1111	1111

この仕組みを応用して、HDD本数が7本の場合、A-BのXOR結果とC、その結果とD、・・・とXORをしていくことになります。

HDD-A	HDD-B	HDD-C	HDD-D	HDD-E	HDD-F	Parity
1111	1010	1100	0110	0000	1111	0000

仮にhdd-Bが故障した場合はどうなるでしょうか。

HDD-A	HDD-B	HDD-C	HDD-D	HDD-E	HDD-F	Parity
1111	?	1100	0110	0000	1111	0000

この場合もBを除いた全てとxorをしていくとBが復元できます。(xorする順番は問わない)

0000 G
1111 F
----
1111
0000 E
----
1111
0110 D
----
1001
1100 C
-----
0101
1111 A
----
1010 B

HDD-A	HDD-B	HDD-C	HDD-D	HDD-E	HDD-F	Parity
1111	1010	1100	0110	0000	1111	0000

こんなシンプルな仕組みであればファームウェアのバグ発生は考えにくそうで、RAID5はそれなりに安全そうですね。

※最後に「インフラエンジニアの教科書」という本を出版させていただきました！という宣伝で締めさせていただきます。

「インフラエンジニアの教科書」という本を書きました

ご無沙汰しています。

前回の記事から1年半近く経ってしまっています。前回のエントリーでLINEが3500万ユーザと書いてますが、現在は2億数千万ユーザとなってますのでずいぶんと伸びたものです。感謝感謝です。

さて、「インフラエンジニアの教科書」という本を書きましたのでご報告させていただきます。おかげさまで出版社の方曰く「ただいま、素晴らしい初速で売れています」だそうで、一部売り切れてしまったお店もあるそうです。おそれいりますが気長に入荷をお待ちください。

書評してくださった方がいらっしゃるのでリンクさせていただきます。どうもありがとうございます。^^
・『インフラエンジニアの教科書』この本をなんと呼ぶ？教科書と呼ぶ！ ・The textbook of the infrastructure enginee ・インフラエンジニアの教科書"を読んで

一応執筆時にこだわった点をアピールしてみます。

・「技術書なのに読みやすい」という路線を目指しました。さくさく読めると思います。

・文書だけだと読むのに疲れるので可能な限り図を入れました。

・起業してから現在に至るまで、個人的に悩んできたことの多くを盛り込みました。特に新たにインフラを立ち上げる場合役に立つと思います。例えば何か買いたいときどのようにベンダーや営業さんと付き合えばよいか、ルータはどれを買えばよいか、データセンターのラックにどこに何を設置すれば良いか等々、他の本ではあまり書かれていないような具体的なレベルのことがたくさん書いてあります。

・メモリには「ランク」という概念がありますが、拙著ではこのランクの意味をわかりやすく正確に説明している国内唯一の本ではないかと自負しています。ネットでくまなく探しましたが、日本語、英語共わかりやすく説明しているサイトが見つからなかったのでした。

・中小オープンソース系企業であまり使われないものについて一通り把握するのに便利です。
　　・Windowsライセンス体系
　　・VMwareライセンス体系
　　・ストレージの種類や技術全般
　　・エンタープライズ機器（電話回線接続してベンダーが障害検知する話しとか）
　　・SASディスク、FCディスク、Fusion-IO(ioDrive)の写真
　　・光ファイバ系の写真（ケーブル、LCコネクタ、SCコネクタ、GBIC、SFP)
　　・ネットワークファブリック構造
　　・データセンターの空調方式（排熱吸引方式、外気空調方式など）
など一通り網羅しています。

・一方、普通の用途に使われないと思うものはばっさり切り捨ててあります。例えばVMwareの製品体系は複雑ですが、本書ではvSphereとvCenterにしか触れてません。

・ライセンス購買のリファレンス的に使えるようにもしました。Win, RHEL, SQLSVR, Oracle, VMwareなどのライセンス体系と価格をわざわざ書いているのは、購買検討時にいちいちネットで検索しなくても済むので便利だからなのでした。ネットとは違い更新が効かない一般書で製品価格を入れるのはリスキーなので普通の本ではあまりやらないと思います。

では～。

(追記 2013/11/2)
いくつか誤植と内容修正が見つかっておりますのでここに共有させていただきます。

-----
第2刷で修正されている内容

・P52。「ストライピング本数がRAID5では4本なのに」→「RAID10では4本なのに」。（川島さん、ありがとうございます）

・P53。RAID6の対角線パリティ方式の考案者はNetAPP社のPeter Corbett氏だそうです。(manabuさん、ありがとうございます)

・P70。Oracle LinuxはDebian系ではなくてRed Hat系の間違いです。（なぜこの明らかな間違いが校正時にあぶりだせなかったのか個人的にショックです。関係者の皆さまご迷惑をおかけしました）

・P114。自動階層化の図で SSD-SATA-SAS の順は、SSD-SAS-SATAの間違いでした。（かみやさとしさん、ありがとうございます）

・P127。排熱吸引方式の最後の行にて、「高なります」→「高くなります」

・P141。Windows20・00→Windows2000

-----
第3刷で修正されている内容

・P93。Protcol -> Protocol。（堂阪さん、ありがとうございます）

・P94。cccc:::1 -> cccc::1、　:::1 -> ::1。（堂阪さん、ありがとうございます）

-----
もし第4刷が出たら修正される内容

・P84
・ARPテーブル -> MACアドレステーブル。（池田さん、ありがとうございます）

L1スイッチの使い道

L2～L4スイッチあたりは馴染みがある人が多いと思いますが、L1スイッチについては聞いたことすらない人も多いのではないでしょうか。L1スイッチは大規模サイトでは必須と言っても過言ではないくらい重要となります。というわけで今回はL1スイッチについて記してみます。

【L1スイッチとは？】
L1スイッチとは、物理層で切り替え（スイッチ）することのできるネットワーク機器となります。ある意味パッチパネルでの切り替えを電気的に行える機械とも言えます。かつ市販されているL1スイッチではメーカー毎に様々な機能が付加されている場合が多いです。

※余談ですが、レピータHUBもレイヤー1に該当しますが、レピータHUB自体にスイッチ機能はないのでレピータHUBがL1スイッチかと問われると微妙な気がします。

【L1スイッチのよくある使い道: ログ分析&IDS】
大規模サイトでよく使われる用途としてはログ分析&IDS監視です。大量の通信をログ分析サーバもしくはIDSサーバに流し込むために、本番系ネットワークとバックエンドネットワークの間にL1スイッチを挟みこみます。

本番系ネットワークのL2スイッチにポートミラーリング設定をほどこし、L2スイッチ上を流れる全てのフレーム(※念のため注:L2なのでパケットではなくてフレーム)をL1スイッチ側に流れるようにすれば、結果的に本番系ネットワークの全てのフレームがL1スイッチを経由してバックエンドネットワークに流れ込むことになります。

そして、その流れ込まれたフレーム（というかL1なので信号かな？)をログ分析サーバもしくはIDSサーバが拾い、分析を行います。

ところでL1スイッチによっては、流れ込まれた信号をロードバランサーのように各サーバに割り振る機能を持つ場合があります。この場合負荷が増えてきた場合に分析サーバのスケールアウトが可能になります。

【L1スイッチを製造しているメーカー】
L1スイッチを製造しているメーカーはそんなに多くありません。例えば著者が調べた限り、以下の4社がありました。

・APCON社(INTELLAPATCH Family)
・Gigamon社(GigaVUE)
・日本ダイレックス株式会社(eL1 SWS)
・Glimmerglass社

【おまけ（宣伝）】
私が監修させていただいた「これだけは知っておきたい ネットワークの常識」技術評論社(共著。監修担当)にも用語集にL1のことをばっちり(?!)載せています。

MySQLのSQLクエリーだけで棒グラフを表示する方法

MySQLの出力結果を棒グラフで表示できたらいいなぁと思っていろいろ実験していたらうまくいってしまったのでご紹介してみます。

【普通の場合】
普通は以下のようになりますよね。出力結果だけ見てもどうもよくわかりません。

■SQL文

mysql> select date_format(regdate, "%Y/%m/%d %H") date, count(*) count from usert group by date order by date asc;

■出力結果

+---------------+-------+
| date　　　　　| count |
+---------------+-------+
| 2010/11/01 00 |　 405 |
| 2010/11/01 01 |　 276 |
| 2010/11/01 02 |　 188 |
| 2010/11/01 03 |　 148 |
| 2010/11/01 04 |　　96 |
| 2010/11/01 05 |　　63 |
| 2010/11/01 06 |　　85 |
| 2010/11/01 07 |　 142 |
| 2010/11/01 08 |　 164 |
| 2010/11/01 09 |　 137 |
| 2010/11/01 10 |　 177 |
| 2010/11/01 11 |　 177 |
| 2010/11/01 12 |　 248 |
| 2010/11/01 13 |　 178 |
| 2010/11/01 14 |　 148 |
| 2010/11/01 15 |　 158 |
| 2010/11/01 16 |　 195 |
| 2010/11/01 17 |　 213 |
| 2010/11/01 18 |　 243 |
| 2010/11/01 19 |　 236 |
| 2010/11/01 20 |　 274 |
| 2010/11/01 21 |　 310 |
| 2010/11/01 22 |　 309 |
| 2010/11/01 23 |　 280 |
+---------------+-------+

【棒グラフの場合】
そして今度は出力結果を棒グラフにした場合の例になります。ものすごくわかりやすくなりました。

■SQL文

mysql> select date_format(regdate, "%Y/%m/%d %H") date, REPEAT("#", count(*)/10) graph from usert group by date order by date asc;

■出力結果

+---------------+-------------------------------------------+
| date　　　　　| graph　　　　　　　　　　　　　　　　　　 |
+---------------+-------------------------------------------+
| 2010/11/01 00 | ######################################### |
| 2010/11/01 01 | ############################　　　　　　　|
| 2010/11/01 02 | ###################　　　　　　　　　　　 |
| 2010/11/01 03 | ###############　　　　　　　　　　　　　 |
| 2010/11/01 04 | ##########　　　　　　　　　　　　　　　　|
| 2010/11/01 05 | ######　　　　　　　　　　　　　　　　　　|
| 2010/11/01 06 | #########　　　　　　　　　　　　　　　　 |
| 2010/11/01 07 | ##############　　　　　　　　　　　　　　|
| 2010/11/01 08 | ################　　　　　　　　　　　　　|
| 2010/11/01 09 | ##############　　　　　　　　　　　　　　|
| 2010/11/01 10 | ##################　　　　　　　　　　　　|
| 2010/11/01 11 | ##################　　　　　　　　　　　　|
| 2010/11/01 12 | #########################　　　　　　　　 |
| 2010/11/01 13 | ##################　　　　　　　　　　　　|
| 2010/11/01 14 | ###############　　　　　　　　　　　　　 |
| 2010/11/01 15 | ################　　　　　　　　　　　　　|
| 2010/11/01 16 | ####################　　　　　　　　　　　|
| 2010/11/01 17 | #####################　　　　　　　　　　 |
| 2010/11/01 18 | ########################　　　　　　　　　|
| 2010/11/01 19 | ########################　　　　　　　　　|
| 2010/11/01 20 | ###########################　　　　　　　 |
| 2010/11/01 21 | ###############################　　　　　 |
| 2010/11/01 22 | ###############################　　　　　 |
| 2010/11/01 23 | ############################　　　　　　　|
+---------------+-------------------------------------------+

急いでいる人のためのMySQLのユーザ権限付与講座

MySQLでは細かいレベルの権限付与が可能ですが、大抵の場合そこまで細かいレベルの権限付与は必要ないですよね？ マニュアルを読まないか、もしくはちょっとしたメモ書きを見る程度でおおよそ使い方が理解できるくらいならいいのに、といつも思います。

そこで今回は、MySQLのユーザ権限付与の中でも、とりわけよく行われる手順だけを簡単にまとめてみました。

【まず知っておいたほうが良いこと】
ユーザはmysqlデータベース内のuserテーブルに作られます。

次に例えば以下のユーザの情報を見てみると「_priv」系のカラム値が全部「Y」であることがわかります。この場合はグローバルレベル権限として全部「Y」なので、全てのテーブルに対して接続が可能となります。

mysql> select * from user where User='adminuser' \G
　
*************************** 1. row ***************************
                 Host: %
                 User: adminuser
             Password: 136b4c537575b6f1
          Select_priv: Y      ←
          Insert_priv: Y      ←
          Update_priv: Y      ←
　
～～～中略～～～
　
  Create_routine_priv: Y      ←
   Alter_routine_priv: Y      ←
     Create_user_priv: Y      ←
             ssl_type:
           ssl_cipher:
          x509_issuer:
         x509_subject:
        max_questions: 0
          max_updates: 0
      max_connections: 0
 max_user_connections: 0
1 row in set (0.00 sec)

一方、以下のユーザの情報を見てみると「_priv」系のカラム値が全部「N」であることがわかります。

mysql> select * from user where User='testuser' \G
　 *************************** 1. row ***************************
                 Host: localhost
                 User: testuser
             Password: 136b4c537575b6f1
          Select_priv: N      ←
          Insert_priv: N      ←
          Update_priv: N      ←
　
～～～中略～～～
　
  Create_routine_priv: N      ←
   Alter_routine_priv: N      ←
     Create_user_priv: N      ←
             ssl_type:
           ssl_cipher:
          x509_issuer:
         x509_subject:
        max_questions: 0
          max_updates: 0
      max_connections: 0
 max_user_connections: 0
1 row in set (0.00 sec)

この場合は、別途ユーザが接続するデータベースを「db」テーブルに設定します。

mysql> select * from db where User='testuser' \G
　
*************************** 1. row ***************************
                 Host: localhost
                   Db: testdatabase
                 User: testuser
          Select_priv: Y
          Insert_priv: Y
          Update_priv: Y
　
～～～中略～～～
　
  Create_routine_priv: Y
   Alter_routine_priv: Y
         Execute_priv: Y
1 row in set (0.00 sec)

普段意識すべきはこのあたりまでだと思いますが、さらに細かい設定を検討する場合は以下もご参照下さい。

※参照:mysqlデータベース内のテーブル一覧

データベース名	説明
user	グローバルレベルの権限とパスワードを管理するテーブル
db	データベースレベルの権限を管理するテーブル
host(今回は考えない)	dbテーブルにホスト名が指定されていない場合に適用される権限を管理するためのテーブル
tables_priv(今回は考えない)	テーブルレベルの権限を管理するテーブル。テーブル内のすべてのフィールドに適用される権限について格納。
columns_priv(今回は考えない)	フィールドレベルの権限を管理するテーブル。テーブル内の一つのフィールドに適用される権限について格納。

これをふまえて。

【1.管理者用ユーザを作りたい】
いわゆる何でもできる管理者用ユーザは以下の要領で作ります。

GRANT ALL ON *.* TO adminuser@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;

※MySQLにはGRANT権限というものがあります。GRANT権限とは、他のユーザに対して権限を付与することができる権限のことです。当然のことながらGRANT権限は通常管理者用ユーザにか付与しません。

IP制限をかける場合は以下の要領です。

GRANT ALL ON *.* TO adminuser@'172.16.0.0/255.255.255.0' IDENTIFIED BY 'password' WITH GRANT OPTION;

【2.一般ユーザを作りたい】
全てのデータベースにアクセスできる一般ユーザは以下の要領で作ります(WITH GRANT OPTIONがないのに注目)。ただし全てのデータベースにアクセスできる一般ユーザをGRANT ALL ON *.*で作ると、SUPER権限がつくのでinit_connectが無視されるなどの副作用があるそうです。(sh2さんご指摘ありがとうございました)

GRANT ALL ON *.* TO testuser@'%' IDENTIFIED BY 'password';

特定のデータベースにアクセスできる一般ユーザは以下の要領で作ります。

GRANT ALL ON testdatabase.* TO testuser@'%' IDENTIFIED BY 'password';

SELECT,INSERT,UPDATE,DELETEしかできない一般ユーザは以下の要領で作ります。

GRANT SELECT,INSERT,UPDATE,DELETE ON testdatabase.* TO testuser@'%' IDENTIFIED BY 'password';

【3.レプリケーション用ユーザを作りたい】
MySQLの大きな特徴であるレプリケーションを行う場合、MASTER DBに以下の要領でユーザを作ります。

GRANT REPLICATION SLAVE ON testdatabase.* TO repl@'172.16.0.0/255.255.255.0' IDENTIFIED BY 'password';

【最後に】
柔軟な権限設定ができるシステムは多いですが、概してどれも設定が複雑になるんですよね。しかし前提知識として今回の内容程度を押さえておけば、日常運用程度ではなんとかなるし、応用も利くようになるのではないでしょうか。

オープンソースソフトウェアのからくりとしくみ

先日本屋の中でぶらぶらしていたら、なかなか良い本を見つけたのでご紹介してみます。オープンソースソフトウェアがどのように作られていて、またどのように作れば良いか具体的に説明されていて結構面白かったです。オープンソースってプログラミング力以前にどういうルールで作ればいいのかという段階でつまずくことがありますが、この本があればそのレベルは軽くクリアできます。

こういう実践的な情報はWEB上でもなかなか見つからないので貴重です。内容が結構良いのに無名（だと思う）なのはもったいないです。

以下引用。

「システム管理者もオープンソース開発者も必読の1冊!
OSSのブラックボックスを丸ごと解説!!
本書は、Linuxが「どのように構成されているのか」「その構成要素はどのよう
にして作られているのか」についてを平易に解説、UNIX系OSを裏側から支える
数々の仕組みを理解できます。Linuxを日常的に利用しているシステム管理者は
もちろん、オープンソース・ソフトウェアを開発しようとする開発者や、オープ
ンソース・ソフトウェアの開発に何らかの貢献をしたいと考えているユーザ
は必読、今までブラックボックスにしていたLinuxソフトウェアの裏側も、この1
冊でわかります。

コンパイルやリンク、ビルドはもちろんパッチやマニュアル、RPMまで、UNIX系OSを裏側から支える数々の仕組みを解説。Linuxを利用しているシステム管理者やLinuxについての知識を深めたい方はもちろん、オープンソースソフトウェアの開発/貢献を考えている方は必読の1冊。」

大規模システム構築と小規模システム構築の大きな違い(その1)

「小規模システムの構築」と比べて「大規模システムの構築」はなんだかものすごく高度で難しい印象を持つかもしれません。しかしどちらが高度で難しいかと問われればそれぞれ作業内容が大きく異なりどちらとも言えない気がします。そこで今回は両者どのように作業内容が違うためどちらが高度で難しいと言い切れないのかを考えてみたいと思います。

【小規模システムは全てを自分でやらないといけないので難しい】
小規模サイトの場合は担当者が自分一人しかいないということがよくあります。しかし例え小規模であっても押さえなければならないポイントは大規模サイトのそれとは大きく差がないと言えるため、実は広く深い知識と経験が必要なのが小規模システムの構築と言えそうです。

例えばいわゆる一般的な2階層式(=WEB+DB)WEBサイトをリリースするとします。この場合に必要な知識は例えばサーバ、OS、WEBサーバ、セキュリティ、ネットワーク、SSL、メールなどなど。これらを一人だけで一通りこなすというのはある意味高度で難しいと言えます。

【大規模システムは全体の構成を考えるのが難しい】
一方、大規模サイトの場合は担当者が数名でかつ予算がそれなりに用意されている場合が多いです。この場合自分はある特定の部分だけ担当すればよいので気が楽です。また手厚いベンダーのサポートを受ける予算があるので、何か問題に突き当たったときにいちいち検索して調べなくてもベンダーに連絡しておけばすぐに回答が帰ってきます。このことは実は自分自身が高度な技術を持っていなくてもある程度なんとかなってしまうことを意味します。

ただし大規模システムの場合、システムを構成する要素が多くて何をどう組み合わせるのか設計するのが難しいと言えます。また小規模システムと比べて購入するハードウェアが非常に高価な場合が多いので、何を購入するかの選定が非常に難しいです。例えばネットワーク機器を購入する場合、メーカー毎にどのような違いがあり、どのような機能差があり、パフォーマンスはどうで、実績はどうで、拡張性はどうで・・・等々、気にすべき要素が多くて非常に悩みます。

【結論】
思うに、小規模システムの構築は職人技の世界なのに対して大規模システムの構築は意思決定の世界な気がします。つまり、小規模システムの構築では担当者の知識と経験が全てなのに対して、大規模システムの構築では担当者を誰にしてどのベンダーを選定してどの機器を採用して等々、大半の時間を選ぶという作業に費やすことになります。

この機会にインフラエンジニアである皆さんがどちらの世界を目指そうとしているのかをちょっと考えてみても良いかもしれません。

【書評】Software Design 総集編 【2000~2009】(DVD付)

献本いただきましたので書評を書かせていただこうと思います。

まずは、なんといっても10年分の記事ですからものすごいボリュームです。昔読んだ記事がちらほら見られとても懐かしい気持ちで一杯になりました。これだけのボリュームがわずか2000円ちょっとですからすごい時代ですよね。HDDの中にDVDの中身を全てコピーしておくだけでもリッチな気持ちになれそうです。^^

ドッグイヤーで進化するIT業界の10年分ですからある意味情報の博物館みたいな感覚を覚えます。ベテランの方にとっては懐かしい歴史の振り返り、若い方にとってはIT業界の技術やトピックの進化を順を追ってたどっていけそうです。

編集者の方曰く刷った部数が少なくて増刷の予定も特にないそうですので、買えるうちに買っておいたほうがよいかもしれません。

【雑談】 TCPとUDPの違い

TCPとUDPの違い。恋人同士の会話はTCP、夫婦間の会話はUDPと覚えればよいです。

高価な機器を使ってITインフラ構築するということ

最近のIT系雑誌やIT系書籍では安い機器を組み合わせてITインフラを構築する記事ばかり。高品質な機器を使ってITインフラ構築する技が書かれた記事を全然見なくなった気がします。私が大学生のときとは時代が変わったということなのでしょう。当時UNIXと言えばEnterprise UNIXの代表格であるSolarisが皆のあこがれで、当時システム一式が数十万円とか100万円とかしていました。無論Linuxもありましたが当時のLinuxは今のように手軽に扱えるディストリビューションがあったわけでもなく、そこそこマニアックな存在でした。

高品質で高価な機器を扱う場合は緊張度や真剣味が全然違います。パーソナルLinuxのように手軽に扱えるものばかり扱うのと違い、高品質で高価な機器を扱う場合は設定事例などを検索にかけてもまず出てきませんので、どうしても自分で周辺知識をきちんと勉強した上でもろもろ自分で判断して設定に落とし込んでいく必要があります。こういった習慣は奥の深いインフラ系エンジニア育成にとても有効だったと思うのですが、最近はなかなかそういう機会や環境が与えられることが少なくなってしまい残念なことです。

ちょっと行き詰まったらひたすら検索して答えだけを探す風潮や、「マニュアルやRFCを読みなさい」と言うとすぐに「英語読めません」という答えが返ってくる風潮はなんとかならないのかなぁと思ってしまいます。

【雑談】 砂漠にデータセンターを作るのはどうだろう

ちょっと思いついたんですが、砂漠にデータセンターを作るのはどうだろう。

通常データセンターで問題になりそうなのは

・土地代の問題
・電力確保の問題
・冷却対策
・安定したネットワーク回線の問題

などがありそうなんですが、砂漠だったらこれらを全て解消できるのではないかとちょっと思いました。個別に見てみます。

【土地代の問題】
土地がいくらでもある砂漠なので、まずはこの問題はクリアですね。

【電力確保の問題】
太陽エネルギーをいくらでも活用できる砂漠であれば電力問題もクリアできそうです。

【冷却対策】
太陽エネルギーをいくらでも活用できるので、強力な冷却装置を設置することで冷却対策もなんとかなりそうな気がします。通常冷却を強くすれば排熱がすごくなりますが、砂漠なのでいくら排熱を出そうが大きな問題にはならない気がします。

【ネットワーク回線の問題】
砂漠にネットワークを引き回すのは大変かもしれないですが、海底ケーブルみたいなことが実現できたんだから、砂漠ケーブルも実現できるに違いない。

という感じですが、無論素人意見なのでいろいろ問題があるんでしょうね。どんな問題がありそうかこのあたり詳しいかたのご意見をいただけましたら幸いです。

これだけは知っておきたい ネットワークの常識

サーバの本に続き、「これだけは知っておきたい ネットワークの常識」という本を技術評論社から出版させていただきました。著者は坪井 義浩さん、工藤 修一さん、そして私(監修)です。

この本には以下の特徴があります。

・（なぜか世の中であまり見かけない）中級～上級を目指す方向けの入門本です。
・多くの初心者向けの本みたいに重要なことを端折って書いたりしていません。ただし正確性を重視したため、文章はやや硬派と言えます。
・ネットワークエンジニアと呼ばれる人が知っていないといけない事項をもれなく詰め込んでいます。プロトコルやフレーム、パケットというレベルはもちろんのこと、IPv6、BGP、トランジット、およびピアリングなども本書でカバーしています。

書店でよく見かけるネットワークの本は、中小企業の社内システム程度を想定したやさしい内容のものばかりです。しかしそういった本しか読んでいない人は多分知識不足で実際の現場では使い物になりません。

そこで本書では、ネットワークの入門書で勉強した人が次に読む本として構成しました。また現役のネットワークエンジニアの方も、自身が足りない知識を補うために一通り目を通してみるというのも良い使い方です。

また、個人的なおすすめは用語集です。本書での用語集では、私が主要ネットワーク機器メーカーのパンフレットの中から意味不明だと思った用語をピックアップして、それに対して解説をしています。ネットワーク機器のパンフレットって何故か「このスイッチはASICを用いたノンブロッキングL2スイッチです」のような意味不明な書き方をされていることが多いですが、こういったものをきちんと読み進められるように用語集を作りました。この用語集は自分で言うのも何ですが結構役に立つと思っています。

是非店頭でご覧いただけたらと思います。よろしくお願い致します。

※追記
技術評論社金田さん、著者の坪井さん、工藤さん。この半年本当にお疲れ様でした！

これだけは知っておきたい サーバの常識

本日「これだけは知っておきたい サーバの常識」という本を技術評論社から出版させていただきました。著者は小島太郎さん、佐藤尚孝さん、そして私(監修)です。

この本には以下の特徴があります。

・サーバの全体像を理解することができる入門書です。（専門学校の授業教材などにいかがでしょうか）
・電車の中でも読み進められるように、やさしい文体で書いています。（堅苦しすぎると寝ちゃいますので）
・でも必要なことは端折らずに詰め込んでいます。（エニーキャスト方式とか、ローエンドサーバとハイエンドサーバの違いとか・・・）

よくある入門書だと、ただサーバの機能や用語がずらずらと書かれているだけで、一通り読んでもサーバの全体像がイメージできないということがよくあります。サーバの機能や用語を調べるだけだったらネットで検索すれば十分です。

そんなこともあり、この本ではサーバの全体像を理解してもらいながら、結果的に今自分は何を知っていて何を知らないのかを自分自身で発見してもらえるように構成しました。この本を読んだ後別の本でさらに勉強を進めていき、壁にぶちあたったらまたこの本に戻って確認する、という使い方でしょうか。

この本で込めたかったメッセージは2つあります。

1つ目は、「ハイエンドサーバってこんなにすごい。ハイエンドサーバで使われた機能や仕組みがどんどんミドルエンドサーバやローエンドサーバに技術移転されてきている。なので将来のサーバ像を知りたければ今のハイエンドサーバを見ればいい」ということです。今Windows7などで「64bitだからメモリをたくさん使えたり、仮想化が使えたりするのですごい」と叫ばれていますが、ハイエンドサーバではそんなの数十年前から普通に実現されていました。

2つ目は、このblogで繰り返し述べているように、ローエンドサーバであってもハイエンドサーバであっても、要はCPU、メモリ、ディスクI/O、そしてネットワークという要素で構成されているということです。普段なかなかハイエンドサーバを見る機会はないかと思いますが、このことさえ押さえておけばどうってことはないということです。

是非店頭でご覧いただけたらと思います。よろしくお願い致します。

※追記
技術評論社金田さん、著者の小島さん、佐藤さん。この半年本当にお疲れ様でした！

Windows PEってご存知ですか？

意外と知らない人が多いようなので、ご紹介してみます。

Windowsのプレインストール作業（PCベンダーなどが出荷前のPCにWindowsをインストールする作業）やリカバリなどを行なうための環境として、Windows PE（Windows Preinstallation Environment）というものがあります。普通のWindowsと比べてもろもろ機能制限がありますが、無償で使えます。

Windows PEはWindows AIK(Windows Automated Installation Kit) に含まれています。

Windows AIKはこちらから入手できます。(こちら)

詳細はWikipediaなどをご覧ください。(こちら)

RAID6の正確な定義とは

いよいよ今月こちらの本が出版されるのですが、その本を執筆している最中、「そういえばRAID6の正確な定義って何だろう？」という話になりました。

よく知られているRAID6の定義としては「パリティ情報を2本のHDDに書き込むので、HDDが2本死んでもデータが飛ばない」というものです。しかし曖昧なのは、どのようなパリティ情報をHDDに書きこむのか、というところです。この件、文献によって書いてあることに差があります。例えば「RAID5のパリティ情報をもう1つ他のHDDにも書き込んだものがRAID6だ」というものや、「RAID5のパリティ情報とは別のアルゴリズムで算出したパリティ情報を他のHDDに書き込んだものがRAID6だ」など。

RAID1-5に関しては明確な定義があります。Wikipediaによると「1988年にカリフォルニア大学バークリー校のデイビッド・パターソン, Garth A. Gibson, Randy H. Katzによる論文「A Case for Redundant Arrays of Inexpensive Disks (RAID)」に於いて提唱された。これはSIGMOD Conference 1988: pp 109-116 で発表された。」ということでした。しかしRAID6に関しては。いつどこで誰が定義したのかを明確に述べた文献が存在しませんでした。

それを踏まえて、日本語の文献は間違いが多い（1次情報を調べず2次情報を鵜呑みにすることが多い）ため、英語の文献を中心に調べてみました。いろいろ調べてみた中で、英語版のWikipediaに書いてあった内容が一番本当っぽい気がします。

Implementation
According to the Storage Networking Industry Association (SNIA), the definition of RAID 6 is: "Any form of RAID that can continue to execute read and write requests to all of a RAID array's virtual disks in the presence of any two concurrent disk failures. Several methods, including dual check data computations (parity and Reed-Solomon), orthogonal dual parity check data and diagonal parity, have been used to implement RAID Level 6

http://en.wikipedia.org/wiki/RAID6#RAID_6

超ざっくり訳すと

「SNIAというストレージベンダーの業界団体によると、RAID6の定義は、2本の仮想ディスクで読み書きに失敗しても処理を継続できること。RAID6の実装には二重チェックデータ計算、直角二重パリティチェック、及び斜めのパリティチェックを含む、いくつかの方法があります」

ということです。つまりはRAID6とは2本のHDDが死んでもRAIDが死ななければ何でもいいということになりそうです。すなわち、パリティ情報の書き込み方についてはベンダーによって実装方法が違うかもしれないという結論ですね。

いろいろなデータベースのバージョンの調べ方

いろいろなデータベースのバージョンの調べ方をまとめてみました。（追加すべき情報がありましたら情報提供をお待ちしております)

■MySQL
select version();

■PostgreSQL
select version();

■Oracle
select BANNER from SYS.V_$VERSION;

■SQL Server 2005
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

SQL Server 2005 SP3: 2005.90.4035
SQL Server 2005 SP2: 2005.90.3042
SQL Server 2005 SP1: 2005.90.2047

■SQL Server 2000
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

SQL Server 2000 SP4: 2000.8.00.2039
SQL Server 2000 SP3a: 2000.80.760.0
SQL Server 2000 SP3: 2000.80.760.0
SQL Server 2000 SP2: 2000.80.534.0
SQL Server 2000 SP1: 2000.80.384.0

「生きてる」自宅サーバー運用

7月にThinkITさんで自宅サーバー関連の連載を持たせてもらいましたのでご紹介させていただきます。

第1回：自宅サーバーを立てるメリットとデメリット 
第2回：自宅サーバーを作ってみよう 
第3回：自宅サーバーを粋に使いこなそう 

※余談
ThinkITはシンクアイティーではなくてシンクイットと読むとのこと。お間違いなく。^^

もしRAIDボードが壊れたら

ハードディスクは壊れやすいのでRAIDで冗長性を確保することが多いですが、RAIDボードは壊れにくいのでRAIDボードが壊れたらどうしようというところまで考えている人は意外と少ないです。

もし今RAID5でサーバを組んでいたとして突然RAIDボードが壊れたとしたらどうなるか。「RAIDボードが壊れたら単に新しいRAIDボードに交換すればよいのでは？ 」と単純に考える人もいると思います。しかしもしそうだとしたらRAID設定した情報はどうやって復元しましょうか。「え？単に同じ設定を新しいRAIDボードに同じように施せばよいのでは？」と思うかもしれませんが、この方法で本当に大丈夫なのでしょうか？

と、今回はそんなことを考えていきたいと思います。

【RAID構成情報ってどこに書かれている？】
RAID構成情報ってどこに書かれているか。高価なRAIDボードであればRAIDボードとHDD双方に、安価なRAIDボードであればRAIDボード上だけに書かれていることが多いようです。

これを確かめるには次の手順で行えます。例えばHDD3本でRAID5を構成し、マシンの電源を落とします。マシンが停止しているときHDD1～3の順番を入れ替えてからマシンの電源を入れます。このときHDDが入れ替わったことをRAIDボードが検知してくれるようであればHDDにRAID構成情報が書き込まれています。逆にRAIDが壊れてしまったらRAIDボード上にしかRAID構成情報が書き込まれていないことになります。

【新しいRAIDボードにそれまでのRAID構成情報を移せるか】
もし高価なRAIDボードが壊れたのであれば、新しいRAIDボードに入れ替えるだけで勝手にHDDからRAID構成情報が新しいRAIDボードに引き継がれます。

それに対して安価なRAIDボードが壊れたのであればもうちょっと深く考える必要があります。

もし安価なRAIDを使っていて、[HDD1][HDD2][HDD3] & [HDD4(HotSpare)]というRAID5構成を組んだとします。これがしばらく使っているうちにHDD2が壊れてしまい、HDD2を新しいHDDに入れ替えたとすると構成は[HDD1][HDD3][HDD4] & [HDD2(HotSpare)に変わります。さて、もしこの時点でRAIDボードが壊れてしまった場合どうなるでしょう。ひょっとしたら新しいRAIDボードに入れ替えて新たに[HDD1][HDD3][HDD4] & [HDD2(HotSpare)という設定を施せば復活するかもしれないし復活しないかもしれません（使用するRAIDボードによるでしょう）。確実に言えるのは、このとき最初の設定[HDD1][HDD2][HDD3] & [HDD4(HotSpare)]にしてしまったら間違いなくRAID5は飛んでしまうでしょう。

つまり、安価なRAIDボード使っているとしたら、新しいRAIDボードに入れ替えてもRAID構成を復旧できるかどうかはボードによるし、もし対応可能なボードであっても壊れる直前のRAID構成情報を正しく把握していなければ復旧が行なえないことになります。

ただし安価なRAIDボードを使っていてもRAID構成がミラーリング(RAID1)なのであれば、RAID1には特にパリティ情報を保持しているわけではなく単にHDD1とHDD2に同じ情報を書き込んでいるだけなので、もしRAIDボードが死んでも、HDDだけ取り出してサーバに直接つなげば普通に読み書きできる場合が多いです。

というわけで、RAID5やRAID6といったパリティを用いるタイプのRAIDを組むのであれば高価なRAIDボード(数万円くらいするもの)でないと怖いですが、RAID1であれば安価なRAIDボードでもそれなりに使えるのではないでしょうか。

【高価なRAIDボードにバッテリーが搭載されている理由】
ここからは余談となりますが、高価なRAIDボードにはバッテリーが搭載されていることがあります。これはRAID構成情報を保持するためのものではなく、キャッシュデータを保持するメモリに何らかの理由で電源供給ができなくなった場合電源供給できるようにすること及び、もしRAIDボードの交換となった場合、キャッシュデータごと新しいRAIDボードに引き継げるようにバッテリーが搭載されている模様です。(DELLのRAIDボードとか)

【オンボードRAIDが壊れた場合】
マザーボードにRAIDチップが搭載されているような場合は、RAIDチップが壊れてしまうとマザーボードごと入れ替えなければならないので面倒です。

以上、RAIDについて述べてきました。RAIDって奥深いですね。

SharePoint Server2007について思うこと

Microsoft社のマーケティングのせいか、SharePoint ServerはNotesやサイボウズのように使えるグループウェアであると勘違いしている人も多いと思います。でも実際は「HTMLを知らなくてもサイトを構築できるWebベースのコラボレーションツール」という言い方が正しい気がします。

SharePointの概要はこうです。システム管理者から1枚のWEBサイトが提供されると、そこにWEBパーツと呼ばれる様々なパーツ(掲示板、スケジュール管理、ドキュメントライブラリ、Wiki、アンケート等々)を自由に貼り付け自分達が使いたいようなサイトを構成することができるというものです。そう、Google Sitesのようなものです。SharePointを使うとグループ内の情報共有が進み業務効率化が図れます。

ただしSharePointには大きな弱点が3つほどある気がします。

1.マーケティング戦略のせいかありとあらゆる機能を盛り込みすぎで、概念や用語が難解です。本を読んで全貌を理解してから取り組もう、なんて思っているとすぐに挫折します。しばらく使ってみてようやくなんとなく概念がわかってくる、というツールが気がします。

2.バグなのか仕様なのかわからないが、とにかく変な挙動が多いです。システム管理者から見て、当然こうなってこうやればいいだろうという勘がことごとく裏切られることが多いです。修正パッチも多いですが、機能が多いためか修正パッチを適用すると今度は他の問題が出てくるなんてことも。とにかくシステム管理者泣かせです。

3.InternetExplorerやOfficeと組み合わせると出来ることが増えますが、それ以外の環境だとできることが制限されます。例えば掲示板にupされたドキュメントをOutlookでメールのように読み込むことができたり、Explorer ViewというモードにするとWEB画面がExplorerのようなデザインになり大量のファイルをDrug&Dropできるようになったります。

総評。ユーザから見たらそれなりに使いやすいツールだと思います。しかしシステム管理者は地獄を見るツールです。次回バージョンアップ時はもっとシンプルで扱いやすいシステムに生まれ変わることを期待したいと思います。

Exchange Server2003と2007の比較

以前Exchange Server2003と2007を比較検証してみたことがあります。その結果、当時の私はExchange2003を選定しました。無論現在は状況が変わっているかもしれませんが、今回はその当時の状況を思い出しながら記してみたいと思います。

【パフォーマンスは概してExchange2007が上】
Exchange Serverは概してメモリをたくさん積めるほうがパフォーマンス的に有利です。そういう意味で、32bit CPUしか対応していない2003より、64bit CPUに対応している2007のほうが概してパフォーマンスが上です。

【管理のしやすさは断然Exchange2003が上】
管理のしやすさというと漠然としてますが、個人的な印象では2003は管理画面が直感的でシンプルなのに対して、2007は凝りに懲りすぎて何が何だかわからないという印象を受けました。2003だとある程度サーバ管理に慣れている人であればマニュアルを読まなくてもなんとなく設定でき、かつ運用時に内部の挙動もなんとなく把握できます。

それに対して2007はマニュアルを読み込んでも何がなんだかさっぱりわからないところから始まります。設定する箇所もよくわからないし、運用時の内部の挙動把握もどうやったらいいのかよくわかりません。2003と比べて無論使いこなせればものすごい管理ツール群なのでしょうが、使いこなせなかったので宝の持ち腐れでした。そう、2007は2003とまるっきりアーキテクチャーやGUIが異なるのです。

こう書くとわけがわからないかもしれませんが、試しに評価版を入手してご自身でインストールしてみたら違いがすぐにわかるので納得してもらえると思います。

【文字化けはExchange2003のほうが少ない】
メールといえば文字化けはとても重要です。通信する全てのMTA&MUAがRFCに準拠しているだとか、送受信する相手とは日本語しかやり取りしないという状況であれば文字化けは起きにくいのでしょうが、残念ながら平気でRFC違反しているMTA&MUAは多いし、送受信する相手は日本人だけとは限りません。そんなわけでいろいろなパターンを検証したのですが、当時はQuoted-Printable問題のためかExchange2007のほうが文字化けが起きやすいようでした。今は違うかも。

当時いろいろ検証したときのメモ書きがあったので載せてみます。(詳細は忘れました。間違ってたらごめんなさい)

・2007では送信時SubjectのEncode方式をQuoted-Printableにされてしまう。このためWILLCOM PHSにメールを送ると化ける。(注: SP1で解消されたという噂あり)

・2007ではHeaderのCharsetと本文の文字コードが一致しないメールを受信すると化ける。(明らかに送信側の問題だが2003では何故か化けない)

・2003ではUnicodeの処理が正しくないため文字化けが起こることがある。(詳細不明)

・2003/2007共Subjectの長さが76byte以上のメールを受信すると化ける。(RFCでは本来Subjectが75byte以下としているので問題なし)

・2003/2007共①㈱㎝などベンダー固有文字に対応していないメールを送受信すると化けることがある。(仕方ないのかも)

・2003/2007共送信時中継するMTAによって化けることがある。(古いMTAだと7bitが基本なので、8bitが前提のUTF-8などでメール送受信すると8bit目が失われてメールが化けることがある。JISで送れば問題なし)

【まとめ】
2003は素直な作り、2007はいろいろ高度なことをやろうとしたがうまくまとめきれなかった、という印象を受けました。そういった意味ではサポート切れ期間が2007より短いことを除けば2003のほうがお勧めです。

ただマイクロソフト製品の場合、技術革新を起こした直後の製品は使いづらいものの次のバージョンで問題点を解決してくるので、多分Exchangeの次のバージョンは高性能でかつ使いやすいものになることでしょう。

WEBブラウザーに表示されている画面を直接編集する方法

とあることを調べていてこんな機能を知りました。WEBブラウザーで適当なホームページを表示させた後WEBブラウザーのアドレスバーに以下を1行で入力してみてください。

javascript:document.body.contentEditable='true'; document.designMode='on'; 
void 0

するとWEBブラウザーに表示されている画面を直接編集できるようになります。