Más contenido relacionado
La actualidad más candente (20)
Similar a DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月) (20)
Más de VirtualTech Japan Inc. (20)
DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)
- 1. Copyright © DeNA Co.,Ltd. All Rights Reserved.
DeNA private cloudのその後
Mar 29, 2017
Kengo Sakai
IT Platform Dept.
System Management Unit
DeNA Co., Ltd.
OpenStack最新情報セミナー(2017年3月)
- 2. Copyright © DeNA Co.,Ltd. All Rights Reserved.
自己紹介
氏名
⁃ 酒井 憲吾(Sakai Kengo)
所属
⁃ 株式会社ディー・エヌ・エー システム本部IT基盤部
経歴
⁃ 前職ではネットワーク系の研究開発、ソフトウェア開発
⁃ DeNAでは遺伝子検査サービス MYCODEのインフラ構築、運用に携
わったのち、現在はprivate cloudの運用に従事
2
- 3. Copyright © DeNA Co.,Ltd. All Rights Reserved.
アジェンダ
2015年12月の発表の振り返り
現在のprivate cloudの状況
SDN: Big Cloud Fabric
SDS: Ceph
3
- 5. Copyright © DeNA Co.,Ltd. All Rights Reserved.
振り返り:2015年12月のセミナー
5
https://www.slideshare.net/VirtualTech-JP/dena-openstack-201512
- 11. Copyright © DeNA Co.,Ltd. All Rights Reserved.
private cloudの構成
11
© 2016 Big Switch Networks,Inc. All rights reserved.
© 2014 F5 Networks,Inc. All rights reserved.
© 2015, Red Hat, Inc. All rights reserved.
Production:
version: kilo
OS: Ubuntu 14.04
Development:
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
OpenStack Component: Keystone, Glance, Nova, Neutron, Cinder, Ironic
- 12. 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 2 3
Instances
Production
Development
private cloudのインスタンス数の推移
12
2016 2017
既存の開発環境を
private cloudへ移行
Compute Node: 36台
Instance: 1786台
Compute Node: 36台
Instance: 144台
Copyright © 2017 Atlassian
Copyright © 2017 Atlassian
- 13. Copyright © DeNA Co.,Ltd. All Rights Reserved.
運用がどう変わったか
サーバ運用とネットワーク運用の統合
⁃ VRF、VLAN、Network ACLの設定
• OpenStack + Big Cloud Fabricでサーバエンジニアが自ら設定可能に
ストレージサービス
⁃ Compute Node故障時のVM再構築は不要に
• 他のCompute Node上でVMを起動するだけ
• VMのイメージはceph storageの中にあるため
⁃ live-migrationも出来るように
• 負荷の偏りを均す
• 故障予兆時に退避する
13
- 15. Copyright © DeNA Co.,Ltd. All Rights Reserved.
Big Cloud Fabricとは
15
OpenStackとのintegrationにアンダーレイネットワークをサポート
コントローラとスイッチから構成。両者ともLinuxが動作している
GUI/APIが充実
- 16. Copyright © DeNA Co.,Ltd. All Rights Reserved.
OpenStack + Big Cloud Fabric Integration
16
! 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が自動生成されるように
インテグレーション
- 17. Copyright © DeNA Co.,Ltd. All Rights Reserved.
OpenStack + Big Cloud Fabric 構成パターン
P-Fabricのパターンを採用
ただし、L3(OpenStackのRouter)の連携がされない、という仕
様
17
- 18. Copyright © DeNA Co.,Ltd. All Rights Reserved.
OpenStack + Big Cloud Fabric Integration
18
BCF Controller
REST API
Controller Node
neutron-server
BCF Plugin
L3 Plugin
Neutronプラグインを内製で開発
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
© 2016 Big Switch Networks,Inc. All rights reserved.
- 20. Copyright © DeNA Co.,Ltd. All Rights Reserved.
障害:新規に作ったインスタンスが通信できない
原因:neutron-serverがインスタンスのPort情報をBCFに反映できなかったため
経緯
BCF pluginでsync処理が頻発する、という不具合が発生
sync処理中は他の処理ができない
Compute Nodeのneutron-openvswitch-agentは追加/削除されたPort情報を
定期的にneutron-serverに通知する。この通知がsync処理のためタイムアウト
通知がタイムアウトするとneutron-openvswitch-agentは管理しているPort情
報をすべて通知する。このためneutronに大量の負荷がかかることになり再度タ
イムアウト(以下無限ループ)
20
BCF Controller
REST API
Controller Node
neutron-server
BCF Plugin
L3 Plugin
Compute Node
agent
Compute Node
agent
sync © 2016 Big Switch Networks,Inc. All rights reserved.
- 21. Copyright © DeNA Co.,Ltd. All Rights Reserved.
障害:新規に作ったインスタンスが通信できない
対応
neutron-openvswitch-agentの通知がさばけるまで順にneutron-
openvswitch-agentを止めていく
この時使用していたneutron-openvswitch-agent(liberty)は起動時にインスタ
ンスのパケットがロスする問題があったため、以下のパッチを適用
Cleanup stale OVS flows for physical bridges
Don't disconnect br-int from phys br if connected
neutron-openvswitch-agentを再度起動していく
BCF pluginの不具合の原因を突き止めてBigSwitch社に報告(修正済み)
21
BCF Controller
REST API
Controller Node
neutron-server
BCF Plugin
L3 Plugin
Compute Node
agent
Compute Node
agent
© 2016 Big Switch Networks,Inc. All rights reserved.
- 23. Copyright © DeNA Co.,Ltd. All Rights Reserved.
Cephとは
オープンソースの分散ストレージ
何かトラブルが起きた時に迅速に対応するためには、ソフトウェアの振る舞い
を詳細に把握する必要がある
構成
MON : OSDの構成、状態監視。Storage Node上でも動作
OSD : ディスクへのデータの読み書きやデータのレプリケーション、データの
配置の管理
現在のCeph Storage Cluster(version: 0.94.6 Hammer)
Development: 225 TB / 421 TB
Production: 19 TB / 25 TB
23
Storage Node
OSD OSD…
Storage Node
OSD OSD…
Monitor Node
MON …
Ceph Storage Cluster
- 24. Copyright © DeNA Co.,Ltd. All Rights Reserved.
Compute Nodeの構成
いわゆるハイパーコンバージドな構成
Compute NodeがCephのStorage Nodeも兼ねる
ALL HDD
特に開発環境はコストを抑えるため、8TB 7200rpmのSATA-
HDD
性能不足の場合はSSDや他のストレージの導入を検討する方針でス
タート
24
- 26. Copyright © DeNA Co.,Ltd. All Rights Reserved.
問題その1: Compute Nodeのディスクの負荷が高い
OSDはjournal領域、data領域の順に書き込みを行う
26
VM OSD journal data
request
当初は同じディスク(SATA-HDD)だった
- 27. Copyright © DeNA Co.,Ltd. All Rights Reserved.
パフォーマンスチューニング:
ジャーナルとデータ領域を一つの物理ディスクに共存させない
ディスクへのI/O負荷を下げるために、ジャーナル領域とデータ領域と
は別の物理ディスクに変更
27
ある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
- 28. Copyright © DeNA Co.,Ltd. All Rights Reserved.
問題その2: VMのI/Oリクエストが数秒〜数十秒待たされる
原因調査が難航
Compute Nodeのディスクの負荷は下がっているので問題ないはず。
Compute NodeのCPU使用率はだんだん高くなってきているものの20%以下。
数十秒待たされる原因とは考えにくい。
ネットワーク上の問題も特に発生していない。
28
あるCompute NodeのCPU使用率(user)
[WRN] slow request 15.012665 seconds old, … currently waiting for subops from 26,28
- 29. Copyright © DeNA Co.,Ltd. All Rights Reserved.
原因調査: ログ分析
cephのログとソースコードを詳細に照らし合わせ調査した結果、write
request受信直後の処理が遅くなっていそうと判明。
OSDは特定の処理を複数のworker threadで処理する方式。何らかの処理が
詰まってworker threadが枯渇しているのではないかと推測。
29
VM
Primary
OSD
2nd
OSD
3rd
OSD
write request
write response
- 30. Copyright © DeNA Co.,Ltd. All Rights Reserved.
原因調査: スレッドダンプからボトルネックを特定
内製のデバッガーを用い、稼働中のceph-osdプロセスにアタッチし、そ
の瞬間の各スレッドのバックトレースを取得
worker threadのほとんどがtcmallocの処理で埋まっている状況
30
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)
- 31. Copyright © DeNA Co.,Ltd. All Rights Reserved.
パフォーマンスチューニング:
tcmallocのスレッドキャッシュサイズを拡張する
tcmallocのキャッシュメモリの獲得、解放にかかるCPU負荷が軽くなる
秒単位で待たされるI/Oリクエストがほぼ無くなる
31
あるCompute NodeのCPU使用率(user)
キャッシュサイズ拡張
- 32. Copyright © DeNA Co.,Ltd. All Rights Reserved.
課題: fsync問題
fsync/fdatasyncのようなデータ同期が発生すると後続のwriteが待たさ
れてしまう
fsyncは例えば、MySQLのトランザクションのコミット処理で使用される
現状のハードウェア構成では根本的な解決は無理と判断
一部のサーバではファイルシステムのバリアオプションを無効にし
てこの問題を回避
32
VM Ceph OSD
Cluster
write request
write response
VM Ceph OSD
Cluster
write request
write response
write request
write response
fsync
通常時は並列にrequestを送信 fsync中は他のrequestが送信できない
- 33. Copyright © DeNA Co.,Ltd. All Rights Reserved.
課題: ネットワークの輻輳
OSDが相互にTCPセッションを張りメッシュ状に通信するため、スイッ
チ上でパケットロスが発生しやすい
ネットワークはcephだけでなく他のトラフィックも共有している
例えばTCP接続時のSYNパケットがロスするとサービスにも影響が
ある
対策
BCFのQoS機能を使用しCeph以外のトラフィックを優先することを
検証中
33
OSD OSD OSD OSD
Switch
バーストトラフィックによる
パケットロス
- 34. Copyright © DeNA Co.,Ltd. All Rights Reserved.
まとめ
private cloud導入の効果
⁃ サーバ運用とネットワーク運用の統合
• ネットワークGへの「依頼」を削減
• アプリケーション、サーバ、ネットワークをone stopでできるように
⁃ ストレージサービス
• Compute Node故障時の対応が簡単に
• live-migrationにより柔軟な運用が可能に
今後の予定
⁃ ストレージの改善
⁃ VM-HAの導入
⁃ OpenStack Upgrade (from kilo/liberty to mitaka)
34