PHPのテクメモ

今、借りているVPSの一つ、ConoHaが停止させられた。メールの文面を見ると、支払いができていないらしい（プログラムで送信されたメールのようだが変数が正しく置換されていなくて少し戸惑ったが）。諸般の事情でクレジットカード払いから口座引き落としに変更してもらったのだが、トラブっているのかもしれないと思って「支払うから方法を教えて」とメールしてみた。折り返しのメールで、「入金は確認していて手違いでした」の連絡が来た。改めて引き落とし口座を確認したら、きちんと引き落としされていた。低姿勢で「お金払います」といったが、引き落としをちゃんと確認していればもっと強気で言えたのに。

サーバは停止されていたが、すぐに復旧された。もともと開発用に借りていたサーバで、数ヶ月くらい寝かしたままだったので問題はなかったのだが、止まっていたMySQLの起動ができなくて困ってしまった。

Another MySQL daemon already running with the same unix socket.

んー。どうもVPSは強制停止させられた状態っぽい。強制終了されたので、sockファイルが削除されずに残ってしまっている感じ。確認したらやっぱりファイルがあったので、削除した。

rm /var/lib/mysql/mysql.sock

これで起動できた。

調べてみたら、あと連絡が3日ほど遅かったら、VPSが削除されるような感じだった。もし、この状態で本当に削除されていたら、当然データの復旧は難しいと思うのだが（バックアップはあるだろうけど）、どういう責任をとったんだろうと、ふと不思議に思った。

今回は実害がなかったのでクレームは入れない（開発を再開するきっかけになったから）。でも、厳重注意だね。

GMOが2013年7月に提供を開始した新しいVPSブランド「ConoHa」を新たに契約したのでメモしておく。

GMOグループは、お名前.com、ラピッドサイト、ServerQueenといろんなブランドでVPSを提供している。以前はあまり好きではなかったが、お名前.comで借りているVPSが予想以上に快調で最近自分の中では株が上がっている。そんなGMOが2013年7月にConoHaというブランドで新たにVPSサービスの提供を開始した。

萌えキャラを全面に押し出しているようで、正直なところ全く興味がわかなかったのだが、複数のIPアドレスを使用できるということで、試用する運びとなった。今回契約したのはメモリ2GBのプランでスペックは以下のとおり。

メモリ2GB
ハードディスク200GB
CPU3コア
初期費用0円
月額費用1,470円

低価格VPS路線としては概ね一般的なスペックであり、安価である（昔はもっと高かったよなとしみじみ思う今日このごろである）。お試し期間も15日あるので試用には十分だ。最初に申し込む（アカウントを登録する）際にクレジットカードの番号が必要。アカウント作成後、VPS追加時に電話認証（管理画面から登録した番号に電話をかけさせて暗証番号を入力）を要求される。ちなみにうちの電話はちょっと小細工がしてあって電話認証できなかったのだけれど、その際「携帯の番号にでも変えてくれ」とのメッセージが表示されたので、指示に従って認証することができた（昨今固定でも携帯でも認証さえ出来れば番号はなんでもいいのかね）。

電話認証完了後、管理画面からVPSを作成すると数分程度でVPSが準備され起動する。初回起動時はsshとpostfixが動いていた。またVPS作成時にSSHキーが作成される（多分root用）。基本的にはrootでログインすることはないし、最初はウェブコンソールからログインしたのでこのキーは使わなかった（新規ユーザを作ってそちらを使うので）。

まだ何も試していないのだけれど、ちょこっと触ってみた感じでの印象をメモしておく。

良い点

• 体感速度
  SSHでログインしてコマンドを叩いている印象では、とっても速い！。ものすごく快適だ。

悪い点

• とりあえず今のところ見つからない。
  試用期間の解除の方法がわからない。放置しておけば勝手に本契約になるようだが、25番ポート制限を早めに解除したくて。
  後日ウェブサイトをよく読んで本契約に移行する方法がわかった。

とまどった点

• apacheを起動したけどブラウザから接続できず（同様にSSHも）。
  理由が全然わからなかったけど、そういえば「ConoHaで、あっという間にWebサーバーを立ち上げてみる方法」ってのが技術情報にあったと思いだしたので確認してみた。
  どうやらデフォルトでiptablesが設定されている模様（初期設定では22番ポートのみオープン）。これは他のVPSではなかったこと。とりあえず後で設定し直すとして、技術情報に従ってCUIベースの仮ツールで設定。無事接続できた。
  あとで、手動で設定してSSHのポート番号変更もできた。

今、わかるのはそれだけ。さすがに提供を開始してから1ヶ月経過していないので、口コミ情報が殆ど無いに等しい。これからユーザが増えれば速度も遅くなってくるのかもしれない。あとどのくらい安定稼働してくれるのかそれが少しだけ心配。とりあえず人柱ということで。

「ssh_exchange_identification: read: Connection reset by peer」とエラーが出る件、症状を取りまとめると、「最初の接続で必ずエラーになるが、続けて接続しようとすると今度は接続できる」ということのようだった。

結局、何の対応もせずサーバ側のsshdを再起動してみたりしたが、やっぱり症状は続いた。

いろいろ調べてみたが、大抵の場合、上記のエラーが出るような場合は接続自体ができないようで、今回のように1回目はダメだけど2回目は大丈夫、なんて事例は見当たらなかった。

とりあえず、ネットで見かけた「hosts.allow」にsshd:allを書き加えてみたのだが、ひょっとしたらこれが当たりかもしれない。トライしてみたらエラーが出ないので・・・。

また、これで様子を見ることにする。

普段、毎日深夜に一回稼働中のサーバ全てのバックアップをとっている。バックアップは自動で、リモートサーバ（バックアップサーバ）に対して、ファイルとデータベースのダンプをSSH経由で転送している。

ある日突然いくつかのファイルがバックアップに失敗していることに気がついた。特定のサーバからのバックアップが全てNGというわけではなく、ファイルだけバックアップしてデータベースはバックアップしていなかったりしていた。とりあえずサーバにログインして調べてみた。

まず、リモートサーバにSSH出来るかどうか確認してみようと接続すると以下のエラーが出た。

ssh_exchange_identification: read: Connection reset by peer

んー。なんでだろう。おかしいなと思いつつ、再度トライしてみると今度はすんなりつながった。理由はわからないけれど、何らかのタイミングでエラーになったのか、それともゴミでも溜まっていたのか・・・。とりあえず動いてくれた。

と思ったら、それでもバックアップできない。ファイルのバックアップで、特定箇所でエラーが出ている。調べてみると、特定のファイルについて権限がないみたい。で、パーミッションを変更してみたら、今度はうまくいった。

結果として二つの疑問。

1. どういう理由でSSHのエラーが出たのかよくわからない。
2. 今まではパーミッションのエラーが出ていなかったのが不思議。

とりあえず、放置して様子を見ることにする。

Kagoyaで借りているVPSに帯域制限がかけられてしまった。転送量が多すぎたのか一時的な不可が高すぎたのか・・・。

Kagoyaで借りているVPSは、毎日深夜に1回お名前.comで借りているKVMなVPSとrsyncで同期をとっているバックアップサーバだ。帯域制限はかかっているようだがファイルのバックアップはとれているっぽい。しかしメールが届かなくなってしまっている。何故だろう。

負荷がかかるのはデータの同期で、メールの送受信はそんなに負荷はかからないと思うのだが、結果として、同期OKでメール不可っぽい状態が発生している。原因を調べてみなくてはいけないな。

ちなみに同期元のお名前.comのサーバについては何も言われていない。ということで、お名前.comとKagoyaクラウドにおいて、Kagoyaにかけられた帯域制限の原因を考えてみるとこんな感じだろうか。

• お名前.comのインフラやハードウェア等がかなりステキでお名前.com側には何ら不可がかかっていない。ただしKagoyaはしょぼすぎてすぐに制限がかけられる。
• インフラやハードウェアは同等だが、お名前.comの管理が甘々で、チェックがかかっていないだけ（他人の影響をうけやすい）。
• インフラやハードウェアは同等だが、Kagoyaの管理がキツキツで、すぐに制限がかけられる（他人の影響はうけにくい）。

メールはシステムのヘルスチェックをかけるために使用しているだけだが、正しく動作しないと手動でチェックしなくてはいけないので不便。引っ越そうかな。