SlideShare una empresa de Scribd logo
1 de 74
Descargar para leer sin conexión
OpenStack + CloudStack


            openstack
       Open source software to build public and private clouds.



Object Storage; Overview
            2011.11.30
      日本 OpenStack ユーザ会
     Tomoaki Nakajima / @irix_jp
                                                                  1
Agenda

  ●   Swift って何?
  ●   Swift の利点
  ●   Swift を使う
  ●   Ring
  ●   Ring 考察
  ●   まとめ
  ●   Swift ニュース
  ●   お知らせ
* OSC2011TokyoFall で予告した「障害時の動作」については時間の都合で省略しました。2
Swift って何?




             3
Swift って何?

●   OpenStack の一部で Object Storage 機能を担
    当します。
●   Amazon S3 相当です(互換 API あり)
●   普段は Glance と連携して、 Nova が使う仮想
    マシンイメージの保存先として動きます。




                                         4
Swift って何?

●   普段は縁の下の力持ち的な存在ですが、果たし
    てその実態は・・・




                        5
Swift って何?

●   その実態は単なるファイルサーバです
    ●   オブジェクト≒ファイル
●   HTTP ( REST )でオブジェクトの操作を行い
    ます。                Swift

                                    Account
            http Proxy http Storage Container
    Client
                 Node        Node   Object

●   一見すると単なるファイルサーバーです
    が・・・
                                           6
Swift って何?
    ●   実は OpenStack の人気者




                                                                                    !




http://blog.zenoss.com/2011/11/zenoss-2011-openstack-adoption-survey-infographic-and-results/
                                                                                        7
Swift って何?

●   Swift の人気の秘密はいったい!?




                          8
Swift の利点




            9
Swift って何がいいの? #1

●   安価なハードウェアで安全にファイルの保存が
    可能です。
    ●   RAID も不要です。
    ●   デフォルトで1つのオブジェクトに3つの複製を作
        成します。
                                        A
                                                Storage Node1

           A
                                    A
               File Put    Swift                Storage Node2
                          Cluster

                                            A
                                                Storage Node3


                                                                10
Swift って何がいいの? #2

●   Web サーバみたいに簡単にスケールします。
          Proxy
          Proxy     Storage
                    Storage      容量が UP !
           Proxy
          Node
           Proxy     Storage
                     Node
                     Storage
          Node
            Proxy
           Node
            Proxy     Node
                      Storage
                      Node
                      Storage
           Node
            Node       Node
                       Node      性能が UP !
            Node       Node
●   Proxy Node へのアクセスは DNS ラウンドロビ
    ンか、ロードバランスで分配
●   Storage Node は Proxy が振り分け

                                        11
Swift って何がいいの? #3

●   中央データベースや共有ストレージを持たない
    シンプルな構造なので・・・
    ●   スケール時のボトルネックが存在しません
        –   認証部分が怪しいようですが・・・
    ●   SPOF が存在しません

              Proxy
              Proxy     Storage
                        Storage
               Proxy
              Node
               Proxy     Storage
                         Node
                         Storage
              Node
                Proxy
               Node
                Proxy     Node
                          Storage
                          Node
                          Storage
               Node
                Node       Node
                           Node
                Node       Node
                                    12
Swift って何がいいの? #4

●   強力な自己修復機能を持っています。
    ●   保存されたオブジェクトの破損や消失を自動検知し
        て自動で修復してくれます。
    ●   HDD やノードごと吹っ飛んでも、 HW を復旧すれ
        ば周辺からデータが複製されて勝手に回復します。

    ●   運用が楽チン!
        –   修復や複製には rsync が使われます。




                                    13
Swift って何がいいの? #5

●   その他
    ●   商用サービス( Rackspace Cloud Files )をベース
        としているので OpenStack の中でも相対的に完成
        度が高いです。
    ●   ファイルにいろんな拡張属性を与えられます
        –   単なるファイルの入れ物ではなく、ファイルと情報を
            セットにしたオブジェクトとして扱えます。
        –   将来的には拡張属性の検索機能が実装される予定です。




                                              14
Swift って何がいいの?

●   Swift の一番いいところ、それは・・・




                            15
Swift って何がいいの?

●   Swift の一番いいところ、それは・・・
    汎用性が高く『単体』でも使い道があります。




                            16
Swift って何がいいの?

 ●   Swift の一番いいところ、それは・・・
     汎用性が高く『単体』でも使い道があります。

Dropbox 風     API
                          API    データ
クライアント
                                バックアップ
            文書管理    API
                          API    データ
            システム
                                アーカイブ

                          API
                    API         Hadoop 等



                                      17
Swift を使う




            18
Swift を使う

●   インストールや設定方法は省略
    ●   「 OpenStack Swift install 」でぐぐる

        –   OpenStack の大容量ストレージサービス、 Swift の使い
            方 - TechTarget
             ●   http://techtarget.itmedia.co.jp/tt/news/1109/20/news02.html
        –   OpenStack Storage(Swift) 調査報告書
             ●   http://www.creationline.com/lab/772
        –   SAIO - Swift All In One
             ●   http://swift.openstack.org/development_saio.html
        –   Instructions for a Multiple Server Swift Installation
             ●   http://swift.openstack.org/howto_installmultinode.html

                                                                               19
Swift を使う

●   大雑把な流れ( RHEL 系)
    ●   準備
        –   rpm -ihv openstack-repo-2011.3-0.2.noarch.rpm
        –   yum install openstack-swift-* xinetd rsync memcached
        –   xfs ファイルシステムの作成 (xattr 対応 FS…ext3/4 も可 )
    ●   設定ファイルの編集
        –   proxy-server.conf 、 account-server.conf
        –   container-server.conf 、 object-server.conf


    ●   Ring の作成
                                                                   20
Ring?




        21
Ring

●   Ring は Swift の根幹機能を制御する重要ファイ
    ル
    ●   データの分散配置
    ●   分散したデータへのアクセス経路
    ●   レプリケーション




                               22
Ring

●   ほぼ全ての機能が Ring を参照する


●   そのため Swift クラスタに参加する全ノードに
    同一 Ring を配布しておく必要がある。

●
    Ring は管理者が手動で編集しないと
    変わらない。


                                23
Ring

●   Ring を作成するために必要な情報
    ●   パーティション数
    ●   レプリカ数
    ●   ゾーン
    ●   ストレージノード IP
    ●   ストレージデバイス名
    ●   デバイス優先度


●   swift-ring-builder コマンドで作成・編集
                                    24
Ring

●   Ring 作成の流れ
    ●   Create
         ↓
    ●   Add
         ↓
    ●   Rebalance
         ↓
    ●   全 Swift ノードに配布
        –   account, container, object
            それぞれに作成する必要あり。
                                         25
Ring を作る
    Create/Add/Rebalance
●   例 ) swift-ring-builder Target create 18 3 24
    ●   Target
        –   account.builder
        –   container.builder
        –   object.builder

    ●   18  ・・・パーティション数
    ●   3   ・・・レプリケーション数 [ 個 ]
    ●   24  ・・・リバランス待ち時間 [h]


                                                   26
Ring を作る
    swift-ring-builder Target create 18 3 24
●   パーティション数
    ●   パーティションは Swift がデータを配置する単位
    ●   Swift クラスタ内に何個のパーティションを作成す
        るか指定する。
        –   マニュアルによる推奨値は
            ●   最終的にクラスタ内に含めるディスク本数を100倍
            ●   その数に最も近い 2^n を求める。
            ●   求めた n をパーティション数として使用する。
                 – 18 の場合、 2^18 = 262144 / 100 ≒ 2600 本

●   レプリケーション数はそのままの意味、リバラ
    ンス待ち時間については後で解説
                                                          27
Ring にデバイスを追加
    Create/Add/Rebalance
●   例 )swift-ring-builder Target add 
       z1-192.168.1.101:6000/disk1_meta 1000

    ●   z1   ・・・ゾーン番号( z2,z3,z4... )
    ●   192.168.1.101:6000
            ・・・ストレージノード IP/PORT
    ●   /disk1 ・・・デバイス
    ●   _meta ・・・エイリアス
    ●   1000   ・・・優先度
                                           28
Ring にデバイスを追加
    z1-192.168.1.101:6000/disk1_meta 1000
●   ゾーン番号
                                     C           A
    ●   複製の範囲を決     Zone 1
        定する
                                 B           A
    ●   データの複製は     Zone 2
        必ず異なるゾー
        ンに属するディ     Zone 3
                                         B

        スクへ行われる
    ●   同一ゾーンに属     Zone 4
                             C           A

        するディスクへ
        は複製されない                  B               C
                    Zone 5


                                                 29
Ring にデバイスを追加
    z1-192.168.1.101:6000/disk1_meta 1000
●   IP/PORT 、デバイス
    ●   そのまんま。 Swift で使うディスクを設定する。
        –   物理デバイス名ではなくマウントポイントを指定
●   エイリアス
    ●   上記の IP/PORT 、デバイスの組合せに別名をつけ
        る。後で Ring を編集する場合にこのエイリアスを
        指定して操作できる。省略可能。
●   優先度
    ●   相対値で指定。大きいものにデータが多く配置され
        る。
                                            30
Ring のリバランス
    Create/Add/Rebalance
●   例 )swift-ring-builder Target rebalance

    ●   所属するディスクに優先度に基づくパーティション
        の割り当てを行う




                                             31
Ring 構築の例

●   Ring の作成とデバイスの追加例
    swift-ring-builder obj.bldr create 18 3 24
    swift-ring-builder obj.bldr add z1-1.1.1.1:100/disk1 100
    swift-ring-builder obj.bldr add z2-2.2.2.2:100/disk2 100
    swift-ring-builder obj.bldr add z3-3.3.3.3:100/disk3 100
    swift-ring-builder obj.bldr add z4-4.4.4.4:100/disk4 100
    swift-ring-builder obj.bldr add z5-5.5.5.5:100/disk5 100


●   この状態でリバランスを行うと・・・
    swift-ring-builder obj.bldr rebalance

obj.bldr ... object.builder の略                            32
Ring 構築の例

●   パーティションが割り当てられる
object.builder, build version 5
262144 partitions, 3 replicas, 5 zones, 5 devices, 0.00
balance
The minimum number of hours before a partition can be
reassigned is 24
Devices:
 id zone ip address port name weight partitions balance meta
 0      1   1.1.1.1 100 disk1 100.00      157286   -0.00
 1      2   2.2.2.2 100 disk2 100.00      157287    0.00
 2      3   3.3.3.3 100 disk3 100.00      157286   -0.00
 3      4   4.4.4.4 100 disk4 100.00      157286   -0.00
 4      5   5.5.5.5 100 disk5 100.00      157287    0.00
                                                         33
Ring 構築の例
               2^18 = 262,144
●   パーティションが割り当てられる
object.builder, build version 5
                                 262,144 x 3 = 786,432
262144 partitions, 3 replicas, 5 zones, 5 devices, 0.00
balance
The minimum number of hours before a partition can be
reassigned is 24
      sum(partitions)
Devices:
 id zone=ip address port name weight partitions balance meta
          786,428
 0      1   1.1.1.1 100 disk1 100.00      157286   -0.00
 1      2   2.2.2.2 100 disk2 100.00      157287    0.00
 2      3   3.3.3.3 100 disk3 100.00      157286   -0.00
 3      4   4.4.4.4 100 disk4 100.00      157286   -0.00
 4      5   5.5.5.5 100 disk5 100.00      157287    0.00
                                                         34
Ring まとめ

●   Ring は Swift の重要ファイル
    ●   Swift は Ring でデータの配置を決定する


●   swift-ring-builder コマンドを使用する
    ●   accout, container, object それぞれ作成する
    ●   create → add → rebalance → 配布の順
    ●   全ノードに同一 Ring を配布する必要がある



                                             35
Ring 考察




          36
Ring の概要
                              GroupA/UserA                             GroupB/UserB
                            A ContainerA                         B     ContainerB
                              filenameA                                filenameB
                                  swift_hash_path_suffix

                          Part1       Part2       Part3        Part4         ・・・ 2^n



Replica1     array('H', [ 0, 1, 5, 8, 7, 6, ...])
Replica2     array('H', [ 6, 3, 9, 4, 3, 2, ...])
Replica3     array('H', [ 4, 7, 2, 0, 5, 1, ...])

{... 'ip': '192.168.128.12', 'id': 4, 'parts': 10, 'device': 'disk5', 'port': 6000 ...},
{... 'ip': '192.168.128.12', 'id': 5, 'parts': 10, 'device': 'disk6', 'port': 6000 ...},
{... 'ip': '192.168.128.12', 'id': 6, 'parts': 10, 'device': 'disk7', 'port': 6000 ...},...
*間違ってたらすみません。後でこっそり教えてください。                                                            37
Ring のメリット

●   静的にデータ配置の決       ●   クラスタ内のノード間連
    定                    結が弱い
    ●   同じデータは同じ場所       ●   ボトルネックが発生しに
        に配置される               くい
    ●   ファイルベースの分散       ●   各ノードが同じ静的経路
    ●   他ノードの状態を意識           を持つので SPOF が無い
        する必要がない          ●   1 つの障害が全体に伝搬
                             しにくい

             構造がシンプルで
        大規模ストレージ環境に適したモデル
                                          38
Ring のデメリット

●   一度作った Ring のパーティション数とレプリ
    カ数は変更できない
    ●   RingBuilder オブジェクトを直接いじれば・・・?

●   同じ手順で作った Ring に互換性が無い
    ●   Create → Add xxx → Rebalance = RingA
    ●   Create → Add xxx → Rebalance = RingB ≠ RingA




                                                       39
Ring のデメリット

●    同じ手順で作った Ring に互換性が無い
     ●   初回リバランス時、デバイスをランダムにパーティ
         ションへ割り当てるため
    '_replica2part2dev':   [
    array('H', [0, 1, 5,   8, 7, 6, 9, 8, 9, 8, 9, 3, ...]),
    array('H', [6, 3, 9,   4, 3, 2, 3, 1, 2, 0, 6, 5, ...]),
    array('H', [4, 7, 2,   0, 5, 1, 4, 7, 6, 5, 0, 8, ...])]

    '_replica2part2dev':   [
    array('H', [8, 0, 1,   7, 5, 0, 6, 3, 2, 8, 5, 8, ...]),
    array('H', [5, 2, 4,   4, 1, 7, 3, 1, 9, 4, 1, 7, ...]),
    array('H', [3, 6, 9,   8, 2, 9, 0, 7, 6, 3, 9, 2, ...])]

                                                               40
Ring の注意点

●   バックアップ重要
    ●   Ring は編集すると同一ディレクトリにバックアッ
        プが作成される
        –   backups/<unix_time>.target
    ●   何重にもバックアップをとっておいて損はない
        –   Swift に突っ込んでおくのもあり


●   編集は必ず既存 Ring に対して行う
    ●   Create → add xxx → rebalance
                 → add/remove yyy → rebalance
                                                41
Ring のメンテナンス

●   変更した Ring を配布中に新旧 Ring が混在する
    場合はどうなるのか?

               Proxy
               Node

         A      A       A




                               42
Ring のメンテナンス

●   このような場合


              Proxy
              Node

        A      A      A




                          追加

                               43
Ring のメンテナンス

 ●   新旧 Ring の混在は一時的には OK
     ●   例)以下のような Ring を作成

swift-ring-builder object.builder create 8 3 1

swift-ring-builder   object.builder   add z1-1.1.1.1:111/disk1   100
swift-ring-builder   object.builder   add z2-1.1.1.1:111/disk2   100
swift-ring-builder   object.builder   add z3-1.1.1.1:111/disk3   100
swift-ring-builder   object.builder   add z4-1.1.1.1:111/disk4   100
swift-ring-builder   object.builder   add z5-1.1.1.1:111/disk5   100
swift-ring-builder   object.builder   rebalance


                                                                 44
Ring のメンテナンス

 ●   Ring の状態
256 partitions, 3 replicas, 5 zones, 5 devices, 0.39 balance
The minimum number of hours before a partition can be
reassigned is 1
Devices:
id zone ip address port name weight partitions balance meta
0     1    1.1.1.1 111 disk1 100.00         154    0.26
1     2    1.1.1.1 111 disk2 100.00         153   -0.39
2     3    1.1.1.1 111 disk3 100.00         153   -0.39
3     4    1.1.1.1 111 disk4 100.00         154    0.26
4     5    1.1.1.1 111 disk5 100.00         154    0.26


                                                           45
Ring のメンテナンス

   ●   Ring に優先度の大きいデバイスを追加
swift-ring-builder   object.builder   add   z1-2.2.2.2:222/disk1   1000
swift-ring-builder   object.builder   add   z2-2.2.2.2:222/disk2   1000
swift-ring-builder   object.builder   add   z3-2.2.2.2:222/disk3   1000
swift-ring-builder   object.builder   add   z4-2.2.2.2:222/disk4   1000
swift-ring-builder   object.builder   add   z5-2.2.2.2:222/disk5   1000




                                                                    46
Ring のメンテナンス

●   Ring の状態(リバランス前)
id zone ip address port name weight partitions   balance meta
0     1    1.1.1.1 111 disk1 100.00        154   1002.86
1     2    1.1.1.1 111 disk2 100.00        153    995.70
2     3    1.1.1.1 111 disk3 100.00        153    995.70
3     4    1.1.1.1 111 disk4 100.00        154   1002.86
4     5    1.1.1.1 111 disk5 100.00        154   1002.86
5     1    2.2.2.2 222 disk1 1000.00         0   -100.00
6     2    2.2.2.2 222 disk2 1000.00         0   -100.00
7     3    2.2.2.2 222 disk3 1000.00         0   -100.00
8     4    2.2.2.2 222 disk4 1000.00         0   -100.00
9     5    2.2.2.2 222 disk5 1000.00         0   -100.00

                                                          47
Ring のメンテナンス

●   このまま Rebalance が実行されてしまうと…
id zone ip address port name weight partitions   balance meta
0     1    1.1.1.1 111 disk1 100.00        154   1002.86
1     2    1.1.1.1 111 disk2 100.00        153    995.70
2     3    1.1.1.1 111 disk3 100.00        153    995.70
3     4    1.1.1.1 111 disk4 100.00        154   1002.86
4     5    1.1.1.1 111 disk5 100.00        154   1002.86
5     1    2.2.2.2 222 disk1 1000.00         0   -100.00
6     2    2.2.2.2 222 disk2 1000.00         0   -100.00
7     3    2.2.2.2 222 disk3 1000.00         0   -100.00
8     4    2.2.2.2 222 disk4 1000.00         0   -100.00
9     5    2.2.2.2 222 disk5 1000.00         0   -100.00

                                                          48
Ring のメンテナンス

●   大幅なパーティション移動が起こりデータへの
    アクセスができなってしまう??
                 FileA 取得
            Proxy
            Node

        A    A              A




                                追加

                                     49
Ring のメンテナンス

●   実際はそうはならず・・・
               初期
    id   zone   ip    name   weight parts
     0   1 1.1.1.1   disk1    100.00 154
     1   2 1.1.1.1   disk2    100.00 153
     2   3 1.1.1.1   disk3    100.00 153
     3   4 1.1.1.1   disk4    100.00 154
     4   5 1.1.1.1   disk5    100.00 154
     5   1 2.2.2.2   disk1   1000.00    0
     6   2 2.2.2.2   disk2   1000.00    0
     7   3 2.2.2.2   disk3   1000.00    0
     8   4 2.2.2.2   disk4   1000.00    0
     9   5 2.2.2.2   disk5   1000.00    0
                                            50
Ring のメンテナンス

●   徐々に・・・                           初期     1 回目
    id   zone   ip    name   weight parts   parts
     0   1 1.1.1.1   disk1    100.00 154       99
     1   2 1.1.1.1   disk2    100.00 153      102
     2   3 1.1.1.1   disk3    100.00 153       97
     3   4 1.1.1.1   disk4    100.00 154      112
     4   5 1.1.1.1   disk5    100.00 154      102
     5   1 2.2.2.2   disk1   1000.00    0      51
     6   2 2.2.2.2   disk2   1000.00    0      51
     7   3 2.2.2.2   disk3   1000.00    0      52
     8   4 2.2.2.2   disk4   1000.00    0      51
     9   5 2.2.2.2   disk5   1000.00    0      51
                                                    51
Ring のメンテナンス

●   徐々に分散され・・・                       初期     1 回目    2 回目
    id   zone   ip    name   weight parts   parts   parts
     0   1 1.1.1.1   disk1    100.00 154       99      58
     1   2 1.1.1.1   disk2    100.00 153      102      56
     2   3 1.1.1.1   disk3    100.00 153       97      48
     3   4 1.1.1.1   disk4    100.00 154      112      55
     4   5 1.1.1.1   disk5    100.00 154      102      39
     5   1 2.2.2.2   disk1   1000.00    0      51     102
     6   2 2.2.2.2   disk2   1000.00    0      51     103
     7   3 2.2.2.2   disk3   1000.00    0      52     103
     8   4 2.2.2.2   disk4   1000.00    0      51     102
     9   5 2.2.2.2   disk5   1000.00    0      51     102
                                                            52
Ring のメンテナンス

●   徐々に分散されます                        初期     1 回目    2 回目    3 回目
    id   zone   ip    name   weight parts   parts   parts   parts
     0   1 1.1.1.1   disk1    100.00 154       99      58      14
     1   2 1.1.1.1   disk2    100.00 153      102      56      13
     2   3 1.1.1.1   disk3    100.00 153       97      48      14
     3   4 1.1.1.1   disk4    100.00 154      112      55      14
     4   5 1.1.1.1   disk5    100.00 154      102      39      14
     5   1 2.2.2.2   disk1   1000.00    0      51     102     140
     6   2 2.2.2.2   disk2   1000.00    0      51     103     140
     7   3 2.2.2.2   disk3   1000.00    0      52     103     140
     8   4 2.2.2.2   disk4   1000.00    0      51     102     139
     9   5 2.2.2.2   disk5   1000.00    0      51     102     140
                                                               53
Ring のメンテナンス

●   Ring のバランスが変動する場合はレプリカ単
    位で Rebanace が実行される。
    ●   急激なパーティションの移動によるデータ消失・ア
        クセス不可を防ぐための仕組み。
    ●   複数回の Rebalnace が必要になる。この時、運用
        上の安全のため、次の Rebalance までロックをか
        けるのが「リバランス待ち時間」
        –   Swift-ring-builder xxx create 18 3 24


    ●   1つのレプリカしか移動しないので、残りのレプリ
        カを使ってデータへアクセスできる。
                                                    54
Ring のメンテナンス

 ●   レプリカ単位での Rebalance
      array('H', [2, 1, 1, 4, 0, 2, 3, 3, 4, 4, 0, 2, 4, ...]),
初期    array('H', [0, 3, 3, 3, 4, 0, 4, 2, 3, 0, 3, 4, 1, ...]),
      array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...])




                                                           55
Ring のメンテナンス

  ●   レプリカ単位での Rebalance
     array('H',   [2,   1,   1,   4,   0,   2,   3,   3,   4,   4,   0,   2,   4,   ...]),
 初期 array('H',    [0,   3,   3,   3,   4,   0,   4,   2,   3,   0,   3,   4,   1,   ...]),
     array('H',   [4,   0,   2,   2,   1,   1,   0,   1,   2,   1,   1,   0,   3,   ...])
     array('H',   [8,   9,   6,   6,   8,   9,   7,   5,   9,   7,   9,   8,   9,   ...]),
1 回目 array('H',   [0,   3,   3,   3,   4,   0,   4,   2,   3,   0,   3,   4,   1,   ...]),
     array('H',   [4,   0,   2,   2,   1,   1,   0,   1,   2,   1,   1,   0,   3,   ...])




                                                                                      56
Ring のメンテナンス

  ●   レプリカ単位での Rebalance
     array('H',   [2,   1,   1,   4,   0,   2,   3,   3,   4,   4,   0,   2,   4,   ...]),
 初期 array('H',    [0,   3,   3,   3,   4,   0,   4,   2,   3,   0,   3,   4,   1,   ...]),
     array('H',   [4,   0,   2,   2,   1,   1,   0,   1,   2,   1,   1,   0,   3,   ...])
     array('H',   [8,   9,   6,   6,   8,   9,   7,   5,   9,   7,   9,   8,   9,   ...]),
1 回目 array('H',   [0,   3,   3,   3,   4,   0,   4,   2,   3,   0,   3,   4,   1,   ...]),
     array('H',   [4,   0,   2,   2,   1,   1,   0,   1,   2,   1,   1,   0,   3,   ...])
     array('H',   [8,   9,   6,   6,   8,   9,   7,   5,   9,   7,   9,   8,   9,   ...]),
2 回目 array('H',   [7,   6,   5,   8,   9,   7,   8,   9,   6,   8,   7,   9,   6,   ...]),
     array('H',   [4,   0,   2,   2,   1,   1,   0,   1,   2,   1,   1,   0,   3,   ...])




                                                                                      57
Ring のメンテナンス

  ●   レプリカ単位での Rebalance
     array('H',   [2,   1,   1,   4,   0,   2,   3,   3,   4,   4,   0,   2,   4,   ...]),
 初期 array('H',    [0,   3,   3,   3,   4,   0,   4,   2,   3,   0,   3,   4,   1,   ...]),
     array('H',   [4,   0,   2,   2,   1,   1,   0,   1,   2,   1,   1,   0,   3,   ...])
     array('H',   [8,   9,   6,   6,   8,   9,   7,   5,   9,   7,   9,   8,   9,   ...]),
1 回目 array('H',   [0,   3,   3,   3,   4,   0,   4,   2,   3,   0,   3,   4,   1,   ...]),
     array('H',   [4,   0,   2,   2,   1,   1,   0,   1,   2,   1,   1,   0,   3,   ...])
     array('H',   [8,   9,   6,   6,   8,   9,   7,   5,   9,   7,   9,   8,   9,   ...]),
2 回目 array('H',   [7,   6,   5,   8,   9,   7,   8,   9,   6,   8,   7,   9,   6,   ...]),
     array('H',   [4,   0,   2,   2,   1,   1,   0,   1,   2,   1,   1,   0,   3,   ...])
     array('H',   [8,   9,   6,   6,   8,   9,   7,   5,   9,   7,   9,   8,   9,   ...]),
3 回目 array('H',   [7,   6,   5,   8,   9,   7,   8,   9,   6,   8,   7,   9,   6,   ...]),
     array('H',   [5,   8,   8,   7,   7,   6,   9,   7,   2,   6,   5,   6,   5,   ...])

                                                                                      58
Ring のメンテナンス

●   編集した Ring を配布するときに Swift が止まる
    んじゃ?
    ●   Reload オプションがあるが・・・
    ●   接続済みのセッションは通信が終わるまで待って
        るっぽいが・・・??

    ●   大丈夫な気もしますが要確認(これから
        –   知ってる方、後で教えてください!




                                 59
Ring の今後

●   全ノードに配布って・・・チョーいけてない!
    ●   ノード追加、 HDD 追加
        –   その都度全ノードに配布・リロードする必要がある。

    ●   Essex では ring-builder-server が実装される予定
        –   Web ベースでの Ring 作成・編集
        –   ノードへの配布機能
        –   https://blueprints.launchpad.net/swift/+spec/ring-builder-ser


    ●   ちょっとは楽になりそう??
                                                                   60
まとめ




      61
まとめ

●   Swift は・・・
    ●   HTTP ( REST )で通信するファイルサーバです。
    ●   安価なハードで安全に動きます。 RAID 不要。
    ●   容量・性能がスケールし、 SPOF がありません。
    ●   勝手に自己修復します。
    ●   汎用性が高く Swift 単体で使えます。
    ●   シンプルで大規模環境に適したストレージ構造
    ●   Ring 重要
        –   忘れずにバックアップしておきましょう

                                       62
2011-11-24 Swift 1.4.4(Essex)

  ●   Self Destructing Files
  ●   add more detail to rate limit errors
  ●   add swift man pages
  ●   better ring builder error messages
  ●   change ring builder exit codes
  ●   create swift recon docs
  ●   swift recon socket stats
  ●   tempauth autocreate accounts
  ●   zone specific recon

                                             63
2011-11-24 Swift 1.4.4(Essex)

  ●   Self Destructing Files
      –   swift-object-expirer
      –   時間経過によるファイルの自動削除
      –   アップロードしたオブジェクトに以下のメタデータを付
          与
           ●   X-Delete-At: 日時指定 (Unix 時間 )
           ●   X-Delete-After: アップロードされてからの経過時間 ( 秒 )


      –   object-server.conf に以下を設定
           [object-expirer]
           interval = 300


                                                        64
お知らせ

●   Swift 実証実験参加メンバー募集中
    ●   大規模環境での Swift の運用を行い、問題点や注意
        点の洗い出しを計画しています。

    ●   現在のステータス
        –   検証・検討内容の募集
        –   HW 、場所の募集 ← 重要!

    ●   クラウドストレージ研究会 ML にて議論中
        –   http://groups.google.com/group/cloudstf
        –   どしどしご参加ください!
                                                      65
ご静聴ありがとうございました。




                  66
参考サイト

●   OpenStack( 本家 )
    ●   http://www.openstack.org/
●   日本 OpenStack ユーザ会
    ●   http://openstack.jp/
●   API マニュアル(本家)
    ●   http://docs.openstack.org/api/openstack-object-storage/1.0/con




                                                                67
参考サイト

●   使用させていただいた素材
    ●   http://cool-liberty.com/
    ●   http://tanukifont.sblo.jp/article/41432838.html
    ●   http://butsudori.blog47.fc2.com/blog-entry-3.html
    ●   http://www.ashinari.com/




                                                            68
おまけ




      69
自己修復機能

●   ファイルが消えた
    ●   1 個・・・修復可能
    ●   2 個・・・修復可能
    ●   3 個・・・修復不可


●   ファイルがストレージノードから消えても複製
    があればアクセス可能
●   replicator で自動修復される


                          70
自己修復機能

●   ファイルが壊れた
    ●   1 個・・・修復可能
    ●   2 個・・・修復可能
    ●   3 個・・・修復不可
    ●   壊れたファイルは quarantine ディレクトリへ移動
        される( lost+found みたいなもの)


●   ファイル破損は auditor により検知・除去さ
    れ、 replicator により修復される

                                        71
自己修復機能

●   ファイルの整合性は拡張属性として付与
    0000   80   02   7D   71   01   28   55   0E   43   6F   6E   74   65   6E   74   2D   ..}q.(U.Content-
    0010   4C   65   6E   67   74   68   71   02   55   04   31   34   37   39   71   03   Lengthq.U.1479q.
    0020   55   04   6E   61   6D   65   71   04   55   24   2F   41   55   54   48   5F   U.nameq.U$/AUTH_
    0030   73   79   73   74   65   6D   2F   66   6F   6C   64   65   72   31   2F   61   system/folder1/a
    0040   6E   61   63   6F   6E   64   61   2D   6B   73   2E   63   66   67   71   05   naconda-ks.cfgq.
    0050   55   13   58   2D   4F   62   6A   65   63   74   2D   4D   65   74   61   2D   U.X-Object-Meta-
    0060   4D   74   69   6D   65   71   06   55   0D   31   33   32   31   38   38   33   Mtimeq.U.1321883
    0070   30   30   37   2E   30   32   71   07   55   04   45   54   61   67   71   08   007.02q.U.ETagq.
    0080   55   20   35   62   38   38   63   35   34   61   34   35   62   34   64   65   U 5b88c54a45b4de
    0090   33   37   62   61   32   34   30   38   62   32   66   65   33   38   37   39   37ba2408b2fe3879
    00A0   30   36   71   09   55   0B   58   2D   54   69   6D   65   73   74   61   6D   06q.U.X-Timestam
    00B0   70   71   0A   55   10   31   33   32   32   32   38   34   35   30   39   2E   pq.U.1322284509.
    00C0   36   37   35   39   33   71   0B   55   0C   43   6F   6E   74   65   6E   74   67593q.U.Content
    00D0   2D   54   79   70   65   71   0C   55   18   61   70   70   6C   69   63   61   -Typeq.U.applica
    00E0   74   69   6F   6E   2F   6F   63   74   65   74   2D   73   74   72   65   61   tion/octet-strea
    00F0   6D   71   0D   75   2E                                                          mq.u.

                                                                                                          72
好きな属性のセットも可能
>   HEAD /v1/AUTH_system/folder1/anaconda-ks.cfg HTTP/1.1
>   Host: 192.168.128.12:8080
>   Accept: */*
>   X-Auth-Token: AUTH_tk90678650dcde455cbf1a28f7f825cde2

<   HTTP/1.1 200 OK
<   Last-Modified: Thu, 24 Nov 2011 15:07:05 GMT
<   Etag: 5b88c54a45b4de37ba2408b2fe387906
<   X-Object-Meta-Installenv: Scientific Linux 6.1 x64
<   X-Object-Meta-FileOwner: root
<   X-Object-Meta-FileGroup: root
<   X-Object-Meta-Permission: 0655
<   Accept-Ranges: bytes
<   Content-Length: 1479
<   Content-Type: application/octet-stream
<   Date: Sat, 26 Nov 2011 01:35:45 GMT                     73
Swift API

●   API マニュアル
    ●   OpenStack Object Storage Developer Guide
        –   http://docs.openstack.org/api/openstack-object-storage/1.0/c




                                                                  74

Más contenido relacionado

La actualidad más candente

Cephベンチマーク kvm
Cephベンチマーク kvmCephベンチマーク kvm
Cephベンチマーク kvmToshimi Kawabata
 
ceph acceleration and storage architecture
ceph acceleration and storage architectureceph acceleration and storage architecture
ceph acceleration and storage architectureYuki Kitajima
 
Ceph アーキテクチャ概説
Ceph アーキテクチャ概説Ceph アーキテクチャ概説
Ceph アーキテクチャ概説Emma Haruka Iwao
 
Red Hat ストレージ製品
Red Hat ストレージ製品Red Hat ストレージ製品
Red Hat ストレージ製品Takuya Utsunomiya
 
20180423 OpenStackユーザー会 SDS
20180423 OpenStackユーザー会 SDS20180423 OpenStackユーザー会 SDS
20180423 OpenStackユーザー会 SDSTakuya Utsunomiya
 
Persistence on Azure - Microsoft Azure の永続化
Persistence on Azure - Microsoft Azure の永続化Persistence on Azure - Microsoft Azure の永続化
Persistence on Azure - Microsoft Azure の永続化Takekazu Omi
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化Kumazaki Hiroki
 
Quantastorを使ったhybrid cloudについて_20140725
Quantastorを使ったhybrid cloudについて_20140725Quantastorを使ったhybrid cloudについて_20140725
Quantastorを使ったhybrid cloudについて_20140725AFfirmBP
 
Rubyによるお手軽分散処理
Rubyによるお手軽分散処理Rubyによるお手軽分散処理
Rubyによるお手軽分散処理maebashi
 
Cephのベンチマークをしました
CephのベンチマークをしましたCephのベンチマークをしました
CephのベンチマークをしましたOSSラボ株式会社
 
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...Insight Technology, Inc.
 
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSSYahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSSYahoo!デベロッパーネットワーク
 
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月VirtualTech Japan Inc.
 
Seastar in 歌舞伎座.tech#8「C++初心者会」
Seastar in 歌舞伎座.tech#8「C++初心者会」Seastar in 歌舞伎座.tech#8「C++初心者会」
Seastar in 歌舞伎座.tech#8「C++初心者会」Takuya ASADA
 
Azure Storage Partition Internals
Azure Storage Partition  Internals Azure Storage Partition  Internals
Azure Storage Partition Internals Takekazu Omi
 
昨今のストレージ選定のポイントとCephStorageの特徴
昨今のストレージ選定のポイントとCephStorageの特徴昨今のストレージ選定のポイントとCephStorageの特徴
昨今のストレージ選定のポイントとCephStorageの特徴Takuya Utsunomiya
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介AdvancedTechNight
 
Openstack summit walk DNSaaS 2015-0713 Summit LT
Openstack summit walk DNSaaS 2015-0713 Summit LTOpenstack summit walk DNSaaS 2015-0713 Summit LT
Openstack summit walk DNSaaS 2015-0713 Summit LTNaoto Gohko
 

La actualidad más candente (20)

Cephベンチマーク kvm
Cephベンチマーク kvmCephベンチマーク kvm
Cephベンチマーク kvm
 
ceph acceleration and storage architecture
ceph acceleration and storage architectureceph acceleration and storage architecture
ceph acceleration and storage architecture
 
Ceph アーキテクチャ概説
Ceph アーキテクチャ概説Ceph アーキテクチャ概説
Ceph アーキテクチャ概説
 
Red Hat ストレージ製品
Red Hat ストレージ製品Red Hat ストレージ製品
Red Hat ストレージ製品
 
20180423 OpenStackユーザー会 SDS
20180423 OpenStackユーザー会 SDS20180423 OpenStackユーザー会 SDS
20180423 OpenStackユーザー会 SDS
 
Persistence on Azure - Microsoft Azure の永続化
Persistence on Azure - Microsoft Azure の永続化Persistence on Azure - Microsoft Azure の永続化
Persistence on Azure - Microsoft Azure の永続化
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化
 
141030ceph
141030ceph141030ceph
141030ceph
 
Quantastorを使ったhybrid cloudについて_20140725
Quantastorを使ったhybrid cloudについて_20140725Quantastorを使ったhybrid cloudについて_20140725
Quantastorを使ったhybrid cloudについて_20140725
 
Rubyによるお手軽分散処理
Rubyによるお手軽分散処理Rubyによるお手軽分散処理
Rubyによるお手軽分散処理
 
Cephのベンチマークをしました
CephのベンチマークをしましたCephのベンチマークをしました
Cephのベンチマークをしました
 
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
 
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSSYahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
 
Openstack+Ceph設定ガイド
Openstack+Ceph設定ガイドOpenstack+Ceph設定ガイド
Openstack+Ceph設定ガイド
 
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
OSSラボ様講演 OpenStack最新情報セミナー 2014年6月
 
Seastar in 歌舞伎座.tech#8「C++初心者会」
Seastar in 歌舞伎座.tech#8「C++初心者会」Seastar in 歌舞伎座.tech#8「C++初心者会」
Seastar in 歌舞伎座.tech#8「C++初心者会」
 
Azure Storage Partition Internals
Azure Storage Partition  Internals Azure Storage Partition  Internals
Azure Storage Partition Internals
 
昨今のストレージ選定のポイントとCephStorageの特徴
昨今のストレージ選定のポイントとCephStorageの特徴昨今のストレージ選定のポイントとCephStorageの特徴
昨今のストレージ選定のポイントとCephStorageの特徴
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
 
Openstack summit walk DNSaaS 2015-0713 Summit LT
Openstack summit walk DNSaaS 2015-0713 Summit LTOpenstack summit walk DNSaaS 2015-0713 Summit LT
Openstack summit walk DNSaaS 2015-0713 Summit LT
 

Destacado

OpenStack Swift production deployments
OpenStack Swift production deploymentsOpenStack Swift production deployments
OpenStack Swift production deploymentsAtul Jha
 
Openstack Swift Introduction
Openstack Swift IntroductionOpenstack Swift Introduction
Openstack Swift IntroductionPark YounSung
 
Deploying OpenStack Object Storage (Swift)
Deploying OpenStack Object Storage (Swift)Deploying OpenStack Object Storage (Swift)
Deploying OpenStack Object Storage (Swift)Juan José Martínez
 
OpenStack Swift In the Enterprise
OpenStack Swift In the EnterpriseOpenStack Swift In the Enterprise
OpenStack Swift In the EnterpriseHostway|HOSTING
 
Turning OpenStack Swift into a VM storage platform
Turning OpenStack Swift into a VM storage platformTurning OpenStack Swift into a VM storage platform
Turning OpenStack Swift into a VM storage platformOpenStack_Online
 
OpenStack Architecture
OpenStack ArchitectureOpenStack Architecture
OpenStack ArchitectureMirantis
 
[OpenStack Day in Korea 2015] Track 2-6 - Apache Tajo on Swift
[OpenStack Day in Korea 2015] Track 2-6 - Apache Tajo on Swift[OpenStack Day in Korea 2015] Track 2-6 - Apache Tajo on Swift
[OpenStack Day in Korea 2015] Track 2-6 - Apache Tajo on SwiftOpenStack Korea Community
 

Destacado (9)

OpenStack Swift
OpenStack SwiftOpenStack Swift
OpenStack Swift
 
OpenStack Swift
OpenStack SwiftOpenStack Swift
OpenStack Swift
 
OpenStack Swift production deployments
OpenStack Swift production deploymentsOpenStack Swift production deployments
OpenStack Swift production deployments
 
Openstack Swift Introduction
Openstack Swift IntroductionOpenstack Swift Introduction
Openstack Swift Introduction
 
Deploying OpenStack Object Storage (Swift)
Deploying OpenStack Object Storage (Swift)Deploying OpenStack Object Storage (Swift)
Deploying OpenStack Object Storage (Swift)
 
OpenStack Swift In the Enterprise
OpenStack Swift In the EnterpriseOpenStack Swift In the Enterprise
OpenStack Swift In the Enterprise
 
Turning OpenStack Swift into a VM storage platform
Turning OpenStack Swift into a VM storage platformTurning OpenStack Swift into a VM storage platform
Turning OpenStack Swift into a VM storage platform
 
OpenStack Architecture
OpenStack ArchitectureOpenStack Architecture
OpenStack Architecture
 
[OpenStack Day in Korea 2015] Track 2-6 - Apache Tajo on Swift
[OpenStack Day in Korea 2015] Track 2-6 - Apache Tajo on Swift[OpenStack Day in Korea 2015] Track 2-6 - Apache Tajo on Swift
[OpenStack Day in Korea 2015] Track 2-6 - Apache Tajo on Swift
 

Similar a OpenStack Object Storage; Overview

OSC2011Tokyo/Fall OpenStack Swift入門
OSC2011Tokyo/Fall OpenStack Swift入門OSC2011Tokyo/Fall OpenStack Swift入門
OSC2011Tokyo/Fall OpenStack Swift入門irix_jp
 
Red Hat OpenShift Container Storage
Red Hat OpenShift Container StorageRed Hat OpenShift Container Storage
Red Hat OpenShift Container StorageTakuya Utsunomiya
 
Riak meetup tokyo idcf 20130312
Riak meetup tokyo idcf 20130312Riak meetup tokyo idcf 20130312
Riak meetup tokyo idcf 20130312Hiroyuki Sato
 
OSC2013 Tokyo Spring OpenStack Overview
OSC2013 Tokyo Spring OpenStack OverviewOSC2013 Tokyo Spring OpenStack Overview
OSC2013 Tokyo Spring OpenStack Overviewirix_jp
 
NTTデータ様講演 OpenStack最新情報セミナー 2014年6月
NTTデータ様講演 OpenStack最新情報セミナー 2014年6月NTTデータ様講演 OpenStack最新情報セミナー 2014年6月
NTTデータ様講演 OpenStack最新情報セミナー 2014年6月VirtualTech Japan Inc.
 
OpenStack Summit in Atlanta 参加報告
OpenStack Summit in Atlanta 参加報告OpenStack Summit in Atlanta 参加報告
OpenStack Summit in Atlanta 参加報告Akira Yoshiyama
 
CloudStackユーザ会 OSC.cloud
CloudStackユーザ会 OSC.cloudCloudStackユーザ会 OSC.cloud
CloudStackユーザ会 OSC.cloudsamemoon
 
OWIN - .NETにおけるPSGI -
OWIN - .NETにおけるPSGI -OWIN - .NETにおけるPSGI -
OWIN - .NETにおけるPSGI -将 高野
 
node-handlersocket
node-handlersocketnode-handlersocket
node-handlersocketkoichik
 
OSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUGOSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUGHideki Saito
 
次世代Webコンテナ Undertowについて
次世代Webコンテナ Undertowについて次世代Webコンテナ Undertowについて
次世代Webコンテナ UndertowについてYoshimasa Tanabe
 
play framework 勉強会 in 関西
play framework 勉強会 in 関西play framework 勉強会 in 関西
play framework 勉強会 in 関西Shinichi Kozake
 
試して学べるクラウド技術! OpenShift
試して学べるクラウド技術! OpenShift試して学べるクラウド技術! OpenShift
試して学べるクラウド技術! OpenShiftEtsuji Nakai
 
OpenStack Summit November 2014 Paris出張報告
OpenStack Summit November 2014 Paris出張報告OpenStack Summit November 2014 Paris出張報告
OpenStack Summit November 2014 Paris出張報告Mitsuhiro SHIGEMATSU
 
Vagrantで即席クラウドストレージ
Vagrantで即席クラウドストレージVagrantで即席クラウドストレージ
Vagrantで即席クラウドストレージYoshimi Tominaga
 
FluentdとRedshiftの素敵な関係
FluentdとRedshiftの素敵な関係FluentdとRedshiftの素敵な関係
FluentdとRedshiftの素敵な関係moai kids
 

Similar a OpenStack Object Storage; Overview (20)

OSC2011Tokyo/Fall OpenStack Swift入門
OSC2011Tokyo/Fall OpenStack Swift入門OSC2011Tokyo/Fall OpenStack Swift入門
OSC2011Tokyo/Fall OpenStack Swift入門
 
Osoljp201210 oi swift
Osoljp201210 oi swiftOsoljp201210 oi swift
Osoljp201210 oi swift
 
Red Hat OpenShift Container Storage
Red Hat OpenShift Container StorageRed Hat OpenShift Container Storage
Red Hat OpenShift Container Storage
 
OpenStack概要
OpenStack概要OpenStack概要
OpenStack概要
 
Riak meetup tokyo idcf 20130312
Riak meetup tokyo idcf 20130312Riak meetup tokyo idcf 20130312
Riak meetup tokyo idcf 20130312
 
OSC2013 Tokyo Spring OpenStack Overview
OSC2013 Tokyo Spring OpenStack OverviewOSC2013 Tokyo Spring OpenStack Overview
OSC2013 Tokyo Spring OpenStack Overview
 
OpenStack Swift紹介
OpenStack Swift紹介OpenStack Swift紹介
OpenStack Swift紹介
 
NTTデータ様講演 OpenStack最新情報セミナー 2014年6月
NTTデータ様講演 OpenStack最新情報セミナー 2014年6月NTTデータ様講演 OpenStack最新情報セミナー 2014年6月
NTTデータ様講演 OpenStack最新情報セミナー 2014年6月
 
OpenStack Summit in Atlanta 参加報告
OpenStack Summit in Atlanta 参加報告OpenStack Summit in Atlanta 参加報告
OpenStack Summit in Atlanta 参加報告
 
CloudStackユーザ会 OSC.cloud
CloudStackユーザ会 OSC.cloudCloudStackユーザ会 OSC.cloud
CloudStackユーザ会 OSC.cloud
 
OWIN - .NETにおけるPSGI -
OWIN - .NETにおけるPSGI -OWIN - .NETにおけるPSGI -
OWIN - .NETにおけるPSGI -
 
node-handlersocket
node-handlersocketnode-handlersocket
node-handlersocket
 
OSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUGOSC2012 Tokyo/Spring JOSUG
OSC2012 Tokyo/Spring JOSUG
 
次世代Webコンテナ Undertowについて
次世代Webコンテナ Undertowについて次世代Webコンテナ Undertowについて
次世代Webコンテナ Undertowについて
 
play framework 勉強会 in 関西
play framework 勉強会 in 関西play framework 勉強会 in 関西
play framework 勉強会 in 関西
 
WalBの紹介
WalBの紹介WalBの紹介
WalBの紹介
 
試して学べるクラウド技術! OpenShift
試して学べるクラウド技術! OpenShift試して学べるクラウド技術! OpenShift
試して学べるクラウド技術! OpenShift
 
OpenStack Summit November 2014 Paris出張報告
OpenStack Summit November 2014 Paris出張報告OpenStack Summit November 2014 Paris出張報告
OpenStack Summit November 2014 Paris出張報告
 
Vagrantで即席クラウドストレージ
Vagrantで即席クラウドストレージVagrantで即席クラウドストレージ
Vagrantで即席クラウドストレージ
 
FluentdとRedshiftの素敵な関係
FluentdとRedshiftの素敵な関係FluentdとRedshiftの素敵な関係
FluentdとRedshiftの素敵な関係
 

Más de irix_jp

The invitation to Infrastructure CI
The invitation to Infrastructure CIThe invitation to Infrastructure CI
The invitation to Infrastructure CIirix_jp
 
The NoOps strategy and tactics
The NoOps strategy and tacticsThe NoOps strategy and tactics
The NoOps strategy and tacticsirix_jp
 
The practical guide of Infrastructure CI
The practical guide of Infrastructure CIThe practical guide of Infrastructure CI
The practical guide of Infrastructure CIirix_jp
 
The strategy from the Iserlohn fortress at JTF2018
The strategy from the Iserlohn fortress at JTF2018The strategy from the Iserlohn fortress at JTF2018
The strategy from the Iserlohn fortress at JTF2018irix_jp
 
JOSUG 34th Meetup
JOSUG 34th Meetup JOSUG 34th Meetup
JOSUG 34th Meetup irix_jp
 
Japan OpenStack User Group 34th Meetup - Handson Environment
Japan OpenStack User Group 34th Meetup - Handson EnvironmentJapan OpenStack User Group 34th Meetup - Handson Environment
Japan OpenStack User Group 34th Meetup - Handson Environmentirix_jp
 
OpenStack Summit Report
OpenStack Summit ReportOpenStack Summit Report
OpenStack Summit Reportirix_jp
 
OSC2016.Enterprise OpenStack & Cloud Native Applications
OSC2016.Enterprise OpenStack & Cloud Native ApplicationsOSC2016.Enterprise OpenStack & Cloud Native Applications
OSC2016.Enterprise OpenStack & Cloud Native Applicationsirix_jp
 
OSC2016 Kyoto Heat + Ansible + Jupyter
OSC2016 Kyoto Heat + Ansible + JupyterOSC2016 Kyoto Heat + Ansible + Jupyter
OSC2016 Kyoto Heat + Ansible + Jupyteririx_jp
 
JTF2016 The strategy and Sun Tzu
JTF2016 The strategy and Sun TzuJTF2016 The strategy and Sun Tzu
JTF2016 The strategy and Sun Tzuirix_jp
 
JOSUG Meetup 28th Heat 101
JOSUG Meetup 28th Heat 101JOSUG Meetup 28th Heat 101
JOSUG Meetup 28th Heat 101irix_jp
 
Hot の書き方(Template Version 2015-04-30) 前編
Hot の書き方(Template Version 2015-04-30) 前編Hot の書き方(Template Version 2015-04-30) 前編
Hot の書き方(Template Version 2015-04-30) 前編irix_jp
 
OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作irix_jp
 
空回りのクラウド基盤導入
空回りのクラウド基盤導入空回りのクラウド基盤導入
空回りのクラウド基盤導入irix_jp
 
クラウド時代のエンジニア魂と企業に必要なカルチャーチェンジ(前半)
クラウド時代のエンジニア魂と企業に必要なカルチャーチェンジ(前半)クラウド時代のエンジニア魂と企業に必要なカルチャーチェンジ(前半)
クラウド時代のエンジニア魂と企業に必要なカルチャーチェンジ(前半)irix_jp
 
Josug 20th meetup アンケート集計
Josug 20th meetup アンケート集計Josug 20th meetup アンケート集計
Josug 20th meetup アンケート集計irix_jp
 
OSC@Kyoto2014 OpenStack概要
OSC@Kyoto2014 OpenStack概要OSC@Kyoto2014 OpenStack概要
OSC@Kyoto2014 OpenStack概要irix_jp
 
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編irix_jp
 
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:OpenStack 基礎操作編
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:OpenStack 基礎操作編H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:OpenStack 基礎操作編
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:OpenStack 基礎操作編irix_jp
 
JTF2014:OpenStackの概要と最新技術動向
JTF2014:OpenStackの概要と最新技術動向JTF2014:OpenStackの概要と最新技術動向
JTF2014:OpenStackの概要と最新技術動向irix_jp
 

Más de irix_jp (20)

The invitation to Infrastructure CI
The invitation to Infrastructure CIThe invitation to Infrastructure CI
The invitation to Infrastructure CI
 
The NoOps strategy and tactics
The NoOps strategy and tacticsThe NoOps strategy and tactics
The NoOps strategy and tactics
 
The practical guide of Infrastructure CI
The practical guide of Infrastructure CIThe practical guide of Infrastructure CI
The practical guide of Infrastructure CI
 
The strategy from the Iserlohn fortress at JTF2018
The strategy from the Iserlohn fortress at JTF2018The strategy from the Iserlohn fortress at JTF2018
The strategy from the Iserlohn fortress at JTF2018
 
JOSUG 34th Meetup
JOSUG 34th Meetup JOSUG 34th Meetup
JOSUG 34th Meetup
 
Japan OpenStack User Group 34th Meetup - Handson Environment
Japan OpenStack User Group 34th Meetup - Handson EnvironmentJapan OpenStack User Group 34th Meetup - Handson Environment
Japan OpenStack User Group 34th Meetup - Handson Environment
 
OpenStack Summit Report
OpenStack Summit ReportOpenStack Summit Report
OpenStack Summit Report
 
OSC2016.Enterprise OpenStack & Cloud Native Applications
OSC2016.Enterprise OpenStack & Cloud Native ApplicationsOSC2016.Enterprise OpenStack & Cloud Native Applications
OSC2016.Enterprise OpenStack & Cloud Native Applications
 
OSC2016 Kyoto Heat + Ansible + Jupyter
OSC2016 Kyoto Heat + Ansible + JupyterOSC2016 Kyoto Heat + Ansible + Jupyter
OSC2016 Kyoto Heat + Ansible + Jupyter
 
JTF2016 The strategy and Sun Tzu
JTF2016 The strategy and Sun TzuJTF2016 The strategy and Sun Tzu
JTF2016 The strategy and Sun Tzu
 
JOSUG Meetup 28th Heat 101
JOSUG Meetup 28th Heat 101JOSUG Meetup 28th Heat 101
JOSUG Meetup 28th Heat 101
 
Hot の書き方(Template Version 2015-04-30) 前編
Hot の書き方(Template Version 2015-04-30) 前編Hot の書き方(Template Version 2015-04-30) 前編
Hot の書き方(Template Version 2015-04-30) 前編
 
OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作
 
空回りのクラウド基盤導入
空回りのクラウド基盤導入空回りのクラウド基盤導入
空回りのクラウド基盤導入
 
クラウド時代のエンジニア魂と企業に必要なカルチャーチェンジ(前半)
クラウド時代のエンジニア魂と企業に必要なカルチャーチェンジ(前半)クラウド時代のエンジニア魂と企業に必要なカルチャーチェンジ(前半)
クラウド時代のエンジニア魂と企業に必要なカルチャーチェンジ(前半)
 
Josug 20th meetup アンケート集計
Josug 20th meetup アンケート集計Josug 20th meetup アンケート集計
Josug 20th meetup アンケート集計
 
OSC@Kyoto2014 OpenStack概要
OSC@Kyoto2014 OpenStack概要OSC@Kyoto2014 OpenStack概要
OSC@Kyoto2014 OpenStack概要
 
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:ボリューム操作編
 
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:OpenStack 基礎操作編
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:OpenStack 基礎操作編H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:OpenStack 基礎操作編
H26第1回 沖縄オープンラボラトリ・ハンズオンセミナー:OpenStack 基礎操作編
 
JTF2014:OpenStackの概要と最新技術動向
JTF2014:OpenStackの概要と最新技術動向JTF2014:OpenStackの概要と最新技術動向
JTF2014:OpenStackの概要と最新技術動向
 

OpenStack Object Storage; Overview

  • 1. OpenStack + CloudStack openstack Open source software to build public and private clouds. Object Storage; Overview 2011.11.30 日本 OpenStack ユーザ会 Tomoaki Nakajima / @irix_jp 1
  • 2. Agenda ● Swift って何? ● Swift の利点 ● Swift を使う ● Ring ● Ring 考察 ● まとめ ● Swift ニュース ● お知らせ * OSC2011TokyoFall で予告した「障害時の動作」については時間の都合で省略しました。2
  • 4. Swift って何? ● OpenStack の一部で Object Storage 機能を担 当します。 ● Amazon S3 相当です(互換 API あり) ● 普段は Glance と連携して、 Nova が使う仮想 マシンイメージの保存先として動きます。 4
  • 5. Swift って何? ● 普段は縁の下の力持ち的な存在ですが、果たし てその実態は・・・ 5
  • 6. Swift って何? ● その実態は単なるファイルサーバです ● オブジェクト≒ファイル ● HTTP ( REST )でオブジェクトの操作を行い ます。 Swift Account http Proxy http Storage Container Client Node Node Object ● 一見すると単なるファイルサーバーです が・・・ 6
  • 7. Swift って何? ● 実は OpenStack の人気者 ! http://blog.zenoss.com/2011/11/zenoss-2011-openstack-adoption-survey-infographic-and-results/ 7
  • 8. Swift って何? ● Swift の人気の秘密はいったい!? 8
  • 10. Swift って何がいいの? #1 ● 安価なハードウェアで安全にファイルの保存が 可能です。 ● RAID も不要です。 ● デフォルトで1つのオブジェクトに3つの複製を作 成します。 A Storage Node1 A A File Put Swift Storage Node2 Cluster A Storage Node3 10
  • 11. Swift って何がいいの? #2 ● Web サーバみたいに簡単にスケールします。 Proxy Proxy Storage Storage 容量が UP ! Proxy Node Proxy Storage Node Storage Node Proxy Node Proxy Node Storage Node Storage Node Node Node Node 性能が UP ! Node Node ● Proxy Node へのアクセスは DNS ラウンドロビ ンか、ロードバランスで分配 ● Storage Node は Proxy が振り分け 11
  • 12. Swift って何がいいの? #3 ● 中央データベースや共有ストレージを持たない シンプルな構造なので・・・ ● スケール時のボトルネックが存在しません – 認証部分が怪しいようですが・・・ ● SPOF が存在しません Proxy Proxy Storage Storage Proxy Node Proxy Storage Node Storage Node Proxy Node Proxy Node Storage Node Storage Node Node Node Node Node Node 12
  • 13. Swift って何がいいの? #4 ● 強力な自己修復機能を持っています。 ● 保存されたオブジェクトの破損や消失を自動検知し て自動で修復してくれます。 ● HDD やノードごと吹っ飛んでも、 HW を復旧すれ ば周辺からデータが複製されて勝手に回復します。 ● 運用が楽チン! – 修復や複製には rsync が使われます。 13
  • 14. Swift って何がいいの? #5 ● その他 ● 商用サービス( Rackspace Cloud Files )をベース としているので OpenStack の中でも相対的に完成 度が高いです。 ● ファイルにいろんな拡張属性を与えられます – 単なるファイルの入れ物ではなく、ファイルと情報を セットにしたオブジェクトとして扱えます。 – 将来的には拡張属性の検索機能が実装される予定です。 14
  • 15. Swift って何がいいの? ● Swift の一番いいところ、それは・・・ 15
  • 16. Swift って何がいいの? ● Swift の一番いいところ、それは・・・ 汎用性が高く『単体』でも使い道があります。 16
  • 17. Swift って何がいいの? ● Swift の一番いいところ、それは・・・ 汎用性が高く『単体』でも使い道があります。 Dropbox 風 API API データ クライアント バックアップ 文書管理 API API データ システム アーカイブ API API Hadoop 等 17
  • 19. Swift を使う ● インストールや設定方法は省略 ● 「 OpenStack Swift install 」でぐぐる – OpenStack の大容量ストレージサービス、 Swift の使い 方 - TechTarget ● http://techtarget.itmedia.co.jp/tt/news/1109/20/news02.html – OpenStack Storage(Swift) 調査報告書 ● http://www.creationline.com/lab/772 – SAIO - Swift All In One ● http://swift.openstack.org/development_saio.html – Instructions for a Multiple Server Swift Installation ● http://swift.openstack.org/howto_installmultinode.html 19
  • 20. Swift を使う ● 大雑把な流れ( RHEL 系) ● 準備 – rpm -ihv openstack-repo-2011.3-0.2.noarch.rpm – yum install openstack-swift-* xinetd rsync memcached – xfs ファイルシステムの作成 (xattr 対応 FS…ext3/4 も可 ) ● 設定ファイルの編集 – proxy-server.conf 、 account-server.conf – container-server.conf 、 object-server.conf ● Ring の作成 20
  • 21. Ring? 21
  • 22. Ring ● Ring は Swift の根幹機能を制御する重要ファイ ル ● データの分散配置 ● 分散したデータへのアクセス経路 ● レプリケーション 22
  • 23. Ring ● ほぼ全ての機能が Ring を参照する ● そのため Swift クラスタに参加する全ノードに 同一 Ring を配布しておく必要がある。 ● Ring は管理者が手動で編集しないと 変わらない。 23
  • 24. Ring ● Ring を作成するために必要な情報 ● パーティション数 ● レプリカ数 ● ゾーン ● ストレージノード IP ● ストレージデバイス名 ● デバイス優先度 ● swift-ring-builder コマンドで作成・編集 24
  • 25. Ring ● Ring 作成の流れ ● Create ↓ ● Add ↓ ● Rebalance ↓ ● 全 Swift ノードに配布 – account, container, object それぞれに作成する必要あり。 25
  • 26. Ring を作る Create/Add/Rebalance ● 例 ) swift-ring-builder Target create 18 3 24 ● Target – account.builder – container.builder – object.builder ● 18  ・・・パーティション数 ● 3   ・・・レプリケーション数 [ 個 ] ● 24  ・・・リバランス待ち時間 [h] 26
  • 27. Ring を作る swift-ring-builder Target create 18 3 24 ● パーティション数 ● パーティションは Swift がデータを配置する単位 ● Swift クラスタ内に何個のパーティションを作成す るか指定する。 – マニュアルによる推奨値は ● 最終的にクラスタ内に含めるディスク本数を100倍 ● その数に最も近い 2^n を求める。 ● 求めた n をパーティション数として使用する。 – 18 の場合、 2^18 = 262144 / 100 ≒ 2600 本 ● レプリケーション数はそのままの意味、リバラ ンス待ち時間については後で解説 27
  • 28. Ring にデバイスを追加 Create/Add/Rebalance ● 例 )swift-ring-builder Target add    z1-192.168.1.101:6000/disk1_meta 1000 ● z1   ・・・ゾーン番号( z2,z3,z4... ) ● 192.168.1.101:6000     ・・・ストレージノード IP/PORT ● /disk1 ・・・デバイス ● _meta ・・・エイリアス ● 1000 ・・・優先度 28
  • 29. Ring にデバイスを追加 z1-192.168.1.101:6000/disk1_meta 1000 ● ゾーン番号 C A ● 複製の範囲を決 Zone 1 定する B A ● データの複製は Zone 2 必ず異なるゾー ンに属するディ Zone 3 B スクへ行われる ● 同一ゾーンに属 Zone 4 C A するディスクへ は複製されない B C Zone 5 29
  • 30. Ring にデバイスを追加 z1-192.168.1.101:6000/disk1_meta 1000 ● IP/PORT 、デバイス ● そのまんま。 Swift で使うディスクを設定する。 – 物理デバイス名ではなくマウントポイントを指定 ● エイリアス ● 上記の IP/PORT 、デバイスの組合せに別名をつけ る。後で Ring を編集する場合にこのエイリアスを 指定して操作できる。省略可能。 ● 優先度 ● 相対値で指定。大きいものにデータが多く配置され る。 30
  • 31. Ring のリバランス Create/Add/Rebalance ● 例 )swift-ring-builder Target rebalance ● 所属するディスクに優先度に基づくパーティション の割り当てを行う 31
  • 32. Ring 構築の例 ● Ring の作成とデバイスの追加例 swift-ring-builder obj.bldr create 18 3 24 swift-ring-builder obj.bldr add z1-1.1.1.1:100/disk1 100 swift-ring-builder obj.bldr add z2-2.2.2.2:100/disk2 100 swift-ring-builder obj.bldr add z3-3.3.3.3:100/disk3 100 swift-ring-builder obj.bldr add z4-4.4.4.4:100/disk4 100 swift-ring-builder obj.bldr add z5-5.5.5.5:100/disk5 100 ● この状態でリバランスを行うと・・・ swift-ring-builder obj.bldr rebalance obj.bldr ... object.builder の略 32
  • 33. Ring 構築の例 ● パーティションが割り当てられる object.builder, build version 5 262144 partitions, 3 replicas, 5 zones, 5 devices, 0.00 balance The minimum number of hours before a partition can be reassigned is 24 Devices: id zone ip address port name weight partitions balance meta 0 1 1.1.1.1 100 disk1 100.00 157286 -0.00 1 2 2.2.2.2 100 disk2 100.00 157287 0.00 2 3 3.3.3.3 100 disk3 100.00 157286 -0.00 3 4 4.4.4.4 100 disk4 100.00 157286 -0.00 4 5 5.5.5.5 100 disk5 100.00 157287 0.00 33
  • 34. Ring 構築の例 2^18 = 262,144 ● パーティションが割り当てられる object.builder, build version 5 262,144 x 3 = 786,432 262144 partitions, 3 replicas, 5 zones, 5 devices, 0.00 balance The minimum number of hours before a partition can be reassigned is 24 sum(partitions) Devices: id zone=ip address port name weight partitions balance meta 786,428 0 1 1.1.1.1 100 disk1 100.00 157286 -0.00 1 2 2.2.2.2 100 disk2 100.00 157287 0.00 2 3 3.3.3.3 100 disk3 100.00 157286 -0.00 3 4 4.4.4.4 100 disk4 100.00 157286 -0.00 4 5 5.5.5.5 100 disk5 100.00 157287 0.00 34
  • 35. Ring まとめ ● Ring は Swift の重要ファイル ● Swift は Ring でデータの配置を決定する ● swift-ring-builder コマンドを使用する ● accout, container, object それぞれ作成する ● create → add → rebalance → 配布の順 ● 全ノードに同一 Ring を配布する必要がある 35
  • 37. Ring の概要 GroupA/UserA GroupB/UserB A ContainerA B ContainerB filenameA filenameB swift_hash_path_suffix Part1 Part2 Part3 Part4 ・・・ 2^n Replica1 array('H', [ 0, 1, 5, 8, 7, 6, ...]) Replica2 array('H', [ 6, 3, 9, 4, 3, 2, ...]) Replica3 array('H', [ 4, 7, 2, 0, 5, 1, ...]) {... 'ip': '192.168.128.12', 'id': 4, 'parts': 10, 'device': 'disk5', 'port': 6000 ...}, {... 'ip': '192.168.128.12', 'id': 5, 'parts': 10, 'device': 'disk6', 'port': 6000 ...}, {... 'ip': '192.168.128.12', 'id': 6, 'parts': 10, 'device': 'disk7', 'port': 6000 ...},... *間違ってたらすみません。後でこっそり教えてください。 37
  • 38. Ring のメリット ● 静的にデータ配置の決 ● クラスタ内のノード間連 定 結が弱い ● 同じデータは同じ場所 ● ボトルネックが発生しに に配置される くい ● ファイルベースの分散 ● 各ノードが同じ静的経路 ● 他ノードの状態を意識 を持つので SPOF が無い する必要がない ● 1 つの障害が全体に伝搬 しにくい 構造がシンプルで 大規模ストレージ環境に適したモデル 38
  • 39. Ring のデメリット ● 一度作った Ring のパーティション数とレプリ カ数は変更できない ● RingBuilder オブジェクトを直接いじれば・・・? ● 同じ手順で作った Ring に互換性が無い ● Create → Add xxx → Rebalance = RingA ● Create → Add xxx → Rebalance = RingB ≠ RingA 39
  • 40. Ring のデメリット ● 同じ手順で作った Ring に互換性が無い ● 初回リバランス時、デバイスをランダムにパーティ ションへ割り当てるため '_replica2part2dev': [ array('H', [0, 1, 5, 8, 7, 6, 9, 8, 9, 8, 9, 3, ...]), array('H', [6, 3, 9, 4, 3, 2, 3, 1, 2, 0, 6, 5, ...]), array('H', [4, 7, 2, 0, 5, 1, 4, 7, 6, 5, 0, 8, ...])] '_replica2part2dev': [ array('H', [8, 0, 1, 7, 5, 0, 6, 3, 2, 8, 5, 8, ...]), array('H', [5, 2, 4, 4, 1, 7, 3, 1, 9, 4, 1, 7, ...]), array('H', [3, 6, 9, 8, 2, 9, 0, 7, 6, 3, 9, 2, ...])] 40
  • 41. Ring の注意点 ● バックアップ重要 ● Ring は編集すると同一ディレクトリにバックアッ プが作成される – backups/<unix_time>.target ● 何重にもバックアップをとっておいて損はない – Swift に突っ込んでおくのもあり ● 編集は必ず既存 Ring に対して行う ● Create → add xxx → rebalance → add/remove yyy → rebalance 41
  • 42. Ring のメンテナンス ● 変更した Ring を配布中に新旧 Ring が混在する 場合はどうなるのか? Proxy Node A A A 42
  • 43. Ring のメンテナンス ● このような場合 Proxy Node A A A 追加 43
  • 44. Ring のメンテナンス ● 新旧 Ring の混在は一時的には OK ● 例)以下のような Ring を作成 swift-ring-builder object.builder create 8 3 1 swift-ring-builder object.builder add z1-1.1.1.1:111/disk1 100 swift-ring-builder object.builder add z2-1.1.1.1:111/disk2 100 swift-ring-builder object.builder add z3-1.1.1.1:111/disk3 100 swift-ring-builder object.builder add z4-1.1.1.1:111/disk4 100 swift-ring-builder object.builder add z5-1.1.1.1:111/disk5 100 swift-ring-builder object.builder rebalance 44
  • 45. Ring のメンテナンス ● Ring の状態 256 partitions, 3 replicas, 5 zones, 5 devices, 0.39 balance The minimum number of hours before a partition can be reassigned is 1 Devices: id zone ip address port name weight partitions balance meta 0 1 1.1.1.1 111 disk1 100.00 154 0.26 1 2 1.1.1.1 111 disk2 100.00 153 -0.39 2 3 1.1.1.1 111 disk3 100.00 153 -0.39 3 4 1.1.1.1 111 disk4 100.00 154 0.26 4 5 1.1.1.1 111 disk5 100.00 154 0.26 45
  • 46. Ring のメンテナンス ● Ring に優先度の大きいデバイスを追加 swift-ring-builder object.builder add z1-2.2.2.2:222/disk1 1000 swift-ring-builder object.builder add z2-2.2.2.2:222/disk2 1000 swift-ring-builder object.builder add z3-2.2.2.2:222/disk3 1000 swift-ring-builder object.builder add z4-2.2.2.2:222/disk4 1000 swift-ring-builder object.builder add z5-2.2.2.2:222/disk5 1000 46
  • 47. Ring のメンテナンス ● Ring の状態(リバランス前) id zone ip address port name weight partitions balance meta 0 1 1.1.1.1 111 disk1 100.00 154 1002.86 1 2 1.1.1.1 111 disk2 100.00 153 995.70 2 3 1.1.1.1 111 disk3 100.00 153 995.70 3 4 1.1.1.1 111 disk4 100.00 154 1002.86 4 5 1.1.1.1 111 disk5 100.00 154 1002.86 5 1 2.2.2.2 222 disk1 1000.00 0 -100.00 6 2 2.2.2.2 222 disk2 1000.00 0 -100.00 7 3 2.2.2.2 222 disk3 1000.00 0 -100.00 8 4 2.2.2.2 222 disk4 1000.00 0 -100.00 9 5 2.2.2.2 222 disk5 1000.00 0 -100.00 47
  • 48. Ring のメンテナンス ● このまま Rebalance が実行されてしまうと… id zone ip address port name weight partitions balance meta 0 1 1.1.1.1 111 disk1 100.00 154 1002.86 1 2 1.1.1.1 111 disk2 100.00 153 995.70 2 3 1.1.1.1 111 disk3 100.00 153 995.70 3 4 1.1.1.1 111 disk4 100.00 154 1002.86 4 5 1.1.1.1 111 disk5 100.00 154 1002.86 5 1 2.2.2.2 222 disk1 1000.00 0 -100.00 6 2 2.2.2.2 222 disk2 1000.00 0 -100.00 7 3 2.2.2.2 222 disk3 1000.00 0 -100.00 8 4 2.2.2.2 222 disk4 1000.00 0 -100.00 9 5 2.2.2.2 222 disk5 1000.00 0 -100.00 48
  • 49. Ring のメンテナンス ● 大幅なパーティション移動が起こりデータへの アクセスができなってしまう?? FileA 取得 Proxy Node A A A 追加 49
  • 50. Ring のメンテナンス ● 実際はそうはならず・・・ 初期 id zone ip name weight parts 0 1 1.1.1.1 disk1 100.00 154 1 2 1.1.1.1 disk2 100.00 153 2 3 1.1.1.1 disk3 100.00 153 3 4 1.1.1.1 disk4 100.00 154 4 5 1.1.1.1 disk5 100.00 154 5 1 2.2.2.2 disk1 1000.00 0 6 2 2.2.2.2 disk2 1000.00 0 7 3 2.2.2.2 disk3 1000.00 0 8 4 2.2.2.2 disk4 1000.00 0 9 5 2.2.2.2 disk5 1000.00 0 50
  • 51. Ring のメンテナンス ● 徐々に・・・ 初期 1 回目 id zone ip name weight parts parts 0 1 1.1.1.1 disk1 100.00 154 99 1 2 1.1.1.1 disk2 100.00 153 102 2 3 1.1.1.1 disk3 100.00 153 97 3 4 1.1.1.1 disk4 100.00 154 112 4 5 1.1.1.1 disk5 100.00 154 102 5 1 2.2.2.2 disk1 1000.00 0 51 6 2 2.2.2.2 disk2 1000.00 0 51 7 3 2.2.2.2 disk3 1000.00 0 52 8 4 2.2.2.2 disk4 1000.00 0 51 9 5 2.2.2.2 disk5 1000.00 0 51 51
  • 52. Ring のメンテナンス ● 徐々に分散され・・・ 初期 1 回目 2 回目 id zone ip name weight parts parts parts 0 1 1.1.1.1 disk1 100.00 154 99 58 1 2 1.1.1.1 disk2 100.00 153 102 56 2 3 1.1.1.1 disk3 100.00 153 97 48 3 4 1.1.1.1 disk4 100.00 154 112 55 4 5 1.1.1.1 disk5 100.00 154 102 39 5 1 2.2.2.2 disk1 1000.00 0 51 102 6 2 2.2.2.2 disk2 1000.00 0 51 103 7 3 2.2.2.2 disk3 1000.00 0 52 103 8 4 2.2.2.2 disk4 1000.00 0 51 102 9 5 2.2.2.2 disk5 1000.00 0 51 102 52
  • 53. Ring のメンテナンス ● 徐々に分散されます 初期 1 回目 2 回目 3 回目 id zone ip name weight parts parts parts parts 0 1 1.1.1.1 disk1 100.00 154 99 58 14 1 2 1.1.1.1 disk2 100.00 153 102 56 13 2 3 1.1.1.1 disk3 100.00 153 97 48 14 3 4 1.1.1.1 disk4 100.00 154 112 55 14 4 5 1.1.1.1 disk5 100.00 154 102 39 14 5 1 2.2.2.2 disk1 1000.00 0 51 102 140 6 2 2.2.2.2 disk2 1000.00 0 51 103 140 7 3 2.2.2.2 disk3 1000.00 0 52 103 140 8 4 2.2.2.2 disk4 1000.00 0 51 102 139 9 5 2.2.2.2 disk5 1000.00 0 51 102 140 53
  • 54. Ring のメンテナンス ● Ring のバランスが変動する場合はレプリカ単 位で Rebanace が実行される。 ● 急激なパーティションの移動によるデータ消失・ア クセス不可を防ぐための仕組み。 ● 複数回の Rebalnace が必要になる。この時、運用 上の安全のため、次の Rebalance までロックをか けるのが「リバランス待ち時間」 – Swift-ring-builder xxx create 18 3 24 ● 1つのレプリカしか移動しないので、残りのレプリ カを使ってデータへアクセスできる。 54
  • 55. Ring のメンテナンス ● レプリカ単位での Rebalance array('H', [2, 1, 1, 4, 0, 2, 3, 3, 4, 4, 0, 2, 4, ...]), 初期 array('H', [0, 3, 3, 3, 4, 0, 4, 2, 3, 0, 3, 4, 1, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) 55
  • 56. Ring のメンテナンス ● レプリカ単位での Rebalance array('H', [2, 1, 1, 4, 0, 2, 3, 3, 4, 4, 0, 2, 4, ...]), 初期 array('H', [0, 3, 3, 3, 4, 0, 4, 2, 3, 0, 3, 4, 1, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) array('H', [8, 9, 6, 6, 8, 9, 7, 5, 9, 7, 9, 8, 9, ...]), 1 回目 array('H', [0, 3, 3, 3, 4, 0, 4, 2, 3, 0, 3, 4, 1, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) 56
  • 57. Ring のメンテナンス ● レプリカ単位での Rebalance array('H', [2, 1, 1, 4, 0, 2, 3, 3, 4, 4, 0, 2, 4, ...]), 初期 array('H', [0, 3, 3, 3, 4, 0, 4, 2, 3, 0, 3, 4, 1, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) array('H', [8, 9, 6, 6, 8, 9, 7, 5, 9, 7, 9, 8, 9, ...]), 1 回目 array('H', [0, 3, 3, 3, 4, 0, 4, 2, 3, 0, 3, 4, 1, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) array('H', [8, 9, 6, 6, 8, 9, 7, 5, 9, 7, 9, 8, 9, ...]), 2 回目 array('H', [7, 6, 5, 8, 9, 7, 8, 9, 6, 8, 7, 9, 6, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) 57
  • 58. Ring のメンテナンス ● レプリカ単位での Rebalance array('H', [2, 1, 1, 4, 0, 2, 3, 3, 4, 4, 0, 2, 4, ...]), 初期 array('H', [0, 3, 3, 3, 4, 0, 4, 2, 3, 0, 3, 4, 1, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) array('H', [8, 9, 6, 6, 8, 9, 7, 5, 9, 7, 9, 8, 9, ...]), 1 回目 array('H', [0, 3, 3, 3, 4, 0, 4, 2, 3, 0, 3, 4, 1, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) array('H', [8, 9, 6, 6, 8, 9, 7, 5, 9, 7, 9, 8, 9, ...]), 2 回目 array('H', [7, 6, 5, 8, 9, 7, 8, 9, 6, 8, 7, 9, 6, ...]), array('H', [4, 0, 2, 2, 1, 1, 0, 1, 2, 1, 1, 0, 3, ...]) array('H', [8, 9, 6, 6, 8, 9, 7, 5, 9, 7, 9, 8, 9, ...]), 3 回目 array('H', [7, 6, 5, 8, 9, 7, 8, 9, 6, 8, 7, 9, 6, ...]), array('H', [5, 8, 8, 7, 7, 6, 9, 7, 2, 6, 5, 6, 5, ...]) 58
  • 59. Ring のメンテナンス ● 編集した Ring を配布するときに Swift が止まる んじゃ? ● Reload オプションがあるが・・・ ● 接続済みのセッションは通信が終わるまで待って るっぽいが・・・?? ● 大丈夫な気もしますが要確認(これから – 知ってる方、後で教えてください! 59
  • 60. Ring の今後 ● 全ノードに配布って・・・チョーいけてない! ● ノード追加、 HDD 追加 – その都度全ノードに配布・リロードする必要がある。 ● Essex では ring-builder-server が実装される予定 – Web ベースでの Ring 作成・編集 – ノードへの配布機能 – https://blueprints.launchpad.net/swift/+spec/ring-builder-ser ● ちょっとは楽になりそう?? 60
  • 61. まとめ 61
  • 62. まとめ ● Swift は・・・ ● HTTP ( REST )で通信するファイルサーバです。 ● 安価なハードで安全に動きます。 RAID 不要。 ● 容量・性能がスケールし、 SPOF がありません。 ● 勝手に自己修復します。 ● 汎用性が高く Swift 単体で使えます。 ● シンプルで大規模環境に適したストレージ構造 ● Ring 重要 – 忘れずにバックアップしておきましょう 62
  • 63. 2011-11-24 Swift 1.4.4(Essex) ● Self Destructing Files ● add more detail to rate limit errors ● add swift man pages ● better ring builder error messages ● change ring builder exit codes ● create swift recon docs ● swift recon socket stats ● tempauth autocreate accounts ● zone specific recon 63
  • 64. 2011-11-24 Swift 1.4.4(Essex) ● Self Destructing Files – swift-object-expirer – 時間経過によるファイルの自動削除 – アップロードしたオブジェクトに以下のメタデータを付 与 ● X-Delete-At: 日時指定 (Unix 時間 ) ● X-Delete-After: アップロードされてからの経過時間 ( 秒 ) – object-server.conf に以下を設定 [object-expirer] interval = 300 64
  • 65. お知らせ ● Swift 実証実験参加メンバー募集中 ● 大規模環境での Swift の運用を行い、問題点や注意 点の洗い出しを計画しています。 ● 現在のステータス – 検証・検討内容の募集 – HW 、場所の募集 ← 重要! ● クラウドストレージ研究会 ML にて議論中 – http://groups.google.com/group/cloudstf – どしどしご参加ください! 65
  • 67. 参考サイト ● OpenStack( 本家 ) ● http://www.openstack.org/ ● 日本 OpenStack ユーザ会 ● http://openstack.jp/ ● API マニュアル(本家) ● http://docs.openstack.org/api/openstack-object-storage/1.0/con 67
  • 68. 参考サイト ● 使用させていただいた素材 ● http://cool-liberty.com/ ● http://tanukifont.sblo.jp/article/41432838.html ● http://butsudori.blog47.fc2.com/blog-entry-3.html ● http://www.ashinari.com/ 68
  • 69. おまけ 69
  • 70. 自己修復機能 ● ファイルが消えた ● 1 個・・・修復可能 ● 2 個・・・修復可能 ● 3 個・・・修復不可 ● ファイルがストレージノードから消えても複製 があればアクセス可能 ● replicator で自動修復される 70
  • 71. 自己修復機能 ● ファイルが壊れた ● 1 個・・・修復可能 ● 2 個・・・修復可能 ● 3 個・・・修復不可 ● 壊れたファイルは quarantine ディレクトリへ移動 される( lost+found みたいなもの) ● ファイル破損は auditor により検知・除去さ れ、 replicator により修復される 71
  • 72. 自己修復機能 ● ファイルの整合性は拡張属性として付与 0000 80 02 7D 71 01 28 55 0E 43 6F 6E 74 65 6E 74 2D ..}q.(U.Content- 0010 4C 65 6E 67 74 68 71 02 55 04 31 34 37 39 71 03 Lengthq.U.1479q. 0020 55 04 6E 61 6D 65 71 04 55 24 2F 41 55 54 48 5F U.nameq.U$/AUTH_ 0030 73 79 73 74 65 6D 2F 66 6F 6C 64 65 72 31 2F 61 system/folder1/a 0040 6E 61 63 6F 6E 64 61 2D 6B 73 2E 63 66 67 71 05 naconda-ks.cfgq. 0050 55 13 58 2D 4F 62 6A 65 63 74 2D 4D 65 74 61 2D U.X-Object-Meta- 0060 4D 74 69 6D 65 71 06 55 0D 31 33 32 31 38 38 33 Mtimeq.U.1321883 0070 30 30 37 2E 30 32 71 07 55 04 45 54 61 67 71 08 007.02q.U.ETagq. 0080 55 20 35 62 38 38 63 35 34 61 34 35 62 34 64 65 U 5b88c54a45b4de 0090 33 37 62 61 32 34 30 38 62 32 66 65 33 38 37 39 37ba2408b2fe3879 00A0 30 36 71 09 55 0B 58 2D 54 69 6D 65 73 74 61 6D 06q.U.X-Timestam 00B0 70 71 0A 55 10 31 33 32 32 32 38 34 35 30 39 2E pq.U.1322284509. 00C0 36 37 35 39 33 71 0B 55 0C 43 6F 6E 74 65 6E 74 67593q.U.Content 00D0 2D 54 79 70 65 71 0C 55 18 61 70 70 6C 69 63 61 -Typeq.U.applica 00E0 74 69 6F 6E 2F 6F 63 74 65 74 2D 73 74 72 65 61 tion/octet-strea 00F0 6D 71 0D 75 2E mq.u. 72
  • 73. 好きな属性のセットも可能 > HEAD /v1/AUTH_system/folder1/anaconda-ks.cfg HTTP/1.1 > Host: 192.168.128.12:8080 > Accept: */* > X-Auth-Token: AUTH_tk90678650dcde455cbf1a28f7f825cde2 < HTTP/1.1 200 OK < Last-Modified: Thu, 24 Nov 2011 15:07:05 GMT < Etag: 5b88c54a45b4de37ba2408b2fe387906 < X-Object-Meta-Installenv: Scientific Linux 6.1 x64 < X-Object-Meta-FileOwner: root < X-Object-Meta-FileGroup: root < X-Object-Meta-Permission: 0655 < Accept-Ranges: bytes < Content-Length: 1479 < Content-Type: application/octet-stream < Date: Sat, 26 Nov 2011 01:35:45 GMT 73
  • 74. Swift API ● API マニュアル ● OpenStack Object Storage Developer Guide – http://docs.openstack.org/api/openstack-object-storage/1.0/c 74