サードパーティHA（高可用性）市場をDb2 Mirrorは破壊するか?
先々週、IBMが発表したDb2 Mirror for iは、大きな称賛をもって迎えられたようです。そのクラスタリング技術により、IBM iの継続的な可用性は、他のほとんどの主要なシステムで提供されているレベルに肩を並べることになります。しかし、Db2 Mirrorによって、このプラットフォームがこれまで築いてきた高可用性ソリューションの遺産が破壊されてしまうことはないのでしょうか。IBMと、論理レプリケーション ソリューション最大手のプロバイダーに『IT Jungle』が尋ねたところでは、答えは「ノー」ということのようです。理由はこうです。
Db2 Mirrorに関してまず理解すべきことは、Db2 Mirrorが、本質的にはデータベース クラスタリング技術であるということです。IBMは、「頭脳が2つある」状態にしてしまうことなく、アクティブ-アクティブ構成で、Db2 for iの1つのインスタンスを2つの別々のシステムで稼働させる方法を考え出しました。特に、IBM iの単一レベル記憶アーキテクチャーに関しては、実に見事な芸当だったと言えそうです。IBMによれば、単一レベル記憶アーキテクチャーは、この技術を開発するうえでの最大の障害だったようです。
Db2 Mirrorクラスターでデータベースをホスティングしている片方のシステムがダウンした場合、もう一方のシステムがアプリケーション サーバーからワークロードを自動的に引き取ります。そのためアプリケーション サーバーは、アクティブ-アクティブ モードが使用されている場合は別のシステムにホスティングされている必要があります（クラスターがアクティブ-パッシブ モードでセットアップされている場合は、アプリケーションとデータベースは同じシステムに配置可能）。
こうしたI/Oのリダイレクトは瞬時に行われるため、Db2 Mirrorでは目標復旧時間（RTO）ゼロへ可能な限り近付くことが可能になります。これにより、IBM iのショップには、WindowsおよびLinuxシステムのユーザーが長い間享受してきたのと同じような継続的な可用性がもたらされます。
ただし、Db2 Mirrorの機能に関しては、重要ないくつかの注意すべき点があります（少なくとも現時点でのこの技術の機能に関して）。そして、こうした注意すべき点があるということは、従来のHAがIBM i上でその役割を終えたわけではないということを意味します。それでは、最もインパクトが強いものから弱いものの順に、そうした注意すべき点について見て行きましょう。
ディザスター リカバリー（災害時回復）には不向き
Db2 Mirrorは、災害からの完全な保護を提供するものではありません。Db2 Mirrorは、厳密には、1つのデータ センター内で稼働するアプリケーションの継続的な可用性を確保するための機能であるため、データ センター全体が稼働停止した場合には役に立ちません。
この制約は、この初期リリースのDb2 Mirrorのアーキテクチャーに由来するものです。Db2 Mirrorでのデータベース書き込みおよび更新は同期する形で実行されるため（つまり、書き込みや更新は、トランザクション完了の確認をアプリケーションが受け取る前にそれぞれのノードで完了している必要がある）、待ち時間を短く抑えるために高速接続が必要となります。
IBMでは、待ち時間を短く抑えるために、2つのデータベース ノードの接続に高速のRoCE（RDMA over Converged Ethernet）ネットワーク リンクを採用しています。RoCE（「ロッキー」と発音）接続は超高速であり、実際、2つのデータベースが同一の物理マシンにハウジングされている場合よりも、データの移動が高速です。
ただし、RoCEネットワーク アーキテクチャーをこの構成に組み込むには、厳密な距離の制限があります。すなわち、2つのノードは、物理的に同じデータ センター内（あるいは少なくとも同じ構内）に位置している必要があり、両ノード間の距離は200メートル未満でなければなりません。そのようにして物理的に分離されていないとしたら、竜巻や地震、あるいはゾンビに襲われたときに、IBM iアプリケーションがオフラインになるのを防ぐ手立てはありません。
IBM iチーフ アーキテクトのSteve Will氏からは、Db2 Mirrorのこうした制約に関して率直な話を聞くことができました。「ディザスター リカバリー サイトを設けるタイプであれば、これらの他のソリューションが入り込む余地はまだ大いに残されています」とWill氏は『IT Jungle』に述べます。「けれども、肝心なデータ センター内での継続的な可用性という観点からは、これが答えということになります。」
IBM i 向けHAソリューション最大手のプロバイダーであるSyncsort社でも、要件が最も厳しいIBM i のショップには、Db2 Mirrorによって新たなレベルの継続的な可用性がもたらされることについて異論はないようです。しかし、Syncsort社は、現時点で存在しているこの技術の制約についても認識しています。Syncsort社が最新製品のMIMIX for Db2 Mirrorの発表を、IBMから大きな発表がある4月23日に合わせたのには、そういう背景があったようです。
「IBM Db2 Mirrorは、Db2データの可用性に対して要件が最も厳しい組織向けのハイエンドのソリューションと言えるでしょう」と、Syncsort社のプロダクト マーケティング担当シニア ディレクターのBecky Hjellming氏は『IT Jungle』に述べます。
「ただし、2つのデータベースが置かれているシステムは、同じデータ センター内の互いに近くに位置していなければならないため、地域的な災害、サイトの障害、またはデータ センターの稼働停止が発生した場合には、データは損失の危機にさらされます」と彼女は続けます。「MIMIX for Db2 Mirrorは、オンプレミスであれ、クラウドであれ、世界各地に位置する複数のリカバリー サーバーにデータを複製するため、あらゆる災害シナリオからのデータの保護が保証されます。」
Db2 Mirrorは素晴らしい機能であると、IBM i 向けHAソフトウェアおよびクラウド サービスのプロバイダーであるMaxava社のシニア バイスプレジデント、Simon O'Sullivan氏は述べます。
「しかし、Maxava社の顧客の95%は、リアルタイムで長い距離を越えてデータを複製することにより、地理的分離を実現しています」と彼は述べます。「ディザスター リカバリーの専門家のほとんどが、プライマリー マシンとDRマシンは100マイル（160km）以上離して配置するよう推奨しています。そうすれば、たとえば、別々の送電網の使用という意味でも、十分な距離となります。」
統合ファイル システム（IFS）がサポートされない
Db2 Mirrorの2番目に大きな制約は、統合ファイル システム（IFS）の直接サポートがないことです。
Db2 Mirrorは、Db2 for iデータベースの同期複製を提供することに重点を置いた機能です。SYSBASEに保存されているかiASPに保存されているかは問いません。Db2 Mirrorは両方の保存場所をサポートしています（また、ネイティブなレコード-レベル アクセスが使用されているかSQLが使用されているかも、まったく問わない点も素晴らしいです）。IFS内のオブジェクトは、その名の通りデータベース オブジェクトではなく、Db2 for iには保存されないため、基本的にDb2 Mirrorでは考慮に入れられません。
現行のIBMの説明書には、IFSサポートについて多少記述が曖昧なところがあるようです。IBMは、次のように記しています。「Db2 Mirrorは、iASPと完全に互換性があり、実際に、Db2 Mirror構成内でのIFSサポートのためにiASPを利用します。」
けれども、少し下には、次のような記述もあります。「IFSおよびIFSのジャーナルのサポートは、iASPへのデプロイメントを通じて実現され、これは、スイッチャブルLUNとして、または、ストレージ レプリケーションを通じてiASPのミラー ペアで構成することができます」 つまり、IFSファイルを複製するには、PowerHAで提供されるレプリケーション手法か、スイッチャブルLUNか、別の論理レプリケーション ソリューションを使用する必要があるということです。
最近では非常に多くのIBM i のショップがIFSを使用していることからすると、IFSがサポートされないことは大きな問題です。Java、PHP、Node.jsアプリケーションなど、RPGやCOBOLで書かれたのでないほとんどすべてのアプリケーションは、IFSを使用してファイルを保存しているため、問題はさらに大きくなります。
この点は、リモート ジャーナリング ベースのIBM i 向け高可用性製品の開発を手掛けるiSam Blue社の業務執行社員、Robert Seal氏の目にも留まったようです。
「DB2 MirrorはIFSを扱いません。代わりに、IFSオブジェクト専用のiASPにIFSを設定し、Power HAを使用してそれらのオブジェクトをミラーリングすることが推奨されています」と彼は記します。「IBM i の世界においてIFSはますます大きな存在になりつつあるため、IFSを扱わないということは、大きなマイナスとなるように思われます。」
Shield Advanced Solutions社CEOのChris Hird氏は、Db2 Mirrorそのものにも、さらにはDb2 Mirrorの持つ、アクティブ-アクティブの可用性ソリューションのニーズに対応できる可能性にも深く印象付けられたと述べます。しかし、彼もまた、IFSのサポートに関して、Seal氏と同じような問題を提起しています。
「オープンソース ソフトウェアというIBM i のもう一方の目標へと向かいながらも、IFSが再び特別扱いが必要な領域となるように思われることで、顧客の増加に歯止めが掛かることになるかもしれません。オープンソース ソフトウェアはIFSに依存するところが大きいからです」とHird氏は記しています。「また、オンライン マニュアルに、「このセクションは今後変更される可能性があります」というような記述が数多くあるため、IFSに対する実際の影響や制約はよく分かりません。もしかするとそれは、今後、IBMがじっくりと取り組むという印のようなものなのかもしれません。」
Robot HA製品を開発しているHelpSystems社から見れば、IFSがサポートされないことはマイナス面となるようです。「企業は様々な理由でIFSを活用し続けていますが、IFSを複製するためには、Db2の顧客はPowerHAを利用しなければならなくなります」と、同社の技術ソリューション担当EVPであるTom Huntington氏は述べます。「アプリケーションとデータを管理するためにはDb2 MirrorとPowerHAの両方を実装および管理しなければならないとしたら、多大な時間と費用が掛かることになりかねません。」 すべてのオブジェクトがサポートされているわけではない
Db2 Mirrorの3番目に大きな難点は、すべてのIBM i オブジェクトをサポートしているわけではないという点です。
IBM i オペレーティング システムは、ほとんどすべてのものをオブジェクトのように扱う点が独特です。システムでサポートされているオブジェクトは何十種類もあり、IBM i 向けHAベンダーは、2つ以上の複製システムにまたがって高可用性を提供するために、複製、適用、同期の手法および技術がそれらのオブジェクトの（すべてではないにしても）ほとんどを完全にサポートできることを確保するべく取り組んできました。
Db2 Mirrorは、ネイティブのDDSレコード-レベル アクセスでの物理および論理ファイルなどの最も重要なオブジェクトや、SQL使用時の他の数々のオブジェクト（エイリアス、関数、インデックス、アクセス権、プロシージャー、スキーマなど）をサポートします。また、ユーザー プロファイル、データ域、データ待ち行列、ジャーナル、ジョブ待ち行列、およびスプール ファイル（OUTQ）についてもサポートしています。しかし、Db2 Mirrorに対応できなかったIBM i オブジェクトもいくつかあります。
「IBMのDb2 Mirrorは、データ可用性を確保するために必要となるオブジェクトを複製しますが、たとえば、装置記述やユーザー見出しオブジェクトなど、完全なサーバー フェイルオーバーのために一般に必要とされる重要なオブジェクトがすべて複製されるわけではありません」と、Syncsort社のHjellming氏は述べます。「MIMIX for Db2 Mirrorは、アクティブ-アクティブ構成で、IBM Db2 Mirrorによってサポートされない重要なオブジェクトをデータベース ノード間で複製し、計画的または計画外のサーバー稼働停止の場合に安心して利用できるフェイルオーバーを保証しています。」
Maxava社のO'Sullivan氏も、同じ制約について指摘します。「ユーザー見出しオブジェクト、ユーザー待ち行列、ユーザー スペースなど、Db2 Mirrorではサポートされない重要なオブジェクトがいくつかあります」と彼は述べます。「Maxavaを使用することで、これらも確実に複製できます。」
高コスト
Db2 Mirrorのライセンス料は、1コアにつき20,000ドルです。大型マシンをペアにしてDb2 Mirrorを稼働するとなると、ソフトウェア コストは一気に6桁に変わります。もちろん、顧客がDb2 Mirrorから得ることができるメリットは、他にもあります。たとえば、本番ワークロードの複数マシン分散機能や、組み込みのロード バランシング機能も利用できます。しかし、従来のHAに比べると、かなり高額と言わざるを得ません。
もっとも、このソフトウェアはスタート地点に立ったばかりでもあります。理由はまだ明らかではありませんが、Db2 Mirrorは内部ストレージで構成されているサーバーでは機能しません。外部SANが必要であり、SANは非常に高価です。さらに、ユーザーはRoCEカードに対しても、1枚約4,000ドルもの大金の支出が必要になります。
O'Sullivan氏は、Db2 Mirrorには、発表されているような、「9」が5つ並んだ可用性（つまり、99.999％のアップタイム）を実現できる可能性があり、これは計画外のダウンタイムが1年間で5分ないしは6分程度ということになる、と述べています。
「しかし、最もコストが掛かるのは、常にその最後の「9」のところです」と彼は指摘します。「同じロケーション内のSAN利用の2台のIBM i マシンが超高速接続されていて、ライセンス料は1コアにつき20,000ドル。Db2 Mirrorを採用するのは、HAのためにそうした予算支出を賄うことができる最上級のIBM i ユーザーということになるでしょう。」
結論: HAはなくならない
これら4つの制約（DR機能がない、IFSサポートがない、一部のオブジェクトのサポートがない、コストが高い）があるということは、裏を返せばHAベンダーがDb2 Mirrorを怖れていないということでもあります（少なくとも今のところは）。
「このソリューションにより、特に銀行や医療機関において、これらの非常に大型のビジネスクリティカルなアプリケーションのニーズが解決されるのは喜ばしいことです」とHelpSystems社のHuntington氏は述べます。「100メートルの距離間でのデータ転送速度や、ロード バランシングを行う機能には実に感心させられました。けれども、マイナス面もいくつか見受けられます。」
それらのマイナス面は、「IBM i 市場には論理レプリケーションのための場所が間違いなくある」ことを意味している、とHuntington氏は続けます。「すべての企業がそうした実装コストを賄えるわけでもありませんし、究極的なアップタイム要件が満たされることを求めているわけでもありません。」
「IBM i に関しては新しくエキサイティングなものは、何であれ良いものです」とShield社のHird氏は述べます。「IBMは、長い間、宙に浮いていた要件に対処しようとしているのだと思います。それは論理レプリケーションが解決しようと取り組んでいる要件であり、すなわち、それはアクティブ-アクティブ レプリケーションです。しかし、私の知る限りでは、現時点でShield社への影響はほとんどないと思われます。」
「かなりエキサイティングだと思います」とMaxava社のO'Sullivan氏は述べます。「IBMが可用性の分野をリードしてくれるのであれば素晴らしいことであり、そのことは、エンタープライズ ユーザーをIBM i につなぎとめておくもうひとつの強力な理由となります。しかし、市場をリードするのは論理レプリケーションであり、それは今後も変わらないでしょう。HAについて真剣に考え、この種の技術に投資する顧客は、ディザスター リカバリーについても真剣に考えているものです。つまり、データベースをデータセンターから別の都市や州や国へ複製する機能も求めているということです。これこそが、モニタリング、データ キャプチャー、セキュリティ ソリューションと並んで、Maxava社の専門としているところです。」
「Db2 Mirrorは、よくできた製品であるように思います」とiSam Blue社のSeal氏は述べます。「しかし、Db2 MirrorをHA計画の一部として使用しようという場合には、制約のせいで、ユーザーは2つ目の製品の購入が必要となります。」
「業界内の他のソリューションによって、ゼロに近いダウンタイムが求められる環境向けのアクティブ-アクティブ レプリケーション ソリューションの重大な特質が実証されるところを目の当たりにできるのですからワクワクしてきます」とSyncsort社のHjellming氏は述べます。「もっとも、ソリューションが対象としている範囲をきちんと認識しておくことは重要です。IBM Db2 Mirrorは、計画的なメンテナンスやデータベース ノードの障害によるダウンタイムを防ぐことによって、互いに近くにある2つのアクティブなデータベース間でDb2データの継続的な可用性を提供するハイエンドのソリューション、ということになるかと思われます。けれども、Db2 Mirrorは、リモートまたはクラウドベースのサーバーへのレプリケーションを通じて災害シナリオからそれらのソリューションを保護するものではなく、フルサーバー高可用性ソリューションというわけではないのです。」
