More Related Content Similar to qpstudy 2014.04 ハードウェア設計の勘所 Similar to qpstudy 2014.04 ハードウェア設計の勘所 (20) More from Takeshi HASEGAWA More from Takeshi HASEGAWA (20) qpstudy 2014.04 ハードウェア設計の勘所2. @hasegaw is 誰
長谷川 猛 (HASEGAWA Takeshi)
twitter: @hasegaw
前職時代
・SEとしてシステム構築、客先のシステム運用、提案
・気付いたらプリセールス∼PM担当SE
(ざっくりデザイン、工数/導入物品見積もり、
構築プロジェクトの管理、保守等の問い合わせ対応)
現職
・フラッシュを軸としたアプリケーション高速化を支援する
セールスエンジニア
14. NUMA ‒ AMD と Intel
Quick
Path
Interconnect
(Intel)
Hyper
Transport
(AMD)
16. プロセッサーのスペック
• コア数/クロック周波数
• みんな認識してる(よね?)
• インターコネクトの数
• 幾つのプロセッサとNUMA構成を組めるか
• メモリチャンネル数
• CPUが認識できるDIMM数には限りがある
• 3 4[channel] = 12[DIMM per CPU]
• その他制限は後述
• PCI Express レーン数
• CPUあたりのPCI Expressレーンは有限資源
• 40 lanes per CPU、ただし自由には使えない
• PCIeスロットの使い方は重要
30. PCIe Native Flash
• フラッシュはDRAMより低速
– だが10年前のDIMMに匹敵する帯域幅
– 再起動してもデータが消えない
– しかも安い
0.0GB/s
2.0GB/s
4.0GB/s
6.0GB/s
8.0GB/s
10.0GB/s
12.0GB/s
14.0GB/s
16.0GB/s
Bandwidth
Bandwidth
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
0
500000
1000000
1500000
2000000
2500000
4
GB
8
GB
16
GB
32
GB
365
GB
Flash
785
GB
Flash
1205
GB
Flash
定価
/GB
31. 帯域幅の比較
0.0GB/s
2.0GB/s
4.0GB/s
6.0GB/s
8.0GB/s
10.0GB/s
12.0GB/s
14.0GB/s
16.0GB/s
ioDrive2
ioDrive2
Duo
PC2-‐2700
PC2-‐3200
PC3-‐6400
PC3-‐10600
PC3-‐14900
Bandwidth
Bandwidth
32. バイト単価
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
0
500000
1000000
1500000
2000000
2500000
4
GB
8
GB
16
GB
32
GB
365
GB
Flash
785
GB
Flash
1205
GB
Flash
定価
/GB
36. PCIe Flashのまとめ
• 年々、ワークロードのデータ量は増加傾向
• DRAM+Flashのティアリングは、今後、 必要 に
• もはや 容量 はDIMMで賄う領域ではない
• 大容量のDIMMは高価
• プロセッサのスロット数制限があり
小容量のDIMMを並べるのは不可能(or高価)
• DIMM 256GBぶんの価格で
128GB DRAM+400GB Flashの構成が視野に
• スピード面でも、PCIe Flashは
10年前のDRAMクラスの帯域幅
• 10年相当と言え、ディスクと比べれば明らかに速い
52. ハードディスクドライブ (HDD)
• 50年以上に渡り使われてきたストレージ
– 磁気的にデータを読み書きする
– ほぼ対称的なリード/ライト性能
– 円盤状のメディア、ヘッドでデータを読み書き
• 複数のモデル
– SATA (デスクトップ用など)
– Nearline (Near on-line) SATA (NASなど)
– SAS (サーバ用などで高速)
• トレンド
– 小容量・高速性を求める場合はフラッシュへ
SAS HDDは今後消えていくのでは
– 大容量のSATAが中心に
59. RAID 0とRAID 1
引用元
hYp://ja.wikipedia.org/wiki/RAID
複数のデバイスで性能を引き上げる。信
頼性は犠牲に(メンバの故障=停止)
同一内容を複数デバイスに書き込み信
頼性を引き上げる。
60. RAID 01とRAID 10
引用元
hYp://ja.wikipedia.org/wiki/RAID
RAID-‐0とRAID-‐1を組み合わせた構成。
組み合わせ方によりRAID-‐10とRAID-‐01の2パターンがある
61. RAID 5とRAID 6
引用元
hYp://ja.wikipedia.org/wiki/RAID
3台以上のディスクで、分散パリティを保存することでメンバデバイスの故障に備える。
RAID-‐5は1パリティで1デバイスの障害、RAID-‐6の場合は2パリティで2デバイスの障害に
耐える。パリティの再計算が必要となるため書き込みが遅くなる傾向にある
62. RAIDの種類まとめ
• RAID-0
– 複数デバイスで性能を引き上げる。信頼性は低下
• RAID-1
– 複数デバイスに同一内容を置き、信頼性を上げる
• RAID-5
– 3本以上のデバイスのうち1本にパリティを持つ。
1本のデバイス故障から保護できるが低速
• RAID-6
– 4本以上のデバイスのうち2本にパリティを持つ。
2本のデバイス故障から保護できるがさらに低速
• その他のパターン
– RAID-10, RAID-01, RAID-50など
65. アレイコントローラとは
• RAIDカードなどとも呼ばれる
– 複数のHDD, SSDを束ねてRAIDを構成、
ひとつのストレージ装置と見せかける
– パリティ計算などをハードウェアで支援
– 不意のシステム電源断時に書き込みデータを保護
• ストレージの信頼性を確保する上で大事
– RAID-5/6を使つもりなら必ず装備しよう
• Write hole/Partial write issue
– バックアップ付ライトバックキャッシュを必ず装備
• ライトスルーだと、多くの場合、手許のPCよりI/Oが遅い
• RAID機能を持たない ホストバスアダプタ
– SATAインターフェイスなどとも呼ぶ
– 安物RAIDカードは実体がホストアダプタで、
ドライバでRAID機能を実装している場合もあり注意
66. ライトスルーとライトバック
• ライトスルー (Write Through)
• ストレージへの書き込みを必ず行い、書き込みが成功
した後に「成功」と返す
• 書き込み要求をキャッシュしないため、データ喪失の
リスクは少ない
• サーバーのディスクは、ライトスルーだと手許のパソ
コンよりも遅い
• ライトバック (Write Back)
• ストレージへの書き込み要求をキャッシュし、書き込
み前に「成功」と返す
• ストレージへの実際の書き込みは後ほど非同期で行う
• BBWC/FBWCがあれば安全、なければ危険
67. RAIDカード
ライトスルー
ミドルウェア
(MySQLなど)
ディスクアレイ
ライトバックキャッシュ (DRAM)
書き込み要求はそのまま
ストレージに伝えられる
70. ライトバック、BBWCとFBWC
ミドルウェア
(MySQLなど)
RAIDカード
ディスクアレイ
ライトバックキャッシュ (DRAM)
BBWC
ライトバックキャッシュの
DRAMに電源を供給
しつづけるバッテリ
・バッテリが劣化する
・時々再充電が必要
・数日しか持たない
FBWC
電源断が発生したら
不揮発のフラッシュメモリに
データをコピーし保護
・フラッシュには利用回数
制限があるが、寿命は
無視できる程度
・BBWCと比べて堅い
書き込み要求があったら、書い
たことにする
遅延
書き込み
72. まとめ: ストレージ(不揮発層)
• 今なら
– 容量重視 -> HDD
– 性能重視 -> SSD
– RAID使うならH/Wコントローラ買っとけ
• ライトバック バックアップキャッシュも付けとけ
– なんちゃってオンメモリ -> PCIe Flash
• メモリの話題として話した
– RAID+SSDベースのPCIe Flash
• RAIDカードとSSDが一枚に収まってる
75. リモートマネジメント
• 実装
– IPMI ‒ 業界標準の管理インターフェイス
– ベンダ固有のマネジメント機能
• できること
– シリアルコンソール/IP-KVM
– リモートからの電源制御
– 温度/ファン状態/消費電力量などの監視
• 機能があるなら活用したほうがいい
– いちいちサーバルームで作業する必要が減る
– ソフトウェア的な管理が可能に
77. 保守スキーム
• 規模が小さければオレオレ保守かもしれない
• 激安サーバ程度ならこの方針でもよいでしょう
• HDD/SSD程度なら秋葉で買ってきたほうが安い
• 「わかってる人間」がいないとできない
• 「直る」と思ってたものが直らないとつらい
• 台数が増えてくるとトラブル件数も増え、個別対応はつらい
• ある程度の時点でベンダー/リセラー保守を利用
• コストをキャップしやすい
• 切り分け/予備パーツ/代替パーツの手配に時間をとられない
• ハードウェアの保守作業時間、そのためのトレーニング時間が不要
• 台数が異常クラスになるとオレオレ保守へ
• 数千台∼の規模になると保守費用払うよりオレオレ保守したほう
がよいことも多い(のではないか)