2015.07.01

KCPSで実現するバックアップソリューション

はじめまして。KDDI Cloud Platform Service(以下KCPS)の開発をしております村崎です。既に本blog内で今回の新機能であるサイトバックアップ機能についてご紹介しておりますが、その魅力について開発者の視点から深堀をしたいと思います。

サイトバックアップ機能について

2012年にサービス開始したKCPS (Ver1.0)においても、メインサイトの万が一の被災時に備えスナップショットを別サイトのストレージに格納される構成となっておりましたが、別サイトのバックアップデータはお客さまが任意に使用できる状態にはありませんでした。KCPS (Ver2.0)ではこの部分の改善も踏まえ以下3つのポイントを考慮した設計としています。

1.管理サーバとサイトの疎結合性
ディザスタリカバリを想定した場合、メインサイトが完全機能停止する可能性は十分に考えられます。(東日本大震災時の各通信キャリアの状況鑑みても、伝送路寸断することが随所に見られており1サイトの外部通信が機能しなくなることが現実に考えられます)KCPSではApacheCloudStackをベースにしたCitrix社の CloudPlatformを用いて仮想インスタンス操作、管理を行っておりますが、KCPS(Ver2.0)におけるサイト分散の設計として、管理サーバと各サイトを疎結合とするために、CloudPlatform構成コンポーネントである’Zone’単位ではなく、各サイトにCloudPlatformを構築しています。

1
尚、ApacheCloudStackにおいては’Region’とよばれる各Zoneリソースをグルーピングした個別マネージメントサーバで管理する機能もApacheCloudStack4.1より提供されておりますが、テンプレートの’Region’間コピーの実装が難しいことから、サイト間のバックアップ機能としては今回の構成が最適と考えております。詳細の実装方式は後程ご説明いたしますが、この構成によりメインサイトが被災時に機能停止した場合においても、対向サイト側のCloudPlatformにて問題無くリカバリ操作が可能となりますし、対向サイト側で管理サーバを立ち上げしなおす必要もありませんのでRTOの短縮を実現しております。さらに平常時においても、お客さまが任意にバックアップ及びリカバリ操作を実施いただけますので予めリカバリの検証が可能となっています。またKCPS (Ver1.0)における’Zone’間における別サイトへのテンプレートコピー機能が、KCPS (Ver2.o)では実装されていませんでしたが、サイトバックアップ機能を用いて同等のコピー操作を行うことが可能となった点が東西サイトをご利用のお客様にとっては改善点の1つとなっています。

2.リカバリリソースの選択自由
ディザスタリカバリを想定されるユーザー様においても、コストを重視したいといった場合もあればRTO重視ですぐに復旧したいといったケースもあるかと思います。KCPSのサイトバックアップであれば、前者のユースケースの場合、被災時のみ対向サイト側で仮想サーバ作成を行う(テンプレートやボリュームから数分~数十分程度で仮想インスタンスのクローンを作成することが可能)ことで、2倍の仮想サーバコストを支払う必要はありません(テンプレートやボリューム容量のコストのみ発生)。また後者のRTO重視されるケースにおいては、平常時より定期的に仮想サーバを作成しておくことで、被災時に構築手間を気にすることなく仮想インスタンスのリカバリを行うことができます。(今後、公開予定の仮想インスタンス作成APIと組み合わせれば仮想サーバ作成までを自動化することも可能となります)KCPSサイトバックアップではこのように自由な選択ができる点も魅力の1つです。

3.エージェントやアプライアンス製品の導入不要
サイト間のリカバリを行う為に3rdベンダー製品を用いたソリューションは幾つも存在します。KCPSの(Ver1.0)においては、サイト間リカバリを行う場合にそのようなソリューションを個別に検討し、導入されたお客さまも多くいらっしゃいました。KCPS (Ver2.0)で提供しているサイトバックアップではKCPSで提供している基盤機能を使用するだけで、サイト間のバックアップ機能を利用することができ、これまで発生していたお客さま仮想サーバへのエージェントインストールや、仮想アプライアンスの導入など、余分な手間やコストは発生しません。では次にこれらを既存の基盤でどのように実現しているか、ご説明したいと思います。

image1

A.移行元サイトにてスナップショットを取得
これまでも提供しているスナップショット機能をそのままご利用いただくだけでサイトバックアップの準備が完了します。定期スナップショットを選択することで、対向サイト側には常に最新の状態1世代のバックアップを作成することが可能となります。

B.サイト間スナップショット(実体ファイル)のコピー
CloudPlatformのセカンダリストレージに取得されたスナップショット実体(ovaファイル)をストレージのレプリケーション機能にてサイト間コピー実施します。こちらはユーザー様が意識することなく全てのスナップショットに対して自動でコピーが行われます。スナップショット取得処理と併行してブロックレベルでレプリケーションされるのでより最新状態のバックアップを取得できるためRPOに貢献します。

C.アカウント情報のコピー
先にご説明した通り東西で別々の管理サーバで管理しているため、ご契約者の契約者情報(東西で同じ契約者番号にて契約されていることがご利用の条件となります)とvolume情報、スナップショット情報をについて対向先側で管理する必要があり、こちらはデータベースのレプリケーション機能を使ってリアルタイムで同期しています。

D.サイトバックアップの設定
対向サイト側でポータルタブの左メニュー内’サイトバックアップ’より該当のスナップショット一覧を表示した際、Bのレプリケーション処理中は右端にReplicatingが表示され、完了時にサイトバックアップアイコン表示に切替わります。この状態であればいつでもマニュアルリカバリ可能となります。オートサイトバックアップ設定をした場合は、10分間隔のバッジ処理によりReplicating表示が終了した(対向先にコピーが完了した)スナップショットから自動でEに記載のリカバリ処理を実施します。

E.リカバリ処理
対向先サイトでのリカバリ処理実行するためには、対向先のCloudPlatformのセカンダリストレージ上に取得したスナップショット実体を配置する必要があります。そのためにはCloudPlatformのnative機能にて外部からovaファイルをアップロードする方法等が考えられますが、KCPSにおいてはセカンダリストレージ内部のクローン機能を使用し迅速なコピーを行うため、次のようにCloudPlatformのAPIをコールし、リカバリを実現しています。

具体的には、
(1).対向先サイトでダミーの仮想サーバ作成API発行
(2).ダミー仮想サーバのスナップショット作成API発行(空のスナップショット)
(3).作成されたスナップショットに対しセカンダリストレージ内部クローンにて移行元から取得されているスナップショット実体を配置(これにより同等のスナップショットが対向先でも取得されている状態を作りだす)
(4).CloudPlatform機能のスナップショットからのテンプレート作成またはボリューム作成APIをコール、作成された時点でリカバリ処理の完了となります。
このようにサイトバックアップではKCPS基盤インフラで使用されているストレージ機能やCloudPlatformのAPIコールを効果的に組み合わせることで、前述の設計考慮ポイントでご説明した3つのメリットを実現しています。尚、スナップショットはオンライン取得も可能ではありますが、完全にデータ整合性を確保したい場合は静止点を取りバックアップを取得することをお勧めします。以下にサイトバックアップを利用した、DBサーバの可用性向上デザインの一例をご紹介します。

3

・ROOTボリュームはデータ整合性確保のためVM停止にてスナップショット取得
※システム領域のみマウントすることでOSのupdateタイミング等スナップショット取得

=VM停止回数を最小化

・DATAボリュームはDB領域を1次領域へマウントし、データ整合性確保のため別ボリュームに同期または定期バックアップ((MySQL等のレプリケーションやDBdump想定)した2次領域を作成した上でスナップショット取得

■KCPS API公開との連携

さて、ここまでサイトバックアップ機能についてご説明してきましたが、今般KCPS仮想サーバへの各種制御についてユーザー向けAPIを一部公開しました。これらのAPIを効果的に使用することでバックアップ等の用途においても便利に使うことができオペレーションの幅を広げることができます。APIをご利用するにあたり、シンプルで使いやすいkick_api.shというbashスクリプトをご紹介します。(本スクリプトはクリエーションライン社より公開されております)まずはご利用の準備としてKCPS Ver2において次の操作によりエンドポイントURL、APIキー、秘密キーを取得します。

4

インスタンス管理タブ
→左側メニューよりアカウント選択
→ドメイン選択
→’表示ーユーザー’リンク選択
→ユーザー選択
※初期値は空白となっていますので左上の’キーの生成’により作成してください

次に取得した情報をスクリプト内(XXX…XXX部分)に設定します。

shの書式は、以下の通りコマンド名とパラメータ名を入力するだけで実行可能です。
./kick_api.sh command=APIメソッド パラメータ名1=値 パラメータ名2= 値
KCPS Ver2にて公開しましたAPIはCloudPlatfromに準拠したREST-APIとなっており、各メソッド、パラメータはAPI Reference(←Lnk:https://cloudstack.apache.org/api/apidocs-4.3/TOC_Domain_Admin.html)を参照下さい
※CitrixCloudPlatformはApacheCloudStackのAPI Referenceに準じています。
※Required欄に記載されているパラメータは必須パラメータとなり省略不可となります。
kick_api.shのsourceは以下の通り。

ユースケース1:自サイトにおけるテンプレート自動作成
サイトバック機能にて対向サイトにはテンプレートを定期自動作成することができますが、自サイト内では手動でスナップショットから作成するのみとなります。対象ボリュームの実容量によっては数時間以上を要することもあるため、RTOを短縮したい場合にAdminConsoleによる定期スナップショット設定し、APIコールをスクリプト化し自動実行させることが可能です。

step1 ’listSnapshots’メソッドにて当該アカウントのスナップショット一覧取得
step2 ’volumeid’及び’created’パラメータにて対象の最新スナップショットを特定
step3 step2にて特定したスナップショットの’id’を引数に’createTemplate’メソッドにてテンプレート作成

ユースケース2:スナップショット処理進捗の確認
スナップショットについては対象ボリュームの実容量によっては数時間~それ以上の処理時間を要することがあります。データ整合性確保のためVM停止等を行った際に停止時間を最小限に留めるため処理進捗を確認したい場合に、非同期job確認のAPIコールを定期的に実行しレスポンスをチェックすることが可能です。

step1 ’listVolumes’メソッドにて当該アカウントのボリューム一覧取得
step2 ’createSnapshot’メソッドにて’volumeid’パラメータで指定したボリュームのスナップショット取得、レスポンスにて’jobid’を特定
step3 step2にて特定した’jobid’を引数に’queryAsyncJobResult’ メソッドのレスポンスにて’jobstatus’値により以下状況確認

0:ジョブが処理中であることを示します。これ以降のジョブの進捗について、定期的にチェックしてください。
1:ジョブが正しく完了しました。実行したコマンドに応じて、適切な成功応答値が返されます。
2:ジョブの完了に失敗しました。タグで失敗原因のコードを、タグで失敗原因をチェックできます。

本メソッドは先に記載のApacheCloudStack API Referenceのメソッド一覧にてメソッド名の後ろに(A)が記載されている全ての非同期jobに対して有効となります。上記はAPI利用のほんの一例ではありますが、その他にも’rebootVirtualMachine’メソッドにて、定期的な仮想インスタンスの再起動を自動実行させたり、’listEvents’メソッドで仮想インスタンスへの操作ログに対し’level’パラメータにてERRORログのみを指定して出力させるなど、いろいろと便利に使うことができます。

■最後に

ここまでKCPSにてリリースいたしました可用性向上に寄与できる新機能について記載させていただきました。今回公開したAPIの機能は限定的ではありますが、今後は、「プレミアム契約によるDedicatedホスト」や「エクストラアベイラビリティ」等も含めて、AdminConsole上で提供される機能APIは順次公開していくことを検討しており可用性向上だけでなく様々なDevOps用途にご利用いただける予定ですのでご期待ください。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
プラットフォーム技術部

村崎 伸

新着記事
タグ
アーカイブ
カテゴリー
TOP