Webサーバの製作

Webサーバを比較的安価で高速なデスクトップPCで作ってきたが、信頼性では少し物足りなく、ECCメモリの必要性を痛感するようになった。 サーバ用のCPUは高価なものが多く、CPUだけで100万円を超えるものがざらにある。 ECCメモリも一般のメモリより高価で、ゲームやネット検索などの一般利用では無用の長物であり、高速になるほど値段も高く、一般メモリのほうが速度性能は高い。

このようなことを考えると、ECCメモリを必要とする特殊な場合のみECC対応にすることが経済的であることがわかる。

しかし、商用サーバとして信頼性の高いサーバを提供するためにはECC対応は不可欠である。 最近のgoogle発表の研究では、以前思われていたよりも非常に高い確率でメモリエラーが発生しているとのこと。 原因は宇宙からの放射線（宇宙線）の影響が大きく、高度が上がるにつれ顕著に増大するらしい。

メモリエラーの影響が出るのは実際にCPUが参照する一部のメモリ部分だけなので、意外と異常停止が起きるのは稀だ。 しかし、データ領域に蓄積し、間違った情報を出力する可能性はある。 膨大なデータの中のほんのわずかなので、いままで見逃してきた可能性は高いだろう。

我々は、暗号ソフトの開発研究も行っているが、メモリエラーは深刻な問題を引き起こす。 また、高精度数値計算分野の研究も行なっているが、少しでも誤りの原因を取り除くことは重要だ。 さらに、顧客対応の信頼性を謳うサーバならば、なおさらだろう。

Webサーバの仕様

RAID10について

信頼性を重視し、ECC以外にRAID10を導入した。RAID1とRAID0の複合システムである。 RAID1はミラーリングと呼ばれ、同じデータを2つ所持し、片方にデータ欠損が起きても修復できる。 RAID0はデータ分散高速化機能であり、複数の記憶媒体に分散してデータ保存し、処理速度を高速化する。 RAID1で低速になったものをRAID0で補う優れた処理方法である。
RAID1とRAID0の順番は決まっている。まず、RAID1でミラーリングを行なうファイルシステムを複数構築し、その上にRAID0の分散システムを構築する。 そのため、最低4枚のSSDが必要になる。今回は8枚のSSDを使ったため、4つの記憶媒体に分散して保存することになり、より高速になっている。
今回、HighPointのRAIDコントローラーを使用し、ハードウェアRAIDと書いたが、本当にハードウェアRAIDなのかいくらか不安に思っている。 何故なら、OS側にドライバーをインストールする必要があり、インストールしなかった場合、個々のSSDがBIOS画面で見えるからである。 OSにインストールし、RAID10構成をセットアップすると、BIOSで一つの記憶媒体として認識されるようになる。 ソフトウェアRAIDがいくらか混じったハードウェアRAIDのような気分がする。
最近のマザーボード自体にRAID機能が用意されるようになってきたが、かなりソフトウェアRAIDに近いらしい。 ソフトウェアRAIDはCPUの負荷が大きく、ハードウェアRAIDはCPUの負荷が少ない。 しかし、最近はその中間のRAIDが普及しつつあるように感じており、ハードなのかソフトなのか判然としない。 HighPointのRAIDコントローラーはかなりハードウェア寄りだろう。 今後発売されるマザーボードでは、かなりハードウェアRAIDに近いものができるようになるだろうと思っている。 しかし、マザーボード自体のSSD設置可能枚数は少ないので、当分の間、RAIDコントローラーは必要だろう。

OSの保存場所について

OSはSSDに置き、重要データをRAID10で保存することにした。 OSをRAID10に置くこともできるが、ハードウェアRAIDが故障したときに対処困難に陥るので、安全性を重視した。 ハードウェアRAIDの安全性はかなり高いので、OSをRAID構成にすることも普及しつつあるが、今は様子見というところ。

SSDとHDDの役割およびバックアップについて

以前の古いタイプのSSDはHDDと同様の取り扱いだったが、M.2 SSDはマザーボードに直接差し込む仕様になっている。 I/O速度も以前とは比べ物にならないほど高速化され、HDDを使う意味がなくなりつつある。 しかし、HDDよりも高額なので、利用頻度の少ないデータまたは長期記録保存用のデータはHDDで良いかもしれない。 （年々、M.2 SSDも安くなってきているので、HDDの利用価値はますますなくなっていくように感じている。） SSDは同じメモリセルに100回書き込みすると壊れると昔は言われていたが、最近は1000から1万回まで寿命が延びたようだ。 しかし、寿命が来ると壊れる。定期的バックアップは重要である。 HDDもしくはその他のバックアップ媒体に記録保存しながら管理する必要があるだろう。

日本製は？

ところで、SSDは日本製を使っている。日本人である我々は極力日本製を使いたい心情があるが、その他の製品はほとんど海外製である。 日本製で安くて良いものがあれば導入したいが、残念ながらそれは難しい状況が続いている。 CPU、HDD、水冷クーラーは米国、マザーボード、メモリは台湾、RAIDコントローラーは中国となっている。

ECC対応について

ECC対応を公式サポートしているCPUは、AMD EPYC、Threadripper、Intel Xeon。非公式にAMD RyzenがECCをサポートしているらしい。 （どこかのサイトにあったが、参照先が現在行方不明） Intel CoreシリーズはECC対応と記述してあるものがあるが、どうも公式でも非公式でもサポートしていないらしい。 非公式サポートのAMD Ryzenは、ECCメモリの認識と修正機能は正常動作するようだが、正式ではないため、十分な機能がそろっていないかもしれない。
今のところ、AMD RyzenでECCは十分機能しているように思える。 おそらく、修正不能ECCエラー（マルチビットエラー）が検出されたとき、CPUの自動停止機能がないのかもしれない。 しかし、それは大した問題ではないだろう。 OS側で修正不能エラーを検知したとき、再起動シークエンスを開始する何らかのシェルスクリプトを用意すればよいだけだ。（たぶん）
AMD Ryzen 7000シリーズを使いたかったが、対応するddr5 ECCメモリを探すのに苦労している。そのため、今回は5000シリーズとなった。

ECCエラーは、CPUがそのメモリアドレスを参照したときのみ修正される。 それゆえ、広大なメモリ空間のどこかにメモリエラーが発生しても、参照されない限り、修正されないまま残されることになる。 修正できるのはシングルビットエラーのみだが、そのまま放置すると、同じアドレスに再度エラーが発生し、マルチビットエラーになる可能性が高まる。 マルチビットエラーは修正不能なので、致命的エラーを引き起こす。
メモリスクラビングは、このような問題に対処する機能であり、すべてのメモリを走査し、ECCエラーを検出、正しいデータに書き換えることを行なう。 かなり負荷のかかる処理なので、サーバが混雑していないとき、もしくは決められた時間に動作するよう設定される。 このメモリスクラビングにより、半永久的に動作させるサーバや重要な計算を長時間行うワークステーションの高い信頼性を実現できるようになる。 （参考：ECCメモリについて)

メモリスクラビングはBIOSで設定するようになっている。どうもOSサイドでは設定できないようだ。
今回利用したマザーボードではBMCチップが無いため、IPMIが使えない。 CPUに負荷のかかるメモリスクラビングをIPMIで処理すれば、CPUの負荷を大幅に減らせることが可能なのだが、それができないのはいくらか不満である。 今後の検討課題にしたい。

追伸 (2023/4/18)

一見するとECC対応になっていると思っていたが、不安要素が出てきた。 2週間近く運用しているが、まだ一度もECCエラーを検出していない。そんなことってあるのだろうか？

Mestest86の技術情報で、 「AMD Ryzen システムで ECC エラーが報告されないのはなぜですか? BIOS 設定のPlatform First Error Handling (PFEH)が原因で、ECC エラーが MemTest86 に報告されない可能性があります。 ・・・・この設定が有効になっている場合は、無効に設定し・・・・」 とある。BIOS設定にPFEH項目が無いので困惑している。

やはり、正式サポートでなければダメなのだろうか？

今後の方針

RyzenよりもEPYCの方がサーバとしては好ましい。 Unbuffered ECCからRegistered ECCへの変更も必要だが、古いEPYCはかなり安く入手できるので、できるだけ安価にEPYCサーバを作ることにした。
進展があれば報告する予定。

追伸（2023/6/2)

EPYC 7443P 24-Core 48-Thread CPUを購入し（20万円ぐらい）、Webサーバを構築しました。 ECC対応ですが、2週間稼働でECCエラーはまだ未検出。
メモリのオーバークロック状態でストレステストをすると、強制的にECCエラーを起こすことができるらしい。 しかしながら、今回購入したEPYC用マザーボード(SuperMicro H12SSL-CT)にはメモリのオーバークロックがサポートされていなかった。 そのため、EPYCサーバでのECCエラー強制引き起こしは断念しました。 前回製作のRyzenサーバは、現在、本サイトのメインサーバとして利用しているため、ストレステストによるシステムクラッシュは避けたい。 ということで、ストレステストによるECCエラー強制検出はしばらく延期することにしました。

作成日:2023.04.10 更新日:2023.06.02