こんにちは!
週ごとに梅雨のような天気になったり日本晴になったりと、変化が激しいですが、いかがお過ごしでしょうか。
前回は、Windows ServerとOracle Linuxのインスタンスを作成し、リージョン間バックアップを設定してバックアップから復元しました。復元後は元のインスタンス同じファイルが確認でき、設定が引き継がれることを確認しました。
インスタンス単体では設定が引き継がれていましたが、別のオブジェクトとの接続はどうなるのでしょうか。
ということで今回は、前回のリージョン間バックアップの検証の続きとして、Windows Server2019インスタンスとブロック・ボリュームをアタッチしiSCSI接続した上でバックアップしてみるという検証を行っていきたいと思います。
目次
今回やること
今回の内容は以下の通りです。
-
前回作成したWindowsインスタンスにiSCSI接続でブロックボリュームをアタッチし、テキストファイルを格納します。
-
1.のブロックボリュームをリージョン間コピーで大阪リージョンにバックアップをとります。(この時東京リージョンにもバックアップされます。)
-
ブロック・ボリュームをバックアップから復元します。
-
3.で復元したインスタンスに接続し、iSCSIの接続が保存されているか確認します。
図のようなイメージです。
ブロック・ボリュームの作成、アタッチ
東京リージョンで作業を行います。 ブロック・ボリュームを作成します。Oracle Cloudのコンソール画面左側のメニューからブロック・ストレージ>ブロック・ボリュームと進み、ブロック・ボリュームの作成をクリックします。 バックアップを仕掛けるので、ここで前回の記事で作成したバックアップ・ポリシーを選択しておきます。

Windows Serverインスタンスにアタッチします。作成後のブロック・ボリュームの詳細画面左側のリソースの欄からアタッチされたインスタンスを選択し、「インスタンスにアタッチ」をクリックします。ボリューム・アタッチメント・タイプにはiSCSIを選択します。
アタッチされたら、ブロック・ボリュームの詳細画面の「アタッチされたインスタンス」の欄にインスタンスが表示されます。インスタンスの右側の三つ点をクリックし、「iSCSIコマンド及び情報」をクリックします。

クリックすると、アタッチされたブロック・ボリュームのIPアドレスが表示されますので、確認しておきます。
Windows ServerでのiSCSI接続の設定
ブロック・ボリュームを接続したので、Windows Server側の設定を行います。 ブロック・ボリュームをD:ドライブとしてWindows Serverにアタッチします。 その際、iSCSIとMPIO(Multipath I/O)の設定が必要ですがこちらを参考に設定いたしました。(設定の詳細については長くなるので省略いたします。)
設定を終えると、エクスプローラから確認します。D:ドライブに接続されていることがわかります。 テストのため適当なテキストファイルも入れておきます。

リージョン間バックアップの設定
リージョン間のバックアップを設定していきます。インスタンスもブロックボリュームも、同じバックアップ・ポリシーを適用します。(リージョン間バックアップの設定手順については、前回の記事をご覧ください。)
左側メニューから、ブロック・ストレージ>バックアップ・ポリシーと進み、バックアップ・ポリシーの作成をクリックします。作成したら、スケジュールを設定します。
今回は、
- 毎日(増分)
- 毎週(完全)
を設定しています。

ブロック・ボリュームにバックアップ・ポリシーを適用します。
左メニューでブロック・ストレージ>ブロック・ボリュームと進み、 ブロック・ボリュームの詳細画面から、バックアップポリシーの「編集」の部分をクリックし、バックアップポリシーを割り当てます。

Windows Serverのインスタンスにもバックアップ・ポリシーを適用します。インスタンスも同様に、インスタンスの詳細画面から割り当てます。
以上でバックアップポリシーの設定は完了です。
復元、iSCSI設定の確認
バックアップされた時間になったら、バックアップからインスタンスとブロック・ボリュームを復元します。 大阪リージョンに移動します。
左端のブロック・ストレージから「ブロック・ボリュームのバックアップ」を選択し、復元したいバックアップをクリックします。

ブロック・ボリュームの作成をクリックします。

インスタンスも同様に復元します。
コンピュート>ブート・ボリュームのバックアップと進み、任意の(iSCSI接続を設定した後の)バックアップを選択します。

「ブート・ボリュームの作成」をクリックし、名前を入力して「ブート・ボリュームを作成」をクリックします。

ブート・ボリュームを作成したら、 ブート・ボリュームの詳細画面から「インスタンスの作成」ボタンを押しインスタンスを作成します。

インスタンスを作成したら、ブロック・ボリュームをインスタンスにアタッチします。
インスタンスの詳細画面に戻り、「リソース」欄の「アタッチされたブロック・ボリューム」を選択し、「ブロック・ボリュームのアタッチ」ボタンをクリックします。

これでアタッチしました。
リモートデスクトップから、設定をみてみます。
Windowsボタンを押し、ディスクの管理を開きます。 みてみると、バックアップ時に設定したはずのD:ドライブがありません。

ブロック・ボリュームの再接続
サーバーマネージャーを開き、右上の「ツール」からiSCSIイニシエーターを開きます。

すると、検出されたターゲットの欄に二つ並んでいます。 「名前」の欄に表示されているのは、ボリュームIQNの情報です。
ボリュームIQNの情報は、インスタンスの詳細画面でアタッチされたブロック・ボリュームの欄の右端の丸点をクリックし、「iSCSIコマンド及び情報」を開くことでみることができます。

どうやら、バックアップ元のブロック・ボリュームと、バックアップから復元したブロック・ボリュームの両方を検出してしまっているようです。
バックアップ元のブロック・ボリュームはアタッチされていないので、接続することはできません。
接続するバックアップから復元したブロック・ボリュームのボリュームIQNと同じ方を選択した状態で、「接続」をクリックします。
「複数パスを有効にする」にチェックし、OKを押します。

再びディスクの管理を開くと、D:に割り当てたブロックボリュームが復活しています。

エクスプローラからも、D:ボリュームに入っているテキストファイルが確認できます。

少し設定を変更すれば、バックアップ元のインスタンスのiSCSI接続の設定が引き継がれることがわかりました。
まとめ
今回は、iSCSI接続を設定したインスタンスとブロック・ボリュームをリージョン間でバックアップし、iSCSIの設定がどのように引き継がれるのかを検証しました。
Oracle Cloudのコンソール上でアタッチしただけでは接続できませんでしたが、iSCSIイニシエータでボリュームIQNを指定して接続することで同じドライブレターで接続でき、ファイルを確認できました。
前回のを含めてまとめると、リージョン間バックアップでは、
-
内部の設定やデータは引き継がれる
-
他のオブジェクトとの接続では、接続先の情報などを確認する必要がある
ということになります。 接続するまでに一手間かかりますが、接続時の情報自体は保存されるので便利ですね。
ではまたお会いしましょう!