情報ガイドステーションメニュー
 |
｜ PowerStore検証記 -第4回【Ansibleモジュール】- |
| ~関西若手SEで話題のPowerStoreを触ってみた！~ |
長らくお付き合いいただいた、「PowerStore検証記」もいよいよ最終回となりました！の予定だったのですが、今回記載させていただく検証内容の報告が、想定よりも大分濃い内容となっており、第4回だけで「検証項目・まとめ」を記載すると超大作になってしまうということが判明いたしました。 (短的にまとめたかったのですが、書きたい内容が山盛りでした。。。) そこで、急遽予定を変更し、第4回で記載を予定していた内容を第4回と第5回、第6回の3部に分けることとしました。 〇記載内容 第4回 検証報告【Ansibleモジュール】 第5回 検証報告【データ削減効果4:1保証・NAS機能確認・ディスク拡張】 第6回 まとめ 想定より長編になってしまいましたが、その分有意義な情報を閲覧者の皆様にお伝えできればと思いますので、変わらず閲覧いただけますと幸いです。 始めに前回の振り返りです！ 第3回では、PowerStore- PowerEdgeの接続を行い、検証環境の準備が整いました。 そして今回いよいよ！第1回で検討した「PowerStoreAnsibleモジュール検証」を行っていきます！ ・検証項目ってなんでこれになったんだっけ？ ・今までどんなことをしていたか、忘れてしまったので、振り返りたい！ という方は、是非下記第1回～第3回のPowerStore検証記をご参照ください！ ■第1回【DXインフラWG・PowerStore紹介編】 弊社のDXに対する取り組み内容とPowerStoreの概要について説明します。 ■第2回【PowerStore初期セットアップ編】 初期セットアップの流れや注意点を説明します。 ■第3回【PowerStore – PowerEdge接続編】 サーバとストレージ間を接続し、サーバから確認できるようになるまでを説明します。 おさらいですが、第1回で検討した検証項目は下記の通りです。 検証項目(今回の流れ) 1.PowerStore Ansibleプラグイン解説 2.検証準備 3.Ansible検証 4.まとめ 今回はAnsibleモジュールに関する検証方法や結果と、所感について記載させていただきます。 PowerStore Ansibleモジュール検証 まずは、PowerStore Ansibleモジュールについて検証を行いました！  画像はクリックで拡大できます 今回検証させていただいたPowerStoreでは、本来時間をかけるべきではない反復的な作業を自動化し、構築/運用者の負荷を軽減化が可能な、「Ansibleプラグイン」が準備されています。 その他にも、管理タスクの自動化に向けた「vROプラグイン」、開発環境で主流となってきているコンテナを利用する為の「CSIプラグイン」なども準備されていたりします。 ※詳細な内容は下記を参照ください。 Dell EMCのストレージ自動化と開発者リソース このAnsibleプラグインは、Git-Hub上に公開されており、フリーでインストールすることが可能です。 つまり、Ansibleモジュールを活用することで、構築工数の削減や運用時の負荷軽減のメリットが享受できます。 上記効率化の結果、PowerStore導入を行われるお客様にとって費用削減につながります。 Git-Hub PowerStore Ansibleプラグイン これまでの検証記をご愛読いただいている皆様であればお察しかと思いますが、検証前は「Ansible」の構文の意味を理解できておらず、構築も行ったことはありませんでした。 さらに検証環境構築に時間を取られてしまった私達に残された検証期間は、1週間程度でした。 その時間で対応しきれるのかいささか不安な面もありますが、検証環境を作る時間がかかりすぎて何もできませんでした、というのは問屋が卸しませんということで、急ピッチで準備を進めていきました。 1.PowerStore Ansibleプラグイン解説 始めに、Ansibleについて記載する上で解説が必要なワードがいくつかありますので、それらについて記載しておきます。 これらのワードを理解しておらず、詰まった部分がありましたので、同じようにAnsibleに初めて触れますという方には参考になる部分があるかと思いますので、良ければ閲覧いただけると幸いです。 ※記載されているワードを見て知ってるわ！という方は、読み飛ばしていただければと思います。 ・そもそもAnsibleって？ 単純に「Ansible」というワードでインターネット検索をしてみると、「プロビジョニング、構成管理、アプリケーションのデプロイメント、オーケストレーション、その他多くの IT プロセスを自動化する、オープンソースの IT 自動化エンジンです。」と難しい言葉が並べられています。簡単な例を挙げると、1回行うのは簡単なコマンドや設定も100回行うとなると、作業者側としてはしんどかったり、チェックが漏れることでミスが発生したりします。 そういったことを感じない方でも、「その作業に対する時間」は発生してしまうので、本当に必要な作業に中々着手できない場面が少なからず生まれてしまいます。 まとめると「手動で行っている作業を自動化する為に、準備されているモジュール」みたいなイメージを持ってもらえれば良いかと思います。 ※あくまで個人的な感想ですので、そんなんちゃうわ！という専門家の方々は今回もそう思う人もいるよねとぐっとこらえていただければと思います。 Red Hat Ansibleの基本 ・Playbookについて Ansibleを利用したいとなった時に、命令(どのデータを使用して何を行うのか指定する)をするファイルが必要となります。このファイルは「Playbook」と呼ばれて、YAML形式(ソフトウェアの設定やデータ交換に良く利用されるデータ形式)で記載されています。 基本的には、このPlaybookに設定や使用するモジュール等を記載すれば実行自体は可能なのですが、記載が煩雑になってしまうことがあるので、ホストサーバに関する情報を「Inventory(INI形式)」に記載したりします。 (今回hostsファイルは使用しませんでした。) ・モジュールについて 一般的にAnsibleを利用する際には、Playbookの命令で実行する「モジュール」が必要になります。 「tasks:」に実行するモジュールを記載していきます。 標準使用できるモジュールとして、「yum(インストールを実行するコマンド)」、「shell(シェル上でコマンドを実行)」など200種類にも及ぶモジュールが準備されています。 ・Ansible galaxyとコレクションについて しかし、標準で準備されているモジュールのみで対応できない場合があります。 今回のPowerStoreもそのいい例の一つで、「PowerStoreのボリュームを作成するモジュール」というものは、標準で準備されておりません。ですが、目的に応じてモジュールを自分で作ることができます。(いわゆる自作モジュールというものです。) 調べてみた所、自作モジュールに使用される言語は、一般的に「Python(.py)コード」が良く使われるみたいです。 自動化する仕組みを作りたいが、標準モジュールに対象の機能が無いので自分でイチから開発が必要、というのはAnsibleを利用する敷居を大幅に上げてしまいます。 そういった自作モジュールの開発を極力防ぐ為に、Ansible galaxyという、全国の開発者(企業/個人問わず)が作成した、Ansibleで利用する様々なロール(変数やタスクを抜粋したファイル)やコレクション(モジュール、playbook、ロールをまとめたデータ形式)などを掲載しているサイトがあります。 今回検証を行っているPowerStoreにも「dellemc.powerstore」というコレクションが掲載されています。 以上、Ansibleに関するワード解説でした！ 2.検証準備 ここからは検証を行う為の事前準備です！ Ansibleプラグインを利用する為の基本的な準備の流れについては、先程記載したGit-Hub上に記載いただいていました。 ・ESXi上に仮想マシンを作成 OSはRHEL推奨とのことでしたので、今回はRHEL8.4で作成しました。 仮想マシンの作成は、普段の業務でも行っていたので、特段問題なく作成することができました。  画像はクリックで拡大できます ※あくまでAnsible検証用の仮想マシンなので、容量もそこまで持たせず、構築しました。 ・Ansibleのインストール 続いて仮想マシンにAnsibleをインストールしていきます。 普段Linuxの検証を行う際は、CentOSを使うことが多いので、サブスクリプションの登録に、少し戸惑いましたが、何とか、Ansible ver2.9をインストールすることができました。 
・Ansibleプラグインのインストール 上記の通り、Ansibleプラグインは「https://github.com/dell/ansible-powerstore」に一般公開されています。公開されているフォルダを一括で準備した仮想マシンにインストールする為に、まず自分のGit-Hubアカウントにログインし、「/dell/ansible-powerstore」で検索して表示された画面から、自分のリモートリポジトリに「Fork(複製)」します。  画像はクリックで拡大できます ※右上の「Fork」というボタンを押すだけで簡単に複製できました。 その後、仮想マシンに、gitコマンドをインストールし、 ・yum install git-all Git cloneで仮想マシンのローカルリポジトリへの複製を行いました。 ・git clone https://github.com/<自分のローカルリポジトリ>/ansible-powerstore これで仮想マシンにAnsibleプラグインのインストールが完了しました。 
3. Ansible検証 準備も整ったので、早速検証を行っていきます！ ESXi上に作成した仮想マシン(RHEL)からAnsibleを利用して、ボリュームの自動作成を行います。 合わせて、作成したボリュームに対して、ホストサーバの紐づけを行います。 ※1手動でSCSI設定やホストサーバの設定は行っている状態です。 ※2 NW構成としては、PowerStore-Power Edge間は、VLAN200で接続されている状態です。 構成についての詳細は、第3回で実施していますので、ご参照ください！  画像はクリックで拡大できます 先程仮想マシンの中にインストールしたAnsibleプラグインの中には、以下のようなフォルダやファイルが格納されていました。 ・各種ライセンス(ASL、GPL) ・READMEファイル ・metaデータ ・galaxy.yml(Ansible-galaxyに関する情報) ・docs ・module 「module」というフォルダには、モジュールファイル(Python形式)が21個格納されており、すべてのファイルは、｢dellemc_powerstore_xxxx.py｣という命名がされていました。 xxxxの部分には、「cluster」、「nasserver」、「quota」、「volume」など一般的に良く使われる、機能のファイル名が記載されていました。 今回利用するのは、「dellemc_powerstore_volume.py｣が使われていると考え、中身を確認させていただくと、本当にざっくりとした確認ですが、「サンプルコード」、「変数定義」、「関数定義」について記載されていました。 「docs」フォルダの中には、「samples」というフォルダが準備されておりその中には、9種類の「playbook(YAML形式)」が格納されていました。  画像はクリックで拡大できます これらのファイルの中で、今回検証を行いたいと考えている「ボリュームの自動作成」には、「create_multiple_volumes.yml」が使えるのではないかと考えました。 Git-Hub create_multiple_volumes.yml Ansibleに知見のある方であれば分かるかと思いますが、結論から言うと「複数のボリュームを自動作成する」という目標を達成するのには、実施することは二つだけでした。 それは、「変数への代入」と「コレクションのインストールとパスの指定」です。 〇変数の代入 「create_multiple_volumes.yml」の中にも記載がある、「Vars:」は、Ansibleで利用されている、変数定義です。「Vars:」配下に任意の変数名を記載し、「:」で挟んで、代入する値を記載します。 〇Varsの書き方 Vars: 変数名:代入する値 これを参考にして、記載されている変数に値を代入する必要があります。 〇Vars配下に準備されている変数 array_ip :クラスターIP user :admin(GUIに利用するユーザー) password :設定したPW verifycert :False(証明書認証) vol_name :任意のボリューム名 cap_unit :GB(容量の単位) 始めは、上記代入方法に加えて、Ansibleのファイル構成を理解しておらず、「インベントリファイル」を作成し、思考錯誤していたのですが、調べていくうちに、変数代入は直で入力できるということが分かり、「変数の代入」は問題なく対応することができました。 〇コレクションのインストールとパスの指定 変数代入の記載方法が分かった所で、早速ansible-playbookコマンドを実行したのですが、ずーっと同じエラーが出ていました。 実行コマンド :ansible-playbook create_multiple_volumes.yml 実行結果 :ERROR! couldn’t resolve module/action ‘dellemc_powerstore_volume’. This often indicates a misspelling, missing collection, or incorrect module path. この段階では、コレクションをインストールしておらず、YAMLファイルからすると、「dellemc_powerstore_volume」に関する記載がなく、参照先設定も無いので、当然発生するエラーです。 (後々確認すると、README.mdにインストールが必要と記載されていました。。。) しかし、当時の私達の頭の中に、コレクションのインストールという頭は無く、スペルミスを探していました。 それでも、ほとんどデフォルトの状態で実行していることもあり、スペルミスも発生しにくいと考え、デル・テクノロジーズ株式会社（以下、デル・テクノロジーズ）様に相談させていただいた所、ストレージコミュニティに質問を投稿してみては、いかがでしょうかとご提案いただきました。 〇ストレージコミュニティって？ デル・テクノロジーズの様々な製品に対する、質問が投稿できるデルコミュニティというコミュニティサイトが準備されています。 デルコミュニティ このデルコミュニティは製品毎に分類分けされており、その中にストレージコミュニティというコミュニティサイトが準備されています。 ストレージコミュニティ こちらのコミュニティサイトは、DELL EMCオンラインアカウントを作成すれば、誰でも、無償で質問ができます。 しかも担当者様のお話によると、このコミュニティサイトは回答率が逐次、管理者に確認されており、数日間回答がない質問に対しては、有識者に声がけをして回答を促しているとのことで、利用者からは、良い評価をいただくことが多いとのことまでお聞きできました。藁にもすがる思いで、このストレージコミュニティに質問を投稿させていただいた所、翌日に回答が返ってきました！ 
回答の内容では、担当者様のデモ環境で事象確認をいただき、対応方針と記載内容の指摘まで回答いただけました。 回答内容の中に、「README.md」の中に、「コレクションのインストールに関する記載があります」とのご指摘をいただいたので、「README.md」を見ながら、コレクションのインストールを行いました。 ※インターネット環境に接続できるのであれば、Ansible-galaxy「PowerStore」に記載されている、「ansible-galaxy collection install dellemc.powerstore」でもインストール可能でした。 Ansible-galaxy PowerStore インストール後、代入していた値も編集し、再度実行した所、PowerStore側でストレージが作成されていることを確認しました。(元々のYAMLファイルは100個作成予定だったのですが、動作確認のため2個で実行しました。)  画像はクリックで拡大できます 〇ホストの紐付け ボリュームを自動作成できたので検証成功です！でもよかったのですが、手動でボリュームを作成する際に、ホストサーバを選択する項目があり、設定するとボリューム作成時に登録されているホストサーバと紐づけを行うことができます。 一方で、自動で作成したボリュームでは、ホストの紐付ができていませんでした。 「ボリュームは自動作成できるけど、サーバの紐付は手動でやってください！」は、少しスッキリしない部分があります。 上記に伴い、ホストの紐付も自動化できないか調べてみることにしました。 Ansibleプラグインの中身を調べていると、「module」-「dellemc_powerstore_volume.py」の「EXAMPLES」に、「Create volume and map it to a host」という記載があり、その中で、「host」という要素が記載されていました。(もちろん変数定義の中にも「host」がありました。) Git-Hub dellemc_powerstore_volume.py このEXAMPLESに記載のあった「host」という要素を使ってホスト名を指定(Vars:で任意の変数定義を行い代入)し、「mapping_state: ‘mapped’」を流用してあげれば、ホストの紐付ができるのではないかと考え、実際に検証した所、見事「ボリュームを作成し、ホストを紐づけること」ができました。 (1GBのボリュームも使いづらいかと思い、100GBに変更しました。)  画像はクリックで拡大できます ホストの紐付も含めた最終的な、Playbookは下記の通りとなりました。 ※PW,クラスターIPについては、マスキングしております。 
4.まとめ PowerStore Ansibleプラグインに実際に触れてみた所感について、記載させていただきます。 ・PowerStore Ansibleプラグインについて Git-Hub上に掲載されているファイルはモジュールだけではなく、サンプルコード(Playbook)が9つ準備されていました。このサンプルコードは、構築/運用業務で利用するものも多いので、利便性は高いのではないかと感じました。加えて、モジュール(Pythonコード)内に記載されている、EXAMPLESの内容を参照し、流用することでさらに自動化できる範囲が広がるのではないかと感じました。 ・ストレージコミュニティについて 今回の検証を順調に進めることができたのは、「ストレージコミュニティ」で早期に正確な回答いただけた部分が大きかったと感じています。他社メーカでいうと、ライセンス(+保守費用)を購入している前提で限られた範囲でのサポート回答が基本かと思いますが、実際に構築検証を行われているデル・テクノロジーズ様の内部SE含めた、有識者の意見を広範囲に、無償でお聞きできるサイトがあることは、Ansibleプラグインを利用する上で、大きな優位性になるのではないかと感じました。 (ストレージに限らず、PowerEdge、ノートパソコン等のコミュニティもありますし、最初に記載した、「vROプラグイン」、「CSIプラグイン」を利用する際に、詰まる部分があっても質問できると感じました。) ・検証に対する稼働時間について 今回の「ボリューム自動作成に関する検証」についてかかった総時間は、1.5人日(約12h)程度でした。 Ansibleを使ったことのない未経験者の例でも1.5人日で完了し、下記のメリットを考慮すると、このAnsibleモジュールについて学習することは、非常に費用対効果が高いと言えるのではないかと感じました。 ・Playbook実行のみのため、作成してしまえば専門知識不要 （loopを行う数を変更するだけで、指定した数のボリューム作成が可能） ・大量の単純作業に伴うオペミスの回避 ・Playbookの記載に則り自動で実行されるため、実施中は効率的に別の作業等に割り当てられる ・一度作成したYAMLファイルは他案件に流用可能 以上で、第4回【Ansibleモジュール】は終了となります。 次回は、残りの3つの検証項目「データ削減効果」、「NAS機能」、「ディスク拡張性」に関する検証報告について記載させていただきます。 前回までの記事を読み返したいという方は、下記ご参照ください！ ■第1回【DXインフラWG・PowerStore紹介編】 弊社のDXに対する取り組み内容とPowerStoreの概要について説明します。 ■第2回【PowerStore初期セットアップ編】 初期セットアップの流れや注意点を説明します。 ■第3回【PowerStore – PowerEdge接続編】 サーバとストレージ間を接続し、サーバから確認できるようになるまでを説明します。 【CTCお問い合わせ先】 DXについて検討は行っているものの、何から取り組めばいいか分からない、取り組んでいるもののできているか分からないなどありましたら、お気軽にお問い合わせください。 DXインフラWGのお問い合わせ先は下記になりますので、ご連絡をお待ちしております。 dxinfra-wg@ctc-g.co.jp 2022/01/17
|
タグ: Ansible, PowerStore, ストレージ, パートナー
