diff --git a/README.md b/README.md index c0129f0719..1548d1abed 100755 --- a/README.md +++ b/README.md @@ -144,3 +144,4 @@ - [SSL 証明書の更新に関するアナウンス](./articles/archive/ssl-intermediate-ca-change.md) - [Azure で単数 NIC の仮想マシンを複数 NIC にする](./articles/archive/singlenicvm-to-multinicvm.md) - [Azure 仮想マシンにおける不要な NIC を削除する方法](./articles/archive/delete-nic.md) + diff --git a/articles/archive/delete-nic.md b/articles/archive/delete-nic.md new file mode 100644 index 0000000000..d455e6c3de --- /dev/null +++ b/articles/archive/delete-nic.md @@ -0,0 +1,175 @@ +--- +title: Azure 仮想マシンにおける不要な NIC を削除する方法 +date: 2016-02-18 16:33:00 +tags: + - Archive + - Network + - VM +--- +> [!WARNING] +> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。** + +表題の、Azure 仮想マシンにおける意図せず不要な NIC が増える問題につきましては、皆様のフィードバックのおかげで機能追加が実現し発生しなくなりました。このため、この Blog で紹介している方法で NIC を削除いただく必要はありません。 + +8 月 3 日より 皆様のお声のおかげで MAC アドレスが固定化する機能が追加され、それに伴い 不要な NIC 情報が増える問題解消しました。皆様のお声により Azure がまさに改善した 1 件となりました。重ねてお礼を申し上げます。 + +今後とも貴重なご意見やフィードバックを頂戴できますと幸いです。 + +[Azure のフィードバックサイト](https://feedback.azure.com/d365community) + +皆さんこんにちは。 + +Azure サポートチームの中垣内 (ナカガイト) です。私事ではありますが、昨年末に結婚し新生活真っ只中です。一緒に住み始めると、日々、結婚する前まで知らなかった相手の新たな一面が増えていきますね。 + +さて、日々増えるものと言えば、Azure 上の仮想マシンを毎日再起動している場合、不要な NIC の情報が増えます。不要な NIC の情報が増えすぎるとファイル共有接続が出来なくなるといった問題が発生します。今回の記事では、増えてしまった不要な NIC の情報を削除するとともに、今後増やさない方法についてご紹介します。NIC 削除方法は OS によって異なるため、Windows Server 2008 R2 以前のOS と Windows Server 2012 以降のOS の削除方法に分けて紹介します。 + +## 不要 NIC が作られる要因 + +不要な NIC の情報を削除手順を紹介する前にまずは NIC の情報が増える事象のメカニズムについて紹介します。 + +Azure に限らず、Windows OS では、デバイスの種類、搭載位置も含めてネットワークインターフェース (NIC) を認識します。そのため、Azure で新しいノードへ VM を移動する (停止/起動) たびに、NIC が新しいデバイスとして認識 (※) されます。 + +この際、前回使用された NIC の情報はレジストリに保持された状態となります。これはハードウェアの搭載位置や種類等、ハードウェアの構成に変更が加わった場合における Windows の想定された動作であり、この動作を設定で変更することはできません。 + +**注意：デバイスの再認識について** + +Azure 上で仮想マシンを停止すると、仮想マシン上の OS を停止するだけではなく、Azure がプロビジョニングしたハードウェアやネットワーク リソースをその時点で解放します。 + +* 参考情報: Azure 仮想マシンにおける操作 (再起動、停止/起動、再デプロイ、再適用) について + + [https://jpaztech.github.io/blog/vm/vm-operation/](https://jpaztech.github.io/blog/vm/vm-operation/) + + +そのため、仮想マシンを改めて起動すると、新たにハードウェア リソースの割り当てが行われ、NIC が追加される動作となります。 + +## Windows Server 2012 での手順 + +不要なNICの情報を削除するための PowerShell スクリプトを作成し、シャットダウン スクリプトにて当該スクリプトを実行することで、毎回のOS起動時に不要なNICの情報を削除する方法です。 + +**手順概要**: +1. 事前準備 A から C までを実行します。 +2. シャットダウン スクリプトの ポリシー設定を行います。 + +### 事前準備 A (Devcon の入手) + +1\) 次の KB から、Windows 8 (Windows Server 2012) の Fix it (MicrosoftFixit25010.mini.diagcab) を C:\\Temp に保存します。 + +* 参考情報: Error message when you try to set an IP address on a network adapter + + URL : [https://support.microsoft.com/en-us/kb/269155/en-us](https://support.microsoft.com/en-us/kb/269155/en-us) + +2\) 管理者として起動したコマンド プロンプトで、上記ファイルをダウンロードしたパスに移動します。 + +```cmd +cd /d C:\Temp +``` + +3\) 次のコマンドを順に実行し、使用する devcon コマンドを取得します。 +```cmd +md NICCleanup +expand MicrosoftFixit25010.mini.diagcab NICCleanup -f:*.exe +``` +これにより、C:\\Temp\\ExpandFiles にはそれぞれのアーキテクチャ用の Devcon が展開されます。 + +4\) ご使用の環境に対応するファイルのファイル名を「devcon.exe」に変更します。 + +* devcon\_V8\_AMD64.exe : 64 bit 環境用 + +* devcon\_V8\_I386.exe : 32 bit 環境用 + +* devcon\_V7\_IA64.exe : IA64 環境用 + +### 事前準備 B (Device Management PowerShell の入手) + +1\) 以下のページから、DeviceManagement.zip を入手します。 + +* 参考情報: Device Management PowerShell Cmdlets + + URL : [https://gallery.technet.microsoft.com/scriptcenter/Device-Management-7fad2388](https://gallery.technet.microsoft.com/scriptcenter/Device-Management-7fad2388) + + +2\) ダウンロードしたファイルを右クリックしてプロパティを開きます。 + +3\) General（一般）タブにて、Unblock（ブロックの解除）をクリックして \[OK\] を押します。 + +4\) 任意の場所に解凍し、作成される「Release」フォルダを C:\\Temp\\NICCleanup フォルダに移動 (またはコピー) します。 + +### 事前準備 C (スクリプトの作成) + +1\) C:\\Temp\\NICCleanup フォルダに次のスクリプト ファイルを作成します。 + +\- HiddenNICRemove.ps1 +```PowerShell +Import-Module .\Release\DeviceManagement.psd1 +$hiddenHypVNics = Get-Device -ControlOptions DIGCF_ALLCLASSES | Sort-Object -Property Name | Where-Object { ($_.IsPresent -eq $false) -and ($_.Name -like "Microsoft Hyper-V Network Adapter*") } + +$hiddenHypVNics | ForEach-Object { + + .\devcon.exe remove "@$($_.InstanceId.Replace("`0", ''))" + +} +``` +### シャットダウン スクリプトへの登録 + +1\) 以下内容のバッチファイルを作成します。 + +\- NICCleanup.bat +```PowerShell +cd /d C:\Temp\NICCleanup +powershell -executionpolicy bypass -command ".\HiddenNICRemove.ps1" +``` +2\) スタート メニューから \[ファイル名を指定して実行\] を選択し、gpedit.msc を起動します。 + +3\) 左ペインにて\[コンピューターの構成\] - \[Windows の設定\] と展開し、 \[スクリプト（スタートアップ/シャットダウン）\]を選択します。 + +4\) 右ペインで\[シャットダウン\]を右クリックし、\[プロパティ\]を開きます。 + +5\) \[追加\] ボタンを押し、1. で作成した C:\\Temp\\NICCleanup.bat のパスを指定します。 + +6\) \[OK\] を押して設定を保存します。（ローカル グループ ポリシー エディタは終了しても問題ありません） + +## Windows Server 2008 R2 以前のOS の設定方法 + +シャットダウン スクリプトに不要なNICの情報を削除するためのバッチファイルを配置し、OS 起動時に不要なNIC を削除する手順です。 + +**手順:** + +1) 次の KB から、「For Windows 7, Windows Vista, Windows XP, Windows Server 2008 or Windows Server 2003」 の Fix it (MicrosoftFixit50609.msi) を C:\\Temp に保存します。 + +* 参考情報: Error message when you try to set an IP address on a network adapter + + [https://support.microsoft.com/en-us/kb/269155/en-us](https://support.microsoft.com/en-us/kb/269155/en-us) + + +2\) C:\\Temp 配下に以下のような内容のバッチファイルを NICCleanup.bat として作成します。 + +\- NICCleanup.bat +```cmd +@echo off +MicrosoftFixit50609.msi /quiet +``` +3\) スタート メニューから \[ファイル名を指定して実行\] を選択し、gpedit.msc を起動します。 + +4\) 左ペインにて\[コンピューターの構成\] - \[Windows の設定\] と展開し、 \[スクリプト（スタートアップ/シャットダウン）\]を選択します。 + +5\) 右ペインで\[シャットダウン\]を右クリックし、\[プロパティ\]を開きます。 + +6\) \[追加\] ボタンを押し、手順 2 で作成した C:\\Temp\\NICCleanup.bat のパスを指定します。 + +7\) \[OK\] を押して設定を保存します。（ローカル グループ ポリシー エディタは終了しても問題ありません） + +※本手順では、作業フォルダを C:\\Temp 以下としておりますので、適宜読み替えて作業をご実施ください。 + +## 補足：不要なNIC の存在の確認方法 + +不要な NIC の有無を確認するためには少しコツが必要です。確認方法についても併せて案内いたします。 + +**手順：** +1. コマンド プロンプトを起動します。 +2. 「set devmgr\_show\_nonpresent\_devices=1」と入力して、Enter キーを押します。 +3. 「devmgmt.msc」と入力し、Enter キーを押します。 +4. \[表示\] をクリックして、\[非表示デバイスの表示\] をクリックします。 +5. \[ネットワーク アダプター\] ツリーを展開します。 +6. 赤枠で示すように、アイコンが半透明になった状態で、不要な NIC の情報が表示されます。 + +![](./devmgmt.jpg) diff --git a/articles/archive/delete-nic/devmgmt.jpg b/articles/archive/delete-nic/devmgmt.jpg new file mode 100644 index 0000000000..e3734daa96 Binary files /dev/null and b/articles/archive/delete-nic/devmgmt.jpg differ diff --git a/articles/archive/lb_appgw_traffic_different.md b/articles/archive/lb_appgw_traffic_different.md new file mode 100644 index 0000000000..fd30671e13 --- /dev/null +++ b/articles/archive/lb_appgw_traffic_different.md @@ -0,0 +1,107 @@ +--- +title: Load Balancer と Application Gateway の通信の違い +date: 2018-11-26 19:29:00 +tags: + - Archive + - Network + - Load Balancer + - Application Gateway +--- +> [!WARNING] +> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。** + +こんにちは、Azure サポートチームの山崎です。 +今回は Load Balancer と Application Gateway の通信の違いについてご紹介します。 + +## Load Balancer の場合 + +Load Balancer を経由する通信は宛先 NAT され、バックエンドのサーバへ転送されます。 + +![Load Balancer 経由の通信](./lb_apgw_tayamasa01.png) + +**[行きの通信]** + +1. クライアントから Load Balancer への通信 + - 送信元：クライアントの IP + - 宛先：Load Balancer のフロントエンド IP +2. Load Balancer からサーバへの通信 + - 送信元：クライアントの IP + - 宛先：サーバの IP (宛先 NAT) + +**[戻りの通信]** + +3. サーバから Load Balancer への通信 + - 送信元：サーバの IP + - 宛先：クライアントの IP +4. Load Balancer からクライアントへの通信 + - 送信元：Load Balancer のフロントエンド IP + - 宛先：クライアントの IP + +## Application Gateway の場合 + +Application Gateway はリバースプロキシとして動作するため、クライアントとApplication Gateway 間、Application Gateway とサーバ間で異なるセッションが作成されます。 + +![Application Gateway 経由の通信](./lb_apgw_tayamasa02.png) + +**[行きの通信]** + +1. クライアントから Application Gateway への通信 + - 送信元：クライアントの IP + - 宛先：Application Gateway のフロントエンド IP +2. Application Gateway からサーバへの通信 + - 送信元：Application Gateway の内部 IP (通信するインスタンスの IP) + - 宛先：サーバの IP + +**[戻りの通信]** + +3. サーバから Application Gateway への通信 + - 送信元：サーバの IP + - 宛先：Application Gateway の内部 IP +4. Application Gateway からクライアントへの通信 + - 送信元：Application Gateway のフロントエンド IP + - 宛先：クライアントの IP + +## よくあるお問い合わせ + +- Application Gateway 経由時にクライアント証明書認証できない + +サーバ側でクライアント証明書の認証を行っており、Application Gateway 経由に変更したタイミングで認証が出来なくなるとのお問い合わせをいただきます。Application Gateway の場合、クライアントとApplication Gateway 間、Application Gateway とサーバ間の通信は異なりますので、クライアントからの証明書がサーバ側に届かないため、サーバ側でのクライアント証明書認証はできません。Application Gateway でクライアント証明書の認証、バックエンドのサーバへクライアント証明書に関する情報の転送を行う場合は、[Application Gateway での相互認証の概要](https://learn.microsoft.com/ja-jp/azure/application-gateway/mutual-authentication-overview?tabs=powershell) をご参照ください。Load Balancer の場合は Load Balancer 自体が通信を終端するわけではなく通信を転送するため、クライアント証明書がサーバまで届きますのでクライアント証明書認証が可能です。 + +- Traffic Manager との違い + +Traffic Manager については DNS で負荷分散を行います。 + +![Traffic Manager を利用した通信](./lb_apgw_tayamasa03.png) + +**[DNS 通信]** + +1. クライアントが Traffic Manager の名前解決を行う + - test.trafficmanager.net +2. Traffic Manager が負荷分散先の情報を返信 + - test01.japaneast.cloudapp.azure.com: 1.1.1.1 (A レコード) + +**[エンドポイントとの通信]** + +3. 名前解決後はエンドポイントと直接通信を行います。（Traffic Manager を経由しない） + - 送信元：クライアントの IP + - 宛先：サーバの IP + +> クライアント側で DNS キャッシュが残っている場合は Traffic Manager を経由せず、そのまま継続してエンドポイントと通信を行います。DNS キャッシュがなくなったタイミングで再度名前解決を行い、Traffic Manager がどのエンドポイントと通信するか決定します。 + +## 正常性プローブの違い + +プローブの送信元についても、Load Balancer と Application Gateway で違いがあります。 + +Load Balancer の場合、プローブの送信元は "168.63.129.16" という IP アドレスになります。 + +![Load Balancer の正常性プローブ](./lb_apgw_tayamasa04.png) + +Application Gateway の場合、プローブの送信元はそれぞれのインスタンスの内部 IP アドレスになります。そのため、インスタンスが 2 つの場合、以下のようにそれぞれからプローブが行われています。 + +![Application Gateway の正常性プローブ](./lb_apgw_tayamasa05.png) + +Traffic Manager の場合、プローブの送信元は [Azure で利用される IP アドレス一覧の JSON ファイル](https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519) 内にある AzureTrafficManager タグの IP アドレスのいずれかが利用されます。 + +![Traffic Manager の正常性プローブ](./lb_apgw_tayamasa06.png) + +以上、ご参考になれば幸いです。 \ No newline at end of file diff --git a/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa01.png b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa01.png new file mode 100644 index 0000000000..ccf6d7db1a Binary files /dev/null and b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa01.png differ diff --git a/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa02.png b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa02.png new file mode 100644 index 0000000000..5bb251e163 Binary files /dev/null and b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa02.png differ diff --git a/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa03.png b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa03.png new file mode 100644 index 0000000000..38289cdaf1 Binary files /dev/null and b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa03.png differ diff --git a/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa04.png b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa04.png new file mode 100644 index 0000000000..adb0c26c76 Binary files /dev/null and b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa04.png differ diff --git a/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa05.png b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa05.png new file mode 100644 index 0000000000..4eb8537a92 Binary files /dev/null and b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa05.png differ diff --git a/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa06.png b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa06.png new file mode 100644 index 0000000000..8e923439e0 Binary files /dev/null and b/articles/archive/lb_appgw_traffic_different/lb_apgw_tayamasa06.png differ diff --git a/articles/archive/nic-property.md b/articles/archive/nic-property.md new file mode 100644 index 0000000000..7d177b2816 --- /dev/null +++ b/articles/archive/nic-property.md @@ -0,0 +1,59 @@ +--- +title: ゲスト OS 側の NIC のプロパティでIP アドレスを変更するとVMとの接続が失われる事象について + +date: 2018-09-12 17:34:42 +tags: + - Archive + - Network +--- +> [!WARNING] +> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。** + +こんにちは！ Azure ネットワーク チームの米川です。 + +ゲスト OS 側の NIC のプロパティで IP アドレスまわりの設定をいじってしまい RDP 接続できなくなるケースが稀にあります。 + +弊社公式ドキュメントでも、極力 仮想マシンの ゲスト OS の NIC のプロパティで 手動で IP アドレスを変更しないようにとの旨が記載されておりますが、そもそも何故 ゲスト OS 側の NIC のプロパティを変更してはいけないのかを、簡単にご説明したいと思います。 + +Azure ネットワーク インターフェイスの IP アドレスの追加、変更、削除 +https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-network-interface-addresses#private + +(一部抜粋) +必要がない限り、仮想マシンのオペレーティング システム内のネットワーク インターフェイスの IP アドレスを手動で設定しないでください。 + +## Azure 上の NIC のプロパティとVM 内のNICのプロパティは独立している + +Azure で作成された仮想マシンには、必ず 1 個以上の NIC が関連付けられますが、ゲスト OS 内で NIC のプロパティを変更すると、Azure 基盤側で保持している NIC のプロパティ (IP アドレス等) と整合性が取れなくなり、一切の通信が出来なくなる場合があります。 + +これは、Azure 側の NIC のプロパティ と ゲスト OS 側の NIC のプロパティが独立していることに起因しています。 + +デフォルトでは、ゲスト OS 側の NIC に設定される IP アドレスは、Azure 側の NIC で指定した IP アドレスが DHCP サーバーから割り振られるように設定されています。 + +従って、デフォルトの状態では、Azure 上の NIC のプロパティを編集しても、ゲスト OS 内の NIC に設定されている IP アドレスと不一致が生じることはありません (図 1.)。 + + +ここで、ゲスト OS 側の NIC のプロパティで 静的 IP アドレスを静的していると、値によっては Azure 側の NIC のプロパティと一致しない状況になる場合があります。 + +この場合、Azure 側から見た IP アドレスに対してパケットを送信したつもりが、ゲスト OS 側から見ると自宛ではないパケットが届いたように認識されてしまい、届いたパケットを破棄してしまいます (図 2.)。 + + +## 仮想マシンとの接続ができなくなった場合の対処策 + +ゲスト OS 側で一度 NIC のプロパティを変更して IP アドレスの不一致が発生してしまうと、RDP 接続等も出来なくなり、ゲスト OS 側の設定が変更できなくなってしまいます。 + +そういった場合は、以下のブログで紹介されているように、Azure VM (ARM) の NIC 差し替えて対処して下さい。 + +Azure VM (ARM) の NIC 差し替えについて +http://blogs.technet.microsoft.com/jpaztech/2016/09/14/azure-vm-arm-nic-change/ + +## 余談 + +### 1 NIC に複数の IP アドレスを割り当てる場合は、ゲスト OS側のNIC のプロパティを変更する必要がある +DHCP では 1 つの IP アドレスしか割り振れないので、複数 IP アドレスを 1 つの NIC に割り当てたい場合には、ゲスト OS 側の NIC に静的 IP アドレスを割り当てる必要があります。 + +この際に、設定のミスにより仮想マシンとの切断が生じ、上記の NIC の差し替えを行うと、ゲスト OS 内で既存の NIC の設定がリセットされてしまうため、ゲスト OS 側の NIC の設定にはくれぐれもご注意下さい。 + +Azure Portal を使用して仮想マシンに複数の IP アドレスを割り当てる +https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-multiple-ip-addresses-portal + +以上、Azure を 利用いただくにあたり、ご参考になれば幸いです。 diff --git a/articles/archive/nsg-rule-activitylogalert-notification.md b/articles/archive/nsg-rule-activitylogalert-notification.md new file mode 100644 index 0000000000..5fc01f5d5e --- /dev/null +++ b/articles/archive/nsg-rule-activitylogalert-notification.md @@ -0,0 +1,50 @@ +--- +title: ネットワーク セキュリティ グループのルール変更のアラート機能について + +date: 2018-03-13 18:58:30 +tags: + - Archive + - Network +--- +> [!WARNING] +> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。** + +## 問題 +ポータルのアクティビティ ログ アラートの構成で NSG (リソースタイプ名：Microsoft.Network/networkSecurityGroups) の構成をしても、ルール (送信規則や受信規則) の変更をしても、アラートが設定した通知先に通知されない。 + +## 原因 +ルールについては、別のリソースタイプの定義 (リソースタイプ名：Microsoft.Network/networkSecurityGroups/securityRules) であり、これが完全に一致しない場合は、アラートの機能としてアラートとして挙がらないため。もし、ルールではなく、NSG 自体の構成をした場合には、リソースタイプ名：Microsoft.Network/networkSecurityGroups のイベントが発生するため、アラートは発生します。 + +## 対応 +現状ポータルからは、リソースタイプ名：Microsoft.Network/networkSecurityGroups/securityRules のアラート設定が対応していないため、ご利用いただく際には、PowerShellをご利用いただく必要があります。以下は簡単なサンプルです。 + +サンプル（新規にアクショングループを作成する場合）： + +```PowerShell +$subscriptionId = "<サブスクリプションID>" +$scope = "/subscriptions/<サブスクリプションID>" +$emailReceiverName = "<メール受信の名前>" +$emailAddress = "<メールアドレス>" +$actionGroupName = "<アクショングループ名>" +$actionGroupNameShort = "<アクショングループ名（短い名前）>" +$activityAlertName = "" +Login-AzureRmAccount -Subscription $subscriptionId +$email_receiver = New-AzureRmActionGroupReceiver -Name $emailReceiverName -EmailReceiver -EmailAddress $emailAddress +$action = Set-AzureRmActionGroup -ResourceGroupName Default-ActivityLogAlerts -Name $actionGroupName -ShortName $actionGroupNameShort -Receiver $email_receiver +$AGAlertObject = New-Object Microsoft.Azure.Management.Monitor.Management.Models.ActivityLogAlertActionGroup +$AGAlertObject.ActionGroupId = $action.Id +$condition1 = New-AzureRmActivityLogAlertCondition -Field "category" -Equal "Administrative" +$condition2 = New-AzureRmActivityLogAlertCondition -Field "resourceType" -Equal "Microsoft.Network/networkSecurityGroups/securityRules" +$condition3 = New-AzureRmActivityLogAlertCondition -Field "status" -Equal "Accepted" +Set-AzureRmActivityLogAlert -ResourceGroupName Default-ActivityLogAlerts -Name $activityAlertName -Scope $scope -Location Global -Action $AGAlertObject -Condition $condition1,$condition2,$condition3 +``` + +もし、上記は新規にアクショングループを作る方法ですが、もし既存のものを使いたい場合には、$email_receiver ... 以下の3行を以下に切り替えることで、既存のアクショングループを使うことが可能です。 + +```PowerShell +$action = Get-AzureRmActionGroup -ResourceGroupName Default-ActivityLogAlerts -Name "<アクショングループ名>" +$AGAlertObject = New-Object Microsoft.Azure.Management.Monitor.Management.Models.ActivityLogAlertActionGroup +$AGAlertObject.ActionGroupId = $action.Id +``` + +以上ご参考になれば幸いです。 diff --git a/articles/archive/p2s-tls-announcement-july-2018.md b/articles/archive/p2s-tls-announcement-july-2018.md new file mode 100644 index 0000000000..cfa38bb4e7 --- /dev/null +++ b/articles/archive/p2s-tls-announcement-july-2018.md @@ -0,0 +1,88 @@ +--- +title: ポイント対サイト VPN の TLS に関するアナウンス +date: 2018-06-01 12:30:38 +tags: + - Archive + - Network +--- + +現在、Azure の仮想ネットワーク環境において、ポイント対サイト VPN 接続をご利用いただいているお客様向けに「対応が必要: Windows 7 および Windows 8 のポイント対サイト VPN クライアントを 2018年7月1日 までに更新してください」（Update Windows 7 and Windows 8 point-to-site VPN clients for PCI compliance）というタイトルのメールがお手元に届いているかと思います。こちらのメールの内容について、本ブログにて少し補足させていただきます。 + +なお、今回の変更は、あくまでポイント対サイト VPN 接続で利用される SSTP に影響を与えるものであり、サイト対サイト VPN 接続や Mac OS や Linux のポイント対サイト接続 VPNで使用されている IKE プロトコルには影響がございません。 + +
+ +## TLS 1.0 および 1.1 のサポート終了 +ポイント対サイト VPN 接続で利用されている SSTP（Secure Socket Tunneling Protocol）では、その暗号化通信の機能として TLS を利用しています。 + +これまで、Microsoft では、より高いセキュリティで安心してシステムをご利用いただくため、段階的に TLS 1.2 への移行をお願いして参りました。Azure のポイント対サイト VPN 接続におきましても、より高いセキュリティでご利用いただくため、仮想ネットワーク ゲートウェイにて、以前より TLS 1.2 の利用を可能にするなどの取り組みを行ってきました。 + +この度、多くのお客様により安心してご利用いただくため、また、PCI（Payment Card Industry）基準に準拠するため、ポイント対サイト VPN 接続で利用される TLS において、TLS 1.0 および TLS 1.1 のサポートを終了し、TLS 1.2 のみをサポートするように変更することになりました。 + +ポイント対サイト VPN 接続のクライアントとして Windows 10 をご利用いただいているお客様におきましては、既定の状態で TLS 1.2 をサポートしているため、特に対処いただく必要はありません。 + +Windows 7 または Windows 8.1 をご利用いただいているお客様におきましては、TLS 1.2 を利用いただくために以下の更新プログラムを適用いただく必要があります。 + +- Microsoft の EAP 実装で TLS の使用を有効にする更新プログラム + + [マイクロソフト セキュリティ アドバイザリ: TLS の使用を可能にする Microsoft EAP 実装の更新プログラム (2014 年 10 月 14 日)](https://support.microsoft.com/ja-jp/help/2977292/microsoft-security-advisory-update-for-microsoft-eap-implementation-th) + +- WinHTTP の既定の安全なプロトコルとして TLS 1.1 と TLS 1.2 を有効にする更新プログラム + + [WinHTTP が Windows での既定のセキュリティで保護されたプロトコルとして TLS 1.1 および TLS 1.2 を有効にする更新プログラム](https://support.microsoft.com/ja-jp/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in) + +
+ +[2018 年 8 月 20 日追記] + +なお、上記の資料でも言及されておりますが、今回の変更に対応するには、更新プログラムの適用に加えて、レジストリの変更も必要になります。資料を参照してレジストリ エディタから変更いただくか、「管理者として実行」したコマンドプロンプトで以下の 3 つのレジストリ設定のコマンドを実行いただければ、対応が可能ですので、参考にしていただければと思います。 + +``` +reg add HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 /v TlsVersion /t REG_DWORD /d 0xC00 + +reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols /t REG_DWORD /d 0xaa0 + +if %PROCESSOR_ARCHITECTURE% EQU AMD64 reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DefaultSecureProtocols /t REG_DWORD /d 0xaa0 +``` + +
+ +## 暗号スイートの変更 + +また、今回の変更と併せて、ポイント対サイト VPN 接続の TLS で使用される暗号化スイートにも一部変更が生じます。具体的には、以下のアルゴリズムが利用できなくなります。 + +* RC4 (Rivest Cipher 4) +* DES (Data Encryption Algorithm) +* 3DES (Triple Data Encryption Algorithm) +* MD5 (Message Digest 5) +* SHA-1 (Secure Hash Algorithm 1) + +この変更に伴いポイント対サイト VPN 接続のクライアントでは、暗号化アルゴリズムとして AES（AES128、AES192、AES256） 、ハッシュ アルゴリズムとして SHA-2（SHA256、SHA384）といったアルゴリズムが利用可能である必要が生じます。 + +ただし、ポイント対サイト VPN 接続でサポートされているWindows 7、Windows 8.1、Windows 10 においては、AES や SHA-2 を使った暗号化スイートが既定でサポートされているため、特に対処は必要ありません。 + +TLS 1.2 への移行に関しましては、こちらのブログでもご案内しておりますので、併せてご覧いただければと思います。 + +* [[IT 管理者向け] TLS 1.2 への移行を推奨しています](https://blogs.technet.microsoft.com/jpsecurity/2017/07/11/tlsmigration/) + +
+ +## 本件に関する FAQ + +**Q1. Windows 8.1 に「マイクロソフト セキュリティ アドバイザリ: TLS の使用を可能にする Microsoft EAP 実装の更新プログラム (2014 年 10 月 14 日)」（KB2977292）を適用しようとしたところ、「この更新プログラムはお使いのコンピューターには適用できません」と表示されます。_** + +この更新プログラムを適用するには事前に以下の更新プログラムが適用されている必要があります。 +Windows RT 8.1、Windows 8.1、および Windows Server 2012 R2 の更新プログラム: 2014 年 4 月 +最新の Windows Update を適用した場合も、今回の TLS1.2 への変更に対応することができますので、弊社といたしましては最新の Windows Update を適用いただくことをお勧めいたします。 + +**Q2. Windows 8.1 / Windows Server 2012 R2用の「WinHTTP の既定の安全なプロトコルとして TLS 1.1 と TLS 1.2 を有効にする更新プログラム」が見つかりません。** + +Windows 8.1 および Windows Server 2012 R2 への本モジュールの適用は不要です。 + +**Q3. 更新プログラムを適用後にそれぞれの手順に記載されたレジストリの変更は必要ですか。** + +TLS1.2 を利用するには、更新プログラムを適用後、レジストリを変更いただく必要があります。 + +**Q4. VPN 接続ができないときに、この問題に合致しているかどうかをどのように判断できますか。** + +この問題に合致すると、VPN 接続時のエラーコードとして「812」「0x80072746」「2147014842」が出ます (更新プログラムの適用状況などにより異なります)。このエラーコードとクライアントの Windows のバージョンが判断の目安になります。 diff --git a/articles/archive/p2s-vpn-error798.md b/articles/archive/p2s-vpn-error798.md new file mode 100644 index 0000000000..0615a068d4 --- /dev/null +++ b/articles/archive/p2s-vpn-error798.md @@ -0,0 +1,58 @@ +--- +title: Azure ポイント対サイト接続における エラー798 +date: 2016-03-08 19:34:29 +tags: + - Archive + - Network +--- + +こんにちは、Azure サポート チーム 大塚です。 + +さて、今回のお題は Azure ポイント対サイト接続についてです。 + +ポイント対サイト接続は、わざわざ VPN ルーターを用意しなくても、クライアント端末からセキュアにそして簡単に仮想ネットワークに乗り入れられるという、何とも便利で嬉しい機能なのですが、その機能を構成する際に、「エラー 798」 というエラーが出力されて、VPN 接続ができないというお問い合わせをよくいただきます。 + +![image-title](./p2s-vpn-error798/798.png) + +一般的にこの 「エラー 798」 は下記の場合に出力されるエラーです。 + +* 利用できる証明書がないと判断された場合 +* 証明書のインストールはされているものの、正しいストアに格納されていない場合 +* ルート証明書からクライアント証明書に至るまでの信頼チェーンが確立できない場合 + +そんな「エラー 798」 が出力された際に、まず確認していただきたいことは、ずばり「クライアント証明書がどこのストアに格納されているか。」ということです。 + +この時、クライアント証明書が格納されているべき場所は + +**現在のユーザーの「個人」 ストア です。** + +もし別のストアに格納していた場合は、上記の正しいストアに格納し直し、改めてVPN 接続が可能かどうかご確認ください。 + +
+ +■（参考図：クライアント証明書格納場所） + +![image-title](./p2s-vpn-error798/client.png) + +クライアント証明書が正しいストアに配置されているのに、VPN 接続ができない場合はルート証明書が正しいストアに格納されていない可能性があります。 + +念のためクライアントコンピューターの + +**現在のユーザー** と **ローカルコンピューター** の**両方**の **「信頼されたルート証明機関」** + +にルート証明書をインストールいただき、改めて VPN 接続が可能かどうかご確認ください。 + +
+ +■（参考図：ローカルコンピューター ・ ルート証明書格納場所） + +![image-title](./p2s-vpn-error798/currentuser.png) + +
+ +■（参考図：現在のユーザー ・ ルート証明書格納場所） + +![image-title](./p2s-vpn-error798/local.png) + +最後に、ポイント対サイト接続を実施する際に実行するクライアント VPN パッケージは、クライアント端末に対して、ルート テーブルを書き換える動作が含まれており、この処理にローカル管理者の権限が必要です。 +このため、ポイント対サイト接続を利用できるのは、ローカルの管理者権限をもつユーザーということになります。ローカルの管理者権限を持たないユーザーがポイント対サイト接続を利用する方法は、現状ではございません。 \ No newline at end of file diff --git a/articles/archive/p2s-vpn-error798/798.png b/articles/archive/p2s-vpn-error798/798.png new file mode 100644 index 0000000000..33564cd3aa Binary files /dev/null and b/articles/archive/p2s-vpn-error798/798.png differ diff --git a/articles/archive/p2s-vpn-error798/client.png b/articles/archive/p2s-vpn-error798/client.png new file mode 100644 index 0000000000..ed9a0d068a Binary files /dev/null and b/articles/archive/p2s-vpn-error798/client.png differ diff --git a/articles/archive/p2s-vpn-error798/currentuser.png b/articles/archive/p2s-vpn-error798/currentuser.png new file mode 100644 index 0000000000..3c82317260 Binary files /dev/null and b/articles/archive/p2s-vpn-error798/currentuser.png differ diff --git a/articles/archive/p2s-vpn-error798/local.png b/articles/archive/p2s-vpn-error798/local.png new file mode 100644 index 0000000000..1a96b23782 Binary files /dev/null and b/articles/archive/p2s-vpn-error798/local.png differ diff --git a/articles/archive/singlenicvm-to-multinicvm.md b/articles/archive/singlenicvm-to-multinicvm.md new file mode 100644 index 0000000000..4b12e593db --- /dev/null +++ b/articles/archive/singlenicvm-to-multinicvm.md @@ -0,0 +1,134 @@ +--- +title: Azure で単数 NIC の仮想マシンを複数 NIC にする +date: 2017-10-17 19:06:00 +tags: + - Archive + - Network + - VM +--- +> [!WARNING] +> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。** + +こんにちは、Azure サポートチームの三國です。 + +今回は、単数 NIC の仮想マシンを複数NICにする方法についてご案内します。 + +本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。 + +## はじめに + +NIC とは、ネットワークインターフェイスカードの略です。Azure Portal から仮想マシンを作成するときは単数 NIC がついている仮想マシンしか作成できないのですが、Azure PowerShell などを使うことにより最初から複数の NIC を持った仮想マシンを作成することができます。 + +最初から複数 NIC を持った仮想マシンを作成する方法は、下記のドキュメントをご覧ください。 + +[複数の NIC を持つ Windows 仮想マシンの作成と管理](https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/multiple-nics#create-a-vm-with-multiple-nics) + +今回のテーマは、**「後から NIC の数を複数にしたい！」** というケースです。 + +実は、2つの NIC を持つ仮想マシンにもう1つNICを加えることは難しくありません。 + +本ブログにおいてこのケースは直接的には取り上げませんので、以下のドキュメントをご参照ください。 + +(なお、本ブログを読んでも方法については理解できるようになります) + +[既存の VM への NIC の追加](https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/multiple-nics#add-a-nic-to-an-existing-vm) + +それでは、早速中身に入りましょう。 + +## 単数 NIC の仮想マシンを複数 NIC にする + +以下のPowerShellを用いてください。解説は後述します。 + +**注意!!** このスクリプトにより仮想マシンが停止(割り当て解除)されます。 + +**注意!!** このスクリプトでは新しい NIC に NSG を割り当てません。割り当てたい場合はスクリプトをカスタマイズするか、NIC 追加後にポータルより行ってください。 +```PowerShell + ###################################################################### +### ログインとサブスクリプション指定 +###################################################################### +Login-AzureRmAccount +$mySub = Get-AzureRmSubscription | Out-GridView -Title "Select an Azure Subscription ..." -PassThru +Select-AzureRmSubscription -SubscriptionId $mySub.Id + +###################################################################### +###基本情報を設定する +###なお、パブリックIPアドレスの割り当ては任意です +###################################################################### +$resourceGroup = "リソースグループ名" +$location = "場所" +$vmName = "仮想マシン名" +$PublicIpAddressName = "パブリックIPアドレス名" +$dnsNameforPublicIp = "パブリックIPアドレスに紐づくDNS名" +$vNetName = "仮想マシンの所属するVnet名" +$newNicName = "新しいNIC名" + +$vm = Get-AzureRmVM -name $vmName -ResourceGroupName $resourceGroup + +###################################################################### +###仮想マシンを停止する +###################################################################### +stop-azurermvm -name $vmName -ResourceGroupName $resourceGroup + +###################################################################### +###パブリックIPアドレスを作成する +###パブリックIPアドレスが不要であればコメントアウトください。 +###################################################################### +$pip = New-AzureRmPublicIpAddress -AllocationMethod Dynamic ` +-ResourceGroupName $resourceGroup -DomainNameLabel $dnsNameforPublicIp ` +-IpAddressVersion IPv4 -Location $location -Name $PublicIpAddressName + +###################################################################### +###新NICを作成する +###パブリックIPアドレスの割り当ては任意です。不要であれば、 +###-PublicIpAddressIdオプションをコメントアウトしてください。 +###################################################################### +$myVnet = Get-AzureRmVirtualNetwork -Name $vNetName -ResourceGroupName $resourceGroup +$mySubnet = Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $myVnet ` +|Out-GridView -Title "Select an Azure Subnet ..." -PassThru + +$newNic = New-AzureRmNetworkInterface -Location $location ` +-Name $newNicName -ResourceGroupName $resourceGroup ` +-SubnetId $mySubnet.Id -PublicIpAddressId $pip.id + +###################################################################### +###新NICを追加する +###################################################################### +Add-AzureRmVMNetworkInterface -VM $vm -Id $newNic.Id + +###################################################################### +###プライマリNICを指定する +###本手順では既存のNICをプライマリにしていますが、新NICをプライマリに +###したい場合は以下のようにしてください +###$vm.NetworkProfile.NetworkInterfaces[1].Primary=$true +###################################################################### +$vm.NetworkProfile.NetworkInterfaces[0].Primary=$true + +###################################################################### +###仮想マシン情報を更新する +###################################################################### +Update-AzureRmVm -ResourceGroupName $resourceGroup -VM $vm + +###################################################################### +###仮想マシンを起動する +###################################################################### +start-azurermvm -name $vmName -ResourceGroupName $resourceGroup +``` +## 解説 + +NIC を単数から複数にするうえで重要なのは、**"プライマリNIC"** を指定するということです。 + +NIC が単数の時は NIC のパラメータに"プライマリ"という概念はありませんが、複数 NIC になると必要になります。 + +下記コマンドを単数 NIC の際と複数 NIC の際とでそれぞれ試してみるとご理解頂けるかと存じます。 +```PowerShell +(Get-AzureRmVM -name [仮想マシン名] -ResourceGroupName [リソースグループ名]).NetworkProfile.NetworkInterfaces +``` +そのため、ただ NIC を追加するだけでなく、プライマリを指定してあげる必要があるのです。 + +最初から複数NICを持っている仮想マシンにNICを加えるときは、すでにプライマリNICが定められているため、NIC の追加だけで十分です。 + +以上になります。 + +(その他、この記事を見に来た方に役立つかもしれないブログ) + +[Azure VM (ARM) の NIC 差し替えについて](https://www.syuheiuda.com/?p=4873) \ No newline at end of file diff --git a/articles/archive/ssl-intermediate-ca-change.md b/articles/archive/ssl-intermediate-ca-change.md new file mode 100644 index 0000000000..ccf8493d77 --- /dev/null +++ b/articles/archive/ssl-intermediate-ca-change.md @@ -0,0 +1,94 @@ +--- +title: SSL 証明書の更新に関するアナウンス +date: 2017-06-08 13:40:00 +tags: + - Archive + - Network +--- +> [!WARNING] +> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。** + +本日、Azure サービスの証明書更新に関する通知がお客様に送信されました。 + +この通知は日本のお客様に対しても英語で送信されてしまい、すぐに対処が必要なのか、なにかリスクが発生しているのかなどがわかりにくく、ご心配をおかけしてしまっているのではないかと思います。 + +今回の通知について、米国本社の下記ブログ記事をベースに、日本語版のご案内を以下に用意いたしました。以下の内容にて、ご覧いただけますと幸いです。 + +参考: [Azure TLS Certificates changes](https://blogs.technet.microsoft.com/kv/2017/04/20/azure-tls-certificates-changes/?WT.mc_id=azurebg_email_Trans_33716_1407_SSL_Intermediate_Cert_Change) + +## はじめに + +安全に Azure サービスをご利用いただけるよう、多くのサービスでは SSL/TLS によるアクセスを提供しています。このときに使用されるサーバー証明書は、あらかじめ定められた、マイクロソフトの中間証明機関から発行されています。証明機関の詳細は、[Certificate Practice Statement](https://www.microsoft.com/pki/mscorp/cps/) (CPS) で情報公開されております。 + +一部のお客様は、[Certificate Pinning](https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning) とよばれる仕組みをアプリケーションに実装しています。Certificate Pinning とは、(非常に簡易的に説明しますと) クライアント アプリケーション側で、信頼する証明書をあらかじめ指定する仕組みです。 + +証明機関のリプレースなどで証明書が変更される場合、Certificate Pinning を実装しているアプリケーションでは、新しい証明機関が信頼されるようアップデートが必要になります。仮にアプリケーションの更新が行われないと、新しく変わったサーバー証明書の信頼性を確認できず、SSL/TLS 通信ができません。このようなことを防ぐために、マイクロソフトはいきなり証明機関を変更するのではなく、あらかじめアナウンスして、実際の変更までに準備期間を設けています。 + +現在、Azure サービス向けの証明書を発行している中間証明機関は、2018 年 5 月に期限を迎えます。これを受けて、マイクロソフトはあらたな中間証明機関を 2016 年 7 月に公開しており、Azure のサービスではこの新たな中間証明機関によって署名された証明書の利用を 2017 年 7 月 27 日から開始します。Certificate Pinning などの仕組みで、証明書が変わることで影響を受けるようなアプリケーションをご利用いただいている場合は、2017 年 7 月 27 日までに、あらたな証明書に対応できるよう、アプリケーションのアップデートが必要になります。 + +## 変更点 + +現在、Azure サービス向けの TLS 証明書は、以下の中間証明機関から発行されています。 + +| CN | 拇印 | +|---|---| +| Microsoft IT SSL SHA2 | 97 ef f3 02 86 77 89 4b dd 4f 9a c5 3f 78 9b ee 5d f4 ad 86 | +| Microsoft IT SSL SHA2 | 94 8e 16 52 58 62 40 d4 53 28 7a b6 9c ae b8 f2 f4 f0 21 17 | + +2017 年 7 月 27 日以降、Azure サービス向けの TLS 証明書は、上記の 2 つに加えて、以下の 4 つの中間証明機関からも発行されるようになります。 + +| CN | 拇印 | +|---|---| +| Microsoft IT TLS CA 1 | 41 7e 22 50 37 fb fa a4 f9 57 61 d5 ae 72 9e 1a ea 7e 3a 42 | +| Microsoft IT TLS CA 2 | 54 d9 d2 02 39 08 0c 32 31 6e d9 ff 98 0a 48 98 8f 4a df 2d | +| Microsoft IT TLS CA 4 | 8a 38 75 5d 09 96 82 3f e8 fa 31 16 a2 77 ce 44 6e ac 4e 99 | +| Microsoft IT TLS CA 5 | ad 89 8a c7 3d f3 33 eb 60 ac 1f 5f c6 c4 b2 21 9d db 79 b7 | + +\* CA#3 がスキップされておりますが、無視してください。 + +発行者の情報は、以下のようになります (CN 以外に現行からの変更はありません)。 + +* CN = Microsoft IT TLS CA 1 \[2,4,5\] +* OU = Microsoft IT +* O = Microsoft Corporation +* L = Redmond +* S = Washington +* C = US + +また、以下のとおり CRL (証明書失効リスト) のエンドポイントと、OCSP のエンドポイントも変更されますので、これらのエンドポイントにアクセスできることを確認してください。 + +| エンドポイント | URL | +|---|---| +| 従来の CRL 配布ポイント | http://cdp1.public-trust.com/CRL/Omniroot2025.crl | +| 新しい CRL 配布ポイント | http://crl3.digicert.com/Omniroot2025.crl | +| OCSP | http://ocsp.digicert.com | + +この情報は、[Certificate Practice Statement](https://www.microsoft.com/pki/mscorp/cps/) (CPS) でも公開されております。 + +## この変更による影響 + +ほとんどのお客様には、この変更による影響はありませんが、以下のような場合には、影響を受ける可能性があります。 + +1. 上述したような Certificate Pinning の仕組みで、信頼する証明書を管理するアプリケーションをご利用の場合。 + +2. 新しい CRL 配布ポイントや OCSP へのアクセスができないような、ファイアウォールやプロキシーのルールが設定されている場合。 + +Certificate Pinning の影響を受ける可能性があるかは、以下のような方法で確認ができます。 + +1. アプリケーションのソースコードに、現在の中間証明書の拇印である **“97 ef f3 02 86 77 89 4b dd 4f 9a c5 3f 78 9b ee 5d f4 ad 86”** や **“94 8e 16 52 58 62 40 d4 53 28 7a b6 9c ae b8 f2 f4 f0 21 17”** を指定している箇所がないかを確認する。ソースコードにこれらが含まれている場合、これらの証明書しか信頼しないというコードが組み込まれている可能性があります。 + +2. もしサードパーティから購入したアプリケーションの場合は、アプリケーションの開発ベンダーに確認する。 + +もし Certificate Pinning の影響を受ける可能性がある場合、新しい中間証明機関を信頼するようにアップデートが必要です。 + +同様に、CRL 配布ポイントや OCSP へのアクセスができない場合は、それらにアクセスできるように、ファイアウォールやプロキシー サーバーの設定変更が必要です。 + +## FAQ + +### 現在の中間証明機関の利用はいつ停止しますか？ + +現在の中間証明機関から発行された証明書は、2018 年 5 月 7 日に有効期限を迎えます。それ以降は、古い証明書を信頼する必要はありません。 + +### 全ての Azure サービスで、2017 年 7 月 27 日に同時に証明書が更新されますか？ + +いいえ、証明書の更新は段階的に、サービスによって異なるタイミングで行われます。すぐにすべてのサービスで証明書が更新されるわけではありません。 \ No newline at end of file diff --git a/articles/archive/static-mac-address.md b/articles/archive/static-mac-address.md new file mode 100644 index 0000000000..246712dc84 --- /dev/null +++ b/articles/archive/static-mac-address.md @@ -0,0 +1,28 @@ +--- +title: MAC アドレスの固定化 + +date: 2016-08-05 13:15:04 +tags: + - Archive + - Network +--- +> [!WARNING] +> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。** + +更新 2017/7/26 + +例外的に、仮想マシンの内部 IP アドレスを固定している場合において、内部 IP アドレスを異なる固定 IP アドレスに変更した場合には、MAC アドレスの変更が生じます。 + +---------------------------------------------------- + +皆さんこんにちは、 + +暑い日が続きますが、水分補給をこまめにして夏を乗り切る予定の Azure サポート部の中垣内です。 + +今年の夏と言えば、オリンピックなど待ち遠しいイベントでいっぱいですね。待ち遠しいといえば Azure IaaS 上でのMAC アドレスの固定化機能が実装されました。また、これに伴い以下の Blog 記事で紹介しました割り当て解除の度に NIC 情報が増える事象も解消され、こまめにNIC 情報を削除するなどの作業は不要になっております。 + +皆様の熱いフィードバックにより実現できた機能ではありますので、重ねてお礼申し上げます。 + +-該当 Blog +Azure 仮想マシンにおける不要な NIC を削除する方法 +https://jpaztech.github.io/blog/archive/delete-nic/ diff --git a/articles/archive/vm-outbound-traffic.md b/articles/archive/vm-outbound-traffic.md new file mode 100644 index 0000000000..b4696a9967 --- /dev/null +++ b/articles/archive/vm-outbound-traffic.md @@ -0,0 +1,101 @@ +--- +title: VM からの送信方向の通信量 (Data Transfer Out) について + +date: 2017-12-19 20:39:28 +tags: + - Archive + - Network +--- +> [!WARNING] +> 本記事は、投稿より時間が経過しており、**一部内容が古い可能性があります。** + +こんにちは。Azure サポートチームの比留間です。皆様ご存知の通り、Azure の仮想マシン (VM) から、インターネットまたは他のデータセンターに出ていく通信に対しては[料金が発生いたします](https://azure.microsoft.com/ja-jp/pricing/details/bandwidth/)。今回は、VM の送信方向の通信量について検討してみましょう。 + +![](./vm-outbound-traffic/DataTransfer.png) + +私の通信量多すぎ？ + +## よくあるご質問 + +Q: VM からの通信量が予想よりも多く記録されていました。どのような通信をしていたか、過去の内訳を調査することは可能ですか？ + +A: 残念ながらできません。 + +… と、ここで終わってしまうと、~~第3部完！~~ひたすら残念なだけの記事になってしまいますので、もう少し説明を補足します。 + +少し堅い話をすると、Azure を始めとする多くのパブリッククラウドサービスでは、お客様と事業者 (Microsoft) との間で[責任範囲を分担するモデル](https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility)を採用しております。大まかに分けると IaaS のレイヤーで提供される VM については、Azure 側は基盤となるハードウェア環境に責任を持ち、OS のレイヤー以上の構成は、お客様にて管理をいただくという区分になります。 + +![](./vm-outbound-traffic/responsibility.png) + +つまり、VM 内部の OS 以上のレイヤーで行っている通信内容はお客様の持ち物、ということになり、Azure 側からはデータプライバシーの観点からも原則的に、お客様の VM の通信に干渉したり、通信内容や宛先を記録することは行っておりません。 + +従いまして、通信量の内訳を過去に遡って調査することは、私どもサポートチームでもご要望にお応えすることができません。しかし、現在進行形で予想以上のトラフィックが発生している、ということであれば、以下のような手法で手掛かりをつかむことが可能です。 + +## 1. VM 内部でパケットキャプチャーを採取する方法 +原始的な方法ですが、OS が行っている通信内容を直接取得することができ、かつ、追加料金も発生しない手法です。Windows OS と Linux OS とで、採取方法の例をご紹介します。 + +### Windows の場合： +Message Analyzer や Wireshark などのパケット採取用ツールを使用してももちろん差し支えございませんが、すぐにインストールすることが難しい場合、OS の組み込み機能で簡易なパケットキャプチャーを実施することも可能です。 + +#### 手順の例： + +◇ ログの採取開始： + +以下の説明では、仮に C:\temp を情報採取フォルダーとしていますが、実際の運用環境に合わせて、十分な空き容量があり、かつ、ストレージの I/O を圧迫しない保存場所を選択してください。 + +以下の各コマンドを、管理者権限のコマンドプロンプトにて順次実行します。 + +これにより、ログの採取が開始されます。 + +```cmd +cd C:\temp +netsh trace start capture=yes traceFile=C:\temp\NetTrace.etl +``` + +◇ ログの採取停止： + +しばらく情報を採取した後、以下の各コマンドを、各仮想マシンの管理者権限のコマンドプロンプトより順次実行します。 + +これにより、ログの採取が停止されます。 + +```cmd +cd C:\temp +netsh trace stop +``` + +採取された NetTrace.etl がパケットキャプチャーです。弊社製 Network Monitor や、Message Analyzer で内容を読み取ることが可能です。 + +### Linux の場合： +一例として以下のような tcpdump コマンドでパケットキャプチャーの実施をいただくことができます。Ctrl+C で停止するまでパケットキャプチャーが継続します。 + +例： + +```bash +sudo tcpdump -s0 -i any -n -w outfile.pcap +``` + +（コマンドの詳細については、tcmpdump のマニュアル (man) をご参照ください。 + +また、データの出力先や、パラメーターについては、お客様の環境に合わせて調整いただきますようお願いいたします。） + +取得された .pcap ファイルは、Wireshark で内容の分析が可能です。 + +## 2. Network Watcher のパケットキャプチャー機能を使用する +VM 内部でパケットキャプチャー採取のための操作を実施することが難しい場合は、Network Watcher のパケットキャプチャー機能を使用する方法がございます。Network Watcher の拡張機能が VM にインストールされ、取得されたパケットキャプチャーをストレージアカウント上に出力させることができます。 + +手順と価格については以下の技術情報をご参照ください。 + +ポータルを使用して Azure Network Watcher でパケット キャプチャを管理する +https://docs.microsoft.com/ja-jp/azure/network-watcher/network-watcher-packet-capture-manage-portal + +Network Watcher の価格 +https://azure.microsoft.com/ja-jp/pricing/details/network-watcher/ + +## 3. Log Analytic の Wire Data 2.0 (プレビュー) を使用する +パケットキャプチャーの取得と分析とは少し毛色が異なるアプローチとして、Wire Data 2.0 を使用するという方法もございます。本稿作成時点でプレビュー段階であることに加え、インストールの手順等は必要になりますが、パケットキャプチャーの解析の知識がなくとも、通信先の IP アドレス等を図示して把握することが可能になります。 + +機能の紹介については、以下の技術情報をご参照ください。 + +Log Analytics の Wire Data 2.0 (プレビュー) ソリューション +https://docs.microsoft.com/ja-jp/azure/log-analytics/log-analytics-wire-data + diff --git a/articles/archive/vm-outbound-traffic/DataTransfer.png b/articles/archive/vm-outbound-traffic/DataTransfer.png new file mode 100644 index 0000000000..001a83a3e6 Binary files /dev/null and b/articles/archive/vm-outbound-traffic/DataTransfer.png differ diff --git a/articles/archive/vm-outbound-traffic/responsibility.png b/articles/archive/vm-outbound-traffic/responsibility.png new file mode 100644 index 0000000000..6d91f45b4e Binary files /dev/null and b/articles/archive/vm-outbound-traffic/responsibility.png differ diff --git a/articles/network/FW-O365.md b/articles/network/FW-O365.md index 7d0ea145e3..b1ec03b6b1 100644 --- a/articles/network/FW-O365.md +++ b/articles/network/FW-O365.md @@ -5,11 +5,22 @@ tags: - Network - Azure Firewall --- +**※ 現在（2023/05 時点）Azure Firewall では Office365 用の FQDN タグ及びサービス タグをサポートするようになり、本記事の方法ではなくても、Office 365 エンドポイント宛の通信を許可できるようになりました。** + +**また、FQDN タグ及びサービス タグは Azure 側に管理されるものであり、お客様側に手動で更新する必要はありませんので、 +そちらの方法で Office365 通信を許可する構成を推奨しております。 +詳細な設定方法について以下の公開ドキュメントをご参照ください。** + +[Azure Firewall を使用して Office 365 を保護する](https://learn.microsoft.com/ja-jp/azure/firewall/protect-office-365) + +**以下は古い記事内容となります。** + +# 概要 こんにちは、Azure テクニカル サポート チームの杜です。 今回多数のお客様にお寄せいただいた Azure Firewall にて Office365 通信を許可する方法についてをご紹介します。 -Azure Firewall のアプリケーション ルールでは、[FQDN タブ](https://docs.microsoft.com/ja-jp/azure/firewall/fqdn-tags) の機能があり、その機能を用いて Windows Update などの通信を便利に許可できますが、残念ながら、現時点 Office365 用の FQDN タグを提供していません。 +Azure Firewall のアプリケーション ルールでは、[FQDN タグ](https://docs.microsoft.com/ja-jp/azure/firewall/fqdn-tags) の機能があり、その機能を用いて Windows Update などの通信を便利に許可できますが、残念ながら、現時点 Office365 用の FQDN タグを提供していません。 そのため、お客様側で必要な IP アドレス及び URL をアプリケーション ルールに登録する必要があります。ただし、Office365 関連の IP アドレス及び URL が多く存在し、Azure ポータルで登録するのは時間かかります。その代わりに、以下の PowerShell コマンドでは、一括で登録することは可能です。 diff --git a/articles/network/appgw-configchange.md b/articles/network/appgw-configchange.md index 35b5eda866..c11f93fc2a 100644 --- a/articles/network/appgw-configchange.md +++ b/articles/network/appgw-configchange.md @@ -54,6 +54,7 @@ Application Gateway パブリック IP 20.48.x.x * HTTP2（無効→有効、有効→無効）の変更 * バックエンド設定に接続ドレイン（無効→有効、有効→無効、タイムアウト時間）の変更 * バックエンド設定に Cookie ベースのアフィニティ（無効→有効、有効→無効、Cookie名）の変更 +* 診断設定の追加、編集、削除 ## Application Gateway SKU Standard_v2 & WAF_v2 ### 設定変更の影響 diff --git a/articles/network/cdn-common.md b/articles/network/cdn-common.md index fa8de18835..fe23ca9f87 100644 --- a/articles/network/cdn-common.md +++ b/articles/network/cdn-common.md @@ -8,6 +8,8 @@ tags: --- こんにちは、Azure テクニカル サポート チームの箕輪です。 +> **先日通知されました通り、Azure CDN の Akamai SKU は、2023 年 10 月 31 日に廃止される予定です。ご検討をされているお客様は何卒ご留意いただければと存じます。** + Azure が提供している CDN サービスの Azure CDN において、ご利用いただける機能やよくあるお問合せ、各 SKU の特徴などを踏まえたトラブル シューティングの手順などをご紹介いたします。 Azure CDN は現在 4 つの SKU があり、3 社の CDN プロバイダー (Microsoft / Verizon / Akamai) で CDN サービスを提供しています。 本ブログは Azure CDN における共通的な事項をまとめたブログとなります。 @@ -310,4 +312,4 @@ Azure CDN 上でクライアント (ユーザー) からの要求 URL に対し
-本ブログが皆様のお役に立てれば幸いです。 \ No newline at end of file +本ブログが皆様のお役に立てれば幸いです。 diff --git a/articles/network/cdn-specific-sku.md b/articles/network/cdn-specific-sku.md index 71df4ea06b..f39c1d7411 100644 --- a/articles/network/cdn-specific-sku.md +++ b/articles/network/cdn-specific-sku.md @@ -9,6 +9,8 @@ tags: こんにちは、Azure テクニカル サポート チームの箕輪です。 +> **先日通知されました通り、Azure CDN の Akamai SKU は、2023 年 10 月 31 日に廃止される予定です。ご検討をされているお客様は何卒ご留意いただければと存じます。** + Azure が提供している CDN サービスの Azure CDN において、ご利用いただける機能やよくあるお問合せ、各 SKU の特徴などを踏まえたトラブル シューティングの手順などをご紹介いたします。 Azure CDN は現在 4 つの SKU があり、3 社の CDN プロバイダー (Microsoft / Verizon / Akamai) で CDN サービスを提供しております。 本ブログは Azure CDN で提供している 4 つの SKU の特徴や、各 SKU における情報採取手順などをまとめたブログとなります。 @@ -88,6 +90,9 @@ Premium Verizon は他の SKU と価格が異なりますが、多機能のル #### Standard Akamai + +> **先日通知されました取り、Azure CDN の Akamai SKU は、2023 年 10 月 31 日に廃止される予定です。** + Standard Akamai は Akamai 社の CDN プラットフォームを用いて CDN サービスを提供しております。 Akamai 社は世界最大規模の CDN プラットフォームで CDN サービスを提供しており、動的なサイトの最適化に優れています。 なお、Akamai 社が提供している Akamai Control Center (旧 Luna Control Center) は Azure CDN ではご利用いただけません。 @@ -201,20 +206,6 @@ Premium Verizon のルール エンジンの設定においては、**Lock Draft
- - -## WAF の設定 -WAF の機能は 2020 年 7 月時点で Standard Microsoft においてプレビュー提供をしています。 -WAF では OWASP のルール セットに準拠した Azure で管理されたルール セットの他に、カスタム規則でルールを設定することができます。 -Standard Microsoft で構成されたエンドポイントに対して 1 つの WAF が関連付けできます。 - -[https://docs.microsoft.com/ja-jp/azure/web-application-firewall/cdn/cdn-overview](https://docs.microsoft.com/ja-jp/azure/web-application-firewall/cdn/cdn-overview) - -2020 年 7月時点の動作として、WAF がエンドポイントに関連付けられた状態において、カスタム規則の変更は一部制限がかかる場合があります。 -WAF のカスタム規則において意図した設定が追加できない場合は、一度エンドポイントとの関連付けを解除した上で設定の変更をお試しください。 - -
- ## エラー発生時の情報採取手順 @@ -271,6 +262,8 @@ Verizon 社のエンジニアとスムーズに連携して調査をするため #### Standard Akamai においてエラー発生時にご提供いただきたい情報 +> **先日通知されました取り、Azure CDN の Akamai SKU は、2023 年 10 月 31 日に廃止される予定です。** + Standard Akamai は Akamai 社の CDN プラットフォームでサービスを提供しているため、調査は Akamai 社のエンジニアと共同で実施いたします。 Standard Akamai では、CDN からエラーメッセージを応答された場合に、画面上に **Reference** と呼ばれるエラー コードが記載されます。 この **Reference** のエラー コードを元に調査することが可能となりますので、お問合せ時にご共有いただけますと幸いです。 @@ -302,4 +295,4 @@ curl -H \
-本ブログが皆様のお役に立てれば幸いです。 \ No newline at end of file +本ブログが皆様のお役に立てれば幸いです。 diff --git a/articles/network/fw-snat.md b/articles/network/fw-snat.md index 688ec54a4a..3a0cd03f58 100644 --- a/articles/network/fw-snat.md +++ b/articles/network/fw-snat.md @@ -14,6 +14,8 @@ tags: ## Azure Firewall のパブリック IP による SNAT について +> **ドキュメントが更新され、現在は実際のパブリック IP の使われ方に沿った内容となっています。** + Azure Firewall を経由してインターネット宛に通信するときは、関連付けられているパブリック IP へ送信元のアドレス変換（SNAT）が行われます。パブリック IP が 1 つしかない時はそのパブリック IP のアドレスしか使用されませんが、複数のパブリック IP アドレスが Azure Firewall に関連付けられている場合の動作について、以下のドキュメントではランダムに選択する旨の記載がございます。 [Azure PowerShell を使用して複数のパブリック IP アドレスを使用する Azure Firewall をデプロイする](https://learn.microsoft.com/ja-jp/azure/firewall/deploy-multi-public-ip-powershell) diff --git a/articles/network/pe-difference-se.md b/articles/network/pe-difference-se.md index 3ca6ee2297..4d1a3b9ced 100644 --- a/articles/network/pe-difference-se.md +++ b/articles/network/pe-difference-se.md @@ -44,7 +44,7 @@ tags: 接続元のクライアントは、接続先の FQDN に対して名前解決の結果として Azure Blob のパブリック IP アドレスが応答されます。 接続元のクライアントは、Azure Blob のパブリック IP アドレスに対して、Azure の既定の経路 (0.0.0.0/0) に従って、インターネット経由で接続します。 -下記の図は便宜上インターネットに接続している構成図としていますが、[Azure の仮想マシンから Azure PaaS へ接続は Azure バックボーン ネットワークを経由して接続する](https://learn.microsoft.com/ja-jp/azure/networking/microsoft-global-network)ため、実際の通信はパブリック インターネットを経由しません。 +下記の図は説明の便宜上インターネットに接続している構成図としていますが、[Azure の仮想マシンから Azure PaaS へ接続は Microsoft バックボーン ネットワークを経由して接続する](https://learn.microsoft.com/ja-jp/azure/networking/microsoft-global-network)ため、実際の通信はパブリック インターネットを経由しません。 ![](./pe-difference-se/01.png)

@@ -54,9 +54,10 @@ tags: この構成では、仮想マシンから Blob に対して、サービス エンドポイントを介して接続します。 接続元のクライアントは、接続先の FQDN に対して名前解決の結果として Azure Blob のパブリック IP アドレスが応答されます。 接続元のクライアントは、Azure Blob のパブリック IP アドレスに対して、サービス エンドポイントで追加された内部経路情報 (VirtualNetworkServiceEndpoint) に従って、Azure 内部で最適化された経路で接続します。 +この時の接続経路は、Microsoft バックボーン ネットワーク内で完結します。 -![](./pe-difference-se/02.png)

+![](./pe-difference-se/02a.png)


**シナリオ 3 : プライベート エンドポイントを有効化**
diff --git a/articles/network/pe-difference-se/02a.png b/articles/network/pe-difference-se/02a.png new file mode 100644 index 0000000000..34ab59affe Binary files /dev/null and b/articles/network/pe-difference-se/02a.png differ diff --git a/articles/network/vpn-defaultsite-update-2022feb.md b/articles/network/vpn-defaultsite-update-2022feb.md index 6f52b00cf9..f65a0404f6 100644 --- a/articles/network/vpn-defaultsite-update-2022feb.md +++ b/articles/network/vpn-defaultsite-update-2022feb.md @@ -1,17 +1,23 @@ --- title: 強制トンネリング利用時の VPN ゲートウェイの動作変更についてのアナウンス -date: 2022-02-02 14:00 +date: 2023-05-26 13:00 tags: - Network - VPN Gateway --- + こんにちは、Azure テクニカル サポート チームです。 Azure の仮想ネットワーク ゲートウェイ (以下「ゲートウェイ」) を用いたサイト間 VPN 接続について、2022 年 2 月 24 日以降に、強制トンネリングに関する一部の動作の変更が行われることがアナウンスされました。 影響が生じる可能性のあるお客様には通知がすでに送信されているか、近日中に送信されることが想定されます。しかしながら、通知に含まれる説明は要点のみとなっているため、本記事にてその補足をさせていただきます。 +__※追記__ +2023 年 5 月 再度、強制トンネリング利用時の仮想ネットワーク ゲートウェイの動作変更のアナウンス (Tracking ID:VK3J-580)が通知されました。 +これは、2022 年に通知されたアナウンス (Tracking ID:ZTPX-19Z)と同様の内容となりますが、動作変更の延期により今回あらためて仮想ネットワーク ゲートウェイ は、2023/6/12 ~ 6/16 の間に動作変更が実施されるという旨のアナウンスとなります。 +2022 年に通知を受け取ったお客様の中で、下記の対応を行っていない環境については、動作変更の影響を受ける条件や合致確認の方法、動作変更の内容および変更の影響を受けないようにする対処方法をご確認の上、2023/6/12 より前にご対応いただけますと幸いでございます。 +

diff --git a/articles/storage/addsAuthforAzureFiles.md b/articles/storage/addsAuthforAzureFiles.md index 6d00ac8261..e71e730882 100644 --- a/articles/storage/addsAuthforAzureFiles.md +++ b/articles/storage/addsAuthforAzureFiles.md @@ -45,7 +45,7 @@ Azure ファイル共有 にアクセスするクライアント端末はドメ 1-1. 対象のストレージアカウント「ファイル共有」へを押下します。 ![](addsAuthforAzureFiles/AzureFiles02.png) -1-2. 「+ファイル共有」を押下し、「名前」「クォータ」「層」を入力し新しいファイル共有を作成します。 +1-2. 「+ファイル共有」を押下し、値を入力し新しいファイル共有を作成します。 ![](addsAuthforAzureFiles/AzureFiles03.png) ### (2) Azure ファイル共有に対するオンプレ AD DS 認証の有効化 diff --git a/articles/storage/addsAuthforAzureFiles/AzureFiles02.png b/articles/storage/addsAuthforAzureFiles/AzureFiles02.png index e050afde85..b35e0a2b47 100644 Binary files a/articles/storage/addsAuthforAzureFiles/AzureFiles02.png and b/articles/storage/addsAuthforAzureFiles/AzureFiles02.png differ diff --git a/articles/storage/addsAuthforAzureFiles/AzureFiles03.png b/articles/storage/addsAuthforAzureFiles/AzureFiles03.png index 63cf88f902..e5d91981d1 100644 Binary files a/articles/storage/addsAuthforAzureFiles/AzureFiles03.png and b/articles/storage/addsAuthforAzureFiles/AzureFiles03.png differ diff --git a/articles/vm/azure-vm-cpu-htt-turbo.md b/articles/vm/azure-vm-cpu-htt-turbo.md index d370adbf36..2d9f3b8eef 100644 --- a/articles/vm/azure-vm-cpu-htt-turbo.md +++ b/articles/vm/azure-vm-cpu-htt-turbo.md @@ -76,8 +76,7 @@ Azure VM では VM サイズとして vCPU 数をお客様に選んでいただ > [!NOTE] > ソフトウェアについてはパブリック クラウド環境の場合はオンプレミスの物理サーバーと違ったライセンス ルールがある場合がございます。 -> 「ライセンス上どのように CPU 数などをカウントするか？」「パブリッククラウドとオンプレミス環境でのライセンスの違いはあるか？」など、 -> 各ソフトウェア ライセンスの観点については、そのソフトウェア ライセンスを取り扱っている会社様にご確認をお願いいたします。 +> 「ライセンス上どのように CPU 数などをカウントするか？」「パブリッククラウドとオンプレミス環境でのライセンスの違いはあるか？」など、各ソフトウェア ライセンスの観点については、そのソフトウェア ライセンスを取り扱っている会社様にご確認をお願いいたします。 --- ## 制約付き vCPU 対応の VM サイズについて @@ -113,7 +112,7 @@ Standard_E32-8ds_v5 サイズ（8 vCPU / 256 GB）というサイズのご用意 同じ VM サイズでも物理ホスト サーバーに搭載された CPU の種類が異なるため、VM の実行される CPU の種類が変わるといったことがございます。 例えば、以下のように Dv4 および Dsv4 シリーズは、ブログ執筆の 2023 年 4 月時点では、以下 2 種類の CPU でご提供をさせていただいております。 -> ■ご参考：■ご参考：Dv4 および Dsv4 シリーズ +> ■ご参考：Dv4 および Dsv4 シリーズ > [https://learn.microsoft.com/ja-jp/azure/virtual-machines/dv4-dsv4-series](https://learn.microsoft.com/ja-jp/azure/virtual-machines/dv4-dsv4-series) > ーーーーーー抜粋ーーーーーー diff --git a/articles/vm/disk-metrics.md b/articles/vm/disk-metrics.md new file mode 100644 index 0000000000..9543698398 --- /dev/null +++ b/articles/vm/disk-metrics.md @@ -0,0 +1,238 @@ +--- +title: Azure VM のディスクパフォーマンス状況の確認方法について +date: 2023-5-10 17:30:00 +tags: + - VM + - Windows + - Linux + - HowTo + - Disk +--- + +こんにちは、Azure テクニカル サポート チームの富田です。 +期待したディスクパフォーマンスが得られないといったお問い合わせをいただくことがあります。 +そのため、今回この記事以下の内容について解説をさせていただきます。 + +1. Azure 側にて VM サイズとディスクサイズ毎に設定されている上限について解説 +2. ディスクに関するメトリックでパフォーマンスを確認する方法 +3. VM サイズとディスクサイズを変更する方法 + +> [!NOTE] +> 本記事では各種の上限について数値を交えて解説しておりますが、こちらは理論値となっており実際の計測では OS レイヤ以上の影響等もございますので、必ずしも記載の理論値が計測可能であることを保証するものではございません点について予めご了承くださいませ。 + +--- +## 1-1.VM サイズとディスクサイズ毎に設定されている上限について解説 + +まずは、Azure VM におけるディスクのパフォーマンスの上限値について解説させていただきます。 + +> [!TIP] +> ディスク性能の上限はオンプレミス上の物理ディスクでも勿論あるものであり、OS から高負荷な I/O 要求が発生し、ディスク性能の上限に達した場合、 I/O に遅延等が発生することはご理解いただけるかと存じます。 +> Azure のディスク性能も同じような考え方となります。上限に達した場合は、オンプレミス環境と同様に I/O の遅延等が発生しますが、これは Azure 特有のものでは無く、オンプレミス環境と同じように発生するものであると考えていただけますと幸いです。 + +オンプレミス環境のサーバーや私たちが普段使用しているパソコンと同様に、Azure VM でもディスクアクセスが行われます。 +Azure ではこの VM とディスク間のディスクアクセスについて、「VMサイズ」と「ディスクサイズ」のそれぞれ両方で「MBps」と「IOPS」の上限値を設定しています。 + +なお、この上限は Read / Write の合計で適用されます。 +つまり Read が 100 MBps、Write が 50 MBps 同時に発生していたら、150 MBps のディスクアクセスとして合算されます。 + +重要な点として、ディスクアクセスの上限は「VMサイズ」と「ディスクサイズ」に設定されている低い方の上限値が適用されます。 +ホストキャッシュやバーストは無効と考えて、VM とデータディスク間の通信について以下に例を記載します。 + +![](./disk-metrics/bisk-base.png) + +上記の例では Standard_D2s_v5 の VM サイズに P20 のデータディスクのサイズを組み合わせています。 + +- Standard_D2s_v5 の VM サイズでの上限：85 MBps / 3750 IOSP +- P20 のディスクサイズでの上限：150 MBps / 2300 IOPS + +という設定がございます。 +先に解説した通り低い値の方（赤字）が適用されますので、実際に想定される速度の上限値としては「85 MBps / 2300 IOPS」となります。 + +なお、この「Standard_D2s_v5 の VM サイズでの上限：85 MBps / 3750 IOSP」という VM の上限値については、ディスク 1 つごとでは無く、ホストキャッシュ無効な全てのデータディスク全体で共有されます。 +すなわち、複数のホストキャッシュ無効なデータディスク合算で 85 MBps / 3750 IOSP が上限となります。 + +ホストキャッシュの有効なディスク・無効なディスクで上限値が別に設定されている VM サイズもございます。 +各 VM サイズおよびディスクサイズにおけるディスクアクセスの上限値は、公式ドキュメントをご確認くださいませ。 + +> ■ご参考：Azure の仮想マシンのサイズ +> [https://learn.microsoft.com/ja-jp/azure/virtual-machines/sizes](https://learn.microsoft.com/ja-jp/azure/virtual-machines/sizes) + +> ■ご参考：Azure マネージド ディスクの種類 +> [https://learn.microsoft.com/ja-jp/azure/virtual-machines/disks-types](https://learn.microsoft.com/ja-jp/azure/virtual-machines/disks-types) + +--- +## 1-2.一時的に通信の上限を上げる「ディスクバースト」という機能がございます + +先に記載した通り、「VMサイズ」と「ディスクサイズ」それぞれにディスクアクセスの上限が設定されています。 +しかしながら、特定の「VMサイズ」と「ディスクサイズ」には、このディスクアクセスの上限を一時的に上げられる「ディスクバースト」という機能がございます。 + +- VM サイズに設定されているディスクアクセスの上限値が一時的に上がること = VM レベルのバースト +- ディスクサイズに設定されているディスクアクセスの上限値が一時的に上がること = ディスクレベルのバースト + +ディスクバーストの詳細については公式ドキュメントをご参照くださいませ。 + +> ■ご参考：マネージド ディスクのバースト +> [https://learn.microsoft.com/ja-jp/azure/virtual-machines/disk-bursting](https://learn.microsoft.com/ja-jp/azure/virtual-machines/disk-bursting) + +なお、クレジットベースのバーストの場合、VM レベルのバーストとディスクレベルのバーストは独立しており、 +以下のように 6 種類のクレジットが独立している点、ご留意くださいませ。 + +- VM レベルに関する MBps のバーストクレジット（キャッシュ無し） +- VM レベルに関する IOPS のバーストクレジット（キャッシュ無し） +- VM レベルに関する MBps のバーストクレジット（キャッシュあり） +- VM レベルに関する IOPS のバーストクレジット（キャッシュあり） +- ディスクレベルに関する MBps のバーストクレジット +- ディスクレベルに関する IOPS のバーストクレジット + +では、ホストキャッシュは無しとして、バーストが発生した際の例を見てみましょう。 + +![](./disk-metrics/disk-burst.png) + +上記は、Standard_D2s_v5 の VM サイズに P20 のデータディスクのサイズを組み合わせて、VM レベルのバースト・ディスクレベルのバースト両方が働いた場合の例です。 +一時的に「170 MBps / 3500 IPOS」までバースト可能なことが分かりましたね。 + + +--- +## 2-1.ディスクに関するメトリックでパフォーマンスを確認する方法 + +Azure では、ディスクアクセスに関してどの程度のパフォーマンスが出ているかといったことを記録しており、メトリックとして確認を行うことが可能です。 +パフォーマンスが上限で頭打ちしている場合は、スペックアップが必要である可能性があるといったことを確認することができます。 + +パフォーマンスが上限で頭打ちしていないにも関わらず、期待したパフォーマンスを得られていない場合は、 +OS やアプリケーションが適切なディスクアクセスを発生させていない可能性がございます。 +ディスクパフォーマンスの詳細については以下の記事もご参照くださいませ。 + +> ■ご参考：Azure Premium Storage: 高パフォーマンス用に設計する +> [https://learn.microsoft.com/ja-jp/azure/virtual-machines/premium-storage-performance](https://learn.microsoft.com/ja-jp/azure/virtual-machines/premium-storage-performance) + +Azure ではこの調査に役立つ多くのディスクに関するメトリックがございますので、一覧形式でご紹介させていただきます。 + +> [!NOTE] +> これらの記録された値については Azure 基盤上で観測された値となりますため、OS 上で観測した値と差異がある可能性がございます点、予めご了承ください。 +> また、メトリック表示の最小の粒度は 1 分でございますため、瞬間的な状況等は確認が叶いません点、ご留意ください。 + +### OS ディスクの Read / Write に関して何 MBps / IOPS が記録されたか確認する + +|確認できる内容|メトリック名| +|:-|:-| +|OS ディスクの Read が何 MBps 記録されたか確認|OS Disk Read Bytes/Sec| +|OS ディスクの Write が何 MBps 記録されたか確認|OS Disk Write Bytes/Sec| +|OS ディスクの Read が何 IOPS 記録されたか確認|OS Disk Read Operations/Sec| +|OS ディスクの Write が何 IOPS 記録されたか確認|OS Disk Write Operations/Sec| + +### データディスクの Read / Write に関して何 MBps / IOPS が記録されたか確認する + +|確認できる内容|メトリック名| +|:-|:-| +|データディスクの Read が何 MBps 記録されたか確認|Data Disk Read Bytes/Sec +|データディスクの Write が何 MBps 記録されたか確認|Data Disk Write Bytes/Sec +|データディスクの Read が何 IOPS 記録されたか確認|Data Disk Read Operations/Sec +|データディスクの Write が何 IOPS 記録されたか確認|Data Disk Write Operations/Sec + +### VM レベルのディスクバーストのクレジットの残りがどれくらいか確認する + +|確認できる内容|メトリック名| +|:-|:-| +|VM レベルの MBps の残バーストクレジット量（キャッシュ有効であるディスク）|VM Cached Used Burst BPS Credits Percentage| +|VM レベルの IOPS の残バーストクレジット量（キャッシュ有効であるディスク）|VM Cached Used Burst IO Credits Percentage| +|VM レベルの MBps の残バーストクレジット量（キャッシュ**無効**なディスク）|VM Uncached Used Burst BPS Credits Percentage| +|VM レベルの IOPS の残バーストクレジット量（キャッシュ**無効**なディスク）|VM Uncached Used Burst IO Credits Percentage| + +### ディスクレベルのディスクバーストのクレジットの残りがどれくらいか確認する + +|確認できる内容|メトリック名| +|:-|:-| +|ディスクレベルの MBps の残バーストクレジット量（OS ディスク）|OS Disk Used Burst BPS Credits Percentage| +|ディスクレベルの IOPS の残バーストクレジット量（OS ディスク）|OS Disk Used Burst IO Credits Percentage| +|ディスクレベルの MBps の残バーストクレジット量（データディスク）|Data Disk Used Burst BPS Credits Percentage| +|ディスクレベルの IOPS の残バーストクレジット量（データディスク）|Data Disk Used Burst IO Credits Percentage| + +### ディスクレベルのベースパフォーマンスに対して何 % のパフォーマンスが記録されたか確認する + +|確認できる内容|メトリック名| +|:-|:-| +|ディスクレベルのベースパフォーマンスに対して計測された MBps のパーセント表示（OS ディスク）|OS Disk Bandwidth Consumed Percentage| +|ディスクレベルのベースパフォーマンスに対して計測された IOPS のパーセント表示（OS ディスク）|OS Disk IOPS Consumed Percentage| +|ディスクレベルのベースパフォーマンスに対して計測された MBps のパーセント表示（データディスク）|Data Disk Bandwidth Consumed Percentage| +|ディスクレベルのベースパフォーマンスに対して計測された IOPS のパーセント表示（データディスク）|Data Disk IOPS Consumed Percentage| + +> [!NOTE] +> ※Premium ストレージをサポートする VM シリーズ上でのみ使用できます。 +> ※バースト時の上限ではなくベースパフォーマンスを 100 % として記録されます。バーストしている場合も 100 % で記録されます。 + +### VM レベルのベースパフォーマンスに対して何 % のパフォーマンスが記録されたか確認する + +|確認できる内容|メトリック名| +|:-|:-| +|VMレベルのベースパフォーマンスに対して計測された MBps のパーセント表示（キャッシュ有効であるディスク）|VM Cached Bandwidth Consumed Percentage| +|VMレベルのベースパフォーマンスに対して計測された IOPS のパーセント表示（キャッシュ有効であるディスク）|VM Cached IOPS Consumed Percentage| +|VMレベルのベースパフォーマンスに対して計測された MBps のパーセント表示（キャッシュ**無効**なディスク）|VM Uncached Bandwidth Consumed Percentage| +|VMレベルのベースパフォーマンスに対して計測された IOPS のパーセント表示（キャッシュ**無効**なディスク）|VM Uncached IOPS Consumed Percentage| + +> [!NOTE] +> ※Premium ストレージをサポートする VM シリーズ上でのみ使用できます。 +> ※バースト時の上限ではなくベースパフォーマンスを 100 % として記録されます。バーストしている場合も 100 % で記録されます。 + +### ディスクのキューの深さを確認する + +|確認できる内容|メトリック名| +|:-|:-| +|OS ディスクのキューの深さを確認|OS Disk Queue Depth| +|データ ディスクのキューの深さを確認|Data Disk Queue Depth| + +ディスク パフォーマンス メトリックについては公式ドキュメントもございますので、合わせてご参照くださいませ。 + +> ■ご参考：ディスク パフォーマンス メトリック +> [https://learn.microsoft.com/ja-jp/azure/virtual-machines/disks-metrics](https://learn.microsoft.com/ja-jp/azure/virtual-machines/disks-metrics) + +--- +## 2-2.実際に Azure ポータルでメトリックを確認する（データディスク毎に確認する方法） + +メトリックを見る際は以下のように、Azure ポータルで対象の VM の画面より「メトリック」のブレードを選択いただくことでメトリック表示画面になります。 + +![](./disk-metrics/disk-metric.png) + +メトリックの表示自体の詳細を確認したい場合は、以下の公開ドキュメントをご参照ください。 + +> ■ご参考: Azure Monitor メトリックの概要 +> [https://docs.microsoft.com/ja-jp/azure/azure-monitor/essentials/data-platform-metrics](https://docs.microsoft.com/ja-jp/azure/azure-monitor/essentials/data-platform-metrics) + +> ■ご参考：Azure Monitor のサポートされるメトリック +> [https://docs.microsoft.com/ja-jp/azure/azure-monitor/essentials/metrics-supported](https://docs.microsoft.com/ja-jp/azure/azure-monitor/essentials/metrics-supported) + + +データディスクのメトリックでは、既定の表示では全データディスクの値が合算されたりした状態で表示されてしまいます。 +各データディスク毎にメトリックを確認したい場合は、以下の手順に沿う必要がございます。 +まず、以下のように VM のディスクブレードからデータディスクの LUN 番号を確認しましょう。 + +![](./disk-metrics/disk-lun.png) + +以下のようにメトリック画面でディメンションを LUN で分割すると、各データディスク毎のメトリックの表示が可能になります。 +下図では 2 つのデータディスクの情報がそれぞれ表示されていますね。 + +![](./disk-metrics/disk-metric-lun.png) + +また、LUN でフィルターをすることで、特定のデータディスクのみ表示することも可能です。 + +![](./disk-metrics/disk-metric-filter.png) + + +--- +## 3.VM サイズ / ディスクサイズを変更する + +上記のメトリックなどを確認の上、更に高パフォーマンスなディスクアクセスが必要となった場合は、VM サイズ / ディスクサイズを変更することが可能です。 +オンプレミス環境の場合は新しいハードウェアの調達などが必要でしたが Azure では簡単に変更をすることが可能です。 +手順については以下のドキュメントをご確認いただけますと幸いです。 + +> ■ご参考：仮想マシンのサイズの変更 +> [https://learn.microsoft.com/ja-jp/azure/virtual-machines/resize-vm](https://learn.microsoft.com/ja-jp/azure/virtual-machines/resize-vm) + +> ■ご参考：マネージド ディスクをある特定のディスクの種類から別のものに切り替える +> [https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/convert-disk-storage#switch-managed-disks-from-one-disk-type-to-another](https://learn.microsoft.com/ja-jp/azure/virtual-machines/windows/convert-disk-storage#switch-managed-disks-from-one-disk-type-to-another) + +VM サイズ / ディスクサイズ変更には VM 停止が必要となります点、ご留意くださいませ。 + +--- + +以上の通り、ディスクのディスクメトリックの確認について解説をさせていただきました。 +お客様の調査等の一助となれば幸いでございます。 \ No newline at end of file diff --git a/articles/vm/disk-metrics/bisk-base.png b/articles/vm/disk-metrics/bisk-base.png new file mode 100644 index 0000000000..e9148c2834 Binary files /dev/null and b/articles/vm/disk-metrics/bisk-base.png differ diff --git a/articles/vm/disk-metrics/disk-burst.png b/articles/vm/disk-metrics/disk-burst.png new file mode 100644 index 0000000000..8c8791d7dd Binary files /dev/null and b/articles/vm/disk-metrics/disk-burst.png differ diff --git a/articles/vm/disk-metrics/disk-lun.png b/articles/vm/disk-metrics/disk-lun.png new file mode 100644 index 0000000000..736989bba6 Binary files /dev/null and b/articles/vm/disk-metrics/disk-lun.png differ diff --git a/articles/vm/disk-metrics/disk-metric-filter.png b/articles/vm/disk-metrics/disk-metric-filter.png new file mode 100644 index 0000000000..0bbb112dde Binary files /dev/null and b/articles/vm/disk-metrics/disk-metric-filter.png differ diff --git a/articles/vm/disk-metrics/disk-metric-lun.png b/articles/vm/disk-metrics/disk-metric-lun.png new file mode 100644 index 0000000000..6154cf87bf Binary files /dev/null and b/articles/vm/disk-metrics/disk-metric-lun.png differ diff --git a/articles/vm/disk-metrics/disk-metric.png b/articles/vm/disk-metrics/disk-metric.png new file mode 100644 index 0000000000..d395376992 Binary files /dev/null and b/articles/vm/disk-metrics/disk-metric.png differ diff --git a/articles/vm/noboot-recovery-unmanaged-disk.md b/articles/vm/noboot-recovery-unmanaged-disk.md index ae1bbb1d05..48ba683b25 100644 --- a/articles/vm/noboot-recovery-unmanaged-disk.md +++ b/articles/vm/noboot-recovery-unmanaged-disk.md @@ -1,144 +1,156 @@ ---- -title: 【非管理ディスク編】 復旧 VM を使った Windows VM の Noboot 復旧手順 -date: 2021-5-14 17:30:00 -tags: - - VM - - Windows - - Noboot ---- - -こんにちは。Azure テクニカル サポート チームの重田です。 -本記事では、Windows OS が起動しなくなる事象が発生した際に Windows OS の復旧手順を実施するために、起動ができない VM の OS ディスクを他の正常な VM にデータ ディスクとして接続する方法について紹介します。 - - - -Windows OS の復旧手順に関しては、Windows サポートチームのブログからご紹介しています。 -本記事では、[対処方法] 編に記載されている切り分け [3] - [6] を Azure 環境上でお試しいただく方法について紹介しています。 - -> **OS が起動しなくなる問題が発生した場合の対処方法について – 概要** -> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-OutLine/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-OutLine/) - -> **OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法** -> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/) - - -本記事では、**非管理ディスク**をご利用の環境用の手順を紹介します。管理ディスクをご利用の場合は、「[【管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順](https://jpaztech.github.io/blog/vm/noboot-recovery-managed-disk/)」をご確認ください。 - ---- - -## 概要 -1. 復旧対象 VM の OS ディスク VHD ファイルを複製します -2. 復旧作業用 VM にて、複製した VHD ファイルをデータ ディスクとしてアタッチします -3. 復旧作業用 VM にて、切り分けを実施します。 -4. 修復した VHD を Azure PowerShell にて現在の復旧対象 VM の VHD と差し替えます。 - ---- - -## 手順 - -### 1. 復旧対象 VM の OS ディスク VHD ファイルを複製します - -Azure Storage Explorer または AzCopy をご利用いただく方法にて、復旧対象 VM の OS ディスク VHD ファイルを複製します。 -　 -#### Azure Storage Explorer をご利用いただく場合 - -Azure Storage Explorer については、下記公開情報をご確認ください。 -> Azure Storage Explorer -> [https://azure.microsoft.com/ja-jp/features/storage-explorer/](https://azure.microsoft.com/ja-jp/features/storage-explorer/) - -1. 復旧対象 VM を停止 (割り当て解除) します。 -2. Azure Storage Explorer にて [ストレージ アカウント] - [<ストレージ アカウント名>] - [Blob Containers] - [vhds (コンテナ―名)] を開き、復旧対象 VM の OS ディスクの VHD を選択した状態で、[クローン] をクリックします。 - - ![](./noboot-recovery-unmanaged-disk/1.png) - -3. "BLOB を新しい名前で複製" 画面にて [<複製後の VHD 名>] を入力し、[複製] をクリックします。 - - ![](./noboot-recovery-unmanaged-disk/2.png) - -4. 複製が完了した際には Azure Storage Explorer の "アクティビティ" に "転送完了" のメッセージが表示されます。 - - ![](./noboot-recovery-unmanaged-disk/3.png) - -#### AzCopy をご利用いただく場合 - -AzCopy については、下記公開情報をご確認ください。 - -> AzCopy を使ってみる -> [https://docs.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-v10](https://docs.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-v10) - - -1. 復旧対象 VM を停止 (割り当て解除) します。 -2. AzCopy コマンドを下記の通り実行します。 - 構文： - ```PowerShell - ./azcopy.exe copy "https://ストレージアカウント名.blob.core.windows.net/vhds/複製元のディスク名.vhd?SAS" "https://ストレージアカウント名.blob.core.windows.net/vhds/複製後のディスク名.vhd?SAS" --overwrite=prompt --s2s-preserve-access-tier=false --recursive - ``` - -### 2. 復旧作業用 VM にて、複製した VHD ファイルをデータ ディスクとしてアタッチします - -1. 復旧作業用の VM を作成します。 - Azure Portal から [Virtual Machines] を開き、 [+ 追加] をクリックし、復旧対象 VM と同様のリージョンにて、同様の OS バージョンの非管理ディスクを用いた VM を作成します。 -2. 複製した VHD ファイルをデータ ディスクとしてアタッチします。 - Azure Portal から [Virtual Machines] - [<復旧作業用の VM 名>] を開き、左メニュー "設定" の [ディスク] をクリックします。 -3. 開いた画面にて [+ データ ディスクの追加] をクリックします。 - - ![](./noboot-recovery-unmanaged-disk/4.png) - - [ソースの種類] を [既存の BLOB] とし、[ソース BLOB] を手順 2 にて複製した VHD を選択します。 - - ![](./noboot-recovery-unmanaged-disk/5.png) - - [OK] をクリックし、前の画面にて [保存] をクリックします。 - - ![](./noboot-recovery-unmsanaged-disk/6.png) - -4. 復旧作業用 VM に RDP 接続し、追加したデータ ディスクが認識されるかを確認します。 - -### 3. 復旧作業用 VM にて、切り分けを実施します - -下記 Windows OS 観点のブログに記載されている [3] - [6] をお試し下さい。 - -> OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法 -> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/) - -また、事象別のトラブルシューティングについては、下記公開情報に詳細が記載されています。併せてご確認ください。 - -> Azure 仮想マシンのブート エラーのトラブルシューティング -> [https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/boot-error-troubleshoot](https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/boot-error-troubleshoot) - -### 4. 修復した VHD を Azure PowerShell にて現在の復旧対象 VM の VHD と差し替えます - -1. Azure Portal より復旧作業用 VM を停止 (割り当て解除) します。 -2. Azure Portal から [Virtual Machines] - [<復旧作業用の VM 名>] を開き、左メニュー "設定" の [ディスク] をクリックします。 -3. データディスクをデタッチし、[保存] をクリックます。 -4. 復旧対象 VM を停止 (割り当て解除) されていることを確認します。 - -5. PowerShell にて下記コマンドを実行します。 - ```PowerShell - #VM 情報の取得 - $VM = Get-AzVM -ResourceGroupName リソースグループ名 -name 復旧対象 VM 名 - #VHD ファイルの内容を差し替え - $VM.StorageProfile.OsDisk.Vhd.Uri = "修復した VHD ファイルのパス" - #VM 情報の更新 - Update-AzVM –VM $VM –ResourceGroupName リソースグループ名 - ``` - 結果例： - ```PowerShell - RequestId IsSuccessStatusCode StatusCode ReasonPhrase - --------- ------------------- ---------- ------------ - True OK OK - ``` - - Azure PowerShell については、下記公開情報をご確認ください。 - - > Install the Azure Az PowerShell module - > [https://docs.microsoft.com/ja-jp/powershell/azure/install-az-ps?view=azps-5.9.0](https://docs.microsoft.com/ja-jp/powershell/azure/install-az-ps?view=azps-5.9.0) - -6. 上記コマンド実施後、復旧対象 VM の OS ディスクの参照先が変更されていることを確認します。 - - ![](./noboot-recovery-unmanaged-disk/7.png) - -7. 復旧対象 VM を起動し、事象が解消されたかをご確認ください。 - -手順は以上となります。 +--- +title: 【非管理ディスク編】 復旧 VM を使った Windows VM の Noboot 復旧手順 +date: 2021-5-14 17:30:00 +tags: + - VM + - Windows + - Noboot +--- +> [!WARNING] +> 本記事は非管理ディスクに関する情報を掲載しておりますが、非管理ディスクについては 2022 年 9 月 13 日より非推奨となっております。 +> 非管理ディスクの完全な廃止は 2023 年 9 月 30 日を予定しておりますが、できる限り速やかに管理ディスクへの移行をご計画いただけますようお願い申し上げます。 +> なお、2023 年 9 月 30 日以降、新規の非管理ディスクの作成が不可となる予定です。本記事で紹介する手順が利用できなくなる可能性がございますことご留意いただけますよう重ねてお願い申し上げます。 +> +> 非管理ディスクの非推奨化/廃止に関する詳細は下記の公式ドキュメントをご確認ください。 +> **2025 年 9 月 30 日までに Azure アンマネージド ディスクを移行してください** +> [https://learn.microsoft.com/ja-jp/azure/virtual-machines/unmanaged-disks-deprecation](https://learn.microsoft.com/ja-jp/azure/virtual-machines/unmanaged-disks-deprecation) + +こんにちは。Azure テクニカル サポート チームの重田です。 +本記事では、Windows OS が起動しなくなる事象が発生した際に Windows OS の復旧手順を実施するために、起動ができない VM の OS ディスクを他の正常な VM にデータ ディスクとして接続する方法について紹介します。 + + + +Windows OS の復旧手順に関しては、Windows サポートチームのブログからご紹介しています。 +本記事では、[対処方法] 編に記載されている切り分け [3] - [6] を Azure 環境上でお試しいただく方法について紹介しています。 + +> **OS が起動しなくなる問題が発生した場合の対処方法について – 概要** +> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-OutLine/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-OutLine/) + +> **OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法** +> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/) + + +本記事では、**非管理ディスク**をご利用の環境用の手順を紹介します。管理ディスクをご利用の場合は、「[【管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順](https://jpaztech.github.io/blog/vm/noboot-recovery-managed-disk/)」をご確認ください。 + +--- + +## 概要 +1. 復旧対象 VM の OS ディスク VHD ファイルを複製します +2. 復旧作業用 VM にて、複製した VHD ファイルをデータ ディスクとしてアタッチします +3. 復旧作業用 VM にて、切り分けを実施します。 +4. 修復した VHD を Azure PowerShell にて現在の復旧対象 VM の VHD と差し替えます。 + +--- + +## 手順 + +### 1. 復旧対象 VM の OS ディスク VHD ファイルを複製します + +Azure Storage Explorer または AzCopy をご利用いただく方法にて、復旧対象 VM の OS ディスク VHD ファイルを複製します。 +　 +#### Azure Storage Explorer をご利用いただく場合 + +Azure Storage Explorer については、下記公開情報をご確認ください。 +> Azure Storage Explorer +> [https://azure.microsoft.com/ja-jp/features/storage-explorer/](https://azure.microsoft.com/ja-jp/features/storage-explorer/) + +1. 復旧対象 VM を停止 (割り当て解除) します。 +2. Azure Storage Explorer にて [ストレージ アカウント] - [<ストレージ アカウント名>] - [Blob Containers] - [vhds (コンテナ―名)] を開き、復旧対象 VM の OS ディスクの VHD を選択した状態で、[クローン] をクリックします。 + + ![](./noboot-recovery-unmanaged-disk/1.png) + +3. "BLOB を新しい名前で複製" 画面にて [<複製後の VHD 名>] を入力し、[複製] をクリックします。 + + ![](./noboot-recovery-unmanaged-disk/2.png) + +4. 複製が完了した際には Azure Storage Explorer の "アクティビティ" に "転送完了" のメッセージが表示されます。 + + ![](./noboot-recovery-unmanaged-disk/3.png) + +#### AzCopy をご利用いただく場合 + +AzCopy については、下記公開情報をご確認ください。 + +> AzCopy を使ってみる +> [https://docs.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-v10](https://docs.microsoft.com/ja-jp/azure/storage/common/storage-use-azcopy-v10) + + +1. 復旧対象 VM を停止 (割り当て解除) します。 +2. AzCopy コマンドを下記の通り実行します。 + 構文： + ```PowerShell + ./azcopy.exe copy "https://ストレージアカウント名.blob.core.windows.net/vhds/複製元のディスク名.vhd?SAS" "https://ストレージアカウント名.blob.core.windows.net/vhds/複製後のディスク名.vhd?SAS" --overwrite=prompt --s2s-preserve-access-tier=false --recursive + ``` + +### 2. 復旧作業用 VM にて、複製した VHD ファイルをデータ ディスクとしてアタッチします + +1. 復旧作業用の VM を作成します。 + Azure CLI を利用して az vm create コマンドに --use-unmanaged-disk オプションを指定することで作成が可能です。 + 詳細は下記のコマンドリファレンスをご確認ください。 + > az vm create + > [https://learn.microsoft.com/ja-jp/cli/azure/vm?view=azure-cli-latest#az-vm-create](https://learn.microsoft.com/ja-jp/cli/azure/vm?view=azure-cli-latest#az-vm-create) + +2. 複製した VHD ファイルをデータ ディスクとしてアタッチします。 + Azure Portal から [Virtual Machines] - [<復旧作業用の VM 名>] を開き、左メニュー "設定" の [ディスク] をクリックします。 +3. 開いた画面にて [+ データ ディスクの追加] をクリックします。 + + ![](./noboot-recovery-unmanaged-disk/4.png) + + [ソースの種類] を [既存の BLOB] とし、[ソース BLOB] を手順 2 にて複製した VHD を選択します。 + + ![](./noboot-recovery-unmanaged-disk/5.png) + + [OK] をクリックし、前の画面にて [保存] をクリックします。 + + ![](./noboot-recovery-unmsanaged-disk/6.png) + +4. 復旧作業用 VM に RDP 接続し、追加したデータ ディスクが認識されるかを確認します。 + +### 3. 復旧作業用 VM にて、切り分けを実施します + +下記 Windows OS 観点のブログに記載されている [3] - [6] をお試し下さい。 + +> OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法 +> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/) + +また、事象別のトラブルシューティングについては、下記公開情報に詳細が記載されています。併せてご確認ください。 + +> Azure 仮想マシンのブート エラーのトラブルシューティング +> [https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/boot-error-troubleshoot](https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/boot-error-troubleshoot) + +### 4. 修復した VHD を Azure PowerShell にて現在の復旧対象 VM の VHD と差し替えます + +1. Azure Portal より復旧作業用 VM を停止 (割り当て解除) します。 +2. Azure Portal から [Virtual Machines] - [<復旧作業用の VM 名>] を開き、左メニュー "設定" の [ディスク] をクリックします。 +3. データディスクをデタッチし、[保存] をクリックます。 +4. 復旧対象 VM を停止 (割り当て解除) されていることを確認します。 + +5. PowerShell にて下記コマンドを実行します。 + ```PowerShell + #VM 情報の取得 + $VM = Get-AzVM -ResourceGroupName リソースグループ名 -name 復旧対象 VM 名 + #VHD ファイルの内容を差し替え + $VM.StorageProfile.OsDisk.Vhd.Uri = "修復した VHD ファイルのパス" + #VM 情報の更新 + Update-AzVM –VM $VM –ResourceGroupName リソースグループ名 + ``` + 結果例： + ```PowerShell + RequestId IsSuccessStatusCode StatusCode ReasonPhrase + --------- ------------------- ---------- ------------ + True OK OK + ``` + + Azure PowerShell については、下記公開情報をご確認ください。 + + > Install the Azure Az PowerShell module + > [https://docs.microsoft.com/ja-jp/powershell/azure/install-az-ps?view=azps-5.9.0](https://docs.microsoft.com/ja-jp/powershell/azure/install-az-ps?view=azps-5.9.0) + +6. 上記コマンド実施後、復旧対象 VM の OS ディスクの参照先が変更されていることを確認します。 + + ![](./noboot-recovery-unmanaged-disk/7.png) + +7. 復旧対象 VM を起動し、事象が解消されたかをご確認ください。 + +手順は以上となります。 本記事が皆様のお役に立てれば幸いです。 \ No newline at end of file diff --git a/articles/vm/vm-operation.md b/articles/vm/vm-operation.md index 85c6768db7..d6e96a62c9 100644 --- a/articles/vm/vm-operation.md +++ b/articles/vm/vm-operation.md @@ -32,7 +32,7 @@ Azure 仮想マシンで予期せぬ問題が発生した際に、切り分け ## ■ 仮想マシンの再起動 -再起動は、**ゲスト OS の再起動** を実施する操作です。ゲスト OS として Graceful Shutdown ※1 を実施し、その後起動します。 +再起動は、**ゲスト OS の再起動** を実施する操作です。ゲスト OS として Graceful Shutdown を実施し、その後起動します。 Graceful Shutdown とは、仮想マシンをシャットダウンする際にシステム内部で決められた手順に従い正常に仮想マシンを終了させることを意味します。 再起動による物理ホスト サーバーの移動は発生しません。 ゲスト OS 内のプロセスが正常な状態となっていない場合の切り分けとして、再起動の実行をご案内しています。 diff --git a/articles/vm/vm-redeploy.md b/articles/vm/vm-redeploy.md index 6b7c373907..d42fa2fb2d 100644 --- a/articles/vm/vm-redeploy.md +++ b/articles/vm/vm-redeploy.md @@ -54,9 +54,9 @@ Azure 仮想マシンで接続不可などの問題が発生した際に、Azure ### ■ Azure PowerShell を利用して再デプロイを実施する こちらの手順では下記の PowerShell モジュールを使用しています。最新のモジュールについては各リンクをご確認ください。 ->- PowerShell 7.1 +>- PowerShell >([PowerShell をインストールする](https://docs.microsoft.com/ja-jp/powershell/scripting/install/installing-powershell)) ->- AzPowerShell 5.9.0 +>- AzPowerShell >([Azure PowerShell をインストールする](https://docs.microsoft.com/ja-jp/powershell/azure/install-az-ps)) diff --git a/articles/vm/vm-replica-1.md b/articles/vm/vm-replica-1.md index 463fcf8d88..dbfde283e0 100644 --- a/articles/vm/vm-replica-1.md +++ b/articles/vm/vm-replica-1.md @@ -40,15 +40,14 @@ Windows VM の場合「OS ディスクのスナップショットから VM を [https://docs.microsoft.com/ja-jp/troubleshoot/windows-server/backup-and-storage/windows-installations-disk-duplication](https://docs.microsoft.com/ja-jp/troubleshoot/windows-server/backup-and-storage/windows-installations-disk-duplication) >＝＝＝＝＝抜粋＝＝＝＝＝ ->複製またはイメージ化された Windows インストールを展開する場合は、イメージをキャプチャする前にシステム準備 (Sysprep) ツールを使用する必要があります。 +>When you deploy a duplicated or imaged Windows installation, it is required that the System Preparation (Sysprep) tool is used before the capture of the image. >＝＝＝＝＝＝＝＝＝＝＝＝ -- 参考: Azure Portal を使用して VHD から VM を作成する -[https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/create-vm-specialized-portal](https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/create-vm-specialized-portal) +- 参考: サポートされていないシナリオ - Sysprep (システム準備) の概要 +[https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview#unsupported-scenarios](https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview#unsupported-scenarios) >＝＝＝＝＝抜粋＝＝＝＝＝ ->複数の VM を作成する場合は、特殊化されたディスクを使用しないでください。 ->代わりに、より大規模なデプロイの場合は、イメージを作成してから、そのイメージを使用して複数の VM を作成します。 +>PC を一般化せずに Windows イメージを別の PC に移動またはコピーすることはサポートされていません。 >＝＝＝＝＝＝＝＝＝＝＝＝ --- diff --git a/articles/vm/windows-noboot-summary.md b/articles/vm/windows-noboot-summary.md index c824d63e90..8d902c28c5 100644 --- a/articles/vm/windows-noboot-summary.md +++ b/articles/vm/windows-noboot-summary.md @@ -1,224 +1,224 @@ ---- -title: Azure 上の Windows OS が起動しない場合の情報まとめ (2021 年 5 月 14 日更新版) -date: 2021-5-14 18:00:00 -tags: - - VM - - Windows - - Noboot ---- - -こんにちは。Azure テクニカル サポート チームの重田です。 -今回は、当サポートチームの旧ブログでご紹介しておりました Windows OS が起動しない (noboot) 場合の情報について、情報を更新した上で改めてご紹介いたします。 - -更新元の記事：[Azure 上の Windows OS が起動しない場合の情報まとめ (2018 年 8 月 27 日版)](https://jpaztech1.z11.web.core.windows.net/Azure%E4%B8%8A%E3%81%AEWindowsOS%E3%81%8C%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%AA%E3%81%84%E5%A0%B4%E5%90%88%E3%81%AE%E6%83%85%E5%A0%B1%E3%81%BE%E3%81%A8%E3%82%81(2018%E5%B9%B48%E6%9C%8827%E6%97%A5%E7%89%88).html) - - - -この Windows OS が起動しなくなる事象については、状況把握や復旧手段に関してご支援させていただいている際のポイントを、弊社 Windows サポートチームのブログからご紹介しています。 - -> **OS が起動しなくなる問題が発生した場合の対処方法について – 概要** -> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-OutLine/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-OutLine/) - -> **OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法** -> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/) - -なお、上記 Windows OS 観点のブログに記載されている [3] - [6] を Azure 環境上でお試しいただく方法については、下記の別記事で紹介しています。 - -> **管理ディスクの場合：** -> 【管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順 -> https://jpaztech.github.io/blog/vm/noboot-recovery-managed-disk/ - -> **非管理ディスクの場合：** -> 【非管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順 -> https://jpaztech.github.io/blog/vm/noboot-recovery-unmanaged-disk/ - -本記事では、Windows OS が起動しなくなる事象に関する Azure 観点での状況把握や復旧方法に関する Tips のまとめをご紹介します。 - - ---- - -## TIPS #1 ブート診断による画面確認 - -Windows VM ではブート診断を有効化していただくことで、Azure ポータル上から OS の画面ショットを見ることができます。 -RDP 接続が出来ない場合には、ブート診断を使ってどのような画面になっているか確認をしましょう。 -具体的な手順については、下記公開情報をご確認ください。 - -> ブート診断を使用して Azure の仮想マシンのトラブルシューティングを行う方法 -> [https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/boot-diagnostics](https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/boot-diagnostics) - - ---- - -## TIPS #2 Azure における復旧方法 - -Windows OS が起動しなくなる事象は原因追及が困難な場合が多く、対処方法を実施しても必ず Windows OS が起動できるようになる保証はないことをご注意下さい。 -最も確実な方法は **バックアップから復旧させる方法** になりますので、**定期的なバックアップのご取得** をご実施くださいますようお願いいたします。 - -もし、バックアップが存在しない場合には、上述の "[OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/)" にて記載されているような対処をお試しいただきます。 - -### ■ バックアップからリストアする - -#### Azure Backup -Azure Backup にて、VM のバックアップを取得しておけば、何かあった場合に正常時の状態からの復元が行える可能性が高いです。 -Azure Backup に関する公開情報をいくつかご紹介いたしますので、ご参考情報としてご確認いただけますと幸いです。 - -> Azure で仮想マシンをバックアップする -> [https://docs.microsoft.com/ja-jp/azure/backup/quick-backup-vm-portal](https://docs.microsoft.com/ja-jp/azure/backup/quick-backup-vm-portal) - -> Azure portal で Azure VM データを復元する方法 -> [https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms](https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms) - -> Azure VM バックアップのサポート マトリックス -> [https://docs.microsoft.com/ja-jp/azure/backup/backup-support-matrix-iaas](https://docs.microsoft.com/ja-jp/azure/backup/backup-support-matrix-iaas) - - -#### スナップショット -Azure Backup を使用できない場合は、ディスク リソースのスナップショットを取得し、有事の際にはそのスナップショットからディスクを復元する方法もあります。 -スナップショットの取得に関する詳細な手順に関しましては、下記の公開情報をご確認ください。 -なお、ディスクのスナップショットは、Azure Backup と異なり VM の稼働状態で取るとデータに不整合が発生する場合があります。 -スナップショットを作成する前に VM を停止することをお勧めします。 - -> ポータルまたは PowerShell を使用してスナップショットを作成する -> [https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/snapshot-copy-managed-disk](https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/snapshot-copy-managed-disk) -> ※ 管理ディスク用の手順になります。 - -#### OS ディスクのスワップ -ディスクを復元した際には、事象が発生した VM の OS ディスクと入れ替えることが可能です。 -詳細な手順は下記をご確認ください。 - -> VM の OS ディスクをスワップする -> [https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-windows#swap-the-os-disk-for-the-vm](https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-windows#swap-the-os-disk-for-the-vm) -> ※ 管理ディスク用の手順になります。 - - -### ■ 復旧用の VM を使って対応する - -起動ができない VM の OS ディスクを、他の正常な VM にデータ ディスクとして接続することで、当該 OS ディスクに対する操作が可能となります。 - -順序が前後しますが、"[OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/)" 内で紹介している "[3] SFC (System File Checker)、[4] regback を用いたレジストリ復旧、[5] 更新プログラムのアンインストール、[6] ファイルシステムの破損チェック" は、この方法で実施することができます。 - -Azure 側の具体的な手順に関しては、再掲となりますが、下記の別記事でご紹介していますので、ご利用環境に合わせてご確認ください。 - -> 【管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順 -> https://jpaztech.github.io/blog/vm/noboot-recovery-managed-disk/ - -> 【非管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順 -> https://jpaztech.github.io/blog/vm/noboot-recovery-unmanaged-disk/ - -なお、公開情報としては下記がございますのでご確認ください。 - -> Azure Portal から OS ディスクを復旧 VM にアタッチして Windows VM のトラブルシューティングを行う -> [https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-windows](https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-windows) - - -### ■ Windows の回復コンソールを使用する - -"[OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/)" 内で紹介している、"[1] スタートアップ修復、[2] Boot 構成情報の修正" を実施する場合、Windows の回復コンソールの立ち上げが必要となります。 -回復コンソールは、Azure 上からは直接操作ができませんので、Nested Hyper-V をご利用いただくか、VHD ファイルをオンプレミス環境にダウンロードし Hyper-V 環境を構築することで行います。 - -オンプレミス環境に Hyper-V 環境が無い場合、Azure での Nested Hyper-V 用 VM を一時的に作成するということが便利です。 -具体的な手順に関しては、下記ブログをご確認ください。 - -> Nested Hyper-V を使った VM の復旧 -> [https://docs.microsoft.com/en-us/archive/blogs/jpaztech/recover_vm_using_nested_hyperv](https://docs.microsoft.com/en-us/archive/blogs/jpaztech/recover_vm_using_nested_hyperv) - - -なお、オンプレミス環境で回復コンソールの立ち上げを実施する場合に関しても、オンプレミス環境で行う "Hyper-V 構築 → VHD のダウンロード → VM の起動" といった手順は、Nested Hyper-V を使った手順とほぼ同様となりますので、ご参考となれば幸いです。 - ---- - -## TIPS #3 バックアップ取得に関する Tips - -上述の通り、Windows OS としての対処をご実施いただいても、事象が 100％ 復旧するという保証はなく、最も確実な復旧方法はバックアップから復旧させる方法になります。 -バックアップからのリストアであれば、復旧までの時間がある程度予測できることも利点と言えます。 -復旧をより確実なものとするために、以下のような点についても心がけてください。 - -### ■ バックアップの基本: Azure Backup で複数世代のバックアップを保持する - -Windows OS が起動できないという状態に陥った場合、何らかの形で Windows OS のデータ (レジストリやファイル システム、ファイル システムのメタデータ) が破損してしまっている場合があります。 -このような場合において事例上少なくないのは、「バックアップを取得したその時点で、すでに何らかのデータが壊れてしまっていた」という状況です。 - -Azure Backup は、VM を止めずにバックアップを取得するができます。 -ただし、稼働中の OS は、起動時に必要なファイルの一部が破損しても、次の再起動までは走り続けることができるという場合があります。 - -#### Windows イメージに何らかの支障が発生した状態で稼働が続いているとどのようになるか - -「Windows VM を再起動したら、OS が正しく起動されなかった。OS の問題が起きているようなので、バックアップからリストアを行った。状況が改善しないため、何世代か前のバックアップを用いてリストアを複数試してみたが、どれをリストアしても同様に OS が正しく起動されない状態になってしまった。」といったシナリオになります。 - -もともと Windows OS 内のレジストリやファイル システムが破損していたがそのまま稼働していた場合、再起動時に問題が顕在化し、OS が正しく起動できない事象が発生します。 - -Azure Backup は「1 日ごとに 7 世代」といったポリシー設定に基づいて世代管理します。 -その枠内で無事復旧できるイメージがあればいいですが、そうではない場合、Azure Backup でも復旧できないシナリオもある、ということをご紹介します。 -稀で不運な事例ではありますが、リスクとしてご認識くださいますようお願いいたします。 - -### ■ ディスクのスナップショットを活用しよう - -VM を再起動して無事に Windows OS が起動できたことが保証できるタイミングまでを含めて確認いただくことが一番安全ではありますが、再起動なんて月に 1 度か、それ以下しかしない、という場合も勿論あります。 - -その場合には、「正常な状態の VM を停止し、OS ディスクのスナップショットを作成しておく」ことをお勧めします。 - -上述の通り、データに不整合がある状態になることを防ぐため、スナップショットを作成する前に VM を停止することをお勧めします。 -スナップショット作成のために、VM を停止 / 開始させることで、開始後に OS が正しく起動することを確かめることもできます。 -(ゲスト OS のシャットダウンを実施してから VM の停止をご実施いただくとより安全です。) -(OS 起動が確約されるのであれば、前のバージョンのスナップショットは削除しても問題ないので、1 世代分のスナップショットを保持すればよいということになります。) - -Windows OS にアプリケーションを追加したり、Windows Update を適用する、といったシステム変更に際してディスクのスナップショットを作成しておくと安心です。 - -#### 追加コストの話 - -スナップショットの課金形態や考え方は、非管理ディスクと管理ディスクで若干異なります。 -追加でコストが発生する部分となりますので、適切に理解をするため下記の通りご紹介します。 - - -#### 非管理ディスクのスナップショット - -非管理ディスクのスナップショットは、もとのディスク (VHD ファイル) のコピーではなく、その時点の差分データです。 -そのため、VHD ファイルを誤って削除してしまうと、スナップショットも削除されてしまうのでご注意ください。 -ただし課金の面では、差分の容量分のみが課金されます。 - -例: - -1. 元々の使用量が 30 GB のVHDでスナップショットを作成する。 - この時点ではスナップショットぶんの課金ゼロであり、30 GB の VHD の容量分のみの課金となる。 -2. VHD ファイル上に 1 GB の変更が加わる。 - この時点で以前のスナップショットとの差分で生じた 1 GB が加算された 31 GB ぶんの課金が発生する。 - -上記の詳細については、下記公開情報をご確認ください。 - -> Blob スナップショットの課金方法について -> [https://docs.microsoft.com/ja-jp/rest/api/storageservices/understanding-how-snapshots-accrue-charges](https://docs.microsoft.com/ja-jp/rest/api/storageservices/understanding-how-snapshots-accrue-charges) - -> Managed Disks の価格 -> [https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/](https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/) ->> <抜粋 (2021/5/14) > ->> Premium SSD Managed Disks の完全なスナップショットとイメージを Standard ストレージに格納できます。 ->>ローカル冗長 (LRS) とゾーン冗長 (ZRS) スナップショットのいずれかのオプションをお選びいただけます。 ->> Standard LRS と Standard ZRS どちらのオプションでも、これらのスナップショットとイメージはディスクの使用量に応じて月々 ¥5.600/GB で課金されます。 ->> たとえば、プロビジョニングされた容量が 64 GB のマネージド ディスクのスナップショットを作成し、実際に使用したデータ サイズが 10 GB だった場合、スナップショットは、使用したデータ サイズである 10 GB に対してのみ課金されます。 ->> Premium SSD マネージド ディスク ストレージに保存することを選択した場合、1 か月あたり ¥17.024/GB で課金されます。 - -#### 管理ディスクのスナップショット - -管理ディスクのスナップショットは、もとのディスク (VHD ファイル) の完全な複製です。 -そのため、スナップショットを作成した元のディスクを削除してもスナップショットは削除されず、スナップショットからディスクの作成 (復元) を実施することが可能です。 -課金の面では、スナップショット元のデータのコピーのため、実使用量分のデータが課金対象になります。 - -管理ディスクは、P10 (Premium, 128GiB) や S10 (Standard, 128GiB) といった決まったサイズごとに課金枠が決まっていますが、スナップショットはその中の実容量をベースに課金されます。 -つまり、128 GiB の VHD 中、10 GiB しか使われていなかったら、10 GiB 分のみがスナップショットの課金額となります。 - -なお、Premium ストレージのスナップショットを Standard ストレージに取る、ということも可能です。 -例えば、P10 の管理ディスクとそのスナップショット (Standard ストレージ) に取得する場合、[もとのディスクの料金 (P10)] と、[Standard スナップショットの容量別課金 × 使用している実容量 GiB] の課金が発生することとなります。 - -### ■ 参考資料 - -バックアップと高可用性、DR との違い、といった点も理解しておくことが重要です。 -高可用性環境なら、VM 1 台の OS が起動しなかった場合にも復旧のための時間的猶予が生まれます。 - -下記ブログのアーカイブにて、Azure において様々に存在するダウンタイムを避けるサービスについて紹介しておりますので、ご参考情報としてご参照下さい。 - -> Azure エンジニアが解説する落ちないサービス入門 -> [https://blogs.technet.microsoft.com/jpaztech/2018/05/29/aiming_no_downtime/](https://blogs.technet.microsoft.com/jpaztech/2018/05/29/aiming_no_downtime/) - - -本記事が皆様のお役に立てれば幸いです。 - +--- +title: Azure 上の Windows OS が起動しない場合の情報まとめ (2021 年 5 月 14 日更新版) +date: 2021-5-14 18:00:00 +tags: + - VM + - Windows + - Noboot +--- + +こんにちは。Azure テクニカル サポート チームの重田です。 +今回は、当サポートチームの旧ブログでご紹介しておりました Windows OS が起動しない (noboot) 場合の情報について、情報を更新した上で改めてご紹介いたします。 + +~~更新元の記事：Azure 上の Windows OS が起動しない場合の情報まとめ (2018 年 8 月 27 日版)~~ + + + +この Windows OS が起動しなくなる事象については、状況把握や復旧手段に関してご支援させていただいている際のポイントを、弊社 Windows サポートチームのブログからご紹介しています。 + +> **OS が起動しなくなる問題が発生した場合の対処方法について – 概要** +> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-OutLine/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-OutLine/) + +> **OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法** +> [https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/) + +なお、上記 Windows OS 観点のブログに記載されている [3] - [6] を Azure 環境上でお試しいただく方法については、下記の別記事で紹介しています。 + +> **管理ディスクの場合：** +> 【管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順 +> https://jpaztech.github.io/blog/vm/noboot-recovery-managed-disk/ + +> **非管理ディスクの場合：** +> 【非管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順 +> https://jpaztech.github.io/blog/vm/noboot-recovery-unmanaged-disk/ + +本記事では、Windows OS が起動しなくなる事象に関する Azure 観点での状況把握や復旧方法に関する Tips のまとめをご紹介します。 + + +--- + +## TIPS #1 ブート診断による画面確認 + +Windows VM ではブート診断を有効化していただくことで、Azure ポータル上から OS の画面ショットを見ることができます。 +RDP 接続が出来ない場合には、ブート診断を使ってどのような画面になっているか確認をしましょう。 +具体的な手順については、下記公開情報をご確認ください。 + +> ブート診断を使用して Azure の仮想マシンのトラブルシューティングを行う方法 +> [https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/boot-diagnostics](https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/boot-diagnostics) + + +--- + +## TIPS #2 Azure における復旧方法 + +Windows OS が起動しなくなる事象は原因追及が困難な場合が多く、対処方法を実施しても必ず Windows OS が起動できるようになる保証はないことをご注意下さい。 +最も確実な方法は **バックアップから復旧させる方法** になりますので、**定期的なバックアップのご取得** をご実施くださいますようお願いいたします。 + +もし、バックアップが存在しない場合には、上述の "[OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/)" にて記載されているような対処をお試しいただきます。 + +### ■ バックアップからリストアする + +#### Azure Backup +Azure Backup にて、VM のバックアップを取得しておけば、何かあった場合に正常時の状態からの復元が行える可能性が高いです。 +Azure Backup に関する公開情報をいくつかご紹介いたしますので、ご参考情報としてご確認いただけますと幸いです。 + +> Azure で仮想マシンをバックアップする +> [https://docs.microsoft.com/ja-jp/azure/backup/quick-backup-vm-portal](https://docs.microsoft.com/ja-jp/azure/backup/quick-backup-vm-portal) + +> Azure portal で Azure VM データを復元する方法 +> [https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms](https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms) + +> Azure VM バックアップのサポート マトリックス +> [https://docs.microsoft.com/ja-jp/azure/backup/backup-support-matrix-iaas](https://docs.microsoft.com/ja-jp/azure/backup/backup-support-matrix-iaas) + + +#### スナップショット +Azure Backup を使用できない場合は、ディスク リソースのスナップショットを取得し、有事の際にはそのスナップショットからディスクを復元する方法もあります。 +スナップショットの取得に関する詳細な手順に関しましては、下記の公開情報をご確認ください。 +なお、ディスクのスナップショットは、Azure Backup と異なり VM の稼働状態で取るとデータに不整合が発生する場合があります。 +スナップショットを作成する前に VM を停止することをお勧めします。 + +> ポータルまたは PowerShell を使用してスナップショットを作成する +> [https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/snapshot-copy-managed-disk](https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/snapshot-copy-managed-disk) +> ※ 管理ディスク用の手順になります。 + +#### OS ディスクのスワップ +ディスクを復元した際には、事象が発生した VM の OS ディスクと入れ替えることが可能です。 +詳細な手順は下記をご確認ください。 + +> VM の OS ディスクをスワップする +> [https://learn.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-windows#swap-the-failed-vms-os-disk-with-the-repaired-disk](https://learn.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-windows#swap-the-failed-vms-os-disk-with-the-repaired-disk) +> ※ 管理ディスク用の手順になります。 + + +### ■ 復旧用の VM を使って対応する + +起動ができない VM の OS ディスクを、他の正常な VM にデータ ディスクとして接続することで、当該 OS ディスクに対する操作が可能となります。 + +順序が前後しますが、"[OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/)" 内で紹介している "[3] SFC (System File Checker)、[4] regback を用いたレジストリ復旧、[5] 更新プログラムのアンインストール、[6] ファイルシステムの破損チェック" は、この方法で実施することができます。 + +Azure 側の具体的な手順に関しては、再掲となりますが、下記の別記事でご紹介していますので、ご利用環境に合わせてご確認ください。 + +> 【管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順 +> https://jpaztech.github.io/blog/vm/noboot-recovery-managed-disk/ + +> 【非管理ディスク編】復旧 VM を使った Windows VM の Noboot 復旧手順 +> https://jpaztech.github.io/blog/vm/noboot-recovery-unmanaged-disk/ + +なお、公開情報としては下記がございますのでご確認ください。 + +> Azure Portal から OS ディスクを復旧 VM にアタッチして Windows VM のトラブルシューティングを行う +> [https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-windows](https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-windows) + + +### ■ Windows の回復コンソールを使用する + +"[OS が起動しなくなる問題が発生した場合の対処方法について – 対処方法](https://jpwinsup.github.io/blog/2021/05/07/Performance/NoBoot/NoBoot-Solution/)" 内で紹介している、"[1] スタートアップ修復、[2] Boot 構成情報の修正" を実施する場合、Windows の回復コンソールの立ち上げが必要となります。 +回復コンソールは、Azure 上からは直接操作ができませんので、Nested Hyper-V をご利用いただくか、VHD ファイルをオンプレミス環境にダウンロードし Hyper-V 環境を構築することで行います。 + +オンプレミス環境に Hyper-V 環境が無い場合、Azure での Nested Hyper-V 用 VM を一時的に作成するということが便利です。 +具体的な手順に関しては、下記ブログをご確認ください。 + +> Nested Hyper-V を使った VM の復旧 +> [https://docs.microsoft.com/en-us/archive/blogs/jpaztech/recover_vm_using_nested_hyperv](https://docs.microsoft.com/en-us/archive/blogs/jpaztech/recover_vm_using_nested_hyperv) + + +なお、オンプレミス環境で回復コンソールの立ち上げを実施する場合に関しても、オンプレミス環境で行う "Hyper-V 構築 → VHD のダウンロード → VM の起動" といった手順は、Nested Hyper-V を使った手順とほぼ同様となりますので、ご参考となれば幸いです。 + +--- + +## TIPS #3 バックアップ取得に関する Tips + +上述の通り、Windows OS としての対処をご実施いただいても、事象が 100％ 復旧するという保証はなく、最も確実な復旧方法はバックアップから復旧させる方法になります。 +バックアップからのリストアであれば、復旧までの時間がある程度予測できることも利点と言えます。 +復旧をより確実なものとするために、以下のような点についても心がけてください。 + +### ■ バックアップの基本: Azure Backup で複数世代のバックアップを保持する + +Windows OS が起動できないという状態に陥った場合、何らかの形で Windows OS のデータ (レジストリやファイル システム、ファイル システムのメタデータ) が破損してしまっている場合があります。 +このような場合において事例上少なくないのは、「バックアップを取得したその時点で、すでに何らかのデータが壊れてしまっていた」という状況です。 + +Azure Backup は、VM を止めずにバックアップを取得するができます。 +ただし、稼働中の OS は、起動時に必要なファイルの一部が破損しても、次の再起動までは走り続けることができるという場合があります。 + +#### Windows イメージに何らかの支障が発生した状態で稼働が続いているとどのようになるか + +「Windows VM を再起動したら、OS が正しく起動されなかった。OS の問題が起きているようなので、バックアップからリストアを行った。状況が改善しないため、何世代か前のバックアップを用いてリストアを複数試してみたが、どれをリストアしても同様に OS が正しく起動されない状態になってしまった。」といったシナリオになります。 + +もともと Windows OS 内のレジストリやファイル システムが破損していたがそのまま稼働していた場合、再起動時に問題が顕在化し、OS が正しく起動できない事象が発生します。 + +Azure Backup は「1 日ごとに 7 世代」といったポリシー設定に基づいて世代管理します。 +その枠内で無事復旧できるイメージがあればいいですが、そうではない場合、Azure Backup でも復旧できないシナリオもある、ということをご紹介します。 +稀で不運な事例ではありますが、リスクとしてご認識くださいますようお願いいたします。 + +### ■ ディスクのスナップショットを活用しよう + +VM を再起動して無事に Windows OS が起動できたことが保証できるタイミングまでを含めて確認いただくことが一番安全ではありますが、再起動なんて月に 1 度か、それ以下しかしない、という場合も勿論あります。 + +その場合には、「正常な状態の VM を停止し、OS ディスクのスナップショットを作成しておく」ことをお勧めします。 + +上述の通り、データに不整合がある状態になることを防ぐため、スナップショットを作成する前に VM を停止することをお勧めします。 +スナップショット作成のために、VM を停止 / 開始させることで、開始後に OS が正しく起動することを確かめることもできます。 +(ゲスト OS のシャットダウンを実施してから VM の停止をご実施いただくとより安全です。) +(OS 起動が確約されるのであれば、前のバージョンのスナップショットは削除しても問題ないので、1 世代分のスナップショットを保持すればよいということになります。) + +Windows OS にアプリケーションを追加したり、Windows Update を適用する、といったシステム変更に際してディスクのスナップショットを作成しておくと安心です。 + +#### 追加コストの話 + +スナップショットの課金形態や考え方は、非管理ディスクと管理ディスクで若干異なります。 +追加でコストが発生する部分となりますので、適切に理解をするため下記の通りご紹介します。 + + +#### 非管理ディスクのスナップショット + +非管理ディスクのスナップショットは、もとのディスク (VHD ファイル) のコピーではなく、その時点の差分データです。 +そのため、VHD ファイルを誤って削除してしまうと、スナップショットも削除されてしまうのでご注意ください。 +ただし課金の面では、差分の容量分のみが課金されます。 + +例: + +1. 元々の使用量が 30 GB のVHDでスナップショットを作成する。 + この時点ではスナップショットぶんの課金ゼロであり、30 GB の VHD の容量分のみの課金となる。 +2. VHD ファイル上に 1 GB の変更が加わる。 + この時点で以前のスナップショットとの差分で生じた 1 GB が加算された 31 GB ぶんの課金が発生する。 + +上記の詳細については、下記公開情報をご確認ください。 + +> Blob スナップショットの課金方法について +> [https://docs.microsoft.com/ja-jp/rest/api/storageservices/understanding-how-snapshots-accrue-charges](https://docs.microsoft.com/ja-jp/rest/api/storageservices/understanding-how-snapshots-accrue-charges) + +> Managed Disks の価格 +> [https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/](https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/) +>> <抜粋 (2021/5/14) > +>> Premium SSD Managed Disks の完全なスナップショットとイメージを Standard ストレージに格納できます。 +>>ローカル冗長 (LRS) とゾーン冗長 (ZRS) スナップショットのいずれかのオプションをお選びいただけます。 +>> Standard LRS と Standard ZRS どちらのオプションでも、これらのスナップショットとイメージはディスクの使用量に応じて月々 ¥5.600/GB で課金されます。 +>> たとえば、プロビジョニングされた容量が 64 GB のマネージド ディスクのスナップショットを作成し、実際に使用したデータ サイズが 10 GB だった場合、スナップショットは、使用したデータ サイズである 10 GB に対してのみ課金されます。 +>> Premium SSD マネージド ディスク ストレージに保存することを選択した場合、1 か月あたり ¥17.024/GB で課金されます。 + +#### 管理ディスクのスナップショット + +管理ディスクのスナップショットは、もとのディスク (VHD ファイル) の完全な複製です。 +そのため、スナップショットを作成した元のディスクを削除してもスナップショットは削除されず、スナップショットからディスクの作成 (復元) を実施することが可能です。 +課金の面では、スナップショット元のデータのコピーのため、実使用量分のデータが課金対象になります。 + +管理ディスクは、P10 (Premium, 128GiB) や S10 (Standard, 128GiB) といった決まったサイズごとに課金枠が決まっていますが、スナップショットはその中の実容量をベースに課金されます。 +つまり、128 GiB の VHD 中、10 GiB しか使われていなかったら、10 GiB 分のみがスナップショットの課金額となります。 + +なお、Premium ストレージのスナップショットを Standard ストレージに取る、ということも可能です。 +例えば、P10 の管理ディスクとそのスナップショット (Standard ストレージ) に取得する場合、[もとのディスクの料金 (P10)] と、[Standard スナップショットの容量別課金 × 使用している実容量 GiB] の課金が発生することとなります。 + +### ■ 参考資料 + +バックアップと高可用性、DR との違い、といった点も理解しておくことが重要です。 +高可用性環境なら、VM 1 台の OS が起動しなかった場合にも復旧のための時間的猶予が生まれます。 + +下記ブログのアーカイブにて、Azure において様々に存在するダウンタイムを避けるサービスについて紹介しておりますので、ご参考情報としてご参照下さい。 + +> Azure エンジニアが解説する落ちないサービス入門 +> [https://blogs.technet.microsoft.com/jpaztech/2018/05/29/aiming_no_downtime/](https://blogs.technet.microsoft.com/jpaztech/2018/05/29/aiming_no_downtime/) + + +本記事が皆様のお役に立てれば幸いです。 +