IPv4枯渇の話
こんにちは、Yos235です。
梅雨明けして（してなくても）暑いですね。
限られたリソースの中での取り合いが起きると、価格が高くなるって話。
New – AWS Public IPv4 Address Charge + Public IP Insights | AWS News Blog
IPアドレスバージョン４のアドレスが枯渇したと言われて久しいですが、とうとうAWSでもIPv4アドレスに課金が開始されます。いままでも完全無料だったわけでは無いのですが、今回からIPアドレスを使っていても、１個めでも、起動していなくても、確保しているだけで課金されることになりました。
IPアドレスひとつ、 1 時間あたり 0.005 ドル
ｘ 750 時間 ＝ 3.75米ドル/月
JST8/1(火)9:40でのレートは142.4700なので
１IPアドレス、１か月当たり、534.2625日本円ってことになります。
一旦確保したら手放したくないという心理はよーーくわかるのですが、もう、みんなIPアドレスの呪縛から離れなさいよ、≒IPv6使えってことですね。クラウド時代に、IPアドレスで場所と紐づけるって考え方自身が古いってこと。
じゃあ、何で管理するかと言ったら”名前”ですけども、日本語（２バイト）でやるわけにもいかない（やろうとした取り組みはあったが、やっぱりちょっと使いにくいみたいで普及してない）ので、英語で≒DNSで対応しましょうということです。
となると大事になってくるサービスは、DNSってことになるのですが、これもいまやメガクラウドが提供しているAzureDNSであったり、AWSのRoute53であったりします。先日の記事でRoute53が外部利用可能になる(下記参照)とかもありましたので、このIPアドレス有償化にむけての布石かなと思いました。
Document history - Amazon Route 53
Updated the entire Route 53 guide with the new console experience for domains. You can also use the new console experience to transfer a domain from one AWS account to another AWS account. For more information, see Registering a new domain and Transferring domains.
今日はこの辺で。
SDDCの追加になるとは、、
こんにちは、Yos235です。
最後の最後に、余計なもの拾ってくるのが得意技（必殺技？)になりつつあるのですが、先の経路数制限がSDDCのとvTGWにも有るってことが判明。
All Category で Networking and Security Maximums をチェックしての、
> Networking and Security Maximums ( Transit Connect )
にあります、
Maximum number of prefixes advertised from a single SDDC to the SDDC group が 250 と。なのでSDDCを追加せよ、ということです。さらに Transit Connect Route Table Size は 1000 と。なので、SDDC４つでテーブルサイズがあふれる計算になるので、SDDCグループを追加せよ、ということです。
せっかくTGWの制限が20から200になって良かったねーって言ってたのに、ねぇ。
SDDCの追加をすると、vCenterが増えるのでNSXマネージャも増えるしHCXマネージャも、増えますです（涙目）そうするとSDDC追加２時間はオンプレに比べたらあっという間ではあるものの、設定作業はけっこう大変なんですよね。
うーん、この上限、何とかならんですかねぇ。ネットワーク制限に引っ掛かるというIPアドレスに縛られた（地球の引力に引っ張られている）人間が悪いんですかね、シャア殿（ガンダムネタですみません）
今日は、この辺で。
TGWからオンプレ環境への経路広報数の上限が緩和
こんにちは、Yos235です。
モンスターハンター®を進めていくとG級が解放されますけど、
クラウドサービスにも上限が決まっているのと同じように(？)、
VMwareでいうと「構成の上限」を確認するってのがとても大事。
今回は、AWSの上限値(クォータ)に関するお話です。
VMware Cloud on AWSを使うとき、オンプレ環境と接続するには
DirectConnectを使用しますよね。
ふつうにデーターセンターとして使うだけなら、１つや２つ程度の
広いセグメントを広報すれば良いですが、マルチテナントというか
IaaS的にアプリ開発者（というかｘｘシステム毎）に経路を広報したい場合
まったくもって20じゃ足りないよ、ってなると思います。
4月のSDDCアップデートに合わせてなのかわかりませんが、
なんとその上限が解放されました（ぱちぱち）
今回の構成上、Transit Gatewayを介しているので、
「Number of prefixes per AWS Transit Gateway from AWS to on-premise
on a transit virtual interface」の行を確認します。
「200 combined total for IPv4 and IPv6」ということで200になってます。
これ、英語サイト上だけの記載になっているので、日本語サイトの更新は
まだされてないっぽい（ドイツ語でも同じだった）んですが、
結構大事なアップデートなんですが、みんなそれほど困ってないのかな…
ま、とりあえず、私的には九死に一生なアップデートだったんで
よかったよかった、という感じです。
今日は、この辺で。
VMware Cloud on AWS の SDDC 1.22がやってきた
こんにちは、Yos235です。
2023年5月2日、SDDCバージョン1.22がやってきました。
2022年9月20日のバージョン1.20以来、7.5か月振りです。
その前の1.19が2022年6月29日、さらに前の1.18が2022年4月5日なので
だいぶ久しぶりな感じがしないでもないと思われがちなのですが、
奇数番号はオプションリリースなので、5.5カ月→7.5カ月ってことで
ちょっとの差、ですかね。
気になるアップデートといえば、NFSデータストアがマルチパスになったこと
かと思いますが、どうやらAmazon FSx for NetApp ONTAP向けのようです。
細かいところはこちらを確認ください。
貧乏くさい私にとってそれよりも気になる（ちょっと前の）リリース情報を
見つけたので確認してみました。
それは何かというと、eDRS（ErasticDRS）の仕様変更です。
Optimize for Lowest Cost の時の、下限値が20％から40％に緩和（といっていいのか？）
されたこと。ストレージは安全を見てホスト数を増やそうとしたり、減らそうとしないという
ありがたーい制御をしてくださっていたのですが、これによってホスト数が多い時に
20％を下回らないと減らしてくれないって状況が改善されそうな気配。
超単純計算では、だいぶ安心感(お財布にとって)が有りますね。
4ホストで20％だとすると、3ホストになって26％
4ホストで40％だとすると、3ホストになって53％
Rapid Scaling の時は、下限値が0％＝手動スケールインだったのが、CPUとメモリは50％
ストレージは40％設定が追加されました。（拍手）
ついでに、増やすときのホスト数が以前は２だったが今回から４に増えたようです。
VDI用途に使われているとするとこのくらいのスケールアウト/スケールインしてくれると
安心ですよねぇ（お財布が）
ついついVDIのことを考えちゃいますが、やっぱりクラウドサービスってのは
スケールアウト、スケールインするってのが大事だったりするんで、
こういう改善は有難いなと思いつつも、リザーブするほうが圧倒的に安いので
なかなか難しいところよね、と思います。
今日は、この辺で。
HCXの可用性向上って何が向上？
こんにちは、Yos235です。
もうすぐゴールデンウィークですが、休み期間中のトラブルによる呼び出し、
嫌ですよねぇ。サービス停止によって緊急呼び出しを喰らわないように、
システムの可用性向上策をいろいろと練り上げたくなるんですが、
いまやろうとしていたのが、東西サイト間での可用性向上。
HCXはオンプレからクラウドの移行に最適なツールですが、L2延伸の機能が在るがゆえにL2延伸したまま動かせばええやん！みたいな発想をされる方々が続出（個人の感想です）してるのを受けて、HCXはL2延伸用のコンポーネントを冗長化することができるようになりました。
でも、実はそれって各サイトにあるコンポーネントが２つになって、２つのトンネルが作られる、経路の可用性向上策ですね。２つのトンネルはアクティブスタンバイなので、コンポーネントが落ちたら切り替わるというもの。
２つ別々のキャリアで冗長網を持てる大規模案件なら良いですが、トンネルが２つとも落ちるってパターンが割と多いと思うのですよね。トンネルを終端しているコンポーネントが落ちたら、の対策よりもやって欲しいのはサイトが落ちたと検知と自動切り替えだったんで、ちょっと残念です。
今HCXでできるのは、(回線が２系統なければ)前述のコンポーネント単体障害、APR（HCXコンポーネント間の回線網を監視する）です。あとは、延伸先のゲートウェイからアップリンクに出すこと（トロンボーン現象の対応）は可用性というよりも移行途中の支援機能なのであんまり万能ではないです。このあたりをもう少し頑張ってくれると、ぼくら少しは安眠出来るんですけどね…
特に後者の機能はこれ素敵！って思ったんだけど、よく考えると延伸したセグメントが延伸先（ここ最近だとVMware Cloud on AWSかな）にいるってことを、外部にどうやって知らせるの？とか全体的な設計が必要だった
りするのでムズいのよね、実は。
まぁ、HCXは延伸がメインじゃなくて、移行を支援するツールなので（以下略
今日はこの辺で。
VMConAWS上の仮想マシンの時刻同期先ってどうするよ
こんにちは、Yos235です。
「楽しい時間はなぜ早く過ぎるのか」というみんなが実感しつつも、疑問に思っていることありますよね。それって実は、心の時計を早送りする神経伝達物質が出るから、心の中のペースメーカーが早送りされるためらしいです。楽しいっていいですよね。
とはいえ、コンピューターからすると時刻が早回しされるのはいいんだけど、
遅れるとかも困るけど最悪なのは”戻る”という事象。
もしくはうるう秒といって１秒差し込まれる事象。うるう秒って
58秒、59秒、60秒、00秒、01秒 みたいな感じで入るようなのですが、
厳密には59.000、59.999、59.000、00.000と、一瞬もどるらしいのです。
このあたりを解決するためには、某社のお高い専用アプライアンスなどを利用して
良い感じに時間調整をしてくれるものを、お金があれば用意すべし！なのですが
AWSのAmazonTimeSyncサービスはこれらを良い感じに吸収してくれる仕組みがあり、
VMware Cloud on AWSだとこれを利用する、が常套手段となります。
で、この素敵なATSですが、いままではVPCだけにとどまっていたのですが、
先日（というか2022年11月10日リリースで）一般公開してくれたようです。
> うるう秒が発生する場合は、UTC の正午から正午までの 24 時間に線形に分散し、
> うるう秒を追加または削除して平滑化することで、Amazon Time Sync Service が
> 自動的に対処します。
ここにあるとおり、良い感じに調整してくれるので、みんな利用さえてもらおうぜ！
というお知らせでした。
今日は、この辺で。
Active / Passive といっても負荷分散の話ではない
こんにちは、Yos235です。
FTPサーバーってPassiveモード使え、がインターネットのお約束的な感じですが
どうやら現在のWindowsはActiveモードしか使えない。まじか、時代は変わったな。
と思っていたら、どうもPASVモードは、あらぬ方向にデータを投げさせる、
行儀の悪いサイトがあるとかで、使わないほうが良いよって話も出ているようだ。
curlの複数の脆弱性情報(Low: CVE-2020-8284, Medium: CVE-2020-8285, CVE-2020-8286 ) - SIOS SECURITY BLOG
> 悪意のあるサーバはPASVへのレスポンスを使ってcrulをだまして特定のIPアドレスと
> ポートに接続させることが出来ます。
まぁ、そうだよね。
だからWindowsもPASVコマンドが無くなった、のかもしれないかなとか思いつつ、
このたび実装を行っているシステムで課題になっちゃいました。
FTPサーバーの前にロードバランサ―を置いて冗長化する、って不通に考えると
思いますが、今回のロードバランサ―はNSX ALB。
上記Docsには、「アクティブ FTP はサポートされていません。NSX Advanced Load Balancer では、回避策としてパッシブ FTP を使用することをお勧めします。」って書いてあります。
いや、それって回避策じゃないでしょ、と思うのだけども、仕方ない。
他の方法を探し回ってみたところ、なんとAVIとかいう製品だとできるような記載が。
って、AVIとNSXALBとどっちやねん、という感じは有りますが、ActiveモードのFTPが
出来ると書いてあるんで、これにて一件落着。 になればいいな…
戻りのPort20でNATポリシー作ってあげる、って話みたいです。
（未実装なのでいい加減な発言感を醸し出しつつ）
今日は、この辺で。
