VCDRのDirect Connectのサポート
タイトルのままですが、ありがたいアップデートですね。
SaaSやIaaS全般ですけど、結構思い込みで「これはイケるやろ」ってのが非サポート構成だったり、制約でできなかったり、ってありますよね。
VCDRはファイルレベルリストアができるようになってたり、VMCでのDR目的だけでなく、普通のバックアップとしての代替としても使えるような機能が色々と増えているので注目です！
vExpert 2022
良かったです！認定いただけてました。
今年は実働よりももうちょい管理/プリセールス寄りになりそうですが、検証系の
技術発信はちょこちょこ継続的にやっていきたい所存です！
HCX NET-EXTの冗長化対応
これまた嬉しいアップデートです。
これまで、VMCとのL2延伸は、
①HCX
②NSX Autonomous Edge
いずれかを使う必要がありました。
NSXのほうは標準でActive-Standby構成が可能でしたが、HCXには冗長化機能がなかったのです。
今回のアップデートでは、
HCX Ver4.3で待望の！HA機能が！
なお、HA構成が可能になったのは、NET-EXT（L2延伸を提供）です。
Service Meshの画面にもHAのタブが出現しております。
公式ドキュメントによると設定自体は、HCXからポチポチポチっとできちゃうようですね。
HCXの可用性はL2延伸構成を維持するためには、かなーりネックだったので嬉しいです。
早速アプデしてみよう。
AWS EC2のネットワークのベーススループットが公開されてました！
いつの間にドキュメントが更新されたのだろうか！
これは地味に嬉しいですね。
General purpose instances - Amazon Elastic Compute Cloud
EBSとは違い、これまでEC2のネットワークスループットはバースト値しか公表されていませんでした。
最大 5Gbps とかっていう書き方ですね。
これがなかなかに曲者で、、、
これまでの経験上でバックアップとかのトラフィックを流してると、ガクッと速度が落ちて困ったこともありました。
m4.xlargeとかでもベースだと1Gbpsくらいしか出ないっていうのは、なんとなく経験してましたが、ドキュメントでも1.25 Gbpsですね、ベースが。
これがmediumとかだと250mbpsとかなので、バースト使い切っちゃったときは遅い遅い・・・
Up to XXXXの罠に見事にハマったのでした。
ドキュメントには、バーストの仕組みとかバーストの補充の仕組み（EBSと考えかたは一緒）も記載が追加されてますのでぜひ参考に。
では。
これは・・・！！！
これは紹介せざるを得ないアップデートでした。
AWSの年次カンファレンスであるre:inventでの発表の
↓
のどれ？かと言うと、
Amazon FSx with NetApp ONTAP Integration
コレです！
経験上、VMCの現行インスタンス（i3.metal、i3en.metal）でSizerを使うと、多いのが[Driven by Storage]！！
つまり、ストレージ容量が足りないからホストを増やす必要がありますよ！と。
というのも、VMC on AWSはベアメタルインスタンスで構成されたvSAN環境です。
各インスタンスは、1台あたりRAW で10TiB くらいのディスクを持ってます。
それらの内蔵ディスクを仮想的にひとつのストレージとして構成するのがvSANです。
つまり、ストレージ容量が足りないときはホストを足すしかないんです。
ただ、vSANを構成するための諸々（RAIDのレプリカやパリティ・・・、管理系VMもここから消費・・・、30%以上のスラックスペース・・・、など）を考慮すると、CPUやメモリに対してストレージが足りなくなることが多いんですよねえ、実際。
これまでVMCは一般的にはこのvSANデータストアしか使用できませんでした。
が、この記事によるとFSx を使えばNFSデータストアが使えるようになるとのこと！
フルマネージドクラウドファイルシステム – FSx for NetApp ONTAP – Amazon Web Services
AWS側のページにも[VMware Cloud on AWS]の記載がありますね。
これは期待できる！
最近のアップデートは、これまであった色々なVMCの制限がどんどん緩和されてる感じです。
NetApp FSx 以外のNFSデータストアも使えるようにしてくれてもええんやで（ﾎﾞｿｯ）。
ほなまた、正式リリースまで！
Log4j脆弱性の脅威！！
これはガチンコのヤベーやつです。
とくに外部からの接続を受け付けているようなサーバは、早めに対策を。。。
ちなみにVMware関連の対応策は以下のKBにまとまってます。
（随時更新かつ更新速度がえげつないです。パッチのないものは設定変更が必要です）
VMCのバックアップ
こんばんは。
VMC on AWSでの仮想マシンのバックアップどうしてますか？？
VMwareでは、従来より標準のバックアップツールというものは提供されていないので、↓ Compatibility Guideで対応しているバックアップソフトを導入するのが一般的ですわな。
かくいう私も、Gartner様のMagic Quadrantと合わせて「フムフム。Veeam、Commvault、Veritas、Rubrikあたりが最近はお強いのね。VMCには対応しているのかしら」とか調べたりしています。
ところが先日のアップデートで、VMC on AWSについては、AWS Backup が使えるようになったと！
AWS Backupは、従来のネイティブAWSにおけるEC2等をバックアップできるサービスなので、操作するのはネイティブAWSのコンソールです。
なので、バックアップポリシーやバックアップボールト（バックアップデータはS3に保管されます）はAWS Backup準拠です。
何が嬉しいの？
っていうと、やはり
ライセンスがいらない！
これに尽きると思います！
ネイティブAWSでもサードパーティ製のバックアップツールはいくつもあります。
AWS Backupではファイル単位のバックアップ・リストアができない、アーカイビングができない、などなどの多くの制約を補完する形で製品がリリースされています。
とはいえ、バックアップを安価に取得できるという点で新たな選択肢になるんではないでしょうか！
ちなみに、AWS BackupはオンプレミスのvSphereもバックアップ取れるらしいですね。
なかなか痺れる構成です。
あと、AWS BackupはいわゆるVPCサービスではなく、グローバルサービスなので、ENIを介したバックアップはできない点は要注意です！
はやく使ってみたい！また使ったらリポートしたいと思います。
ではでは。
VMworld 2021 Japan
今年もVMworldが開催されます！
コロナの影響なので今年もウェビナーオンリーです。
自宅で気軽に見れるのは良いんですけど・・・、やっぱり現地のお祭り感が楽しいですよね。
在宅だとなんやかんや他の仕事とか電話とかで集中できないこと多いですしね。
見たいセッションやコンテンツを探しやすかったり、ライブじゃなくても見れるメリットとかもありますけどね！
かくいう私もチョロっとセッションに参加させていただきました！
動画撮影スタイルだったので、ノイズも消してもらったりと、いやー便利なものです。
ちなみに、私のセッションテーマは、この2-3年でものすごい勢いで増えているVMware Cloud on AWSについてです。
VMCはアップデートも頻繁ですし、最新機能や実例やハマりポイントなどなど、メーカー目線やSIer目線など様々なパースペクティヴでVMworldをご覧くださいー。
様々なパースペクティヴで！
VMC大阪リージョン！
タイトルの件！
待望の日本国内２つ目のVMCリージョンの正式リリースになりました。
ちなみに、大阪リージョンは、３つのAZで構成されているみたいです。
公式サイトにも価格が表示されていましたが、東京とほぼ同額でした。
注意点としては、以下くらいでしょうか。すぐにアップデートされると思われます。
・VMware Transit Connect (VTGW) が使用できない点
・VMware Cloud Disaster Recovery (VCDR) が使用できない点
やっぱり物理的な遅延というのはどうしても発生しますしネックになるポイントですから、西日本圏のDCやオンプレミスとL2延伸を構成する場合は大阪リージョンを活用できるのは嬉しいポイントですね！
東京リージョンとのDR構成も国内で完結できるようになります。
その他にもVMworld 2021 Japan（VMworld 2021 Japan | ライブ配信 11月25日(木) - 26日(金) | VMware）に先駆けて、10月頃に様々なアップデートが発表されてました。
色々ありますが・・・・
・VMCでのTanzuのサポート
・VMC２ノードのストレッチクラスタのサポート
・VMCでのNSX Advance Firewall（分散IPS/IDSなど）のAdd-onサポート
・VMCでのCarbon Blackのサポート
・VCDRのRPO短縮（・・・30分！）
など
より活用できる幅が広がった感じがしますね。
ではでは。
HCXのL2延伸ってすごい安定するなぁ
HCXのL2延伸ってすごい安定するなぁの件です。
昔々あるところに、NSX Autonomous Edge(NAE)でL2延伸を構成した案件がありましたとさ。
アプリサーバはVMC on AWSへ行き、DBサーバはオンプレミスに残りました。
はてさて、DBへのセッションが安定しないではありませんか。
これは厄介、厄介。どうしたものか。
にしても、こういうクラウドとのネットワーク関連のトラブルというのはホントに根深いですねぇ。。。
オンプレ側の基盤？ネットワーク機器？回線？Direct Connect？どこが原因？全部が原因？とか、これを解明するのは至難のワザでございました。
昔のWindowsは、レジストリでもコマンドでもTCP関連のタイムアウト値がイジれない、という壁もあったんですねえ。
そこでNAEをHCXに替えてみました。
すると、なんということでしょう。めっきりエラーがなくなったではありませんか。
ということで、すっかりみんなご機嫌になりましたとさ。
めでたしめでたし。
と、まぁNAEが悪いわけではない、と信じたい（結局根本原因は不明でした。技術者としてどうなのよソレ）ですが、HCXは偉大でした。
で、HCXの何が良かったか、って多分ですがコイツじゃないかと僕は踏んでます。
↓のTraffic Engineering ってヤツ！！
ちなみに、この機能は2020年11月以降、VMCのライセンスにバンドルされるHCXでも使えるようになった機能のひとつです。
Traffic Engineering には、TCP Flow Conditioning とApplication Path Resiliencyっていう機能があります。
詳しい説明は↑に任せます（よくわからない）が、それぞれ要約すると
・パケットのフラグメントを最適化する
・トラフィックパスを最適化する
というような機能です。
HCXのL2延伸設定時に、チェックボックスをひとつポチっとするだけで有効にできちゃう。
ありがとうHCX！ありがとう無償化！
教訓：クラウド移行する際は、アプリケーションの種類やトラフィックフローをちゃんと精査してから移行しよう！物理的なレイテンシは避けられないので！
