

Amazon FSx File Gateway 不再提供給新客戶。FSx File Gateway 的現有客戶可以繼續正常使用服務。如需類似 FSx File Gateway 的功能，請造訪[此部落格文章](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/)。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 針對 Storage Gateway 部署的問題進行故障診斷
<a name="troubleshooting-gateway-issues"></a>

您可以在下面找到與閘道、主機平台、檔案系統、高可用性、資料復原和快照相關的最佳實務和疑難排解問題的相關資訊。內部部署閘道疑難排解資訊涵蓋部署在支援的虛擬化平台上的閘道。高可用性問題的故障診斷資訊涵蓋了在 VMware vSphere High Availability (HA) 平台上執行的閘道。

**主題**
+ [故障診斷：閘道離線問題](troubleshooting-gateway-offline.md) - 了解如何診斷可能導致您的閘道在 Storage Gateway 主控台中離線顯示的問題。
+ [故障診斷：Active Directory 問題](troubleshooting-active-directory.md) - 了解如何在嘗試將檔案閘道加入 Microsoft Active Directory 網域`ACCESS_DENIED`時收到錯誤訊息，例如 `TIMEOUT`、 `NETWORK_ERROR`或 。
+ [故障診斷：閘道啟用問題](troubleshooting-gateway-activation.md) - 了解如何在嘗試啟用 Storage Gateway 時收到內部錯誤訊息。
+ [故障診斷：內部部署閘道問題](troubleshooting-on-premises-gateway-issues.md) - 了解使用內部部署閘道時可能遇到的典型問題，以及如何允許 支援 連線至閘道以協助故障診斷。
+ [故障診斷：Microsoft Hyper-V 設定問題](troubleshooting-hyperv-setup.md) - 了解在 Microsoft Hyper-V 平台上部署 Storage Gateway 時可能遇到的典型問題。
+ [故障診斷：Amazon EC2 閘道問題](troubleshooting-EC2-gateway-issues.md) - 尋找您在使用 Amazon EC2 上部署的閘道時可能遇到的典型問題的相關資訊。
+ [故障診斷：硬體設備問題](troubleshooting-hardware-appliance-issues.md) - 了解如何解決使用 AWS Storage Gateway 硬體設備時可能遇到的問題。
+ [故障診斷：檔案閘道問題](troubleshooting-file-gateway-issues.md) - 尋找可協助您了解檔案閘道 CloudWatch 日誌中出現錯誤和運作狀態通知的原因的資訊。
+ [故障診斷：高可用性問題](troubleshooting-ha-issues.md) - 了解如果在 VMware HA 環境中部署的閘道發生問題，該怎麼辦。

# 故障診斷：Storage Gateway 主控台中的閘道離線
<a name="troubleshooting-gateway-offline"></a>

如果主控台顯示您的閘道離線， AWS Storage Gateway 請使用下列疑難排解資訊來判斷該怎麼做。

由於以下一個或多個原因，您的閘道可能顯示為離線：
+ 閘道無法連線到 Storage Gateway 服務端點。
+ 閘道意外關閉。
+ 與閘道相關聯的快取磁碟已中斷連線或修改，或已失敗。

若要讓閘道重新上線，請識別並解決導致閘道離線的問題。

## 檢查相關聯的防火牆或代理
<a name="w2ab1c54c12c11"></a>

如果您將閘道設定為使用代理，或將閘道放置在防火牆後方，請檢閱代理或防火牆的存取規則。代理或防火牆必須允許進出 Storage Gateway 所需網路連接埠和服務端點的流量。如需詳細資訊，請參閱[網路和防火牆需求](https://docs.aws.amazon.com/filegateway/latest/filefsxw/Requirements.html#networks)。

## 檢查閘道流量的持續 SSL 或深度封包檢查
<a name="w2ab1c54c12c13"></a>

如果目前對閘道和 之間的網路流量執行 SSL 或深度封包檢查 AWS，則閘道可能無法與所需的服務端點通訊。若要讓閘道重新上線，您必須停用檢查。

## 在重新啟動或軟體更新後檢查 IOWaitPercent 指標
<a name="w2ab1c54c12c15"></a>

重新啟動或軟體更新後，請檢查檔案閘道的`IOWaitPercent`指標是否為 10 或更高。這可能會導致閘道在重建索引快取到 RAM 時回應速度變慢。如需詳細資訊，請參閱[故障診斷：使用 CloudWatch 指標](https://docs.aws.amazon.com/filegateway/latest/filefsxw/troubleshooting-file-gateway-issues.html#gateway-not-responding)。

## 檢查 Hypervisor 主機上是否有電源中斷或硬體故障
<a name="w2ab1c54c12c17"></a>

閘道 Hypervisor 主機上的電源中斷或硬體故障可能會導致閘道意外關閉且無法連線。還原電源和網路連線後，您的閘道將可再次連線。

閘道恢復上線後，請務必採取步驟來復原資料。如需詳細資訊，請參閱[最佳實務：復原資料](https://docs.aws.amazon.com/filegateway/latest/filefsxw/recover-data-from-gateway.html)。

## 檢查相關聯的快取磁碟是否有問題
<a name="w2ab1c54c12c19"></a>

如果至少有一個與閘道相關聯的快取磁碟遭到移除、變更或調整大小，或者已損毀，您的閘道可能會離線。

**如果從 Hypervisor 主機移除工作快取磁碟：**

1. 關機閘道。

1. 重新新增磁碟。
**注意**  
請務必將磁碟新增至相同的磁碟節點。

1. 重新啟動閘道。

**如果快取磁碟損毀、已取代或已調整大小：**
+ 遵循將[現有 S3 檔案閘道取代為新執行個體](https://docs.aws.amazon.com/filegateway/latest/files3/migrate-data.html#replace-instance-file-gateway)中所述**的方法 2** 程序，以設定新的閘道，並從雲端重新下載快取磁碟資訊 AWS 。

# 故障診斷：將閘道加入 Active Directory 時發生問題
<a name="troubleshooting-active-directory"></a>

使用下列疑難排解資訊，判斷當您嘗試將檔案閘道加入 Microsoft Active Directory 網域`ACCESS_DENIED`時，收到錯誤訊息時該怎麼做，例如 `TIMEOUT`、 `NETWORK_ERROR`或 。

若要解決這些錯誤，請執行下列檢查和組態。

## 透過執行 nping 測試，確認閘道可以到達網域控制站
<a name="w2ab1c54c15b7"></a>

**若要執行 nping 測試：**

1. 使用 Hypervisor 管理軟體 (VMware、Hyper-V 或 KVM) 連接內部部署閘道的閘道本機主控台，或使用 ssh 連接 Amazon EC2 閘道。

1. 輸入對應的數字以選取**閘道主控台**，然後輸入 `h`以列出所有可用的命令。若要測試 Storage Gateway 虛擬機器與網域之間的連線，請執行下列命令：

   `nping -d corp.domain.com -p 389 -c 1 -t tcp`
**注意**  
`corp.domain.com` 將 取代為您的 Active Directory 網域 DNS 名稱，並將 取代`389`為您環境的 LDAP 連接埠。  
確認您已在防火牆中開啟必要的連接埠。

以下是閘道能夠到達網域控制站的成功 nping 測試範例：

```
nping -d corp.domain.com -p 389 -c 1 -t tcp

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:24 UTC
SENT (0.0553s) TCP 10.10.10.21:9783 > 10.10.10.10:389 S ttl=64 id=730 iplen=40  seq=2597195024 win=1480 
RCVD (0.0556s) TCP 10.10.10.10:389 > 10.10.10.21:9783 SA ttl=128 id=22332 iplen=44  seq=4170716243 win=8192 <mss 8961>

Max rtt: 0.310ms | Min rtt: 0.310ms | Avg rtt: 0.310ms
Raw packets sent: 1 (40B) | Rcvd: 1 (44B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.09 seconds<br>
```

以下是 nping 測試的範例，其中目的地沒有連線或沒有回應`corp.domain.com`：

```
nping -d corp.domain.com -p 389 -c 1 -t tcp

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:26 UTC
SENT (0.0421s) TCP 10.10.10.21:47196 > 10.10.10.10:389  S ttl=64 id=30318 iplen=40 seq=1762671338 win=1480

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (40B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.07 seconds
```

## 檢查為 Amazon EC2 閘道執行個體的 VPC 設定的 DHCP 選項
<a name="w2ab1c54c15b9"></a>

如果檔案閘道是在 Amazon EC2 執行個體上執行，則您必須確保 DHCP 選項集已正確設定並連接到包含閘道執行個體的 Amazon Virtual Private Cloud (VPC)。如需詳細資訊，請參閱 [Amazon VPC 中的 DHCP 選項集](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)。

## 透過執行 dig 查詢，確認閘道可以解析網域
<a name="w2ab1c54c15c11"></a>

如果閘道無法解析網域，則閘道無法加入網域。

**若要執行 dig 查詢：**

1. 使用 Hypervisor 管理軟體 (VMware、Hyper-V 或 KVM) 連接內部部署閘道的閘道本機主控台，或使用 ssh 連接 Amazon EC2 閘道。

1. 輸入對應的數字以選取**閘道主控台**，然後輸入 `h`以列出所有可用的命令。若要測試閘道是否可以解析網域，請執行下列命令：

   `dig -d corp.domain.com`
**注意**  
`corp.domain.com` 將 取代為您的 Active Directory 網域 DNS 名稱。

以下是成功回應的範例：

```
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> corp.domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24817
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;corp.domain.com.        IN    A

;; ANSWER SECTION:
corp.domain.com.    600    IN    A    10.10.10.10
corp.domain.com.    600    IN    A    10.10.20.10
            
;; Query time: 0 msec
;; SERVER: 10.10.20.228#53(10.10.20.228)
;; WHEN: Thu Jun 30 16:36:32 UTC 2022
;; MSG SIZE  rcvd: 78
```

## 檢查網域控制站設定和角色
<a name="w2ab1c54c15c13"></a>

確認網域控制站未設定為唯讀，且網域控制站有足夠的角色供電腦加入。若要測試這一點，請嘗試將其他伺服器從與閘道 VM 相同的 VPC 子網路加入網域。

## 檢查閘道是否已加入最近的網域控制站
<a name="w2ab1c54c15c15"></a>

最佳實務是，建議您將閘道加入地理上靠近閘道設備的網域控制器。如果閘道設備因為網路延遲無法在 20 秒內與網域控制器通訊，則網域聯結程序可能會逾時。例如，如果閘道設備位於美國東部 （維吉尼亞北部）， AWS 區域 而網域控制站位於亞太區域 （新加坡），則程序可能會逾時。 AWS 區域

**注意**  
若要增加預設逾時值 20 秒，您可以在 AWS Command Line Interface (AWS CLI) 中執行 [join-domain 命令](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html)，並包含增加時間`--timeout-in-seconds`的選項。您也可以使用 [JoinDomain API 呼叫](https://amazonaws.com/storagegateway/latest/APIReference/API_JoinDomain.html)並包含 `TimeoutInSeconds` 參數來增加時間。逾時值上限為 3，600 秒。  
如果您在執行 AWS CLI 命令時收到錯誤，請確定您使用的是最新版本 AWS CLI 。

## 確認 Active Directory 在預設組織單位 (OU) 中建立新的電腦物件
<a name="w2ab1c54c15c17"></a>

請確定 Microsoft Active Directory 沒有任何群組政策物件，可在預設 OU 以外的任何位置建立新的電腦物件。您必須先在預設的 OU 中存在新的電腦物件，才能將閘道加入 Active Directory 網域。有些 Active Directory 環境會自訂為具有新建立物件的不同 OUs。若要保證閘道 VM 的新電腦物件存在於預設 OU 中，請先嘗試在網域控制器上手動建立電腦物件，再將閘道加入網域。您也可以使用 執行 [join-domain 命令](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html) AWS CLI。然後，指定 的選項`--organizational-unit`。

**注意**  
建立電腦物件的程序稱為預備。

## 檢查您的網域控制站事件日誌
<a name="w2ab1c54c15c19"></a>

如果您在嘗試前幾節所述的所有其他檢查和組態後，無法將閘道加入網域，建議您檢查網域控制站事件日誌。檢查網域控制站的事件檢視器中是否有任何錯誤。確認閘道查詢已到達網域控制站。

# 故障診斷：閘道啟用期間的內部錯誤
<a name="troubleshooting-gateway-activation"></a>

Storage Gateway 啟用請求會周遊兩個網路路徑。用戶端傳送的傳入啟用請求會透過連接埠 80 連線至閘道的虛擬機器 (VM) 或 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。如果閘道成功接收啟用請求，閘道會與 Storage Gateway 端點通訊，以接收啟用金鑰。如果閘道無法連線到 Storage Gateway 端點，閘道會以內部錯誤訊息回應用戶端。

使用以下疑難排解資訊，判斷在嘗試啟用 時，如果收到內部錯誤訊息該怎麼辦 AWS Storage Gateway。

**注意**  
請務必使用最新的虛擬機器映像檔案或 Amazon Machine Image (AMI) 版本部署新的閘道。如果您嘗試啟用使用過期 AMI 的閘道，將會收到內部錯誤。
下載 AMI 之前，請務必選取您要部署的正確閘道類型。每個閘道類型的 .ova 檔案和 AMIs 都不同，而且無法互換。

## 解決使用公有端點啟用閘道時的錯誤
<a name="w2ab1c54c18b9"></a>

若要解決使用公有端點啟用閘道時的啟用錯誤，請執行下列檢查和組態。

### 檢查所需的連接埠
<a name="w2ab1c54c18b9b5"></a>

對於內部部署的閘道，請檢查本機防火牆上的連接埠是否已開啟。對於部署在 Amazon EC2 執行個體上的閘道，請檢查連接埠是否在執行個體的安全群組上開啟。若要確認連接埠已開啟，請從伺服器對公有端點執行 telnet 命令。此伺服器必須與閘道位於相同的子網路中。例如，下列 telnet 命令會測試連接埠 443 的連線：

```
telnet d4kdq0yaxexbo.cloudfront.net 443
telnet storagegateway.region.amazonaws.com 443
telnet dp-1.storagegateway.region.amazonaws.com 443
telnet proxy-app.storagegateway.region.amazonaws.com 443
telnet client-cp.storagegateway.region.amazonaws.com 443
telnet anon-cp.storagegateway.region.amazonaws.com 443
```

若要確認閘道本身可以到達端點，請存取閘道的本機 VM 主控台 （適用於內部部署的閘道）。或者，您可以 SSH 到閘道的執行個體 （適用於部署在 Amazon EC2 上的閘道）。然後，執行網路連線測試。確認測試傳回 `[PASSED]`。如需詳細資訊，請參閱[測試閘道的網路連線](https://docs.aws.amazon.com/filegateway/latest/filefsxw/manage-on-premises-fgw.html#MaintenanceTestGatewayConnectivity-fgw)測試閘道對網際網路。

**注意**  
閘道主控台的預設登入使用者名稱為 `admin`，預設密碼為 `password`。

### 確保防火牆安全不會修改從閘道傳送至公有端點的封包
<a name="w2ab1c54c18b9b7"></a>

SSL 檢查、深度封包檢查或其他形式的防火牆安全可能會干擾從閘道傳送的封包。如果從啟用端點預期修改 SSL 憑證，則 SSL 交握會失敗。若要確認沒有進行中的 SSL 檢查，請在連接埠 443 的主要啟用端點 (`anon-cp.storagegateway.region.amazonaws.com`) 上執行 OpenSSL 命令。您必須從與閘道位於相同子網路的機器執行此命令：

```
$ openssl s_client -connect  anon-cp.storagegateway.region.amazonaws.com:443 -servername anon-cp.storagegateway.region.amazonaws.com
```

**注意**  
將*區域*取代為您的 AWS 區域。

如果沒有進行中的 SSL 檢查，則命令會傳回類似如下的回應：

```
$ openssl s_client -connect anon-cp.storagegateway.us-east-2.amazonaws.com:443 -servername anon-cp.storagegateway.us-east-2.amazonaws.com
CONNECTED(00000003)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-2.amazonaws.com
verify return:1
---
Certificate chain
 0 s:/CN=anon-cp.storagegateway.us-east-2.amazonaws.com
   i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
 1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
   i:/C=US/O=Amazon/CN=Amazon Root CA 1
 2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
 3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
   i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
---
```

如果有持續的 SSL 檢查，回應會顯示已變更的憑證鏈，如下所示：

```
$ openssl s_client -connect  anon-cp.storagegateway.ap-southeast-1.amazonaws.com:443 -servername anon-cp.storagegateway.ap-southeast-1.amazonaws.com
CONNECTED(00000003)
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.ap-southeast-1.amazonaws.com
   i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---
```

啟用端點只有在識別 SSL 憑證時，才會接受 SSL 交握。這表示閘道對端點的傳出流量必須免於由網路中的防火牆執行檢查。這些檢查可能是 SSL 檢查或深度封包檢查。

### 檢查閘道時間同步
<a name="w2ab1c54c18b9b9"></a>

時間過長可能會導致 SSL 交握錯誤。對於內部部署閘道，您可以使用閘道的本機 VM 主控台來檢查閘道的時間同步。時間扭曲不應大於 60 秒。如需詳細資訊，請參閱[ your Gateway VM TimeSynchronizing](https://docs.aws.amazon.com/filegateway/latest/filefsxw/MaintenanceTimeSync-hyperv.html)。

在 Amazon EC2 執行個體上託管的閘道上無法使用**系統時間管理**選項。為了確保 Amazon EC2 閘道可以正確同步時間，請確認 Amazon EC2 執行個體可以透過連接埠 UDP 和 TCP 123 連線至下列 NTP 伺服器集區清單：
+ time.aws.com
+ 0.amazon.pool.ntp.org
+ 1.amazon.pool.ntp.org
+ 2.amazon.pool.ntp.org
+ 3.amazon.pool.ntp.org

## 解決使用 Amazon VPC 端點啟用閘道時的錯誤
<a name="w2ab1c54c18c11"></a>

若要解決使用 Amazon Virtual Private Cloud (Amazon VPC) 端點啟用閘道時的啟用錯誤，請執行下列檢查和組態。

### 檢查所需的連接埠
<a name="w2ab1c54c18c11b5"></a>

確定本機防火牆 （適用於內部部署的閘道） 或安全群組 （適用於 Amazon EC2 中部署的閘道） 內的必要連接埠已開啟。將閘道連線至 Storage Gateway VPC 端點所需的連接埠，與將閘道連線至公有端點時所需的連接埠不同。連線至 Storage Gateway VPC 端點需要下列連接埠：
+ TCP 443
+ TCP 1026
+ TCP 1027
+ TCP 1028
+ TCP 1031
+ TCP 2222

如需詳細資訊，請參閱[建立 Storage Gateway 的 VPC 端點](https://docs.aws.amazon.com/filegateway/latest/filefsxw/gateway-private-link.html#create-vpc-endpoint)建立 Storage Gateway 的 VPC 端點。

此外，請檢查連接至 Storage Gateway VPC 端點的安全群組。連接至端點的預設安全群組可能不允許必要的連接埠。建立新的安全群組，允許來自閘道 IP 地址範圍的流量通過所需的連接埠。然後，將該安全群組連接到 VPC 端點。

**注意**  
使用 [Amazon VPC 主控台](https://console.aws.amazon.com//vpc/)來驗證連接到 VPC 端點的安全群組。從主控台檢視 Storage Gateway VPC 端點，然後選擇**安全群組**索引標籤。

若要確認所需的連接埠已開啟，您可以在 Storage Gateway VPC 端點上執行 telnet 命令。您必須從與閘道位於相同子網路的伺服器執行這些命令。您可以在未指定可用區域的第一個 DNS 名稱上執行測試。例如，下列 telnet 命令會使用 DNS 名稱 vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 測試所需的連接埠連線：

```
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 443
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1026
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1027
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1028
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1031
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 2222
```

### 確保防火牆安全不會修改從閘道傳送至 Storage Gateway Amazon VPC 端點的封包
<a name="w2ab1c54c18c11b7"></a>

SSL 檢查、深度封包檢查或其他形式的防火牆安全可能會干擾從閘道傳送的封包。如果從啟用端點預期修改 SSL 憑證，則 SSL 交握會失敗。若要確認沒有進行中的 SSL 檢查，請在 Storage Gateway VPC 端點上執行 OpenSSL 命令。您必須從與閘道位於相同子網路的機器執行此命令。為每個必要的連接埠執行 命令：

```
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:443 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1026 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1028 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1031 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com

$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:2222 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
```

如果沒有進行中的 SSL 檢查，則命令會傳回類似如下的回應：

```
openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify return:1
---
Certificate chain
 0 s:CN = anon-cp.storagegateway.us-east-1.amazonaws.com
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
---
```

如果有持續的 SSL 檢查，回應會顯示已變更的憑證鏈，如下所示：

```
openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.us-east-1.amazonaws.com
   i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---
```

啟用端點只有在識別 SSL 憑證時，才會接受 SSL 交握。這表示閘道透過所需連接埠傳出至 VPC 端點的流量不受網路防火牆執行的檢查影響。這些檢查可能是 SSL 檢查或深度封包檢查。

### 檢查閘道時間同步
<a name="w2ab1c54c18c11b9"></a>

時間過長可能會導致 SSL 交握錯誤。對於內部部署閘道，您可以使用閘道的本機 VM 主控台來檢查閘道的時間同步。時間扭曲不應大於 60 秒。如需詳細資訊，請參閱[ your Gateway VM TimeSynchronizing](https://docs.aws.amazon.com/filegateway/latest/filefsxw/MaintenanceTimeSync-hyperv.html)。

**系統時間管理**選項不適用於在 Amazon EC2 執行個體上託管的閘道。為了確保 Amazon EC2 閘道可以正確同步時間，請確認 Amazon EC2 執行個體可以透過連接埠 UDP 和 TCP 123 連線至下列 NTP 伺服器集區清單：
+ 0.amazon.pool.ntp.org
+ 1.amazon.pool.ntp.org
+ 2.amazon.pool.ntp.org
+ 3.amazon.pool.ntp.org

### 檢查 HTTP 代理並確認相關聯的安全群組設定
<a name="w2ab1c54c18c11c11"></a>

啟用之前，請檢查 Amazon EC2 上的 HTTP 代理是否已在內部部署閘道 VM 上設定為連接埠 3128 上的 Squid 代理。在此情況下，請確認下列事項：
+ 連接至 Amazon EC2 上 HTTP 代理的安全群組必須具有傳入規則。此傳入規則必須允許來自閘道 VM IP 地址的連接埠 3128 上的 Squid 代理流量。
+ 連接至 Amazon EC2 VPC 端點的安全群組必須具有傳入規則。這些傳入規則必須允許連接埠 1026-1028、1031、2222 和 443 上來自 Amazon EC2 上 HTTP 代理的 IP 地址的流量。

## 解決使用公有端點啟用閘道，且相同 VPC 中有 Storage Gateway VPC 端點時的錯誤
<a name="w2ab1c54c18c13"></a>

若要解決在相同 VPC 中發現 Amazon Virtual Private Cloud (Amazon VPC) 時，使用公有端點啟用閘道時的錯誤，請執行下列檢查和組態。

### 確認 Storage Gateway VPC 端點上未啟用**啟用私有 DNS 名稱**設定
<a name="w2ab1c54c18c13b5"></a>

如果啟用**私有 DNS 名稱**已啟用，您就無法啟用從該 VPC 到公有端點的任何閘道。

**若要停用私有 DNS 名稱選項：**

1. 開啟 [Amazon VPC 主控台](https://console.aws.amazon.com//vpc/)。

1. 在導覽窗格中選擇**端點**。

1. 選擇 Storage Gateway VPC 端點。

1. 選擇**動作**。

1. 選擇**管理私有 DNS 名稱**。

1. 針對**啟用私有 DNS 名稱**，清除**此端點的啟用**。

1. 選擇**修改私有 DNS 名稱**以儲存設定。

# 故障診斷：內部部署閘道問題
<a name="troubleshooting-on-premises-gateway-issues"></a>

您可以在下面找到有關使用內部部署閘道時可能遇到的典型問題的資訊，以及如何允許 支援 連接到您的閘道以協助故障診斷。

下表列出使用內部部署閘道時一般可能遇到的問題。


| 問題 | 採取動作 | 
| --- | --- | 
| 您找不到閘道的 IP 地址。  |  使用虛擬化管理程序用戶端連線到您的主機，尋找閘道 IP 地址。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) 如果仍找不到閘道 IP 地址： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html)  | 
| 您有網路或防火牆的問題。  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html)  | 
|  當您在 Storage Gateway 管理主控台中按一下**繼續啟用**按鈕時，您的閘道啟用會失敗。  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html)  | 
|  您需要改善閘道與 AWS之間的頻寬。  |  您可以透過在網路轉接器 (NIC) AWS 上設定 的網際網路連線，與連接應用程式和閘道 VM 的連線分開， AWS 來改善從閘道到 的頻寬。如果您與 有高頻寬連線， AWS 而且想要避免頻寬爭用，尤其是在快照還原期間，採取此方法非常有用。對於高輸送量工作負載的需求，您可以使用 [Direct Connect](https://aws.amazon.com/directconnect/) 在內部部署閘道和 AWS之間建立專用網路連線。若要測量閘道連線的頻寬 AWS，請使用閘道的 `CloudBytesDownloaded`和 `CloudBytesUploaded`指標。如需此主題的詳細資訊，請參閱[效能和最佳化](Performance.md)。提升網際網路連線能力有助於確保您的上傳緩衝區不會用盡。  | 
|  閘道的出入輸送量降到零。  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) 您可以從 Amazon CloudWatch 主控台檢視在您閘道出入的輸送量。如需測量閘道與 之間傳輸量的詳細資訊 AWS，請參閱 [效能和最佳化](Performance.md)。  | 
|  您無法在 Microsoft Hyper-V 匯入 (部署) Storage Gateway。  |  請參閱 [故障診斷：Microsoft Hyper-V 設定](troubleshooting-hyperv-setup.md)，以了解在 Microsoft Hyper-V 部署閘道的常見問題。  | 
|  您會收到以下訊息：「The data that has been written to the volume in your gateway isn't securely stored at AWS」。  |  如果您的閘道 VM 是從另一個閘道 VM 的複製或快照所建立，就會收到此訊息。如果不是這種情況，請聯絡 支援。  | 

## 開啟 支援 存取權，以協助對內部部署託管的閘道進行故障診斷
<a name="enable-support-access-on-premises"></a>

Storage Gateway 提供本機主控台，您可以用來執行數個維護任務，包括允許 支援 存取您的閘道，以協助您疑難排解閘道問題。根據預設，對閘道的 支援 存取會關閉。您可以透過主機的本機主控台開啟此存取權。若要提供閘道的 支援 存取權，請先登入主機的本機主控台，導覽至 Storage Gateway 的主控台，然後連線至支援伺服器。

**開啟對閘道的 支援 存取**

1. 登入您主機的本機主控台。
   + VMware ESXi：如需詳細資訊，請參閱 [使用 VMware ESXi 存取閘道本機主控台](accessing-local-console.md#MaintenanceConsoleWindowVMware-common)。
   + Microsoft Hyper-V：如需詳細資訊，請參閱 [使用 Microsoft Hyper-V 存取閘道本機主控台](accessing-local-console.md#MaintenanceConsoleWindowHyperV-common)。

1. 出現提示時，輸入對應的數字以選取**閘道組態**。

1. 輸入 **h** 以開啟可用命令視窗。

1. 

   執行以下任意一項：
   + 如果您的閘道使用公有端點，請在**可用命令**視窗中輸入 **open-support-channel** 來連線到 Storage Gateway 的客戶支援。允許 TCP 連接埠 22，即可開啟 AWS的支援管道。當您連線到客戶支援時，Storage Gateway 會指派一個支援號碼給您。請記下您的支援號碼。
   + 如果您的閘道使用 VPC 端點，請在**可用命令**視窗中輸入 **open-support-channel**。如果您的閘道未啟用，請提供 VPC 端點或 IP 地址以連線到 Storage Gateway 的客戶支援。允許 TCP 連接埠 22，即可開啟 AWS的支援管道。當您連線到客戶支援時，Storage Gateway 會指派一個支援號碼給您。請記下您的支援號碼。
**注意**  
此管道號碼不是傳輸控制通訊協定/使用者資料包通訊協定 (TCP/UDP) 連接埠號碼。反之，閘道以 Secure Shell (SSH) (TCP 22) 連線到 Storage Gateway 伺服器，並提供此連線的支援管道。

1. 建立支援管道之後，請將支援服務號碼提供給 ， 支援 以便 支援 可以提供故障診斷協助。

1. 當支援工作階段完成時，請輸入 **q** 將其結束。在 Amazon Web Services Support 通知您支援工作階段完成之前，請勿關閉工作階段。

1. 輸入 **exit** 以登出 Storage Gateway 主控台。

1. 依照提示結束本機主控台。

# 故障診斷：Microsoft Hyper-V 設定
<a name="troubleshooting-hyperv-setup"></a>

在 Microsoft Hyper-V 平台上部署 Storage Gateway 時通常可能會遇到的問題如下表所列。


| 問題 | 採取動作 | 
| --- | --- | 
| 您嘗試匯入閘道並收到下列錯誤訊息： 「嘗試匯入虛擬機器時發生伺服器錯誤。匯入失敗。在位置 【...】 下找不到虛擬機器匯入檔案。只有在使用 Hyper-V 建立和匯出虛擬機器時，才能匯入虛擬機器。」  |  此錯誤的發生原因如下： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/filefsxw/troubleshooting-hyperv-setup.html)  | 
|  您嘗試匯入閘道並收到下列錯誤訊息： 「嘗試匯入虛擬機器時發生伺服器錯誤。匯入失敗。匯入任務無法從 【...】 複製檔案：檔案存在。(0x80070050)"  |  如已部署閘道，而您嘗試重複使用存放虛擬硬碟檔案和虛擬機器組態檔案的預設資料夾，則會發生此錯誤。若要修正此問題，請在 **Hyper-V 設定**對話方塊左側面板的**伺服器**下指定新位置。  | 
|  您嘗試匯入閘道並收到下列錯誤訊息： 「嘗試匯入虛擬機器時發生伺服器錯誤。匯入失敗。Import failed because the virtual machine must have a new identifier. Select a new identifier and try the import again."。  |  當您匯入閘道時，請務必選取**複製虛擬機器**，並勾選**匯入虛擬機器**對話方塊中的**複製所有檔案**方塊，為虛擬機器建立新的唯一 ID。  | 
|  您嘗試啟動閘道 VM 並收到下列錯誤訊息： 「嘗試啟動選取的虛擬機器 （多個） 時發生錯誤。子分割區處理器設定與父分割區不相容。'AWS-Storage-Gateway' 無法初始化。（虛擬機器 ID 【...】)  | 此錯誤可能是因為閘道所需 CPU 和主機可用 CPU 之間的 CPU 差異所造成。請確定基礎虛擬化管理程序支援 VM CPU 計數。 如需關於 Storage Gateway 需求的詳細資訊，請參閱 [檔案閘道設定需求](Requirements.md)。 | 
|  您嘗試啟動閘道 VM 並收到下列錯誤訊息： 「嘗試啟動選取的虛擬機器 （多個） 時發生錯誤。'AWS-Storage-Gateway' 無法初始化。（虛擬機器 ID 【...】) 無法建立分割區：系統資源不足，無法完成請求的服務。(0x800705AA)"  |  此錯誤可能是因為閘道所需 RAM 和主機可用 RAM 之間的 RAM 差異所造成。 如需關於 Storage Gateway 需求的詳細資訊，請參閱 [檔案閘道設定需求](Requirements.md)。  | 
|  您的快照和閘道軟體更新出現的次數會和預期的稍有不同。  |  閘道 VM 的時鐘可能會從實際的時間偏移，稱為時鐘飄移。請使用本機閘道主控台的時間同步選項，檢查並更正 VM 的時間。如需詳細資訊，請參閱[為您的閘道設定網路時間通訊協定 (NTP) 伺服器](MaintenanceTimeSync-fgw.md)。  | 
|  您需要將解壓縮的 Microsoft Hyper-V Storage Gateway 檔案放在主機的檔案系統。  |  像您對一般 Microsoft Windows 伺服器所做的一樣，存取主機。例如，如果虛擬化管理程序主機名為 `hyperv-server`，則您可使用以下 UNC 路徑 `\\hyperv-server\c$`，其假設 `hyperv-server` 名稱可在本機主機檔案中解析或定義。  | 
|  連線到虛擬化管理程序時，系統會提示您提供登入資料。  |  使用 Sconfig.cmd 工具新增您的使用者登入資料，做為虛擬化管理程序主機的本機管理員。  | 
|  如果您為使用 Broadcom 網路轉接器的 Hyper-V 主機開啟虛擬機器佇列 (VMQ)，您可能會注意到網路效能不佳。  |  如需解決方法的資訊，請參閱 Microsoft 文件，請參閱[開啟 VMQ 時 Windows Server 2012 Hyper-V 主機上虛擬機器的網路效能不佳](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/poor-network-performance-hyper-v-host-vm)。  | 

# 故障診斷：Amazon EC2 閘道問題
<a name="troubleshooting-EC2-gateway-issues"></a>

在下列各節中，您會發現使用部署在 Amazon EC2 的閘道時，一般可能遇到的問題。如需內部部署閘道和部署在 Amazon EC2 閘道兩者間之差異的詳細資訊，請參閱 [部署 FSx 檔案閘道的預設 Amazon EC2 主機部署 FSx 檔案閘道的自訂 Amazon EC2 主機](ec2-gateway-file.md)。

**Topics**
+ [您的閘道在一段時間後仍未啟用](#activation-issues)
+ [執行個體清單中找不到您的 EC2 閘道執行個體](#find-instance)
+ [使用 Amazon EC2 序列主控台連接到您的閘道執行個體](#ec2-serial-console)
+ [支援 您想要協助疑難排解 Amazon EC2 閘道](#EC2-EnableAWSSupportAccess)

## 您的閘道在一段時間後仍未啟用
<a name="activation-issues"></a>

在 Amazon EC2 主控台中，檢查以下項目：
+ 連接埠 80 會在您與該執行個體相關聯的安全群組中開啟。如需新增安全群組規則的詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[新增安全群組規則](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#adding-security-group-rule)。
+ 閘道執行個體標示為執行中。在 Amazon EC2 主控台中，執行個體的**狀態**值應為執行中。
+ 請確保您的 Amazon EC2 執行個體類型符合最低要求，如 [儲存需求](Requirements.md#requirements-storage) 所述。

更正問題後，請嘗試再次啟動閘道。若要執行此操作，請開啟 Storage Gateway 主控台，選擇**在 Amazon EC2 上部署新的閘道**，然後重新輸入執行個體的 IP 地址。

## 執行個體清單中找不到您的 EC2 閘道執行個體
<a name="find-instance"></a>

如果您並未建立執行個體的資源標籤，又有許多執行個體正在執行，要分辨您啟動了哪些執行個體會十分困難。在這種情況下，您可以執行以下動作，尋找閘道執行個體：
+ 在執行個體的**描述**標籤上檢查 Amazon Machine Image (AMI) 的名稱。以 Storage Gateway AMI 為基礎的執行個體的開頭文字應為 **aws-storage-gateway-ami**。
+ 如果您有數個以 Storage Gateway AMI 為基礎的執行個體，請檢查執行個體的啟動時間，以尋找正確的執行個體。

## 使用 Amazon EC2 序列主控台連接到您的閘道執行個體
<a name="ec2-serial-console"></a>

您可以使用 Amazon EC2 序列主控台來疑難排解開機、網路設定和其他問題。如需指示和疑難排解秘訣，請參閱*《Amazon 彈性運算雲端使用者指南》*中的 [Amazon EC2 序列主控台](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html)。

## 支援 您想要協助疑難排解 Amazon EC2 閘道
<a name="EC2-EnableAWSSupportAccess"></a>

Storage Gateway 提供本機主控台，您可以用來執行數個維護任務，包括允許 支援 存取您的閘道，以協助您疑難排解閘道問題。根據預設，對閘道的 支援 存取會關閉。您可以透過 Amazon EC2 本機主控台開啟此存取權。您可以透過 Secure Shell (SSH) 登入 Amazon EC2 本機主控台。若要透過 SSH 成功登入，您執行個體的安全群組必須有開啟 TCP 連接埠 22 的規則。

**注意**  
如果您將新的規則新增至現有的安全群組，新的規則將套用到使用該安全群組的所有執行個體。如需安全群組以及如何新增安全群組規則的詳細資訊，請參閱《Amazon EC2 使用者指南》**中的 [Amazon EC2 安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)。

若要讓 支援 連線至您的閘道，請先登入 Amazon EC2 執行個體的本機主控台，導覽至 Storage Gateway 的主控台，然後提供存取權。

**開啟在 Amazon EC2 執行個體上部署之閘道的 支援 存取權**

1. 登入 Amazon EC2 執行個體的本機主控台。如需說明，請參閱《Amazon EC2 使用者指南》**中的[連線到您的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)。

   您可以使用以下命令登入 EC2 執行個體的本機主控台。

   ```
   ssh –i PRIVATE-KEY admin@INSTANCE-PUBLIC-DNS-NAME
   ```
**注意**  
*PRIVATE-KEY* 是 `.pem` 檔案，其中包含 EC2 金鑰對的私有憑證，您可用來啟動 Amazon EC2 執行個體。如需詳細資訊，請參閱《Amazon EC2 使用者指南》**中的[擷取金鑰對的公有金鑰](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#retriving-the-public-key)。  
*INSTANCE-PUBLIC-DNS-NAME* 是用於執行閘道之 Amazon EC2 執行個體的公有網域名稱系統 (DNS) 名稱。您可以在 EC2 主控台中選取 Amazon EC2 執行個體，然後按一下**描述**標籤以取得此公有 DNS 名稱。

1. 出現提示時，輸入 **6 - Command Prompt** 以開啟 支援 管道主控台。

1. 輸入 **h** 以開啟**可用命令**視窗。

1. 執行以下任意一項：
   + 如果您的閘道使用公有端點，請在**可用命令**視窗中輸入 **open-support-channel** 來連線到 Storage Gateway 的客戶支援。允許 TCP 連接埠 22，即可開啟 AWS的支援管道。當您連線到客戶支援時，Storage Gateway 會指派一個支援號碼給您。請記下您的支援號碼。
   + 如果您的閘道使用 VPC 端點，請在**可用命令**視窗中輸入 **open-support-channel**。如果您的閘道未啟用，請提供 VPC 端點或 IP 地址以連線到 Storage Gateway 的客戶支援。允許 TCP 連接埠 22，即可開啟 AWS的支援管道。當您連線到客戶支援時，Storage Gateway 會指派一個支援號碼給您。請記下您的支援號碼。
**注意**  
此管道號碼不是傳輸控制通訊協定/使用者資料包通訊協定 (TCP/UDP) 連接埠號碼。反之，閘道以 Secure Shell (SSH) (TCP 22) 連線到 Storage Gateway 伺服器，並提供此連線的支援管道。

1. 建立支援管道之後，請將支援服務號碼提供給 ， 支援 以便 支援 可以提供故障診斷協助。

1. 當支援工作階段完成時，請輸入 **q** 將其結束。在 Amazon Web Services Support 通知您支援工作階段完成之前，請勿關閉工作階段。

1. 輸入 **exit** 以結束 Storage Gateway 主控台。

1. 依照主控台選單操作登出 Storage Gateway 執行個體。

# 故障診斷：硬體設備問題
<a name="troubleshooting-hardware-appliance-issues"></a>

**注意**  
可用性終止通知：自 2025 年 5 月 12 日起，將不再提供 AWS Storage Gateway 硬體設備。硬體 AWS Storage Gateway 設備的現有客戶可以繼續使用和獲得支援，直到 2028 年 5 月為止。或者，您可以使用 AWS Storage Gateway 服務為應用程式提供現場部署和雲端存取幾乎無限制的雲端儲存。

下列主題討論您使用 AWS Storage Gateway硬體設備時可能遇到的問題，以及疑難排解這些問題的建議。

**Topics**
+ [您無法確定服務 IP 地址](#service_ip_address)
+ [如何執行重設成出廠預設值？](#factory_reset)
+ [如何執行遠端重新啟動？](#remote-restart)
+ [哪裡可以取得 Dell iDRAC 支援？](#iDRAC_support)
+ [您找不到硬體設備序號](#appliance_serial_number)
+ [在何處取得硬體設備支援](#appliance_support)

## 您無法確定服務 IP 地址
<a name="service_ip_address"></a>

嘗試連接到服務時，請務必使用服務的 IP 地址，而非主機 IP 地址。在服務主控台中設定服務 IP 地址，並在硬體主控台設定主機 IP 地址。當您啟動硬體設備時會看到硬體主控台。若要從硬體主控台前往服務主控台，請選擇 **Open Service Console (開啟服務主控台)**。

## 如何執行重設成出廠預設值？
<a name="factory_reset"></a>

如果您需要在設備上執行原廠重設，請聯絡 AWS Storage Gateway硬體設備團隊以取得支援，如以下支援一節所述。

## 如何執行遠端重新啟動？
<a name="remote-restart"></a>

如果您需要執行裝置的遠端重新啟動，可以使用 Dell iDRAC 管理介面來執行此作業。如需詳細資訊，請參閱 Dell Technologies InfoHub 網站上的 [iDRAC9 虛擬電源重啟：遠端重啟 Dell EMC PowerEdge 伺服器電源](https://infohub.delltechnologies.com/en-us/p/idrac9-virtual-power-cycle-remotely-power-cycle-dell-emc-poweredge-servers/)。

## 哪裡可以取得 Dell iDRAC 支援？
<a name="iDRAC_support"></a>

Dell PowerEdge 伺服器隨附 Dell iDRAC 管理介面。我們建議下列作法：
+ 如果您使用 iDRAC 管理介面，則應變更預設密碼。如需關於 iDRAC 認證的詳細資訊，請參閱 [Dell PowerEdge - 什麼是 iDRAC 的預設登入憑證？](https://www.dell.com/support/article/en-us/sln306783/dell-poweredge-what-is-the-default-username-and-password-for-idrac?lang=en)
+ 請確定韌體是最新狀態，以防止安全漏洞。
+ 將 iDRAC 網路界面移到一般 (`em`) 連接埠，可能導致效能問題或阻止裝置正常運作。

## 您找不到硬體設備序號
<a name="appliance_serial_number"></a>

您可以使用 AWS Storage Gateway 主控台找到Storage Gateway閘道硬體設備的序號。

**若要尋找硬體設備序號：**

1. 前往 [https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/) 開啟 Storage Gateway 主控台。

1. 在頁面左側的導覽窗格選擇**硬體**。

1. 從清單中選擇您的硬體設備。

1. 在設備**的詳細資訊**索引標籤上尋找**序號**欄位。

## 在何處取得硬體設備支援
<a name="appliance_support"></a>

若要聯絡 AWS 以取得硬體設備的技術支援，請參閱 [支援](https://aws.amazon.com/contact-us)。

 支援 團隊可能會要求您啟用支援管道，以遠端疑難排解您的閘道問題。不需要將此連接埠開放給閘道的正常操作使用，但進行疑難排解時需要用到。您可以從硬體主控台啟用支援管道，如以下程序所示。

**開啟 的支援管道 AWS**

1. 開啟硬體主控台。

1. 選擇硬體主控台主頁面底部的**開啟支援管道**，然後按 `Enter`。

   如果沒有網路連線或防火牆問題，指派的連接埠號碼應該會在 30 秒內顯示。例如：

   **狀態：在連接埠 19599 上開啟**

1. 請記下連接埠號碼並將其提供給 支援。

# 故障診斷：檔案閘道問題
<a name="troubleshooting-file-gateway-issues"></a>

您可以設定檔案閘道，將日誌項目寫入 Amazon CloudWatch 日誌群組。如果您這樣做，您會收到有關閘道運作狀態和閘道遇到之任何錯誤的通知。您可以在 CloudWatch Logs 中找到這些錯誤和運作狀態通知的相關資訊。

在下列各節，您可以找到相關資訊，協助您了解每個錯誤的原因、運作狀態通知，以及修正問題的方法。

**Topics**
+ [錯誤：FileMissing](#troubleshoot-logging-errors-filemissing)
+ [錯誤：FsxFileSystemAuthenticationFailure](#troubleshoot-logging-errors-fsxfilesystemauthenticationfailure)
+ [錯誤：FsxFileSystemConnectionFailure](#troubleshoot-logging-errors-fsxfilesystemconnectionfailure)
+ [錯誤：FsxFileSystemFull](#troubleshoot-logging-errors-fsxfilesystemfull)
+ [錯誤：GatewayClockOutOfSync](#troubleshoot-logging-errors-gatewayclockoutofsync)
+ [錯誤：InvalidFileState](#troubleshoot-logging-errors-invalidfilestate)
+ [錯誤：ObjectMissing](#troubleshoot-logging-errors-objectmissing)
+ [錯誤：DroppedNotifications](#troubleshoot-logging-errors-droppednotifications)
+ [通知：HardReboot](#troubleshoot-hardreboot-notification)
+ [通知：重新啟動](#troubleshoot-reboot-notification)
+ [故障診斷：Active Directory 網域問題](#troubleshooting-ad-domain)
+ [故障診斷：使用 CloudWatch 指標](#troubleshooting-with-cw-metrics)

## 錯誤：FileMissing
<a name="troubleshoot-logging-errors-filemissing"></a>

`FileMissing` 錯誤類似於`ObjectMissing`錯誤，解決錯誤的步驟相同。當指定檔案閘道以外的寫入器從 Amazon FSx 刪除指定的檔案時，您可能會收到`FileMissing`錯誤。任何後續上傳至 Amazon FSx 或從 Amazon FSx 擷取物件失敗。

**解決 FileMissing 錯誤**

1. 將檔案的最新副本儲存至 SMB 用戶端的本機檔案系統 （您需要在步驟 3 中使用此檔案副本）。

1. 使用 SMB 用戶端從檔案閘道刪除檔案。

1. 使用 SMB 用戶端複製您在步驟 1 Amazon FSx 中儲存的最新版本檔案。透過您的檔案閘道執行此操作。

## 錯誤：FsxFileSystemAuthenticationFailure
<a name="troubleshoot-logging-errors-fsxfilesystemauthenticationfailure"></a>

當附加檔案系統時提供的登入資料過期，或其權限已撤銷時，您可能會收到`FsxFileSystemAuthenticationFailure`錯誤。

**解決 FsxFileSystemAuthenticationFailure 錯誤**

1. 確定連接 Amazon FSx 檔案系統時提供的登入資料仍然有效。

1. 確定使用者擁有所有必要的許可，如[連接 Amazon FSx for Windows File Server 檔案系統](https://docs.aws.amazon.com/filegateway/latest/filefsxw/attach-fsxw-filesystem.html)所述。

## 錯誤：FsxFileSystemConnectionFailure
<a name="troubleshoot-logging-errors-fsxfilesystemconnectionfailure"></a>

當無法從閘道機器存取 Amazon FSx 伺服器時，您可能會收到`FsxFileSystemConnectionFailure`錯誤。

**解決 FsxFileSystemConnectionFailure 錯誤**

1. 確保所有防火牆和 VPC 規則允許閘道機器和 Amazon FSx 伺服器之間的連線。

1. 確定 Amazon FSx 伺服器正在執行。

## 錯誤：FsxFileSystemFull
<a name="troubleshoot-logging-errors-fsxfilesystemfull"></a>

當 Amazon FSx 檔案系統中沒有足夠的可用磁碟空間時，您可能會收到`FsxFileSystemFull`錯誤。

**解決 FsxFileSystemFull 錯誤**
+ 增加 Amazon FSx 檔案系統的儲存空間。

## 錯誤：GatewayClockOutOfSync
<a name="troubleshoot-logging-errors-gatewayclockoutofsync"></a>

當閘道偵測到本機系統時間和 AWS Storage Gateway伺服器報告的時間之間有 5 分鐘或更多的差異時，您可能會收到`GatewayClockOutOfSync`錯誤。時鐘同步問題可能會對閘道與 之間的連線產生負面影響 AWS。如果閘道時鐘不同步，NFS 和 SMB 連線可能會發生 I/O 錯誤，而 SMB 使用者可能會發生身分驗證錯誤。

**解決 GatewayClockOutOfSync 錯誤**
+ 檢查閘道和 NTP 伺服器之間的網路組態。如需同步閘道 VM 時間和更新 NTP 伺服器組態的詳細資訊，請參閱[為您的閘道設定網路時間協定 (NTP) 伺服器](https://docs.aws.amazon.com/filegateway/latest/filefsxw/manage-on-premises-fgw.html#MaintenanceTimeSync-fgw)。

## 錯誤：InvalidFileState
<a name="troubleshoot-logging-errors-invalidfilestate"></a>

當指定閘道以外的寫入器修改指定檔案共享中的指定檔案時，您可能會收到`InvalidFileState`錯誤。因此，閘道上的檔案狀態與 Amazon FSx 中的檔案狀態不相符。後續從 Amazon FSx 上傳或擷取檔案可能會失敗。

**解決 InvalidFileState 錯誤**

1. 將檔案的最新副本儲存至 SMB 用戶端的本機檔案系統 （您需要此檔案才能在步驟 4 中複製）。如果 Amazon FSx 中的 檔案版本是最新版本，請下載該版本。您可以使用任何 SMB 用戶端直接存取 Amazon FSx 共用來執行此操作。

1. 直接刪除 Amazon FSx 中的檔案。

1. 使用 SMB 用戶端從閘道刪除檔案。

1. 使用您的 SMB 用戶端，*透過檔案閘道*將您在步驟 1 中儲存的最新版本檔案複製到 Amazon FSx。

## 錯誤：ObjectMissing
<a name="troubleshoot-logging-errors-objectmissing"></a>

當指定檔案閘道以外的寫入器從 Amazon FSx 刪除指定的檔案時，您可能會收到`ObjectMissing`錯誤。任何後續上傳至 Amazon FSx 或從 Amazon FSx 擷取物件都會失敗。

**解決 ObjectMissing 錯誤**

1. 將檔案的最新副本儲存至 SMB 用戶端的本機檔案系統 （您需要在步驟 3 中使用此檔案副本）。

1. 使用 SMB 用戶端從檔案閘道刪除檔案。

1. 使用 SMB 用戶端複製您在步驟 1 Amazon FSx 中儲存的最新版本檔案。透過您的檔案閘道執行此操作。

## 錯誤：DroppedNotifications
<a name="troubleshoot-logging-errors-droppednotifications"></a>

當閘道根磁碟上的可用儲存空間小於 1 GB，或在 1 分鐘內產生超過 100 個運作狀態通知時，您可能會看到`DroppedNotifications`錯誤，而不是其他預期的 CloudWatch 日誌項目類型。在這些情況下，閘道會停止產生詳細的 CloudWatch 日誌通知做為預防措施。

**解決 DroppedNotifications 錯誤**

1. 在 Storage Gateway `Root Disk Usage` 主控台中檢查閘道**監控**索引標籤上的指標，以判斷可用的根磁碟空間是否不足。

1. 如果可用空間小於 1 GB，請增加閘道根儲存磁碟的大小。如需說明，請參閱虛擬機器 Hypervisor 的文件。

   若要增加 Amazon EC2 閘道的根磁碟大小，請參閱《*Amazon Elastic Compute Cloud 使用者指南*》中的[請求修改 EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html)。
**注意**  
無法增加 AWS Storage Gateway 硬體設備的根磁碟大小。

1. 重新啟動您的閘道。

## 通知：HardReboot
<a name="troubleshoot-hardreboot-notification"></a>

當閘道 VM 意外重新啟動時，您可能會收到 `HardReboot` 通知。這種重新啟動可能是因為電源中斷、硬體故障或其他事件。對於 VMware 閘道，vSphere 高可用性應用程式監控重設可能會導致此事件。

當閘道在這種環境中執行時，請檢查 `HealthCheckFailure` 通知是否存在，並參閱 VM 的 VMware 事件記錄。

## 通知：重新啟動
<a name="troubleshoot-reboot-notification"></a>

當閘道 VM 重新啟動時，您可能會收到重新啟動通知。您可以使用 VM Hypervisor Management 主控台或 Storage Gateway 主控台來重新啟動閘道 VM。您也可以在閘道維護週期期間使用閘道軟體來重新啟動。

如果重新啟動的時間在閘道所設定之[維護開始時間](MaintenanceManagingUpdate-common.md)的 10 分鐘以內，此重新啟動可能是正常的情況，而不是任何問題的徵兆。如果重新啟動很常在維護時段外發生，請檢查閘道是否已手動重新啟動。

## 故障診斷：Active Directory 網域問題
<a name="troubleshooting-ad-domain"></a>

FSx File Gateway 不會為 Active Directory 網域問題產生特定日誌訊息。如果您在將閘道加入 Active Directory 網域時遇到問題，請執行下列動作：
+ 確認閘道並未嘗試使用唯讀網域控制站 (RODC) 加入網域。
+ 確認閘道已設定為使用正確的 DNS 伺服器。

  例如，如果您嘗試將 Amazon EC2 閘道執行個體加入 AWS受管 Active Directory，請確認 EC2 VPC 的 DHCP 選項集指定受 AWS管 Active Directory DNS 伺服器。

  您透過 VPC DHCP 選項集設定的 DNS 伺服器會提供給 VPC 中的所有 EC2 執行個體。如果您想要為個別閘道指定 DNS 伺服器，您可以使用該閘道的 EC2 本機主控台來執行此作業。

  對於內部部署閘道，您可以使用 VM 本機主控台指定 DNS 伺服器。
+ 從閘道本機主控台的命令提示字元執行下列命令，以確認閘道網路連線。將反白顯示的變數取代為部署中的實際網域名稱和 IP 地址。

  ```
  dig -d ExampleDomainName
  ncport -d ExampleDomainControllerIPAddress -p 445
  ncport -d ExampleDomainControllerIPAddress -p 389
  ```
+ 確認您的 Active Directory 服務帳戶具有必要的許可。如需詳細資訊，請參閱 [Active Directory 服務帳戶許可要求](https://docs.aws.amazon.com/filegateway/latest/filefsxw/ad-serviceaccount-permissions.html)。
+ 驗證閘道是否聯結正確的組織單位 (OU)。

  加入網域會使用閘道的**閘道 ID** 做為帳戶名稱 （例如，SGW-1234ADE)，在預設的電腦容器 （非 OU) 中建立 Active Directory 電腦帳戶。您無法自訂此帳戶的名稱。

  如果您的 Active Directory 環境具有新電腦物件的指定 OU，您必須在加入網域時指定該 OU。

  如果您在嘗試加入指定的 OU 時遇到存取遭拒錯誤，請洽詢 Active Directory 網域管理員。管理員可能需要預先設定閘道的電腦帳戶，才能加入網域。如需詳細資訊，請參閱[如何疑難排解將 Storage Gateway 檔案閘道加入網域以進行 Microsoft Active Directory 身分驗證的問題？](https://aws.amazon.com/premiumsupport/knowledge-center/storage-gateway-domain-join-error/)。
+ 從閘道本機主控台的命令提示字元執行下列命令，確認閘道的主機名稱可在 DNS 中解析。將反白顯示的變數取代為閘道的實際主機名稱。

  ```
  dig -d ExampleHostName -r A
  ```

  如果您已為閘道設定自訂主機名稱，則必須手動新增指向其 IP 地址的 DNS A 記錄。
+ 確認閘道與網域控制器之間的網路延遲相當低。如果閘道未在 20 秒內收到來自網域控制器的回應，加入網域的查詢可能會逾時。

  如果您使用 [JoinDomain](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_JoinDomain.html) CLI 命令將閘道加入網域，您可以新增 `--timeout-in-seconds`旗標，將逾時增加到最多 3，600 秒。
+ 確認您用來將閘道加入網域的 Active Directory 使用者具有執行此作業所需的權限。

## 故障診斷：使用 CloudWatch 指標
<a name="troubleshooting-with-cw-metrics"></a>

您可以在以下找到使用 Amazon CloudWatch 指標搭配 Storage Gateway 處理問題之動作的相關資訊。

**Topics**
+ [瀏覽目錄時，您的閘道反應緩慢](#slow-gateway)
+ [您的閘道未回應](#gateway-not-responding)
+ [您在 Amazon FSx 檔案系統中看不到檔案](#files-missing-fsx)
+ [您在 Amazon FSx 檔案系統中看不到較舊的快照](#snapshots-missing-fsx)
+ [您的閘道傳輸資料到 Amazon FSx 的速度緩慢](#slow-data-transfer-to-fsx)
+ [您的閘道備份任務失敗，或寫入閘道時發生錯誤](#backup-job-fails)

### 瀏覽目錄時，您的閘道反應緩慢
<a name="slow-gateway"></a>

如果您的檔案閘道在執行**ls**命令或瀏覽目錄時反應緩慢，請檢查 `IndexFetch`和 `IndexEviction` CloudWatch 指標：
+ 如果您執行 `ls`命令或瀏覽目錄時`IndexFetch`，指標大於 0，您的 File Gateway 會啟動，而沒有受影響目錄內容的資訊，且必須存取 FSx for Windows File Server。後續列出該目錄內容的動作應會更快完成。
+ 如果`IndexEviction`指標大於 0，表示您的檔案閘道已達到當時可在其快取中管理的限制。在這種情況下，您的檔案閘道必須從最近最少存取的目錄釋放一些儲存空間，以列出新的目錄。如果經常發生這種情況且效能受到影響，請聯絡 支援。

  與相關 Amazon FSx 檔案系統 支援 的內容和建議討論，以根據您的使用案例改善效能。

### 您的閘道未回應
<a name="gateway-not-responding"></a>

如果您的檔案閘道沒有回應，請執行下列動作：
+  如果有最近的重新開機或軟體更新，則請查看 `IOWaitPercent` 指標。此指標會顯示在有未完成磁碟 I/O 請求時 CPU 閒置時間的百分比。在某些情況下，百分比可能偏高 (10 或以上)，而且可能已在伺服器重新啟動或更新後上升。在這些情況下，您的檔案閘道可能會在重建索引快取至 RAM 時，受到慢速根磁碟的瓶頸。您可以將速度較快的實體磁碟用於根磁碟來解決此問題。
+ 如果`MemUsedBytes`指標與`MemTotalBytes`指標等於或幾乎相同，則檔案閘道會用盡可用的 RAM。請確定您的檔案閘道至少具有所需的 RAM 下限。如果已經這麼做，請考慮根據您的工作負載和使用案例，將更多 RAM 新增至您的檔案閘道。

  如果檔案共享是 SMB，此問題也可能是因為連線到檔案共享的 SMB 用戶端數目所造成。若要查看在任何指定時間連線的用戶端數目，請檢查 `SMBV(1/2/3)Sessions` 指標。如果連接了許多用戶端，您可能需要將更多 RAM 新增至檔案閘道。

### 您在 Amazon FSx 檔案系統中看不到檔案
<a name="files-missing-fsx"></a>

如果您注意到閘道上的檔案未反映在 Amazon FSx 檔案系統中，請檢查 `FilesFailingUpload` 指標。如果指標報告某些檔案上傳失敗，請檢查您的運作狀態通知。當檔案無法上傳時，閘道會產生運作狀態通知，其中包含問題的詳細資訊。

### 您在 Amazon FSx 檔案系統中看不到較舊的快照
<a name="snapshots-missing-fsx"></a>

FSx File Gateway 上的某些檔案操作，例如頂層資料夾重新命名或許可變更，可能會導致多個檔案操作，導致 FSx for Windows File Server 檔案系統具有高 I/O 負載。如果您的檔案系統沒有足夠的效能資源來處理工作負載，檔案系統可能會刪除[影子複本](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html)，因為它會將持續 I/O 的可用性優先於歷史影子複本保留。

在 Amazon FSx 主控台中，檢查**監控和效能**頁面，查看您的檔案系統是否佈建不足。如果是，您可以切換到 SSD 儲存體、增加輸送量容量或增加 SSD IOPS 來處理工作負載。

### 您的閘道傳輸資料到 Amazon FSx 的速度緩慢
<a name="slow-data-transfer-to-fsx"></a>

如果您的檔案閘道將資料傳輸到 Amazon FSx for Windows File Server 的速度緩慢，請執行下列動作：
+ 如果`CachePercentDirty`指標為 80 或更高，您的 File Gateway 將資料寫入磁碟的速度會比將資料上傳至 Amazon FSx for Windows File Server 的速度更快。考慮增加從檔案閘道上傳的頻寬、新增一或多個快取磁碟，或減慢用戶端寫入速度，或增加相關聯 Amazon FSx for Windows File Server 的輸送量容量。
+ 如果`CachePercentDirty`指標很低，請檢查`IoWaitPercent`指標。如果 `IoWaitPercent` 大於 10，您的檔案閘道可能會因為本機快取磁碟的速度而遇到瓶頸。建議將本機固態硬碟 (SSD) 磁碟用於快取，最好是 NVM Express (NVMe)。如果無法取得這種磁碟，請嘗試使用來自個別實體磁碟的多個快取磁碟，以提升效能。

### 您的閘道備份任務失敗，或寫入閘道時發生錯誤
<a name="backup-job-fails"></a>

如果您的檔案閘道備份任務失敗，或寫入檔案閘道時發生錯誤，請執行下列動作：
+ 如果`CachePercentDirty`指標為 90% 或更高，您的檔案閘道就無法接受對磁碟的新寫入，因為快取磁碟上沒有足夠的可用空間。若要查看您的檔案閘道上傳到 FSx for Windows File Server 的速度，請檢視 `CloudBytesUploaded` 指標。將該指標與 `WriteBytes` 指標進行比較，該指標顯示用戶端將檔案寫入檔案閘道的速度。如果 SMB 用戶端寫入檔案閘道的速度比上傳至 FSx for Windows File Server 的速度快，請新增更多快取磁碟，以至少涵蓋備份任務的大小。或者，增加上傳頻寬。
+ 如果備份任務等大型檔案副本失敗，但`CachePercentDirty`指標低於 80%，您的檔案閘道可能會命中用戶端工作階段逾時。若是 SMB，您可使用 PowerShell 命令 `Set-SmbClientConfiguration -SessionTimeout 300` 來增加此逾時設定。執行此命令會將逾時設為 300 秒。

## 高可用性運作狀態通知
<a name="troubleshooting-ha-notifications"></a>

在 VMware vSphere High Availability (HA) 平台上執行閘道時，您可能會收到運作狀態通知。如需運作狀態通知的詳細資訊，請參閱[故障診斷：高可用性問題](troubleshooting-ha-issues.md)。

# 故障診斷：高可用性問題
<a name="troubleshooting-ha-issues"></a>

如果發生可用性問題，您可在下列資訊中找到應採取的動作。

**Topics**
+ [運作狀態通知](#ha-health-notifications)
+ [指標](#ha-health-notification-metrics)

## 運作狀態通知
<a name="ha-health-notifications"></a>

在 VMware vSphere HA 上執行閘道時，所有閘道都會對您設定的 Amazon CloudWatch 日誌群組產生下列運作狀態通知。這些通知會進入名為 `AvailabilityMonitor` 的日誌串流。

**Topics**
+ [通知：重新啟動](#troubleshoot-reboot-notification)
+ [通知：HardReboot](#troubleshoot-hardreboot-notification)
+ [通知：HealthCheckFailure](#troubleshoot-healthcheckfailure-notification)
+ [通知：AvailabilityMonitorTest](#troubleshoot-availabilitymonitortest-notification)

### 通知：重新啟動
<a name="troubleshoot-reboot-notification"></a>

當閘道 VM 重新啟動時，您可能會收到重新啟動通知。您可以使用 VM Hypervisor Management 主控台或 Storage Gateway 主控台來重新啟動閘道 VM。您也可以在閘道維護週期期間使用閘道軟體來重新啟動。

**採取動作**

如果重新啟動的時間在閘道所設定之[維護開始時間](MaintenanceManagingUpdate-common.md)的 10 分鐘以內，這可能是正常的情況，而不是任何問題的徵兆。如果重新啟動很常在維護時段外發生，請檢查閘道是否已手動重新啟動。

### 通知：HardReboot
<a name="troubleshoot-hardreboot-notification"></a>

當閘道 VM 意外重新啟動時，您可能會收到 `HardReboot` 通知。這種重新啟動可能是因為電源中斷、硬體故障或其他事件。對於 VMware 閘道，vSphere 高可用性應用程式監控重設可能會導致此事件。

**採取動作**

當閘道在這種環境中執行時，請檢查 `HealthCheckFailure` 通知是否存在，並參閱 VM 的 VMware 事件記錄。

### 通知：HealthCheckFailure
<a name="troubleshoot-healthcheckfailure-notification"></a>

若是 VMware vSphere HA 上的閘道，當運作狀態檢查失敗且請求 VM 重新啟動時，您可能會收到 `HealthCheckFailure` 通知。此事件也會在監控可用性的測試期間發生，並顯示於 `AvailabilityMonitorTest` 通知中。在此情況下，則預期會收到`HealthCheckFailure` 通知。

**注意**  
此通知僅適用於 VMware 閘道。

**採取動作**

如果此事件在沒有 `AvailabilityMonitorTest` 通知的情況下重複發生，請檢查您的 VM 基礎設施是否有問題 (儲存空間、記憶體等)。如果您需要其他協助，請聯絡 支援。

### 通知：AvailabilityMonitorTest
<a name="troubleshoot-availabilitymonitortest-notification"></a>

對於 VMware vSphere HA 上的閘道，您可以在 VMware 中[執行](vmware-ha.md#vmware-ha-test-failover)[可用性和應用程式監控](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_StartAvailabilityMonitorTest.html)系統的測試時收到 `AvailabilityMonitorTest` 通知。

## 指標
<a name="ha-health-notification-metrics"></a>

`AvailabilityNotifications` 指標可在所有閘道上使用。此指標會計算閘道產生的可用相關運作狀態通知數目。使用 `Sum` 統計資料，即可觀察閘道是否發生任何可用性相關事件。如需事件的詳細資訊，請參閱您設定的 CloudWatch 日誌群組。