サーバを安く調達する為に、昔からVPSを使う事が多いけど、
このVPSいろんな業者があって、それぞれの特色なども色々あるのですが
このBlogのKagoyaというVPSを使って提供している訳なのですが
最近、このKagoyaのVPSが品質が悪くてちょっとなーと思っているので記事にしたいと思います。

VPSとは？

上にもちょっと書いたけど、VPSを提供している業者となります。
VPSは、クラウドでサーバを切り売りしている業態で、1台のサーバの中に
複数のクラウドサーバを生成し、効率良くサーバを動作させるという仕組みです。

上記の画像は、起業ブログ様よりおかりしました。
https://kigyolog.com/article.php?id=519#:~:text=%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99%E3%80%82-,VPS%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF,%E6%8C%81%E3%81%A1%E8%87%AA%E7%94%B1%E3%81%AB%E6%89%B1%E3%81%88%E3%81%BE%E3%81%99%E3%80%82

だいたいこんな仕組みです。

それらを提供している会社が、AWSも含めて色々あります。
高い物から低価格低機能なものまで色々あるのですが、
今回は、その業者の1つ、KagoyaのVPSを紹介します。

Kagoyaとは？

https://www.kagoya.jp/vps/

使い始めた頃は、さくらのVPSより遙かに使いやすく利便性も高い状態でした。
なので、筆者は最初さくらのVPSをつかって、このブログサイトを公開しておりました。
その後、カゴヤの乗り換えた経緯です。

自動的にスナップショットをとる機能があったり、すぐ作って検証終わったらすぐつぶすみたいな
事がかなり簡単にできるすばらしいクラウドでした。

しかし、数年前からどんどんトラブルも増えてきており、夜中にホストサーバの容量が足りなくなり
契約してサーバを立ち上げているリソースを剥奪されて、使えない時間帯があったり。
リソース不足なんか、常時監視してれば、そろそろサーバリソース一杯だなとか
追加しないと、どれかのサーバが下記みたく影響を受けるな？とか分かりそうなものですが・・・。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
発生日時　：4月7日(金)23時30分 ～ 4月8日(土)11時40分（24時間表記）
原　　因　：リソース不足
対応内容　：リソース不足解消のためのメンテナンス実施
影響範囲　：ホスト機収容の以下インスタンス
　　　　　　○○○○○○○○
影響内容　：上記時間帯でご利用インスタンスに接続できない時間が発生いたしました。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

たまたま、使っていたサーバは、テスト用のサーバで商用としては使って居なかった為
実害はなかったのですが、それにしても、こちら起因でないサーバ停止は費用も含めて
譲歩いただきたいですが、メール一本で電話連絡などもない状態です。

これ以外にも

最近の出来事になりますが、上にも出てきました自動スナップショット保存機能がバグってます。
管理画面にはいって下記の仕組みがそれに当たります。

これをONにすると、1日1回（時間指定できないのもちょっと使いにくいのですが）自動的にホットで
スナップショット保存が行われます。ただ、最近コントロールパネル障害が多発している関係なのか？
この前のコントロールパネルのサーバにDDoS攻撃された影響なのか？
全く、普及後のテストをしていないのか？分かりませんが
上記スナップショット保存をONにしても、スナップショット保存がとられるないサーバと
普通にスナップショット保存が行われるサーバがあるのです。

これが、リアルでとられているスナップショットですが、何か？おかしくないですか？
カゴヤのサポートが言うには、

============================================================================
コントロールパネルのスナップショット一覧を確認したところ
ID：aaaaaaaa　スナップショット名：[停止不可]みせ
というスナップショットが6月14日15時3分に作成されておりました。

6月15日分のスナップショットについては、6月14日15時3分に取得されていますので
24時間程度お待ちいただけますでしょうか。
============================================================================
次保存されているのが、6月18日11:32:53です。
スナップショット保存の状態を確認しただけで、内部的な動作は一切確認せず
サポートが回答してきた訳です。

また、コントロールパネルから、問い合わせを投げても
平気で3日くらい何も対応せず、放置される状況が続いてます。
電話してやっと、一次回答をしますといって、送ってきたのが上のメールがそれに当たります。
過去色々なトラブルがあり、問い合わせしているのですが、10個あったら2つくらいしか
回答して折らず、その後の進捗やもう分かりません等も一切行ってこない。

サポートとしては、これを作ったシステム会社にエスカレーションするだけで
Kagoyaの方では、一切調べていないのではないかと思っています。

結局、24時間後はおろか、14日～18日の間にスナップショット保存はされず
なんなのか？不定期な感じになってる。

昨日の出来事

昨日は、もう数ヶ月前から調子が悪いサーバがあって、それをどうにすべく
調査してたのですが、結論からすると、ストレージの枯渇が影響しているかなとの結論で
停止させて、スナップショットを手動保存して、その作業自体も数時間かかって
なんなのよって？思いながら、なんとかスナップショット保存までこぎ着けて
その後、1つプランアップを実施したら、もはや帰ってこない。24時間がたとうとしている。

下記の動画みてもらえると、ステータス取得中となって強制停止も何も一切出来ない状態に陥った・・・。

カントリー風な音楽をつけたけど、いい加減にしてほしい感じ。

このサーバは、もう捨てる決心が早々についてるので、サーバさえ起動して、状況さえ確認出来たら
もうすてて、課金を止めたいのですが、このままでもずーっと課金され続けている訳で。
ヘルプデスクに電話して、早々にもう止めれるか？止めれないなら、いつまでこの状況なのかで
課金の金額をそれなりに検討しておかないと行けないので、どうにかしていただきたいですね。
これも、電話は時間外だったので、メールフォームから問い合わせを投げていますが
メールフォームって、上にも書いた通り、数日最低でも3日くらいは放置されて
受付したのか？今やってますなのか？全く分からないですよね。

何が起こっているか？考察する

このサーバは、数ヶ月前から調子が悪く、監視alertが多発するサーバだった。
そももそ、使用用途が監視サーバなので監視サーバ自体が遅く
問題ないサーバであっても、alertを発報するという訳の分からない状態になっていた。

これらの原因を調査すべきSSHで中に入って色々見るが、
特に何も無く、ひたすらシステム側の負荷が高い状態が見て取れた。

これは、今までの経験上、原因は限られる。

1．同じホストに人気のサイトを提供しているサーバがある場合
　　そちらにリソースを持って行かれて、あまりリソースを消費していない
　　サーバ側のリソースが奪われて遅くなっているパターン

2．収容されているサーバのいずれかが、DDoS攻撃などで
　　ネットワーク帯域を圧迫しており、ネットワークが流れないことにより
　　スペック劣化に陥るパターン

3．ホストサーバが不安定になっているパターン
　　完全に壊れるとわかるが、中途半端に壊れているパターン
　　例えば、該当サーバが収容されているストレージのSANの経路に問題があるとか
　　そのストレージ装置の収容されているボリュームのRAID構造が壊れているとか
　　RAID5もしくはRAID6構成でいずれかのSSDが壊れていて、スペックダウンしている場合など

色々考えられるが、スナップショット保存に異常な時間を要し、
スナップショット自動j保存にも数日かかっていることから、
最後のストレージ装置の不具合の可能性が高い気がする。

今回不具合のサーバから採取した、スナップショットをインスタンスとして
サーバを構築したが、全くをもってあれだけ不安定だった状況がうその様に改善した。

その結果をもって考えると、収容されていたホストもしくはストレージ装置
もしくは、その両方に不具合があって、数ヶ月まえから調子が悪かった事がうかがえる。

もし、サーバそのものが調子が悪い場合、スナップショットからサーバを起こしても
同様に調査が悪い状態が再現されるはず。
例えば、サーバをクラックされて何か他のサイトへの攻撃の踏み台にされているとか。
画面開くだけでもヒーヒー言っていたので、新たな環境で立ち上げたサーバは
何もなかったかのように無事動いている。

調子が悪い時は、CPUの負荷率が1～3位をいったり来たりしてた、
今は、0．1～0．4平均最大でも0．8くらいで収まってる。

これからのことから、格納されたサーバホストに接続されるサーバ本体か、ストレージ装置のトラブルが考えられる。
こういうのは、監視を日々ちゃんとトレンドを見ておけば、異常が発生する前に気がつける話しではあるが
監視サーバにたよっていると、閾値を超える前の不安定な状態であっても、監視がなっていないから
大丈夫だになってしまうのである。

改善いただきたい内容

とりあえず、ヘルプデスクのシステムへのスキル向上及び上流ヘルプデスクの
技術解析スキル向上と、チケットなどで焦げ付いている問い合わせへの対応を
もっとちゃんと実施していただきたい。電話で会話しても、スキル不足によって
会話にならない時がある。VPSを使う人って、それなりのスキル持ってる人だと思っています。
それに対応出来るスキルを持っている方の配置が好ましい。

対応に時間がかかり過ぎて、いまやってるのか？もう分からないから
忘れるのを待とうか？なのか全く分からない・・・。
こんな事言っちゃ悪いですが、サポートデスクは地に落ちてます。
よくこれで、クレームにならないレベルだと思っています。

最後に、今システムで色々異常が発生しているように思いますが
これ、システムが正常に動いてますか？を総点検していただきたいですね。

追記

問い合わせしていた内容が帰ってきましたが、予想通り

カゴヤ・ジャパン サポートセンター ○○です。
平素は当社サービスをご利用いただき誠にありがとうございます。

お待たせいたしまして申し訳ございません。

担当部署にて調査を行いましたが、6月19日に定期スナップショット取得ができなかった
原因について特定することができませんでした。

誠に申し訳ございません。

で？どうするの？分からないで済まそうとしてるみたいです。
現に現在もうごいていないのですが。
どうにかならないですかね？カゴヤさん！！

The post 正直、最近KagoyaのVPS品質悪い first appeared on ～下町物語～.

昨日作成して立ち上げたインスタンスですが、朝まで起動していたのですが、朝までに６４回sshの不正アクセスがありました。何ちゅうipアドレスを引き当てちゃったんだよｗ

スナップショット取って、もう一回インスタンス立て直そうかなと思います。まだ、朝まで処理流していたのですが、処理が終わらなかったので途中で止めましたが、不正アクセスがなかったら、そのまま流しっぱにしたかったですけど。

後３０パーセント位残す所まで処理が進んで行ったのですが、また、夜起動して完全にipを限定し隔離した後処理する感じにしたいと思います。しかし、上手くいかねーっす。

The post 昨日作成したインスタンス・・・・org first appeared on ～下町物語～.

本日の東京の空模様

本日ですが、めっちゃ晴れてますね。雨の心配は無いようです。洗濯日和ですので、たまった洗濯物を一気に片付けてましょう。

雪情報

今日も雪の影響は出ている感じですね。

今日の一言

昨日は、自宅帰って来てから色々やってました。スナップショットからの戻しが遅かったこともあり、気がつけば３時３０分になったので速攻寝ました。睡眠効率が９４パーセント位なので、比較的朝すっきりしています。ショートスリーパーなので、そんな感じですね。今日も解析と再構築を進めないといけないです。かなり負荷が高いですね。

最後の一言

今日は、週の折り返し水曜日です。がんばって行ってらっしゃい。

The post 本日の東京の空模様です。１月１０日 first appeared on ～下町物語～.

旧ブログサーバ停止します。

以下のエビデンスから完全にDNSの書き換えがおわった事により、旧環境のサーバを停止します。

まずは、nginxのステータスをグラフ化しれいるのですが、朝の６時付近を最後にピタッとアクセスが止まりました。

ブログのcacheを吐き出しているグラフですが、こちらは１０月１９日の２４時付近で増加量は認められませんね。ただ、増加しない程度のアクセスは上のグラフをみていると、合った模様ですね。

この後

念の為スナップショットを作成して、インスタンスを停止します。以降はしばらくサーバのreplaceは相当な事が無い限り行わない予定です。特に読者の皆様においては影響はございません。

The post 旧ブログサーバ停止します first appeared on ～下町物語～.

ブログサーバreplace

当ブログサーバですが、諸事情によりreplaceしました。その理由は、これから下に書いて行きますね。

replaceした理由

このブログサーバですが、数点不可解な点があって、何が悪いのか？どうなっているのか？ずーーーーと調査していた案件があります。見た目は普通に何もないですが、ある特定の条件下の元発症するのです。

発症する構成図

どこにでもあるNAT環境です。グローバルIPと言われるいわゆる外部からアクセス出来るIPアドレスは、1つでルーター配下は、全てプライベートIPを振って、ポート番号でアクセス元とアクセス先を紐付けて通信させます。

出典：http://www.geekpage.jp/technology/nat/whatis-nat.php

この時、PC1・Android1・iPhone1・Android2・iPhone2と5台例えば、このブログサイトに接続してみます。

○PC1　通信出来る　×Android1／Android2　×iPhone1／iPhone2　通信出来ない。

不可解な現象

何かの拍子にiPhone1を再起動して、ブログサーバに接続すると、おぉ！なんか接続出来る様になった。もしくはは、Routerを再起動させて一発目はAndroid1で接続すると接続出来る。iPhone1は接続出来ない。Android2は接続出来ない。PCはいつも何も無く接続出来る。一度接続出来なくなると、もうずーっと出来ない。そして、ソフトバンクとか、ドコモとか、AUとかの3G・4G回線から来ると、問題なく接続出来る事。厳密に言うと回線業者によってちょっとまた色々あるので下に書きます。なぞやぁ！これ本当にハゲそうです。

そして分かったんです。

上の構成図で、NATの原理をちょっと書くと、ローカルIPに192.168.1.10(PC) / 192.168.1.11(Android1)/192.168.1.12(Android2)/192.168.1.13(iPhone1)/192.168.1.14(iPhone2)と仮定して、外に出るグローバルIPは、111.111.111.111とします。

PCからこのブログサイトに接続します。192.168.1.10 ->  111.111.111.111にRouterで変換される、その上でDNSサーバに当ブログのドメインを聞きに行く。このブログサーバは、Address: 133.18.171.141がこれなので、このグローバルIPに対して接続を行う。

ブログサーバは、アクセスしてきた端末に対して、ｈｔｍｌをコンテンツを111.111.111.111に送信する。その上でRouterが111.111.111.111に戻ってきた通信を、ＮＡＴテーブルを元に192.168.1.10に送り届ける。

これが、概ねの動作概要になるのですが、複数端末が同じブログサイトにアクセスにきた場合、どうでしょうか？下記の様な構図ができあがりますね。

ＰＣ1———————–>  Ruter 111.111.111.111 -> Blog Server

Android1 ——————>

Android2 ——————>

iPhone1 ——————->

iPhone2 ——————->

Blogサーバからしてみると、同じIPに何度も同じパケットを送っていると思い出す訳であって、そこでふと考える訳です。あれ？もうさっき送ってきたパケットより古い物はもうパケット送んなくていいや！って思い出してパケットは破棄する訳です。

もうお分かりですか？

Linuxには、tcp_tw_recycleという仕組みが用意されています。

そのそも、それってなによ？って話なのですが、TIME_WAIT状態のソケットを高速に再利用するためのLinuxカーネル特 有の仕組という事らしいです。

こいつを有効にした時、同じグローバルIPからの同時に接続した時、TCPパケットにタイムスタンプ情報が入っている場合（Android・iPhone共に付加して送っているそうです）、同 時にパケットを送ると、古いタイムスタンプの方のパケットが破棄されます。

不可解だった、一度接続出来なくなると、もうずーっと出来ないのは、いつまでたっても端末は同じ速度で時間が過ぎて行きます。Android1にしてもiPhone1にしても、同じ1秒は1秒なので、それが逆転する事はありません。よって、接続出来る場合は、ずーっと接続出来るし、接続出来ない端末はもう接続出来ないんです。

パラメーター変更したら良いじゃん

じゃあ！このパラメーターを変更すれば良いじゃん！そうなんです。とっととやってしまいましょう。
CentOS7だと下記のコマンドを打つと出来るんですよ。できるんでよねぇ・・・。

root権限がないと出来ないって！？いや、このユーザrootだしな・・・。そして、悟ったんです。このスーパーバイザー的なアカウントじゃないとパラメーターいじれないんじゃ！？

そうなんです。このブログサーバVPSを借りて居るので、VPSのホストサーバの設定に引きずられるんですよ。この仮想化ソリューションでは、もう絶対にいじれない神の領域なんです。という事で、replaceする事にしました。思い立った時が、replaceのタイミングなんで、とっととやってしまいましょう。

replaceを開始

ちょうど、ひな形のスナップショットを作成するチャンスだったので、監視エージェントとかjenkinsスレーブとか全部入れてひな形化して、スナップショットとった後でブログサーバに設定する事にしました。

WordPressのデータをtarで圧縮してローカルPCにダウンロード。mariaDBの設定全部まるっと、dumpとってローカルPCにダウンロードして、該当サーバへ移設する。必要なPackageを入れてWebサーバに仕立てる。dumpを戻したり、zabbixの個別設定をしたりして、昨日2時間くらいで別のサーバで稼働させてDNSを書き換える。間もなく24時間くらいが経過して、やっとアクセスは新サーバの方に移りつつある。完全に通信が止まったらインスタンス削除して完了。

番外編

通信回線の業者に寄って、グローバルIPを付与しない業者も時折あります。なので、NAT環境のでかい版と考えてもらうと、そこの通信業者で私のブログを見てくれている方がいらっしゃいましたら、同様に起動時間の古い方は繋がらないという事が想定されます。また、ドコモもグローバルIPはふるものの、複数端末にグローバルIPを振る方式を採用している為、同様の事象になる可能性があります。
よって、1つでも、2つでもアクセスしようとされた方が接続出来ない状況を避ける為、replaceと相成りました。

1つ、エラーログに大量にログを書かれているのは認識していたのですが、それも先ほど1つのPackageがインストールされていない事により発生している事と、php.iniを移行するのすっかり忘れてて、php.iniがありませんでした・・・org それでも、普通に動くんですねｗ全部デフォルトって事だったんでしょう。日本語の処理が上手く出来ないってエラーだったので、すぐ気がついたので良かったですけどね。

The post こんなに速くreplaceするとは思わなかった first appeared on ～下町物語～.