DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)

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月)

自己紹介
 氏名
⁃ 酒井憲吾（Sakai Kengo）
 所属
⁃ 株式会社ディー・エヌ・エーシステム本部IT基盤部
 経歴
⁃ 前職ではネットワーク系の研究開発、ソフトウェア開発
⁃ DeNAでは遺伝子検査サービス MYCODEのインフラ構築、運用に携
わったのち、現在はprivate cloudの運用に従事
2

アジェンダ
 2015年12月の発表の振り返り
 現在のprivate cloudの状況
 SDN: Big Cloud Fabric
 SDS: Ceph
3

2015年12月の発表の振り返り
4

振り返り：2015年12月のセミナー
5
https://www.slideshare.net/VirtualTech-JP/dena-openstack-201512

振り返り：サーバ運用とネットワーク運用の統合
6

振り返り：サーバ運用とネットワーク運用の統合
7

振り返り：ストレージサービス
8

振り返り：ストレージサービス
9

現在のprivate cloudの状況
10

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

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

運用がどう変わったか
 サーバ運用とネットワーク運用の統合
⁃ VRF、VLAN、Network ACLの設定
• OpenStack + Big Cloud Fabricでサーバエンジニアが自ら設定可能に
 ストレージサービス
⁃ Compute Node故障時のVM再構築は不要に
• 他のCompute Node上でVMを起動するだけ
• VMのイメージはceph storageの中にあるため
⁃ live-migrationも出来るように
• 負荷の偏りを均す
• 故障予兆時に退避する
13

SDN: Big Cloud Fabric
14

Big Cloud Fabricとは
15
 OpenStackとのintegrationにアンダーレイネットワークをサポート
 コントローラとスイッチから構成。両者ともLinuxが動作している
 GUI/APIが充実

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
!
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
!
member interface-group osvdev0001 vlan 171
Project
Router
Network
OpenStackでネットワーク作成すると、
BCF上にconfigが自動生成されるように
インテグレーション

OpenStack + Big Cloud Fabric 構成パターン
 P-Fabricのパターンを採用
 ただし、L3（OpenStackのRouter）の連携がされない、という仕
様
17

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

障害発生！
19

障害：新規に作ったインスタンスが通信できない
 原因：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.

障害：新規に作ったインスタンスが通信できない
 対応
 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

SDS: Ceph
22

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

Compute Nodeの構成
 いわゆるハイパーコンバージドな構成
 Compute NodeがCephのStorage Nodeも兼ねる
 ALL HDD
 特に開発環境はコストを抑えるため、8TB 7200rpmのSATA-
HDD
 性能不足の場合はSSDや他のストレージの導入を検討する方針でス
タート
24

やはりI/O性能が問題に！！
25

問題その1: Compute Nodeのディスクの負荷が高い
 OSDはjournal領域、data領域の順に書き込みを行う
26
VM OSD journal data
request
当初は同じディスク(SATA-HDD)だった

パフォーマンスチューニング:
ジャーナルとデータ領域を一つの物理ディスクに共存させない
 ディスクへの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

問題その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

原因調査: ログ分析
 cephのログとソースコードを詳細に照らし合わせ調査した結果、write
request受信直後の処理が遅くなっていそうと判明。
 OSDは特定の処理を複数のworker threadで処理する方式。何らかの処理が
詰まってworker threadが枯渇しているのではないかと推測。
29
VM
Primary
OSD
2nd
OSD
3rd
OSD
write request
write response

原因調査: スレッドダンプからボトルネックを特定
 内製のデバッガーを用い、稼働中の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)

パフォーマンスチューニング:
tcmallocのスレッドキャッシュサイズを拡張する
 tcmallocのキャッシュメモリの獲得、解放にかかるCPU負荷が軽くなる
 秒単位で待たされるI/Oリクエストがほぼ無くなる
31
あるCompute NodeのCPU使用率(user)
キャッシュサイズ拡張

課題: 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が送信できない

課題: ネットワークの輻輳
 OSDが相互にTCPセッションを張りメッシュ状に通信するため、スイッ
チ上でパケットロスが発生しやすい
 ネットワークはcephだけでなく他のトラフィックも共有している
 例えばTCP接続時のSYNパケットがロスするとサービスにも影響が
ある
 対策
 BCFのQoS機能を使用しCeph以外のトラフィックを優先することを
検証中
33
OSD OSD OSD OSD
Switch
バーストトラフィックによる
パケットロス

まとめ
 private cloud導入の効果
⁃ サーバ運用とネットワーク運用の統合
• ネットワークGへの「依頼」を削減
• アプリケーション、サーバ、ネットワークをone stopでできるように
⁃ ストレージサービス
• Compute Node故障時の対応が簡単に
• live-migrationにより柔軟な運用が可能に
 今後の予定
⁃ ストレージの改善
⁃ VM-HAの導入
⁃ OpenStack Upgrade (from kilo/liberty to mitaka)
34

ご静聴ありがとうございました
35

DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)

More Related Content

What's hot

Viewers also liked

Similar to DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)

More from VirtualTech Japan Inc.

Recently uploaded

DeNA private cloud のその後 - OpenStack最新情報セミナー(2017年3月)