ErogameScape －エロゲー批評空間－ Blog

2016の年末から2017年の年始にかけてPHPを7.1にあげました。
そのタイミングと同時にErogameScapeに接続しづらくなる事象が発生しました。
結論から書くと、PHPのVerUPは関係なく、サーバーを収容しているスイッチのPPPoE向けポートの障害だったことが分かりました。
最終的な切り分け結果を以下に示します。


悩まされたのが、開発用から現用系へのpingはOKですが、http接続はOKだったりNGだったりすることでした。
http接続が完全にOKでしたら、スイッチのPPPoE向けポートが悪いと断言できるのですが、微妙にNGになるのです…

被疑箇所のポートに刺さっていたLANケーブルを別のポートに接続したところ事象が発生しなくなったので、おそらくこのポートが被疑だと思います。

PHPのVerを7.1にあげた際に事象が発生したことと、サーバーへのpingはOKとなることから、PHPとApacheを被疑として調査していたのですが、当たり前ですが悪い箇所は見当たらず、しかしApacheを再起動すると直ることが多く(直らないこともありました)、現象は5分程度で自然回復するため、切り分けに時間がかかってしまいました。

調査の対象に「サーバーからPPPoEルータ向けにping」を追加していれば、もっと早く分かった気がいたします。ここの区間は疑っていませんでした。

ある日、何回やってもpg_basebackupが失敗する事象が発生しました。
結論から書くと、PPPoEルータの再起動で回復しました。

pg_basebackupは-Pと-vのオプションをつけると、今、どのファイルを送っているのかを見ることができます。
今回の事象は、途中でファイルの転送が止まる…というものでした。

転送が止まった時のメッセージは以下のとおりです。

トランザクションログの開始ポイント: タイムライン18上の35/CE053750
  617773/12835829 kB (4%), 0/1 テーブル空間 (...ive_log/0000001200000035000000B4)

トランザクションログの開始ポイント: タイムライン18上の35/C9000028
 3803779/12753907 kB (29%), 0/1 テーブル空間 (...gsql/9.6/data/base/16390/18342.1)

何回かpg_basebackupを試してみたのですが、同じファイルで転送が失敗するわけではありませんでした。
最初は快調にデータを送るのですが、ピタッと転送が止まります。

ErogameScapeは自宅サーバーなので、いつもそこそこの量のパケットをPPPoEルータは処理をしています。
サービス影響は見えなかったので、バックアップ先を疑ってみたり、バックアップ先までのネットワークで大量のデータを送ったときにパケットを阻止している…可能性を疑って、別のサーバーにバックアップを試したり、プロバイダを変更したりしましたがNGでした。

pg_basebackupは-X sオプションをつけると、トランザクションログをストリームするのですが、面白いことにselect * from pg_stat_replicationを見ると、backupの接続は切れるのに、streamの接続は切れずに、淡々と送り続けていました。
これを見て、ネットワークは繋がっいてデータは転送できるのに、backupの接続だけ切れるようにみえて…実際にそうなのですが…pg_basebackupだけを疑って切り分けをしていました。

ちなみにpg_basebackupに-X sオプションをつけて実行した際の、select * from pg_stat_replicationは以下のようになります。2つ接続が開かれているのが分かります。

# select * from pg_stat_replication;
  pid  | usesysid |     usename      | application_name |  client_addr    | client_hostname | client_port |         backend_st
art         | backend_xmin |   state   | sent_location | write_location   | flush_location | replay_location | sync_priority |
 sync_state
-------+----------+------------------+------------------+-----------------+-----------------+-------------+-------------------
------------+--------------+-----------+---------------+----------------+----------------+-----------------+---------------+
------------
 12737 |    16389 | replication_user | pg_basebackup    | ***.***.***.*** |                 |       36151 | 2017-02-12 21:28:1
9.644764+09 |              | backup    |               |                |                |                 |             0 |
 async
 12836 |    16389 | replication_user | pg_basebackup    | ***.***.***.*** |                 |       36152 | 2017-02-12 21:29:2
4.968719+09 |              | streaming | 35/C022FB60   | 35/C022E9C0    | 35/C0000000    |                 |             0 |
 async
(2 行)

その後、大量データをインターネットの向こうにあるサーバーに送ると途中で転送が止まることが分かり、pg_basebackupの問題ではないことが分かりました。

ErogameScapeに使用しているPPPoEルータとは別のPPPoEルータを介してバックアップ先にデータを転送するとOKだったので、ErogameScapeに使用しているPPPoEルータを疑って再起動したところ回復しました。

ああ…こういう不具合が起きることもあるんだなあ…と思った次第です。
ネットワーク機器は、思いもよらない壊れ方をします…

ErogameScapeのサーバーマシンは夏になると熱すぎてthermal event interruptsがたびたび発生していました。
※ thermal event interruptsが発生するとどういう影響があるのか分からないのですが…

年末にサーバーマシンの全面の蓋を開けたら吸気口がすごいことになっていました。


これを掃除したところ、おそらくPC内の温度が劇的に下がりました。

これで今年の夏が乗り切れるといいな…と思います。

Linuxのシェルの1つであるbashにとんでもない脆弱性が発見されて大変なことになっています。
私はWindowsしか使っていないから大丈夫…と思っていても、実は周辺機器がLinuxベースで動いていて、その周辺機器がWebブラウザで操作出来るものの場合、今回発見された脆弱性の対象である可能性があります。

bash脆弱性、国内メーカーの対応まとめ（10月3日夜現在） - ITmedia エンタープライズ
を見て頂くと、だいぶ多くの製品が該当することになります。
ぜひ、周辺機器もご確認頂きたいと思います。

以前、私は、ErogameScapeで使っているFutureNet XR-410/TX2がNTPの脆弱性に該当することに気がつかずに世界に迷惑をかけたことがありました。
NTPの脆弱性が発見されたことには気がついていて、サーバーマシン自体の対処は実施したのですが、XR-410がLInuxベースで動いていてかつNTPが動作していて、当時発見された脆弱性に該当することに気がつかずに対処が出来ておらず、DDosの踏み台になってしまいました…

FutureNet XR-410/TX2はサポート終了が2015/03/31ですので、今回のbashの脆弱性に対応するためのファームがリリースされるので、すごくうれしいですが、サポート終了が目前ですので、別の機器に入れ替えないといけない…と今、気がつきました…

ちなみに今回の件で、実はXR-410/TX2にインターネット側からアクセスできることを知って青ざめました…
今まで何も問題が無かったことが奇跡です… 

ビルには電力点検があって、1年に1回は点検のために電気がこなくなる日があります。
自宅サーバーでは電力点検以外の理由でも、サーバーをシャットダウンする必要があったりします。

私の経験でしかないのですが、サーバーやNW機器は電源をOFF/ONすると、今までちゃんと動いていたのに、壊れたりあがってこなかったりすることがよくある気がします。

ちょっと前に、自宅サーバーの大規模メンテナンスですべての機器の電源を落としたのですか

• サーバー1台が立ち上がらない。モニタに何も映らないし最小構成(M/BとCPUだけ)にしても何も映らない。
• L2SWが微妙に故障。ONUとのリンクが確立せず、pingは100%通るけど、スピードが全然出ない。

 という結果になりました。
L2SWもサーバーも予備機があったので、予備機と交換して復旧させました。
※予備機大事です。前にL2SWが壊れたときは予備機が無くて大変なことになりました。

さて…あがってこなかったサーバーは、多分、M/BかCPUが壊れた気がしているのですが、交換してみないとどちらが壊れたか分かりません。
そして、もう3年も前のM/BやCPUですので同じ物がありません。
※中古を頑張って探すしかないです。

新しいM/Bを買ってくると、多分、OSから再インストールになるので、面倒です。
※動いたらラッキーですが、うまく動かないのだろうなあ…と。

この問題を解決するには

1. 買った当時にM/BとCPUは同じ物を買っておく
2. あきらめてOSの再インストールからはじめる
3. 自宅サーバーをやめてデータセンターに移行する

という3つの選択肢があります。

昨今のVPSや専用サーバーやクラウドの価格を考えると、負荷が年々高まっていくのであれば、3.のデータセンターに移行するというのが、簡単にスケールアップ/アウトできていいのでしょうが、ErogameScapeはもう負荷が高まる要因がないので1.でいいのかな…と思っています。

2.も…たまにOSの再インストールからやらないと、不慮の事故で全部のサーバーが駄目になったときに、何も出来なくなるので、選択肢としてはありかな…という気がしています。
 

はじめに

第2回さくら石狩DC見学ツアー～さくらの夕べin石狩～に参加してきました。




体験記としてはさくらインターネット #石狩DC 体験記 - myfinderのはてなブログが一番だと思います。
この文書を読むよりは上記文書を読んで頂いた方がよいです。

さくらインターネット公式の記事は以下の通りです。

Blogを書くまでが第2回さくら石狩DC見学ツアーである…という田中社長のお言葉がありましたので頑張ってBlogを書いている次第です。

あまりメモをしてこなかったので頂いた写真を元に記憶を掘り起こしてコメントをしていきます。
間違っていたら…他に参加された方々がコメントして頂けると勝手に思っていますので、よろしくお願いいたします。


写真から記憶を掘り起こして

下の画面は、見学者用に作られた空調運転のステータス画面です。
1-Aは1号棟のA区画、1-Bは1号棟のB区画のことです。
区画ごとに空調の方式が違っていて、A区画は冷たい空気が壁の横から吹き出してきて、上方の排気されます。
B区画は冷たい空気が天井から吹き出してきて、上方に排気されます。

区画ごとに空調方式を変えられる…というのはすごいなと思いました。
私が働いていた機械室(機械室と呼んでいるのですが、一般的にはサーバールームなのでしょうか…)は、フレキシブルに空調方式をかえることはできませんでした。







外気は冷たすぎたり、湿度が高すぎたり、低すぎたりするので、外気と排気を混合して適切な温度にして、さらに湿度を調整してサーバールームに送り込まれます。



A区画とB区画の外気冷房の概念図は以下の通りです。



ラックからの排気ルートが書いていませんが、ラックからの排気は冷たい空気と交わらないように天井の赤い線に抜けていくような構造になっています。

A区画の壁から吹き出すファンの画像が以下になります。
風が相当強いらしくて、機械には優しいけど人間には厳しいそうです。
一般的な機械室は二重床で、下から冷たい空気がでてくると思います。その空気にやられることが多い私は機械室の中ではコートを着て作業したり、ダンボールで自分の下の吹き出し口を閉めて作業をしてたりしましたが、横からの風は防ぎようが無いな…と思いました。





下の画面は、ASHRAE2011の推奨温度、推奨湿度に収まっていますなことを示す画面です。
ASHRAEについてはこちらを参照頂くのがいいかと思います。
※私はASHRAEについて知りませんでした…

サーバーに送り込むための空気は冷たければいいってもんではなく、画面の赤い四角の中に入っている必要がありますということだそうです。赤い四角の中に、実際の給気/還気が収まっているのでOKということだそうです。
左側にある赤い点は外気の温度/湿度をプロットしたものです。



サーバーは熱いのでその排熱も利用しています的な画面が以下の画面です。



写真にはないのですが、各ラックごとに温度センサーがついていて、どのラックがどのような温度になっているのかを確認することができまして、ああ、いいなあと思いました。

自社では装置が温度警報をあげたときにはじめてセンサーを設置してなんとかするということをしています。
最近のデータセンターは素晴らしいです。

新しい機械室はいいなーと思うのは配線が美しいことです。
マシンを増やしたり減らしたりすると、どうしても配線がいりみだれてしまって、なるべく交差しないようにしたいのですが、交差せざるをえない箇所があってしまいます。
線を目でおってなんとかすることはあまりないのですが…最終的に目でおうしかない場合もありまして、そんな場合に配線が美しいといいですよね。



なるほどなあ…と思ったのは下の写真です。
現在建設中…もう完成したのかな?の2号棟では実際に空気の流れは大丈夫かを確認するためにドライヤーで試験をしていました。
うちの機械室もこれをやっておけば、マシンを入れてから「熱いー、うわー」とならずにすむのかもなあと思いました。



この文書を専門でない方がご覧になるかも…ということで、200Vの電気のプラグは下の写真のようなものになります。自分は、はじめて見たときに「何アレ?」と思いました。



機械室は「いかに冷たい空気だけをサーバーに送り込んで、熱い空気は冷たい空気と交わらせずに機械室から外に出すか」です。その、今のところの最適解が下の写真のような構成のようです。
ラックの後ろから排熱される熱い空気を部屋に閉じ込めて、天井上方に排気します。





私は機械室に関わり始めて…もう8年くらいかな…になりますが、これを見て超感動しました。
が、他の参加者の方、さくらインターネットの方から「知らないんですか!」と言われて、なんというか、自分のアンテナの低さを反省いたしました。

下の写真は多分…HVDC用のラック上部に設置される電源だと思います(340Vと文字が見えるので、多分そうかなと…)
HVDCだとAC方式より電力効率がいいそうです。知りませんでした…



私が衝撃を受けたもう一つのことが、そうか、二重床じゃないから蓄電池を置く場所を考えなくていいんだ…でした。
各ラックの列の端っこに、その列のサーバーが必要とする蓄電池が設置されています。
電池は重いので、二重床の上には置けない…置こうとすると、二重床の柱をとんでもなく強くする…柱の間隔を短くしないと駄目だと思います。おけるかな…
何かあったときの影響範囲が分かりやすくていいなーと思いました。

また、こんなに高密度にサーバーを搭載すると荷重が大変なことになりそうですが、二重床でなければできるのか…とも思いました。



下の写真はディーゼル発電機です。
手前にあるのは起動用の電池だそうです。そうですよね、起動するのに電気が必要ですよね。そんなことも知りませんでした…

ちなみに、電気は余っているそうで、理由はSandyBridge時代の設計で、IvyBridgeに変えたら3割くらい消費電力が下がってくるケースもあるため(話をすっかり忘れていましたので、さくらインターネット #石狩DC 体験記 - myfinderのはてなブログから引用させて頂きます。)だそうです。

機械室におけるマシンの総量は

• 電気
• 空調
• 床面積
• 耐荷重

で決定されて、床が余っているのに電気が無いとか、床が余っているのに熱すぎて、でも空調は増設できないとか、非常用電源がもうおけなくて、これ以上何もできないとか、あるので、足りないよりは全然いいのかなと思います。都心のデータセンターは、上記4つのどこれかにくるボトルネックと戦っているかなと思います。



非常用電源室の壁面に設置されたファンです。排気だったか…吸気だったか忘れました。
ディーゼルエンジンが本気で回り始めると大量の空気を必要として、それを供給する必要があるから…だったと思いました。間違えてたらごめんなさい!




下の画像は、外気を取り込むところのフィルターだったと記憶しています。
1年に1回だったかな…半分ずつ洗濯…えーと、洗うそうです。

 

下の画像は、除塩フィルタです。
私、除塩フィルタをはじめて見ました。どういう原理で、これが塩をはじいてくれるのかさっぱり分かりません…




下の写真は…水冷インバータターボ冷凍機です。
自分で書いててなんのことだか分かっていないのですが、空調機だと思います。
石狩は寒いのであまり動かないかなと思っていたら、夏は意外に暑くて、よく動いているそうです。
よく動いているといっても、この冷凍機は100%の力で動くと効率がいいそうなのですが、100%の力で動かずに送風運転をしていることも多いそうなので、次の棟(だったかな…)はこれを設置しないで普通の空調にしようかなとのことでした。
こちらのターボ冷凍機については、中2病を実現？！ さくらインターネット石狩DCを、はてなのエンジニアが見学してみた - はてなブックマークニュースが詳しいです。




下の写真は特別高圧電気室です。
手前に16個ある箱は力率改善用のコンデンサだったかな…
これを設置すると電力会社ががっつり値引きしてくれるとかしないとか…

電気についても中2病を実現？！ さくらインターネット石狩DCを、はてなのエンジニアが見学してみた - はてなブックマークニュースが詳しいです。

石狩データセンターは6万6000Vで受電しているそうです。
6万6000Vを電力会社の変電所から受け取るには

• 高圧鉄塔を作って送電線を這わせる
• 地中に洞道を作って這わせる

ことが必要だそうです。

いずれもお金がかかってしょうがないのですが、 石狩湾新港は結構自由に「掘れる」そうですので、特別高圧の電気をもってきやすかったとのことです。



以下の写真は石狩DCの会議室の様子です。





機械室で火災があった場合、水や泡で火を消すわけにはいかないので、酸素濃度を低くして消火します。
以下はそのための窒素ガスの写真です。
「へーっ」て感じですよね。
この消火設備の工事/整備には消防設備士の資格が必要で、取るのは簡単なのですが、定期的に講習を受けなくてはいけないので、使わないのであれば取得をお勧めしない資格です。
危険物取扱者のように使わなければ講習を受けなくていい…にして欲しいな…と思います。


 
このツアー、なんかこう、いい意味でおかしくて、2日目のオプショナルツアーでは、石狩湾新港にある変電所を見に行くんです、いや、まあ、なんというか、あまりないですよね、変電所を見にいくツアー。



ついでに、風車も見てきました。



下の写真は、搬入されたサーバーを常温に戻すための部屋です。
搬入されたサーバーは冷たくて持てないし、そのまま部屋にいれると結露するので、この部屋で寝かせます、とのことです。



写真は以上です。


さくらインターネットの求人

私はさくらインターネットの社員でもなんでもないのですが…なんとなくいい人が欲しい…という空気を感じましたので、さくらインターネットの求人をしてみます。
※参加された学生さんに「さくらインターネットで働きたいです!」という方がいらっしゃいましたが、頑張って欲しいですね。

Webの世界は私がはじめてWebに触れてから複雑怪奇になってきていまして、昔難しかったことが簡単になっていく一方、本当に難しいことはその手の会社に入らないと学びようも経験のしようもないと思っています。

Webサービスを作って、立ち上げて、人が増えたらスケールしていく…というのはとても簡単になりましたが、そもそもスケールするようなサービスを作らないと、スケールした後の経験を積めない…という状況です。
一方、求められる人材が「大規模なWebサービスを運用したことがある人」とか、まあ、無茶言うなと、そんな人はごくわずかじゃ無いかと、そう思います。

「本当に難しいことはその手の会社に入らないと学びようも経験のしようもない」の「その手の会社」の一つがさくらインターネットじゃないかなあと思います。

今の仕事をやめるつもりはないのですが、石狩DCを見学してる最中に、さくらインターネットの求人情報を見ちゃいました。人生もう一回あったら働いてみたいなーと思いました。

自分はインフラのお仕事をしているのですが、インフラの仕事って結構地味で、ErogameScapeの地味さはインフラ屋が作っているからと文脈と関係ない言い訳しておきつつ、インフラに興味がおありでしたら選択肢の一つに加えていいかなと思います。


終わりに

優秀な営業さんは、物を売るんじゃなくて体験を売るのだと聞いたことがあります。
この人から買ってよかったと、そして口コミで、この人はいいよと広まっていくのだそうです。

第2回さくら石狩DC見学ツアーに参加させてもらって、いい体験をさせてもらいました。
ErogameScapeはさくらインターネットのサービスを利用させて頂いていますが、今後も「利用させてもらいたいなあ」という気持ちになりました。

国内の同業他社、海外のサービスにまけないように頑張って欲しいです。

自身以外にサービスを提供するつもりで自宅サーバーを設置する理由はVPSというサービスがでてきた結果なくなったかなと思います。

理由は以下の通りです。

• 電気代がかかる
• VPS等のサービスに比べてハードの信頼性が低い
• 必要に応じて電池が必要
• 上り帯域が多すぎるとプロバイダに怒られる

自宅サーバーにするメリットは…

• Webサービスを提供するだけだったらルーターで80番ポートだけあければいいのでVPSで1からOSを設定するよりはセキュリティに気を遣わなくてもいいかも

くらいかな… 

ちなみにErogameScapeは自宅サーバーです。
理由は、ErogameScapeが出来た当時VPSなんてなかったし、専用サーバーは高かったので、自宅サーバーにせざるを得なかったからです。
今だったら専用サーバーを借りると思います。


自宅サーバーで不特定多数の方々にサービスを提供していて、サーバー自体のリソース以外のリソースで頭打ちになるのは以下の2つだと思います。

• 帯域
• NATのセッション数

帯域は取得が容易で、ちまたにグラフ化するツールがあるので、頭打ちになったことに気がつくのは容易かなと思います。
2つ目のNATのセッション数は頭打ちになったことに気がつきにくいかと思います。

NATのセッション数が頭打ちになると、目に見えて起こる現象は「ルーターがハングアップする」です。
再起動すると直るのですが、またハングアップします。
原因はルーターのNATのセッション数の上限を超えてしまったことなのですが、自宅サーバーを運用している初期は、今まで遣っていた安いブロードバンドルーターを使っていると思いますので、ログ等は一切残りません。

NATのセッション数の確認方法は…当時どうやって確認したか思い出せないのですが、netstatで80番ポートにどれだけアクセスがあるか?等から推測した気がします。

帯域が足りているのに、熱暴走するような気温ではないのに、ルーターがハングアップするようでしたら、NATのセッション数が足りないことを疑ってみるのがいいかなと思います。


NATのセッションが頭打ちになるのは、中規模のオフィスのように1つのIPの下にたくさんのクライアントがぶらさがる環境でも起こります。
togetterでまとめられていた「200人程度の中規模オフィス向けネットワークの、基幹ルータ選定と設計」が興味深かったのでご紹介します。

 

ある日ケース背面（リア）のファンがうるさい音をたてるようになりました。
電源を落として再度電源を投入すると音が止まるのですが、しばらくするとまた音がではじめるので

• 新しいファンを買わねば
• 冬だからそんなに急がなくて大丈夫かな

と思って、ファンの電源を落としたままで、ケースの蓋を閉じてそのままにしていました。
12月23日の15時頃、以下のメッセージを出力してサーバーの応答がなくなりました。

ああ…、だいぶ熱かったんですね…
現在は蓋をしめずに、開けっ放しで運用しています。

教訓

• 　ケースファンが動いていないのに蓋をしめて運用するのは冬でも無理
• 　ケースファンが壊れたときにすみやかに交換できるように予備を用意しておこう

ケースファンが壊れたのは現用系のサーバーでした。
待機系のサーバーはVRRPでアドレスを引きついで動作を開始しました。

ものは壊れます。
個人でパソコンを使っていると…そんなに壊れない、壊れるときは壊れますが、1日1回壊れたりすることはないです。
ですので、ものってそんなに壊れないんじやないかなあと思っている方が多いんじゃないかなと思います。
私もそんな一人でした。
しかし、 お仕事でサーバーやネットワーク機器の監視をしてみると、機器が多いので、少なくとも1日に1つは何かが壊れるということを知りました。

ここから嘘を書きますが、わかりやすさのため勘弁してください。

10年に1回壊れるという製品があったとします。
10年は365日ですので、3650日に1回壊れます。
この機器が3650個あると、1日に1個は壊れる…ことになります。

嘘ここまでです。

厳密にはポアソン分布に従うので、んーと、もっと壊れるかな…
HDDとかは10年に1回どころかもっと壊れますし、パソコンはHDD含めいろんな部品で動いていますので、実際は3650個とかなくてもあちこちで壊れます。
ネットワーク機器はHDDのように物理的に何か接触する部分がないように作られている(ことがほとんど)なので、結構壊れませんが、ときどき壊れます。
洗濯機とか車とか、あんなにガシガシ動いているのにそんなに壊れない気がするのはすごいと思います。

ものは壊れるし、機器が増えれば増えるほど何かが壊れることが多くなるので、いつ壊れてもいいように、二重化したり、予備の物品を持っておいたりしないといけません。
 
あとは、できればなるべきシンプルな構成にすることがいいですね、間に何かが増えると増えた分だけ壊れるものが増えますので…

ということで、スイッチが壊れました。
振り返ると以下のような時系列でした。

1. ノートパソコンがインターネットに繋がりにくかった(無線LANの親機は壊れたスイッチに繋がっていた)
2. サーバーとスイッチの間のリンクが10BASE HALFに落ちることが増えた
3. サーバーとスイッチの間のリンクがあがらなくなった
4. スイッチがスイッチングできなくなった

1.は、無線の調子が悪いのだろうと思って、親機の電源OFF/ONをしていました。
親機の電源OFF/ONをすると…スイッチとのリンクを再確立しなおしますので、たまたま調子がよくなっただけだったのだろうなあと思います。

2.は…最初、全然気がつかずftpの速度が遅いなあと思って、 ethtoolのコマンドをたたいたら10BASE HALFだったというものです。まさか10BASEになっているなんて疑っていなかったので、当時は設定を確認してうんうん唸っていました。切り分けの最初は物理層から…が基本ですね…
10BASE HALFに落ちるのは、ケーブルを抜き差しで回復しました。
まあ、一過性のものかなと思っていたのですが、こういう現象が起きたら故障を疑った方がいいと学習しました。ネゴシエーションに失敗して10BASE HALFに落ちることはよくあるかなと勝手に思っていたので、故障と気づくまでに時間がかかりました。
ちなみに、この時、ケーブルとポートを変更しても事象が再発するかを試したところ、再発したのでサーバー側のイーサボードが悪いと思って交換しました。

その昔はIntelのチップが最高だったのですが、今でもIntelのチップが安定しているようでしたので、

ギガビット CT デスクトップ・アダプタ EXPI9301CT
販売元：インテル
(2009-02-25)
販売元：Amazon.co.jp

を買ってさしました。
イーサボードは悪くなかったようでしたが…

3.はイーサボードをかえてから2回起こりました。 
サービスが中断した場合、サービス回復を優先するか、調査を優先するかというのが、運用している方々の悩むところだと思いますが、ErogameScapeの場合は「まあ、再起動すれば直るかな」程度の気持ちでやっているので、とりあえず再起動したら直りました。

サービス中断した時、あとで原因を追及するためのログが残っていればいいのですが、案外原因を追及するための材料がログに記録されていないのはよくあることです、と思っています。
サーバーなんかは、自分で設定に融通が利くので、いろいろ仕込めたりしますが、ネットワーク機器は自分ではどうしようもないことが多いので、事象が起こったそのときに、いろんなコマンドをたたくマクロを作っておいて、とりあえずログをとっておきます。でないと、故障の根本原因がわからず、事象発生、再起動、直りました、をただ繰り返すだけになってしまいますので…

さて、再起動して直ったはいいですが、また数日後リンクが落ちました。
(1) サーバー側のifdown/ifup → 未回復
(2) サーバー側のLANケーブルの抜き差し → 未回復
(3) スイッチ側のLANケーブルの抜き差し → 未回復
(4) スイッチの電源OFF/ON → 回復
な感じでした。

ここらで、ああ、もしかしたらスイッチが悪いかもしれないけど、電源OFF/ONでなおったから様子見でいいかなと思っていました。

そして、先日4.が起こりました。
知り合いの方からメールで「サーバー落ちてますよ」と連絡を頂き、Twitterを眺めると、どうも8時間前に落ちたようで、胃が痛いです。

胃が痛いって、若いころはよくわからなかったんですが、そうですね、会社でサーバー等の保守部門にうつってからは、胃が痛くなることがよくあります。サーバーが落ちてサービス止まると大変です。サーバーやネットワークの機器の保守をされているみなさん、お疲れ様です、胃が痛くならないようなネットワークだといいですね。

さて、それはそうとして、メールを頂いたときに「ああ、多分スイッチが逝ったな」と思いました。
現場に到着。
サーバーとスイッチの間のリンクが断になっていることを確認しました。
それだけだったら待機系のサーバーで処理するはずなのですが、それもできていなかったので、待機系のサーバーに入ってpingをうったら

PING 192.168.0.12 (192.168.0.12) 56(84) bytes of data.
64 bytes from 192.168.0.12: icmp_seq=7 ttl=128 time=0.377 ms
64 bytes from 192.168.0.12: icmp_seq=8 ttl=128 time=0.511 ms
64 bytes from 192.168.0.12: icmp_seq=9 ttl=128 time=0.489 ms
64 bytes from 192.168.0.12: icmp_seq=16 ttl=128 time=0.492 ms
64 bytes from 192.168.0.12: icmp_seq=18 ttl=128 time=0.495 ms
64 bytes from 192.168.0.12: icmp_seq=19 ttl=128 time=0.479 ms
64 bytes from 192.168.0.12: icmp_seq=20 ttl=128 time=0.491 ms

--- 192.168.0.12 ping statistics ---
20 packets transmitted, 7 received, 65% packet loss, time 19178ms
rtt min/avg/max/mdev = 0.377/0.476/0.511/0.044 ms

と、ああ、フレームをロスるときは、こんなにロスるんだなあと思うくらいロスっていました。
電源のOFF/ONをしてもリンクがあがらなかったので、あ、こりゃ駄目だ、ということで他のスイッチの余っているポートにさして回復しました。

スイッチの予備はもっていなかったので、今回を機に買うことにしました。
安いですね、スイッチ、1000円以下でしかも送料無料です。いい世の中です。
ErogameSpapeのトラヒックは大したことないので…確かピークで4Mbpsほどだったと思いますので、100Mbpsのスイッチで十分です。とりあえず一番安いのを買いました。

Logitec 10 100Mbps スイッチングHUB 5ポート 電源外付 プラスチックケース ホワイト LAN-SW05/PH
販売元：ロジテック
(2010-04-07)
販売元：Amazon.co.jp
今のスイッチは電力消費を抑えるいろいろな工夫がしてあってすごいと思いました。
ケーブルの繋がっていないポートには電気送らなかったり、ケーブルの長さを把握して必要最小限の電気だけ使って送ったり、すごいです。

ちなみにルータは壊れたらすぐに買えないのと、ライフサイクルが短いので予備を購入済みです。
実家においてありますので、お取り寄せに時間がかかりますが…

ちなみに、XR-410というルータなのですが、今、HPを見たらだいぶ前に販売終了して今はXR-430になってますね。

センチュリーシステムズ FutureNet XR-430 XR-430
販売元：センチュリーシステムズ
(2008-08-27)
販売元：Amazon.co.jp


故障したら分かりやすく故障して欲しいと思うのですが、多くの場合分かりやすくは故障してくれないので、企業のネットワークでは本当にいろんなものを見て「こりゃ故障の可能性がある」と判断したら交換とかしてると思います。それでも、未知の壊れ方をすることもいっぱいありまして「えー、そこが故障だったのー」とかよくあります。

ちゃんと故障してくれないと、切り替わるものも切りかわってくれなくて、微妙に使えないとか、そういうのもよくあります。

サービス中断した時には、中の人々は大変な思いで、すごい勢いで切り分けてると思いますので、そのうち直るかなーとゆっくり待ってもらえるとうれしいと思います。

でわでわ

ErogameScapeのサーバーはソフトウェアRAIDを組んでいます。
RAID1です。
1つHDDが壊れてもサービスを継続でき…ると思っていたのですが、実際はそうではなく、 止まります。
止まり方としては「telnetできなくなり、リセットまたは電源のOFF/ONをしなければいけない」状況になります。

　→　ハードウェアRAIDだとどうなんでしょうか…

HDDの一時的障害でも、リセットまたは電源のOFF/ONは必要で、立ち上がると勝手に同期がはじまります。
HDDの一時的障害ではなく、本当に障害が発生している場合は、立ち上がってきません。
立ち上がってきても良さそうなのですが、今まで2回HDDが故障しているのですが、2回とも立ち上がってきませんでした。

立ち上がってこない場合、被疑のHDDを切り離して電源をONすると立ち上がってきます。
被疑のHDDをもう一度接続すると、立ち上がってきません。

※ErogameScapeのサーバーはHDD1台×2で運用していまして、GRUBがインストールされています。
　もしかしたらGRUBをインストールしてないHDDだったら、被疑のHDDを切り離さなくても立ち上がってこれたり、HDDが故障してもサービスを継続できる…かもしれません。どうなんでしょうか。


被疑のHDDを交換したら、

1. fdiskで領域を確保する
2. mdadmコマンドで同期させる
3. grubをインストールする

という手順を踏みます。
googleで検索すると、手順の中で「壊れたHDDに故障したというマークをつけて、切り離す」ということをしているものもありますが、多分、オンラインでHDDを交換できるサーバーの場合の手順な気がします。

実際の手順は
LinuxMania: ソフトウェアRAID1 障害時の復旧手順(Fedora,CentOS)
の通りです。

いろいろなソフトウェアRAIDの構築の手順のHPのfdiskの結果を見ると

[root@linux ~]# fdisk -l /dev/sdb

 Device   Boot  Start   End     Block    Id  System

/dev/sdb1 *         1     13      104391  fd  Linux raid autodetect

/dev/sdb2         14    274     2096482+ fd  Linux raid autodetect 　

/dev/sdb3        275   1566    10377990  fd  Linux raid autodetect 

のようになっています。 
sdb1が/boot、sdb2はSWAP、sdb3が他の領域という設定です。

SWAP領域はRAIDにする必要はないので、本当はIdが82のSystemが「Linux スワップ / Solaris」とした方がいいと思います。スワップ領域はミラーリングされている必要がないので、わさわざ負荷のかかるRAIDにする意味がないから…です。

と、どこかのHPに書いてあって、そうしています。

あと、もう一点。
fdiskをするときに、/bootからブート可能とするため、「a」でブート可能フラグをつけていますが、GRUBを使う場合、ブート可能フラグをつけていなくてもちゃんとブートできます。

実際、ErogameScapeのサーバーはブートフラグがついていなくても起動できていて「あれ？なんで起動できているのだっけ？」と調べたら以下のHPにいきつきました。

• GRUB によるトリプルブートの実験
• LinuxにおけるMBRのまとめとバックアップ方法

GRUBであればブートフラグがついていなくてもブートできます。

もし、ソフトウェアRAIDを使ってみたい、しかも多数の人に使われるサーバーで使いたいという場合は注意することがあります。

1. mdadmコマンドで同期させる際に、滅茶苦茶時間がかかります。
2. mdadmコマンドで同期させる際に、とても負荷がかかります。

1.については、ErogameScapeの環境で1TBのHDDで12時間かかりました。
サーバーとして運用しながらの値です。
サーバーとして運用しないでいればもっと早い気がしますが、それでもうん時間単位かかります。

2.については、ロードアベレージで1くらい食います。
ErogameScapeのサーバーは資源に余裕がありまくりですので、ロードアベレージで1食っても全然大丈夫ですが、シビアな使い方をしている場合は、サーバーとして運用しないで同期させるのがいいと思います。

これは実際やってみないと分からないことで、何年か前にソフトウェアRAIDを組もうと思ったときに、いろんなサイトを見たのですが「同期に時間がかかるから注意だ」「同期は負荷がかかるから注意だ」と書いてなかったので気がつきませんでした。

また、HDDは案外壊れますが、そんなにも壊れないとも言えますので、壊れた時のことを考えてちゃんと復旧のマニュアルを自分用に作っておくのがいいです。

確かにgoogleで検索するとそれなりにヒットするのですが、自分でやってみると「あれ？」と思うことがよくあります。
例えば、HPによっては「マスターのHDDが故障した場合は、スレーブのHDDをマスターのHDDが刺さっていたところに差し替える」と書いてありまして、これは…多分GRUBをスレーブのHDDにコピーしていない場合のことだと思うのですが、そういった「自分の環境と微妙に違う」ということがありますので、ぜひ、ちゃんと故障したときのことを考えてマニュアルを作っておいた方がいいです。

※ちなみに私は紙でもっていてクリアファイルに挟んで保管しています。