tokyo-wasted’s diary

しがないインフラエンジニアが、余り役に立たない情報を載せていきます。

VMware Cloud on AWS で Veeam バックアップを使う

この投稿は vExpert Advant Calendar 2018 に参加しています。
=====================



こんにちは

初めて vExpert Advant Calendar 2018 に参加させて頂いております。
12月24日という大事な日のわりに、記事内容は大したことありませんのでご注意ください。

VMware Cloud on AWS に足りないもの

物理サーバ、ネットワーク機能、ストレージなど仮想化環境に必要な機能が一通りそろってる VMware Cloud on AWS ですが、実サービスでの利用にあたってはサードパーティ製品が必要になります。
大きくはアンチウィルスとバックアップが挙げられます。複数のセキュリティベンダー、バックアップベンダーが VMware Cloud on AWS対応を発表していますが、本記事では Veeam社の Veeam Backup & Replication 9.5 によるバックアップを取り上げます。

Veeam を VMware Cloud on AWS で動かす

基本構成

VMware KB で公開されているドキュメントが一番わかりやすいです。

kb.vmware.com

本記事では簡易デプロイの構成で行い、とりあえず Veeam Backup Server 上にバックアップを取得するところまで進めます。


構築手順

1. VMware Cloud on AWS SDDC の作成

VMware Cloud コンソール画面へログインし、SDDC を作成します。

f:id:tokyo-wasted:20181223154201p:plain
Tokyoリージョンを選択、いちばんお安い Single Host で進めます

f:id:tokyo-wasted:20181223154156p:plain
AWS アカウントと紐づけます

f:id:tokyo-wasted:20181223154153p:plain
Tokyoリージョンに作成されている VPC と Subnet を選択します

f:id:tokyo-wasted:20181223154148p:plain
vCenterなど管理サーバのネットワークを指定します。デフォルトで良ければ空欄でOK

「Deploy SDDC」を押して 1.5h ~ 2.0h ほど待つと SDDC が完成します。
※今回の環境は NSX-v ではなく NSX-T で動作しています。

2. Veeam Backup Server の作成

f:id:tokyo-wasted:20181223155035p:plain
Veeam Backup Server が動作する Windows Serverを作ります。仮想マシン作成ができるリソースプールは「Compute-ResourcePool」のみ。

f:id:tokyo-wasted:20181223160441p:plain
Veeam公式ページから ソフトウェアの 評価版 ISOファイルをダウンロードします(要アカウント)

ダウンロードは こちらのページ から。
30日間の評価版ライセンスファイルも一緒にダウンロードします。

f:id:tokyo-wasted:20181223161048p:plain
ISO をマウントしてインストールします

f:id:tokyo-wasted:20181223161504p:plain
エラーがでますけど「Install」をクリックで修復してくれます

f:id:tokyo-wasted:20181223161807p:plain
インストールできました

f:id:tokyo-wasted:20181223161919p:plain
デスクトップにできるコンソールのショートカットから管理コンソールに接続できればOK。


3. Veeam Backup Server と 管理ネットワークの接続

VMware Cloud on AWS の環境では、管理ネットワーク と コンピュートネットワークがあります。
デフォルトでは接続できないので、ゲートウェイファイアウォールルールを変更して必要な通信を許可します。

f:id:tokyo-wasted:20181223163355p:plain
VMCコンソールに表示される 2つのネットワーク(NSX-T)

Veeam Backup Server から vCenter や ESXi への通信を許可します。

【参考】NSX-v では、各ネットワークに異なるゲートウェイ(NSX Edge) が作成され、以下のように異なるグローバルIPが付与されます。
この環境で2つのネットワークを接続するにはゲートウェイ同士で IPsec-VPN を張る必要があり、とても微妙な環境でしたが NSX-T では IPsec-VPN は不要になりました。

f:id:tokyo-wasted:20181223171941p:plain
ちなみに NSX-v 環境は上記のように各ネットワークで異なるグローバルIPが付与されます


[vCenter Inbound] と [ESXi Inbound] という2ルールを作成しました。[compute1] は Veeam Backup Server のネットワークです。

f:id:tokyo-wasted:20181223165019p:plain
管理ネットワーク FW設定

[outbound] という大雑把なルールを作ってます。

f:id:tokyo-wasted:20181223165852p:plain
コンピュートネットワーク FW設定

コンピュートネットワークから vCenter に接続させるので、FQDN設定を変更してプライベートIP アドレスを返すようにします。

f:id:tokyo-wasted:20181223170358p:plain
vCenter FQDN の設定変更



4. バックアップしてみる

Veeam Backup Server で [Inventory] を選択し [VMware vSphere] から VMware Cloud on AWS の vCenter Server を接続します。

f:id:tokyo-wasted:20181223172607p:plain
Veeam Backup Server から vCenter を登録

[Inventory] に vCenter のインベントリが表示されますので「Compute-ResourcePool」にある仮想マシンをバックアップ。

f:id:tokyo-wasted:20181223173200p:plain
[Inventory] からバックアップする仮想マシンを選択

問題なく完了しました

f:id:tokyo-wasted:20181223173638p:plain
バックアップ完了しましたー


f:id:tokyo-wasted:20181223174147p:plain
仮想マシンのスナップショットが作成されている様子

※vCenterなど管理サーバのバックアップは権限がないためバックアップできません

まとめ

ネットワーク設定でいくつかポイントがありますが、数時間もあればバックアップ環境を構築することができます。

実環境では VMware Cloud on AWS の障害を考慮し、Backup Repository を AWS側(そして複数AZ)に配置するのが望ましいので、次回はそこら辺を設定してみます。

VMware Cloud on AWS にNSXがもたらすネットワーク機能

こんにちは。

VMware Cloud on AWSサービスが2018年の VMworld で正式リリースされてからもうすぐ1年が経とうとしています。最初は北米オレゴンのみの提供でいしたが、右回りに地球をぐるりと回ってリージョンがオープンし続けており、ゆっくりと日本に近づいてきています(日本でのリリースは2018年の予定)。

 

この記事では、次々に進化する VMware Cloud on AWS の機能の中から、ネットワーク仮想化の NSX にフォーカスして、今後のロードマップを覗いてみます。

 

VMware Cloud on AWS におけるNSXの役割

VMwareが提唱しているSDDCは以下のように大きく3つの製品が柱になっています。そのうち VMware Cloud on AWS でネットワーク機能を提供しているのがNSXです。なかなか実際のSI案件ではNSXがもつ機能をフルスタックで使う機会には巡り合わないのですが(笑)。

 

具体的には論理スイッチによる仮想マシンへのL2ネットワーク提供、論理スイッチ間をルーティングする論理ルータ、NSX Edge によるvCenter や仮想マシンへのアクセス制御、オンプレミス環境との IPsec-VPN や L2VPNなどなど。実際の画面を踏まえた説明は別記事にしますが、NSXがもつネットワーク機能がこれでもかと使われています。

f:id:tokyo-wasted:20180618012311p:plain

 

いまの NSXが提供できていないもの

 VMware Cloud on AWSNSX が活躍していますが、「分散ファイアウォールは?」「自分でNSX Edge作成できないの?」「ロードバランサがなんでないの?」という疑問がでてきますよね。

執筆時点では、NSXが提供する機能は限定されており(Simplify Modeと呼ばれる)、NSX Managerへのアクセスはできない形でサービス提供がされています。今後のロードマップでは NSX が持つ機能が開放されていく事になっていますが、どんな機能が追加されるのかは公式サイトにしっかりと記載されているんです。

 

https://cloud.vmware.com/vmc-aws/roadmap

 

 このロードマップでは VMware Cloud on AWS の機能を紹介しながら、その機能がすでに提供されている(Available)なのか、試験的な提供(Preview)なのか、開発中(Developing)なのか、あるいは予定されている(Planned)のか、ご丁寧にステータスが書いてあるのです。

 

f:id:tokyo-wasted:20180618011732p:plain

上位に書かれている機能はほとんどが提供済み(Available)

 

見ていくと、Distributed Firewall の文字が確認できますね、ちゃんとロードマップにあるようで安心です。その他にもロードバランサや、IPsec-VPN冗長化機能なども記載されています。

個人的に、次の大きな機能拡充は以下かなと思いました

Connectivity within SDDCs

Enhancing connectivity within SDDCs enables automation and partner solutions. Native connectivity across workloads, management appliances (i.e., vCenter Server), and ESXi hosts, improving performance and throughput and simplifying configuration for automation and backup-restore solutions.

アンチウィルスやバックアップなど、サードパーティベンダーで提供されていた機能がまだまだ VMC on AWS には足りません。ここらへんが揃ってくると、いよいよ 本格的なハイブリッドクラウドへの移行が現実味を帯びてくる気がします。

 

それではこのへんで。

 

VMware NSXファミリーのリブランドが発表されました

VMware社のNSX製品ファミリーがリブランドされました。これに伴って、NSX for vSphereのライセンス構成も変更になりました。今回の変更について簡単にまとめてみます。

新しいNSXポートフォリオは以下のようになっています。緑色帯の下の部分がリブランドされた製品構成で、5つに分類されています。

f:id:tokyo-wasted:20180630023758p:plain

 

NSX Data Center

 これまでのVMware NSXNSX Data Center に名前が変更されました。ライセンスエディションごとの機能は最後に載せています。

 

NSX Cloud

 オンプレミスのNSXによる管理性やセキュリティポリシーを、パブリッククラウドにも適用します。NSX Data Centerとおなじ管理プレーン・制御プレーンを利用することで、パブリッククラウドでも同じコンプライアンスに準拠してアプリケーションを動作させることが可能になります。

 

・AppDefence

 仮想マシン上のアプリケーション状態をモニタリングし情報を収集し、機械学習を利用してアノマリーを検知しセキュリティプロファイルを保つことができるようになります。まだ日本ではサービス開始していないと思いますので、これからの動向に注目ですね。

 

NSX SD-WAN by Velo Cloud

 VMware社に買収されたVelo Cloudが NSX SD-WANとしてリブランドされました。VMware としてはソフトウェアの提供のみになるそうです。ライセンスのエディション(Standard/Advanced/Enterprise) と回線帯域によって価格が変動します。

 

NSX Hybrid Connect

 仮想マシンの移行に利用することができ、WAN回線高速化やL2ネットワーク延伸も行うことができます。HCX(Hybrid Cloud Extension) と呼ばれ、NSX Data Center のEnterprise Plus には含まれています。VMware Cloud on AWS にも含まれています。

 

簡単にNSXファミリーをまとめてみましたが、今のところもっともお目にかかるのはNSX Data Centerになります。新しいライセンスエディションは以下の通りになります。

Professionalが新設され、VPNなどこれまでEnterprise で提供されていた機能が含まれるようになりました。Professionalに分散ファイアウォールが含まれるので、ロードバランサが不要であればこちらを選択する機会が増えそうですね。

 

  Standard
(ネットワーク仮想化)
Professional
ファイアウォールと接続性)
Advanced
(高度なサービス)
Enterprise Plus
(管理性、ハイブリッド性、セキュリティ)
ROBO
(支店・支社向け)
分散スイッチと分散ルーティング
(スイッチ機能のみ)
NSX Edge ファイアウォール
NSX Edge NAT
物理環境へのソフトウェアL2ブリッジ  
ECMPによるダイナミックルーティング
(アクティブーアクティブ)
クラウドマネジメントプラットフォームとの連携
分散ファイアウォール  
VPN(L2およびL3)  
NSX Cloud との連携  
NSX Edge ロードバランサ    
分散ファイアウォールとの連携
(AD連携、AirWatchおよびサードパーティー製品との連携)
   
Application Rule Manager    
コンテナに対するネットワーキング&セキュリティ      
マルチサイトにおけるネットワーキング&セキュリティの最適化    
ハードウェアVTEPとの連携      
エンドポイントの監視        
レイヤー7ファイアウォール
(アプリケーションおよびRDSHセッション)
       

【VMware Cloud on AWS 】VMCコンソールでできるネットワーク設定

2つのVMware Cloud on AWS 管理画面

VMware Cloud on AWS を利用する場合、大きく2つのコンソール画面が提供されており、操作できる内容は異なっています。

 

  1. VMCコンソール
    https://vmc.vmware.com にアクセスすることで利用できる管理画面。登録しているVMwareクラウドサービスを俯瞰して操作できる管理ポータルで、VMware Cloud on AWS もそのサービスの1つになっています。

  2. vCenter Server
    ご存知の通りvCenter Serverの管理画面がそのまま提供されます。オンプレミス環境でも使い慣れたvCenterを利用できるので、クラウドサービスでありながら違和感なく操作をすることが可能になっています。

 

この記事では、VMCコンソールで利用できるネットワーク機能についてご紹介します。

 

VMware Cloud on AWS におけるNSXの制限

本題に入る前に、VMware Cloud on AWS の環境でNSXが果たしている役割について簡単にご紹介します。下の画面は VMware Cloud on AWS のvCenterにログインした時の画面です。

リソースプール「Mgmt-ResourcePool」の中にvCenterやNSX Manager/Controllerがでプロされているのが見えます。そして「SDDC-CGW」と「sddc-mgw」という仮想マシンがペアで計4台デプロイされています。これはNSX Edge で動いており、"-0" や "-1” とあるのは2台のNSX Edgeで冗長化されていることを示しています。 

f:id:tokyo-wasted:20180630040911p:plain

 

NSX Edgeの設定ですが、オンプレミス環境と同じ手順で vCenterメニューから Networking & Security を選ぼうとしても、項目自体がありません。現在のサービス仕様ではNSX Managerは使用することができないためです。

f:id:tokyo-wasted:20180630041448p:plain

 

VMCコンソールで設定できるネットワーク機能

 vCenterから設定できないNSX Edgeですが、VMCコンソールから設定することができるようになっています。

VMCコンソールでネットワーク設定画面をみると、以下のネットワーク図がでてきます。vCenterで確認した「SDDC-CGW」が Compute Gateway、「sddc-mgw」がManagement Gateway ですね。

f:id:tokyo-wasted:20180630042527p:plain

 

Edgeファイアウォール

Compute と Management それぞれでファイアウォールを設定ができます。デフォルトでは「All Deny」になっているので、vCenterにアクセスするにもまずはファイアウォールで許可してあげる必要があります。

難点としては、1ルールに対して紐づけられるサービスが1つなので、例えばHTTPS と ICMPを許可したい場合は2ルールになってしまうので、ここら辺は改善して欲しいですね。

f:id:tokyo-wasted:20180630044317p:plain


IPsec-VPN

IPsec-VPNも簡単に設定ができます。オンプレミスのvCenterと連携する場合などは必須の設定です。IPsec-VPNのステータスも確認できるので、Phase1 でコケてるのか、どんなエラーなのかも確認ができるようになってます。

ComputeとManagement のどちらでも設定が可能です。f:id:tokyo-wasted:20180630045440p:plain

 

L2 VPN

Compute向けに L2VPN機能も提供されています。L2VPN Serverとして動作するので、接続する側は Client としてつなげます。 オンプレミスのNSXが入っていれば NSX Edge を使えますし、NSXがなければ無償の Standalone Edge を使うこともできます。

HCXを使ってL2延伸もできますが、標準機能だけでもできますよ。f:id:tokyo-wasted:20180630050240p:plain

 

Public IP / NAT

Public IPをVMCコンソールから簡単に追加できます。ただし追加費用が発生します。

発行した Public IP に対してNAT設定をすることで、仮想マシンへのアクセスができるようになります。

f:id:tokyo-wasted:20180630051209p:plain

 

 というわけで、VMCコンソールでから設定できるネットワークについて説明してみました。

 

 

 

 

 

 

re:Invent 2017 で VMwareのクラウドサービスがさらに進化!

こんにちは。

最近 VMwareだけではなく AWSビジネスにもかかわるようになりました。
その一環で、初めてAWSの Tech Eventである re:Invent 2017 に参加してきました。

f:id:tokyo-wasted:20180119192235j:plain


今回VMware関連のサービス発表で VMware Cloud on AWS の機能追加発表がありましたので紹介します。

vCloud Airなど、これまで VMwareクラウドビジネスに挑戦してきましたが、なかなかうまくいっていない部分がありました(撤退・・・)。
そこで VMwareがとった驚きの一手は、クラウドの巨人AWSとの協力し VMwareクラウドを提供する「VMware Cloud on AWS」でした。VMC on AWSが発表されてから1年、やっと北米でサービス提供が開始されましたが、さっそく今回の re:Invent 2017 で進化しました。

まず、サービスローンチ時に提供されていなかった「オンプレミスのvSphere環境から vMotionして VMC on AWS仮想マシンを移行する」という目玉機能ですが、早くも追加されました! 距離のある Cross-vCenter vMotionという感じですが、これがサポートされたことでオンプレミスからクラウド移行の選択肢としてかなり有力になりました。実際には仮想マシンサイズやネットワーク遅延などを考えて、かなり検証が必要になる機能ですが、早く検証してみたいですね!

次に、オンプレミス環境との接続はこれまでVPN接続のみがサポートされていましたが、AWS Direct Connect(Dx) による接続がサポートされました。 Dx接続によってキャリアが帯域保証する安定した回線を使えるようになり、オンプレミス環境とのトラフィック品質についてユーザの懸念を払しょくできるようになりそうです。

そのほかにも、これまでの最大ホスト台数16台が倍の32台になったり、課金制度が従量課金だけではなく1年・3年のサブスクリプション選択が増えより低料金で利用できるようになったりと、サービスの拡張が行われています。

f:id:tokyo-wasted:20180119193240p:plain

今回のアップデートは 「マイルストーン2」と呼ばれているそうです。
日本でのサービスローンチが2018年の末ごろになるそうですので、それまでにも複数のマイルストーン更新で進化を続けていきそうですね。

個人的には、最小のESXiホスト台数を 4台から 2台とか3台にしてほしいのですが・・・・笑


それでは!

Nested ESXi 構築時のレシピまとめ (vSphere 6.5 + vSAN)

物理サーバ上に ESXi をインストールすることで WindowsLinux などのOSを仮想環境上で動かすことができます。 しかし、ESXi を自体も仮想マシンとして作成することで、ESXiのインストール手順やアップグレード手順などを検証することができるようになります。 また、複数のESXi を用意して vSphere HA や vMotionなどの機能も検証することもできるようになるので、勉強するにはもってこいの機能です。 ESXiを動かす環境を用意するには物理サーバが必要ですが、この方法であれば少ない物理サーバであっても大丈夫です。
このように仮想マシンとしてデプロイされる ESXi は「Nested ESXi」などと呼ばれ、VMware製品の検証環境を作る定石になっています。

Nested ESXi をデプロイするにはいくつかのお作法がありますので、備忘録としてまとめておきます。

1) VMware Toolsインストー

ESXiも仮想マシンとして動作しますので、VMware Toolsがないと色々と不便です。vSphere 5.x では以下のリンクにあるFlingをインストールする必要があります。 vSphere 6.0以降であれば組み込まれているので不要です。

labs.vmware.com


2) ゲストOSのバージョン設定

ゲストOSのバージョン設定は、Windows Server や CentOSなど選ぶ事ができます。Nested ESXi の場合は「ゲストOS」を「その他」に設定し、ESXi バージョンを選択します。

下記例では 5.x を指定していますが、6.x や 6.5 が選択できます(ESXi 6.5 の場合)ので、環境に合わせて設定します。
f:id:tokyo-wasted:20170616022528p:plain


3) hardware-assisted virtualization (HV)有効化

ハードウェア仮想化機能を仮想マシンに提供するため、物理サーバ上の ESXiホストで以下のコマンドを実行します(再起動は不要)。

echo 'vhv.allow = "TRUE"' >> /etc/vmware/config

コンフィグを確認し、以下のように追加されていれば完了です。
f:id:tokyo-wasted:20170616023330p:plain


4) ハードウェア仮想化機能をゲストに公開

前項 2)と関連しますが、ハードウェア仮想化機能を仮想マシンにも公開(Expose)するため、Nested ESXi の仮想マシン設定を開き以下のチェックボックスを有効にします。
f:id:tokyo-wasted:20170616023914p:plain


5) CPU/MMU仮想化設定

この設定は必ずしも必要ではないかも知れませんが、Nested ESXi仮想マシン設定の「CPU/MMU仮想化」から以下を選択します。
f:id:tokyo-wasted:20170616024157p:plain


6) vSAN構成時のエラー対処

Nested ESXi が vSANデータストア上にある場合、ESXiインストールが開始されるとエラーがでて失敗します。インストールするバージョンによってエラーメッセージは異なります。

この事象の対処法は以下のブログに紹介されていました。コマンド1行を物理サーバ上の ESXiで実行すればOKです。

www.virtuallyghetto.com

コマンド: 
esxcli system settings advanced set -o /VSAN/FakeSCSIReservations -i 1




と、ここまで書いてきましたが。。。
このようにNested ESXiの構築は手間がかかっていたのですが、現在は以下のようにOVFでデプロイするだけの Nested ESXiが非公式ながら提供されています。まだ使ったことがないので、試して気づいたことがあれば記事を書こうと思います。

www.virtuallyghetto.com



では。

NSX AUTOPOLOGY - 絵を描いてネットワーク構築

VMware から面白い Flings がでてきました。
WYSIWYGGUI でネットワークを描くことで、設定ができるらしいです。

labs.vmware.com


百聞は一見にしかず、以下の動画でコンセプトはよくわかります。

www.youtube.com



NSX の無味乾燥な GUI をキャッチーにしてくれるツールです。
もちろん裏方で動いているのはNSXですので、エンジニアの立場としては AUTOPOLOGY によって作業や管理が楽になるわけではまったくありませんが、ユーザへのデモ映えとしては最高ですし「SDN、もとい、SDDCはここまで楽になりました!」とアピールするには持ってこいですね。

ただ残念なことに AUTOPOLOGY は NSX-T 向けなので、日本で普及するまではあと2年くらいは掛かりそうですね。
Flingsとして登場したことで、今後の NSX がどのように進化していくのかを少し垣間見ることが出来た気がします。