RHEL HA クラスタ内の VIP を内部ロードバランサに移行する

Google Cloud で SAP 用の OS ベースの高可用性（HA）クラスタに仮想 IP アドレス（VIP）を実装する場合、内部 TCP / UDP ロードバランサのフェイルオーバーサポートを使用することをおすすめします。

Google Cloud に SAP 用 Red Hat Enterprise Linux（RHEL）の HA クラスタがあり、エイリアス IP を使用して実装された VIP を使用している場合は、VIP を移行して内部ロードバランサを使用できます。

サポートされなくなった sap_hana_ha Deployment Manager テンプレートを使用して、RHEL の HA クラスタに SAP HANA スケールアップシステムをデプロイしている場合、VIP はエイリアス IP を使用して実装されています。

ここでは、RHEL の HA クラスタで VIP を移行する方法について説明します。

前提条件

以下の手順は、エイリアス IP を使用して VIP を実装している、適切に構成された HA クラスタが Google Cloud 上に存在することを前提としています。

手順の概要

VIP の代わりに一時的な転送ルールと IP アドレスを使用して、ロードバランサの構成とテストを行います。
クラスタをメンテナンスモードに設定します。予期しない動作を回避するため、可能な場合は SAP アプリケーションサーバーのインスタンスを停止します。
プライマリホストのエイリアス IP アドレスの割り当てを解除します。このアドレスはロードバランサの VIP になります。
Pacemaker クラスタの構成で次の操作を行います。
- 既存の VIP リソースのクラスを変更します。
- エイリアス IP の既存のパラメータをヘルスチェックサービスのパラメータに置き換えます。

既存の VIP アドレスを確認する

プライマリ VM インスタンスで、root 権限を使用して既存のエイリアス IP ベースのクラスタの構成を表示します。

$ pcs configure show

リソース定義では、VIP アドレス範囲が alias リソースと IPaddr2 リソースにあります。VIP アドレスを変更する必要がある場合は、両方のリソースを更新する必要があります。次の例をご覧ください。

Resource rsc_alias (class=ocf provider=heartbeat type=gcp-vpc-move-vip) \
               Attributes: alias_ip=10.10.0.90/32
               Operations: monitor interval=60s timeout=60s (vip_hkn_00-monitor-interval-60s)
               start interval=0s timeout=600s
               stop interval=0s timeout=20s
Resource rsc_vip(class=ocf provider=heartbeat type=IPaddr2) \
               Attributes: cidr_netmask=32 ip=10.10.0.90 nic=eth0
               Operations: monitor interval=10s timeout=20s (vip_hkn_00-monitor-interval-10s)
               start interval=0s timeout=20s (vip_hkn_00-start-interval-0s)
               stop interval=0s timeout=20s (vip_hkn_00-stop-interval-0s)

Google Cloud コンソールで、エイリアス IP で使用されている IP アドレスが予約されていることを確認します。IP アドレスは、エイリアス IP に使用した IP アドレスの場合もあれば、新しい IP アドレスの場合もあります。

$ gcloud compute addresses list --filter="region:( cluster-region )"

IP アドレスが予約され、プライマリ VM インスタンスに割り振られている場合、ステータスは IN_USE と表示されます。IP をロードバランサに再割り当てする場合は、最初にアクティブプライマリインスタンスの割り当てを解除します。この時点でステータスが RESERVED に変わります。

そのアドレスが list コマンドで返される IP アドレスに含まれていない場合は、将来のアドレスの競合を避けるため、この時点で予約してください。

$ gcloud compute addresses create vip-name \
  --region cluster-region --subnet cluster-subnet \
  --addresses vip-address

もう一度アドレスの一覧を表示して、IP アドレスが表示され RESERVED になっていることを確認します。

Cloud Load Balancing のフェイルオーバーサポートを構成する

フェイルオーバーをサポートする内部パススルーネットワークロードバランササービスは、ヘルスチェックサービスに基づいて、SAP HANA クラスタ内のアクティブホストにトラフィックをルーティングします。

競合を回避し、移行が完了する前にテストできるようにするため、この手順では VIP アドレスと同じサブネットのプレースホルダ IP アドレスを使用して一時的な転送ルールを作成します。VIP の実装を切り替える準備ができたら、VIP アドレスを使用して最終的な新しい転送ルールを作成します。

一時的な IP アドレスを仮想 IP 用として予約する

VIP アドレスはアクティブな SAP HANA システムに追従します。ロードバランサは、VIP に送信されるトラフィックを、現在アクティブな SAP HANA システムをホストしている VM にルーティングします。

Cloud Shell を開きます。

Cloud Shell に移動
エイリアス IP と同じサブネット内の一時的な IP アドレスをテスト用として予約します。--addresses フラグを省略すると、指定したサブネット内の IP アドレスが自動的に選択されます。
```
$ gcloud compute addresses create VIP_NAME \
  --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
  --addresses VIP_ADDRESS
```
静的 IP の予約の詳細については、静的内部 IP アドレスの予約をご覧ください。

IP アドレスの予約を確認します。

$ gcloud compute addresses describe VIP_NAME \
  --region CLUSTER_REGION

出力は次の例のようになります。

address: 10.0.0.19
addressType: INTERNAL
creationTimestamp: '2020-05-20T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-hana-ha
networkTier: PREMIUM
purpose: GCE_ENDPOINT
region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

ホスト VM のインスタンスグループを作成する

Cloud Shell で 2 つの非マネージドインスタンスグループを作成し、プライマリマスターホスト VM を 1 つのグループに、セカンダリマスターホスト VM をもう一方のグループに割り当てます。

$ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE \
  --instances=PRIMARY_HOST_NAME
$ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE \
  --instances=SECONDARY_HOST_NAME

インスタンスグループが作成されたことを確認します。

$ gcloud compute instance-groups unmanaged list

出力は次の例のようになります。

NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Compute Engine ヘルスチェックを作成する

Cloud Shell で、ヘルスチェックを作成します。ヘルスチェックで使用するポートには、他のサービスと競合しないようにプライベート範囲の 49152～65535 を選択します。チェック間隔とタイムアウトの値は、Compute Engine のライブマイグレーションイベント中のフェイルオーバーの許容範囲を広げるために、デフォルトよりも少し長くなっています。必要に応じて値を調整できます。
```
$ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2
```

ヘルスチェックが作成されたことを確認します。

$ gcloud compute health-checks describe HEALTH_CHECK_NAME

出力は次の例のようになります。

checkIntervalSec: 10
creationTimestamp: '2020-05-20T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: hana-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
tcpHealthCheck:
 port: 60000
 portSpecification: USE_FIXED_PORT
 proxyHeader: NONE
timeoutSec: 10
type: TCP
unhealthyThreshold: 2

ヘルスチェック用のファイアウォールルールを作成する

プライベート範囲のポートのファイアウォールルールを定義して、Compute Engine のヘルスチェックで使用される IP 範囲（35.191.0.0/16 と 130.211.0.0/22）からホスト VM へのアクセスを許可します。詳細については、ヘルスチェック用のファイアウォールルールの作成をご覧ください。

ホスト VM にネットワークタグを追加します（まだ設定されていない場合）。このタグは、ファイアウォールルールのヘルスチェックで使用されます。

$ gcloud compute instances add-tags PRIMARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone PRIMARY_ZONE
$ gcloud compute instances add-tags SECONDARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone SECONDARY_ZONE

まだ作成していない場合は、ヘルスチェックを許可するファイアウォールルールを作成します。

$ gcloud compute firewall-rules create RULE_NAME \
  --network NETWORK_NAME \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --target-tags NETWORK_TAGS \
  --rules tcp:HLTH_CHK_PORT_NUM

次に例を示します。

gcloud compute firewall-rules create  fw-allow-health-checks \
--network example-network \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags cluster-ntwk-tag \
--rules tcp:60000

ロードバランサとフェイルオーバーグループを構成する

ロードバランサのバックエンドサービスを作成します。

$ gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme internal \
  --health-checks HEALTH_CHECK_NAME \
  --no-connection-drain-on-failover \
  --drop-traffic-if-unhealthy \
  --failover-ratio 1.0 \
  --region CLUSTER_REGION \
  --global-health-checks

プライマリインスタンスグループをバックエンドサービスに追加します。

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group PRIMARY_IG_NAME \
  --instance-group-zone PRIMARY_ZONE \
  --region CLUSTER_REGION

セカンダリのフェイルオーバーインスタンスグループをバックエンドサービスに追加します。

$ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group SECONDARY_IG_NAME \
  --instance-group-zone SECONDARY_ZONE \
  --failover \
  --region CLUSTER_REGION

一時的な転送ルールを作成します。IP アドレスについては、テスト用に予約した一時的な IP アドレスを指定します。以下で指定されているリージョンの外部から SAP HANA システムにアクセスする必要がある場合は、定義に --allow-global-access フラグを含めます。
```
$ gcloud compute forwarding-rules create RULE_NAME \
  --load-balancing-scheme internal \
  --address VIP_ADDRESS \
  --subnet CLUSTER_SUBNET \
  --region CLUSTER_REGION \
  --backend-service BACKEND_SERVICE_NAME \
  --ports ALL
```
SAP HANA 高可用性システムへのリージョン間アクセスの詳細については、内部 TCP / UDP ロードバランシングをご覧ください。

ロードバランサの構成をテストする

バックエンドインスタンスグループはすぐには正常として登録されませんが、ヘルスチェックに応答するようにリスナーを設定することで、ロードバランサの構成をテストできます。リスナーを設定した後、ロードバランサが正しく構成されていれば、バックエンドインスタンスグループのステータスは正常に変わります。

以降のセクションでは、構成のテストに使用できるさまざまな方法について説明します。

`socat` ユーティリティでロードバランサをテストする

socat ユーティリティを使用して、ヘルスチェックポートを一時的にリッスンできます。

両方のホスト VM に socat ユーティリティをインストールします。
```
$ sudo yum install -y socat
```
socat プロセスを開始して、ヘルスチェックポートで 60 秒間リッスンします。
```
$ sudo timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork
```

Cloud Shell で、ヘルスチェックがリスナーを検出するまで数秒待ってから、バックエンドインスタンスグループのヘルスチェックを行います。

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

出力は次のようになります。

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

ポート 22 を使用してロードバランサをテストする

ホスト VM で SSH 接続用にポート 22 が開いている場合、ヘルスチェッカーに応答できるリスナーを備えたポート 22 を使用するように、ヘルスチェッカーを一時的に編集できます。

ポート 22 を一時的に使用するには、次の手順に従います。

コンソールでヘルスチェックをクリックします。

[ヘルスチェック] ページに移動
[編集] をクリックします。
[ポート] 項目で、ポート番号を 22 に変更します。
[保存] をクリックし、1～2 分待ちます。

Cloud Shell で、バックエンドインスタンスグループのヘルスチェックを行います。

$ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

出力は次のようになります。

---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

完了したら、ヘルスチェックのポート番号を元のポート番号に戻します。

ロードバランサを使用するように VIP の実装を移行する

以下の手順で、Pacemaker クラスタの構成とロードバランサの転送ルールを編集して、VIP の移行を完了します。

編集に向けてシステムの準備をする

可能であれば、SAP アプリケーションから SAP HANA データベースへの接続を一時的に停止します。これは、IP アドレスの交換の際に接続が短時間中断されるためです。NetWeaver のワークプロセスはデータベースに再接続する機能を備えていますが、障害やハングアップが発生する可能性があります。これは、接続を停止することによって回避できます。IP がターゲットリージョンの VPC に含まれる内部範囲に登録されていることを確認してください。
アクティブなプライマリインスタンスで root 権限を使用してクラスタをメンテナンスモードにします。
```
$ pcs property set maintenance-mode="true"
```
クラスタの構成をバックアップします。
```
$ pcs config show > clusterconfig.backup
```

エイリアス IP の割り振りを解除する

Cloud Shell で、SAP HANA のプライマリインスタンスに割り振られているエイリアス IP の範囲を確認します。
```
$ gcloud compute instances describe \
    primary-host-name \
    --zone primary-zone \
    --format="flattened(name,networkInterfaces[].aliasIpRanges)"
```
注: プライマリインスタンスのネットワークインターフェースを更新して、エイリアス IP を削除しようとしています。複数のエイリアス IP があり、いずれかを保持する必要がある場合は、ネットワークインターフェースの更新コマンドで、保持するエイリアス IP を指定する必要があります。更新コマンドで指定されていないエイリアス IP は、すべて割り振り解除されます。
Google Cloud コンソールで、ネットワークインターフェースを更新します。保持する必要のあるエイリアス IP がない場合は、--aliases "" を指定します。
```
$ gcloud compute instances network-interfaces update primary-host-name \
--zone primary-zone \
--aliases "ip-ranges-to-retain"
```

VIP の転送ルールを作成してクリーンアップする

Google Cloud コンソールで、ロードバランサ用の新しいフロントエンド転送ルールを作成します。以前にエイリアス IP 用として使用していた IP アドレスを IP アドレスとして指定します。この IP アドレスが VIP になります。
```
$ gcloud compute forwarding-rules create rule-name \
  --load-balancing-scheme internal \
  --address vip-address \
  --subnet cluster-subnet \
  --region cluster-region \
  --backend-service backend-service-name \
  --ports ALL
```
転送ルールの作成を確認し、削除対象となる一時的な転送ルールの名前を書き留めます。
```
$ gcloud compute forwarding-rules list
```

一時的な転送ルールを削除します。

$ gcloud compute forwarding-rules delete rule-name --region=cluster-region

予約した一時的な IP アドレスを解放します。

$ gcloud compute addresses delete temp-ip-name --region=cluster-region

リスナーをインストールし、ヘルスチェックリソースを作成する

ヘルスチェックリソースを構成するには、まずリスナーをインストールする必要があります。

リスナーをインストールする

ロードバランサは、各ホストのヘルスチェックポートでリスナーを使用して、SAP HANA クラスタのプライマリインスタンスが実行されている場所を判断します。1. プライマリシステムとセカンダリシステムのマスターインスタンスの root として、TCP リスナーをインストールします。以下の手順では、HAProxy をインストールしてリスナーとして使用します。

# yum install haproxy

構成ファイル haproxy.cfg を編集用に開きます。

# vi /etc/haproxy/haproxy.cfg

haproxy.cfg のデフォルト セクションで、mode を tcp に変更します。

デフォルト セクションの後に、以下を追加して新しいセクションを作成します。

#---------------------------------------------------------------------
# Health check listener port for SAP HANA HA cluster
#---------------------------------------------------------------------
listen healthcheck
  bind *:healthcheck-port-num

バインドポートは、ヘルスチェックの作成時に使用したポートと同じです。

完了したら、次の例のように更新されます。

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
  mode                    tcp
  log                     global
  option                  tcplog
  option                  dontlognull
  option http-server-close
  # option forwardfor       except 127.0.0.0/8
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000

#---------------------------------------------------------------------
# Set up health check listener for SAP HANA HA cluster
#---------------------------------------------------------------------
listen healthcheck
 bind *:60000

各ホストで root として、サービスを開始し、正しく構成されていることを確認します。
```
# systemctl start haproxy.service
```
Google Cloud コンソールの [ロードバランサ] ページで、ロードバランサのエントリをクリックします。

[ロードバランシング] ページ

[ロードバランサの詳細] ページの [バックエンド] セクションで、両方のホストで HAProxy サービスがアクティブな場合、各インスタンスグループエントリの [正常] の列に 1/1 が表示されます。
各ホストで、HAProxy サービスを停止します。
```
# systemctl stop haproxy.service
```
各ホストで HAProxy サービスを停止すると、各インスタンスグループの [正常] の列に 0/1 が表示されます。

後でヘルスチェックが構成されると、クラスタはマスターノードのリスナーを再起動します。

ヘルスチェックリソースを作成する

いずれかのホストで root として、HAProxy サービスのヘルスチェックリソースを作成します。
```
# pcs resource create healthcheck_resource_name service:haproxy op monitor interval=10s timeout=20s
```

クラスタ構成を編集してヘルスチェックリソースを使用し、エイリアスリソースを削除する

SAP HANA のプライマリインスタンスにマッピングされるエイリアス IP リソースを含む既存のグループの Colocation Constraints を削除します。
```
# pcs constraint remove colocation-alias-vip-group-sap_hana_resource_name
```
VIP とヘルスチェックリソースをグループ化する新しいリソースグループを作成します。
```
# pcs resource group add rsc-group-namehealthcheck_resource_namevip_resource_name
```
このコマンドは、エイリアス IP リソースと VIP リソースの以前のグループ名を、クラスタ構成の新しいリソースグループ名に置き換えます。

クラスタ構成で新しいリソースグループ名を確認します。

# pcs config show

出力は次の例のようになります。

Group: ilb-vip-group
Resource: vip_hkn_00 (class=ocf provider=heartbeat type=IPaddr2)
 Attributes: cidr_netmask=32 ip=10.10.0.90 nic=eth0
 Operations: monitor interval=10s timeout=20s (vip_hkn_00-monitor-interval-10s)
             start interval=0s timeout=20s (vip_hkn_00-start-interval-0s)
             stop interval=0s timeout=20s (vip_hkn_00-stop-interval-0s)
Resource: ilb-health-check (class=service type=haproxy)
 Operations: monitor interval=60 timeout=100 (ilb-health-check-monitor-interval-60)
             start interval=0s timeout=100 (ilb-health-check-start-interval-0s)
             stop interval=0s timeout=100 (ilb-health-check-stop-interval-0s)

エイリアスリソースを削除します。
```
# pcs resource delete alias_resource_name
```

クラスタのステータスを確認します。

# pcs status

出力には、次の例のように [Resource Group] セクションが表示されます。

STONITH-hana-ha-vm-1   (stonith:fence_gce):    Started hana-ha-vm-2
STONITH-hana-ha-vm-2   (stonith:fence_gce):    Started hana-ha-vm-1
Clone Set: SAPHanaTopology_HA1_22-clone [SAPHanaTopology_HA1_22]
    Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
Master/Slave Set: SAPHana_HA1_22-master [SAPHana_HA1_22]
    Masters: [ hana-ha-vm-1 ]
    Slaves: [ hana-ha-vm-2 ]
Resource Group: g-primary
    rsc_healthcheck_HA1        (service:haproxy):      Started hana-ha-vm-1
    rsc_vip_HA1_22     (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1

クラスタのメンテナンスモードを終了します。
```
# pcs property set maintenance-mode=false
```

更新された HA クラスタをテストする

アプリケーションインスタンスから、次のいずれかのコマンドを発行してデータベースにアクセスできることを確認します。

sidadm ユーザーとして:
```
> R3trans -d
```

任意のユーザーとして:

telnet VIP HANA SQL port

または

nc -zv VIP HANA SQL port

RHEL HA クラスタ内の VIP を内部ロードバランサに移行する

前提条件

手順の概要

既存の VIP アドレスを確認する

Cloud Load Balancing のフェイルオーバー サポートを構成する

一時的な IP アドレスを仮想 IP 用として予約する

ホスト VM のインスタンス グループを作成する

Compute Engine ヘルスチェックを作成する

ヘルスチェック用のファイアウォール ルールを作成する

ロードバランサとフェイルオーバー グループを構成する

ロードバランサの構成をテストする

socat ユーティリティでロードバランサをテストする

ポート 22 を使用してロードバランサをテストする

ロードバランサを使用するように VIP の実装を移行する

編集に向けてシステムの準備をする

エイリアス IP の割り振りを解除する

VIP の転送ルールを作成してクリーンアップする

リスナーをインストールし、ヘルスチェック リソースを作成する

リスナーをインストールする

ヘルスチェック リソースを作成する

クラスタ構成を編集してヘルスチェック リソースを使用し、エイリアス リソースを削除する

更新された HA クラスタをテストする

Cloud Load Balancing のフェイルオーバーサポートを構成する

ホスト VM のインスタンスグループを作成する

ヘルスチェック用のファイアウォールルールを作成する

ロードバランサとフェイルオーバーグループを構成する

`socat` ユーティリティでロードバランサをテストする

リスナーをインストールし、ヘルスチェックリソースを作成する

ヘルスチェックリソースを作成する

クラスタ構成を編集してヘルスチェックリソースを使用し、エイリアスリソースを削除する