ラベル ovs の投稿を表示しています。 すべての投稿を表示
ラベル ovs の投稿を表示しています。 すべての投稿を表示

2020年12月24日木曜日

AHVにおける仮想スイッチ(ブリッジ)の作成方法

AHV環境におけるAOS 5.19からPrism UIをとおして仮想スイッチの作成やアップリンクNICの設定変更、アップリンクNICのチーミングモードの変更が行えるようになりました。
AOS5.19は、STSのため次のLTSバージョンが出ればより多くの方のこの機能を利用していただくことができますが、新しいLTSが出るにはすこし時間がかかります。
現時点のLTSであるAOS 5.15においてAHV環境では、アップリンクの変更やブリッジの作成は、コマンドベースで行う必要があります。

今回は、新たなブリッジを作成する方法そして次に、アップリンクのNICチーミング方法の設定についてご紹介をしていきます。

仮想スイッチ(ブリッジの作成)は、AHV上で行います。なお、追加の仮想スイッチを作る場合は本番業務には影響はありませんが、アップリンクNICの操作間違いなどにより1ノードが疎通できなくなるとHAが発動する事象が出ることも考えられますので、アップリンクNICを含め操作する場合は、事前に仮想マシンを停止しクラスターサービスを止めておくことをおすすめします。

まずは、仮想スイッチを作成します。

manage_ovs --bridge_name br1 create_single_bridge

仮想スイッチ(ブリッジ)が出来たことを確認するため「manage_ovs show_bridges」を実行します。

$manage_ovs show_bridge
Bridges:
br0
br1


続いて新たに作成したbr1のアップリンクモードを設定します。
bond-modeは以下から選択可能です。

bondモード使用事例上位スイッチ
active-backupデフォルトの構成であり、推奨構成。
単一のアクティブなNICが全てのトラフィックを処理します。
通常ポート設定
balance-slb各仮想NIC毎にアップリンクのNICが割り付けられます。
マルチキャストトラフィックの一部で問題が発生するため、推奨されていません。
接続する物理スイッチ側は、LAGの設定をしないで下さい。
通常ポート設定
balance-tcp仮想マシンが通信するポート番号によって利用するアップリンクNICを割り付けます。
本機能は、接続する物理スイッチでLACPの設定を行って下さい。静的LAGモードは非サポートです。
LACP(動的)


現行ホストに存在しているNICを「manage_ovs show_interfaces」で確認します。

$ manage_ovs show_interfaces
name  mode  link speed
eth0  1000 True  1000
eth1  1000 True  1000
eth2  1000 False  None
eth3  1000 False  None
eth4 10000 False  None
eth5 10000 False  None
eth6 10000  True 10000
eth7 10000  True 10000


ここでは、eth4とeth5のNICを割り付けます。eth4とeth5は、まだリンクアップしていない状態でアップリンクの設定をするため「--require_link=false」を付与します。

なお、既存で用意されているデフォルトの仮想スイッチ(br0)においてアップリンクモードを変える場合も以下のコマンドを利用します。

manage_ovs --bridge_name br1 --interfaces eth4,eth5 --require_link=false --bond_mode=active-backup update_uplinks

では、アップリンクNICと仮想スイッチ(br1)の状態を以下のコマンドで確認していみます。

$manage_ovs show_uplinks
Bridge: br0
  Bond: br0-up
    bond_mode: active-backup
    interfaces: eth7 eth6 
    lacp: off
    lacp-fallback: false
    lacp_speed: slow
Bridge: br1
  Bond: br1-up
    bond_mode: active-backup
    interfaces: eth4 eth5

    lacp: off
    lacp-fallback: true
    lacp_speed: off


これで作業は完了です。続いて、VLANの作成を行います。
AOS5.19より前の環境においては、複数の仮想スイッチを作成した場合、VLAN作成は必ず「acli」で作成を行って下さい。これは、PrismのVLAN作成画面ではどの仮想スイッチに対してVLANを作成するかの指定が出来ないためです。
ここでは、VLAN20のネットワークを新しく作成したbr1側に作成したいと思います。

acli net.create vlan20-seconde-net vlan=20 vswitch_name=br1

重要な点は、vswitch_nameを定義することです。

以上で、作業は完了です。PrismのNetwork Visualizationの画面で見ると新しい仮想スイッチ(ブリッジ)が作成されNICがアップリンクに割り当たっていることが分ります。


作業における注意点は以下の通りです。
  • アップリンクNICを変更することでノード間疎通が出来なくなるとトラブルが発生することが予見されます。あらかじめホストをメンテナンスモードにするかクラスターサービスの停止を行った上で作業を行って下さい。
  • manage_ovsは、操作を行ったCVMのホストにのみ反映されます。クラスター内の全てのノードに対して作業を一括で行うためには、「hostssh "manage_ovs ~」と、hostsshで各ホストに実行を行って下さい。
  • manage_ovsは、クラスターメンバーに属していないノードでも作業が可能です。クラスターに新規で追加を行うノードに対してmanage_ovsでアップリンク設定を変更した上で、ノード拡張を行うことが可能です。
  • AOS5.1までで利用していた、ovs-vsctlコマンドによる仮想スイッチ作成は、AOS5.5以降サポートされていません。

本項目では、manage_ovsコマンド出の作業方法をお伝えしました。acliで、「net.create_cluster_vswitch」を利用すると、各ノードをローリングでメンテナンスモードのしながらアップリンクNICの設定を変更できます。(当然ながらクラスターサービスが起動している状態で実施)
この「net.create_cluster_vswitch」は、AOS 5.19からは「net.create_virtual_switch」コマンドに変更されており、Prism側の仮想スイッチ作成オペレーションと紐付いた操作が可能となっております。

AOS5.0時代に比べるとAHVにおける仮想スイッチの操作はだいぶ楽になっていますが、ovs-vsctlコマンドでの操作が廃止になったり、acliでの仮想スイッチ操作がコマンドが変更になったりとかなり時代に応じて変更されています。

AOS5.19以降はPrismからの操作が最も楽な方法かと思いますが、次のLTSバージョンがリリースされるまでは、現行のLTSであるAOS 5.15の利用においては今回ご紹介したコマンドベースでの作業となります。(次のLTSが待ち遠しい物です)




2020年12月22日火曜日

AOS 5.19アップデート(その1)AHV環境における仮想スイッチの作成方法

AHV環境において1つハードルが高いことは、仮想スイッチを複数利用する構成です。
結論から言えば構成は可能なのですが、従来AHVにおける仮想スイッチの作成は、CVM上から「manage_ovs」コマンドを実行し、環境を確認しながら、AHV上で「ovs-vsctl」コマンドで設定を行うという、あまりユーザーフレンドリーとは言えない状況でした。

そもそもNutanixおいては、シンプルな構成を目指していることと、NutanixのCVM間の通信がデーターローカリティーの概念により10Gネットワークをフルで利用することがないため、10GのネットワークにVLAN分離でサービス系とCVMのネットワークを混在して利用してもなんら問題がないため、そこまで大きな問題として顕在化することはありませんでした。

とはいえ、セキュリティの観点からアップリンクNICを意図的に分けたいなどの構成や設計の方針で仮想スイッチを分けなければいけないことがあるかと思います。

そんな仮想スイッチ作成作業ですが、AOS 5.19よりPrismの操作だけで、仮想スイッチに追加・削除ができるようになりました。

今日は、この仮想スイッチの追加機能について紹介いたします。


<ブリッジと仮想スイッチについて>

そもそもAOS5.18までは、AHVにおける仮想スイッチは、ブリッジという表現をしていました。しかし、AOS5.19でブリッジという表現は表上からは消えて「vs(Virtual Switch)」という表現に改められています。もちろんbr0という形で内部的にはブリッジとして動作しているので、表面上の表現だけが変更になりました。

▼AOS 5.15.4のNetwork Visualizationでのホストのネットワーク画面


▼AOS 5.19のNetwork Visualizationでのホストのネットワーク画面


<仮想スイッチの作成方法>

では、実際に2個目の仮想スイッチを作成していきましょう。
今回は、10Gのネットワークで利用しているbr0には割り当てられておらず、どこの仮想スイッチにも割り当てられていない、1GのNIC「eth3」と「eth4」のNICを「service-sw」という新たに作る仮想スイッチに割り当てたいと思います。

まずは、ギアアイコン→「Network Configuration」→「Virtual Switch」に移動します。
Foundation直後は、vs0として1つの仮想スイッチが見える状態になっています。

ここから、右上の「+ Create VS」をクリックします。


次に、仮想スイッチに必要なパラメーターを入れるウィザードが出てきます。
仮想スイッチ名、説明、MTUサイズ(1280~9216)を入力します。
Configuration Methodは、詳細な設定ができるよう「Standard」を選択します。
Quickは、各ホストをメンテナンスモードにせずホストを再起動します。ホスト自体はrollingでの再起動となりますが、時間短縮のためメンテナンスモードにせずホスト再起動を掛けるため、仮想マシンワークロードが稼動していると予期せぬ仮想マシンのパワーオフが実施されますので、仮想マシンがCVM以外に存在しない状況の場合のみ選択できます。

ここでは、「service-sw」と名称を設定します。


次に、アップリンクモードやアップリンクNICの設定ができる画面が表示されます。

BondTypeには、「Active-Backup」「Active-Backup with MAC pinning」「Active-Active」「No Uplink Bond」が選択できます。
No Uplink Bondは、チーミング指定なしということになります。通常のサーバー運用ではまず選択しないオプションになるかと思います。

Select Hostsは、設定反映するホストを指定します。こちらの機能はおそらくノード拡張後にボンドモードが既存クラスターと異なっている場合に利用する機能のようで、完全に新規の仮想スイッチを選択する場合、「All Hosts」を選択しないと、ウィザードの次の画面に行こうとすると「When creating/editing a virtual switch, all hosts must be selected (except storage-only node).」と表示されます。

続いて、新しく作る仮想スイッチに割り当てる物理NICを選択します。
ここでは、eth3と4を割り当てます。
このNIC選択は、ホスト毎に選択できますので、複数ホストある場合は、1ホストずつ別のNICを割り当てることも可能です。


ここまでパラメーターを入れたら、「Create」で仮想スイッチを作成します。

今回はQuickを選択していませんでしたが、稼動している仮想マシンが少なかったのもあり、3台のホストを再起動しても時間は20分かからないぐらいでした。

全てのホストの再起動が終わると、タスクが完了します。

完了後は、いつも通り「Network Configuration」→「+ Create Network」からVLANを作成します。


VLANの作成画面で、仮想スイッチの選択画面が出てきていることが分ります。
ここで、先程作成した仮想スイッチを選択し、VLANを作成します。


作成が完了したVLANは、そのままPrismのVirtual Machinesの画面から、仮想マシンに割り当て可能です。

Network Visualizationで確認してみましょう。

ホストを選択すると、先程作成した仮想スイッチとアップリンクNICが割り当てられていることが分ります。


Virtual Switch出先ほど作成したスイッチ「service-sw」をチェックを入れるとアップリンクNICの色が既存の仮想スイッチであるvs0とは別の色で表示されます。




<仮想スイッチの削除方法>

仮想スイッチの削除も、Virtual Switchの一覧から削除可能です。(既存で存在するvs0は削除できません)



以上で、仮想スイッチの作成方法は終わりです。

しかし、今までのあのコマンドと長いパラメーターを利用せず仮想スイッチを作成できるようになったのは、個人的には感動的な機能です。(というかもっと早く実装してほしかったというのが正直なところですが)

AHV利用時のハードルがまた一つ消えたことは、よりAHVが身近なハイパーバイザーに進化してきているという現れだと思います。