ロードバランサー再入門

こんにちわ。またエライ間隔があいてすんません。
酔っ払い系ツチノコです。

今回はロードバランサーとか ADC ( Application Delivery Controller ) とか呼ばれているもののお話です。

私は元々 L2/L3 のネットワークが専門で最近は仮想基盤なんかも扱っている感じのエンジニアなんですが、久々にロードバランサーに関わる事になりました。

過去にもある程度ロードバランサーについても構築・運用経験はあり、それなりに理解しているつもりだったのですが、実はロードバランサーを通る「パケットの気持ち」になりきれてない事がわかってきました。

同時に、この領域には体系化された教科書的な資料が少ないんだな、ということが見えてきまして、せっかくなのでカンファレンスでしゃべっちゃえ、ついでに同僚向けの研修用資料にしちゃえ、ということで書いちゃいました。

御自由にお使いください。

尚、パケットのウォークスルーを PowerPoint のアニメーションで書いている関係上、ダウンロードしてご覧頂いた方がいいかもしれません。

また、あわせて去年の Internet Week でしゃべったこちらの資料もご覧頂けると幸いです。GSLB なんかと多少からんできます。

 

P.S. 最近は業界の先輩におそわった上野せんべろライフを楽しんでおります。

それでは、よい酒ライフを。

OpenStackの設定と格闘していました

おはようございます。ライトノベル好きのツチノコです。

さて、先日までOpenStackの検証環境を作って検証をしていました(Mitaka Release)。
その時につらかったことの1つが、設定項目に設定するべき値やそもそも項目自体の存在がわからないということでした。
結果としてドキュメントやdaemon起動時の設定値のダンプを見ていろいろと悩んで解決できたのですが、そもそも設定値がどこで定義されているかをmain関数から追いかけてみました。

novaを例にとるとmain関数はcmd/以下にあります。
cmd/api.pyを例に読んでいきます。

37行目にそれっぽい部分があります。

CONF = nova.conf.CONF

nova.conf.CONFはconf/__init__.pyで定義されています。
cfg.CONFはoslo_config.cfg.CONFというグローバル変数で、その下にそれっぽい関数があります。

CONF = cfg.CONF

api.register_opts(CONF)
availability_zone.register_opts(CONF)
base.register_opts(CONF)
cache.register_opts(CONF)
cells.register_opts(CONF)

この関数の実態はconf/api.py#L403にあります。
それで上のほうを見ると、OptGroup(confファイルで[api]などのセクションになる)とOpt(confファイルでauth_stratedy=…_というオプションと値となる)が定義されているところが見つかります。

api_group = cfg.OptGroup('api',
    title='API options',
    help="""
Options under this group are used to define Nova API.
""")

auth_opts = [
    cfg.StrOpt("auth_strategy",
        default="keystone",
        choices=("keystone", "noauth2"),
        deprecated_group="DEFAULT",
        help="""
This determines the strategy to use for authentication: keystone or noauth2.
'noauth2' is designed for testing only, as it does no actual credential
checking. 'noauth2' provides administrative credentials only if 'admin' is
specified as the username.
"""),

まとめ(novaの場合)
・conf/*.py に各オプションの定義があります。
・import nova.conf した段階で各オプションがCONFに登録されます。

他の(いまのところドキュメントが充実していない)プロジェクトもこうやっていけばオプションにたどり着けるはずです。

おまけ
こんな感じで全ファイルをロードしてregister_opts関数を呼べばひょっとしてオプションのリストができるのではということを思いつきました。何事も暴力で解決するのが一番だ。

for 全ファイル
    import モジュール as dummy
    dummy.register_opts(conf)
    print(conf)

結果のnova.txt(348KBあります)の一部です。

[DEFAULT]

(snip...)

[api]

(snip...)

auth_strategy = keystone
# class:      
# deprecated: False
# multi:      False
# required:   False
# help:
# This determines the strategy to use for authentication: keystone or noauth2.
# 'noauth2' is designed for testing only, as it does no actual credential
# checking. 'noauth2' provides administrative credentials only if 'admin' is
# specified as the username.

わーい。

生成に利用したツールは以下の場所にあります。
リポジトリ
プロジェクトごとに生成したテキスト
中間生成されるjsonの例

ドキュメントがあればそちらを参照するのがよいですが、今のところドキュメントが見当たらないdesignate/magnumなども生成できますので、これはこれでよいかなというところです。

今後もいろいろ実験していこうかと思います。

P.S. 発売日が近い本の中でぜったい転職したいんです!! ~バニーガールは賢者を目指す~が気になっています

StackStorm 運用 TIPS ー config.yaml と config.schema.yaml の違い

 こんにちは、インフラ本部の大山裕泰です。
 ここでは StackStorm の開発・運用を実際に行っている人向けに、拡張モジュール (pack) のパラメータ設定のテーマで掘り下げた内容をお届けします。

 StackStorm がどんなもので、どういう問題を解決するかについては StackStormで始める運用自動化 ~入門編~ をご覧ください。

 このエントリによって、StackStorm pack の config.yaml と config.schema.yaml の違いや、どういったケースでどのような設定方法がベストかを理解できるようになると思います。

 冒頭で紹介した CodeZine の記事でも書きましたが、レガシーな pack の設定パラメータの記述方法として、対象 pack の `config.yaml` ファイルに記述する方法があります。その他に `config.schema.yaml` で設定されたパラメータを pack の設定コマンド `st2 pack config` から設定する方法と、StackStorm が参照するデータストア (本校執筆時点の StackStorm では `MongoDB` を使用) に設定する方法があります。
 ここでは AWS の StackStorm モジュール aws pack を例に、それぞれの方法の使い方や他の設定方法との違いについて解説して行きます。

config.yaml による設定

 config.yaml による設定は、最も単純な pack の設定パラメータの記述方法です。ユーザは config.yaml 編集し、StackStorm pack に任意のパラメータを渡すことができます。これにより、StackStorm の UI を通して外部サービスのイベントハンドリングやアクションを実行できます。
 以下は aws pack のデフォルトの config.yaml の全文になります。

---
# Note: credentials under "setup" object are deprecated and have been replaced
# with top-level values which have precedence and also work with dynamic config
# values.
setup:
  region: ""
  aws_access_key_id: null
  aws_secret_access_key: null

aws_access_key_id: null
aws_secret_access_key: null
region: "us-east-1"
interval: 20
st2_user_data: "/opt/stackstorm/packs/aws/actions/scripts/bootstrap_user.sh"

service_notifications_sensor:
  host: "localhost"
  port: 12345
  path: "/my-path"

sqs_sensor:
  input_queues:

sqs_other:
  max_number_of_messages: 1

 config.yaml は全ての pack で共通して pack の管理ディレクトリ (/opt/stackstorm/packs/{pack 名}/) の直下に置かれています。aws pack の場合には config.yaml は /opt/stackstorm/pack/aws/ 配下に置かれます。

config.schema.yaml による設定

 config.yaml はとても単純な仕組みで使い勝手が良いのですが、pack の管理ディレクトリ配下のファイルが状態を持ってしまうと、運用上で不都合が生じてしまいます。

 pack は StackStorm の ‘st2 pack install’ コマンドによって StackStorm-Exchange から最新のコードを取得し、対象 pack の管理ディレクトリ (/opt/stackstorm/packs/{pack名}/) にデプロイされた後、StackStorm に登録されます。
 また pack の削除は `st2 pack uninstall` コマンドで行いますが、その際 pack の管理ディレクトリがそっくり削除されるため、pack のデプロイ後に編集した config.yaml も削除されます。
 pack の削除以外でも、StackStorm-Exchange の pack が更新され config.yaml のスキーマが変わった場合には、pack のアップデート時にユーザが編集した config.yaml は上書きされてしまいます。

 こうした挙動は Infrastructure as Code のプラクティスに合ったもので問題ありません。
 むしろ config.yaml の存在によってポリシーと設定が結合する格好になり、上記のような運用上の問題が発生します。また、設定項目や設定値の型はユーザが自由に記述することができるため、設定周りのテストがしづらいという問題もあります。

 これに対して config.schema.yaml で記述される 設定スキーマ (Configuration schema) の仕組みが作られました。
 設定スキーマは、予め pack の作成者が必要な pack の設定項目のスキーマをスキーマファイル (config.schema.yaml) に定義しておき、ユーザは ‘st2 pack config ‘ コマンドによって、予め規定された設定項目・型の値を設定します。

 これによりテストし易くなるという利点のほか、設定結果を pack の管理ディレクトリとは別の設定項目を管理するディレクトリ ‘/opt/stackstorm/configs’ 配下に置き、ポリシーと分離させることで、pack のバージョンや状態に関わらず設定内容を独立させることができます。

 以下に aws pack の config.schema.yaml の全文を示します。

 ’st2 pack config aws’ を実行することで、上記のスキーマファイルに沿った入力が求められ、最終的に aws 用のオリジナルの設定ファイルが生成されます。

 なお、ここでの設定は cnofig.yaml の設定よりも優先されます。なので、同じ設定項目を config.yaml と config.schema.yaml から生成された設定ファイルの両方で設定されている場合には、後者の値が読み込まれます。

データストアによる設定

 最後に、データストアによる pack の設定について解説します。
 ’st2 key set’ コマンドによって、以下のように任意の key/value をデータストアに登録させることができます。

 センサーの実装においては、上記の config.yaml/config.schema.yaml による設定は起動時に読み込まれ、ここでの設定値は動的に読み込まれるような 使い分け をしており、aws pack のセンサーではこれに沿って、データストアによる設定が優先されるように実装されています。

 また Jinja template の拡張により、以下のように config.schema.yaml から生成した設定ファイルから、データストアで設定した値を参照させることができます。

 以下で、設定ファイルで指定したキー ‘dev_api_key’ の値 ‘SecretValue’ を暗号化して設定します。

 ただ、これには 文字列型しか設定できない制限 が存在するため、使用する際には注意が必要になります。

JANOG39ミーティング、本日最終日です!

始まったと思ったらもう最終日。
3日間、本当にあっという間でした。

2日目に行われた懇親会でツチノコNOCに参加してくれた学生たちがライトニングトークを行いました。

IMG_0074

2日間で起きたトラブル?!について

ホール入り口のアクセスポイントに繋がりにくい!

立ち見が出るセッションもありホールは大盛況。
アクセスポイント毎のアソシエート数を見ていると入り口付近は接続数が伸びていないことがわかりました。

会場図

立ち見の参加者さんが、アクセスポイントからの電波を通りにくくする壁となっていました。
そのため、該当のアクセスポイントの出力を下げ、他のアクセスポイントに逃がし繋がりにくさを回避しました。

接続数が少ないアクセスポイントの対応について

会場内に設置したアクセスポイントのなかで、極端に接続数が少ないものが確認できました。

接続数減少AP

現地を確認するとアクセスポイントの角度が設置時時よりずれていることがわかりました。
角度を戻すと少しずつ接続数が増えていき正常な動作に戻りました。

接続数減少AP2

用意したパトランプは…

パトランプ

Zabbixに連動したパトランプを用意しましたが、鳴り響いたのは撤去作業の時のみでした。
(監視の止め忘れによるもの)

最後に

短い時間で資料をまとめ、懇親会会場で発表をした学生ツチノコNOCメンバーお疲れさまでした。
小さな事項を挙げればキリがないですが、大きなトラブルもなく会場ネットワークを提供できたかと思います。

ご利用いただいたJANOGerの皆さまありがとうございました!
ご協力いただいたツチノコNOCメンバーのみんなありがとうございました!

今回の会場ネットワーク構築について、ツチノコブログで更新していきますのでお見逃しなく!

 

JANOG39ミーティングはじまりました!

本日からJANOG39ミーティングがはじまりました!
雪景色の金沢は、初日から大盛況です。

ツチノコNOCもフル稼働!

ツチノコNOCは午前中からフル稼働で設営を行いました。
プログラムの構成上、Day1が一番部屋を使うので準備が山積みです。

朝のブリーフィングでは、部屋の暖房が効き始めるまでコートが脱げないメンバーたち。

朝のMTGⅢ 朝のMTG2

まずは、譜面台にAPをくくりつけます。
レクチャーを受けながらもくもくと作業が進みます。

譜面台Ⅲ 譜面台4

各部屋に設置される前のAP群。
譜面台2 譜面台5

そして、配置。
譜面台6

続いて、ケーブル配線です。

ケーブル配線Ⅲ ケーブル配線1

ケーブル養生も忘れずに。

養生 養生2

お昼前に設営を完了し、ランチを食べて午後からの開場に備えます。

ランチ

いざ、開場!
会場ネットワークのweatermapを見ると会場のネットワークのトラフィックの様子がわかって面白いですよ。

https://weathermap.tnoc.party/

こちらはJANOG初日のWiFiアクセスポイントへの接続数です。
アクセスポイント毎に色分けしてあるのですが、BoFの時間に人が会場を移動した様子が良くわかります。

201701181640

最後に

ホールの入り口は協賛一覧のパネルがお出迎えしてくれます!
協賛してくださった企業様、ありがとうございました!

ホール入り口

明日、明後日も会場でお会いできることを楽しみにしています!
凍っている道路もありますので、足元お気を付けください。