designetwork

ネットワークを軸としたIT技術メモ

自宅ラボ+VyOSでネストESXiホスティング環境を構築する

自宅でサーバの勉強をしたいが、古いPC(32bit)しかなくESXiを構築できない、という同僚がおり、検証環境を提供するため、自宅ラボにESXiホスティング環境を構築した。

私はこの記事で選定したサーバでESXi v6.5を運用おり、メモリーは24GBに増強したが余しているため、部分的に切り出して貸し出してみようと思う。

designetwork.hatenablog.com

自宅サーバホスティングを事業として収入を得る場合は、電気通信事業法の内容を要確認。今回は無償提供なので抵触しない。

ネットワーク構成

実現性とセキュリティを考慮して、自宅ラボの中で以下のような位置付けでホスティング環境を構築した。検討ポイントは後述のとおり。

f:id:daichi703n:20170618033628p:plain

独立したネストESXiをホスティング

ホスティングは基本的にはLinuxWindowsのサーバ単位での貸し出しとなる。しかし、今回はESXi (VMware vSphere) を含めて自由に検証できる環境を提供したい。

自分用のESXiを提供し共有するのはプライバシー的に好ましくないので、ネスト構成でESXiを新規構築する。(いずれもESXi v6.5)

ユーザからするとネストであることは意識する必要がなく、通常通りESXi上にLinuxWindows、仮想アプライアンスなどのVMを自由に作成することができる。

ホスティング環境をネットワーク的に分離

図に記載の通り、ホスティング環境は自分のinside, dmzと完全に分離している。ネットワーク分離のために、仮想ルータVyOSを導入し、セグメント分割している。ASA5505はライセンス上限でVLAN追加不可で、また、仮想ルータはCisco CSRやXRV、F5 BIG-IP VEなどを使用したかったが、無償版ではスループット制限(数Mbps程度)があり、実用に耐えず、OSSのVyOSを選定した。

なお、ホスティング環境からはインターネットへのみ通信可能とするが、inside->hostingのメンテナス通信はしたいため、VyOSのステートフルファイアウォールを使用し、通信の開始方向を含めたアクセス制御を実装する。

このように戻り通信を許可した上で内部向け(inside, dmz: 192.168.x.x)の通信を拒否する。デフォルトはacceptとすることでインターネット宛の通信を全体的に許可する。

set firewall all-ping 'enable'
set firewall name hosting default-action 'accept'
set firewall name hosting rule 10 action 'accept'
set firewall name hosting rule 10 'destination'
set firewall name hosting rule 10 state established 'enable'
set firewall name hosting rule 10 state related 'enable'
set firewall name hosting rule 20 action 'drop'
set firewall name hosting rule 20 destination address '192.168.0.0/16'

(参考情報)VyOSの設定に関して参考にさせていただきました。

komeiy.hatenablog.com

インターネットからのアクセスはWindowsリモートデスクトップ

セキュリティ的な懸念はあるが、操作性を優先して、インターネットからWindows Serverへリモートデスクトップできるようにする。必要十分で言えば、ESXi Web Client (vSphere Web Client)へのWebアクセスのみを提供すれば、コンソールで全台操作可能だが、コピペなどの運用性が低い。そのため、一旦Windows Serverを踏み台として、そこからVM操作、SSH接続することにする。

インターネットFWとして使用しているCisco ASA5505でNAT/FWの処理をする。ASAでの公開設定はこちらの通り(設計見直し余地あり)。Webとして書いているが、ポート番号を変えればRDPにも適用できる。

designetwork.hatenablog.com

VPNホスティングセグメントに入れるようにすればさらに便利かも…

※RDP Win Serverがホスティング環境にいるとESXi再起動できないため移動。図は未修正。

DDNSでIP動的変更

固定IPは未契約なので、インターネットからのリモートデスクトップ接続にあたり、自宅グローバルアドレスはDDNSを使用してFQDNで接続できるようにしておく。

動作確認

テザリングでインターネットから以下の動作が可能であることを確認した。

まとめ - 自宅ラボVyOSでESXiホスティング環境を構築する

自宅ラボにセキュアなESXiホスティング環境を構築した。Windows Serverを踏み台にすることで、LinuxへのSSH接続なども実用的な環境とした。

また、ホスティング環境用として使用したVyOSは、設定がシンプルで、スループットも確保でき、今回のようなちょっとした拡張ではかなり有用だと思う。

環境の提供は応相談ですのでご連絡ください。自動デプロイの仕組みなどはなく手動対応です。

BIG-IPでOSPFを設定しダイナミックルーティングする

f:id:daichi703n:20170617194650p:plain

BIG-IPを通常のルータとしても使用するためにOSPFの設定をする。BIG-IP はVE評価版を使用する。

VyOSなどの仮想ルータを使用してもいいのだが、管理する機器を増やしたくないので、導入済みのBIG-IP VEをシンプルな仮想ルータとして兼用する。

前提構成

  • PowerEdge T110 II (Xeon E3-1220, RAM 24GB)
  • VMware ESXi6.5 (Build 5310538) 無償ライセンス
  • BIG-IP VE v13.0.0 (Build 0.0.1645) 評価版ライセンス

Route-DomainでOSPFを有効化する

私の環境ではBIG-IPをルートドメインで論理分割している。ルートドメインを使用している場合は、その中でOSPFを有効にする必要がある。

Route Domains > Properties > Dynamic Routing Protocols

ここでOSPFをEnabledに追加する。

f:id:daichi703n:20170617185230p:plain

続いてSelf IPでもOSPFを有効化する。(インタフェースでOSPFを動かす場合)

f:id:daichi703n:20170617185316p:plain

tmshからOSPF(zebos)プロセスの起動状況を確認する。環境によりルートドメイン指定が必要。ospfdが上がっていればOK。

root@(h-big-ip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# zebos check
=== route domain: 0 ===
No dynamic routing protocol enabled

root@(h-big-ip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# zebos
usage: zebos [-r <rd_id | -a] check
       zebos [-r <rd_id | -a] (cmd command1)[,command2]

root@(h-big-ip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# zebos -r 1 check
=== route domain: 1 ===
nsm is running [2640]
imi is running [2639]
ospfd   is running [2641]

IMIシェルからZebOSの設定をする

上記BIG-IP GUIだけではOSPFの設定は完了していない。(私の環境では)

BIG-IPに搭載されているIMIシェルからZebOSの設定をする必要がある。こちらはCumulusのQuaggaと同じイメージ。ログイン時にルートドメインを指定する必要あり。

今回はBIG-IP配下の172.16.0.0/24のセグメント情報を192.168.1.0/24側に広告したい。

[root@h-big-ip01:Active:Standalone] config # imish -r 1
h-big-ip01.designet.local[1]>en
#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
(config)#router ospf 1
(config-router)#router-id 192.168.1.8
(config-router)#network 192.168.1.0 0.0.0.255 area 0.0.0.0
(config-router)#network 172.16.0.0 0.0.0.255 area 0.0.0.0

sh runを見ると、このようにかなりシンプル。OSPFコストの設定などは未実施。BIG-IP GUI側ではこのあたりのOSPF設定はできないように見える。

h-big-ip01.designet.local[1]#sh run
!
no service password-encryption
!
interface lo
!
interface tmm
!
interface inside
!
interface hosting
!
router ospf 1
 ospf router-id 192.168.1.8
 network 172.16.0.0 0.0.0.255 area 0.0.0.0
 network 192.168.1.0 0.0.0.255 area 0.0.0.0
!
line con 0
 login
line vty 0 39
 login
!
end

これでOSPF neighborが張れた。ルート情報も交換できている。対向機器はCisco ASA5505。

h-big-ip01.designet.local[1]#show ip ospf neighbor

OSPF process 1:
Neighbor ID     Pri   State            Dead Time   Address         Interface
192.168.1.5       1   Full/DR          00:00:38    192.168.1.5     inside

h-big-ip01.designet.local[1]#sh ip route

K*      0.0.0.0/0 [0/0] via 192.168.1.5, inside
C       127.0.0.1/32 is directly connected, lo
C       127.1.1.254/32 is directly connected, tmm
C       172.16.0.0/24 is directly connected, hosting
C       192.168.1.0/24 is directly connected, inside
O E2    192.168.50.0/24 [110/20] via 192.168.1.5, inside, 02:09:31

(対向機器のルーティングテーブル)
ASA5505# sh route

S*    0.0.0.0 0.0.0.0 [1/0] via 133.xxx.xxx.xx, outside
O        172.16.0.0 255.255.255.0
           [110/20] via 192.168.1.8, 02:10:10, management
C        192.168.1.0 255.255.255.0 is directly connected, management
L        192.168.1.5 255.255.255.255 is directly connected, management
C        192.168.50.0 255.255.255.0 is directly connected, dmz
L        192.168.50.1 255.255.255.255 is directly connected, dmz

参考情報

F5オフィシャル情報

AskF5 | Manual Chapter: Working with Dynamic Routing

AskF5 | K14490: Overview of OSPF/OSPFv3 on the BIG-IP system

個人ブログ(英語)だが、一通りの手順は書いてある。私の環境での必要設定とは若干差異あり。

www.fransvandokkumburg.com

評価版では非実用的

BIG-IP VEをルータとしたが、評価版ライセンスではスループットが2Mbpsに制限されており、配下セグメントは実用的ではない…。

まとめ - BIG-IPにOSPFの設定をしてダイナミックルーティングする

(設定内容に不安があるので誤りがあれば指摘ください)
F5 BIG-IP GUIとIMIシェル(imish/ZebOS)の設定により、BIG-IPでCisco ASA5505とOSPFネイバーを形成し、ルート情報を交換することができた。この設定により、BIG-IPをルータとして使用し、セグメント追加時にもルート情報をダイナミックにアップデートできる。

BIG-IPでX-Forwarded-Protoを付与する設定

f:id:daichi703n:20170514162355p:plain

F5 BIG-IPでHTTP/Sの負荷分散をする際に、S-NATした上でX-Forwarded-Proto, X-Forawarded-ForのHTTPヘッダを付与する設定をする。

なお、今回の設定方法はこちらのディスカッションの情報を元にしている。

devcentral.f5.com

検証構成

検証バージョン: F5 BIG-IP VE 13.0.0 (Build 0.0.1645)

f:id:daichi703n:20170514162414p:plain

MacBookでWebサーバ(Rails)を起動し、Webブラウザ(Chrome)からBIG-IPのVirtual Server経由で自身にアクセスする。このとき、正常に通信ができるようS-NATを有効化しておく。

設定と動作確認

基本的な設定はこちらの通り。Rails向けのNode, Poolを設定した上でVirtual Serverを作成し割り当てる。通常のHTTPで試験するため種類(Type)はPerformance(HTTP)を使用する。

f:id:daichi703n:20170514164330p:plain

パケットはこちらの通り。

f:id:daichi703n:20170514164404p:plain

IPアドレスは以下の通り。キャプチャはPCで取得しているため、Client(Chrome)->Virtual Server, S-NAT->Server(Rails)のパケットが見える。

Client: 192.168.1.102
Server: 192.168.1.102
Vertual Server: 192.168.1.91
S-NAT Address: 192.168.1.8

ここではX-Forwarded-Proto(XFP), X-Forwarded-For(XFF)のいずれも付与されていない。

X-Forwarded-Proto, X-Forawarded-Forを付与する

HTTPヘッダにXFF, XFPを追加するよう、Profileを作成する。

Local Traffic > Profiles > Protocols > Fast HTTP

f:id:daichi703n:20170514164928p:plain

HTTP関連の設定欄で、Insert X-Forwarded-For: Enabled, Request Header Insert: X-Forwarded-Proto: httpと設定する。 f:id:daichi703n:20170514165706p:plain

作成したプロファイルをVirtual Serverに適用する。

f:id:daichi703n:20170514165855p:plain

適用後はコネクションが残存していることがあるため、必要に応じてNodeのOffline/Online等でクリアする。

改めてHTTPアクセスすると、以下の通りHTTPヘッダにX-Forwarded-For, X-Forwarded-Protoが追加されている。

f:id:daichi703n:20170514165913p:plain

HTTPSは適用プロファイルを変更

上記はperformance(http)での適用方法を記載した。HTTPS(SSL)等で適用する際には、使用するプロファイルを合わせて同様に設定すればよい。

通常のHTTPプロファイルを使用する場合は場所は違うが同様にRequest Header InsertでXFPヘッダを設定する。

f:id:daichi703n:20170514170156p:plain

X-Forwarded-Portは?

X-Forwarded-Protoの他に、X-Forwarded-Portを付与したいケースもあるかもしれない。残念ながら、こちらについてはiRulesでの指定が必要となる。

devcentral.f5.com

GUIで変数指定しても展開されず、動的に情報を取得できなかった。

まとめ - BIG-IPでX-Forwarded-Protoを付与する設定

HTTPプロファイルを作成することで、S-NAT環境でHTTPヘッダにX-Forwarded-Protoを付与した。なお、X-Forwarded-Portを付与したい場合にはiRulesを使用する必要がある。

postNFCData failedのエラーでBIG-IP VEがESXi6.5にデプロイできない

f:id:daichi703n:20170507154512p:plain

評価版使用のためにF5 BIG-IP VE(Virtual Edition)をVMware ESXi6.5にデプロイしようとしたがエラーが発生してデプロイに失敗した。結果として、ALL, LTMのOVAイメージはデプロイできず、1SLOTのモデルでデプロイに成功した。

発生事象

ESXi Web ClientからOVAイメージをデプロイしたときにこちらの通りエラーが発生した。後述するが、ESXiホストのスペックには余裕があったので、ALLのモデルを使用している。

f:id:daichi703n:20170507144206p:plain

postNFCData failed: Capacity of uploaded disk is larger than requested

DISK容量不足のメッセージだが、私の環境では900GB程度の空き容量があるため、システム要件等を踏まえて問題ない。

f:id:daichi703n:20170505213310p:plain

前提環境

以下の環境で試験している。

クライアント バージョン: 1.18.0
クライアント ビルド番号: 5270848
ESXi バージョン: 6.5.0
ESXi ビルド番号: 5310538

RAM: 8 GB / DISK: 1 TB

ESXiのUIバージョンなどが低い場合はこちらの通りアップデートください。

designetwork.hatenablog.com

デプロイ手順はESXi Web Clientから 新規仮想マシン > OVA/OVFテンプレートと通常通りデプロイする。

F5 BIG-IP VEモデルとバージョン

なお、互換性はこちらの通り。VE13.0.0はESXi6.5で使用可能となっている。

AskF5 | Manual: Virtual Edition and Supported Hypervisors Matrix

BIG-IP VE版のダウンロードはこちらから(要F5アカウント登録・誰でも登録可能)

https://downloads.f5.com/esd/index.jsp

BIG-IP > BIG-IP v13.x / Virtual Edition > Virtual-Edition とパスを辿るとダウンロードファイルの一覧が表示される。ここでESXを検索(ブラウザで)すると次の3種類が見つかる。(バージョンは2017/5/7時点の情報)

  • BIGIP-13.0.0.0.0.1645.ALL-scsi.ova
  • BIGIP-13.0.0.0.0.1645.LTM-scsi.ova
  • BIGIP-13.0.0.0.0.1645.LTM_1SLOT-scsi.ova

OpenStackのドキュメントでかつ一世代前の情報にはなるが、それぞれの役割はこちらに記載されている。

BIG-IP® VE Flavor Requirements — F5 OpenStack Documentation

ざっくりとHWスペックで分かれており、1SLOT: Small, LTM: Medium, ALL: Largeという こちらのスループットライセンスのCPU上限と合わせてHWスペックを選定する。

K14810: Overview of BIG-IP VE license and throughput limits - AskF5

各イメージのDISKサイズはこちらの通り。

K14946: Overview of BIG-IP Virtual Edition image sizes - AskF5

システム要件として、CPUは1SLOT/LTM: 2vCPU or ALL: 4vCPU、RAMはCPUあたり2GBとなっている。

K15796: Hardware requirements on the system hosting BIG-IP Virtual Edition - AskF5

VEモデル別のデプロイ可否

システム要件的には問題はないが、検証として各モデルのデプロイを実施した。結果は以下の通り。

VEモデル デプロイ可否
BIGIP-13.0.0.0.0.1645.ALL X
BIGIP-13.0.0.0.0.1645.LTM X
BIGIP-13.0.0.0.0.1645.LTM_1SLOT O

最小の1SLOTモデルであればデプロイすることができた。

f:id:daichi703n:20170507150455p:plain

2vCPU, RAM 4GB, DISK 8GBで動作している。

f:id:daichi703n:20170507151027p:plain

f:id:daichi703n:20170507151040p:plain

あとはコンソール・SSH・WebGUIから通常通りBIG-IP VEが使用できる。

旧BIG-IPバージョン・ESXiバージョンでの切り分け

VEモデル デプロイ可否
ESXi5.5 ALLデプロイ O
ESXi6.5 BIG-IP v12 ALLデプロイ X

ESXi側を疑って、ESXi5.5.0(1623387)でもデプロイしてみた。こちらはBIGIP-13.0.0.0.0.1645.LTM-scsi.ova問題なくデプロイできた。そのため、BIG-IP VEではなくESXi6.5の問題と考えられる。

また、ESXi5.5ではOVAデプロイ時に仮想マシンのvCPU, RAMを選択できる。

f:id:daichi703n:20170507150021p:plain

なお、BIG-IP v13の問題を疑ってv12のBIG-IP VEをESXi6.5にデプロイしてみたが、こちらは上記と同様のエラーとなりデプロイできなかった。また、ESXi6.5においてはオプションはNWの設定のみで、VMのリソース選択はできない。

f:id:daichi703n:20170507150719p:plain

まとめ - postNFCData failedのエラーでBIG-IP VEがESXi6.5にデプロイできない

ESXi6.5では、postNFCData failed: Capacity of uploaded disk is larger than requestedのエラーにより、F5 BIG-IP VE(Virtual Edition) のALL及びLTMモデルがデプロイできない。BIG-IP VEを使用したい場合は1SLOTの最小モデルを使用する必要がある。

4台のHDDで2組のRAID1を構成しESXiマウントする(PowerEdge T110ⅡPERC H200A)

f:id:daichi703n:20170505215401p:plain

自宅サーバとして使用しているDell PowerEdge T110ⅡにHDDを追加する。既存DISKは初期搭載のRAIDコントローラPERC H200Aを使用し、RAID1構成となっている。コントローラには最大4台のHDDを接続できるため、残りの2台を追加し同様にRAID1で増設する。

自宅サーバ選定はこちら。

designetwork.hatenablog.com

RAIDコントローラ

元々搭載されているRAIDコントローラはこちら。この中のPERC H200A (PowerEdge RAID Controller)というモデルのようだ。

www.dell.com

基本的な操作マニュアルはこちらに記載されている。

SAS 5/6およびPERC H200シリーズにおけるRAID BIOS操作一覧 - Dell

なお、こちらのRAIDコントローラは最大4台のHDDを接続できるものの、RAID1 * 2組 の構成ができるかの情報は事前には見つけられなかった。4台はRAID10構成用?という懸念もなった。ただ、失って困るデータもないので、実機でそのまま検証した。

RAID設定モードで新規RAID作成

まずはBIOS起動画面でCtrl+CによりRAID設定モードに入る。起動直後なので逃さないよう注意する。

f:id:daichi703n:20170505210447j:plain

その後、RAID PropertiesからCreate Newで新規RAIDを作成し、新規DISKを所属させる。(序盤の画面を撮り忘れていました…)

RAID作成後は、このように新規DISKのDrive StatusがRAIDになる。写真の0, 1が既存HDDで、今回は2, 3のHDDを増設している。

f:id:daichi703n:20170505210959j:plain

一見、既存のRAIDに追加されてRAID10になっている?というようにも感じたが、View Volumeで見ると1 of 2として新規作成分が認識されていることが分かる。追加分が1番目になっているのは若干不思議。

f:id:daichi703n:20170505211252j:plain

Alt+NでRAID情報のページを送れる。

f:id:daichi703n:20170505211255j:plain

なお、状態を確認する上ではSAS Topologyから確認するのが一番分かりやすかった。以下のように表示され、RAID1のペアが2組作成されていることが見て取れる。

f:id:daichi703n:20170505211339j:plain

なお、このときBoot Deviceの選択を誤らないように注意。OS(私の環境はVMware ESXi6.5)がインストールされているRAIDをBoot Deviceとして指定していないと、サーバを起動できなくなる。

VMware ESXi6.5にマウントする

新規RAIDを構成できたので、ESXiに取り込む。ESXi Web Clientでデータストアの追加をする。

f:id:daichi703n:20170505212559p:plain

「新しいVMFSデータストアの作成」を選択して次へ

f:id:daichi703n:20170505212652p:plain

新規作成したRAIDを認識できている。データストア名を入力して次へ

f:id:daichi703n:20170505212737p:plain

私はここで一度つまづいた。「パーティション分割オプションの選択」のステップでロードしています…のまま停止してしまった。

f:id:daichi703n:20170505212920p:plain

数分待っても進まないため、「次へ」をクリックして強制的に進めたらエラー終了…。気を取り直してもう一度最初から設定したら、今度は正常に表示された。

f:id:daichi703n:20170505213027p:plain

全容量を一つのパーティションとして使用する。物理で分けてしまうと扱いづらい部分があるため、パーティション分けは仮想マシン側で実施する。なお、ESXi6.5からは新しいVMFS6を使用できるようになっている。しかし、私はもう一台のESXi5.5からの移行等を考慮して、VMFS5で作成した。

f:id:daichi703n:20170505213310p:plain

完了して新規データストアを使用可能になった。

まとめ - PowerEdge T110Ⅱ(PERC H200A) 4台のHDDで2組のRAID1を構成しESXiマウントする

PowerEdge T110ⅡのRAIDコントローラ PERC H200A で、4台のHDDで2組のRAID1を構成することができた。また、新規RAIDVMware ESXi6.5のデータストアとして取り込むことができた。

ESXi6.5 Web ClientからVIBでパッチ適用する

f:id:daichi703n:20170505005750p:plain

VMwareでは各メジャーバージョンの中で随時パッチがリリースされている。従来、vCenterがないスタンドアロン環境ではesxcliによりVIB (VMware Infrastructure Bundle)をインストールする必要があった。しかし、ESXi6.5ではスタンドアロンで使用可能なWebGUIが搭載されているため、通常使用の管理画面から簡単にインストールすることができる。

なお、今回はGoogle ChromeからESXi Web Clientへのログイン時のエラーの対応としてesx-uiのパッチを適用する。なお、私の環境ではエラーが出てもF5更新すればエラーを抜けられた。

VIBをダウンロードする

VIB(パッチ)はMy VMwareからダウンロードできる。(要ログイン)

VMware patch portal

KBのバグ修正情報等を参考に該当するパッチをダウンロードする。

f:id:daichi703n:20170504234515p:plain

期待していたのは、Yum等のパッケージ管理のように、オンラインのリポジトリ(Depot)にアクセスしてアップデートするような動作だった。しかし、リポジトリは見つけられずローカルにダウンロードするしかないようだ。

ZIPファイルのままではNG

ダウンロードしたVIBはZIP形式で圧縮されている。残念ながらそのままではWeb Clientからはインポートできない。手順は以下の通り。

データストアにZIPファイルをアップロードする。アップロードしたパスを控えておく。

f:id:daichi703n:20170504234557p:plain

ストレージ情報からベースのパスを取得する。表示は短縮されているが、トリプルクリックで非表示部分を含め取得できる。

f:id:daichi703n:20170504235132p:plain

ホスト > 管理 > パッケージ > アップデートのインストールからインストールする。

f:id:daichi703n:20170504235836p:plain

先ほどのファイルパスを加えてフルパスで指定する。

f:id:daichi703n:20170504235352p:plain

後述するが、VIB単体でのバージョンアップはVMwareとしてのサポート対象外となってしまう。私の場合は個人的な検証利用なので問題ない。

このホストが VMware Update Manager によって管理されている場合、更新を実行するとホストが非準拠になる場合があります。続行しますか?

f:id:daichi703n:20170505001032p:plain

エラーになる…

! アップデートを適用できませんでした: アップデートが指定された形式ではありません。VIB ファイルへのパスまたは URL を指定してください。

f:id:daichi703n:20170505001211p:plain

メッセージより、ZIP形式ではダメなのだろう。

VIBファイルを取り出す

ダウンロードしたZIPファイルにはVMwareのindex情報などとともに各種VIBファイルが含まれている。内容はこのような感じ。

f:id:daichi703n:20170505002911p:plain

ZIPファイルを解凍してVIBファイル単体をアップロードする。

f:id:daichi703n:20170505002244p:plain

f:id:daichi703n:20170505003120p:plain

数秒でアップデートが完了する。(完了メッセージは撮り忘れ…)

f:id:daichi703n:20170505003218p:plain

esx-uiがバージョンアップされた。1.8.0 -> 1.18.0

Web Client からの運用は非現実的

パッチ適用作業をしてみて、正直なところ、ESXi Web Client (GUI) からのVIBインストール運用は実用に耐えないと感じている。また、VMwareのサポートを受けられなくなる点もデメリットと考えられる。

運用ハードルを下げるためにWeb GUIからの作業を実施したが、結局個別のVIBを選定したりと、それなりの知識が求められる。また、そもそもESXiを運用する人は前提知識とスキルがあるはずなので、CLIからコマンドでアップデートする方が効率も良さそうだ。

ちょうど同時期に同様の問題でパッチ適用をされている方がいらっしゃいました。こちらの手順を参考にCLIからVIB一色のインストール作業をしようと思います。

japan-vmware.hateblo.jp

まとめ - ESXi6.5 Web ClientからVIBでパッチ適用する

ESXi6.5 Web ClientからVIBのパッチを適用できた。一連の作業を実施したものの、結果としてWeb GUIからのパッチ適用作業はメリットが少なく、従来通りCLIでアップデートする方が良さそうだ。

Logstashで内容ごとに送信先を複数に振り分ける設定

f:id:daichi703n:20170410024520p:plain

Logstashでは設定したConfigは全体的に有効になるため、シンプルな設定では単一の出力設定となる。そこで、ifで項目により条件分岐させることで、複数の出力を設定できる。

前回こちらの記事で紹介した汎用的な設計を元に、Logstashからの送信先を複数に分散、振り分ける設定を追加する。

Logstashの設定

  • input/filter

inputのConfigファイルはこちらのとおり。syslog系のログをモニタリングして収集する。tagsにより、Fluentd(td-agent)と同様の処理を実装する。

/etc/logstash/conf.d/messages.conf

input {
  file {
    path => "/var/log/messages"
    tags => ["sys", "logstash_messages", "%{host}" ]
    type => syslog
  }
  file {
    path => "/var/log/cron"
    tags => ["sys", "logstash_cron", "%{host}" ]
    type => syslog
  }
  file {
    path => "/var/log/secure"
    tags => ["sys", "logstash_secure", "%{host}" ]
    type => syslog
  }
}

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
      add_field => [ "received_at", "%{@timestamp}" ]
      add_field => [ "received_from", "%{host}" ]
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
  }
}

今回は試験用に/var/log/secure/var/log/cronchmod 644で読み取れるようにしておく。デフォルトだと600で開けず以下のエラーが発生する。

[2017-04-10T02:14:50,228][WARN ][logstash.inputs.file     ] failed to open /var/log/cron: Permission denied - /var/log/cron
[2017-04-10T02:14:50,519][WARN ][logstash.inputs.file     ] failed to open /var/log/secure: Permission denied - /var/log/secure
  • output

出力用の設定は次の通り。Fluentd(td-agent)の<match tag>と同様にtagにより送信・出力先を複数に振り分ける。配列の項目を比較する際は次のようになる。今回Elasticsearchは同一サーバを使用したが、別々に指定できる。ちなみに、上記filterプラグインでも既にシンプルなif分岐を使用している。

比較は基本的にRubyの文法に従う。詳細はオフィシャルを参照。

/etc/logstash/conf.d/output.conf

output {
  if [tags][1] == "logstash_messages" {
    elasticsearch {
      hosts => ["localhost:9200"]
      index => "%{tags[0]}.%{tags[1]}-%{+YYYY.MM.dd}"
    }
    file {
      path => "/var/log/logstash/%{tags[0]}/%{tags[1]}.log"
    }
  } else if [tags][1] == "logstash_cron" {
    elasticsearch {
      hosts => ["localhost:9200"]
      index => "%{tags[0]}.%{tags[1]}-%{+YYYY.MM.dd}"
    }
    file {
      path => "/var/log/logstash/others/%{tags[1]}.log"
    }
  } else {
    file {
      path => "/var/log/logstash/others/other.log"
    }
  }
}

配列の内容を比較する場合は[<type>][<number>]を指定する。通常だと[<type>]のみ。

実装結果

Elasticsearchのindexは設定通り、messagesとcronのみが作成されている。

$ curl http://localhost:9200/sys.logstash_cron-*
{"sys.logstash_cron-2017.04.09":{"aliases":{},"mappings":{"syslog":...

$ curl http://localhost:9200/sys.logstash_messages-*
{"sys.logstash_messages-2017.04.09":{"aliases":{},"mappings":{"syslog":...

$ curl http://localhost:9200/sys.logstash_secure-*
{}

fileへのバックアップはこちらの通り。設定した通りにファイルが生成されている。

$ sudo tree /var/log/logstash/

/var/log/logstash/
├── logstash-plain.log
├── others
│   ├── logstash_cron.log
│   └── other.log
└── sys
    └── logstash_messages.log

まとめ - Logstashで内容ごとに送信先を複数に振り分ける設定

if文を使用することで、Logstashで内容ごとにログの送信先を複数に分散、振り分けることができた。ログ種別に応じて、Elasticsearch、fileなど柔軟に保存方法を設定できる。