DeNA private cloudのその後 #denatechcon

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

自己紹介
 氏名
⁃ 酒井憲吾（Sakai Kengo）
 入社
⁃ 2013年7月
 所属
⁃ システム本部IT基盤部
 経歴
⁃ 前職ではネットワーク系の研究開発、ソフトウェア開発
⁃ DeNAではMYCODEのインフラ構築、運用に携わったのち、現在は
private cloudの運用に従事
2

アジェンダ
 昨年の発表の振り返り
 現在のprivate cloudの状況
 SDN: Big Cloud Fabric
 LBaaS: Orion（内製BIG-IP用API）
 SDS: ceph
3

昨年の発表の振り返り
4

振り返り：昨年のDeNA TechCon
5

6
振り返り：Private Cloud導入のねらい

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

8

9

振り返り：仮想化基盤の運用改善
10

11

12

振り返り：昨年の発表はここまで
13

現在のprivate cloudの状況
14

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

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

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

SDN: Big Cloud Fabric
18

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

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
!
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）の連携がされない、という仕
様
21

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.

障害発生！
23

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

障害：新規に作ったインスタンスが通信できない
 対応
 agentの通知がさばけるまで順にagentを止めていく
 通知がさばけた後で順にagentを再度起動していく
 BCF pluginの不具合の原因を突き止めてBigSwitch社に報告（修正済み)
25
BCF Controller
REST API
Controller Node
Neutron
BCF Plugin
L3 Plugin
Compute Node
agent
Compute Node
agent

LBaaS: Orion
26

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

Orionの構成
 ユーザにはorion-cliでの操作を解放
 Orionが内製の構成管理DBと連携
 構成管理DBはサーバのIPアドレス、使用用途等を管理
 Orionがアクセス制御を実装
 BIG-IPのパーティション機能を利用
28
BIG-IP
iControlRest
user
Orionorion-cli
構成管理DB
JSON-RPC

使い方: 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

使い方: 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

アクセス制御
 BIG-IPのパーティション機能を
利用
 サービスに対応したパーティシ
ョンを作成
 orion-cliを実行したサーバのサ
ービスを元に操作可能なパーテ
ィションか判断
 サーバへのログインは別途
LDAPで管理
31

SDS: Ceph
32

Cephとは
 オープンソースの分散ストレージ
 何かトラブルが起きた時に迅速に対応するためには、ソフトウェア
の振る舞いを詳細に把握する必要がある
 オブジェクトストレージとブロックストレージの両方に対応している
 弊社ではブロックストレージとして使用
 AWSのEBSのように使える
33

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

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

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

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

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

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

問題その2: VMのI/Oリクエストが数秒〜数十秒待たされる
 原因調査が難航
 Compute Nodeのディスクの負荷は下がっているので問題ないはず
。
 Compute NodeのCPU使用率はだんだん高くなってきているものの
20%以下。数十秒待たされる原因とは考えにくい。
 ネットワーク上の問題も特に発生していない。
40
あるCompute NodeのCPU使用率(user)

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

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

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

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

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

まとめ
 private cloud導入の効果
⁃ サーバ運用とネットワーク運用の統合
• ネットワークGへの「依頼」を削減
• アプリケーション、サーバ、ネットワークをone stopでできるように
⁃ 仮想化基盤の運用改善
• Compute Node故障時の対応が簡単に
• live-migrationにより柔軟な運用が可能に
46

今後の予定
 コンテナ（LXD）の導入
 VM-HAの導入
 ceph以外のSDS、ストレージの導入
 OpenStack自体のバージョンアップ
47

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

DeNA private cloudのその後 #denatechcon

More Related Content

What's hot

Similar to DeNA private cloudのその後 #denatechcon

More from DeNA

DeNA private cloudのその後 #denatechcon