狠狠撸

狠狠撸Share a Scribd company logo

さくらのクラウドインフラの绍介

?
?
SAKURA Internet Inc.
SAKURA Internet Inc.
1 of 63
贰狈翱骋18発表资料 さくらのクラウド インフラの紹介 さくらインターネット（株） 研究所 大久保 修一
免責事項 ? 「会場のみ」と記載しているスライドについては、一部数値 等を伏せさせていただいております。ご了承ください。 ? 資料中の性能値は、発表者個人の経験に基づくものであ り、弊社の公式見解ではありません。また、製品やリビジョ ンによって異なる場合がありますので、利用者自身におい て確認をお願いします。 ? この資料は、資料作成時における最新情報をご参考のた めに提供することを目的として記載されており、弊社は情 報の正確性、完全性または有用性について何ら保証する ものではありません。また、内容は予告なしに変更または 更新されることがあります。 ? この資料の情報に基づいて導入?設定?運用した結果につ いて、弊社はいかなる保証も責任も負いかねますので予 めご了承ください。
自己紹介 ? 所属：さくらインターネット(株) 研究所 ? 氏名：大久保 修一 ? 数年後のビジネスのネタになりそうな技術の 評価、検証など – クラウド技術 ネットワーク仮想化、分散ストレージ – IPv4アドレス枯渇対策 IPv6移行技術 トランスレータ、トンネル技術(6rd、MAP他) ? さくらのクラウド、ネットワーク、新ストレージ担当
Agenda ? さくらのクラウドについて ? ネットワークの構成 ? ストレージの構成 ? まとめ
さくらのクラウドとは？？ ? いわゆるIaaSのサービスです。 ? コンセプト：開発者向けのシンプルクラウド – 物理サーバの使い勝手をコンパネ上に再現 ? 以下のコンピューティングリソースを提供 – ネットワーク – サーバ（CPU、メモリ） – ストレージ
さくらのクラウドとは？？ http://cloud.sakura.ad.jp/
例：サーバリソースの一覧
例：ネットワークリソースの一覧
システム全体像 インターネット ルータ コントロール パネル L2スイッチ等 L2ネットワーク ホストサーバ API(REST) クラウド ストレージ コントローラ L2スイッチ等 ネットワーク 課金システム ストレージ
仮想インフラの概要 ? サーバの仮想化 – qemu/KVMを使用、現在CentOS6.2ベース。 – 生のqemuをそのまま利用(libvirtも使っていない) ? ネットワークの仮想化 – VLANを用いた論理分割 – 仮想スイッチはOpen vSwitchを利用 ? ストレージの仮想化 – 論理ボリューム、iSCSIによる接続 ? コンパネ、API、コントローラ、課金システム – 完全自社開発
ネットワーク编
仮想システムプロビジョニング例 このようなシステムを、IaaSインフラ上に展開してみる インターネット VPN VLAN101 VLAN102 ルータ FW VLAN106 VLAN103 LB VPN VLAN104 Webサーバ Webサーバ VLAN105 コントローラにて VLANを自動割り当て DBサーバ DBサーバ
クラウド上に配置したシステム インターネット VPN L2網(コアスイッチ、エッジスイッチ、仮想スイッチ) VLAN101 VLAN102 VLAN103 VLAN104 VLAN105 VLAN106 仮想スイッチ 仮想スイッチ 仮想スイッチ ルータ FW LB WEB WEB DB DB VPN ホストサーバA ホストサーバB ホストサーバC VMはどのホストサーバ上に配置してもよい
仮想ネットワークトラフィックフロー インターネット VPN ルータ FW LB VPN Webサーバ Webサーバ DBサーバ DBサーバ
物理トラフィックフロー インターネット north-southトラフィック コアスイッチ、エッジスイッチを ルータ トラフィックが何往復もする east-westトラフィック VMの収容ホストに依存 コアスイッチ エッジスイッチ エッジスイッチ 仮想スイッチ 仮想スイッチ 仮想スイッチ DB LB ルータ Web FW ホストサーバA ホストサーバB ホストサーバC
现在の尝2ネットワークの构成 ルータへ 10GbEスイッチ 10GbE×8 （コアスイッチ） 10GbE×4 Ethernet InfiniBand 変換装置 L2網 IB 40Gbps IBスイッチ群 InfiniBand QDR(40Gbps) ホストサーバ群
VLAN数の制限 ? VLAN ID数の不足(12bit≒約4,000VLAN) – 1ユーザあたり10VLANとして、400ユーザが上限 ? ロジカルポート数の不足(次ページで説明) ? 装置によって扱えるVLAN数に制限がある ケース ? 弊社では当初2,000VLANをデプロイ
参考：ロジカルポート数の不足 L2スイッチ 40ポート 4,000VLAN 4,000VLAN 4,000VLAN 4,000VLAN 約4,000×40ポート =約160,000ロジカルポート必要 ロジカルポート数が12,000や24,000の制限があるスイッチがある
MACアドレス数の制限 ? MACテーブルエントリ数 – ハッシュコリジョン問題(次ページで説明) – Internalで消費されるMACアドレス – 実質、カタログスペックの半分くらいしか使えない – 弊社での要件は16,000エントリ
参考：ハッシュコリジョン问题 同じハッシュ値をとる５つ目のMACアドレスが 来ると学習できない 4段の例 ハッシュ値1 gg:gg:gg:gg:gg:gg hh:hh:hh:hh:hh:hh ii:ii:ii:ii:ii:ii jj:jj:jj:jj:jj:jj ハッシュ値2 ハッシュ値3 ハッシュ値4 VMに割り当てるMACアドレスをランダムにすることで、 コリジョンの可能性を減らすことができる
L2網のスケーラビリティ確保 VLAN数制限、MACアドレス数制限により、 基本的に網を分割していくしかない。 分割されたL2網間を接続する仕組みが別途必要 VLAN ID変換装置 802.1Q + LAG 802.1Q + LAG コアスイッチ コアスイッチ L2網#1 L2網#2
余談：OUI取得しました http://standards.ieee.org/cgi-bin/ouisearch?9C-A3-BA 他のクラウドや他の物理ネットワークとの L2レベルでの相互接続も問題なし！
ルータの构成 ? 以下2種類のインターネット接続を提供 – 共有インターネット接続（最大100Mbps） – ルータ＋スイッチ（100M、500M、1Gbps） ? ARPテーブル – VMのIPアドレス、MACアドレスを学習 – 弊社の要件は12,000エントリ程度 ? L3仮想インターフェイス数 – インターネットに接続するVLANの収容 – 冗長プロトコルのインスタンス数の制限にあたりやすい – 弊社の要件は2,000インスタンス程度 ? ルータ宛てのDoSアタックへの耐性
ルータの构成 インターネット バックボーン eBGP OSPF eBGP 冗長構成 HSRP L2網
インターネット接続构成 バックボーンルータ バックボーンルータ クラウドでプールしている eBGP eBGP 10GBase-LR アドレスブロックを集約 10GBase-LR x.x.x.x/20 x.x.x.x/20 して広報 OSPFで経路交換 エッジルータ redist connect エッジルータ redist static 192.168.1.1/29 192.168.0.1/29 192.168.0.2/29 192.168.1.2/29 OSPF VLAN101 VLAN100 VLAN100 VLAN101 動的にL3インター フェイスを追加 10G VRRP等 10G VLAN101 VLAN100 VLAN100 VLAN101 コアスイッチ コアスイッチ
仮想スイッチの構成 ? ホストサーバ上で動作し、物理ネットワークと VM間の通信の橋渡しを行う。 ? VM向けにフィルタ設定が必要 – MACスプーフィング対策、ARPスプーフィング対策、 – IPスプーフィング対策 – お客様指定のパケットフィルタ ? 仮想ポートでの帯域制限 ? 物理IFの冗長性はbondingにて対応 ? さくらのクラウドではOpen vSwitchを使用
仮想スイッチの実装方法 IB Ether変換 IB Ether変換 InfiniBand(QDR) ↑L2網 ↓ホストサーバ vnic1 vnic2 802.1QタグVLAN bonding VLAN 2～2000 Open vSwitch (br0) VLAN100 VLAN300 VLAN1200 VLAN1001 tap0 tap1 tap2 tap3 VM1 VM2
Open vSwitchのボトルネック ? DoSアタックなど、大量のフローが発生すると、 転送性能が極端に低下する ? 同一ホストの別のお客様のVMに影響が及ぶ ? 弊社で実施した対策 – 新しいバージョンを使用する – ガベージコレクション開始の閾値を変更 (1,000?120,000) – フロー数監視?異常な通信の検出
参考：Open vSwitchのアーキテクチャ デーモン ovs-vswitchd ← CPU負荷が上昇 （ユーザランド） ?未使用エントリは最大5秒間キャッ 一旦すべてフロー(MACアドレス、 シュ Ethertype、IPアドレス、ポート番号)に分 ?5秒以下でも、1,000エントリを超え 解し、ovs-vswitchdに問い合わせる るとガベージコレクションが始まる ?ガベージコレクションの開始タイミ ングは1秒間隔 カーネル フローキャッ openvswitch_mod モジュール シュ パケット転送処理
ストレージ编
新ストレージ導入の経緯 2012/4 2012/5 2012/6 2012/7 2012/8 2012/9 2012/10 2012/11 2012/4頃 新ストレージの開発、 2012/10/1～ 導入をスタート 既存ユーザの課金再開 2012/6/25～ 第一期iSCSIストレージの 2012/11/1～ β提供開始 新規ユーザ募集再開 （サービス正常化） 2012/8/31～ SSDプランの提供開始 第二期iSCSIストレージの β提供開始
ストレージのボトルネック ホストサーバ ストレージのキャパシティ ? IOPS ストレージネットワーク ? プールサイズ IF帯域 IF帯域 ? 帯域(MBytes/sec) コントローラ#0 コントローラ#1 コントローラの miniSAS(24Gbps) 性能 RAID-XX JBOD ストレージ 各6Gbps ディスクの性能
ストレージのボトルネック ? HDDはIOPSが絶対的に不足 – 1本のディスクを数十ユーザで共有 – 共有ストレージは難しい – 専用サーバ等では1本のディスクを1ユーザが専 有（DAS最強説？） ? その他の制限 – IF、miniSASの帯域（あまり気にする必要ない？） – iSCSIセッション数上限（1ポートあたり256セッショ ンなど）
キャパシティを左右するパラメータ ? ディスクのタイプ（SAS or NL-SAS or SATA） ? HDDのサイズ（300GB or 600GB or 900GB） ? 回転数（10Krpm or 15Krpm or 7.2Krpm） ? RAID構成（RAID10 or RAID60 or RAID50） ? ホットスペア（２～４本？） ? HDDの本数（JBODにささるきりのいい数字に） ? スナップショット領域 IO性能（IOPS） 、プールサイズ(GB)
搁础滨顿构成による违い 性能1/3 RAID10 RAID60(8+PQ) RAID50(4+P) random write IOPS N/2 N/6 N/4 random read IOPS N N×4/5 N×4/5 容量 M/2 M×4/5 M×4/5 リビルドの安全性 ○ ◎ △ 容量1.6倍 ? N=HDD1本あたりのIOPS × 本数 ? M=HDD1本あたりの容量 × 本数
収容設計の考え方（弊社の例） ? 4KiB random writeにてストレージのIOPS性能 を測定する。 ? 1ユーザあたり平均XXIOPSとして、収容ユー ザ数の上限を決定する。 ? 容量が無駄にならないように、もしくは容量が 先に頭打ちしないように各種パラメータを調 整する。 会場のみ
収容設計のイメージ 40～1024GBのユーザを最大N個詰めて、容量が余らない プールを作りたい ? ナップサック問題を解く！ 40GB 40GB 100GB 250GB 100GB 100GB 1024GB SAS XXXGB 2.5” 10Krpm XX本 RAIDXX X,XXXIOPS（最大XXXユーザ）、XX,XXXGiB 会場のみ
第一期iSCSIストレージ（HDD） ? 2012/6/25～提供中 ? 市販サーバにHDD搭載 ? IB接続 ? OS: CentOS 6.2 ? クラスタ制御: Pacemaker + DRBD ? ボリューム制御: LVM ? iSCSI Target: tgtd (scsi-target-utils)
接続构成 ホストサーバ ホストサーバ 150台 ? IPoIBによる接続 InfiniBand(QDR) ? ターゲットは仮想IP ? IB経由でデータのミラー 仮想IP ストレージ ストレージ サーバ サーバ 5セット RAID10 DRBD RAID10
RAID構成、収容ユーザ数 ? RAID: RAIDXX ? HDD: XXXGB 2.5” SAS 10Krpm × XX本 ? IOPS性能: X,XXXIOPS ? 容量: X,XXXGiB （スナップショット領域500GiB別途） ? 収容ユーザ数: 20GiB×XXXユーザ ? IOPS収容率: XX% ? 容量収容率: XX% 会場のみ
開発、運用中に生じた課題 ? パフォーマンスがでない – DRBDのバージョンを8.4から8.3にダウンすることで解 消 ? DRBDの不具合 – RHEL6系からbarrier命令に対するカーネルの挙動が 変化したことによるデータ不整合 – no-barrierに変更、Verify+再同期によって解消 – 参考情報: http://www.3ware.co.jp/aboutus/news/news- 20120911.html
運用してみた結果 ? メリット – ストレージサーバの内部まで作りこめるので、ク ラウドコントローラとの接続を好きにできる。 – ノード冗長なので、バックプレーンの故障などにも 対応できる。 ? デメリット – ノード冗長により、HDDが2倍必要になる – （RAID101） => 4冗長 – HDDのコストがかかる
第二期iSCSIストレージ（HDD） ? 2012/8/31～提供中 ? コスト削減のため、大容量ユーザ向けに商用の ストレージ製品を導入。 ? 異なる国内メーカの二機種を評価し、某N社さん のストレージを導入 ? 一般的なミッドレンジストレージ ? 10GbE接続、マルチパスによる冗長化 ? 大容量ユーザを収容 – 40,60,80,100,250,500,750,1024GiB
RAID構成、収容ユーザ数 ? RAID: RAID60（8+PQ） ? HDD: XXXGB 2.5” SAS 10Krpm × XX本 ? ホットスペア: 別途4本 ? IOPS性能: X,XXXIOPS ? 容量: XX,XXXGiB （スナップショット領域1,024GiB別途） ? 収容ユーザ数: 最大XXXユーザ ? IOPS収容率: XX% （平均XXXGiBで試算） ? 容量収容率: XX% 会場のみ
接続构成 Internet storage storage storage storage ルータ ルータ 10G×8 10G×8 VLAN-XX VLAN-YY コアスイッチ(VDX) コアスイッチ(VDX) 1/1 2/1 3/1 4/1 EoIB 1/1 2/1 3/1 4/1 InfiniBand VLAN-XX VLAN-YY VLAN-XX VLAN-YY vnic1 vnic2 vnic3 vnic4 vnic1 vnic2 vnic3 vnic4 OVS x.x.x.x y.y.y.y OVS x.x.x.x y.y.y.y VM VM VM VM
参考：マルチパス构成 ゲスト VM(qemu) VM(qemu) /dev/mapper/mpatha /dev/mapper/mpathb dm_multipath dm_multipath /dev/sdb /dev/sdc /dev/sdd /dev/sde ホスト iSCSI initiator コントローラ#0 コントローラ#1 ストレージ ストレージ ボリューム
参考：マルチパスと仮想IPの違い ? iSCSIイニシエータのタイマー値が全く異なる。 ? 仮想IPアドレスによる冗長 – ストレージの切替りの間、ユーザのIOを保留して切り 替わりを待つ。 node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 node.session.timeo.replacement_timeout = 86400 ? マルチパスによる冗長 – 即座にdm_multipathにIOエラーを返し、切替えを行う。 node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.session.timeo.replacement_timeout = 5
参考：ストレージの帯域 会場のみ 10Gbpsあれば全然問題ないくらい
SSDストレージ ? 2012/11/1～提供中 ? 第一期iSCSIストレージと同じアーキテクチャ – 市販サーバ＋DRBD＋IPoIB ? HDDをSSDに換装 ? Intel SSDXXX XXXGB XX本 ? ホットスペア: 2本（SSD Guard、後ほど詳細） ? 1セットあたり100GiB × XXユーザ収容 会場のみ
SSDとHDD、単体の性能比較 HDD 転送帯域: 150MB/sec IO性能: 300IOPS latency: 5ms SSD 転送帯域: 550MB/sec IO性能: 50,000IOPS latency: 0.1ms
弊社で公开しているベンチ结果 仮想サーバから测定
仮想化ドライバの比較 ? qemuには、IDEとvirtioの2種類が存在 ? IDE – 1並列でしかIOを出せない（NCQのような仕組みを 提供していない） – 実質QD=1 ? virtio block – 複数IOを並列で出せる – デフォルトではQD=32（iSCSIイニシエータに依存） ? SSDはvirtio利用を前提
厂厂顿ストレージサーバボトルネック IPoIB処理が複数 ホストサーバへ 会場のみ コアに分散しない read write iSCSI Target(IPoIB) X万IOPS LVM serializeされる DRBD X万IOPS RAIDカード(RAID0) XX万IOPS XX万IOPS SSD SSD SSD XX本 X万IOPS×XX X万IOPS×XX (XXX万IOPS) (XX万IOPS)
SSDのEndurance管理 ? SMART情報の監視 @sac-is1a-iscsi4-st01a Enc Slot ID DG RAID E8 E9 Firmware state 11 0 8 0 1 100 100 Online, Spun Up 11 1 9 0 1 100 100 Online, Spun Up 11 2 10 1 0 100 100 Online, Spun Up 11 3 13 1 0 100 100 Online, Spun Up 11 4 14 1 0 100 100 Online, Spun Up <snip> ? SSD Guard – LSI社の技術 – RAID0ボリュームで、SMART情報より壊れそうなSSDの データをホットスペアにコピー
ストレージ以外のチューニング ? ユーザからのIO負荷制限 ? IOスケジューラ ? ページキャッシュ ? アライメントの整合性
ユーザからのIO負荷制限 ? iSCSIで見えるブロックデバイスに対して cgroupを掛けている ? 一部QDを制限 会場のみ ストレージ IOPS BW QD read write read write HDD IDE XXXX XXXX XXXMB/s XXXMB/s 実質1 HDD Virtio XXXX XXXX XXXMB/s XXXMB/s XX SSD XXXX XXXX XXXMB/s XXXMB/s 実質4
多段滨翱スケジューラの苦悩 プロセス FS iSCSI target pagecache ゲスト(QEMU) pagecache block device block device scheduler scheduler(deadline) IDE LVM ストレージ DRBD RAID card pagecache block device minisas ホスト scheduler(CFQ) HDD/SSD iSCSI initiator iSCSI
ホストサーバのページキャッシュ ? Linuxはブロックデバイスに対して4KiB単位でメモ リにキャッシュする?一見よさそうだが？ ? cgroup(IO制限)が意図通りに動かない – cgroupはページキャッシュの下で動いている ? 性能が安定しない – ホストサーバのメモリが減ると遅くなる – メモリが少ないVMプランでもIOが爆速 – ユーザの不公平感がある ? 4KiBアライメントずれによる性能劣化 ? ページキャッシュは使わない（cache=none）
アライメントのミスマッチ ? 古いOSでは、パーティションが63セクタ目から始 まっている。 ゲストのファイルシステム（4KB単位） ゲストの仮想ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74 ホストのページキャッシュ（4KB単位） ストレージの物理ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74
アライメントのミスマッチ ? ページキャッシュをバイパスすれば問題ない ゲストのファイルシステム（4KB単位） ゲストの仮想ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74 ホストのページキャッシュ（4KB単位） ストレージの物理ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74
础贵罢、厂厂顿でも同様の问题が再现 ゲストのファイルシステム（4KB単位） ゲストの仮想ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74 物理ディスクの論理セクタ（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74 物理ディスクの物理セクタ（4KB単位） ↑AFT、SSDの場合（ディスクの内部で処理）
今後取り組みたい課題 ? HDDへのIO負荷低減対策 – 小容量のHDDストレージをSSDで実装 – 階層化ストレージ、シンプロビジョニング、その他 ? データバックアップ処理の改善 ? iSCSIセッション制限の克服
まとめ ? ネットワークの使用帯域はどんどん増える。 増速によって対応。L2ネットワークのボトル ネックは、将来的にSDN的なソリューションに よって解消を図りたい。 ? ストレージIOは、HDDを使う限り最初から「詰 んでいる」状態。ゲストとストレージ間の中間 層の最適化、SSDの導入などで、負荷低減、 オフロードを図る必要がある。

More Related Content

さくらのクラウドインフラの绍介

  • 1. 贰狈翱骋18発表资料 さくらのクラウド インフラの紹介 さくらインターネット（株） 研究所 大久保 修一
  • 2. 免責事項 ? 「会場のみ」と記載しているスライドについては、一部数値 等を伏せさせていただいております。ご了承ください。 ? 資料中の性能値は、発表者個人の経験に基づくものであ り、弊社の公式見解ではありません。また、製品やリビジョ ンによって異なる場合がありますので、利用者自身におい て確認をお願いします。 ? この資料は、資料作成時における最新情報をご参考のた めに提供することを目的として記載されており、弊社は情 報の正確性、完全性または有用性について何ら保証する ものではありません。また、内容は予告なしに変更または 更新されることがあります。 ? この資料の情報に基づいて導入?設定?運用した結果につ いて、弊社はいかなる保証も責任も負いかねますので予 めご了承ください。
  • 3. 自己紹介 ? 所属：さくらインターネット(株) 研究所 ? 氏名：大久保 修一 ? 数年後のビジネスのネタになりそうな技術の 評価、検証など – クラウド技術 ネットワーク仮想化、分散ストレージ – IPv4アドレス枯渇対策 IPv6移行技術 トランスレータ、トンネル技術(6rd、MAP他) ? さくらのクラウド、ネットワーク、新ストレージ担当
  • 4. Agenda ? さくらのクラウドについて ? ネットワークの構成 ? ストレージの構成 ? まとめ
  • 5. さくらのクラウドとは？？ ? いわゆるIaaSのサービスです。 ? コンセプト：開発者向けのシンプルクラウド – 物理サーバの使い勝手をコンパネ上に再現 ? 以下のコンピューティングリソースを提供 – ネットワーク – サーバ（CPU、メモリ） – ストレージ
  • 9. システム全体像 インターネット ルータ コントロール パネル L2スイッチ等 L2ネットワーク ホストサーバ API(REST) クラウド ストレージ コントローラ L2スイッチ等 ネットワーク 課金システム ストレージ
  • 10. 仮想インフラの概要 ? サーバの仮想化 – qemu/KVMを使用、現在CentOS6.2ベース。 – 生のqemuをそのまま利用(libvirtも使っていない) ? ネットワークの仮想化 – VLANを用いた論理分割 – 仮想スイッチはOpen vSwitchを利用 ? ストレージの仮想化 – 論理ボリューム、iSCSIによる接続 ? コンパネ、API、コントローラ、課金システム – 完全自社開発
  • 12. 仮想システムプロビジョニング例 このようなシステムを、IaaSインフラ上に展開してみる インターネット VPN VLAN101 VLAN102 ルータ FW VLAN106 VLAN103 LB VPN VLAN104 Webサーバ Webサーバ VLAN105 コントローラにて VLANを自動割り当て DBサーバ DBサーバ
  • 13. クラウド上に配置したシステム インターネット VPN L2網(コアスイッチ、エッジスイッチ、仮想スイッチ) VLAN101 VLAN102 VLAN103 VLAN104 VLAN105 VLAN106 仮想スイッチ 仮想スイッチ 仮想スイッチ ルータ FW LB WEB WEB DB DB VPN ホストサーバA ホストサーバB ホストサーバC VMはどのホストサーバ上に配置してもよい
  • 14. 仮想ネットワークトラフィックフロー インターネット VPN ルータ FW LB VPN Webサーバ Webサーバ DBサーバ DBサーバ
  • 15. 物理トラフィックフロー インターネット north-southトラフィック コアスイッチ、エッジスイッチを ルータ トラフィックが何往復もする east-westトラフィック VMの収容ホストに依存 コアスイッチ エッジスイッチ エッジスイッチ 仮想スイッチ 仮想スイッチ 仮想スイッチ DB LB ルータ Web FW ホストサーバA ホストサーバB ホストサーバC
  • 16. 现在の尝2ネットワークの构成 ルータへ 10GbEスイッチ 10GbE×8 （コアスイッチ） 10GbE×4 Ethernet InfiniBand 変換装置 L2網 IB 40Gbps IBスイッチ群 InfiniBand QDR(40Gbps) ホストサーバ群
  • 17. VLAN数の制限 ? VLAN ID数の不足(12bit≒約4,000VLAN) – 1ユーザあたり10VLANとして、400ユーザが上限 ? ロジカルポート数の不足(次ページで説明) ? 装置によって扱えるVLAN数に制限がある ケース ? 弊社では当初2,000VLANをデプロイ
  • 18. 参考：ロジカルポート数の不足 L2スイッチ 40ポート 4,000VLAN 4,000VLAN 4,000VLAN 4,000VLAN 約4,000×40ポート =約160,000ロジカルポート必要 ロジカルポート数が12,000や24,000の制限があるスイッチがある
  • 19. MACアドレス数の制限 ? MACテーブルエントリ数 – ハッシュコリジョン問題(次ページで説明) – Internalで消費されるMACアドレス – 実質、カタログスペックの半分くらいしか使えない – 弊社での要件は16,000エントリ
  • 20. 参考：ハッシュコリジョン问题 同じハッシュ値をとる５つ目のMACアドレスが 来ると学習できない 4段の例 ハッシュ値1 gg:gg:gg:gg:gg:gg hh:hh:hh:hh:hh:hh ii:ii:ii:ii:ii:ii jj:jj:jj:jj:jj:jj ハッシュ値2 ハッシュ値3 ハッシュ値4 VMに割り当てるMACアドレスをランダムにすることで、 コリジョンの可能性を減らすことができる
  • 22. 余談：OUI取得しました http://standards.ieee.org/cgi-bin/ouisearch?9C-A3-BA 他のクラウドや他の物理ネットワークとの L2レベルでの相互接続も問題なし！
  • 23. ルータの构成 ? 以下2種類のインターネット接続を提供 – 共有インターネット接続（最大100Mbps） – ルータ＋スイッチ（100M、500M、1Gbps） ? ARPテーブル – VMのIPアドレス、MACアドレスを学習 – 弊社の要件は12,000エントリ程度 ? L3仮想インターフェイス数 – インターネットに接続するVLANの収容 – 冗長プロトコルのインスタンス数の制限にあたりやすい – 弊社の要件は2,000インスタンス程度 ? ルータ宛てのDoSアタックへの耐性
  • 24. ルータの构成 インターネット バックボーン eBGP OSPF eBGP 冗長構成 HSRP L2網
  • 25. インターネット接続构成 バックボーンルータ バックボーンルータ クラウドでプールしている eBGP eBGP 10GBase-LR アドレスブロックを集約 10GBase-LR x.x.x.x/20 x.x.x.x/20 して広報 OSPFで経路交換 エッジルータ redist connect エッジルータ redist static 192.168.1.1/29 192.168.0.1/29 192.168.0.2/29 192.168.1.2/29 OSPF VLAN101 VLAN100 VLAN100 VLAN101 動的にL3インター フェイスを追加 10G VRRP等 10G VLAN101 VLAN100 VLAN100 VLAN101 コアスイッチ コアスイッチ
  • 26. 仮想スイッチの構成 ? ホストサーバ上で動作し、物理ネットワークと VM間の通信の橋渡しを行う。 ? VM向けにフィルタ設定が必要 – MACスプーフィング対策、ARPスプーフィング対策、 – IPスプーフィング対策 – お客様指定のパケットフィルタ ? 仮想ポートでの帯域制限 ? 物理IFの冗長性はbondingにて対応 ? さくらのクラウドではOpen vSwitchを使用
  • 27. 仮想スイッチの実装方法 IB Ether変換 IB Ether変換 InfiniBand(QDR) ↑L2網 ↓ホストサーバ vnic1 vnic2 802.1QタグVLAN bonding VLAN 2～2000 Open vSwitch (br0) VLAN100 VLAN300 VLAN1200 VLAN1001 tap0 tap1 tap2 tap3 VM1 VM2
  • 28. Open vSwitchのボトルネック ? DoSアタックなど、大量のフローが発生すると、 転送性能が極端に低下する ? 同一ホストの別のお客様のVMに影響が及ぶ ? 弊社で実施した対策 – 新しいバージョンを使用する – ガベージコレクション開始の閾値を変更 (1,000?120,000) – フロー数監視?異常な通信の検出
  • 29. 参考：Open vSwitchのアーキテクチャ デーモン ovs-vswitchd ← CPU負荷が上昇 （ユーザランド） ?未使用エントリは最大5秒間キャッ 一旦すべてフロー(MACアドレス、 シュ Ethertype、IPアドレス、ポート番号)に分 ?5秒以下でも、1,000エントリを超え 解し、ovs-vswitchdに問い合わせる るとガベージコレクションが始まる ?ガベージコレクションの開始タイミ ングは1秒間隔 カーネル フローキャッ openvswitch_mod モジュール シュ パケット転送処理
  • 31. 新ストレージ導入の経緯 2012/4 2012/5 2012/6 2012/7 2012/8 2012/9 2012/10 2012/11 2012/4頃 新ストレージの開発、 2012/10/1～ 導入をスタート 既存ユーザの課金再開 2012/6/25～ 第一期iSCSIストレージの 2012/11/1～ β提供開始 新規ユーザ募集再開 （サービス正常化） 2012/8/31～ SSDプランの提供開始 第二期iSCSIストレージの β提供開始
  • 32. ストレージのボトルネック ホストサーバ ストレージのキャパシティ ? IOPS ストレージネットワーク ? プールサイズ IF帯域 IF帯域 ? 帯域(MBytes/sec) コントローラ#0 コントローラ#1 コントローラの miniSAS(24Gbps) 性能 RAID-XX JBOD ストレージ 各6Gbps ディスクの性能
  • 33. ストレージのボトルネック ? HDDはIOPSが絶対的に不足 – 1本のディスクを数十ユーザで共有 – 共有ストレージは難しい – 専用サーバ等では1本のディスクを1ユーザが専 有（DAS最強説？） ? その他の制限 – IF、miniSASの帯域（あまり気にする必要ない？） – iSCSIセッション数上限（1ポートあたり256セッショ ンなど）
  • 34. キャパシティを左右するパラメータ ? ディスクのタイプ（SAS or NL-SAS or SATA） ? HDDのサイズ（300GB or 600GB or 900GB） ? 回転数（10Krpm or 15Krpm or 7.2Krpm） ? RAID構成（RAID10 or RAID60 or RAID50） ? ホットスペア（２～４本？） ? HDDの本数（JBODにささるきりのいい数字に） ? スナップショット領域 IO性能（IOPS） 、プールサイズ(GB)
  • 35. 搁础滨顿构成による违い 性能1/3 RAID10 RAID60(8+PQ) RAID50(4+P) random write IOPS N/2 N/6 N/4 random read IOPS N N×4/5 N×4/5 容量 M/2 M×4/5 M×4/5 リビルドの安全性 ○ ◎ △ 容量1.6倍 ? N=HDD1本あたりのIOPS × 本数 ? M=HDD1本あたりの容量 × 本数
  • 36. 収容設計の考え方（弊社の例） ? 4KiB random writeにてストレージのIOPS性能 を測定する。 ? 1ユーザあたり平均XXIOPSとして、収容ユー ザ数の上限を決定する。 ? 容量が無駄にならないように、もしくは容量が 先に頭打ちしないように各種パラメータを調 整する。 会場のみ
  • 37. 収容設計のイメージ 40～1024GBのユーザを最大N個詰めて、容量が余らない プールを作りたい ? ナップサック問題を解く！ 40GB 40GB 100GB 250GB 100GB 100GB 1024GB SAS XXXGB 2.5” 10Krpm XX本 RAIDXX X,XXXIOPS（最大XXXユーザ）、XX,XXXGiB 会場のみ
  • 38. 第一期iSCSIストレージ（HDD） ? 2012/6/25～提供中 ? 市販サーバにHDD搭載 ? IB接続 ? OS: CentOS 6.2 ? クラスタ制御: Pacemaker + DRBD ? ボリューム制御: LVM ? iSCSI Target: tgtd (scsi-target-utils)
  • 39. 接続构成 ホストサーバ ホストサーバ 150台 ? IPoIBによる接続 InfiniBand(QDR) ? ターゲットは仮想IP ? IB経由でデータのミラー 仮想IP ストレージ ストレージ サーバ サーバ 5セット RAID10 DRBD RAID10
  • 40. RAID構成、収容ユーザ数 ? RAID: RAIDXX ? HDD: XXXGB 2.5” SAS 10Krpm × XX本 ? IOPS性能: X,XXXIOPS ? 容量: X,XXXGiB （スナップショット領域500GiB別途） ? 収容ユーザ数: 20GiB×XXXユーザ ? IOPS収容率: XX% ? 容量収容率: XX% 会場のみ
  • 41. 開発、運用中に生じた課題 ? パフォーマンスがでない – DRBDのバージョンを8.4から8.3にダウンすることで解 消 ? DRBDの不具合 – RHEL6系からbarrier命令に対するカーネルの挙動が 変化したことによるデータ不整合 – no-barrierに変更、Verify+再同期によって解消 – 参考情報: http://www.3ware.co.jp/aboutus/news/news- 20120911.html
  • 42. 運用してみた結果 ? メリット – ストレージサーバの内部まで作りこめるので、ク ラウドコントローラとの接続を好きにできる。 – ノード冗長なので、バックプレーンの故障などにも 対応できる。 ? デメリット – ノード冗長により、HDDが2倍必要になる – （RAID101） => 4冗長 – HDDのコストがかかる
  • 43. 第二期iSCSIストレージ（HDD） ? 2012/8/31～提供中 ? コスト削減のため、大容量ユーザ向けに商用の ストレージ製品を導入。 ? 異なる国内メーカの二機種を評価し、某N社さん のストレージを導入 ? 一般的なミッドレンジストレージ ? 10GbE接続、マルチパスによる冗長化 ? 大容量ユーザを収容 – 40,60,80,100,250,500,750,1024GiB
  • 44. RAID構成、収容ユーザ数 ? RAID: RAID60（8+PQ） ? HDD: XXXGB 2.5” SAS 10Krpm × XX本 ? ホットスペア: 別途4本 ? IOPS性能: X,XXXIOPS ? 容量: XX,XXXGiB （スナップショット領域1,024GiB別途） ? 収容ユーザ数: 最大XXXユーザ ? IOPS収容率: XX% （平均XXXGiBで試算） ? 容量収容率: XX% 会場のみ
  • 45. 接続构成 Internet storage storage storage storage ルータ ルータ 10G×8 10G×8 VLAN-XX VLAN-YY コアスイッチ(VDX) コアスイッチ(VDX) 1/1 2/1 3/1 4/1 EoIB 1/1 2/1 3/1 4/1 InfiniBand VLAN-XX VLAN-YY VLAN-XX VLAN-YY vnic1 vnic2 vnic3 vnic4 vnic1 vnic2 vnic3 vnic4 OVS x.x.x.x y.y.y.y OVS x.x.x.x y.y.y.y VM VM VM VM
  • 46. 参考：マルチパス构成 ゲスト VM(qemu) VM(qemu) /dev/mapper/mpatha /dev/mapper/mpathb dm_multipath dm_multipath /dev/sdb /dev/sdc /dev/sdd /dev/sde ホスト iSCSI initiator コントローラ#0 コントローラ#1 ストレージ ストレージ ボリューム
  • 47. 参考：マルチパスと仮想IPの違い ? iSCSIイニシエータのタイマー値が全く異なる。 ? 仮想IPアドレスによる冗長 – ストレージの切替りの間、ユーザのIOを保留して切り 替わりを待つ。 node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 node.session.timeo.replacement_timeout = 86400 ? マルチパスによる冗長 – 即座にdm_multipathにIOエラーを返し、切替えを行う。 node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.session.timeo.replacement_timeout = 5
  • 48. 参考：ストレージの帯域 会場のみ 10Gbpsあれば全然問題ないくらい
  • 49. SSDストレージ ? 2012/11/1～提供中 ? 第一期iSCSIストレージと同じアーキテクチャ – 市販サーバ＋DRBD＋IPoIB ? HDDをSSDに換装 ? Intel SSDXXX XXXGB XX本 ? ホットスペア: 2本（SSD Guard、後ほど詳細） ? 1セットあたり100GiB × XXユーザ収容 会場のみ
  • 50. SSDとHDD、単体の性能比較 HDD 転送帯域: 150MB/sec IO性能: 300IOPS latency: 5ms SSD 転送帯域: 550MB/sec IO性能: 50,000IOPS latency: 0.1ms
  • 51. 弊社で公开しているベンチ结果 仮想サーバから测定
  • 52. 仮想化ドライバの比較 ? qemuには、IDEとvirtioの2種類が存在 ? IDE – 1並列でしかIOを出せない（NCQのような仕組みを 提供していない） – 実質QD=1 ? virtio block – 複数IOを並列で出せる – デフォルトではQD=32（iSCSIイニシエータに依存） ? SSDはvirtio利用を前提
  • 53. 厂厂顿ストレージサーバボトルネック IPoIB処理が複数 ホストサーバへ 会場のみ コアに分散しない read write iSCSI Target(IPoIB) X万IOPS LVM serializeされる DRBD X万IOPS RAIDカード(RAID0) XX万IOPS XX万IOPS SSD SSD SSD XX本 X万IOPS×XX X万IOPS×XX (XXX万IOPS) (XX万IOPS)
  • 54. SSDのEndurance管理 ? SMART情報の監視 @sac-is1a-iscsi4-st01a Enc Slot ID DG RAID E8 E9 Firmware state 11 0 8 0 1 100 100 Online, Spun Up 11 1 9 0 1 100 100 Online, Spun Up 11 2 10 1 0 100 100 Online, Spun Up 11 3 13 1 0 100 100 Online, Spun Up 11 4 14 1 0 100 100 Online, Spun Up <snip> ? SSD Guard – LSI社の技術 – RAID0ボリュームで、SMART情報より壊れそうなSSDの データをホットスペアにコピー
  • 55. ストレージ以外のチューニング ? ユーザからのIO負荷制限 ? IOスケジューラ ? ページキャッシュ ? アライメントの整合性
  • 56. ユーザからのIO負荷制限 ? iSCSIで見えるブロックデバイスに対して cgroupを掛けている ? 一部QDを制限 会場のみ ストレージ IOPS BW QD read write read write HDD IDE XXXX XXXX XXXMB/s XXXMB/s 実質1 HDD Virtio XXXX XXXX XXXMB/s XXXMB/s XX SSD XXXX XXXX XXXMB/s XXXMB/s 実質4
  • 57. 多段滨翱スケジューラの苦悩 プロセス FS iSCSI target pagecache ゲスト(QEMU) pagecache block device block device scheduler scheduler(deadline) IDE LVM ストレージ DRBD RAID card pagecache block device minisas ホスト scheduler(CFQ) HDD/SSD iSCSI initiator iSCSI
  • 58. ホストサーバのページキャッシュ ? Linuxはブロックデバイスに対して4KiB単位でメモ リにキャッシュする?一見よさそうだが？ ? cgroup(IO制限)が意図通りに動かない – cgroupはページキャッシュの下で動いている ? 性能が安定しない – ホストサーバのメモリが減ると遅くなる – メモリが少ないVMプランでもIOが爆速 – ユーザの不公平感がある ? 4KiBアライメントずれによる性能劣化 ? ページキャッシュは使わない（cache=none）
  • 59. アライメントのミスマッチ ? 古いOSでは、パーティションが63セクタ目から始 まっている。 ゲストのファイルシステム（4KB単位） ゲストの仮想ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74 ホストのページキャッシュ（4KB単位） ストレージの物理ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74
  • 60. アライメントのミスマッチ ? ページキャッシュをバイパスすれば問題ない ゲストのファイルシステム（4KB単位） ゲストの仮想ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74 ホストのページキャッシュ（4KB単位） ストレージの物理ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74
  • 61. 础贵罢、厂厂顿でも同様の问题が再现 ゲストのファイルシステム（4KB単位） ゲストの仮想ディスク（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74 物理ディスクの論理セクタ（512B単位） 58 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 71 72 73 74 物理ディスクの物理セクタ（4KB単位） ↑AFT、SSDの場合（ディスクの内部で処理）
  • 62. 今後取り組みたい課題 ? HDDへのIO負荷低減対策 – 小容量のHDDストレージをSSDで実装 – 階層化ストレージ、シンプロビジョニング、その他 ? データバックアップ処理の改善 ? iSCSIセッション制限の克服
  • 63. まとめ ? ネットワークの使用帯域はどんどん増える。 増速によって対応。L2ネットワークのボトル ネックは、将来的にSDN的なソリューションに よって解消を図りたい。 ? ストレージIOは、HDDを使う限り最初から「詰 んでいる」状態。ゲストとストレージ間の中間 層の最適化、SSDの導入などで、負荷低減、 オフロードを図る必要がある。