« 2020年3月 | トップページ | 2020年5月 »

2020年4月

2020年4月29日 (水)

Google Search Consoleとの連携

Google Search Consoleから見えるようにした。目的はGoogle Searchにホームページをちゃんと認識してもらうため。

まずは以下にGoogleアカウントでログインする。

https://search.google.com/search-console

URLプリフィックスにホームページのアドレスを入れる。このブログの場合はhttp://www.pathpilot.jp/blogになる。
Googlesearchconsole

所有権の確認の中で”その他の確認方法”からHTMLタグを選び、メタタグをコピーする。
Photo_20200429095501

ココログの場合、メニュー右下の設定から”外部連携”を選択する。

Photo_20200429094804
Google Search Console所有権タグにペーストする。確認用の文字列を入力するようになっているけれど、コピーしてきたそのまんまをペーストしても文字列部分だけを自動的に抜き出してくれる。これで保存をクリックする。
Photo_20200429094803
Search Consoleの所有権の確認に戻って”確認”ボタンをクリックすると以下の確認ダイアログが表示される。
Photo_20200429094801

Search ConsoleはメタタグをターゲットURLに埋め込むことができるのそのURLの管理者であるとの判断のもと、この確認を行っているそうだ。

WordPressの場合、外観からテーマエディターに入り、テーマヘッダーの<head>タグの中にコピーする。以下は他のメタタグの後に貼り付けた例。

Photo_20200429100601

以上。

2020年4月29日 (水) ツールの使い方 | | コメント (0)

2020年4月25日 (土)

Google Mapで任意の座標にマーカを設定する

Google Mapで任意の座標にマーカを設定する方法が分かったのでメモ。

マーカを設定したい場所にカーソルを持っていく。以下の図では赤矢印の場所。
Mapa
グレーの小さなマーカが置かれる。ウインドウ上のそのマーカの下あたりに、そのマーカに対して緯度・経度が設定できる最も近い座標が表示される。その座標表示にカーソルを持っていくと、その座標の場所が●で表示される。
Mapb
そのまま、その座標表示をクリックすると最初に地図上にクリックした場所にマーカが設定され、ウインドウ上の左側表示が座標表示に変わる。
Mapc
後は、バーガーアイコンをクリックし、share or embed mapを選んで埋め込むhtmlをコピーする。
Mapd

以上で出来上がり。

 

 

 

2020年4月25日 (土) ツールの使い方 | | コメント (0)

2020年4月24日 (金)

EpocCamを使ってみる

最近WEB会議とかが多くなってきた。

たまにはカメラをイネーブルにしようかと思ったりするんだけれど、MacやPCのスクリーン上部に内蔵されたカメラ位置が好きじゃない。どうしてもドアップになってしまうし、部屋の中のごちゃごちゃが映らないようにするには作業する向きが問題になったりする。だから、なんだかんだ言ってイネーブルにしない。

そんな中で面白いツールを発見。EpocCam。iPhoneをWebカメラにすることができる。iPhoneをクライアント、Mac（またはPC)をサーバーとするP2P構成でiPhoneをカメラデバイスとして使う構成のようだ。

まずAppStoreでEpocCamをダウンロード・インストール。HD版は有料だけれどSD版は無料。

次に www.kinoni.com に行って、自分の環境（MacまたはWindows）のドライバをダウンロード・インストールする。

これだけでつながる。iPhoneとMac間の認証などはない（これは不安）。EpocCamがインストールされたiPhoneが複数ある環境だと、多分選択するんだろうとは思う。逆にMacが複数台あったらどうなるんだろう？？

そもそもWiFi環境が前提だとなると同じネットワークセグメントにいるiPhoneとMacはどれでも繋がるのか？セキュリティ的にものすごく不安を感じるけれども、、、

少なくともiPhone上のEpocCamアプリを閉じればiPhoneのカメラデバイスとしての機能は停止する（P2P通信が切れる）。

注意：インストールした直後ではiPhoneのフロント/リアカメラの切り替えができない。また、数分で通信が切れる。この後、レビューコメントをアップすると、通信が再開しカメラ切り替えもできるようになる。

自分の家の中ではネットワークセグメントは自分のプライベート専用なので問題はないかと思うので、いろいろと試してみる。

また、その背景にあるテクノロジーはWebRTC (Web Real Time Communication）らしい。こっちもいろいろ調べてみたい（2020/4/24現在）。

 

2020年4月24日 (金) ツールの使い方 | | コメント (0)

2020年4月21日 (火)

Google My Mapの使い方

 自分のホームページにGoogle Mapを埋め込みたい。
埋め込むこと自体は難しくないけれど、Google Mapに任意のスポットを登録したい。例えば自分がアップした写真の撮影場所など。で、どうするか。
使うのはGoogle My Map。

Google アカウントでログインする。以下の例ではすでに一つマップを作ってある。新しい地図を作成をクリックすると新しい地図をつくることができる。

Maymap1

既にある地図（ここでは木曽）を選択、あるいは新しい地図の作成を選択すると地図が開かれる。新しい地図の場合はロケーションを絞り込む。ここでは既にある地図を選択する。すると以下の地図が現れる。
Mymap2
ここでは既に”大桑村のポイント”という名前でレイヤが登録されている。レイヤごとにポイントをグループ化でき、レイヤ単位で選択できる。複数のレイヤを登録しても、実際に表示するレイヤを選択できるわけだ。
ここでは森林鉄道鉄橋跡が登録されている。これを選択するとポイントに吹き出しが現れる。この吹き出しはペンアイコン”編集します”を選ぶことで編集することができる。
Mymap3

新しいスポットを追加する場合はマーカーの追加を選ぶ。
Mymap4
マークしたいポイントでクリックすると新しいポイントが作成される。ポイント名と解説を記載して保存をクリックすればOK。
Mymap5
スタイルをクリックするとマーカーのアイコンを変更することができる。
Mymap6
レイヤの追加の右隣りの共有をクリックすると共有するリンクを取得することができる。
Mymap7
このリンクを自分のホームページに埋め込めばよい。
https://drive.google.com/open?id=1U9l_B44_IEb7dfIAev_0A_6mX8nvJhJ3&usp=sharing
このリンクをクリックするとGoogle Mapが立ち上がって、登録したポイントが設定したマーカーで表示される。

ホームページに埋め込む場合は以下を埋め込むとよい（Wordpressの場合はカスタムHTMLで）。上のURLのid=の値を以下URLのmid=にコピーする。
<iframe src="https://www.google.com/maps/d/embed?mid=1U9l_B44_IEb7dfIAev_0A_6mX8nvJhJ3" width="640" height="480"></iframe>

以上。

2020年4月21日 (火) ツールの使い方 | | コメント (0)

2020年4月 6日 (月)

Spectrum Scale - 振り返り

 

振り返り- その1

Protocolノードをインストールした訳だけれど、今回の構成はいろいろと考慮点があるようだ。

まずCES IP。今回CES Groupは2ノードで構成して、それにCES IPを一つ割り当てた。
この構成では、このCES IPはどちらかのノードに固定的に割り当てられているそうだ。つまり、2ノードの内1ノードしかアクセスを受け付けていないことになる（片方は遊んでいる）。そもそもCES Groupを構成した目的が可用性確保であれば、この構成はActive-Standbyとなり、CES IPが割り当てられているノードがダウンした場合、このCES IPは他方のノードに動的に再割当てが行われる。クライアントはCES IPをアクセスしにくるので、これは大変にありがたい。
仮に、通常状態でも2ノードを働かせたい場合はCES IPを2つCES Groupに割り当てればよい。それぞれのノードにCES IPが割り当てられるので、両CES IPを上手くアクセス出来れば負荷分散が可能となる。もちろん片方のノードがダウンすれば両CES IPは生きているノードに片寄される。
ここでの問題は両CES IPを上手くアクセスする方法だが、これはScaleの外で解決してもらう必要がある。外部ロードバランサーやDNS Round Robinなどの利用が想定される。

つまり、Spectrum ScaleにはLoad Balancing機能がない。複数ノードでCES Groupを構成する場合、この部分の考察がないとノード数を増やす意味が薄れる（可用性はあがるけれども）。

2020年4月 6日 (月) ソフトウエア導入 | | コメント (0)

Spectrum Scale - Unified Accessまとめ

Unified Accessのまとめ

ここまでの作業環境を以下にまとめる。

NSD Servers:
snode-0  192.168.1.91
snode-1  192.168.1.92
CES Nodes:
  nfsgroup1   192.168.1.98 (CES IP)　<- NFS access用
    pnode-1     192.168.1.96
    pnode-2     192.168.1.97
  s3group1    192.168.1.108 (CES IP)  <- S3 access用
    pnode-s1    192.168.1.106
    pnode-s2    192.168.1.107
NFS Client:  192.168.1.60
Windows Client (CloudBerry Explorer):  192.168.1.8

ここまでの一連作業による結果を以下にまとめる。

  • OBJにてUnified Accessを構成する場合Policyを指定する。このPolicy名がFileset名に継承される。たとえばPolicy名がunified01ならば、obj_unified01というディレクトリがGPFS Mount Point直下に作成される。
  • このディレクトリ内にOBJによってディレクトリ構造が作られる。以下の例ではbucket01を作成した後の構造。
    obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01
  • このディレクトリ構造はUnified Accessを構成して初めてわかる。なので、既にNFSでExportされているディレクトリに対して、そのディレクトリをそのままOBJでアクセスできるように構成できるわけではない。
  • NFSとの間でUnified Accessを構成したい場合は、NFSでobj_unified01またはそれ以下のディレクトリをExportする。Export方法はこのブログの後半を参照。

以下、Unified Accessの結果確認。

NFSクライアントから見たbucket01ディレクトリ内のファイル。ここではNFSサーバーはobj_unifiedディレクトリをExportしている。Objclient

S3でアクセスしたbucket01の中身。
Cbbucket

 

NFS Exportの手順：

Export前の状態の確認。
[root@s3group1 work]# mmnfs export list
Path Delegations Clients
------------------ ----------- -------
/gpfs/gpfsfs01/nfs NONE *

obj_unified01をNFS Exportに追加する。
[root@s3group1 work]# mmnfs export add /gpfs/gpfsfs01/obj_unified01
mmnfs: The NFS export was created successfully

確認する。
[root@s3group1 work]# mmnfs export list
Path Delegations Clients 
---------------------------- ----------- -------
/gpfs/gpfsfs01/nfs NONE *
/gpfs/gpfsfs01/obj_unified01 NONE *

obj_unified01のアクセスタイプを確認。
[root@s3group1 work]# mmnfs export list --nfsdefs /gpfs/gpfsfs01/obj_unified01

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

アクセスタイプがNONEなので、これをRWに変更。SquashもNO_ROOT_SQUASHに変更。Squashについては過去のブログ を参照。
[root@s3group1 work]# mmnfs export change /gpfs/gpfsfs01/obj_unified01 --nfschange "*(Access_Type=RW,Squash=NO_ROOT_SQUASH)"
mmnfs: The NFS export was changed successfully.

お約束の確認。
[root@s3group1 work]# mmnfs export list --nfsdefs /gpfs/gpfsfs01/obj_unified01

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

[root@s3group1 work]#

以上でNFSサービス上での事前準備は完了。

次にNFSクライアント側での作業と確認。
[root@localhost ~]# mkdir /mnt/objclient
[root@localhost ~]# mount -t nfs 192.168.1.98:/gpfs/gpfsfs01/obj_unified01 /mnt/objclient

ディレクトリを掘り込んでいく。
[root@localhost ~]# ls /mnt/objclient
s17392004030z1device1
[root@localhost ~]# ls /mnt/objclient/s17392004030z1device1
AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf
[root@localhost ~]# ls /mnt/objclient/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf
bucket01
[root@localhost ~]# ls /mnt/objclient/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01
auth-out.txt object01 pnode-s1.txt unified-out.txt
[root@localhost ~]# ls -l /mnt/objclient/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01
合計 25
-rw-rw-rw-. 1 root root 7516 4月 4 09:26 auth-out.txt
-rwxr-xr-x. 1 1001 1001 334 4月 3 17:24 object01
-rwxr-xr-x. 1 nobody nobody 6225 4月 3 18:06 pnode-s1.txt
-rw-rw-rw-. 1 root root 6520 4月 3 23:17 unified-out.txt
[root@localhost ~]#

以上でOBJのbucketをNFSでもアクセス出来ていることが確認できた。

2020年4月 6日 (月) ソフトウエア導入 | | コメント (0)

2020年4月 4日 (土)

Spectrum Scale - OpenStackへの扉 その4

実際にS3でアクセスしてみる

一通りの設定ができたので実際にS3でScaleをアクセスしてみる。

念の為projectを確認する。
[root@s3group1 work]# openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| d297b07b7ef044b3b8c89a2071cdb491 | admin |
| b8f1a4a6c40d4e90bfc7a57ed09674bf | service |
+----------------------------------+---------+

Access KeyとSecret Keyを、project/user = service/user1で取得する。
[root@s3group1 work]# openstack ec2 credentials create --project service --user user1
+------------+-----------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------+-----------------------------------------------------------------------------------------------------------------------------------+
| access | 3095037eb75e4a9cbd9b00cbe2dc7b89 |
| links | {u'self': u'http://s3group1:35357/v3/users/46c2a1e3bbcc418797d85f78725e5881/credentials/OS-EC2/3095037eb75e4a9cbd9b00cbe2dc7b89'} |
| project_id | b8f1a4a6c40d4e90bfc7a57ed09674bf |
| secret | 94e95d72e5fb4580b22e040617e2d663 |
| trust_id | None |
| user_id | 46c2a1e3bbcc418797d85f78725e5881 |
+------------+-----------------------------------------------------------------------------------------------------------------------------------+
[root@s3group1 work]#

取得したKeysは以下の方法で確認することができる。ただし、どのuserのものかはopenstack user listを参照しないとわからない。
[root@s3group1 work]# openstack ec2 credentials list
+----------------------------------+----------------------------------+----------------------------------+----------------------------------+
| Access | Secret | Project ID | User ID |
+----------------------------------+----------------------------------+----------------------------------+----------------------------------+
| 3095037eb75e4a9cbd9b00cbe2dc7b89 | 94e95d72e5fb4580b22e040617e2d663 | b8f1a4a6c40d4e90bfc7a57ed09674bf | 46c2a1e3bbcc418797d85f78725e5881 |
+----------------------------------+----------------------------------+----------------------------------+----------------------------------+
[root@s3group1 work]#

Proxy-server.confのなかのswift3を確認する。
[root@s3group1 work]# mmobj conf list --ccrfile proxy-server.conf --section filter:swift3
use = egg:swift3#swift3
s3_acl = true
allow_no_owner = true
dns_compliant_bucket_names = fales
[root@s3group1 work]#

チェックする理由は以下の通り：IBM KC
Container or objects created using the swift API are not accessible through S3 API when the allow_no_owner configuration flag is set to false in proxy-server.conf. To change this setting, you can use the following command:
# mmobj config change --ccrfile proxy-server.conf --section filter:swift3 --property allow_no_owner --value true
The default value of the allow_no_owner configuration flag is true.

S3curlを使ってS3アクセスを試みる。まずはhttps://github.com/rtdp/s3curlからzipをダウンロードし解凍する。
[root@s3group1 work]# unzip s3curl-master.zip
Archive: s3curl-master.zip
6049d159e9b9af9f47ee235f6ff23b7084d0e7b8
creating: s3curl-master/
inflating: s3curl-master/LICENSE.txt
inflating: s3curl-master/NOTICE.txt
inflating: s3curl-master/README
inflating: s3curl-master/s3curl.pl

READEにならって.3curlを以下内容で作成する。
[root@s3group1 s3curl-master]# vi .s3curl
[root@s3group1 s3curl-master]# cat .s3curl
%awsSecretAccessKeys = (
    # personal account
    user1 => {
        id => '3095037eb75e4a9cbd9b00cbe2dc7b89',
        key => '94e95d72e5fb4580b22e040617e2d663',
    },
);

モードを以下の通り変更。実際、変更していないとs3curlがエラーとなる。
[root@s3group1 s3curl-master]# chmod 0600 .s3curl

実行してみるとDigest/HMAC_SHA1.pmが無いと怒られた。
[root@s3group1 s3curl-master]# ./s3curl.pl --id user1 -- -s http://s3group1:8080/ | xmllint --format -
Can't locate Digest/HMAC_SHA1.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at ./s3curl.pl line 20.
BEGIN failed--compilation aborted at ./s3curl.pl line 20.
-:1: parser error : Document is empty

そこで以下をインストールする。
[root@s3group1 s3curl-master]# yum install perl-Digest-HMAC.noarch -y

実行してみるとエラーになる。なんだろう。。。。
[root@s3group1 s3curl-master]# ./s3curl.pl --id user1 -- -s http://s3group1:8080/ | xmllint --format -
<?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>AccessDenied</Code>
<Message>AWS authentication requires a valid Date or x-amz-date header</Message>
<RequestId>tx732e989c07fd461dbdafe-005e889442</RequestId>
</Error>

ここは本質ではない（Scale S3のテストがしたいだけ）ので、aws cliを試してみる。まずは構成情報の設定から。
[root@s3group1 s3curl-master]# aws configure
AWS Access Key ID [None]: 3095037eb75e4a9cbd9b00cbe2dc7b89
AWS Secret Access Key [None]: 94e95d72e5fb4580b22e040617e2d663
Default region name [None]:
Default output format [None]:

実行すると、こちらもエラーになる。なんだろう。。。。
[root@s3group1 s3curl-master]# aws --endpoint-url http://192.168.1.108:8080 s3 ls s3://bucket01

An error occurred (SignatureDoesNotMatch) when calling the ListObjectsV2 operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.
[root@s3group1 s3curl-master]#

ジタバタしても始まらないので、もうひとつの方法としてWindows PCからCloudBerry S3 Explorerでアクセスしてみた。
Service pointにポート番号8080を付けるのを忘れないように。
Cbcofig
これはうまくいった。
Cbbucket

なんだかすっきりしないけれども、とりあえずS3でScaleがアクセスできることを確認できた。

2020年4月 4日 (土) ソフトウエア導入 | | コメント (0)

Spectrum Scale - OpenStackへの扉 その３

Unified Accessを試してみる（但しNFSとSwift）

Unified Accessが出来るようになった。
しかしFileの世界でのファイル操作はObjectの世界を通らないのでObjectは気が付かない。
つまり、Objectの世界の誰かがFileの世界から行われたファイル操作を見にこないといけない。その視点で操作してみる。

Fileの世界で手元にあったunified-out.txtをObjectのバケットにコピーする。
[root@s3group1 gpfsfs01]# cp /root/work/unified-out.txt obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01
[root@s3group1 gpfsfs01]# ls obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01 -l合計 17
-rwxr-xr-x 1 user1 user1  334  4月  3 17:24 object01
-rwxr-xr-x 1 swift swift 6225  4月  3 18:06 pnode-s1.txt
-rw-r--r-- 1 root  root  6520  4月  3 23:17 unified-out.txt
念の為ファイルのモードを666にしておいた。
[root@s3group1 gpfsfs01]# chmod 666 obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01/unified-out.txt
[root@s3group1 gpfsfs01]# ls obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01 -l合計 17
-rwxr-xr-x 1 user1 user1  334  4月  3 17:24 object01
-rwxr-xr-x 1 swift swift 6225  4月  3 18:06 pnode-s1.txt
-rw-rw-rw- 1 root  root  6520  4月  3 23:17 unified-out.txt
[root@s3group1 gpfsfs01]#

では、バケットの中身をswift側から見てみる。
[root@s3group1 work]# swift list bucket01
object01
pnode-s1.txt
Fileの世界で保存したunified-out.txtが見えない。
でもダウンロードは出来るようだ。実際以下は成功して、uuu.txtとしてダウンロードできた。
[root@s3group1 work]# swift download bucket01 unified-out.txt -o ~/work/temp/uuu.txt
unified-out.txt [auth 0.457s, headers 0.635s, total 0.635s, 0.037 MB/s]

ランチから帰って確認してみるとObjectの世界でもunified-out.txtが確認できた。つまり同期完了。
[root@s3group1 work]# swift list bucket01
object01
pnode-s1.txt
unified-out.txt

Spectrum ScaleにはobjectizerというFunctionがあるそうだ。これは定期的にFileの世界を確認してObjectとの世界との同期を維持する。定期的ということはIntervalがあるということ。このIntervalは、mmobjコマンドで取得できる。
[root@s3group1 work]# mmobj config list --ccrfile spectrum-scale-objectizer.conf --section DEFAULT --property objectization_interval
objectization_interval = 1800
この時間、1800。単位は秒。つまり30分ごとに同期を取ることになる。これは時間が掛かるわけだ。
このIntervalを短くする。ここでは120、つまり2分。これもmmobjコマンドで実行する。
[root@s3group1 work]# mmobj config change --ccrfile spectrum-scale-objectizer.conf --section DEFAULT --property objectization_interval --value 120
念の為の確認。
[root@s3group1 work]# mmobj config list --ccrfile spectrum-scale-objectizer.conf --section DEFAULT --property objectization_interval
objectization_interval = 120

早速確認をしてみる。ファイルの世界で手元にあったauth-out.txtをバケットに保存した。
[root@s3group1 gpfsfs01]# cp /root/work/auth-out.txt obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01
[root@s3group1 gpfsfs01]# chmod 666 obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01/auth-out.txt
[root@s3group1 gpfsfs01]# ls obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01 -l合計 25
-rw-rw-rw- 1 root  root  7516  4月  4 09:26 auth-out.txt
-rwxr-xr-x 1 user1 user1  334  4月  3 17:24 object01
-rwxr-xr-x 1 swift swift 6225  4月  3 18:06 pnode-s1.txt
-rw-rw-rw- 1 root  root  6520  4月  3 23:17 unified-out.txt
[root@s3group1 gpfsfs01]#

直後には反映されていない。
[root@s3group1 work]# swift list bucket01
object01
pnode-s1.txt
unified-out.txt
2分以内に反映された。これならストレスは少ない。
[root@s3group1 work]# swift list bucket01
auth-out.txt
object01
pnode-s1.txt
unified-out.txt
[root@s3group1 work]#

以上でUnified Accessの基本設定は完了だ。

2020年4月 4日 (土) ソフトウエア導入 | | コメント (0)

2020年4月 3日 (金)

Spectrum Scale - OpenStackへの扉 その2

Objectアクセスをためしてみる

OpenStack上のユーザーuser1が無事作成出来た。
このuser1でObject Storageアクセスを試す。

まずはPolicyとしてunified01を作成する。
で、さっそくエラー。

root@s3group1 ~]# mmobj policy create unified01 --enable-file-access
mmobj policy create: The general file-access capability is not enabled.
Usage:
mmobj policy create PolicyName
[-f FilesetName] [-i MaxNumInodes]
{[--enable-compression --compression-schedule CompressionSchedule]}
{[--enable-expiration --expire-at ExpireAt | --expire-after ExpireAfter]}
{[--enable-encryption --encryption-keyfile [--force-rule-append]]}
[--enable-file-access] [--enable-multi-region] [--help]
mmobj policy create: Command failed. Examine previous error messages to determine cause.
[root@s3group1 ~]#
file-access capabilityがEnableになっていないと怒られた。

で、以下を実行。
[root@s3group1 ~]# mmobj file-access enable
[root@s3group1 ~]#
再試行。
[root@s3group1 ~]# mmobj policy create unified01 --enable-file-access
[I] Getting latest configuration from ccr
[I] Creating fileset gpfsfs01:obj_unified01
Attention: the specified maximum number of files (8000000) is too high.
The amount of available disk space allows for a maximum of 1224832 files.
[I] Creating new unique index and building the object rings
[I] Updating the configuration
[I] Uploading the changed configuration
[root@s3group1 ~]#
ちょっと教育的指導メッセージを頂いたが無事完了。policy listを確認する。
[root@s3group1 ~]# mmobj policy list

Index Name Default Deprecated Fileset Functions File System
-----------------------------------------------------------------------------------------------
0 policy-0 yes object_fileset gpfsfs01
17392004030 unified01 obj_unified01 file-and-object-access gpfsfs01
[root@s3group1 ~]#

ここからuser1にて作業を行う。
[root@s3group1 ~]# source openrc_user1
まずはbucketの作成をする。
[root@s3group1 ~]# swift post bucket01 --header "X-Storage-Policy:unified01"
確認。作成されているようだ。
[root@s3group1 ~]# swift list
bucket01
[root@s3group1 ~]#

保存するソースobjectを用意する。とりあえず手元にあったhostsファイルを使ってみる。
[root@s3group1 work]# cp hosts object01
このファイルobject01をバケットbucket01にアップロードしてみる。
[root@s3group1 work]# swift upload bucket01 object01
object01
上手くいったようだ。確認する。
[root@s3group1 work]# swift list bucket01
object01

今度はダウンロードしてみる。ダウンロード先としてtempを作成する。
[root@s3group1 work]# mkdir temp
[root@s3group1 work]# cd temp
[root@s3group1 temp]# swift download bucket01 object01 -o ~/work/temp/object01
object01 [auth 1.084s, headers 1.625s, total 1.625s, 0.001 MB/s]
[root@s3group1 temp]# ls
object01
[root@s3group1 temp]#
上手くいったようだ。

ではFile System上ではどうなっているのか。GPFS Mount Pointを覗いてみる。
[root@s3group1 /]# cd /gpfs/gpfsfs01
新しいディレクトリとしてobj_unified01が作成されている。unified設定する前のOBJ serviceをEnableした時に作られたディレクトリobject_filesetとは別のディレクトリ。作成したポリシー名はここに現れる。
[root@s3group1 gpfsfs01]# ls
ibmobjectizer nfs obj_unified01 object_fileset
このディレクトリの中を掘り込んでみる。
[root@s3group1 gpfsfs01]# ls obj_unified01
s17392004030z1device1
[root@s3group1 gpfsfs01]# ls obj_unified01/s17392004030z1device1
AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf
[root@s3group1 gpfsfs01]# ls obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf
bucket01
[root@s3group1 gpfsfs01]# ls obj_unified01/s17392004030z1device1/AUTH_b8f1a4a6c40d4e90bfc7a57ed09674bf/bucket01 -l
合計 1
-rwxr-xr-x 1 user1 user1 334 4月 3 17:24 object01
[root@s3group1 gpfsfs01]#
今作成したバケットbucket01はここにある。

以上より、FileとObjectのUnifiedは出来上がった。FileとObjectでUnified Accessしたいファイル（オブジェクト）はこのバケットの下に置くことになるのか。。。。

2020年4月 3日 (金) ソフトウエア導入 | | コメント (0)

Spectrum Scale - OpenStackへの扉 その1

OpenStackでユーザーを作成する

Spectrum ScaleでObjectを扱うことを目指すと、OpenStackの扉を開けなければならない。まったくの未知の世界。

Projectってなんだ？
どうやらユーザーグループのことを差すらしい。
以下docs.openstack.orgより転記
OpenStack ユーザーインターフェースとドキュメントでは、ユーザーのグループは プロジェクト または テナント と呼ばれます。これらの用語は同義です。OpenStack Compute の初期実装は独自の認証システムを持ち、プロジェクト という用語を使用していました。認証が OpenStack Identity (Keystone) プロジェクトに移行したとき、ユーザーのグループを参照するために``テナント``という用語が使用されました。このような経緯のため、いくつかの OpenStack ツールはプロジェクトを使用し、いくつかはテナントを使用します。

S3で使用するユーザーをOpenStack上に追加したい。さてどうする。
以下、実際にやったこと。

/var/mmfs/ccrへ移動する。
[root@localhost ccr]# ls
cached ccr.noauth ccr.nodes committed
[root@localhost ccr]# ls -l
合計 8
drwxr-xr-x 2 root root 23 4月 1 13:41 cached
-rw-r--r-- 1 root root 4 4月 1 13:41 ccr.noauth
-rw-r--r-- 1 root root 52 4月 1 13:41 ccr.nodes
drwxr-xr-x 2 root root 6 4月 1 13:41 committed

mmccr fgetにてopenrcをローカル（2つ目のoenrc）に取得する。
[root@localhost ccr]# mmccr fget openrc openrc
fget:1
[root@localhost ccr]#

中身はこんな感じ。
[root@localhost ccr]# cat openrc
# 2020年 4月 1日 水曜日 17:46:46 JST
export OS_AUTH_URL="http://127.0.0.1:35357/v3"
export OS_IDENTITY_API_VERSION=3
export OS_AUTH_VERSION=3
export OS_USERNAME='admin'
export OS_PASSWORD='passw0rd'
export OS_USER_DOMAIN_NAME='Default'
export OS_PROJECT_NAME=admin
export OS_PROJECT_DOMAIN_NAME=Default

#export OS_REGION_NAME="RegionOne"
[root@localhost ccr]#

この認証情報をopenstackコマンド実行に先立ってsourceコマンドで設定する。以後のopenstackコマンドはこの認証情報を使って実行される。
[root@localhost ccr]# source openrc
[root@s3group1 ccr]# openstack user list
+----------------------------------+-------+
| ID | Name |
+----------------------------------+-------+
| 894f7164282e4e45863f9a4fd5109fdb | admin |
| 77d095f60bce4bf59600d8167157429a | swift |
+----------------------------------+-------+

新しいユーザーとしてuser1を作成する。
[root@s3group1 ccr]# openstack user create user1 --password passw0rd
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | 46c2a1e3bbcc418797d85f78725e5881 |
| name | user1 |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+

ユーザー登録されたことを確認。
[root@s3group1 ccr]# openstack user list
+----------------------------------+-------+
| ID | Name |
+----------------------------------+-------+
| 894f7164282e4e45863f9a4fd5109fdb | admin |
| 77d095f60bce4bf59600d8167157429a | swift |
| 46c2a1e3bbcc418797d85f78725e5881 | user1 |
+----------------------------------+-------+
[root@s3group1 ccr]#

このユーザーのProject（いわゆるユーザーグループ）を指定する。ここでは既存のProjectを指定する。で、リストすると。。。
[root@s3group1 ccr]# openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| d297b07b7ef044b3b8c89a2071cdb491 | admin |
| b8f1a4a6c40d4e90bfc7a57ed09674bf | service |
+----------------------------------+---------+
[root@s3group1 ccr]#

Projectとしてserviceを指定することにする。で、user1用の認証情報ファイルを編集する。このファイルの元は上記で取得したopenrc。変更するのはUSERNAMEとPROJECT_NAME、PASSWORDはそのままにしている。
[root@s3group1 ccr]# vi openrc_user1
# 2020年 4月 1日 水曜日 17:46:46 JST
export OS_AUTH_URL="http://127.0.0.1:35357/v3"
export OS_IDENTITY_API_VERSION=3
export OS_AUTH_VERSION=3
export OS_USERNAME='user1'
export OS_PASSWORD='passw0rd'
export OS_USER_DOMAIN_NAME='Default'
export OS_PROJECT_NAME=service 
export OS_PROJECT_DOMAIN_NAME=Default

#export OS_REGION_NAME="RegionOne"

この認証情報ファイルのsourceコマンドで設定する。
[root@s3group1 ccr]# source openrc_user1

user1でopenstackコマンドが実行できることを確認する。
[root@s3group1 ccr]# openstack user list
+----------------------------------+-------+
| ID | Name |
+----------------------------------+-------+
| 894f7164282e4e45863f9a4fd5109fdb | admin |
| 77d095f60bce4bf59600d8167157429a | swift |
| 46c2a1e3bbcc418797d85f78725e5881 | user1 |
+----------------------------------+-------+
[root@s3group1 ccr]#

以下追記：

なぜだかSpectrum Scale Knowledge Centerのコマンドリストにmmccrが無い。
以下のSpectrum Scale Admin Guide によるとmmccrコマンドをfgetプションで使うとCCRに保存されている構成情報ファイルをローカルに読み出せるらしい。
12.Save the restored CCR copy of the keystone.conf to the local location using a command similar to 
mmccr fget keystone.conf /etc/keystone/keystone.conf
Also, update the owner and the group ofthis file using the following command: chown keystone:keystone /etc/keystone/keystone.conf.

sourceコマンドの使い方　参考リンク

以下を叩くと opestackでコマンド実行する場合の認証情報を持ったファイル(opencr)をローカルに取得できる。
# mmccr fget openrc /root/work/openrc
以下をopenstackコマンド実行に先立って叩くことで、それ以降のOpenstackコマンド実行時の認証にこの認証情報が使用される。
# source /root/work/openrc



Keystoneでのユーザー管理方法　IBM KCより


Configuring Keystone administration





  1. Create or select a Keystone project for REST services. You can create a project or use an
    existing project such as the "service" project.     To create a new project, enter the following
    command:
    openstack project create project_nameコピー
    where
    project_name is the name of the new project.
  2. Create or select a user that other users can communicate with for token validation. If you
    create a new user, specify a password for it.     Enter a command like the following one to create a
    user:
    openstack user create user_name --password passwordコピー
    where
    user_name is the user and
    password is the password.
  3. Assign the user an administration role within the project. Enter a command like the following
    one:
    openstack role add --user user_name --project project adminコピー
    where
    user_name is the user and
    project is the project.
Configuring the Keystone administration is complete.

 

2020年4月 3日 (金) ソフトウエア導入 | | コメント (0)

2020年4月 1日 (水)

Scale 5.0.4.3にS3 Objectノードをインストールする

Objectノードを構成する

NFSノードがインストールできたので、Objectノードをインストールする。

ノード構成は以下のとおり。
NSD Servers:
snode-0  192.168.1.91
snode-1  192.168.1.92
CES Nodes:
  nfsgroup1   192.168.1.98 (CES IP)　<- NFS access用
    pnode-1     192.168.1.96
    pnode-2     192.168.1.97
  s3group1    192.168.1.108 (CES IP)  <- S3 access用
    pnode-s1    192.168.1.106
    pnode-s2    192.168.1.107

見ての通り、CES Nodesは2つのGroupに分けて、それぞれをNFS、S3アクセス用に設定する。すべてのCES NodesにはNFSとOBJの両方のProtocol Serviceがインストールされる。CES Nodeに対して選択的にProtocolをインストールすることはできない。

pnode-s1とpnode-s2を新たに用意してClusterに追加する。
[root@snode-0 gpfsfs01]# mmaddnode -N pnode-s1,pnode-s2

2020年  4月  1日 水曜日 13:41:48 JST: mmaddnode: Processing node pnode-s1

2020年  4月  1日 水曜日 13:41:51 JST: mmaddnode: Processing node pnode-s2

mmaddnode: Command successfully completed

mmaddnode: Warning: Not all nodes have proper GPFS license designations.

    Use the mmchlicense command to designate licenses as needed.

mmaddnode: Propagating the cluster configuration data to all

  affected nodes.  This is an asynchronous process.

[root@snode-0 gpfsfs01]#

ライセンスが設定されていないと注意を受けた。
[root@snode-0 gpfsfs01]# mmlsnode

===============================================================================| Warning:                                                                    |
|   This cluster contains nodes that do not have a proper GPFS license        |
|   designation.  This violates the terms of the GPFS licensing agreement.    |
|   Use the mmchlicense command and assign the appropriate GPFS licenses      |
|   to each of the nodes in the cluster.  For more information about GPFS     |
|   license designation, see the Concepts, Planning, and Installation Guide.  |
===============================================================================

GPFS nodeset    Node list
-------------   -------------------------------------------------------
   gpfscluster1     snode-1 snode-0 pnode-1 pnode-2 pnode-s1 pnode-s2

CES NodeはServer Licenseが必要なので、それを設定する。
[root@snode-0 gpfsfs01]# mmchlicense server --accept -N pnode-s1,pnode-s2

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

とりあえず確認。
[root@snode-0 gpfsfs01]# mmlsnode

GPFS nodeset    Node list
-------------   -------------------------------------------------------
gpfscluster1     snode-1 snode-0 pnode-1 pnode-2 pnode-s1 pnode-s2

[root@snode-0 gpfsfs01]#


[root@snode-0 gpfsfs01]# mmlscluster

GPFS cluster information
========================
  GPFS cluster name:         gpfscluster1.snode-0
  GPFS cluster id:           17390685069738965895
  GPFS UID domain:           gpfscluster1.snode-0
  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-0           192.168.1.91   snode-0          quorum-manager
   2   snode-1           192.168.1.92   snode-1          quorum-manager
   3   pnode-1           192.168.1.96   pnode-1          
   4   pnode-2           192.168.1.97   pnode-2          
   5   pnode-s1          192.168.1.106  pnode-s1         
   6   pnode-s2          192.168.1.107  pnode-s2         

[root@snode-0 gpfsfs01]#

cesSharedRootを確認。これが意味を持つのだろうか。後から要確認。
[root@snode-0 gpfsfs01]# 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

現時点でのCES Nodeを確認。
[root@snode-0 /]# mmces node list

Node Number   Node Name   Node Groups   Node Flags   
------------- ----------- ------------- ------------
3             pnode-1     nfsgroup1     none         
4             pnode-2     nfsgroup1     none         

今回新たに追加するpnode-s1とpnode-s2でCESをイネーブルにする。
[root@snode-0 /]# mmchnode --ces-enable -N pnode-s1,pnode-s2

2020年  4月  1日 水曜日 15:07:47 JST: mmchnode: Processing node pnode-s1
The NFS service can not be enabled because it is not installed.
The file /usr/bin/gpfs.ganesha.nfsd was not found.
mmcesop: Command failed. Examine previous error messages to determine cause.
mmchnode: Node pnode-s1 cannot be added to CES.
2020年  4月  1日 水曜日 15:07:49 JST: mmchnode: Processing node pnode-s2
The NFS service can not be enabled because it is not installed.
The file /usr/bin/gpfs.ganesha.nfsd was not found.
mmcesop: Command failed. Examine previous error messages to determine cause.
mmchnode: Node pnode-s2 cannot be added to CES.
mmchnode: Command failed. Examine previous error messages to determine cause.

[root@snode-0 /]#

どうやらNFS serviceのインストールがCES Nodeになる必要条件のようだ。そこで、これら2つのノードにNFSをインストールする。[root@localhost rhel7]# rpm -ihv gpfs.nfs*

準備しています...              ################################# [100%]
更新中 / インストール中...
   1:gpfs.nfs-ganesha-2.7.5-ibm054.05.################################# [ 25%]
   2:gpfs.nfs-ganesha-gpfs-2.7.5-ibm05################################# [ 50%]
   3:gpfs.nfs-ganesha-utils-2.7.5-ibm0################################# [ 75%]
   4:gpfs.nfs-ganesha-debuginfo-2.7.5-################################# [100%]

[root@localhost rhel7]#

再挑戦。
[root@snode-0 /]# mmchnode --ces-enable -N pnode-s1,pnode-s2
2020年  4月  1日 水曜日 16:45:30 JST: mmchnode: Processing node pnode-s1
2020年  4月  1日 水曜日 16:45:33 JST: mmchnode: Processing node pnode-s2
mmchnode: Propagating the cluster configuration data to all
  affected nodes.  This is an asynchronous process.

[root@snode-0 /]#

念の為の確認。
[root@snode-0 /]# mmces node list

Node Number   Node Name   Node Groups   Node Flags   
------------- ----------- ------------- ------------
3             pnode-1     nfsgroup1     none         
4             pnode-2     nfsgroup1     none         
5             pnode-s1                  none         
6             pnode-s2                  none         

[root@snode-0 /]#

今追加2つのCESノードで新たなグループ s3group1を構成する。
[root@snode-0 /]# mmchnode --ces-group s3group1 -N pnode-s1,pnode-s2
2020年  4月  1日 水曜日 16:57:37 JST: mmchnode: Processing node pnode-s1
2020年  4月  1日 水曜日 16:57:37 JST: mmchnode: Processing node pnode-s2
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     nfsgroup1     none         
4             pnode-2     nfsgroup1     none         
5             pnode-s1    s3group1      none         
6             pnode-s2    s3group1      none         

[root@snode-0 /]#

このグループs3group1にCES IPとして192.168.1.108を割り当てる。
[root@snode-0 /]# mmces address add --ces-ip 192.168.1.108 --ces-group s3group1

念の為の確認。
[root@snode-0 /]# mmces address list

Address         Node       Ces Group   Attributes   
--------------- ---------- ----------- ------------
192.168.1.108   pnode-s1   s3group1    none         
192.168.1.98    pnode-2    nfsgroup1   none         

[root@snode-0 /]#

以下の内容でscale_object.repoを作り/etc/yum.repos.dに保存する。
[spectrum_scale]
name=spectrum_scale
baseurl=file:///usr/lpp/mmfs/5.0.4.3/object_rpms/rhel7
enabled=1
gpgcheck=0

OBJパッケージをインストールする。
[root@localhost rhel7]# yum -y install spectrum-scale-object

とりあえず以下の内容でパスワードファイルをつくり、ks-passwordとして/var/mmfs/ssl/keyServ/tmpに保存する。mmobjはパスワードファイルをこのディレクトリから読み出す。

ドキドキしながら以下を実行する。これはどれかのCES nodeで一回実行すればよい。CESノード全体が構成される。
ここで重要なのは既設のfilesetを指定していないところ。
[root@localhost rhel7]# mmobj swift base -g /gpfs/gpfsfs01 --cluster-hostname s3group1 --local-keystone --pwd-file ks-password -i 20000 --enable-s3

mmobj swift base: Validating execution environment.
mmobj swift base: Creating fileset gpfsfs01 object_fileset.
mmobj swift base: Configuring Keystone server in /gpfs/gpfsfs01/nfs/object/keystone.
mmobj swift base: Creating postgres database.
mmobj swift base: Setting cluster attribute object_database_node=192.168.1.108.
mmobj swift base: Validating Keystone environment.
mmobj swift base: Validating Swift values in Keystone.
mmobj swift base: Configuring Swift services.
mmobj swift base: Setting cluster attribute object_singleton_node=192.168.1.108.
mmobj swift base: Uploading configuration changes to the CCR.
mmobj swift base: Configuration complete.
[root@localhost rhel7]#
Defaultでobject_filesetがgpfs mount pointである/gpfs/gpfsfs01の下に作られた。

OBJをイネーブルしようとしたらエラーが出た。
[root@snode-0 /]# mmces service enable OBJ
pnode-s2:  [E] The OBJ service cannot be enabled because it is not installed.
pnode-2:  [E] The OBJ service cannot be enabled because it is not installed.
pnode-s2:  The file /etc/swift/swift.conf was not found.
pnode-s2:  mmcesop: Command failed. Examine previous error messages to determine cause.
mmdsh: pnode-s2 remote shell process had return code 1.
pnode-2:  The file /etc/swift/swift.conf was not found.
pnode-2:  mmcesop: Command failed. Examine previous error messages to determine cause.
mmdsh: pnode-2 remote shell process had return code 1.
pnode-1:  [E] The OBJ service cannot be enabled because it is not installed.
pnode-1:  The file /etc/swift/swift.conf was not found.
pnode-1:  mmcesop: Command failed. Examine previous error messages to determine cause.
mmdsh: pnode-1 remote shell process had return code 1.
mmces service: Command failed. Examine previous error messages to determine cause.
pnode-s1:  Keystone DB: service already stopped.
pnode-s1:  Keystone: service already stopped.
pnode-s1:  Swift: service already stopped.
mmces service enable: Command failed. Examine previous error messages to determine cause.
[root@snode-0 /]#

CESノード全てにOBJをインストールせねばならないようだ。で、以下を他のCESノードに対しても実行する。repoとパスワードファイルのコピーも忘れずに。
# yum -y install spectrum-scale-object

改めて実行。
[root@snode-0 /]# mmces service enable OBJ

mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all
  affected nodes.  This is an asynchronous process.
pnode-s1:  Keystone DB: service already stopped.
pnode-s2:  Keystone DB: service already stopped.
pnode-s1:  Keystone: service already stopped.
pnode-s2:  Keystone: service already stopped.
pnode-2:  Keystone DB: service already stopped.
pnode-2:  Keystone: service already stopped.
pnode-1:  Keystone DB: service already stopped.
pnode-1:  Keystone: service already stopped.
pnode-s1:  Swift: service already stopped.
pnode-s2:  Swift: service already stopped.
pnode-2:  Swift: service already stopped.
pnode-1:  Swift: service already stopped.
pnode-s1:  Version mismatch during upload of proxy-server.conf (1). Retrying.
pnode-s2:  Version mismatch during upload of proxy-server.conf (2). Retrying.
pnode-s2:  Version mismatch during upload of proxy-server.conf (3). Retrying.
pnode-2:  Swift: service succesfully started.
pnode-s2:  Swift: service succesfully started.
pnode-s1:  Swift: service succesfully started.
pnode-1:  Swift: service succesfully started.
pnode-s1:  Keystone DB: service succesfully started.
pnode-s2:  Keystone: service succesfully started.
pnode-s1:  Keystone: service succesfully started.
pnode-1:  Keystone: service succesfully started.
pnode-2:  Keystone: service succesfully started.
[root@snode-0 /]#

上手くいったようだ。念の為の確認。これをNSDサーバーで実行したらエラーになった。CESノードで実行する必要があるようだ。
[root@snode-0 /]# mmces service list -v

Enabled services: NFS OBJ
mmces service: [E] The local node is not a CES node.

mmces service list: Command failed. Examine previous error messages to determine cause.
[root@snode-0 /]#

改めてCESノード上で確認。
[root@localhost rhel7]# mmces service list -v

Enabled services: NFS OBJ
NFS is running
OBJ is running
OBJ:openstack-swift-object-updater           is running
OBJ:openstack-swift-object-expirer           is running
OBJ:ibmobjectizer                        is not running
OBJ:openstack-swift-object                   is running
OBJ:openstack-swift-account                  is running
OBJ:openstack-swift-container                is running
OBJ:memcached                                is running
OBJ:openstack-swift-proxy                    is running
OBJ:openstack-swift-object-replicator        is running
OBJ:openstack-swift-account-reaper           is running
OBJ:openstack-swift-account-auditor          is running
OBJ:openstack-swift-container-auditor        is running
OBJ:openstack-swift-container-updater        is running
OBJ:openstack-swift-account-replicator       is running
OBJ:openstack-swift-container-replicator     is running
OBJ:openstack-swift-object-sof           is not running
OBJ:postgresql-obj                           is running
OBJ:httpd (keystone)                         is running
[root@localhost rhel7]#

いい感じだ。念の為、更に確認。
[root@localhost rhel7]# mmces service list -a

Enabled services: NFS OBJ
pnode-2:  NFS is running, OBJ is running
pnode-1:  NFS is running, OBJ is running
pnode-s1:  NFS is running, OBJ is running
pnode-s2:  NFS is running, OBJ is running
[root@localhost rhel7]#

S3が動いているか確認。
[root@localhost rhel7]# mmobj s3 list
[I] The S3 API is enabled.
[root@localhost rhel7]#

とりあえず、S3が動いているようだ。
今日はここまで。次は実際にS3 APIでアクセスしてみるのだ。

 

 

2020年4月 1日 (水) ソフトウエア導入 | | コメント (0)

« 2020年3月 | トップページ | 2020年5月 »