未解決
Community Manager
•
3.1K メッセージ
2
484
Cluster Configuration export & importってなに？しらべてみました！！
＊こちらの記事は2021年12月に開催された[AskTheExperts]PowerScaleコーデ 2021冬からの内容になります。
Cluster Configuration export & importってなに？
しらべてみました！！
OneFS9.2からCluster Configuration export & import（以下export & importという）機能が新たに追加されたという噂を耳にしました。
export & importって？
この機能の適用範囲って？
想定される用途は？
ライセンス料はかかるの？
いろいろわからないことだらけですねー。
なので調べてみました！
ついでに検証もしてみました！
まずOneFS9.2から実装された export & import機能はOneFSクラスタの構成情報のバックアップを取得し、またそのバックアップデータから、同じクラスタや別のクラスタに対してリストアできる機能のようです。
使用が想定される主な用途は
- バックアップ（構成変更をする前や障害時など）
- クラスタ構築/再構築の工数削減
らしいです！またライセンス料は不要とのことです！
障害が発生した際にクラスタの構成を再構築しなければならない事態や、検証環境でいろいろと試した際などに、クラスタの設定をもとの状態へコマンド一つで簡単に戻せるのが、このexport & importの主な利点のようですね。
我々チームも検証機を用いて日々検証をしているのですが、チームで機器を共有しているので検証用に作った構成を、その度に構築したり壊したり戻したりと正直めんどーだなーと感じていました。
ですが、この export & importを用いれば、自分の構築した設定のバックアップを取得しておいて、次の機会にリストアすれば再構築するコストを削減できますし、元の設定に戻すのも簡単です。検証環境でいろいろなパターンの構成情報をバックアップしておいて、チームで共有もできるので生産性を向上できるのでは？と期待しています。
■ 適用範囲
今回 OneFS9.2にて追加されたexport & importの適用範囲である各種コンポーネントは以下の7つになります。
※今後コンポーネントと言及する際は以下のいずれかを指します。
'http', 'quota', 'snapshot', 'nfs', 'smb', 's3', 'ndmp’
上記コンポーネントの全ての設定を検証できたわけではありませんが、この機能はあくまで OneFS上の各種機能における構成情報に対するexport & importになります。保存されているデータが対象ではないので注意が必要ですね。
またネットワーク設定や認証関連の設定、システムパラメータなどは未対応ですので今後に期待ですね！
■ export & importの操作方法
現状サポートしているインターフェイスは CLI と PAPIになりWebUIは非対応です。
それではCLIの操作方法の説明といっしょに、実際にexport & importという新しい機能を、設定項目のバックアップとリストア機能として用いるという観点から検証してみたいとおもいます！
私が今回の検証で実施した手順の簡単な流れとしては、以下のような手順で検証しています。
「export」→「各コンポーネントの追加や設定変更」→「import」→「リストアされているか確認」
① まず exportを実行してファイルを取得します。
すべての項目の exportを取得する場合
# isi cluster config exports create
あるコンポーネントを指定して取得する場合 (下の例はsnapshotとnfsのみ)
# isi cluster config exports create --components=snapshot, nfs
exports createを実行すると以下の画像のように export idが発行されます
※今回以下で取得したexport idは「node1-20211209034515」になります。
PowerScale OneFS 9.3.0.0
node1-1# isi cluster config exports create
Are you sure you want to export cluster configuration? (yes/[no]): yes
This may take a few seconds, please wait a moment
Created export task 'node1-20211209034515'
② このexportが成功したか失敗したかは、上記の段階ではわかりませんので
以下のコマンドで確認します。
# isi cluster config exports view 対象のexport id
# isi cluster config exports list –-verbose
実際に実行しますと、さきほど発行された export idの結果が以下のように出力されます
※以下は成功例です
node1-1# isi cluster config exports view node1-20211209034515
ID: node1-20211209034515
Status: Successful
Done: ['http', 'quota', 'snapshot', 'nfs', 'smb', 's3', 'ndmp']
Failed: []
Pending: []
Message:
Path: /ifs/data/Isilon_Support/config_mgr/backup/node1-20211209034515
またexportデータに関しては上記にPassの記載があるように、ファイルエクスプローラーの「/ifs/data/Isilon_Support/config_mgr/backup」以下からアクセスして確認できます。
③ それでは無事にexportできていることも確認できましたので、このexportをもとにimportを実行して構成情報のリストアを実施してみたいとおもいます。
importを実行する場合に必要なのが export idです。
以下のimport実行例では先程発行された export id（node1-20211209034515）を用いて、importを実行します。
その際にexport≒バックアップを取得した状態と同じ設定のままでは、import実行後に本当にリストアできたかどうか検証して確認できませんよね。
なので、設定情報に変化をもたせるために予め作っておいたsnapshotなどのコンポーネントの設定を、export後にちょっと変更して、実際 importをしてリストアされるのか検証しました。
※コマンドに関しては先ほど紹介したexportの箇所がimportになっている程度なので割愛します。
node1-1# isi cluster config imports create node1-20211209034515
※importの場合は必ず対象のexport idを指定する必要があります
Are you sure you want to import cluster configuration? (yes/[no]): yes
create時と同様に実行するか確認がされます。
This may take a few seconds, please wait a moment
Created import task 'node1-20211209035644'
import idがここで発行されます。
④ さきほど発行されたimport idでimportが成功したか確認します。
※以下は成功例です。
node1-1# isi cluster config imports view node1-20211209035644
ID: node1-20211209035644
Export ID: node1-20211209034515
Status: Successful
Done: ['http', 'quota', 'snapshot', 'nfs', 'smb', 's3', 'ndmp']
Failed: []
Pending: []
Message:
Path: /ifs/data/Isilon_Support/config_mgr/restore/node1-20211209035644
無事にimportが成功していることが確認できました。
実際の検証ではOneFS9.3 simulatorと弊社の検証環境にあるOneFS9.2.1.3の双方で試したところ、どちらの環境でもexportからのimportに成功しました！
大事な第一歩として、simulatorでも物理Nodeのクラスタ構成でも、OneFS9.2でも9.3でもexport & importは問題なく実行できることがわかりましたので、次はいろいろな角度から検証した結果を共有します。
■ export & import機能の検証
結果の判断が分かりやすい４つのコンポーネントをメインに検証をすすめました。
検証の際のおおまかな流れは以下のようになります
「デフォルトの設定」→「export」→「各コンポーネントの追加」→「各コンポーネントの設定変更」→「import」→「デフォルトの設定に戻っているか確認」
検証した項目は文章にすると冗長になり検証項目と結果がわかりにくので以下表にまとめスポイラで格納しました。
※検証環境はOneFS 9.3 simulatorで実施しています。
| 検証したコンポーネント |
Export実行後に追加・設定したアイテム |
Export実行後に変更した設定項目 |
import (リストア)検証結果 |
| Smb |
SMB共有作成 新規フォルダ自動作成 |
continuous availability timeout を5 minに変更 permission levelをRead-onlyからFull controlに変更
|
・フォルダと共有は維持された ・continuous availability timeoutもpermission levelも 元にリストアされた |
| nfs |
新規ディレクトリ作成 それに対しNFS共有作成 |
NFSv4 no domainの Global setting項目のnfs4を enableを変更 PermissionをRead-onlyに変更 |
・ディレクトリと共有は維持された ・nfs4のenableが外れ元の設定にリストアされた。 |
| snapshot |
あるフォルダを毎日1回 11AMにスケジュール設定 |
Auto-create snapshotsを disableに変更 あるsnapshotのscheduleの Snapshot expiration期間を 1Weekから1Monthに変更 |
・作成したsnapshotのスケジュールは維持された ・Auto-create snapshotsと Snapshot expirationは 元にリストアされた。 |
| quota |
あるフォルダのHard limitを 300GBに設定 その後で500GB等に変更 |
Quota reporteのNumber of scheduled reports retainedを20に、 |
・directory Quota自体は維持 ・Hard limitはリストアされた ・Quota reporteのNumber of scheduled reports retainedは元の10に、取得間隔を週1の日曜日にリストアされた |
表にまとめてみたけど分かりづらいですね。。。
掲載上はたたんで隠しまたので気になる方は参照してください！
気を取り直して、snapshotを例に取り以下の画像で説明しますと。
snapshot設定のパスや、スケジュールに関してはimportによるリストアの対象外でした。
その一方で、たとえば下記画像のようにsnapshot機能自体に対するSetting項目ではimportによるリストの対象でした！
各コンポーネントおよびそれ自体に対する設定(Setting)の項目が対象であるのは間違いないと思います。
しかしその一方で、quota機能の場合ですと、directory quotaで設定したHard limitの容量設定を変更し検証したところ、import実行後には元の設定に戻っていましたので、リストアの対象ということも分かりました。snapshotとquotaで違いがあるようなので、検証の結論を出すにはまだ早そうです。
それに、まだちょっと気になる点がありますよね？
そうです。上記の検証ではexport実行後に各コンポーネントを作成・追加しましたが、削除は実施していません。
SMB共有やsnapshotのスケジュールなど各コンポーネントを削除した場合はどうなのかな？と思いますよね。同じように削除したコンポーネントも削除されたままになるのでしょうか。。。
■検証！追加だけではなく、削除もしてみた
そこでexport後にコンポーネントを削除してみてimportを実施するという手順で検証したところ衝撃の事実が判明しました（私の想像とはちょっと違っていたので、やっぱり検証って大事ですねー）
手順としましては
「各コンポーネントを追加設定しておく」→「export」→「各コンポーネントの設定変更」→「各コンポーネントの削除」→「import」→「各コンポーネントがどうなっているか確認」
結果はといいますと、smbでもnfsでもexport後に削除した共有についてはimportによって共有それ自体もリストアされることが確認されました！
更に、snapshotのスケジュールとdirectory quotaもexport後に削除して、importを実施してみたところ、削除したsnapshotのスケジュールもdirectory quotaそれ自体や設定項目も含めリストアされていました。
■まとめ
これらの結果から、export & importの適用範囲には大きく３つの種類があることが分かりました。
- 各コンポーネントそれ自体
- quotaやSMB共有など
- 各コンポーネントの設定項目
- たとえば各quota内のoft/hard limit、またはSMB共有の個別アクセス権など
- コンポーネント自体に対する設定項目（General Settingなど）
- たとえばquotaのレポート作成間隔や保持数など
上記の結果を踏まえた大まかに結論をまとめますと、以下のことは少なくとも明らかになったとおもいます。
- export後から追加された①に関してはimportによるリストア後に消されず維持される
- export後に削除された①に関してはimportによってリストアされる
（設定項目含めてimportの対象） - ②に関してはバックアップとリストアの対象だが、一部コンポーネントによって違いがある。
（Snapshotのスケジュールは既に設定がされている場合にはリストア対象外である一方で、directory quotaのHard limitの値はリストア対象であった。） - ②に関してコンポーネントが削除からリストアされた場合は、設定されていた項目は、それがexport(バックアップ)実施される直前の設定項目が維持（リストア）される。
- ③に関してはexport & importの対象であり、バックアップされリストアされる。
ドキュメント上ではconfig backupとだけ記載があり、またリストアによって現在ある共有などは消去されないとありましたが、importによって削除された共有などもリストアされるとの記載はなかったので検証って大事なことが身にしみて分かりました！
■ そのほかの利用上の注意点は？
- バージョンアップ中はexport & importは実施できません。
- 検証を様々なパターンで実施していくと、いくつものexport idとimport idが発行され、どれがどの時点でのデータなのかゴチャゴチャになってしまいました。あるexport idが習得された際の構成はどうだったのか。管理のために一覧表などを作成しておくと便利かもしれません
- exportを実行する際に、ライセンスを持っていない項目を含めるとエラーが発生してしまいます
→例えばsnapshotの項目だけをexportする場合を例に取ると、以下の コマンドで解決できます！
# isi cluster config exports create --components=snapshot
createのあとに “--components=任意のコンポーネント”とコマンドを加えればいいだけなので簡単ですね！ - さらに、上記のようにコンポーネントを指定した export の場合は、検証によって判明した大事な注意点があります！
このコンポーネントを指定した export データをもとにリストアする場合には、以下のコマンドのようにリストアする項目を同時に指定あげる必要があります。
指定されたコンポーネントとexport データが合わない場合は importがエラーになります。これで誤ったリストアを避ける仕組みなんですね！# isi cluster config imports create 任意のexport id --components=snapshot
以上です！
いかがでしたか？
OneFSはますます便利になっていきますね。この機能もGUIによるサポートや機能の拡充も予定されているので unstoppableなPowerScaleを今後もよろしくお願いいたします！