Azure Stack Development Kit (Build 1.1809.0.90) がリリースされました

Azure Stack Development Kit (ASDK) の最新版である Build 1.1809.0.90 がリリースされました。

Azure Stack Development Kit Downloader から Build 番号の確認やダウンロードが可能です。

ASDK Build 1.1809.0.90 のリリースに伴い、リリースノートも対応した Build の内容に更新されています。

Microsoft Azure Stack Development Kit release notes | Microsoft Docs
https://docs.microsoft.com/en-us/azure/azure-stack/asdk/asdk-release-notes

Microsoft Azure Stack Development Kit – Build 1.1809.0.90 について (意訳)

新しい機能

今回のビルドで Azure Stack に関する改善点および修正点は次のとおり :

Azure Stack syslog クライアント (General Availability) : このクライアントを使用すると、Azure Stack インフラストラクチャに関連する監査、アラート、およびセキュリティログを Syslog サーバー、もしくは Azure Stack 外部のセキュリティ情報イベント管理 (SIEM) ソフトウェアに転送することが可能となっています。syslog クライアントは、syslog サーバがリッスンしているポートの指定をサポートしています。今回のリリースでは、syslog クライアントが GA として利用可能となり、運用環境で使用することが可能です。より詳細な情報は、Azure Stack syslog forwarding を参照してください。

修正された問題

ポータルでは、空き容量/使用容量を示すメモリチャートが正確になりました。作成可能な仮想マシン数をより確実に予測できるようになりました。
Azure Stack ユーザーポータルに仮想マシンを作成し、DS シリーズ VM に接続可能なデータディスク数が間違っているという問題を修正しました。DS シリーズの VM は、(パブリック) Azure 構成と同数のデータディスクを収容することができます。
次の Managed ディスクの問題について 1809 で修正されており、1808 Azure Stack Hotfix 1.1808.5.110 でも修正されています :
- SSD データディスクを Premium サイズの Managed ディスク仮想マシン (DS、DSv2、Fs、Fs_V2) にエラーが発生して失敗する問題を修正しました : Requested operation cannot be performed because storage account type ‘Premium_LRS’ is not supported for VM size ‘Standard_DS/Ds_V2/FS/Fs_v2).
- createOption: Attach を使用して管理対象ディスクのVMを作成する：次のエラーで失敗します : Long running operation failed with status ‘Failed’. Additional Info:’An internal execution error occurred.’ ErrorCode: InternalExecutionError ErrorMessage: An internal execution error occurred.この問題は修正されています。
Dynamic allocation メソッドを使用してデプロイされたパブリック IP が、Stop-Deallocate の発行後に保持されることが保証されないという問題を修正しました。現在は保持されています。
1808 以前に VM を停止済み (割り当て解除) (Stop-Deallocate) 状態にした場合、1808 アップデート後 VM を再割り当てすることはできませんでした。この問題は 1809 で修正されました。この状態にあって起動できなかったインスタンスは、この修正を持つ 1809 で開始することができます。この修正により、今回の問題が再発するのを防ぎます。
パフォーマンス、安定性、セキュリティ、および Azure Stack で使用されるオペレーティングシステムに対するさまざまな修正が行われています。

変更点

既知の問題

ポータル

すべてのサービスは、Azure Stack 管理およびユーザーポータルで、より多くのサービスを置き換えます。Azure ポータルでの操作と同じ方法で Azure Stack ポータル内をナビゲートする代わりに、すべてのサービスを使用できるようになりました。
Basic A 仮想マシンのサイズは、ポータルを介した仮想マシンスケールセット (VMSS) の作成は廃止されました。このサイズの VMSS を作成するには PowerShell 、もしくはテンプレートを使用します。

正常性と監視

- Health controller コンポーネントのアラートが表示される場合があります :
  - Alert #1:
    - NAME: Infrastructure role unhealthy
    - SEVERITY: Warning
    - COMPONENT: Health controller
    - DESCRIPTION: The health controller Heartbeat Scanner is unavailable. This may affect health reports and metrics.
  - Alert #2:
    - NAME: Infrastructure role unhealthy
    - SEVERITY: Warning
    - COMPONENT: Health controller
    - DESCRIPTION: The health controller Fault Scanner is unavailable. This may affect health reports and metrics.

どちらのアラートも無視しても問題ありません。

Azure Stack オペレーターが、メモリ不足のアラートを受信し、テナント仮想マシンが Fabric VM の作成エラーでデプロイできなかった場合、Azure Stack 内のリソースに利用可能なメモリがない可能性があります。 Azure Stack Capacity Planner を使用して、ワークロードで使用可能な容量について、理解する必要があります。

Compute

v2 サフィックスを含むサイズの VM をデプロイする : 例として Standard_A2_v2 の場合、サフィックスを Standard_A2_v2 (小文字の v) と指定する必要があります。Standard_A2_V2 (大文字の V) は使用しないようお願いします。これはグローバル Azure では動作しますが、Azure Stack では動作しません。
Azure Stack ポータルを用いて新しい仮想マシン (VM) を作成する際に VM サイズを選択した場合、USD/Month 列に Unavailable メッセージが表示されます。この列 (VM 価格設定列) を表示することは、Azure Stack では非サポートとなります。
1808 Update を適用した際、Managed ディスクを用いて VM をデプロイするときに次の問題が発生することがあります:
1. サブスクリプションが 1808 Update 以前に作成された場合、Managed ディスクを使用した VM のデプロイは失敗し、内部エラーメッセージが表示されることがあります。このエラーを解決するには、各サブスクリプションごとに以下の手順を実行します :
  1. テナントポータルでサブスクリプションに移動し、サブスクリプションを検索します。[Resource Providers]、[Microsoft.Compute]、[Re-register] の順番にクリックします。
  2. 同じサブスクリプション配下で、[Access Control (IAM)] に移動し、[Azure Stack-Managed Disk] が一覧表示されていることを確認します。
2. マルチテナント環境を設定した場合、ゲストディレクトリに関連付けられたサブスクリプションに VM をデプロイすると、内部エラーメッセージが表示されずに失敗することがあります。このエラーを解決するには、次の手順を実行します :
  1. 1808 Azure Stack Hotfix を適用します。
  2. この記事の手順にしたがい、各ゲストディレクトリを再構成します。
Add-AzsPlatformImage コマンドレットを使用する場合は、ディスクがアップロードされるストレージアカウントの URI として -OsUri パラメーターを使用する必要があります。ディスクのローカルパスを使用すると、コマンドレットは次のエラーで失敗します。長時間実行されている操作が状態 “Failed” で失敗しました。
SSD データディスクをプレミアムサイズの Managed Disk 仮想マシン (DS、DSv2、Fs、Fs_V2) に接続すると、エラーが発生して失敗します：Failed to update disks for the virtual machine ‘vmname’ Error: Requested operation cannot be performed because storage account type ‘Premium_LRS’ is not supported for VM size ‘Standard_DS/Ds_V2/FS/Fs_v2この問題を回避するには、Premium_LRS ディスクの代わりに Standard_LRS データディスクを使用してください。 Standard_LRS データディスクを使用しても、IOPS や課金コストは変更されません。
ポータルを使用して、プレミアム VM サイズ (DS、Ds_v2、FS、FSv2) で仮想マシン (VM) を作成すると、VM はスタンダードストレージアカウントで作成されます。スタンダードストレージアカウントでの作成は、機能的、IOP、または請求に影響を与えません。プレミアムディスクをサポートするサイズでストレージディスクを使用することを選択しました。: You’ve chosen to use a standard disk on a size that supports premium disks. This could impact operating system performance and is not recommended. Consider using premium storage (SSD) instead.
仮想マシン Scale Set (VMSS) 作成エクスペリエンスは、展開のオプションとして CentOS-based 7.2 を提供します。このイメージは Azure Stack では使用できないため、展開用に別の OS を選択するか、オペレーターが marketplace に展開する前にダウンロードした別の CentOS イメージを指定する ARM テンプレートを使用してください。
仮想マシンスケールセットのスケーリング設定は、ポータルでは使用できません。回避策として、Azure PowerShell を使用することができます。PowerShell バージョンの違いのため、-VMScaleSetName の代わりに -Name パラメーターを使用する必要があります。
VM イメージの作成に失敗すると、VM イメージ Compute ブレードに削除できない失敗したアイテムとして追加されることがあります。回避策として、Hyper-V (New-VHD -Path C:\dummy.vhd -Fixed-SizeBytes 1 GB) を使用して作成できるダミー VHD を使用して新しい VM イメージを作成します。このプロセスは、失敗したアイテムの削除を防止する問題を修正します。ダミーイメージを作成してから 15 分後に、正常に削除できます。以前に失敗した VM イメージを再ダウンロードすることができます。
VM のデプロイで拡張機能をプロビジョニングするのに時間がかかりすぎる場合、VM の割り当てを解除、もしくは削除するためにプロセスを停止しようとするのではなく、プロビジョニングのタイムアウトを許可する必要があります。
Linux VM 診断機能は、Azure Stack ではサポートされていません。VM 診断機能を有効にして Linux VM をデプロイすると、そのデプロイは失敗します。診断設定でLinux VM の基本メトリックを有効にすると、そのデプロイも失敗します。
サブスクリプション設定内で [Microsoft.Insight] リソースプロバイダーを登録し、ゲスト OS 診断を有効にした Windows VM を作成するばあい、VM 概要ページのCPU パーセンテージグラフはメトリックデータを表示できなくなります。VM の CPU パーセンテージチャートを検索するには、[メトリクス] ブレードに移動し、サポートされているすべての Windows VM ゲストメトリックを表示します。

Networking

[Networking] で、VPN 接続を作成するために [Create VPN Gateway] をクリックする場合、Policy Based が VPN の種類として表示されます。このオプションは選択できません。Azure Stack でサポートされているのは Route Based オプションのみです。
Azure Stack は、IP アドレスごとに単一のローカルネットワークゲートウェイをサポートします。これは、すべてのテナントサブスクリプションで当てはまります。最初のローカルネットワークゲートウェイ接続の作成後、同じ IP アドレスを持つローカルネットワークゲートウェイリソースを作成しようとする後続の試行はブロックされます。
DNS サーバーの設定が [自動] で作成された仮想ネットワークで、カスタム DNS サーバーへの変更が失敗します。更新された設定は、その Vnet の VM にプッシュされません。
Dynamic allocation メソッドを用いて展開されたパブリック IP は、Stop-Deallocate が発行された後も保持されることは保証されません。
Azure Stack Secret Rotation 中、パブリック IP アドレスが 2 ～ 5 分間到達不能な期間があります。
S2S VPN トンネルを用いてテナントが仮想マシンにアクセスしているシナリオにて、ゲートウェイがすでに作成された後にオンプレミスのサブネットがローカルネットワークゲートウェイに追加された場合、接続が失敗するシナリオが発生する可能性があります。

App Service

サブスクリプション内で最初の Azure Function を作成する前に、テナントで Storage リソースプロバイダーを登録する必要があります。
インフラストラクチャ (ワーカー、管理、フロントエンドの役割) をスケールアウトするには、Compute のリリースノートに記載されている PowerShell を使用する必要があります。