このエントリは2022/12/28現在の情報に基づいています。将来の機能追加・変更に伴い、記載内容からの乖離が発生する可能性があります。

何を調べようとしているか？

Blob storageをRA-GRS (読み取りアクセス geo 冗長) で構成し、そのストレージに対してSFTPサーバー機能を構成、SSHキーを生成した。そのとき、

• 読み取り専用リージョンに対してもSSHキーは有効か？
• Blob storageがフェールオーバーした場合、このSSHキーはペアリージョンで再設定する必要があるか？それともプラットフォーム側で担保してくれるか？

「ま、プラットフォーム側でよろしくやってくれるでしょ（やってくれないと困る）」と思っていたのだが、ほんまかいな、ということで、簡単に試してみた。

準備

Storage accountをRAｰGRSで作成し、Blob コンテナーを作成しておく。SFTP機能の構成は以下のドキュメントを参照。

SSH ファイル転送プロトコル (SFTP) を使用して Azure Blob Storage に接続する / Connect to Azure Blob Storage by using the SSH File Transfer Protocol (SFTP)
https://learn.microsoft.com/azure/storage/blobs/secure-file-transfer-protocol-support-how-to

まずは既存のSSH公開キーを追加してみる。

続いて、PortalでSSHキーを生成するオプションを指定して別のユーザーを追加する。

完了後、適当なファイルをPutしておく。logicojpでは以下のファイル（IMG_3585.JPG、いつものやつ）。

logicojp2では以下のファイル（342878816.jpg、やや懐かしめ）。

テスト

まずは、読み取り専用リージョン側でもSFTPが動作するのか、という点を確認する。Portalの設定＞エンドポイント、もしくはデータ管理＞冗長性で【ストレージ エンドポイント】を選択すると、読み取り専用セカンダリBlob service エンドポイントを確認できる。

命名規則によると、セカンダリの場合Storage accountに -secondary が付くので、blobsftp4logicojpというStorage accountであれば、blobsftp4logicojp-secondaryに対してアクセスする必要がある。

$ sftp  blobsftp4logicojp.logicojp@blobsftp4logicojp-secondary.blob.core.windows.net
Connected to blobsftp4logicojp-secondary.blob.core.windows.net.

ただし、SFTP ユーザー名には -secondary を付ける必要はない。付けてアクセスしようとしても接続に失敗する。

$sftp  blobsftp4logicojp-secondary.logicojp@blobsftp4logicojp-secondary.blob.core.windows.net
Received disconnect from xxx.yyy.zzz.www port 22:15: The SSH username format is invalid. - RequestId:<GUID> Time:2022-12-28T10:15:03.5390729Z
Disconnected from xxx.yyy.zzz.www port 22
Connection closed

ではlogicojpでログインしdirを打ってみると、ちゃんとIMG_3585.JPGを確認できる（ダウンロードして中身も同一であることは確認済み）。

$ sftp  blobsftp4logicojp.logicojp@blobsftp4logicojp-secondary.blob.core.windows.net
Connected to blobsftp4logicojp-secondary.blob.core.windows.net.
sftp> dir
IMG_3585.JPG
sftp>

残る、フェールオーバー時の挙動だが、階層型名前空間を有効にしているStorage accountでは利用者によるマニュアルフェールオーバーが実行できないため、現時点では動作確認できない（下図）。

ただし、-secondaryが付くセカンダリBlob storageのFQDN（およびIPアドレス）に対しても、プライマリBlob storageに対して設定したSSHキーで接続できることが確認できているので、Storage accountのFQDN自体が入れ替わっても問題なく接続できる、つまり、プラットフォーム側でSSH公開キーを担保してくれていることがわかる（GRSの場合、読み取り専用アクセスのセカンダリサービスへのアクセスができなくなっているだけで、裏ではRA-GRSと同様のことを実現している）。

ということで、推測通りプラットフォーム側でよろしくやってくれることがわかったので、めでたしめでたし。