ソフトウエア導入

2023年3月21日 (火)

非Windows11対応PCをWindows11にアップグレードする方法

備忘録

非Windows11 PCをWindows10 からWindows11にアップグレード

MicrosoftからWindows11のmulti-edition ISOイメージをダウンロード
setup.exeの実行、要件を見たいしていないことを確認
sources\appraiserres.dllファイルの中身を削除(ファイル自体を消すと再度作られてしまう)
setup.exeの実行
「セットアップでの更新プログラムのダウンロード方法の更新」をクリック
更新プログラム、ドライバー、オプション機能の入手で「今は実行しない」を選択して次へをクリック
ライセンス条項に同意するをクリック
インストール準備が完了したらインストールをクリック


10日以内ならシステム->回復->復元でWindows10に戻すことができる
10日以上に設定したかったら予め以下を実行
DISM /Online /Set-OSUninstallWindow /Value:100
Valueは日数指定、ここでは100日になる。
ただし、一旦この日数を過ぎるとWindows10に戻すことはできなくなる。

2022年11月23日 (水)

ThonnyでPicoのVersion upで SSL: CERTIFICATE_VERIFY_FAILED, certificate has expired にハマった件

ThonnyでRaspberry Pi Picoのversionを最新(1.19.1)にバージョンアップしようとしたら、SSL: CERTIFICATE_VERIFY_FAILED, certificate has expired と言われてエラーになった。この対策の備忘録。

現象から。Certification has expiredと言われる。
Thonnycertificationfailed

どこに有効期限が切れたCertificationがあるんだか分からないので、とりあえずThonnyを最新に更新してみた。更新前。
Thonnycurrentversion

ThonnyはここからWindows版をダウンロード。更新後。
Thonnynewversion

しかし現象は変わらず。
Thonnycertificationfailedonnewversion

この症状についてネット検索した結果、この問題のDiscussion Threadにたどり着いた。で、次の書き込みに注目!
I finally got it solved by installing https://letsencrypt.org/certs/lets-encrypt-r3.der 

この中の対応策にならって、このセキュリティ証明書をインポートした。以下、そのステップ記録。

「開く」をクリック。
Encryptr31

「証明書のインストール」をクリック。
Encryptr32

Thonnyを「すべてのユーザー」でインストールしたので、証明書もローカルコンピューターにインポート。
Encryptr33

「自動的に証明書ストアを選択する」を選択。
Encryptr34

「完了」をクリック。
Encryptr35

Encryptr36

これで証明書のインポートは完了。

さてさて、これでうまくいくのだろうかと。。。
Thonnypicoupdatesuccess

うまくいった。Certificationが更新されたということなんだろうけれど、インポートした証明書が一体なんだったのかはよく分からない。

でも、動くようになったので、めでたし、めでたし。

 

2022年11月22日 (火)

UI-VIEW32のオリジナルマップの作製

UI-VIEW32にオリジナルマップを入れたので、その手順の備忘録。

大桑村部分を拡大したマップを入れてみた。JA0WBT-7を中心にした長方形エリアがそのマップ。マップを入れるとUI-VIEW32は入れられたマップの表示エリアを四角枠で表示する。
Map1

このマップはGoogle Mapのマップで自分が入れたいマップの部分をモニターに表示させてスクリーンコピーでJPEGファイルを作る。
Okuwavil

このJPEGファイルの表示領域の左上隅と右下隅の座標をGoogle Mapで取得する。なので、JPEG座標隅位置の座標を取得しやす目印を隅にするとよい。

JPEGファイルはUI-VIEW32¥MAPにokuwa-vil.jpgとして保存した。取得した座標はJPEGファイルと同じファイル名のINFファイル(okuwa-vil.inf)としてMAPディレクトリに保存する。

okuwa-vil.infの内容:

35.45.99N, 137.25.98E <- 左上隅の座標
35.35.21N, 137.52.23E <- 右下隅の座標
okuwa-vil <- マップの名前(マップリストに表示される)

これらのファイルを保存したらUI-VIEW32のMap -> Refresh Map Listを実行する。これでokuwa-vilでAPRS局をポイントできるようにる。

以下がokuwa-vilで表示した例。
Map2

なかなか面白い。

2022年11月15日 (火)

APRS I-Gateの設置

APRS I-Gateサーバーを構成したので、その備忘録。

木曽谷はAPRS空白地帯。一方で中央アルプスへの登山道が何本もある。それらの登山道の多くのエリアが携帯圏外。ここでの遭難防止のためにAPRSを活用したいのだが、空白地帯故に役に立たない。これは新たに立ち上げるしかない。

で、とりあず実験システムの構成。

ヤフオク!でゲットしたFT-7800とメルカリでゲットしたThinkCentraで構成した。アンテナは軒先ホイップアンテナ。とりあえずFT7-7800の外部スピーカー端子をThinkCentraのマイク端子に直結した。

ThinkCentraはWindows 11、TNCはAWG Packet Engine、サーバーにはUI-VIEW32で接続した。全体の実験構成は以下。
Photo_20221116080201

今回の実験に使ったFT-7800
Img02642_small

I-Gateサーバーとして使っているLenovo ThinkCentre。FT-7800の外部スピーカー端子からマイク入力端子に直結している。ThinkCentraに外部スピーカーを取り付け、マイク入力をスピーカーモニターする構成にしてFT-7800からの音声入力をThinkCentraにてモニターしている。
Img02644_small

ビーコン発生機としてFT3Dを使用した。
Img02653_small

Software TNC、AGWPEをダウンロードする。この時AGW Monitorも一緒にダウンロードする。具体的な設定方法についてはソフトウエアTNCの解説を参考にした。AGW MonitorはAGW Monitorが実際にデコードできるかをチェックする。チェックの際、トランシーバーの音声出力レベルやPCのマイク入力レベルを調整することになる。

UI-VIEW32のインストールについては、いろいろなWEBページがあるが、どれも10年以上前とかなり古い。けれども、逆にそれ以降このアプリケーションは変更がなく、かつそれ以降あまりインストール事例報告がないともいえる。今回は、以下の3WEBページを参考にさせて頂いた。

細かなパラメータ設定は最初の2つに大変助けて頂いた。3つ目には命を救われたように思う。特に今回はWindows 11でのインストールだったのだけれど、アプリの互換性設定についてはめちゃくちゃ貴重な経験を共有いただいた(こころより感謝)。

以下、ちょっとハマったところの備忘録。

真っ先に行うComms Setupでつまづいた。そもそもこのCOMポート設定って何なんだろうってことになるわけだけれど、UI-VIEW32がデータを取得する元はTNCで、ハードウエアTNCの場合はRS-232CでPCと接続するのだろう(これに思い当たるのにちょっと時間がかかった)。であれば、ソフトウエアTNCを使っている場合はどうなるのか???先の3つのWEBページの2つ目に答えがあった、Host modeでAGWPEを選べばよいのだ。これで解決した。

Comms SetupでのHost mode設定。
Awgpe

Setup -> APRS Server Setupで接続先となるAPRSサーバーを指定する。ここでは先のWEBページのガイドに沿ってaprsjp.net:14579を設定した。しかし、いつまで経っても自分の存在がMap上に現れない。そこで、Option -> Show IGATE Trafficを選んでRF to Internet Trafficを見てみたが、Trafficがない。つまり、サーバーとの通信がないわけだ。そもそも、APRS Server Setupで設定したサーバーにどういタイミングでログインするのか???Server SetupダイアログでOkボタンをクリックしたらログインするのか???どうもそこの理解が正しくなかったようだ。Actionメニューを見るとAction -> Connect to APRS Serverとある。ここをクリックしてみた。何度かTimeoutが起きたけれど、数回のチャレンジのあと、無事APRS Serverに接続した。接続するとMap上に沢山のノードが表示され、IGATE TrafficのRF to the Internetにも、ビーコン受信に合わせてトラフィックがレポートされた。

APRS Serverに接続した後のAction Menu。
Aprsconnection

次にMap上のシンボル設定。ネットで公開されているシンボル設定に従ってシンボルを設定した。

No Diam’dでR(I-Gate単体でReceive Only)に設定した。
Symbol

さてさて、これでI-Gateサーバーが動くようになったので、FT3D(暫定的にTX Interval=1分に設定)を携帯して自動車にて近所を走ってみた。以下がその結果。
Arps

1分は自動車としては案外長い(移動する)。

とりあえず基礎実験が完了した。今後は以下のテーマで先に進むこととする。

  • 携帯圏外(中央アルプス登山道)でのARPS電波受信実験
  • パケット認識率向上のためのチューニング(現在は無線機とスピーカー出力とPCのマイク入力直結)
  • 双方向通信の為の環境構築
  • 9600bpsでの運用実験

まずはめでたし、めでたし。

2022年11月13日 (日)

PCIe dual serial port adapterドライバーCH38XDRV.ZIPのWindows11へのインストール

AmazonにてPCIe 2 serial port adapterを購入。ドライバーインストールで手間取ったので備忘録。

メルカリでLenovo ThinkCentreをゲット。COMポートを使うアプリケーションでの使用が目的だが、届いてみると、なんとCOMポートが実装されていない。しょうがないので、LOW HIGHTのPCIe Serial Port Adapterをアマゾンで購入した。2099円。余分な出費(COMポートの存在を確認していればこの出費はなし)。

届いたアダプター。
Img02608_small

早速実装した。
Img02575_small

DRIVER CD-ROMが付属していたがドライバーインストールファイルの日付が2018と古いのでネットからメーカーのドライバーをダウンロードした。このドライバーページは英語版。PUMPSETUP.EXEというインストールツールを使ってインストールしたがエラーが表示された。
Img02568_small
デバイスマネージャで見てもドライバーのインストールが無いといって黄色のビックリマークが表示される。どうもデバイスドライバーがWindows11に対応していないようだ。ダウンロードページの説明ではWindows11対応になっているのだが、、、

Googleで検索しなおすと同じメーカーの中国語ダウンロードページがあった。ドライバーをダウンロードして日付を見ると2021年になっている。これならWindows 11対応だろうと思い、先にインストールしたドライバーをアンインストールしてから、ここからダウンロードしたドライバーをインストールしてみた。インストール成功。デバイスマネージャでCOMポートが二つ表示された。

ということで、めでたし、めでたし。

2021年12月 7日 (火)

Chrome Desktopを使ってみた

今までTeam Viewerを個人使用で使ってきた。いろいろと面倒なことが起きたのでChrome Desktopに乗り換えようと思う。

インストールは至って簡単で、Chrome Desktopをインストールするだけ。クライアントからのアクセスはChomeを使う。重要なのは同一Googleアカウントで、サーバー、クライアントともログインするということ。つまり、同じGoogleアカウントでログインしているPC同士はPINコードさえ入力すればリモートアクセスを許可するというもの。

同じGoogleアカウントでログインしていて、Chrome Desktopサーバーとなっているマシーンはクライアントから一覧で見ることができる。
Chromedesktop_20211207110401
ここでログインしたいRemote Desktopを選択すればよい。

ではTeam Viewerの良いところがあるか、自分の過去の利用状況から考えてみた。Team Viewerで使ったのはファイル転送や再起動などだ。それ以外は単純なRemote Desktopとしてしか使ていない。
Teamvieweroption

Chrome DesktopでもCtl+Alt+Delを送ることができるからリモートから再起動が可能だ。
Chromedesktop_20211207110201

ファイル転送もできる。
Chromedesktop_20211207110202

となると、Team Viewerを使い続ける意味があるのか?今の所、それを主張しうるポイントがない。今後はChrome DesktopでリモートFT8運用をおこなってみるかな。

 

 

 

 

2020年10月10日 (土)

Bondで1日縛られた土曜日

とある事からBondを試すことになった。なんだかんだで結構時間がかかってしまって、朝から初めてもう外は薄暗くなってきてしまった。
で、いつものように備忘録。

環境はVMWare Player上の仮想サーバーのCentOS7.8。ネットワークアダプターは3つ用意して接続状態に設定。そのうち一つだけにIPアドレスを手動で設定しておくけれども、残り2つは何も事前設定しないでおく。

CentOSが立ち上がった直後のインターフェース状態は以下の通り。ens33だけにIPアドレスをセットしてある。

[root@localhost ~]# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.60 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::20c:29ff:fe89:51ca prefixlen 64 scopeid 0x20<link>
inet6 240b:11:4541:9100:20c:29ff:fe89:51ca prefixlen 64 scopeid 0x0<global>
ether 00:0c:29:89:51:ca txqueuelen 1000 (Ethernet)
RX packets 74 bytes 6888 (6.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 82 bytes 9410 (9.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens37: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:0c:29:89:51:d4 txqueuelen 1000 (Ethernet)
RX packets 27 bytes 2082 (2.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens38: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:0c:29:89:51:de txqueuelen 1000 (Ethernet)
RX packets 27 bytes 2082 (2.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 68 bytes 5908 (5.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 68 bytes 5908 (5.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:b1:f3:35 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens33にはインターフェース情報が設定されていて、のこりの2つのネットワークデバイスのens37とens38はいずれもstateはUPになっているけれどもインターフェース情報は未設定。

[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:89:51:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.1.60/24 brd 192.168.1.255 scope global noprefixroute ens33
valid_lft forever preferred_lft forever
inet6 240b:11:4541:9100:20c:29ff:fe89:51ca/64 scope global mngtmpaddr dynamic
valid_lft 2591893sec preferred_lft 604693sec
inet6 fe80::20c:29ff:fe89:51ca/64 scope link
valid_lft forever preferred_lft forever
3: ens37: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:89:51:d4 brd ff:ff:ff:ff:ff:ff
4: ens38: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:89:51:de brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:b1:f3:35 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:b1:f3:35 brd ff:ff:ff:ff:ff:ff

で、これらをまとめると現在はこんな状態。インターフェース名ens33に対してのみネットワークデバイスens33が紐づけられている。

[root@localhost ~]# nmcli c
NAME UUID TYPE DEVICE
ens33 5fe6b09c-d12c-456e-9b1f-1d018a789fd2 ethernet ens33
virbr0 3de4169c-88a9-424f-b931-52ae87288f01 bridge virbr0
ens37 23a1e399-5010-4b12-842e-f43fcb6fb36c ethernet --
ens38 204e9f07-1a89-4c28-9ef1-1e0f775f9352 ethernet --

BondingのMasterを作成する。接続名とインターフェース名の両方とも名前はbond0と命名。モードはactive-backup。

[root@localhost ~]# nmcli connection add type bond autoconnect no con-name bond0 ifname bond0 mode active-backup
接続 'bond0' (329498e1-1f6b-4ed5-9885-c1a401cc63dc) が正常に追加されました。

確認。bond0が作られている。

[root@localhost ~]# nmcli c
NAME UUID TYPE DEVICE
ens33 5fe6b09c-d12c-456e-9b1f-1d018a789fd2 ethernet ens33
virbr0 3de4169c-88a9-424f-b931-52ae87288f01 bridge virbr0
bond0 329498e1-1f6b-4ed5-9885-c1a401cc63dc bond --
ens37 23a1e399-5010-4b12-842e-f43fcb6fb36c ethernet --
ens38 204e9f07-1a89-4c28-9ef1-1e0f775f9352 ethernet --

ens37とens38をSlaveとしてMaster bond0に登録する。

[root@localhost ~]# nmcli connection add type bond-slave autoconnect no ifname ens37 master bond0
接続 'bond-slave-ens37' (a2516f43-5725-425f-80c0-f6226d125f84) が正常に追加されました。
[root@localhost ~]# nmcli connection add type bond-slave autoconnect no ifname ens38 master bond0
接続 'bond-slave-ens38' (5c1e4b8b-dc77-414b-8a91-3ab3cc809056) が正常に追加されました。

状況の確認。いずれもbond-slaveとして接続名が登録されている。

[root@localhost ~]# nmcli c
NAME UUID TYPE DEVICE
ens33 5fe6b09c-d12c-456e-9b1f-1d018a789fd2 ethernet ens33
virbr0 3de4169c-88a9-424f-b931-52ae87288f01 bridge virbr0
bond-slave-ens37 a2516f43-5725-425f-80c0-f6226d125f84 ethernet --
bond-slave-ens38 5c1e4b8b-dc77-414b-8a91-3ab3cc809056 ethernet --
bond0 329498e1-1f6b-4ed5-9885-c1a401cc63dc bond --
ens37 23a1e399-5010-4b12-842e-f43fcb6fb36c ethernet --
ens38 204e9f07-1a89-4c28-9ef1-1e0f775f9352 ethernet --

Masterであるbond0にIPアドレス等を設定する。

[root@localhost ~]# nmcli c mod bond0 ipv4.method manual ipv4.address "192.168.1.61/24" ipv4.gateway "192.168.1.1" ipv4.dns "192.168.1.1" ipv6.method ignore

以降のシステム再起動でens37とens38が自動で接続状態にならないように、かつbond-slave-ens37とbond-slave-ens38とbond0が自動で接続状態になるように設定する。つまり、ens37とens38は単独ではイネーブルにならないであくまでbond-slaveとしてイネーブルされることを明示的に設定するわけだ。

[root@localhost ~]# nmcli c m ens37 connection.autoconnect no
[root@localhost ~]# nmcli c m ens38 connection.autoconnect no
[root@localhost ~]# nmcli c m bond-slave-ens37 connection.autoconnect yes
[root@localhost ~]# nmcli c m bond-slave-ens38 connection.autoconnect yes
[root@localhost ~]# nmcli c m bond0 connection.autoconnect yes

設定状態を確認する。

[root@localhost ~]# nmcli -f connection c s bond-slave-ens37
connection.id: bond-slave-ens37
connection.uuid: a2516f43-5725-425f-80c0-f6226d125f84
connection.stable-id: --
connection.type: 802-3-ethernet
connection.interface-name: ens37
connection.autoconnect: はい
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1602314980
connection.read-only: いいえ
connection.permissions: --
connection.zone: --
connection.master: bond0
connection.slave-type: bond
connection.autoconnect-slaves: -1 (default)
connection.secondaries: --
connection.gateway-ping-timeout: 0
connection.metered: 不明
connection.lldp: default
connection.mdns: -1 (default)
connection.llmnr: -1 (default)


[root@localhost ~]# nmcli -f connection c s bond-slave-ens38
connection.id: bond-slave-ens38
connection.uuid: 5c1e4b8b-dc77-414b-8a91-3ab3cc809056
connection.stable-id: --
connection.type: 802-3-ethernet
connection.interface-name: ens38
connection.autoconnect: はい
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1602314980
connection.read-only: いいえ
connection.permissions: --
connection.zone: --
connection.master: bond0
connection.slave-type: bond
connection.autoconnect-slaves: -1 (default)
connection.secondaries: --
connection.gateway-ping-timeout: 0
connection.metered: 不明
connection.lldp: default
connection.mdns: -1 (default)
connection.llmnr: -1 (default)


[root@localhost ~]# nmcli -f connection c s bond0
connection.id: bond0
connection.uuid: 329498e1-1f6b-4ed5-9885-c1a401cc63dc
connection.stable-id: --
connection.type: bond
connection.interface-name: bond0
connection.autoconnect: はい
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1602314980
connection.read-only: いいえ
connection.permissions: --
connection.zone: --
connection.master: --
connection.slave-type: --
connection.autoconnect-slaves: -1 (default)
connection.secondaries: --
connection.gateway-ping-timeout: 0
connection.metered: 不明
connection.lldp: default
connection.mdns: -1 (default)
connection.llmnr: -1 (default)

一連の変更を反映させるためにネットワークサービスの再起動を行う。

[root@localhost ~]# systemctl restart NetworkManager
[root@localhost ~]# systemctl restart network.service

出来上がった結果は以下のとおり。

[root@localhost ~]# nmcli c
NAME UUID TYPE DEVICE
ens33 5fe6b09c-d12c-456e-9b1f-1d018a789fd2 ethernet ens33
bond0 329498e1-1f6b-4ed5-9885-c1a401cc63dc bond bond0
virbr0 b8211a91-b2aa-4c8d-af4d-7207588fadff bridge virbr0
bond-slave-ens37 a2516f43-5725-425f-80c0-f6226d125f84 ethernet ens37
bond-slave-ens38 5c1e4b8b-dc77-414b-8a91-3ab3cc809056 ethernet ens38
ens37 23a1e399-5010-4b12-842e-f43fcb6fb36c ethernet --
ens38 204e9f07-1a89-4c28-9ef1-1e0f775f9352 ethernet --

 

[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:89:51:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.1.60/24 brd 192.168.1.255 scope global noprefixroute ens33
valid_lft forever preferred_lft forever
inet6 240b:11:4541:9100:20c:29ff:fe89:51ca/64 scope global mngtmpaddr dynamic
valid_lft 2591984sec preferred_lft 604784sec
inet6 fe80::20c:29ff:fe89:51ca/64 scope link
valid_lft forever preferred_lft forever
3: ens37: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
link/ether 00:0c:29:89:51:d4 brd ff:ff:ff:ff:ff:ff
4: ens38: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
link/ether 00:0c:29:89:51:d4 brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:b1:f3:35 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:b1:f3:35 brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0c:29:89:51:d4 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.61/24 brd 192.168.1.255 scope global noprefixroute bond0
valid_lft forever preferred_lft forever
inet6 240b:11:4541:9100:20c:29ff:fe89:51d4/64 scope global mngtmpaddr dynamic
valid_lft 2591984sec preferred_lft 604784sec
inet6 fe80::20c:29ff:fe89:51d4/64 scope link
valid_lft forever preferred_lft forever
[root@localhost ~]#

そとから192.168.1.61でpingして疎通確認を行ってオッケー。

この作業を行って分かったことは、Bonding設定が終わるとSlaveに設定したens37とens38のMACアドレスが同じになる(末尾d4)ことと、Masterのbond0のMACアドレスも同じになること。試しにってことでもう一つSlaveを追加しても同じMACアドレスになった。ということはMasterのIPアドレスをこのMACアドレスに設定して、Slaveに設定したどのポートも外からは金太郎飴に見えるようにするってことなんだろうなぁ、、、とぼや~と理解した感じ(少なくともactive-standbyでは)。

まぁ、時間は費やしたけれど、新しい理解(ぼや~だけど)を得られたみたいだから良しとするか。

追記:
モニターの前から離れる前に、この理解は本当に正しいのかなぁって思ってちょっと調べてみたんだけれども、どうやら正しい感じだ。で、更に現在のBonding状態がActiveなSlaveの切り替え方法が見つかったので実際にやってみた。

[root@localhost ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: ens37
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: ens37
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:89:51:d4
Slave queue ID: 0

Slave Interface: ens38
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:89:51:de
Slave queue ID: 0

ActiveなSlaveを切り替えてみる。現在ens37がActive。
[root@localhost ~]# cat /proc/net/bonding/bond0 | grep Currently
Currently Active Slave: ens37

切り替え実行。

[root@localhost ~]# ifenslave -c bond0 ens38

切り替え確認。

[root@localhost ~]# cat /proc/net/bonding/bond0 | grep Currently
Currently Active Slave: ens38
[root@localhost ~]#

ちゃんと動いているようだ。めでたし、めでたし。

追記2:

Masterのbond0のIPアドレスは/etc/sysconfig/network-scripts/ifcfg-bond0にかかれているIPADDRを変更すれば良いが、変更後NetworkManagerやnetwork.serviceをrestartしただけではIPアドレスが更新されなかった。で、実際には以下を実行することで変更を反映させた。

# nmcli c down bond0
# nmcli c up bond0

これは知ってないとハマるところだろうなぁ。まぁ、たまたまnmcli c up コマンドを実行した直後にこの課題にぶつかったので、試しにこのコマンド投げてみたら、、、ってことに過ぎなかったから。

追記3:

いろいろと先人の知恵を学んでいるとどうやら正解は以下のようだ。

# nmcli c reload <接続名>   ここではbond0
# nmcli c down <接続名>
# nmcli c up <接続名>

2020年9月27日 (日)

restlet serverを立ち上げる

今から6年程前に結構一生懸命になってデモ用のRestletサーバーを構成したことがある。その頃のことを思い出して、久々にRestletサーバーを試してみた。目的はRaspberry Piの話し相手の作成。

環境は以下のとおり:
Centos 7.8
Java 1.8.0
Restlet 2.4.3

Step-1
Javaのインストール
# yum install java-1.8.0-openjdk java-1.8.0-openjdk-devel

Step-2
Restletのインストール
以下からzipをダウンロードする。
https://restlet.talend.com/downloads/current/
展開先は$HOME/workにした。

Step-3
環境変数の設定
Homeの.bash_profileに以下を設定する
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=.:$JAVA_HOME/jre/lib:JAVA_HOME/lib:$JAVA_HOME/lib/tools.jar:$HOME/work/restlet-jse-2.4.3/lib/org.restlet.jar:$home/work
なお、Class編集を含むコーディング環境は$home/workとしている。
備忘録として、、、上記環境変数の即時有効化には以下のコマンドを実行。
source ./.bash_profile

Step-4
コードの作成
作ったJAVAコードは以下の3つ:
ServerMain.java:Port8010でServerを立ち上げ、Dispatcherを呼ぶ
ServerDispatcher.java:コマンドに従ってFunctionを呼ぶ(この時点ではDataInpuのみを呼び出している)
DataInput.java:Dispatcherに呼び出されるFunction(中身はこの時点では空)

以下がソースコード。昔のコードを引っ張りだして今時点で不要な部分はざっくりとそぎ落としてあるけれどもimportはそのままなので、余分なライブラリがImportされているかも(だろう)。

ServerMain.java

import org.restlet.Component;
import org.restlet.data.Protocol;
import org.restlet.resource.ServerResource;

public class ServerMain extends ServerResource{
public static void main(String[] argsthrows Exception {
    // Create a new Component.
    Component component = new Component();

    // Add a new HTTP server listening on port 8010.
    component.getServers().add(Protocol.HTTP8010);

    // Attach the sample application.
    component.getDefaultHost().attach("/command",
            new ServerDispatcher());

    // Start the component.
    component.start();
   }

ServerDispatcher.java

import org.restlet.Application;
import org.restlet.Restlet;
import org.restlet.routing.Router;

public class ServerDispatcher extends Application {

    /**
     * Creates a root Restlet that will receive all incoming calls.
     */
    @Override
    public synchronized Restlet createInboundRoot() {
        // Create a router Restlet that routes each call to a new instance
        Router router = new Router(getContext());

        // Defines only one route
        router.attach("/datain/{keyword}"DataInput.class);
  
        return router;
    }
}

DataIn.java

import org.restlet.resource.Get;
import org.restlet.resource.ServerResource;
import org.restlet.Restlet;
import org.restlet.Client;
import org.restlet.Context;
import org.restlet.Request;
import org.restlet.Response;
import org.restlet.data.MediaType;

 /**
 * Resource which has only one representation.
 * 
 */
public class DataInput extends ServerResource {

    public static int count;
            
    @Get
    public String represent() {

        String str = getReference().getPath();
        System.out.println( str );
        int index = str.indexOf("/datain/");
        index += "/datain/".length();
        String indata =  str.substring(index);
        System.out.println("input :" + indata );

    return "return from datain";

    }
}

 

それぞれのJavaコードをコンパイルしてClassファイル化しておく。
以下、ServerMainの実行。クライアントからのコマンドの実行結果(19:58:07)が出力されている。インプットデータはtestと表示している。

# java ServerMain
Starting the internal [HTTP/1.1] server on port 8010
Starting ServerDispatcher application
/command/datain/test
input :test
2020-09-27 19:58:07 192.168.1.8 - - 8010 GET /command/datain/test - 200 18 0 56 http://192.168.1.62:8010 curl/7.55.1 -

上記出力をさせた、実際にクライアントから実行したコマンドは以下。testをパラメータとして渡している。

>curl http://192.168.1.62:8010/command/datain/test
return from datain
>

これで基本形が出来たことになる(と言うか昔のコードを復活したことになる)。

次のステップはRaspberry Piからコマンド(多分温度計の値)を送ってみたいと思う。
で、今日はここまで。

 

2020年8月30日 (日)

Kubernetesテストベンチへの道 ゴール - CSI Driverのインストール

ようやくゴールに到着。ゴールインの前に今回のシステム構成のおさらい。

まず、全てのノードはVM上に作成した。

ホストH/W Lenovo Minitowr 530 i9 9900 (8core/16thread) 3.10GHz, memory=32GB 
ホストOS Windows10 Home Edition
親VM VMWare Workstation Player 15
  dns 1CPU, 1GB (local DNS)
  nfs 1CPU, 1GB (scale pvcマウントに先立つnfs pvcのマウントテスト用)
  子VM ESXi 6.0
    Kubernetes Nodes (Kubernetes環境構築ESXi)
      master 2CPU, 4GB
      worker1 2CPU, 4GB
      worker2 2CPU, 4GB
    Scale Nodes (scale環境構築ESXi)
      server node 1 (snode1) 1CPU, 2GB
      server node 2 (snode2) 1CPU, 2GB
      gui node (sgui) 1CPU, 3GB

合計システムリソース CPU 11、memory 21GB

今回のホストH/Wではこれがほぼほぼ上限の構成となる。当初Kubernetesは2GBメモリーで構成したけれども、メモリーが足りないようで頻繁にハングしたので4GBに増強。Scale GUIノードも2GBでハングしので3GBに増強。この結果、今時点においてScale CSIドライバー試験が出来てはいる。

それではゴールインストーリの始まり始まり、、、、

CSI Driverのインストール

KubernetesのインストールScaleのインストールはそれぞれのブログを参照して下さい。Local DNSDNS利用留意点についても同様です。

Scale GUIサーバー上での作業

ユーザーグループ csiadminの作成

cd /usr/lpp/mmfs/gui/cli

[root@localhost cli]# ./mkusergrp CsiAdmin --role csiadmin
[root@localhost cli]# ./lsusergrp
Name ID Role
Administrator 1 admin
SecurityAdmin 2 securityadmin
StorageAdmin 3 storageadmin
SystemAdmin 4 systemadmin
Monitor 5 monitor
SnapAdmin 6 snapadmin
DataAccess 7 dataaccess
ProtocolAdmin 8 protocoladmin
UserAdmin 9 useradmin
CsiAdmin 10 csiadmin
CnssOperator 11 cnssoperator
EFSSG1000I The command completed successfully.

CSIドライバーからGUIサーバーにログインするユーザーの作成

[root@localhost cli]# ./mkuser csiadmin -p password -g CsiAdmin
EFSSG0019I The user csiadmin has been successfully created.
EFSSG1000I The command completed successfully.
[root@localhost cli]# ./lsuser
Name Long name Password status Group names Failed login attempts Target Feedback Date
admin active SecurityAdmin 0 24.09.2020 09:03:23.000
csiadmin active CsiAdmin 0
EFSSG1000I The command completed successfully.
[root@localhost cli]#

作成したユーザーアカウントでのGUIサーバーへのアクセスを確認.

[root@localhost cli]# curl --insecure -u 'csiadmin:password' -X GET https://sgui.pathpilot.local:443/scalemgmt/v2/cluster
{
"cluster" : {
"clusterSummary" : {
"clusterId" : 1593904468708199996,
"clusterName" : "gpfscluster1.pathpilot.local",
"primaryServer" : "snode-1.pathpilot.local",
"rcpPath" : "/usr/bin/scp",
"rcpSudoWrapper" : false,
"repositoryType" : "CCR",
"rshPath" : "/usr/bin/ssh",
"rshSudoWrapper" : false,
"uidDomain" : "gpfscluster1.pathpilot.local"
},
"capacityLicensing" : {
"liableCapacity" : 10737418240,
"liableNsdCount" : 2,
"liableNsds" : [ {
"nsdName" : "NSD_101",
"liableCapacity" : 5368709120
}, {
"nsdName" : "NSD_102",
"liableCapacity" : 5368709120
} ]
}
},
"status" : {
"code" : 200,
"message" : "The request finished successfully."
}
[root@localhost cli]#

Quotaの設定

[root@localhost cli]# mmlsfs gpfsfs01 --perfileset-quota
flag value description
------------------- ------------------------ -----------------------------------
--perfileset-quota いいえ Per-fileset quota enforcement
[root@localhost cli]# mmlsfs gpfsfs01 -Q
flag value description
------------------- ------------------------ -----------------------------------
-Q none Quotas accounting enabled
none Quotas enforced
none Default quotas enabled
[root@localhost cli]# mmchfs gpfsfs01 -Q yes
mmchfs: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@localhost cli]# mmlsfs gpfsfs01 -Q
flag value description
------------------- ------------------------ -----------------------------------
-Q user;group;fileset Quotas accounting enabled
user;group;fileset Quotas enforced
none Default quotas enabled
[root@localhost cli]#

クラスタに属性情報追加

[root@localhost cli]# mmchconfig enforceFilesetQuotaOnRoot=yes -i
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@localhost cli]# mmchconfig controlSetxattrImmutableSELinux=yes -i
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@localhost cli]# mmlsconfig
Configuration data for cluster gpfscluster1.pathpilot.local:
------------------------------------------------------------
clusterName gpfscluster1.pathpilot.local
clusterId 1593904468708199996
autoload no
dmapiFileHandleSize 32
minReleaseLevel 5.0.5.1
ccrEnabled yes
cipherList AUTHONLY
enforceFilesetQuotaOnRoot yes
controlSetxattrImmutableSELinux yes
adminMode central

File systems in cluster gpfscluster1.pathpilot.local:
-----------------------------------------------------
/dev/gpfsfs01

ファイルシステム情報にdf表示追加

[root@localhost cli]# mmchfs gpfsfs01 --filesetdf
[root@localhost cli]#


以降の作業はKubernetesのマスターノードで実行する

CSI OperatorのProvisioning対象ノードであることを示すためラベル付け

[root@master yaml]# kubectl label node worker1.pathpilot.local scale=true --overwrite=true
node/worker1.pathpilot.local labeled
[root@master yaml]# kubectl label node worker2.pathpilot.local scale=true --overwrite=true
node/worker2.pathpilot.local labeled
[root@master yaml]#
[root@master yaml]# kubectl describe node worker1.pathpilot.local
Name: worker1.pathpilot.local
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
kubernetes.io/arch=amd64
kubernetes.io/hostname=worker1.pathpilot.local
kubernetes.io/os=linux
scale=true
....

ネームスペースの作成

[root@master yaml]# kubectl create namespace ibm-spectrum-scale-csi-driver
namespace/ibm-spectrum-scale-csi-driver created

Operatorの作成

[root@master yaml]# kubectl create -f https://raw.githubusercontent.com/IBM/ibm-spectrum-scale-csi/v2.0.0/generated/installer/ibm-spectrum-scale-csi-operator.yaml
deployment.apps/ibm-spectrum-scale-csi-operator created
clusterrole.rbac.authorization.k8s.io/ibm-spectrum-scale-csi-operator created
clusterrolebinding.rbac.authorization.k8s.io/ibm-spectrum-scale-csi-operator created
serviceaccount/ibm-spectrum-scale-csi-operator created
customresourcedefinition.apiextensions.k8s.io/csiscaleoperators.csi.ibm.com created

[root@master yaml]# kubectl get pod,deployment -n ibm-spectrum-scale-csi-driver
NAME READY STATUS RESTARTS AGE
pod/ibm-spectrum-scale-csi-operator-66c7bfc95c-cgvnn 1/1 Running 1 65s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/ibm-spectrum-scale-csi-operator 1/1 1 1 65s
[root@master yaml]#
[root@master yaml]# curl -O https://raw.githubusercontent.com/IBM/ibm-spectrum-scale-csi/v2.0.0/operator/deploy/crds/csiscaleoperators.csi.ibm.com_cr.yaml
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5001 100 5001 0 0 9307 0 --:--:-- --:--:-- --:--:-- 9330


csiscaleoperators.csi.ibm.com_cr.yamlの編集

ClusterIDはmmlsclusterが返すcluster idをコピーする。
[root@localhost ~]# mmlscluster

GPFS cluster information
========================
GPFS cluster name: gpfscluster1.pathpilot.local
GPFS cluster id: 1593904468708199996
GPFS UID domain: gpfscluster1.pathpilot.local
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
Repository type: CCR

Node Daemon node name IP address Admin node name Designation
------------------------------------------------------------------------------------
1 snode-1.pathpilot.local 192.168.1.121 snode-1.pathpilot.local quorum-manager
2 snode-2.pathpilot.local 192.168.1.122 snode-2.pathpilot.local quorum-manager
6 sgui.pathpilot.local 192.168.1.123 sgui.pathpilot.local
7 worker2.pathpilot.local 192.168.1.133 worker2.pathpilot.local
8 worker1.pathpilot.local 192.168.1.132 worker1.pathpilot.local

[root@localhost ~]#

scaleHostpathは mmlsfsが返す”Default mount point” をコピーする。
[root@localhost ~]# mmlsfs all

File system attributes for /dev/gpfsfs01:
=========================================
flag value description
------------------- ------------------------ -----------------------------------
....
-o none Additional mount options
-T /gpfs/gpfsfs01 Default mount point
--mount-priority 0 Mount priority
[root@localhost ~]#

secrets.yamlの編集と適用

Scale GUIサーバーにログオンするためのSecret.yamlを編集する。
ユーザー名とパスワードはbase64に変換した値をセットする。

[root@master ~]# echo -n 'csiadmin' | base64
bXktcGFzc3dvcmQ=
[root@master ~]# echo -n 'password' | base64
bXktdXNlcm5hbWU=
[root@master ~]#

編集後のsecret.yamlは以下のようになる。
apiVersion: v1
kind: Secret
metadata:
name: sguisecret << 自分のsecret名
labels:
product: ibm-spectrum-scale-csi
data:
username: bXktdXNlcm5hbWU= <<< base64で設定(この値はダミーです)
password: bXktcGFzc3dvcmQ= <<< base64で設定(この値はダミーです)

[root@master yaml]# kubectl apply -f secrets.yaml -n ibm-spectrum-scale-csi-driver
secret/sguisecret created

csiscaleoperators.csi.ibm.com_cr.yaml の編集

spec:
# The path to the GPFS file system mounted (either remote/local) on the local Spectrum Scale API host machine.
# ==================================================================================
scaleHostpath: "/gpfs/gpfsfs01"  << ここを編集

# A passthrough option that distributes an imagePullSecrets array to the containers
# generated by the csi scale operator. Please refer to official k8s documentation for
# your environment for more details. https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
# ==================================================================================
# imagePullSecrets:
# - APullSecret
# - AnotherOptional

# Below specifies the details of a SpectrumScale cluster configuration used by the
# plugin. It can have multiple values.
# ==================================================================================
clusters:
- id: "1593904468708199996" << ここを編集 mmlsclusterからコピー
secrets: "sguisecret"  << ここを編集 secrets.yamlで設定した名前
secureSslMode: false
primary:
primaryFs: "gpfsfs01"  << ここを編集
# primaryFset: "< Fileset in Primary Filesystem >" # Optional - default:spectrum-scale-csi-volume-store
# inodeLimit: "< inode limit for Primary Fileset >" # Optional
# remoteCluster: "< Remote ClusterID >" # Optional - This is only required if primaryFs is remote cluster's filesystem and this ID should have separate entry in Clusters map too.
# cacert: "< Name of CA cert configmap for GUI >" # Optional
restApi:
- guiHost: "sgui.pathpilot.local"  << ここを編集
#

Lightweight Volumeの作成先filesetの作成

[root@localhost ~]# mmcrfileset gpfsfs01 pvfileset
Fileset pvfileset created with id 1 root inode 19456.
[root@localhost ~]# mmlsfileset gpfsfs01
Filesets in file system 'gpfsfs01':
Name Status Path
root Linked /gpfs/gpfsfs01
pvfileset Unlinked --
[root@localhost ~]#
[root@localhost gpfsfs01]# ls /gpfs/gpfsfs01
[root@localhost gpfsfs01]#
[root@localhost gpfsfs01]# mmlinkfileset gpfsfs01 pvfileset -J /gpfs/gpfsfs01/pvfileset
Fileset pvfileset linked at /gpfs/gpfsfs01/pvfileset
[root@localhost gpfsfs01]# mmlsfileset gpfsfs01
Filesets in file system 'gpfsfs01':
Name Status Path
root Linked /gpfs/gpfsfs01
pvfileset Linked /gpfs/gpfsfs01/pvfileset
[root@localhost gpfsfs01]#
[root@localhost gpfsfs01]# ls /gpfs/gpfsfs01
pvfileset
[root@localhost gpfsfs01]#

Persistent Volume作成先ディレクトリを作成する
[root@localhost pvfileset]# mkdir lwdir

念の為、モードを777にする。これは要らないかもしれない。

[root@localhost pvfileset]# ls -l
合計 1
drwxr-xr-x. 2 root root 4096 8月 27 15:08 lwdir
[root@localhost pvfileset]# chmod 777 lwdir
[root@localhost pvfileset]# ls -l
合計 1
drwxrwxrwx. 2 root root 4096 8月 27 15:08 lwdir

lightweight-storage-class.yamlの編集と適用

[root@localhost pvfileset]# cat lightweight-storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ibm-spectrum-scale-csi-lt << ここを編集
provisioner: spectrumscale.csi.ibm.com
parameters:
volBackendFs: "gpfsfs01" << ここを編集
volDirBasePath: "pvfileset/lwdir"  << ここを編集
reclaimPolicy: Delete

[root@master yaml]# kubectl apply -f lightweight-storage-class.yaml
storageclass.storage.k8s.io/ibm-spectrum-scale-csi-lt created

[root@master yaml]# kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
ibm-spectrum-scale-csi-lt spectrumscale.csi.ibm.com Delete Immediate false 19s

lightweight-pvc.yamlの編集と適用

[root@master yaml]# cat lightweight-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: scale-lw-fset-pvc << ここを編集 podのyamlが参照
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
storageClassName: ibm-spectrum-scale-csi-lt << ここを編集、lightweight-storage-class.yamlのclass名をコピー

[root@master yaml]# kubectl apply -f lightweight-pvc.yaml
persistentvolumeclaim/scale-lw-fset-pvc created

[root@master yaml]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nfs-claim1 Bound pv0001 3Gi RWO 12d
scale-lw-fset-pvc Pending ibm-spectrum-scale-csi-lt 15s

[root@master yaml]# kubectl describe pvc scale-lw-fset-pvc
Name: scale-lw-fset-pvc
Namespace: default
StorageClass: ibm-spectrum-scale-csi-lt
Status: Pending
Volume:
Labels: <none>
Annotations: volume.beta.kubernetes.io/storage-provisioner: spectrumscale.csi.ibm.com
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Mounted By: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ExternalProvisioning 14s (x2 over 24s) persistentvolume-controller waiting for a volume to be created, either by external provisioner "spectrumscale.csi.ibm.com" or manually created by system administrator
[root@master yaml]#

Microservice pod (mypod-lw01.yaml)の編集と適用

[root@master yaml]# cat mypod-lw01.yaml

apiVersion: v1
kind: Pod
metadata:
name: csi-scale-dynamicdemo-pod << このpodの名前
labels:
app: nginx
spec:
containers:
- name: web-server
image: nginx
volumeMounts:
- name: mypvc
mountPath: /usr/share/nginx/html
ports:
- containerPort: 80
volumes:
- name: mypvc
persistentVolumeClaim:
claimName: scale-lw-fset-pvc  << pvcの名前
readOnly: false

[root@master yaml]# kubectl apply -f mypod-lw01.yaml
pod/csi-scale-dynamicdemo-pod created

[root@localhost yaml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
csi-scale-dynamicdemo-pod 1/1 Running 0 79s

無事Runningになっている!!!念の為確認。

[root@localhost yaml]# kubectl describe pod csi-scale-dynamicdemo-pod
Name: csi-scale-dynamicdemo-pod
Namespace: default
Priority: 0
Node: worker2.pathpilot.local/192.168.1.133
Start Time: Sat, 29 Aug 2020 21:26:27 +0900
Labels: app=nginx
Annotations: <none>
Status: Running
IP: 10.244.4.4
IPs:
IP: 10.244.4.4
Containers:
web-server:
Container ID: docker://c3572aa8247d4713f234c7b10da00e5644ebe1a4ab176f0b9d8ade727aee3455
Image: nginx
Image ID: docker-pullable://docker.io/nginx@sha256:b0ad43f7ee5edbc0effbc14645ae7055e21bc1973aee5150745632a24a752661
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sat, 29 Aug 2020 21:26:48 +0900
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/usr/share/nginx/html from mypvc (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-pzg5l (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
mypvc:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: scale-lw-fset-pvc
ReadOnly: false
default-token-pzg5l:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-pzg5l
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m3s default-scheduler Successfully assigned default/csi-scale-dynamicdemo-pod to worker2.pathpilot.local
Normal SuccessfulAttachVolume 2m3s attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-6f729ce5-24f2-4310-aee7-d82f60a73f39"
Normal Pulling 106s kubelet, worker2.pathpilot.local Pulling image "nginx"
Normal Pulled 103s kubelet, worker2.pathpilot.local Successfully pulled image "nginx"
Normal Created 102s kubelet, worker2.pathpilot.local Created container web-server
Normal Started 102s kubelet, worker2.pathpilot.local Started container web-server
[root@localhost yaml]#

web-serverが立ち上がっているとの事なので早速動作確認。

Persistent Volumeに対応するディレクトリがgpfs上で自動で作成されていることを確認。
[root@worker2 ~]# ls /gpfs/gpfsfs01/pvfileset/lwdir
pvc-6f729ce5-24f2-4310-aee7-d82f60a73f39

自前のindex.htmlをそのディレクトリに保存する。
[root@worker2 ~]# ls /gpfs/gpfsfs01/pvfileset/lwdir/pvc-6f729ce5-24f2-4310-aee7-d82f60a73f39
index.html
[root@worker2 ~]# cat /gpfs/gpfsfs01/pvfileset/lwdir/pvc-6f729ce5-24f2-4310-aee7-d82f60a73f39/index.html
Hello World! I Love Scale!!!
[root@worker2 ~]#

ブラウザーで作成したPodのWebサーバー(nginx)にアクセスして、index.htmlが表示されることを確認する。

Scalecsi

以上

Kubernetes テストベンチへの道 その6 Spectrum Scale 5.0.5.2 のインストール

Spectrum Scale Data Management 5.0.5.2をCentOS7.7にインストールする。

Kubernetesのインストールの後での作業。

まずは前さばき作業から。

FirewallとSELINUXの停止

# systemctl stop firewalld
# systemctl disable firewalld
# vi /etc/selinux/config
以下のように行を修正する。
SELINUX=disabled

# setenforce 0

Local DNSへの自分の登録
Local DNSをアクセスするように自分の設定

vi /etc/NetworkManager/NetworkManager.conf
mainセクションにdns=noneを追加する。

[main]
#plugins=ifcfg-rh,ibft
dns=none <<< これを追加

systemctl restart NetworkManager
# vi /etc/resolv.conf

# Generated by NetworkManager
nameserver 192.168.1.250 <<< Local DNSのアドレスを追加する。
nameserver 192.168.1.1

# nmcli c mod ens160 ipv4.dns ""
# systemctl restart NetworkManager
# nmcli d show によってIP4.DNSが消去されていることを確認する。

自分のサーバー名がResolveされることを確認する。
# nslookup snode-1.pathpilot.local
Server: 192.168.1.250
Address: 192.168.1.250#53

Name: snode-1.pathpilot.local ## verify myself is resolved.
Address: 192.168.1.121

NTP同期確認
# systemctl restart chronyd
# timedatectl
VMをサスペンド/リジュームすると同期が止まるので、リジューム後には毎回restartの必要がある。

パスワード無しSSHの構成
自分のところで鍵を作り、その鍵をScale Clusterに参加する自分を含むすべてのノードにコピーする。
# ssh-keygen -t rsa
# ssh-copy-id root@snode-1.pathpilot.local
# ssh-copy-id root@snode-2.pathpilot.local
# ssh-copy-id root@sgui.pathpilot.local
# ssh-copy-id root@worker1.pathpilot.local
# ssh-copy-id root@worker2.pathpilot.local

自分を含む全てのノードにパスワード無しでSSH出来ることを確認する。
# ssh snode-1.pathpilot.local date

Scaleのインストール

スケールモジュールのインストールとビルド
CentOS 7.7の場合、最新のkernel-develを入れるとmmbuildgplがエラーとなるのでベースのレベルにする必要がある。
その為、以下のrpmをCentOSのリポジトリからダウンロードしてインストールする。
# rpm -ihv kernel-devel-3.10.0-1062.el7.x86_64.rpm
それ以外のモジュールは最新を入れる。
# yum -y install cpp gcc gcc-c++ binutils ksh m4

CentPS8の場合はこの問題は起きない(2020年8月時点)ので以下だけの実行でよい。
# yum -y install kernel-devel cpp gcc gcc-c++ binutils ksh m4

# chmod u+x Spectrum_Scale_Data_Management-5.0.5.2-x86_64-Linux-install
# ./Spectrum_Scale_Data_Management-5.0.5.2-x86_64-Linux-install --silent

# cd /usr/lpp/mmfs/5.0.5.2/gpfs_rpms
# rpm -ivh gpfs.adv* gpfs.base*.rpm gpfs.docs*.rpm gpfs.gpl*.rpm gpfs.gskit*.rpm gpfs.msg*.rpm gpfs.license*.rpm gpfs.compression*.rpm gpfs.crypto*.rpm

# export LINUX_DISTRIBUTION=REDHAT_AS_LINUX
# /usr/lpp/mmfs/bin/mmbuildgpl

以降の作業のためにパス設定を行う。
# export PATH=$PATH:/usr/lpp/mmfs/bin
恒久的に設定するために、自分のホームディレクトリ内の.bash_profileを編集し、PATH=$...を追記する。

Scale構成作業

1. Configure Cluster
mmcrcluster
# mmcrcluster -N snode-1.pathpilot.local:quorum-manager,snode-2.pathpilot.local:quorum-manager,sgui.pathpilot.local,worker1.pathpilot.local,worker2.pathpilot.local --ccr-enable -r /usr/bin/ssh -R /usr/bin/scp -C gpfscluster1

2. Apply License
mmchlicense
# mmchlicense server --accept -N snode-1.pathpilot.local,snode-2.pathpilot.local
# mmchlicense client --accept -N sgui.pathpilot.local,worker1.pathpilot.local,worker2.pathpilot.local

3. Start up cluser
mmstartup
# mmstartup -a

4. Edit Stanza file
NSDを定義するStanzaファイルを編集する

ダウンロード - snode1.nsd

5. Create NSD
mmcrnsd
# mmcrnsd -F /root/work/snode1.nsd

6. Create Filesystem
mmcrfs
# mmcrfs gpfsfs01 -F /root/work/snode1.nsd -B 256K -D posix -k all

7. Mount filesystem
mmmount
# mmmount gpfsfs01 -a
# mmlsmount gpfsfs01 -L

以降、実際のコマンド実行記録
[root@localhost gpfs_rpms]# mmcrcluster -N snode-1.pathpilot.local:quorum-manager,snode-2.pathpilot.local:quorum-manager,sgui.pathpilot.local,worker1.pathpilot.local --ccr-enable -r /usr/bin/ssh -R /usr/bin/scp -C gpfscluster1

[root@localhost gpfs_rpms]# mmchlicense server --accept -N snode-1.pathpilot.local,snode-2.pathpilot.local

[root@localhost gpfs_rpms]# mmchlicense client --accept -N sgui.pathpilot.local,worker1.pathpilot.local

[root@localhost gpfs_rpms]# mmlscluster

GPFS cluster information
========================
GPFS cluster name: gpfscluster1.pathpilot.local
GPFS cluster id: 1593904468708199996
GPFS UID domain: gpfscluster1.pathpilot.local
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
Repository type: CCR

Node Daemon node name IP address Admin node name Designation
------------------------------------------------------------------------------------
1 snode-1.pathpilot.local 192.168.1.121 snode-1.pathpilot.local quorum-manager
2 snode-2.pathpilot.local 192.168.1.122 snode-2.pathpilot.local quorum-manager
6 sgui.pathpilot.local 192.168.1.123 sgui.pathpilot.local
7 worker2.pathpilot.local 192.168.1.133 worker2.pathpilot.local
8 worker1.pathpilot.local 192.168.1.132 worker1.pathpilot.local

[root@localhost gpfs_rpms]#

[root@localhost gpfs_rpms]# /usr/lpp/mmfs/bin/mmstartup -a
2020年 8月 24日 月曜日 06:17:18 JST: mmstartup: Starting GPFS ...

[root@localhost gpfs_rpms]# mmgetstate -a

Node number Node name GPFS state
-------------------------------------------
1 snode-1 active
2 snode-2 active
6 sgui active
7 worker2 active
8 worker1 active
[root@localhost gpfs_rpms]#

[root@localhost gpfs_rpms]# cd /root
[root@localhost ~]# mmcrnsd -F /root/work/snode.nsd
mmcrnsd: Processing disk sdb
mmcrnsd: Processing disk sdc
mmcrnsd: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.

[root@localhost ~]# mmcrfs gpfsfs01 -F /root/work/snode.nsd -B 256K -D posix -k all

The following disks of gpfsfs01 will be formatted on node snode-1.pathpilot.local:
NSD_101: size 5120 MB
NSD_102: size 5120 MB
Formatting file system ...
Disks up to size 146.21 GB can be added to storage pool system.
Creating Inode File
Creating Allocation Maps
Creating Log Files
Clearing Inode Allocation Map
Clearing Block Allocation Map
Formatting Allocation Map for storage pool system
Completed creation of file system /dev/gpfsfs01.
mmcrfs: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.

[root@localhost ~]# mmlsfs all
[root@localhost gpfs_rpms]# mmlsfs all
File system attributes for /dev/gpfsfs01:
=========================================
flag value description
------------------- ------------------------ -----------------------------------
-f 8192 Minimum fragment (subblock) size in bytes
-i 4096 Inode size in bytes
-I 16384 Indirect block size in bytes
-m 1 Default number of metadata replicas
-M 2 Maximum number of metadata replicas
-r 1 Default number of data replicas
-R 2 Maximum number of data replicas
-j cluster Block allocation type
-D posix File locking semantics in effect
-k all ACL semantics in effect
-n 32 Estimated number of nodes that will mount file system
-B 262144 Block size
-Q user;group;fileset Quotas accounting enabled
user;group;fileset Quotas enforced
none Default quotas enabled
--perfileset-quota いいえ Per-fileset quota enforcement
--filesetdf はい Fileset df enabled?
-V 23.00 (5.0.5.0) File system version
--create-time Mon Aug 24 06:43:15 2020 File system creation time
-z いいえ Is DMAPI enabled?
-L 4194304 Logfile size
-E はい Exact mtime mount option
-S relatime Suppress atime mount option
-K whenpossible Strict replica allocation option
--fastea はい Fast external attributes enabled?
--encryption いいえ Encryption enabled?
--inode-limit 873856 Maximum number of inodes in all inode spaces
--log-replicas 0 Number of log replicas
--is4KAligned はい is4KAligned?
--rapid-repair はい rapidRepair enabled?
--write-cache-threshold 0 HAWC Threshold (max 65536)
--subblocks-per-full-block 32 Number of subblocks per full block
-P system Disk storage pools in file system
--file-audit-log いいえ File Audit Logging enabled?
--maintenance-mode いいえ Maintenance Mode enabled?
-d NSD_101;NSD_102 Disks in file system
-A yes Automatic mount option
-o none Additional mount options
-T /gpfs/gpfsfs01 Default mount point
--mount-priority 0 Mount priority
[root@localhost gpfs_rpms]#

[root@localhost ~]# mmmount gpfsfs01 -a
2020年 8月 24日 月曜日 06:44:14 JST: mmmount: Mounting file systems ...
[root@localhost gpfs_rpms]# mmlsmount gpfsfs01 -L
File system gpfsfs01 is mounted on 5 nodes:
192.168.1.121 snode-1
192.168.1.123 sgui
192.168.1.122 snode-2
192.168.1.132 worker1
192.168.1.133 worker2
[root@localhost ~]#

以上でScaleのインストールと構成が完了した。

Scale GUIサーバーのインストール

Scale GUIサーバーをインストールする。

cd /usr/lpp/mmfs/5.0.5.2/gpfs_rpms
[root@sgui gpfs_rpms]# yum install gpfs.java-5.0.5-2.x86_64.rpm

cd ../zimon_rpms/rhel7
[root@localhost rhel7]# yum install gpfs.gss.pmcollector-5.0.5-2.el7.x86_64.rpm
[root@localhost rhel7]# yum install gpfs.gss.pmsensors-5.0.5-2.el7.x86_64.rpm

Install the following on GUI node.
[root@sgui gpfs_rpms]# yum install gpfs.gui-5.0.5-2.noarch.rpm
[root@sgui gpfs_rpms]# systemctl start gpfsgui

Scalefirstlgui

GUIにログインするためのユーザーをCLI作成する。
[root@sgui gpfs_rpms]# /usr/lpp/mmfs/gui/cli/mkuser admin -g SecurityAdmin
EFSSG1007A Enter password for User :
EFSSG0225I Repeat the password:
EFSSG0019I The user admin has been successfully created.
EFSSG1000I The command completed successfully.
[root@sgui gpfs_rpms]#

ユーザーを作成した直後のログオン画面。通常画面とはちょっと異なる。
Scaleguilogon

一回上記画面でログインするとそれ以降のログインは普段見慣れた画面になる。
Scaleguilogon2

以上

より以前の記事一覧