NSX-Tを実装しました（いつもどおりの紆余曲折あり・・・）（２／２）

今回は、

「NSX-Tを実装しました（いつもどおりの紆余曲折あり・・・）（２／２）」

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

前回の続きで、今回は前回お話したオーバレイを何故組まなければいけないという結論に至ったのか、、、という部分と、よく解説されているNSX-Tの基本的な動作の仕組みとの隙間を埋められれば、な感じでの話です。

（繰り返しですが、あくまでも自分が理解したイメージの様な話で、メーカ公表の正確な表示とは異なるかもしれませんが、理解する助けになるかもしれない、、、と書いてます。）

NSX-Vであれば、
Edge Service Gatewayをデプロイして、これを仮想のネットワークアプライアンス（Citrix ADC（旧NetScaler）などなど、、、）の様に単独のサービス提供者として使えばよかったわけですが、

NSX-Tは、、、

同じ名称？のEDGEは、、、立ち位置が違うんです。

何というか、そもそもNSX-TのEDGEは『Tier-0』、『Tier-1』Gateway（論理ルータ）というサービスを実行するための基盤（ハイパーバイザー的・・・）として動くんです。

上記を前提としておいて、
更に追加の条件として、NSX-Tでのロードバランサのサービスは、
Tier-1Gatewayにホストしなければいけない。

その為、NSX-Tのロードバランサを動かすためには、
Tier-1Gateway を正常に動かす＝EDGE（T1、T0の動作基盤）を正常に動かす。

そのEDGEを正常に動作させるためには、

オーバレイ用セグメントと、VLAN用セグメント（サービス用）をそれぞれ用意しておかないといけない。。。

と、逆順に書いていった結果、

そんなに難しい話ではなく、当たり前な話になってますね（笑

うーん、とはいえ、、、

参考にしてくれる（参考になる）方はきっといると信じましょう。

ちなみに、もう一つ余談ですが、

上記の様にEDGEとTier0、Tier1で組んだネットワークは論理ネットワーク内に構成されるんですが、バランス対象のサーバは論理ネットワーク内に組み込み必要はありません。

これも、、、論理ネットワークの中にバランス対象のサーバたちも組み込んで作らないといけないんじゃないか？と、途中で悩んでいたりもしたので、そこら辺を悩んでる方のために書いておきます。

Tier-1（およびサービス）をTier-0からルーティングなりNATなりで通信できるようにしておけば、これは問題ありません！

ご参考まで。

NSX-Tを実装しました（いつもどおりの紆余曲折あり・・・）（１／２）

今回は、

「NSX-Tを実装しました（いつもどおりの紆余曲折あり・・・）（１／２）」

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

（※多分に私見（偏見？）を含んだ話で、某サイトであれば『要○○』が付く感じです（笑）

とあるユーザさんでNSX-Vで作られていたVDI環境を
新たに作り直すという案件で、

やることとしては、分散ファイアウォールを使ったマイクロセグメンテーションと、
管理系サーバの負荷分散をするための負荷分散装置を利用したい。
と、いう話だったんですが、、、タイトルおよび冒頭のとおり紆余曲折ありました。

そもそも、

なんというか、NSX-Vは正直いうとサーバを少し触れるネットワークエンジニアなら簡単に触れます（暴言？）、、、が、それは何をやらなければいけないというのが目に見えている（物理の考え方に近い・・・）のが大きいと思います。

それに対して、

NSX-TはSDN（Software Defined Network）を前提にした概念が必要な感じで構築しなければならず、、、オーバレイを考慮しておかないとうまく動かない、、、様に思えました。

NSX-Tの組み立て方的な話を公開されている方々は沢山いらっしゃるんですが、

この辺のどういうことを考えながらやらなければいけないかというのを書いてくださっているサイトは見つけられなかったんですよね。
（誤解が無いように、、、↑ディスっているわけではなく、
　『手順として』こういう風にやればいいというのは大変役に立ちました（汗）

そんなわけで、他の方々が直接的に書いていない部分を埋める的な話で、書いていきます。

（ノウハウだから書かないのかもしれませんが・・・(笑）

端的に、

一番困ったのが、冒頭の要件を満たすために何をしたらいいのか。

自分が至った結論としては、、、

「NSX-Tを動かすために最低限の環境を準備しなければいけない。」

この最低限、、、が、どこまでやればいいのかを見つけられなくて困ったんですよねー。

勿体ぶってもしかたないので、

『NSX-TでOver-Layネットワークを組んでおいて、その上で様々なネットワークサービスを提供する。』んです。

これ、、、結構重要だと思うんですよね。

自分の様にNW畑出身で、NSX-V使っていた人間としては、
仮想のネットワークアプライアンスくらい普通にデプロイしてくれればいいのに、って思ってしまうと思うので、『なんで、コレ（このサービス）が動かないんだ？？』ってなることが多いんじゃないかと、、、。

長くなってしまいそうなので、２回に分けますが、、、

次回も宜しければご覧ください。

ご参考まで。

vSANデータストアに関する障害の話

今回は、

「vSANデータストアに関する障害の話」

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

結構前にエンドユーザ様環境で発生した障害の話なのですが、

vSANのデータストアが溢れました...。
（溢れた…という表現が妥当なのかというのはあるのですが、、、。）

その当日、大分容量の大きな仮想マシンを
他のデータストアから移行してきていた様で
vSANデータストアとしての全体使用量は
溢れるところまでは行ってなかったのですが75%を超えていて、、、
それよりも問題はvSANクラスタの中の特定ホスト数台のDiskに
データが集中してしまい、該当のDiskの使用率が
100%になっていたという状態でした。

実害としては、

該当のディスクにデータ（オブジェクト）がある仮想マシンは
データストア内（ディスクに対して）で空き容量が無いために、
Suspendに近い状態となって動作しない状態となり、、、
vSANクラスタ内の仮想マシンに対して、かなり影響の大きい話となっていました。

動作的にはリバランスが必要になったホスト（ディスク）から
データを退避させるのにまず空きが必要なのに、
使える領域が少なくなってしまって
リバランスの処理が全く進まず、、、
という悪循環を繰り返していたような感じでした、、、。

このような状況から、、、
出来ること（メーカサポートからも言われたこと、、）というのは
『空き容量を確保してください』なわけで、

そして、
焼け石に水かもしれないとは思いながらも、
不要なデータ（各種OSなどのインストール用ISOや停止されている旧システムのVMDKなど、、、）を削除して、
少しでも容量を確保しつつ、リバランスが終わるのを
ひたすら、、、ディスクの状況を見守りながら待つ。

そんなわけで非常に幸運なことに
無事、、、データロストは無く復旧できたことから
リバランスの処理は遅々としてではあったものの
きっちりと動いていたんだなーと、再認識されられたとともに、、、

75%は超えないように運用するのが必須です、と、
改めてユーザ様には認識して頂かなければ、、、と、

ココロに決めさせられた事案でした。

いやー
本当に二度と遭遇したくないような障害でしたね。。

ご参考まで。

DCに居たら、停電してサーバルームが・・・

今回は、

「DCに居たら、停電してサーバルームが・・・」

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

ちょうど本日某所のデータセンタに居りまして、

12時52分ごろ、、、サーバルームが真っ暗になりました・・・。

↑

東日本旅客鉄道株式会社（JR東日本）さんの変電所で12時50分に火事があったらしく、その影響で周辺の送電網でも電圧低下が発生し、給電に影響したようですね。
（DC側で受電系統を切り替える際に、、、断したんですかね・・？）

今回は、

サーバ等の機器が接続されている電源はCVCF等で保護されていたのでしょう、、、ということで影響は無く、

作業しようとしていた我々が、え？え？？と、、、「窓のない部屋で真の暗闇・・・（サーバのLEDだけは見えましたが・・・）」に陥り、慌てていた？だけでした。。。

因みに、エアコンも止まってましたね。。

まぁ、、、

照明やエアコンは、、最悪自家発電設備（自家発）起動までの間、落ちても問題ない、、、ということなんでしょうね。
データセンタのファシリティ関連も含めてサービス化するために、入社当時の1年目に色々見てましたが、、、普通？10分以内には自家発が立ち上がるらしいですから、エアコンも止まっていても冷却性能に問題が無い（システムが止まる温度まではマシン内の温度が上がらない）ということなのでしょうね。。。

うーん、
クラウドなどなどの話を商材にはしてますが、
やはり物理的に問題が起きれば障害起きてシステムダウンするんだろうなーというものを目の当たりにしてきた日でした。。

因みに、古い？技術者（として？）の発言に取られてしまうんでしょうけど、、、

昨今クラウド化は進んではいますが、、、

インフラをやられる方は電機？電器？の基本的な話は知っておくと

障害原因の分析やらクラウド業者やDC事業者の説明のおかしなところにも気づけたりすると思うので、、、、、、

「非常～～」にFundamentalな部分だとは思いますが、知っておくべきだと思います。
（因みに、、、学生時代に研究室で分電盤の大元の方落としたり、、、色々やらかしたことあるからこそ、、、の発言です。。笑）

因みに、DC事業者さんが電力の使用量で、分電盤や回路ごとのブレーカ容量よりも少ないのにご指摘をされるのは、、、『何か』があったときに自家発に切り替えるまでのCVCFやUPSの容量が問題なんでしょうねー。。想定より使われてると、、、10分持たずに、、、。
・・・・・・
・・・。
多くは語りますまい。。。

これは当たり前の話ではありますが、、、

アプリよりな方がたは意識してないですし、、、

我々インフラ屋も改めて気にしてないといけないですね・・・。

ご参考まで。

VMware製品の基本、、、vSphereの機能について

今回は、

「VMware製品の基本中の基本、、、vSphereの機能について」

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

ポイントとしては、移行と、vMotionと、HAの話です。

自分が所属するグループの新人には、私が昔よく説明をしていた話でもあります。

うーん、社内の技術者？？？（敢えて3個ほど付けました笑）・・・
への愚痴も含んでの話になりますが、、、

エンジニアがちゃんと整理できてなくて話をされたがために混同させられてしまったエンドユーザ様もいるかと思い、そんなユーザさまのために敢えて書いておきます。
（↑この発言は夜道に気を付けないといけないパターンです(笑 ）

よくあるパターン

・vMotionとHAを混同している

・vMotionと「VMの移行」を混同している

上記は本当に「よくあるパターン」だと思います。

そもそも、vMotionとは、、、、、、

『仮想マシンのライブ マイグレーション
vSphere vMotion
vSphere vMotion を使用すると、サーバ間でのワークロードのライブ マイグレーションをダウンタイムなしで実行できます。ユーザーはシステムを継続して使用できるため、生産性を維持できます。』

www.vmware.com

そう、あくまでも『ライブ』マイグレーションなんですよ・・・。

と上記を踏まえて頂き、、、

これもよくある

『ホスト障害が発生した際に何故「vMotion」でマシンを保護できなかったのか？』

という質問に対しては、

vMotionはメモリ状態も移すからダウンタイムほぼゼロでホスト間を移行出来るものなので、

突発的に発生するホスト障害などでメモリ状態を移行できない状況では、vMotionはそもそも使えません。

『vSphere HA』は、突発的な障害などで仮想マシンを『再起動して』保護するものです。（大意）

ものすごく雑な感はありますが、、、

vMotionと、HAの違いは上記がポイントです。

あと一点、付け加えてですが、

仮想マシン（VM）をホスト間で移行する機能については、

VMwareだけではなく、仮想化そもそものポイントである可搬性の特徴でもありますが、物理ホスト間を移行しやすい、、、わけで、

「vMotionを使わなくても」普通に「移行」できます。

もちろんこれは、VMwareではvCenterがいれば、vSphere Client（GUI）でお手軽にできますし、いない場合やvCenter自身をオフラインで移行したいなどのときは、vmdkやvmxなどの必要なファイル（フォルダ）をマルっと移動して、インベントリに登録し直すとかでもいいわけです。

そんなわけで、言葉の定義の解説でした。

 ご参考まで。

クラウドサービスとの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を導入する機会があり、いつも通りいろいろ・・・とあり、、、（問題あることが予定調和？）動かせるようにするまでの「あんなことやこんなこと」をご紹介します。

というわけで、、、

動作環境です。

１．サーバ用OS

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

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

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

２．監視対象への接続方法

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

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

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

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

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

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

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

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

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

因みに、、、

VMwareさんから買うと、、、

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

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

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

・・・ま、ちょと、（略）

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

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

ご参考まで。