Upload
virtualtech-japan-inc
View
3.435
Download
4
Embed Size (px)
Citation preview
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
1
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例のご紹介
GMOインターネット株式会社エンジニア郷古 直仁テクニカルエバンジェリスト斉藤 弘信
OpenStack最新情報セミナー 2015/02/18
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
[前半: OpenStack Swiftのサービスシステムについて]
・GMOインターネットでのOpenStack Swift利用
・物理構成選択のポイント
・マルチサービスでのインターフェース
・継続的運用とversion up
・インフラ上の今後の課題
[後半: オブジェクトストレージ利用動向について]
・ConoHaについて
・ConoHaオブジェクトストレージ
・利用動向について
2
アジェンダ
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
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インターネットにおけるOpenStack Swiftのサービス化とその利用事例
GMOアプリクラウドとは
• ソーシャルゲームをターゲット中心に、VLAN, LB, PKIなど必要な機能を搭載した、ゲーム専用クラウド
• 最新環境はOpenStack Havanaで提供(API)
• 大規模利用可能なクラウドストレージ用途として、OpenStack Swiftを提供(2014/4/22~)
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
ConoHaとは
• 技術者やスタートアップ企業向けのVPSサービス
• OpenStack Grizzly
• クラウドストレージ用途での、オブジェクトストレージOpenStack Swiftを「GMOアプリクラウド」での提供開始後に、提供開始 (2014/09/03~)
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
GMOアプリクラウド、ConoHaデュアルヘッド
• 一般公開したOpenStack Swift
– 企業向けのGMOアプリクラウド
– コンシューマ向け的なConoHa
• トラフィック利用形態が異なりそうな複数のサービスでPublic利用を提供
• 運用側としては、様々な利用が考えられるConoHaをベースにHardware構成を考えていく
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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の内容がちょっと出たのを、現地で聞けた
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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)によって、配信向けのトラフィックを分割する仕組み
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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を配置すればよいのだろうか?
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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
こちらのボトルネックは無かった
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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
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 account
swift container
Xeon E5620 2.4GHz x 2CPU
Memory 64GB, SSD x 2
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 account
swift container
Xeon E5620 2.4GHz x 2CPU
Memory 64GB, SSD x 2
swift objects
swift objects
Xeon E3-1230 3.3GHz
swift account
swift container
Xeon E5620 2.4GHz x 2CPU
Memory 64GB, SSD x 2
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 2) test: GMO構成B)
>> よさそう
これが最終的な物理構成配置になる
>> 物理構成がだいたい決定
• CPUスレッド分に分割されるにしても、適度な安価なハードを選択
• ハードの世代が変わってもあまり気にしないようにする
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 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も含めて実行を検討
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
物理構成選択のポイント 3) 最近のScale
>> keystoneがまずボトルネックになって、まず対策実施(scale up)
(2014/12ごろ)
>> vmで構成されていたので、memory, CPUを増やす
ストレージノードのScaleはまだ必要なさそう (利用率 10%)
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
もともとGMOアプリクラウドがあったSwift環境:
ConoHaサービス用に、あとからswift-proxy などのFrontを追加
account DB 的には問題なさそう
マルチサービスのインターフェース
swift proxy keystone swift proxy keystone
swift objectsswift objects
swift objectsswift objects
swift objectsswift objects
swift objectsswift objects
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
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
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のメタデータ
マルチサービスのインターフェース
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
容量課金
>> 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
swift objectsswift objects
swift objectsswift objects
swift objectsswift objects
swift objectsswift objects
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
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
継続的運用とバージョン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向け開発を始めるにあたり、まずはバージョンアップを実施
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
継続的運用とバージョン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が必要
>> どうしたのか?
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
継続的運用とバージョン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
>> 超絶しんどい、でもやりました
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
継続的運用とバージョン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の検証をしてから、本番に投入
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
継続的運用とバージョンup: 今後
Kilo以降の開発は確実に python 2.7以降の検証しかされてない
>> python 2.6で動くかどうかは、確実に機能テストをしてから適用するべき
CentOS6 SCL pkg repositoryの存在:
python27, python33
>> こちらで動作するものに移行するかどうかは、今後検討
>> RDO-el7からRDO-el6-python27をbuildするには、systemdをinit.dにバックポートする必要がある
>> 片系づつ、OSを今後切り替えるかもしれない
GMOインターネットにおけるOpenStack Swiftのサービス化とその利用事例
インフラ上の今後の課題と展望
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