ソフトウエア導入

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

以上

2020年8月29日 (土)

Kubernetes テストベンチへの道 その5 Master再インストール

Masterノードの作り方を間違えていた。

kubeadm init時に--pod-network-cidr を指定していなかった。あとkube-flannel.ymlのnet-conf.jsonのNetwork IP設定を間違えていた。

kubeadm resetを実行したけれどもエラーが出てしまってどこまできれいになったか怪しい。後から変なところでハマると悲しいので、masterノードを再インストールした。で、実際に実行した手順。

  1. masterノード上で、workerノードを全部deleteした。
  2. masterノードの再インストール
  3. kubeadm initの実行
  4. workerノードでkubeadm resetの実行。workerノードはmasterノードでDeleteすればMasterとの関係を忘れてくれるかと思ったらそうではなかった。でresetが必要となった。
  5. workerノードでjoinの実行

以上で、スタートにもどった感じ。
では、なかった。

教訓:Resetの後にflannel.1とcni0をDeteleせよ!

このあと以下のエラーの連打に遭遇した。

[root@localhost yaml]# kubectl describe pod csi-scale-staticdemo-pod

・・・省略・・・

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 47m default-scheduler Successfully assigned ibm-spectrum-scale-csi-driver/ibm-spectrum-scale-csi-operator-55555c45c5-mwv9v to worker2.pathpilot.local
Warning FailedCreatePodSandBox 47m kubelet, worker2.pathpilot.local Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "91c235921db5fe2273132e115cb4c071bbdccb1980815c4a4049c7009c01a13e" network for pod "ibm-spectrum-scale-csi-operator-55555c45c5-mwv9v": networkPlugin cni failed to set up pod "ibm-spectrum-scale-csi-operator-55555c45c5-mwv9v_ibm-spectrum-scale-csi-driver" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.1.1/24

どうやらcni0がすでに構成されているよ!と言っているようだ。確かにflannel.1とcni0が既に存在している、というかReset前のが残ったままになっている。

[root@localhost work]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:0c:29:c2:be:18 brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:38:1d brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:38:1d brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:e8:9b:ec:01 brd ff:ff:ff:ff:ff:ff
6: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 6e:fd:57:be:69:71 brd ff:ff:ff:ff:ff:ff
7: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether b2:ab:34:6e:29:22 brd ff:ff:ff:ff:ff:ff
8: veth159ba468@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default
link/ether 5e:c4:42:45:ec:34 brd ff:ff:ff:ff:ff:ff link-netnsid 0

で、以下を実行。

[root@localhost work]# ip link delete flannel.1
[root@localhost work]# ip link delete cni0
[root@localhost work]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:0c:29:c2:be:18 brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:38:1d brd ff:ff:ff:ff:ff:ff
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:bf:38:1d brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:e8:9b:ec:01 brd ff:ff:ff:ff:ff:ff

これで過去をわすれさせて、
[root@localhost yaml]# kubectl describe pod csi-scale-staticdemo-pod はエラー連打がなくなった。


 

以上

2020年8月27日 (木)

PATH設定を変更する

毎回忘れるので備忘録。

export PATH=$PATH:/usr/lpp/mmfs/bin

恒久的に変更するには以下に上記を追記する。

[home directory]/.bash_profile

2020年8月24日 (月)

mmbuildgpl がKilledのわけ

mmbuildgplがエラーで終了した。Killされている。
詳しい人に聞いたらOut Of Memoryとのこと。
早速VMのメモリを倍増したらmmbuildgplは無事終了。なかなか奥が深いぞ。。。。。make[2]: Entering directory `/usr/src/kernels/3.10.0-1062.el7.x86_64'
  LD      /usr/lpp/mmfs/src/gpl-linux/built-in.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/tracelin.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/tracedev-ksyms.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/ktrccalls.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/relaytrc.o
  LD [M]  /usr/lpp/mmfs/src/gpl-linux/tracedev.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/mmfsmod.o
  LD [M]  /usr/lpp/mmfs/src/gpl-linux/mmfs26.o
  CC [M]  /usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o
/bin/sh: line 1: 15901 Killed                  ./tools/objtool/objtool check “/usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o”
make[3]: *** [/usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o] Error 137
make[2]: *** [_module_/usr/lpp/mmfs/src/gpl-linux] Error 2
make[2]: Leaving directory `/usr/src/kernels/3.10.0-1062.el7.x86_64'
make[1]: *** [modules] Error 1
make[1]: Leaving directory `/usr/lpp/mmfs/src/gpl-linux’
make: *** [Modules] Error 1
--------------------------------------------------------
mmbuildgpl: Building GPL module failed at Mon Aug 24 17:39:57 JST 2020.
--------------------------------------------------------
mmbuildgpl: Command failed. Examine previous error messages to determine cause

2020年8月23日 (日)

Spectrum ScaleがCenOS7.7にインストールできない理由

カーネルのバージョン問題がCentOS7.7へのSpectrum Scaleのインストールを阻んでいるようだ。

Spectrum Scaleの導入に先立って以下を実行する必要がある。Kernelのheader.hを参照する必要があるたけだけれど、これが問題を引き起こしているようだ。

# yum install kernel-devel

これを実行することで以下のディレクトリが作られる。
# ls /usr/src/kernels
3.10.0-1127.18.2.el7.x86_64

しかしunameコマンドは違った値を返す。
# uname -r
3.10.0-1062.el7.x86_64

mmbuildgplはunameが返す値と同じ値を期待してBuildを進める。

以下mmbuildgplの出力結果
mmbuildgpl: Building GPL (5.0.4.2) module begins at 2020年 8月 23日 日曜日 11:01:45 JST.
--------------------------------------------------------
Verifying Kernel Header...
kernel version = 31000999 (310001062000000, 3.10.0-1062.el7.x86_64, 3.10.0-1062)
module include dir = /lib/modules/3.10.0-1062.el7.x86_64/build/include
module build dir = /lib/modules/3.10.0-1062.el7.x86_64/build
kernel source dir = /usr/src/linux-3.10.0-1062.el7.x86_64/include
Cannot find a valid kernel header file. One of these files should exist.
 /lib/modules/3.10.0-1062.el7.x86_64/build/include/linux/version.h
 /usr/src/linux-3.10.0-1062.el7.x86_64/include/linux/version.h
 /usr/src/kernels/3.10.0-1062.el7.x86_64/include/generated/uapi/linux/version.h
 /lib/modules/3.10.0-1062.el7.x86_64/build/include/generated/uapi/linux/version.h

期待するディレクトリが無いのでエラーとなる。
とりあえずの対応策として、マニュアルで以下を実行してみる。

# mkdir 3.10.0-1062.el7.x86_64
# cp -r 3.10.0-1127.18.2.el7.x86_64/* 3.10.0-1062.el7.x86_64

# /usr/lpp/mmfs/bin/mmbuildgpl
事前チェックはパスしえmake Worldに進むが、、、、

以下出力結果make[2]: ディレクトリ `/usr/src/kernels/3.10.0-1062.el7.x86_64' に入ります
LD /usr/lpp/mmfs/src/gpl-linux/built-in.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/tracelin.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/tracedev-ksyms.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/ktrccalls.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/relaytrc.o
LD [M] /usr/lpp/mmfs/src/gpl-linux/tracedev.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/mmfsmod.o
LD [M] /usr/lpp/mmfs/src/gpl-linux/mmfs26.o
CC [M] /usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o
In file included from /usr/lpp/mmfs/src/gpl-linux/cfiles.c:61:0,
from /usr/lpp/mmfs/src/gpl-linux/cfiles_cust.c:54:
/usr/lpp/mmfs/src/gpl-linux/kx.c: 関数 ‘reopen_file’ 内:
/usr/lpp/mmfs/src/gpl-linux/kx.c:5743:7: エラー: 関数 ‘file_release_write’ の暗黙的な宣言です [-Werror=implicit-function-declaration]
file_release_write(fP);
^
cc1: some warnings being treated as errors
make[3]: *** [/usr/lpp/mmfs/src/gpl-linux/cfiles_cust.o] エラー 1
make[2]: *** [_module_/usr/lpp/mmfs/src/gpl-linux] エラー 2
make[2]: ディレクトリ `/usr/src/kernels/3.10.0-1062.el7.x86_64' から出ます
make[1]: *** [modules] エラー 1
make[1]: ディレクトリ `/usr/lpp/mmfs/src/gpl-linux' から出ます
make: *** [Modules] エラー 1
--------------------------------------------------------
mmbuildgpl: Building GPL module failed at 2020年 8月 23日 日曜日 11:06:55 JST.

どうやら、インストールした大元のCentOS7.7と後からインストールしたkernel-develのレベルが異なるとCentOS自体がおかしくなる(uname -rが更新したレベルを認識できない)ようだ。

考えられる対策は2つ、いずれもmmbuildgplが正常終了することが確認できた。

  • 1062レベルのkernel-develをインストールする(1062のkernel-devel rpmをダウンロードしてきてインストールする)
  • CentOS7.8をインストールする。

今から古いカーネルレベルにするっていうのも考え物だけれど、Spectrum Scale CSIがRHEL 7.5, 7.6, 7.7までしかサポートしていないので、7.7(1062)で行くってことかなぁ、、、、、

2020年8月22日 (土)

VM間の共有ディスクを作成する

VM間の共有ハードディスクを作成する。これはSpectrum Scale NSD Serverの共有ハードディスクとして使うため。
ここではsnode-1とsnode-2の2ノード(2VM)間に共有ディスクを構成している。

まずsnode-1の設定の編集でディスクの追加を行う。その際重要なのはSCSIアドレス。ブートディスク、つまりこのVM専用のディスクはSCSI (0:0)、すなわちSCSIチャンネル0に割り当てられ、そのチャンネル用のSCSIコントローラに紐づけられる。このチャンネルは共有しないので、共有するディスクは別のSCSIチャンネルに割り当てる必要がある。以下の図ではSCSI(1:0)。このチャンネルをVM間共有チャネルとする。

注意:シックプロビジョニング(Egerzeroed)でディスクを作成すること。シンだと後でVM起動エラーになるらしい。

Photo_20200822103601

ハードディスクの追加をすると、このSCSIチャンネルに対応するSCSIコントローラが現れる。
2
ここではハードディスクを2個追加するので、ハードディスク追加作業を繰り返す。2個めのハードディスクのSCSIアドレスは(1:1) とする。

次に他方のVMであるsnode-2の設定の編集を開き、ハードディスクの追加を行う。ここでは上記作業で作成した既存のハードディスクを選択する。先ほど作った2つのディスクが(1:0)がsnode-1_3.vmdk、(1:1)がsnode-1_4.vmdkになっている。
4

それぞれのvmdkをsnode-1と同じSCSIチャンネルに割り当てる。
5

SCSIバスの共有は物理に設定しておく。書き忘れたけれどsnode-1でも同様に設定しておくこと。
6

以上で、両VM間で共有するハードディスクを構成できる。

 

 

 

 

 

2020年8月15日 (土)

Kubernetesテストベンチへの道 その4 pv作成テストの続き

NFSでPersistent Volumeを作る環境が出来たので早速試行。

[root@master ~]# ls yaml
Minikube oss_27.pdf join kubeadm.txt mypv.yaml nginx-iscsi-pod.yamp storage-class-silver.yaml
canal.yaml kubectl_get_pv_mypv.text mypvc.yaml nginx-pod.yaml
iscsi-claim.yaml kubernetes.repo nfs-claim.yaml pod-httpd.yaml
iscsi-pv.yaml mypod.yaml nfs-pv.yaml rbac.yaml


[root@master ~]# kubectl create -f yaml/nfs-pv.yaml
persistentvolume/pv0001 created

ダウンロード - nfs-pv.yaml

[root@master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv0001 3Gi RWO Recycle Available 13s


[root@master ~]# kubectl create -f yaml/nfs-claim.yaml
persistentvolumeclaim/nfs-claim1 created

ダウンロード - nfs-claim.yaml

[root@master ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nfs-claim1 Bound pv0001 3Gi RWO 11s


[root@master ~]# kubectl apply -f yaml/nginx-pod.yaml
pod/nginx-pod created

ダウンロード - nginx-pod.yaml

[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 28h
nginx-pod 0/1 ContainerCreating 0 14s
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 28h
nginx-pod 1/1 Running 0 21s
[root@master ~]#

注意:ダウンロードしたyamlファイルのファイル名中の"-"が抜けている(ここのBlogのFile Managerの問題??)

この状態でNFSサーバーのExportしてディレクトリーに以下を書き込んだ。
# cat index.html

Hello My World

結果は以下。
Hellomyworld

ちなみにPodのIPアドレスは以下で取得する。
[root@master ~]# kubectl describe pod nginx-pod
Name: nginx-pod
Namespace: default
Priority: 0
Node: worker1/192.168.1.132
Start Time: Fri, 14 Aug 2020 21:36:32 +0900
Labels: <none>
Annotations: Status: Running
IP: 10.96.0.4
IPs:
IP: 10.96.0.4

以上で、Persistent Volumeをテストする環境が出来上がった。

より以前の記事一覧