ただのにっき。

ただつらつらと日記が書かれていくようです。

WN-AX1167GRをにAterm WG1200HP3に入れ替えてIPv6を使ってみた

先日、WN-AX1167GRでIPv6を使っていたら再起動に直面することを書いたが、やや頻繁に再起動するようになったような気がするので、さくっとリプレースすることにした。

買ってきたのは、NECの「Aterm WG1200HP3」。自宅のフレッツはIPoEに対応しているので、設定を「IPv6オプション」にすれば、後は機器を普通に入れ替えればよさそうだ。で、WG1200HP3の管理画面をのぞきながら、接続される様子をみていたが、接続時に何かを確認しながら接続しているというか、すんなり接続している感じではなさそう。

そういえば、biglobeがIPoEで提供しているIPv6サービスはいつの間にかリプレースされていて、旧サービスは日本ネットワークイネーブラーが提供していたが、新サービスの方はIPoEをbiglobeが自ら提供するようになったらしく。IPoEのサービスも日本ネットワークイネーブラーだけでなく、他の事業者も提供するようになったことで、サービス毎に接続シーケンスなどがビミョーに違うのかもしれない。もし、そういうことなら…その辺の差異を機器で吸収するのはあまり賢いやり方ではないような気がするんだけどな…いやはや。

しばらく使ってみたが、WG1200HP3は再起動してなさそうなので、WN-AX1167GRの頃よりも安定性は増したような気がする。

さくらのクラウドの物理サーバあたりが不調だった

さくらのクラウドで動いているインスタンスの1台がCPU使用率のディスクI/Oが徐々に増えていって、サーバのレスポンスが徐々に遅くなっていった。最終的には、ちょっとしたコマンド(例えば、lsとか)を実行しても、結果かが帰ってくるのに一呼吸かかるようになってしまっていた。まぁまぁな性能劣化だなぁ…と。

仕方ないので、ロードバランサの振り分け対象から切り離して様子を見てみることにしたが、改善する様子もない。試しにということで、さくらのクラウドのコントロールパネルから該当インスタンスを停止させようとしたが、なかなか止まらない…ので、仕方なく強制停止をかけた。

さくらのクラウドは、インスタンスを停止させて起動すると、違う物理サーバの上で起動する(仕様としてそうなっているのか、たまたまそうなのかはわからないけど…とりあえず物理サーバが変わることは多いような気がする)ので、それを試して、別の物理サーバの上で動き始めたらあっさりと性能は元に戻った。ということは、ストレージサーバが輻輳していたわけではなさそうなので、物理サーバのNICの障害とか、NICから先、ストレージまでのネットワークの輻輳とか、その辺が原因ってところだろうか。

ただ、そのあたりの監視は、クラウドベンダーのお仕事のような気もするんだけど、今のところ障害の報告は出ていなかった。物理ホストを変えて元に戻ったことだし、一件落着ではあるんだけど…。

はてなダイアリーが終了するとのことで

はてなダイアリーがサービスを終了するらしい。実際に終了するのは2019年のことだが、発表と同時にはてなブログへの移行が殺到したようで、移行処理用のサーバーリソースが枯渇して、一時的にそのサービスは利用できなくなっていた。まぁ、機能追加や改善がなされるはてなブログと、維持されるだけのはてなダイアリーって位置付けは明らかでもやもやしてたはてなダイアリーユーザーは少なくなかったんだろう。

なくなるサービスに記事を置いておいてもしょうがない(…駄記事の山だけど…)ので、はてなダイアリーでMovableType形式でエクスポートして、このサイトにインポートしてみた。

とりあえず、はてなダイアリーから移行した記事にはタグを付けてみたので、以下のリンクから見ることができる。

はてなダイアリーから移行した記事

しかし、WordPress登場以前に勢いのあったMovableTypeが互換性のあるデータフォーマットとして生き残ってるのはスゴいというか何というか…。

t3インスタンスがリリースされてた。

AWSのブログを眺めていたら、EC2のt2インスタンスの後継インスタンスのt3インスタンスがリリースされたらしい。

記事はこちら→New T3 Instances – Burstable, Cost-Effective Performance

ハイパーバイザはC5インスタンスやM5インスタンスから採用されている、Nitroが採用されているそうだし、vCPUの数はt2インスタンスの場合は1個からだったけど、t3.nanoから2になっているようで。あと、t2インスタンスのネットワークのスループットはlowとかなんとなくぼんやりとした表記になっていたけれど。t3インスタンスのネットワーク周りについては

T3 instances are powered by the Nitro system. In addition to CPU bursting, they support network and EBS bursting, giving you access to additional throughput when you need it. Network traffic can burst to 5 Gbps for all instance sizes; EBS bursting ranges from 1.5 Gbps to 2.05 Gbps depending on the size of the instance, with corresponding bursts for EBS IOPS.

って記載になっていた。一応、ネットワークは5Gbpsまではバーストするみたいだし、EBS方面も1.5Gbpsから2.05Gbpsまではバーストするとのこと。まぁ、細かいところはともかく…(汗)、常に負荷がかかっているようなシステムでもなければ、バーストできる恩恵がありそうな気がするなー。

t3インスタンスは東京リージョンでも使えることだし、リザーブドインスタンスの有効期限が切れたt2インスタンスはt3インスタンスに切り替えることにしようかなと。

DigitalOceanからのメールが来ない

久々に(たぶん、2年とか3年ぶり)DigitalOceanでも使ってみるかと思って、アカウントを引っ張り出してアクセスしてみたら、いつの間にか二段階認証が導入されていて、メールで送った6桁の数字を入力せよとのこと…。ただ、待てどもメールは来ず。うーむ。

また、別の機会に同じことを試してみたら、メールが届いたので管理画面にアクセスできた。以前の管理画面とはかなり変わっていて、なかなか興味深い思いがした。で、そのまま、登録してあるメールアドレスを変更しようとしたら、新しいメールが使えるものかどうかの確認のためにメールを送ったようだけど、やはりメールは来ず…。うーむ。

まぁ、メールアドレスの変更を後回しにしてdropletを起動してみたんだけど、ルートパスワードが書かれているはずのメールが来ず、さらにルートパスワードをリセットしてみてもメールは来ず。うーむ、うーむ。

いや、これ、フツーに起動したdropletにアクセスできないんじゃないかと(汗)

dropletの起動時にSSHの鍵を登録してあったはずなので、公開鍵認証でアクセスしてみたら、ルートパスワードの変更だけができそうだったのでとりあえずパスワードを変えてみた。んで、VNCのコンソールから変更後のパスワードでrootユーザーでログインしようとしたら、ハネられた。なかなか厳しいな。

この件をDigitalOceanのサポートに英語で問い合わせする手間を考えると、linodeでインスタンスを立てるのが楽だなってことで、dropletはdestroy。

うーむ、近頃のメールは送られて受け取れるまでに様々な障害がありそうだから、問題の切り分けは簡単ではないけれど、目下、次々とSPAMが届いてる現状を鑑みると、受信側でDigitalOceanからのメールを的確に打ち落としてる現状って想像しづらいけどなぁ(実は、メールサーバーとして使ってるレンサバ屋さんのどこかで怪しいメールを撃ち落としてて、実際に送られてきてるSPAMは目の前にあるものよりもずっと多くて…ってのはあり得るかしれないけど)

どうしたもんかねぇ…いやはや。

« Older posts