AWSへのDirectConnect接続について

今回は・・・

掲題の件についてなのですが。。。

簡略版、ということで、

同僚が作った環境がHWのリソース不足のために、

処理能力の高いHWに・・・即座に載せ替えた際の話を備忘録的に載せておきます。

今回やったのは、

オンプレの環境から、AWS環境のサーバをバックアップリポジトリとして接続したという話なのですが、、、
自分は環境コピーしただけなので、細かい設定だったり、、、どの辺が難しい、、、とかは省きますが、大枠での話で。

やるのに必要な話は、FW（Fortigate側）の基本的な設定と、以下の設定。

・AWSとのIP-secでのVPN接続。

・AWS側とのルーティングをやり取りするためのBGP設定。

今回、変更したのは、Fxxxxxxxx60C→Fxxxxxxxx100Fという環境でした、、、。

そんなこんなで、あらかじめ聞いていた話をもとにある程度、見込みをつけてはいて、、、

僭越ながら・・・、自分自身勘所を抑えているので問題なく移行できる、、と思い依頼を受け、、、リプレースしたんですが・・・、

リプレース後、、、なぜか、AWSとの接続がつながらない。。。

見直していっても、

WAN回線状態はActiveになっていて、PPPoEの状態もOKになっている・・・。

外からのPingもつながるし、、、
うーん？？？？
なぜだ・・・？

と、、、思って悩んでいたところ、

VPNのPre-SharedKeyが伝えられていたものでは異なっていた模様でした・・・（汗

直した結果・・・、無事接続ができ、、、無事という記載の通りコト無きを得ました。。。

使う技術についての項目は書きましたが、詳細はうちの会社の方が書くはずなので、、、この辺に関して詳細をご希望の方は、、弊社の他の方の記事をぜひご参照くださいー！

うーん、、、

自分的には、、、F社Firewall・・・過去に非公開仕様のせいでトラブったりしたんですが・・・、

BGP喋れるというのが『新発見』で、、

これができると、、、、、、
AWSへのDirectConnectに安価且つ一般的な製品であるということ・・・・・についてだけは認めざるを得ませんねー。。。

まぁ、あとはリプレース前の機器のように、、ソフトウェアで処理させたときにスループットが足らなくなるという点、、、、、、。
これは、この製品特有なのか、、10年位前から言われていたこと（IPSを使うとスループットが1/10以下に落ちる・・・だとか。。）なのですが・・・。。。

使われる際にはお気を付けください。

何はともあれ、VMwareの仮想化環境などで利用することが増えているVeeamなどのリポジトリとして、AWSを利用することが増えている昨今、、、こういう話もふえるのでは・・・？という話です。

ご興味があれば、お問い合わせください。

Adobe社のFlashの影響について

今回は、

「Adobe社のFlashの影響について」

というタイトルでお送りします。

過去のVMware社製品を使っていると、

vSphere5.5以降で間違いなく影響を受ける部分です。

はい、vCenterです。

5.5：vSphere Web Client（Flash）

6.0：vSphere Web Client（Flash）

6.5：vSphere Web Client（Flash）

　　vSphere Client（HTML5）

6.7：vSphere Client（HTML5）（ここからやっとHTML5がメインに。）

　　vSphere Web Client（Flash）

7.0：vSphere Client（HTML5）

と、それぞれのバージョンの対応を書きました。

6.5からHTML5版がありますが、6.5ではvSAN、NSXなどはFlash版でしか設定・確認できないという問題があります。

6.7からはvSAN、NSXもHTML5の方で問題なく利用できる・・・んです。

（同僚の情報によると、6.7でもHTML5の方に一部制約があるらしいんですが、、、参考情報を見つけられませんでした。）

7.0からは完全にFlash版は無くなってますね。

ということで、Flashのサポート終了に伴って

6.7以降にバージョンアップをした方がいいわけですね。

とはいえ、いろいろ影響などなどを考えるとすぐにはできない！！

という方のために、VMwareさんもKBを提供してくれています。

https://kb.vmware.com/s/article/78589

------引用------

Caution: VMware will not provide support for the instructions below; use at your own risk.

For more information, see the Enterprise enablement support section of the Adobe Flash Player EOL Enterprise Information Page.

For example "mms.cfg"

EOLUninstallDisable=1
EnableAllowList=1
AllowListPreview=1
AllowListUrlPattern=https://FQDN_Of_The_Target_System/

------ここまで------

こちらのKBに記載の通り、、、推奨はしないよ、という話ですが、

mms.cfgを編集することで使えるようになります。

6.5以前の環境の方はご参考にどうぞ。

NSXでのマイセグについて その3

今回は、

「NSXでのマイセグについて その3」

というタイトルでお送りします。

よくある構成で、

Trend Micro社のDeep Securityが検出したものをGuest Introspectionと連携して、分散ファイアウォールによって隔離する構成です。

この構成、昔、「自動隔離はするけれど、、、自動的に解除はしてくれない」と

聞いたことがあったんですが、

最近、、、
運用されている環境で「隔離された仮想マシンの中から誰が隔離を解除したのか判らない・・仮想マシン」というものが、
発生していまして、、、、。

いつもながらに、、、

「？？？？？？」と、

首をかしげながら、はてなマークをたくさん放出してたところ

・・・・・・

・・・

・・・判りました。

Deep Securityの方でフルスキャン掛けると

隔離が解除されるようです。。。

これは、、、『あるべき姿』ではあるわけなんですけどねー。。。

というわけで、

他の方もブログ等で紹介していらっしゃる仕組みを改めて説明しますが、

まず、隔離の仕組みとして順番に。

セキュリティソフトウェアの方で「変ナモノ」（各ソフトウェアで検出できる・・・「アレ」ですね。。。）を検出。

その情報を基に、VMwareのNSXで検出された該当仮想マシンに対して（問題ありますよーという。。。）タグをつける。

上記のタグがつけられた仮想マシンは、（NSXの分散ファイアウォールのポリシー設定で通信不可なファイアウォールポリシーを設定されているために）自動的にネットワーク通信を行えなくなる。

という3段階の流れで、遮断を行うわけですね。

そこから、仮想マシンをネットワークに復帰させるためには、

「タグを外さないと通信できない」という仕組みなのを

ご理解いただいた上で。。。

元の話に戻りまして。

「セキュリティソフトウェア側でスキャン」して問題が無かったら、、、

自動的に（問題ありますよーという。。。）タグも外してくれるものが、、

最近はありそうです。。。

以前は駄目だった（と聞いていた）・・・から、
今もダメだと思ってましたが、大丈夫になっていそうだという話ではあります。

が、、、この辺もし（バージョンで関係してればその辺もぜひ・・・）お詳しい方見てらっしゃれば、
ご助言賜れれば助かります！！

VMware Cloud on AWSに触れた

今回は、

「VMware Cloud on AWSに触れた」

というタイトルでお送りします。

これまで、クラウド製品はVMware Cloud on AWSをはじめとして、Desktop as a Serviceの基盤などの提案活動では触れてきていたのですが、実際に案件で触ってみたのは初めてでした。

うーん、、、とはいえ、VMware Cloud on AWS自体をやっているのは弊社の他の方でそれを後ろからのぞき見している感じでしたが、うたい文句通りvSphereなんですね。

お作法はありそう・・というかあるんですが、その辺も含めてvSphereを使ったことのあるユーザさんは違和感なく使えそうではありますね。

そんなわけで、自分がこの案件でやったことといえば、、、相変わらずのネットワーク仮想化？いや、仮想化はしてないですね。クラウド環境へのネットワーク繋ぎこみの設計です。

この案件では、Direct-Connectを採用しているので、実際の接続を行っているL3装置の設計は通信業者がやっているんですが、全体的なネットワークの設計をしないと、、、

VMware Cloud on AWSへの接続が2拠点から出ている構成のため、無駄な通信が発生してしまいます。

こういうのはオンプレ、クラウド問わずなことだというのが、よくわかりました（笑

技術的なポイントとして、VMware Cloud on AWSのTier0ルータはBGPしか対応せず手動でルーティングテーブルを追加は出来ないようで、Direct-Connectを行うオンプレ側のルータでBGPのアドバタイズする情報を制御してあげないといけないということがあります。

実際に設定してもらったり、ルート集約の設計とかをしてもらったり・・というのは通信業者さんの方で、、、なので、通信業者含めてお客さんと3社で打合せしてしまいたいですね。。。

ひとまず、この先面白い話があればVMware Cloud on AWSの話もちょこちょこ話題にしようかなーと考えてます。

オンプレのVMware Identity Manager（Workspace One）についての考察（私見）

今回は、

「オンプレのVMware Identity Manager（Workspace One）についての考察（私見）」

というタイトルでお送りします。

※タイトル通り、あくまでも私見です！

VMware Workspace Oneのコンポーネントの1つであるIdentity Manager（以下VIDM）が朝一のタイミングで原因不明でスタックするという・・・恐ろしい事象が発生しています。

事象としては、（ロードバランサが前段にいてバランシングを掛けているために・・・）ユーザがアクセスした際に503エラーを返す。

しかも、この問題の影響としては、、、

シンクライアントを使い、ブラウザベースでVIDMで認証を行ってVDI（Horizon）にはシングルサインオンしている環境のため、

「一般ユーザはデスクトップに一切アクセスできなくなる・・・」という致命的大惨事を巻き起こします。。。

そのため、初めて問題が発生したときに復旧したVIDMサーバ再起動を行って、

とにかく早く復旧させなければいけない。

という話もあるかもしれませんが、障害発生後のログを取得してみても、

異常なログはなく、この事象自体は、、、３度再発、、、（再々発？）しているものの原因特定が出来ず、どの辺が問題になっていそうということすらも、、、全くもって原因不明な状況でした。。。

 打つ手が無いまま放置するわけにもいかず、

4度目が発生してしまった際、一筋の光明？？ともいうべき、サーバのCPU負荷が上がっていることを発見できたことで、一つの仮説が成り立ちました。

”VIDMにおいてもWEBサーバが動いてるはずだから、

その性能を左右するのはCPUのスレッド数ではないのか？

そのため朝一などのユーザアクセスが集中した際にはWEBサーバの処理が足りてないんじゃないか？？"

この仮説はサポートの方にはお話していませんが・・・（笑、

原因不明のまま放置もできないので、可能性があるのなら・・・と、

ユーザの許可をもらってvCPUの割り当てを増やし、現状、、様子見中です。。。

増強前でもサイジングの推奨値通りにしていたんですけど（2020年3月時点）、

 この仮説が当たっていて、再発しなくなることを願います。。。

これでも発生する様なら、、、

自分がいることで発生している業・・・？？ですかね。。。

 ＜2020年12月25日追記＞

1ヶ月近くたちましたが・・・再発はしていません。

前回、1週間とかで再発したことを考えると、、、希望が持てるかも？？

年明けに期待・・・！！です。

NSXのVXLANを利用したマルチアクティブデータセンタについて

今回は、

「NSXのVXLANを利用したマルチアクティブデータセンタについて」

と、いうタイトルでお送りします。

実装したのは2017年でしたが、ユーザさんの情シス部門の方々に仕組みを改めてご説明する機会（ユーザ企業様ないでの社内講習会）があったので、

ブログの話題にもしてしまおうというわけです。

バージョン自体は少し古いですが、考えの根本は参考になるんじゃないかな？と思います。

NSXでの実装の仕方としては、素直な構成です。

アンダーレイとして物理ネットワーク（裏LAN）があり、オーバーレイとして論理ネットワークがある。

ユニバーサル分散論理ルータでユニバーサル論理スイッチに接続された仮想マシンのゲートウェイの役割を担う。

分散論理ルータからのネクストホップは、それぞれの拠点に作成したNSX Edgeの論理ルータとなる。

両拠点のNSX Edgeの論理ルータはサービス系の表LANとつながって、WANおよびWANを介した拠点とつながる。

ここからが面白い部分ですが、

せっかく2つのデータセンタでユニバーサル論理スイッチによって同じネットワークが提供されているのに、通信の最適化をしなければ、WANに対しての出入り口が偏ってしまう。という問題に突き当たります。

そういうわけで、

Aの拠点側リソースを使っている仮想マシンは、A側の出入り口（ルータ）を利用する。

Bの拠点側リソースを使っている仮想マシンは、B側の出入り口（ルータ）を利用する。

こういう形が理想ですよね？

でなければ、

Bの拠点にいても、Aの方から入ってきてB側に引き渡され処理、またA側に戻ってきて出口から出ていく。。。

という、全くもって無駄な話になってしまいます。

ということで、目玉の通信の最適化。

出口の制御としては、A拠点、B拠点どちらにいるのかというのを

NSXのロケーションIDによって検知・制御してもらいます。

入口側の制御としては、完全にネットワークの技術ですがルーティングプロトコルで制御します。

この時に実装したやり方としては、2拠点だったためにデフォルトの通信先をA拠点の方として、B拠点で稼働する仮想マシンはネットマスクのロンゲストマッチを利用してB拠点側にいるということをルーティングマップにのせてやるようにルーティングプロトコルをうまく動かす。という形です。

（ネットワークの技術の話なので細かい部分は割愛です（汗）

こういう構成とすることで、

A拠点にいた仮想マシンをB拠点にCross-vCenter vMotion してやると、仮想マシン側の設定を何も変更せずに稼働させられ、且つ無駄な通信を省ける構成の完成です。

ご興味のある方、ご相談ください。

お仕事大歓迎です（笑

禁じ手？Cross-vCenter vMotionでvCenter Server Applianceを移行する

今回は、

「禁じ手？Cross-vCenter vMotionでvCenter Server Applianceを移行する」

というタイトルでお送りします。

2つのデータセンタのサーバ仮想化環境において、

NSXのVXLANでL2延伸してある環境をお使いのユーザさんがいらっしゃるんですが、

とある事情から片方のvCenter Server Applianceをもう片方にちょっと退避しなければいけないということがありました。

これまでは、その他の仮想マシンはCross-vCenter vMotionで移行したことはあったのですが、、、

果たして、Cross-vCenter vMotionでvCenter Server Appliance自体の移行は・・・できるのか？

結論、、、。

出来ました。

ただ、、、

移行した際の応答の無くなる時間の長さが、

他のサーバをやっているときよりも長かった気がして、もう、、、ドキドキでしたが

移行は可能でした。

それと、Cross-vCenter vMotionの問題ではないですが、

リモートサイトにvCenter Server Applianceを移行したことで発生した問題は・・・、いくつかありました。。。

• vCenter Server が応答しなくなることが頻発
  （vCenter Server Applianceは生きている）
• Veeam Backup ＆ Replicationでバックアップ取得後のスナップショット切り離しの失敗が頻発
• Veeam Backup ＆ ReplicationからvCenter Server への認証が突然できなくなるというのも頻発

そんなわけでリモートサイトから戻してみたところ、

上記3つの問題は全部起こらなくなりました。

うーん、、、何が悪かったのか、、、応答時間のレイテンシが増えたことで

2番目の話が起こるのは、VeeamのProxyサーバがスナップショットをマウントしているのをアンマウントする際にタイムアウトしてしまう・・・とかで納得できるんですが、、1番目と3番目は、、、なぜ起こるんでしょう・・・？？

ひとまず、、、再発が無くなったのでこのまま経過観察ですね。。。。