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.
Copyright © DeNA Co.,Ltd. All Rights Reserved.
DeNA private cloudのその後
Feb 10, 2017
Kengo Sakai
IT Platform Dept.
System Ma...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
自己紹介
 氏名
⁃ 酒井 憲吾(Sakai Kengo)
 入社
⁃ 2013年7月
 所属
⁃ システム本部IT基盤部
 経歴
⁃ 前職で...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
アジェンダ
 昨年の発表の振り返り
 現在のprivate cloudの状況
 SDN: Big Cloud Fabric
 LBaaS: O...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
昨年の発表の振り返り
4
Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:昨年のDeNA TechCon
5
Copyright © DeNA Co.,Ltd. All Rights Reserved.
6
振り返り:Private Cloud導入のねらい
Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:サーバ運用とネットワーク運用の統合
7
Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:サーバ運用とネットワーク運用の統合
8
Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:サーバ運用とネットワーク運用の統合
9
Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:仮想化基盤の運用改善
10
Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:仮想化基盤の運用改善
11
Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:仮想化基盤の運用改善
12
Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:昨年の発表はここまで
13
Copyright © DeNA Co.,Ltd. All Rights Reserved.
現在のprivate cloudの状況
14
Copyright © DeNA Co.,Ltd. All Rights Reserved.
0
200
400
600
800
1000
1200
1400
1600
1800
2000
1 2 3 4 5 6 7 8 9 10 11 12 ...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
private cloudの構成
16
© 2016 Big Switch Networks,Inc. All rights reserved.
© ...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
運用がどう変わったか
 サーバ運用とネットワーク運用の統合
⁃ VRF、VLAN、Network ACLの設定
• OpenStack + Big ...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
SDN: Big Cloud Fabric
18
Copyright © DeNA Co.,Ltd. All Rights Reserved.
Big Cloud Fabricとは
19
 OpenStackとのintegrationにアンダーレイネットワークをサポート
 コントローラとス...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
OpenStack + Big Cloud Fabric Integration
20
! tenant
tenant test_project.op...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
OpenStack + Big Cloud Fabric 構成パターン
 P-Fabricのパターンを採用
 ただし、L3(OpenStackのR...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
OpenStack + Big Cloud Fabric Integration
22
BCF Controller
REST API
Control...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
障害発生!
23
Copyright © DeNA Co.,Ltd. All Rights Reserved.
障害:新規に作ったインスタンスが通信できない
 原因:NeutronがインスタンスのPort情報をBCFに反映できなかったため
 経緯
 BCF...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
障害:新規に作ったインスタンスが通信できない
 対応
 agentの通知がさばけるまで順にagentを止めていく
 通知がさばけた後で順にage...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
LBaaS: Orion
26
Copyright © DeNA Co.,Ltd. All Rights Reserved.
Orionとは
 内製のBIG-IP用 API
 開発の背景
⁃ 以前から使用していたF5のHardware ApplianceをOpenStac...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
Orionの構成
 ユーザにはorion-cliでの操作を解放
 Orionが内製の構成管理DBと連携
 構成管理DBはサーバのIPアドレス、使...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
使い方: LB作成
 OpenStack LBaaSv2の場合
 neutron lbaas-loadbalancer-create …
 ne...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
使い方: Poolメンバ追加
 OpenStack LBaaSv2の場合
 neutron lbaas-member-create –subnet...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
アクセス制御
 BIG-IPのパーティション機能を
利用
 サービスに対応したパーティシ
ョンを作成
 orion-cliを実行したサーバのサ
...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
SDS: Ceph
32
Copyright © DeNA Co.,Ltd. All Rights Reserved.
Cephとは
 オープンソースの分散ストレージ
 何かトラブルが起きた時に迅速に対応するためには、ソフトウェア
の振る舞いを詳細に把握する必要があ...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
Ceph Storage Clusterの構成
 MON
 OSDの構成、状態監視を行う。Storage Node上でも動作
 OSD
 ディ...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
Compute Node故障時はどうする?
 nova evacuateコマンドでVMを他のCompute Nodeに退避する
⁃ ブロックストレー...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
Compute Nodeの構成
 いわゆるハイパーコンバージドな構成
 Compute NodeがCephのStorage Nodeも兼ねる
 ...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
やはりI/O性能が問題に!!
37
Copyright © DeNA Co.,Ltd. All Rights Reserved.
問題その1: Compute Nodeのディスクの負荷が高い
 OSDはjournal領域、data領域の順に書き込みを行う
38
VM OSD j...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
パフォーマンスチューニング:
ジャーナルとデータ領域を一つの物理ディスクに共存させない
 ディスクへのI/O負荷を下げるために、ジャーナル領域とデー...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
問題その2: VMのI/Oリクエストが数秒〜数十秒待たされる
 原因調査が難航
 Compute Nodeのディスクの負荷は下がっているので問題な...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
原因調査: ログ分析
 cephのログとソースコードを詳細に照らし合わせ調査した結果、write
request受信直後の処理が遅くなっていそうと判...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
原因調査: スレッドダンプからボトルネックを特定
 内製のデバッガーを用い、稼働中のceph-osdプロセスにアタッチし、そ
の瞬間の各スレッドのバ...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
パフォーマンスチューニング:
tcmallocのスレッドキャッシュサイズを拡張する
 tcmallocのキャッシュメモリの獲得、解放にかかるCPU負...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
課題: fsync問題
 fsync/fdatasyncのようなデータ同期が発生すると後続のwriteが待たさ
れてしまう
 fsyncは例えば、...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
課題: ネットワークの輻輳
 OSDが相互にTCPセッションを張りメッシュ状に通信するため、スイッ
チ上でパケットロスが発生しやすい
 ネットワー...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
まとめ
 private cloud導入の効果
⁃ サーバ運用とネットワーク運用の統合
• ネットワークGへの「依頼」を削減
• アプリケーション、...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
今後の予定
 コンテナ(LXD)の導入
 VM-HAの導入
 ceph以外のSDS、ストレージの導入
 OpenStack自体のバージョンアッ...
Copyright © DeNA Co.,Ltd. All Rights Reserved.
ご静聴ありがとうございました
48
Upcoming SlideShare
Loading in …5
×

DeNA private cloudのその後 #denatechcon

784 views

Published on

DeNA TechCon 2017の登壇資料です。

Published in: Technology
  • Be the first to comment

DeNA private cloudのその後 #denatechcon

  1. 1. Copyright © DeNA Co.,Ltd. All Rights Reserved. DeNA private cloudのその後 Feb 10, 2017 Kengo Sakai IT Platform Dept. System Management Unit DeNA Co., Ltd. DeNA TechCon 2017
  2. 2. Copyright © DeNA Co.,Ltd. All Rights Reserved. 自己紹介  氏名 ⁃ 酒井 憲吾(Sakai Kengo)  入社 ⁃ 2013年7月  所属 ⁃ システム本部IT基盤部  経歴 ⁃ 前職ではネットワーク系の研究開発、ソフトウェア開発 ⁃ DeNAではMYCODEのインフラ構築、運用に携わったのち、現在は private cloudの運用に従事 2
  3. 3. Copyright © DeNA Co.,Ltd. All Rights Reserved. アジェンダ  昨年の発表の振り返り  現在のprivate cloudの状況  SDN: Big Cloud Fabric  LBaaS: Orion(内製BIG-IP用API)  SDS: ceph 3
  4. 4. Copyright © DeNA Co.,Ltd. All Rights Reserved. 昨年の発表の振り返り 4
  5. 5. Copyright © DeNA Co.,Ltd. All Rights Reserved. 振り返り:昨年のDeNA TechCon 5
  6. 6. Copyright © DeNA Co.,Ltd. All Rights Reserved. 6 振り返り:Private Cloud導入のねらい
  7. 7. Copyright © DeNA Co.,Ltd. All Rights Reserved. 振り返り:サーバ運用とネットワーク運用の統合 7
  8. 8. Copyright © DeNA Co.,Ltd. All Rights Reserved. 振り返り:サーバ運用とネットワーク運用の統合 8
  9. 9. Copyright © DeNA Co.,Ltd. All Rights Reserved. 振り返り:サーバ運用とネットワーク運用の統合 9
  10. 10. Copyright © DeNA Co.,Ltd. All Rights Reserved. 振り返り:仮想化基盤の運用改善 10
  11. 11. Copyright © DeNA Co.,Ltd. All Rights Reserved. 振り返り:仮想化基盤の運用改善 11
  12. 12. Copyright © DeNA Co.,Ltd. All Rights Reserved. 振り返り:仮想化基盤の運用改善 12
  13. 13. Copyright © DeNA Co.,Ltd. All Rights Reserved. 振り返り:昨年の発表はここまで 13
  14. 14. Copyright © DeNA Co.,Ltd. All Rights Reserved. 現在のprivate cloudの状況 14
  15. 15. Copyright © DeNA Co.,Ltd. All Rights Reserved. 0 200 400 600 800 1000 1200 1400 1600 1800 2000 1 2 3 4 5 6 7 8 9 10 11 12 1 Instances Production Development 現在のprivate cloudの状況 15 2016 2017 既存の開発環境を private cloudへ移行 Version: liberty Compute Node: 34台 Instance: 1730台 Version: kilo Compute Node: 32台 Instance: 133台 Copyright © 2017 Atlassian Copyright © 2017 Atlassian
  16. 16. Copyright © DeNA Co.,Ltd. All Rights Reserved. private cloudの構成 16 © 2016 Big Switch Networks,Inc. All rights reserved. © 2014 F5 Networks,Inc. All rights reserved. © 2015, Red Hat, Inc. All rights reserved. Production: OpenStack version: kilo OS: Ubuntu 14.04 Development: OpenStack version: liberty OS: Ubuntu 14.04 © 2015, Red Hat, Inc. All rights reserved.© The OpenStack Foundation September 19,2012 © The OpenStack Foundation September 19,2012
  17. 17. Copyright © DeNA Co.,Ltd. All Rights Reserved. 運用がどう変わったか  サーバ運用とネットワーク運用の統合 ⁃ VRF、VLAN、Network ACLの設定 • OpenStack + Big Cloud Fabricでサーバエンジニアが自ら設定可能に ⁃ ロードバランサーの設定 • Orion(内製BIG-IP用API)でサーバエンジニアが自ら設定可能に  仮想化基盤の運用改善 ⁃ Compute Node故障時のVM再構築は不要に • 他のCompute Node上でVMを起動するだけ • VMのイメージはceph storageの中にあるため ⁃ live-migrationも出来るように • 負荷の偏りを均す • 故障予兆時に退避する 17
  18. 18. Copyright © DeNA Co.,Ltd. All Rights Reserved. SDN: Big Cloud Fabric 18
  19. 19. Copyright © DeNA Co.,Ltd. All Rights Reserved. Big Cloud Fabricとは 19  OpenStackとのintegrationにアンダーレイネットワークをサポート  コントローラとスイッチから構成。両者ともLinuxが動作している  GUI/APIが充実
  20. 20. Copyright © DeNA Co.,Ltd. All Rights Reserved. OpenStack + Big Cloud Fabric Integration 20 ! tenant tenant test_project.openstack id 48285b588ec5457f95c38b33a93c45e0 origination openstack ! logical-router route 0.0.0.0/0 next-hop tenant system interface segment net_test ip address 192.0.2.1/24 interface tenant system ! segment net_test id a808b97d-10e1-4f08-b3d3-978b5ae1f07d origination openstack ! endpoint 22accd96-5894-41bc-bd67-57790022a467 attachment-point interface-group osvdev0001 vlan 171 ip 192.0.2.10 mac fa:16:3e:2d:3d:3c origination openstack ! member interface-group osvdev0001 vlan 171 origination openstack Project Router Network OpenStackでネットワーク作成すると、 BCF上にconfigが自動生成されるように インテグレーション
  21. 21. Copyright © DeNA Co.,Ltd. All Rights Reserved. OpenStack + Big Cloud Fabric 構成パターン  P-Fabricのパターンを採用  ただし、L3(OpenStackのRouter)の連携がされない、という仕 様 21
  22. 22. Copyright © DeNA Co.,Ltd. All Rights Reserved. OpenStack + Big Cloud Fabric Integration 22 BCF Controller REST API Controller Node Neutron BCF Plugin L3 Plugin  Neutron(OpenStackのネットワークコンポーネント)のプラグインを 内製で開発  BCF ControllerのREST APIを用いて、L3(Router)の情報を反映  https://github.com/DeNADev/networking-bigswitch-l3-pe で公 開 tenant test_project.openstack logical-router route 0.0.0.0/0 next-hop tenant system interface segment net_test ip address 192.0.2.1/24 interface tenant system Router© 2001-2016 Python Software Foundation. All rights reserved. © 2016 Big Switch Networks,Inc. All rights reserved.
  23. 23. Copyright © DeNA Co.,Ltd. All Rights Reserved. 障害発生! 23
  24. 24. Copyright © DeNA Co.,Ltd. All Rights Reserved. 障害:新規に作ったインスタンスが通信できない  原因:NeutronがインスタンスのPort情報をBCFに反映できなかったため  経緯  BCF pluginでsync処理が頻発する、という不具合が発生  sync処理中は他の処理ができない  Compute Nodeのagentは追加/削除されたPort情報を定期的にNeutronに通知 する。この通知がsync処理のためタイムアウト  通知がタイムアウトするとagentは管理しているPort情報をすべて通知する。こ のためneutronに大量の負荷がかかることになり再度タイムアウト(以下無限ル ープ) 24 BCF Controller REST API Controller Node Neutron BCF Plugin L3 Plugin Compute Node agent Compute Node agent sync © 2016 Big Switch Networks,Inc. All rights reserved.
  25. 25. Copyright © DeNA Co.,Ltd. All Rights Reserved. 障害:新規に作ったインスタンスが通信できない  対応  agentの通知がさばけるまで順にagentを止めていく  通知がさばけた後で順にagentを再度起動していく  BCF pluginの不具合の原因を突き止めてBigSwitch社に報告(修正済み) 25 BCF Controller REST API Controller Node Neutron BCF Plugin L3 Plugin Compute Node agent Compute Node agent © 2016 Big Switch Networks,Inc. All rights reserved.
  26. 26. Copyright © DeNA Co.,Ltd. All Rights Reserved. LBaaS: Orion 26
  27. 27. Copyright © DeNA Co.,Ltd. All Rights Reserved. Orionとは  内製のBIG-IP用 API  開発の背景 ⁃ 以前から使用していたF5のHardware ApplianceをOpenStack環境 でもそのまま使用することとした • 初期コストを抑えるため ⁃ 従来から使っている内製のAPIがあったが、Load Balancerの作成な どには未対応で依頼作業が発生していた ⁃ OpenStack LBaaSv2の仕様では機能不足 • 例えば、SNATの設定ができない ⁃ BIG-IPのrestful APIではアクセス制御の機能が不足 • BIG-IPのrestful APIをcallするにはadmin権限が必要 • 担当外のobjectを操作できないように、アクセス制御を実装する必要がある 27
  28. 28. Copyright © DeNA Co.,Ltd. All Rights Reserved. Orionの構成  ユーザにはorion-cliでの操作を解放  Orionが内製の構成管理DBと連携  構成管理DBはサーバのIPアドレス、使用用途等を管理  Orionがアクセス制御を実装  BIG-IPのパーティション機能を利用 28 BIG-IP iControlRest user Orionorion-cli 構成管理DB JSON-RPC
  29. 29. Copyright © DeNA Co.,Ltd. All Rights Reserved. 使い方: LB作成  OpenStack LBaaSv2の場合  neutron lbaas-loadbalancer-create …  neutron lbaas-listener-create …  neutron lbaas-pool-create …  neutron lbaas-member-create …  neutron lbaas-healthmonitor-create …  orion-cliの場合  orion-cli virtualserver create …  Orionが内部的にLBaaSv2の場合と同等の処理をしている 29
  30. 30. Copyright © DeNA Co.,Ltd. All Rights Reserved. 使い方: Poolメンバ追加  OpenStack LBaaSv2の場合  neutron lbaas-member-create –subnet $SUBNET –address $IP_ADDRESS --protocol-port $PORT $POOL  orion-cliの場合  orion-cli member add –m $HOSTNAME  LB作成時に--pool-usageオプションを指定してpoolを作成しておく  Orionが構成管理DBから必要な情報(IPアドレスや使用用途)を取得し、使 用用途(usage)に紐付いたpool全てに追加してくれる 30 BIG-IP Pool A usage: web Orionorion-cli 構成管理DB Pool B usage: web Pool C usage: dns $HOSTNAME usage: web
  31. 31. Copyright © DeNA Co.,Ltd. All Rights Reserved. アクセス制御  BIG-IPのパーティション機能を 利用  サービスに対応したパーティシ ョンを作成  orion-cliを実行したサーバのサ ービスを元に操作可能なパーテ ィションか判断  サーバへのログインは別途 LDAPで管理 31
  32. 32. Copyright © DeNA Co.,Ltd. All Rights Reserved. SDS: Ceph 32
  33. 33. Copyright © DeNA Co.,Ltd. All Rights Reserved. Cephとは  オープンソースの分散ストレージ  何かトラブルが起きた時に迅速に対応するためには、ソフトウェア の振る舞いを詳細に把握する必要がある  オブジェクトストレージとブロックストレージの両方に対応している  弊社ではブロックストレージとして使用  AWSのEBSのように使える 33
  34. 34. Copyright © DeNA Co.,Ltd. All Rights Reserved. Ceph Storage Clusterの構成  MON  OSDの構成、状態監視を行う。Storage Node上でも動作  OSD  ディスクへのデータの読み書きやデータの冗長化、データの配置の管理を行う  データは複数のOSDにレプリケーションされる(レプリカ数=3で運用)  現在のCeph Storage Cluster(version: 0.94.6 Hammer)  Development: 214 TB / 421 TB  Production: 18 TB / 22 TB 34 Storage Node OSD OSD… Storage Node OSD OSD… Monitor Node MON … Ceph Storage Cluster
  35. 35. Copyright © DeNA Co.,Ltd. All Rights Reserved. Compute Node故障時はどうする?  nova evacuateコマンドでVMを他のCompute Nodeに退避する ⁃ ブロックストレージの内容はそのままに他のCompute Node上で VMが起動する  今後はVirtual Machine High Availability(VM-HA)を導入したい 35 Compute Node Ceph Storage Cluster Compute Node VM VM VM VM VM VM
  36. 36. Copyright © DeNA Co.,Ltd. All Rights Reserved. Compute Nodeの構成  いわゆるハイパーコンバージドな構成  Compute NodeがCephのStorage Nodeも兼ねる  ALL HDD  特に開発環境はコストを抑えるため、8TB 7200rpmのSATA- HDD  性能不足の場合はSSDや他のストレージの導入を検討する 36
  37. 37. Copyright © DeNA Co.,Ltd. All Rights Reserved. やはりI/O性能が問題に!! 37
  38. 38. Copyright © DeNA Co.,Ltd. All Rights Reserved. 問題その1: Compute Nodeのディスクの負荷が高い  OSDはjournal領域、data領域の順に書き込みを行う 38 VM OSD journal data request 当初は同じディスク(SATA-HDD)だった
  39. 39. Copyright © DeNA Co.,Ltd. All Rights Reserved. パフォーマンスチューニング: ジャーナルとデータ領域を一つの物理ディスクに共存させない  ディスクへのI/O負荷を下げるために、ジャーナル領域とデータ領域と は別の物理ディスクに変更 39 あるCompute Nodeのiostatの%util ディスク構成変更 SATA-HDD SAS-HDD SAS-HDD SATA-HDD RAID1 RAID0 RAID0 • Linux root filesystem • OSD.1 journal • OSD.2 journal • OSD.1 Data • OSD.2 Data
  40. 40. Copyright © DeNA Co.,Ltd. All Rights Reserved. 問題その2: VMのI/Oリクエストが数秒〜数十秒待たされる  原因調査が難航  Compute Nodeのディスクの負荷は下がっているので問題ないはず 。  Compute NodeのCPU使用率はだんだん高くなってきているものの 20%以下。数十秒待たされる原因とは考えにくい。  ネットワーク上の問題も特に発生していない。 40 あるCompute NodeのCPU使用率(user)
  41. 41. Copyright © DeNA Co.,Ltd. All Rights Reserved. 原因調査: ログ分析  cephのログとソースコードを詳細に照らし合わせ調査した結果、write request受信直後の処理が遅くなっていそうと判明。  OSDは特定の処理を複数のworker threadで処理する方式。何らかの処理が 詰まってworker threadが枯渇しているのではないかと推測。 41 VM Primary OSD 2nd OSD 3rd OSD write request write response
  42. 42. Copyright © DeNA Co.,Ltd. All Rights Reserved. 原因調査: スレッドダンプからボトルネックを特定  内製のデバッガーを用い、稼働中のceph-osdプロセスにアタッチし、そ の瞬間の各スレッドのバックトレースを取得  worker threadのほとんどがtcmallocの処理で埋まっている状況 42 tcmalloc::CentralFreeList::FetchFromOneSpans(int, void**, void**)(7f51b59e9670+81); tcmalloc::CentralFreeList::RemoveRange(void**, void**, int)(7f51b59e99c0+198); tcmalloc::ThreadCache::FetchFromCentralCache(unsigned long, unsigned long)(7f51b59ec8b0+83); operator new(unsigned long)(7f51b59fc620+232); FileStore::build_op(std::list<ObjectStore::Transaction*, std::allocator<ObjectStore::Transaction*> >&, Context*, Context*, std::tr1::shared_ptr<TrackedOp>)(8e6de0+586); FileStore::queue_transactions(ObjectStore::Sequencer*, std::list<ObjectStore::Transaction*, std::allocator<ObjectStore::Transaction*> >&, std::tr1::shared_ptr<TrackedOp>, ThreadPool::TPHandle*)(8eaf40+832); ReplicatedPG::queue_transaction(ObjectStore::Transaction*, std::tr1::shared_ptr<OpRequest>)(89e5d0+219); void ReplicatedBackend::sub_op_modify_impl<MOSDRepOp, 112>(std::tr1::shared_ptr<OpRequest>)(a0fda0+2330); ReplicatedBackend::sub_op_modify(std::tr1::shared_ptr<OpRequest>)(9fca10+73); ReplicatedBackend::handle_message(std::tr1::shared_ptr<OpRequest>)(9fcb00+910); ReplicatedPG::do_request(std::tr1::shared_ptr<OpRequest>&, ThreadPool::TPHandle&)(8269c0+359); OSD::dequeue_op(boost::intrusive_ptr<PG>, std::tr1::shared_ptr<OpRequest>, ThreadPool::TPHandle&)(695e20+957); OSD::ShardedOpWQ::_process(unsigned int, ceph::heartbeat_handle_d*)(6963d0+824); ShardedThreadPool::shardedthreadpool_worker(unsigned int)(b97ce0+2165); ShardedThreadPool::WorkThreadSharded::entry()(b9a660+16); start_thread(7f51b57b30c0+196); __clone(7f51b3d1c310+109)
  43. 43. Copyright © DeNA Co.,Ltd. All Rights Reserved. パフォーマンスチューニング: tcmallocのスレッドキャッシュサイズを拡張する  tcmallocのキャッシュメモリの獲得、解放にかかるCPU負荷が軽くなる  秒単位で待たされるI/Oリクエストがほぼ無くなる 43 あるCompute NodeのCPU使用率(user) キャッシュサイズ拡張
  44. 44. Copyright © DeNA Co.,Ltd. All Rights Reserved. 課題: fsync問題  fsync/fdatasyncのようなデータ同期が発生すると後続のwriteが待たさ れてしまう  fsyncは例えば、MySQLのトランザクションのコミット処理で使用される  現状のハードウェア構成では根本的な解決は無理と判断  一部のサーバではファイルシステムのバリアオプションを無効にし てこの問題を回避 44 VM Ceph OSD Cluster write request write response VM Ceph OSD Cluster write request write response write request write response fsync 通常時は並列にrequestを送信 fsync中は他のrequestが送信できない
  45. 45. Copyright © DeNA Co.,Ltd. All Rights Reserved. 課題: ネットワークの輻輳  OSDが相互にTCPセッションを張りメッシュ状に通信するため、スイッ チ上でパケットロスが発生しやすい  ネットワークはcephだけでなく他のトラフィックも共有している  例えばTCP接続時のSYNパケットがロスするとサービスにも影響が ある  対策  BCFのQoS機能を使用しCeph以外のトラフィックを優先することを 検証中 45 OSD OSD OSD OSD Switch バーストトラフィックによる パケットロス
  46. 46. Copyright © DeNA Co.,Ltd. All Rights Reserved. まとめ  private cloud導入の効果 ⁃ サーバ運用とネットワーク運用の統合 • ネットワークGへの「依頼」を削減 • アプリケーション、サーバ、ネットワークをone stopでできるように ⁃ 仮想化基盤の運用改善 • Compute Node故障時の対応が簡単に • live-migrationにより柔軟な運用が可能に 46
  47. 47. Copyright © DeNA Co.,Ltd. All Rights Reserved. 今後の予定  コンテナ(LXD)の導入  VM-HAの導入  ceph以外のSDS、ストレージの導入  OpenStack自体のバージョンアップ 47
  48. 48. Copyright © DeNA Co.,Ltd. All Rights Reserved. ご静聴ありがとうございました 48

×