職業体験みたいなことしてきました。
3月29日18:00 ~ 30:30
3月30日16:00 ~ 30:00
みっちり。
人員は僕も含めて3人。
ラックの移設とか配線とか。
光ファイバーのクリーナーなんて初めて触りました。
あと減衰調査の機材とか。
またもやCiscoルータとかスイッチをたくさんお目にかかる機会となりました。
しかも配線やら何やらも教えてもらいながら。
L3スイッチはもしかして初めて見たかも？ATMは久しぶり。
ラッキングのタグ付けとか配線まとめとか綺麗でした。
見習いたいもんです。
マジックテープがいいらしい。
なんかどこまで書いたらいいのか分からないので抽象的な感じ。
仕方ないか。
というのも、企業の人でも入れないようなところに入れてもらったようで。
そんなとこで作業してたのかぁ、と。そりゃ、守秘しないといけないね。
最初でこんな経験しちゃったので、しばらく並の場所では驚かないような気がしてきました。
いや、次もビビりそうかも？
ここまで書いといてなんですが、書いていいのかよく分かってません。
ま、いいや。
詳しくは本人まで。
雰囲気くらいなら話していいのかな。
実感したのは、ネットワーク系の知識はついてきてるかな、と。
プロの人の話についていけるようになってきた、っていうのが嬉しかったですね。
特に低レイヤ。設定とかは分かりませんでしたけど。
設定ってベンダー毎に違ったりするし…。
分からなかった部分は、これから再度学習します。
と、いっても足りないのはスイッチいじったりルータいじったりで補うしかなさそう。
どれだけ機器の設定をするか、ってことになりそうなので、時間かかりそうだな、と。
今は他にもいろいろ触っておきたいので一旦スタック積み積み。
話を聞いてると、ネットワーク+サーバ でやった方がいいみたい。
やっぱそうなるよねー。
あと物理層。やること山積みか。
ただでさえ春休みにやりたかったことの半分しか終わってないんだけど…。
ま、vCenterのせいってことで。
いろいろお話聞けたので、それを基にして院で頑張りますか。
今回の作業でも、ハプニングはありました。
ていうかハプニングだらけでした。
pingが通らない、とか。LAに聞きたかった。
結局解決してました。さすが。
またあるみたいなので、それまでにもっといろんな濃い話できるように頑張ります。
当面の課題は、L1で。
学習はやる気あるけど、勉強のやる気はでない。
なんか個人的に感覚違うので最近は学習って言うようにしてたりするというどうでもいいこと。
まとまりのない日記だなぁ。
ネットワーク系のことで少し疑問に思ったことなので備忘録的な。
疑問点 要請ノードマルチキャストアドレスはネットワーク負荷を軽減するのか？ 要請ノードマルチキャストアドレスは一意なものか？ の2点。
というわけで、説明していきます。
[]{#more-164}
負荷軽減？ ITproのページによると、要請ノードマルチキャストアドレスを用いることによりネットワーク負荷が軽減される、と記述されている。
これ、何と比べて負荷軽減なんだろうか。あと、どこの負荷なのか。
話の流れ的には「IPv4のブロードキャスト」と比べて「IPv6のマルチキャスト」の方が負荷軽減される、ってこと？
負荷は、ネットワーク？
そもそも、今読んでいる本では、「L2アドレス変換を行う要請ノードマルチキャストアドレスがLAN内の前端末あてにマルチキャスト送信される」ってかかれてる。
ってことは、ネットワークの負荷ではない？
つまり、「L2ブロードキャストを受け取ってしまった関係のないIPv4ノードがL3レベルでパケットを破棄する」ということと比べて「要請ノードマルチキャストを受け取ってしまった関係のないIPv6ノードがL2レベルでパケットを破棄する」ことが負荷軽減ってことかな？
まあIP以上はOSの域だしCPUリソースを若干使うとかその辺が負荷になってるのか。
ここまで予想。そのうち調べる。
要請ノードマルチキャストアドレスは一意なものか？ 要請ノードマルチキャストアドレスの作成方法は割とシンプルで、上位104ビットがff02::1:ffとなっていて、下位24ビットがIPv6アドレスの下位24ビットと同じになるというもの。
つまり、fe80::a8bb:ccff:fedd:eeffというIPv6アドレスが存在した場合、要請ノードマルチキャストアドレスはff02::1:ffdd:eeffとなる。
ここまでは良いんだけど、疑問に思ったのは「要請ノードマルチキャストアドレスが使われるのはIPv4でいうARPのようなL2アドレス変換の際である」と書いてあるため。
L2アドレス変換を行うっていうことは、一意なアドレスを指定しないといけないってことで、IPv4のときは4オクテット全て使ってARPしていたから分かるんだけど、IPv6のこの考えでは、下位24ビットしかみていない。
それじゃあ被ることってあるんじゃないの？被った時どうすんの？っていう疑問。
例えば、fe80::a7bb:ccff:fedd:eeffとかってIPv6アドレスがあった場合、要請ノードマルチキャストアドレスは同じものになってしまう。
EUI-64の場合は、上のようにouiが違ってノードidが同じだったら起こりうるわけで。
とか考えてググってみたら「アドレス重複の検出などにも使う」ね。
ちなみにこのサイトです。
でも結局元々の問題は解決してないわけであって…。
微妙に悩んだけど、これって送信元を未指定アドレスにしてレスポンスにIPv6アドレスとL2アドレスを載せるようにしてマルチキャストしたらいいのか、って考え。
ff02::1くらいに。
ってことで、その方面で軽くぐぐってみたらここに少し書いてる。
やっぱそれであってるっぽい？
ていうかさっきのIPv6アドレスだとEUI-64なのバレバレなんでaa:bb:cc:dd:ee:ffってMACアドレスなのはすぐばれちゃうってのもある。
んー、しかしそんな変換をいちいちするよりさっきのでNS送った方がいいのかな。
ちなみに要請ノードマルチキャストアドレスはSolicited-node Multicast Addressっていうらしい。へ〜。
そういえばこのページも見ました。
ついでにIPv6のプライバシー問題（？） 上で少し書いてるけど、EUI-64ではIPからMACアドレスがすぐにばれます。
世界で一意のはずのMACアドレスが簡単にばれちゃうわけ。こわ。
と、いっても最近はEUI-64で通信するってことあまりないんじゃないかな〜、とか思っていろいろやってたんですが。
学科VMのCentOSを使っている人は、EUI-64になっているかも。
その辺の設定した方が安心。
Macの人は
[bash]
sysctl net.inet6.ip6.use_tempaddr
[/bash]
で確認できるみたい。
1だとオッケーらしい（？）
ちなみにちなみに、高木先生のブログに行き着いた。
結構前の話題だけど、今更ようやくv6やり始めたから…。
CentOSの人は/etc/sysctl.confに
[bash]
net.ipv6.conf.eth0.use_tempaddr = 2
net.ipv6.conf.eth0.temp_valid_lft = 86400
net.ipv6.conf.eth0.temp_prefered_lft = 3600
[/bash]
でrebootしたらいいんじゃないかと。
心配な人は確認してみてください。
ubuntuも同じ感じでいけるかも？
vCenter5 Windows Server 2012にvCenter5入れるとか。
割と苦労しました。オチもあります。
まず、インストールできない。
SQLとかシステムDSNとかActiveDirectoryとかその他もろもろ。
そんな感じのとこをいじってなんとかインストール・起動オッケー。
さっと書いてますが、かなり時間食いました。
Windows いじっていて思ったんですが、ログの場所が分かりにくい。
まあ紆余曲折を経てなんとかインストールは大丈夫じゃないの？ってとこまでたどり着きます。
起動しません。
こっちも
結局最後の要因は、勘で、「依存関係か！きっとそれしかない！」みたいな感じになって必死にぐぐってたらありました。
プロンプトで変なコマンド実行する感じ。
コマンドプロンプト開くのは得意です。
「Winキー + r」したあと"cmd"と打ち込みエンター押せば起動します。
この辺はなぜか昔から知ってた。
しかし、「C:¥"Program Files(x64)」みたいな部分見づらい。
あと、Windowsのpingってv4/v6切り替えどこでやるんだろー、とか。
IP？まあいいや。
起動後のオチ いろいろやって起動したんですが、起動した後にvmwareのページに飛んでみると、
「vCenter5はWindows Server 2012には対応していない」
と。
うおおおおおおおおおおおおおおおおおおおおお！！！！！！！！！！！！！！
いや、遅いよ！！！！！！！！！
と、いうわけで必死に「対応してないOSに対応させてた」ってわけです。
そりゃ時間も食う。
ていうか動くんだね！スゴい！
Update 2で対応しているみたいです。
ちなみにこのページに書いてます。
サポートされました！やったね！
いや、もうなんかね！
そんな落ちでした。
教訓：ちゃんとリリースノート見よう。 これ大事。すごく大事。
“ググり力"が若干アップしたような、してないような。
もしかして：ググり力以前の問題…？
そんなわけで、そろそろ（自分で作った）Windowsに振り回される時期は終わるんじゃないかな。
まあ、こういっちゃなんですが、楽しかったです。
しかし、もう少し賢くなれないかな…。
次、気をつけよう。次。
なんか地味に作業が多くて時間を取りにくい。
行き詰まったり空いた時間に本読むという流れが最近できてきて良い感じかなと。
バックアップ処理中は暇だし…というわけでそんな時間に本読んだり。
まさしく今。
仕組みが見えるシリーズ シリーズ系って、最初手にしたものが良かったりすると読みたくなります
このシリーズもそうで、以前書いた『仮想化の基本と技術』が良かったので読んでみたくなり、今回読むことにしました。
今回の本は あまり僕がやってきたこととは違った分野についてのものでした。
そのため読みながら新鮮さを感じてました。
データ分析の基礎知識から説明が入って「相関と回帰分析」「時系列分析」「多次元分析」など多くのデータ分析について例を交え、また、データ分析の特徴などしっかり書いていたので分かりやすいです。
計算式も地味に多かったりして数字好きな人には良いのではないでしょうか。
現実にあるデータがどんな風に分析されているのか、とか気になる人にはオススメ。
僕も楽しく読めたので入門者向けで間違いないかと。
興味 この関係も面白そうだなーとは思いますが、「やっぱネットワークかな〜」と。
インフラ楽しいです。
3月中盤過ぎ と、いうわけで3月ももう19日となってしまいましたが、ようやく4冊…。
次読むのはしばらくぶりにネットワーク分野なので、今から楽しみです。
そろそろバックアップ終わってくれないかな〜。
意外と読み終わるの早かった。
今回は、データベース。
『ネットワークの知識と実務』より読みやすかったです。
ちなみにその時のブログはココ。
まあ、ネットワークは説明することが多かったからでしょうね。
後は、「知ってる内容が多かった」とか。
感想 読んだ後の感想としては、割と知ってたってのが正直なところ。
正規化とかトランザクションとか考えてデータベースいじる人には、物足りない内容かも。
ネットワークでは知識編が良かったのに対して、データベースでは実務編がためになりました。
知識編で書いてる内容を、実務編で「どのように使うか」とまとめられていた点です。
チューニングの仕方なんかも簡単にではありますが書いてましたね。
tuningathonのとき読んでいたかったかも。
MySQLとかPostgreSQLとかの踏み込んだ内容ではないのですが、データベースの知識全体を抑えるのには向いているかと。
浅く広くってやつ。
さくさく読めるので、多くの人にオススメできるんじゃないでしょうか。
実務編ではMySQLが取り上げられて説明がありました。
InnoDBとかMyIsamとかの説明があったわけではないのですが、ストーリーに沿ってER図の作成から行っていたので、実際の業務っぽい流れを大雑把に知ることができます。
この辺りも良い点ではないかと。
本選び 今回は、知ってる内容が多いということで非常に読みやすかったわけですが、これまで取り上げた2冊に比べて新しい知識が少なかったのが残念。
復習になるし、本を読むことで体系化できるってのはでかいメリットではあるのですが、それでもやはり「なるべく多くの新知識が欲しい」という欲が出ます。
そのために時間をかけて本を選ぶというのも何か違うような気もしますし。時間は価値の高いリソースですから有効利用したいです。
その辺はおいおい考えるとします。
とりあえず今は、積んでる本をなくしましょう。
最近思った以上に時間が取れず、読み終えるのに結構かかりましたが、ようやく読み終えました。
最初のうちは割と読み進めやすい感じでしたが、途中で若干詰まるところも。
個人的に読みたかったのはサーバーとネットワークの部分でしたが、クラウドとかも触れられていて良かったかと。
世の中で「クラウド」って言葉は結構流行っているわけですけど、詳しくは知りませんでしたし。
サービス使ってるから「こんな感じなのがクラウドか〜」っていう感覚的な理解、というか何も考えてないに近かったです。
ある程度払拭された点が良かったと思います。
割と基礎的な内容が多かったのだろうとは思いますが、専門外はさっぱり…。
CPUの仮想化支援機構とか時間かかりました。多分まだちゃんとは理解できてません。
あと良かった点としては、実例がかなり多いところ。
ESXiとかXenとかHyper-Vとか、他にも多数の実例を紹介しつつ説明があったのがイメージしやすかったです。
図もかなり多いですし。
これ読むと、サーバ・ネットワーク・ストレージ・クラウドの基礎的な部分を浅く広く触れるのではないかと思います。
「仮想化」が中心なわけですが、若干従来の説明もあって助かります。
windows 難しい。
Active Directoryとか以前の問題で、操作とか。
どこに何があるのか分からなさ過ぎて全部ググってます。
そう、Internet Explorerでね。
嘘です。使ってません。終わり。
ちょっと機会があり、見学に行ってきたので感想。
感想書くまでが見学会。
NOC… Network Operations Center らしい。
独特の匂いというか なんという「機械機械しい」匂い、あと機械音。
学科のなんて小さ過ぎて笑ってしまうレベルでした。
情報処理センターのでも、小さいんだな〜。
むき出しのシングルモード光ファイバケーブルを初めてみてテンションあがっちゃったりなんかしました。
おー、数字的には知ってたけど、やっぱり細いなー。
光ファイバケーブルのコア部が石英ガラスでできてるってのは常識として、なんかすっごい曲がり方してて気になって聞いてみると、光ファイバケーブルって今は90度曲げれるらしい！
ガラスなんじゃねーのか…って感じでした。不思議技術！
Cisco かなりCiscoの機材に目がいってました。
Catalyst 4500とかすごく目につきました。
後で調べると、Catalyst 4500って中古でも数十万する…。
生で多くの製品見れて「すげーすげー」言ってました。
IBM IBMの機材なんかもありました。
というより、IBMは「ラックまるごとドーン！」って感じで6ラックくらい置かれてましたね。
ラックの隙間から中見たらHDDの量とかかっこいー！って感じ。
ADSLやらISDN なんかすごい追いやられ方というかなんというか。
使ってる人少ないから仕方ないのかな。
セキュリティ 静脈の(?)生体認証使ったのは初めて！
敷地内に入るのに1回認証し、建物への入り口で認証扉2枚。サーバルームへの入り口で認証扉2枚を通りました。
詳しく書いていいのか分からないのであまり書きませんが、とりあえずスゴかったです。
人数確認のカメラがうまく動作されずに「侵入者あり。係員が応答に参ります。侵入者あり。係員が応答に参ります。」とアナウンスが流れたのは笑いました。
後で聞くと、カメラの近く(真下？)に人が立っていたせいだったみたい。死角だったのかな。
事前知識 いや、『ネットワークの知識と実務』読んでおいて良かったな〜と思うことも多々。
ネットワーク系の事前知識を学習した後だったので、余計にワクワクしましたね。
やっぱり、少しでも事前知識があるとああいう所は楽しさが一気に増します。
そんな感じ かなりうろちょろしてたような…。
ケーブル類とか知らない規格とかで分からないことだらけでしたが、テンション上がり興奮してました。
入る機会なんて滅多にないところのはずなので、ラッキーでした。
今後もこういう機会あったらまた見に行きたいですね。
『ネットワークの知識と実務』 320ページくらいの本ですが、約一週間かけて読み終えました。
ちなみに今日で180ページくらい読みました。頭がパンクしそう。
読んでいて「理解しやすかった」です。
多分卒論というバックボーンがあったからでしょうけどね。
パッと思ったこととしては、「入門者向けなのか・・・？」と。
入門者のレベルにもよるんでしょうけど。
「OSIのL1~L4までの知識をwikiで見たことある、とかのレベルなら読みやすいのかも？」
とか思ってまたぱらぱら見直しましたが、これはやはりもう少しネットワークの知識が必要っぽい。
最近はL1~L4好きな人になりつつあるので僕は楽しく読めました。
知識編 L1~L4とセキュリティについての体系的に学べます。
今まで研究だのシスカンだのでggって得た断片的な知識が繋がる感じがして気持ちよく読み進めてました。
って、これ書いて「やっぱ知識ないと読み進めにくいのかも」と。
実務編 プロマネっぽい。
割と設計とか学ぶ機会って無いので、この本で大局的にでも知れて良かったかな、と思います。
これを足がかりに、プロマネの授業も理解しやすくなってくれると良いなぁ。
終わりに 「ネットワークに興味がある」という人は読んでおいて良いのではないか、と思います。
僕自身あまり本を読んでないので「なんでそう思うの？」って聞かれたら「僕が読んでいて勉強になったから」とか「読んでいてワクワクしたから」としか言いようが無いですが。
しかし、、、
アプリケーション層のような上位レイヤより低レイヤを楽しく感じるという時代逆行感。
L2とかL3辺りが良いですね。
ここ が前回。
クイズ〜その1〜 [bash]
$ perl -e ‘print "1\n" ; warn "2\n";'
[/bash]
これですが、普通に
[bash]
$ 1
$ 2
[/bash]
と表示されるだけです。まあ別に問題ない。
クイズ〜その2〜 [bash]
$ perl -e ‘print "1\n" ; warn "2\n";’ >a.txt
[/bash]
これですが、
[bash]
$ 2
[/bash]
となります。
1 がどこに消えたかというと、
[bash]
$ cat a.txt
[/bash]
で出てきます。
この結果の違いは、標準出力と標準エラー出力の違いのためです。
標準出力は、画面への出力、または、次のコマンドに対して標準入力
のどちらかとなります。
それに対して、標準エラー出力は、ユーザの目に見える形に直接出力します。
図で見る [bash]
$ perl -e ‘print "1\n" ; warn "2\n";'
[/bash]
の場合を見てみると…
となるので、両方ともディスプレイに表示されます。
次は、grepを使ってみます。
[bash]
$ perl -e ‘print "1\n" ; warn "2\n";’ | grep 1
無事に終えて まあ、一安心。
論文は結局、目標の45ページは超えませんでした。
目次を見てみると半分以上が研究内容の章だったので、そこは目標達成かな。
図を多用しているので、もうちょっといくかと思ったけど意外と進みにくかったです。
春休み！かな？
tex 改ページは使うなとのことを言われたので[H]を使う感じで。
まあ、確かにtexに任せた方が良いですね。
texってよく見てみるとWARNING出るんですよね。
プログラムでは注意するのに、こちらは見逃しがち…。
卒論 テーマ決めが一番の難題でした。
決まらないってことはすることが分からない状態に近いので、やることが見えてることを先にやっちゃうんですよね。その方が楽しいし。
当初は研究よりシスカン楽しい状態でした。
チケットあるのでやること見えてるし、やったことは目に見えるし。
そして、それがずるずると…。
と、いうわけで、テーマは本当に早い方がいいんだな、っていうことを実感しました。
修士進学予定なので、そこでは気をつけたい。というか、今のテーマが面白いので続けていきたいです。
テーマが決まって進めていけば、そのテーマの問題点とか結構見えてきてようやく「この辺研究っぽくなるかな」というイメージが湧くようになりました。
修士に向けての基礎知識のような感じだったのかな、と。今思えば。
テーマの大枠は卒論で取り扱った技術として、細かいところも早めに決めちゃいたいところなんですが…。
授業がー、就活がー、という流れになりそうで怖いです。（というかなると思う。）
あと、お金ないのでバイトもどうにかしないといけないですし。
すでに先行き不安感。
研究の進め方の反省 卒研ノートはしっかり取るべき
やった内容も後からみて分かります。そして最終的に提出するときに慌てないで済みます。
（といってもこれってJABEEのものなんでしたっけ？来年から関係ない？）
まあ、ライフログ的な感じで。 人に話す
どういうことかっていうと、自分のやっている研究についてとにかく同じ研究室の先輩やら同期やらに話すということです。
問題点でもなんでも。
「こんなことできたぜ！すごくね？」とか的なことでも（同期には話しやすいはず）。
一人でやってもどっかで詰まることは分かってるし、一人で考えるより複数人で話しながらやった方がアイディア出やすいです。
問題点の解決策を自分で考えついていたとしても「○○な問題があって、解決したいんだけど」と聞いてみるべき。
一人一人考え方は違うわけで、割と参考になります。
あと、話していて自分のやっていることが整理できるのがでかいです。
人に話せるようにまとめる、という力にもなるのかな、と。 そんなわけで後半というか、ここ最近はいろいろ話すよう努力しました。
というかドヤ顔で「実験結果良くなったぜ」的なことばっかしてたような、というかしてました。
まあ、「周りが何やってるかよくわからない」研究室よりも「周りとよく話してやっていることを把握している」研究室の方が私は魅力的に感じます。
あとは、話す相手ってのは同じ研究室じゃなくて別研究室でもいいんじゃないかな、と。
「分野違うから話しても意味無い」ということは無いはず。
別研究室にいってドヤ顔で「実験結果良かったわ〜」ってするわけですよ。うざいだけです。
なぜ反省かというと、ちょっと気付くのが遅かったからですね。
ていうか先輩に聞け、同期に話せ、ってのが割と近い？いや、もちろん先輩に話しても同期に聞いてもいいんですけど。
と、ここまで書いて思い出しましたが、いろいろ話した同期は来年別の場所でした。oh…。
卒論発表の反省 練習
明らかに練習不足でした。
嚼みまくり。話す相手をちゃんと見てなかったのも反省点。
もう少し度胸が必要ですね。発表直前は割と緊張してました。
「やることはやったし先輩にも見てもらってオッケー貰えたから大丈夫」って唱えてたら楽になりました。
先輩==仏？ 質問
質問の意図を聞き違えていました。
やはり「○○という質問内容ですか？」のように確認するのがベターかも。 反省ばっかり書いても しょうがないので良かったと思う点も。
発表時間
発表時間はちょうど良かったかな、と。12分制限で、11分40秒くらいでした。
ある意味、練習不足で嚼み噛みだったからかも？練習したら、もっと情報詰めれたかな。 質問の予想
割と質問の予想はしてましたし、先輩にもお願いしたり同期にも聞きました。