クラウドサービスとのL2延伸(備忘録的要素90%)

今回は、

「『クラウド』サービスとのL2延伸(備忘録的要素90%)」

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

 

うーん、端的に。。。揉めています(笑

「(笑 」、、、で済ませられる状況ではないんですけどね(笑(さらに)

 そんなこんなで今回は、まだ解決に至っていないので、

分析?している中でなんかおかしなことしてるなーというのを自分的にメモしておくための投稿です。

 

・問題点

クラウド』環境にL2延伸を行っているのですが、

フロントエンドーDB構成のフロントエンドサーバを『クラウド』環境に持って行ったところ、通信に問題が発生する。

(DBはオンプレに残っていてオンプレに残ったゲートウェイからルーティングをしている)

 

パケット解析を行ったところ、

『Out-Of-Order』のついたパケットがたくさん出てるんですよね。。。

うーん、out-of-orderが出ているということは・・・と、パケットが記録されている時間(および時刻)を確認していたら、、、

milliseconfd・・・のオーダーどころか、microsecondのオーダーで、

再送要求をして、その応答を受け取っているから・・・。『Out-Of-Order』のフラグがついているんですよね。。。

 

実際問題。

L2延伸したとき、この限定ではないんですが、クラウドに行くだけで、、数millisecondの遅延は有って然るべきなのに、microsecondで応答があるわけがない。

(と、現段階では考えています。)

 同じDC内だってルーターかませたら・・・普通に発生する遅延があるわけですからねー。

別ロケにある(はずな)のに(もしかしたら、、そのオンプレ環境がそのクラウドと同一DC内にあるなんてこともないこともないかもしれませんが、、、普通ないですよね(笑 )、こういうあり得ない動きになっているので。

と、いうか、同一ロケーションに居たって、別フロアになるわけですから↑の遅延で済むなんてのは有りえないですよね。。

(と思っているのが、既に古い知識なのかも・・・??というのもありますが。。)

 

ということで、、、。

今、疑っているのは、、、(あくまでも私見です)L2延伸の端(物理の環境とクラウドに延伸する際の境界ともいえる?)にいるこの端(edge)のコンポーネントがしている処理。。。

こいつがどういう処理をするのか。

メーカーさんからはL2VPN機器と同じ動きをすると聞いているし、

そうだとは思うんですが、実際の通信処理をどうやっているのか、、、まで分析しないと、『白』だとは言えないんじゃないかな??と思っている次第です。

 

 ご参考まで。

 

たぶん、次回は解決編になりますが、、、
上記の推測と全く異なった回答を書くかもしれません。笑
それはそれでネタになりますし、ご興味があればご覧ください。

ControlUp・・・Horizon8で標準監視ツール?になった(その1)

今回は、

「ControlUp・・・Horizon8で標準監視ツール?になった(その1)」

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

 

Horizon 8 からvRealize Operations Manager for Horizon (V4H)はサポート対象外となり、同様なことをやるためにはControlUp を使用することになっています。

 

VMware Horizon 8 に関するお知らせ、および価格設定とパッケージの更新 (80146)

https://kb.vmware.com/s/article/80146?lang=ja

 

今回、Horizon8向けではないですが、

ControlUpを導入する機会があり、いつも通りいろいろ・・・とあり、、、(問題あることが予定調和?)動かせるようにするまでの「あんなことやこんなこと」をご紹介します。

 

というわけで、、、

動作環境です。

1.サーバ用OS

モニター用のサーバのOSですが、日本語OSだと動かないスクリプトがあり、、、

プロジェクトの途中から英語のOSを調達してきてインストールし直しました。。。


あとから検証のために日本語OSの物を言語設定などなどをUSに全部変えても、、、動かず、、、うーん、何が直接的な原因なのかは不明なままですが、USのOSから言語を日本語化する必要がありそうでした。

 

2.監視対象への接続方法

DNSでの名前解決が必須、、、とのことです。

VDIでFloating割り当てにしている様な環境では、動的にレコードを更新させないことがあると思いますが、、、そういう環境ではControlUpからAgentを検出できなくなる可能性があります。。。


DNSの設定を触れるなら、設定を直す、、、もし直せないなら力技でもいいから名前解決できるようにする…というのが解決策です。

因みに今回のケースは、後者の力技で、『既存環境には影響与えず』に「どうにか」して名前解決できるようにしています。。

『メーカさんからは継続して解決できるならいいんじゃない?(大意な和訳)』とお墨付き?ももらえています(笑?。
ので、これを書いている7月末時点(実装して2週間経過してます)でも問題なく更新されて名前解決できるようになっているので、良しとしましょう。。

 

と、2つ書いただけで結構な文量になってしまってますので、

一旦ここまでにしておきます。

続きは、、、自分が書くか、一緒に対応してもらった方に書いて頂くか、、、は

ありますが、、、引き続き情報発信していきます。

 

因みに、、、

VMwareさんから買うと、、、

きっとこの辺のサポートもしてくれる!

たぶん、してくれるはず。

してくれるんじゃないかな・・・。

・・・ま、ちょと、(略)

さだまさしさんの某曲をオマージュ)

実際は、、、どうなんでしょう??

 

 

ご参考まで。

VMware vCenter Serverの複数の脆弱性(CVE-2021-21985、CVE-2021-21986)について

今回は、

VMware vCenter Serverの複数の脆弱性(CVE-2021-21985、CVE-2021-21986)について」

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

 

すでに公開されてから時間が経っておりますが、

・vCenterのプラグインにアクセスしてリモートコードが実行できる脆弱性

が公開されています。

脆弱性の深刻度としてCVSSv3(Common Vulnerability Scoring System v3.0)スコアは順番に9.8で、クリティカルに設定されています。


VMware社からはすでにFixedバージョンが提供されてますので、

そちらにアップデートが推奨されます。

が、基本的にvCenterを外部に公開している環境なんて、OnPremis環境ではほとんどないかな・・・?

とは思うものの、『直近で「色々」あった』ので潰せる問題は潰しておくのが良い。。。ですね・・・。

 

「外側の障壁を抜けられて、踏み台を掌握されたのが一番の問題」だったりして、、、
「普段攻撃を受けない、その後ろにある部分の脆弱性を突かれ」ても、
槍玉に挙げられるのは、被害の大きさに比例する…可能性が高いかな・・・と、
思う次第です。。

 

そんなわけで、情報はこちら 

VMware vCenter Serverの複数の脆弱性(CVE-2021-21985、CVE-2021-21986)に関する注意喚起

www.jpcert.or.jp

 

 

VMSA-2021-0010: What You Need to Know - VMware vSphere Blog

blogs.vmware.com

 

一番の対策は、アップデートです。

回避策も公開されていますが、vSAN環境だと弊害の方が大きい気がします。

(今回の対応はvSANプラグインを無効化することで、vSANのステータスが拾えなくなる。。。はず)

Pluginを無効化

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

 

ご参考まで。

【環境管理(支援)ツール】Runecastの使い方

今回は、

「【環境管理(支援)ツール】Runecastの使い方」

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

 

なんというか、、、

何とも弁解・弁明のしようがないのですが、

エンドユーザにご購入いただいていたのに、

うまく活用できていませんでした。。(2020年9月時点)

↑で書かせて頂いた、、、エンドユーザ様申し訳ありません。

 

ですので、、、!

 

その活用方法、事例をちょっとだけ書き残しておきます。

 

そもそもRunecastとは何か、という話から念のため書いておきますと、

(詳しくはメーカーやプロバイダー、システムインテグレーターのサイトをご覧ください。)

環境において、使用しているバージョンのパッチ情報や設定情報について推奨される情報、、、このパッチ出てますよとか、この仮想スイッチの設定はこうすることが推奨されますよ・・・とか、そういったものを教えてくれるツールです。

 

 

そんなわけで、件の使い方という話になりますが、

構築完了後、お客様に引き渡す際の第三者的視点からの品質担保!

そんな形で使えます。

 

セキュリティ的な部分で推奨される設定方法など、

メーカが公表している設定からずれている部分がピックアップされたりするので、

Runecastでスキャンする前はこうなってました⇒今こうなってます

ということを提示しやすいです。

 

具体的には

Runecastで1回目スキャン、出てきた結果をPDF化して保存、確認して対策実施。

Runecastで2回目スキャン、出てきた結果をPDF化して保存、1回目で出てきていた項目が消えていることを確認。

 

環境によっては、運用上消しきれない項目だったりがあるとは思いますが、

ユーザに合意を取るのに一覧化されて出てくるのは結構便利だと思う次第です。

 

上記はスポットでの使い方として書きましたが、、

定期的に運用していくというのが一番良い話なのは、、、もちろんです(笑

 

月1回とかでスキャン掛けて、項目が増えてないことを定期的に確認。

増えているなら定期メンテナンスで対応を行っていく・・という感じですね。

 

ご参考まで。

 

vSAN環境でのDisk障害対応について

今回は、

「vSAN環境でのDisk障害対応について」

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

 

vSANを利用している環境でローカルのストレージに障害が起こった場合、

従来の様にメーカと調整して、フィールドエンジニア(CE)の方に現地に来てもらってディスクを交換してもらうだけでは復旧しません。

 

そういう意味では、vSAN環境では障害時の復旧作業(運用作業)の難易度は高くなってしまっていると言えますかね。

某ハードウェアメーカの派遣したフィールドエンジニアの言うことを、確認せずに信じてしまったせいで、復旧するのにすごく、、、大変だった&時間が掛かった。。。というのもありますが・・・笑

 

そんなわけで、今回は公開されている情報でもありますが、

自分が今後対応しやすくするための備忘録的なことも含めて...な投稿です。

 

まず、、、どんなことを言われても、『交換対象のディスクをホストするvSANホスト』は、オフラインにしましょう。

(ここまで、ディスク、、、と書いてましたが、SSDだったらディスクじゃなくドライブですね。。笑)

 

状況によっては、ハードウェアとしてはオンラインのまま交換出来て、
IPMI系のツールだったりでは認識できたりするのですが、、、
ハイパーバイザーで交換したドライブを認識しないことが多々あります。

そうしたら、どうなるか、、、

一度ハイパーバイザーを再起動しなければいけないわけです。

 

で、、、あれば、最初から「再起動必要です。」というのと、vSANでの話なので
クラスタの中の他のハイパーバイザーにゲストOSは逃がしますから。」と、
言って、ユーザとの調整を図るべきかと思いますね。

(↑の話をするには、こういう時に使えなくて何のために
 「冗長性を持った構成で可用性を担保しているのか、、?」
 という話をユーザにも啓蒙活動しておいて、理解しておいてもらう必要はあるとは
 思いますが、、、。)

 

まぁ、ハードウェア故障の予兆検知だったりした場合には、
ドライブを手動でオフラインにしないといけないですから、、
安全性を考えたらこの意味でもハイパーバイザー的にもvSANとしての意味でも
ホストはメンテナンスモードにしてオフライン化しておくべきですね。。

 

そんなこんなで、グダグダ書かせて頂き、くどいですが結論は、

vSAN環境のハードウェア障害は当然のことながら、
サービス停止は無く(ゲストOSの停止は無く)行えます。

ユーザ様へは、最初からホストだけは停止します、というのは伝えておくべきでしょうね。

 

ちなみに、実際に交換時にやることは、

○ Capacity Tierの場合

  • 交換前に故障したドライブをvSAN管理画面から削除する
  • 交換する
  • (ホストの再起動も含めて)交換したドライブを認識したら
    Diskグループに組み込む

○ Cache Tierの場合

  • 交換前に故障したドライブが担当(?)していたディスクグループを削除する
  • 交換する
  • (ホストの再起動も含めて)交換したドライブを認識したらDiskグループを作り直して、CacheとCapacityを登録する

です。

 

ちなみに、多分、この作業は、、1時間で物理的な交換までやるには厳しいと思いますので、

VSAN.ClomRepairDelayの値を事前に変えておくことをお勧めします。

KBはこちらですね。

kb.vmware.com

 

ご参考まで。

バックアップ製品+バックアップ専用ストレージ

今回は、

「バックアップ製品+バックアップ専用ストレージ」

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

 

上記のタイトルで書き始めましたが、

具体的に言ってしまって...最近はvSphereの仮想環境バックアップで鉄板な感じの...

『Veeam社のVeeam Backup & Replication と、

DELL EMC社のData Domain』の話です。

 

Veeam Backup & Replication が、比較的、、vSphere仮想環境にメリットが
あると思っているし、

DataDomainも動き始めれば、、比較的問題もないし、、、

ということで、
さらにVeeamがどちらかというと仮想マシンのバックアップに良い製品だと
思っているので、

仮想環境のバックアップについては特に良い組み合わせだと思ってます。

 

と、メーカの太鼓持ちしても仕方ないので、、、
この組み合わせで色々と、、、苦労した件・・・してる件・・・+α(メーカと揉めた件・・・笑)を書いておきます。

 

まず!、この組み合わせ、

普通に使えば問題は起こりづらいです。(個人的私見

が、

 

問題点その1:

 

(早速+αから書いてます):
たしかに、

使い始められれば...、問題は起こりづらいです...。

と書いたのは、DataDomainが認定ベンダーにしか資料を提供しないという旧E社(D社ではなく)の方針?に基づいて行動されるので...、ファームウェアアップデート時に失敗したりすると、メーカからはサポート情報どころか…マニュアル等の一般的情報も得られません。

これは、納入された直後にファームウェアのバージョン変更に失敗した経験があるのですが…エンドユーザとして聞いてみても何の情報もくれませんでした...(ほんとにどういう風にメーカとしてサポートするつもりなのか・・・???)。

最終的に中間販社が認定ベンダーだったために、ドキュメント内の情報を教えてくれて復旧が叶い、納期までに無事納入でき…事なきを得たという状況でした。

(メーカには…『2度と売らないからな!』と、捨て台詞を吐きましたけどね(笑...

 

問題点1は私怨が多々に含まれましたが…、ちゃんと製品的な話をここから…

 

問題点その2:

 

両製品ともに、容量の削減機能を持っているためにどこでどっちの機能が利いているのかよく判らなくなる。。。

 

問題点その3:

 

両製品のフィージビリティの問題。

それぞれでバージョンが変わるときに足並みそろえて対応してくれない。。

2018年くらいの時でした...が、自分の場合には、DataDomain側が予想外に早くDDOSの新バージョンを公開した際に(4か月間)待ちに待っていたバグが修正されたというのに、Veeamが対応してくれず...、
しばらく放置せざるを得なかったという経験があります。
(他の製品も一緒ですね、これは。)

 

そんなわけで、問題点、、というか、
いつも通りハマった記録になってしまいました(笑

 

ご参考まで。

 

VMware製品の脆弱性(VMSA-2021-0002)について

今回は、

VMware製品の脆弱性(VMSA-2021-0002)について」

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

 

すでに公開されてから数時間経っておりますが、

・vCenterのプラグインにアクセスしてリモートコードが実行できる脆弱性
・ESXiのOpenSLPサービスでヒープオーバーフローからリモートコードが実行できる脆弱性

・vCenterにSSRF(Server Side Request Forgery)を仕掛けることができる脆弱性
この3点が公開されています。

脆弱性の深刻度としてCVSSv3(Common Vulnerability Scoring System v3.0)スコアは順番に9.8、8.8、5.3で、1個目はクリティカルに設定されています。


VMware社からはすでにFixedバージョンが提供されてますので、

そちらにアップデートが必要です。

 

ソースはこちら

https://www.vmware.com/security/advisories/VMSA-2021-0002.html

www.vmware.com

 

回避策も公開されていますが、

vCenterはvROpsのPluginを無効化

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

ESXiはCIMを無効化

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

 

弊害としては、Opsで情報が表示できなくなる。。

まぁ、当たり前ですね。

 

うーん、Ops使ってなければ、まずは回避策を実装しましょう。

 

ご参考まで。

手順なども後ほど整理して追記するかもしれません。