チャージ不足でサーバー停止50時間
ConoHa のチャージ残高が尽きていて、サーバーを止められていたのに気づいたのが1月5日の夜中だった。
300円チャージしたのが6日の朝7時で復活した。
停止したのは4日の0時過ぎだから、50時間以上のダウンタイムとなった。
4日の0時といえば、Poon Hill トレッキング中で、ゴレパニの宿で深い睡眠中であった。
ポカラに着いた夜に気づいた。
丁度WiFiがなかった。
止められたらメールで通知が来るが、見落としていた。
このサイトはモニターされていて、ダウンするとメール通知が届くが、ダウンした直後と、その1時間後の2回しか届かない。これが１時間ごとに届いていればもう少し早く気付くこともできただろうが。
警告なしにサーバー停止するのがいけない。
止める前にそれだけの警告メールが1本欲しい。
いきなり止める。
残高の通知メールは頻繁に来るが、頻繁すぎて見ない。
残高メールと、サーバー停止警告メールはサブジェクトぐらい変えて欲しい。
それに、サーバーを停止したという通知メールは誰もが寝ている時間ではなく、起きている時間に送信すべきであろう。朝9時とか。すぐに反応できるように。
チャージ不足でサーバーを停止されたことはこれまでにも何度かあった。
２回だった。
その時はこれほど長時間はダウンさせずに追加チャージできていた。
ConoHa 4 January 2018 at 00:50
makotoiwasaki.com 様
いつもConoHaをご利用いただき、ありがとうございます。ConoHaチャージの残高不足により、
サービスを一時停止させていただき
ました。至急ご入金(チャージ)をお願いいたします。
------------------------------------------------------------
不足金額： 14 円
ConoHaアカウント : C39808666
------------------------------------------------------------
ご入金(チャージ)が確認でき次第、自動的にサービスの復旧手続きを
進めさせていただきます。
復旧までに1時間程かかる場合がございますことあらかじめご了承
ください。ご利用サービスの詳細につきましては、コントロールパネル内、
右上
メニューの「請求履歴」にてご確認ください。なお、お支払いには、
自動引き落としのためサービス停止の心配が少ない
「クレジットカード払い」がおすすめです。お支払い方法の設定につきましては、コントロールパネル内
右上メニューの「支払い設定」にてご設定ください。【ご注意】
弊社にて不足金額分のご入金が確認できない場合、
ご利用のサービスを
削除させていただきます。------------------------------
------------------------------
削除予定日： 2018/01/10
------------------------------------------------------------ サービスの削除後は不足金額をご入金いただいた場合でも、復旧を
承ることができません。あらかじめご了承ください。今後ともConoHaをよろしくお願いいたします。
GMOグループのサービスは、お名前.com でもVPS でも支払い方法としてデビットカードは使えないようになっている。クレジットカードのみ。それで前払いチャージしておかねばならぬ。不足するとサーバ停止される。めんどくさい。
それでGMOとの決別を試みた。
Google Cloud Platform の Google Compute Engine がVPS に相当するサービス。
無料トライアル＋１年間300ドル分のクーポンがあって、今回はこれにした。
Amazon のEC2 に相当する。
サーバーの位置でアメリカのオレゴンを選択し、f1-micro＋HDD30GB 以下の構成なら半永久的に無料で利用できる。
今回はせっかく１年間300ドル分使えるのだから1ヶ月25ドル分は使えるとして、
東京レジョンで g1-small メモリ1.7GB $16.45/月 をセットアップしてみた。
Conoha から Google Compute Engine へ丸ごと移転
これは非常に簡単だった。 サーバーの丸ごと移転ツールで、もはや、Wordpress の個別の移転作業の面倒は必要ない。
の通りにやればよい。
最初はオレゴンに移してみたらデータ転送に1時間ぐらいかかった。
毎月25ドル使ってもいいことにして、次には東京にしてみたらすぐに準備完了状態になった。
テスト起動して問題なければ、カットオフで本番起動する。
そこからが一苦労。
静的IP取得とDNS情報変更
サーバーの外部IPアドレスを把握してDNSサーバーに登録する必要がある。
IPアドレスには エフェメラル外部 IP アドレスと静的IPアドレスがあって、IPが変わってほしくなければ、静的IPアドレスを取得する作業が必要になる。
手順はここ：すぐに取得できる。
静的IPアドレスを確認できたら、DNSサーバーに変更登録する。
これで30分ぐらいで新サーバー、Google 東京のサーバーに接続されるはずである。
SSHでもConoha の時の認証鍵の設定のまま、ログインできる。
Conoha と Google Compute Engines のシステム（左）
Webmin の設定、ファイヤーウォールのポート開放
https ブログの表示は問題なかったが、サーバー設定ツール、Webmin 10000 ポートに接続できなかった。
ssh , http と https 以外のポートはGoogleファイヤーウォールで全部閉じている。
ポート 10000 だけ開放しょうと設定したらそれだけではだめだったので、とりあえず全部開放する設定を試みた。
右のような設定で、Webmin が表示されるようになった。
メールも受信できるようになった。
Google Cloud Platform ではメールの送信ができない
これでメールの受信は imaps でConoha の時の設定のままで受信できるようになったが、送信ができない。
Google Cloud Platform では、他社の外部メールサーバーのポート25 宛のトラフィックは全部遮断されているということが判明。
だから、送信したメールは全部闇に消える。
Google Cloud Platform がすすめる方法、一旦外部のメールサーバーに2525番ポートで中継してもらってからメールを送信する方法を取らざるをえなかった。
SendGrid、Mailgun、Mailjet という外部のリレーサービスのうち、Mailgun でやってみたら自分のドメイン名でもメールを送信できるようになった。
受信はこれまでどおり、自営サーバーでできる。
送信サーバーだけ Mailgun サーバーを使うように設定する。
smtp.makotoiwasaki.com
のようなサブドメインで登録し、
value-domain.com の無料DNSサーバーの設定画面で、次のようにsmtp の設定を追加したらできた。
txt smtp.makotoiwasaki.com. v=spf1 include:mailgun.org ~all txt smtp v=spf1 include:mailgun.org ~all cname email.smtp.makotoiwasaki.com. mailgun.org. cname smtp.makotoiwasaki.com. mailgun.org. mx smtp 10 smtp mx mxa.mailgun.org. 10 smtp mx mxb.mailgun.org. 10 smtp
後はこの手順通りに設定する。
smtp のユーザー名とパスワードは、
でドメイン名登録した時に表示される。
#/etc/postfix/main.cf に次を最後に追記するだけで良い。
relayhost = [smtp.mailgun.org]:2525 smtp_tls_security_level = encrypt smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous
これでテストメールを、Google Compute Engine をコマンドラインで送信してメールログを見ると、
no mechanism available
とエラーが出た。
これは cyrus-sasl-plain が存在しなかったことに起因する。Yum でインストールすればいいだけ。
yum install cyrus-sasl-plain
これで、自分のPCからも、Google サーバーからもメールを自分のドメイン名で送信できるようになった。
Mailjet もアカウントを作って試したが、ややこしい前置き、個人情報の聴取があってストップした。 Mailjet は欧州基盤のサービス。
ホスト名の恒久化
Amazon EC2 の時も困ったが、再起動するたびにホスト名が変更されてしまう。 それでホスト名が変更されないようにするには、これを参考に、
Google Compute Engine: how to set hostname permanently?
nano /etc/rc.d/rc.local
次を追記したら、よかった。
hostnamectl set-hostname my.hostname.com
/etc/hostname にホスト名は格納されているようだ。 この名前が毎回再起動する度にインスタンス作成時に登録した名前に変わってしまっていた。
Conoha 東京 から Google Cloud Platform 東京へのTraceroute
root@s4:~# trace 35.200.106.139 traceroute to 35.200.106.139 (35.200.106.139), 30 hops max, 60 byte packets 1 v150-95-144-2.a089.g.tyo1.static.cnode.io (150.95.144.2) 1.422 ms 1.432 ms 1.395 ms 2 unused-133-130-014-141.interq.or.jp (133.130.14.141) 2.896 ms 2.905 ms 3.108 ms 3 unused-133-130-013-017.interq.or.jp (133.130.13.17) 0.897 ms 0.881 ms 0.958 ms 4 unused-133-130-012-033.interq.or.jp (133.130.12.33) 0.765 ms 0.787 ms 0.770 ms 5 as15169.ix.jpix.ad.jp (210.171.224.96) 0.837 ms 0.826 ms 0.811 ms 6 * 108.170.242.161 (108.170.242.161) 0.927 ms 0.852 ms 7 216.239.49.180 (216.239.49.180) 1.163 ms 209.85.243.102 (209.85.243.102) 1.101 ms 209.85.245.116 (209.85.245.116) 1.076 ms 8 * * * 9 139.106.200.35.bc.googleusercontent.com (35.200.106.139) 1.653 ms 1.656 ms 1.678 ms
逆に Google Cloud Platform からConoha へのTracerouteはできなかった。ブロックされているようだ。
Google Compute Engine と Conoha のCPU
Google Compute Engine の /proc/cpuinfo
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU @ 2.20GHz stepping : 0 microcode : 0x1 cpu MHz : 2200.000 cache size : 56320 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx xsaveopt bogomips : 4400.00 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:
Conoha の /proc/cpuinfo
root@s4:/proc# cat cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz stepping : 2 microcode : 0x1 cpu MHz : 2599.996 cache size : 4096 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt bogomips : 5199.99 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz stepping : 2 microcode : 0x1 cpu MHz : 2599.996 cache size : 4096 KB physical id : 1 siblings : 1 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt bogomips : 5199.99 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:
/proc/meminfo の比較
左がGoogle Compute Engine 右がConoha /proc/meminfo
ハードディスクは SSD50GBから HDD50GBへ
丸ごとイメージ移行ツールでコピー移転したから50GBのハードディスクの使用量がそのまま移ったままである。 これを無料内のHDD30GBに変更したかったが今のところできない。 これで課金されるのかどうか様子見。
今はインスタンス1個のみで他は削除した。
Cloud API アクセス スコープ の設定でインスタンスを一旦停止
Cloud Platform のダッシュボードをいろいろいじっているうちに、 Stackdriver Monitoring サービスを有効化しようとして、agent をインストールしてみたらエラーがでて失敗した。 その理由は、そのインスタンスから、APIへのアクセス権限がないかららしかった。
VM インスタンスの詳細 画面で、 Cloud API アクセス スコープ という項目があればよいが、なければ編集して追加する。 その際にはインスタンスを一時停止しなければならぬ。 そして Cloud API アクセス権を許可する。
