![[小ネタ] クロスケーブル直結でAWS SnowconeのNFSサーバーを利用してみた](https://devio2023-media.developers.io/wp-content/uploads/2021/12/AWS-Snowcone.png)
[小ネタ] クロスケーブル直結でAWS SnowconeのNFSサーバーを利用してみた
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
しばたです。
AWS Snowconeには物理NICが2個ついており両方利用することができます。
データ移行におけるデータ転送のネットワーク負荷を最低限にするためにデータ転送元サーバーとSnowconeデバイスをクロスケーブル直結で利用することができないか試してみました。
どういうこと?
こういうことです。

NIC二枚刺しのデータ転送元サーバーのうち一つのNIC(図ではeth1)をクロスケーブルでSnowconeと直結させ転送に使います。
利用者(ぼく)はSnowconeの残りのNICに対しAWS OpsHubで接続しデバイス管理を行う、といった感じです。
なお、図に具体的なCIDR(192.168.9.0/24と192.168.20.0/24)が割り振られていますがこれは私の自宅ネットワークの都合なだけで特別な意味はありません。
やってみた
先に結論から書くと「若干の制限はあるが実現可能」でした。
まずはAWS OpsHubからNFSサーバーを手動作成します。

(クイックセットアップだとIPなど自動で決められてしまうのでダメ)

物理NICをクロスケーブル直結させる方を選び適切なIPアドレスとサブネットを割り当てます。
直結させるので「すべてホストを許可」で問題ないでしょう。

これでNFSサーバーが出来上がるのを待ちます。

しばらく待つと以下のエラーメッセージが出るもののNFSサーバーの状態は「アクティブ」になります。
NFS マウントポイントを取得できませんでした。NFS アクティベーションが完了するまで待機するか、NFS の非アクティブ化および再アクティブ化をお試しください

どうもNFSサーバーのマウントポイントについてはSnowcone内部からではなくAWS OpsHubのクライアント側から取得する処理が行われている様です。
このためAWS OpsHubから到達できず(できるわけがない)エラーを吐きます。
その代わりにCLIからNFSサーバーの状態を確認すると問題ないことがちゃんとわかります。
# CLIからはNFSサーバーの状態を問題なく取れる
C:\> snowballEdge describe-service --service-id nfs --profile my-first-snowcone
{
  "ServiceId" : "nfs",
  "Status" : {
    "State" : "ACTIVE"
  },
  "Endpoints" : [ {
    "Protocol" : "nfs",
    "Port" : 2049,
    "Host" : "192.168.20.3"
  } ],
  "ServiceConfiguration" : {
    "AllowedHosts" : [ "0.0.0.0/0" ]
  }
}
この状態でもサーバーからはちゃんとNFSサーバーにアクセス可能です。
AWS OpsHubからマウントポイントを取得できないので、サーバー上でshowmountコマンドを使うなどしてください。
# NFSサーバーと疎通可能なサーバーで実施
showmount -e 192.168.20.3
結果こんな感じで無事NFSサーバーにアクセスできました。

補足 : NFSサーバーの無効化
ちなみにこの構成にするとAWS OpsHubからNFSサーバーを無効にすることができなくなります。

(どうやらOpsHubではマウントポイントの取得までチェックしたうえで「正常」扱いする模様)
このためNFSサーバーを無効にする場合はCLIからsnowballEdge stop-serviceコマンドを実行してください。
# CLIからNFSサーバーを無効にする
C:\> snowballEdge stop-service --service-id nfs --profile my-first-snowcone
Stopping the service on your Snowball Edge. You can determine the status of the service using the describe-service command.
# 無事無効になったのを確認
C:\> snowballEdge describe-service --service-id nfs --profile my-first-snowcone
{
  "ServiceId" : "nfs",
  "Status" : {
    "State" : "INACTIVE"
  }
}
AWS OpsHubで確認してもちゃんと初期状態に戻りました。

最後に
簡単ですが以上となります。
Snowconeで扱うデータ量であればそこまで問題になることは少ないと思いますが、もしネットワーク転送量を気にする場合はこの様な構成も可能だということを共有しておきます。








