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

カテゴリー: ITめいたこと (4ページ目 (31ページ中))

さくらインターネットの東京リージョンのVPSの在庫がなくなっていた。

先日、仕事で、さくらのVPSを使ってサーバを構築しようとしていたら…。東京リージョンのVPSがいずれのサイズでも「在庫なし」になっていた。本当は東京リージョンで構築しようと思っていたんだけど。まぁ、大阪でもいいんだけどさ…。

そういえば、大阪リージョンでのVPSの在庫が復活したときに、東京、大阪、石狩の3拠点でDRできますってのをウリにしてたじゃーんって無駄絡みしたくなるのは人情ってヤツだろうか。東京リージョンのVPSではハードウェアの老朽化対応メンテナンスを実施していて、いろいろと整理してそうで、それと関係あるんだろうか。

F5がnginxを買収したそうで。

どうやら、F5 Networks,Inc.がnginxを買収したらしく。

F5 Acquires NGINX to Bridge NetOps & DevOps, Providing Customers with Consistent Application Services Across Every Environment

そういえば、(オープンソースなソフトウェアルータのVyattaを開発してた)Vyatta社を買収したbrocadeがVyattaのオープンソース版の公開を中止して、コミュニティーがフォークしたVyosが生まれたことを思い出したりするけれど…(いつの間にか、brocadeがAT&TにVyattaを売却してたらしく、今ではAT&Tの子会社になってるそうだ)

はてさて。

Auroraでt3インスタンスをサポートとな

どうやら、そういうことらしい。

Amazon RDS for MySQL と Amazon RDS for MariaDB が T3 インスタンスタイプをサポート開始

Amazon Relational Database Service (RDS) for MySQL および Amazon RDS for MariaDB を使用する際に、T3 インスタンスタイプを起動できるようになりました。Amazon EC2 T3 インスタンスは次世代の汎用バーストインスタンスタイプで、ベースラインレベルの CPU パフォーマンスとともに、必要なときにいつでも無期限で CPU 使用率をバーストできる機能を備えています。

EC2に新しいインスタンスタイプがリリースされて、近々、RDSでも新しいインスタンスタイプが使えるようになるんだろうなぁ…と思いつつ、目前に迫ったリザーブドインスタンスの有効期限を睨みながら「ちっ」とか思いながら旧世代のインスタンスでリザーブドインスタンスを買っちゃった翌週くらいに、新しいインスタンスタイプがRDSで使えるようになって遠い目になるのは何回目だろうか…。いやはや。

とはいえ…。

>AWSの中の人
Auroraでt3インスタンスを使えるようにしてくれてありがとう。

このブログをAWSのA1.mediumインスタンスに移行してみた。

このブログを動かしているサーバを、AWSのOregonリージョンのA1.mediumインスタンスで建ててみた。A1インスタンスというと、AWSの子会社が開発した汎用ワークロード向けARMプロセッサ(AWS Graviton Processors)で動いているサーバで、一瞬、大丈夫かなぁと思ったものの、実際にPHPやRedisなどをビルドしてみると普通にビルドできたし、今のところ、普通に動いているように見える。

まぁ、実際のところ、A1.mediumインスタンスであれば、月額1,000円ちょっとで動かせてサーバのメモリが2GB確保されているのはかなりお得なんじゃないだろうか。もし、仮に多少、CPUがショボかったとしても、私のブログ群のように対してトラフィックがないサイトにとってはCPUリソースが枯渇するなんてことはほぼない訳だし、うっかりメモリが枯渇しちゃってOOM Killerが猛威を振るうことの方が恐ろしいような気もする。むしろ、MySQLやRedisにたっぷりメモリを使わせる方が速くなったりしないだろうか…ま、時と場合によるか。

まぁ、ただ、aarch64アーキテクチャ向けにビルドしてある、新しめ(=10.x系)のMySQL/MariaDBのがAmazon Linux2のyumレポジトリになくて、仕方なくMariaDB5.5で動かしているけれども、WordPressなら大した差にはならないんじゃないかと信じている(そういえば、FULLTEXTインデックスに対応してなくて前のサーバからmysqldumpで引っ張り出したSQLがコケた時はちょっと遠い目になったくらいか)

ソフトバンクのLTEネットワーク障害の原因は、EricssonのvMMEだったようで。

今日はソフトバンクのLTE網が割と長い時間にわたって障害を起こしてたなぁ…って印象だったけど、どうやら、ソフトバンクの障害の原因は、LTEネットワークを構成するノード群の中のMME(Mobility Management Entity)と呼ばれる装置だったようで、2016年2月に出されたEricssonのプレスリリースによれば、ソフトバンクはEricssonが提供するvMMEを導入していて、このvMMEが障害を起こしたことが原因だったらしく。

そして、このMMEと呼ばれるノードは、DoCoMoのTechnology Reportsによると

MMEは,位置登録,ページング、ハンドオーバなどの移動制御、およびベアラ確立/削除を行う

という役割を果たしているとのことなので、これが止まってしまうとネットワークが全く機能しなくなるくらいに重要なノードであろうことは想像に難くない。

で、このvMMEは仮想環境で動いている(vMMEのVは「Virtual」)ようで、ソフトバンクのLTE網に障害をもたらしたものと同じソフトウェアがイギリスのO2ってキャリアでも使われていて、イギリスのO2でも大規模な障害に繋がってしまったようで、なんともこれは…と。

一応、イギリスのfinancial timesが記事にしてた。
Ericsson software problem leads to global smartphone outage

追記:
ITmediaも記事を公開してました。
ソフトバンク通信障害はエリクソン製設備が原因か Financial Times報道

追記 その2:
あと、Reutersの記事によるとEricssonの広報も、顧客(=通信キャリア)と問題解決に取り組んでいることを認めたみたいですな。

“We are aware of the issue and are working together with our customers to solve it as soon as possible,” an Ericsson spokesman said.

追記 その3:
ケータイWatchの記事によれば、2016年当時、ドコモはEricsson、Cisco、NECのマルチベンダーで導入した一方、ソフトバンクはEricssonのシングルベンダーで導入していたそうだ(ただし、今回の障害の原因となったMMEに限定した話ではなさそう)

マルチベンダーでの導入は今回のような事象にはメリットがあるかもしれないけれど、ベンダーの違いをうまく吸収しながら安定運用を目指すとなると、運用の複雑さや、機器にかかるコストなんかはデメリットになりそうなので、マルチベンダーで導入するのが正解といったシンプルな話ではなさそうな気はする。

追記 その4:
ソフトバンクがお詫び文のPDFを公開。この文書によると、原因について

2018年12月6日(木)午後1時39分ごろ、全国のお客さまをカバーする、東京センターおよび大阪センターに配置してある、エリクソン社製パケット交換機全台数で、同社ソフトウエアに異常が発生しました。なお、同ソフトウエアは9カ月前から運用しており、同ソフトウエアによる異常は、エリクソン社製の通信設備を使用する海外(11カ国)の通信事業者においても、ほぼ同じ時刻に同様に発生していると、エリクソン社から報告を受けています。ソフトウエアを旧バージョンに戻すことで、復旧を行いました。

との記載があった。9ヶ月前から使っていたソフトが、時限爆弾のように突然障害を起こすなんてなかなかの恐怖だなぁ…いやはや。

追記 その5:
Ericssonがプレスリリースを出していた。それによると、障害が起きた顧客(SoftBankやO2など)が使っていたソフトウェアのバージョンには、有効期限切れの証明書が使われていたことが障害の原因となったとのこと。

An initial root cause analysis indicates that the main issue was an expired certificate in the software versions installed with these customers.

確か、ソフトバンクのプレスリリースではアプリケーションを切り戻して復旧させたと書いてあったんだけど、9ヶ月前に運用を始めたバージョンには有効期限切れの証明書が使われていて、切り戻した(=現在、利用している)、さらに古いバージョンには有効な証明書が入っていたということはリリース時の手違いか何かで古い証明書を入れちゃったってことだろうか。

今回の大規模障害のせいで、ソフトバンクは上場直前のこのタイミングで総務省に怒られることは間違いない(そういえば、指針に沿わない不適正な端末購入補助の件で既に総務省に怒られているのに、それに加えて…ってのはキツい)だけに、ネットワークベンダー起因のトラブルで自社のネットワークが大規模にダウンするのはどうなのよってことになったりしないもんだろうかって気もしないでもないけれど、はてさて、どうなることやら。

参考リンク:

php.netのミラーサイトがなんだか激減してた。

久々にphp.netにアクセスしてphpのソースをダウンロードしようとしたら、ミラーサイトの数が激減していることに気がついた。

php.netのミラーサイトが減少…

イランに、台湾に、アメリカに…Unknown。確か、日本にもミラーサイトがあったはずだし、アメリカのミラーサイトは2つだか、3つだかあったような気がするんだけどなぁ。PHPの終わりの始まりじゃなきゃいいけれども…。

追記:
改めて確認したら、ミラーサイトが復帰してました。

更新:Amazon LightsailでAmazonLinux2が使えるようになっていた。

EC2向けにAmazonLinux2が使えるようになって久しいので、そろそろAmazon Lightsailで動かしているインスタンスをAmazonLinux2に入れ替えようかと思って、とりあえず1個のインスタンスを落として、AmazonLinux2で新しいインスタンスを起動して…と思って作業していたら…。

Lightsailのインスタンスの起動画面のOSの選択肢の中に、AmazonLinux2がない…。うーむ。あー。マジかー。そのうち、対応するんだろうとは思うけれど、まだなのかそうなのか…。一応、U.S.のリージョンでもAmazonLinux2は選択肢に出てこないので、リージョン間の展開待ちって感じでもないようだ。

追記:
AmazonLinux2がLightsailで使えないのは相変わらずだけど、AmazonLinux2のFAQを眺めていたら、こんなことが書かれていた。

EC2などでは、既に後継バージョンが使えるようになってるのに、Lightsailでは2020年6月までしかサポートされない旧版しか使えないってのはなかなかグッとくるんだけどなぁ。AmazonLinux2への移行がさくっとできちゃうなら問題じゃないけど、そうではないだろうから、うっかり、LightsailでAmazon Linuxを使ったサーバーを構築しちゃったら、早々に再構築するハメになりそうだなぁ。いやはや。

Q:AWS では今後も Amazon Linux AMI のサポートを継続しますか?

はい。Amazon Linux 2 への移行を促進するために、AWS では 2020 年 6 月 30 日まで、Amazon Linux の最新バージョンに対するセキュリティ更新とコンテナイメージの提供を継続します。

追記(2020年12月1日):久しぶりにLightsailの管理画面にアクセスして、インスタンスを起動する際の画面を確認してみたら、いつの間にかAmazon LightsailでAmazon Linux 2を選択できるようになっていた!

Amazon LightsailでAmazon Linux2が使えるようになった。

Amazon LightsailでAmazon Linux2が使えるようになった。

Nexus 5xにmineoのソフトバンクSIMを入れてテザリングしてみた。

まぁ…結果は見えていた話ではあるんだけど。

以前、ドコモが投げ売り(具体的には、ドコモオンラインショップで、一括648円)していたNexus5xを何となく買ってみたんだけど、特にこれといった使い道もなく余らせていた。まぁ、Nexus5xなら、他キャリアのMVNOのSIMを刺すこともあるだろうと思ってさくっとSIMロックを外してあった。

で、mineoがソフトバンクのSIMも扱い始めたので、とりあえず買ってみてNexus5xに刺してみたら、フツーにLTEに接続できたけど、テザリングしようとするとエラーが出た。

mineoの動作確認済み端末一覧を見てみても、Nexus5xはテザリング不可になっている訳だけども(遠い目)ただ、その一覧には「Y!mobileブランド端末」として書かれているので、ドコモ販売のSIMロック解除だと、もしかして…と思ったがダメだった。

テザリング開始時のエラーが、ソフトバンクのテザリングオプションの規約への同意を求める(…同意しても、結果として接続できない)ものであることからして、ソフトバンク網でテザリングをしようとすると、何か別のアプリケーションが起動するように、Nexus5xのROMが設定されているって雰囲気がする。おそらく、ソフトバンクやYモバが販売した端末には、そういう設定が入っているんだろう。

そして、端末としては、差し込まれたSIMについてはキャリアがソフトバンクであることは見ているだろうけれども、その先のMVNOなのか、本家のソフトバンクもしくはYモバかは見てないので、テザリングをonにしようとすると、特殊なアプリケーションが起動してしまいテザリングが使えないと。

日本国内においては、Nexus5Xはドコモから販売されようが、Yモバから販売されようが、SIMフリーとしてGoogleから販売されようが、ROMのバリエーションとしては同じ(北米版とか…って大枠のくくりはありそうだけど)だろうから、ドコモから買った端末だからって、ソフトバンク向けの制御とは無縁ではないってことなんだろう。

しかし、少し前、ドコモが販売した端末のテザリングにまつわるビミョーな仕様(テザリングしようとするとドコモ専用のAPNに接続を切り替えるのでMVNOのSIMではテザリング不可になる)がアレだなーと思った記憶があるだけに、やっぱりキャリアかソフトバンクだった時の、一旦、テザリングオプションを確認しにいく何かもやっぱりビミョーだと思うんだけど。

まぁ、単なる土管屋になりたくないケータイキャリアがバタバタといろんな土管業から派生した何かに取り組むのはいいとしても、それはきっちり土管業をこなした上での話ではないだろうか。一旦、公共性の高いはずの土管業にビミョーな軸を持ち込まないで欲しいし、公共の福祉の観点から見ても、どさくさに紛れて競争を回避しようとする姿勢が見えたりするとシバかれるべきではないかと思う。まぁ、結果的にそうなってしまうだけなのかもしれないけれど、MVNOのSIMだからってテザリングができない状態にしてしまうのは、早々に是正されるべきだと思う。

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

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

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

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

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

« Older posts Newer posts »