Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

725 views

Published on

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

Published in: Internet
  • Be the first to comment

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

  1. 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. 2. Agenda • 1)  About  us • 2)  現在のストレージ問題点 • 3)  AzureStackに感動した話 • 4)  OpenStackに対応する場合のHyper-Converged要件 • 5)  構成を考える
  3. 3. 1)About  US
  4. 4. Infrastructure  Business
  5. 5. Using  OpenStack at  GMO  Internet
  6. 6. Public Clouds We are offering four public cloud services.
  7. 7. OpenStack  Juno:  2  service  cluster Mikumo ConoHa Mikumo Anzu Mikumo =  美雲 =  Beautiful  cloud
  8. 8. 2)現在のストレージ問題点
  9. 9. NexentaStor zfs cinder:  ConoHa cloud(Juno) Compute  
  10. 10. ストレージ利用の問題どころ 使っているストレージの種類多すぎ • GlusterFS,  NexentaStor(OpenSolairs),  NetApp,  3PAR,  Swift • 適材適所で増やしていったら • Randy  Bias  (@randybias)  に「Crazy  !!」と言われる 別々の管理ストレージの台数多くなってくる • それぞれ、別の種類で… • 増設が面倒 利用が面倒 • Volume  nodeが別なので、volume  copyとか面倒
  11. 11. Scale  outすると良いよね
  12. 12. 3)AzureStackに感動した話
  13. 13. Microsoft高添さんのAzureStack勉強会(2016/2/19) è 結果的に、分散ストレージとしての構成になっている?  らしい AzureStack • Micro  service <<  OpenStackと似ている • Clustered  service <<  製品化されるので、さすがよく考えているなぁ • SDN(vxlan) <<  vxlanはDefactだよね • Unified  storage <<  これも、cephとか見ていると、なるほどな • Hyper-Converged <<  ぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉぉ そして • Computing • PaaS
  14. 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. 15. 「やるなぁ(●´ω`●)」 と、いろいろな飲み会で 話題にする
  16. 16. Nodeを増やせば scale  out  する è 「理想」のインフラ
  17. 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. 18. いろいろかぶっている
  19. 19. 4)OpenStack対応する場合 の Hyper-Converged要件
  20. 20. Hypervisorと一体なのか or   Hypervisorとは別なのか
  21. 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. 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. 23. データが増え続けるStorageと分散処理の両立 (かなり重要)足りないリソースに対して、スケールアウトできるIOPS 0 2 4 6 8 10 12 14 16 0 1 2 3 4 5 6 1KxIOPS Number of Nodes
  24. 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. 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. 26. Hyper-Converged  node十分要件 (OpenStack):  Network Network • OvS vxlan Overlay  offload • RDMA  storage  network
  27. 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. 28. 5)構成を考える
  29. 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. 30. iSCSIの限界 IO  read/writeアクセスがGateway構成の「コントローラ」に性能依存 • iSCSIセッションの処理上限 SolidFire • いい感じだけど? • Hyper-Converged構成はとれない
  31. 31. iSCSIプロトコルの拡張 IO  read/writeの分散処理 マルチパス処理をクライアント側に実装 è 独自プロトコルになる場合が多い è Nutanix /  ScaleIO /  Ceph /  Sheepdog  /  Open  vStorage などの分散block   storageの登場(OSS版、コミュニティ版) どれがいいんだろうか
  32. 32. Storage  server:  many  NVMe SFF-8639 For  Software  Defined  Storage?      Ceph or  ScaleIO or  etc. çNVMe活用したい!
  33. 33. storage:  IO  gateway  model  (ex:  GlusterFS)
  34. 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. 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. 36. Opensource or  Closed-source?  選定中の意見 • ストレージ担当者:   保守がある製品版が安心 メーカーのサポートは大事 • Compute担当者: いきなりHyper-Convergedから入るのではなく、 Compute(cinder  boot)  +  分散ストレージ としての運用から入れる物が良い • Baremetalの見地から なんらかの提供方法がある(authあり,  network経路) • Block  Storage • File  Storage なにが該当するのか?
  37. 37. みなさんの話を聞いて、参考 にさせていただきたいと思い ます。

×