読者です 読者をやめる 読者になる 読者になる

befs_anneの日記

インフラエンジニアとして多少マシになっていく記録(予定)

フランクに原典にあたるということ

ポエム RFC

概要

最近RFCを読み始めた人の所感。

TL;DR

何らか調べものにおいて「原典にあたる」ということをはじめて教わったのは、マッキンゼー卒業生の人が書いた本だった。 これだったかな?

https://www.amazon.co.jp/マッキンゼー流-入社1年目問題解決の教科書-大嶋-祥誉/dp/4797369531www.amazon.co.jp

その頃はまだ前職に在籍していて、そんなに歳も変わらないのにかなり仕事のできるネットワークエンジニアがいた。彼はトラブルが起きた時の解決の手段として「RFCを読む」という選択肢を持っていて、ベンダマニュアルレベルで一通りの手段を試しても問題が解決しなかった場合、RFCに目を通してプロトコルの動きを確認していた。「当たり前だろ」と思う人もいるんだろうけど少なくとも私はそうじゃなくて、純粋に「すげーなこの人」と思っていた。

何が「すげー」かったのか?

純粋に「RFCを読む」ためには少なくとも英語が読めなきゃならない。今でこそ私も技術英語に慣れてきて、ベンダのKBぐらいならある程度の速度で読めるようになったものの、当時は今以上(以下というべきか)の英語弱者だったし、RFCはものにもよるけどボリュームがあるうえ抽象的な表現も多いし、トラブル発生時というのは通常業務に比べてインプットにかけられる時間も限られるので、そのスピード感の中であれを読むという選択肢は私は選べなかった。Google先生とベンダ、テクサポ頼み。エンジニアとしてはあまりかっこよくない。

最近の話

最近は業務に余裕が出てきたことと、もっと英語に慣れなきゃいけないということ、そしていい加減Google先生および「ネットワークエンジニアとして」離れをしなきゃならないという思いから、新しい技術に触れる時はRFCを読むようにしている。

しかし、RFCだけでそのプロトコルを理解しようとするのは中々にキツくて、他の日本語のドキュメントを参照してみたり、ツールを利用して少しでも読みやすくしたりしながら少しずつ読んでいる。

フランクに原典にあたるということ

はっきり言って今の私にとって原典(RFC)にあたるというのは結構なストレスだ。それでも、理解や問題解決の手法として「それ」を選べるということは、(業界で必須かどうかは一旦どうでもよくて)自意識のレベルで必要なことだと思っている。当たり前のようにRFCを読むということを選択できる彼のようには未だになれていないけど、いつか必要になる時のために、ヘルパーを頼りつつ目を通してみるのも悪くないと思う。

フランクに原典にあたるために使っているもの

「マスタリングTCP/IP」シリーズ

業界に飛び込んだ頃からの付き合いだけど、このシリーズの偉大さをあらためて思い知らされている。

www.amazon.co.jp

Google Dictionary Extension

ダブルクリックで単語を翻訳してくれる優れもの。Google翻訳が格段におりこうさんになったのは聞き及んでいるが、ページ丸ごと翻訳はしないという鉄の掟を守っている。

chrome.google.com

RFC読書会

……なるものをたまに見かける。気になる。一回身内(弊社内or同業の友人達)でやってみる?

Tremaで遊んだ

Trema Ruby ポエム

概要

Tremaで遊んだ。

Tremaとは

OpenFlowコントローラのプログラミングフレームワーク。 詳細は以下参照。

trema.github.io

TremaでOpenFlowプログラミング

プログラミングフレームワークとは

私のようなネットワーク土方には「プログラミングフレームワーク」という言葉がピンと来なかったのでググってみた。RubyだけでOpenFlowを動かすよりもTremaを挟んでやったほうが簡単に済むように、特定の機能・プロトコルを抽象化してとっつきやすくしてくれるものっぽい。前述のtrema-bookにも解説があるので併せて参照。

blog.codecamp.jp

遊んでみて

OpenFlowが一番バズってた頃は「ネットワークエンジニア絶滅の危機」な感じだったので毛嫌いしていたが、いざ遊んでみると面白いやつだった。こいつとだったらうまくやれそう。まだまだ本質的な使い方をしていないので、これから細々とやっていきたい。

にしても、我ながらPythonやったりRubyやったり忙しい。プログラマというのはそういうもんなんだろうか?

RXアクセラレーション(というかNICオフロード)が悪さをすることがあるらしい

Linux

概要

NICが持つRXアクセラレーション系の機能が、通信のパフォーマンスに悪影響を与えるケースがあるらしい。

RX アクセレーション (GRO、LRO、TPA など) を持つ NIC が、パフォーマンスが悪い TCP の影響を受ける場合がある - Red Hat Customer Portal

https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2090294

RXアクセラレーションとは

トラフィック受信時に発生するソフトウェア(CPU)処理を、ハードウェア(NIC)に肩代わり(オフロード)してもらっちゃおうという機能。「アクセラレーション」という言葉はよく出てくる(SSLアクセラレーションとか)けど、基本的にはハードウェア処理にすることを指すと思っておけばとりあえずよさそう。

LRO(Large Receive Offload)とは

セグメンテーションされたTCPパケットの構築をNICにやらせる。

Large receive offload - Wikipedia

GRO(Generic Receive Offload)とは

Red Hat Enterprise Linux 6 の低レベルネットワーク実装は、Generic Receive Offload (GRO) のサポートをその特徴の1つとして収納しています。 GRO システムは、CPU で実行されるプロセッシングの量を低減することにより来信ネットワーク接続のパフォーマンスを向上します。GRO は Large Receive Offload (LRO) システムと同じ技術を実装しますが、より広範囲のトランスポートレイヤープロトコルに適用できます。

解説だけ見ると、LROの上位互換に見える。

https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Release_Notes/networking.html#idp11696352

TX(送信)もあるでよ

TSO(TCP Segmentation Offload)やGSO(Generic Segmentation Offload)のように、TX(送信)オフロード機能も存在する。

TSO(TCP Segmentation Offload)の無効化 - Knowlege Database

オフロード系機能まとめ

Redhatのナレッジを見るのが話早そう。

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/network-nic-offloads.html

付き合い方

ネット上には送受信どちらにおいてもOFFにせよという記事が多い。

【CentOS7】オフロード機能まとめ – ZacoDesign

そんな中、以下のような情報もある。

uzy-exe.hateblo.jp

速さを追い求めるのでなければ、OFFが吉?

SRE Tech Talks #2に参加した

ポエム SRE イベント

概要

「SREとか超かっけえ」という生半可な気持ちで「SRE Tech Talks #2」なるイベントに参加して思ったこと。

SREとは何なのか

TLに流れてくるSRE関連ツイートから「SRE=超できるインフラエンジニア、または彼らによるエンジニアリング」ぐらいの定義をしていて、あぁなんて高い山だろうと勝手につらみを感じていたんだけど、最初のセッションでメルカリの@cubicdiyaさんがSREのミッションをオペレーションとソフトウェアエンジニアリングの2つにシンプルに定義してくれて、SRE(する)とは?っていうモヤが少し晴れた。Googleが公開したドキュメントも読み込んでみようと思う。英語苦手だけど。

Google - Site Reliability Engineering

技術が資本

登壇者の方々や懇親会でお話しした方々は皆スキルフルで、やっぱりSREも技術があって、その上で何をするか、なんだなと思った。On-Call Engineeringは目から鱗。他の登壇者の方のセッションも、DBチューニング、サーバクラスタリング、バックアップ技術など、同じSREという括りの中で、裾野の広さを感じさせられた。

制度も大事

@cubicdaiyaさんのセッションの話ばっかりだけど、制度設計や会社の理解も重要だと思い知らされた。「皆電車乗ってたら困るから、On-Call当番は他のメンバーが出社した後に遅れて出社する」とか、On-Call対応期間中の手当とか。

ネットワークエンジニアから見たSRE

Site Reliabilityっていうぐらいだから、やはりWeb/DB/Appのウェブ系三銃士(人によってはリバプロが加わる)の話がメインだった。やっぱりまだまだサーバサイドの修行が足りない。特にMySQLの話なんかチンプンカンプンだった。

インフラエンジニアに囲まれて仕事をしているからなんとなく自分もインフラエンジニアという括りにいれてしまいそうになるけど、実際のところ未だにネットワークエンジニアしている。それも昔ながらのネットワーク屋って感じの。同じようなことをしている人達を貶めるつもりは一切ないし、ネットワークは好きだから、私はネットワークのためにコードを書いて、ネットワークのためにAPIを叩きたい。

そんななので、イベント中「ほとんど(と言うか全く?)ネットワークについて誰も話さないけど、ネットワークってSite Reliabilityには関わってないの?」と思ってしまう。ネットワークエンジニアの視点から見たSREもまたオツだと思うので、ぜひ聞きたいし、私も話したい(でも自社の事例を話せるようなフランクな会社でないのがつらいところ)。

Windows10のVagrantでJuniper Fireflyを動かすまで

手順書 Vagrant VirtualBox Juniper Firefly

概要

このQiitaの投稿を見て思い立った。一筋縄ではいかなかったので、手順を残しておく。VagrantVirtualBoxはインストール済み。

qiita.com

手順

boxをダウンロード

vagrant box add firefly121X47D154 https://atlas.hashicorp.com/juniper/boxes/ffp-12.1X47-D15.4

Vagrantfileの生成と編集

ディレクトリを作ってvagrant initする。vagrantディレクトリは作成済み。

cd vagrant
mkdir firefly01
cd firefly 01
vagrant init firefly121X47D154

記事で紹介されていた通りに編集。

vim Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
    config.vm.box = "firefly121X47D154"
    config.vm.define :firefly01 do | firefly01 |
        firefly01.vm.hostname = 'firefly01'
        firefly01.vm.network "private_network",ip: "192.168.33.1",netmask: "255.255.255.0"
    end
end

VMを起動

vagrant upでVMを起動しようとしたら、プラグインをインストールするよう言われたので素直にインストール。

vagrant up # 以下プラグインのインストールを要求される
vagrant plugin install vagrant-host-shell
vagrant up # 以下プラグインのインストールを要求される
vagrant plugin install vagrant-junos
vagrant up # 成功

vagrant statusで確認すると、無事runningに。

Fireflyにログイン

ここで問題発生。記事ではvagrant sshでログインするが、Windows10にはデフォルトでSSHクライアントが入っていないためvagrant sshができない。bashからもSSHを試したがこれも不可(公開鍵認証しか許可されていないから?)。

①Git for Windowsをインストール

最初のトライでやった対応。以下の記事を参考にGit for Windowsをインストールする。

d.hatena.ne.jp

ホームに作成されたアイコンをダブルクリックして開いたプロンプトからVagrantfileがあるディレクトリへ移動し、vagrant sshする。インストール時にWindows標準のプロンプトを使用するよう指定したが、反応が非常に悪い。

bash on Ubuntu on Windowsからログイン

先ほど試したらうまくいったので併せて記載しておく。vagrant sshは公開鍵認証を利用してSSHログインするわけだが、前述の通りWindowsにはデフォルトでSSHクライアントはない。しかし、秘密鍵はしっかり作成してある。以下のコマンドで出力される「 IdentityFile」にその絶対パスが記載されている。

vagrant ssh-config

秘密鍵の所在を確認した後、以下を実行する。

  1. 秘密鍵bashの~/.ssh配下に格納(多分ここじゃなくても大丈夫)。
  2. ファイル名を「id_rsa」に変更。

以下を実行すれば、パスワード認証なしでログインできる。

ssh root@127.0.0.1 -p XXXX

1を実施しただけではログインできなかったのだが、秘密鍵のファイル名は「id_rsa」じゃないとダメなんだろうか?

※追記

秘密鍵の指定って方法もあるのか。

www.ellinikonblue.com

Fireflyの設定変更

SSHログインさえできれば、あとは新規のログインユーザを作るもよし、そのまま検証するもよし。

IOS-XRvをVirtualBoxとGNS3で動かすまで

手順書 VirtualBox GNS3 IOS-XRv

概要

タイトルの通り。某所でアリスタ社の方が「SNMP古い!これからのテレメトリーはgRPCだ!!」とおっしゃっていて、gRPCとは何ぞ~と思っていたところに「IOS-XRvのデモ版がタダで使えて、gRPCが動く」なんてツイートを見たので飛びついてみた。まずはPC上(Windows10、VirtualBoxとGNS3インストール済)で動かして、pingで疎通確認するところまで。

参照

www.youtube.com

www.routingloops.co.uk

手順

Ciscoサイトからイメージをダウンロード

以下のサイトからISOイメージをダウンロードする(要Cisco ID)。最新リリース(6.1.1)はOVAファイルしかないようだったので、それを落とした。

https://upload.cisco.com/cgi-bin/swc/fileexg/main.cgi?CONTYPES=Cisco-IOS-XRv

以下参考。

itpro.nikkeibp.co.jp

VirtualBoxVMを作成

「ファイル」→「仮想アプライアンスのインポート」を選択して、先ほどダウンロードしたOVAファイルを選択する(画像の「iosxrv01」は練習がてら作成したもの)。

f:id:befs_anne:20161214215044j:plain

f:id:befs_anne:20161214232449j:plain

初期設定は、名前とCPU、RAMだけいじっておく(8GBも食わせられないので)。

f:id:befs_anne:20161214225426j:plain

VMが完成。細かい設定をしていく。

f:id:befs_anne:20161214225657j:plain

起動時に読み込むメディアからフロッピーと光学を外す。

f:id:befs_anne:20161214225720j:plain

ネットワークアダプタMACアドレス以外全て同じ設定。

f:id:befs_anne:20161214225744j:plain

シリアルポートの設定。

f:id:befs_anne:20161214225805j:plain

GNS3でテンプレートを作成

「Edit」→「Preferences」→「VirtualBox VMs」を選択する。

f:id:befs_anne:20161214225927j:plain

「New」ボタンをクリックして新規テンプレートを作成する。

f:id:befs_anne:20161214230003j:plain

以下のように設定。

f:id:befs_anne:20161214230217j:plain

f:id:befs_anne:20161214230154j:plain

GNS3でVM配置、起動

画面左のルータの形をしたアイコンをクリックして、先ほど作成したiosxrv02を画面中央にD&Dする。

f:id:befs_anne:20161214230411j:plain

f:id:befs_anne:20161214230431j:plain

画面上部の再生ボタン(Start/Resume all devices)をクリックすると……こいつ、動くぞ!

f:id:befs_anne:20161214230700j:plain

ルータアイコンを右クリック→「Console」でコンソールを確認できる。

f:id:befs_anne:20161214230709j:plain

設定、結線、疎通確認

iosxrv01も起動して、もろもろ設定。

# iosxrv01
configure terminal
hostname iosxrv01
interface gigabitethernet 0/0/0/0
ipv4 address 10.0.0.1 255.255.255.0
no shutdown
commit
end

# iosxrv02
configure terminal
hostname iosxrv02
interface gigabitethernet 0/0/0/0
ipv4 address 10.0.0.2 255.255.255.0
no shutdown
commit
end

※まだ結線してないのに、no shutした段階でUp/Upになるのは……なぜ?

画面左のケーブルの形したアイコンをクリックして、各ルータアイコンをクリックしてケーブルを接続するI/Fを選択する(今回はEthernet0どうし)。

片方のiosxrvのコンソールから、対向のIPアドレスに向けてpingを送信する。

# iosxrv01
ping 10.0.0.2

無事通った。今日はここまで。

f:id:befs_anne:20161214231450j:plain

所感

はじめてIOS-XR触った。明らかに私がこれまで触ってきたIOSとは違うし、Junosとも違う。ハーフと言うとしっくりくる。本来の目的はgRPCの検証だけど、これを通してIOS-XRの習熟も図りたい。

あと概要を書いている時(「アリスタ社…」のところ)にアリスタのvEOSを思い出した。こっちでやればいいのでは……?gRPCできるか分からないけど。

VirtualBoxでAristaのvEOSを使えるようにする

……これはこれでやろう。

「転職しなきゃ」という病

ポエム

主な症状

知り合いの転職をきっかけとして、現在の職場、キャリア、エンジニアとしての市場価値に対する漠然とした不安感に襲われ、直近のタスクが手につかなくなる。症状が重くなると、現職の業務が満足にこなせていないにも関わらず、転職活動を始める。

予防・治療

  • 自身のキャリアパスの具体化と微調整(月次、年次など)。
  • キャリアパスを具体化する過程で洗い出した必要なスキルや経験の習得計画の策定と実施。
  • 資格取得、勉強会参加などによる自己啓発(ただし、無闇に実施するとキャリアパスに悪影響を及ぼす可能性もあるため注意)。

所感

仲良くしてくれる同期が近々転職するという話を聞いて、久々に症状が出てきた。一番最初に発症したのは尊敬している上司が帰りの電車で「転職を考えている」と言った時。その時は結局私の方が早く転職した。