ただつらつらと日記が書かれていくようです。
久々にLinodeのステータスページを眺めていたら、Tokyo2リージョンのコアルーターのメンテナンス情報が出ていたのを見つけた。
On Thursday, June 15th, 2017 we will be performing a code upgrade on our core network devices in our Tokyo 2 (Shinagawa, SHG1) data center.
Tokyo2として記載されているものの、括弧書きで「Shinagawa, SHG1」と書かれている。ってことは、品川にあるデータセンターに入っているんだろうな、ってことで。品川のデータセンターか…ってことは…といろいろと妄想してみたが、品川区だとすると割といろいろありそうな気がするな(笑)
たまには、Azureでも試用してみようかと思って、Microsoftアカウント…というか、outlook.jpなメールアドレスを作成して、サインアップしたんだが、Azureの管理画面が重い。Office365のポータルもそうなんだけど、Microsoftのサービスの管理画面のレスポンスが遅い時のどうしようもない感じ、それも、とてもWebのレスポンスじゃないくらいのながーい待ち時間はなんなんだろうか。うーむ、AWSの方がいいな。
しかも、試用用のサブスクリプションを作成しようとしら、いきなりエラー。試用サブスクリプションもないのに、いきなりサポートのお世話になることになった。この時点で試用する気分じゃなくなって来てるんだけど、どうしたものか、いやはや。
追記：
とりあえず、サポートに投げてみたら電話がかかってきた。しかも、何回も取れなかったのに、諦めることなくかけてくれて、やっと出たら、とても丁寧な対応をいただいた。やはり、まー、この辺の電話サポートって辺りがAWSなんかとの差別化のための施策なんだろうなぁと思ってみたり。
GoogleBookmarksにとあるサイトのURLを入れていて、アクセスしようとしたらリダイレクトの嵐…。うーむ、Googleにはログインしてあるのになんか変だなー。
めまぐるしく、くるくる変わるURLを眺めていると、sidというパラメータをどうにかしようとしているようで…。というわけで、ブラウザのCookieの管理画面を引っ張り出して、google.comのCookieの中で「SID」ってパラメータがあったので、それを削除。改めて、Google Bookmarksにアクセスすると無事にアクセスできた。なんとなーくバグっぽい動きをしているあたり、最近のGoogleでは珍しい気もするけど、とりあえず回避できたからいいや。
一昔前のRaspberryPi Zeroを引っ張り出してきた。んで、microSDを刺して、さらに、いろんなものをUSB経由で刺してなんとかRaspbian Jessieをインストールして起動することができた。一昔前のUSB Ethernetアダプタ(IOデータの「ETG-US2」。Windows向けのデバイスドライバはWindows10でリリースされてないような感じ。一応、「ASIX AX88178」を使っているとして認識されている)が無事に認識されたところで、IPアドレスを固定したいと思った。
んで、最近のRaspbianでIPアドレスを固定したい場合は、dhcp周りの設定ファイルをいじるってことでいじりはじめたものの一向にIPアドレスが固定されずに、ネットワーク上にいるDHCPサーバからIPを取ってしまう(遠い目)
ふとした瞬間、いじるファイルが間違っていることに気付くまで必死に、/etc/dhcpd.confをいじっていたけど、これはRaspberry PiがDHCPサーバとして動くときの設定ファイル。dhcpクライアントとして動作するときのファイルに固定IPを記載すべきだったのだ。んで、そのファイル名が/etc/dhcpcd.conf。ま、ややこしいといえばややこしいが、違うと言えば確かに違う。dhcpcd.confに設定を追記して再起動したら、無事にIPが固定された。
…いやはや、年中こんなことばかりやってる気がする(遠い目)
ふむ、Tokyo2のサーバはBroadwellなXeonであったか。…ま、実はいろんな世代の物理サーバが混じっていて、たまたまBroadwellなXeonだった可能性は否定しきれないんだけども。
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2697 v4 @ 2.30GHz
stepping : 1
microcode : 0x1
cpu MHz : 2299.994
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 3dnowprefetch fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat
bugs :
bogomips : 4601.65
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
ちょっと前、GoogleがPublic DNSに加えて、Google Public NTPをリリースしていた。しばらくの間はtime1.google.com
などはstratum2のサーバとして動いていたと思うが、さっき確認したら、stratum1のサーバ群になってた。
日本国内のLinuxマシンから、time4.google.comを指定してntpdを動かした時の、ntpq -pの結果がこんな感じ。
remote refid st t when poll reach delay offset jitter
==============================================================================
time4.google.co .GOOG. 1 u 5 64 1 35.928 -0.607 0.000
ソースの「.GOOG.」ってなんだろうって感じではあるが、一応、stratum1らしい。ネットワークのdelay的には、台湾あたりのサーバっぽいなという感じだけど、はてさて。
AWSのEC2のC4インスタンスのリザーブドインスタンスの有効期限を確認していて、ふと思い出したんだけども…。
去年の12月1日の「AWS re:Invent 2016」でSkylakeコアを使ったXeonを搭載したC5インスタンスのリリースが発表されてたはずだけども…。発表から半年近く経過した今でもC5インスタンスがリリースされていない。同時に発表されたF1インスタンス、R4インスタンスやt2.xlargeなどはリリースされているだけどなぁ。
C5インスタンスとC4インスタンスを比較すると、シンプルにHaswellコアのXeonを、SkyLakeコアのXeonでリプレースしただけのように見えなくもないだけに、なんでだろう。
んで、ちょっと調べてみたら、SkylakeなXeonのE5シリーズE7シリーズってまだ出荷されてなかった。で、いつ頃に登場するかってことについては、
2017年のサーバープロセッサ動向・Intel編:
http://cloud.watch.impress.co.jp/docs/column/virtual/1041290.html
って記事に
Xeon E5 v5、Xeon E7 v5のリリーススケジュールは、2016年11月に米国で開催されたSuperComputing 16（SC16）において、2017年中盤と発表された
って書かれていた。まぁ、具体的な日程まではわからないけれど、もうちょっとするとSkylakeなXeonがリリースされそうってことか。ただ、EC2向けのXeonはAWS専用のカスタマイズ品だろうから、一般的なXeonの出荷と比べると、AWS向けの出荷はもう少し遅くなるのかもしれない。
ま、とりあえずC4インスタンスのリザーブドインスタンスを買っとくか。
追記：
2018年2月に、C5インスタンスが利用可能なリージョンが拡大されたけれど…。
東京リージョン含まれず…orz
古い自作PCにWindows7Proでもインストールしておいて、リモートデスクトップで使おうと思って、粛々とインストールを完了。
とりあえず、LAN越しにアクセスできるようにIPアドレスを固定して、Windows7側でリモートデスクトップの接続を許可。はてさて、うまくいくか不安になりながらMacでリモートデスクトップクライアントを起動。…無事に接続完了。
まー、これでMacからWindows7を使えるようになって、多少便利になるかなーと思って、しばらく放っておいたら、リモートデスクトップがつながらなくなっていた。しかも、ケースの電源ランプは何秒に一回か点灯しては消えるという状態だし、電源ランプが点いたタイミングでケースファンが少し回って止まるということを繰り返していた。
このPC、マザーボードがIntelのDH57JGだったから、かなり古い。インストールしたばかりなのに壊れたかーと思って遠い目になった。しかも、電源ボタン長押しも効かない…。仕方ないので電源ケーブルを引っこ抜き、ため息をひとつ。
ま、試しにってことで、再びケーブルをつないで電源をon。…うっかり普通に起動してしまった。
じゃ、さっきのアレはなんだったんだろうと思って、しばらく放置してみたら、また息も絶え絶えな状況に陥って電源ケーブルを引っこ抜くというのを2回繰り返して、ふと気づいた。このPC、起動して30分近く経ったら前後不覚になってないか…と。
…というわけで、このPCは起動して30分近く経って、律儀にスリープに入ろうとするものの、BIOSか何かのバグを踏んでるのか、スリープに入れずに前後不覚に陥ってるんじゃないかと仮説を立てて、そっとスリープに入らないように設定したら、前後不覚状況を回避できた。
いやはや、古いPCではあるけど、スリープできないってのもなかなかアレだなーと。とりあえずハードウェア障害ではないから、一安心。…でも、いつまで動いてくれるんだろうか…(遠い目)
このブログで使ってるドメイン向けに安いSSL証明書がいつの間にか失効してた…。なんか更新のお知らせのメールが来てたような気がするけど、更新忘れてた(大汗)
SSL証明書を更新しなきゃと思ったけど、このサーバーにはcertbotをインストールしてあるし、systemdで更新プロセスも動いてることだし…ということでLet’s EncryptなSSL証明書を取得して入れ替えた。
自動更新の仕組みさえ、ちゃんと動いてるなら、expireすることもないし…意外と悪くないかもしれない。
先日、文化庁のWebサイトが見られなくなってるのがネットで話題になっていた。ネットで話題になるってことは、誰も文化庁のWebサイトでメンテナンスをやっているという情報を見つけられなかったわけで、まぁ、メンテナンスでダウンするWebサイトにしかメンテナンスのお知らせが出てなかったってことだろうか。
まぁ、文化庁は文部科学省の外局なんだし、文部科学省のWebサイトで文化庁のWebサイトのメンテナンス情報を出しておくとか、なにかできなかったんだろうかと思う。それに、内閣官房とか総務省あたりが、官公庁のWebサイトのステータスを監視、お知らせするためのWeb(正常に稼働してます、メンテやってます、DDoS食らってますとか)を用意してても罰は当たらないような気もするが、そこは縦割りの権化みたいな世界だと、そうもいかないんだろう。
さて、そんな文化庁のWebサイトだが、気がついたら復旧してた。トップページの上部に、赤い文字でフォントサイズ大きめに「文化庁ホームページメンテナンスのお知らせ」というリンクが表示されていて、そのリンクの先には、こんな情報。まぁ、年末年始はメンテナンスやりますよってことがお知らせされていた。
平成28年12月28日（水）18:15から平成29年1月3日（火）23:00まで
（メンテナンス作業状況により，終了時間が前後する可能性があります。）
落ちてたサイトが復帰したってことは、メンテナンスの一部は完了したわけで、何が変わったんだろうと思ってnetcraftで調べてみると、メンテナンス以前(といっても、2016年6月の記録だが)はWindowsのIISがWebサーバで、その前にCitrixのNetscalerが控えていたような感じだが、メンテナンス完了後にはクラウド型WAFの「Scutum」が導入されたようだし、インターネットから見えるIPアドレスもIIJのもの(ってことは、ScutumはIIJのクラウドで動いてるってことか)に変わっていた。今回のメンテナンスの一部は、WAFの導入だったんだろう。
しかし、クラウド型WAFを導入するとなると、確かにDNSをいじる必要が出てくるとは言え、ネットがざわざわするくらいの期間、サイトを見えなくする必要があったのかはよくわかんない。例えば、DNSはWAFに向けつつも、DNSのキャッシュがなかなか更新されない人向けに、直接のアクセスをしばらくの間は許可しておいて、さすがにもういいだろうってタイミングで直接のアクセスを遮断するってのも移行パターンとしてはありかもしれないし。
ふと、文化庁のWebサイトくらいでしか、メンテのお知らせが出てなかったことを思い出すと、実はメンテナンス計画上は停止なしか、止まっても、わずかな期間で済むはずだったにも関わらず、メンテナンス中に予期せぬことが起こって、想定外に止まっちゃったんじゃないかという下衆の勘繰りをしてみたが、実際はどうなんだろうか(笑)
© 2024 ただのにっき。
Theme by Anders Noren — 上へ ↑