目次
はじめに
みなさん、こんにちは。
Oracle Cloud Infrastructure検証チームです。
今回は、Oracle Cloud Infrastructure(OCI)のストレージ・ゲートウェイ・サービスを使ってみましたので、ご紹介したいと思います。
ストレージ・ゲートウェイ・サービスとは
ストレージ・ゲートウェイとは、オブジェクト・ストレージ・サービスとNetwork File Storage(NFS)準拠を統合することにより、オンプレミスのサーバとOracle Cloudとの間でファイルを安全に移動することができるサービスです。
オンプレミスのアプリケーションは、データをNFSターゲットに書き込むことでOracle Cloud上のオブジェクト・ストレージにまでファイルを転送することができます。
Oracle Cloudにデータを転送するためにクライアントがREST APIを取り込む必要がないという点が特徴です。
オブジェクト・ストレージ・サービスは過去記事で紹介していますのでご覧下さいね!
OCI オブジェクト・ストレージとは
こんなケースにおすすめ
- オンプレミス・アプリケーションがOCI オブジェクト・ストレージを使用するハイブリッド・クラウド・アーキテクチャの場合
- オンプレミスからクラウドへのデータ移行または継続的なデータ同期を行いたい場合
オブジェクト・ストレージ・サービスは、OCIのすべてのお客様向けに無償で提供されるサービスです。
ストレージ・ゲートウェイ・サービスは、オブジェクト・ストレージの標準ストレージ層とアーカイブ・ストレージ層の両方に対応しています。
使ってみた
今回の検証内容はこちらです。
ストレージ・ゲートウェイ・サーバの構築
こちらのインストール・マニュアルを参考に構築しました。
今回は、サーバとしてOCIのコンピュート・インスタンスとブロック・ボリュームを使用します。
コンピュート・インスタンスのOSは、Oracle Linux 7です。
2022年11月時点では、Oracle Linux 8はサポートされていないようです。
ブロック・ボリュームは600GB以上がストレージ・ゲートウェイの推奨サイズなのですが、今回は簡単な検証なので選択できる最小サイズの50GBにしました。
ブロック・ボリュームはコンピュート・インスタンスにアタッチして、ファイル・システムとして追加しておきます。
[opc@vmsgw ~]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.7G 0 7.7G 0% /dev tmpfs 7.7G 0 7.7G 0% /dev/shm tmpfs 7.7G 8.8M 7.7G 1% /run tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup /dev/sda3 39G 3.7G 35G 10% / /dev/sda1 200M 7.4M 193M 4% /boot/efi tmpfs 1.6G 0 1.6G 0% /run/user/0 tmpfs 1.6G 0 1.6G 0% /run/user/994 tmpfs 1.6G 0 1.6G 0% /run/user/1000 /dev/mapper/vg01-lv_data 50G 33M 50G 1% /mnt/ocisg
「/mnt/ocisg」がアタッチしたブロック・ボリュームの領域です。ファイル・システム・タイプはxfsを選択しています。
ここまで準備ができましたら、製品をインストールしていきます。インストール・メディアをこちらからダウンロードします。
ダウンロードしたインストール・メディア(ocisg-1.4.tar.gz)をコンピュート・インスタンスへ配置し、解凍します。
そしてインストール方法はとても簡単!
展開されたファイル「ocisg-install.sh」をrootまたはsudo権限で実行するだけです。
[opc@vmsgw ~]$ sudo tar zxvf ocisg-1.4.tar.gz ocisg-1.4/ ocisg-1.4/helper-install-ocisg.sh ocisg-1.4/ocisg:1.4.tar ocisg-1.4/ocisg-install.sh ocisg-1.4/connect-fs.sh ocisg-1.4/ocisg-control.sh ocisg-1.4/health-check.sh ocisg-1.4/support-bundle.sh ocisg-1.4/test-bandwidth.sh ocisg-1.4/ocisg-config.sh ocisg-1.4/ocisg ocisg-1.4/OCISG_README.txt [opc@vmsgw ~]$ [opc@vmsgw ~]$ cd ocisg-1.4/ [opc@vmsgw ocisg-1.4]$ sudo ./ocisg-install.sh
インストールの途中でDockerのインストールとNFSサーバの有効化を求められますので、「y」を入力します。
ストレージ・ゲートウェイは、セキュリティと分離のためにDockerコンテナ内で実行されるようです。
Docker does not appear to be installed. Do you want to install docker engine with yum? [y/N] y NFS server does not appear to be enabled. Do you want to enable NFS? [y/N] y
その後、インストール・ロケーションの選択を求められますので、コンピュート・インスタンスにアタッチしたブロック・ボリュームの領域を指定します。
デフォルトのインストール・ロケーションを受け入れます。 Enter the install location press enter for default (/opt/ocisg/) : /opt/ocisg/ ファイル・システム・キャッシュのパスを入力します。 Enter the path for OCISG file system cache : /mnt/ocisg/sg/cache メタデータ・ストレージのパスを入力します。 Enter the path for OCISG metadata storage : /mnt/ocisg/sg/metadata ログ・ストレージのパスを入力します。 Enter the path for OCISG log storage : /mnt/ocisg/sg/log
これでインストールは完了です!
インストール後は、こちらのコマンドで構成情報を確認します。
[opc@vmsgw .ssh]$ sudo ocisg info Management Console: https://vmsgw:32770 If you have already configured an OCISG FileSystem via the Management Console, you can access the NFS share using the following port. NFS Port: 32771 Example: mount -t nfs -o vers=4,port=32771 vmsgw:/<OCISG FileSystem name> /local_mount_point
コマンド実行の結果から、管理コンソール用に32770ポート、NFSマウント用に32771ポートを使用していることが分かりました。
管理コンソールへの接続URLとNFSマウントを実行するためのコマンド例も表示されています。
ここでポイント
OCIでは仮想クラウド・ネットワーク(VCN)のセキュリティ・リストによって通信が制限されています。
セキュリティ・リストにイングレス・ルールを追加し、以下の必要な通信を許可します。
- 管理コンソールを使用するクライアントからストレージ・ゲートウェイ・サーバへのTCPプロトコル/32770ポートでの通信
- NFS領域をマウントするクライアントからストレージ・ゲートウェイ・サーバへのTCPプロトコル/32771ポートでの通信
ファイル・システムの追加
インストールが完了したら管理コンソールへ接続し、ファイル・システムを追加してみます。
ここでのファイル・システムは、ストレージ・ゲートウェイ用語です。
作成するファイル・システムは、クライアントからはNFS領域として利用され、ファイル・システム上のファイルやディレクトリは対応するオブジェクト・ストレージのバケット内に同一名のオブジェクトとしてマップされます。
WEBブラウザから管理コンソールへ接続するURLを入力します。
管理コンソールへ接続するURLは、先ほどの情報確認コマンドから得られます。
https://<ストレージ・ゲートウェイ・サーバのIPアドレス>:<管理コンソール用のポート番号>
初回のログインでは、Adminユーザのパスワード設定が求められますので、適切なパスワードを設定します。
ログイン後、画面に表示されている「Create File System」をクリックします。
ファイル・システムを作成するためにいくつか情報が必要になりますので、表でまとめてみました。
項目 | 説明 |
---|---|
File System Name | 対応するオブジェクト・ストレージのバケット名と同一の名前を入力します。 ここで入力する名前と一致するバケットが存在しない場合、ファイル・システム作成時にバケットも作成されます。 |
Object Storage Tier | ストレージ層の種類「Standard/Archive」を選択できます。 標準ストレージ層の場合は「Standard」を選択します。 アーカイブ・ストレージ層の場合は「Archive」を選択します。 |
Object Storage API Endpoint | 利用するオブジェクト・ストレージのAPIエンドポイント情報を入力します。 リージョン毎に異なるため、公式ドキュメントのエンドポイントの一覧から確認して下さい。 Object Storage Service API |
Compartment OCID | 利用するオブジェクト・ストレージのコンパートメントOCIDを入力します。 コンパートメントOCIDはOCIコンソールへ接続して、情報を確認することができます。 |
Tenant OCID | 利用するオブジェクト・ストレージのテナンシOCIDを入力します。 テナンシOCIDはOCIコンソールへ接続して、情報を確認することができます。 |
User OCID | 利用するオブジェクトストレージのユーザOCIDを入力します。 ユーザOCIDはOCIコンソールへ接続して、情報を確認することができます。 |
Public Key’s Finger Print | オブジェクト・ストレージ用にAPI署名キーを登録します。 事前に公開鍵と秘密鍵を生成しておきます。 この項目では公開鍵のフィンガープリントを入力します。 |
Private Key | 上と同様に、事前に生成したAPI署名キーの秘密鍵を入力します。 鍵を生成した際にパスフレーズを設定した場合、そのパスフレーズも入力が必要になります。 |
ファイル・システム作成が完了しましたら、オブジェクト・ストレージのバケットとの接続を実施します。
ファイル・システムの作成時にバケットを自動作成した場合は、OCIコンソールへ接続してバケットが作成されていることをこのタイミングで確認しましょう。
ファイル・システムの接続は、管理コンソールから行います。
「Connect」をクリックします。
検証では、接続が完了するまで数分間かかりました。
アイコンがグレーから緑色に変わったら接続完了です。
クライアントからOCIにファイルをアップロード
作成したファイル・システムを通して、クライアントからオブジェクト・ストレージにファイルをアップロードしてみます。
今回の検証ではOCI外部のクライアントとして、Oracle VM VirtualBoxを使用して、ローカルPC上に仮想マシンを用意しました。
仮想マシンが外部のネットワーク(ここではOCI上のストレージ・ゲートウェイ・サーバ)と通信できるように、仮想ネットワーク・アダプタを適切に設定しておきます。
仮想マシンのOSはOracle Linux 6を使用しています。このサーバから先ほど作成したファイル・システムをNFSマウントします。
マウント・コマンドは、インストール後に実行した「ocisg info」コマンドから確認しています。
[root@myhost ~]# mount -t nfs -o vers=4,port=32771 <IPアドレス>:/Bucket-SGW /bucketsgw1 [root@myhost ~]# [root@myhost ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 59G 55G 1.6G 98% / tmpfs 2.0G 72K 2.0G 1% /dev/shm /dev/sda1 190M 54M 126M 31% /boot <IPアドレス>:/Bucket-SGW 8.0E 0 8.0E 0% /bucketsgw1
マウント・ポイントは「/bucketsgw1」にしました。
さっそく、この領域にファイルをコピーしてみます!
[root@myhost ~]# ls -l /tmp/oracle total 897168 -rw-r--r-- 1 oracle oinstall 1581 Nov 2 11:47 export.log -rw-r--r-- 1 oracle oinstall 1247 Oct 19 17:44 import.log -rw-r----- 1 oracle oinstall 918687744 Oct 19 17:35 test_user.dmp [root@myhost ~]# [root@myhost ~]# cp /tmp/oracle/test_user.dmp /bucketsgw1
コピーが完了したら、OCIコンソールからオブジェクト・ストレージのバケット内にオブジェクトが作成されていることを確認します。
確かにコピーしたファイルが作成されていました。
アップロードには時間を要するため、この時点ではまだ「0バイト」となっています。
実際のアップロード状況は、ストレージ・ゲートウェイの管理コンソールの方から確認できます。
これでファイルのアップロードは完了です!
おわりに
今回の検証はこれで終わりです。
ストレージ・ゲートウェイを利用することで、クライアントは簡単にOracle Cloud上にファイルをアップロードすることができるようになりました。
現行のオンプレミス環境のシステムで、既存の設計にREST APIを新規に取り込むことなくOracle Cloudが使用できる便利なサービスですね。
Oracle Cloudに関して、何かございましたら、お気軽に当社までお問い合わせ下さい!
ハイレベルな技術者で構成されたOCI検証チームが対応致します。