ScaleIOを触り始めた

ScaleIO を触り始めた。

  • ソフトウェアベースのストレージ製品
    • 拡張規模は1000ノード以上
  • サーバーの内蔵ディスクを共有ストレージ化
    • HDD, SSD, PCIe-Flash
  • OpenStackのブロックストレージとして活用
    • Cinder Driverを提供

のSDS (Software Defined Storage)プロダクトとなる。

商用の場合はライセンスが必要だが、検証目的の場合はフル機能を無償で利用出来るらしい。

Vagrantを活用した超簡単なScaleIOのインストール方法 の動画の通り、Vagrant上でScaleIOを試すことが出来る。

https://github.com/emccode/vagrant

vagrant up すると

  • mdm1
  • mdm2
  • td

という3つのVMが立ち上がる。それぞれ "Meta Data Manager", "Tie-Breaker" という役割でこの3台が最小のセットとなるみたい。各々の機能についてはまだよく分かっていない。

ScaleIO Quick Start Guide - EMC の "4. Enable the Storage" を見ると、CLI経由での操作が書いてあるが、mdm1にて

scli --login --username admin --password <password>
scli --query_all

すると

System Info:
        Product:  EMC ScaleIO Version: R1_32.402.1
        ID:      77b9056833d2c793
        Manager ID:      0000000000000000
        Name:     cluster1

License info:
        Installation ID: 5380876158d928c8
        SWID:
        Maximum capacity: Unlimited
        Usage time left: Unlimited *** Non-Production License ***
        Enterprise features: Enabled
        The system was activated 0 days ago

System settings:
        Volumes are not obfuscated by default
        Capacity alert thresholds: High: 80, Critical: 90
        Thick volume reservation percent: 0
        MDM restricted SDC mode: disabled

Query all returned 1 Protection Domain:
Protection Domain protection_domain1 (Id: b4deb59f00000000) has 1 storage pools, 0 Fault Sets, 3 SDS nodes, 1 volumes and 112.0 GB (114688 MB) available for volume allocation
Operational state is Active

Storage Pool capacity (Id: 70b6ba8f00000000) has 1 volumes and 112.0 GB (114688 MB) available for volume allocation
        The number of parallel rebuild/rebalance jobs: 2
        Rebuild is enabled and using Limit-Concurrent-IO policy with the following parameters:
        Number of concurrent IOs per device: 1
        Rebalance is enabled and using Favor-Application-IO policy with the following parameters:
        Number of concurrent IOs per device: 1, Bandwidth limit per device: 10240 KB per second
        Background device scanner: Disabled
        Zero padding is disabled
        Spare policy: 10% out of total
        Uses RAM Read Cache
        RAM Read Cache write handling mode is 'cached'

SDS Summary:
        Total 3 SDS Nodes
        3 SDS nodes have membership state 'Joined'
        3 SDS nodes have connection state 'Connected'
        276.4 GB (283026 MB) total capacity
        232.8 GB (238340 MB) unused capacity
        0 Bytes snapshots capacity
        16.0 GB (16384 MB) in-use capacity
        0 Bytes thin capacity
        16.0 GB (16384 MB) protected capacity
        0 Bytes failed capacity
        0 Bytes degraded-failed capacity
        0 Bytes degraded-healthy capacity
        0 Bytes unreachable-unused capacity
        0 Bytes active rebalance capacity
        0 Bytes pending rebalance capacity
        0 Bytes active fwd-rebuild capacity
        0 Bytes pending fwd-rebuild capacity
        0 Bytes active bck-rebuild capacity
        0 Bytes pending bck-rebuild capacity
        0 Bytes rebalance capacity
        0 Bytes fwd-rebuild capacity
        0 Bytes bck-rebuild capacity
        0 Bytes active moving capacity
        0 Bytes pending moving capacity
        0 Bytes total moving capacity
        27.6 GB (28302 MB) spare capacity
        16.0 GB (16384 MB) at-rest capacity
        0 Bytes decreased capacity

        Primary-reads                            0 IOPS 0 Bytes per-second
        Primary-writes                           0 IOPS 0 Bytes per-second
        Secondary-reads                          0 IOPS 0 Bytes per-second
        Secondary-writes                         0 IOPS 0 Bytes per-second
        Backward-rebuild-reads                   0 IOPS 0 Bytes per-second
        Backward-rebuild-writes                  0 IOPS 0 Bytes per-second
        Forward-rebuild-reads                    0 IOPS 0 Bytes per-second
        Forward-rebuild-writes                   0 IOPS 0 Bytes per-second
        Rebalance-reads                          0 IOPS 0 Bytes per-second
        Rebalance-writes                         0 IOPS 0 Bytes per-second

Volumes summary:
        1 thick-provisioned volume. Total size: 8.0 GB (8192 MB)

とVagrantによるプロビジョン時にVolumeが作成されていることが分かる。利用するノードにもScaleIO Data Clientをインストールし、ScaleIO Data Serverと通信することでストレージを利用出来るようになるようだ。

徹底解説!ScaleIOをOpenStackで 活用するメリットとは?を読んだりしていた。

第5回ペパボテックカンファレンスでOpenStackによるプライベートクラウド運用の話をした

去る 5/14(土) に 第5回ペパボテックカンファレンス〜インフラエンジニア大特集〜 を開催し、自分はOpenStackによるプライベートクラウド "Nyah" の運用についてトークしました。

当日の様子は前編後編と録画がありますので、合わせてご覧頂ければと思います。
筆者の出番はこの辺から。

イベントが企画された3月半ばくらいに社内に対しては「OpenStackの運用と改善した話します」という宣言をしたものの、スライドで述べられている

  • OpenStackのバージョンアップ
  • Cinderを利用可能にする(およびストレージ製品・ソフトウェアの検証)
  • Neutronによるネットワーク刷新

のどれも終わってなかったので発表のわりと直前までヒヤヒヤしていました。無事にカンファレンスまで間に合って良かったです、わりと4月に頑張っています。

質問もいただいたので補足しておきます。いずれも "今も困ってるんですよ・運用始まったら考えます” みたいな印象ですが、次また別の機会に "こうやって解決した!" 的な発表をするしかないですね。

Q1

Q: (OpenStackに載ってるインスタンスの)バックアップ構成は?
A: Nyah上の別AZのインスタンスだとか、別ロケーションにあるOpenStack外の基盤にとっています。サービス(商材)によってJ-SOX適用対象・非対象でやり方が違っている部分があり、統一が出来ていないのが現状課題だと考えています。

これはまあOpenStack使っている使っていないにあまり依らないかもですが。

Q2

Q: OpenStackのバージョンアップ後の切り戻りは?
A: 新バージョンは全コンポーネントを別途構築して移行しています。マイグレーションの仕組みを準備していないので実質切り戻しは行わない予定です。

後ほどKeystoneは共用出来たのではないかとも考えたのですが、今回はHavanaからMitakaへのジャンプアップということもあり、やはり分けてしまった方が切り替えやすそうだと結論づけています。以降のバージョンアップ時はなるべくシームレスなマイグレーションを目指します。

Q3

Q: Neutronが今後ボトルネックになりそうな印象。Linuxでパフォーマンス落ちないか?パフォーマンス測定したか?
A: DVR + SNAT HA構成は組めましたが、パフォーマンスは全く計測出来ていません。プライベートクラウドなので自分たちでキャパシティを調整出来るというのもあり、様子を見ながら実際の運用の中で測っていきます。

DVR + SNAT HA構成はOpenStackを運用してる国内の企業の中でも最速の事例なのではないかと自負しています。いかんせんNeutronがっつりというのが初めてなので、どうなるか楽しみ半分不安半分といったところです。

5/14は第5回ペパボテックカンファレンス〜インフラエンジニア大特集〜

第5回ペパボテックカンファレンス〜インフラエンジニア大特集〜 ということで登壇する資料の準備を始めた。

ペパボのプライベートクラウド "Nyah" が利用されるようになって1年経ったわけだけども、既に次バージョンへの改善に向けて色々動いているのでそれについて発表するつもり。

アウトラインとしては

  • Nyahとは
    • リリースまでの経緯
    • 概要
  • Nyahの利用実績・規模
  • 現状の問題点
  • 改善、新トライアルについて
    • コンポーネントのOSマイグレーション
    • OpenStackのバージョンアップ
    • SDN, ネットワークのDVR構成
  • 改善、新トライアルを支える技術

みたいな感じになりそう。

イベントでの個人的な推しトークは "(仮) ペパボのインフラを読み解く" というトークセッション。我々インフラグループのマネージャー tamon と古くから東京のインフラを支えてきたベテラン sugy, 福岡のインフラサブマネージャーの tshpaper がどんな話をするのか、中の人としても楽しみ。

Gitのコミット時メールアドレスをdirenvを使って切り替える

具体的にはメールアドレスをこういう風に使いわけたい

  • GitHubの時にはプライベートの
  • 会社のGitHub Enterpriseの時には会社の

Gitは環境変数GIT_AUTHOR_EMAIL GIT_COMMITTER_EMAILを参照するのでこれをdirenvで変更することで切り替えが出来る。

ghqを使ってリポジトリを管理していると便利で、$GOPATH以下が

├── git.yourcompany.com
│   └── orgA
│       └── repoB
└── github.com
    └── tnmt
        └── repoC

こんな感じになっていると思うので

  • $GOPATH/git.yourcompany.com/.envrc
  • $GOPATH/github.com/.envrc

にそれぞれ

export GIT_AUTHOR_EMAIL=foo@bar.org
export GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL

GIT_AUTHOR_EMAILのアドレスを変えたファイルを設置するとバッチリ?

ちなみにコミット時のユーザ名もGIT_COMMITTER_NAME GIT_AUTHOR_NAMEで制御できる。COMMITTERとAUTHORの差異はよく分からない。

Let's Encryptで取得したSSL証明書を使ってNginxをhttps, http2対応した

先日パブリックβになったLet's Encryptを使ってこのblogのSSL証明書を取得した。Clientを使えばすぐ出来る。

@hsbt日記でiniファイルを渡してcronで定期実行という便利技を見つけたので習った。

せっかく証明書を取得したし、合わせてNginxをhttp2対応もする。とはいえ、1.9.5以降のパッケージをmainlineのリポジトリからインストールして configuration の server ディレクティブを listen 443 ssl http2; とするだけ。