こんにちは、キクです。
僕は今現在、NetAppの新しいクラスタ構築業務を任せていただいています。
そんな中でコントローラが一向に起動してこないブートループという事象に遭遇しました。
というわけで、今回は『ONTAP初期構築作業で遭遇したブートループ』をテーマに書いていきたいと思います！
なぜブートループが発生してしまったのか？
どのようにして解消したのか？
などなど、順を追って触れていきたいと思います。
本記事の内容
それでは、よろしくお願いします。
ブートループ発生までに実施した作業
それでは実際にブートループが発生するまでに実施した作業内容を見ていきましょう。
先にお伝えしておきたいのですが、僕はある程度NetAppに触れているとはいえ、物理作業含めた初期構築作業に関して"経験豊富"という訳ではありません。
そのため｢何でそんなことしてるの？｣と思われてしまう手順を踏んでいる場合がありますが、その点はご容赦ください。
1. ラッキングおよび配線
まず初めに実施したのはコントローラとシェルフ(SAS / SATA)のラッキング作業です。
各筐体をラッキングしたら、電源やSASケーブルの配線作業を行いました。
SASケーブルの配線に関してはNetApp公式ドキュメントを参考に実施して、HAペアとなる両コントローラから全シェルフが認識されるように接続しました。
公式：NetAppドキュメントページ
2. 全シェルフ接続状態で起動
次に実施したのが各筐体の起動です。
起動順序は｢シェルフ」→「コントローラ｣の順番で実施しました。
ちなみに、コントローラの起動はシェルフを起動させてから数分間待機してから行いました。
アグリゲートやボリュームはシェルフ上のディスクに作成されるため、シェルフがきちんと起動するまで待ちたかったというのが狙いです。
3. SATAディスク上のアグリゲート削除
各筐体が起動した後、まずはルートアグリゲートがどのディスクに作成されているのかを確認しました。
::> disk showここでの確認としては、｢Container Type｣と｢Container Name｣という項目に注目します。
ルートアグリゲートとして利用されているディスクは、次のような表示になっています。
Container Type：aggregate
Container Name：aggr0_xxここで想定していたのははSASディスクにルートアグリゲートが作成されている状態でした。
しかし、実際に確認してみたらSATAディスクに作成されてしまっていました。
そのため、一旦ルートアグリゲートを削除してから再構築するようにしました。
削除作業はブートメニュー｢(5) Maintenance mode boot.｣でメンテナンスモードを起動した状態で行いました。
※ブートメニューの選択方法は後ほど記載します。
*> aggr offline aggre0_xx
*> aggr destroye aggr0_xxこれでルートアグリゲートは削除されました。
改めて、「disk show」コマンドを実行してルートアグリゲートとして利用されているディスクがないことを確認します。
さらに、余計な情報を残さないためにディスクのオーナー情報も削除しておきました。
*> disk remove_ownershipここまできたら、一旦OS（ONTAP）をシャットダウンしておきます。
*> halt4. SATAシェルフの停止
OS（ONTAP）を停止できたら、次にSATAシェルフを物理的に停止しておきます。
この作業を実施しておくことで、次にOS（ONTAP）を起動したときに再びSATAディスクにルートアグリゲートが作成されてしまうのを回避することができます。
5. コントローラAでブートメニュー(4)を実施
それではいよいよ再構築を実施していきましょう。
ステップ3でONTAPは停止しているので、現在は「LOADER>」というプロンプトが表示されている状態になっています。
そこから起動するためには「boot_ontap」というコマンドを実行します。
LOADER> boot_ontapboot_ontapコマンドを実行すると、起動処理が開始されてブートプロセスがたくさん表示されていきます。
以下の内容が表示されたら、「Ctrl + C」でONTAPのブートメニューにアクセスします。
*******************************
* *
* Press Ctrl-C for Boot Menu. *
* *
*******************************ブートメニューからは、ディスクの初期化を実施するモードや、ノード構成を再起動するモード、ブート デバイスへのノード構成情報のリストアを実施するモードを起動することができます。
具体的には、以下のようなメニューから選択することになります。
(1) Normal Boot.
(2) Boot without /etc/rc.
(3) Change password.
(4) Clean configuration and initialize all disks.
(5) Maintenance mode boot.
(6) Update flash from backup config.
(7) Install new software first.
(8) Reboot node.
(9) Configure Advanced Drive Partitioning.公式情報ではそれぞれのメニューで実施可能な内容は以下になります。
(1)通常のモードでノードをブートする
(2)廃止されており、選択しても何も実施されない
(3)ノードのパスワード(「admin」アカウントのパスワードと同じ)を変更する
(4)ノードのディスクを初期化し、そのノードのルートボリュームを作成する
(5)アグリゲート処理およびディスク保守処理を実行し、アグリゲートおよびディスクに関する詳細情報を取得する
(6)ノードのルートボリュームからPC CompactFlashカードなどのブートデバイスに構成情報をリストアする
(7)ノードに新しいソフトウェアをインストールする
(8)ノードをリブートする
(9)ルート/データパーティショニングまたはルート/データ/データパーティショニング用に設定されたディスクに管理機能
今回は、1回目の起動時に作成されてしまった不要な構成情報を削除した後に、新たにシステムを再構築する必要があります。
そのため「(4) Clean configuration and initialize all disks.」を実行していきます。
このメニューではシステムの初期化と共に、新たにルートアグリゲートとルートボリュームの作成もしてくれます。
ちなみに、SATAシェルフは停止しているので必然的にSASディスクに作成されることになります。
6. クラスタセットアップ(create)
ステップ5で設定情報の初期化が完了したら、改めてクラスタセットアップを実行していきます。
作業自体は1回目と同じ流れで進めていきます。
ただ、コントローラBが起動していない状態で作業しようとしたらセットアップの途中で失敗してしまいました。
具体的には以下の項目で失敗しました。
Do you intend for this node to be used as a single node cluster?表示されたエラーは以下です。
Error: command faild: Creation of auto-cluster LIFs is not complete.
Verify that this node is cabled correctly, and then try operation again.セットアップ時点で疎通が取れないと失敗してしまうように感じられたので、コントローラB側でも｢boot_ontap｣コマンドでONTAPを起動してから作業を進めることにしました。
クラスタが作成できたら、再び「disk show」コマンドでルートアグリゲートの状態を確認していきます。
この段階で無事にSASディスクにルートアグリゲートが作成されていることが確認できました。
･･･良かった。
7. コントローラBをクラスタに参加させようとするも･･･
｢いよいよコントローラBをクラスタに参加させて完了だー！｣
そう思ってコントローラBに繋いでみると、永遠にブート処理がループしていました。
いわゆる｢ブートループ｣というやつです。
ステップ6ではコントローラBで｢boot_ontap｣を実行しただけで、その後の確認は特にしていませんでした。
しかし、いざ繋いでみると全然正常に起動していないという状態だったんです(泣)
ブートループが発生した原因
なぜコントローラBでブートループが発生してしまったのか。
自分でも「なんでだろう」と考えてみると、コントローラAでは実施していてコントローラBでは実施していなかった作業があることに気が付きました。
それはブートメニュー「(4) Clean configuration and initialize all disks.」の実行です。
これを実施しているかしていないかでどのように違ってくるのか。
ブートループ中に表示されるの内容の中に、次のようなものがありました。
WARNING: there do not appear to be any disk attached to the system.
No root volume found.これはつまり起動に必要な情報が入っているのルートボリュームが見つからないということ。
それが原因でブートループが発生しているのではないかと捉えました。
これはあくまで僕の見解ですが、ステップ3でルートアグリゲートは削除したものの、OS（ONTAP）自身はまだそこ(SATAディスク)にルートアグリゲートならびにルートボリュームが存在していると認識しているのではないかと思いました。
あるいはSATAディスクとか関係なく、単純にルートボリュームが存在していないことが原因という可能性も考えられますが・・・。
しかし、初回起動時にはブートループは発生せずにクラスタセットアップ画面が表示されたことを考えると、
やっぱり「〇〇にルートボリュームがある」という情報をコントローラは知っていたのではないでしょうか。
そこを探した結果、ルートボリュームが見つかなくてブートループが発生したと考えるのが自然な気もします。
でも、どちらにせよ「ルートボリュームが存在しない」ということがブートループを発生させてしまっていることの原因であることは分かりました。
ブートループを解消した方法
前項では、ブートループの原因が「ルートボリューム不在」である可能性が高いことを突き止めました。
また、削除したはずのルートボリュームの位置情報をOS（ONTAP）が保持している可能性があることも捨てきれませんでした。
そのため、「ルートボリュームがないこと」「ルートボリュームがある(あった)位置を知っていること」の2点を解消する必要があります。
そこで必要になってくるのが「(4) Clean configuration and initialize all disks.」です。
このメニューで実施される｢Clean configuration｣により「〇〇にルートボリュームがあるだろう」という情報を削除してくれると僕は認識しています。
その情報を削除した上で、新たにルートアグリゲートとルートボリュームを作成すれば、今後の起動処理ではそれらの情報を利用して起動してくれるようになります。
これでようやくブートループの原因となっていた｢No root volume found」の状態は解消され、正常に起動そして構築作業ができるようになりました。
おわりに
いかがだったでしょうか。
今回はブートループの発生および対応について順を追って解説してきました。
長々と書きましたが、結論としては両コントローラでブートメニュー「(4) Clean configuration and initialize all disks.」を実施すれば解消できたということでしたね(笑)
僕自身、今回の作業でルートボリュームのことや起動までの流れについてとても勉強になりました。
その情報を記事に残すことで、少しでも誰かの「気付き」に繋がっていれば嬉しいです。
本記事を最後までお読みいただきありがとうございました。
ではでは！