ツチノコNOC 〜ホットステージ大会 LANケーブル作ったよ編〜

こんにちは、普段はDMMでサーバサイドエンジニアをしていますウドラです。

2017年1月18日〜20日に開催された、JANOG39のお手伝いをさせていただきました。ありえないくらい遅くなりましたが、2016年12月13日 〜 15日の3日間で開催されたホットステージ大会の様子をレポです。

ホットステージとは、実際の会場を想定し、 準備した機材でネットワークを構築し動作確認する作業のことです。設定した機材を最終的に、会場にもっていき配置していきます。実は、ホットステージがなにかさえ、わかっておりませんでした(*ノω・*)テヘ

主に3チームにわかれ、以下の作業をしました。
※一部残作業は、各チームがリモートで対応してくださったそうです。お疲れ様です(´;ω;`)

・ネットワーク … IXルータ、PoEスイッチ、APなどの設定作業
・サーバ … DHCPなどのサーバ構築や、監視ツールの導入
・WiFi … ケーブルの準備・チェック、仮組み

現場では、サーバサイドエンジニアの私には縁がない高価なCiscoのAP(中古)がごろごろ転がっていて、ドキドキです。

さて、私はホットステージ大会では、LANケーブルの作成をお手伝いさせていただいました!

事前に 会場下見 をしているので、ルータやAPなどの配置場所をもとに、必要なLANケーブルはリスト済です。今回、短いのは市販のもの、長いものは自分たちで作成しました。その長さ、MAX70m。

1. 既成品のLANケーブルのラベリング

まずは、既成のLANケーブルの長さを確認しながら、ラベリングをします。

ラベリングは、スイッチに大量のLANケーブルをさすので、緊急時にケーブルを抜き間違えを防止するために、必要な作業です。

こんな風にたくさんささっていると、どのケーブルかなんか、すぐさまわかりませんし。

ラベリングが完了したら、袋に戻します。袋にも、番号を書いておきます。
袋に番号があることで、会場設営でケーブルを探す手間を省くことができます。
地味な作業ですが、円滑な運営をするには必須の作業になるのです(`・ω・´)

2. LANケーブルの作成

既製品のラベリングが完了したら、既製品では準備できないLANケーブルの作成に入ります。

2-1. LANケーブルを測り、切る

LANケーブルは切られないものが売られています!

今回は、CAT5e UTP 4P TSUNET-350E 0.5-4P という カテゴリ5e(CAT5e)ケーブルを、ほしい長さに切って作成していきます。

60mオーバーのさを測るのか(;´д`)…と思ったんですが、心配無用。
ケーブルには1mごとに長さが表示されているので、欲しい長さまでひたすら箱からケーブルを出していきます。

ひたすら…

ひたすら…、ひたすら…

とにかく長いので、ケーブルを出す側と、出したケーブルを巻く係の二人一組で行いましょう。
ケーブルを巻くとき、ただまくのではなく、ケーブルをひく時からまないように、 八の字巻きで巻いていく必要があります!

…8の字巻き、…… 8の字巻き……
難しい(´;ω;`) とにかく、難しい(´;ω;`)

言葉では説明できないので図解をしてみました。こんな感じで、順手、逆手を交互に巻いていきます。

必要な長さを箱から出したら、ニッパーでざっくり切ります。

2-2. ケーブルの外皮を剥がす

保護ケーブル(ゴムの部分)の中から芯線をだすため、外皮むき工具などを使って保護ケーブルをはずしていきます。

このあと中の芯線をほぐしたりするので、5~8cmくらいのところで切れ目を入れてしまっていいと思います。
ケーブル自作初めて組なので、失敗を踏まえて少し長めから、外皮をはがしています。

外皮むき工具は、軽めに刃をいれてください!
強めに刃を入れると、中の芯線を傷つけてしまい、再び外皮をむきなおし作業…と、どんどんLANケーブルが短くなってしまいます。外皮むき工具は、軽くやさしく、1回転させて切れ込みをいれましょう。切れ込みをいれたら、ケーブルの端を強めにひっぱったりして、外皮をむきます。

2-3. ケーブルの撚りをほどく

芯線がでれきたら、カラフルな線が各ペアで絡まっているので、撚りをすべてほどいていきます。

ほぐします…

ほぐれーん!!!!!
四苦八苦していると、Wifiチームリーダーさんが、簡単なほぐし方をおしえてくれました!

先端の部分は切ってしまうので、強くぐりぐりして芯線を傷つけても、問題ないとのこと。
遠慮なく折ってトグル状にし、先端をぐるぐるまわして、撚りをほどいていきましょう!

2-4. ケーブルにコネクタを取り付ける

ほぐれたらコネクタに芯線をいれ取付作業を行います。今回準備したコネクタには、 ロードバー(蛍光黄色のやつ)があるタイプです。

芯線の並びは、T568A配線とT568B配線の2種類が存在します。AとBで性能の違いはないのですが、混在させていはいけません!

今回は、一般的なT568B配線で取り付けます。白橙(オレシロ)・橙(オレ) ・白緑(ミドシロ) ・青(アオ) ・白青(アオシロ) ・緑(ミドリ) ・白茶(チャシロ) ・茶(チャ)で並べていきます。

先にロードバーに芯線を、T568B配線順で差し込みます。

芯線がはみ出てる場合は、切って調整しましょう。切り終わったら、コネクタに差し込みます。コネクタ部分に金属があるので、少なくとも、芯線がツメ(金属)に触れる位置までは、ロードバーを押し込みます。爪が芯線に触れないと、ケーブルとして機能しないので注意。

コネクタにさしこんだら、かしめという工具で、圧着します。迷いなく一気にかしめます。これで、LANケーブルの完成!

3. LANケーブルのテスト

LANケーブルが問題なく、動くか検品しましょうー。FLUKE networks のケーブル・テスターを使います。

ちなみに、こちら100万円ほどする高級機械だそうな。とりあえず、拝んでおきましょう。

テスト開始

…見事合格。よかった(∩´∀`)∩ワーイ

損失も問題なかったようです。

今回5本ほどつくりましたが、1本以外は合格でした!
その1本もかしめが失敗しただけで、コネクタを付け直したところ見事合格できました!

逆に市販のケーブルは、2本以外は不合格という状況(´・ω・`)

テスター機械の性能がよすぎるので、数値的には問題なしとのことでしたが、LANケーブルは自作したほうが性能は圧倒的によさそうです。費用もかさみますが。

ということで、みなさんがホットステージを設定している横下でケーブル作成をしてたのでした。

ちょっと時間があまったから、熊手もつくったよ!

最後は仲良く記念撮影

作成したケーブル含めホットステージは、問題なく JANOG39で動作しました(∩´∀`)∩ワーイ

ロードバランサー再入門

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

今回はロードバランサーとか 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メンバーのみんなありがとうございました!

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