オープンソースでいこう

本日、サードウェアは創立15周年を迎えることができました。会社の生存率は10年で5パーセントと言われている中でこれまで営業を続けてこられたのは、お客様やお引き立てや社員の下支えがあったからと、深く感謝しております。

当社が創業した1997年は、まだLinuxはほとんど認知されていませんでした。今ではLinuxは当たり前の選択肢のひとつになっており、隔世の感を禁じえません。

Linux/オープンソースを取り巻く環境は大きく変わりましたが、当社の理念とするところは変わっておりません。それは、社名でもある「サードウェア」、すなわちハードウェアやソフトウェアを生かすのは、サポートや教育などの人の営みである、ということです。

この理念にもとづいて、技術面では電子メールなどのコミュニケーションツール、ならびに信頼性や可用性の高いサーバシステムをコア分野に据えてまいりました。Webメール＆グループウェア「Scalix」、当社が日本語対応を強化したSpamAssassinを使ったウィルス・スパム対策製品「メールフィルタ」、開発元との提携にもとづく「ThirdWare Linux-HA」などが挙げられます。

これからも、当社は上記の理念やコア分野を堅持してまいります。さらに、クラウドコンピューティングなどの最新の動向に適合する製品やサービスの開拓にも取り組み、引き続き皆様のご期待に応えられるよう精進してまいります。

引き続き、当社に対してご指導、ご鞭撻を賜りますよう、心よりお願い申し上げます。

1999年12月8日19:42:10 DRBDソースコードの初版がコミット
2009年12月8日8:19:16 LinusがDRBDコードをカーネルに取り入れた

DRBDはまもなく満10歳になります。

初版は、ミスターDRBDことPhilipp Reisnerが大学で研究テーマとして取り組んだ成果として発表されたものですが、10年間で大きく成長し、2年前にはLinuxカーネルに正式に取り入れられました。

私が初めてDRBDを使ったのは2003年だったので、まだ4歳頃だった、ということになりますね。バージョンは0.6で、多少安定性に問題がありました。データが壊れるとかいう信頼性の問題はなかったのですが、何かのはずみでデータ領域全体の同期を取り直してしまうという問題があったことを記憶しています。

現行バージョンのバージョン8は、その前の0.6や0.7と比べて格段に成熟度が高まっていて、ネットワーク越しにデータをリアルタイムに複製(レプリケート)するツールとしては、商用製品をしのぐ仕様と多数の利用実績を持っていると思います。高可用クラスタの基盤としてだけでなく、最近では災害対策のためのリモートバックアップツールとしても使えるようになっています。

Philippに「おめでとう」のメールを送ったところ、上記以外のこれまでの主なマイルストーンを教えてくれました。

2004年7月16日 DRBD 0.7リリース
2007年1月24日 DRBD 8.0リリース
2008年12月18日 DRBD 8.3リリース
2011年7月18日 DRBD 8.4リリース
201?年?月?日 DRBD 9リリース(予定)

初期の頃の論文をDRBDの主な論文は、http://www.drbd.org/home/publications/にまとめられています。

ウチではDRBDを中心にしたクラスタやリモートバックアップをサポートしているわけですが、まもなく11年目に入るDRBDがますます広く使われるよう、精進していきたいと考えています。

ところで、最近facebookでの情報提供も始めました。Philipp他の写真などもアップしていますので、よろしければご覽ください。

DRBD開発元のLINBIT社との打ち合わせのため、オーストリアのウィーンに来ています。土曜日(10/1)に着いたのですが、今回で４回目ということもあって、いろいろと歩きまわっています。

今回は、オーストリアの携帯電話やモバイルデータ通信にチャレンジして、一応うまく動作したので、備忘録を兼ねてこちらの状況をお知らせします。

まず、こちらではファーストフードや観光地のレストラン以外は、土曜日は早く終了するし、日曜日は閉店です。このため、実際にSIMカードを購入できたのは月曜日でした。

電話

あらかじめSIMロックを解除したXperiaを用意してあったので、電話についてはeetyという会社のSIMカードをショップで購入して挿入するだけで、あっさりとつながってしまいました。起動時にSIMを有効にするために毎回４桁のPINコードを入力するのがちょっと面倒ですが。

eetyを選んだ理由は、日本への電話料金が非常に安いため。乱暴に１ユーロ＝100円と換算してみると、日本の固定電話と携帯電話への料金は、それぞれ12円/分、25円/分程度です。毎回の接続ごとに接続料金が10円程度かかるのですが、国内での通話料金と比べても安いくらいかと思います。

eetyのサイトに接続すると、ほとんどがドイツ語表示になってしまいますが、通話履歴と現在の残高がリアルタイムに確認できるのも便利です。

初期のSIM料金は10ユーロで、５ユーロ分の通話料金が含まれています。これで、日本の固定電話に対して少なくとも20分以上電話がかけられるので、チャレンジした甲斐があったというものです。

なお、このSIMは電話専用で、データ通信はできません。

データ通信

こちらは、大手のOrange社のDatenpaket LというSIMを買いました。料金は約30ユーロと少し高いのですが、1GBまで転送できる10ユーロ分の使用権込みです。何も使っていなくても海外パケ・ホーダイで毎日1,000円以上かかってしまうことを考えると、数日の滞在ならこの方が圧倒的に安い計算になります。1GBあたり10ユーロは、日本通信のb-mobile Fairが1GBあたり9,800円なので、１桁安いですね。

SIMフリーのE Mobile WifiルータにSIMをセットして、PCからWeb設定ツールにアクセスし、APN情報を登録するだけで、こちらもあっさりと接続できました(実際は多少試行錯誤してしまいましたが)。設定しなければならないのは、次の３パラメータのみで、他はデフォルトでOK。

APN名: www.one.at、ユーザ名: web、パスワード: web

ただし、毎回の起動時にPINコードを入力するのは面倒なので、設定ツールでPINコードを覚えこませる必要があります。

写真のような感じでつながって、Xperiaや他のPCなどでデータ通信ができるようになりました。Googleマップで現在の所在地を確認できるようになったので、とても安心感が高まりました。

有効期限

SIMカードごとの残高が少なくなったら、スーパーマーケットなどで売っているカードを買ってチャージ(reloadと言うのが普通らしい)すれば、ずっと使い続けられるそうです。しかし１年間何もしなければSIMカード自体が無効になってしまいます。データカードの基本料金が少し高いので、１年以内にウィーンに来られなければ無効になるのがちょっとつらいところです。

Linux-HAの最新の紹介記事を書きました。

「障害が発生しても止まらないシステムを実現したい」「災害に備えたリアルタイムの遠隔バックアップやシステムの二重化を行いたい」「大容量データをバックアップしたい」---震災以来、これらはシステムにとっての大きな課題となっている。

DRBD、Heartbeat、Pacemakerの概要や、これらを組み合わせてどのように活用できるのかを、現場の技術者だけでなく技術マネージャや経営層の方にも読んでいただけるようにまとめてみました。このため、インストールや設定方法などを詳しく書くのではなく、関連情報サイトへのリンクを豊富に盛り込むようにしてあります。

用途については、高可用クラスタはもちろん、ディザスタリカバリ・システム(災害に備えたデータのバックアップや業務システム二重化)、仮想化やクラウドとの組み合わせの可能性など、できるだけ幅広く紹介するようにしました。また、そろそろ現場で使えるレベルになってきたGUI管理ツール「DRBD Management Console」も画面写真を添えて簡単に説明してあります。

• ［1] オープンソースのクラスタソフトLinux-HA
• ［2］DRBDによるデータレプリケーション
• ［3］Heartbeatで監視、Pacemakerでフェイルオーバー
• ［4］遠隔レプリケーションで災害対策
• ［5］クラウドや仮想化環境でのLinux-HA活用法

おかげさまで、初日はアクセスランキングの1位を獲得できました。ご感想やコメントはこちらでもお受けいたしますので、ぜひご一読ください。

きわめて多数の会員を管理するデータベースサーバなど、きわめて高速なディスクI/O、しかもランダムアクセスが必要なアプリケーションがあります。通常のハードディスク(HDD)では読み込み、書き込み性能ともに限界があるため、分散データベース構成で対応しているケースがあります。このような分野などを狙った製品にFusion-io社の超高速半導体ストレージ製品のioDriveがあります。IOPSやレイテンシはたしかにケタ違いです。

しかし、高速に頻繁にデータを書き換えるということは、ストレージ自体やサーバ筐体が故障したときにダメージも大きくなることを意味します。ホットバックアップしてあっても、リストアするとデータ内容はバックアップ時点の状態に戻ってしまいます。やはりここは、DRBDのようなリアルタイムの筐体間レプリケーションの出番です。

しかし、ioDriveの読み書き性能は数百メガバイト/秒のオーダーです。通常のギガビットネットワークは、パケットヘッダなどのオーバヘッドをまったく無視したとしても125メガバイト/秒が仕様上の限界です。より高速なネットワークインタフェースには10ギガビットネットワークやインフィニバンドがあります。現在入手できるインフィニバンド製品は通常10〜40ギガビット/秒の転送性能を持ち、イーサネットと比較してきわめてレイテンシが低いという特徴があります。すでに当社はサーヴァンツインターナショナル(株)とパートナーになっていることもあって、同社が取り扱っておられるMellanox社のConnectXは以前検証したことがあります。

そこで、当社の社員がioDriveとConnectXを組み合わせたときのDRBDのレプリケーション性能を調べてみました。ioDriveを単体で使った場合(非同期)と、ioDrive同士をDRBDで完全同期させた場合(同期)、そしてHDDについても同様の2パターンで、PostgreSQLデータベースのpgbenchプログラムによるトランザクション性能を計測しました。

結果のグラフを掲載しましたが、HDDとioDriveのトランザクション性能には1桁近い性能差があることがわかりました。ioDriveには可動部品がないことや、CPUやメモリとのインタフェース方式が違うため、ランダムアクセスの書き込みに強いことがうかがえます。

DRBDを使わない場合(非同期)とDRBDでレプリケーションした場合(同期)の比較については、少し開きが出ました。パーセンテージで言えば7〜8パーセントです。イーサネットの場合には、アクセスパターンによっては20〜30パーセント性能が低下することがあると言われているので、インフィニバンドの優秀さ(とくに遅延が小さいことが効いています)がうかがえます。

会員管理などといったビジネスの根幹に関わるデータベースは、きわめて頻繁に更新されるでしょうが、障害に対する備えは不可欠です。インフィニバンドとDRBDを使って2台のioDriveに同時にデータを書き込むことは「保険」として有効です。レプリケーションに伴う性能低下はありますが、データを喪失しないため、あるいは長時間のダウンを避けるための保険のコストと考えると、許容範囲内だろうと思います。

この検証試験の詳細レポートは当社ホームページからダウンロードしていただけます。

(お詫び) 当初のこの記事で、ioDriveをSSDのカテゴリの製品として紹介してしまいました。読者からの指摘で、これは正確性を欠くことがわかりました。CPUやメモリとのインタフェース方式の違いにもとづく桁違いの性能差や、長寿命設計など、高速性と信頼性が求められるサーバ用途向けの製品として位置づけるべきです。不正確な表現で読者や関係者にご迷惑をおかけしたことを深くお詫び申し上げます。

4月20日にIDC Japanはディザスタリカバリ対策への投資が増加基調になっているという調査結果を発表しました。震災後、私のところにもディザスタリカバリ対策の問い合わせが増えています。

そこで、オープンソースのLinux-HAクラスタスタックでどういったディザスタリカバリ対策が可能なのかを紹介する「Linux-HAによるディザスタリカバリの概要」というホワイトペーパーを作りました。

ディザスタリカバリは、災害でもデータを失わないようにするバックアップやレプリケーションなどのデータ保全というレベルと、データ保全をベースとして別サイトで短期にシステムを再開できる事業継続というレベルに分けて考えることができます。また、「いつまでのデータを再現すべきか」というリカバリポイント目標と、「被災後いつまでに業務を再開すべきか」というリカバリタイム目標を定めて方式を決定することが重要です。

DRBDなどのLinux-HAクラスタスタックは、ディザスタリカバリ・サイトへのリアルタイムのデータレプリケーションができることや、Windowsも含めた業務アプリケーションをディザスタリカバリ・サイトで継続できることなども、利用シーン別に図入りで紹介しました。

小俣さん(日本シー・エー・ディー)にも紹介していただきましたが、回線遅延シミュレータEthdelayを使ってWAN回線の遅延の効果を調べたグラフも入れさせていただきました。

これからの我が国では、地震などに対する災害対策と同時に、電力機器への対応も同時に考える必要があります。サーバやストレージの追加を最小に抑えていくことも重要だと思います。また、コストも抑える必要があるでしょうから、オープンソースベースの対策も検討する価値は高いのではないかと思います。

ディザスタリカバリ対策や事業継続計画(BCP)を検討しておられる方のお役に立てたら幸いです。

3月14日のブログで「東京に過度に一極集中していることも見直していく必要がある」という意見を書いたが、同様の主張がちらほら出ている。私は政治家でも都市計画の専門家ではないが、災害対策に取り組んでいる者として、その必要性を考えてみた。

私が分散すべきと考える最大の理由はリスク分散だ。

万一首都圏を直撃する大災害が起きたら、災害対策の司令塔もなくなってしまい、日本全体がダメになってしまうのではないだろうか。今回の震災で打撃を受けた東北各県を優先してもいいし、「〇〇省は△△県へ」などという誘致合戦を知事さん達にやってもらうというドラフト会議で決めるといった方法でもいい。出張所や連絡事務所と副大臣を都内に残すのはいいが、本省と大臣を全国に分散させるべきだし、現在のIT技術を使えば分散してもコミュニケーションは維持できるはずだ。

そして次の理由は、分散することによって生じる国内需要だ。

当然ながら、移転には何年かの準備が必要だ。お上が動けば、企業も動き、それに伴って人も動く。交通、建設をはじめとして、あらゆる分野で内需が拡大する。内需が拡大すれば同じ税率でも税収が増えるだろう。現在の自粛ムードや先行き不安が蔓延している状態では、災害復興の莫大な費用は、私は最終的には増税でまかなうしかないのではないかという気がしている。内需が拡大すれば、自然に税収が増え、増税が必要になってもその率は抑えられるのではないだろうか。

その他、人口バランスもだが、雇用機会、過疎、地方の医者不足、さまざまな歪の是正にも役立つのではないだろうか。

東日本大震災から3週間が経過し、復興や再建の動きが始まりつつある。数十兆円もの莫大な費用がかかるとの試算が出ているが、必要な費用を賄うのと同時に、削減できるコストは可能な限り削減する工夫も必要だ。ITの場面では、さまざまなオープンソース・ソフトウェア(OSS)が貢献できるだろう。

私は最近UbuntuやopenSUSEをメインに使っている。メール、Web閲覧、ワープロ、表計算、ビデオ視聴など、一般的なオフィスでの用途はほとんど不自由しない。OpenOfficeやLibreOfficeは、オープンドキュメントフォーマット(ODF)に加えて、ワード(docやdocx)やエクセル(xlsやxlsx)形式のファイルも読み書きできる。マイクロソフトのOffice 2010もODFを読み書きできるので、官庁、自治体、企業はODFも受け入れるようにしてほしい。すでに大阪府交野市、会津若松市などの自治体がODFを採用しているが、さらに多くの企業や自治体がODFを採用できるようになり、慣れや予算に応じた選択の自由が広がる。

また、Linuxデスクトップには、Windows 7を動かすのはつらいスペックのPCでも快適に動作するという魅力もある。Linuxデスクトップによって、ライセンスコストとハードウェアコストを大幅に削減できるだろう。

サーバ分野では、すでにLinux/OSSは金融機関を含めて基幹業務でも幅広く使われている。被災で失われたシステムを再構築するにあたって、オープンソースもぜひ考慮していただきたい。また、開発したシステムをオープンソースとして公開し、業界全体で完成度を高めるとともにコストを削減する動きがクラウド処理系などで活発だ。このような方法論は、有用性を高めてコスト削減するのに役立つと思う。

今回の震災を契機として、災害対策を検討している企業も多いようだ。Linux-HAクラスタスタック(DRBD、Heartbeat、Pacemaker)は、可用性を高めるためのクラスタ基盤として認知が高まっているが、災害に備えたデータ保全のためのバックアップや、複数拠点にまたがるシステム全体の二重化など、ディザスタリカバリ・システムにも使われている。メインサーバのデータを数十キロ離れたセンターのサーバにリアルタイムでバックアップできる。米国のMidlandという自治体では、救急車や消防車などの緊急車両の運行管理システムを2箇所のセンター間で二重化し、テロや災害に備えている。

デスクトップ、サーバ、業務アプリケーション、ディザスタリカバリなど、さまざまな場面で利用できるOSSは数多い。OSSの本質的なメリットはソースコード公開やベンダーロックインからの解放などにあるが、短期間に多数のITシステムを再建しなければならないことを考えると、ライセンス料や保守料不要というコスト面のメリットは、はかりしれないほど大きい。

東北地方太平洋沖地震に伴う計画停電の開始から約1週間経過した。原子力発電所、火力発電所が被災したため、電力供給能力が低下したのが原因なので、緊急対応としてやむを得ない措置だと思う。

しかし、18日に石原東京都知事が経産大臣に提出した緊急要望や、19日の地震発生から１週間　福島原発事故の現状と今後（大前研一ライブ579)などが指摘しているように、現在の計画停電は可能なかぎり速やかに見直して、別の節電や総量規制に移行すべきだ。

都内23区(一部を除く)が除外されていることは、一定の合理的な理由はあるとは理解できる。しかし「難しい地域を避け弱者に集中」(大前氏)、「地域的な不公平が生じている」(石原氏)という指摘を無視すべきではない。

毎日時間帯が変わる3時間単位の停電は、短期間ならやむを得ないが、長期化すると多くの企業にとって大きなストレスになる。途中で停電が入るために生産計画が立てられない業種もあると聞く。私の場合、停電が終わるたびに数台のサーバを起動するのだが、少し古い機種が混じっていることもあって、無事に起動するか毎回ヒヤヒヤしている。「大規模施設等への計画的な使用制限」(石原氏)、「週5日間を選択制で操業し平準化する」(大前氏)など、3時間単位ではなく日単位などでの調整の方が、電気をどうしても必要とする製造業の稼働にも優しい規制になるだろう。

節電を促す方向に電気料金制度を変えるという大前氏の提案も、ユニークで前向きに検討すべきと思う。

被災地の復興を支えるためにも、その周辺の地域での生産的活動の維持が欠かせない。一見公平なように見えて地域的な不公平が残る「毎日１〜２回の３時間ずつの停電」から、ピーク時の需要を引き下げられる別の規制に一刻も早く移行してほしい。

11日は船橋のオフィスで地震に遭いました。近くでガス洩れ騒ぎもあったため、夕方までWebやtwitterなどでの情報しかわからず、その夜や土曜にテレビで津波の惨状などを知り、心理的に相当なショックを受けてしまいました。これが土曜夜までの正直なところだったのでした。

でも、世界中からの支援の動きやtwitterなどの書き込みを見て、自分を取り戻せるようになってきました。

これは昨日twitterでつぶやいたことです。

3.11は、米国にとっての9.11やそれ以上のインパクトになるのではないかという気がしています。

• 原子力発電依存を続けるのか、他の方法への切り替えをはかっていくのか、こういった見直しは必要でしょう。
• 東京に過度に一極集中していることも見直していく必要があるように思います。
• 米国に比べて遅れている災害対策を、ITだけでなく組織や人の動き方も含めて対策をすすめるべきではないか。

小さな会社の社長にすぎない私ですが、これらに対して貢献できることを考えて、取り組んでいきたいと思います。