Azure LocalでiSCSI接続をロールバック

接続が永続的なのに、いきなりDisconnect-IscsiTargetを実行してはまりました。

外部ストレージ アレイを Azure Local に接続する の 手順 7: SAN ディスクを確認する からのロールバックを開始しました。

手順 5: iSCSI ターゲットに接続する (iSCSI のみ) だからDisconnect-IscsiTargetでよいだろうと、2ノードともに実施しました。

別のiSCSIターゲットからディスクを追加したところ、Disconnect-IscsiTargetで切断したはずのディスクも見えます。

PowerShellでPersistent接続にしたディスクを解除する方法が見当たらない（正確には切断の手順誤りで、Unregister-IscsiSessionを実施すべきと後からわかりました）。

生成AIを駆使してみたところ、Unregister-IscsiSessionを実施すべきと出たので実施したものの後の祭り。

その後も生成AIを使いながら、試行錯誤しました。該当のiSCSIターゲットに絞ってセッションを改めて特定。

途中で、4と5が該当ディスクでしたので、改めてGet-Diskにて情報を採取しました。

各々のディスクからパーティション情報を取得したところ、ここでドライブレターがあることを認識しました。

MPIO周りの情報を見ておきます。

各々のディスクをオフラインにします。

再度iSCSIセッション情報を取得します。

iscsicli ListPersistentTargetsにて、Persistent Targetを確認します。

iscsicli RemovePersistentTarget ROOT\ISCSIPRT\0000_0 "iqn.1991-05.com.microsoft:pet440-pet440-iscsitarget-target" 12 192.168.3.8 3260

にてiSCSIターゲットとの永続的な接続を切りました。

確認したところもう一つのほうがあります。

これも同じように削除しておきます。

iscsicli RemovePersistentTarget ROOT\ISCSIPRT\0000_0 "iqn.1991-05.com.microsoft:pet440-pet440-iscsitarget-target" 13 192.168.3.8 3260

全iSCSIセッション情報を取得します。

各セッションをセッションをLogoutします。

ということで、同じ手順でもう片系ノードもロールバックを実施しました。。。

Azure Local 2606でiSCSI接続

都合により今回は、Azure Local 2606でiSCSI接続を確認します。

結論を先に書くと、Microsoft iSCSI Targetではダメかもしれません。別途QNAPでも確認します（これもサポート対象と書かれていないのですが、使えそうな機器はこれしかない）。

以下、

外部ストレージ アレイを Azure Local に接続する

に基づき、Microsoft iSCSI Targetの接続していた例です。今回はNested Azure Localかつサポート対象ではない機器故、一部の手順を省略しています。ご了承ください。

手順 1: Windows機能とサービスを有効にする

マルチパス I/Oの有効化、iSCSI イニシエーター サービスを有効化

マルチパスI/O（Multipath I/O）の有効化とベリファイ、iSCSI イニシエーター サービスを有効化とベリファイを連続して実施しました。下記は、片系ノードの画面キャプチャです。もう片系ノードも同様に実施しました。

イニシエーター識別子を収集

下記は、片系ノードの画面キャプチャです。もう片系ノードも同様に収集します。

外部ストレージ アレイを Azure Local に接続する に載っていませんが、iSCSIターゲットに古たー識別子を登録しました。

手順 2: MPIO にベンダーを登録し、設定を構成する

負荷分散ポリシーを設定

iSCSI 自動要求を有効

IPアドレスなどを設定

手順 5: iSCSI ターゲットに接続

手順 6: 構成を確認して再起動する

手順 7: SAN ディスクを確認する

手順 8: ディスクを初期化してフォーマット

スクリプトをよく見るとドライブレターが割り当てられています。これが影響している可能性もあるかもしれませんね。

準備が終わったのでデプロイしていこうとしました。しかしBasicのMachine Validationがエラーになりました。

iSCSI接続のロールバックに続く。

Azure Local deployment local identity with key vault その2

Azure Local deployment local identity with key vault その1

からの続き。今回は、実際にデプロイを進めます。

Basicです。こちらの下記画面は、通常通り設定しており、S2Dのままです。

Identity Providerは、local identity with key vaultを選びます。それ以外は、通常通り設定しています。

Configurationです。新規構成として、通常通り設定しています。

Networkingです。Nested Hyper-V構成ゆえ仮想スイッチ経由となるため、ストレージ通信はNWスイッチ経由を選択しています。

仮想NICを6ポート用意し、Management、Compute、Storageの描くインテントに割り当てられるようカスタム構成を選びます。

各インテントごとに仮想NICを選択しつつ、RDMAは無効化します。

クラスターで使用するIPアドレス情報、DNSゾーンを指定します。

DNSサーバーを指定し、サブネットを検証します。

Managementです。カスタムロケーションとして、当方はクラスター名を流用しています。Witnessで使用するストレージアカウントを作成しています。

ADレスであるため、各ノードで共通するローカル管理者アカウントのみを指定します。

Securityです。推奨値のままとします。

Advancedです。CSVなどのボリュームは推奨構成のままとします。

Tagsです。後々トライする可能性も鑑みて、設定しています。

Validationです。Nestedゆえかはわかりませんが、1時間弱かかってます。

サマリーを確認ののち、デプロイします。

3時間かからずに完了しました。

デプロイのウィンドウが1号機に残っていました。

デプロイ完了後、Azure Localのサマリーを確認しました。Local with key vaultになっています。

ストレージパスは下記の通りです。

Key Vaultは下記のようになっています。ローカル管理者のクレデンシャルが含まれています。

最後に、各ノードのOpen sshdです。

前提条件でsshアクセスを有効化していましたが、各ノードのsshdは自動起動していないです。