LoginSignup
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@damepanda_supra(Toshihisa Noguchi)inTIS株式会社

FSx for NetApp ONTAPとFlexCacheを組み合わせてファイルサーバのマイグレーションを考える。

Last updated at Posted at 2023-05-05

この記事はFSx for NetAppとFlexCacheのお話です。

はじめに

あるところに、オンプレミスで動いているファイルサーバをクラウドにマイグレーションを検討している情報システムの人がいました。ファイルサーバは、データセンタと各オフィスで稼働しています。データセンタのファイルサーバのマイグレは、オフィスからみるとアクセスの先が変わるだけなので、情報システムもそれほど問題視していませんでした。
問題は、オフィスにおいてあるファイルサーバのクラウドへのマイグレです。オフィスのファイルサーバは、オフィス内のL3スイッチの先にぶら下がっています。オフィスのメンバーからはクラウドへのマイグレに対して、性能低下への強い懸念と不信感を持たれています。オフィスのファイルサーバは巨大なファイル、たくさんの写真のファイルを取り扱っています。情報システムの人はこの課題に対して、どのように取り組むべきでしょうか？

お約束とご了承事項。
エンジニア向けのナレッジ提供用として作成しています。
ベンチマーク結果（詳細）は、一人歩きするリスクがあるため非公開とする予定です。
所感だけこちらに公開します。興味があるかたはお知らせください。
Qiitaの非公開リンクを作成しています。

考慮のポイント

考慮ポイントは簡単にまとめます。

  • オフィスにファイルサーバがおいてある。
  • 大きいファイルとたくさんの写真ファイルを取り扱っている。
  • 読み書きがそこそこある。
  • 遅延対策でオフィスにファイルサーバをおいた過去の経緯。

なぜオフィスにファイルサーバをおいているかを考慮する。

  • 大きいファイルがある。（読み書き）

マイグレーション方針は？（この記事では割愛）

  • 一般的なRoboCopyで移行（よくある話）
  • ファイルサーバにNetAppを使っているのであれば、SnapMirrorで移行（NetApp to NetAppの定番）

前提条件

  • 利用するAWS上のサービスはFSx for NetApp ONTAPを活用。
  • 一つのストレージはシェアして利用する（例：NFSとか）。
  • ネットワークの帯域はそこそこ潤沢であると仮定（1Gbpsとか）

今回のテストはWANをVPC Peeringでつないでいるため、帯域は比較的潤沢です。
本気で検証する場合は、ShapeやJitterなどを発生させる装置を挟んで試験してもいいかと思います。

テスト環境はこちら

  • AWS東京リージョン（メインFS）と、AWSシンガポールリージョン（FlexCache）で実施
  • ADはAWS Managed ADを活用、クライアントはシンガポールリージョンで稼働するWindows2022
    本当はClient OSで試したいが・・・。（以下略）
  • NetApp上のSVMは東京/シンガポール共にAD参加済み。クライアントもAD参加済み。
  • 東京リージョンとシンガポールリージョンはVPC Peeringで接続をしている。遅延値は60ms～70ms程度
  • メインのファイルサーバは100GBで作成、FlexCacheは効果を見極めるため10GBで作成。（10%としました）

環境情報はこちら

  • Tokyo(172.27.0.0/21):AWS-Managed AD
  • Tokyo-FSx(172.27.16.0/21):FSx for NetApp ONTAP
  • Singapore(172.27.32.0/21):AD
  • Singapore-FSx(172.27.28.0/22):FSx for NetApp ONTAP

構成図はこちら

WorkloadとFSxのVPCが分かれている理由は、Workload側がVMC on AWSのLinkedセグメントです。
国内で上記の課題を考える場合は、一般的な回線で東京－大阪で10ms程度が目安かと思います。
絵がヘタなのは突っ込まないでください。
image.png

PING遅延は実測値です。

  • 172.27.22.28は東京リージョン
  • 172.27.28.190はシンガポールリージョン
    Image.png

FSx for NetAppの構成はこちら

  • 画面キャプチャは抜粋です。
  • 東京もシンガポールも最小構成のFSxで構成しています。
    実際に動いているFSxの設定はこちらです。（お金かかるので最小構成）
    image.png

東京（DataVolume側）

  • Volume
    image.png

シンガポール（FlexCache側）

  • Volume
    image.png
  • FlexCache
    image.png

テスト方法

  • 大きく二つのテスト方法を実施しています。
  1. 大きいファイルのテスト（1GB程度のファイル）
    ファイルの中身はOVAファイル1個です。
  2. 小さい大量のファイルのテスト（2GB/630個のファイル）
    ファイルの中身は写真や動画です。（主にJPGとか動画）

共有はFSX01（DataVolume）側も、FSX02（FlexCache）側も同じ用に作成しています。
管理者端末から、fsmgmt.mscで作成しました。

  • FSX01側
    Image.png

  • FSX02側
    Image.png

結果まとめ

  • FlexCacheの効果について
  1. 大きなファイルの読み込み：効果あり
  2. 大きなファイルの書き込み：効果あり（本来はReadでしか効かないはず。要確認）
  3. 小さなファイルの読み込み：効果絶大（一番わかりやすい効果だった）
  4. 小さなファイルの書き込み：効果なし（逆に直接東京に書いた方が高速だった。要確認）
  • 所感
    FlexCacheの効果は、大きなファイルで2倍程度、小さいファイルだと数倍程度の読み込み速度の効果があるため、大量アクセスのファイルサーバのマイグレ時のチューニングアイテムとしては効果があることはわかった。
    ただし、得手不得手があるため全般的に効果があるということではないので、このあたりは各々でテストが必要であると考える。

参考資料

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?