OpenStack public cloudとしてConoHaを提供しているが、Hyper-Converged Infraは適用できるのか? 考えてみた。

1. NEXT Gen. Cloud Computing and Storage Infrastructure;
OpenStack ComputingはHyper-Convergedの夢を見るのか?
GMO Internet, Inc.
Naoto Gohko (@naoto_gohko)
Japan Hyper-Converged infrastructure Community Meetup #2
http://japanhci.connpass.com/event/29550/
2016/04/25, NHNテコラス(新宿)にて

2. Agenda
• 1) About us
• 2) 現在のストレージ問題点
• 3) AzureStackに感動した話
• 4) OpenStackに対応する場合のHyper-Converged要件
• 5) 構成を考える

3. 1)About US

4. Infrastructure Business

5. Using OpenStack at GMO Internet

6. Public Clouds
We are offering four public cloud services.

7. OpenStack Juno: 2 service cluster
Mikumo ConoHa Mikumo Anzu
Mikumo = 美雲
= Beautiful cloud

8. 2)現在のストレージ問題点

9. NexentaStor zfs cinder: ConoHa cloud(Juno)
Compute

10. ストレージ利用の問題どころ
使っているストレージの種類多すぎ
• GlusterFS, NexentaStor(OpenSolairs), NetApp, 3PAR, Swift
• 適材適所で増やしていったら
• Randy Bias (@randybias) に「Crazy !!」と言われる
別々の管理ストレージの台数多くなってくる
• それぞれ、別の種類で…
• 増設が面倒
利用が面倒
• Volume nodeが別なので、volume copyとか面倒

11. Scale outすると良いよね

12. 3)AzureStackに感動した話

13. Microsoft高添さんのAzureStack勉強会(2016/2/19)
è 結果的に、分散ストレージとしての構成になっている? らしい
AzureStack
• Micro service << OpenStackと似ている
• Clustered service << 製品化されるので、さすがよく考えているなぁ
• SDN(vxlan) << vxlanはDefactだよね
• Unified storage << これも、cephとか見ていると、なるほどな
• Hyper-Converged << ぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉ
そして
• Computing
• PaaS

14. AzureStack をググルと:
Darryl van der Peijl [MVP]
Azure Stack -­ The Fabric Layer (2016/1/5)
https://www.linkedin.com/pulse/azure-­stack-­fabric-­layer-­darryl-­van-­der-­peijl-­mvp-­

15. 「やるなぁ(●´ω｀●)」
と、いろいろな飲み会で
話題にする

16. Nodeを増やせば
scale out する
è 「理想」のインフラ

17. 自分がOpenStackのインフラでやりたいと思っていたこと
OpenStack
• OpenStack serviceのdocker cluster/vApp Hybrid運用
• HA Clustered service
• SDN(and NFV) + Neutron
• Unified storage
• Hyper-Converged + Distributed Storageの混合運用
その他
• Multi-Hypervisor(Hyper-V)

18. いろいろかぶっている

19. 4)OpenStack対応する場合
の Hyper-Converged要件

20. Hypervisorと一体なのか
or
Hypervisorとは別なのか

21. Hyper-Converged node要件 (OpenStack対応の場合)
Storage
• Nova, Cinder: boot or ephemeral storage(and cache)ç block storage
• Glance: image storage(and cache); ç block or file storage
• Swift: object storage(fast and cold)
Network
• Neutron 動く
• Overlay
• L3, L4, L7(DVR or NFVの場合)
• Managed Network 必要
Computing
• Nova resource : CPU/Memory share(Hypervisor : Storage : Network)
• CPU pin / other BUS

22. Hyper-Converged node必要要件 (OpenStack): Storage
Storage
• Flash + HDDの使い分け、Policy baseで混在可能
• Primary storage (nova, cinder, (cache含む)): è IOPSが速い
• Secondary storage (glance): è スループット優先、できれば”安い”
• Primary ß à Secondary で copy offload (upload/download offload)
• Scale out ç 重要(IOPS)
• 追加、削除が容易、稼働ノードのみ、容量単価でコストになる
• Baremetal nodeからもアクセスできる
• Vlanでネットワークとセキュリティ分離
なぜUnified Storageを考える?
• 小スケールの場合には、ノード数が少なくて済む
なぜPolicy baseが必要?
• スケールアウトした時に、適材適所のコストのノードを適用できる

23. データが増え続けるStorageと分散処理の両立
(かなり重要)足りないリソースに対して、スケールアウトできるIOPS
0
2
4
6
8
10
12
14
16
0 1 2 3 4 5 6
1KxIOPS
Number of Nodes

24. Hyper-Converged node十分要件 (OpenStack): Storage
Storage
• Dedupe
• Compress
• Write cache
• でも、これはちょっと微妙
• Writeの最終commitは? ç ノードの突如なDown時とか意味なくなる
• QoS
• 最悪ストレージに機能が無い場合、attachした時のlibvirt(cgroup)でIOPS,
Throughput制限を設定
• ストレージに機能がある場合、cinder block storageからAPIで設定できること
が条件となる

25. Hyper-Converged node必要要件 (OpenStack): Network
Network
• Storage:Manage:Compute service ç ネットワークの帯域分離 (5.9:0.1:4.0とか)
• Ex)
• Storage帯域: vlan 501, 502, 503
• Manage帯域: vlan 500
• Compute(tenant)Networking帯域: vlan 1001 – 2000 (overlay含む)
これは例えば、次のようなポリシー
• Storage Networkは上限がある
• Manage 絶対確保帯域領域
• Tenant Network 絶対確保帯域、Burst可能

26. Hyper-Converged node十分要件 (OpenStack): Network
Network
• OvS vxlan Overlay offload
• RDMA storage network

27. Hyper-Converged node必要要件 (OpenStack): Computing
Computing resource
• CPU
• Memory
• Bus
Computing
• CPU/Memory share(Hypervisor : Storage : Network)
• Hypervisor/Network CPU: share
• Storage CPU: loadは低ければ低いほどよい >> Computingが主目的より
NFV nodeの場合NICはCPU pinする場合が多い ç 利用可能でほしい
• CPU pin ç migrationしたときに、考慮必要
• SR-IOV, PCIe pass through card, vGPUも同様
Busの要件に関しては、用途別に必要要件

28. 5)構成を考える

29. Storage と IO Gateway構造
IO read/writeアクセスとプロトコルの変換点
• かならずある(ネットワーク化、仮想化をした場合)
• なんらかの変換処理がされるPoint
EX) iSCSI for Baremetal
• Baremetal server
• Storage IO ó iSCSI protocol (iSCSIイニシエータ)
• Storage system
• iSCSI protocol (コントローラ・iSCSIターゲット) ó Storage IO
これは、SCSIというストレージデバイスをネットワークでアクセスできるように「iSCSIデ
バイス」によって抽象化している

30. iSCSIの限界
IO read/writeアクセスがGateway構成の「コントローラ」に性能依存
• iSCSIセッションの処理上限
SolidFire
• いい感じだけど?
• Hyper-Converged構成はとれない

31. iSCSIプロトコルの拡張
IO read/writeの分散処理
マルチパス処理をクライアント側に実装
è 独自プロトコルになる場合が多い
è Nutanix / ScaleIO / Ceph / Sheepdog / Open vStorage などの分散block
storageの登場(OSS版、コミュニティ版)
どれがいいんだろうか

32. Storage server: many NVMe SFF-8639
For Software Defined Storage? Ceph or ScaleIO or etc.
çNVMe活用したい!

33. storage: IO gateway model (ex: GlusterFS)

34. storage: IO gateway model: どこでCPU/Memory使うの?
1) IO gateway is a bottleneck point
IO gateway := torage IO and protocol conversion part
2) Important process of gateway of close to the IO of the "guest OS”
3) Tiering of the cache is important, the primary commitment of the write
processes as soon as possible. But, it is weak in the crash of the host.
…

35. GlusterFS (Fuse and libgfapi): our problems
1) The performance of Fuse driver is BAD.
2) Very high CPU load
3) Memory leark
4) Qemu libgfapi driver is Sad.
(reggression test and benchmark)
Crash guest OS !! (CentOS 7.1 + Qemu 2.1.0)
この検証により、OSS Hyper-Convergedな構成に、現在はNegative

36. Opensource or Closed-source? 選定中の意見
• ストレージ担当者:
保守がある製品版が安心
メーカーのサポートは大事
• Compute担当者:
いきなりHyper-Convergedから入るのではなく、
Compute(cinder boot) + 分散ストレージ
としての運用から入れる物が良い
• Baremetalの見地から
なんらかの提供方法がある(authあり, network経路)
• Block Storage
• File Storage
なにが該当するのか?

37. みなさんの話を聞いて、参考
にさせていただきたいと思い
ます。