OpenStack ComputingはHyper-Convergedの夢を見るのか?

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

なにが該当するのか?

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