なぜサイオステクノロジーは災害対策(DR)に対応した「Disaster Recovery add-on」の提供を開始したのか!?

こんにちは。SCSK 池田です。

まだ2月だというのに、少し気の早い春を感じるようになってきた今日この頃ですが皆様いかがお過ごしでしょうか。

早速本日のお題です。

少し時間が経ってしまいましたが、昨年9月にリリースされたLifeKeeper for Linux v9.9.0で新機能として提供を開始した「Disaster Recovery add-on」について、本機能が求められるようになった経緯を私なりに考察してみました。

Disaster Recovery add-onの振り返り

Disaster Recovery add-onについては、データ同期処理にLinbit社のDRBDというソフトウェアを利用したLifeKeeperの災害対策ソリューションの名前です。こちらのSCSK技術ブログであるTech Harmonyの中でも何回か記事にさせていただきましたので、詳細のご説明はそちらに譲ります。

災害対策ということですので、地理的に離れた箇所にサーバを配置する必要があり、AWSの場合は、リージョンを跨いだレプリケーションを実現する必要があります。

データレプリケーションしたいならDataKeeperでは!?

LifeKeeperを扱ったことのある人の中にはご存じのかたもいらっしゃるかと思いますが、サーバのローカルディスク間をデータレプリケーションするソリューションとして「DataKeeper」という製品があります。

オンプレミス環境においては、比較的高価な共有ディスクを買わずとも、サーバに内蔵されたディスクを安価にレプリケーションすることができる為、とても重宝されてきました。

AWSやAzureといったパブリッククラウド環境においては、そもそも共有ディスクを構成できなかったり、できたとしても様々な制約があり構成することが難しいケースの方が大半なことから、EC2インスタンスに紐づけたEBSボリュームをDataKeeperを用いてレプリケーションする構成が主流となっています。

それならば今回のようなAWSのリージョンを跨いだ災害対策目的の構成でも、DataKeeperが使えるのではと思った方も多いと思います。

結論からお伝えすると、DataKeeperは、リージョンを跨いだデータレプリケーションには不向き なんです!

その理由をご説明していきましょう。

DataKeeperがリージョン跨ぎ構成に向かない理由

非同期レプリケーションが使えない

リージョン跨ぎの場合、どんなに低レイテンシの回線だと言われても、どうしても回線速度がネックになってしまいます。同期レプリケーション(リアルタイムレプリケーション)とした場合、DRサイト側のディスクに書き込みが完了しないと、稼働系で動作しているアプリケーションに対してI/O完了となりません。その為、回線速度の影響をまともに受けてしまい、レスポンスの低下に繋がってしまいます。

この問題は、非同期レプリケーションとすることで解決できるように感じますが、実は、Linuxのカーネルの問題により、レプリケーションタイプを非同期モード(Async mirror)に設定している場合、並列的に送られたデータの書き込み順序がまれに前後する可能性が不具合として報告されており、ファイルシステムの整合性に問題が生じる可能性があります。

簡単にイメージ化すると以下のようになります。

■本来あって欲しい処理

■カーネルの不具合により、非同期モードかつパラレルで同期した場合

このカーネルの問題に対応する為に、並列処理が行われないようにLifeKeeper for Linux8.1.2以降では、nbd(正確にはnbd-server)のスレッド数を1ケにするよう改修が行われていますが、並列処理が行われなくなったことで、データレプリケーション処理速度を犠牲にせざるをえませんでした。

このことが、DataKeeperがリージョン跨ぎ構成に向かない理由となります。

DRBDを用いたDisaster Recovery add-on機能をサポート

そこで、サイオステクノロジー社が目を付けたのが、LINBIT社製のDRBDでした。DRBDはWAN経由で遠隔地へ安定したデータレプリケーションを実現することができるソフトウェアとして、DataKeeperの代わりになると判断し、検証の末、2024年9月25日にリリースされたLifeKeeper for Linux xv9.9.0でサポートされることとなりました。

 

DataKeeperとDisaster Recovery add-onの棲み分けは?

それでは、LifeKeeperにおいて、データレプリケーション構成を実現させるためにはどのような基準でDataKeeperとDisaster Recovery add-onを選択すれば良いでしょうか?

現在、サイオステクノロジー社でサポートしているDisaster Recovery add-on構成は、リージョン跨ぎの構成のみとなっています。その為、必然的に単一リージョン内の場合はDataKeeper、リージョン跨ぎの場合はDisaster Recovery add-onを選択するという棲み分けで覚えていただければと思います。

  データレプリケーションソフト 備考
単一リージョン(マルチAZ) DataKeeper  
リージョン跨ぎ Disaster Recovery add-on 3ノード構成

 

※Disaster Recovery add-onの場合は、現時点で3ノード構成(単一リージョン内別AZに2ノード、別リージョンに1ノード)のみがメーカーからサポートされる構成となります。3ノード間のデータレプリケーションは全てDRBDを用いますのでご注意ください。

まとめ

今回は、『災害対策(DR)に対応した「Disaster Recovery add-on」の提供を開始した理由』と、同様のデータレプリケーションソフトであるDataKeeperとの違いや構成選択のポイントについて解説しました。

・データレプリケーションには、DataKeeperとDisaster Recovery add-onの2種類がある
・リージョン跨ぎの構成では、Linuxのカーネルの問題があり、DataKeeperは不向きである
・単一リージョン内のAZ間レプリケーションではDataKeeperを、リージョン跨ぎの場合はDisaster Recovery add-onを選択する
著者について
池田 雄介

中学時代にMSXを手に入れ、N88-Basicでのプログラミングを覚える。その後、ユーザ企業の情シスから社会人人生をスタート。100人に1台程度しかパソコンが割り当たっていない時代に、Windows95のパソコンを全国展開、本社、支店、工場のLAN/WAN化を推進。WindowsNTサーバを弄りながら流行りのイントラネットや社外向けのサイト作成・運用など担う。
2002年に現在のSIerへ転職。2007年からオンプレミスや仮想環境を中心としたインフラ基盤の構築に携わり、2013年からLifeKeeperを担当。以来12年に渡り、LifeKeeperビジネスに携わってきた。
趣味は、草野球、ボウリング、バドミントン、キャンプ、天体観測、ゴルフ、お酒を嗜むこと、ドライブなど

池田 雄介をフォローする

クラウドに強いによるエンジニアブログです。

SCSKクラウドサービス(AWS)は、企業価値の向上につながるAWS 導入を全面支援するオールインワンサービスです。AWS最上位パートナーとして、多種多様な業界のシステム構築実績を持つSCSKが、お客様のDX推進を強力にサポートします。

AWSLifeKeeperクラウドプロダクト
シェアする
タイトルとURLをコピーしました