運用

ErogameScapeを17年間自宅サーバーで運用してみて

ErogameScapeは自宅サーバーだったのですが、先日、専用サーバーを借用して移管をしました。
自宅サーバーにしたのが2003年4月27日だったので、17年間くらい自宅サーバーを運用してきました。

後から、ああ、こんなことあったなあ…、と思い出にひたるために記録に残しておきます。

(1)レンタルサーバーから自宅サーバーに切り替える
ErogameScapeを作った当初はレンタルサーバーで動かしていました。
そのレンタルサーバーは2001年時点でPostgreSQLが使えるというとても先進的なサーバーでした。
2001年のことですから、PostgreSQLでサービスをするWebアプリを作る人は少なく…、そのサーバーのリソースは私が独り占め状態でした。
ある日、phpで無限ループするスクリプトをレンタルサーバーにあげてしまって、サーバーを落としました。当然、怒られました…
少し経って、また同じミスをして、サーバーを落としました。今度は、サーバーを出ていってくれと言われました。さあ大変…
PostgreSQLが使えるレンタルサーバーは他に選択肢がなく、自宅サーバーにすることにしました。

(2)上り帯域が足りない
ErogameScapeは基本テキストのデータしか扱っていないので帯域はとても少なくて大丈夫です。
当時の自宅サーバーの回線はADSLでした。
ADSLの上り帯域は1Mbpsでしたが、サービス開始当初はこれで問題ありませんでした。
しかし、2004年頃、帯域が足りなくなって、ADSLモアIII(上り5Mbps)に変更しました。
帯域が出るかはNTTの局舎からの距離によるので、おそらく賭けだったと思うのですが、確かちゃんと帯域は出て問題は解決した…はずです。
このとき、帯域が足りなかったので、一時的にコンテンツをレンタルサーバーに退避していますが、ADSLモアIIIへの切り替え後、元に戻しています。
ちなみに今でもErogameScapeは平均すると1Mbps/sで足りております。

(3)IPマスカレードのセッション数が足りない
2005年、当時使っていたADSLルータのBBR-4HGのIPマスカレードのセッション数が足りない事象が発生していました。
BBR-4HGのセッション数は800でした。
どうやって「IPマスカレードのセッション数が足りない」ことを知ったのかの記録をおったら、モデムとADSLルータの間にスイッチング機能を持たないハブをいれてパケットをキャプチャし、トラヒックが高くなる時間にルータがたくさんRST ACKを返していることから推測したようです。
そういえば当時の自分は切り分け用にハブを持っていました…
ユーザーさんに対策を相談し、XR410/TX2(4万円)かRTX1000(ヤフオクで4万円)を勧められました。
高い…
セッション数の問題であれば、セッション数が潤沢な安いADSLルータを相談し買えばいいと思い、BLR3-TX4(セッション数4096)を買うも問題解決せず…
結局、XR410/TX2を買いました。
XR410/TX2は大変素晴らしくEOLまで使いました。
この時、学んだのは「カタログスペックはあてにならない」「高いものはいい」です。

(4)XR410/TX2が踏み台にされる
サーバーの設定を確認して問題ないと思っていたらプロバイダから
この度、外部より、ご提供しておりますインターネット接続回線に
割当てのIPアドレス「XXX.XXX.XXX」から、NTPを利用した大量の通信
(DDoS攻撃)が発生しているとの連絡を受けております。
との連絡が来て青ざめました。
連絡を受けた時は、何が原因なのかさっぱり見当がつかなかったのですが、サーバーは確認していたけど、そういえばネットワーク機器は確認していなかった…ということで、XR410/TX2のNTPDを止めてDDosが収まりました。
ネットワーク機器もちゃんと確認しなくてはいけない…と思った次第でした。

(5)FedoraからCentOSにする
2011年まで、Fedoraを使っていました。
2011年にCentOSの存在を知りCentOS6に移行しています。
それまではFedoraは1年に1回アップデートしていた(今もそうなのかな?)ので、1年に1回、OSを再インストールしていました。
2008年まではサーバーのスペック不足のため1年に1回新しいPCを買っていたので、ついでに新しいOSを入れるのは問題なかったのですが、後述するとおり2009年を最後に新しいPCを買わなくなったので、OSのインストール面倒…というところでした。
CentOSにしたら、OSのインストールをすることはなくなったので、作業量は激減したのですが、次のOS更改の際に自分は対応できるのだろうか…と不安を抱えることになります。

(6)スペックが足りないのでだいたい1年に1回サーバーをリプレイス(2008年まで)
当時は時間をおうごとに着々と負荷があがっており、ソフト的な対策(キャッシュできるところはキャッシュするとか)やハード的な対策(pgpoolを導入して2台で負荷分散)をしていたのですが、おいつかないので、1年に1回PCを買っていました。
しかし2008年を最後にリプレイスしなくてよくなりました。
買ったPCの構成は以下のとおりです
Storm Metaphor 64 LTD
 Core 2 Quad Q9550
 ASUS P5Q(Intel P45 + ICH10R IEEE GbLAN)
 Winchip/DDR2-800 16GB(4GBx4)
 GeForce 8400GS 256MB PCI-Express x16
 WesternDigital WD Caviar Green WD10EADS(1TB SATA-3Gb/s 32MB)
 Seagate Barracuda 7200.12 ST31000528AS(1TB SATA-3Gb/s 7200rpm 32MB)
 KURO600G(静音)
これの1つ前のマシンはメモリが少なかった(6G)のですが、メモリを思い切って16GBにしたら負荷ががくっと下がった…と思われます。
「データベースは使う内容がメモリにすべてのる」ことが肝ですが、当時の自分はそんなことはまったく知らなかったので、16GBのすごさを思い知りました。
この後、同じスペックのPCをもう1台買って、冗長構成になりました。

(7)引っ越し
自宅サーバーなので引っ越しをするたびにサーバー一式を移動させる必要があります。
最初の引っ越しのときは、自宅サーバーしかなかったので、旧居でサーバーを落とし、新居に一式を持っていき、立ち上げ、まではサービス中断でした。
その後の引っ越しはバックアップ用の専用サーバーを借りていたので、一時的に専用サーバーを現用にして、引っ越しが終わったら自宅サーバーに戻す、ということをしていました。
引っ越しで一番怖かったのは、電源を入れたときにちゃんと起動するか、でした。
電源を落とすと、なぜか起動しない…というのはよくあることで、切り分けが大変でした。
たいてい、がちゃがちゃやってるうちに起動するのですが…

(7)東日本大震災の計画停電
自宅サーバーの最大の危機がやってきました。電気がきません…
しかし、自宅サーバーのある地区が計画停電から外れていたためサービスを止めなくてすみました。
こんなこともある…ということが分かったので大容量の無停電電源装置BN220Sを買いました。
UPSの本来の用途と違うのですが…3時間程度なら耐えられる容量です。
ただ、このUPS欠点が2つありました。
  • めちゃくちゃ重い(自分は持てないので引きずるしかない)
  • ファンがうるさい(BATT駆動になると冷却のためFANが24時間回る)
この後、これでは根本対策にならないし、そもそも自宅が壊れたらBAD ENDだ、ということで2012年にさくらインターネットに専用サーバー借りて、バックアップとすることにしました。
ちなみに、それまでのバックアップは定期的にDVD-Rにデータを焼いて実家に送る、実家にはサーバーに使えるPCが1台置いてある…という態勢でした。

(9)ハード故障
(9)-1 PCのケースファンが壊れた
PCのケースファンが大きな音をたてるようになったので電源を抜きました。その後、冬だから大丈夫かなと思って、ファンを回さずに運用したら、全然大丈夫ではなく、温度異常でサーバーが落ちました。
この後、ファンの回転速度、温度を計測するmuninのプラグインを導入しつつ、ケースFANの予備を配備しました。

(9)-2 M/Bが壊れた
切り分けのために最小構成にしても立ち上がらず、CPUを買ってきて交換するも立ち上がらず、M/Bが原因と分かり…M/Bを別のものに交換するとOSの再インストールになっちゃうし、それはきつい…ということで、秋葉原で同じM/B探して見つけて交換ました。お値段は中古だけど新品とあまりかわらない価格ですが…しょうがない…

(9)-3 HDDが壊れた
RAID1なので、1つ壊れても大丈夫。
なのですが、手順を誤ると、データが入っている方を壊してしまうので、昔練習した手順書を探して、えーと、あー、どうやったっけ…と思い出しながら作業。

(9)-4 ネットワークスイッチが壊れた × 2回
自分の経験上、機器が壊れる時は人間が想像もしないような動作をするのですが、自宅サーバーに接続されていたネットワークスイッチも同様で被疑がネットワークスイッチだ!とたどり着くまでに時間がかかったと記憶しています。確か、NICが悪いと思って、NICを交換したけど回復しなくて頭をかかえた気がします。スイッチを介してpingを飛ばすとpingのlossが半端なかったと記憶しています。
ネットワークスイッチは壊れても、電気屋にいけばすぐ買えるので、予備は持っていなかったのですが、安いから買っておこう…ということで予備を購入しました。
購入してからは壊れることはありませんでした…

自宅サーバーの場合「予備をもっておくか」が悩ましいところです。
理想は、1台PCを買ったら、同じ構成のPCをもう1台買って予備にする…だと思うのですが、お金かかりますし…、でもマザーボードが故障して別のものと交換するOSの再インストールになっちゃうのでマザーボードは予備として欲しいかな…今、もし自宅サーバーをたてるなら買うかな…と思います。
また単一障害点となるXR410/TX2が壊れたら同じものを買うまでサービス中断になってやばい、と思ってもう1台同じものを買って所持していました。


自宅サーバーを運用していると、いろんな事案が発生し、都度ググったり、ユーザーさん意見を聞いて、乗り切ってきましたが、「1人では圧倒的に技術も情報も時間も足りない」と思います。

今はレンタルサーバーもVPSもクラウドも低コストで借りられるのでWebアプリを自宅サーバーで動かすメリットはないかな…と思います。自宅サーバーを保守する時間をWebアプリを開発する時間にあてた方がいいと思います。

インフラエンジニアのスキル(ErogameScape構築/運用の場合)

インフラエンジニアのスキルチェックリストを書き出してみたよを見て、このチェックリストの項目において、ErogameScapeを構築/運用する場合を書いてみます。
※チェックリストにないスキルもいろいろ必要だと思います。一番必要なのはErogameScapeを構築/運用しても苦にならないことじゃないかな…

DB設計

  • 必須 : 要件からDB定義を作成できる
  • 必須 : ER図を作成できる
  • 必須 : 第3正規化まで正規化できる
  • 必須 : パフォーマンスを意識したインデックス設定ができる

パッケージ管理

  • 不要

Webサーバー構築

  • Apacheは必須 : Apache・NginxでWebサーバーを構築できる
  • 不要 : リバースプロキシを設定できる
  • 不要 : エラーログが読める
  • 必須 : バーチャルホストが設定できる
  • たまに必要 : Rewriteのルールが記述できる
  • 必須 : HTTPSのWebサーバーを立てられる
  • 不要 : HTTP/2化できる
  • 不要 : 負荷分散計画が立てられる

DBサーバー構築

  • PostgreSQLは必須 : MySQL / PostgreSQLでDBサーバーを構築できる
  • たまに必要 : DBサーバーのパフォーマンスチューニングができる
  • 必須 : ボトルネックとなっているクエリを特定し改善案が立てられる
  • 必須 : DBレプリケーションが構築できる
  • 必須 : DB MasterのHA化ができる
  • 不要 : DBの水平分割・垂直分割を組める
  • 必須 : 準同期レプリケーションが組める
  • 必須 : レプリケーションが停止した場合に原因対処と復旧ができる

DNSサーバー構築

  • 必須 : DNSの仕組みを理解している
  • 不要 : BINDでDNSサーバーを構築できる
  • たまに必要 : ゾーンファイルを記述できる
  • 不要 : DNSスレーブサーバーを構築できる

メールサーバー構築

  • 不要

キャッシュサーバー

  • 不要

ロードバランサー

  • 必須 : ipvsadm + keepalivedでLVSを構築できる
  • 不要 : PacemakerでHAIPを構成できる
  • 不要 : HAProxyでプロキシサーバーを構築できる
  • 不要 : ヘルスチェックスクリプトを記述できる
  • 知らない : BIG-IPの設定ができる

監視サーバー

  • 必須 : Muninでリソース監視ができる
  • 他は不要

ログ管理

  • 不要

AWS

  • 不要

仮想化

  • 不要

Docker

  • 不要

Ansible

  • 知らない

ストレージ

  • たまに必要 : CUIでパーティション操作ができる
  • 不要 : 各ファイルシステムの特性を理解している
  • 知らない : 誤って削除したファイルの救出方法を知っている
  • 必須 : 容量が肥大化しているファイルを特定できる
  • 必須 : ディスクI/Oを計測しボトルネックを特定できる
  • 必須 : ファイルマスクを理解している
  • たまに必要 : ファイルのタイムスタンプを変更できる
  • RAID1が必須 : RAID0〜RAID10までのRAID構成が組める
  • 必須 : ソフトウェアRAIDとハードウェアRAIDの特性の違いを理解している
  • 不要 : NFS環境が構築できる
  • 不要 : Samba環境を構築できる
  • 知らない : lsyncdを使ってファイル同期環境が構築できる
  • 知らない : テープドライブのCUI操作ができる

ネットワーク

  • 必須 : ネットワークレイヤーの違いを理解している
  • 必須 : ルーターとL3スイッチ、ネットワークハブとL2スイッチの違いを説明できる
  • 不要 : NICの特性を理解している
  • 不要 : BGPを理解している
  • 不要 : DHCPのルールを設定できる
  • 不要 : オートネゴシエーションの特性を理解しオン・オフともに設定できる
  • たまに必要 : WireSharkなどのパケットキャプチャツールを使用することができる
  • 知らない : iperfなどでネットワーク速度を計測できる
  • 不要 : Cisco IOSをCLIで設定できる
  • 不要 : OpenFlowを理解している
  • たまに必要 : ネットワークのボトルネックを特定できる
  • 必要 Luaは知らない: YAMAHA RTXシリーズをCLIで設定できる。Luaで拡張できる
  • 不要 : タグベースVLANやポートベースVLANを構築できる
  • 必要 : PPTP / IPsecのVPNを構築できる

メモリ

  • 不要

ラック

  • 不要


2017年の年始からErogameScapeに接続しづらくなった件の原因について

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」を追加していれば、もっと早く分かった気がいたします。ここの区間は疑っていませんでした。

ErogameScapeのPostgreSQLの論理構成

ErogameScapeのPostgreSQLは以下のような構成でした。
--- pgpool ---- サーバー1
    (レプリケーションモード)
      |
      |
      --------- サーバー2
                   |
                   | ↓1日1回、pg_dumpしたデータを送りつけ
                   |
                サーバー3(さくらインターネット)
サーバー1と2に同時に障害が発生した場合…というか、サーバー1と2の設置しているロケーションが駄目になった場合、最大で1日データが巻き戻りました。

そこで、先日以下のような構成に変更しました。

--- pgpool ---- サーバー1
    (レプリケーションモード)
      |
      |
      --------- サーバー2
                   |
                   | ↓非同期レプリケーション
                   |
                サーバー3(さくらインターネット)
私自身が無事であれば、DNSの設定を変更し、サーバー3をMasterに昇格させることでサービスの復旧が可能になりました。

PostgreSQLを趣味で使い始めてから15年がたちました。
レプリケーションの技術についてはいまいちだなあ…と思っていましたが、今ならスケールアウトがすごく手軽に出来るなあ…と思いました。

ErogsmScapeはスケールアウトは必要なく、確か5年前からスケールアップすらも必要なくなりましたので、その恩恵にあずかることはないのですが、Verがあがるたびに性能も改善されているので、スケールアップも必要ないのかな…と思っています。
※もちろん訪れる方が横ばいであるというのもあります…

PostgreSQLの開発者の方々に感謝申し上げます。

同一物理ネットワークで2つのブロードバンドルータを使う場合の注意

通常のご家庭には、ブロードバンドルータが2つあるなんてない…と思いますが、ErogameScapeを運用している自宅サーバーの環境はブロードバンドルータが2つあります。

1つはErogameScape用で、もう1つは私がプライベート用です。

なんでこうなっているか?というと、ブロードバンドルータが1つですと「http://erogamescape.dyndns.org/~ap2/ero/toukei_kaiseki/」で接続しようとすると、接続できなかった…おそらく名前解決すると自身に設定されているIPアドレスなのでルーティングできなかったからだと思うのですが…のと、「ErogameScapeに接続できない」AND「内部ネットワークからはErogameScapeに接続できる」といった場合に、
自宅 --- ブロードバンドルータ1 --- プロバイダ1 --中略-- プロバイダ2 ---- ブロードバンドルータ2 ---- 自宅な接続が出来る?ということを確かめたかったからです。

ここまで書いて、現在はスマホがあるから、後者のErogameScape用のブロードバンドルータの外部からの接続の正常性の確認はスマホで代用できる気がしました…

さて、本題です。
ブロードバンドルータの内部LANの初期設定は、自身のアドレスが192.168.0.1だったりすると思います。
ある日、プライベート用のブロードバンドルータの電源をOFF/ONしましたら設定が初期化されまして、デフォルトの設定に戻りました。
プライベート用のブロードバンドルータのアドレスが192.168.0.1になりました。
ErogameScape用のブロードバンドルータのアドレスは192.168.0.1です。

自身のPCからプライベート用のブロードバンドルータにログインできなくなるし、なぜかErogameScapeのトラヒックのグラフがおかしくなるし、なんでかなーと思い、今やったのはプライベート用のブロードバンドルータの電源のOFF/ONでしたので、とりあえずこれを切り離すかーと思って、切り離したらErogameScapeのトラヒックが回復しました。

また繋ぐとおかしくなるなるので、原因はプライベート用のブロードバンドルータだと分かったのですが、なぜおかしくなったのかが分からなくて、なんとなく「設定初期化された?」と気がついて調べたらあたりでした。

同一物理ネットワークで2つのブロードバンドルータを使う場合は、設定が初期化されてしまうことも考えて、初期設定のアドレスから変更しておきべきだなあ…と思いました。
ブロードバンドルータを2つ使うことなんてないと思いますが…

CentOSのソフトウェアRAID1を構成するHDDの1つが故障したので、新HDDに交換する手順

ErogameScapeはLinuxのソフトウェアRAID1でHDDを冗長化しています。
ソフトウェアRAID1を採用してはじめてHDDが壊れましたので、その復旧手順をメモしておきます。

ErogameScapeではHDDが壊れてもメールする…という仕組みを設定してなくて、Muninのグラフを見て「あ、壊れた」と判断します。
ちなみに壊れたことにまったく気がついていなくて、気がついたときには5日くらい経っていました…
HDDが壊れたときのMUninのグラフを以下に示します。

無題
いつもは100%ですが、1つ壊れると50%になります。

/proc/mdstatの出力は以下のようになりました。
[ap2@erogamescape13 ~]$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdf1[1](F) sde1[0]
      1060244 blocks super 1.0 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sdf3[1](F) sde3[0]
      942138801 blocks super 1.1 [2/1] [U_]
      bitmap: 7/8 pages [28KB], 65536KB chunk

unused devices: 
正常時は以下の通りです。
[ap2@erogamescape13 ~]$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sde1[0] sdf1[2]
      1060244 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sdf3[2] sde3[0]
      942138801 blocks super 1.1 [2/2] [UU]
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: 
/dev/sdfが壊れているので、/dev/sdfをRAIDから切り離します。
[root@erogamescape13 ap2]# mdadm /dev/md0 -r /dev/sdf1
mdadm: hot removed /dev/sdf1 from /dev/md0
[root@erogamescape13 ap2]# mdadm /dev/md1 -r /dev/sdf3
mdadm: hot removed /dev/sdf3 from /dev/md1
[root@erogamescape13 ap2]# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sde1[0]
      1060244 blocks super 1.0 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sde3[0]
      942138801 blocks super 1.1 [2/1] [U_]
      bitmap: 7/8 pages [28KB], 65536KB chunk
/proc/mdstatから/dev/sdfがいなくなりました。
/dev/sdfを交換します。

※HDDを交換するとき、今回で言うとどのHDDが/dev/sdfなのかが、ぱっと見分からないです…
 同じHDDを積んでいないのでHDD本体を見れば「こっちか」と分かるのですが、外さないと型番が見にくいです。
 何かいい方法はないでしょうか、おそらくあると思うのですが…

交換が終わりましたら、/dev/sdeと同じようにfdiskで領域を確保します。
/dev/sdfの領域は以下のようになっています。
[root@erogamescape13 ap2]# fdisk -l /dev/sde

ディスク /dev/sde: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O size (minimum/optimal): 512 bytes / 512 bytes
ディスク識別子: 0x000b174e

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sde1   *           1         132     1060258+  fd  Linux raid 自動検出
/dev/sde2             133        4310    33559785   82  Linux スワップ / Solaris
/dev/sde3            4311      121601   942139957+  fd  Linux raid 自動検出

[root@erogamescape13 ap2]# fdisk /dev/sdf
デバイスは正常な DOS 領域テーブルも、Sun, SGI や OSF ディスクラベルも
含んでいません
新たに DOS ディスクラベルをディスク識別子 0x1fd65b05 で作成します。
あなたが書き込みを決定するまで、変更はメモリ内だけに残します。
その後はもちろん以前の内容は修復不可能になります。
警告: 領域テーブル 4 の不正なフラグ 0x0000 は w(書き込み)によって
正常になります

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

警告: DOS互換モードは廃止予定です。このモード (コマンド 'c') を止めることを
      強く推奨します。 and change display units to
         sectors (command 'u').

コマンド (m でヘルプ): m
コマンドの動作
   a   ブート可能フラグをつける
   b   bsd ディスクラベルを編集する
   c   dos 互換フラグをつける
   d   領域を削除する
   l   既知の領域タイプをリスト表示する
   m   このメニューを表示する
   n   新たに領域を作成する
   o   新たに空の DOS 領域テーブルを作成する
   p   領域テーブルを表示する
   q   変更を保存せずに終了する
   s   空の Sun ディスクラベルを作成する
   t   領域のシステム ID を変更する
   u   表示/項目ユニットを変更する
   v   領域テーブルを照合する
   w   テーブルをディスクに書き込み、終了する
   x   特別な機能 (エキスパート専用)

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本パーティション (1-4)
p
パーティション番号 (1-4): 1
最初 シリンダ (1-121601, 初期値 1):
初期値 1 を使います
Last シリンダ, +シリンダ数 or +size{K,M,G} (1-121601, 初期値 121601): +1G

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1         132     1060256+  83  Linux
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.

コマンド (m でヘルプ): a
パーティション番号 (1-4): 2
警告: 領域 2 は空のタイプです。

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本パーティション (1-4)
p
パーティション番号 (1-4): 2
最初 シリンダ (132-121601, 初期値 132):
初期値 132 を使います
Last シリンダ, +シリンダ数 or +size{K,M,G} (132-121601, 初期値 121601): +32G

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1         132     1060256+  83  Linux
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.
/dev/sdf2             132        4310    33551756   83  Linux

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本パーティション (1-4)
p
パーティション番号 (1-4): 3
最初 シリンダ (4310-121601, 初期値 4310):
初期値 4310 を使います
Last シリンダ, +シリンダ数 or +size{K,M,G} (4310-121601, 初期値 121601):
初期値 121601 を使います

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1         132     1060256+  83  Linux
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.
/dev/sdf2             132        4310    33551756   83  Linux
/dev/sdf3            4310      121601   942147988+  83  Linux

コマンド (m でヘルプ): m
コマンドの動作
   a   ブート可能フラグをつける
   b   bsd ディスクラベルを編集する
   c   dos 互換フラグをつける
   d   領域を削除する
   l   既知の領域タイプをリスト表示する
   m   このメニューを表示する
   n   新たに領域を作成する
   o   新たに空の DOS 領域テーブルを作成する
   p   領域テーブルを表示する
   q   変更を保存せずに終了する
   s   空の Sun ディスクラベルを作成する
   t   領域のシステム ID を変更する
   u   表示/項目ユニットを変更する
   v   領域テーブルを照合する
   w   テーブルをディスクに書き込み、終了する
   x   特別な機能 (エキスパート専用)

コマンド (m でヘルプ): t
パーティション番号 (1-4): 1
16進数コード (L コマンドでコードリスト表示): fd
領域のシステムタイプを 1 から fd (Linux raid 自動検出) に変更しました

コマンド (m でヘルプ): t
パーティション番号 (1-4): 2
16進数コード (L コマンドでコードリスト表示): 82
領域のシステムタイプを 2 から 82 (Linux スワップ / Solaris) に変更しました

コマンド (m でヘルプ): t
パーティション番号 (1-4): 3
16進数コード (L コマンドでコードリスト表示): fd
領域のシステムタイプを 3 から fd (Linux raid 自動検出) に変更しました

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1         132     1060256+  fd  Linux raid 自動検出
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.
/dev/sdf2             132        4310    33551756   82  Linux スワップ / Solaris
/dev/sdf3            4310      121601   942147988+  fd  Linux raid 自動検出

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!

ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。
[root@erogamescape13 ap2]#
[root@erogamescape13 ap2]#
[root@erogamescape13 ap2]# fdisk /dev/sdf

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

警告: DOS互換モードは廃止予定です。このモード (コマンド 'c') を止めることを
      強く推奨します。 and change display units to
         sectors (command 'u').

コマンド (m でヘルプ): a
パーティション番号 (1-4): 1

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1   *           1         132     1060256+  fd  Linux raid 自動検出
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.
/dev/sdf2             132        4310    33551756   82  Linux スワップ / Solaris
/dev/sdf3            4310      121601   942147988+  fd  Linux raid 自動検出

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!


ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。
/dev/sdfをRAIDに組み込みます。
[root@erogamescape13 ap2]# mdadm /dev/md0 --add /dev/sdf1
mdadm: added /dev/sdf1
[root@erogamescape13 ap2]# mdadm /dev/md1 --add /dev/sdf3
mdadm: added /dev/sdf3
組み込むとRebuildがはじまります。
/dev/md0は1Gしかないのであっという間に終わりますが、/dev/md1は相当時間がかかります。
[root@erogamescape13 ap2]# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.0
  Creation Time : Thu Jul 28 04:17:57 2011
     Raid Level : raid1
     Array Size : 1060244 (1035.57 MiB 1085.69 MB)
  Used Dev Size : 1060244 (1035.57 MiB 1085.69 MB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Jun 24 23:21:19 2014
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : localhost.localdomain:0
           UUID : 02707424:61b2b644:717d3829:948376d3
         Events : 223

    Number   Major   Minor   RaidDevice State
       0       8       65        0      active sync   /dev/sde1
       2       8       81        1      active sync   /dev/sdf1
[root@erogamescape13 ap2]# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.1
  Creation Time : Thu Jul 28 04:17:59 2011
     Raid Level : raid1
     Array Size : 942138801 (898.49 GiB 964.75 GB)
  Used Dev Size : 942138801 (898.49 GiB 964.75 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Jun 24 23:21:51 2014
          State : active, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 0% complete

           Name : localhost.localdomain:1
           UUID : e1c4e9e4:ed5a8be1:2e5318e8:3fc28250
         Events : 1335745

    Number   Major   Minor   RaidDevice State
       0       8       67        0      active sync   /dev/sde3
       2       8       83        1      spare rebuilding   /dev/sdf3
[root@erogamescape13 ap2]# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdf1[2] sde1[0]
      1060244 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sdf3[2] sde3[0]
      942138801 blocks super 1.1 [2/1] [U_]
      [>....................]  recovery =  0.3% (3171840/942138801) finish=218.2min speed=71696K/sec
      bitmap: 7/8 pages [28KB], 65536KB chunk

unused devices: 
/dev/sdfから起動できるようにgrubを書き込んでおきます。
/dev/sdfがhd0なのかhd1なのか分からないので(いや…分かる方法はあると思うのですが…)、とりあえずhd0にもhd1にも書き込んでおればいいかーということで、両方にgrubを書き込んでおきます。
Rebuild中でも大丈夫です。
[root@erogamescape13 ap2]# grub
Probing devices to guess BIOS drives. This may take a long time.


    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]
grub> root(hd0,0)
root(hd0,0)

Error 2: Unrecognized command
grub> root (hd0,0)
root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  26 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+26 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.
grub> root (hd1,0)
root (hd1,0)
 Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd1)
setup (hd1)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd1)"...  26 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd1) (hd1)1+26 p (hd1,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.
grub> quit
quit
以上で作業は完了です。

HDDが毎日とか週単位で壊れる環境だったら問題ないですが、個人でRAIDを使っているレベルだとごく稀にしか壊れないため、実際に壊れた場合に「さて、どうするんだっけ?」となると思います。
RAIDを組む際には、組んだ際に壊れたときの対処方法を何回か練習しておくべきだと思っています。
実際に壊すことはできないので、SATAのケーブルを抜いてみるとかそういう感じになってしまいますが…

踏み台経由で作業をする場合の注意点と対策

事故らないために普段守っているターミナルの運用ポリシ(Mac + iTerm2) | TechRachoを読んで、.ssh/configにProxyCommandを書くと、exitしたときに踏み台サーバーに戻るのではなくて、そのままセッションが切れるように出来るということを知りました。

自分は仕事でNW機器の監視と故障対応をしているので踏み台NW機器というのでしょうか…を経由して、作業をすることがたまにあるのですが、いくら気をつけていても、いくら2人で作業をしていても、やっちゃうときはやっちゃいます。

やっちゃうのは、ド定番で、知らない間に(知らなくはないのですが…自分的には知らない間に…)セッションが切れるか、切ったりして、本来踏み台の先のNW機器にいれるコマンドを、踏み台のNW機器に入れてしまうことです。

踏み台になるのは、二重構成になっているNW機器の逆の系のNW機器なことが多いのですが、踏み台を経由して故障したNW機器にログインして、試しにリセットでもしてみるかーと思ってリセットするコマンドを、踏み台のNW機器で実行してしまって(以下略

NW機器にも
ProxyCommand的な何かが欲しい…そう思いました。

※ちなみに、以下略の後、私は叫びました。 

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

はじめに

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

20131123170115_original


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

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

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

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


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

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

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

20131123163318_original


20131123163331_original


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

20131123153218_original

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

20131123152906_original

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

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

20131123152702_original



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

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

20131123163258_original

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

20131123163146_original

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

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

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

20131123154955_original

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

20131123154836_original

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

20131123154528_original

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

20131123154216_original

20131123154200_original

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

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

20131123152333_original

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

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

20131123151348_original

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

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

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

20131123145307_original

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


20131123144737_original

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

 20131123143914_original

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

20131123143705_original


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

20131123142443_original


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

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

石狩データセンターは6万6000Vで受電しているそうです。
6万6000Vを電力会社の変電所から受け取るには
  • 高圧鉄塔を作って送電線を這わせる
  • 地中に洞道を作って這わせる
ことが必要だそうです。

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

20131123142038_original

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

20131123135154_original

20131123135140_original

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

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

20131125151209_original

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

20131125151207_original

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

20131125151154_original

写真は以上です。


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

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

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

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

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

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

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


終わりに

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

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

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

IPVSとKeepalivedとApacheは同じOS上で共存出来ない…と思う

はじめに

一つのパソコンのLinuxの上に
  •  KeepalivedでVRRPを設定
  •  IPVSでロードバランシングを設定
  •  Apacheを動作
させて、
  •  パソコンが落ちると、もう一つのパソコンに切り替わり
  •  通常時は2台あるパソコンに処理を分散させる
ことを実現しようと思ったのですが、出来なかった…という記録です。
※何年かしたら、なんで出来ないんだっけ?と思う日が来るかもしれないので書いておきます。
※ちなみに、IPVSとKeepalivedの設定はKeepalivedによるロードバランサLVS構築 - RLBの文書が丁寧でいいかなと思います。


ハードウェア構成
001

実現したかった構成
002
設定
BlogPaint

#VRRP部分
vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    garp_master_delay 5
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.0.100/24 dev eth1
    }
}

#ロードバランシング部分
virtual_server_group example_web_servers {
  192.168.0.100  80
}

virtual_server group example_web_servers {
  delay_loop   3
  lvs_sched    lc
  lvs_method   DR
  protocol     TCP

  real_server  192.168.0.1 80 {
    weight 1
    inhibit_on_failure
    HTTP_GET {
      url {
        path /
        status_code 200
      }
      connect_port 80
      connect_timeout 10
    }
  }
  real_server  192.168.0.2 80 {
    weight 1
    inhibit_on_failure
    HTTP_GET {
      url {
        path /
        status_code 200
      }
      connect_port 80
      connect_timeout 10
    }
  }
}
想像していたもの
BlogPaint


現実
BlogPaint


192.168.0.100の80番ポートに要求が来ると、それをロードバランサが処理するのではなくApacheが先に処理をしてしまいます。その結果、ロードバランサは素通りします。

ロードバランサもApacheも80番ポートで待ち構えているのがNGなので、Apacheのポートを8080にすればいいじゃないか!とも思いましたが、DSR構成でないといけないのでApacheのポートを8080にすると80番ポートに要求してきたものが8080番で応答が返ってしまうのでNGです。

ちなみに左のパソコン自身で
$ curl http://192.168.0.100/index.html
すると、左のパソコンのApacheが選ばれた場合は
21:55:03.363352 IP 192.168.0.1.52535 > 192.168.0.100.http: Flags [S], seq 2243980878, win 14600, options [mss 1460,sackOK,TS val 2335997614 ecr 0,nop,wscale 7], length 0
21:55:03.363465 IP 192.168.0.100.http > 192.168.0.1.52535: Flags [S.], seq 1870693664, ack 2243980879, win 14480, options [mss 1460,sackOK,TS val 2335994093 ecr 2335997614,nop,wscale 7], length 0
21:55:03.363571 IP 192.168.0.1.52535 > 192.168.0.100.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 2335997614 ecr 2335994093], length 0
21:55:03.363659 IP 192.168.0.1.52535 > 192.168.0.100.http: Flags [P.], seq 1:184, ack 1, win 115, options [nop,nop,TS val 2335997614 ecr 2335994093], length 183
21:55:03.363995 IP 192.168.0.100.http > 192.168.0.1.52535: Flags [.], ack 184, win 122, options [nop,nop,TS val 2335994094 ecr 2335997614], length 0
21:55:03.364464 IP 192.168.0.100.http > 192.168.0.1.52535: Flags [P.], seq 1:272, ack 184, win 122, options [nop,nop,TS val 2335994094 ecr 2335997614], length 271
21:55:03.364550 IP 192.168.0.1.52535 > 192.168.0.100.http: Flags [.], ack 272, win 123, options [nop,nop,TS val 2335997616 ecr 2335994094], length 0
21:55:03.364750 IP 192.168.0.1.52535 > 192.168.0.100.http: Flags [F.], seq 184, ack 272, win 123, options [nop,nop,TS val 2335997616 ecr 2335994094], length 0
21:55:03.364997 IP 192.168.0.100.http > 192.168.0.1.52535: Flags [F.], seq 272, ack 185, win 122, options [nop,nop,TS val 2335994095 ecr 2335997616], length 0
21:55:03.365065 IP 192.168.0.1.52535 > 192.168.0.100.http: Flags [.], ack 273, win 123, options [nop,nop,TS val 2335997616 ecr 2335994095], length 0
と、送信元が192.168.0.1で宛先が192.168.0.100となって通信が成立します。
が、右のパソコンが選ばれた場合は
21:57:00.468685 IP 192.168.0.100.40601 > 192.168.0.100.http: Flags [S], seq 1090039344, win 32792, options [mss 16396,sackOK,TS val 2336114720 ecr 0,nop,wscale 7], length 0
21:57:00.468820 ARP, Request who-has 192.168.0.100 tell 192.168.0.2, length 46
21:57:00.468843 ARP, Reply 192.168.0.100 is-at 6c:62:6d:08:c8:97 (oui Unknown), length 28
21:57:00.469031 IP 192.168.0.100.http > 192.168.0.100.40601: Flags [S.], seq 354377091, ack 1090039345, win 14480, options [mss 1460,sackOK,TS val 2336111198 ecr 2336114720,nop,wscale 7], length 0
21:57:01.468573 IP 192.168.0.100.40601 > 192.168.0.100.http: Flags [S], seq 1090039344, win 32792, options [mss 16396,sackOK,TS val 2336115720 ecr 0,nop,wscale 7], length 0
21:57:01.468714 IP 192.168.0.100.http > 192.168.0.100.40601: Flags [S.], seq 354377091, ack 1090039345, win 14480, options [mss 1460,sackOK,TS val 2336112198 ecr 2336114720,nop,wscale 7], length 0
21:57:01.631898 IP 192.168.0.100.http > 192.168.0.100.40601: Flags [S.], seq 354377091, ack 1090039345, win 14480, options [mss 1460,sackOK,TS val 2336112362 ecr 2336114720,nop,wscale 7], length 0
21:57:03.468575 IP 192.168.0.100.40601 > 192.168.0.100.http: Flags [S], seq 1090039344, win 32792, options [mss 16396,sackOK,TS val 2336117720 ecr 0,nop,wscale 7], length 0
21:57:03.468768 IP 192.168.0.100.http > 192.168.0.100.40601: Flags [S.], seq 354377091, ack 1090039345, win 14480, options [mss 1460,sackOK,TS val 2336114198 ecr 2336114720,nop,wscale 7], length 0
21:57:03.631910 IP 192.168.0.100.http > 192.168.0.100.40601: Flags [S.], seq 354377091, ack 1090039345, win 14480, options [mss 1460,sackOK,TS val 2336114362 ecr 2336114720,nop,wscale 7], length 0
となって、192.168.0.100の間でピンポンゲームになってしまいます。
送信元が192.168.0.100になるロジックが分からないのでなんともですが、まず
192.168.0.100 → 192.168.0.100(左のパソコンが受信)
というパケットが左のパソコンに送られます。
左のパソコンには
iptables -t nat -A PREROUTING -d 192.168.0.100 -j REDIRECT
が書いてあるので、送信元が192.168.0.100、宛先が192.168.0.100のパケットを返します。
このパケットを受け取った左のパソコンは…送信元が192.168.0.100で宛先が192.168.0.100ってなんだっけ?と破棄して、またSYNパケットを送る…という動作になっているのだと思います。

実現するには

多分、物理的なパソコン2台に、それぞれ1つのOSがのっているという状態だと無理なのだと思います。

※ぐぐって見つかるIPVS + Keepalivedの設定例は、書いてある図が物理構成なのか論理構成なのかいまいち分からない…というのが悩ましいところだと思っています。

※余談ですが、NW機器をまったく知らないという方が異動したきた際に例えばVRFを使った「論理的なルータ」というものを理解してもらうのに苦労します…しませんか?。「ええとね、このルータは物理的には1台なんだけど、仮想的に3台になっていてね…」「物理的なポートに対して仮想的なポートを設定してね…」と説明すると、明らかに挙動がおかしくなり、じゃあ図を書いて説明しますねとホワイトボードに向かうも…ごちゃごちゃになっていまいち分かりにくいと…自分はいったいこれをどう理解して現在に至るのか分かりません…

多分、以下のように仮想化するしかないのかなと…
006

この構成を取るには学ばなければいけないことがたくさんありすぎるので諦めることにしました。

設定を開始してから諦めるまで5時間くらいかかりました。敗因は「できる」と思い込んでいたことでしょうか…
「できなかったです」という掲示板のやりとりを見て「ああ、やっぱできないんだ」と、そこで、自分でいろいろいじった結果も踏まえて納得して諦めることができました。
この文書が、私と同じ発想に行き着いてしまった方のために役に立つことを祈ります。
※まあ、だいたい、何年後の自分のために役に立つことが多いんですよね。ぐぐると、意外に自分の書いた文書がひっかかったりします…

※ちなみに、keepalivedによるVRRP --- nginx(80番ポートで待ち受け)によるロードバランス ---- Apache(8080番ポートで待ち受け)な構成で、元々やりたかったことが実現可能だと分かりました。


 
もう5年も前に発売された本ですが、個人でサーバーを運用している私にとってはその内容は色あせることがないです。Webの世界…特にフロントエンドは新しい技術がわさわさ出てきてついていくのが大変ですが、インフラの世界は比較的穏やかなのかな…という気がしました。
そのかわり、達人の域に達するには、達人の域が必要である環境に飛び込まないとスキルが身につかない気がいたします。一度、すごいトラヒックをさばく環境で仕事をしてみたいです。

一週間止まっていたサービスを何の考えもなしに最繁時間帯に再開するとどうなるか

概要

一週間止まっていたサービスを何の考えもなしに最繁時間帯に再開するとどうなるか…

今まで考えないことはなかったのですが、具体的な対策もしていなかったので想定通り接続しづらい状態が続きました。
誤算は応答時間が通常通りになるまで2時間を要したことでした。

サーバーを現用に組み込む場合は慣らし運転をして十分にキャッシュにデータがのった後に組み込む必要がある…というのは知っていましたが「まあ、30分くらい耐えられば大丈夫だしなあ」と思って特に対策はしていませんでした。
※事実、今までも半日くらいサービスが止まることはありましたが、30分くらいで落ち着きました。

後述しますが、ErogameScapeはPHPが生成するキャッシュ機構を使ってキャッシュを生成しています。
その生成のためにIOwaitが発生し応答時間が遅延しました。

よくアクセスのあるページのキャッシュを生成するスクリプトを作る必要があるかなあ…と思いました。

詳細

2013年9月9日から2013年9月15日に発生した障害についてに記載したとおり、ErogameScapeは一週間ほどサービスが止まりました。
ハード的な障害ではなくソフトの問題でしたので、サーバーを再起動すれば復旧できました。
今までの経験からサーバーが止まって復旧させるとアクセスが集中して負荷が大変なことになることは分かっていました。

ErogameScapeのソフトの構成は以下のようになっています。
---- Apache ---- PHP  ---- pgpool  ---- PostgreSQL
                  |
                  |----- PHPのキャッシュ(HDD)
ErogameScapeは2台のサーバーで動かしています。
いつもは1台のサーバーでやりくりしているため、ApacheもPostgreSQLも同じサーバーで動かしています。
しかし、今回は多数のアクセスがあることが予想されたため、ApacheとPostgreSQLを別々のサーバーで動かすことにしました。

---- Apache ---- PHP  ---- pgpool  --------   ネットワーク    ---- PostgreSQL
                  |
                  |----- PHPのキャッシュ(HDD)
 
この状態で、twitterで「高負荷になるのでアクセスできない場合は時間をおいてアクセスしてください」とアナウンスして、組み込みました。

その結果
 Apacheを動かしているサーバーのLoad Average → 100越え
 PostgreSQLを動かしているサーバーのLoad Average → 最大でも10程度
と、そんな結果になりました。

「ああ、ErogameScapeって意外にPostgreSQLによる負荷って少ないんだなあ」と今更ながら思いました。
さて、Apackeの方がボトルネックになっているからなんとかしないといけないと思いました。

Apacheのhttpd.confのMaxClientsが大きすぎると接続数が多すぎて処理できないから、少なく設定してクライアントに待ってもらった方が結果的に応答時間が少なくなる…という記述を見たことがあったので、設定値を300から200にしてみました。

その結果、300の場合は応答時間が長いものの応答が返ってきていたのですが、200にしたらそもそも応答が返ってこなくなって、これはまずい…と元の設定に戻しました。

元に戻した途端に応答時間が通常通りになりました。

さて、何がボトルネックになっていて当時応答時間が遅かったのだろう…と思ってmuninのグラフを見て考えました。

無題

①はサーバーを組み込んだ後、応答時間が長かった間のApacheのアクセス数です。
通常50access/secondくらいは問題なく処理できるはずなのですが全然捌処理出来ていません。
キャッシュを生成しきった後と思われる②の時点では、通常通り処理できています。

また、Apacheのprocessesについて、③はサーバーを組み込んだ後で、MaxClientsの上限である300までいってしまっているのが見えます。その後、④で200に設定を変更しても応答がなくなってしまったので、あわてて300に変更したら200processes程度に落ち着いたのが分かります。

無題
当時のDisk throughputを見ると最大で3.8MB/secondの書き込みがあります。
②の段階では520kB/second程度にまで落ちています。
ErogameScapeは主要なページをキャッシュしています。
PHPがキャッシュを生成しまくって、最大で3.8MB/secondの書き込みをしている結果、応答が遅くなったのだろうなあと思います。

以上の事象を防ぐには、事前にキャッシュを生成するか、キャッシュを破棄するタイマーを一時的に長くして(通常は5分から1時間に設定しています)みることかなあ…と思います。

終わりに

商用でサービスを提供している技術者の方々には当たり前の内容な気がするのですが、多くのアクセスがある規模のサービスを提供する会社に入るのはすこぶる難しい気がして、でもそういう会社に入らないと学べないこともあると思うんですが、そういう会社に入るためにはそういう会社の当たり前なこと知らないと入れない気もして(求人の条件を見ると、そんな人は少ないんじゃないか…なものばかりに見えます)、できる人はよりできるようになるけど、できないけどやる気がある人は…昔よりは大規模サービスを運用している方々がいろんな本を書いてくださっているので学ぶことはできるのですが、昔よりすこぶる内容が難しくなっているし覚えることも多いし、大変だよなあ…と思います。
こう…なんといいますか、中間くらいの知識が欲しいです。
初心者でもないけど、大規模なサービス運用者でも全然なくて、サーバーが2,3台で済むくらいのサービス運用のノウハウ的な何か。
Webサービス以外の分野もそんな気がしますが、初心者向けの本(サーバーを構築してみよう的な)と、専門書(数百台規模のサーバーを運用します的な)は充実しているのですが、その中間というか、1台だったサーバーを2台で運用してみよう!的な段階の本があるとうれしいなあと思います。
実はあったら教えて欲しいなあと思います。 
記事検索