Microsoft Azure documentation updateとして公開された「Updating DLC for release 9.67.7808.1 for Debian11/Debian12/UB18/UB20/UB24/SLES15」は、Azure Site Recoveryを利用しているLinux VM管理者が確認すべき更新です。結論から言うと、新機能の大規模追加というより、Azure-to-Azureの災害対策で使うMobility AgentのLinuxカーネル対応情報を更新する内容です。対象OSでカーネル更新を行う前に、現在のカーネル、Mobility Agentのバージョン、自動更新設定を確認しておくと、レプリケーション失敗やフェールオーバー時の想定外トラブルを避けやすくなります。
今回の更新は、2026年5月20日にAzure/Azure-SiteRecoveryリポジトリへマージされたPull Request #35に基づくものです。PRでは「Updating DLC for release 9.67.7808.1 for Debian11/Debian12/UB18/UB20/UB24/SLES15」として、Azure Site Recovery関連コンテンツのうち、MobilityAgent配下のサポートカーネル情報が更新されています。Azure/Azure-SiteRecoveryリポジトリ自体も、MobilityAgentのダウンロードリンクやサポートカーネル情報を含むリポジトリとして説明されています。(GitHub)
Microsoft Azure documentation updateの変更点
今回のMicrosoft Azure documentation updateで見るべきポイントは、Azure Site RecoveryのAzure-to-AzureシナリオにおけるLinuxカーネル対応の更新です。PRのファイルツリーでは、MobilityAgent/AzureToAzure/SupportedKernels 配下にあるサポートカーネル一覧のテキストファイルが対象になっています。PR上では .txt ファイルが7件変更され、Debian 11、Debian 12、Ubuntu 18.04、Ubuntu 20.04、Ubuntu 22.04、Ubuntu 24.04、SLES 15に関連するカーネル情報が含まれています。(GitHub)
注意したいのは、PRタイトルでは主にDebian 11、Debian 12、Ubuntu 18.04、Ubuntu 20.04、Ubuntu 24.04、SLES 15が示されていますが、ファイルツリー上にはUbuntu 22.04のサポートカーネルファイルも含まれている点です。運用担当者は、タイトルだけで対象外と判断せず、Ubuntu 22.04を使っているVMも棚卸し対象に含めるのが安全です。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 更新日 | 2026年5月20日 |
| 対象サービス | Microsoft Azure / Azure Site Recovery |
| 主な対象シナリオ | Azure-to-Azureのディザスターリカバリー |
| 主な対象OS | Debian 11、Debian 12、Ubuntu 18.04、Ubuntu 20.04、Ubuntu 22.04、Ubuntu 24.04、SLES 15 |
| 管理者が見るべき箇所 | Mobility Agentのバージョン、Linuxカーネル、サポートマトリックス、自動更新設定 |
| すぐに必要な対応 | 本番VMのカーネル更新前に、ASRの対応状況を照合する |
DLC更新はAzure Site Recoveryの何に影響するのか
ここでいうDLC更新は、Azure Site Recoveryで保護されるLinux VMのカーネル対応に関係する更新と考えると分かりやすいです。Azure Site Recoveryでは、VMのレプリケーションやフェールオーバーにMobility Agentが関わります。Linux VMではカーネルとの互換性が重要で、OSを更新した結果、カーネルがASRのサポート範囲から外れると、レプリケーションの有効化、継続、フェールオーバー後の安定性に影響する可能性があります。
Microsoft Learnのサポートマトリックスでは、Linuxについて「カスタムOSカーネルはサポートされず、ディストリビューションのマイナーリリースや更新に含まれるstockカーネルのみがサポートされる」と明記されています。また、ARM64 CPUアーキテクチャのVMはSite Recoveryでサポートされない点も明記されています。(Microsoft Learn)
つまり、今回の更新を「ドキュメントが少し変わっただけ」と軽く見るのは危険です。実務上は、次のような場面で影響します。
| 運用シーン | 確認すべき理由 |
|---|---|
| Linux VMの定期パッチ適用 | カーネル更新後にASR対応外になると、レプリケーションに影響する可能性がある |
| DR対象VMの新規追加 | OSバージョンだけでなく、実際のカーネルがサポート対象か確認する必要がある |
| Ubuntu 24.04やDebian 12への移行 | 比較的新しいOSでは、カーネル系列の確認が特に重要 |
| SLES 15のSP更新 | SPやカーネル系列によって対応条件が変わる可能性がある |
| 自動更新を有効にしている環境 | 意図せず新しいカーネルに上がる前提で監視と検証が必要 |
対象者はAzure Site Recoveryを使うLinux VM管理者
今回の更新で特に確認すべきなのは、Azure Site RecoveryでLinux VMを保護している管理者です。対象は開発者だけではなく、インフラ運用、クラウド運用、セキュリティ運用、BCP/DR担当者にも広がります。
特に次の環境では、優先度を上げて確認してください。
- Azure VMのリージョン間DRをAzure Site Recoveryで構成している
- Debian、Ubuntu、SLESを本番ワークロードで使っている
- OSパッチを自動適用している
apt upgrade、unattended-upgrades、zypper updateを定期実行している- DRテストを半年以上実施していない
- カーネルを固定せず、最新化を優先している
- Linux VMをテンプレート化して多数展開している
逆に、Azure Site Recoveryを使っていないLinux VMには直接の影響は限定的です。ただし、将来的にASR保護を有効化する予定がある場合は、現在のカーネルがサポート範囲に入っているかを事前確認しておくと、導入時の手戻りを減らせます。
管理者が最初に確認すべき3つの設定
今回のMicrosoft Azure documentation updateを受けて、管理者がまず行うべき確認は3つです。難しい作業ではありませんが、順番を間違えると原因切り分けに時間がかかります。
現在のLinuxカーネルを確認する
各VMで現在稼働しているカーネルを確認します。
uname -rDebianやUbuntuでは、インストール済みカーネルも確認しておくと安全です。
dpkg -l | grep linux-imageSLESでは次のように確認できます。
uname -r
rpm -qa | grep kernel確認したカーネルは、OS名、OSバージョン、VM名、ASR保護状態とセットで一覧化します。たとえば、次のような形式で棚卸しすると判断しやすくなります。
| VM名 | OS | 現在のカーネル | ASR保護 | 判定 |
|---|---|---|---|---|
| vm-web-01 | Ubuntu 24.04 | 6.8.0-xx-generic | 有効 | サポートマトリックス確認 |
| vm-db-01 | Debian 12 | 6.1.0-xx-amd64 | 有効 | カーネル更新前に検証 |
| vm-sap-01 | SLES 15 | 5.14.x / 6.4.x系 | 有効 | SPとカーネル系列を確認 |
Mobility Agentのバージョンを確認する
Azure Site Recoveryでは、OSとカーネルだけでなくMobility Agentのバージョンも重要です。今回のPR名にはrelease 9.67.7808.1 が含まれていますが、PRのファイルツリーでは一部のサポートカーネルファイルが 9.66.7808.1 配下にも追加されています。実環境では、Azureポータルのレプリケート済み項目や拡張機能の状態を確認し、対象VMがどのバージョンのMobility Agentで保護されているかを見ます。(GitHub)
前提として、MicrosoftのUpdate Rollup 83ではAzure-to-AzureのMobility service version 9.66.7691.1に対して、SLES15、Debian 11、Debian 12、Ubuntu 18.04、Ubuntu 20.04、Ubuntu 22.04、Ubuntu 24.04の新しいカーネルサポートが示されています。あわせて、WindowsのNVMeサポートやUbuntu 20.04のOSディスク破損に関する修正も記載されています。(マイクロソフトサポート)
自動更新設定を確認する
Azure Site Recoveryには、Mobility service extensionの更新をSite Recovery側で管理する仕組みがあります。Microsoftのドキュメントでは、Automation Account経由のRunbookが新しいMobility service extensionの有無を確認し、利用可能であれば更新を適用する流れが説明されています。また、自動更新を有効にしてもAzure VMの再起動は不要で、進行中のレプリケーションにも影響しないとされています。(GitHub)
Azureポータルでは、Recovery Services vaultから次の設定を確認します。
| 確認場所 | 見る項目 |
|---|---|
| Recovery Services vault | 対象VMがどのコンテナーで保護されているか |
| Site Recovery Infrastructure | Extension Update Settings |
| Replicated items | 各VMのエージェント状態 |
| Automation Account | ASR更新用Runbookの実行状態 |
| Activity log / Jobs | 更新失敗や警告の有無 |
自動更新を有効にしている場合でも、カーネル更新とMobility Agent更新のタイミングが完全に一致するとは限りません。特に本番環境では、OSのカーネル更新を先に進めるのではなく、ASR側の対応状況を確認してから段階的に適用する運用が安全です。
Linuxカーネル更新で失敗しやすいポイント
Azure Site RecoveryとLinuxカーネルの組み合わせでは、「OS名はサポート対象なのに、実際のカーネルが未対応」というケースが起こりやすいです。たとえば「Ubuntu 24.04がサポートされている」と聞くと、Ubuntu 24.04上のすべてのカーネルが無条件に使えるように感じます。しかし、実際にはサポートマトリックスで示されるカーネル系列やstockカーネルであることが重要です。
Microsoft Learnでは、新しいLinuxカーネルに対するMobility Agentの修正プログラムは、最新のMobility Agentバージョンの上に提供され、Azure-to-AzureのDRシナリオに限って、カーネルリリースから30日以内を目安にベストエフォートで提供されると説明されています。ただし、これはSLAではない点も明記されています。(Microsoft Learn)
| 失敗しやすい判断 | 正しい確認方法 |
|---|---|
| OSが対応していればカーネルもすべて対応していると思う | OS、カーネル、Mobility Agentバージョンをセットで確認する |
| カスタムカーネルを使っても問題ないと思う | stockカーネルのみサポート対象である点を確認する |
| カーネル更新後にASRを確認する | 更新前にサポートマトリックスと検証環境で確認する |
| 自動更新なら常に安全と思う | 自動更新のジョブ失敗や反映タイミングも確認する |
| Ubuntu 22.04を対象外と判断する | PRファイルツリー上ではUbuntu 22.04も含まれるため確認する |
展開・移行時の実務チェックリスト
この更新を受けた対応は、すぐに全VMへ変更を入れることではありません。まずは影響範囲を明確にし、パッチ適用やOS移行の手順にASR確認を組み込むことが重要です。
既存VMで確認すること
既存のASR保護VMでは、次の順で確認します。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | ASRで保護されているLinux VMを抽出 | Debian、Ubuntu、SLESを優先 |
| 2 | uname -rで現在のカーネルを取得 | サポートマトリックスと照合 |
| 3 | Mobility Agentのバージョンを確認 | 更新対象か、更新済みかを判断 |
| 4 | 自動更新設定を確認 | Offの場合は手動更新計画を作る |
| 5 | テストフェールオーバーを実施 | 業務影響のないネットワークで検証 |
| 6 | 本番パッチ適用順を決定 | 低リスクVMから段階展開 |
実務では、いきなり全VMにカーネル更新を適用するのではなく、同じOS・同じカーネル系列の代表VMでテストするのが現実的です。特にDR対象のデータベースサーバー、SAP関連サーバー、認証基盤、監視基盤は、更新前後のレプリケーション状態を必ず確認してください。
新規展開で確認すること
新しくAzure Site Recovery保護を有効化する場合は、VM作成時点のOSイメージとカーネルを確認します。Azure Marketplaceイメージを使っていても、デプロイ直後の初回パッチでカーネルが変わることがあります。
新規展開では、次の流れがおすすめです。
- VMを作成する
- OSバージョンとカーネルを確認する
- 必要なOS更新を適用する
- 再起動後のカーネルを再確認する
- サポートマトリックスと照合する
- Azure Site Recoveryの保護を有効化する
- レプリケーション正常性を確認する
- テストフェールオーバーを実施する
この順番にすると、「ASRを有効化した後にOS更新でカーネルが変わり、後から不整合に気づく」パターンを避けやすくなります。
開発者・SREが意識すべき運用設計
開発者やSREにとって重要なのは、Azure Site Recoveryのサポートカーネル情報を「インフラ担当だけが見る情報」にしないことです。CI/CD、IaC、VMイメージ更新、パッチ管理のどこかでLinuxカーネルが変わるなら、ASRの互換性チェックも運用に組み込む必要があります。
たとえば、TerraformやBicepでVMを展開している環境では、OSイメージのバージョン、パッチ適用ポリシー、ASR保護の有効化タイミングをセットで管理します。ゴールデンイメージを作っている場合は、イメージ作成時点のカーネルだけでなく、展開後に適用される更新まで確認してください。
運用設計では、次のルールを作っておくとトラブルを減らせます。
| ルール | 目的 |
|---|---|
| ASR保護VMはカーネル更新前にサポート確認を必須化する | レプリケーション停止を防ぐ |
| 本番前にテストフェールオーバーを実施する | 起動後のアプリ影響を確認する |
| 自動パッチ適用VMを別管理にする | 意図しないカーネル更新を検知する |
| カーネルとMobility AgentのバージョンをCMDBに記録する | 障害時の切り分けを速くする |
| Ubuntu 24.04やDebian 12は検証VMから展開する | 新しいOS系列のリスクを抑える |
すぐに取るべき対応
今回のMicrosoft Azure documentation updateを受けて、管理者がすぐに行うべきことは、更新プログラムを急いで適用することではなく、対象VMの棚卸しとカーネル互換性の確認です。
まず、Azure Site Recoveryで保護しているLinux VMを一覧化します。次に、Debian 11、Debian 12、Ubuntu 18.04、Ubuntu 20.04、Ubuntu 22.04、Ubuntu 24.04、SLES 15に該当するVMを抽出します。そのうえで、現在のカーネル、Mobility Agentのバージョン、自動更新設定、直近のレプリケーション正常性を確認してください。
最後に、OSパッチ適用やVMイメージ更新の手順書に、次の一文を追加しておくと実務で役立ちます。
ASR保護対象のLinux VMでは、カーネル更新前にAzure Site RecoveryのサポートマトリックスとMobility Agentの更新状態を確認し、必要に応じてテストフェールオーバーを実施する。
今回の更新は、目立つUI変更や新サービスの発表ではありません。しかし、DR対象のLinux VMを安定して守るうえでは重要な更新です。特に自動パッチ適用を有効にしている環境、Ubuntu 24.04やDebian 12へ移行中の環境、SLES 15を業務基盤で使っている環境では、早めに確認しておく価値があります。
コメント