Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
Google Compute Engine でロード バランシングのヘルス チェックをデバッグするコツ
2015年7月22日水曜日
* この投稿は、米国時間 7 月 14 日、Technical Solutions Engineer の
Charles Bacon によって投稿されたもの
の抄訳です。
ヘルス チェックでエラーが発生したら、どうすればデバッグできるでしょうか? ロード バランシングの適切な構成がどのようなものかを知っていれば、ヘルス チェックのデバッグ方法を理解するのは簡単です。この投稿では、ロード バランシングの適切な構成を示したうえで、ヘルス チェックの仕組みをかいつまんで紹介し、典型的なタイプのエラーと、ヘルス チェックのデバッグの進め方を説明します。
以下では、皆さんに
Compute Engine
のロード バランシングの使用経験があることを前提にしています。このテーマになじみがなければ、まず最初に
Compute Engine のドキュメントを参照
してネットワーク ロード バランシングの手順を試してみてください。
ロード バランシングの構成
Compute Engine で動作する
Debian GNU/Linux 7.8 (wheezy)
のインスタンスを見てみましょう。
/etc/init.d/google-address-manager
という起動スクリプトを含む
google-compute-daemon
というパッケージがあります。以下のコマンド実行例のとおりです。
$
dpkg-query -S /etc/init.d/google-address-manager
google-compute-daemon: /etc/init.d/google-address-manager
アドレス マネージャのジョブは、ロード バランスされている IP アドレスの設定など、インスタンスのネットワーク設定を構成することです。最初に、ロード バランサのターゲット プールに含まれないインスタンスで以下のコマンドを実行すると、IP 構成がわかります。
$
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 42:01:0a:f0:6c:91
inet addr:192.0.2.0 Bcast:192.0.2.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:263618 errors:0 dropped:0 overruns:0 frame:0
TX packets:311301 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:114548264 (109.2 MiB) TX bytes:29265762 (27.9 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
$
ip route list table local
local 192.0.2.0 dev eth0 proto kernel scope host src 192.0.2.0
broadcast 192.0.2.0 dev eth0 proto kernel scope link src 192.0.2.0
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
このインスタンスをネットワーク ロード バランシングのターゲット プールに追加すると、何が起こるか見てみましょう。この例では、ロード バランサは IP アドレス 198.51.100.0 を持っています。インスタンスをターゲット プールに追加すると、アドレス マネージャは次のように変更を
syslog
:
に記録します。
$
grep google-address /var/log/syslog
Feb 19 00:22:04 instance-1 google-address-manager: INFO Changing public IPs from None to ['198.51.100.0'] by adding ['198.51.100.0'] and removing None
ルート リストにもロード バランサの IP アドレスのエントリが追加されています。
$
ip route list table local
local 192.0.2.0 dev eth0 proto kernel scope host src 192.0.2.0
broadcast 192.0.2.0 dev eth0 proto kernel scope link src 192.0.2.0
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 198.51.100.0 dev eth0 proto 66 scope host
ロード バランサがバックエンドにパケットを送信すると、そのパケットは書き換えられずに転送されます。つまり、インスタンスがロード バランスされたトラフィックを受信すると、パケットの宛先 IP アドレスがロード バランサの外部アドレスと一致します。これは、インスタンス自体の外部アドレスに送られるトラフィックとは異なる点です。こうしたトラフィックは 1 対 1 の NAT(ネットワークアドレス変換)を経て到着し、その宛先 IP アドレスはインスタンスの内部 IP アドレスに設定されています。
ヘルス チェック
ロード バランサからインスタンスにどのようにトラフィックが流れるかがおわかりいただければ、ヘルス チェックの仕組みをご理解いただけます。IP アドレス 169.254.169.254 のメタデータ サーバーが、ヘルス チェック URL に対するトラフィックの送信を担当しています。このヘルス チェック宛先のアドレスは、ロード バランサの外部アドレスです。このプロセスは実際のインバウンド トラフィックを模しています。
ヘルス チェックは、timeoutSec 設定で指定された時間内に、HTTP 200 のステータス コードとともにレスポンスが返され、続いて TCP 接続が正常に閉じられなければなりません。ヘルス チェックのオプションの詳しい情報については、
ドキュメント
を参照してください。
ヘルス チェック エラーのタイプ
以下では、ヘルス チェック エラーの一般的な原因を紹介します。
エラー1. ロード バランサのアドレスでリッスンしていない
ヘルス チェック エラーの最も一般的な原因は、サービスをインスタンスの外部 IP アドレスにのみバインドしてしまうことです。以下の
netcat
コマンドでセットアップされた例を示します。
$
sudo nc -l -p 80 -s
192.0.2.0
$
netstat -an | grep :80
tcp
0
0 192.0.2.0:80
0.0.0.0:*
LISTEN
ポート 80 でリッスンしているサービスがあることがわかります。しかし、このサービスはインスタンスのアドレスにバインドされているため、ロード バランサの外部アドレスへの問い合わせに応答しません。この問題を修正するのは簡単です。サーバー プロセスがすべての問い合わせに応答するよう、
0.0.0.0
でリッスンするようにすればよいのです。このように構成されたサーバーは、以下のように、ポート 80 でロード バランサの外部アドレスへの問い合わせに応答します。
$
netstat -an | grep :80
tcp
0
0 0.0.0.0:80
0.0.0.0:*
LISTEN
エラー2. アドレスが構成されていない
以前のバージョンでは、起動スクリプト
google-address-manager
に問題があり、アドレス マネージャと
syslog
が競合することがありました。これについては
GitHub に修正方法が公開
されています。
この競合が発生すると、インスタンスはロード バランサの外部アドレスでトラフィックを受け入れられるように構成できません。ルーティング テーブルにエントリがないからです。
ip route table list local
を実行すれば、ルーティング テーブルを見ることができることを思い出してください。また、Linux の OOM(out-of-memory)-Killer が動作し、
google-address-manager
デーモンを強制終了(キル)した場合も、同様の問題を起こすことがあります。この場合は、このデーモンが強制終了される原因を解決する必要があります。当座の策として、デーモンを手動で起動してください。
エラー3. RST パケットの送信
インスタンス上のウェブ サーバーが、ヘルス チェックの TCP 接続を、TCP の通常の 4 ウェイ クロージング ハンドシェイクではなく、RST(リセット)パケットで閉じるように構成されることがあります。たとえば、一部のストリーミング メディア サーバーはこのオプションを提供しています。この場合、
tcpdump
を実行して表示されるウェブ サーバーからのトラフィックは問題なさそうですが、結局はフラグを見ることになります。以下のように、出力に R(ST)フラグが含まれます。
Flags [R.], seq 59, ack 92, win 8096
ウェブ サーバーがこのオプションを提供している場合、ヘルス チェック URL については無効にしておきましょう。
エラー4. 応答に時間がかかりすぎる
ウェブ サーバーが、指定されたタイムアウト時間内にヘルス チェックへのレスポンスを完了しない場合、健全な状態ではないと見なされます。最終的に
HTTP 200 response
コードを返し、TCP 接続が正常に閉じられるとしてもです。ヘルス チェックはこの種のエラーをやり過ごすように設計されています。しかし、健全な状態にあると考えるサーバーでこの問題が起こった場合、ヘルス チェックのタイムアウト時間を延ばして対処することもできます。
エラー5. HTTP 200 レスポンス コードを直接返さない
ウェブ サーバーは、HTTP 200 レスポンス コードを返すページにリクエストをリダイレクトするように構成されていることもあります。ヘルス チェックはリダイレクトに対応しておらず、ヘルス チェック ページが
HTTP 200 response
コードを直接返すことを期待します。
デバッグ
ヘルス チェック エラーが発生しているロード バランサをデバッグしようとするときは、以下のような考え方で作業を進めます。
ip route list table local
を実行し、ロード バランサのアドレスが適切に設定されているかどうかをチェックします。適切に設定されていなかったら、アドレス マネージャが動いていない原因を調べましょう。設定されていた場合は、ロード バランサのプール内の健全な状態ではないインスタンスに対して
tcpdump
を実行します。たとえば、以下のようなコマンドを実行します。
$
tcpdump host 169.254.169.254
このコマンドにより、メタデータ サーバー(ヘルス チェックを起動するサーバー)からのパケットがすべて出力されます。さらにフィルタリングする必要があるかもしれません。インスタンスはメタデータ サーバーにプロジェクトのメタデータを問い合わせることがあるからです。こうした問い合わせは調べる必要がありません。
インスタンスの外部アドレスに焦点を当ててヘルス チェックをデバッグしたくなるかもしれませんが、このアプローチでは不十分です。上記のエラー 1、2 が調査から漏れてしまい、エラー 3 も見過ごされるおそれがあるからです。
デバッグの際に念頭に置くべきもう 1 つのポイントは、「ヘルス チェックがどのようにロード バランサに影響するか」です。
いずれかのインスタンスが健全な状態と判定されれば、ロード バランサはそのインスタンスにトラフィックを送信します。すべてのインスタンスが健全な状態ではないと判定された場合でも、それらにトラフィックが送信され、トラフィックを落とさないようになっています(
ターゲット プールに関するドキュメントの backupPool セクションのルール 3、4
を参照)。
このため、すべてのインスタンスが健全ではない状態と判定されても、ロード バランサが機能しているように見える場合があります。上記のエラー 3 または 4 はこの場合に当てはまるかもしれません。いずれにしても、トラフィックを受信すべきノードとそうでないノードを適切に識別できるように、ヘルス チェックの問題解決を行わなければなりません。
- Posted by Charles Bacon, Technical Solutions Engineer
0 件のコメント :
コメントを投稿
12 か月間のトライアル
300 ドル相当が無料になるトライアルで、あらゆる GCP プロダクトをお試しいただけます。
Labels
.NET
.NET Core
.NET Core ランタイム
.NET Foundation
#gc_inside
#gc-inside
#GoogleCloudSummit
#GoogleNext18
#GoogleNext19
#inevitableja
Access Management
Access Transparency
Advanced Solutions Lab
AI
AI Hub
AlphaGo
Ansible
Anthos
Anvato
Apache Beam
Apache Maven
Apache Spark
API
Apigee
APIs Explore
App Engine
App Engine Flex
App Engine flexible
AppArmor
AppEngine
AppScale
AprilFool
AR
Artifactory
ASL
ASP.NET
ASP.NET Core
Attunity
AutoML Vision
AWS
Big Data
Big Data NoSQL
BigQuery
BigQuery Data Transfer Service
BigQuery GIS
Billing Alerts
Bime by Zendesk
Bitbucket
Borg
BOSH Google CPI
Bower
bq_sushi
BreezoMeter
BYOSL
Capacitor
Chromium OS
Client Libraries
Cloud API
Cloud Armor
Cloud Audit Logging
Cloud AutoML
Cloud Bigtable
Cloud Billing Catalog API
Cloud Billing reports
Cloud CDN
Cloud Client Libraries
Cloud Console
Cloud Consoleアプリ
Cloud Container Builder
Cloud Dataflow
Cloud Dataflow SDK
Cloud Datalab
Cloud Dataprep
Cloud Dataproc
Cloud Datastore
Cloud Debugger
Cloud Deployment Manager
Cloud Endpoints
Cloud Firestore
Cloud Foundry
Cloud Foundry Foundation
Cloud Functions
Cloud Healthcare API
Cloud HSM
Cloud IAM
Cloud IAP
Cloud Identity
Cloud IoT Core
Cloud Jobs API
Cloud KMS
Cloud Launcher
Cloud Load Balancing
Cloud Machine Learning
Cloud Memorystore
Cloud Memorystore for Redis
Cloud monitoring
Cloud NAT
Cloud Natural Language API
Cloud Networking
Cloud OnAir
Cloud OnBoard
cloud Pub/Sub
Cloud Resource Manager
Cloud Resource Manager API
Cloud SCC
Cloud SDK
Cloud SDK for Windows
Cloud Security Command Center
Cloud Services Platform
Cloud Source Repositories
Cloud Spanner
Cloud Speech API
Cloud Speech-to-Text
Cloud SQL
Cloud Storage
Cloud Storage FUSE
Cloud Tools for PowerShell
Cloud Tools PowerShell
Cloud TPU
Cloud Translation
Cloud Translation API
Cloud Virtual Network
Cloud Vision
Cloud VPC
CloudBerry Backup
CloudBerry Lab
CloudConnect
CloudEndure
Cloudflare
Cloudian
CloudML
Cluster Federation
Codefresh
Codelabs
Cohesity
Coldline
Colossus
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Container-Optimized OS
Container-VM Image
Couchbase
Coursera
CRE
CSEK
Customer Reliability Engineering
Data Studio
Databases
Dbvisit
DDoS
Debugger
Dedicated Interconnect
deep learning
Deployment Manager
Developer Console
Developers
DevOps
Dialogflow
Disney
DLP API
Docker
Dockerfile
Drain
Dreamel
Eclipse
Eclipse Orion
Education Grants
Elasticsearch
Elastifile
Energy Sciences Network
Error Reporting
ESNet
Evernote
FASTER
Fastly
Firebase
Firebase Analytics
Firebase Authentication
Flexible Environment
Forseti Security
G Suite
Gartner
gcloud
GCP
GCP Census
GCP 移行ガイド
GCP 認定資格チャレンジ
GCPUG
GCP導入事例
gcsfuse
GEO
GitHub
GitLab
GKE
Go
Go 言語
Google App Engine
Google Apps
Google Certified Professional - Data Engineer
Google Cloud
Google Cloud Certification Program
Google Cloud Client Libraries
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Endpoints
Google Cloud Explorer
Google Cloud Identity and Access Management
Google Cloud INSIDE
Google Cloud INSIDE Digital
Google Cloud INSIDE FinTech
Google Cloud Interconnect
Google Cloud Launcher
Google Cloud Logging
Google Cloud Next '18 in Tokyo
Google Cloud Next '19 in Tokyo
Google Cloud Platform
Google Cloud Resource Manager
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud SQL
Google Cloud Storage
Google Cloud Storage Nearline
Google Cloud Summit '18
Google Cloud Summit ’18
Google Cloud Tools for IntelliJ
Google Code
Google Compute Engine
Google Container Engine
Google Data Analytics
Google Data Studio
Google Date Studio
Google Deployment Manager
Google Drive
Google Earth Engine
Google Genomics
Google Kubernetes Engine
Google maps
google maps api
Google Maps APIs
Google Maps Platform
Google SafeSearch
Google Service Control
Google Sheets
Google Slides
Google Translate
Google Trust Services
Google VPC
Google マップ
Google 公認プロフェッショナル
GoogleNext18
GPU
Gradle
Grafeas
GroupBy
gRPC
HA / DR
Haskell
HEPCloud
HIPAA
Horizon
HTCondor
IaaS
IAM
IBM
IBM POWER9
icon
IERS
Improbable
INEVITABLE ja night
inevitableja
InShorts
Intel
IntelliJ
Internal Load Balancing
Internet2
IoT
Issue Tracker
Java
Jenkins
JFrog
JFrog Artifactory SaaS
Jupiter
Jupyter
Kaggle
Kayenta
Khan Academy
Knative
Komprise
kubefed
Kubeflow Pipelines
Kubernetes
KVM
Landsat
load shedding
Local SSD
Logging
Looker
Machine Learning
Magenta
Managed Instance Group
Managed Instance Group Updater
Maps API
Maps-sensei
Mapsコーナー
Maven
Maxon Cinema 4D
MightyTV
Mission Control
MongoDB
MQTT
Multiplay
MySQL
Nearline
Network Time Protocol
Networking
neural networks
Next
Node
NoSQL
NTP
NuGet パッケージ
OCP
OLDISM
Open Compute Project
OpenCAPI
OpenCAPI Consortium
OpenShift Dedicated
Orbitera
Organization
Orion
Osaka
Paas
Panda
Particle
Partner Interconnect
Percona
Pete's Dragon
Pivotal
Pivotal Cloud Foundry
PLCN
Podcast
Pokemon GO
Pokémon GO
Poseidon
Postgre
PowerPoint
PowerShell
Professional Cloud Network Engineer
Protocol Buffers
Puppet
Pythian
Python
Qwiklabs
Rails
Raspberry Pi
Red Hat
Redis
Regional Managed Instance Groups
Ruby
Rust
SAP
SAP Cloud Platform
SC16
ScaleArc
Secure LDAP
Security & Identity
Sentinel-2
Service Broker
Serving Websites
Shared VPC
SideFX Houdini
SIGOPS Hall of Fame Award
Sinatra
Site Reliability Engineering
Skaffold
SLA
Slack
SLI
SLO
Slurm
Snap
Spaceknow
SpatialOS
Spinnaker
Spring
SQL Server
SRE
SSL policies
Stack Overflow
Stackdriver
Stackdriver Agent
Stackdriver APM
Stackdriver Debugger
Stackdriver Diagnostics
Stackdriver Error Reporting
Stackdriver Logging
Stackdriver Monitoring
Stackdriver Trace
Stanford
Startups
StatefulSets
Storage & Databases
StorReduce
Streak
Sureline
Sysbench
Tableau
Talend
Tensor Flow
Tensor Processing Unit
TensorFlow
Terraform
The Carousel
TPU
Trace
Transfer Appliance
Transfer Service
Translate API
Uber
Velostrata
Veritas
Video Intelligence API
Vision API
Visual Studio
Visualization
Vitess
VM
VM Image
VPC Flow Logs
VR
VSS
Waze
Weave Cloud
Web Risk AP
Webyog
Wide and Deep
Windows Server
Windows ワークロード
Wix
Worlds Adrift
Xplenty
Yellowfin
YouTube
Zaius
Zaius P9 Server
Zipkin
ZYNC Render
アーキテクチャ図
イベント
エラーバジェット
エンティティ
オンライン教育
クラウド アーキテクト
クラウド移行
グローバル ネットワーク
ゲーム
コードラボ
コミュニティ
コンテスト
コンピューティング
サーバーレス
サービス アカウント
サポート
ジッター
ショート動画シリーズ
スタートガイド
ストレージ
セキュリティ
セミナー
ソリューション ガイド
ソリューション: メディア
データ エンジニア
データセンター
デベロッパー
パートナーシップ
ビッグデータ
ファジング
プリエンプティブル GPU
プリエンプティブル VM
フルマネージド
ヘルスケア
ホワイトペーパー
マイクロサービス
まっぷす先生
マルチクラウド
リージョン
ロード シェディング
運用管理
可用性
海底ケーブル
機械学習
金融
継続的デリバリ
月刊ニュース
資格、認定
新機能、アップデート
深層学習
深層強化学習
人気記事ランキング
内部負荷分散
認定試験
認定資格
料金
Archive
2019
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
6月
5月
4月
3月
2月
Feed
月刊ニュースレターに
登録
新着ポストをメールで受け取る
Follow @GoogleCloud_jp
0 件のコメント :
コメントを投稿