昨日InnoDB Clusterの推奨スペックがセミナーで発表されましたが
上司がクラウド嫌いとかDBサーバはどう考えてもオンプレだ！とか
減価償却とか考えられる人のために推奨スペックを提示します
おそらくクラウドとPostgreSQLにも通じます。
最近のマイクロサービス化とは逆行したスペックになりますので
松よりも梅～竹のインスタンスを並べる方がいいのかもしれません。
ケース
必須 2CPU搭載可能、HDDかSSD(2.5インチ)が6台以上、1GNICx4
推奨 2CPU搭載可能、NVMeでSSDが4台以上搭載できるサーバ
CPU
NUMA問題というのがありMySQL5.7ではパラメータが追加されるほどです。
LinuxのカーネルでもNUMAのパラメーターが追加されたり苦労が伺えます。
そのためできる限り1CPU多スレッドが求められます。
また、XZをバックアップで使うのにも多スレッドが有利です
梅 1CPU16スレッド
将来InnoDBが確実にスケールする(2CPU)32スレッドまでを想定
竹 1CPU32スレッド
InnoDB Clusterが32～64スレッド推奨なので(2CPU)64スレッドになるように。
最新DBでも64スレッドくらいが性能が伸びる限界のようです。
松 1CPU36スレッド～(理想は64スレッドだがまだ存在しない）
InnoDB Clusterが32～64スレッド推奨なので1CPU64スレッドが理想。
メモリ
NUMA問題があるためできる限り1つのCPUに集中して載せましょう
梅 CPUスレッドに対して2～4倍
見ているとCPUに対して2～4倍を搭載するところが多いようです
竹 CPUスレッドに対して4倍～
松 0.5TB～(まだ存在しないが3D XPointをメモリ代わりにも）
ディスク
MySQLでFusion-IOにすると劇的に早くなることからディスク性能が如何に大事かわかります。
全部メモリにデータを載られるのが理想ですがbuffer_poolは色々使われるのでデータはその1/3以下でやっと乗り切るくらいでしょうか
ディスク性能を上げていくほうが堅実です。
また、MyISAMでならRAMDISKにTMPを置けますが5.6.29/5.7でないとALTER TABLEが失敗する
巨大なTMPを作ると容量不足で失敗するなど注意が必要です。
MyISAMでならRAMDISKにTMPを置けますが巨大なTMPを作ると容量不足で失敗します。
それなりのNVMeクラスタになっているのでしたらrelayをRAMDISKに入れることもあるようです。
またストレージを分けるならバイナリログを出力するスレーブのデータの流れが
書き込み：relay→bin→REDO
↓→UNDO
↓→(非同期)本体
読み込み：buffer→本体
となっているためrelay、bin、UNDO、TMPとREDO、MySQL本体でしょうか。
梅 SSD(2.5インチ)でRAID5/10+ホットスペア[+バックアップHDD]
できるかぎりRAID5+ホットスペアの4台を推奨します。
容量が比較的小さいので性能と容量効率がいいRAID5か
RAID5より性能がよくSSDが2台壊れても稼働できる可能性のあるRAID10が悩ましいですが
即交換対応できる運用ならRAID10がいいかもしれません。
この場合はSSDの中でOSとMySQL領域は分けるべきです。
バックアップにはランダム性能が不要なのでHDDで十分です。別サーバのHDDでもいいですが複数箇所バックアップしましょう。
H/WでのRAIDよりもMDによるRAIDの方が性能は出ます。
SSDRAID(MySQL)とバックアップHDDとRAIDカード1枚よりもリッチな環境にするのであれば竹にすべきです。
竹 (出来る限りホットスワップ可能な)NVMe2台+RAID1HDD
NVMeもホットスワップでるのがあるのでそちらを選ぶべきです。
NVMe用RAIDカードは存在しなくMDRAIDでRAID1が多いようですが
NVMeによっては内部完全二重化されているため1台で運用しているところもそれなりに聞きます。
しかし、そこそこの台数がないとNVMeが故障したら即停止させて交換対応となるため
NVMeを2台用意しRAIDは組まずrelay、bin、UNDO、TMPとMySQL本体を分けて格納し
故障時は緊急の措置として片方に寄せましょう。
binlog_error_action=ABORT_SERVER
を設定していればMySQLは片方のNVMe障害で停止されるはずです(要検証)
RAID1HDDはOSとバックアップ格納です。
発熱、容量、速度、耐障害性のために4台NVMeを用意できるならMDでRAID5+ホットスペアを組んでしまうのもいいでしょう。
逆にRAID1は容量、速度とNVMeの利点がなくなりかねないので推奨はしません
松 スケールアウトかもうクラウド
竹で性能か容量が足りないとなるとサーバを分けるかものすごい値段のSANかクラウドにするしかありません。
さすがにものすごい値段のSANは推奨しかねます。
また、容量でも13TB以上必要になる場合NVMeのRAIDでは難しいので
サーバを分けるかものすごい値段のSANかクラウドにするしかありません。
補足：ファイルシステム
複数スレッドでの同時書き込みができるため
NVMe以上の性能ではXFSにすべきです。
ただし、XFSはメモリを他より消費します。
ext4は次点になりますが高速な暗号化機能があります。
NW
上流含めて完全2重化をしましょう
梅 1Gbps x4
bondingないしは802.3adで構成しましょう
受信パケットをLinuxでは普通1CPUで処理してしまうために分散処理させましょう
CentOS 6.2 で RPS/RFS を使ってネットワークの割り込み処理を複数コアに分散してみた
APPサーバからのリクエストとレプリケーション、メンテのトラフィックを分離しましょう。
また検証はきちんと行いましょう
竹 Receive Side Scaling (RSS)対応1Gbps x8
RSS対応かメーカーに問い合わせてRSSで処理させてしまったほうが楽です。
802.3adで構成し、検証はきちんと行いましょう。
松 Receive Side Scaling (RSS)対応NBASE-T x4 + 1Gbps x2
NBASE-Tがようやく出てきました。
10Gbpsにするなら銅ケーブルはレイテンシとエラーが悪いと聞くので光を推奨。
10Gbpsだと超低レンテンシな世界があり効果もあるそうですが1台にトラフィックがそこまで必要でしょうか。
メンテのトラフィックは1Gbpsの802.3adで十分でしょう
欄外：OS
梅 CentOS7
SSDに特化したMQもバックポートされ CnetOS6と同じくMySQL5.5以降サポートされているのでオススメです。
MySQLサーバはほぼミドルウェア入れないのでCentOS7でも大して困らないでしょう。
なお、CentOS7.0の安定性、7.2へのアップデートは問題があるので最初から7.2以上にしましょう。
DAXサポートは7.3です。
竹 Ubuntu16.04
kernel4.4(～21年4月) 4.10(～17年10月)
世界で一番シェアがあるので説得しやすいです。
kernel3.18、4.4からNWのパフォーマンスがあがり
4.1ではMDのRAID5でパフォーマンスがあがります。
バックエンドのDBサーバにはあまり必要ないかもしれませんが
4.0からはライブアップデートにも対応できます。
MySQL5.6に公式が対応していないのが難点
もしMDでRAID5にするのであればkernel4.11以上を推奨します。
松 Debian9
kernel4.9採用
日本ではシェアがないので使いにくいかもしれませんが
シェアは世界2位です。
kernel4.9を採用しておりそのまま一番性能が引き出せます。
またOSも安定志向が高いです。
4.7ではPostgreSQLへの改良が入っておりMySQLにも期待できます。
Ubuntuと違いMySQL5.6にも公式が対応