SeagateのオープンソースSDS CORTXを試す。

#オープンソースSDSのCORTXを試す。

![welcome.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/6758d417-bd92-8f0a-0b7c-5353c0389ba3.png)

HDDベンダーのSeagateが2020年9月に発表したオープンソースのSDS CORTX（コアテックス）を試す。
Githubにソースを公開している100% Open sourceなSDSですが、最初から構築すると大変そうなので、お試し版（？）のVMイメージをデプロイしてみました。


１、OVAファイル(cortx-ova-1.0.1)のダウンロードとデプロイ
２、CORTXの起動と動作確認
３、GUIの設定
４、IAMユーザーの作成
５、オブジェクトのアップロード
６、ステータスチェックとアラート
７、再起動
８、既知の問題

環境
仮想環境で作ったCORTXサーバーに仮想環境のWindowsからデータをアップロードして状態監視するのをゴールとします。

| H/W | OS | Management IP | Data IP|
|:-:|:-:|:-:|:-:|
| Supermicro E300-9D |VMware ESXi6.7  |192.168.3.13 |
| 仮想マシン |CORTX 1.0.1  |192.168.3.14 |192.168.3.16|
| 仮想マシン |WindowsServer2019 ||192.168.3.17|
| ノートPC |Win10  |192.168.3.100 ||

CORTXのgithubに詳しい資料がありますが、プロジェクトごとにドキュメントが分かれているので若干わかりにくいかもしれません。
今回使ったドキュメントは下記です。
メインページ
https://github.com/Seagate/cortx
ダウンロードリンク
https://github.com/Seagate/cortx/releases/tag/VA
基本の設定
https://github.com/Seagate/cortx/blob/main/doc/CORTX_on_Open_Virtual_Appliance.rst
GUIの設定
https://github.com/Seagate/cortx/blob/main/doc/Preboarding_and_Onboarding.rst
クライアントの設定
https://github.com/Seagate/cortx/blob/main/doc/testing_io.rst

# 1、OVAファイルのダウンロードとデプロイ

＊このドキュメントはバージョン1.0.1で作成しましたが、のちに1.0.4でいくつかの変更があり、その部分は追記してあります。

zipファイルをダウンロードして展開するとOVAファイルがあります。
https://github.com/Seagate/cortx/releases/tag/VA
ESXiの仮想マシンの作成から、OVAファイルを選択して進めていくとサクサク進むはずです、が、、

エラー　Unsupported hardware family 'vmx-17'
![cortxerror.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/821243ec-99b6-f871-85d4-1975c97859ea.png)


CORTXはESXi7.0以降を前提に作られているので、私のように6.7でデプロイするとエラーになります。
素直にESXiを新しくするかOVAファイルを編集します。
![OVA.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/09b36e3b-ac15-e486-999d-cd1f8605e5be.png)

vmx-17となっているところを14にするとESXi 6.7でも動きます。
各ESXiのバージョンとvmx-xxのバージョン名はわかりやすい法則は無さそう。
vmx-17 = ESXi7.00
vmx-14 = ESXi6.7
vmx-13 = ESXi6.5
他VMware Fusionのバージョンも細かく分かれているので要チェックです。
https://kb.vmware.com/s/article/1003746

これでヨシ！
あとは数分待ちます。
![2020-09-25 09_48_27-localhost.localdomain - VMware ESXi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/0aeefd4a-5a4f-21b6-48d1-fc5d56cf1dc8.png)



#２、CORTXの起動と動作確認

インストールが終わったらCORTXのVMを起動。
cortx/opensource!で入ってroot権限でホストネームを設定します。

```
$sudo su -
#hostnamectl set-hostname --static --transient --pretty test
#hostnamectl status
```
エラーが無ければいよいよCORTEXサービスを起動します。

```
#sh /opt/seagate/cortx/provisioner/cli/virtual_appliance/bootstrap.sh
```
パッと見エラーがなければ多分OK。
![boot.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/e4a35401-f5d2-3b3d-f61e-42eaa3b84c35.png)
直感的にイケる！という感触。

心配なら下記サービスのステータスをsystemctl statusコマンドで確認します。
rabbitmq-server,elasticsearch,haproxy,s3authserver,sspl-ll,hctl,csm_agent,csm_web

一旦rebootして起動したらhctlコマンドでサービスを起動します。

```
[root@tarotx ~]# reboot
---------------------------------
[root@tarotx ~]# hctl start
2020-10-08 14:28:42: Starting Consul server agent on this node........... OK
2020-10-08 14:28:50: Starting Consul agents on other cluster nodes... OK
2020-10-08 14:28:51: Waiting for the RC Leader to get elected... OK
2020-10-08 14:28:51: Starting Motr (phase1, m0d)... OK
2020-10-08 14:28:54: Starting Motr (phase2, m0d)... OK
2020-10-08 14:28:56: Starting S3 servers (phase3)... OK
2020-10-08 14:28:57: Checking health of services... OK
[root@tarotx ~]#

```
-----------------------------
サービスが動いたらネットワーク関連の設定
外からアクセスできるようにデフォルトで閉まっている80番ポートを開放(Version 1.0.4からは不要かもしれません。)

```
#salt '*' cmd.run "firewall-cmd --zone=public-data-zone --add-port=80/tcp --permanent"
#salt '*' cmd.run "firewall-cmd --reload"
```

ip adでアクセスできるIPアドレスを確認。
今回の環境はDHCPなので下記のように振られています。
ens192　>　管理用ポート　> 192.168.3.14
ens256　>　データ用ポート > 192.168.3.16
![ipad.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/1ecc61da-f0ea-12d5-b2a0-cd1a4de3ed4e.png)

あらかじめ、ens192は管理ポート、ens256はデータ用と決められているようですが、バージョン1.0.4では下記のようになっています。
ens32 - Management IP
ens33 - Public data IP
ens34 - Private data IP (if present)


任意のアドレスを入れる場合はコマンドが必要です。


```
マネージメントネットワーク
#provisioner pillar_set "cluster/srvnode-1/network/mgmt_nw/public_ip_addr" \"192.168.3.14\"
#provisioner pillar_set "cluster/srvnode-1/network/mgmt_nw/netmask" \"255.255.255.0\"
#provisioner pillar_set "cluster/srvnode-1/network/mgmt_nw/gateway" \"192.168.3.1\"
#salt-call state.apply components.system.network.mgmt.public

データネットワーク
#provisioner pillar_set "cluster/srvnode-1/network/data_nw/public_ip_addr" \"192.168.3.16\"
#provisioner pillar_set "cluster/srvnode-1/network/data_nw/netmask" \"255.255.255.0\"
#salt-call state.apply components.system.network.data.public
```
salt-callコマンドの出力
ちゃんと設定出来てます。
![staticip_data.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/3cac2eb8-b1fe-1a51-587f-c5f417b4d06d.png)
念のためip adコマンドでも確認して問題無ければミッションクリア！

-----------------------------

ネットワークの設定が終われば、次は正常に動いているかどうかをS3のテストスクリプトで試します。
ここでNGだとサービスが何かしら動いていないという事になります。
一個一個確認してみてください。
だめならCORTXのSlackで"中の人"に聞くしかないでしょう。
案外レスポンス早いのですごい勢いで助けてくれますよ。

```
#sh /opt/seagate/cortx/s3/scripts/s3-sanity-test.sh 

バージョン1.0.4はこちら
#sh /opt/seagate/cortx/s3/scripts/s3-sanity-test.sh -e 127.0.0.1

~~
*****S3: SANITY TEST SUCCESSFULLY COMPLETED *****
```

正常に終わればCORTEXはちゃんと動いているという事になります。
テスト内容を見ると、s3cmdを使ってアカウントやBucketsを作ってput/get/deleteを一通り行ってすべて消しているようです。
終了画面はこんな感じ。
![s3test.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/600dd329-57c0-12c7-c894-84ed55affa6f.png)
#３、GUIの設定

GUIでCOTEXの状況を見るためには、下記を最低限行う必要があります。
１、管理ユーザーを作る
２、管理ユーザーとシステムの設定・登録
３、IAMユーザーの作成

まずは、管理ユーザーの作成を下記から作成します。
https://<management IP>:28100/#/preboarding/welcome
今回だとhttps\://192.168.3.14:28100/#/preboarding/welcome
![welcome.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/6758d417-bd92-8f0a-0b7c-5353c0389ba3.png)
Startをクリックして、ユーザー名、パスワード、メールアドレスを登録して管理ユーザーを作成します。
注意：https://<management IP>:28100のみでアクセスしてもログイン画面が出ますが、
デフォルトでユーザーは無いので、デフォルトユーザーとパスワードは？？？と調べても出てきません。（経験済み）

ユーザーの作成が終わるとログイン画面になるので、作ったユーザーでログイン
システムネームやSSL（Defaultのまま）、DNS(8.8.8.8)、Search Domain(cortx.test)、NTP(ntp-b.nist.gov)、タイムゾーン(GMT+9時間)
をサクサク設定していくとまたログイン画面まで戻ります。

今作成したユーザーでログイン後、Dashboardが見えると「おおー　できたー！」となりますね。
![dash.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/756b8d4f-87a8-b197-e2c6-bf395eba6f89.png)

#４、IAMユーザーの作成

次にユーザー関連をやっておきます。
S3アカウント作成⇒IAMユーザーの作成という流れ。

まず、Manage画面からS3 accountを作成します。
ここでアクセスキーとシークレットキーが貰えるのでCSVで保存しておきます。
![s3account.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/bf3e0965-b37d-0b87-535d-bc117474d01c.png)

一度ログアウトして今作ったS3アカウントで入りなおします。
すると画面が先ほどとは違うユーザー画面になります。
![IAMuser01.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/a7de1d2c-bd5b-a8ad-3f2c-e882f2bede99.png)

そこで今度はIAM userを作成します。
またアクセスキーとシークレットキーが貰えるのでCSVで保存しておきます。
実際はこのユーザーを使用してファイルのPut/Get/Deleteをする事になります。
![IAMuser02.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/210b99f8-f173-a8f4-6eff-90da46e6336b.png)

#５、オブジェクトのアップロード

さあ、あとはオブジェクトのアップロードです。
Windowsの場合はCyberduckという無料のアップローダーを使えばGUIでドラッグアンドドロップで簡単に操作できます。
Linuxの場合はs3互換のお好きなコマンドs3cmdやaws-cli、mc(minio-client)などで使用が可能です。
Cyberduckの設定例
![cyberduck.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/8c80a412-87c7-f5ce-6a57-045b5323f328.png)
アドレスとキーを入れた後は、フォルダの作成とファイルをドラッグアンドドロップで簡単にアップロードができます。
![cyberduck02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/c4c86727-b727-8a74-73c1-f8b28b60adf1.png)

実際の書き込みをするとDashboardのPerformanceのグラフにリアルタイムでパフォーマンスが表示されます。
![dashboard.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/fb2eae75-d3a1-a66d-a92c-76bea5bd25e4.png)

という事で、とりあえずこれで無事にオブジェクトストレージの構築ができました。



#6、ステータスチェックとアラート

Alert画面は＋マークで掘り下げることができます。
今出ているのは"RAIDが無いよ",”仮想マシンのメモリー容量が変わったよ""Storage容量足りない？”など色々でていて、詳細はコミュニティに聞こう！というスタンス。
![error.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/e7d04eaf-fe3d-733b-e2b7-4ff0d182b219.png)

CORTXは基本的にサーバー＋RAIDが標準構成なので、RAIDが無いよ！というエラー。
![raid missing.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/478729/3aaa41ab-669e-158d-1d36-58b0340d44dd.png)
うん、繋げてないからね。
#7、再起動
CORTEXが動いているVMを再起動する場合の手順は下記のとおりです。

```
#hctl shutdown
[root@tarotx ~]# hctl shutdown                                                  Stopping s3server@0x7200000000000001:0x16 at srvnode-1...
Stopped s3server@0x7200000000000001:0x16 at srvnode-1
Stopping m0d@0x7200000000000001:0xc (ios) at srvnode-1...
Stopped m0d@0x7200000000000001:0xc (ios) at srvnode-1
Stopping m0d@0x7200000000000001:0x9 (confd) at srvnode-1...
Stopped m0d@0x7200000000000001:0x9 (confd) at srvnode-1
Stopping hare-hax at srvnode-1...
Stopped hare-hax at srvnode-1
Stopping hare-consul-agent at srvnode-1...
Stopped hare-consul-agent at srvnode-1
Killing RC Leader at srvnode-1...done
[root@tarotx ~]# shutdown -h now
```
VM起動してrootでログイン

```
[root@tarotx ~]# hctl start
2020-10-08 14:28:42: Starting Consul server agent on this node........... OK
2020-10-08 14:28:50: Starting Consul agents on other cluster nodes... OK
2020-10-08 14:28:51: Waiting for the RC Leader to get elected... OK
2020-10-08 14:28:51: Starting Motr (phase1, m0d)... OK
2020-10-08 14:28:54: Starting Motr (phase2, m0d)... OK
2020-10-08 14:28:56: Starting S3 servers (phase3)... OK
2020-10-08 14:28:57: Checking health of services... OK
[root@tarotx ~]#

```
これで元通り。
のはずですが、s3serverがうまく立ち上がっていない時があり、ユーザーが見えなくなる時があります。
その時はs3authserverを確認してFailだったら立ち上げ直せば大丈夫。

```
#systemctl status s3authserver
#systemctl start s3authserver
```

#8、既知の問題
最後に、
CORTX自体まだリリースしたてなのと、今回使用したVMはあくまで簡易的なお試し版なので、本番運用は想定していないようです。
さらに既知の問題もいくつかあるので、下記から情報を取るといいと思います。
既知の問題　
https://github.com/Seagate/cortx-motr/issues
現時点でLNet Error (Packet too big)が結構出てますがその辺も修正中の様子です。
SLACK
https://cortxcommunity.slack.com