Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Azure / Microsoft Azure, Windows Client, Windows Server, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019

Azure VM でネットワーク帯域制限をかける方法

by  •  • 0 Comments

VPN や ExpressRoute の帯域を特定のサーバーが食いつぶす時など、Azure VM であえてネットワークの帯域を制限したいという場合は、OS の QoS の機能を使いましょう。(逆に言えば、VPN Gateway や VNET 等の Azure 側で帯域制限をかける機能はありません)

以下のように、[gpedit.msc] – [コンピューターの構成] – [Windows の設定] – [ポリシー ベースの QoS] – [新規ポリシーの作成] から設定できます。

なお、受信方向の帯域制限は極めて限定的にしか出来ませんので、基本的には上記の QoS を大量の通信を発生させている送信元で設定する必要があります。どうしてもインバウンドの通信を制限したいという場合は、TCP のウインドウ サイズを絞ることができるので、それを使いましょう。(TCP の輻輳制御とか、ウインドウの概念は当然ご存知かと思いますが、知らない人は 3 分間 NetWorking を見て勉強しましょう)

※ 当然ですが、TCP のウインドウ サイズを制御するだけなので、以下のような制限が伴います。

  • TCP 以外のプロトコルは制御できません (無差別に送られてくる UDP パケットを抑えることはできません)
  • 帯域幅を明示的に制限できるわけではありません (受信用のバッファ サイズを 16  MB -> 1 MB -> 256 KB -> 64 KB と 4 段階で設定できるだけなので、xx Mbps といった制限はできません)
  • 帯域制御をおこなうトラフィックを細かく設定はできません (すべての受信トラフィックに対して一律で帯域幅が制限されます

以下のように、 [gpedit.msc] – [コンピューターの構成] – [Windows の設定] – [ポリシー ベースの QoS] – [QoS の詳細設定] から設定できます。

ということで、受信側で制限するのは無理があるので、送信側でアウトバウンドの通信を制限しましょう。OS の設定なので、Azureに限らずオンプレでも AWS とかの他社クラウドでも使えると思います。

P.S. ネットワークの最適化に関しては、Tech Summit 2018 のセッションがおすすめです。

PowerShell, Windows Azure / Microsoft Azure

Azure Automation で Invoke-WebRequest したあと Parse してくれない件

by  •  • 0 Comments

Azure Automation で wget したあと、プロパティが参照できなくて毎回同じ場所で時間を浪費してるのでメモ。

$Result = Invoke-WebRequest "http://www.contoso.com"
$Result.Links.href
Invoke-WebRequest : The response content cannot be parsed because the Internet Explorer engine is not available, or
Internet Explorer's first-launch configuration is not complete. Specify the UseBasicParsing parameter and try again.
At line:1 char:1
+ Invoke-WebRequest "https://bangumi.org/epg/td?broad_cast_date=2019031 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotImplemented: (:) [Invoke-WebRequest], NotSupportedException
+ FullyQualifiedErrorId : WebCmdletIEDomNotSupportedException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

UseBasicParsing を使って、最小限のパースだけで我慢しましょう。

$Result = Invoke-WebRequest "http://www.contoso.com" -UseBasicParsing
$Result.Links.href
Windows Azure / Microsoft Azure

Azure Front Door の SSL 証明書更新

by  •  • 0 Comments

Azure Front Dorr (通称 AFD) の SSL 証明書を更新したので、忘れないうちに手順を残しておきます。なお、証明書は AFD が払い出すものではなく、自前で持ち込むパターンです。

更新前の証明書は有効期間が 2019/05/29 までになっています。

今回、AFD のフロントエンド ホストには、DigiCert で発行した証明書を持ち込んでいますが、作成時に Key Vault (キー コンテナー) を作って配置してあるはずなので、当該コンテナにある対象の証明書に [新しいバージョン] として追加します。

Key Vault に証明書を追加したら、AFD のフロントエンド ホストで対象のホスト名を選択し、[キー コンテナー] – [シークレット] – [シークレット名] と順に選択します。最後のシークレット名で、Key Vault にインポートした証明書の [現在のバージョン] となっている最新のものを選択して [更新] し、最後に変更を [保存] しましょう。

以上で無事に更新でき、有効期限が 2020/07/02 に変更されたことが確認できました。(AFD は CDN のようにキャッシュを持つので、更新されない場合は 30 分くらい待てばいいと思います。今回は数分以内には更新されました。)

Key Vault の存在を忘れていなければ、特に難しくはないですね。

jpaztech, Windows Azure / Microsoft Azure

詳説 Azure ExpressRoute – Part5: ExpressRoute の増速やプロバイダー変更について

by  •  • 2 Comments

### 注釈ここから ###

本投稿は、Microsoft の TechNet Blog のリタイアに伴って、バックアップ目的で個人ブログに再投稿したものです。
リンク切れや内容にも多少の修正を加えていますが、情報が古い可能性があります。
(元記事)
https://blogs.technet.microsoft.com/jpaztech/2018/12/25/expressroute-deep-dive-part5/
(公式のバックアップ一覧)
Japan Azure IaaS Support Team Blog のバックナンバー #1
Japan Azure IaaS Support Team Blog のバックナンバー #2

### 注釈ここまで ###

こんにちは。Azure サポートの宇田です。
今回は ExpressRoute 回線の増速や、プロバイダー変更の際の手順についてご紹介いたします。

Read more →

jpaztech, Windows Azure / Microsoft Azure

詳説 Azure ExpressRoute – Part4: ExpressRoute の冗長構成について

by  •  • 1 Comment

### 注釈ここから ###

本投稿は、Microsoft の TechNet Blog のリタイアに伴って、バックアップ目的で個人ブログに再投稿したものです。
リンク切れや内容にも多少の修正を加えていますが、情報が古い可能性があります。
(元記事)
https://blogs.technet.microsoft.com/jpaztech/2018/11/20/expressroute-deep-dive-part4/
(公式のバックアップ一覧)
Japan Azure IaaS Support Team Blog のバックナンバー #1
Japan Azure IaaS Support Team Blog のバックナンバー #2

### 注釈ここまで ###

こんにちは。Azure サポートの宇田です。
今回は、ExpressRoute を複数ご契約いただく場合の留意点や、冗長構成の考慮点についてご説明します。

Read more →

jpaztech, Windows Azure / Microsoft Azure

ロードバランサーの診断ログが出力されない場合のチェックポイントについて

by  •  • 0 Comments

### 注釈ここから ###

本投稿は、Microsoft の TechNet Blog のリタイアに伴って、バックアップ目的で個人ブログに再投稿したものです。
リンク切れや内容にも多少の修正を加えていますが、情報が古い可能性があります。
(元記事)
https://blogs.technet.microsoft.com/jpaztech/2018/04/04/loadbalancer-troubleshooting3/
(公式のバックアップ一覧)
Japan Azure IaaS Support Team Blog のバックナンバー #1
Japan Azure IaaS Support Team Blog のバックナンバー #2

### 注釈ここまで ###

こんにちは。Azure サポートの宇田です。今回はロードバランサー (Basic) の診断ログが出力されない場合のチェックポイントについてご紹介します。

Azure におけるロードバランサーの挙動については、以下の投稿もあわせてご確認ください。

2021/07/08 追記

Basic SKU の外部ロードバランサーでは診断ログが利用できなくなりました。(元々、診断ログが正常に取得できないという既知の不具合情報がドキュメントに記載されていましたが、以下に抜粋する通知メールのとおり、最終的に診断ログの機能は廃止という結論になったようです。)

ログが必要な場合は、Standard SKU でメトリックの機能を活用しましょう。（以前から運用環境では Standard SKU が推奨になっています。）

TRACKING ID: 8NBV-BT0

You’re receiving this notice because you currently use the Azure Load Balancer with diagnostic logs configured with “Load Balancer Alert Events” and “Load Balancer Probe Health Status” categories.

The diagnostic log categories “Load Balancer Alert Events” and “Load Balancer Probe Health Status” are no longer functional and will be removed from the Azure Portal to prevent them from being enabled. They’re being removed from the REST API, Powershell, and CLI starting on 15 March 2021.

Upgrade to Standard to use the “All Metrics” category if you require logging. This will also unlock metrics and insights features. Find more information in our upgrade instructions and known issues page.

Read more →