しかし、LCMは いいところばかりではありません。
実際の利用における注意点をご紹介します。これからLCMを使う人は是非、目を通しておらえるとありがたいです。
注意点1・アップリンクのチーミングモードに注意
Nutanixで、vSphereやAHVを利用する場合、LAG（Link Aggregation）の設定が入っている場合、LCMでBIOSなどの各種ファームウェアアップグレードに失敗する可能性があります。これは、LCMは、ファームウェアアップデートの際に該当のホストでPhoenixが起動し、そのPhoenixは他のCVMからアップデート用のファームウェアをネットワーク経由で取得します。このPhoenixは、現行バージョン（2019/12現在）LAGに対応していないため、仮想スイッチのアップリンクNICでLAGを組んでいる場合、バイナリをもらうCVMとの間の疎通がうまく行かずFailする可能性があります。LCMでアップグレードをするときには、NICを片系しか利用しないActive/Backupの状態で実行する必要があります。なお、LCM2.2.3.1で、LACP対応という情報が.NEXT 2019 コペンハーゲンの情報で出てきていますので、もうまもなくのリリースを待ちましょう。
注意点2・一括アップグレードの注意点
1つのノードに、BIOSやBMC,SATADOMにHBAなど様々なファームウェアアップデートが必要な状態になった場合、ローリングアップデートで動作をします。vSphereの場合はDRSの機能が有効化されている必要があります。
注意点3・vSphereの場合のDRS必要有無
従来OneClick Upgradeの場合、1つのコンポーネントごとのアップデートで対象ホストはクラスターメンバーのホストすべてが対象でした。そのため、ハイパーバイザーより下の層（BIOSやHDDのファームウェアなど）は、ホストを再起動する必要が出てくるため、仮想マシンの待避を自動的に行うDRSが必須でした。LCMのアップグレードは、ファームウェアアップデートの場合、必要な項目をホスト単位でアップグレードできます。そのため、あらかじめファームウェアアップグレード対象のホストで稼動する仮想マシンをCVM以外すべてvMotionした状態で、LCMでアップグレードすると、ホストをメンテナンスモードにすると同時にCVMのシャットダウン処理が行われます。その後アップグレード処理が終わり再びホストが起動しCVMが起動しクラスターメンバー復活するとアップデートが完了します。
動作としては一見問題なさそうなのですが、CVMがシャットダウン出来たことを確認すると、ホストがメンテナンスモードになりきれていないままホストの再起動がかかる現象が起きます。これは既知のバグなのかそれとも仕様なのかはわかりませんが、LCMのドキュメントには、「For all LCM updates on ESXi, enable DRS and disable admission control in vCenter.」という記載があります。
この状況から考えると、ホスト単位でBIOSなどのファームウェアをアップグレードする際にDRSを無効化した状態での作業は、自己責任での作業になると思われます。
注意点4・アップデートにかかる時間
BIOSやBMCのアップデートは手動で行うと10分から15分程度で終わることが想定されます。LCMを利用した場合、ホストを再起動後Phoenixが起動しファームウェアアップデートを行い、再起動後またPhoenixが起動し成功したかの確認をするなど、かなり厳重に処理が行われるため、1つのファームウェアアップデートに30分〜50分程度を要することがあります。基本LCMでのアップグレードは、クリックしたらコーヒー飲んでブレイクして戻ったらもう終わっているというスタンスの機能ですが、時間はけっこうかかりますので焦らず待つことが大事です。
注意点5・LCMのアップデート方法
LCMは現在どんどん新しい機能が追加されているため、新しいLCMを利用することをお勧めします。では、LCMのアップグレードはどのようにすれば良いのでしょうか？現行のLCMでは、個人の意思でアップグレードをするためのボタンがそもそもありません。LCMのアップグレードは、LCM画面の「Setting」ボタンからAdvanced Setting画面を表示し、「Enable LCM Auto Inventory」にチェックを入れると、インターネットから新しいLCMバイナリを取得します。
この5点を押さえてえおけば、LCMマスターです。
LCMを使うと、今までの手作業だったことが、全自動で行われるため大変楽になります。
0 件のコメント:
コメントを投稿