チャージ不足でサーバー停止50時間

ConoHa のチャージ残高が尽きていて、サーバーを止められていたのに気づいたのが1月5日の夜中だった。

300円チャージしたのが6日の朝7時で復活した。

停止したのは4日の0時過ぎだから、50時間以上のダウンタイムとなった。

4日の0時といえば、Poon Hill トレッキング中で、ゴレパニの宿で深い睡眠中であった。

ポカラに着いた夜に気づいた。

丁度WiFiがなかった。

 

止められたらメールで通知が来るが、見落としていた。

このサイトはモニターされていて、ダウンするとメール通知が届くが、ダウンした直後と、その1時間後の2回しか届かない。これが1時間ごとに届いていればもう少し早く気付くこともできただろうが。

警告なしにサーバー停止するのがいけない。

止める前にそれだけの警告メールが1本欲しい。

いきなり止める。

残高の通知メールは頻繁に来るが、頻繁すぎて見ない。

残高メールと、サーバー停止警告メールはサブジェクトぐらい変えて欲しい。

 

それに、サーバーを停止したという通知メールは誰もが寝ている時間ではなく、起きている時間に送信すべきであろう。朝9時とか。すぐに反応できるように。

 

チャージ不足でサーバーを停止されたことはこれまでにも何度かあった。

2回だった。

その時はこれほど長時間はダウンさせずに追加チャージできていた。

 

ConoHa  4 January 2018 at 00:50
 
makotoiwasaki.com 様
いつもConoHaをご利用いただき、ありがとうございます。

ConoHaチャージの残高不足により、サービスを一時停止させていただき
ました。至急ご入金(チャージ)をお願いいたします。
————————————————————
不足金額: 14 円
ConoHaアカウント :  C39808666
————————————————————
ご入金(チャージ)が確認でき次第、自動的にサービスの復旧手続きを
進めさせていただきます。
復旧までに1時間程かかる場合がございますことあらかじめご了承
ください。

ご利用サービスの詳細につきましては、コントロールパネル内、右上
メニューの「請求履歴」にてご確認ください。

なお、お支払いには、自動引き落としのためサービス停止の心配が少ない
「クレジットカード払い」がおすすめです。

お支払い方法の設定につきましては、コントロールパネル内
右上メニューの「支払い設定」にてご設定ください。

▼コントロールパネルへのログインはこちら
https://www.conoha.jp/login


【ご注意】

弊社にて不足金額分のご入金が確認できない場合、ご利用のサービスを
削除させていただきます。

————————————————————
削除予定日: 2018/01/10
————————————————————

サービスの削除後は不足金額をご入金いただいた場合でも、復旧を
承ることができません。あらかじめご了承ください。

今後ともConoHaをよろしくお願いいたします。

——————————
ConoHa byGMO
https://www.conoha.jp/

 

GMOグループのサービスは、お名前.com でもVPS でも支払い方法としてデビットカードは使えないようになっている。クレジットカードのみ。それで前払いチャージしておかねばならぬ。不足するとサーバ停止される。めんどくさい。

それでGMOとの決別を試みた。

 

関連

Compute Engine - IaaS  |  Google Cloud Platform
Google Compute Engine は、高性能な仮想マシンを低価格で提供し、高速で環境に優しいネットワーキングを実現します。

 

 Google Cloud Platform の Google Compute Engine がVPS に相当するサービス。

無料トライアル+1年間300ドル分のクーポンがあって、今回はこれにした。

Amazon のEC2 に相当する。

サーバーの位置でアメリカのオレゴンを選択し、f1-micro+HDD30GB 以下の構成なら半永久的に無料で利用できる。

今回はせっかく1年間300ドル分使えるのだから1ヶ月25ドル分は使えるとして、

東京レジョンで g1-small メモリ1.7GB  $16.45/月 をセットアップしてみた。

 

関連

Google Cloud Platform 料金計算ツール  |  Google Cloud Platform
Create your own Custom Price Quote for the products offered through Google Cloud Platform based on number, usage, and power of servers

 

Conoha から Google Compute Engine へ丸ごと移転

これは非常に簡単だった。

サーバーの丸ごと移転ツールで、もはや、Wordpress の個別の移転作業の面倒は必要ない。

VM の Compute Engine への移行

の通りにやればよい。

最初はオレゴンに移してみたらデータ転送に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?
How do I set the hostname of an instance in GCE permanently? I can set it via hostname,but after reboot it is gone again.I tried to feed in metadata (hostname:f.q.d.n), but that did not do the jo...

 

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 アクセス権を許可する。

 

 

関連

Amazon EC2 から ConoHa に移転する
 Amazon AWSの1年無料期間が終わるので移転した。 無料といっても月3ドルぐらいの請求はされていた。データー転送量の課金である。移転の手順はこんな感じ。 新サーバーのSSHログイン操作環境を整える。 /root/.bashrc    などのコピー 新旧サーバー同...

関連

Blogger からWordPress-Kusanagi への移転方法:同一ドメイン
 Blogger からKusanagi-WordPress への移転が完了し、一段落したので、これまでの経緯を振り返り、次回のためのマニュアルとして記す。 BloggerからWordPressに移行決定。 Bloggerでも独自ドメインで運用していた。 Wordpressでも同一ドメインで運用す...

次の記事