タイムマシンにおねがい by Nutanix Database Service
本投稿は、Nutanix Database Service (NDB)についての入門レベルの技術紹介記事です。Nutanix Advent Calendar 2022の16日目として作成しました。
Nutanix上でデータベースワークロードを動かすメリット
DBサーバー専用機など別プラットフォームで動いていたデータベースを、Nutanix上へ移行するケースが増えてきています。Nutanix上でデータベースワークロードを動かすメリットとしてはどのようなポイントがあるのでしょうか。ここでは、以下の5つを挙げました。
- DBのパフォーマンスを最適化 ⇒ ユーザの満足度を向上
- DBのストレージ使用量を最適化 ⇒ インフラコストの削減
- DBのプロビジョニングを簡素化 ⇒ ビジネスの俊敏性獲得に貢献
- 複数DBサーバーのライフサイクル管理を一元化 ⇒ 運用管理工数の削減、コンプライアンスとセキュリティレベルを維持
- DBのバックアップ&リストアとクローンを省力化 ⇒ 事業継続性の確保、システム開発やテストの効率化に貢献
1, 2はAOSのデータローカリティ、圧縮やスナップショット機能から受ける恩恵です。一方、3, 4, 5はNDBが提供するメリットです。今回はこのうち5番目のメリットに関わるNDBのタイムマシン機能について紹介します。
NDBがサポートするデータベースの種類
2022年12月現在、Nutanix NDB 2.5.1では、以下の通り主要なデータベースをサポートしています(OSバージョンや各機能との互換性を含めてはNDB Software Compatibility and Feature Supportを参照)。
データベースエンジンの種類 | サポートバージョン |
---|---|
Oracle Databsse* | 11.2.0.4.x /12.1.0.2.x /12.2.0.1.x /18.0.0.0.x /19.0.0.0.x/19.7.0.0.x /19.16.0.x /19.17.0.x *Linux版のみサポート |
MS SQL Server | 2008 (SP4) /2008 R2 (SP3) /2012 (SP4) /2014 (SP3) /2016 (SP2) /2017 (RTM) /2019 (RTM) |
PostgreSQL | 10.x /11.x /12.x /13.x /14.x |
MySQL | 5.6 /5.7 /8.0 |
MariaDB | 5.5 /10.0 /10.1 /10.2 /10.3 |
MongoDB | 4.x /5.x |
タイムマシンの設定と動作
NDBタイムマシンは、データベースのスナップショットまたはトランザクションログをキャプチャして保持します。NDBに登録およびプロビジョニングした全てのソースデータベースに対して、タイムマシンが作成されます。
特定時点またはスナップショットを指定して、データベースのクローンおよび高速なリストアの実行が可能です。特定時点のデータベースクローンの作成と配布については、開発・テストや監査の目的で、一般的にコピーデータ管理 (CDM)ソリューションとして知られています。
それでは、NDBタイムマシンの設定と動作を見ていきましょう(参考:Nutanix Database Service User Guide 2.5 および Nutanix Database Service Time Machine Tech Note)。
1. SLAの設定
2. ソースデータベースの登録とスケジュールの設定
3. データアクセス管理(スナップショットを保持するクラスタの追加)
4. データベースのログ管理
5. 最初のスナップショットとDay2以降の動作
6. 継続的なタイムマシンの運用(ログの自動パージ、特定時点へのリストア・クローン)
1. SLAの設定
スナップショット・ログ取得に関するSLAの設定が、[ポリシー]>[SLA]メニューより追加・更新可能です。[継続的なログの保持期間]の指定によってデータベースのトランザクションログを保持する日数を指定します。
2. ソースデータベースの登録とスケジュールの設定
[データベース]メニューの[ソース]よりソースデータベースの登録する際に、タイムマシンのスナップショットスケジュール指定が可能です。
スケジュール設定は[タイムマシン]メニューから[更新]アクションを選択して編集できます。
3. データアクセス管理(スナップショットを保持するクラスタの追加)
マルチクラスタの環境においては、NDBに登録した複数のクラスターでタイムマシンのデータアクセス管理(DAM)が可能です。[タイムマシン]メニューから特定のタイムマシンを選択した後、[データアクセス管理]をクリックすると、データアクセス管理のダイアグラムページに移動します。
[テーブル]タブよりタイムマシンデータを利用可能なクラスタを追加することができます。その際、DAMポリシーとしてSLAを指定します。
4. データベースのログ管理
NDBのログキャッチアップにより、特定時点へのリストア(PITR、ポイントインタイムリカバリ)を実現します。ログキャッチアップはデータベースログ(トランザクションログ、REDOログ、WALログ)をソースデータベースからNDBにコピーします。ログキャッチアップのスケジュール周期はデフォルト30分で、15分/30分/60分/90分/120分のいずれかに設定できます。ログキャッチアップの操作が実行されている間、データベースは静止しません。
Oracleの場合
現在のオンラインREDOログを切り替え、その後、最後のログキャッチアップ以降に生成されたすべてのアーカイブログをNDBの永続的なログ保存場所(ログドライブ)にコピーします。
MS SQL Serverの場合
NDBはMS SQL Serverのトランザクションログのバックアップを使用します。NDBが管理下のSQL Serverデータベースのログバックアップを取得するたびに、データベースログは切り捨てられます。
PostgreSQLの場合
PostgreSQLインスタンスでは、NDBはarchiveコマンドを使用してログのキャッチアップを実行します。PostgreSQLはクラスタデータディレクトリのpg_wal/<サブディレクトリ>に先行書き込みログ(WAL)を維持します。ログキャッチアップ操作の間、NDBは現在のWALセグメントを切り替え、そして最後のログキャッチアップ以降に生成されたすべてのアーカイブWALセグメントをNDBのログドライブにコピーします。
5. 最初のスナップショットとDay2以降の動作
データベース登録後、スケジュールで指定した[最初のスナップショット取得時間]に最初のスナップショットが取得されます。これはアプリケーション一貫性がある合成フルバックアップに相当します。OracleであればRMANで取得したバックアップと同等です。DB製品固有のAPI(begin backupとend backup)を使用してデータベースの静止点を確保し、AOSの高速なスナップショットを使用してバックアップ処理を実行します。スナップショットが取得されている間はデータベースは静止しているので、1日あたりのスナップショット数は最小限に留めることが望ましいです。
その後、DBベンダー認定の手法で先にスケジュールとして指定した15分から120分間隔のログキャッチアップが行われます。
Day2以降も指定したスナップショットとログキャッチアップの間隔に従って、ストレージレベルのスナップショットとデータベースレベルのログキャッチアップの組合せで、効率的な増分バックアップを取得します。
6. 継続的なタイムマシンの運用(ログの自動パージ、特定時点へのリストア・クローン)
SLAによって定義された[継続的なログの保持期間]の日数の間は、秒単位で指定して任意の時点にリストアすること(タイムトラベル)ができます。例えば、[継続的なログの保持期間]を14日間に設定した場合、ログを14日間保持することになり、直近の14日間は秒単位の指定でリストアが可能です。更に、15日目以降の古いログは、ログディスクを調べて削除(パージ)されます。
肝心のデータベースのリストアやクローンのオペレーションですが、タイムマシンのアクションにて[ソースデータベースのリストア]または[データベースのクローン作成]を選択することにより、[継続的なログの保持期間]の範囲では秒単位で日時を指定した時点に、それ以前ではスナップショットを取得した時点にリストアまたはクローンが可能です。
おわりに
今回はNDBの特徴的な機能であるタイムマシンについてご紹介しました。NDBの具体的な設定や動作検証については、gowatanaさんが時代は Nutanix NDB Advent Calendar 2022にクリスマスまで毎日アップされています。gowatanaさんの記事は私も楽しみにしています!
Discussion