SlideShare ist ein Scribd-Unternehmen logo
1 von 40
Downloaden Sie, um offline zu lesen
プライベートクラウドを支える
AMD EPYC サーバ
株式会社サイバーエージェント
技術本部
平野 智洋
1.自己紹介
2.Privateクラウド環境の紹介
3.インテルじゃダメなんですか?
4.ストレージはインテル?
5.これからのPrivateクラウド
6.まとめ
自己紹介
平野 智洋
株式会社サイバーエージェント
技術本部
Private Cloud Team
•ハードウェア&ストレージエンジニア
•プライベートクラウドに導入する
サーバハードウェア、ストレージの
選定・検証・運用
•SDSの設計・検証・構築・運用
•その他 小さいシステムの設計・構築
• 監視カメラ・ラック解錠システム・テープバックアップ
写真はTYAN B8026 + 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倍くらい拡張
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)
なぜディスクレスなの?
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を
扱える
インテルじゃ
ダメなんですか?
電力会社に支払われる電気代は、どこでも同じ。
ラックの月額費用も、だいたい同じ。
ならば、できるだけ多くのリソースを、
高密度で搭載した方が、コスト的に有利。
このスペースに、何GHz詰め込めるかが、そのまま
運用コストの圧縮効果に直結する。
何ソケットはいる?何ノードいれるの?
というパズルゲーム。
AMDを選ぶ理由
←1ラック(高さ220cm、幅70cm、奥行120cm)
------横幅70cm------
------高さ220cm------
AMDを選ぶ理由
実際のラック全景
←Compute Node
← Compute Node
← AMD Ceph Storage
← Compute Node
← Compute Node
← Compute Node
← Compute Node
← Compute Node
← TYAN NVMe Storage
← TYAN NVMe Storage
← Compute Node
← Archive Storage
2Uで裏側から4Node差し込むタイプ
DISKがないのでスカスカで通気が良いです
← 100G Switch (裏側)
← Mng Switch (裏側)
←(Compute Node 予定)
←(AMD Ceph Storage 予定)
← ケーブルを束ねるスペース (裏側)
← ケーブルを束ねるスペース (裏側)
← パッチパネル (裏側)
■ Compute Node 36台
■ NVMe 3.2TB x 44本
■ HDD 10TB x 12本
■ アプライアンス 1台
あわせて実効15KVAくらい
←Appliance Storage
TYAN B8026 EPYC搭載 NVMeストレージサーバ
200V PDU x2→
(30A 2系統)
200V PDU x2→
(30A 2系統)
200V PDU x2→
(30A 2系統)
200V PDU x2→
(30A 2系統)
電源定格
24,000W
------横幅70cm------
------高さ220cm------
大事なパラメータは、
■ 1GHzあたりの消費電力
なら、7nmなので消費電力で有利
■ 1GHzあたりの単価
なら、他社より安い設定
何ソケットはいる?何ノードいれるの?
というパズルゲーム。
AMDを選ぶ理由
←1ラック(高さ220cm、幅70cm、奥行120cm)
次回導入するCompute Nodeは、
AMD EPYC ROME 7352 (24Core) Dual Socket
10シャーシ、40ノードをチョイス
何ソケットはいる?何ノードいれるの?
というパズルゲーム。
AMDを選ぶ理由
←1ラック(高さ220cm、幅70cm、奥行120cm)
------横幅70cm------
------高さ220cm------
←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 + TYAN B8026 OSD Server 3台
NAPLES + TYAN B8026 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
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マシン
まとめ
まとめ
なぜインテルじゃなくAMDなのか。
性能?コスト?消費電力?セキュリティ?
まとめ
ちゃんと動くのか心配・・・
サポートが弱そう・・・
毎回インテルだから・・・
→ 今後どんな環境をつくっていきたいのか、
どんな製品に期待をしたいのか、えらぶのは私たちユーザ。
なぜ「それ」をえらぶのか、しっかり考えてゆきたいです。
ご静聴ありがとうございました

Weitere ähnliche Inhalte

Was ist angesagt?

NGINX Back to Basics: Ingress Controller (Japanese Webinar)
NGINX Back to Basics: Ingress Controller (Japanese Webinar)NGINX Back to Basics: Ingress Controller (Japanese Webinar)
NGINX Back to Basics: Ingress Controller (Japanese Webinar)NGINX, Inc.
 
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)VirtualTech Japan Inc.
 
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介IBM Analytics Japan
 
Ceph Performance and Sizing Guide
Ceph Performance and Sizing GuideCeph Performance and Sizing Guide
Ceph Performance and Sizing GuideJose De La Rosa
 
ネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chefネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chefnpsg
 
INF-018_OS の中で SDN 抗争勃発!? ~主役を争う VXLAN vs NVGRE~
INF-018_OS の中で SDN 抗争勃発!? ~主役を争う VXLAN vs NVGRE~INF-018_OS の中で SDN 抗争勃発!? ~主役を争う VXLAN vs NVGRE~
INF-018_OS の中で SDN 抗争勃発!? ~主役を争う VXLAN vs NVGRE~decode2016
 
KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢Naoyuki Yamada
 
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -Yahoo!デベロッパーネットワーク
 
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会ShuheiUda
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAkihiro Kuwano
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2Preferred Networks
 
Cycloudのストレージ紹介と歴史
Cycloudのストレージ紹介と歴史Cycloudのストレージ紹介と歴史
Cycloudのストレージ紹介と歴史Hiroki Chinen
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについてKumazaki Hiroki
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Etsuji Nakai
 
サーバーレスでアンケートフォームを作ってみた
サーバーレスでアンケートフォームを作ってみたサーバーレスでアンケートフォームを作ってみた
サーバーレスでアンケートフォームを作ってみたryutakatori
 
VPC Reachability Analyzer 使って人生が変わった話
VPC Reachability Analyzer 使って人生が変わった話VPC Reachability Analyzer 使って人生が変わった話
VPC Reachability Analyzer 使って人生が変わった話Noritaka Sekiyama
 
Hadoopの標準GUI HUEの最新情報
Hadoopの標準GUI HUEの最新情報Hadoopの標準GUI HUEの最新情報
Hadoopの標準GUI HUEの最新情報Cloudera Japan
 

Was ist angesagt? (20)

NGINX Back to Basics: Ingress Controller (Japanese Webinar)
NGINX Back to Basics: Ingress Controller (Japanese Webinar)NGINX Back to Basics: Ingress Controller (Japanese Webinar)
NGINX Back to Basics: Ingress Controller (Japanese Webinar)
 
LakeTahoe
LakeTahoeLakeTahoe
LakeTahoe
 
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)
OpenStackで始めるクラウド環境構築入門(Horizon 基礎編)
 
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
Db2 v11.5.4 高可用性構成 & HADR 構成パターンご紹介
 
Ceph Performance and Sizing Guide
Ceph Performance and Sizing GuideCeph Performance and Sizing Guide
Ceph Performance and Sizing Guide
 
ネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chefネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chef
 
INF-018_OS の中で SDN 抗争勃発!? ~主役を争う VXLAN vs NVGRE~
INF-018_OS の中で SDN 抗争勃発!? ~主役を争う VXLAN vs NVGRE~INF-018_OS の中で SDN 抗争勃発!? ~主役を争う VXLAN vs NVGRE~
INF-018_OS の中で SDN 抗争勃発!? ~主役を争う VXLAN vs NVGRE~
 
KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢KubernetesでRedisを使うときの選択肢
KubernetesでRedisを使うときの選択肢
 
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
Yahoo! JAPANのデータパイプラインで起きた障害とチューニング - Apache Kafka Meetup Japan #5 -
 
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
 
オンプレML基盤on Kubernetes パネルディスカッション
オンプレML基盤on Kubernetes パネルディスカッションオンプレML基盤on Kubernetes パネルディスカッション
オンプレML基盤on Kubernetes パネルディスカッション
 
Cycloudのストレージ紹介と歴史
Cycloudのストレージ紹介と歴史Cycloudのストレージ紹介と歴史
Cycloudのストレージ紹介と歴史
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについて
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
 
サーバーレスでアンケートフォームを作ってみた
サーバーレスでアンケートフォームを作ってみたサーバーレスでアンケートフォームを作ってみた
サーバーレスでアンケートフォームを作ってみた
 
VPC Reachability Analyzer 使って人生が変わった話
VPC Reachability Analyzer 使って人生が変わった話VPC Reachability Analyzer 使って人生が変わった話
VPC Reachability Analyzer 使って人生が変わった話
 
Hadoopの標準GUI HUEの最新情報
Hadoopの標準GUI HUEの最新情報Hadoopの標準GUI HUEの最新情報
Hadoopの標準GUI HUEの最新情報
 
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
 

Ähnlich wie プライベートクラウドを支えるAMD EPYCサーバ

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 sizingVxRail ChampionClub
 
【テストレポート】Datrium DVXによるIOmark-VM性能テスト
【テストレポート】Datrium DVXによるIOmark-VM性能テスト【テストレポート】Datrium DVXによるIOmark-VM性能テスト
【テストレポート】Datrium DVXによるIOmark-VM性能テストデイトリウム
 
Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)
Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)
Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)Masahiro Tsuji
 
インフラ野郎 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 2018Toru Makabe
 
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 2018Tomohiro Hirano
 
Apache cloudstack4.0インストール
Apache cloudstack4.0インストールApache cloudstack4.0インストール
Apache cloudstack4.0インストールYasuhiro Arai
 
「おうちクラウド」が今熱い!
「おうちクラウド」が今熱い!「おうちクラウド」が今熱い!
「おうちクラウド」が今熱い!Hirotaka Sato
 
OSC 2011 Hokkaido 自宅SAN友の会(後半)
OSC 2011 Hokkaido 自宅SAN友の会(後半)OSC 2011 Hokkaido 自宅SAN友の会(後半)
OSC 2011 Hokkaido 自宅SAN友の会(後半)Satoshi Shimazaki
 
NUCで始めるVMware Tanzu
NUCで始めるVMware TanzuNUCで始めるVMware Tanzu
NUCで始めるVMware TanzuHirotaka Sato
 
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoyaインフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 NagoyaSatoshi Shimazaki
 
Snr005 レノボだから実現
Snr005 レノボだから実現Snr005 レノボだから実現
Snr005 レノボだから実現Tech Summit 2016
 
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介NTT Communications Technology Development
 
Jetson Xavier NX クラウドネイティブをエッジに
Jetson Xavier NX クラウドネイティブをエッジにJetson Xavier NX クラウドネイティブをエッジに
Jetson Xavier NX クラウドネイティブをエッジにNVIDIA Japan
 
20160625 cloud samuai_final
20160625 cloud samuai_final20160625 cloud samuai_final
20160625 cloud samuai_finalTakano Masaru
 
HELLO AI WORLD - MEET JETSON NANO
HELLO AI WORLD - MEET JETSON NANOHELLO AI WORLD - MEET JETSON NANO
HELLO AI WORLD - MEET JETSON NANONVIDIA Japan
 
Azure Stack 受け入れ準備_20180630
Azure Stack 受け入れ準備_20180630Azure Stack 受け入れ準備_20180630
Azure Stack 受け入れ準備_20180630Hiroshi Matsumoto
 
Apache CloudStack 4.0 インストール(ver0.5)
Apache CloudStack 4.0 インストール(ver0.5)Apache CloudStack 4.0 インストール(ver0.5)
Apache CloudStack 4.0 インストール(ver0.5)Yasuhiro Arai
 
CUDAプログラミング入門
CUDAプログラミング入門CUDAプログラミング入門
CUDAプログラミング入門NVIDIA Japan
 

Ähnlich wie プライベートクラウドを支えるAMD EPYCサーバ (20)

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性能テスト
 
Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)
Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)
Sheepdogを使ってみて分かったこと(第六回ストレージ研究会発表資料)
 
インフラ野郎 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
 
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
 
Apache cloudstack4.0インストール
Apache cloudstack4.0インストールApache cloudstack4.0インストール
Apache cloudstack4.0インストール
 
「おうちクラウド」が今熱い!
「おうちクラウド」が今熱い!「おうちクラウド」が今熱い!
「おうちクラウド」が今熱い!
 
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
 
OSC 2011 Hokkaido 自宅SAN友の会(後半)
OSC 2011 Hokkaido 自宅SAN友の会(後半)OSC 2011 Hokkaido 自宅SAN友の会(後半)
OSC 2011 Hokkaido 自宅SAN友の会(後半)
 
NUCで始めるVMware Tanzu
NUCで始めるVMware TanzuNUCで始めるVMware Tanzu
NUCで始めるVMware Tanzu
 
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoyaインフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
インフラエンジニアなら知っておきたいストレージのはなし@OSC 2012 Nagoya
 
Snr005 レノボだから実現
Snr005 レノボだから実現Snr005 レノボだから実現
Snr005 レノボだから実現
 
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介
【たぶん日本初導入!】Azure Stack Hub with GPUの性能と機能紹介
 
Jetson Xavier NX クラウドネイティブをエッジに
Jetson Xavier NX クラウドネイティブをエッジにJetson Xavier NX クラウドネイティブをエッジに
Jetson Xavier NX クラウドネイティブをエッジに
 
20160625 cloud samuai_final
20160625 cloud samuai_final20160625 cloud samuai_final
20160625 cloud samuai_final
 
HELLO AI WORLD - MEET JETSON NANO
HELLO AI WORLD - MEET JETSON NANOHELLO AI WORLD - MEET JETSON NANO
HELLO AI WORLD - MEET JETSON NANO
 
Azure Stack 受け入れ準備_20180630
Azure Stack 受け入れ準備_20180630Azure Stack 受け入れ準備_20180630
Azure Stack 受け入れ準備_20180630
 
Apache CloudStack 4.0 インストール(ver0.5)
Apache CloudStack 4.0 インストール(ver0.5)Apache CloudStack 4.0 インストール(ver0.5)
Apache CloudStack 4.0 インストール(ver0.5)
 
Cmc cmd slim
Cmc cmd slimCmc cmd slim
Cmc cmd slim
 
CUDAプログラミング入門
CUDAプログラミング入門CUDAプログラミング入門
CUDAプログラミング入門
 

プライベートクラウドを支えるAMD EPYCサーバ