SlideShare a Scribd company logo
1 of 38
Download to read offline
OpenStackを200%活用する
SDSの挑戦
株式会社サイバーエージェント
技術本部
平野 智洋
1.自己紹介
2.Privateクラウド環境の紹介
3.インテルじゃダメなんですか?
4.ストレージはインテル?
5.これからのPrivateクラウド
自己紹介
平野 智洋
株式会社サイバーエージェント
技術本部
Private Cloud Team
•ハードウェア&ストレージエンジニア
•プライベートクラウドに導入する
サーバハードウェア、ストレージの
選定・検証・運用
•SDSの設計・検証・構築・運用
•その他 小さいシステムの設計・構築
• 監視カメラ・ラック解錠システム・テープバックアップ
写真はAMD ROMEを使用したSDSクラスタ検証の様子→
Privateクラウド環境の紹介
Privateクラウドの紹介
DC間Network・VPN
Transit
IX
エンドユーザ
リソース コントローラ ミドルウェア
CDN
サービス
Privateクラウドの紹介
Transit
IX
CDN
リソース コントローラ
Private Cloud Team は
ここまでを管理
DC間Network・VPN
Privateクラウドの紹介
Transit
IX
リソース コントローラ
■ Development Team
■ Network Team
■ Hardware & Storage Team
■ 運用 Team
■ OPT Team
全Team総勢19人
CDN
DC間Network・VPN
Privateクラウドの変遷
- OpenStack
Diablo
- 1Gbps x2
- 1Node 8 Core
- 300GB x4
実効600GB
- 3,000 vCPUs
2011 2013 2015 2018
- Clover
(自社内製)
- 1Gbps x1
- 1Node 12 Core
- 600GB x4
実効1.2TB
- 70,000 vCPUs
- OpenStack
Kilo
- 10Gbps x2
- 1Node 20 Core
- 1.2TB x 4
実効2.4TB
- 25,000 vCPUs
- OpenStack
Queens
- 25Gbps x2
- 1Node 40 Core
- Diskless
+ Cinder
- 20,000 vCPUs+
物理環境からの移行先新規サービスの受入れ環境
Cloverからの移行先
あと2倍くらい拡張
なぜディスクレスなの?
Instance Type VCPUs RAM(MB) Disk(GB)
m1.tiny 1 2,662 21
m1.small 2 5,324 42
m1.medium 4 10,752 85
m1.large 8 21,504 170
m1.xlarge 12 32,256 256
m1.2xlarge 16 43,008 341
m1.3xlarge 24 64,512 512
プランごとに
CPU・メモリ・ディスク
それぞれが強制的に決め打ち
CPUだけ使いたいユーザ
DISKだけ大量にほしいユーザ
メモリを大量に使いたいユーザ
ミスマッチにより、
リソースが割り当てられても
使われないケースが多発
なぜディスクレスなの?
ディスクレスCompute Nodeの利点
・DISKリソースの有効利用
前述の通り、無駄にストレージを買わずに済む
・Compute Nodeが安くなる
SSD/HDDを搭載しないから、コストが抑えられる
・故障からの解放
小規模のたくさんのアレイをチマチマとメンテナンスするより、
ガッチリ冗長の大規模アレイを運用したほうが楽
・かんたん構築
PXE Boot → ライブOS稼働だから、設置したらすぐに稼働可能。
・仮想サーバの高速マイグレーション
デタッチしてアタッチするだけの動きなので、データ移行とかは発生しない
・Compute Nodeが死んでもデータは死なない
Compute Nodeの外に保存してるから
「ディスクがー!」
「バッテリーがー!!」
「Firmwareガー!!!」
「保守切れがー!!」
なぜディスクレスなの?
・ストレージの停止=全サービス即死
集中共有ストレージが停止すると、すべてのサービスが即死することになる。
ストレージ障害による影響を抑えるための対策:
→ AZ(ラック架列)を3系統に分けてデザインすることで、DC設備の電源系統を分離
→ さらにAZ内で独立した複数の系統を構築
→ さらにさらに、アレイはラックレベルの冗長性を確保
・ネットワークトラフィックが増える
ユーザが利用するDISK IOのほか、アレイ内で冗長をとるためのIOもNWを通るので、
2-3倍くらいトラフィックが増えることになる。
トラフィック増加への対策:
→ 10Gで足りなければ25G x2 = 50Gにするだけ。お値段はそんなに変わらない。
ディスクレスCompute Nodeの欠点
Privateクラウドの中身
NOVA Compute Node
Virtual
Machine
VDA
VDB
Virtual
Machine
VDA
mpathA
mpathB
mpathC
Cinder-Boot
Cinder-Standard
Volume Volume Volume
Volume Volume Volume
OSをBootする用のCinder
そんなに速くない
大量のVolumeを
扱える設計
高速なCinder
とっても速い
オールNVMe
2冗長 HA構成
VDB
mpathD
Cinder-Ceph
Volume Volume Volume
上記2つの中間
そこそこ速い
多数のVolumeを
扱える
Privateクラウドの中身
NOVA Compute Node
L2 Network
20,000 vCPUs
200TB
200TB
300TB
Cinder-Boot
Cinder-Standard
Cinder-Archive
Cinder-Boot
Cinder-Standard
Cinder-Ceph
Cinder-Archive
Cinder-Ceph
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
NOVA Compute Node
Global
Network
120TB
(OpenStack Queens)
インテルじゃ
ダメなんですか?
電力会社に支払われる電気代は、どこでも同じ。
ラックの月額費用も、だいたい同じ。
ならば、できるだけ多くのリソースを、
高密度で搭載した方が、コスト的に有利。
このスペースに、何GHz詰め込めるかが、そのまま
運用コストの圧縮効果に直結する。
何ソケットはいる?何ノードいれるの?
というパズルゲーム。
AMDを選ぶ理由
←1ラック(高さ220cm、幅70cm、奥行120cm)
------横幅70cm------
------高さ220cm------
AMDを選ぶ理由
実際のラック全景
←Compute Node
← Compute Node
← AMD/Supermicro Ceph Storage
← Compute Node
← Compute Node
← Compute Node
← Compute Node
← Compute Node
← NVMe Storage
← NVMe Storage
← Compute Node
← Archive Storage
2Uで裏側から4Node差し込むタイプ
DISKがないのでスカスカで通気が良いです
← 100G Switch (裏側)
← Mng Switch (裏側)
←(Compute Node 予定)
←(AMD/Supermicro Ceph Storage 予定)
← ケーブルを束ねるスペース (裏側)
← ケーブルを束ねるスペース (裏側)
← パッチパネル (裏側)
■ Compute Node 36台
■ NVMe 3.2TB x 44本
■ HDD 10TB x 12本
■ アプライアンス 1台
あわせて実効15KVAくらい
←Appliance Storage
Supermicro NVMe 搭載 Cephストレージ
200V PDU x2→
(30A 2系統)
200V PDU x2→
(30A 2系統)
200V PDU x2→
(30A 2系統)
200V PDU x2→
(30A 2系統)
電源定格
24,000W
大事なパラメータは、
■ 1GHzあたりの消費電力
AMDなら、7nmなので消費電力で有利
■ 1GHzあたりの単価
AMDなら、他社より安い設定
何ソケットはいる?何ノードいれるの?
というパズルゲーム。
AMDを選ぶ理由
←1ラック(高さ220cm、幅70cm、奥行120cm)
------横幅70cm------
------高さ220cm------
次回導入するCompute Nodeは、
Supermicro BigTwin (2U4Node)
AMD EPYC ROME 7352 (24Core) Dual Socket
10シャーシ、40ノードをチョイス
何ソケットはいる?何ノードいれるの?
というパズルゲーム。
AMDを選ぶ理由
←1ラック(高さ220cm、幅70cm、奥行120cm)
Intel Xeon:
1,760 vCPUs, 6.4THz
AMD EPYC ROME:
3,840 vCPU, 8.83THz
同等の消費電力で、
大幅な高密度化が可能!!Xeon:20core x 2socket x 2thread x 2GHz x 2U4Node x 10chassis = 6.40THz
EPYC: 24core x 2socket x 2thread x 2.3GHz x 2U4Node x 10chassis = 8.83THz
AMDを選ぶ理由
------横幅70cm------
------高さ220cm------
AMDを選ぶ理由
Xeon → EPYC Romeで
1コアあたりの性能がどう変わるか、
気になりませんか?
Compute Node 性能試験結果グラフ
試験方法:物理サーバに8CoreのKVM仮想サーバを立てて、仮想サーバ内でUnixBenchを実行。
公平を保つため、qemu-kvmのCPU Profileはkvm64で設定。KernelはCentOS7 3.10.0-957
AMDを選ぶ理由
ストレージは
インテルで良いでしょ?
新しいCinderストレージにcephを採用!
Cephは、最近あたらしいosdストレージ
“BlueStore” に対応。
Google生まれFacebook育ちの
Key Value Store “Rocks DB” を経由した
ブロックデバイスへの直接IOで、
従来ボトルネックとなっていた
File Systemの足かせが無くなり、
Write性能が超改善!
×
×
ストレージにAMDを選ぶ理由
新しいCinderストレージにcephを採用!
Cephは、最近あたらしいosdストレージ
“BlueStore” に対応。×
×
ストレージにAMDを選ぶ理由
新しいCinderストレージにcephを採用!
■ オールNVMe構成
SATAは不安定なのでダメ
今は価格差もないのでNVMeを選択
■EPYCの豊富なPCIレーンをフル活用
128 PCIレーン、ロスレスでたくさんの
NVMeが使える。
XeonはPCIレーンが足りないので論外
■ EPYC ROMEはPCIe Gen4対応
Gen4デバイスを選択すればデータ効率が◎
×
×
ストレージにAMDを選ぶ理由
Xeonは論外ですが、
Naples(旧 EPYC 7001)→Rome(新 EPYC 7002)で
どう変わるか、
気になりませんか?
ストレージにAMDを選ぶ理由
×
×
ROME vs NAPLES
ROME OSD Server
ROME OSD Server 3台
NAPLES OSD Server 3台
ROME OSD Server
ROME OSD Server
ROME OSD Server
ROME OSD Server
ROME OSD Server
ROME OSD Server
ROME OSD Server
ROME OSD Server
NVMe
NVMe
NVMe
NVMe
NVMe
NVMe
NVMe
NVMe
NVMe
Naples OSD Server
Naples OSD Server
Naples OSD Server
Naples OSD Server
Naples OSD Server
Naples OSD Server
Naples OSD Server
Naples OSD Server
Naples OSD Server
NVMe
NVMe
NVMe
NVMe
NVMe
NVMe
NVMe
NVMe
NVMe
×
×
ROME vs NAPLES
これからのPrivateクラウド
これからのPrivateクラウド
Keyword:NVMe over Fablic
さようならiSCSI…
これからのPrivateクラウド
回転する円盤用の
インターフェイスは、もうおしまい。
NVMeだけでなく、あらゆるBlock Storageが
NVMe over TCPで接続できるようになりました。
これからのPrivateクラウド
ココ
ココの
これからのPrivateクラウド
NOVA Compute Node
Virtual
Machine
VDA
VDB
Virtual
Machine
VDA
VDB
disk
disk
disk
disk
Cinder-Hyper (Active)
Volume Volume Volume
Cinder-Hyper (Backup)
Volume Volume Volume
NVMe over Fablic NVMe Cluster
【試験環境】
1クラスタ
38TB
HA構成
140万IOPS
(4k randwrite)
とんでもねぇ性能
これからのPrivateクラウド
24本のNVMeを、600Gbpsの
NVMe over RDMA / NVMe over TCP で
提供する、EBOFマシン
これからのPrivateクラウド
24本のNVMeを、400Gbpsの
NVMe over RDMAで
提供する、EBOFマシン
これからのPrivateクラウド
■ AMD EPYC ROME
■ NVMe over Fablic
■ NVMe over TCP
ご静聴ありがとうございました

More Related Content

What's hot

仮想化環境におけるパケットフォワーディング
仮想化環境におけるパケットフォワーディング仮想化環境におけるパケットフォワーディング
仮想化環境におけるパケットフォワーディング
Takuya ASADA
 

What's hot (20)

Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
分散ストレージ技術Cephの最新情報
分散ストレージ技術Cephの最新情報分散ストレージ技術Cephの最新情報
分散ストレージ技術Cephの最新情報
 
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
不揮発性メモリ(PMEM)を利用したストレージエンジンの話  #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ不揮発性メモリ(PMEM)を利用したストレージエンジンの話  #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ
 
仮想化環境におけるパケットフォワーディング
仮想化環境におけるパケットフォワーディング仮想化環境におけるパケットフォワーディング
仮想化環境におけるパケットフォワーディング
 
Kubernetesによる機械学習基盤への挑戦
Kubernetesによる機械学習基盤への挑戦Kubernetesによる機械学習基盤への挑戦
Kubernetesによる機械学習基盤への挑戦
 
Cycloudのストレージ紹介と歴史
Cycloudのストレージ紹介と歴史Cycloudのストレージ紹介と歴史
Cycloudのストレージ紹介と歴史
 
CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)CDNの仕組み(JANOG36)
CDNの仕組み(JANOG36)
 
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
 
エンジニアのためのOSSライセンス管理~OSS管理ツールの池の水全部抜く~
エンジニアのためのOSSライセンス管理~OSS管理ツールの池の水全部抜く~エンジニアのためのOSSライセンス管理~OSS管理ツールの池の水全部抜く~
エンジニアのためのOSSライセンス管理~OSS管理ツールの池の水全部抜く~
 
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
OSC2011 Tokyo/Spring 自宅SAN友の会(前半)
 
GMOインターネット様 発表「OpenStackのモデルの最適化とConoHa, Z.comとGMOアプリクラウドへの適用」 - OpenStack最新情...
GMOインターネット様 発表「OpenStackのモデルの最適化とConoHa, Z.comとGMOアプリクラウドへの適用」 - OpenStack最新情...GMOインターネット様 発表「OpenStackのモデルの最適化とConoHa, Z.comとGMOアプリクラウドへの適用」 - OpenStack最新情...
GMOインターネット様 発表「OpenStackのモデルの最適化とConoHa, Z.comとGMOアプリクラウドへの適用」 - OpenStack最新情...
 
「おうちクラウド」が今熱い!
「おうちクラウド」が今熱い!「おうちクラウド」が今熱い!
「おうちクラウド」が今熱い!
 
ML2/OVN アーキテクチャ概観
ML2/OVN アーキテクチャ概観ML2/OVN アーキテクチャ概観
ML2/OVN アーキテクチャ概観
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
NEDIA_SNIA_CXL_講演資料.pdf
NEDIA_SNIA_CXL_講演資料.pdfNEDIA_SNIA_CXL_講演資料.pdf
NEDIA_SNIA_CXL_講演資料.pdf
 
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
 
不揮発メモリ(NVDIMM)とLinuxの対応動向について
不揮発メモリ(NVDIMM)とLinuxの対応動向について不揮発メモリ(NVDIMM)とLinuxの対応動向について
不揮発メモリ(NVDIMM)とLinuxの対応動向について
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
 
昨今のストレージ選定のポイントとCephStorageの特徴
昨今のストレージ選定のポイントとCephStorageの特徴昨今のストレージ選定のポイントとCephStorageの特徴
昨今のストレージ選定のポイントとCephStorageの特徴
 
GitLab から GitLab に移行したときの思い出
GitLab から GitLab に移行したときの思い出GitLab から GitLab に移行したときの思い出
GitLab から GitLab に移行したときの思い出
 

Similar to Openstackを200%活用するSDSの挑戦

【テストレポート】Datrium DVXによるIOmark-VM性能テスト
【テストレポート】Datrium DVXによるIOmark-VM性能テスト【テストレポート】Datrium DVXによるIOmark-VM性能テスト
【テストレポート】Datrium DVXによるIOmark-VM性能テスト
デイトリウム
 
インフラ野郎 Azureチーム v18.11 at Tech Summit 2018
インフラ野郎 Azureチーム v18.11 at Tech Summit 2018インフラ野郎 Azureチーム v18.11 at Tech Summit 2018
インフラ野郎 Azureチーム v18.11 at Tech Summit 2018
Toru Makabe
 
Apache cloudstack4.0インストール
Apache cloudstack4.0インストールApache cloudstack4.0インストール
Apache cloudstack4.0インストール
Yasuhiro Arai
 
Applibot presents Smartphone Game on AWS
Applibot presents Smartphone Game on AWSApplibot presents Smartphone Game on AWS
Applibot presents Smartphone Game on AWS
Kenta Yasukawa
 

Similar to Openstackを200%活用するSDSの挑戦 (20)

Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)
Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)
Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)
 
Networld vx railchampionclub_essential point of sizing
Networld vx railchampionclub_essential point of sizingNetworld vx railchampionclub_essential point of sizing
Networld vx railchampionclub_essential point of sizing
 
【テストレポート】Datrium DVXによるIOmark-VM性能テスト
【テストレポート】Datrium DVXによるIOmark-VM性能テスト【テストレポート】Datrium DVXによるIOmark-VM性能テスト
【テストレポート】Datrium DVXによるIOmark-VM性能テスト
 
NUCで始めるVMware Tanzu
NUCで始めるVMware TanzuNUCで始めるVMware Tanzu
NUCで始めるVMware Tanzu
 
HELLO AI WORLD - MEET JETSON NANO
HELLO AI WORLD - MEET JETSON NANOHELLO AI WORLD - MEET JETSON NANO
HELLO AI WORLD - MEET JETSON NANO
 
インフラ野郎 Azureチーム v18.11 at Tech Summit 2018
インフラ野郎 Azureチーム v18.11 at Tech Summit 2018インフラ野郎 Azureチーム v18.11 at Tech Summit 2018
インフラ野郎 Azureチーム v18.11 at Tech Summit 2018
 
Jetson Xavier NX クラウドネイティブをエッジに
Jetson Xavier NX クラウドネイティブをエッジにJetson Xavier NX クラウドネイティブをエッジに
Jetson Xavier NX クラウドネイティブをエッジに
 
Apache cloudstack4.0インストール
Apache cloudstack4.0インストールApache cloudstack4.0インストール
Apache cloudstack4.0インストール
 
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介
 
Snr005 レノボだから実現
Snr005 レノボだから実現Snr005 レノボだから実現
Snr005 レノボだから実現
 
CUDAプログラミング入門
CUDAプログラミング入門CUDAプログラミング入門
CUDAプログラミング入門
 
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoyaインフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
 
Cmc cmd slim
Cmc cmd slimCmc cmd slim
Cmc cmd slim
 
ITpro EXPO 2014: Cisco UCSによる最新VDIソリューションのご紹介
ITpro EXPO 2014: Cisco UCSによる最新VDIソリューションのご紹介ITpro EXPO 2014: Cisco UCSによる最新VDIソリューションのご紹介
ITpro EXPO 2014: Cisco UCSによる最新VDIソリューションのご紹介
 
Cyberagent amd tyan server solution seminar 2018
Cyberagent amd tyan server solution seminar 2018Cyberagent amd tyan server solution seminar 2018
Cyberagent amd tyan server solution seminar 2018
 
Azure Stack 受け入れ準備_20180630
Azure Stack 受け入れ準備_20180630Azure Stack 受け入れ準備_20180630
Azure Stack 受け入れ準備_20180630
 
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
 
20160625 cloud samuai_final
20160625 cloud samuai_final20160625 cloud samuai_final
20160625 cloud samuai_final
 
Applibot presents Smartphone Game on AWS
Applibot presents Smartphone Game on AWSApplibot presents Smartphone Game on AWS
Applibot presents Smartphone Game on AWS
 
OSC 2012 Fukuoka
OSC 2012 FukuokaOSC 2012 Fukuoka
OSC 2012 Fukuoka
 

Openstackを200%活用するSDSの挑戦