Azure VPN Gateway の死活監視


VPN Gateway をどうしても死活監視したい場合は、ドキュメントの隅にこっそり書いてある healthprobe の URL を使いましょう。

https://<VPN GW の IP>:8081/healthprobe

 

手順 7.Azure ゲートウェイの正常性プローブを確認する
1. 正常性プローブに移動します。
2. 証明書の警告を無視して続行します。応答を受け取った場合、VPN ゲートウェイは正常であると考えられます。
3. 応答を受け取らない場合、ゲートウェイが正常な状態にないか、またはゲートウェイ サブネット上の NSG が問題の原因になっている可能性があります。応答のサンプル テキストを次に示します。
<?xml version="1.0"?> Primary Instance: GatewayTenantWorker_IN_1 GatewayTenantVersion: 14.7.24.6</string>

そもそも VPN Gateway は内部で二台構成になっていて、片系が死んでも他方に切り替わるので、監視する意味は殆どないですけどね。(PaaS のクラウド サービスになれた人だと、「GatewayTenantWorker_IN_1」というのでピンときますよね。)

二台とも死んだ場合でないと、こちらの URL を監視しても意味はないので、おとなしく VPN のトンネル (Main Mode SA, Quick Mode SA) が張れているかを確認したり、VPN 経由で疎通できるかという観点で監視をしましょう。

healthprobe はあくまでも VPN Gateway のインスタンスが生きているかの確認しかできないですし、Port が 8081 なことからもお察しのように、IKE (UDP/500) の通信自体をチェックできるわけではありません。SA の rekey に失敗した等で VPN が切れた際とかは当然検知できませんので、これはあくまでも VPN Gateway の Active なインスタンスが OS として正常かのチェック用途にどうぞ。

2 台とも死んでいて healthprobe に応答がないなんて事が万が一あった場合は、VPN Gateway のリセットを 2 回と、サイズ変更 (Basic -> Standard -> Basic 等) をして、復旧するか確認しましょう

  • VPN Gateway のリセット
    https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-resetgw-classic

 


Azure の仮想ネットワークが削除出来ない件


クラシック環境の仮想ネットワーク (VNET) が消せないというのを定期的に見かけるので、ありがちなパターンをまとめておきます。

  • この仮想ネットワークは使用中であるため、削除できません。リソースを最近削除した場合は、仮想ネットワークが更新されるまで時間がかかることがあります。
  • 操作 ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ が失敗しました: ”test’ の使用中に仮想ネットワークを削除または変更することはできません。’。
  • リソース グループ xxxxx を削除できませんでした: 識別子 ‘Microsoft.ClassicNetwork/virtualNetworks/xxxx’ のリソースを削除できなかったため、リソース グループ ‘xxxxx’ の削除に失敗しました。このリソース グループのプロビジョニング状態はロールバックされます。追跡 ID は ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ です。詳細については、監査ログを参照してください。 (コード: ResourceGroupDeletionBlocked) 操作 ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ が失敗しました: ”test’ の使用中に仮想ネットワークを削除または変更することはできません。’。 (コード: OperationFailed)
  • リソース グループ xxxxx を削除できませんでした: 識別子 ‘Microsoft.ClassicNetwork/virtualNetworks/xxx’ のリソースを削除できなかったため、リソース グループ ‘xxxxx’ の削除が許容時間内に完了しませんでした。このリソース グループのプロビジョニング状態はロールバックされます。追跡 ID は ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ です。詳細については、監査ログを参照してください。 (コード: ResourceGroupDeletionTimeout) 操作 ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ が失敗しました: ”test’ の使用中に仮想ネットワークを削除または変更することはできません。’。 (コード: OperationFailed)

基本的には、ポータルから見えない何らかのリソースのゴミが残っているパターンが殆どなので消しましょう。

  • VM / Cloud Service のインスタンスが残存 (さすがにこれは気づくはず…)
  • VPN 用の仮想ネットワーク ゲートウェイが残存
  • ExpressRoute 用の仮想ネットワーク ゲートウェイが残存
  • Application Gateway が残存
  • Azure RemoteApp が残存
  • AppService Environment が残存

Azure PowerShell で以下を実行して何が残っているのかを確認し、不要なリソースは削除しましょう。
あと、クラシックは依存関係が強いので、残存リソースの削除後は少し待ってから VNET を消すのをお勧めします。

# Azure PowerShell をインストールしていない場合は、最新版の msi を入れてください
# https://github.com/Azure/azure-powershell/releases?after=clu-2016012142

# ログイン
Add-AzureAccount

# サブスクリプション選択
# 参考: https://blogs.msdn.microsoft.com/dsazurejp/2013/12/06/id-id/
Select-AzureSubscription -SubscriptionId "サブスクリプション ID"

# 残存している VPN Gateway を確認
Get-AzureVirtualNetworkGateway

<#
GatewayId : d360f9a9-3c1a-454e-ae5f-d9e2677fb165 <== 削除時に指定する GatewayId
GatewayName : Default
LastEventData :
GatewayType : DynamicRouting
LastEventTimeStamp : 2018/01/15 23:44:42
LastEventMessage : Successfully configured the gateway.
LastEventID : 23005
State : Provisioned <== NotProvisioned は無視してよいので、Provisioned のものを探す
VIPAddress : 52.230.68.115
DefaultSite :
GatewaySKU : Standard
Location : Southeast Asia
VnetId : d360f9a9-3c1a-454e-ae5f-d9e2677fb165
SubnetId :
EnableBgp : False
Asn : 0
BgpPeeringAddress :
PeerWeight : 0
OperationDescription :
OperationId :
OperationStatus :
#>

# VPN Gateway が残存している場合は削除
Remove-AzureVirtualNetworkGateway -GatewayId "上記で確認した GatewayId"

# ExpressRoute Gateway を確認
((Get-AzureVNetConfig).XMLConfiguration).NetworkConfiguration.VirtualNetworkConfiguration.VirtualNetworkSites.VirtualNetworkSite.name | foreach{echo "VNetName: $_"; Get-AzureVNetGateway -VNetName $_}

<#
VNetName: test
LastEventData :
LastEventTimeStamp : 2018/01/16 10:12:26
LastEventMessage : Successfully created a gateway for the following virtual network: test
LastEventID : 23002 State : Provisioned
VIPAddress : 13.73.17.147
DefaultSite : 
GatewaySKU : Default
OperationDescription : Get-AzureVNetGateway
OperationId : ab493757-5fa3-3a92-a173-50b82e73279a
OperationStatus : Succeeded
#>
# ExpressRoute Gateway が残存している場合は削除
Remove-AzureVNetGateway -VNetName "上記で確認した VNET 名"

# Application Gateway を確認
Get-AzureApplicationGateway

# Application Gateway が残存している場合は削除
Remove-AzureApplicationGateway -Name "上記で確認した AppGW 名"
# Azure RemoteApp のコレクションを確認
Get-AzureRemoteAppCollection | select Name

# Azure RemoteApp が残存している場合は削除
Remove-AzureRemoteAppCollection -CollectionName "コレクション名"

# ASE は詳しくないので割愛

それから、ARM への移行操作中もエラーになった気がします。Validate や Prepare したままのリソースは、Abort してから削除しましょう。

Move-AzureNetworkSecurityGroup -NetworkSecurityGroupName "NSG 名" -Abort
Move-AzureReservedIP -ReservedIPName "Reserved IP 名" -Abort
Move-AzureRouteTable -RouteTableName "UDR 名" -Abort
Move-AzureService -ServiceName "クラウド サービス名" -DeploymentName "VM 名" -Abort
Move-AzureStorageAccount -StorageAccountName "ストレージ アカウント名" -Abort
Move-AzureVirtualNetwork -VirtualNetworkName "VNET 名" -Abort

移行については以下も参照。

クラシック ポータルもリタイアしたことですし、これを機にクラシックの VM は全部 ARM に移して掃除しましょう。

そもそもクラシック環境は IaaS を前提に作られていないですし。(Azure は PaaS から始まっているのを知らない人も増えたんだろうなぁ…。)


vPro 対応の NUC7i5DNHE を買ってみた


どうも、NUC マニアです。久々にマシンが増えました。

Intel 先生が 2 世代に一度くらいのペースでしかリリースしてくれない貴重な vPro / AMT 対応 NUC です。型番は NUC7i5DNHE (NUC7i5DNKE もありますが、国内未発売っぽい) で、アキバの Ark さんのみ取り扱いを確認。

ちなみに、過去に vPro / AMT 対応だった DC53427HYE と NUC5i5MYHE も 4 台ずつ積みあがってます。

で、今回の構成はこちら。大体 1 セット 13 万くらい?

付属品はこんな感じ。

電源コードは相変わらず 3 pin のミッキーでした。
今回はケーブルもちゃんと同梱されているものの、ケーブル長が 50 cm しかないので短めです。

電源ボタンは上部から正面に移ったので、これからは NUC を大量に積み重ねても安心!

miniDP から HDMI x2 になったのも個人的にはうれしい限りです。
あと、lid 用のスロットも健在なので、拡張ボードもさせる模様。(この辺とか)

ちゃんとケンジントンロックもあります。

SATA と電源のケーブルが短いので、外さないと開腹ができない感じです。
今回から vPro NUC にも WiFi / BT が標準搭載されました。(個人的には不要なので安くしてほしい。)

メモリと SSD を搭載。

 

で、OS をインストールするわけなんですが、NVMe のおかげで 3 分で完了。
組み上げて OS を入れるまで 30 分かからないくらいで終わりました。

 

以下、雑なベンチ結果とか貼っておきます。

  • CINEBENCH
  • CrystalDiskMark 6.0.0
    (SSD 自体はもうちょっと性能出そうな気がする…)

    ———————————————————————–
    CrystalDiskMark 6.0.0 x64 (C) 2007-2017 hiyohiyo
    Crystal Dew World : https://crystalmark.info/
    ———————————————————————–
    * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
    * KB = 1000 bytes, KiB = 1024 bytesSequential Read (Q= 32,T= 1) : 1838.118 MB/s
    Sequential Write (Q= 32,T= 1) : 1617.923 MB/s
    Random Read 4KiB (Q= 8,T= 8) : 1025.103 MB/s [ 250269.3 IOPS]
    Random Write 4KiB (Q= 8,T= 8) : 1054.540 MB/s [ 257456.1 IOPS]
    Random Read 4KiB (Q= 32,T= 1) : 679.381 MB/s [ 165864.5 IOPS]
    Random Write 4KiB (Q= 32,T= 1) : 631.597 MB/s [ 154198.5 IOPS]
    Random Read 4KiB (Q= 1,T= 1) : 46.962 MB/s [ 11465.3 IOPS]
    Random Write 4KiB (Q= 1,T= 1) : 190.586 MB/s [ 46529.8 IOPS]Test : 1024 MiB [C: 4.5% (21.0/465.2 GiB)] (x5) [Interval=5 sec]
    Date : 2018/01/14 14:59:36
    OS : Windows Server 2016 Datacenter (Full installation) [10.0 Build 14393] (x64)
  • デバイス マネージャー
    Windows Server 2016 を入れた直後の状態がこちら。TPM 2.0 を積んでるので、BitLocker とかも安心。
    (ちなみに、メーカー的には Windows 10 系のみサポートらしいので要注意。)

    あと、有線 NIC は認識するものの、WiFi/BT は Windows Server は「ワイヤレス LAN サービス」の機能を有効化して、個別にドライバー入れないとダメでした。(一個だけ不明なデバイス扱いで残りましたが、MS_BTHPAN なので Bluetooth の PAN 関連と思われ、別に不要なので放置。未検証ですが、Windows 10 なら多分すんなり入るんじゃないかな。)
  • msinfo32

 

AMT もブート時に Ctrl + P でログインして IP とかを設定したら、無事につながりました。
これで VNC 経由でコンソールをとれるようになるので、リモート管理も楽チンですわ。

一か月くらい検証して、問題なければあと 3 台買い増す予定。


Azure の IP アドレスかを PowerShell でチェックする


Azure の IP アドレスに含まれるか (+ どこのリージョンか) を表示してくれるスクリプトです。
以前つくったあとブログを書いてなかった気がするので、だいぶ今更ですが。

Azure の Datacenter IP Ranges は以下で公開されていますが、Details 欄に記載の通り変更される事があるので、都度最新の xml を拾ってくる作りにしています。

PS> Check-AzureIpAddress.ps1 -IpAddress 13.78.0.1
13.78.0.1 is in Azure japaneast region.

PS> Check-AzureIpAddress.ps1 -IpAddress 203.0.113.1
203.0.113.1 is not in Azure.

Azure PowerShell のジョブ実行


先ほどのログイン自動化に続いて、Azure PowerShell 4.4.0 以降で使える便利な TIPS をもう一つ。

各コマンドレットに AzureRmContext というオプションが追加されて、PSJob 内に認証情報を渡せるようになっています。

Start-Job {

   # ArgumentList で渡した Context を引数 ($ctx) として使用して、
    param ($ctx)

    # 並列実行したいコマンドを $ctx の認証情報で実行
    Get-AzureRMVM -AzureRmContext $ctx

} -ArgumentList (Get-AzureRmContext)


# ジョブの一覧を表示
Get-Job

Id     Name            PSJobTypeName   State         HasMoreData     Location             Command
--     ----            -------------   -----         -----------     --------             -------
1      Job1            BackgroundJob   Completed     True            localhost            ...


# ジョブの実行結果を表示 (↑で State が Running の場合は待つべし)
Receive-Job 1 # Job ID

ResourceGroupName       Name  Location VmSize OsType NIC ProvisioningState Zone
-----------------       ----  -------- ------ ------ --- ----------------- ----
SHUDA1215         shuda1215a japaneast                           Succeeded
SHUDA1215         shuda1215b japaneast                           Succeeded
SHUDA1221         shuda1221a japaneast                           Succeeded
SHUDA1221         shuda1221b japaneast                           Succeeded

これの何がうれしいかというと、PSJob を使いこなすことで時間のかかるコマンドをパラレル実行できるようになるので、作成に時間のかかるリソース (Gateway とか) を複数作るときや、サブスクリプションをまたいで並列処理をしたいときに大変はかどります。

例えば、こんな感じでサブスクリプションを切り替えて、全サブスクリプションの VM 一覧を取得したりとか。

Get-AzureRmSubscription | foreach{

    # サブスクリプションを切り替えて
    Select-AzureRmSubscription -SubscriptionId $_.SubscriptionID

    # ジョブを実行
    Start-Job{
        param($ctx)

        Get-AzureRmVM -AzureRmContext $ctx
    } -ArgumentList (Get-AzureRmContext)
}

# 各サブスクリプションに対してジョブが実行される
Get-Job

Id     Name            PSJobTypeName   State         HasMoreData     Location             Command
--     ----            -------------   -----         -----------     --------             -------
1      Job1            BackgroundJob   Completed     True            localhost            ...
3      Job3            BackgroundJob   Completed     True            localhost            ...
5      Job5            BackgroundJob   Completed     True            localhost            ...
7      Job7            BackgroundJob   Completed     True            localhost            ...
9      Job9            BackgroundJob   Completed     True            localhost            ..

ということで、去年までは「口を動かす前に、手を動かせ」が口癖でしたが、今年は手を動かす手間さえも省きたいと思います。

 


Azure PowerShell (ARM) で毎回ログインしなくて済む方法


Azure PowerShell で毎回ログイン (Login-AzureRmAccount) するの面倒ですよね。

Ver 4.4.0 (Ignite Release) から認証情報を保存できるコマンドレットが増えてるので、皆さん今すぐ使ってください。

Enable-AzureRmContextAutosave
Login-AzureRmAccount #一回だけログインすれば、以降は保存した Context を使ってくれます。

以上。

P.S. Azure PowerShell は月に一度くらいの頻度で更新されるので、毎月リリース情報チェックして最新版にしましょう。