原文はこちら。
https://blogs.oracle.com/pshuff/entry/instance_and_storage_snapshot
昨日はOracle Public Cloudの3個のサーバ上にE-Business Suite 12.5.5のインスタンスを作成していきました。
Oracle Cloudでは、インスタンスのスナップショットだけでなく、ストレージのスナップショットもとることができます。これは、既存のインスタンスを複製し、必要な時にプロビジョニングできることを意味しますが、これはバックアップとは異なります。バックアップとは通常固定されたコンピュータ・アーキテクチャを想定しており、OSやアプリケーションコードをディスク上に戻すことができます。事態が変化し、オンプレミスデータセンターとの通信に使う仮想プライベートネットワークを追加する場合、ネットワークディスク上のバックアップにはその構成がない可能性があります。これはVMWareと同様のケースであることが多くの顧客は知っています。Software Defined Networkを使ってネットワークを再定義し、仮想ディスクや仮想ネットワークインターフェースを作成できる場合、こうした追加構成はufsdumpやOSレベルのバックアップには存在しません。本当に仮想ディスクおよびその構成のクローンを作成する必要があります。
Oracleは、Cloud Serviceの5月/6月のアップデートで、ストレージのスナップショットだけでなく、インスタンスのスナップショット機能をリリースしました。ストレージ・スナップショットについては制限はありませんが、インスタンス・スナップショットには少々制限があります。インスタンス・スナップショットは、非永続的ブートディスクである必要があります。これは、ディスクを事前に作成し、インスタンスにアタッチし、そのディスクからブートしないことを意味します。ディスクは、終了すると削除される特性を持っている必要があります。これは率直に言って非常に危険なように見えます。/etc にユーザーアカウントを追加したり、/etc/initにinitファイルを追加するようなカスタマイズを施した場合、これらのカスタマイズが終了と同時に削除されるからです。ここで重要なのは、インスタンスを作成し、カスタマイズして、そのスナップショットを取るということです。そして、OSのバニラ・イメージからではなく、このスナップショットから起動します。
まず、ストレージスナップショットから見ていきましょう。オンラインドキュメントにコンソール操作、REST API、コマンドラインインターフェースの詳細があります。
![]()
![]()
![]()
起動可能ディスクとしてこのスナップショットをリストアすることができる状態にあります。そしてこのボリュームを基にして新規インスタンスを作成することができます。ストレージスナップショットのタブへ移動し、［ボリュームの復元］を選択して、リストアします。
![]()
![]()
インスタンス・スナップショットも作成できます。インスタンス・スナップショット作成にあたっての重要な制限事項は、そのディスクが非永続でなければならない、ということです。つまり、インスタンスの一部として作成し、マウントされるのではなく、終了時にディスクは削除されます。これは最初少々途惑うところではあります。デフォルトのインスタンス作成に従うと、ストレージボリュームが作成されます。このストレージボリュームを削除して、終了時に削除されるルートディスクに置き換える必要があります。インスタンス作成の手順において、ストレージ作成時に挙動を変更する必要があります。デフォルトではストレージインスタンスを作成します。そのストレージインスタンスを削除すると、自動的に非永続ボリュームで置き換えられます。
![]()
![]()
![]()
このハードルがなくなれば、インスタンス・スナップショットを作成することができます。インスタンスを選択し、［スナップショットの作成］をメニューから選択します。グレーアウトしていて選択できない場合、永続ストレージボリュームをブート・イメージとして使っています。
![]()
![]()
![]()
スナップショットのメニューをクリックしてこのスナップショットをイメージと関連付けると、起動可能イメージをこのスナップショットを基に作成することができます。これを使うと自身が作成したイメージでインスタンスを作成することができます。
![]()
![]()
![]()
インスタンス・スナップショット使用の鍵は、起動可能なインスタンスを作成し、望むように設定してから、このインスタンスのスナップショットを作成することです。こうすることで、起動可能ディスクだけでなく、そのインスタンスに対して実施したネットワーク設定やカスタマイズのゴールデンマスタを作成することができます。インスタンス・スナップショットの場合は少々異なった考え方をする必要があります。永続ルートディスクを持たないことが奇異に映るかもしれません。任意のカスタマイズが再起動時に失われることを知ると少し奇妙なことでしょう。デフォルトのログファイルが再起動時に一掃されることを知ると少し奇妙に思うことでしょう。通常とは少々異なる考え方で、ログや構成、カスタマイズを再構成し、デフォルトのルートディスクではなく、別のディスクに保存するようにする必要があります。これはそれほど悪い話ではありません。ルートディスクが保護され、カスタマイズされません。カスタマイズした場合には、それはどこかのタイミングで凍結保存してください。この方法の大きな利点の1つは、カーネルにルートキットを挿入できないということです。こうした種類の侵入は、通常マルウェアをロードするために再起動が必要です。再起動すると、安心・安全なカーネルとデフォルトのライブラリに戻ります。これはつまり、任意のパッケージやカスタマイズはこのカスタマイズ用に新しくスナップショットを永続化する必要がある、ということです。
まとめると、スナップショットはストレージやインスタンスを凍結保存するよい方法です。これを使うと開発やテストにあたって簡単に複製できるゴールデンマスタを作成することができます。さらに、必要なパッケージを有するブートディスクを凍結することで、再起動が必要なマルウェアをロックアウトできるという意味で、新しいレベルのセキュリティも追加します。パッケージやルートファイルのカスタマイズには新しいスナップショットを持つ新しいゴールデンマスタが必要である、という新しい考え方が加わります。このエントリがスナップショットの利用や、スナップショットを利用する上でのベストプラクティス方法論の作成にあたってお役に立つことを願っています。
https://blogs.oracle.com/pshuff/entry/instance_and_storage_snapshot
昨日はOracle Public Cloudの3個のサーバ上にE-Business Suite 12.5.5のインスタンスを作成していきました。
E-Business Suite in the Oracle Cloudその前日、データベースを隠し、パブリック・インターネットからアクセスできないようにして、アプリケーション・サーバーのみデータベース・インスタンスに接続できるようにすることで、これらのインスタンスを保護する方法について説明しました。
https://blogs.oracle.com/pshuff/entry/e_business_suite_in_the
hiding a server in the cloud本日は、アーキテクトとしての作業が終わり、バックアップする必要があるという前提とします。まずは標準のufsdumpを使い、ネットワーク・ストレージにシステムのバックアップをとることができるでしょう。これだけではクラウドの半分の問題しか解決しません。データをリストアできますがクラウドの世界ではちょいと事情が異なります。セキュリティ・リスト、セキュリティ・ルール、インスタンスの構成もバックアップする必要があります。この環境を開発・テストもしくはQAのセカンダリ環境にレプリケートしたいと思うかもしれません。それゆえ、ゴールデンマスターを作成するのがよさそうです。
https://blogs.oracle.com/pshuff/entry/hiding_a_server_in_the
Oracle Cloudでは、インスタンスのスナップショットだけでなく、ストレージのスナップショットもとることができます。これは、既存のインスタンスを複製し、必要な時にプロビジョニングできることを意味しますが、これはバックアップとは異なります。バックアップとは通常固定されたコンピュータ・アーキテクチャを想定しており、OSやアプリケーションコードをディスク上に戻すことができます。事態が変化し、オンプレミスデータセンターとの通信に使う仮想プライベートネットワークを追加する場合、ネットワークディスク上のバックアップにはその構成がない可能性があります。これはVMWareと同様のケースであることが多くの顧客は知っています。Software Defined Networkを使ってネットワークを再定義し、仮想ディスクや仮想ネットワークインターフェースを作成できる場合、こうした追加構成はufsdumpやOSレベルのバックアップには存在しません。本当に仮想ディスクおよびその構成のクローンを作成する必要があります。
Oracleは、Cloud Serviceの5月/6月のアップデートで、ストレージのスナップショットだけでなく、インスタンスのスナップショット機能をリリースしました。ストレージ・スナップショットについては制限はありませんが、インスタンス・スナップショットには少々制限があります。インスタンス・スナップショットは、非永続的ブートディスクである必要があります。これは、ディスクを事前に作成し、インスタンスにアタッチし、そのディスクからブートしないことを意味します。ディスクは、終了すると削除される特性を持っている必要があります。これは率直に言って非常に危険なように見えます。/etc にユーザーアカウントを追加したり、/etc/initにinitファイルを追加するようなカスタマイズを施した場合、これらのカスタマイズが終了と同時に削除されるからです。ここで重要なのは、インスタンスを作成し、カスタマイズして、そのスナップショットを取るということです。そして、OSのバニラ・イメージからではなく、このスナップショットから起動します。
まず、ストレージスナップショットから見ていきましょう。オンラインドキュメントにコンソール操作、REST API、コマンドラインインターフェースの詳細があります。
Oracle® Cloud Using Oracle Compute Cloud Service (IaaS)REST APIには少々深掘りするに値する機能があります。REST APIのドキュメントによれば、同じサーバにスナップショットを作成することができます。これは、スナップショット作成時にプロパティとして/oracle/private/storage/snapshot/collocatedを指定することによってより高速にリストアできるようにするものです。
Backing Up and Restoring Storage Volumes Using Snapshots
https://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-0C04E7C5-0D24-4D16-9D83-92EC1E737622.htm#STCSG-GUID-0C04E7C5-0D24-4D16-9D83-92EC1E737622
REST API for Oracle Compute Cloud Service (IaaS)
https://docs.oracle.com/cloud/latest/stcomputecs/STCSA/toc.htm
Oracle® Cloud Command Line Reference for Oracle Compute Cloud Service (IaaS)
https://docs.oracle.com/cloud/latest/stcomputecs/STCLR/toc.htm
REST API for Oracle Compute Cloud Service (IaaS)また、以下のAPIを使うと、ストレージボリュームをスナップショットから作成できます。
Storage Volume Snapshots REST Endpoints
https://docs.oracle.com/cloud/latest/stcomputecs/STCSA/api-Storage%20Volume%20Snapshots.html
REST API for Oracle Compute Cloud Service (IaaS)Computeコンソールからこれらの機能のほとんどを操作できます。ストレージボリュームを選択し、［スナップショットの作成］を選択します。
Create a Storage Volume
https://docs.oracle.com/cloud/latest/stcomputecs/STCSA/op-storage-volume--post.html
起動可能ディスクとしてこのスナップショットをリストアすることができる状態にあります。そしてこのボリュームを基にして新規インスタンスを作成することができます。ストレージスナップショットのタブへ移動し、［ボリュームの復元］を選択して、リストアします。
インスタンス・スナップショットも作成できます。インスタンス・スナップショット作成にあたっての重要な制限事項は、そのディスクが非永続でなければならない、ということです。つまり、インスタンスの一部として作成し、マウントされるのではなく、終了時にディスクは削除されます。これは最初少々途惑うところではあります。デフォルトのインスタンス作成に従うと、ストレージボリュームが作成されます。このストレージボリュームを削除して、終了時に削除されるルートディスクに置き換える必要があります。インスタンス作成の手順において、ストレージ作成時に挙動を変更する必要があります。デフォルトではストレージインスタンスを作成します。そのストレージインスタンスを削除すると、自動的に非永続ボリュームで置き換えられます。
このハードルがなくなれば、インスタンス・スナップショットを作成することができます。インスタンスを選択し、［スナップショットの作成］をメニューから選択します。グレーアウトしていて選択できない場合、永続ストレージボリュームをブート・イメージとして使っています。
スナップショットのメニューをクリックしてこのスナップショットをイメージと関連付けると、起動可能イメージをこのスナップショットを基に作成することができます。これを使うと自身が作成したイメージでインスタンスを作成することができます。
インスタンス・スナップショット使用の鍵は、起動可能なインスタンスを作成し、望むように設定してから、このインスタンスのスナップショットを作成することです。こうすることで、起動可能ディスクだけでなく、そのインスタンスに対して実施したネットワーク設定やカスタマイズのゴールデンマスタを作成することができます。インスタンス・スナップショットの場合は少々異なった考え方をする必要があります。永続ルートディスクを持たないことが奇異に映るかもしれません。任意のカスタマイズが再起動時に失われることを知ると少し奇妙なことでしょう。デフォルトのログファイルが再起動時に一掃されることを知ると少し奇妙に思うことでしょう。通常とは少々異なる考え方で、ログや構成、カスタマイズを再構成し、デフォルトのルートディスクではなく、別のディスクに保存するようにする必要があります。これはそれほど悪い話ではありません。ルートディスクが保護され、カスタマイズされません。カスタマイズした場合には、それはどこかのタイミングで凍結保存してください。この方法の大きな利点の1つは、カーネルにルートキットを挿入できないということです。こうした種類の侵入は、通常マルウェアをロードするために再起動が必要です。再起動すると、安心・安全なカーネルとデフォルトのライブラリに戻ります。これはつまり、任意のパッケージやカスタマイズはこのカスタマイズ用に新しくスナップショットを永続化する必要がある、ということです。
まとめると、スナップショットはストレージやインスタンスを凍結保存するよい方法です。これを使うと開発やテストにあたって簡単に複製できるゴールデンマスタを作成することができます。さらに、必要なパッケージを有するブートディスクを凍結することで、再起動が必要なマルウェアをロックアウトできるという意味で、新しいレベルのセキュリティも追加します。パッケージやルートファイルのカスタマイズには新しいスナップショットを持つ新しいゴールデンマスタが必要である、という新しい考え方が加わります。このエントリがスナップショットの利用や、スナップショットを利用する上でのベストプラクティス方法論の作成にあたってお役に立つことを願っています。