はじめに
IBM Cloud Infrastructure(旧softlayer)で提供されているObject Storage OpenStack Swift サービス終息のアナウンスがでたため移行サービスのIBM Cloud Object Storage （AWSのS3互換）への移行検証を行いました。
Object Storage OpenStack Swift (Infrastructure) 一部サービスサポート終了のお知らせ
https://www.ibm.com/blogs/solutions/jp-ja/object-storage-openstack-swift-infrastructure/
- 2019年3月31日でObject Storage OpenStack Swift一部機能が利用できなる。
- TOK02(東京）は2019年3月31日以降、具体的な日程は決まってないが、近日中にすべての機能が利用できなくなる。
移行手順がIBM Cloudで公開さているので、今回知りたかったのは自分の環境では手順通り移行できるのか、どれくらい時間がかかるのかです。
Migrating data from OpenStack Swift
https://cloud.ibm.com/docs/services/cloud-object-storage/tutorials/migrate.html#migrating-data-from-openstack-swift
IBM Cloudで公開されているのは英語ドキュメントですが、qiitaに同内容のものを @khayama さんが日本語のドキュメントを投稿されています。
IBM Cloud Object Storage のデータを Swift API コンテナ から S3 API バケットに移行する
https://qiita.com/khayama/items/0a55c2001aa5efe55286
今回の投稿では、ドキュメントは整備されているので環境構築の部分は省略します。
構成
データ移行用のVSI(仮想サーバ）を用意し、そのVSIに設置したデータ移行ツール(rclone)を実行すると Object Storage OpenStack Swift(Swift)のコンテナに保存しているデータをVSIを経由して、IBM Cloud Object Storage(S3)のバケットに転送する仕組みになっています。
今回は、以下の３回検証を行います。
- TOK02(東京)の01コンテナ(Swift) から Regional/JP-TOK
の01-s3バケット(S3)への移行 - TOK02(東京)の02コンテナ(Swift) から Regional/JP-TOKの02-s3バケット(S3)への移行
- TOK02(東京)の03コンテナ(Swift) から Regional/JP-TOKの03-s3バケット(S3)への移行
今回用意したVSIのスペックは下記の通りで、CPUは2 Coreで100%使い切りそうなので4 Coreを選択、帯域は最大の1Gbps、それ以外は選択できた最小値です。
- OS: CentOS7
- CPU: 4 Core
- Memory: 4GB
- HDD: 25GB
- NIC: 1Gbps (Private Network Only)
テストデータ
Swiftの01から03のコンテナにContentLengthがそれぞれ同程度になるように用意しました。
- 01コンテナ: 単体ファイル(１ファイル容量100MBから700MB)
- 02コンテナ: 小さなファイル(1ファイル容量約200KB)でオブジェクト数がたくさんあるもの
- 03コンテナ: 1ファイル容量5GB以上のSwiftへファイル分割アップロード(SLO)されたラージオブジェクト
01コンテナは通常のパターン、02コンテナは時間がかかると想定されるもの、03コンテナはラージオブジェクトの取り扱いがSwiftとS3では違うので確認したいとそれぞれ分けて検証します。
Swift, S3ともに１オブジェクトの最大サイズは 5GB という制限があります。
検証01 単体ファイル(１ファイル容量100MBから700MB)の移行
TOK02(東京)の01コンテナ(Swift) から Regional/JP-TOKの01-s3バケット(S3)への単体ファイル(１ファイル容量100MBから700MB)の移行検証を行います。
以下のコマンドで実施します。
# rclone -v copy --checksum SWIFT:01 COS:01-s3
下記のログから407オブジェクト、総容量213.473Gを平均123.768MBytes/sのスピードで29分26秒で終了していることがわかります。
2019/01/20 01:11:05 INFO : S3 bucket 01-s3: Waiting for checks to finish
2019/01/20 01:11:05 INFO : S3 bucket 01-s3: Waiting for transfers to finish
<<<<<<<<<<<<<<<<<<<<<<<<< skip >>>>>>>>>>>>>>>>>>>>>>>>>
2019/01/20 01:40:06 INFO : tokyo201807-2.mp4: Copied (new)
2019/01/20 01:40:31 INFO : tokyo201807-1.mp4: Copied (new)
2019/01/20 01:40:31 INFO :
Transferred: 213.473G / 213.473 GBytes, 100%, 123.768 MBytes/s, ETA 0s
Errors: 0
Checks: 0 / 0, -
Transferred: 407 / 407, 100%
Elapsed time: 29m26.1s
実行時のhtopの結果: CPUは4Coreそれぞれ80%前後を遷移していました。
最後に、01コンテナと01-s3バケットのファイルが一致するかチェックします。
# rclone -v check SWIFT:01 COS:01-s3
0 differences foundと全てのファイルが一致しています。
2019/01/21 01:25:12 INFO : S3 bucket 01-s3: Waiting for checks to finish
2019/01/21 01:25:29 NOTICE: S3 bucket 01-s3: 0 differences found
検証01まとめ
この検証から407オブジェクト総容量213.473Gの100MBから700MBのファイルを
CPU 4Coreを80％前後使用して平均123.768MBytes/sのスピードで29分26.1秒で移行できることがわかりました。 この結果を基準にして検証2と検証3に進みます。
検証02 小さなファイルでオブジェクト数がたくさんあるケースの移行
TOK02(東京)の02コンテナ(Swift) から Regional/JP-TOKの02-s3バケット(S3)へ小さなファイル(1ファイル容量約200KB)でオブジェクト数がたくさんあるケースを移行します。
以下のコマンドで実施します。
# rclone -v copy --checksum SWIFT:02 COS:02-s3
1122523オブジェクト、総容量213.213Gの転送を平均7.78MBytes/sのスピードで7時間47分44秒で終了していました。
2019/01/20 02:11:33 INFO : kanagawa2018-1/01.m3u8: Copied (new)
2019/01/20 02:11:33 INFO : kanagawa2018-103/01.m3u8: Copied (new)
<<<<<<<<<<<<<<<<<<<<<<<<< skip >>>>>>>>>>>>>>>>>>>>>>>>>
2019/01/20 09:59:14 INFO : yokohama2019-999/stream-0-128000/frag-98.ts: Copied (new)
2019/01/20 09:59:14 INFO : yokohama2019-999/stream-0-128000/index.m3u8: Copied (new)
2019/01/20 09:59:14 INFO :
Transferred: 213.213G / 213.213 GBytes, 100%, 7.780 MBytes/s, ETA 0s
Errors: 0
Checks: 0 / 0, -
Transferred: 1122523 / 1122523, 100%
Elapsed time: 7h47m44s
実行時のhtopの結果: CPUは4Coreそれぞれ10%前後を遷移して十分に使いきれていません。
最後に、02コンテナと02-s3バケットのファイルが一致するかチェックします。
# rclone -v check SWIFT:02 COS:02-s3
0 differences foundと全てのファイルが一致していますが検証1で17秒で終了したものが、今回は35分かかっています。
2019/01/21 01:25:56 INFO : S3 bucket 02-s3: Waiting for checks to finish
2019/01/21 02:01:00 NOTICE: S3 bucket 02-s3: 0 differences found
検証02 まとめ
この検証から1122523オブジェクト総容量213.213Gの小さなファイル(約200KB)を7時間47分44秒で終了し、検証1の実行時間29分26秒に比べると約15倍遅い結果になりました。
CPU 4Coreを10％前後使用、平均7.780 MBytes/sのスピードとリソースは十分に余っているので、今回はやってませんが追加検証を行う場合は、rcloneの並行して実行されるファイル転送数はデフォルト4なので、並列数を増やして、時間が短縮されるか工夫が必要だと考えています。
rcloneの並行して実行されるファイル転送数のパラメータは下記になります。
--transfers=N
検証03 1ファイル容量5GB以上のラージオブジェクトの移行
TOK02(東京)の03コンテナ(Swift) から Regional/JP-TOKの03-s3バケット(S3)へ1ファイル容量5GB以上のSwiftへファイル分割アップロード(SLO)されたラージオブジェクトを移行します。
以下のコマンドで実施します。
# rclone -v copy --checksum SWIFT:03 COS:03-s3
224オブジェクト、総容量393.412Gを平均128.768MBytes/sのスピードで52分11.1秒で終了しています。
なぜか、テストデータは213.67GBなのに393.412GB転送されていてデータ量が増えています。おそらく、 SwiftとS3のLargeObject(１ファイル5GB制限)の取り扱いは異なるので、ファイルの実体はS3のLargeObjectの取り扱いで保存され、SwiftのObjectStorageにファイルを分割アップロード(SLO)した .file-segments/ファイル名/ フォルダ以下のファイルも、そのまま転送されたため容量が増えたのだと思われます。
そのため .file-segments/ フォルダを除外して転送を行えばよさそうです。実行する場合は以下のコマンドを実施します。
rclone -v copy --checksum SWIFT:03 --exclude .file-segments/ COS:03-s3
実行時のhtopの結果: CPUは4Coreそれぞれ90%前後を遷移していました。
次に03コンテナと03-s3バケットのファイルが一致するかチェックします。
# rclone -v check SWIFT:03 COS:03-s3
8 hashes could not be checkedとこれまでと違ってhashが一致していないものが出ててきました。
2019/01/22 02:28:01 INFO : S3 bucket 03-s3: Waiting for checks to finish
2019/01/22 02:28:05 NOTICE: S3 bucket 03-s3: 0 differences found
2019/01/22 02:28:05 NOTICE: S3 bucket 03-s3: 8 hashes could not be checked
上記ログではよくわからないので、DEBUGも出力するように再度コマンドを実行します。
# rclone -vvv check SWIFT:03 COS:03-s3
8件全て「 Returning empty Md5sum for swift large object」 と swift large objectのマニュフェストファイルなので、気にする必要はありませんでした。
2019/01/22 02:29:46 INFO : S3 bucket 03-s3: Waiting for checks to finish
<<<<<<<<<<<<<<<<<<<<<<<<< skip >>>>>>>>>>>>>>>>>>>>>>>>>
2019/01/22 02:29:46 DEBUG : nagoyaa1812-1.mov: Returning empty Md5sum for swift large object
2019/01/22 02:29:46 DEBUG : nagoyaa1812-1.mov: OK
2019/01/22 02:29:46 DEBUG : nagoyaa1812-2.mov: Returning empty Md5sum for swift large object
2019/01/22 02:29:46 DEBUG : nagoyaa1812-2.mov: OK
2019/01/22 02:29:46 DEBUG : nagoyaa1812-4.mov: Returning empty Md5sum for swift large object
2019/01/22 02:29:46 DEBUG : nagoyaa1812-4.mov: OK
2019/01/22 02:29:47 DEBUG : tokyo1804-5.MOV: OK
2019/01/22 02:29:47 DEBUG : tokyo1804-6.MOV: OK
2019/01/22 02:29:47 DEBUG : tokyo1804-7.MOV: OK
2019/01/22 02:29:47 DEBUG : tyosun1812-1.mov: Returning empty Md5sum for swift large object
2019/01/22 02:29:47 DEBUG : tyosun1812-1.mov: OK
2019/01/22 02:29:47 DEBUG : tyosun1812-2.mov: Returning empty Md5sum for swift large object
2019/01/22 02:29:47 DEBUG : tyosun1812-2.mov: OK
2019/01/22 02:29:47 DEBUG : tyosun1812-3-2.mov: Returning empty Md5sum for swift large object
2019/01/22 02:29:47 DEBUG : tyosun1812-3-2.mov: OK
2019/01/22 02:29:47 DEBUG : tyosun1812-3.mov: Returning empty Md5sum for swift large object
2019/01/22 02:29:47 DEBUG : tyosun1812-3.mov: OK
2019/01/22 02:29:47 DEBUG : tyosun1812-4.mov: Returning empty Md5sum for swift large object
2019/01/22 02:29:47 DEBUG : tyosun1812-4.mov: OK
<<<<<<<<<<<<<<<<<<<<<<<<< skip >>>>>>>>>>>>>>>>>>>>>>>>>
2019/01/22 02:29:50 NOTICE: S3 bucket 03-s3: 0 differences found
2019/01/22 02:29:50 NOTICE: S3 bucket 03-s3: 8 hashes could not be checked
追加試験: 03コンテナ(Swift)の.file-segments/ フォルダを除外して、新規に追加した04-s3バケット(S3)の試験を実施しました。
rclone -v copy --checksum SWIFT:03 --exclude .file-segments/ COS:04-s3
下記のログから11オブジェクト、総容量189.432Gを平均98.431MBytes/sのスピードで32分49.7秒で終了していました。
2019/01/20 22:44:38 INFO : S3 bucket 04-s3: Waiting for checks to finish
2019/01/20 22:44:38 INFO : S3 bucket 04-s3: Waiting for transfers to finish
2019/01/20 23:17:28 INFO : tyosun1812-4.mov: Copied (new)
2019/01/20 23:17:28 INFO :
Transferred: 189.432G / 189.432 GBytes, 100%, 98.481 MBytes/s, ETA 0s
Errors: 0
Checks: 0 / 0, -
Transferred: 11 / 11, 100%
Elapsed time: 32m49.7s
ファイルの実体の数11と転送したオブジェクト数はあっていて、04-s3バケット(S3)からtyosun1812-4.movのファイルをダウンロードして、動画が再生できたので,swiftの.file-segmentsフォルダは除外して転送するのが正解でした。
検証03 まとめ
この検証から LargeObjectを転送する場合は、SwiftとS3のLargeObject(１ファイル5GB制限)の取り扱いは異なるので、Swiftの.file-segmentsフォルダを除外して転送しないと、ファイルの実体以上の容量を転送することになることがわかりました。
また、ファイルが一致するかチェックする場合も同様にSwiftとS3のLargeObject(１ファイル5GB制限)の取り扱いは異なるので、Swiftのマニュフェストファイルでhashが一致しないと出力されることがわかりました。
まとめ
検証01から検証03までのネットワークトラフィックとCPU Load Averageのグラフ
検証01から検証03までそれぞれ総容量約213GBのデータ転送をIBM Cloudで公開されている手順で移行検証を行いました。
- 検証01: 単体ファイル(1ファイル容量100MBから700MB)
- 検証02: 小さなファイル(1ファイル容量約200KB)でオブジェクト数がたくさん(1122523Oオブジェクト)あるもの
- 検証03: 1ファイル容量5GB以上のSwiftへファイル分割アップロード(SLO)されたラージオブジェクト
今回の検証では、手順の確認に以外にわかったことは以下の２つです。
- 検証02の小さなファイルがたくさんの場合は、検証01よりも約15倍時間がかかる。可能ならばCPUのロードアベレージも低いので、転送の並列数を増やすことを検討するのがよさそう。だめなら、余裕を持ったスケジュールを組まないといけない。
- 検証03でSwiftとS3のLargeObject(１ファイル5GB制限)の取り扱いは異なるので、ファイルの実体以外に、Swiftの分割ファイル(.file-segmentsフォルダ)は除外しないとファイルの実体以上に転送することになる。
幸い自分が移設しなければならない環境では、検証01から検証03までフォルダが分かれているので、今回の検証で目安ができましたが、ファイルが混在していて大容量の環境の場合は、転送の並列数も変更できないでしょうから移設の長期化など苦労しそうです。
最後に今回の検証がみなさんの参考になれば幸いです。