コマンド, 小ネタ

pingでsearchをかけるといろいろと出てくるpingライクなコマンド

みんなどんな役割を持っているんだろうか。

いわずと知れたpingのように各プロトコルで応答の確認を行うコマンドであり、

fping,httpingなど監視ツールと組み合わせて利用されることも多いんだと思いますが、

普段使いできそうなコマンドはあるのでしょうか。

さっそく、調べてみました。

fping:
複数のipにping
ioping:
簡易的なディスクレイテンシーモニタリング
omping:
マルチキャストとユニキャストで応答確認
hping:
icmp,udp,tcpなどいろんなパケットを生成し応答確認
arping:
イーサネットレベルの応答確認
2ping:
特定の2ホストでどちら側のホストに問題があるのか確認できる。
httping:
httpレスポンス詳細が確認できる。

結果、下記の三つのコマンドは覚えておいても損はないかなと思いました。

一つずつ確認していきます。

  1. httpingはウェブサーバで遅延しているときにどの部分で遅延が発生しているのかが確認できる。
  2. arpingはipバッティングがないかどうかの確認ができる
  3. iopingは実運用下の中でディスクのレイテンシーの悪化状況を確認できる。

1.httping

名前解決が完了するまでの時間
+サーバへ接続するまでの時間
+リクエストがサーバに受け付けられるまでの時間
+サーバが最初のデータをスタートするまでの時間
+データの転送が完了しコネクションがクローズされるまでの時間
=合計

がわかります。

これでどこの部分で遅延が発生しているのかが具体的にわかるようになります。

2.arping

このようにIPのconflictの確認が可能です。

このコマンドを運用に組み込んでIPバッティングを防いだりできます。


3.ioping

このように実稼働環境においてレイテンシーの変化を確認し増強のタイミングを見極めることができます。

ちなみに、pong2というOpenGLを利用した3Dゲームがあります。

3Dのピンポンゲームです。aptでサクっと入ります。画面はこんな感じ^^

pong2

iDC, インフラ全般, コラム

こんにちは。あきみちと申します。ゲストブロガーとしてツチノコブログで連載することになりました。連載の内容は、DMM.comの裏側で使われている技術などを解説するものですが、視点としては多少ネットワーク寄りになる予定です。

第一回は、DMM.comが運営されている環境の概観を紹介しつつ、今後掘り下げて行く予定にしている項目をいくつか示します。

DMM.comの規模

bps(bits per second)は、ネットワークを語るときに非常に良く利用される指標です。その名の通り、1秒間に何ビットが転送されるかを示しています。一般的なOSでは、8ビットを1バイトとして扱っているので、たとえば、800Mbpsでの通信であれば、100MBのファイルを1秒で転送できるぐらいだと言えます。

DMM.comが扱っているネットワークトラフィックは、ピーク時で100Gbpsを超えます。100Gbpsというのは、10GBのファイルを0.8秒間で送信するぐらいの規模ですが、それが毎秒送信されているのです。凄い量のパケットがDMM.comからインターネットに向けて毎秒配信されています。

このトラフィックは、「艦隊これくしょん」などのゲーム(2014年7月現在246タイトル)、コンテンツ配信、通信販売、オンラインレンタル、などを提供するためのものです。以下の図のように、DMM.comの会員数は増え続けていることもあり、インターネットに向けて配信しているトラフィックも年々上昇しています。2014年1月時点で、会員数は900万を超え、月間PVは16億にもなります。

100Gbpsものトラフィックをどのように捌くの?

現在、市場で購入可能な商用ネットワークインターフェースで最も広帯域なものは100Gbpsの通信が可能な100ギガイーサネットです。100ギガイーサネットは、数年前に標準化され、最近になってやっと商品が揃いつつありますが、それを使ったとしてもDMM.comの全てのトラフィックを捌くことはできません。さらに、一ヶ所で全てを配信するようなネットワーク設計にしてしまうと、何か問題が発生したときに全てがストップしてしまうので、複数の回線を使ってトラフィックが流れるようにしてあります。

AS間接続
図:AS間接続

DMM.comとインターネットを繋ぐ回線は、合計で180Gbpsの帯域があります。この値は年々増えていますが、まだまだ増えそうです。

この他、CDN(Content Delivery Network)事業者と呼ばれる、インターネットデータ配信代行を行う事業者に依頼してのデータ配信も行っています。

物理的にどこに置くの?

DMM.comが配信する100Gbpsを超えるトラフィックは、物理的に1ヶ所から配信されているわけではありません。

日本国内にある4ヶ所のデータセンターから配信されています。4つのうちの3つは東京にあり、残るひとつが九州にあります。それぞれ目的に応じてデータセンターが使い分けられています。

4つのデータセンター
図:4ヶ所のデータセンター

個人で小規模なWebサイトを運営する場合、ホスティング事業者などからサーバを借りますが、DMM.comの場合はデータセンター事業者から「場所」を借ります。このような場所借りは「コロケーション」と呼ばれています。コロケーションサービスによって提供されている場所に大量のサーバを持ち込み稼働させるという手法は、大規模なWebサービスを運用するうえで良く行われる手法です。

拠点間の通信ってどうやってるの?

DMM.comは、物理的に異なる4ヶ所のデータセンターで運用されていますが、それぞれのデータセンターを何らかの形で結ぶ必要があります。提供しているサービスが大きくなってくると、一ヶ所では運用し切れなくなり、一ヶ所で運用し切れなくなると拠点間の通信をどのように行うのかを考える必要がでてくるのです。

DMM.comは、東京都内にあるデータセンター間を結ぶために、「キャリア」と呼ばれる大規模通信事業者から光ファイバを借りています。こういった長距離光ファイバは、光が通っていない状態であることから「ダークファイバ」と呼ばれています。

拠点間を結ぶ方法としては、ダークファイバ、L2伝送、VPNなど、いくつかの方法がありますが、各事業者がおかれている状況に応じて必要なサービスが選択されたうえで運用されています。

「裏側」のトラフィック?

ネットワークトラフィックには「表側」と「裏側」があります。表側は、インターネットに対してサービスを提供する部分ですが、これが先ほど書いた100Gbps超のトラフィックです。

Webサービスの規模が大きくなってくると、1台のサーバだけで全てを完結するのが難しくなってきます。たとえば、DMM.comでは、データベース、ログイン認証、課金のための仕組み、データストレージなどが、それぞれ独立した別々のサーバで稼働しています。これらがDMM.com内部ネットワークでの「裏側」トラフィックを発生させます。

Webサービスの規模が大きくなって行くと、裏側のトラフィックをどのように制御するのかに関しても様々な工夫が必要になります。新しい機器が登場しがちなジャンルでもあるので、数年おきに運用トレンドが変わっていく部分でもあります。そういった「楽しさ」があるのも「裏側」の特徴かも知れません。

膨大な台数をどうやって管理するの?

DMM.comは、2014年8月現在、あわせて約4500台の物理サーバと仮想サーバをデータセンター内で運用しています。さらにそれに加えて外部のパブリッククラウドサーバでの運用も行なっています。

このような台数のサーバを全て手動でひとつひとつ制御するのは、もはや困難です。「複数のサーバを同時に制御するための仕組み」を考えることは、いままさに大きなトレンドであり、様々なものが提案されていますが、DMM.comでは構成管理ツールのansibleを一部で利用したり、Webサーバの操作やデプロイにcapistranoを利用しています。大量のWebサーバの管理は、capistrano等の自動化ツールがないと不可能です。

これらの他に、どのラックにどのような機器がマウントされているのかなどをRackTablesで管理しています(参考 racktablesを使っています)。

膨大なデータをどうやって記憶しておくの?

Webサービスが巨大になっていくにつれ、膨大な量のデータを扱う必要も出てきます。

個人的に運用している小規模なWebサイトであれば、1台のサーバにデータを記憶させておくことも可能でしょうが、規模が大きくなってくるとデータストレージ部分を独立したサーバ群として管理する必要がでてきます。

データストレージも時代とともにトレンドが変化している部分であると言えます。DMM.comでのデータストレージ方法も、そのうち解説する予定です。

続く

今後、こういった話などをひとつひとつ掘り下げて連載していきたいと考えています。お楽しみに!

ネットワーク

覚えなければ意味がないので簡単にいきます。

本当に必要最低限なんですが、
ネットワークエンジニアとの認識が合わせられるようになり確実に威力を発揮すると思います。

では進めていきます。

ネットワークは大きく分けてL2とL3の世界だということを認識し意識しましょう。
では、それぞれ重要と思われる部分を説明していきます。

 

■レイヤ2(データリンク層)

レイヤ2では各ノードを識別するためにNICやハードウェアに一意に割り当てられる物理アドレス(MACアドレス)を利用し、直接接続した機器同士の通信や電気信号の誤り訂正を行う。

レイヤ2に対応するテーブルはMACアドレステーブルである

MACアドレステーブル
接続機器のMACアドレスと自身のポートとの対応表で、接続機器から発せられる通信を参照することで学習、生成している。

使えるツール arping、arp など

 

■レイヤ3(ネットワーク層)

ネットワーク上のノードに一意のIPアドレス情報を割り当て、それを基に、異なるネットワーク間の中継やパケットサイズの変換などを行う。

レイヤ3に対応するテーブルはARPテーブル、ルーティングテーブルである。

ARPテーブル
IPアドレスやMACアドレスの対応表で、arpと呼ばれるプロトコルで取得し、生成している。
ルーティングテーブル
宛先ネットワークと転送先IPアドレスの対応表で、設定や近接機器との経路交換で学習、生成している。

使えるツール ip、ping、traceroute(tracert)など

 L3スイッチでは処理高速化のため、実際には前述のMACアドレステーブルやarpテーブル、ルーティングテーブルを基にFDBテーブルと呼ばれるテーブルを生成、ASICに落とし込んで処理をさせているが、論理的にL2スイッチと高速ルータに分かれていると考えれば良い。

 

■テーブル対応表

tableseet

上記を踏まえてここからは具体的にどのような点に注意すべきなのかをまとめました。 ここでもL2とL3の違いを意識してみていきましょう。
※そもそも分けてまとめていますが^^;

■L2で注意すべき点

上記の表からわかる通りMACアドレステーブルに注意

L2スイッチ間のケーブル配線の変更などまさにこのテーブルを気にするべきです。

逆に言えば、このMACアドレステーブルしか気にしなくても良い。

スイッチの配線を変更した際はこのMACアドレステーブルをクリアするか、エージングタイム(標準301秒~600秒)まで待つ必要がある。

※もしくは作業中に配下のサーバから連続pingを打っておくことで、配線変更後にスイッチが新しいポートで再学習、MACアドレステーブルを上書きするので、滞りなくスイッチ配線の変更が成功します。

■L3で注意すべき点

MACアドレステーブル、ARPテーブル、FDBテーブルに注意する。

サーバのNIC修理やサーバのIPアドレスを別のサーバへ切り替える場合にこれらを留意する必要がある。

ARPの保持期間はMACアドレスのそれより長くなっているので、タイムアウトまで待つのは現実てきではない。

基本的にはすべての機器ですべてのテーブルをクリアしておけば安心 ※GARPが対応していない機器もあるかもしれないので使わない。

ファイアーウォールや負荷分散装置などは意図的に実装を外している場合があるので特に気を付けること。

 

上記がサーバオペレーションで必要最低限気にしておくべき事項でたいてい予想外の障害も把握できるようになると思います。   最後にもっと絞ります。ここだけ読んでもいいかもしれません。

 

■まとめのまとめ。

・L3スイッチは論理的にL2スイッチとL3スイッチに分かれていていると考える。

・ネットワークメンテナンスはL2レベルとL3レベルを意識する。

・VLANにIPが設定できるインテリジェントL2スイッチというものがあるが、基本的にサーバが1台接続されたL2スイッチと考えておけば良い。 ※対象L2スイッチへの死活監視やリモート接続は影響を受けるが、L2スイッチを通過しているだけの通信には影響しない。

上記を最低限押さえておくことで、いろんな事が推測できるようになると思います。

これをベースにいろんな事が説明できるようになっていきます。

サーバにブリッジ機能を持たせた場合はMACアドレステーブルを持つことになるとか仮想化の部分の理解の助けにもなりますし、

OpenFlowの技術はL1からL4、L7などのマルチレイヤ層を抽象化(フロー化)し今まで階層ごとに処理していたものを一つのレイヤのみで転送できるようになる技術なんだとわかるとかですかね。

routeswitch

ということで、
本日のお話しは以上ですが、みなさん的に、これも忘れちゃいかんでしょ?ってありましたらツイートいただけると嬉しいです。反映したいと思います。

linux, コマンド, 小ネタ, 運用管理

ifconfigを含むnet-toolsが非推奨になって久しいようですが、

rhel7系からnet-toolsはおさらばとなります。
※手動で入れれば使えますが。

今思えば、ifconfig君

あなたと出会ってからこの十数年、あなたを打たなかった日はありません。

雨の日も風の日もいつも一緒だったね。

あなたがいつもいてくれたから私も輝けたんだといます。

これから私は新しいiproute2君と歩んでいくことになりますが、あなたのことは決して忘れることはないでしょう。

ifconfig君に幸あれ

P.S.
ついつい ifco[tab]ってやっちゃうのはご愛嬌です。

ということでnet-toolsとiproute2の対応表一覧です。自分の備忘録として残しておきます。

net-tools iproute2
ifconfig ip l (ip link)
ifconfig -a ip a show (ip addr show)
ifconfig eth0 up ip link set eth0 up
netstat ss
netstat -i ip -s link
netstat -l ss -l
netstat -r ip r (ip route)
route [add|del] ip route [add|del]
route -n ip route show
arp -n ip n (ip neighbor)

heartbeat+pacemakerなどで利用する仮想IPはipaddr2を利用しています。

そもそもifconfigではこのコマンドで設定されたIPは表示されません。rhel6系であってもip addr showで確認しなくてはいけません。

開発、オペレーションする側みんながこの違いを認識し共有することがミスを防ぐことになります。

小ネタ

こんにちは

焼き直し的なネタですが、お恥ずかしながら私は知らなかったので共有します。
ドキュメント用にIPアドレスとドメインが予約されているって話です。

RFC2606:ドメインについて

ドキュメント用に予約されているドメインは

example.com
example.net
example.org

※これらのドメイン名はドキュメンテーションにおける例を提示するために利用する。このドメインは予約されているので万が一パブリック環境で利用したとしても第三者に影響を及ぼすことがない。

jpドメインなら下記が予約されています。

example.jp
example.co.jp
example.ne.jp
ドメイン名例.JP

※また、exampleの後ろに0~9の数字、たとえばexample0.jpなどなども予約されています。

rfc5737(RFC3330):IPv4ドキュメント用アドレスブロック

192.0.2.0/24
198.51.100.0/24
203.0.113.0/24

※こちらもドメイン同様ドキュメントやサンプルコードで例を提示するために利用する。このIPアドレスはブロックされているので第三者に影響を及ぼすことがない。

ちなみにipv6はこちらです。

rfc3849:IPv6ドキュメント用アドレスプリフィックス

2001:0DB8::/32

今後はこのあたりも気にしながら書いてみます。^^

PAGE TOP