- UbicloudはHetznerの新しいAX162サーバーがAX161より性能・価格の面で優れているように見えたため導入したが、運用中に障害が16倍も頻発する信頼性問題に直面した
- 原因追跡はNULLバイトが残ったシステムログから始まり、負荷、温度、部品情報、電力消費を順に除外していく形で進められ、
sensors、dmidecode、powerstatが中核ツールとなった
- 初期データではAX161はサービス期間3,784日で障害11件、AFR 1.06だった一方、AX162は737日で障害34件となり、AFR 16.84を記録した
- 一度障害が起きたサーバーの80%は24時間以内に2回目の障害を経験し、Hetznerは電力制限の有無を確認しないまま、マザーボードのロット不良を通知した
- 最新マザーボードへ移行したAX162 -v3は数か月の監視後にAFR 0.39まで低下し、新しいハードウェアは非中核ワークロードから段階的に検証すべきだと分かった
AX162導入後に繰り返されたクラッシュ
- Ubicloudはベアメタルプロバイダーをクラウドプラットフォームに変えるソフトウェアを作っており、Hetznerを安価で信頼できるサーバープロバイダーとして利用してきた
- HetznerのAX162サーバーラインは、前モデルのAX161より高い性能と低価格を提供しており、急速に導入された
- 最初のAX162サーバーを購入して3週間後、1台のサーバーがクラッシュし、システムログにはNULLバイトが残っていた
- 電源喪失のように書き込み処理を正常に完了できなかった、突然の障害の兆候と解釈された
- Hetznerのハードウェア点検では当初異常は見つからなかったが、1週間後に別のクラッシュが発生し、その後も数日のうちに障害が繰り返された
障害の現れ方
- すべてのクラッシュはAX162サーバーでのみ発生した
- 障害は2つの形に分かれた
- 手動再起動後にサーバーが再びオンラインに戻るケース
- 再起動要求やHetznerエンジニアの診断コードにも応答せず、サーバーを交換しなければならないケース
- サーバーは通常、長期間は正常に動作するが、最初のクラッシュ後は追加クラッシュが起きる可能性が高まった
- 1つ目のタイプのクラッシュが何度も繰り返された後、最終的に2つ目のタイプへ進み、サーバー交換に至る流れが観察された
まず負荷と温度を除外
- AX162は96 vCPUを提供しており、UbicloudにはすべてのvCPUを同時に使うワークロードがあった
- 高負荷が温度上昇や予期しない問題を生むという仮説を検討したが、クラッシュ時点では低負荷、あるいは無負荷の状態でも障害が発生していた
- 温度と障害の相関を見るため、
sensorsコマンドでシステム構成要素の温度を収集した
- 単純なcronジョブで温度データを集め、再びクラッシュが起きたときに確認した温度は平均より大幅に高くはなかった
部品情報と電力消費の調査
lshwとdmidecodeでハードウェア部品のモデルとシリアル番号を確認した- クラッシュが発生したAX162サーバーとそうでないサーバーの部品を比較したが、有意な差は見つからなかった
- 古い部品のほうが故障しやすい可能性を考えてシリアル番号の増加傾向も確認したが、最新シリアル番号を持つサーバーでもクラッシュが発生した
- データセンター拡張では、空間よりも電力が制約になることが多く、運用者がマシンごとの電力使用量を制限できる場合がある
- UbicloudはHetznerが電力消費を制限しているかは分からなかったが、長期間安定稼働した後に反復クラッシュが起こる症状はハードウェア摩耗と一致すると見ていた
- 他の仮説を一つずつ除外した結果、電力制限が有力な仮説として残った
powerstat -Rで長期間の最大電力消費を測定し、公称値と比較した
- AX161: 公称最大電力 147W、測定最大電力 168W
- AX162: 公称最大電力 408W、測定最大電力 266W
- この差から、Hetznerが実際の電力使用を制限している可能性があると疑った
AFRで見た障害率
- ハードウェア信頼性の比較にはAnnualized Failure Rate(AFR) を使った
- AFRには限界があるが、障害率を比較する出発点としては十分に単純な指標だった
- 初期測定結果ではAX162の障害率はAX161よりはるかに高かった
- AX161: 障害11件、総サービス日数3,784日、AFR 1.06
- AX162: 障害34件、総サービス日数737日、AFR 16.84
- このデータは、AX162が他モデルより障害を経験する可能性が16倍高いという観察を裏付けていた
- 一度クラッシュしたサーバーは再びクラッシュする可能性が非常に高く、クラッシュを1回経験したサーバーの80%が24時間以内に2回目のクラッシュを経験した
マザーボード交換とv2の限界
- Ubicloudは、電力制限への疑いとAFRデータを含む詳細なサポートチケットをHetznerに提出した
- Hetznerは電力制限の可能性を確認も否定もしなかったが、マザーボードのロット不良を確認したと伝えた
- Hetznerは新ロットのマザーボードを受領しており、影響を受けたサーバーのマザーボード交換を推奨した
- 大規模なサーバー交換は顧客ワークロードに影響し得たが、反復クラッシュのため、すでに大半の重要作業をAX162から移していた状態だったので交換できた
- 新しいマザーボードへ交換した後も、重要ワークロードはAX162に戻さず、長期監視を続けた
- 当初はクラッシュがなかったが、2週間後、新マザーボードを搭載したサーバーでもクラッシュが発生した
- AX162 -v2: 障害11件、総サービス日数758日、AFR 5.30
- v2は従来のAX162よりクラッシュ頻度は低かったが、障害率は依然として高かった
v3で安定した結果
- Hetznerに再度連絡したところ、信頼性がさらに改善された最新マザーボード版があることが分かった
- サーバーを最新バージョンへ移行し、信頼性を監視した
- 数か月にわたり新サーバーを観察した後、AX162のクラッシュ問題は解決したと判断した
- 最終的なAFR比較は次の通り
- AX161: 障害11件、総サービス日数3,784日、AFR 1.06
- AX162: 障害34件、総サービス日数737日、AFR 16.84
- AX162 -v2: 障害11件、総サービス日数758日、AFR 5.30
- AX162 -v3: 障害4件、総サービス日数3,738日、AFR 0.39
- AX162 -v3のAFRはAX161よりもさらに低かった
運用プロセスの改善
- 新しいサーバーラインを早期導入すると、予想外の問題が生じることがある
- AX162は仕様が魅力的で、HetznerがAX161を終了したことも、新ラインが本番投入の準備ができている合図のように見えた
- 6か月待っていれば多くの問題を避けられた可能性が高いと判断した
- 今後の変更点は次の通り
- 新しいサーバーモデルについて、より徹底した検証を行う
- 新しいハードウェアは非中核ワークロードから始めて段階的に導入する
- リスク分散のため、より多くのベアメタルプロバイダーを追加する
- UbicloudはすでにLeasewebとLatitudeという2つの追加ベアメタルプロバイダーをサポートしており、4つ目のプロバイダー追加も進行中である
1件のコメント
Hacker Newsの意見
ほかのAXモデル（AX42、AX52、AX102）にも、数カ月後に故障する深刻な信頼性問題がある
欠陥のあるメインボードが原因なので、Hetznerは特定の日付以前に作られたサーバーのメインボードを、今後12カ月の間に大半、場合によってはすべて交換する必要がある [0]
[0] https://docs.hetzner.com/robot/dedicated-server/general-info...
最新の交換品は持ちこたえているようなので、小さなサンプルでは**故障率50%**のように見える。実際の数字はHetznerとASRockだけが知っているのだろう
以前の会社で、DevOpsがHetzner機材のCPUファン故障をよく見つけていた
一般的に想定されるHDD/SSD故障とは別のもので、自分たちで監視する必要があった。非マネージドのサーバーがクラウドインスタンスより安い理由の1つだ
Dropboxに入社した初日にチームへ「フリート内で400MHzで動いているマシンを見つけられる」と言い、実際その通りだった。誤った冗長PSUコントローラーがPROCHOTを発動していた。マシンが多ければこういうことは起きる
物理機器を正しく所有・保守・修理するのは依然としてホスティング会社の責任であり、監視も含まれる。以前はスクリプトやパッケージをインストールして監視に接続する必要があったが、IPMIなどが標準になった今では顧客の手助けなしでもできる
ラックスペース、電力、ネットワークだけを提供している場合でなければ、どこまで引き受けるかは契約上の問題だ。Hetznerが自社ハードウェアのCPUファン故障すら検知できず、新システムを十分にテストせずに配備したのなら、ずれ続けている証拠に見える
購入を評価するときに相手の立場を少しも考えず、コストを下げて売上だけを伸ばそうとすれば、怪しい営業系の業種でもない限り長続きしない
サーバーハードウェアは本当に安く、ある程度腕のあるプログラマーなら、たいていのプログラムは単一サーバーや仮想マシン1台でも処理できる。月25ドルではなく月50ドルを払って、多少のマージンを与えるべきだ。それでもその会社が潰れない、あるいはあなたを大切な顧客として見てくれる保証はなく、結局は大口顧客のおかげで全体が利益を出す構造に頼ることになる
事業が米国にあるなら、米国のホスティング業者を使うのが正しい
「6カ月待っていれば多くの問題を避けられたし、アーリーアダプターがたいてい先に問題を見つけ、後で修正される」という助言は、安定性が必要なあらゆるシステムに当てはまる
セキュリティ問題がなければ、数カ月待つか、1〜2バージョン遅れの状態を維持する
たとえば森で年老いたイノシシは、信頼しにくい空き地にまず子どもたちを送り込もうとして安全の合図を出す。技術の世界で言えば、まだ本番準備ができていない技術を持ち上げるブログ記事を書くのに似ている
それでも私たちの苦労が根本原因をより早く明らかにする助けになったのは、せめてもの幸いだ
記事には書かなかったが、今後はサーバーを受け取ったら、実際の顧客ワークロードなしで約1カ月間アイドル状態にしておく案も検討した。費用は増えるが、ユーザーに影響を与えずに潜在的な問題を見つける助けになり得る。私たちの場合、最初のAX162サーバーを配備して3週間後にクラッシュが始まったので、少なくとも1カ月、場合によってはもっと長いバッファ期間が必要だ
ただしUbicloudが新モデルや購入トランシェをバーンインなしで使うのは、今回が最初で最後になるはずだ。私もそこで働いており、共同創業者だ
Dellにも時々こういう問題がある。以前のサーバーの初回ロットを受け取った時、サーバーが背面I/O側のデバイス群をしばらく見失い、メインボードのI/O背面セクションを交換する必要があった
たとえばイーサネットコントローラー、iDRAC、ときにはBIOSまで消えた。この問題を乗り越えた後は、ほぼ10年間順調に動いた
最近はRAIDカードから電源レギュレーターまで全部劣化して退役させた。設定変更のために正常稼働していたサーバーを再起動したところ、エレクトロマイグレーションでRAIDプロセッサ内部の配線が侵食され、RAIDカードを永遠に失うというのは、目が覚めるような経験だった
Hetzner は電力制限の可能性を肯定も否定もしなかったそうですが、電力制限の結果が何なのか気になります。
記事ではハードウェアがより早く劣化する可能性があるとしていますが、なぜそうなるのか分かりません。
Hetzner の無反応と UbiCloud の測定値を見ると、実際に電力を制限しているように思えます。そうでなければ「違う」と言ったはずですから。
確認するには
cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governorを実行すればよいです。値はperformanceであるべきです。そうでなければ
echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governorで設定できます。CPU を多く使うワークロードなら効果があります。再起動すると戻るので、cron/systemd などで維持すればよいです。もちろん電気代を自分で払っている場合や自分のハードウェアなら、スケーリングガバナーは自分で判断すればよいです。しかし借りているベアメタルサーバーなら
performanceが適切です。データセンター運営者が電力制約の中でマシン数を増やすためにサーバーごとの消費電力を制限し、それがマザーボードの劣化を早める可能性があるという部分は直感に反します。
ざっと調べた限りでも、電力制限は複数の部品の有効寿命を延ばす方向に見えました。
逆の主張をする検索結果は、サーマルスロットリングにかかったときの高い動作温度がコンデンサーのような部品をより早く劣化させ得る、という内容だけでした。ところが記事では複数の温度センサーを見ており、そのケースではないと明示されていました。
下の返信が例を一つ共有しており、検索してみるとソースがさらにいくつか出てきました [1], [2]。
ただし私は電子工学者ではないので、理解が完全に正確ではないかもしれません。劣化は電力制限そのものではなく電力変動によるものだったか、別の要因があった可能性もあります。
[1] https://electronics.stackexchange.com/questions/65837/can-el...
[2] https://superuser.com/questions/1202062/what-happens-when-ha...
電圧は電力会社が供給する値で、電流はラックごとに監視されます。データセンターで電流上限を超えたときの一般的な反応は、ヒューズが飛ぶか、さらに多くの料金を求められることです。
サーバーが使う電力を減らす唯一の方法は CPU をスロットリングすることです。通常は OS を通じて CPU をスロットリングするので協力が必要です。
OS の関与なしに lights-out ベースバンドコントローラーで可能かもしれないとは推測しますが、そうであれば
/sysで見える可能性が高いと思います。それでも、高電力サーバー数台がデータセンターのより広い範囲をダウンさせないよう、ラックごとに制限します。
制限方式は確かではありませんが、家庭にあるような単純なブレーカーが簡単な解決策かもしれません。すると遮断時にラックの電源が落ち、ラック全体と複数の顧客に影響するので理想的ではありません。
別の選択肢は電流/電力リミッター[0]ですが、P = U * I なのでより多くの問題を生み得ます。電圧（U）が下がってシステム全体が低電圧状態になり、奇妙なグリッチが発生します。チップのさまざまなセキュリティ機構を迂回する一般的な方法でもあります。Raspberry Pi もこうしたバグを見つけ、電圧攻撃を含む攻撃にチップがどれだけ耐えられるかをテストするためにチャレンジ[1]を開催しました。
[0] - https://en.m.wikipedia.org/wiki/Current_limiting
[1] - https://www.raspberrypi.com/news/security-through-transparen...
通常の解決策は、そのほかの部品の温度も監視してファン速度アルゴリズムの入力に入れることです。実際にここでそうしたことが起きたかは分かりません。
はっきりとは分かりませんが、電力・信号、またはVRM の問題かもしれません。
CPU が熱くないということは、ボード上の別の何かが仕様を外れて致命的な故障に入っていない、という意味ではありません。
電力・信号まわりのマザーボード問題は診断が厄介です。外からは別の部品の問題のように見えるあらゆる症状として現れ、経験上、RAM の初期化失敗とランダムな再起動が非常によくあります。結局、実際にマザーボードを交換するまで、あらゆるものを交換してみることになります。
現在使っている AX102 でも似たことがあり、ネットワークカード関連の問題でクラッシュしたように見えました。
幸い Hetzner のサポートは交換用ハードウェアをうまく手配してくれました。かなり面倒でしたが、ハードウェア問題の解決を学ぶ良い機会で、個人的にはその価値がありました。
Hetzner が何度も見てくれましたが、何も見つけられないか、CPU のサーマルペーストや PSU コネクターを交換するだけでした。AX162 に移行し、今のところは問題ありません。
データセンターの経験がある人は、Hetzner がここでマザーボード供給元とどのような商業的な解決をしたのか推測できるだろうか？
すべてのマザーボードを無償交換し、さらに補償まで受けたと見るべきなのだろうか？
補償は事前に交渉していた場合に限って可能で、その場合は追加費用を払う必要がある。ダウンタイムの費用をベンダーから回収しようとするより、事業中断保険のようなものを買うほうがよい可能性が高い。たとえベンダー側の過失であっても同じ
Hetzner は一般の顧客ではない。極端なコスト最適化の一環として最も安い部品を買っている可能性が高く、保証なしでさらに低い価格を交渉していたかもしれない。そうであれば、交換用マザーボードを自前で買う必要があったはず
ドイツでサッカーのワールドカップが開催されていた時期だった
データセンター運営者が電力制約のためにサーバーごとの消費電力を制限し、それがマザーボードの劣化をより早める可能性があるという話は初めて聞いたので、かなり驚いた