Automatic selection設定の仕様について(Veeam)

# 近況
FF7 Rebirthの2週目をハードモードで進めています。
大体2月末から200時間やってますが、トロフィーコンプリートまで結構かかりそうです。
ちなみに2週目のデート相手はティファでした。めっちゃよかった。。。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3494465/5b15e7d4-9b58-b7aa-0fb3-3b0115ab83e2.png)

# 本題

いま参画している案件の中で、Veeamを使用した移行環境を作り、お客さんに移行自体を実施してもらうといった作業を担当しています。
その中でお客さんから「移行実施時にエラーが出た！」と問い合わせをいただき、調査し解決できたので、ここに備忘メモとして残しておこうと思います。

# エラーが起きた環境
結構特殊(?)だとは思うので、整理しておきます。

#### ①お客さんの移行元、移行先はそれぞれvSphere環境です。現行基盤(vSphere7.0.2)から新基盤(vSphere8.0.2)へ移行していきます。

#### ②登場する環境は3つあります。一般的な本番環境や開発環境といった環境が3つあるイメージです。
(この記事ではそれぞれA～C環境として書いていきます。)

#### ③A～C環境については図のような関係になっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3494465/63c94e8a-38a0-26ae-1835-2e0b651604c0.png)

なお、**A環境とB環境は完全に通信できません。**
↑
今回はここが重要です！

#### ④レプリケーションジョブの設定
ジョブの設定の中で、データ転送に使用するVeeamのproxyサーバーの設定を指定する箇所があるんですが、その設定を[Automatic selection]に設定しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3494465/eee17ec9-d2f8-ce30-1244-3518fc91043f.png)

#### ⑤レプリケーションの実行環境

今回のジョブが失敗したのは、B環境からC環境への移行で発生しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3494465/6a769194-0e13-9d01-4cad-9150c96e1568.png)


# エラー内容

ジョブ実行時に以下のエラーが出て、ジョブに失敗しました。

**Error: Cannot get service content.
Soap fault. No route to hostDetail: 'connect failed in tcp_connect()', endpoint: 'https://X.X.X.X:443/sdk’**

X.X.X.Xの部分は、B環境ESXiホストのIPです。

# エラーメッセージから調査して確認した内容

エラーメッセージで検索をかけたとところ、以下のページに引っかかり、どうやら「ESXiホストとバックアップサーバーの通信がうまく取れていない」とのことでした。

https://forums.veeam.com/vmware-vsphere-f24/unable-to-establish-soap-connection-no-route-to-host-error-veeam-12-case-07030198-t91158.html

結果として、バックアップサーバーとvCenter(今回はバックアップサーバーにvCenterを登録し、通信している)
の通信を確認しましたが、特に問題はなく通信できていました。(vCenterのRescanや再登録を実施)

# エラーログから調査して確認した内容
Veeamのログを確認したところ、以下のようなエラーも出ていました。

**Failed to create NFC download stream.**

これで検索をかけると、kbが見つかったので記載されている対処法/切り分けを試したところ、レプリケーションが成功するようになりました。

https://www.veeam.com/kb1198

### 確認したこと①
**名前解決の確認**：バックアップサーバーと移行元vCenter,ESXiが名前解決できているかを確認しました。

` nslookup <B環境ESXiホストのFQDN>` 
` nslookup <B環境vCenterのFQDN>` 

結果は問題なく名前解決できていました。


### 確認したこと②
**ポート902が空いていることの確認**：バックアップサーバーと移行元vCenter,ESXiでポート902の通信ができるかを確認しました。

`Test-NetConnection [B環境vCenterのIP] -Port 902`
`Test-NetConnection [B環境ESXiのIP] -Port 902`

結果は問題なく通信できていました。


### 確認したこと③

**移行元VMを別ホストにvMotionしてからのレプリケーション実行確認**：問題の切り分けとして、ESXiホスト側に問題があるかを確認しました。

実行結果としては、状況が変わらず、同じエラーで失敗しました。
ホスト側の問題ではなかったみたいです。

※Storage vMotionをすることで、ストレージ側に問題があるかどうかを確認するのも切り分けとして実施した方がいいです。
(このお客さんの環境では、vSphereのライセンス的にStorage vMotionができなかった。)



### 確認したこと④

**使用するproxyを明示的に指定し、レプリケーション実行確認**：問題の切り分けとして、proxyサーバー側に問題があるかどうかを確認しました。

指定したproxyはC環境のバックアップサーバーです。(バックアップサーバーはproxyとしての役割も担っているため指定可能)

実行結果としては、レプリケーションジョブ実行時のエラーは起こらず、正常に終了しました
これで原因はproxyサーバーであることがわかりました。


# 原因
結論から言うと、レプリケーションジョブ設定値の[Automatic selection]の仕様理解不足でした。

[Automatic selection]の仕様は自身の中で勝手に画像のようなものだと考えてしまっていました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3494465/02931a1e-636a-45a7-6639-72ed09e06ad1.png)

黒色のproxyはデータの転送に使用できないため、レプリケーションジョブにアサインされないものだと思い込んでいました。

実際の仕様としては、以下の画像の通りです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3494465/e8437c33-ef57-05ce-cba0-c24a26dc49dd.png)


Automatic selectionの仕様は以下のようになっています。

**①バックアップサーバーからみて、通信ができているproxyの中で、負荷の低いproxyをジョブにアサインする**

**②アサインされたproxyサーバーと移行元のESXiが通信できない場合、別のproxyを使用するような機能はない**

また、エラーの直接の原因となっているのは、proxyから移行元のvCenterやESXiに対し、443で通信できないことが原因です。



# エラーを解消する方法
複数の環境にproxyサーバーを立てている場合は、[Automatic selection]ではなく、明示的にproxyサーバーを指定する必要があります。
移行元と移行先が1対1であれば特に意識せずに[Automatic selection]でよいと思います。

# さいごに
それなりにVeeam移行をやってきていたので、意識せずに設定値を入れていましたが、次からはここもしっかり検討していく必要がありそうです。
同じような環境でエラー調査をしている方の一助となればいいなと思います。
それではまたどこかで。