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 UnitDeNA 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 月のセミナー

5https://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


1 2 3 4 5 6 7 8 9 10 11 12 1 2 30

200

400

600

800

1000

1200

1400

1600

1800

2000 ProductionDevelopment

Inst

ance

sprivate 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

! tenanttenant 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 が自動生成されるよう

に

インテグレーション


OpenStack + Big Cloud Fabric 構成パターン

P-Fabric のパターンを採用ただし、 L3 （ OpenStack の Router ）の連携がされない、とい

う仕様

17


OpenStack + Big Cloud Fabric Integration

18

BCF Controller

REST API

Controller Node

neutron-serverBCF 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


https://github.com/DeNADev/networking-bigswitch-l3-pe


障害発生！

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


L3 Plugin

Compute Node

agent

Compute Node

agent

Port

Port

Port

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


L3 Plugin

Compute Node

agent

Compute Node

agent

Port

Port

Port


https://github.com/openstack/neutron/commit/8d29f38356fc5b840fa8b5c31fcd9d76c0fdd336

https://github.com/openstack/neutron/commit/a46e00817a65ac7a55e47f4e4b0b89596d776f8d


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

VMPrimary

OSD2ndOSD

3rdOSD

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 OSDCluster

write request

write response

VM Ceph OSDCluster

write request

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

Technology