2015 0228 OpenStack swift; GMO Internet Services

Copyright (c) 2014 GMO Internet, Inc. All Rights Reserved.

OSC Tokyo 2015/Spring 2015-02-28

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

その利用事例のご紹介

GMOインターネット株式会社エンジニア郷古　直仁

テクニカルエバンジェリスト斉藤　弘信


[前半: OpenStack Swiftのサービスシステムについて] ・オブジェクトストレージとは? ・GMOインターネットでのOpenStack Swift利用・物理構成選択のポイント・マルチサービスでのインターフェース・継続的運用とversion up ・インフラ上の今後の課題 [後半: オブジェクトストレージ利用について] ・ひろのぶさんに (?・・)ル(^^*)ノタッチ

2

アジェンダ


自己紹介 •  郷古直仁(@naoto_gohko)

•  所属:GMOインターネットシステム本部第二サービス開発部オープンコンピューティングチーム

•  ConoHaサービスの開発運用、 GMOアプリクラウドのサービスの開発運用、お名前.com VPS KVMの運用など、クラウド系サービスのお仕事、 OpenStack関係

•  Ingressは… 緑だけど…


自己紹介

•  美雲このは(@MikumoConoHa) •  クラウドのようなVPS「ConoHa」の応援団長

•  データセンターの座敷童子

•  年齢: 13歳くらい？

•  身長: 150cm＋α

•  https://www.conoha.jp/blog/conoha

オブジェクトストレージとは? •  ファイルオブジェクトの格納場所はコンテナ(バケット)などの格納領域の中にフラットに配置される •  ファイルシステムなどに見られるディレクトリ構造とは対照的

•  オブジェクトの格納されるストレージ領域は冗長性と分散性を持つ •  レプリカの数やキャッシュの工夫によりwebの配信エンジンとしての利用も

•  アクセスにはRESTfulなwebの仕組みを利用する場合がほとんど •  メタデータのアクセスにhttpを利用


解りづらい~_~;


冗長化されたクラウドストレージとして l  バックアップストレージ l  クラウドアプリケーションからのデータ保存領域 l  fluentdによるログ保存 l  Hadoop Map-Reduceストレージ Web配信サーバーとして l  CMSからの画像配信サーバー l  写真ownCloudなどでの写真置き場 l  ストリーミングデータサーバ

そのような利用がされるOSS: >> OpenStack Swift

じゃ、どんなことに使えんの？


OpenStack Swiftとは? •  オブジェクトの格納領域はAccount, Container, Objectの3サービスにより管理される

•  Swift Proxyサービスがオブジェクトの保存情報をAccount, Containerに保存、実オブジェクトはObjectサービスに保存

•  認証サービスには主にKeystoneを利用する •  メタデータなどの機能pluginはSwift Proxyに入れることで、機能が拡張できる

•  システムの独立性が高いので、メジャーバージョンアップしやすい

•  SoftLayer, HPCloud, CloudVPS rackspace cloudfiles などと共通

•  << ここ、意外と重要

swift proxy

swift account

swift container

swift objects swift objects

keystone

swift proxy keystone

swift account

swift container


plugin ratelimit

plugin s3swift

plugin static web

plugin … …


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)によって、配信向けのトラフィックを分割する仕組み


物理構成選択のポイント 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

keystone LVS-DSr LVS-DSR HAProxy(SSL) HAProxy(SSL)

swift account swift container swift objects


Xeon E3-1230 3.3GHz



Xeon E3-1230 3.3GHz



Xeon E3-1230 3.3GHz



Xeon E3-1230 3.3GHz



Xeon E3-1230 3.3GHz

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

keystone LVS-DSr LVS-DSR HAProxy(SSL) HAProxy(SSL)



Xeon E5620 2.4GHz x 2CPU Memory 64GB

swift objects

swift objects

Xeon E3-1230 3.3GHz

swift account swift container

Xeon E5620 2.4GHz x 2CPU Memory 64GB, SSD x 2

swift objects

swift objects

Xeon E3-1230 3.3GHz



swift objects

swift objects

Xeon E3-1230 3.3GHz



swift objects

swift objects

Xeon E3-1230 3.3GHz



swift objects

swift objects

Xeon E3-1230 3.3GHz




物理構成選択のポイント 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 objects swift objects swift objects swift objects swift objects swift objects swift objects swift objects swift objects swift objects

Havana Grizzly

Havana swift 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 l  /account l  アカウントメタデータ階層 l  含まれるcontainerの内容

l  /account/container l  コンテナのメタデータ階層 l  含まれるobjectの内容

l  /account/container/object l  objectデータ l  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

Havana swift 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が必要 >> どうしたのか?


継続的運用とバージョンup: el6-RPMS build Icehouse release >> el6用のRDO builded pkgがある Icehouse el6 RDO pkgのSPEC file Juno el7 RDO pkg sources Juno el6 swift RPMSをbuild >> 超絶しんどい、でもやりました


継続的運用とバージョンup: el6-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


OpenStack Swift環境で使われているOpenSource Toolsたち


HAProxy 1.5: SSL terminate


nginx: (keystone API;reverse proxy)


Object StorageのSwiftってどうやって使うの＞＜


私の利用例 01: WordPress pluginからFull backup; UpdraftPlus •  WordPressのpluginでweb, DBのfull backupがObject Storageに取得できるplug in

http://updraftplus.com •  plug inを入れて設定のみ Full backupなので、 siteの複製にも使えます •  URLが変わる場合には WordPressではfull pathで記載されるので注意が必要

•  他にもrackspace対応のものがあるので探してみると良い


私の利用例 02: ownCloud •  Dropboxのように使えるownCloud serverには、OpenStack Swiftをバックエンドストレージとしてセットアップすることで、ownCloud自体の冗長性を拡張できます http://owncloud.org

•  ownCloudさんがセミナー、ブース出展していますので、そちらも見て下さい


私の利用例 03: duplicity によるバックアップ •  rsyncアルゴリズムをつかったクラウドストレージへのバックアップツールです

•  C#で作りなおした “duplicati” というツールもあるみたい(未確認) https://code.google.com/p/duplicati/

http://duplicity.nongnu.org/


オブジェクトストレージ、もう一度おさらい

•  450円/100GB～ •  容量無制限、転送量課金なし •  使ってもらうほどスケールメリッ

ト効果が出るサービスです


では、つづいて、ひろのぶさんの講座になります。

Engineering

2015 0228 OpenStack swift; GMO Internet Services