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

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

VPCの中で既存のNICを使ってインスタンスを起動しようとするとpublic IPがもらえない…

EC2のインスタンスを起動するときに、VPCで既に設定してあるNICを使って起動しようとすると、ちょっと前は、そんなNICにもpublic IPが割り当てられてたような気がするんだけど…。さっき、既存のNICを使って起動としたら、以下のようなメッセージが出てきた。

We can no longer assign a public IP address to your instance

The auto-assign public IP address feature for this instance is disabled because you have selected an existing network interface for eth0. Public IPs can only be assigned to new network interfaces for eth0. To re-enable the auto-assign public IP address feature, please select a new network interface for eth0.

既存のNICはVPCのIPアドレスを固定するものだったので、それはそれとして割り当てて、public IPアドレスを付けたい場合は素直にElastic IPを使えってことだろうか。

追記:
ENIのNICを使うとPublic IPが割り当てられずに「…なんでだろう…」と悩み続けていた。VPCの「Auto-assign Public IP」もYesに変更したのになぁ…。で、仕方ないからNATインスタンスでも立てるかと思って、t2.microインスタンスを立ててiptablesの設定もして…最後にVPCの「Route Tables」を更新してインスタンスを起動してみると、Public IPが割り当てられた状態で起動してきた。結局、WebからのVPCの設定変更では変更が反映されなくて、「Auto-assign Public IP」がnoのままで、「Route Tables」を変更したタイミングで「Auto-assign Public IP」がYesに変わったような…なんか妙な感じしかしないけど、とりあえずPublic IPが割り当てられた…。んで、NATインスタンスを落として、VPCの「Route Tables」を元に戻した。

Linodeの「Tokyo2」は品川なのか。

久々に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」と書かれている。ってことは、品川にあるデータセンターに入っているんだろうな、ってことで。品川のデータセンターか…ってことは…といろいろと妄想してみたが、品川区だとすると割といろいろありそうな気がするな(笑)

Microsoft Azureの試用をしようとしたら

たまには、Azureでも試用してみようかと思って、Microsoftアカウント…というか、outlook.jpなメールアドレスを作成して、サインアップしたんだが、Azureの管理画面が重い。Office365のポータルもそうなんだけど、Microsoftのサービスの管理画面のレスポンスが遅い時のどうしようもない感じ、それも、とてもWebのレスポンスじゃないくらいのながーい待ち時間はなんなんだろうか。うーむ、AWSの方がいいな。

しかも、試用用のサブスクリプションを作成しようとしら、いきなりエラー。試用サブスクリプションもないのに、いきなりサポートのお世話になることになった。この時点で試用する気分じゃなくなって来てるんだけど、どうしたものか、いやはや。

追記:
とりあえず、サポートに投げてみたら電話がかかってきた。しかも、何回も取れなかったのに、諦めることなくかけてくれて、やっと出たら、とても丁寧な対応をいただいた。やはり、まー、この辺の電話サポートって辺りがAWSなんかとの差別化のための施策なんだろうなぁと思ってみたり。

GoogleBookmarksでリダイレクトの嵐

GoogleBookmarksにとあるサイトのURLを入れていて、アクセスしようとしたらリダイレクトの嵐…。うーむ、Googleにはログインしてあるのになんか変だなー。

めまぐるしく、くるくる変わるURLを眺めていると、sidというパラメータをどうにかしようとしているようで…。というわけで、ブラウザのCookieの管理画面を引っ張り出して、google.comのCookieの中で「SID」ってパラメータがあったので、それを削除。改めて、Google Bookmarksにアクセスすると無事にアクセスできた。なんとなーくバグっぽい動きをしているあたり、最近のGoogleでは珍しい気もするけど、とりあえず回避できたからいいや。

Raspberry PiのRaspbian JessieでIPを固定できなくて困った。

一昔前の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が固定された。

…いやはや、年中こんなことばかりやってる気がする(遠い目)

LinodeのTokyo2でインスタンスを立ててみたら

ふむ、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 NTPがstratum1になってた。

ちょっと前、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的には、台湾あたりのサーバっぽいなという感じだけど、はてさて。

そういえば、EC2のC5インスタンスって。

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

追記:TokyoリージョンでもC5インスタンスが利用可能になりました。

Windows7のスリープ失敗がまるでハード障害

古い自作PCにWindows7Proでもインストールしておいて、リモートデスクトップで使おうと思って、粛々とインストールを完了。

とりあえず、LAN越しにアクセスできるようにIPアドレスを固定して、Windows7側でリモートデスクトップの接続を許可。はてさて、うまくいくか不安になりながらMacでリモートデスクトップクライアントを起動。…無事に接続完了。

まー、これでMacからWindows7を使えるようになって、多少便利になるかなーと思って、しばらく放っておいたら、リモートデスクトップがつながらなくなっていた。しかも、ケースの電源ランプは何秒に一回か点灯しては消えるという状態だし、電源ランプが点いたタイミングでケースファンが少し回って止まるということを繰り返していた。

このPC、マザーボードがIntelのDH57JGだったから、かなり古い。インストールしたばかりなのに壊れたかーと思って遠い目になった。しかも、電源ボタン長押しも効かない…。仕方ないので電源ケーブルを引っこ抜き、ため息をひとつ。

ま、試しにってことで、再びケーブルをつないで電源をon。…うっかり普通に起動してしまった。

じゃ、さっきのアレはなんだったんだろうと思って、しばらく放置してみたら、また息も絶え絶えな状況に陥って電源ケーブルを引っこ抜くというのを2回繰り返して、ふと気づいた。このPC、起動して30分近く経ったら前後不覚になってないか…と。

…というわけで、このPCは起動して30分近く経って、律儀にスリープに入ろうとするものの、BIOSか何かのバグを踏んでるのか、スリープに入れずに前後不覚に陥ってるんじゃないかと仮説を立てて、そっとスリープに入らないように設定したら、前後不覚状況を回避できた。

いやはや、古いPCではあるけど、スリープできないってのもなかなかアレだなーと。とりあえずハードウェア障害ではないから、一安心。…でも、いつまで動いてくれるんだろうか…(遠い目)

…いつの間にかSSL証明書が失効してたので、Let’s Encrypt

このブログで使ってるドメイン向けに安いSSL証明書がいつの間にか失効してた…。なんか更新のお知らせのメールが来てたような気がするけど、更新忘れてた(大汗)

SSL証明書を更新しなきゃと思ったけど、このサーバーにはcertbotをインストールしてあるし、systemdで更新プロセスも動いてることだし…ということでLet’s EncryptなSSL証明書を取得して入れ替えた。

自動更新の仕組みさえ、ちゃんと動いてるなら、expireすることもないし…意外と悪くないかもしれない。

«過去の 投稿 新しい 投稿 »