ドブにはまってしまいました。トホホホ…
これによる修正作業費が発生する。
今日も続けてNutanix Filesの話です。これから導入される方は、この記事はとっても重要！役に立てるかも？
Filesに関するNutanixバイブルはここあたり。
Advent Calendar 2022 に関しての連続投稿8日目になります。
Arcserve UDP ApplianceからNutanix Files（過去記事）のファイルサーバのバックアップを行うにあたって、ネットワーク設計上での大問題が発覚した。
これから投稿する内容は、下記記事となります。
上記のURLが読めない方もおられると思うので、何ぞや？について説明していきます。ただ間違っている内容もあると思いますので、ご指摘下さい。
Nutanix Test Driveでは、この構築手順までウィザードで説明されているので、設定の流れが分かるぞ！ただ、実行はできなかった。
下画像はNutanix Filesのプラットフォームconfigration画面。Test Driveでやろうとしたら、エラーが出たので、Test Driveでは見れない画面。
注目すべき箇所は、ちょっとした絵が描かれている部分。
Network7とNetwork6の両セグメントをもっているVMがFSVM（ファイルサーバVM）。最低3台なので、3台になっている。
Files では、ファイル共有にアクセスするクライアントや NTP、DNS、Active Directory、LDAPなどへの接続に用いられる Client Network （クライアントネットワーク）と、CVM （Nutanix HCIの管理やストレージコントローラ機能をもつコンポーネント）とストレージIOのために使用される Storage Network （ストレージネットワーク）の２つのネットワークを設定する必要があります。この２つのネットワークで異なるサブネットを指定している場合、ストレージネットワークのサブネットにのみ存在するクライアントについてはFilesの共有フォルダにはアクセスできまない。
上記画像では、ストレージネットワークはInternal Network6（VLAN6、192.168.6.xxx）と、クライアントネットワークのExternal Network7（VLAN7、192.168.7.xxx）という2つのネットワークセグメントで構成して運用している。
VLAN6は開発環境用として利用し、VLAN7は本番環境用として、サーバセグメントを2分して運用し10年目。
つまり、VLAN6の機器からは、Filesの共有フォルダにアクセスができない！
VLAN7のPCは、このCVMを介してVLAN6のストレージにアクセスする。すると、CVMはストレージ側のVLAN6を利用して通信の返事を行う。VLAN6以外のクライアント機器であれば問題ない。
しかし、VLAN6の機器から接続が行われた場合に問題が発生する。
VLAN6機器からストレージにアクセスした際、ストレージ側から戻る際に自分たちのセグメントがVLAN6で構成されていることを受け、カーネルのセキュリティポリシーに反するため、パケットはカーネルのレベルで廃棄される。それが影響して、Filesの外にあるVLAN6の機器に通信を返せないという問題が発生。その結果、通信できない、ということになってしまう。
これを回避するためには、セグメントを分けない設定、クライアントネットワーク(Network7)をストレージネットワーク(Network6)と同じセグメントにすることで、通信の帰れる道ができるわけだが、あんまり気持ち的に行いたくない。
FSVM、CVMの位置関係を分かりやすく描かれていたブログがありましたので参考を…
（参考） Nutanix Files の可用性／拡張性の特徴とは？（SB C&Sの最新技術情報 発信サイト）
今後の勤務先での課題は、VLAN6＝開発環境という位置づけにしていた環境を、開発環境をVLAN6以外の未使用セグメントに構え直すということになりそうだ。このVLAN6, 7でサーバ群として利用して10年もたてば、そろそろ改変してもいいかな…？
で、冒頭の話に戻ります。
Nutanix FilesをArcserve UDP Applianceでバックアップしようとした際、AHVの場合はBackup Proxy経由でバックアップすることになる。この、Backup Proxyは本番ネットワークに影響を与えないよう開発環境のVLAN6で設定しているため、Filesへのアクセスできないよー！なんで？ということが問題で調査した結果の内容だ。Arcserve UDP Applianceについても過去記事は充実しているつもり。参考ください。
最近のコメント