PATHpilotのブログ

まずはNFSノードを構成する

今回構成するScale Clusterは以下のとおり。
NSD Servers:
snode-0: 192.168.1.91
snode-1: 192.168.1.92
NFS Protocol Nodes:
pnode-1: 192.168.1.96
pnode-2: 192.168.1.97
nfsgroup1 (CES IP): 192.168.1.98
なお、NSD ServerとProtocol Nodeはそれぞれ別々のESXiサーバー上にVMとして構成している。

特に確認したいのはFilesetを作らなくてもNFS共有できることの確認。

CESで共有するディレクトリーの設定をする。GPFSのマウントポイントの下にnfsディレクトリを作成し、それをcesSharedRootに設定する。
[root@snode-0 ~]# ls /gpfs/gpfsfs01
[root@snode-0 ~]# mkdir /gpfs/gpfsfs01/nfs

ガイドに従ってクラスターをシャットダウンしてからcesSharedRootの変更を行う。
[root@snode-0 ~]# mmshutdown -a
2020年 3月 26日 木曜日 12:18:56 JST: mmshutdown: Starting force unmount of GPFS file systems
2020年 3月 26日 木曜日 12:19:01 JST: mmshutdown: Shutting down GPFS daemons
2020年 3月 26日 木曜日 12:20:09 JST: mmshutdown: Finished
[root@snode-0 ~]# mmchconfig cesSharedRoot=/gpfs/gpfsfs01/nfs
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.

念の為、確認。
[root@snode-0 ~]# mmlsconfig
Configuration data for cluster gpfscluster1.snode-0:
----------------------------------------------------
clusterName gpfscluster1.snode-0
clusterId 17390685069738965895
autoload no
dmapiFileHandleSize 32
minReleaseLevel 5.0.4.0
ccrEnabled yes
cipherList AUTHONLY
cesSharedRoot /gpfs/gpfsfs01/nfs
adminMode central

File systems in cluster gpfscluster1.snode-0:
---------------------------------------------
/dev/gpfsfs01

クラスターの再起動。
[root@snode-0 ~]# mmstartup -a
2020年 3月 26日 木曜日 17:56:00 JST: mmstartup: Starting GPFS ...

無事に立ち上がったことを確認する。
[root@snode-0 ~]# mmgetstate -a

Node number Node name GPFS state
-------------------------------------------
1 snode-0 active
2 snode-1 active
3 pnode-1 active
4 pnode-2 active
[root@snode-0 ~]#

Protocol NodeにはScale Server Licenseが必要だということが判明した。というか、Scale Clientに何かしらの機能を持たせる場合にはServer Licenseが必要。Server LicenseがないままCESをイネーブルしようとするとエラーになる。
[root@snode-0 ~]# mmchlicense server --accept -N pnode-1,pnode-2

The following nodes will be designated as possessing server licenses:
pnode-1
pnode-2
mmchlicense: Command successfully completed
mmchlicense: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.

ClientにてCESをイネーブルする。
[root@snode-0 ~]# mmchnode --ces-enable -N pnode-1,pnode-2
2020年 3月 30日 月曜日 13:46:19 JST: mmchnode: Processing node pnode-1
2020年 3月 30日 月曜日 13:46:26 JST: mmchnode: Processing node pnode-2
mmchnode: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.

念の為の確認。
[root@snode-0 ~]# mmces node list
Node Number Node Name Node Groups Node Flags
------------- ----------- ------------- ------------
3 pnode-1 none
4 pnode-2 none
[root@snode-0 ~]#

可用性を実装するために、これらのCESノードをグループ化する。グループ名はnfs-group-1で実行。しかし、、、
[root@snode-0 ~]# mmchnode --ces-group nfs-group-1 -N pnode-1,pnode-2
2020年 3月 30日 月曜日 14:45:30 JST: mmchnode: Processing node pnode-1
mmchnode: Invalid group name nfs-group-1
2020年 3月 30日 月曜日 14:45:30 JST: mmchnode: Processing node pnode-2
mmchnode: Invalid group name nfs-group-1
mmchnode: Command failed. Examine previous error messages to determine cause.

いろいろ試してみて、どうやら'-'がNG文字のようだ。以下で実行し直し。
[root@snode-0 ~]# mmchnode --ces-group nfsgroup1 -N pnode-1,pnode-2
2020年 3月 30日 月曜日 14:52:42 JST: mmchnode: Processing node pnode-1
2020年 3月 30日 月曜日 14:52:42 JST: mmchnode: Processing node pnode-2
mmchnode: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
[root@snode-0 ~]#

確認すると2つのCESノードが同じグループに入った。
[root@snode-0 ~]# mmces node list
Node Number Node Name Node Groups Node Flags
------------- ----------- ------------- ------------
3 pnode-1 nfsgroup1 none
4 pnode-2 nfsgroup1 none
[root@snode-0 ~]#

このCESグループ(nfsgroup1)にCES IPを割り当てる。このCES IPはFloating IPとなっていて、Scale内部のポリシーに従ってグループ内のどれかのCESノードにマップされる。CESノードが死んだときにはIPを自動再割当てしてくれるので可用性が確保できる。しかし、、、
[root@snode-0 ~]# mmces address add --ces-ip 192.168.1.98 --ces-group nfsgroup1
Cannot resolve 192.168.1.98; Name or service not known
mmces address add: Incorrect value for --ces-ip option
Usage:
mmces address add [--ces-node Node] [--attribute Attribute] [--ces-group Group]
{--ces-ip {IP[,IP...]}

mmces address add: Command failed. Examine previous error messages to determine cause.
エラーになる。IPアドレスがresolveできない？？？これはなんだ？どうやら、ここで使うIPアドレスはhostnameと紐付けされていなければならないそうだ。そこで、/etc/hostsに以下を追記した（Cluster内のすべてのNodeで実行した）。参考情報：IPアドレスのResolveについて
192.168.1.98 nfsgroup1

この後再実行。
[root@snode-0 ~]# mmces address add --ces-ip 192.168.1.98 --ces-group nfsgroup1

エラーメッセージ無しで戻ってきた。念の為の確認。
[root@snode-0 ~]# mmces address list
Address Node Ces Group Attributes
-------------- --------- ----------- ------------
192.168.1.98 pnode-2 nfsgroup1 none
[root@snode-0 ~]#

次に認証方式の定義。
[root@snode-0 ~]# mmuserauth service create --data-access-method file --type userdefined

Executing command on pnode-1

File authentication configuration completed successfully.

NFSサービスをEnableにする。
[root@snode-0 ~]# mmces service enable NFS
pnode-2: Redirecting to /bin/systemctl start nfs-ganesha.service
pnode-1: Redirecting to /bin/systemctl start nfs-ganesha.service
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
affected nodes. This is an asynchronous process.
pnode-2: NFS: service succesfully started.
pnode-1: NFS: service succesfully started.

表示内容を読む限りNFS Serviceはスタートしたみたい。これでは、すべてのCESノードでNFSがスタートしてしまう。本当はStartはNode選択的に行いたかった。CESノードのうち半数はNFS、のこりはObjectと、振り分けを考えているから。
念の為service startも実行してみる。やはりalready running....CESノードに選択的にサービススタートする方法を考察する必要がある。

追記：特定のCESノードを特定のプロトコルのみで構成する方法は現在は無いらしい（専門家に確認）

[root@snode-0 ~]# mmces service start NFS -N pnode-1,pnode-2
pnode-2: NFS: service already running.
pnode-1: NFS: service already running.

先に作成し共有宣言したdirectoryをExportする。
[root@snode-0 ~]# mmnfs export add /gpfs/gpfsfs01/nfs
mmnfs: The NFS export was created successfully
mmnfs: Restarting NFS services.

念の為の確認。
[root@snode-0 ~]# mmces service list -a
Enabled services: NFS
pnode-2: NFS is running
pnode-1: NFS is running
[root@snode-0 ~]# mmuserauth service list
FILE access configuration : USERDEFINED
PARAMETERS VALUES
-------------------------------------------------

OBJECT access not configured
PARAMETERS VALUES
-------------------------------------------------

[root@snode-0 ~]# mmnfs export list

Path Delegations Clients
------------------ ----------- -------
/gpfs/gpfsfs01/nfs NONE *

[root@snode-0 ~]#

アクセスタイプをRWに設定する。こうしないとNFSクライアントからアクセスできない（access denied）。まずは現状確認。
[root@snode-0 gpfsfs01]# mmnfs export list --nfsdefs /gpfs/gpfsfs01/nfs

Path Delegations Clients Access_Type Protocols Transports Squash Anonymous_uid Anonymous_gid SecType PrivilegedPort DefaultDelegations Manage_Gids NFS_Commit Pseudo Path
------------------ ----------- ------- ----------- --------- ---------- ----------- ------------- ------------- ------- -------------- ------------------ ----------- ---------- ------------------
/gpfs/gpfsfs01/nfs NONE * NONE 3,4 TCP ROOT_SQUASH -2 -2 SYS FALSE NONE FALSE FALSE /gpfs/gpfsfs01/nfs

以下を実行する。参考情報：NFS Mount時の問題について
[root@snode-0 gpfsfs01]# mmnfs export change /gpfs/gpfsfs01/nfs --nfschange "*(Access_Type=RW,Squash=NO_ROOT_SQUASH)"
mmnfs: The NFS export was changed successfully.

念の為の確認。
[root@snode-0 gpfsfs01]# mmnfs export list --nfsdefs /gpfs/gpfsfs01/nfs

Path Delegations Clients Access_Type Protocols Transports Squash Anonymous_uid Anonymous_gid SecType PrivilegedPort DefaultDelegations Manage_Gids NFS_Commit Pseudo Path
------------------ ----------- ------- ----------- --------- ---------- -------------- ------------- ------------- ------- -------------- ------------------ ----------- ---------- ------------------
/gpfs/gpfsfs01/nfs NONE * RW 3,4 TCP NO_ROOT_SQUASH -2 -2 SYS FALSE NONE FALSE FALSE /gpfs/gpfsfs01/nfs

[root@snode-0 gpfsfs01]#

NFSクライアントからアクセスしてみる。
#mkdir /mnt/nfsclient
# mount -t nfs 192.168.1.98:/gpfs/gpfsfs01/nfs /mnt/nfsclient

無事NFSマウントが成功した。おつかれ。

参考情報：NFSパラメータについて 　以下参考情報より転記。
Squashについて
root_squash: uid/gidが0、つまりrootユーザからのリクエストをanonymousに格下げ（squash）する。デフォルト有効で無効にするにはno_root_squashを指定する。
all_squash: root以外のユーザからのリクエストもanonymousに格下げ（squash）する。デフォルトはno_all_squash

Unified Accessテスト用のScaleを構成する

投稿時点での最新版 5.0.4.3をインストールしてみる。

5.0.3.xではなかったm4に依存関係があって、gpfs関連rpmのインストールができなかった。
なので以下を追加で実行。
# yum -y install m4
インストールされたのは以下のrpm
m4-1.4.16-10.el7.x86_64.rpm

rpm -ihv gpfs.adv* gpfs.base* gpfs.docs* gpfs.gpl* gpfs.gskit* gpfs.msg* gpfs.license* gpfs.crypto*

m4とは（http://www.bnote.net/linux/compile.shtml より）
マクロを処理するための処理系。 マクロ命令を使って記述されたプログラムやテキスト列などを展開して、 マクロ命令を含まない形のテキストなどに変換する。 マクロ命令をパラメータに基づいて展開したり、条件分岐などを評価して 状況に応じたコードだけを選択して展開したりする。

GPFSを立ち上げようとしてmmstartupを叩いたら、エラーの連打に遭遇。どうやらkernel extensionが期待する場所で見つからないらしい。
[root@snode-1 ~]# mmstartup -a
2020年 3月 25日 水曜日 18:21:10 JST: mmstartup: Starting GPFS ...
snode-1: mmremote: startSubsys: The /lib/modules/3.10.0-1062.el7.x86_64/extra/mmfslinux.ko kernel extension does not exist. Use mmbuildgpl command to create the needed kernel extension for your kernel or copy the binaries from another node with the identical environment.
snode-1: mmremote: startSubsys: Unable to verify kernel/module configuration.
mmdsh: snode-1 remote shell process had return code 1.
mmdsh: snode-0 remote shell process had return code 1.
pnode-2: mmremote: startSubsys: The /lib/modules/3.10.0-1062.el7.x86_64/extra/mmfslinux.ko kernel extension does not exist. Use mmbuildgpl command to create the needed kernel extension for your kernel or copy the binaries from another node with the identical environment.
pnode-2: mmremote: startSubsys: Unable to verify kernel/module configuration.
mmdsh: pnode-2 remote shell process had return code 1.
pnode-1: mmremote: startSubsys: The /lib/modules/3.10.0-1062.el7.x86_64/extra/mmfslinux.ko kernel extension does not exist. Use mmbuildgpl command to create the needed kernel extension for your kernel or copy the binaries from another node with the identical environment.
pnode-1: mmremote: startSubsys: Unable to verify kernel/module configuration.
mmdsh: pnode-1 remote shell process had return code 1.
snode-0: mmremote: startSubsys: The /lib/modules/3.10.0-1062.el7.x86_64/extra/mmfslinux.ko kernel extension does not exist. Use mmbuildgpl command to create the needed kernel extension for your kernel or copy the binaries from another node with the identical environment.
snode-0: mmremote: startSubsys: Unable to verify kernel/module configuration.
mmstartup: Command failed. Examine previous error messages to determine cause.
[root@snode-1 ~]#

mmstartupが探しに行っている/lib/modulesを見るとKernel extesonが入っているディレクトリー名が違っている。どうやらインストーラが作ったディレクトリ名が期待値になっていないようだ(1062.18.1.el7となっている）。そこで、そのディレクトリ内の/extraディレクトリー内のkernel extensionを1062.el7/extra下にコピーした。
[root@snode-1 ~]# ls /lib/modules -l
合計 4
drwxr-xr-x. 3 root root 19 3月 25 15:06 3.10.0-1062.18.1.el7.x86_64
drwxr-xr-x. 7 root root 4096 2月 11 18:36 3.10.0-1062.el7.x86_64
[root@snode-1 ~]#

コピーしたkernel extensionファイル。
[root@snode-1 ~]# ls /lib/modules/3.10.0-1062.18.1.el7.x86_64/extra -l
合計 4432
-rw-r--r--. 1 root root 3780664 3月 25 15:06 mmfs26.ko
-rw-r--r--. 1 root root 675880 3月 25 15:06 mmfslinux.ko
-rw-r--r--. 1 root root 72568 3月 25 15:06 tracedev.ko
[root@snode-1 ~]#

ここまでやってmmstartupが正常終了した。

備忘録
手順：
1. Google Mapでストリートビュー表示
2. 画面左上の三つボタンをクリックして画像を共有または埋め込むを選択
3. 地図を埋め込むを選んで、HTMLをコピー
4. WordPressのブロック、カスタムHTMLを選んで、そこにコピー
以上

WordPressテーマ、Cocoonに挑戦。

以下、ちょっと悩んだ点の備忘録。

親テーマと子テーマ
cocoon本体（親テーマ）のほかにcocoon子テーマがある。親テーマだけで動くわけだけれど、親テーマで構成変更を行うと変更前に戻ることはできない（構成情報が上書きされる）。そんなときは子テーマを使うと安心。子テーマは親テーマのサブセットで、それ単独では動作できないけれど、親テーマの構成を残したまま構成変更したテーマを作成できる。構成を2パターン持って使い分けたいときに便利なんだろう。

吹き出し
Cocoon設定で吹き出しを選び、自分用の吹き出しを定義。
プラグインTinyMCE Advancedをインストールして有効化（これがどの程度必要かよくわからないけれど、入れてみた）。
ブロック追加メニューのCocoonブロックの吹き出しが使えるようになる。
ブロックメニューで定義した吹き出しを選ぶと、そこで設定した顔アイコンが使えるようになる。

タイムライン
ブロック追加メニューでCocoonブロックを選んで、タイムラインを選択。
タイムラインブロックを選んで、ブロックメニューからアイテム数を設定するとタイムライン項目がその数分増える。

いろいろいじってみたけれど、FlayMagに比べてというか、段違いに多機能で使い方によってはとてもクールなページが作れるとの印象あり。

なので、トライアル用の以下もFlayMagからcocoonにテーマ変更実施。
In and Out

スキン
現在の選択
pathpilot.net -> Veilnui Simplog (teal)
pathpilot.sunnyday.jp -> tecrio mango