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

タグ: AWS (1ページ目 (3ページ中))

Amazon Linux 2022がなかなかGAにならないと思ったら、Amazon Linux2のEOLが延長された。

Amazon Linux2022のことが発表されて、しばらくプレビュー版のまま。なかなかGAにならないなぁと思ってはいたけれど、もう7月。2022年の半分が終わってしまったことになる。いっそ、Amazon Linux2023くらいにしておいた方がよかったんじゃないかなぁーと無邪気に思ってたら、Amazon Linux2のEOLが延期されてた。延長されたEOLは2024年6月30日。

そっと、Amazon Linux2のFAQページが更新されてるのが興味深い。

AmazonLinux2のEOLが2024年6月30日に1年間延長

AmazonLinux2のEOLが2024年6月30日に1年間延長

PHP8.0を動かすインスタンスを構築しようと思っていて、Amazon Linux2022を待っていたけれど、結局、PHP8.0のEOLが2023年11月26日なのでPHP8.0のEOLの方がAmazon Linux2よりも早くEOLを迎えることになるので、まぁ、なかなかGAにならないAmazon Linux2022を待つよりもAmazon Linux2で構築しちゃおうか。

さくらのクラウドのディスクのクローンで「待機中」

さくらのクラウドで、サーバーをクローンするためにディスクをクローンしようとしているけど、「待機中」のステータスになって、いっこうにディスクのコピーが進捗するする気配がない。ディスクのコピーは常にインスタンスからアクセスされているストレージ(SANだったっけ)のリソース(帯域幅やCPU)をがっつり使うことになるので、コピーの優先度を上げるわけにはいかないだろう。例えば、複数のユーザーからのディスクコピーのリクエストがパラレルに走らないような制御がなされているんだろうけど…。

例えば、ヤバい!って事態に陥って、急遽、サーバをクローンしようとしてこの状況に直面すると切ないだろうな…と思いながら、まったく進まないプログレスバーを眺めてみたりして。

しかし、AWSだとこういう待ち時間がなかったような気がするんだけどなぁ。インスタンスを起動するときにはAMIの裏側のS3からEBSにがっつりデータをコピーしているはずだし、サーバのクローンをする時にもEBSとS3の間でゴリゴリとデータをコピーしているはずだけど、特にちょっと待ってってステータスになっているのは見たことがない気がする。まぁ、さくらのクラウドがショボいというか、むしろ、AWSのEBS周りのネットワークの帯域幅はどれだけ太いんだって話かもしれないけど。

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インスタンスを使えるようにしてくれてありがとう。

更新: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が使えるようになった。

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インスタンスに切り替えることにしようかなと。

やっとTokyoリージョンでC5インスタンスが利用可能に

AWSのblogに記事が載ってたけど、やっとTokyoリージョンのEC2でC5インスタンスが利用可能になったとのこと。

確か、C5インスタンスからはhypervisorがXenからAWSが開発したnitroと呼ばれるhypervisorに変更になっていて、EBSと接続などが専用のハードウェアにオフロードされるため、よりCPUがユーザーに割り当てられるようになったようで。既存のAMIをC5インスタンスで動かせるか、ちょっと検証してみるかな。その時間を確保できたらいいんだけども。いやはや。

ec2のt2インスタンスのCPU使用率が…

EC2のTokyoリージョンで動かしているt2インスタンスについて、zabbixからのアラートが来てた。CPUのStealが高い、と。当該サーバはAmazon Linux 2017.09で、 カーネルは「4.9.70-22.55.amzn1.x86_64」(ちょっと古いか)

しかし、実際にサーバにSSHしてみると、stealが高いというか訳わかんない数字になっていた。

Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,29700.0%id, 0.0%wa, 0.0%hi, 0.0%si,-1458782470144.0%st

なんかもう壊れてませんかって数字。仮想化基盤とLinuxカーネルあたりで何かが起きてるような気がするけれど、訳が分からない。そっと業務から外して再起動するしかないか。いやはや。

« Older posts