2017年4月28日金曜日

vCenter Serverは不要。ESXi単独で仮想マシンのクローンを作る方法

vSphere環境で仮想マシンのクローンを作る場合は、vCenter Serverを用意する必要があると思っていたが、実はESXiシェルのコマンドを使えばESXi単独でクローンが作れてしまうことを最近知った。

若干手順が多くなるのでちょっと手間ではあるものの、無償のESXiのみの環境であってもクローンが使えることは非常に便利である。例えば、よく使うOSの仮想マシンはテンプレートとして1台作っておいて、今回記載する手順でクローンして使うようにすれば、検証作業のたびにOSインストールから始める必要がなくなって効率がよくなる。

ESXi単独での仮想マシンのクローンの手順

以下に手順を記載していく。

1. クローン先の仮想マシンの箱を作成

vSphere Clientなどでクローン元と同じ構成で仮想マシンを作成する。仮想マシン作成時に「標準」と「カスタム」が選べるが、「標準」を選んだ場合、必ず仮想マシンに1つディスクを作成する必要がある。このディスクは次の手順ですぐに消すため、1GBと小さくして作成しておけばよい。
※「カスタム」の場合は、ディスクを作らない仮想マシンの箱を作成できる。


2. クローン先の仮想マシンのディスク削除

仮想マシン作成時に作られたディスクは不要なので、仮想マシンから削除(ディスクからも削除)しておく。


3. sshでESXiシェルにログイン

Tera Termなどでログインする。なお、ESXiの場合は、「チャレンジレスポンス認証」を選んでログインする。

4. コピー元ディスクの確認

データストアは以下パスに存在する。

/vmfs/volumes/<データストア名>/<仮想マシン名>

クローン元のファイルを事前に確認しておく。コピー対象となるファイルは*.vmdkファイルとなる。以下確認例となる。

[root@t3011es60:~] ls -l /vmfs/volumes/ssd_local_01/t1162w28r/
total 7388176
------------------------------
-rw-------    1 root     root     42949672960 Apr 26 13:55 t1162w28r-flat.vmdk
-rw-------    1 root     root          8684 Apr 26 13:41 t1162w28r.nvram
-rw-------    1 root     root           524 Apr 26 13:55 t1162w28r.vmdk
-rw-r--r--    1 root     root            43 Apr 26 13:55 t1162w28r.vmsd
-rwxr-xr-x    1 root     root          2806 Apr 26 13:55 t1162w28r.vmx
-rw-------    1 root     root          4151 Apr 17 05:19 t1162w28r.vmxf
-rw-r--r--    1 root     root       1203822 Apr 18 21:24 vmware-1.log
-rw-r--r--    1 root     root        267260 Apr 26 13:41 vmware.log
------------------------------

5. ディスクコピーの実施

以下コマンドで仮想マシンのディスクをコピーする。

vmkfstools -i <クローン元> <クローン先> -d <ディスク形式>

"-d"オプションでディスクの形式を選択できる。

・zeroedthick (default) : シックプロビジョニング
・thin : シンプロビジョニング
・eagerzeroedthick : EagerZeroedThick (作成時に0書き込み)

以下シンプロビジョニング形式でクローンを作成する実行例となる。

[root@t3011es60:~] vmkfstools -i /vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r.vmdk  /vmfs/volumes/iscsi_qnap_01/t1165w28r/t1165w28r.vmdk -d thin
------------------------------
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r.vmdk'...
Clone: 100% done.
------------------------------

なお、仮想マシンがパワーオン状態の場合、以下のようにファイルがロックされているメッセージが表示されてしまいクローンが実行できない。

------------------------------
Failed to open '/vmfs/volumes/ssd_local_01/t1162w28r/t1162w28r-000001.vmdk': Failed to lock the file (16392).
Command exited with non-zero status 255
------------------------------

この場合は、一度仮想マシンのスナップショットを取得してから、再度vmkfstoolsコマンドを実行すれば成功する(スナップショットを取得すると、vmdkファイルのロックが差分用のvmdkファイルに移るため)。一時的にスナップショットを取得した場合は、作業後のスナップショット削除も忘れずに。

6. 仮想マシンにディスクを追加

vSphere Clientで、先ほどコピーしたvmdkファイルを指定して、仮想マシンのハードディスクを追加する。



7. 仮想マシンを起動

仮想マシンを起動する。特に問題なくログイン画面が表示される。


なお、仮想マシン起動状態でクローンを実施した場合は、以下のように正常にシャットダウンされなかった旨が表示されるが、「windows を通常起動する」を選べばOSは起動できる。


参考

ESX/ESXi ホスト端末を使用して個々の仮想マシン ディスクのクローンを作成する (2078416)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2078416

vmkfstools を使用した仮想マシン ディスクのクローン作成および変換 (2078921)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2078921

2017年4月22日土曜日

ESXi 6.0上にESXi 5.5の仮想マシンを作って、ESXi用のVMware Toolsをインストールした話 (ESXi on ESXi)

自宅の検証環境はESXi 6.0で構築しているが、ちょっとESXi 5.5の検証作業が必要になったので、仮想マシンとしてESXi 5.5を作成することにした。これは、Nested ESXiとかESXi on ESXiと呼ばれる方法で、検証等ではよく用いられる手法である。

本記事ではESXi 6.0上にESXi 5.5の仮想マシンを作成する方法と、ESXi 5.5用のVMware Toolsのインストール手順について記載する。

ESXiのインストール

まず、ESXi用に仮想マシンの箱を作成する。ESXi 6.0では、仮想マシンのOS選択にて、「その他」の中にESXiが選べるようになっているので、適切な種類を選択すればよい。今回は、ESXi 5.5なので、「VMware ESXi 5.x」を選択した。


また、ESXiにはインストール最小要件があるので注意する。以下KBに記載がある通り、ESXi 5.5の場合は、CPUは2コア以上、メモリは4GB以上必要となる。

・ESXi 5.5 のインストールおよびアップグレードのベスト プラクティス (2080534)
 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080534

作成した仮想マシンを起動する前に、vmxファイルを修正する必要がある。データストアブラウザにてvmxファイルをダウンロードし、最下行に以下2行を追加したのち、アップロードして上書きする。

------------------------------
vhv.enable = "TRUE"
hypervisor.cpuid.v0 = "FALSE"
------------------------------

作成した仮想マシンを起動させ、VMware社のサイトからダウンロードしたESXiのisoをマウントしてブートさせる。Nested ESXiであっても、インストール方法は特に変化がないため、ここでは詳細は割愛する。なお、ここで、CPUやメモリが最小要件を満たしていない場合、以下のようなエラーメッセージが表示され、インストールを進めることができないので注意。


ESXiの初期設定

正常にESXiのインストールが終わり、起動が完了したら、まずは仮想マシンのコンソールを用いて、管理用のIPアドレス設定をしておこう。


管理用ポートの設定ができれば、後はvSphere Clientにて接続して操作・設定が可能となる。ただし、ESXi 5.5にはvSphere Client 6.0では接続できないので、vSphere Client 5.5をインストールしておくことが必要となる。

なお、vSphere Clientは上書きインストールにはならず、各バージョンが共存して利用可能である(接続先のESXiやvCenter Serverのバージョンに応じて、適切なバージョンのvSphere Clientで接続がされる)ので、既に別バージョンのvSphere Clientがインストールされていたとしても、単純にvSphere Client 5.5のインストーラーを実行して、インストールしてしまえばよい。

ESXi用のVMware Toolsのインストール

以下URLからESXi用のVMware Toolsをダウンロードできる。

・VMWARE TOOLS FOR NESTED ESXI
 https://labs.vmware.com/flings/vmware-tools-for-nested-esxi#summary

なお、上記VMware Toolsは、ESXi 6.0以降をネストする場合は不要のようだ。後述するURLに「This Fling's functionality is now integrated into ESXi 6.0 and later. However, you can still download the Fling for ESXi 5.*」と記載されているとおり、ESXi 6.0以降では本機能(VMware Tools)は、もともと本体に組み込まれている模様。

ちなみに、ダウンロード場所が若干わかりずらいが、本文にさらりと記載されている、「This VIB package」のリンクをクリックすればよい。以下ファイル名のVIBファイルがダウロードされる。容量は2MB以下とコンパクト。

 esx-tools-for-esxi-9.7.2-0.0.5911061.i386.vib

ダウンロードしたVIBファイルは、vSphere Clientのデータストアブラウザを使って、アップロードしておく。今回は、ESXiのローカルディスクであるdatastore1にアップロードした。


VIBファイルをアップロードした後は、ESXiシェルにてインストールを実施する。親ESXiにて仮想コンソールを使うか、sshを有効にしている場合はsshにてESXiシェルにログインする。

ログインしたのち、以下コマンドを実行する。実行後、「The update completed successfully」と表示されれば成功。

# esxcli software vib install -v /vmfs/volumes/datastore1/esx-tools-for-esxi-9.7.2-0.0.5911061.i386.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: VMware_bootbank_esx-tools-for-esxi_9.7.2-0.0.5911061
   VIBs Removed:
   VIBs Skipped:
------------------------------

インストール結果に記載されている通り、ESXiの再起動が必要となるため、再起動をしておく。

# shutdown -r

後は親ESXiでVMware Toolsの実行状況を確認すればよい。「実行中 (サポート対象外)」という表示になっていればOK。IPアドレス情報が確認できるし、ゲストのシャットダウン等の機能も利用できるようになる。


以上で作業は完了となる。

2017年4月14日金曜日

ZabbixでCPUやメモリなどのリソース監視を行う

先日、ESXiのCPU、メモリの使用率をグラフに表示するという記事を書いた。その後しばらくして、ESXiのCPU使用率が高い値で張り付くという事象が発生した。


原因は、1台の仮想マシン(Windows Server)のSQL Serverが高負荷になったことであり、仮想マシンの再起動で復旧できた。しかし、根本原因は不明であり、不定期に再発することもあったことから、ZabbixでCPUのリソース監視を行うことにした。

アイテムを作る

ESXiのCPU使用率とメモリ使用率のアイテムの作り方は、別記事を参照。

トリガーを作る

「設定」→「テンプレート」→「Template Virt VMware Hypervisor」→「トリガー」を選択し、トリガーを新規作成する。

今回は例として、CPU周波数が2GHz = 2000000000Hzを600秒超過した場合に、「重度の障害」として検知する設定となる。余談だが、"2G"という表記でもZabbixは認識してくれるが、2G = 2*1024*1024*1024となり、正確な値にならないので注意が必要。

------------------------------
・名前:High CPU Usage
・条件式:{Template Virt VMware Hypervisor:vmware.hv.cpu.usage[{$URL},{HOST.HOST}].avg(600)}>2000000000
・深刻度:重度の障害
・障害イベントを継続して生成:チェックなし
・有効:チェックあり
------------------------------


なお、メモリを監視したい場合の条件式に入れる値は以下のようになる。
※事前にアイテムを作成していることが必要

------------------------------
・メモリ使用量
 vmware.hv.memory.used[{$URL},{HOST.HOST}]
・メモリバルーン
 vmware.hv.memory.size.ballooned[{$URL},{HOST.HOST}]
------------------------------

グラフで確認

グラフを作ってある場合は、グラフにもトリガー設定の閾値が表示されるので確認しておこう。今回設定した2GHzが監視閾値として、点線で表現されていることがわかる。


以上で設定は完了となる。

2017年4月9日日曜日

オープンソースのログ統合管理ツール「Graylog」でsquidのログを管理する

自宅の検証環境では、squidを使ってプロキシサーバーを構築しており、このプロキシサーバーを経由してインターネットにアクセスするように構成している。このsquidログをsyslogでGraylogに飛ばして管理してみたのだが、ログの中身までは分析されず、ただ保存されるだけとなってしまい、統計情報を確認したり、ログを分析することは困難となっていた。

そこで、Graylogでこのsquidログに対し、分類・タグ付け(ログの正規化)を行い、統計情報を表示できるようにしてみた。

GraySquidのダウンロード

まず、Graylogにてsquidを管理するためのContent Packを以下からダウンロードしておく。

GraySquid
https://marketplace.graylog.org/addons/bd3efa5f-6ccb-47ce-97ea-6ebe0270a9c7

拡張子が.jsonとなるJSONで記載されたテキストファイルがダウンロードされる。
※JSON (JavaScript Object Notation):XMLのようなテキストベースのデータフォーマット

このContet Packの概要は以下の通り。

 ・Graylogの受信ポート番号はTCP/19302を使う
 ・squidログは標準形式のものを取り込む(apacheのログ形式はきちんと取り込めない)
 ・squidログの各種情報(アクセス先URLやステータスコードなど)を正規化して取り込む
 ・squidの直近の通信の統計情報を表示するDashboardも用意されている

GraylogにGraySquidをインポート

GraylogのWeb GUIにログインし、Content Packのインポートから実施する。

「System」→「Content Packs」を選択し、「Select content packs」の一番下に「Import Content Pack」という項目があるため、先ほどダウンロードしたJSONのファイルを選択し、「Upload」ボタンを押下する。


インポートが成功すると、「Select content packs」に「Proxies」という項目が新たに表示されるので、その中の「Squid Logs」を選択し、「Apply Content」ボタンを押下する。


これだけで、TCP/19302で受信したログをsquidのログとして取り込む準備が完了する。

squid側の設定

squid側でログを飛ばす設定を行う。squidのaccess.logをrsyslogにてGraylogに飛ばす設定となる。なお、今回ログを飛ばすOS、squid、rsyslogのバージョンは以下の通りとなる。

# cat /etc/redhat-release
------------------------------
CentOS Linux release 7.3.1611 (Core)
------------------------------

# squid -v
------------------------------
Squid Cache: Version 3.5.20
------------------------------

# rsyslogd -v
------------------------------
rsyslogd 7.4.7
------------------------------

squidがインストールされたLinuxにログインし、以下ファイルを新規作成する。

# vi /etc/rsyslog.d/60-squid.conf
------------------------------
# Load Modules
module(load="imfile")
module(load="omfwd")

# rsyslog Input Modules
input(type="imfile"
         File="/var/log/squid/access.log"
         Tag="squid-access"
         Severity="info"
         Facility="local7"
         ruleset="SquidForward")

# rsyslog RuleSets
ruleset(name="SquidForward") {
        action(type="omfwd"
        Target="<GraylogのIPアドレス>"
        Port="19302"
        Protocol="tcp"
        template="RSYSLOG_SyslogProtocol23Format")
}
------------------------------

設定反映のため、rsyslogサービスをリスタートする。

# systemctl restart rsyslog
# systemctl status rsyslog   ←確認
------------------------------
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since 日 2017-04-02 07:22:34 JST; 5s ago
 Main PID: 5493 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           mq5493 /usr/sbin/rsyslogd -n

 4月 02 07:22:34 t3023ce72 systemd[1]: Starting System Logging Service...
 4月 02 07:22:34 t3023ce72 systemd[1]: Started System Logging Service.
------------------------------

Graylogにてログの確認

squid側の設定が完了したら、実際にログが表示されることを確認する。

「Search」タブにてログを表示させ、squidのログをクリックしてみる。MethodやStatus_Codeがそれぞれ分類されて表示されており、ログが正規化されていることがわかる。


次に「Dashboards」を選択すると、以下3つのDashboardが追加されていることがわかる。

 ・Squid TCP_ALLOWED
 ・Squid TCP_DENIED Stats
 ・SquidStats


お勧めは3つめの「SquidStats」で、直近15分のsquidを経由した通信の統計情報が表示される。直近15分では統計情報として物足りないのであれば、時間をカスタマイズすることも可能な模様。ただし、時間を延ばせば、その分Graylogの処理も増えるはずなので、マシンリソースと相談して設定するのがよいだろう。



以上で、Graylogにてsquidログを正規化して取り込み、統計情報を表示することができた。ただし、squidログは生ログで見ると時間表示がUNIX時間(1970/1/1からの累計時間)で表示される仕様となっており、人間が確認する場合は視認性がいまいちである。squidログはapache形式にログ表示を変えることができるので、apache形式でログ取得して同様のことができないかも調べていきたい。

2017年4月2日日曜日

オープンソースのログ統合管理ツール「Graylog」の仮想アプライアンスをインストールしてみた

昨年、SIEM(Security Information Event Management)を検討する機会があり、SplunkやMcAfee SIEMの評価版を自宅の検証環境に入れて使っていた。当たり前だが、SplunkもMcAfee SIEMも評価版は使用日数に制限があり(Splunkは60日、McAfee SIEMは30日)、長期的に利用することは不可能であった。そこで、オープンソースでログを統合管理するツールがないかと探していたら、「Graylog」を発見した。

試しにGraylogの仮想アプライアンスをインストールしてみて使ってみたら、なかなか有用なツールと感じた。本記事ではGraylogの仮想アプライアンスのインストールと初期設定の手順を記載する。

Graylogの入手とインストール

Graylogのインストーラは以下から入手する。2017年4月時点の最新バージョンは、2.2.2となっていた。

Graylog - Download and Install
https://www.graylog.org/download

今回はVMware ESXi上に展開するので、「OVA」ファイルをダウンロードする。

OVAファイルの展開は、vSphere Clientにて「ファイル」→「OVFテンプレートのデプロイ」にて実施する。設定項目はデフォルトで問題ない。私の場合は、ディスク容量の削減のため、ディスクの種類を「Thin Provision」にしている。


OVAテンプレートのデプロイが完了する。仮想アプライアンスのリソースはCPU2コア、メモリ4GBとなっているが、ここもデフォルトのままで問題ない。最初、リソース削減のため、CPUを1コアにしてみたが、CPU使用率が100%で張り付いたりしたので、1コアではちょっときつい模様。


問題なければパワーオンする。起動時にvSphere Clientにて以下のメッセージが表示されるが、「はい」を選んで「OK」を押しておけば問題なく起動する。

------------------------------
Virtualized Inter-VT-x/EPT is incompatible with this virtual machine configration.
仮想msg.intel.hvhwnnuを使わずに続行しますか?
------------------------------


Graylogの仮想アプライアンスは、ubuntu 14.04がベースとなっている。起動時はNICのDHCP機能が有効になっているので、IPアドレスの取得待ちに少し時間を要するが、ログインプロンプトが表示されるまで待機する。なお、ログインプロンプト表示の際に、以下メッセージが表示されている場合があるが、同じくDHCPでIPが取得できなかったことに起因するメッセージなので無視してOK。

------------------------------
Your appliance came up without a configured IP address. Graylog is probable not running correctly!
------------------------------


インストール後の初期設定

Graylogの初期設定を実施し、Web GUIにログインできるようにする。

ログインとパスワード変更

まずはログインとなる。初期パスワードは以下の通り。

 ユーザー名:ubuntu
 パスワード:ubuntu

ログインしたら、とりあえずパスワードを変更しておく。

$ passwd
------------------------------
Changing password for ubuntu.
(current) UNIX password:<現在のパスワード>
Enter new UNIX password:<新パスワード>
Retype new UNIX password:<新パスワード>
passwd: password updated successfully
------------------------------

IPアドレス設定

IPアドレスの設定はubuntuと同じ方式で設定すればよい。viで以下ファイルを開き編集する。なお、ubuntuなので、頭にsudoを付けて編集しているが、毎回sudoを付けるのが面倒な場合は"sudo su -"でrootになってしまってもよい。

$ sudo vi /etc/network/interfaces
------------------------------
# The primary network interface
auto eth0
#iface eth0 inet dhcp       ←コメントアウト
#pre-up sleep 2         ←コメントアウト

iface eth0 inet static      ←追加 (静的IPアドレス付与)
address 192.168.11.151      ←追加 (IPアドレス)
netmask 255.255.255.0      ←追加 (サブネットマスク)
gateway 192.168.11.1       ←追加 (デフォルトゲートウェイ)
dns-nameservers 192.168.11.1   ←追加 (DNS)
------------------------------

設定反映のためにインターフェースの落とし上げを行う。

$ sudo ifdown eth0
$ sudo ifup eth0

設定を確認しておく。

$ ifconfig
------------------------------
ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:3a:6a:6f
          inet addr:192.168.11.151  Bcast:192.168.11.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe3a:6a6f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
------------------------------

Graylogの初期設定

Graylogのアプリケーションとしての初期設定は以下2つのコマンドを実行するのみ。

まずは、Web GUIのログイン時のパスワードを変更する。

$ sudo graylog-ctl set-admin-password <新パスワード>

次に、タイムゾーンを変更する。

$ sudo graylog-ctl set-timezone "Asia/Tokyo"

最後に設定反映のコマンドを実行するのだが、この際にapt-getが動作するようで、インターネットへの接続ができる状態で実行したほうがよい。プロキシ環境の場合は、以下の通りプロキシ設定を実施しておく。

$ export http_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
$ export https_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
$ export ftp_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
$ export ←確認コマンド
------------------------------
declare -x ftp_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
declare -x http_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
declare -x https_proxy="http://<プロキシのIPアドレス>:<プロキシのポート>/"
------------------------------

設定反映のコマンドを実行する。このコマンドは少々時間がかかる。プロキシ設定の環境変数を引き継ぐ必要があるので、"sudo"ではなく"sudo -E"で実行すること。

$ sudo -E graylog-ctl reconfigure

open-vm-toolsのインストール

仮想アプライアンスなのに、なぜかopen-vm-toolsが入っていないなので、apt-getでインストールする。

$ sudo -E apt-get update
$ sudo -E apt-get install open-vm-tools

GraylogのWeb GUIにログイン

以上で初期設定は終わりとなる。ブラウザからhttpにて仮想アプライアンスのIPアドレスを指定すると、ログイン画面が表示される。


以下のユーザー名、パスワードでログインする。

 ユーザー名:admin
 パスワード:<先ほど設定したパスワード>

以下のような画面が表示されればログイン成功。


LinuxのSyslogを転送させてみる

Graylogは初期状態からsyslog転送をUDP/514ポートで受け付ける状態になっているので、試しにLinuxサーバーからSyslogを転送させてみる。

Syslog送信元サーバーで、/etc/rsyslog.confの最後に以下設定を追加する。
※192.168.11.151はGraylogのIPアドレスに適宜変更

# vi /etc/rsyslog.conf
------------------------------
*.* @192.168.11.151:514;RSYSLOG_SyslogProtocol23Format
------------------------------

設定反映のため、rsyslogサービスをリスタートする。

# systemctl restart rsyslog
# systemctl status rsyslog   ←確認
------------------------------
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since 日 2017-04-02 07:22:34 JST; 5s ago
 Main PID: 5493 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           mq5493 /usr/sbin/rsyslogd -n

 4月 02 07:22:34 t3023ce72 systemd[1]: Starting System Logging Service...
 4月 02 07:22:34 t3023ce72 systemd[1]: Started System Logging Service.
------------------------------

これで、GraylogのWeb GUIにて、「Search」をクリックすると、ログが表示されるはず。


以上でインストールと初期設定は終了となり、とりあえずログを溜めて検索する機能は利用可能になる。Graylogには各種ログを解析するための「Content Pack」と呼ばれる、様々なログに対応したプラグインが提供されているので、今後それらを追加してログの分析ができるようにしていきたい。

2017年3月20日月曜日

USB3.0の1Gb 物理NICを買って仮想マシンに接続してみた

USB3.0になってから、データ転送速度が4Gbps=500MB/sになったということで、1GbpsのNICよりも転送速度が速くなっている(USB2.0は480Mbps=60MB/s)。今は安価でUSB3.0の1Gbpsの物理NICが売られているので、1つ買って検証用マシンのNICを増設することにした。

できることなら、ESXi自体のNICとして利用したかったのだが、案外手間がかかりそうだったので、仮想マシンのNICとして使うことにした。

購入したUSB3.0のNIC

今回購入したNICは以下となる。有名なメーカーでは無いが、安価だったことが購入の決め手となった。Amazonのレビューでも記載されているが、中身のチップセットはRealtek RTL8153となる。

このNICをESXiとして利用している物理マシンのUSB3.0ポートに接続し、ESXi自体で認識状況を確認してみる。1行目に「8153 Realtek」の文字が確認でき、ESXiとしても認識はしているようだ。

[root@esx01:~] lsusb
------------------------------
Bus 004 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. 
Bus 003 Device 003: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash Card Reader
Bus 003 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
------------------------------

仮想マシンへの接続

続けて、NICを仮想マシンに接続する。vSphere Clientにて、接続したい仮想マシンを選んで、「設定の編集」を開く。

USBデバイスを使用する前に、まずはUSBコントローラを追加する必要がある。「追加」ボタンを押し、「USBコントローラ」を選択する(この時点では「USBデバイス」はグレーアウトしており追加不可)。コントローラタイプとして、"EHCI+UHCI"と"xHCI"の2種類が選択可能だが、USB3.0の場合は、"xHCI"を選ぶ。



一旦、「OK」を押して設定の編集画面を閉じたのち、再度「設定の編集」を開く。「USBデバイス」を選択すると、"Realtek USB 10/100/1000 LAN"が選択できるはずなので選択する。



これで仮想マシンにNICが追加された。Windowsの場合は標準のドライバで認識しているはず。Windows Server 2016の場合は、"usb_xhci"という名前でNICが表示された。



Windowsのドライバーの更新

Windows標準のドライバーで認識はするものの、最新ドライバーとなっていない。例えばWindows Server 2016では、OS標準ドライバーのバージョンは10.5となるが、本記事を記載した時点の最新ドライバーは10.13になる。そこで、最新のドライバーファイルを入手し更新することにする。

以下は、OS標準ドライバーの状態。2015年9月のドライバーとなっている。



ドライバーの最新バージョンの確認とダウンロードは、以下URLから実施できる。

Realtek - Software: Drivers & Utilities RTL8153
http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false

ダウンロードしたドライバーのフォルダの中にsetup.exeが同梱されているが、今回はデバイスマネージャーから更新を行うことにする。

デバイスマネージャーを開き、「Realtek USB GbE Family Controller」のプロパティを開き、「ドライバーの更新」を選択する。



ドライバーファイルのパスを聞かれるので、

   <ドライバーの解凍パス>\WIN10\64\rtux64w10.INF

を選択する。

  
後は自動でドライバーが更新され、バージョンが最新となっていればOK。


このNICを使ってQNAPのNASにファイル転送を実施してみると、100MB/s以上の転送速度が出るので、1Gbpsの帯域近くまで使えており、1000円程度のNICでも問題なく速度が出ることがわかった。最近は無線LANのみで物理NICを持たないノートPCが多いので、サーバーメンテナンス等で物理NICが欲しい場合に備えて、1個持っておくのはよいかもしれない。

2017年3月3日金曜日

CentOS 7にunboundをインストールしてDNSキャッシュサーバーにしてみた

DNSといえば昔からBINDが有名だが、BINDは機能が高度化して複雑になっており、それゆえ脆弱性の問題が多く発見される傾向にある。

以下サイトでまとめられているが、1か月に1回は脆弱性情報が公開される印象がある。

・JPRS DNS関連技術情報
https://jprs.jp/tech/

というわけで、単純なDNSキャッシュサーバーであれば、そろそろBINDを使わなくてもよいのではないか?ということで、unboundというOSSを使ってみることにした。

unbound導入手順

今回はCentOS 7.3にunboundを導入する。

1. yumでunboundをインストール

yumを使ってインストールする。

# yum install unbound
------------------------------
読み込んだプラグイン:fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.nus.edu.sg
 * extras: centos.usonyx.net
 * updates: mirror.vastspace.net
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ unbound.x86_64 0:1.4.20-28.el7 を インストール
--> 依存性の処理をしています: unbound-libs(x86-64) = 1.4.20-28.el7 のパッケージ: unbound-1.4.20-28.el7.x86_64
--> 依存性の処理をしています: ldns >= 1.6.16-10 のパッケージ: unbound-1.4.20-28.el7.x86_64
--> 依存性の処理をしています: libunbound.so.2()(64bit) のパッケージ: unbound-1.4.20-28.el7.x86_64
--> 依存性の処理をしています: libldns.so.1()(64bit) のパッケージ: unbound-1.4.20-28.el7.x86_64
--> 依存性の処理をしています: libevent-2.0.so.5()(64bit) のパッケージ: unbound-1.4.20-28.el7.x86_64
--> トランザクションの確認を実行しています。
---> パッケージ ldns.x86_64 0:1.6.16-10.el7 を インストール
---> パッケージ libevent.x86_64 0:2.0.21-4.el7 を インストール
---> パッケージ unbound-libs.x86_64 0:1.4.20-28.el7 を インストール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 Package              アーキテクチャー
                                     バージョン              リポジトリー  容量
================================================================================
インストール中:
 unbound              x86_64         1.4.20-28.el7           base         473 k
依存性関連でのインストールをします:
 ldns                 x86_64         1.6.16-10.el7           base         476 k
 libevent             x86_64         2.0.21-4.el7            base         214 k
 unbound-libs         x86_64         1.4.20-28.el7           base         296 k

トランザクションの要約
================================================================================
インストール  1 パッケージ (+3 個の依存関係のパッケージ)

総ダウンロード容量: 1.4 M
インストール容量: 4.4 M
Is this ok [y/d/N]: y
Downloading packages:
(1/4): ldns-1.6.16-10.el7.x86_64.rpm                       | 476 kB   00:00  
(2/4): unbound-1.4.20-28.el7.x86_64.rpm                    | 473 kB   00:00  
(3/4): unbound-libs-1.4.20-28.el7.x86_64.rpm               | 296 kB   00:00  
(4/4): libevent-2.0.21-4.el7.x86_64.rpm                    | 214 kB   00:00  
--------------------------------------------------------------------------------
合計                                               1.4 MB/s | 1.4 MB  00:00  
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction

~(中略)~

インストール:
  unbound.x86_64 0:1.4.20-28.el7                                              

依存性関連をインストールしました:
  ldns.x86_64 0:1.6.16-10.el7               libevent.x86_64 0:2.0.21-4.el7    
  unbound-libs.x86_64 0:1.4.20-28.el7    

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

yumが使えない場合は、rpmからインストールする必要があるが、依存するパッケージとインストール順序は以下の通りとなる。

------------------------------
 1 -> libevent-2.0.21-4.el7.x86_64.rpm
 2 -> ldns-1.6.16-10.el7.x86_64.rpm
 3 -> unbound-libs-1.4.20-28.el7.x86_64.rpm
 4 -> unbound-1.4.20-28.el7.x86_64.rpm
------------------------------

2. unbound設定

/etc/unbound/unbound.confを編集し、必要な設定を行う。デフォルトではすべてがコメントアウトされているので、必要な部分をコメントインしたり、追記したりすればよい。

以下に修正箇所を記載する。

------------------------------
server:
       interface: 0.0.0.0     ←すべてのアドレスからの問い合わせに回答(IPv4)
       interface: ::0       ←すべてのアドレスからの問い合わせに回答(IPv6)

       access-control: 0.0.0.0/0 refuse   ←デフォルト拒否(IPv4)
       access-control: 127.0.0.0/8 allow  ←ループバックアドレスを許可(IPv4)
       access-control: 192.168.1.0/24 allow ←問い合わせを許可するネットワーク
       access-control: ::0/0 refuse     ←デフォルト拒否(IPv6)
       access-control: ::1 allow       ←ループバックアドレスを許可(IPv6)
       access-control: ::ffff:127.0.0.1 allow ←ループバックアドレスを許可(IPv6)

 forward-zone:           ←コメントインする
       name: "."            ←すべてのドメインに対してフォワード
       forward-addr: 129.250.35.250 ←フォワード先DNS(今回はNTT America Technical Operations)
       forward-addr: 8.8.8.8      ←フォワード先DNS(今回はGoogle Public DNS)
------------------------------

3. 設定ファイルのチェック

unboundには設定ファイルをチェックするコマンドが用意されている。これはサービス起動時に自動で実行されるが、手動でも実行可能。

# unbound-checkconf
------------------------------
unbound-checkconf: no errors in /etc/unbound/unbound.conf
------------------------------

4. 設定ファイル再読み込みのため、unboundを再起動

最後に設定繁栄のためunboundを再起動する。

# systemctl restart unbound
# systemctl status unbound
------------------------------
unbound.service - Unbound recursive Domain Name Server
   Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled)
   Active: active (running) since 土 2017-02-25 12:03:22 JST; 2s ago
  Process: 28392 ExecStartPre=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
  Process: 28391 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS)
 Main PID: 28395 (unbound)
   CGroup: /system.slice/unbound.service
           mq28395 /usr/sbin/unbound -d

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

5. DNS名前解決先を自分自身にする

必須ではないが、最後にOS自身の名前解決も自分自身に変えておく。

# vi /etc/resolv.conf
------------------------------
nameserver 127.0.0.1
------------------------------

以上でインストール作業は終了。私の環境ではインストールから半月ほど経過しているが、特に問題なく動作している。