ただつらつらと日記が書かれていくようです。
EC2のインスタンスって、デフォルトではNTPサーバについてはntp.orgのサーバがいくつか設定されていて、時刻を同期しようとするとインターネットへのアクセスが必要になっていた。まぁ、たいした通信量じゃないからいいんだけどさ…と思ってたら、re:Invent 2017で「Amazon Time Sync Service」が発表された。
端的には、EC2のNTPクライアント(chronydとか)で以下のIPアドレスにアクセスするように設定すればNTPサーバに同期できるらしい。
169.254.169.123
実際にやってみたら、Stratumは3。でも、ネットワーク的には近いところにあるようで(…って、リンクローカルアドレスだから当然か)他のNTPサーバを設定してあっても、NTPクライアントはAmazon Time Sync ServiceのIPアドレスを同期に使用していた。
C5とM5インスタンスではまだ使えないみたいではあるけれど、これはこれで便利かも(さくらインターネットは、かなり前からNTPサーバが用意してあったけども)
AWSの管理コンソールにアクセスしようとしたら、なんか違和感があった。なんだろうなぁ…と思って、よーく見てみるとAWSのロゴが変わってるようだった。
以前のロゴは、ブロックを積んであるようなデザインの前面に「Amazon Web Services」って書いてあった感じだが、新しいロゴはAmazon
のロゴの下にある、スウォッシュマークのような矢印の上に「AWS」の文字が配置されているようなもの。AWSと略した状態で、十分に市民権を得たってことなんだろうな。新しいロゴは、なんかかわいいような気もするが、どっちかというと前のロゴの方がしっくりくるような気がしたりしなかったり…ま、要するに慣れってことかもしれない。
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」を元に戻した。
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
AWSブログを眺めていたら、EC2のC4インスタンスなど、特定のインスタンスタイプを対象に値下げが行われるらしい。
EC2 値下げ (C4、M4、そしてT2インスタンスで) 東京リージョンも！より：
2016年12月1日からEC2の価格を下げるアナウンスをできることを非常に嬉しく思っています。これで皆さんの年末シーズンがすこし楽しくなることでしょう！我々の技術に対する投資と、規模と長年のキャパシティ管理の経験に基いて、コストを抑えることができることになりましたので、皆さんにお伝えします。
まぁ、私の場合、検証用のサーバはだいたいt2インスタンスで起動しているし、本番用のサーバもC4インスタンスを使っているので、これはありがたい話ではあるんだけど、ちょっと気になることがあった。
そもそも、このブログは、AWSのChief EvangelistのJeff Barrさんが英語で書いたモノを、日本のアマゾンウェブサービスジャパン株式会社の中の人が日本語に訳しているモノのはず。しかし、今回の記事は微妙に原文と日本語訳の内容が異なる点があった。
そもそも英語で書かれた記事の方では、C4インスタンスの値下げ対象について、こういう書き方になっている。
C4 – Reductions of up to 5% in US East (Northern Virginia) and EU (Ireland) and 20% in Asia Pacific (Mumbai) and Asia Pacific (Singapore).
んで、これを日本語訳するとこうなっている。
C4 – アメリカ東部(北部バージニア)とEU(アイルランド)とアジア太平洋(東京)で5%削減、アジア太平洋(ムンバイ)とアジア太平洋(シンガポール)では20%削減
原文の方では東京に関する記載がないにも関わらず、日本語訳の方には東京に関する記載があるという状況だ。
もちろん、冒頭に「For example:」と記載されているから全てを記載しているわけではないだろうし、実際の値下げが行われると料金表も改訂されるから、そこで全てが明らかになるんだろうとは思うけれど。ぱっと見た感じ、東京リージョンのEC2は本当に値下げされるんだろうか、とちょっと不安になった。
例えばだが、原文の日本語訳は日本語訳として記載してもらって、日本語版を読んでいる人達の中には東京リージョンを使っている人が多いので、東京リージョンの値下げのことも紹介したいというのであれば、日本語訳の後に、訳者による追記のような形で、東京リージョンでも値下げ予定があることを記載してもらえると少しは安心できるような気がする。
追記：
改めて、該当の記事を確認してみたら、原文には記載がないものの、東京リージョンにおいても値下げが行われる旨が追記されていた。追記、ありがとうございました＞AWSのなかの人。
※訳注: 原文には東京リージョンへの言及が特別にありませんが、今回の値下げは全てのリージョンが対象のため、東京リージョンの価格変更情報も追記しています。
商用環境のAmazon Linuxのアップデートを適用した翌日の今日、Amazon Linux AMI 2016.09がリリースされた…。まぁ、リリースされたてのものにアップデートするかどうかはあるとしても…むむむ。
Amazon Linux AMI 2016.09 Release Notes
リリースノートをざっと読んでみたが、BTRFSで管理されているソフトウェアRAIDを使っていると、起動時に自動マウントされないってあたりはなかなか切ないけれど、BTRFSは使ってないから、まぁ、いっか。んで、後は、Linuxカーネルが4.4.19になった(追記：後で調べて見たら、2016.03も４．４．１９だった。あれ？)ってのも、まぁ、いっか。yumレポジトリに入ってるPHPが7も使えるようになったようで。これも、まぁ、いっか。
ちょっと興味深いのは、ブート時の性能を改善したようで、SSHできるようになるまでの時間が短縮されたようで。簡単なベンチマークが載ってたけど、c4.largeインスタンスで2016.03と2016.09で比較すると7秒くらい早く起動するようになったらしい。まぁ、たいしたことじゃないけど、再起動かけた後、ちょっとドキドキしながら待つ時間が短くなるのは悪いことではないと思う。
あと、nginxやPHPが新しいバージョンに入れ替えられる中で、jdk1.6.0やtomcat6が削除されたようで。
昨日、やったばかりではあるけれど、そのうち、またスケジュール組んでアップデートの準備をするかな…(遠い目)
とあるサーバのバックアップデータをS3に格納しておこうと思って、サーバにAWS CLIをインストールした。
データをtarで固めて、「aws s3 cp –region ap-northeast-1 test.gz s3://(バケット名)/」みたいな感じでアップロードしようとしたら無慈悲にも下記のようなエラーメッセージが出て、何回もアップロードに失敗した。どうやら、大きいファイルは分割してアップロードするが、その欠片のアップロードがどこかでコケるらしい。数GBくらいはある大きなデータではあるけれど、S3のファイルサイズ制限はテラバイトオーダーなので、数GBくらいのfairは問題なくアップロード出来るはずだ。
upload failed: ./test.gz to s3://(バケット名)/test.gz
Unable to parse response (syntax error: line 1, column 0), invalid XML received:
x-amz-id-2: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
x-amz-request-id: XXXXXXXXXXXXXXXXXX
Date: Tue, 15 Sep 2015 10:35:40 GMT
ETag: “XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx”
x-amz-storage-class: REDUCED_REDUNDANCY
Content-Length: 0
Server: AmazonS3
エラーをざっくりと読む限りは、S3のサーバから不正なXMLが返っていてParseに失敗しているけれど、AWS CLIを使っているだけの私にとっては謎すぎて手が出ないので、途方に暮れていた。ふと気付いたのは、他の環境では同じくらいのサイズのファイルのアップロードに成功していて、AWS CLIのバージョンが1.8.2であること。…というわけで、失敗している環境のAWS CLIのバージョンを戻して、成功している環境と同じバージョンにしてみた。
# pip install awscli==1.8.2
バージョンを戻してみたところ、問題なくアップロードできてしまった。AWS CLIのリリースノートを見てみたけど、それっぽい記述もなくて…なかなか悩ましい。
ちょっとt2.microインスタンスを起動してみたら、「Intel(R) Xeon(R) CPU E5-2676 v3」でインスタンスが起動してきた。これって、m4インスタンスに導入されたAWS特注のCPUじゃなかったっけ…。
うーむ、t2インスタンスって、いろんな物理サーバで起動するんだろうか、ということで。
[ec2-user@ip-XX-XX-XX-XX ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
stepping : 2
microcode : 0x25
cpu MHz : 2394.542
cache size : 30720 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 ht syscall nx lm constant_tsc rep_good nopl xtopology 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 xsaveopt fsgsbase bmi1 avx2 smep bmi2 erms invpcid
bogomips : 4789.08
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
そろそろ、ElasitCacheのredisサーバをセットアップしようと思って、AWSのWebコンソールを開いた。そんなに大規模なキャッシュとして使うわけでもないので、t2.microインスタンスくらいでいいかなぁと思ったら、multi-AZのチェックボックスを入れるとt2インスタンスが候補から消えるという…(汗)
さすがに、Webコンソールのバグではないだろうと言うことで、調べてみたら、AWSブログにしっかり書いてあった。
【AWS発表】ElastiCacheでもT2インスタンスタイプを利用可能に：
T2インスタンスはAmazon Virtual Private Cloud内でのみサポートされています。 Redisのバックアップおよびリストア機能とRedis AOFは現在のところT2インスタンスではご利用いただけません。 通常の方法(コマンドライン、API、CloudFormation、コンソール)で起動することが出来ます。
おっと、マジかー(汗)
しかし、t2インスタンスがMulti-AZ(「バックアップおよびリストア機能」とMulti-AZは同じ意味なんだろうか…)とかAOFが使えないのって、t2インスタンスがephemeralディスクを持っていないこと(m1インスタンスとかって、HDDだけど、一応、ephemeralディスクを持ってるし)と関係があるのかなぁ…と妄想してみる。リカバリーする際にephemeralディスクを使ったりするんじゃないだろうか。もしそうだとすると、t2インスタンスでこれらの機能を使おうとすると、一時的にしろEBSをアタッチするなんて方式で実現するしかなさそうなので、なかなか大変そうなわけで、そうなると「現在のところ」ってのは割と長い時間に渡ってこのままなんじゃないかという気もするな。
さて、Single-AZでt2インスタンスを使うか、Multi-AZでm1インスタンス使うか…ケチケチで構築しようとすると、なかなか微妙な選択肢を迫られるなぁ…いやはや。
先日から、EC2のインスタンスの再起動祭りが行われていて、きっとアレはXenのパッチに伴う再起動だろうと言われていたが、やはり、Xenの脆弱性対応だったらしい。
EC2メンテナンスについての続報＠Amazon Web Services ブログより
本日は先週末(2014/9/27から)に実施した、再起動を伴うEC2のメンテナンスについての続報や背景をお知らせします。
これはXen Security Advisory (XSA108)に関する全てのセキュリティリスクから皆様を守るために実施され、AWSは昨日(米国時間9/30)遅くすべての対象EC2(全体の10%未満)のメンテナンス作業を完了しました。
で、今回の再起動祭りの原因となった脆弱性についてはこちらに情報があったけど、何を書いてるのかまったくわからないので、今回の脆弱性に関するニュース記事を眺めてみた。
The Xen Vulnerability That Rebooted the Public Cloud@eWeekより
The impact of the flaw is that an attacker could potentially crash the underlying host server and potentially read data from other virtual machines on the system. So, the problem for public cloud providers, for example, is that the flaw could have enabled an attacker to potentially get access to other resources and data on the cloud. Needless to say, that would have been catastrophic for any public cloud provider, especially the world’s largest.
適当に訳してみると、「今回修正されたXenの脆弱性を突くことによって、物理サーバーをクラッシュさせたり、他の仮想サーバ(適当な訳注:きっと同じ物理サーバの上で動いてる仮想サーバだろうな)のデータを読んだりすることが、潜在的にできるようになってしまう。
パブリッククラウドにおいては、攻撃者がクラウド上の他人のリソースやデータにアクセスできることになってしまう。パブリッククラウドを提供する事業者、特に世界最大級の事業者にとっては、壊滅的な事態に陥ってしまうことは言うまでもない」…って感じだろうか(誤訳してたらごめんなさい)
ただまぁ、今回の脆弱性はIntelのVT-xやAMD-Vを使った、HVM (Hardware-assited VM:ハードウェア支援仮想化。完全仮想化とか言われてる方式か)で仮想化されたサーバにのみ影響があるようで、従来のPV(ParaVirtualisation:準仮想化)では影響を受けないらしい。
再起動祭りをやったのはAWSだけかと思いきや、個人的には縁のないRackspaceやIBM Softlayerあたりも再起動祭りをやってたらしい。いやはや、ハイパーバイザのバグとなるとさすがに影響が大きいな。
追記：そういえば、LinodeってXenを使ってたような気がするんだけど、どうなったんだろう(遠い目)
© 2024 ただのにっき。
Theme by Anders Noren — 上へ ↑