New-IscsiTargetPortalQNAPで共有ディスクを作り直しました。接続は、
外部ストレージ アレイを Azure Local に接続する
を参照しています。ただし再度実行する必要がないところは省略しました。
外部ストレージ アレイを Azure Local に接続する
に則ります。
New-IscsiTargetPortalQNAPで共有ディスクを作り直しました。接続は、
外部ストレージ アレイを Azure Local に接続する
を参照しています。ただし再度実行する必要がないところは省略しました。
外部ストレージ アレイを Azure Local に接続する
に則ります。
接続が永続的なのに、いきなりDisconnect-IscsiTargetを実行してはまりました。
外部ストレージ アレイを Azure Local に接続する の 手順 7: SAN ディスクを確認する からのロールバックを開始しました。
手順 5: iSCSI ターゲットに接続する (iSCSI のみ) だからDisconnect-IscsiTargetでよいだろうと、2ノードともに実施しました。別のiSCSIターゲットからディスクを追加したところ、Disconnect-IscsiTargetで切断したはずのディスクも見えます。PowerShellでPersistent接続にしたディスクを解除する方法が見当たらない(正確には切断の手順誤りで、Unregister-IscsiSessionを実施すべきと後からわかりました)。都合により今回は、Azure Local 2606でiSCSI接続を確認します。
結論を先に書くと、Microsoft iSCSI Targetではダメかもしれません。別途QNAPでも確認します(これもサポート対象と書かれていないのですが、使えそうな機器はこれしかない)。
以下、
外部ストレージ アレイを Azure Local に接続する
に基づき、Microsoft iSCSI Targetの接続していた例です。今回はNested Azure Localかつサポート対象ではない機器故、一部の手順を省略しています。ご了承ください。
準備が終わったのでデプロイしていこうとしました。しかしBasicのMachine Validationがエラーになりました。
iSCSI接続のロールバックに続く。
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は自動起動していないです。