2018年8月25日土曜日

ESXi 6.7の環境でIntel I219-V (デバイスID:15bc) のNICを認識させる方法

先日、検証ESXiサーバーを新調した。新調したサーバーのマザーボードは、ASRock H370M-ITX/acという製品となり、オンボードのイーサネットポートが2つ付いている。2つのポートのチップセットは同一ではなく、以下2種類が搭載され、それぞれのポートを個別に制御しているようだ。
  • Intel I219-V (下写真の上側のNIC)
  • Intel I211AT (下写真の下側のNIC)
しかし、ESXi 6.7をインストールした際に、Intel I219-VのNICを認識しない事象が発生した。


Webで調べても、完全に一致する事象は確認できなかったのだが、いろいろ試すうちにIntel I219-VのNICを認識させることに成功したので、その方法を記載する。

NICの認識状況を調査してみる

デバイスの認識状態を確認するため、ESXi Shellにて各種コマンドを実行してみる。

物理NICの認識状況確認

Intel I211のNICのみしか表示されず、Intel I219-VのNICは表示されない。

[root@localhost:~] esxcfg-nics -l
------------------------------
Name    PCI          Driver      Link Speed      Duplex MAC Address       MTU    Description
vmnic0  0000:02:00.0 igbn        Up   1000Mbps   Full   70:85:c2:8c:db:1e 1500   Intel Corporation I211 Gigabit Network Connection
------------------------------

PCIデバイスの確認

PCIデバイスとしては、Intel I219-VのNIC情報が表示される。Intel I219-VのデバイスIDは「15bc」であることがわかる (赤字箇所)。

[root@localhost:~] lspci -v
------------------------------
0000:00:00.0 Host bridge Bridge:
         Class 0600: 8086:3ec2

0000:00:01.0 PCI bridge Bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [PCIe RP[0000:00:01.0]]
         Class 0604: 8086:1901

~(中略)~

0000:00:1f.6 Ethernet controller Network controller: Intel Corporation Ethernet Connection (7) I219-V
         Class 0200: 8086:15bc

0000:02:00.0 Ethernet controller Network controller: Intel Corporation I211 Gigabit Network Connection [vmnic0]
         Class 0200: 8086:1539

0000:03:00.0 Network controller Network controller: Intel Corporation Dual Band Wireless-AC 3168NGW [Stone Peak]
         Class 0280: 8086:24fb
------------------------------

VMware Compatibility Guide (VCG) で互換性を確認

VCGのIO Devicesの項目から、確認したデバイスID「15bc」の互換性を確認してみる。

VMware Compatibility Guide - IO Devices
https://www.vmware.com/resources/compatibility/search.php?deviceCategory=io

検索は以下条件で行う。
  • 製品リリースバージョン:All
  • I/Oデバイスタイプ:Network
  • キーワード:15bc
検索結果は以下の通り。Intel Ethernet Connection (7) I219-Vは「ESXi 6.5 U2」以外のバージョンには対応していないことがわかる。


上記の「Intel Ethernet Connection (7) I219-V」のリンクをさらにクリックし詳細を確認してみる。

VMware Compatibility Guide - Ethernet Connection (7) I219-V
https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=45884&vcl=true


Intel I219-VのNICは、ESXi 6.5 U2に含まれる「ne1000 version 0.8.3-7vmw」というデバイスドライバが対応していることがわかる。上記ドライバをWebで探すと以下サイトからダウンロードできるようだ。

VMware ESXi Patch Tracker
https://esxi-patches.v-front.de/ESXi-6.5.0.html

このサイトから「VMW_bootbank_ne1000_0.8.3-7vmw.650.2.50.8294253.vib」というファイルをダウンロードしておこう。ESXi 6.5用のドライバとなるが、結論から言うとESXi 6.7にも適用可能である

Intel I219-Vのデバイスドライバを適用する

先ほどダウンロードしたデバイスドライバのファイルをESXiサーバーの/tmpにアップロードしておく。

[root@localhost:~] ls -l /tmp/
------------------------------
-rw-r--r--    1 root     root        189658 Aug 24 21:04 VMW_bootbank_ne1000_0.8.3-7vmw.650.2.50.8294253.vib
-rw-------    1 root     root            40 Aug 24 21:10 probe.session
drwx------    1 root     root           512 Aug 21 21:11 vmware-root
------------------------------

古いデバイスドライバが上書きされるので、念のため旧デバイスドライバのバージョンを確認しておこう。ESXi 6.7では、0.8.3-4というバージョンがインストールされているようだ。

[root@localhost:~] esxcli software vib list | grep ne1000
------------------------------
ne1000                         0.8.3-4vmw.670.0.0.8169922            VMW     VMwareCertified   2018-08-12
------------------------------

それではデバイスドライバをインストールする。

[root@localhost:~] esxcli software vib install -v /tmp/VMW_bootbank_ne1000_0.8.3-7vmw.650.2.50.8294253.vib
------------------------------
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMW_bootbank_ne1000_0.8.3-7vmw.650.2.50.8294253
   VIBs Removed: VMW_bootbank_ne1000_0.8.3-4vmw.670.0.0.8169922
   VIBs Skipped:
------------------------------

「アップデートには成功したが反映には再起動が必要」という旨のメッセージが表示されているので、実施後、ESXiを再起動しておこう。

ESXiの再起動後、デバイスドライバのバージョンを確認すると、0.8.3.-7にバージョンアップされていた。

[root@localhost:~] esxcli software vib list | grep ne1000
------------------------------
ne1000                         0.8.3-7vmw.650.2.50.8294253           VMW     VMwareCertified   2018-08-24
------------------------------

また、物理NICも以下の通りIntel I219-Vが表示されるようになった。試しにIntel I219-VのポートにPCをつないでみると、問題なく1Gbpsでリンクアップした。

[root@localhost:~] esxcfg-nics -l
------------------------------
Name    PCI          Driver      Link Speed      Duplex MAC Address       MTU    Description
vmnic0  0000:02:00.0 igbn        Up   1000Mbps   Full   70:85:c2:8c:db:1e 1500   Intel Corporation I211 Gigabit Network Connection
vmnic1  0000:00:1f.6 ne1000      Up   1000Mbps   Full   70:85:c2:8c:db:1c 1500   Intel Corporation Ethernet Connection (7) I219-V
------------------------------

まとめ

以上でESXi 6.7の環境にて、Intel I219-Vを認識させる作業は完了となる。なお、ESXi 6.5 U2では対応しているのに、ESXi 6.7では対応しなくなった理由は不明である。デバイスドライバに不具合があり、VMware社にて意図的にダウグレードしている可能性もあるので、本作業は自己責任で対応をお願いしたい。

2018年8月22日水曜日

vCenter High Availability (vCenter HA) の設定手順とフェイルオーバー時間について


vCenter Server Appliance (vCSA) について、バージョン6.5以降より、vCenter High Availability (vCenter HA) と呼ばれる冗長化機能が利用できるようになった。ちなみに、vCenter Serverの高可用性の手法については、VMware社の以下KBにてまとめられている。

サポート対象の vCenter Server 高可用性オプション (1024051)
https://kb.vmware.com/s/article/1024051?lang=ja

今回、手順確認と動作確認を目的として、実際にvCSAを構築して、vCenter HAの設定をしてみた。また、実際にフェイルオーバーさせた際の、vCenter Serverが操作できなくなる時間をざっくり計測してみた。

実施環境

今回の環境は以下の通り。vCenter HAを構成する際は、通常のvCenter Serverへのアクセス用のネットワークとは別に、vCenter HA用のネットワーク(下図のオレンジ線)を用意する必要がある。


上図のように、vCenter HAでは、元のvCSA(アクティブノード)、フェイルオーバー用のvCSA(パッシブノード)、監視用のvCSA(監視ノード)の3台が必要となる。監視ノードがアクティブノードとパッシブノードにハートビートを送信し監視をする。

パッシブノードはアクティブノードと同一CPU、メモリ、ディスクが必要となる。監視用ノードは、メモリは1GBと少なく構成されるようだ。

vCenter HA設定手順

それではvCenter HAの設定手順を見ていこう。

1. vCenter HAの構成の開始

vSphere Web Clientにて、「vCenter Server」→「設定」→「vCenter HA」→「構成」ボタンを押下する。


2. 設定オプション

「基本」を選択する。


3. ネットワークアダプタの追加

vCenter HA用のNICに付与するIPアドレスと、ポートグループを指定する。今回は分散仮想スイッチのポートグループ「DPortGroup165」を指定している。


4. パッシブノードと監視ノードのIPアドレスの設定

パッシブノードと監視ノードのIPアドレスとして、前手順でアクティブノードに設定したIPアドレスと同一セグメントにて設定する。


5. デプロイ構成の選択

デプロイされる際の構成が表示される。今回は検証環境の制約により、これといって選択できる項目はなかった。なお、赤丸で示した「互換性の警告」は、可用性を担保するうえで問題となる構成があることを表している。


今回の互換性の警告としては、データストアがすべて同一となってしまっていることと、データストアの空き容量が不足しているという2点となっていた。実際にデータストアの空き容量不足により、一度パッシブノードの展開に失敗してしまったため、データストアの容量を増やしてやり直しをすることになってしまった。


6. 設定の確認

最後に設定の確認が表示されるので、問題なければ「完了」ボタンを押下する。


「最近のタスク」にデプロイやクローン作成の進捗が表示されるので、完了までしばらく待機する。なお、私の環境では8分程度で完了した。


7. vCenter HA構成後の確認

vCenter HAの構成タスクが完了しても、フェイルオーバーが無効となっている旨の以下メッセージが表示される。

------------------------------
現在、レプリケーションで障害が発生している可能性があります。自動フェイルオーバー保護は無効です。vCenter HA を有効にして間もない場合は、最初のレプリケーションがまだ進行中で、あと数分かかる状態である可能性があります。
------------------------------


慌てずに1分程度待機すれば、これは解消される。


フェイルオーバー時間

vCenter HAは手動でフェイルオーバーさせることができるので、実際にフェイルオーバーを実行して、その際の切り替わり時間を計測してみることにする。

vCenter HAの設定画面の右上の「フェイルオーバー開始」ボタンを押下する。確認のダイアログボックスが表示されるので、「はい」を押下する。


0分経過

Ping疎通が途絶える

1分経過

Ping疎通が回復

2分経過

vCSAの管理Webにアクセスすると、「503 Service Unavailable」エラーが返ってくる


4分経過

Web画面は回復したが、vSphere Web Clientを表示しようとすると、「Failover in progress...」の表示となり、まだ操作はできない


7分経過

「The vSphere Client web server is initializing」の画面となり、相変わらず操作はできない


8分経過

vSphere Web Clientにログインできるようになる

というわけで、vCenter HAを構成していたとしても、数分間の操作不能の時間が発生するので注意が必要となる。

なお、フェイルオーバー後にvCenter HAの画面を確認すると、アクティブノードとパッシブノードのIPアドレスが入れ替わっている。


管理Web用のIPアドレス(今回の場合、192.168.11.165)は、パッシブノード側に付与されていることがわかる。


まとめ

vCenter HAはフェイルオーバー時に数分レベルの切り替わり時間が発生し、その間は管理Webのアクセスが不能となることがわかった。

vSphere HAによる仮想マシン再起動でも数分あればvCSAは起動できることから、2倍以上のCPU、メモリリソースを消費するほどのメリットがvCenter HAにはないと感じてしまう。さらに、vCenter Server自体の機能は、仮想マシンの稼働に影響を与えることはなく、緊急性という観点でも、vSphere HAによる再起動で十分な場合が多いだろう。

では、どのような場合にvCenter HAを使う必要があるのだろうか?以下URLに「vCenter High Availability (vCenter HA) は、ホストとハードウェアの障害に加え、vCenter Server アプリケーションの障害からの保護にも対応」とある。

vCenter High Availability を使用した vCenter Server Appliance の保護
https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.avail.doc/GUID-226A925F-BF20-4A58-BF15-4A76B4CEDC84.html

従来のvSphere HAによる保護の場合は、アプリケーションの状態は監視できないため、vCenter Serverのアプリケーション障害時のフェイルオーバーを実現したい場合には、vCenter HAの構成を検討する必要はあると思われる。

2018年8月20日月曜日

電源ボタンを押さずにパソコンの電源をONにする方法

久しぶりに自作PCを作ったのだが、ケース以外のパーツが先に揃うという事態が発生した。マザーボードやメモリ等の各パーツの初期不良等チェックをしたかったので、裸のまま結線して起動させてみることにした。

組み上げて電源をつないで、いざ電源投入しようとしたところ、電源ボタンがないことに気づいた。当たり前だが、電源ボタンはケースに付属されているので、このままでは電源ONにすることができない。

今回は、電源ボタンを使わずにマザーボードの電源をONにする方法について記載する。

方法

マザーボードのマニュアルやWebを調べてみると、マザーボードにある電源ボタン接続用のジャンパーピンをショートさせれば電源ONできることがわかった。赤枠で囲んだ箇所が電源ボタン用の+と-のピンとなる。



これをドライバーなどの金属でショートさせる。


すると、CPUファンが回りだし、PCを起動させることに成功した。


2018年8月13日月曜日

Ansibleでプロキシを指定してyum updateする

RHELやCentOSをインストールした際に、ソフトウェアの最新化を行うためにyum updateをすることがあると思うが、それをAnsibleで実行してみる。なお、今回プロキシを経由しなければインターネット接続ができない環境となっているため、環境変数にてプロキシを指定したうえで、yum updateする処理としてPlaybookを作成した。

Playbook

Playbookは以下の通り。varsセクションでproxy_envという変数を作成し、tasksセクションのyumの箇所で、その変数を環境変数として設定する。

update_all.yml
------------------------------
---
- hosts: all

  vars:

    proxy_env:
      http_proxy: http://192.168.33.23:8080/
      https_proxy: http://192.168.33.23:8080/
  tasks:
    - name: update all packages
      yum: name='*' state=latest
      environment: "{{ proxy_env }}"
------------------------------

ちなみに、このプロキシ設定の方法は、公式マニュアルにも記載されている。

Setting the Environment (and Working With Proxies)
https://docs.ansible.com/ansible/2.6/user_guide/playbooks_environment.html


実行結果

実行結果は以下の通り。

[root@t1000cent ~]# ansible-playbook update_all.yml
------------------------------
PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
ok: [192.168.11.241]

TASK [update all packages] *****************************************************
changed: [192.168.11.241]

PLAY RECAP *********************************************************************
192.168.11.241             : ok=2    changed=1    unreachable=0    failed=0
------------------------------

処理対象サーバーのyumの実行結果を確認すると、きちんとアップデートが実行されていることがわかる。

[root@t1241cent ~]# tail -f /var/log/yum.log
------------------------------
Aug 10 15:32:58 Updated: nspr-4.19.0-1.el7_5.x86_64
Aug 10 15:32:58 Updated: nss-util-3.36.0-1.el7_5.x86_64
Aug 10 15:32:58 Updated: libgcc-4.8.5-28.el7_5.1.x86_64
Aug 10 15:32:58 Updated: libcom_err-1.42.9-12.el7_5.x86_64
Aug 10 15:33:00 Updated: python-libs-2.7.5-69.el7_5.x86_64
Aug 10 15:33:00 Updated: python-2.7.5-69.el7_5.x86_64

~(以下略)~
------------------------------


2018年8月8日水曜日

超初級Ansible! ~Ansibleのインストールから簡単なPlaybookの実行まで~

インフラエンジニアを何年も続けていれば、サーバ構築、単体テスト、運用・保守作業の手順をスクリプト化して効率化することはよくやる話となる。このように、IT機器の構成情報をコード化・自動化することを「構成管理」と呼ぶ。

ちなみに、ITILでいう「構成管理」とは意味が異なる
  • ITILでいう構成管理:ITサービスに含まれる資産とその構成情報を一元管理すること
  • ここでいう構成管理:IT機器の構成情報をコード化・自動化すること
構成管理ツールとしては、以前はChefやPuppetといったツールが著名であったが、近年は「Ansible」というツールが非常に注目されている。Ansibleでは、YAML(ヤムル)という記述フォーマットで処理内容を記述するのだが、可読性に優れており容易に記載できることが特徴となる。

本記事では、Ansibleのインストールから、実際に簡単なPlaybookを作成して処理を実行する手順について記載することにする。実際にやってみればわかるが、1時間もあればできてしまう

環境

Ansibleをインストールするサーバー、Ansibleにて処理を実行するサーバーともに、CentOS 7.5を用いる。念のためバージョン情報を以下に記載する。

[root@t1000cent ~]# cat /etc/redhat-release
------------------------------
CentOS Linux release 7.5.1804 (Core)
------------------------------

IPアドレスは以下の通りとなる。
  • Ansibleサーバー:192.168.11.221 (ホスト名:t1000cent)
  • 処理対象サーバー:192.168.11.223

Ansibleインストール

Ansibleはyumを使ってインストールするのが一番手っ取り早い。依存関係のあるパッケージとして、複数のPythonのライブラリが合わせてインストールされる。

[root@t1000cent ~]# yum install ansible
------------------------------
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.usonyx.net
 * extras: ftp-srv2.kddilabs.jp
 * updates: centos.usonyx.net
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ ansible.noarch 0:2.4.2.0-2.el7 を インストール
--> 依存性の処理をしています: sshpass のパッケージ: ansible-2.4.2.0-2.el7.noarch
--> 依存性の処理をしています: python2-jmespath のパッケージ: ansible-2.4.2.0-2.el7.noarch
--> 依存性の処理をしています: python-six のパッケージ: ansible-2.4.2.0-2.el7.noarch

~(中略)~

  python2-jmespath.noarch 0:0.9.0-3.el7
  python2-pyasn1.noarch 0:0.1.9-7.el7
  sshpass.x86_64 0:1.06-2.el7

完了しました!
------------------------------

Ansibleのバージョンを確認しておく。2.4.2というバージョンとなる。

[root@t1000cent ~]# ansible --version
------------------------------
ansible 2.4.2.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.5 (default, Apr 11 2018, 07:36:10) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]
------------------------------

Ansibleから接続するための初期設定

Ansibleでは、処理対象のサーバーとの接続性を確認するコマンドが用意されており、構文は以下となる。

------------------------------
ansible <接続先ホスト名 or IPアドレス> -m ping -k

 -m : モジュールを指定。今回は「ping」モジュールを使う
 -k : 実行時に接続先サーバーのパスワードの入力を求める
------------------------------

しかし、上記を実行してみたが、そのままではエラーとなってしまう。

[root@t1000cent ~]# ansible 192.168.11.223 -m ping -k
------------------------------
SSH password:
 [WARNING]: Could not match supplied host pattern, ignoring: all

 [WARNING]: provided hosts list is empty, only localhost is available

 [WARNING]: Could not match supplied host pattern, ignoring: 192.168.11.223

 [WARNING]: No hosts matched, nothing to do
------------------------------

Ansibleの処理対象とするサーバーは、/etc/ansible/hostsに記載する必要があるらしいので、記載して再度実行してみることにする。

[root@t1000cent ~]# cat /etc/ansible/hosts
------------------------------
192.168.11.102
------------------------------

再実行するとエラーが変わったが失敗してしまった。

[root@t1000cent ~]# ansible 192.168.11.223 -m ping -k
------------------------------
SSH password:
192.168.11.223 | FAILED! => {
    "msg": "Using a SSH password instead of a key is not possible because Host Key checking is enabled and sshpass does not support this.  Please add this host's fingerprint to your known_hosts file to manage this host."
}
------------------------------

メッセージを見ると~/.ssh/known_hostsに処理対象サーバーの署名を登録する必要がある旨書いてあるようなので、手動でssh接続して登録してみる。

[root@t1000cent ~]# ssh 192.168.11.223
------------------------------
The authenticity of host '192.168.11.223 (192.168.11.223)' can't be established.
ECDSA key fingerprint is SHA256:4sEF5Y1AsG3y4ywjkd9KOdILXIKTmcUDosmKGqJcrbA.
ECDSA key fingerprint is MD5:26:7c:6a:01:e5:a4:61:58:54:43:28:2c:18:cb:41:67.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.11.223' (ECDSA) to the list of known hosts.   ←★署名が登録される
root@192.168.11.223's password:
Last login: Wed Aug  1 18:47:58 2018
------------------------------

すると、ようやく接続に成功した!

[root@t1000cent ~]# ansible 192.168.11.223 -m ping -k
------------------------------
SSH password:
192.168.11.223 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
------------------------------

ssh接続時にパスワード入力を求められないようにする

とりあえず接続には成功するのだが、毎回パスワードを入力する必要があり面倒となる。そこで、Ansibleサーバー側にてssh接続用の秘密鍵と公開鍵のペアを作成し、公開鍵を処理対象サーバーに登録することで、パスワード入力なしでログインできるようにしておく。

まずはAnsibleサーバーにて秘密鍵と公開鍵のペアを作成する。

[root@t1000cent ansible]# ssh-keygen
------------------------------
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):   ←★そのままエンター
Enter passphrase (empty for no passphrase):   ←★そのままエンター
Enter same passphrase again:   ←★そのままエンター
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.

~(以下略)~
------------------------------

公開鍵を処理対象サーバーにコピーする。ssh-copy-idコマンドを使うことで、処理対象サーバーの~/.ssh/authorized_keysに公開鍵情報が登録される。

[root@t1000cent ~]# ssh-copy-id 192.168.11.223
------------------------------
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.11.223's password:   ←★処理対象サーバーのパスワードを入力

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '192.168.11.223'"
and check to make sure that only the key(s) you wanted were added.
------------------------------

-kオプションを抜いて接続確認をすると、パスワード入力をすることなく接続に成功した。

[root@t1000cent ~]# ansible 192.168.11.223 -m ping
------------------------------
192.168.11.223 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
------------------------------

Playbookを実行 (yumでパッケージをインストールする)

それでは、実際にAnsibleから処理を実行してみよう。今回は処理対象サーバーにyumを使ってtelnetをインストールさせてみる。
※処理対象サーバーはインターネット接続ができる必要あり

Playbookは以下のように超シンプルなものになる。

[root@t1000cent ~]# cat install_telnet.yml
------------------------------
---
- hosts: all
  tasks:
    - name: install telnet
      yum: name=telnet state=latest
------------------------------

それではPlaybookを実行してみよう。コマンドはansible-playbookとなる。

[root@t1000cent ~]# ansible-playbook install_telnet.yml
------------------------------
PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
ok: [192.168.11.223]

TASK [install telnet] **********************************************************
changed: [192.168.11.223]

PLAY RECAP *********************************************************************
192.168.11.223             : ok=2    changed=1    unreachable=0    failed=0
------------------------------

処理対象サーバーにてインストール結果を確認してみる。

[root@localhost ~]# cat /var/log/yum.log
------------------------------
Aug 03 21:47:29 Installed: 1:telnet-0.17-64.el7.x86_64 ←★インストールされている
------------------------------

このように、Ansibleでは簡単な処理であれば、たった4行のコードを書くだけで実行できてしまう。コードの内容もわかりやすいし、公式マニュアルも充実しているので、少ない学習時間で使えるようになるのがAnsibleの特徴と言えるだろう。

参考

yum - Manages packages with the yum package manager
https://docs.ansible.com/ansible/latest/modules/yum_module.html


2018年8月6日月曜日

HPEのEmulex製HBAのファームウェアをESXi Shellを使ってバージョンアップする方法

Amazonで8Gb FC HBA (ホストバスアダプター)が安く売られていた。



通常20万円するHBAが1.3万円程度となっており、怪しいと思いつつダメ元で買ってみた。すると、2週間ほど要したものの、普通に配送されてきた。


SFP+もきちんと付属していたが、ポートごとに形状が違っていた。他にも若干の汚れ(シールを剥がした後?)があり、実際は新品ではないんだろうなあと思いつつ、サーバーに差して動作確認してみたところ、問題なく認識し、正常に通信ができた。


というわけで、安くHBAを手に入れることができて、結果的に良い買い物ではあったが、ファームウェアが古かったので、ファームウェア更新を行うことにした。

HBAのファームウェアをバージョンアップする場合、メーカー提供のファームウェアバージョンアップ用のブートCD (HPEであれば、Service Pack for ProLiant) を利用し、実施することができる。しかし、ブートCDでのブートが必要となるため、サーバーの停止、ブートCDでの起動、バージョンアップ、バージョンアップ後の再起動といった作業が発生することから、メンテナンスのために必要となる作業時間と負荷が高い。

そこで、各社はブートCDとは別に、OSから直接ファームウェアをバージョンアップするためのツールを用意している。今回、ESXi 6.7環境のESXi Shellから直接Emulex製のHBAのバージョンアップ作業を実施したので、その手順について記載する。

HBAのファームウェアバージョンアップツールをダウンロードする

HPEのサーバーに対する、ESXi 6.5用のHBAのファームウェアバージョンアップのツールは、以下からダウンロードできる
※HBAはEmulex製とQLogic製の2種類があり別物となる
※ESXi 6.5用となっているが、ESXi 6.7でも使用はできた。ただし、メーカー正式サポートはされていないと思われるので注意

* RECOMMENDED * Emulexファイバーチャネルホストバスアダプター for VMware vSphere 6.5用HPEファームウェアフラッシュ
https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_997e3d792e444c449f69f55d53

* RECOMMENDED * QLogicファイバーチャネルホストバスアダプター for VMware vSphere 6.5用HPEファームウェアフラッシュ
https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_76b61eebb93045f6a0d05d4ad4

HPE以外のメーカーのサーバーの場合であっても同様のツールが用意されているものと想定されるため、メーカーサポート等に確認しよう。

実際にバージョンアップしてみる

Emulex製HBA AJ763Aに対してバージョンアップしてみた。

まずは、現在のHBAのファームウェアバージョンを確認するため、ESXi Shellにて以下コマンドを実行し、サーバーのNICやHBAの一覧を出力させる。

[root@localhost:~] /usr/lib/vmware/vmkmgmt_keyval/vmkmgmt_keyval -d
------------------------------
Dumping all key-value instance names:
Key Value Instance:  vmhba0/vmw_ahci
Key Value Instance:  vmhba2/Emulex ←★バージョンアップ対象のHBA
Key Value Instance:  vmhba1/Emulex ←★バージョンアップ対象のHBA

~(以下略)~
------------------------------

HBAの詳細情報を出力させる。現在のバージョンは1.00A12であることがわかる。なお、このファームウェアバージョンでググると、2009年のマニュアルが出てきたりすることから、かなり古いものであることがわかる。

[root@localhost:~] /usr/lib/vmware/vmkmgmt_keyval/vmkmgmt_keyval -l -i vmhba1/Emulex
------------------------------
Listing keys:
Name:   adapter
Type:   string
value:
lpfc Adapter Page

Emulex LightPulse FC SCSI 11.4.142.11
HP 8Gb Dual Channel PCI-e 2.0 FC HBA on PCI bus 0000:0c device 00 fn 0 port 0 Link Speed: 8 Gb

BoardNum:       0
FW Version:     1.00A12
HW Version:     31004549
ROM Version:    5.03a0
SerialNum:      XXXXXXXX
PCI ID:         10df f100 103c 3282

~(以下略)~
------------------------------

HPEのサイトから入手したHBAバージョンアップ用のzipファイルを/tmpに配置する。

[root@localhost:/tmp] ls -l
------------------------------
-rw-r--r--    1 root     root       5135821 Jul 19 16:53 CP032799.zip

~(以下略)~
------------------------------

zipファイルを解凍する。

[root@localhost:/tmp] unzip CP032799.zip
------------------------------
Archive:  CP032799.zip
 inflating: CP032799.vmexe
 inflating: CP032799.vmfile
 inflating: CP032799.xml
 inflating: payload.json
 inflating: README.txt
------------------------------

解凍したファイルを確認し、CP032799.vmexeに実行権限が付与されていることを確認しておく。

[root@localhost:/tmp] ls -l
------------------------------
-rwx------    1 root     root         26680 Jul 20 02:01 CP032799.vmexe
-rw-r--r--    1 root     root       5221264 Jul 20 02:01 CP032799.vmfile
-rw-r--r--    1 root     root         32518 Jul 20 02:01 CP032799.xml
-rw-r--r--    1 root     root       5135821 Jul 19 16:53 CP032799.zip
-rwxr-xr-x    1 root     root          1129 Jul 20 02:01 README.txt
-rw-r--r--    1 root     root         11042 Jul 20 02:01 payload.json
------------------------------

ファームウェアバージョンアップを実施する。CP032799.vmexeをそのまま実行するだけでよい。

[root@localhost:/tmp] ./CP032799.vmexe
------------------------------
Starting Smart Component...
argv[0]=[./hpsetup]
Calling OEMFLASHER.DOFLASH()...
Calling oem_do_discovery_with_files
m_oDiscoveryHeader.m_sDiscoveryFile=[/tmp/EMULEX_FC_HBA_DISC.xml]
m_sFirmwareBinDir=[./Flash/]
Vendor Return Code for discovery={0} [The installation of the deliverable was successful.  No reboot was required. Discovery was successful]
Load Component XML[./CP032799.xml]
Calling xmlParseFile to Update Discovery Data.
Update type=[emulex]
Update alt_name=[HPE Firmware Flash for Emulex Fibre Channel HBA's for ESXi 6.5]
Update version=[2017.06.02]
Update product_id=[82E PCIe FC HBA (AJ763A)]
Update product_id=[82E PCIe FC HBA (AJ763A)]
Saving Discovery Data
Calling xmlParseFile to Load Discovery Data
Load xml successful; Fetching Discovered Data...
No. of devices[2]
No. of FW Items for device[0]=[2]
*********************************
Calling oem_do_full_flash_PCI
Firmware=[./Flash/UD203X14.ALL] ForceInstall=[0]
PCI Bus=[12] Device=[0] Function=[0]
Vendor Return Code ={0} [The installation of the deliverable was successful.  No reboot was required. Discovery was successful]
*********************************
*********************************
Calling oem_do_full_flash_PCI
Firmware=[./Flash/UU1120A7.PRG] ForceInstall=[0]
PCI Bus=[12] Device=[0] Function=[0]
Vendor Return Code ={0} [The installation of the deliverable was successful.  No reboot was required. Discovery was successful]
*********************************
No. of FW Items for device[1]=[2]
*********************************
Calling oem_do_full_flash_PCI
Firmware=[./Flash/UD203X14.ALL] ForceInstall=[0]
PCI Bus=[12] Device=[0] Function=[1]
Vendor Return Code ={0} [The installation of the deliverable was successful.  No reboot was required. Discovery was successful]
*********************************
*********************************
Calling oem_do_full_flash_PCI
Firmware=[./Flash/UU1120A7.PRG] ForceInstall=[0]
PCI Bus=[12] Device=[0] Function=[1]
Vendor Return Code ={0} [The installation of the deliverable was successful.  No reboot was required. Discovery was successful]
*********************************
SC Return Code for Discovery={0} [The installation of the deliverable was successful.  No reboot was required. Discovery was successful]   ←★リブート不要のメッセージ
Ending flasher ...
SCEXE_SUCCESS:-->0   ←★リターンコード0を確認しておく
------------------------------

HBAの詳細情報を出力させる。バージョンが1.00A12→2.03X14にバージョンアップされていることがわかる。

[root@localhost:/tmp] /usr/lib/vmware/vmkmgmt_keyval/vmkmgmt_keyval -l -i vmhba1/Emulex
------------------------------
Listing keys:
Name:   adapter
Type:   string
value:
lpfc Adapter Page

Emulex LightPulse FC SCSI 11.4.142.11
HP 8Gb Dual Channel PCI-e 2.0 FC HBA on PCI bus 0000:0c device 00 fn 0 port 0 Link Speed: 8 Gb

BoardNum:       0
FW Version:     2.03X14
HW Version:     31004549
ROM Version:    11.20a7
SerialNum:      XXXXXXXX
PCI ID:         10df f100 103c 3282

~(以下略)~
------------------------------

以上のように、ESXiからもファームウェアバージョンアップが実施できた。再起動も不要だったので作業負荷が少なく、大変お勧めである。

人気の投稿