Upload
naoto-gohko
View
507
Download
0
Embed Size (px)
Citation preview
NEXT Gen. Cloud Computing and Storage Infrastructure;
OpenStack ComputingはHyper-Convergedの夢を見るのか?
GMO Internet, Inc.
Naoto Gohko (@naoto_gohko)
Japan Hyper-Converged infrastructure Community Meetup #2http://japanhci.connpass.com/event/29550/
2016/04/25, NHNテコラス(新宿)にて
Agenda
• 1) About us
• 2) 現在のストレージ問題点
• 3) AzureStackに感動した話
• 4) OpenStackに対応する場合のHyper-Converged要件
• 5) 構成を考える
1)About US
Infrastructure Business
Using OpenStack at GMO Internet
Public Clouds
We are offering four public cloud services.
OpenStack Juno: 2 service cluster
Mikumo ConoHa Mikumo Anzu
Mikumo = 美雲= Beautiful cloud
2)現在のストレージ問題点
NexentaStor zfs cinder: ConoHa cloud(Juno)
Compute
ストレージ利用の問題どころ
使っているストレージの種類多すぎ• GlusterFS, NexentaStor(OpenSolairs), NetApp, 3PAR, Swift
• 適材適所で増やしていったら• Randy Bias (@randybias) に「Crazy !!」と言われる
別々の管理ストレージの台数多くなってくる• それぞれ、別の種類で…• 増設が面倒
利用が面倒• Volume nodeが別なので、volume copyとか面倒
Scale outすると良いよね
3)AzureStackに感動した話
Microsoft高添さんのAzureStack勉強会(2016/2/19)
è 結果的に、分散ストレージとしての構成になっている? らしい
AzureStack• Micro service << OpenStackと似ている• Clustered service << 製品化されるので、さすがよく考えているなぁ• SDN(vxlan) << vxlanはDefactだよね• Unified storage << これも、cephとか見ていると、なるほどな• Hyper-Converged << ぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉ
そして• Computing• PaaS
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-
「やるなぁ(●´ω`●)」と、いろいろな飲み会で
話題にする
Nodeを増やせばscale out する
è 「理想」のインフラ
自分が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)
いろいろかぶっている
4)OpenStack対応する場合の Hyper-Converged要件
Hypervisorと一体なのかor Hypervisorとは別なのか
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
Hyper-Converged node必要要件 (OpenStack): StorageStorage• 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が必要?• スケールアウトした時に、適材適所のコストのノードを適用できる
データが増え続けるStorageと分散処理の両立
(かなり重要)足りないリソースに対して、スケールアウトできるIOPS
0
2
4
6
8
10
12
14
16
0 1 2 3 4 5 6
1K x
IOP
S
Number of Nodes
Hyper-Converged node十分要件 (OpenStack): StorageStorage• Dedupe• Compress• Write cache
• でも、これはちょっと微妙• Writeの最終commitは? ç ノードの突如なDown時とか意味なくなる
• QoS• 最悪ストレージに機能が無い場合、attachした時のlibvirt(cgroup)でIOPS, Throughput制限を設定
• ストレージに機能がある場合、cinder block storageからAPIで設定できることが条件となる
Hyper-Converged node必要要件 (OpenStack): NetworkNetwork• 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可能
Hyper-Converged node十分要件 (OpenStack): NetworkNetwork• OvS vxlan Overlay offload• RDMA storage network
Hyper-Converged node必要要件 (OpenStack): ComputingComputing 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の要件に関しては、用途別に必要要件
5)構成を考える
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デバイス」によって抽象化している
iSCSIの限界
IO read/writeアクセスがGateway構成の「コントローラ」に性能依存• iSCSIセッションの処理上限
SolidFire• いい感じだけど?
• Hyper-Converged構成はとれない
iSCSIプロトコルの拡張
IO read/writeの分散処理マルチパス処理をクライアント側に実装
è 独自プロトコルになる場合が多い
è Nutanix / ScaleIO / Ceph / Sheepdog / Open vStorage などの分散block storageの登場(OSS版、コミュニティ版)
どれがいいんだろうか
Storage server: many NVMe SFF-8639For Software Defined Storage? Ceph or ScaleIO or etc.
çNVMe活用したい!
storage: IO gateway model (ex: GlusterFS)
storage: IO gateway model: どこでCPU/Memory使うの?1) IO gateway is a bottleneck pointIO 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.
…
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
Opensource or Closed-source? 選定中の意見• ストレージ担当者: 保守がある製品版が安心
メーカーのサポートは大事
• Compute担当者:いきなりHyper-Convergedから入るのではなく、Compute(cinder boot) + 分散ストレージ
としての運用から入れる物が良い
• Baremetalの見地から
なんらかの提供方法がある(authあり, network経路)• Block Storage• File Storage
なにが該当するのか?
みなさんの話を聞いて、参考にさせていただきたいと思います。