今 NonStopイノベーションという会社に勤めています。
昔 TandemといわれたシステムがNonStopという名前でHPEから販売されていますが、その技術支援が主力事業になっています。（Open系の構築も行っているので、双頭の鷲といえばカッコいいですが、こんな小さな会社なのに方針が絞り込めていないともいえます。）
長いこと、Open系のDBやHAの構築を生業にしてきたものとして、なぜShared NothingのTandemが生き残ってきたのかが不思議でした。
実際に入社して、SQLMXのエンジニアとしてNonStopに触れるようになり、理由が少し分かってきた気がします。

やはりよくできたOSであることが大きいです。
とても古いOSですが、いまだに斬新といえる設計思想で構築されているので色あせません。 自分はよく一周回って気が付けば最先端にいると言っています。

ハードの進歩によって単体性能を向上させてきたコンピュータですがそろそろ限界に達してきていて、HADOOPだとか分散型クラウドシステムだとか、 世をあげて分散処理に移行していますが、気が付けばみんなが目指す先にある姿と同じものを、すでに前世紀から動かしていたのがNonStopだと思います。

例えば、単体OS（例えばLinux）の場合、1,000接続ぐらいになってくると、Thunder Stormという現象が起きます。 休止しているプロセス群に接続依頼のイベント（実際にはSignal）が発生すると候補プロセスが一斉に目を覚ますためにプロセス起動の雪崩が起きて一瞬システムが止まることが起きます。
そうでなくても、通信はOSの管理下にあるので、必ずどこかのデーモンがネックになって性能の限界が発生します。
さらに、分散化を進めると、2Phase Commitに代表される”分散化”のコストが重たくなり、サーバを追加すると性能が劣化するという悲劇も普通にあります。
ハードを2倍にすると1.5倍ぐらい性能が出ればよしという世界です。

一方、NonStopでは、プロセスもファイルもすべてオブジェクトと考えられていて、そのオブジェクト間の通信（情報の受け渡し）でシステムを構築するという設計思想なので、どんなにサーバが増えようが、動きとしては同一なので性能はあまり変わりません。 その上、オブジェクトをミラー化すれば、障害にも強く止まらないシステムの一丁上がりとなります。

NonStopでは実際にはブレードですが個々のサーバをCPUといいます。そして、そのCPUの上に各オブジェクトを配置して、どこかのCPUが落ちても、ディスクが壊れても大丈夫なように設計・設定します。 各プロセスはプロセスペアを構成していて、概ね同じ情報を共有しているので、メインで動いているプロセスが落ちてしまってもバックアップのプロセスが処理を引き継ぎます。
そのため、CPUが１つ落ちてもそのまま業務が継続します。プロセスオブジェクトはCPU#2とCPU#3に両方にまたがっていて、CPU#2で動いていたプロセスが落ちたら、CPU#3にある同じプロセスオブジェクトを点灯するイメージです。 （実際には瞬時に切り替わります）

何がすごいって、OSの隅々まで分散を前提に作られていることで、こういった高可用性や分散処理については利用者は気にすることがない（というか少ない）ことで、全体を１つのサーバと考えて扱うことができます。 最近のPCではマルチコアで内部では複数のCPUが動いているということが当たり前になっていますが、かなりこれに近い感覚です。

まだまだ色々な魅力がありますが、ひとまずはこんなところで。