バージョン情報については、Distributed Cloud 接続のリリースノートをご覧ください。

Distributed Cloud コネクテッドのトラブルシューティング

Google は、Google Distributed Cloud に接続されたハードウェアをリモートでモニタリングし、メンテナンスします。このため、Google エンジニアは Distributed Cloud 接続ハードウェアへの Secure Shell（SSH）アクセス権を持っています。Google が問題を検出すると、Google のエンジニアからお客様に連絡して、トラブルシューティングと解決を行います。問題をご自身で特定した場合は、直ちに Google サポートにお問い合わせのうえ、診断と解決を依頼してください。

Distributed Cloud コネクテッドマシンの接続

このセクションでは、Cloud Monitoring の指標エクスプローラ機能を使用して、Distributed Cloud に接続されたマシンのインターネットと Google Cloud の接続を確認する方法について説明します。

この手順では、次の Monitoring 指標を使用します。

Machine Connected（/machine/connected）: マシンが Google Cloudに接続されているかどうかを示します。
ネットワーク接続（/machine/network/connectivity）: マシンのプライマリネットワークインターフェースにインターネット接続があるかどうかを示します。

このセクションの手順を完了するには、次の前提条件を満たす必要があります。

Google Cloud コンソールと Distributed Cloud に接続された Google Cloud プロジェクトへのアクセス権。
Monitoring 指標を表示できる Monitoring 閲覧者 IAM ロール。
（省略可）返される結果をフィルタリングするための、ターゲットの Distributed Cloud コネクテッドマシンの machine_id 値。

Metrics Explorer を使用してマシンの接続を検証する

Metrics Explorer に移動します。
1. Google Cloud コンソールで、[モニタリング] セクションに移動します。
2. 左側のナビゲーションツリーで、[Metrics Explorer] をクリックします。
ターゲットリソースタイプを選択します。
1. [Metrics Explorer] ページで、[クエリ] ページに移動します。
2. 検索バーを使用して、マシン リソースタイプを検索します。完全なリソース識別子 edgecontainer.googleapis.com/Machine を使用することもできます。
3. 返された結果で、[マシン] リソースタイプをクリックします。
マシンが Google Cloudに接続されていることを確認します。
1. [指標] セクションで、connected 値を検索します。
2. [マシン接続] 指標を選択します。完全なパスは edgecontainer.googleapis.com/machine/connected です。
3. （省略可）[フィルタ] セクションを使用して、ターゲットの machine_id 値でフィルタします。
4. 表示された時間グラフで、[正常] の線が 100% のままになっていることを確認します。この値が 0% または [Unhealthy] になった場合、マシンは示された時間に Google Cloud との接続を失っています。
マシンのインターネット接続を検証します。
1. [指標] セクションで、connectivity 値を検索します。
2. [ネットワーク接続] 指標を選択します。完全なパスは edgecontainer.googleapis.com/machine/network/connectivity です。
3. （省略可）[フィルタ] セクションを使用して、ターゲットの machine_id 値でフィルタします。
4. 表示された時間グラフで、[正常] の線が 100% のままになっていることを確認します。この値が 0% Unhealthy になった場合、マシンは示された時間にインターネット接続を失っています。

検証結果を理解する

次の表に、Metrics Explorer から返される結果を示します。

マシンの状態	診断	解決策
正常「マシン接続」指標の値が `1` 「ネットワーク接続」指標の値が `1`	通常のオペレーション。	なし
切断「マシン接続」指標の値は `0` 「ネットワーク接続」指標の値は `1`	マシンはインターネットに接続されているが、 Google Cloudに接続できない。	Google サービスと API エンドポイントの [ファイアウォールルール](distributed-cloud/connected/1.11.0/docs/requirements#connected_management_and_monitoring_traffic)を確認します。Distributed Cloud 接続エージェントがマシンで実行されていることを確認します。
分離「マシン接続」指標の値は `0` 「ネットワーク接続」指標の値は `0`	マシンがインターネットに接続されていない。	電源ケーブルとネットワークケーブル、ローカルネットワーク構成、マシンの LED ステータスを確認します。VLAN とルーティングの構成を確認します。
断続的「マシン接続」指標の値が `0` と `1` の間で交互に変化する「ネットワーク接続」指標の値が `0` と `1` の間で交互に変化する	ネットワーク接続が不安定である、パケットロスが発生している、レイテンシが過剰である。	ローカルネットワークで輻輳やハードウェアの障害が発生していないか確認します。

いずれかの指標で 0 の値が継続的に確認される場合は、表に記載されているトラブルシューティングの手順に沿って問題を解決してください。問題が解決しない場合は、影響を受けるマシンの machine_id 値と停止のタイムスタンプを添えて、Google サポートにお問い合わせください。

VPN 接続で使用される Cloud Router リソースの BGP セッションが破損している

Distributed Cloud VPN 接続は、対応する Cloud Router リソースによって確立および管理される BGP セッションに依存して、Distributed Cloud 接続クラスタと Google Cloud間のルートをアドバタイズします。Distributed Cloud VPN 接続に関連付けられた Cloud Router リソースの構成を変更すると、その接続が機能しなくなる可能性があります。

影響を受ける Cloud Router で破損した BGP セッション構成を復元するには、次の操作を行います。

Google Cloud コンソールで、破損した BGP セッションの名前を取得します。次に例を示します。
```
INTERFACE=anthos-mcc-34987234
```
破損した BGP セッションのピア BGP と Cloud Router BGP の IP アドレス、および影響を受ける Distributed Cloud VPN 接続で使用されるピア ASN を取得します。次に例を示します。
```
GDCE_BGP_IP=168.254.208.74
CLOUD_ROUTER_BGP_IP=168.254.208.73
PEER_ASN=65506
```
BGP セッションを削除した場合は、代わりに Distributed Cloud 接続クラスタからこの情報を取得します。
1. クラスタの認証情報を取得します。
```
gcloud edge-cloud container clusters get-credentials CLUSTER_ID \
  --location REGION \
  --project PROJECT_ID
```
  次のように置き換えます。
  - CLUSTER_ID: 対象とするクラスタの名前。
  - REGION: ターゲットクラスタが作成される Google Cloud リージョン。
  - PROJECT_ID: ターゲット Google Cloud プロジェクトの ID。
2. MultiClusterConnectivityConfig リソースの構成を取得します。
```
kubectl get multiclusterconnectivityconfig -A
```
  このコマンドでは、次のような出力が返されます。
```
 NAMESPACE     NAME                   LOCAL ASN              PEER ASN
 kube-system   MultiClusterConfig1    65505                   65506
 ```
```
3. ピアの BGP IP アドレス、Cloud Router の IP アドレス、BGP セッションの ASN を取得します。
```
kubectl describe multiclusterconnectivityconfig -n kube-system MCC_CONFIG_NAME   
```
  MCC_CONFIG_NAME は、前の手順で取得した MultiClusterConfigResource の名前に置き換えます。
  
  このコマンドでは、次のような出力が返されます。
```
 Spec:
 Asns:
   Peer:  65505
   Self:  65506 # GDCE ASN
 Tunnels:
   Ike Key:
     Name:       MCC_CONFIG_NAME-0
     Namespace:  kube-system
   Peer:
     Bgp IP:      169.254.208.73 # Cloud Router BGP IP
     Private IP:  34.157.98.148
     Public IP:   34.157.98.148
   Self:
     Bgp IP:      169.254.208.74 # GDCE BGP IP
     Private IP:  10.100.29.49
     Public IP:   208.117.254.68
 ```
```
Google Cloud コンソールで、破損した VPN トンネルの名前、リージョン、Google Cloud プロジェクト名を取得します。次に例を示します。
```
VPN_TUNNEL=VPNTunnel1
REGION=US-East1
VPC_PROJECT_ID=VPC-Project-1
```
破損した BGP セッションを Cloud Router の構成から削除します。
新しい Cloud Router インターフェースを作成します。
```
gcloud compute routers add-interface --interface-name=INTERFACE_NAME \
   --vpn-tunnel=TUNNEL_NAME \ 
   --ip-address=ROUTER_BGP_IP \
   --project=VPC_PROJECT_ID \
   --region=REGION \
   --mask-length=30
```
次のように置き換えます。
- INTERFACE_NAME: このインターフェースを一意に識別するわかりやすい名前。
- TUNNEL_NAME: 前の手順で取得した VPN トンネルの名前。
- ROUTER_BGP_IP: この手順の前半で取得した Cloud Router の BGP IP アドレス。
- VPC_PROJECT_ID: ターゲット VPCGoogle Cloud プロジェクトの ID。
- REGION: ターゲット VPC Google Cloud プロジェクトが作成された Google Cloud リージョン。
BGP ピアを作成します。
```
gcloud compute routers add-bgp-peer --interface=INTERFACE_NAME \
   --peer-name=TUNNEL_NAME \
   --region REGION \
   --project=VPC_PROJECT_ID \
   --peer-ip-address=GDCE_BGP_IP \
   --peer-asn=GDCE_BGP_ASN \
   --advertised-route-priority=100 \
   --advertisement-mode=DEFAULT
```
次のように置き換えます。
- INTERFACE_NAME: 前の手順で作成したインターフェースの名前。
- TUNNEL_NAME: 前の手順でインターフェースの作成に使用した VPN トンネルの名前。
- REGION: ターゲット VPC Google Cloud プロジェクトが作成される Google Cloud リージョン。
- VPC_PROJECT_ID: ターゲット VPCGoogle Cloud プロジェクトの ID。
- GDCE_BGP_IP: この手順で取得した Distributed Cloud ピアの BGP IP アドレス。
- GDCE_BGP_ASN: この手順で先ほど取得した Distributed Cloud ピアの BGP ASN。

この時点で、BGP セッションが復元され、運用可能になります。

仮想マシンが `Pending` 状態のままになる

次のいずれかの状況が発生すると、仮想マシンワークロードが Pending 状態で停止し、ノードでスケジュール設定に失敗する可能性があります。

Distributed Cloud Connected は、リクエストされたリソース（CPU 時間、メモリ、ディスク容量など）を仮想マシンに割り当てることができません。
仮想マシンの構成に障害があります。
仮想マシンのストレージに障害が発生しています。
ターゲットノードが汚染されています。

この問題を解決するには、次の操作を行います。

クラスタの認証情報を取得するの説明に沿って、クラスタの認証情報を取得します。

影響を受けた仮想マシンに関する情報を取得します。

kubectl describe virtualmachine VM_NAME -n NAMESPACE

次のように置き換えます。

VM_NAME: ターゲット仮想マシンの名前。
NAMESPACE: ターゲット仮想マシンの Namespace。

このコマンドでは、次のような出力が返されます。

Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

コマンドの出力には、リソースの制約、スケジューリングの失敗、ストレージ障害などの問題を示すメッセージが含まれています。

出力で、次のセクションで説明するように、スケジューリングの失敗の原因を特定します。

リソースの不足

CPU、メモリ、ディスク容量などのリソースが不足していることを示すメッセージが表示されることがあります。次に例を示します。

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

この問題を解決するには、影響を受ける仮想マシンとノードでスケジュールされている他のワークロードに割り当てられているリソースを確認し、ビジネスニーズに応じて次の操作を行います。

ノードでスケジュールされている他のワークロードをスケールダウンする。
影響を受ける仮想マシンに割り当てられているリソースの量を減らします。
影響を受けるクラスタにマシンを追加します。

taint を追加したノード

ターゲットノードが汚染されていることを示すメッセージが表示されることがあります。次に例を示します。

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

この問題を解決するには、次の操作を行います。

次のコマンドを使用して、ノードの taint を確認します。

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

このコマンドでは、次のような出力が返されます。

NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

次のいずれかを行います。
- 予期しない taint がある場合は、taint と toleration の説明に沿って削除します。
- 想定される taint については、taint と toleration で説明されているように、対応する toleration を仮想マシンの構成に追加します。

ストレージの障害

仮想マシンのストレージに障害があることを示すメッセージが表示されることがあります。次に例を示します。

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

このメッセージは、対応する永続ボリュームがターゲットノードにマウントされていないことを示している可能性があります。

この問題を解決するには、次の操作を行います。

次のコマンドを使用して、影響を受ける仮想マシンの Namespace 内の永続ボリュームクレーム（PVC）のステータスを取得します。

kubectl get pvc -n NAMESPACE

NAMESPACE は、ターゲット Namespace の名前に置き換えます。

このコマンドでは、次のような出力が返されます。

NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

対応する PVC のステータスが Bound であることを確認します。ステータスが Pending の場合、ストレージサブシステムはボリュームのプロビジョニングに失敗しています。このような場合は、ストレージサブシステムの構成をトラブルシューティングし、適切な StorageClass が利用可能であることを確認する必要があります。

Distributed Cloud コネクテッドのトラブルシューティング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Distributed Cloud コネクテッド マシンの接続

Metrics Explorer を使用してマシンの接続を検証する

検証結果を理解する

VPN 接続で使用される Cloud Router リソースの BGP セッションが破損している

仮想マシンが Pending 状態のままになる

リソースの不足

taint を追加したノード

ストレージの障害

Distributed Cloud コネクテッドのトラブルシューティング

Distributed Cloud コネクテッドマシンの接続

仮想マシンが `Pending` 状態のままになる