三流エンジニアの落書き帳

さあ、今日も未知という扉を開けてみよう

OCIの勉強～ストレージ編～

OCI

どうもこれしきです。

最近グミにプチハマりしています。

今回はOCIのストレージサービスについてです。

ブロックストレージをはじめ、いくつか異なる種類のストレージサービスがありますが、悩んだ末まとめてブログにしました。

Block Storage

Block Storageの概要

コンピュートにアタッチして利用するストレージサービス。

AWSのEBSに該当する機能で、伸縮性に優れたNVMe SSDベースのストレージ。以下のような特徴がある。

  • 50GB ~ 32TBの間で1GB単位での指定が可能
  • オンラインでのリサイズが可能、ただし縮小はできない
  • ミリ秒以下のレイテンシー
  • インスタンスに対してアタッチ・デタッチが可能で、デタッチされてもストレージ内のデータは消去されない
  • アタッチ方法はiSCSIと準仮想化の2種類が存在する
  • アクセスタイプにRead/Write(非共有),Read/Write(共有),Read Only(共有)の3タイプが存在する
  • 共有ボリュームには最大8つのインスタンスを接続可能*1
  • 1インスタンスに最大32ボリュームまでアタッチ可能
  • デフォルトで暗号化（データ格納時、転送時）
  • AD内で複数のレプリカを持つため、可用性に優れている
  • VMインスタンスにアタッチされている場合、性能上限はネットワーク帯域にも依存する

Local NVMe Device

Dense I/Oシェイプインスタンスに、ローカルに接続されたNVMeデバイス。

高いストレージパフォーマンスが要求されるワークロードに適しているが、 OCI側がこのNVMeデバイスを保護する機能は無く*2、ユーザー自身でRAIDを組むなどしてデータの保護を行う必要がある。

Local NVMeの特徴として、インスタンスを停止や再起動したとしても、Local NVMe内のデータは保持されるというものがある。(インスタンス削除時には、データは削除される)

なお、NVMeパフォーマンスについてはSLAが定義されている。*3

ブートボリューム

OSが含まれているボリュームで、各インスタンスに必ず1つ存在する。

ブートボリュームという名前ではあるが、実質はブロックボリュームと同じで、バックアップやサイズの拡張など同様に行える。

Linuxのデフォルトサイズは46.6GB、Windowsのデフォルトサイズは256GB。

デフォルトでは、インスタンスを削除してもブートボリュームのデータは保持される。

ブートボリュームのトラブルシューティング

ブートボリュームにはOSの起動に必要なデータが含まれているため、ブートボリューム内のデータに問題があるとインスタンスが起動できなくなるといった問題が発生する恐れがある。

このようなケースでは、ブートボリュームをそのインスタンスからデタッチし、別のインスタンスにブロックボリュームとしてアタッチする。 そうすることで問題が発生したボリュームの調査が可能となる。

パフォーマンス

以下の4種類のパフォーマンスタイプが存在する。

  • より低いコスト(SLAの対象外)
    • 2 IOPS/GB (最大 3000 IOPS)
    • 240 KB/s/GB (最大 480 MB/s)
  • バランス
    • 60 IOPS/GB (最大 25,000 IOPS)
    • 480 KB/s/GB (最大 480 MB/s)
  • より高いパフォーマンス
    • 75 IOPS/GB (最大 50,000 IOPS)
    • 600 KB/s/GB (最大 680 MB/s)
  • UHP*4
    • 90~225 IOPS/GB (最大 300,000 IOPS)
    • 720~1800 KB/s/GB (最大 2,680 MB/s)

より低いパフォーマンスはSLA対象外な点に注意。

ボリュームに対して、パフォーマンスの自動チューニングを有効にしておくと、 そのボリュームがインスタンスからデタッチされた際にパフォーマンスがより低いコストに自動で設定される。*5

バックアップとリストア

Block Storageに対してバックアップ・リストア機能が提供されていて、次のような特徴がある。

  • バックアップ開始時点のボリューム上のデータのPoint-in-timeスナップショット
  • オリジナルのボリュームに付随しているタグも、バックアップされる
  • オンラインでの取得
  • 完全バックアップと増分バックアップをサポート
  • ブートボリューム・ブロックボリューム共同じ仕組み
  • データは暗号化されObject Storageに保存される
  • 新規ボリュームとして別ADにもリストアが可能(異なるリージョンでは不可)
  • 取得したバックアップを別リージョンにコピーすることが可能
  • 手動バックアップとポリシーベース・スケジュールバックアップをサポート

バックアップ方法

以下の2つの方法が存在する

  • 手動バックアップ
  • ポリシーベースのバックアップスケジュール
    • Oracle定義
      • Bronze 月次バックアップ(該当月の初日)、12か月保持＋毎年1回の年次バックアップ
      • Silver 週次バックアップ(日曜日)、4週間保持＋Bronze
      • Gold 日時バックアップ、7日間保持＋Silver
    • ユーザ定義 Oracle定義のバックアップポリシーでは要件を満たさないものについては、ユーザ独自の定義でバックアップを行える ユーザ定義のバックアップを行うためには、ユーザ定義バックアップポリシーを作成して、スケジュールを作成する必要がある

クローン

バックアップとは異なり、既存のブロックボリューム全体を新しいボリュームにコピーする。以下の特徴がある。

  • クローン時にソースボリュームをデタッチする必要は無い
  • 同じAD内でのみ実施可能
  • クローン操作自体はすぐに完了するが、実際のデータコピーはバックグラウンドで行われる
  • ソースボリュームがインスタンスにアタッチされている場合は同時にクローン出来るボリューム数は1つまで
  • ソースボリュームがインスタンスにアタッチされていない場合は同時にクローン出来るボリューム数は10個まで

ボリュームグループ

バックアップやクローンの目的で単一エンティティとして扱えるブロックボリューム(ブートボリュームも含む)のセット。

ボリュームグループを活用することで、アプリケーション全体で一貫性のあるバックアップを取得することができる。

デフォルトで最大32個のボリューム、合計で128TBまでをひとつのグループに含めることが可能。

単一のAD内でのみ有効。

クロスリージョン・ボリュームレプリケーション

ボリュームを別のリージョンに継続して自動的に非同期レプリケーションを行う。

最初はその時点での完全なデータをレプリケートするが、以降は変更された部分のみレプリケートされる。

クロスリージョン・ボリュームレプリケーションをすることで、DRを実現できる。

この設定はボリューム作成時にも、既存のボリュームにも行うことができる。

ソースリージョンによって、レプリケーション先のリージョンが固定されている点に注意が必要。*6

Object Storage

Object Storageの概要

AWSのS3に該当するサービスで、以下のような特徴がある。

  • データを容量的な制限なしに保存可能
  • 標準化されたRESTful APIを使用
  • 用途に応じて3つのタイプを使用可能
  • リージョンに有効なサービス
  • サービスゲートウェイを介して、VCN内からプライベート接続可能
  • クロスリージョンコピー
  • 事前認証済みリクエスト
  • ライフサイクルルール
  • マルチパートアップロード
  • 強固な一貫性（常に最新データを取得）
  • 複数のストレージサーバ間でデータを冗長化
  • Key-Value型の独自メタデータの定義が可能
  • AES-256による自動暗号化

S3が提供する機能とほとんど被る

Object Storageの用語

  • オブジェクト
    • すべてのデータはオブジェクトとして管理される
    • オブジェクトはオブジェクト＋メタデータで構成される
  • バケット
    • オブジェクトを管理する論理的なコンテナ
  • 名前空間
    • バケット名はテナント＋リージョン内で一意である必要がある
    • 同じバケット名でもリージョンが異なれば利用可能

Object Storageの階層

Object Storageは用途に合わせて3つの階層が存在している

  • 標準
    • ホットデータ用の標準的なストレージ
    • 瞬時に検索
  • 頻度の低いアクセス
    • アクセス頻度の低いデータ向け
    • 追加でデータ検索のための費用がかかる
    • 最小保存期間は31日
  • アーカイブストレージ
    • 超低価格アーカイブストレージ 1TB 364yen/month
    • 最小保存期間は90日
    • ダウンロードする前にオブジェクトをリストアする必要がある（リストア時間はおよそ1時間）

S3同様に、どのようなアクセスタイプがどのストレージ層に適しているか見極める必要がありそう。

アクセスタイプが分からない場合、次に説明するAuto-tieringを活用したい。

Auto-tiering

31日間アクセスが無かったオブジェクトを、自動的に頻度の低いアクセス層へ移動する機能。

また、そのオブジェクトへのアクセス頻度が高くなると標準層へ移動する。

バケット単位で設定され、有効化されたバケット内のすべてのオブジェクトのアクセスが監視される。

アクセスパターンが確立していないケースで適切。

Object Storageへの認証・アクセス

  • 認証済みリクエスト

    有効期限が設定されたURLを共有されたユーザーは、そのバケットやオブジェクトにアクセスできる。

    Object Storageにアクセスするために、認証情報を用意する必要が無い。

  • パブリックバケット

    バケットはデフォルトでプライベートだが、これをパブリックバケットへ変更することができる。

    パブリックバケットに対しては、匿名ユーザーであってもアクセスが可能となる。

    アクセスタイプを変更しても、既存の認証済みリクエストには影響を与えない。

今のところ、AWSのS3にある静的ウェブサイトのホスティング機能のようなものは無いっぽい。

ライフサイクル管理

ルールに従って、オブジェクトを自動的にアーカイブ・削除したり、頻度の低いアクセス層へ移行することが可能。

使用するにあたって、サービスがオブジェクトを管理することを承認する必要がある。

Allow service objectstorage-ap-tokyo-1 to manage object-family in compartment <compartment>

バケットやオブジェクトに対して有効化でき、プレフィックスレベルで適用される。

レプリケーション（クロスリージョンコピー）

Object StorageはAD内に複数のコピーを持っているため、どれか一つに障害が発生しても問題が無い。

しかし、リージョン障害が発生した場合などいわゆるDR目的のために、別リージョンへレプリケーションすることもできる。（同一リージョン内でコピーすることも可能）

レプリケーションポリシーを設定する際には、予めレプリケーション先にバケットを作成しておく必要がある。

1つのソースバケットに対して、1つだけレプリケーションポリシーを設定できる。

レプリケーション先のバケットをプライマリーとして、レプリケーションのチェインを行うことはできない。

保持ルール

保持ルールを使用することで、オブジェクトをイミュータブルにすることが可能。 （いわゆるWriter Once Read Manyを実現できる）

有効期限を設けることも、無期限にすることも可能。

ルールそのものをロックすることが可能。

使用用途としてはガバナンス、法令順守など。

バージョニング

同じ名前のオブジェクトが変更されたときに、上書きするのではなく古いオブジェクトを過去のバージョンとして保持することができる。

バージョニングを一度有効化すると無効化できないが、機能の一時停止が可能。

バージョニングされたオブジェクトは、ライフサイクルポリシーに含めることが可能。

レプリケーションポリシーにはバージョニングは適用されない。

保持ルールは使えない。

Object Storageのイベントログ

Object Storageの読み取りアクセス、書き込みアクセスに対してそれぞれロギングを有効化できる。

ロギング機能はバケットごとに有効化できる。

取得したログはOCI Logging analyticsと連携ができる。

マルチパートアップロード

大きいファイルをObject Storageにアップロードする際に、元のファイルをいくつかの小さいファイルに分割し、個々のファイルを並列にアップロードすることができる。

100MiBを超えるオブジェクトは、マルチパートアップロードを活用したほうが効率的と言われている。

アップロードが失敗した際には、分割されたパートごとにアップロードの再試行が可能。

コンソールからのアップロードの場合、64MiBを超えるオブジェクトは自動でマルチパートアップロードが適用される。

マルチパートアップロードは、他にもAPIやCLIからも利用可能。

次の制約がある

  • オブジェクトの最大サイズは10TiB
  • オブジェクトのパートサイズは10MiB~50GiB
  • 分割数の上限は10000パート

File Storage

NFS v3に互換性のあるフルマネージドなファイルシステム。 UNIXとWindowsに対応している。AWSのEFSにあたるサービス。

特徴

  • エクスポート：NFSコントロールレイヤー
  • マウントターゲット：クライアントが接続する際に利用するエンドポイント
  • ファイルシステム当たり10000スナップショットを取れる
  • 取得したスナップショットに対してクローンを作成することが可能
  • すべてのファイルシステムとメタデータに対するデータの保存時および転送時の暗号化*7
  • クライアントからマウントターゲット間の暗号化はデフォルトでは無効
  • マウント時にオプションを指定することでクライアントとマウントターゲット間の通信を暗号化できる*8
  • フェイルオーバーのためにサブネット内に3つの空きIPアドレスが必要*9
  • エクスポートオプションでNFSクライアントのアクセスを制御する

まとめ

というわけで今回はOCIのストレージサービスについて勉強しました。

ストレージサービスはその用途に合わせて、最適なサービスを選択する必要があります。

それぞれが多種多様の機能を有しており覚えることも多いですが、一つずつ丁寧に理解していきたいですね。

*1:OCI側での同時書き込み制御は無いため、ユーザ側で管理する必要がある

*2:RAIDやスナップショット、バックアップなどの機能が提供されていない

*3:各シェイプごとにサポートされる最小IOPSが定義されている.https://docs.oracle.com/ja-jp/iaas/Content/Compute/Concepts/computeperformance.htm

*4:Ultra High Performance

*5:再アタッチされると、指定されたパフォーマンスが設定される

*6:東京リージョンからは大阪リージョンか、ソウルリージョンへのみレプリケーションが行える

*7:マウントターゲットとエクスポート間の通信

*8:クライアントにoci-fss-utilsのインストールが必要

*9:/30のサブネットでは数が足りなくなることに注意