2024年9月15日日曜日

vSphere環境のRHELのネットワークデバイスの名称ルール (ens192、224…) を確認してみた

RHEL 7以降より、ネットワークデバイスが従来のeth0、eth1といったものからens192、ens224といった名称に変更になっている。これは、「biosdevname」と呼ばれる仕組みで名称が決定されるようになった。

この名称ルールによって、vSphereの仮想環境に構築したRHELのネットワークデバイスは、必ず「ensNNN (NNNは数字3桁)」となる。「en」はEthernetを示し「s」はホットプラグの意味となり、末尾3桁の数字は、PCIスロットの「Physical Slot」の値で決定するようだ。

上記法則は調べてわかったのだが、実際は末尾3桁の付与される法則は連番で付与されるものではなく、毎回NICを追加してからネットワークデバイス名称を確認する作業が必要となってしまう。そこで、実際にvSphereの仮想環境で、RHEL 8及びRHEL 9の仮想マシンに仮想NICを10本を付けた際のネットワークデバイス名の命名ルールを確認することにした。

なお、ESXi 7とESXi 8ではPhysical Slotの番号が変わったことにより、ネットワークデバイス名も変更となっている。

ネットワークデバイス名 (ESXi 7)

ESXi 7にRHELをインストールし、OSを起動した状態で、1個ずつ仮想NIC追加し確認を行った。付与されるネットワークデバイス名称は以下のようになった。
NIC番号 デバイス名
1 ens192
2 ens224
3 ens256
4 ens161
5 ens193
6 ens225
7 ens257
8 ens162
9 ens194
10 ens226
どうやらネットワークデバイス名称の数字は以下のように32ずつ増加して推移するようだ。なお、ens160が存在しない理由は、Physical Slotの160を「VMware PVSCSI SCSI Controller」が利用しているためとなる。

なお、「Physical Slot」はlspciコマンドで確認ができる。確かに、「Physical Slot」の値と名称は一致しているようだ。
# lspci -v
~(中略)~

03:00.0 Serial Attached SCSI controller: VMware PVSCSI SCSI Controller (rev 02)
        Subsystem: VMware PVSCSI SCSI Controller
        Physical Slot: 160
        Flags: bus master, fast devsel, latency 0, IRQ 18
        I/O ports at e000 [size=8]
        Memory at fe900000 (64-bit, non-prefetchable) [size=32K]
        Expansion ROM at fe910000 [disabled] [size=64K]
        Capabilities: [40] Express Endpoint, MSI 00
        Capabilities: [7c] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [94] Power Management version 3
        Capabilities: [9c] MSI-X: Enable+ Count=24 Masked-
        Capabilities: [100] Device Serial Number 57-0d-a1-90-50-05-05-68
        Kernel driver in use: vmw_pvscsi
        Kernel modules: vmw_pvscsi

~(中略)~

1b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
        Subsystem: VMware VMXNET3 Ethernet Controller
        Physical Slot: 256
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at fd103000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd102000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd100000 (32-bit, non-prefetchable) [size=8K]
        I/O ports at 4000 [size=16]
        Expansion ROM at fd110000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [48] Express Endpoint, MSI 00
        Capabilities: [84] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [9c] MSI-X: Enable+ Count=25 Masked-
        Capabilities: [100] Device Serial Number 00-0c-29-ff-ff-5a-a4-cb
        Kernel driver in use: vmxnet3
        Kernel modules: vmxnet3

1c:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
        Subsystem: VMware VMXNET3 Ethernet Controller
        Physical Slot: 257
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at fd003000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd002000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd000000 (32-bit, non-prefetchable) [size=8K]
        I/O ports at 3000 [size=16]
        Expansion ROM at fd010000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [48] Express Endpoint, MSI 00
        Capabilities: [84] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [9c] MSI-X: Enable+ Count=25 Masked-
        Capabilities: [100] Device Serial Number 00-0c-29-ff-ff-5a-a4-f3
        Kernel driver in use: vmxnet3
        Kernel modules: vmxnet3

ネットワークデバイス名 (ESXi 8)

ESXi 8にRHELをインストールし、OSを起動した状態で、1個ずつ仮想NIC追加し確認を行った。付与されるネットワークデバイス名称は以下のようになった。
NIC番号デバイス名
1ens34
2ens37
3ens38
4ens39
5ens40
6ens41
7ens42
8ens43
9ens44
10ens45
こちらはESXi 7と異なり、1つ目のNICのデバイス名はens34となり、2つ目以降は37番から1ずつ増加して名称が割り当てられることが確認できた。

参考

更新履歴

  • 2020/8/29 新規作成
  • 2024/9/15 ESXi 8の場合のデバイス名の記載を追加
2024年9月14日土曜日

Oracle VM VirtualBox (Windows版)&Guest Additionsインストール手順 (6.1、7.1対応)

WindowsやMACのPCにて手軽にLinuxなどの検証を行いたい場合がある。そのような場合には、PCにインストール可能なホスト側仮想化ソフトウェアを利用し、Linuxの仮想マシンを構築することができる。

ホスト型仮想化ソフトウェアとして利用可能なものは、以下のようなものがある。

製品名 プラットフォーム 説明
Oracle VM VirtualBox Windows, macOS, Linuxなど 様々なプラットフォームで動作し、無償であるにも関わらずかなり柔軟に仮想マシンの設定が可能。また、Vagrantを使えば構築の自動化も可能。
VMware Workstation Player Windows vSphereでおなじみのVMwareのホスト型仮想化ソフトウェア。
VMware Fusion Player macOS macOSを所有していないため評価不可。

今回は、「Oracle VM VirtualBox」をWindows環境にインストールし、VirtualBox上にWindows Server 2019とRHEL 8.4をインストールする手順を記載する。

環境

VirtualBoxをインストールする手ごろなWindowsクライアントがすぐに用意できなかったため、たまたまインストールしていたWindows Server 2022 PreviewにVirtualBoxをインストールしたが、他Windows環境でも手順に差異はないだろう。

また、VirtualBoxは6.1.24と7.1.0の二種類でインストールを確認しているが、本記事の画面は6.1.24のものを記載する。

  • Windows Server 2022 Preview
  • Oracle VM VirtualBox 6.1.24 / 7.1.0

なお、私の環境はESXi上のOSにVirtualBoxをインストールする構成となる。このような構成の場合は、ESXiのCPUの設定にて「ハードウェア アシストによる仮想化をゲスト OS に公開」を有効にすること。

Oracle VM VirtualBoxインストール手順

1. Oracle VM VirtualBoxのダウンロード

VirtualBox本家とOracle 日本のいずれかからVirtualBoxのダウンロードができる。Oracle 日本でダウンロードできるバージョンは少し古くなってしまうことから、特に理由がなければ本家からダウンロードすれば問題ない

また、同じサイトでダウンロードできるOracle VM VirtualBox Extension Packもダウンロードしておく。Extension Packをインストールすることで、USBコントローラやディスク暗号化などの拡張機能を利用することができる。

2. (VirtualBox 7以降)Pythonのインストール

VirtualBoxの前提として、Pythonとpywin32のインストールが必要となる。Pythonは以下からダウンロードしてインストールする。Pythonは管理者として実行してインストールすること。

Pythonインストール後、PowerShellを開き、pywin32をインストールする。

pip install pywin32 --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --trusted-host pypi.org

3. VirtualBox本体のインストール

ダウンロードしたexeファイルをダブルクリックすれば、インストールウィザードを起動する。基本的には、すべてを「次へ」を押して進めばよい。

インストールが開始されると、「このデバイスをインストールしますか?」と表示されるので、「インストール」を選んでおく。

4. Extension Packのインストール

VitualBoxをインストールしたのち、Extension Packのファイル (vbox-extpack) をダブルクリックすることでインストールを開始することができる。

ライセンス規約が表示されるので、一番下までスクロールしたのち、「同意します」を選択する。

インストールが成功すると、以下のような「拡張機能パッケージ Oracle VM Virtual Box Extension Pack のインストールに成功しました。」のメッセージが表示される。
※完了メッセージが表示されない場合もある模様。

VirtualBox上にWindows Server 2019をインストール

1. 仮想マシンを作成

「新規」ボタンをクリックすることで、仮想マシンの作成ウィザードが表示される。以下のように設定を行い仮想マシンを作成する。

設定値 説明
名前 任意で指定。今回はwin2019とする。
タイプ Microsoft Windows
バージョン Windows 2019 (64-bit)
メモリーサイズ 任意で指定。デフォルトは2048MB
ハードディスク 「仮想ハードディスクを作成する」を選択
ハードディスクのファイルタイプ デフォルトの「VDI (VirtualBox Disk Image)」を選択する。なお、「VHD」 (Hyper-Vで使用) や「VMDK」 (ESXiで使用) も選択可能。
物理ハードディスクにあるストレージ 可変サイズと固定サイズが選択できる。いわゆるシックプロビジョニングとシンプロビジョニングに対応する。「固定」の場合はディスク作成時にすべての容量が割り当てられてしまい効率が悪いので、使用した分だけディスクサイズを割り当てていく「可変」を選択する。
ファイルの場所とサイズ 任意で指定。デフォルトは50GB

2. OSをインストールメディアから起動

作成した仮想マシンの「設定」を開き、「ストレージ」→「光学ドライブ」を選択する。CDマークを選択し、「ディスクファイルを選択」を選択し、Windows Server 2019のISOイメージを選択する。

仮想マシンの起動モードは以下3種類ある。VirtualBox用語となっており、初見では動作の違いが判らないため、それぞれの違いを以下に記載する。

起動モード 説明
通常起動 起動時に仮想マシンのコンソールが開く。コンソールを閉じる際は、「状態保存 (いわゆるサスペンド)」または「仮想マシンの停止」のみ選択が可能。
ヘッドレス起動 起動時に仮想マシンのコンソールが開かない。起動後に「表示」を選択することで仮想マシンのコンソールを開くことができる。コンソールを閉じる際に「バックグラウンドで動作を継続」を選択することで、仮想マシンのコンソールを閉じても起動状態を継続させることが可能。
デタッチモード起動 起動時に仮想マシンのコンソールが開く。それ以外は「ヘッドレス起動」と同様となり、「バックグラウンドで動作を継続」を選択可能。

通常は、仮想マシンのバックグラウンドでの起動が選択可能な、「デタッチモード起動」を選択しておけば問題ないだろう。

3. OSインストール

Windows Serverのインストールメディアを読み込むので、Enterを押しインストールを開始させる。インストール手順自体は特に通常と変更は不要であるため割愛する。

インストール完了後はインストールメディアは不要となることから、「デバイス」→「光学ドライブ」→「仮想ドライブからディスクを除去」を選択しインストールメディアを取り出しておこう。

4. Guest Additionsをインストール

VirtualBoxでは「Guest Additions」と呼ばれる、ESXiでいうところのVMware Toolsと同様の機能を待つエージェントのインストールが推奨される。

「デバイス」→「Guest Additions CDイメージの挿入…」を選択する。

すると、仮想CDドライブに「VirtualBox Guest Additions」というメディアがマウントされるので、これをダブルクリックすることでインストールウィザードが開始される。インストールウィザードでは、基本的には、すべてを「次へ」を押して進めばよい。

インストールが開始されると、「このデバイスをインストールしますか?」と表示されるので、「インストール」を選んでおく。

最後に再起動を求められるため、再起動して完了となる。

Guest Additionsが正常にインストールされていることの確認は、「仮想マシン」→「セッション情報」→「ランタイム情報」から確認することができる。


VirtualBox上にRHEL 8.4をインストール

1. 仮想マシンを作成~OSインストール

Windows Serverと同様の手順となるため割愛する。

2. Guest Additionsをインストール

RHELに対してGuest Additionsをインストールする場合は、GUIではなくCLIによるインストールを行う。

まず、前提パッケージとして以下が必要となる。

  • kernel-headers
  • kernel-devel
  • tar
  • bzip2
  • gcc
  • make
  • perl
  • elfutils-libelf-devel

上記パッケージをdnfまたはyumを使ってインストールを行うのだが、インターネット経由でインストールする場合、ネットワーク設定やサブスクリプション登録など手順が多くなる。そこで、今回はRHELのOSインストールメディアに含まれるパッケージを用いてインストールを行う。

まず、OSインストールメディアのパッケージが含まれるディレクトリをリポジトリとして登録する。

# cat << EOF > /etc/yum.repos.d/dvd-base.repo
[dvd-base]
baseurl=file:///media/BaseOS/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
EOF

# cat << EOF > /etc/yum.repos.d/dvd-appstream.repo
[dvd-appstream]
baseurl=file:///media/AppStream/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
EOF

次にOSインストールメディアをマウントし、dnfにてパッケージのインストールを行う。

# mount /dev/cdrom /media/
mount: /media: 警告: デバイスは書き込み禁止です、読み込み専用でマウントします.
# dnf install kernel-headers kernel-devel -y
# dnf install tar bzip2 gcc make perl elfutils-libelf-devel -y
# eject /dev/sr0

次に、OSインストールメディアを「Guest Additions」のメディアに変更する。Windows Serverの手順と同様、「デバイス」→「Guest Additions CDイメージの挿入…」を選択したのち、VBoxLinuxAdditions.runを実行すると、自動的にGuest Additionsがインストールされる。

# mount /dev/cdrom /media/
mount: /media: 警告: デバイスは書き込み禁止です、読み込み専用でマウントします.

# /media/VBoxLinuxAdditions.run
Verifying archive integrity... All good.
Uncompressing VirtualBox 6.1.24 Guest Additions for Linux........
VirtualBox Guest Additions installer
Removing installed version 6.1.24 of VirtualBox Guest Additions...
Copying additional installer modules ...
Installing additional modules ...
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel
modules.  This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel
4.18.0-305.el8.x86_64.
ValueError: File context for /opt/VBoxGuestAdditions-6.1.24/other/mount.vboxsf already defined

最後に再起動をしておく。

# reboot

再起動後、Guest Additionsのサービスvboxaddの正常起動を確認できれば完了となる。

# systemctl status vboxadd
● vboxadd.service
     Loaded: loaded (/opt/VBoxGuestAdditions-7.1.0/init/vboxadd; enabled; preset: disabled)
     Active: active (exited) since Fri 2024-09-13 22:13:12 JST; 56s ago
    Process: 43447 ExecStart=/opt/VBoxGuestAdditions-7.1.0/init/vboxadd start (code=exited, status=0/SUCCESS)
   Main PID: 43447 (code=exited, status=0/SUCCESS)
        CPU: 483ms

 9月 13 22:13:12 localhost.localdomain systemd[1]: Starting vboxadd.service...
 9月 13 22:13:12 localhost.localdomain vboxadd[43447]: VirtualBox Guest Additions: Starting.
 9月 13 22:13:12 localhost.localdomain systemd[1]: Finished vboxadd.service.

更新履歴

  • 2021/8/14 新規作成
  • 2024/9/14 VirtualBox 7.1.0のインストール結果を反映
2024年9月4日水曜日

Fluentdを使ってKubernetesのログをsyslogで送信する

KubernetesのPodのログはファイルに出力はされているが、1台のサーバーにログ集約を行い一元管理をしたい場合がある。そのような用途で利用されるソフトウェアとしてFluentdがある。

本記事では、Fluentdを使ってKubernetesのログをsyslogで送信する手順を記載する。

環境

今回の環境の構成概要図を以下に記載する。赤枠個所が本記事の設定個所となる。

以下に今回構築する各種ソフトウェアのバージョンを記載する。

  • ホストOS : AlmaLinux 8.6
  • Docker : 24.0.6
  • cri-dockerd: 0.3.4
  • Kubernetes: v1.29.4

Fluentd導入

1. fluentd-kubernetes-daemonsetのマニフェストファイルをダウンロード

FluentdをKubernetesで動作させるため、fluentd-kubernetes-daemonsetを導入する。マニフェストファイルは以下からダウンロードできる。

今回はsyslogによるログ送信をしたいことから、fluentd-daemonset-syslog.yamlをダウンロードする。ダウンロード方法は任意となるが、curlを使う場合は以下の通り行う。

# curl -LO https://raw.githubusercontent.com/fluent/fluentd-kubernetes-daemonset/master/fluentd-daemonset-syslog.yaml

2. マニフェストファイルを修正

マニフェストファイルそのままではsyslogファイルを正常に送ることができないため、以下の★箇所の修正を行う。

fluentd-daemonset-syslog.yaml

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
    version: v1

~(中略)~

---
apiVersion: apps/v1
kind: DaemonSet

~(中略)~

      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-syslog
        env:
          - name: K8S_NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name:  SYSLOG_HOST
            value: "192.168.1.1" # ★ログ送信先のsyslogサーバーを指定
          - name:  SYSLOG_PORT
            value: "514" # ★ポート番号を変更する場合は修正
          - name:  SYSLOG_PROTOCOL
            value: "tcp" # ★udpまたはtcpを指定
          - name:  FLUENTD_SYSTEMD_CONF
            value: "disable" # ★"No such file or directory retrying in 1s"のエラーログ抑止のため指定
          - name:  TZ
            value: "Asia/Tokyo" # ★Fluentdのログのタイムゾーンを指定(デフォルトはUTC)
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        # When actual pod logs in /var/lib/docker/containers, the following lines should be used.
        - name: dockercontainerlogdirectory     # ★アンコメント
          mountPath: /var/lib/docker/containers # ★アンコメント
          readOnly: true                        # ★アンコメント
        # When actual pod logs in /var/log/pods, the following lines should be used.
        #- name: dockercontainerlogdirectory    # ★コメントアウト
        #  mountPath: /var/log/pods             # ★コメントアウト
        #  readOnly: true                       # ★コメントアウト
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      # When actual pod logs in /var/lib/docker/containers, the following lines should be used.
      - name: dockercontainerlogdirectory  # ★アンコメント
        hostPath:                          # ★アンコメント
          path: /var/lib/docker/containers # ★アンコメント
      # When actual pod logs in /var/log/pods, the following lines should be used.
      #- name: dockercontainerlogdirectory # ★コメントアウト
      #  hostPath:                         # ★コメントアウト
      #    path: /var/log/pods             # ★コメントアウト

3. マニフェストファイルをapply

修正したマニフェストファイルapplyする。

# kubectl apply -f fluentd-daemonset-syslog.yaml
serviceaccount/fluentd created
clusterrole.rbac.authorization.k8s.io/fluentd created
clusterrolebinding.rbac.authorization.k8s.io/fluentd created
daemonset.apps/fluentd created

成功すると、fluentdのPodが各KubernetesノードでRunningとなるはずだ。

# kubectl get pod -n=kube-system
NAME                                READY   STATUS    RESTARTS      AGE
coredns-76f75df574-dntsp            1/1     Running   1 (51d ago)   105d
coredns-76f75df574-lswd4            1/1     Running   1 (51d ago)   105d
etcd-t1051kube                      1/1     Running   1 (51d ago)   105d
etcd-t1052kube                      1/1     Running   1 (51d ago)   105d
etcd-t1053kube                      1/1     Running   1 (51d ago)   105d
fluentd-k98t7                       1/1     Running   0             18s
fluentd-pn55s                       1/1     Running   0             18s
fluentd-xq6rb                       1/1     Running   0             18s
kube-apiserver-t1051kube            1/1     Running   1 (51d ago)   105d
kube-apiserver-t1052kube            1/1     Running   1 (51d ago)   105d
kube-apiserver-t1053kube            1/1     Running   1 (51d ago)   105d
kube-controller-manager-t1051kube   1/1     Running   3 (20d ago)   105d
kube-controller-manager-t1052kube   1/1     Running   2 (51d ago)   105d
kube-controller-manager-t1053kube   1/1     Running   2 (19d ago)   105d
kube-proxy-7lhj5                    1/1     Running   1 (51d ago)   105d
kube-proxy-gx8rj                    1/1     Running   1 (51d ago)   105d
kube-proxy-krjfz                    1/1     Running   1 (51d ago)   105d
kube-scheduler-t1051kube            1/1     Running   3 (51d ago)   105d
kube-scheduler-t1052kube            1/1     Running   1 (51d ago)   105d
kube-scheduler-t1053kube            1/1     Running   3 (19d ago)   105d

4. 動作確認

ログ送信先となるsyslogサーバーにてログの受信状況を確認する。以下は私の環境の例となる。Fluentd経由でSquidのPodの標準出力に対して出力された接続ログが出力されている。
※Podのログを収集する場合、標準出力に対して出力させるようコンテナを構成する必要があるため注意する。

Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.225  83353 10.244.1.0 TCP_TUNNEL/200 6767 CONNECT www.googleapis.com:443 - HIER_DIRECT/172.217.175.234 -
Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.225  63309 10.244.3.0 TCP_TUNNEL/200 2408 CONNECT play.google.com:443 - HIER_DIRECT/142.251.222.14 -
Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.225 138131 10.244.0.1 TCP_TUNNEL/200 28279 CONNECT apis.google.com:443 - HIER_DIRECT/172.217.175.238 -
Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.226  63194 10.244.0.1 TCP_TUNNEL/200 4006 CONNECT play.google.com:443 - HIER_DIRECT/142.251.222.14 -
Aug 31 18:07:00 fluentd-72t29 fluentd: log:1725095215.224  56514 10.244.1.0 TCP_TUNNEL/200 2491 CONNECT ogs.google.com:443 - HIER_DIRECT/142.250.196.110 -

以上で、Fluentdを使ってKubernetesのログをsyslogで送信する手順は完了となる。

人気の投稿