Blob storageのSFTPローカルユーザーに割り当てたSSHキーはストレージのフェールオーバー後も利用できるか

このエントリは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と同様のことを実現している)。

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

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中