SD-WANのアップグレードとTGW Connect
備忘として。
SD-WANのバージョン 5.2.0がリリースノートされています。
ちなみに、名前がVMware SASE になってます。
その中で ↓ の機能がリリースされていて、
TGW のConnect アタッチメントというものの存在を知りました。
これまでのSD-WANとTGWの接続は
TGW側は「VPN アタッチメント」を選択し、SD-WAN側はIPsec VPNとして接続するという形態（VPNなのでグローバルIP同士で）でしたが、
このリリースで、
TGW側と「Connect アタッチメント」を利用して、GRE接続することができるようになりました。
Connect アタッチメントのイメージは、AWS公式によるとこういう感じ。
VPCアタッチメントに近いイメージで、LAN接続になるって感じですね。
メリットとしては速度でしょうね。
TGWの制限上、
VPNは 1トンネルあたり 1.25Gbps
GREは 1トンネルあたり 5.0Gbps
になります。
まだ検証等は試せてはないですが、使ってみたら追加レポしたいと思います。
以上、備忘でした！
Flex StorageとFSx for NetApp ONTAP
VMCでの外部ストレージの話
先に、GAされたのはFSx for ONTAPのサポートでしたが、Flex Storageのほうも着々と準備が進んでいるようです。
簡単におさらい
FSx for NetApp ONTAP
・AWSのマネージドサービス
・オンプレでいうNetAppストレージのAWS版
オンプレで7-modeから移行したときは、cDOT(シードット clustered Data ONTAPの略)とか言ってましたが、この呼び方はもう消え去っているんですね。
Flex Storage
・正式にはVMware Cloud Flex Storage
・VMwareのマネージドサービス
英語サイトには価格が出てました。なおアジアパシフィックでは現時点未リリースです。（ちなみに、最低容量は25TiB～とさらって書いてます）
25TiBで3年だと ¥427.68328 × 25600GiB = ¥10,948,692
FSx for NetApp ONTAPのほうをSizerしてみると
$2,209 × 36ヶ月 × ¥135 = ¥10,735,740
ほぼ同じでした。
FSxのほうは実際は利用量に応じた従量課金なので、使い始めはもっと安くなりそうですけどね。
Flex Storageが使えるようになったら比較してみてかなー。
オンプレNetAppユーザーは、「FSxにSnapMirrorしてVMCにマウントして全台移行」とかできそうなので1回やってみたい。
俺的備忘 VMC管理リソースについて
VMCの管理リソースについて
VMCではvCenterやNSXなどにリソースが確保されます。
備忘として残しておく。
おおよそ、
標準で、34 vCPUと116GBメモリが確保される。
サイジング時には注意！
参考にするのは以下、
VMware Configuration Maximum tool
と
それぞれ、
↓を見る。
Sizerの方は、グローバル設定でアプライアンスサイズを指定して適当にサイジングしたあとの「サイジングの前提条件」のところで見れます。
サイバー攻撃
これもランサムウェアですかねぇ・・・
病院はヤバ過ぎる。。
まぁどんな業界でもヤバイとは思うんですが。
ワタクシもランサムウェア被害で軒並み暗号化されてしまった現場の復旧のお手伝いをしたことはありますが、もう地道な作業ですよね。
ランサムウェアって結構前から仕込まれたりしてて・・・・
大きな流れとしては ↓ の繰り返しになると思うんですが、
・ネットワーク周りをガチガチにする
・バックアップから復元する
・復元したマシンをEDRでスキャンする
・検出されたら、さらに古いバックアップから復元する
・検出されなかったらネットワークに戻す
・時間差で検出されたらネットワークから隔離する
・検出されたら、さらに古いバックアップから復元する
（以下ループ）
まーーー、やっぱりバックアップって超重要になってますね。
バックアップがないと本当に「詰み」の可能性ありますからね。
一昔前だと、ハードウェアの故障に備えてバックアップってイメージでしたけど、昨今ハードウェアって丈夫だし、ヒューマンエラーとこのランサムウェアのためのバックアップが大事！って感じですね。
VMwareもCarbonBlack買収してNSXとかこれまでのネットワークセキュリティとかもあってVCDRでクラウドバックアップもリリースして、できる幅が広がってますよね。
サイバーセキュリティ再考しましょう・・・
Officeライセンス系の話
ライセンス系、結局よくわからないですよね。
よく話題になるのは ↓ ですよね
Windows Server
Oracle database
Microsoftは規約が結構な頻度で変わるし、
Oracleの方は担当営業によって言う事が変わる、ってヤツです。
で、今回AWS EC2でOfficeライセンス込のAMIが出たのと、MSの規約がちょっと緩和された（？）らしいので、ちょっと触れたいと思います。
その前に、おさらいしとくと
VMC環境(AWSでいうDedicated Hostの位置付け)でいうと、2019年10月の規約変更が大きかったです。
専用ホスト クラウド サービスに関するマイクロソフト ライセンス条項の改定 - マイクロソフト ボリューム ライセンス
これは、ざっくり言うとWindows ServerやOfficeライセンスに関しては、SAなしでも
・2019年10月より前に買ったライセンスはBYOLしてもよいよ。ただしアップグレードは不可。
・2019年10以降のライセンスはBYOLダメよ。サービスプロパイダー(VMCならVMware)からSPLAの形態で新たに買いなさいよ。
って感じです。
↓ 2022年10月のMSの発表
New options for partner hosted cloud
結局よくわからないが、結論はAWSやVMCに関してはあまり変わりなし。
そもそもOfficeには2種類あります。
・昔ながらの買い切り型（ボリュームライセンスなど）
・Microsoft 365 Apps（旧：Office 365 ProPlus）などのサブスクリプション型
|
BYOL |
2022年10月まで |
2022年10月～ |
|---|---|---|
|
ソフトウェア アシュアランス付きボリューム ライセンスの BYOL |
- 専用ハードウェア上の任意のプロバイダーに許可されます。 - マルチテナント (「パブリック クラウド」) BYOL は、ライセンス モビリティ パートナーのステータスを持つプロバイダーにのみ許可されます。 |
- すべての認定アウトソーサーに許可されています。専用ハードウェアと共有ハードウェアに違いはありません。 - AWS、GCP、Alibaba: SA によるライセンス モビリティのみ。 - Azure: ライセンス モビリティ + Azure ハイブリッド使用特典。
|
|
Office 365 アプリと Windows 11 VDI の BYOL |
- 専用ハードウェア上の任意のプロバイダーに許可されます。- マルチテナント (「パブリック クラウド」) BYOL は、QMTH ステータスのプロバイダーにのみ許可されます。 |
- 認定アウトソーシング業者および Azure に許可されます。専用ハードウェアと共有ハードウェアに違いはありません。 |
結論
・AWSやVMCでO365はどうやってもムリ
・買い切り型Officeなら可能。BYOLはNG。
という感じです。
VMCの場合、OfficeのSPLAはVMwareから買えないので、ベンダー経由でのSPLAでしか買えない状態です。
ちなみにサーバ側でOfficeをRPA的に使っている場合はまた別のライセンスがいりそうな。
↓ なぜかwordのまま公開されてますが、無人(Unattended)ライセンスというやつです。
https://www.microsoft.com/cms/api/am/binary/RE4ELC4
このあたりをすべて把握している生き字引マンが社内にいれば嬉しいなぁ。
Shared Prefix List（共有プレフィックスリスト）って何？
VMC SDDC ver1.20がリリースされました。
で共有プレフィックスリストが使えるようになった！
↓
って書いてるけどこれ何？っての
AWSユーザーなら当たり前かも知れんのですが、AWS SA Proの更新を先延ばしにしているワタクシとしては知らない領域でした・・・・
（ま、ここのリリースノートに書いてある通りですが、、、）
これまで、VTGW → TGWを接続してネイティブVPCを接続している環境だと、
VMCが持っているセグメントのルートは、VTGW側のルートテーブルにネクストホップをTGWにするように、手動で書く必要がありました。
TGWのルートテーブルにも、VMC宛の通信はVTGWとのピアリングアタッチメントに向くように書く、という感じです。
この機能を使えば、VMCで作ったセグメントは、自動でTGWのルートテーブルに反映されます、ということですね。
↓ の記事がわかりやすかったです。
Understanding Shared Prefix Lists for SDDC Groups in VMC on AWS | VMware
個人的には、
VMCのENI（こっちは元々自動でVPCのメインルートテーブルが更新される）でも、意図せず（というか自動で反映されるというのを忘れていて）、テスト用ネットワークをVMC側で作ったらオンプレで使ってるネットワークと重複してて、伝播されちゃってエライコッチャ！になった経験があるので、ちょっとこの機能をバリバリ使うかは様子見です。
脳が馴染んできたら使っていこうかな。
VMware Explore in USA!!!!行ってきました
3年ぶりのオンサイト開催＠サンフランシスコ
VMware Explore行ってきましたー
キーワード的なとこでいうと
Cross-Cloud
とかCloud Chaos（クラウド環境が乱立している状態）をスマート化していく、といったような話が多かった気がします。
他のハイパースケーラーではできない視点なので、非常に興味深いところですね。
あとは、まだプレビューでしたが、VMCの
Flex Compute が気になりました。
単純に言うと、ベアメタルより小さい単位でVMCを利用できるようになる機能のことみたいです。
i3.metalのリタイアに伴いi4i.metalが次のVMCの最小インスタンスになりますが、結構1ホストが大きいんですよねえ（つまり高い）。
VMCはリソース余らせちゃうと損なので、規模の小さめなお客様向けには、このFlex Computeには期待大です！
ブロードコムのCEOも登壇してました。
VMwareに関してはこれまで通りのビジネスを継続していく、的なことを言ってたと思います、たぶん。
パロアルトのVMware本社もちょっと覗かせてもらいました。
食堂の寿司職人のお兄さんが「最近、本社には日本人がいなくなっちゃったんだよねー」と言ってました。
グローバル人材を目指そう、とちょっとだけ思いました。
にしてもサンフランシスコ天気良すぎてぐう羨ましい
VMCにおけるアドミッションコントロール
アドミッションコントロール
それは、
vSphere HAが起こったときに、残ったクラスタリソースで仮想マシンが起動できるように、事前に全体のリソース量を制限しておくことができる機能です。
事前に設定した閾値を超えて仮想マシンを起動したりすることができなくなります。
VMCの場合、以下が注意点です。
VMCではアドミッションコントロールの設定（HAの設定）はVMwareマネージドのため変更ができません。
管理リソースなどが確保している領域等などがあるため、
VMCの2ホストi3.metal構成だとアドミッションコントロールにより、
36VM以上の仮想マシンはパワーオンができないようになっています。
閾値設定（VMCでは50%）はまだしもVM数の制限は見落としがちなので要注意。
BROADCOM！！！！
そんなことがあるんですねえ
Broadcom to Acquire VMware for Approximately $61 Billion in Cash and Stockhttps://t.co/VhdGU0Aezl pic.twitter.com/3dZXkMQQO1
— VMware News (@vmwarenews) 2022年5月26日
ちょうど6月にVMwareに転職した知人が、
「社内が物凄くザワツイている・・！！！！」と言ってました。
販売形態をサブスクリプションに切り替えていく、ってのはニュースでも出てましたが、他にも色々とあるのかなぁー。
ま、気にしても仕方ないので楽観的に行きましょう！
