アプリケーション整合性のあるデータ保護を Compute Engine ワークロードに実現

※この投稿は米国時間 2021 年 7 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

Compute Engine は極めて要求の厳しいワークロードに対して、信頼性の高いデータ保護インフラストラクチャを提供しています。このインフラストラクチャは、Google をはじめ、エネルギー、小売、メディア、金融などさまざまな業界で大規模なミッション クリティカル サービスの基盤として活用されています。

本日、Google はアプリケーション整合性のある Linux 向け永続ディスク スナップショット フックの提供開始を発表いたします。このスナップショット フックはスナップショットとマシンイメージで利用できます。新しい OS テクノロジーにより、Linux インスタンスでスナップショットやマシンイメージを取得する前または後でカスタム スクリプトのフックを実行できるようになります。API、コンソール、gcloud CLI は Windows ワークロードで利用可能な既存の guestFlush フラグを再利用するため、Linux と Windows それぞれのプラットフォームのワークロードに同じ自動化を簡単に適用できます。ドキュメントについては、Linux アプリケーションの整合性のあるスナップショットの作成をご覧ください。

スナップショットのクラッシュ整合性とアプリケーション整合性

データがバックアップされる際、クラッシュ整合性かアプリケーション整合性で保存されます。データの状態が、マシンの電源が突然切れたのと同じような状態になった場合、クラッシュ整合性があると判断されます。この場合、すべてのディスク I/O は完全に commit されるか、ディスク上から失われるかのどちらかになります。ある時点において、それより前に認識されたディスク I/O はすべてバックアップに取り込まれ、それより後に発行されたディスク I/O はバックアップに含まれません。

スナップショットとマシンイメージはユーザーがどのような手順を行っても、常にクラッシュ整合性です。クラッシュ整合性ではワークロードを一時停止するための操作は一切必要ありません。たいていのワークロードはクラッシュ整合性で十分であり、一時停止やファイル システムのフリーズを許容できないワークロードに適しています。

アプリケーション整合性のある保護を実現し、データ復元時にワークロードが正常に動作するようにするには、追加の状態管理が必要です。また、アプリケーション整合性を実現するには、処理中のトランザクションのメモリ状態をフラッシュする必要もあります。アプリケーション整合性では通常ワークロードが短時間一時停止されるため、これを選択するかどうかは任意です。しかし、確実かつ迅速にリカバリを行うためには、アプリケーション整合性のあるデータベース バックアップを行うことを強くおすすめします（Google の Actifio GO をお使いのお客様は、GO の独自のフックを活用することで、アプリケーション整合性のあるバックアップを実行できます）。

VM インスタンス上の複数のディスクにデータ依存関係が存在する場合、すべてのディスクでまったく同じタイミングでバックアップが取得されるように、ディスク間の整合性が必要になる場合もあります。マシンイメージでは、ディスク間の整合性を実現できます。アタッチされたすべてのディスクの状態が、保護されている VM 内で各ディスクが自動的に同期されるタイミングで、クラッシュ整合性のあるバックアップで保存されます。VM にアタッチされたディスクが複数ある場合、マシンイメージはその複数のディスクを自動的に保護します。

一時停止を許容できないお客様の中には、クラッシュ整合性のあるスナップショットとマシンイメージのみを使用する方もいらっしゃいます。ワークロードでクラッシュ整合性のあるデータを復元する場合、そのワークロードを復元する前にアプリケーション レベルのジャーナルを再度実行する必要があります。ワークロード オペレーターは、クラッシュ整合性のあるスナップショットやマシンイメージのオフライン検証を行うことで、オンライン復元を実行する前にそのスナップショットやマシンイメージが使用可能かを判断できます。

これまで、Windows VM の永続ディスク スナップショットの作成、または Windows ボリューム シャドーコピー サービス（VSS）を使用した Google マシンイメージの作成でアプリケーション整合性を確保することができました。guestFlush フラグを呼び出すことで、単一ディスクを対象としたスナップショットや、VM 上でアタッチされた全ディスクを対象としたマシンイメージでアプリケーション整合性を実現できます。これにより、VSS に統合された Windows アプリケーションと連動して VSS も呼び出されます。しかし、Linux にはアプリケーション整合性の機能がありませんでした。

Linux ワークロードのアプリケーション整合性

この記事の冒頭でもお伝えしましたが、Google ではアプリケーション整合性のある Linux 向け永続ディスク スナップショット フックの提供を開始することとなりました。このスナップショット フックはスナップショットとマシンイメージで利用できます。新しい OS テクノロジーにより、Linux インスタンスでスナップショットやマシンイメージを取得する前または後でカスタム スクリプトのフックを実行できるようになります。API、コンソール、gcloud CLI は Windows ワークロードで利用可能な既存の guestFlush フラグを再利用するため、Linux と Windows それぞれのプラットフォームのワークロードに同じ自動化を簡単に適用できます。ドキュメントについては、Linux アプリケーションの整合性のあるスナップショットの作成をご覧ください。

これまで、アプリケーション整合性が必要な Linux ワークロードでは、スナップショットの作成中にスナップショットの状態をポーリングし、ワークロードを再開する前にスナップショットが UPLOADING 状態になっているかを確認する必要がありました。guestFlush またはゲスト内スナップショット フックへ移行すると、スナップショット リソースのステータスを監視する必要がなくなり、ゲスト OS 内からアプリケーションのステータスを直接操作できます。

スクリプト フックによって、Linux ゲスト内で柔軟性とコントロールが実現し、自動化が可能になります。また、アプリケーション整合性を実現するために、スナップショットやマシンイメージの作成前に VM を停止する必要はありません。まず、スナップショットがキャプチャされる前後で実行するスクリプトを構成します。次に、gcloud CLI、コンソール、API のいずれかを使用して、guestFlush オプションを有効にしたスナップショットを作成します。これにより適切なタイミングでスクリプトが呼び出されるシステムが構成されます。Linux 向けのスナップショット フックでは、スナップショットの実行前後のカスタム自動化、ワークロードの停止と停止解除、その他のハウスキーピングやワークロード検査などが可能です。

guestFlush オプションの最大のメリットは、アプリケーションが破損されていない使用可能な状態で、スナップショットが復元されるということにあります。アプリケーション整合性は、カスタム スクリプトの動作によってのみ保証されます。スナップショット オペレーション自体では保証されませんのでご注意ください。

独自のスクリプトを統合したり、お好きなデータ保護のベンダーにソリューションを依頼したりできます。また、サードパーティのプロダクトをアプリケーション整合性のあるフックと統合することで、ソリューションに付加価値が生まれます。Commvault のプロダクト マネージャーである Anand Venkatesh 氏は次のように述べています。「Commvault では、お客様は Compute Engine で実行される SAP HANA、PostgreSQL、MySQL、その他の Linux ベースのワークロードに対してアプリケーション整合性を実現できるようになりました。構成は簡単で、Commvault Command Center™ UI で設定を有効にするだけです。お客様は、組み込みの自動化を使用するか、ご自身のカスタム スクリプトを実行するかを、バックアップの前に選択できます。このソリューションは、Commvault と Google が緊密に連携することで Compute Engine で実行されるワークロードをシンプルかつ高速な、信頼できる方法で保護できるようになる、という一例にすぎません。」

Compute Engine ワークロード保護の概要

Compute Engine ワークロードの管理と保護には、複数のオプションがあります。Windows と Linux のどちらでも、スナップショットとマシンイメージのアプリケーション整合性を選択できます。または、常に保証されているクラッシュ整合性を使い続けることも可能です。その場合はワークロードを一時停止する必要はありません。データ保護に関するその他のベスト プラクティスや、Google のバックアップと DR ソリューションに関するページもご確認ください。

-プロダクト マネージャー David Seidman