Db2 for iデータベースでのアクティブ-アクティブ ミラーリング
現在は、ミッション クリティカルなシステムでダウンタイムが許されないエンタープライズ企業にプラットフォームが導入されるようになって（System/38やAS/400とその後継を含め）40年にもなろうとしているので、RPGやCOBOLを稼働しているIBMミッドレンジ システムに、最も洗練され、かつ唯一のアプリケーションセントリックなクラスタリング ソフトウェアが備えられたとしても、それは当然のことと言えるでしょう。
IBMは、今週のIBM i 7.4のリリースに合わせて、Db2 Mirrorと呼ばれる、新たなタイプのデータベース クラスタリング機能を発表しました。これは、トランザクション処理システムにおいてどのようなダウンタイムのリスクも一切許されない顧客に向けた機能と言えます。Db2 MirrorはDb2 for iデータベースに対する追加機能で、IBM i 7.4を稼働しているPower8およびPower9システムでのみ利用可能です。Db2 Mirrorは、Maxava社やSyncsort社（2006年に競合するiTera社、2007年にLakeview Technology社を買収していたVision Solutions社を買収）、DataMirror社（IBMが2007年に買収し、2012年にRocket Software社に売却）やSheild Advanced Solutions社が販売しているハイ アベイラビリティー クラスタリング ツールとは多少異なるところがあります。この記事では、どのような違いがあるのかざっくばらんに見てみることとしましょう。
まず言えるのは、Db2 Mirrorは、2台のマシン間で、いわゆるアクティブ-アクティブ データベース クラスターを作成するということです。これは、エンタープライズ グレードのハイ アベイラビリティー クラスタリング技術の多くで採用されているアクティブ-パッシブ セットアップとは異なるものです。前者の場合、2台のマシンのクラスターが、処理を行うために利用可能で、時にはこの処理がユニークであることもあり、時にはトランザクションのコミットが2台のマシンでほぼ同時に行われるように構成されることもあります。
こうしたDb2 Mirrorセットアップは、Tandem Computers社およびStratus Technologies社の往年のフォールト トレラント マシンとは少し異なりますが、その流れを汲んでいるのは明らかであり、また、1990年に遡るSystem zメインフレーム向けのSysplexおよびParallel SysplexなどのIBMが作成したデータベース クラスタリング技術や、OracleのReal Application Clusters（RAC）の流れも汲んでいると言えます。Oracle RACは、Tru64 Unixプラットフォーム向けにDEC社によって作成されたTruClusterソフトウェアから派生したもので、VAXプラットフォームの由緒あるVMSオペレーティング システムおよびRDBデータベース向けのVAXClusterソフトウェアをベースにしています。さらにまた、部分的には、IBM独自のDb2 PureScale分散データベースの流れを汲むものであることも間違いありません。これは、AIXおよびLinux向けのIBMのDb2データベースの分散型並列データベース エクステンションで、1クラスターで最大128のサーバー ノードにスケールし、これは、Parallel Sysplexにおける32台のメインフレームや、Oracle RACクラスターにおける8ノードに比べるとはるかに多い数と言えます。またIBMは、1990年代半ばにNUMA技術での同社のハードウェアのスケール アップに苦労していたときに、TandemやStratusや、Oracle RACの前身のOracle Parallel Serverにいくつかの点で似たところがある（すべてではない）、シェアード・ナッシング クラスタリング セットアップを作成するためにDB2マルチシステムを作成したことを忘れないでおきましょう。IBMのPowerHAは、ミラーリングされたストレージ アレイおよび高速ネットワークを通じてデータのディスクベースのレプリケーションを行います。一対のサーバー間でリモート ジャーナリングを通じてデータベース レプリケーションを行うのではありません。これは1999年以降、OS/400、i5/OS、およびIBM i に備えられてきた方式です。
システム レベルおよびデータベース レベルでハイ アベイラビリティー クラスタリングを行う方法は数多くあるため、どれほど魅力的であろうと、それらすべてを探究してみるだけの時間はありません。Db2 Mirrorというのは、IBM i チーフ アーキテクトのSteve Will氏の言葉を借りれば、継続的な可用性、あるいは1つのデータセンター内でデータベース レベルで2台のマシンをミラーリングした場合と同じ程度の可用性が確保されるように、このプラットフォームでアクティブ-アクティブ データベース クラスタリングが必要だという一部のIBM i 顧客からの声を受けて、この3年間、開発が行われてきた新たな手法ということになるでしょうか。
「Db2 Mirrorは、ジャーナルベースではありません」とWill氏は説明します。「Db2 Mirrorでは、2つのシステムをペアにすると、すべてのデータベース操作が両方のシステムのデータベースでまったく同時に発生することになります。そのため、表の更新を行って、アプリケーションがたまたまそのデータベースを参照していた場合、そのデータベース操作は、両方のシステムでその更新が行われて初めて完了します。これは、PowerHAのような物理レプリケーション ソリューションではありません。似たようなことは、PowerHAでも起こるでしょうが、そのデータベースを独立補助記憶域プール（iASP）に配置して相手側へ複製する必要があります。けれども、相手側では、そのデータベースはそれに反してアクティブな処理を行うのには利用できません。つまり、Db2 Mirrorはこの点に違いがあります。ジャーナルには依存しません。また、独立ASPを使用でき、それはそれでよいのですが、独立ASPには依存しません。古いスタイルであれ、新たなスタイルであれ、特定の方法でデータベースにアクセスする必要はないのです。」
アクティブ-アクティブ クラスタリングはどれくらい広く使用されているでしょうか。アクティブ-アクティブ クラスタリングは、最新のリレーショナル データベースのほとんどを稼働しているWindowsサーバーおよびLinuxシステムで利用できますし、また、Google、Facebook、Microsoft、Amazonといったハイパースケーラーが行った仕事の流れを汲む、オープンソースとしても利用可能な、実に処理の速い並列分散データベースも存在しています。そう考えると、IBM i プラットフォームの中核にあるDb2 for iデータベースに、もっと前からアクティブ-アクティブ クラスタリングを備えることもできただろうに、とも思えてきます。ところが、それを邪魔する存在がありました。すなわち、System/38、AS/400、およびその後継の、単一レベル記憶アーキテクチャーです。
単一レベル記憶では、オペレーティング システムはメイン メモリー、ディスク、そして現在はフラッシュ ストレージの容量を、連続した単一のアドレス指定可能なメモリー スペースとみなし、データベースに関しては、違いは無視します。このアーキテクチャーはまさに独特で、世界でも類例がなく、これまでのところ、活かすことができたのはIBMだけで、IBMのミッドレンジ サーバー ラインにおいてのみ使用されてきました。システムにオーバーヘッドを生じますが、プログラミングは根本的に簡略化され、AS/400およびその後継を象徴する存在となっています。けれども、単一レベル記憶はアクティブ-アクティブ ミラーリングには少し邪魔になります。なぜなら、2人の異なる人物にまったく同じことを記憶させても、おかしなことにならないようにするようなものだからです。 Will氏によれば、Unix、Windows Server、およびLinuxのアクティブ-アクティブ クラスタリング技術は、いくぶん気楽に使用できるようです。
「その理由の一部には、それらがどのようにしてクラスタリングを行い、スケーリングを行っているかということがあります。それらの技術では、実際に、IBM i で行える以上に、ファイル システムをストレージ デバイスに委譲しています。アーキテクチャーの面からは、これまでIBM i にアクティブ-アクティブがなかった理由の1つとしては、単一レベル記憶アーキテクチャーを維持できることを望んだ一方で、複数のシステムにわたって拡大することができなかったことが挙げられます。それぞれのシステムにそれぞれ独自のアドレス空間があっても、それを行う方法を見つける必要があったのです。単一レベル記憶は、IBM i 独自のファイル システムであるからです。他のどのシステムにも、そのようなファイル システムはありません。そのため、それについて心配する必要もありません。その代わりに階層記憶システムがあるため、ロッキングや、IBM i では必要ない他の操作に時間を費やす必要があります。そのことに問題があるというのではなく、単にそういうアーキテクチャーだというだけのことです。けれども、データベース レイヤーで必要だったのは、すべての操作がクラスター全体でミラーリングできるように、すべての操作を調整することでした。そのため、ノードが多くなればなるほど、数多くの大規模なクライアントのパフォーマンス目標に対応できる可能性は少なくなります。」
それだからこそ、少なくとも初期リリースでは、Db2 Mirrorは一対のシステムに制限されています。これで十分です。より高いプロセッシング パワーを求めるのであれば、ソケットが多く、ハードウェアレベルでNUMA技術を使用した共有メモリー クラスタリングを備えたシステムを購入することができます。さらにそれ以上を求めるのであれば、Db2マルチシステムを使用してデータベース表を分割し、あのTandemおよびStratusマシンのようなシェアード・ナッシング セットアップで、並列に稼働する最大32台のマシンのクラスターに分散させてそれらを稼働することもできます。Db2 Mirrorはスケーリングではなく、継続的な可用性のための機能ですが、こんな巨大なIBM i クラスターを想像してみるのも楽しいものです。最大の32ノードがDb2マルチシステムを稼働していて、ハードウェアをスケール アウトすることによってマシンのパフォーマンスをスケール アップし、Db2 Mirrorを使用して、別の32ノードのセットで継続的な可用性が実現されている。頭がくらくらしてきますが . . . .。
Db2 Mirrorを使用するには、新たなIBM i 7.4リリース（4/24号の別記事を参照）が必要ですが、その購入またはインストールは必ず求められるというものではありません。これは、10年以上の間、Db2マルチシステムの購入が求められなかったのと同じです。Db2マルチシステムと同様、Db2 Mirrorはプラットフォームおよびデータベースに統合されていますが、別途ライセンスが必要な製品です。このケースでは、1コアにつき20,000ドルです。IBM i 7.4とDb2 Mirrorは、いずれも6月21日より利用可能になります。ちなみに、この日はAS/400の31回目の誕生日です。
今後の記事では、このアーキテクチャーについて深く掘り下げる予定です。また、リモート ジャーナリング技術をベースにしたHAソフトウェアを販売しているベンダーから、Db2 Mirrorについての感想を聞かせてもらおうと思っています。現時点で言えることは、Db2 Mirrorには、RDMA over Converged Ethernet（RoCE）プロトコルをサポートしている、2台のマシンをリンクする高速Ethernetアダプターが必要になるということです。これは20年前にInfiniBandスイッチに組み込まれたRemote Direct Memory Access技術のクローンです。これにより、マシンはリモートでお互いのメモリーにアクセスできるようになりますが、約200メートルという距離の制限があるようです（1キロメートルという話もありますが、マニュアルによると、聞いた話と違うようです）。このことが意味するのは、Db2 Mirrorは、データセンター内での継続的な可用性のためには有効かもしれませんが、リモート データセンターとの間でのディザスター リカバリーには役に立たないということです。サービス プロバイダーによるクラウドでの稼働でも、自社での運用であっても同じです。
