gmoインターネットにおけるopenstack...

GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例

1

GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例のご紹介

GMOインターネット株式会社エンジニア郷古直仁テクニカルエバンジェリスト斉藤弘信

OpenStack最新情報セミナー 2015/02/18


[前半: OpenStack Swiftのサービスシステムについて]

・GMOインターネットでのOpenStack Swift利用

・物理構成選択のポイント

・マルチサービスでのインターフェース

・継続的運用とversion up

・インフラ上の今後の課題

[後半: オブジェクトストレージ利用動向について]

・ConoHaについて

・ConoHaオブジェクトストレージ

・利用動向について

2

アジェンダ


3

まずは自己紹介

• 郷古直仁 (ゴウコナオト, Naoto Gohko)

– Twitter: @naoto_gohko

– Facebook: http://www.facebook.com/gohko

• 所属: GMOインターネット株式会社

• 部署: システム本部第2サービス開発部

• なにをしているのか: GMOグループ内のOpenStackに関するインテグレーションチーム

• 関わっているもの:

– お名前.com VPS KVM(OpenStack Diablo環境)

– GMOアプリクラウド(OpenStack Havana環境)

– ConoHa VPS(OpenStack Grizzly環境)

– オブジェクトストレージ (OpenStack Juno release ver.)

>> GMOアプリクラウド (Keystone Havana)

>> ConoHa (Keystone Grizzly)


GMOアプリクラウドとは

• ソーシャルゲームをターゲット中心に、VLAN, LB, PKIなど必要な機能を搭載した、ゲーム専用クラウド

• 最新環境はOpenStack Havanaで提供(API)

• 大規模利用可能なクラウドストレージ用途として、OpenStack Swiftを提供(2014/4/22~)


GMOアプリクラウド OpenStack Tenant NW


GMOアプリクラウド OpenStack Swift NW


ConoHaとは

• 技術者やスタートアップ企業向けのVPSサービス

• OpenStack Grizzly

• クラウドストレージ用途での、オブジェクトストレージOpenStack Swiftを「GMOアプリクラウド」での提供開始後に、提供開始 (2014/09/03~)


GMOアプリクラウド、ConoHaデュアルヘッド

• 一般公開したOpenStack Swift

– 企業向けのGMOアプリクラウド

– コンシューマ向け的なConoHa

• トラフィック利用形態が異なりそうな複数のサービスでPublic利用を提供

• 運用側としては、様々な利用が考えられるConoHaをベースにHardware構成を考えていく


物理構成選択のポイント 1)

• まずは、情報集め

– 利用形態が似た案件での物理構成を調べる

– NTT Data 梶波崇さんの Swift発表 (July Tech Festa 2013, 産業技術大学)

>> SSDの使い方について

– Rackspace Object Storage (OpenStack summit Hong Kong,

2013/11)>> SSDの利用、Hard構成

Hong KongのOpenStack summit (2013/11)に参加できた>> ちょうど、Hardwareの内容がちょっと出たのを、現地で聞けた


物理構成選択のポイント 1) rackspace参考

https://www.openstack.org/assets/presentation-media/Swift-

at-Scale.pdf

(rackspace発表資料)

https://www.openstack.org/summit/openstack-summit-hong-

kong-2013/session-videos/presentation/an-intimate-look-at-

running-openstack-swift-at-scale

“An Intimate Look at Running Openstack Swift at Scale”

>> rackspaceはCDNとの接続(SOS middleware)によって、配信向けのトラフィックを分割する仕組み

https://www.openstack.org/assets/presentation-media/Swift-at-Scale.pdf

https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/an-intimate-look-at-running-openstack-swift-at-scale


物理構成選択のポイント 1) rackspace構成

Hardware

• (old) 24 x 1TB drives / box, 1Gbps network

• 90 x 3TB drives / box, 10Gbps network

• SSD drives for Account/Containers

– AccountとContainerは所詮分散DatabaseであるのでIO重視

– SSDが重要であることは、かなりアピールされた

• Commodity SATA drives

Network

• 10Gbps to host

ここまではヒントが分かったが、実際どのようにSSDとHDDとCPUを配置すればよいのだろうか?


物理構成選択のポイント 2) test: GMO構成A)

>> 結局はやってみるしか無い

稼働前test: 構成A)

Hardware: Storage Node:

• 12 x 4TB drives (3Gbps SATA) / box

• 10 Gbps network

• CPU E3-1230 v3 3.3GHz (4 core, 8HT)

• memory 16 GB

• SSD 2 drives

– OS boot (RAID 1)/Account/Containers

• Commodity SATA drives

Proxy Node:

• CPU E5620(4 core, 8HT) x2(cpu)

• memory 64 GB


物理構成選択のポイント 2) test: 構成A)


物理構成選択のポイント 2) test GMO構成A)

swift proxy

keystone

OpenStack Havana (5 zones, 3 copy)

swift proxy

keystoneLVS-DSrLVS-DSR HAProxy(SSL)HAProxy(SSL)

swift account

swift container

swift objects

swift account

swift container

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container

swift objects

swift account

swift container

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container

swift objects

swift account

swift container

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container

swift objects

swift account

swift container

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container

swift objects

swift account

swift container

swift objects

Xeon E3-1230 3.3GHz

Xeon E3-1230 3.3GHz

Memory 16GB

Xeon E3-1230 3.3GHz

Memory 16GB

Xeon E5620 2.4GHz x 2CPU

Memory 64GB


物理構成選択のポイント 2) test: 構成A)問題点

>> 結局はやってみる << 色々浮かび上がってくる

稼働前test: 構成A)

Account / Containersの分散DatabaseをStorage Nodeと兼用でスケールアウトさせるつもりの構成だったが... ...

Hardware: Storage Node:

>> CPU E3-1230 v3 3.3GHz (4 core, 8HT)

>> このCPUがAccount / Containers の分散Databaseには性能不足だった

>> swiftbench負荷中、cpu loadが上昇して遅くなる

Proxy Node:

• CPU E5620(4 core, 8HT) x2(cpu)

• memory 64 GB

こちらのボトルネックは無かった


物理構成選択のポイント 2) test: 構成B)

>> Database アクセスだけの Account / Containerサーバプロセスのアクセスと Storage アクセスが同じNetworkに入るのも良くなさそう

>> Account / Container サーバの分離構成B) に変更

追加Hardware: Account-Container-DBサーバ

• E5620(4core, 8HT) x 2CPU

• SSD x 2 (単体で利用)

• Memory 24GB


物理構成選択のポイント 2) test GMO構成B)

swift proxy

keystone

OpenStack Havana (5 zones, 3 copy)

swift proxy

keystoneLVS-DSrLVS-DSR HAProxy(SSL)HAProxy(SSL)

Xeon E3-1230 3.3GHz

Memory 16GB

Xeon E3-1230 3.3GHz

Memory 16GB


Memory 64GB

swift objects

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container


Memory 64GB, SSD x 2

swift objects

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container



swift objects

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container



swift objects

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container



swift objects

swift objects

Xeon E3-1230 3.3GHz

swift account

swift container




物理構成選択のポイント 2) test: GMO構成B)

>> よさそう

これが最終的な物理構成配置になる

>> 物理構成がだいたい決定

• CPUスレッド分に分割されるにしても、適度な安価なハードを選択

• ハードの世代が変わってもあまり気にしないようにする


物理構成選択のポイント 3) Scale

スケールさせる単位

• HAProxy reverse proxy (connection, TPS, Memory)

• swift-proxy (connection, TPS, Memory, CPU)

• swift-container-server, swift-account-server

(同居) (SSD IOと容量, TPS, CPU)

• swift-object-server (CPU, HDD容量)

• keystone, keystone DB (auth TPS, CPU)

– swift clientの種類により、毎回tokenを取りに来たりする

– ここが意外と致命的。swiftclient (python)と同じ実装だと、まさにこの状態

– スケールupも含めて実行を検討


物理構成選択のポイント 3) 最近のScale

>> keystoneがまずボトルネックになって、まず対策実施(scale up)

(2014/12ごろ)

>> vmで構成されていたので、memory, CPUを増やす

ストレージノードのScaleはまだ必要なさそう (利用率 10%)


もともとGMOアプリクラウドがあったSwift環境:

ConoHaサービス用に、あとからswift-proxy などのFrontを追加

account DB 的には問題なさそう

マルチサービスのインターフェース

swift proxy keystone swift proxy keystone

swift objectsswift objects





Havana Grizzly

Havanaswift account

swift container

swift account

swift container

swift account

swift container

swift account

swift container

swift account

swift container


account DB 的には問題なさそう

<< Swiftの仕組み上、tenant_idからなるaccount IDがかぶらない限り問題無い

https://swift.example.com/v1/account/container/object

Storage location: /account/container/object

/account

アカウントメタデータ階層

含まれるcontainerの内容

/account/container

コンテナのメタデータ階層

含まれるobjectの内容

/account/container/object

objectデータ

objectのメタデータ



容量課金

>> ceilometerからのpolling (容量check)

リクエスト数課金

Ceilometer (swift-proxy server)

>> 改造: ConoHa, GMOAppsCloud別々に ceilometer-log出力

td-agent (swift-proxy server)

>> ceilometer-logからrequest count

>> ceilometer mongodbにデータ投入


swift proxy keystone swift proxy keystone






Havana Grizzly

Havanaswift account

swift container

swift account

swift container

swift account

swift container

swift account

swift container

swift account

swift container


マルチサービスのインターフェースceilometer-log の一部


継続的運用とバージョンup

Juno release

>> OpenStack Swift version 2.2

( >> current ver. 2.2.2 )

Storage Policiesなどの新機能

Swift環境構築時: Havana (ver. 1.8.0, [1.10.0])

Juno向け開発を始めるにあたり、まずはバージョンアップを実施


継続的運用とバージョンup: el6-RPMS build

Juno release

>> OpenStack Swift version 2.1

Juno RDO pkgは el7 (RHEL 7, CentOS 7)でしか提供されない

>> python 2.7 over

Havana環境は el6 (CentOS 6.5)

>> python 2.6

>> Juno release Swiftにするには、el6用RPMのbuildが必要

>> どうしたのか?



Icehouse release

>> el6用のRDO builded pkgがある

Icehouse el6 RDO pkgのSPEC file

Juno el7 RDO pkg sources

Juno el6 swift RPMSをbuild

>> 超絶しんどい、でもやりました



Juno release swift 2.2 el6


継続的運用とバージョンup: update

yum local repositoryをたてる

>> あとは、swiftのupgrade tipsにしたがって更新する

1) swift-proxy の冗長片系ずつ更新 (yum update)

2) swift-container/account server のzoneごとの更新 (yum update)

3) swift-object server のzoneごとの更新

4) 追加サービス(swift-container-reconciler など)を設定して起動

これで、Havana(1.8.0)からJuno(2.2.0)のswift にupgrade

>> もちろん、テスト環境でupgradeの検証をしてから、本番に投入


継続的運用とバージョンup: 今後

Kilo以降の開発は確実に python 2.7以降の検証しかされてない

>> python 2.6で動くかどうかは、確実に機能テストをしてから適用するべき

CentOS6 SCL pkg repositoryの存在:

python27, python33

>> こちらで動作するものに移行するかどうかは、今後検討

>> RDO-el7からRDO-el6-python27をbuildするには、systemdをinit.dにバックポートする必要がある

>> 片系づつ、OSを今後切り替えるかもしれない


インフラ上の今後の課題と展望

Swiftを継続的に運用する上で、以下の展望と課題がある

• Swiftのモジュール対応– Container sync middleware対応が、バグに引っかかってできていない

http://docs.openstack.org/developer/swift/overview_container_sync.html• Storage nodeの削除同期でエラーで先に進まなくなる

– SOS (Swift Origin Server) middleware対応

https://github.com/dpgoetz/sos• ドキュメントがあんまりない。ソースコード読めなのね

• Swift gateway対応– static-web HTTP/HTTPS/HTTP2.0(SPDY) gateway

– sftp gateway (API使わなくてもできるなど)

• マルチリージョン対応、Storage Policies対応– sheepdog + swift front

– ZFS + Swift-on-file + swift front

gmoインターネットにおけるopenstack...

Technology