vCenter のRDU 8.x -> 9.x を試す

 概要

vCenter 8.x をReduced downtime Upgradeで9.0にする

 

 

参考

vCenter Server upgrades with the reduced downtime

[TAM Blog] Reduced Downtime Upgrade（RDU）機能のご紹介（Part1） - VMware Japan Blog

[TAM Blog] Reduced Downtime Upgrade（RDU） 機能のご紹介（Part2） - VMware Japan Blog

 

 

 

Reduced Downtime Upgrade（RDU）とは

あたらしいVCSAのアップグレード方式です。

従来の手法と比べてvCenterの再起動やデータ移行に伴うダウンタイムが短縮されており、

より簡単に負担なくアップグレードができるようになっている。

 

従来の方法はUIでの操作手順も異なる。

 

今後はこの方法が主流となり、従来の方法は廃止される予定となっている。

 

まずはダウンロード

 

Broadcom Support SiteからvCenterのISOをダウンロードする

Installerと同じISOを利用する

 

 

vCenter 8.xまでは、My DownloadからvCenterで検索すると簡単に見つかるが、vCenter 9.0はVmware Cloud foundation で検索して、

Vmware Cloud Foundation の中でvCenterを探して掘り進んでいくと見つかります。

 

 

 

 

ISOファイルをデータストアに配置する

 

何とかダウンロードしたISOファイルはVCSAにマウントする必要があるので、その前段階としてデータストアに転送します。

VCSAをホストするESXからアクセスできるデータストアであればどこでも良いです。

 

 

 

VCSAにISOファイルをマウントする

 

特別なことは何もないです。既存のアップグレード対象のVCSA VMの編集画面からISOファイルをマウントする。

 

 

 

 

 

 

 

RDUのウィザードを開始する

 

RDUは従来とは異なる手順でのアップグレードとなる。

アップグレード対象のVCSAのvSphere Clientにログインし、最上位インベントリにいるvCenter自身を選択する。

UpdateタブからvCenter Server のUpdateが可能となっている。

 

 

ISOファイルをマウント済みの場合は、現在のバージョンとISOファイルのバージョンが確認できるようになっている。

バックアップを取ることが推奨されるので、バックアップがない場合は取得しておく。

とってなかったとしてもチェックを入れてNextから先に進めることはできる。

 

 

↓PluginのUpgradeが指示されるので、UPGRADE PLUG-INから実行する。この操作ではvCenterの再起動は発生しないので業務影響はない。

 

 

 

 

↓PluginのUpgradeの完了を待つ。（数分～５分）

 

 

アップグレードが終わると自動的にUIがリロードする。

リロードされたらもう一度RDUのウィザード画面に戻り、今度はプリチェックを流す。（RUN PRE-CHECKS）

 

 

 

 

Precheckが終わると先に進める

 

 

次にターゲットアプライアンスの構成に移る。

RDUでは既存のVCSAとは別のVCSA VMを新規で構築し、移行する形で進行する。

ターゲットアプライアンスとは、新規で作成されるVCSA VMの設定のことである。

 

 

 

お決まりのEULAとCEIPの後に、ロケーションの構成がある。

今回はSelf Manged 構成なので同じ場所を選択する。（Self Managedじゃない場合にSame Locationを選ぶとどうなるんだろうか）

 

 

 

 

次に、VCSA VMの構成（サイズとかデータストアとか名前とか）を選択する。

 

 

 

次にVCSA VM名とRootパスワードを選択する。既存と同じものを選んで問題ない。

 

 

Network設定の項目では新VCSAが利用するTemporary IP等の設定をする。

Temporary IPは既存VCSAと同じIPを選択することはできない。重複しないIP設定、かつ既存のVCSAからアクセスできるものにする必要がある。

手動での設定も可能だが、今回はAutomaticを選んで何が起こるのかを観察する。

 

参考ブログの記載ではDNSの正引き・逆引きが必要とされていたが、今回は何もしてない（というかAutoなので何もできない）

 

 

 

最後に構成をReviewしてFINISH。

 

 

 

 

構成が完了したらSTART UPGRADEからアップグレードを開始する。

 

 

スイッチオーバーをどのように実行するのかが選択できる。

スイッチオーバーのタイミングではVCSAへのアクセスができなくなる（バックアップなども失敗する）ので、定常運用業務側との調整が必要である。

今回はTemporary IPの挙動を見たいのでManualを選択する

 

 

暫し待つ。いつでのキャンセルができるのは地味にありがたい。

 

 

 

しばらくするとスイッチオーバーのフェーズに入る（手動を選択しているので自動的にはスイッチオーバーしない）

 

 

 

 

このタイミングでTemporary IPをAutomaticにした際の挙動を確認する。

新VCSAの構成を確認すると、Temp IPとしてリンクローカルIPが降られている

 

 

 

一方で旧VCSAに対してもリンクローカルIPが追加されていた。

同セグメントでのRDU実行の場合はTemporary IPはAutomaticが非常に便利だと思う。

 

 

 

 

スイッチオーバーを押してみる

 

 

 

５分程度でスイッチオーバーが完了した。

 

 

スイッチオーバー後は新VCSAがIPアドレスとFQDNを引き継いでいる。

 

 

 

 

RDUについての所感

全体的に非常に簡単で細かいドキュメントの確認なしでエラー無く完了できた。

Temporary IPのAutomatic設定についは非常に便利だと感じた。

IP/FQDNは引き継がれるが、Mac Addressが引き継がれないのでMac Addressで通信をフィルターしている場合は注意が必要である。

Broadcom Support PortalからvCenter 9.0 ISOのダウンロードが一番のハードルだった

 

 

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...
続きを読む

NTPと同期してくれないときのトラブルシューティング

ラボ環境や検証環境だと、用意したNTPサーバーとESXi/VCSAが同期してくれないことがしばしばあると思います。 多くの場合はちょっとした設定の追加で解決できることが多いので、今回はその方法についてご説明します。 NTPサーバとの疎通確認 何はともあれ、まずはNTP側との疎通と動作確認が必要です。 以下のコマンドを実行してください。 ※ESXiにはntpdateコマンドはないのでスキップしてください。
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む