Autonomous Edge を構築してみた⑤ 注意点&発生した事象について
皆様こんにちは。
早いもので、2021年ももう1か月が過ぎてしまいました。
さて、今回でAutonomous Edge構築についての記事はおしまいです。
本来サポートされていないバージョンの基盤で利用したためか、
もしくは無理やりダウングレードをしたからか、下記のような事象が発生しました。
ー*-*-*-*-
①仮想マシン(Autonomous Edge)の「設定の編集」から見えるMACアドレスと、マシンのコンソールにログインして確認したMACアドレスが違う
→構築当初、L2延伸が切れたりつながったりと挙動が大変不安定になり、そのトラブルシューティング中に本件が発覚。手動でMACアドレスを変更して対応
②Active-Standby構成にならない
→お互いにもう一方の機器を認識できているものの、それぞれがActive側を奪い合うような動きをしてしまい、L2延伸がブチブチ切れる事象が発生
③セカンダリ側でしかL2延伸を張れない
→何度作成し直しても、セカンダリ側のマシンのみを起動させたときのみL2延伸が安定して貼られ、2台ともパワーオン、プライマリのみパワーオンの状態では挙動が不安定になる…という状態に
ー*-*-*-*-
かなり念入りに原因調査やトラブルシューティングを実施したものの、
結局②③の問題は解決できませんでした。
ダウングレード前のAutonomous EdgeをvSphere6.7の環境にて動かした際にはどちらの事象も発生しなかったので、環境依存の問題ではあるのでしょうが、モヤモヤ…。。。
結局本お客様環境では
・ホスト障害時はvSphere HAで保護する
・論理障害時は可及的速やかに復旧させる
という決めのもと、セカンダリのマシンのみでL2延伸を張る方針となりましたが、その状態で約8か月間、一度も障害等発生することなく、安定して稼働してくれました。
また、こちらは障害ではありませんが、
Edgeが稼働するESXiホストの設定によっても動きが不安定になります。(備忘)
Autonomous Edge でL2延伸をしたとき、挙動が不安定になることがありましたら、まずはここの設定を確認してみてください。
>esxcli system settings advanced set -o /Net/ReversePathFwdCheckPromisc -i 1
それでは、短いですが今回はこの辺で。
次回以降は、先月東京リージョンでのサポートが開始されたばかりの「VMware Cloud Disaster Recovery」を早速触ってみましたので、そちらについてご紹介する予定です。
Autonomous Edge を構築してみた③ Secondary機の構築
皆様こんにちは。
本年もよろしくお願いいたします。
本日は元旦ですが、時勢の影響で今年も帰省ができず、アイコンにもしているペットのワンコ(もうすっかり成犬ですが…)とともに2人でお正月を過ごしております。
さて、今回も前回に引き続き、Autonomous Edge構築手順の紹介です。
1台目のデプロイが完了したら、同じOVFテンプレートを使って2台目の構築を行います。
途中までの手順は1台目と全く同じですが、2台目(Secondary)のマシンの構築時のみ設定する項目があります。
では、早速構築していきましょう。
①1台目のAutonomous Edgeをパワーオンし、SSHで接続
※vSphereクライアントからのコンソール接続でもダメではありませんが、コンソール接続だとコピペができないので、SSH推奨です。
②admin ユーザでログインし、下記コマンドを実行
>get certificate api thumbprint
③コマンド実行結果をコピーして控えておく
④OVFテンプレートを展開し、1台目と同様に構築を進める
⑤「Secondary API Node」にチェックをつけ、下記4項目を入力
・Primary Node management IP
・Primary Node Username
・Primary Node Password
・Primary Node management Thumbprint(③でコピーしたもの)
⑥設定値を確認して「完了」
これで、2台の Autonomous Edge の構築は完了です。
この後は2台目のEdgeもパワーオンし、それぞれの管理コンソールにアクセスしてActive-Standby構成が組めていることを確認したら、vSphere Converter を使って仮想マシンHWバージョンをダウングレードします。
次回はそちらの手順をご紹介できればと思います。
Autonomous Edge を構築してみた② Edge構築環境と初期構築時の注意点
皆様こんにちは。
寒くなって参りましたが、いかがお過ごしでしょうか。
わたしの家の近くでは、昨日からハイカラな歯医者さんが赤と緑に光り始めました。
世間はもうクリスマスなんですね。
クリスマス商戦て、ハロウィン終了とともに始まるじゃないですか。
あわてんぼうのサンタクロースもびっくりのフライング具合ですよ。
なのに、終わりは1日たりとも猶予してくれないのは何故なんでしょうか。
たとえば今年、24日は木曜日、25日は金曜日ですよね。
平日も平日です。ド平日。
あと1日くらい猶予してくれてもバチは当たらないのではないでしょうか。
社畜だって、クリスマス満喫したい。
さて、そろそろ本題に入ります。
Autonomous Edge ですが、5.5環境に直接立てることは出来ないので、
①vSphere 7 の検証環境に立てる
②Converterでダウングレードする
③OVFエクスポートして 5.5 環境にインポートする
という順序で進めていきました。
須らく各手順に落とし穴が潜んでいて苦労したので、
1記事あたり1工程で、丁寧に進めていこうと思います。
では早速、Edgeを立てていきましょう。
①OVFテンプレートの選択
はい、ローカルファイルの選択からして、落とし穴があります。
↑の画像、ちょっと変ですよね。
「コピー」?って思いませんか?
こちら、vSphere 7 環境に構築しようとしたがゆえに引いてしまった問題なのですが、
My VMwareから落としてきたファイルをそのまま展開しようとすると、エラーが出て先に進めないんです。
なのでovfファイルの中身を手動で一部書き換えて、かつ、.ovf と .vmdk の二つだけを選択した状態で進む必要があります。(.mf と .cert は選択しない)
ちなみに修正するのは"sched.mem.pin"が記載されている行で、
中身をまるっと↓に置き換えます。
<vmw:Config ovf:required="false" vmw:key="memoryReservationLockedToMax" vmw:value="true"/>
その後しばらくは素直に、設定をいれつつ進みます。
②名前とフォルダ~ネットワークの選択
ここまでは、素直に設定を選んで進めばOKです。
ここの「名前」は、ダウングレードや 5.5環境に再デプロイするときに変更できます。
問題は次です。
③テンプレートのカスタマイズ
気をつけるべきはここ、「テンプレートのカスタマイズ」で設定する設定値です。
ここで設定した値は基本的に全て、
ダウングレードしようが、
OVFエクスポート→インポートしようが、
未来永劫変えられないと思っておいたほうがいいです。
一部頑張れば変えられるものもありますが、
IPアドレス、ホスト名、そういった主要な項目は一切出来なくなっています。
たちが悪いのもので、ダウングレードしてOVFインポートする際、
設定値がいじれる様に見えるんですよ。
普通に設定値を打ちかえられますし、エラーも出ませんし。
デプロイが完了してから気がついて涙です。
そして各設定値についても、1点嵌まったところがあって、それが↓です。
こういう、VLAN ID を入れるようなところが何箇所かあります。
このNWにすでに振られているVLAN ID を入れれば良いものと思い込んでいたのですが、実はそうではなく、
「ここで入れたVLAN IDを、そのNWに振ってやるぜ!」というシロモノでした。
なので、すでにVLAN ID が振られているNWを使う場合は、ここは「0(=VLANを振らない)」にするのが正解です。
※画像のわたしは見事に99を入れていますが、これは間違いです。
逆にVLAN IDが振られていないNWを使うときは、99でも何でも、任意の数字を入れてあげてください。
さて、このあとは設定値を確認して「完了」を押せばデプロイが始まります。
大分長くなってしまったので、今回はこの辺で。
次回はプライマリとセカンダリの設定項目の違いや設定値の入手方法などについて
お話できればなと思っています。
Autonomous Edge を構築してみた① HCX × Autonomous Edge 編
皆様こんにちは。ド文系です。
わたしは今、おそらくなかなかに革新的であろう環境の構築に勤しんでいます。
なのですが、壁という壁すべてにぶつかっているんじゃないかというくらい
躓き倒していて、証跡として取っているスクリーンショットがもう
あっち行ったりこっち行ったりで滅茶苦茶、見るも無残な状態となっております。
なので、正解ルートの整理ともろもろの備忘を兼ねて、
このところのわたしの活動をスクショと共にお届けしたいと思います。
HU○TER × HUN○ER 並みに完結しない可能性がありますが、気長にお付き合い頂けましたら幸いです。
今回は初回ということで、
何を実現したいの?どういう環境で使うの?
といった、前提条件について簡単にご説明したいと思います。
要件
・オンプレ仮想化基盤を、VMC on AWS に移行したい
・移行作業中に仮想マシンが停まるのは、メンテナンスウィンドウ内であればOK
・一度に全台移行するのは難しそうなので、
仮想マシンがオンプレとVMCとで行き別れになっている間も疎通が途切れない
ように、L2延伸をしたい
オンプレ基盤
・vSphere 5.5 Standard
さて、VMCに明るい方は、上記を見て、ん…??となったことと思います。
ーーー5.5 Standard で L2延伸…?無理では?
そうなのです。ご認識の通り、普通に行けば無理です。
というのも、L2延伸にはHCXを使うか、Autonomous Edge を使うか、2つの方法があるのですが、それぞれ下記が要件としてあるからです。
HCX 場合は分散仮想スイッチ(Standardライセンスでは使えない)が必須
Autonomous Edgeの場合は vSphere 6.5 以上が必須
また、Autonomous Edge による L2VPN環境で 実施可能な移行方式は vMotion のみで、こちらについても
・vSphere 6.7U2 以降
・vSphere 6.5P03 以降
のいずれかが必須要件となっているので、Edge案については、二重の意味で無理に思えます。
ただここで、あることに気がついたのです。
>Autonomous Edgeの場合は vSphere 6.5 以上が必須
この要件は、提供されている Edge の仮想マシンHWバージョンが 13 以上であるがゆえの要件であると…
え、じゃあ逆に、そっちをコンバーターで、 vSphere 5.5 で動くバージョン(10以下)まで、落としてしまえば良いのでは…?
ただそれでもやっぱり vMotion は無理なので、HCX も立てて、
L2延伸したセグメントめがけてBulk Migrationすれば完璧なのでは…?!
…と、いうことで、
HCX と Autonomous Edge のあわせ技への挑戦が始まったのでした。
そしてこの Edge がなかなか一筋縄ではいかず、冒頭に戻るわけです。
次回から早速、
Edge構築の手順をスクリーンショットで整理していきたいと思います。
※もちろんお客様環境ではなく、検証環境でのスクショなのでご安心ください
VMWorld2020_VMC関連まとめ②
皆さんこんばんは、ド文系です。
VMWorld2020 回その②になります。
前回に引き続き
VMWorld2020における、VMC関連の注目アップデートをご紹介して参りたいと思います。
今回はHCXのお話です。
HCXの機能強化
HCXについては大きく3つの強化ポイントがあります。
機能名称がやたらと長くて、それだけ見ても何のこっちゃ?という感じではありますが、いちおう全部書いておきます。
HCX Replication Assisted vMotion
HCX Mobility Optimized Networking
HCX Migration Planning With Mobility Group
この中のひとつ、「HCX Replication Assisted vMotion 」が、前回ご紹介した VMware Cloud Disaster Recovery 同様、わたしがずっと心待ちにしていた機能なのです。
これはかなり前に一度プレビューまで来ていたのに
いつの間にか使えなくなっていた機能で、エッどこ行っちゃったの?!と思っていたのですが、ここに来て無事実装と相成りました。
これはズバリ、「大量の仮想マシンを、無停止で一気に移行できるよ」という機能です。
これまでのHCXにはBulk Migration と vMotion という2通りの移行方式があったのですが、ざっくり言うとそれぞれ、
「複数台一気に移行できるよ、停止が発生するけどね」
「無停止で移行できるよ、1台ずつですけどね」
という仕様になっていて、あっちを立てればこっちが立たずな感じだったのですが、
今回実装された第3の手法により、死角のない移行方式が確立されたと言えるのではないでしょうか。
ちなみに残るふたつは、
Mobility ~のほうが ルーティング最適化の機能、
Migration ~のほうが 仮想マシンのグルーピングに関する機能
です。
この2つも何気に強力な機能で、これらの追加によって、
・移行した仮想マシンのルーティングテーブルを自動で更新したり、
・各アプリケーションの動作に必要な一連のVM群を特定して、
それらを自動でグループ化したり
することが可能になりました。
グループ化に関してはスケジュールを指定して移行をセットしたとき、
同じ時刻を指定されたマシンを同じグループにするといったことも可能とのことで、
オンプレからVMCへ段階的に移行するようなときにかなり使える機能だと思います。
珍しく真面目なブログとなりましたが、今回はこの辺で。
VMWorld2020_VMC関連まとめ①
皆様こんばんは。ド文系です。
英語問題を解決できないまま10月を迎えてしまったわたしではありますが、
無事VMWorldに参加して参りました。
もう、字幕機能のありがたさたるや!!!オンライン万歳!
直接日本語の字幕が出るのはGeneral Session だけでしたが、
ほとんど全部のセッションが英語字幕(自動生成)に対応していたので、
再生→字幕が表示されたら一時停止→すべてをDeepL翻訳に打ち込む→再生→字幕が切り替わったら一時停止→すべてをDeepl(以下略
という、ゴリゴリの力技で視聴しました。
(20分のセッションを再生しきるまでに4時間くらいかかりました、、、、、)
血と汗と涙を流しながら収集した、VMC関連のニュースをダイジェストでご覧ください。
まず、今回発表されたアップデートすべて纏めたものがこちらです。
厳密には初出でないものも混ざっていますが、全部で16個。
相当な量のアップデートですよね。
このジャンルに、いかに力を入れているかがよくわかります。
この中でも個人的に特に「うおお!!」となったのは、↓の2つです。
① VMware Cloud Disaster Recovery
② HCX の機能強化
これらについて、この記事と、次の記事の2回分を使ってご紹介していきたいと思います。
VMware Cloud Disaster Recovery
これは昨年の vFORUM で「DRサイト用の料金体系を今準備してるよ~」という話を聞いてから、ずっと楽しみにしていたアップデートなのですが、期待していた以上の完成度でのお披露目となりました。
これは一言でいうと、
「VMCをDRサイトとして利用できるようになったよ、従量課金でね」
というシロモノになります。
仕組みを簡単に描くとこんな↓感じで、
オンプレミス側にDRaaS Connector なるアプライアンスを立てるだけで、
「中間ストレージ」というクラウド上の中継拠点のようなものを経由して、
オンプレのデータをVMCへレプリケーションしてくれるんだとか。
費用は、1TiB単位で使った分だけ課金となるので、
通常のVMCをDRサイトにする(維持費年間400万円~)のに比べてコスパが格段に向上しますし、これはわたしだけでなく、全世界待望のアップデートだったのではないでしょうか。
東京リージョンが初期ローンチ対象外なのが残念ですが、
日本上陸の日を首を長くしてお待ちしております!
Horizon8 GA
皆様こんばんは。ド文系です。
いよいよHorizon8がGAになりましたね。
…ってえらそうに書いてますけど、GAってなんの略なんでしょう…
(調べました。General Availability の略だそうです。)
意味的には、
プレビューとか紆余曲折を経て、実際にお客様に提供できる状態になりましたよ、
ってことだと理解しています。
さて、ではHorizon7と比べて、大きく変わったところはどこでしょう。
わたしはHorizonにあまり明るくなく、細かい機能の話はちょっと自信がないので、
そんなわたしでも理解できた大きなトピックを4つ、ご紹介したいと思います。
リンククローンサポート終了
以降インスタントクローンがエディション問わず利用可能に
全EditionからvSANライセンス削除
VDIから快適にZoomやTeamsが利用できるように
V4Hがサポート終了、以降ControlUpが公式の監視ツールに
なかなかにインパクトのあるアップデート…?が揃っていますね。
全体的には、無駄というか、いらないと判断したものをそぎ落として、スマートな製品にした…という感じでしょうか。(個人的には、vSANをいらないと思ったことはないですけど、、、、)
インスタントクローンがエディション問わず使えるようになるのは良いのですが、
まだまだユーザも多いであろうリンククローンを完全に切るとは大分思い切ったなという印象です。
でも海外と日本とで、いろいろなものの使われ方が結構違うと聞きますし(L2延伸なんてものを喜んでるのは日本くらいだ!とか)、海外的にはリンククローンは終わったコンテンツなんでしょうか…
インスタントクローンはリンククローンの後身といえど、細部が結構違っていた記憶があるので、Horizon7サポート終了時はなかなか大変なことになる予感がします。
VDIからのリモート会議が快適になるのは、在宅勤務民としては素直に嬉しいですね!
短いですが、今回はこの辺で。