評価のトラブルシューティング - FAQ
この記事では、評価に関する問題のトラブルシューティングに関する最も一般的な質問に対する回答を示します。 評価に関する問題のトラブルシューティングと、評価のトラブルシューティングに関するサポートされるシナリオの記事を参照してください。
Azure VM の評価で、オンプレミスのものより大きい Azure ディスク SKU が推奨されるのはなぜですか?
Azure VM 評価では、評価の種類に基づいて、より大きいディスクが推奨される場合があります。
- ディスクのサイズ設定は、サイズ設定基準とストレージの種類という 2 つの評価プロパティに依存します。
- サイズ設定基準がパフォーマンスベースで、ストレージの種類が自動に設定されている場合は、ターゲット ディスクの種類 (Standard HDD、Standard SSD、Premium、または Ultra Disk) が識別されるときに、ディスクの IOPS とスループットの値が考慮されます。 その後、そのディスクの種類からディスク SKU が推奨され、この推奨ではオンプレミスのディスクのサイズ要件が考慮されます。
- サイズ設定基準がパフォーマンスベースで、ストレージの種類が Premium である場合、オンプレミスのディスクの IOPS、スループット、サイズの要件に基づいて、Azure の Premium ディスク SKU が推奨されます。 サイズ設定基準がオンプレミスで、ストレージの種類が Standard HDD、Standard SSD、Premium、または Ultra Disk である場合は、同じロジックを使ってディスクのサイズ設定が行われます。
たとえば、オンプレミスのディスクと 32 GB のメモリを使っていても、ディスクの読み取りと書き込みの集計 IOPS は 800 IOPS であるとします。 Azure VM 評価では、高い IOPS 要件のため、Premium ディスクが推奨されます。 また、必要な IOPS とサイズをサポートできるディスク SKU も推奨されます。 この例では、適合する最も近いものは P15 (256 GB、1100 IOPS) になります。 オンプレミスのディスクで必要なサイズは 32 GB でしたが、オンプレミスのディスクの高い IOPS 要件により、Azure VM 評価ではさらに大きいディスクが推奨されます。
評価レポートで一部またはすべての VM のパフォーマンス データが見つからないのはなぜですか?
パフォーマンスベースの評価では、Azure Migrate アプライアンスでオンプレミス VM のパフォーマンス データを収集できない場合、評価レポートのエクスポートに "PercentageOfCoresUtilizedMissing" または "PercentageOfMemoryUtilizedMissing" と表示されます。 次のことを確認します。
- 評価を作成している期間に VM の電源がオンになっていたかどうか。
- メモリ カウンターのみが存在せず、Hyper-V VM を評価しようとしている場合は、これらの VM で動的メモリが有効になっているかどうかを確認します。 現在、既知の問題のため、Azure Migrate アプライアンスでは、そのような VM のメモリ使用率を収集できません。
- すべてのパフォーマンス カウンターが不足している場合は、評価のためのポート アクセス要件が満たされていることを確認します。 VMware、Hyper-V、および物理評価のためのポート アクセス要件の詳細を参照してください。 いずれかのパフォーマンス カウンターを取得できない場合、Azure Migrate: 検出および評価はオンプレミスの割り当てられたコアまたはメモリにフォールバックし、それに応じて VM サイズが推奨されます。
Azure VM や Azure VMware Solution の評価レポートに、一部またはすべてのサーバーに関するパフォーマンス データがないのはなぜですか?
パフォーマンスベースの評価では、Azure Migrate アプライアンスでオンプレミス サーバーのパフォーマンス データを収集できない場合、評価レポートのエクスポートに PercentageOfCoresUtilizedMissing または PercentageOfMemoryUtilizedMissing と表示されます。 次のことを確認します。
評価を作成している期間にサーバーの電源がオンになっていたかどうか。
メモリ カウンターのみ取得されず、Hyper-V 環境内のサーバーを評価しようとしていたかどうか。 このシナリオでは、サーバーの動的メモリを有効にし、評価を再計算して最新の変更内容を反映させます。 アプライアンスは、サーバーで動的メモリが有効になっている場合にのみ、Hyper-V 環境内のサーバーのメモリ使用率値を収集できます。
すべてのパフォーマンス カウンターがない場合は、ポート 443 (HTTPS) での発信接続が許可されていることを確認します。
Note
いずれかのパフォーマンス カウンターを取得できない場合、Azure Migrate: Discovery and assessment はオンプレミスの割り当てられたコアまたはメモリにフォールバックし、それに応じて VM サイズが推奨されます。
Azure SQL の評価に、一部またはすべての SQL インスタンスまたはデータベースに関するパフォーマンス データがないのはなぜですか?
パフォーマンス データが確実に収集されるようにするには、次のことを確認します。
- 評価を作成している期間中に SQL サーバーの電源がオンになっていたかどうか。
- Azure Migrate で SQL エージェントの接続状態が接続済みかどうか、また、最後のハートビートも確認します。
- 検出された SQL インスタンス ウィンドウで、すべての SQL インスタンスの Azure Migrate の接続状態が接続済みかどうか。
- すべてのパフォーマンス カウンターがない場合は、ポート 443 (HTTPS) での発信接続が許可されていることを確認します。
パフォーマンス カウンターのいずれかが欠落している場合、Azure SQL 評価により、そのインスタンスまたはデータベースに対して最小限の Azure SQL 構成が推奨されます。
評価の信頼度レーティングが低いのはなぜですか?
信頼度のレーティングは、評価を計算するために必要な使用可能データ ポイントの割合に基づいて、パフォーマンスベースの評価に対して計算されます。 評価では、次の理由により、信頼度のレーティングが低くなる可能性があります。
評価を作成する期間について環境をプロファイルしなかった。 たとえば、パフォーマンス期間を 1 週間に設定した評価を作成する場合は、すべてのデータポイントが収集されるまで、検出を始めてから少なくとも 1 週間待つ必要があります。 その期間待つことができない場合は、パフォーマンス期間をより短い期間に変更し、評価を再計算します。
評価期間内に一部または全部のサーバーのパフォーマンス データを評価で収集できません。 高い信頼度レーティングを得るために、次のことを確認します。
- 評価期間中、サーバーの電源がオンになっている。
- ポート 443 でのアウトバウンド接続が許可されている。
- Hyper-V サーバーで、動的メモリが有効になっている。
- Azure Migrate のエージェントの接続状態が接続済みである。 また、最後のハートビートも確認します。
- Azure SQL 評価において、検出された SQL インスタンス ウィンドウで、すべての SQL インスタンスの Azure Migrate の接続状態が接続済みである。
評価を再計算し、信頼性評価に最新の変更を反映します。
Azure VM および Azure VMware Solution の評価では、検出の開始後に作成されたサーバーはほとんどありませんでした。 たとえば、過去 1 か月間のパフォーマンス履歴の評価を作成しているのに、ほんの 1 週間前にいくつかのサーバーが環境内に作成されたとします。 この場合、新しいサーバーのパフォーマンス データは期間全体を通しては利用できず、信頼度レーティングが低くなります。 詳細情報 を参照してください。
Azure SQL の評価の場合、検出が開始された後で、いくつかの SQL インスタンスまたはデータベースが作成されました。 たとえば、過去 1 か月間のパフォーマンス履歴の評価を作成しているのに、ほんの 1 週間前にいくつかの SQL インスタンスまたはデータベースが環境内に作成されたとします。 この場合、新しいサーバーのパフォーマンス データは期間全体を通しては利用できず、信頼度レーティングが低くなります。 詳細情報 を参照してください。
RAM 使用率が 100% を超えるのはなぜですか?
設計上、プロビジョニングされた最大メモリが VM で必要な量よりも少ない場合、Hyper-V では、評価によってメモリ使用率に 100% を超える値が表示されます。
オペレーティング システムのライセンスは Azure VM 評価に含まれていますか?
現在、Azure VM 評価では、Windows サーバーのオペレーティング システムのライセンス コストのみが考慮されます。 Linux サーバーのライセンス コストは現在は考慮されません。
Azure VM 評価ではパフォーマンス ベースのサイズ設定はどのように動作しますか?
Azure VM 評価では、オンプレミスのサーバーのパフォーマンス データを継続的に収集し、それを使って Azure で VM の SKU とディスクの SKU が推奨されます。 パフォーマンスベースのデータの収集方法の詳細については、こちらを参照してください。
Azure Migrate を使用してディスクを Ultra Disk に移行できますか?
不正解です。 現時点では、Azure Migrate と Azure Site Recovery の両方で、Ultra Disk への移行はサポートされていません。 Ultra ディスクのデプロイの詳細については、こちらを参照してください。
Ultra Disk でプロビジョニングされた IOPS とスループットがオンプレミスの IOPS とスループットを超えるのはなぜですか?
Ultra Disk は、公式価格のページに従い、プロビジョニングされたサイズ、プロビジョニングされた IOPS、プロビジョニングされたスループットに基づいて課金されます。 たとえば、20,000 IOPS および 1,000 MB/秒の 200 GiB Ultra Disk をプロビジョニングし、20 時間後に削除した場合、256 GiB のディスク サイズ プランにマップされます。 20 時間分の 256 GiB、20,000 IOPS、1,000 MB/秒に対して課金されます。
プロビジョニングされる IOPS = (検出されたスループット) * 1024/256
Ultra Disk の推奨事項では待機時間が考慮されますか?
いいえ。現時点では、サイズ設定とコスト計算には、ディスク サイズ、合計スループット、合計 IOPS が使用されます。
M シリーズで Ultra Disk がサポートされているのを確認できますが、Ultra Disk が推奨された評価では、"この場所に VM が見つかりません" と表示されます
Ultra Disk をサポートするすべての VM のサイズが、Ultra Disk でサポートされているすべてのリージョンに存在するとは限らないため、このようになる可能性があります。 ターゲット評価リージョンを変更して、このサーバーの VM サイズを取得します。
無効なプランで作成されたことを示す警告が評価で表示されるのはなぜですか?
無効になったプランで評価が作成されたため、[編集]と [再計算] のボタンは無効になっています。 従量課金制、開発テスト用の従量課金制、Enterprise Agreement のいずれかの有効なプランで新しい評価を作成することができます。 また、[割引 (%)] フィールドを使用して、Azure プランに加え、任意のカスタム割引を指定できます。 詳細情報 を参照してください。
非推奨となったターゲットの Azure の場所で作成されたことを示す警告が評価で表示されるのはなぜですか?
非推奨となった Azure リージョンで評価が作成されたため、[編集] と [再計算] のボタンは無効になっています。 有効なターゲットの場所であればどこでも、新しい評価を作成することができます。 詳細情報 を参照してください。
予約インスタンス、VM アップタイム、割引 (%) の無効な組み合わせで作成されたことを示す警告が評価で表示されるのはなぜですか?
[予約インスタンス] を選択すると、[割引 (%)] および [VM のアップタイム] プロパティは適用されません。 これらのプロパティの無効な組み合わせで評価が作成されたため、[編集] ボタンと [再計算] ボタンは無効になっています。 新しい評価を作成してください。 詳細情報 を参照してください。
一部の評価が "最新の評価バージョンにアップグレードされる" とマークされているのはなぜですか?
評価を再計算して、アップグレードされた Azure SQL 評価エクスペリエンスを表示し、Azure SQL Managed Instance、Azure VM 上の SQL Server、Azure SQL DB にわたる SQL デプロイに理想的な移行ターゲットを特定します。
- Azure のベスト プラクティスに従って、"Azure VM 上の SQL Server" にインスタンスを移行することをお勧めします。
- "適切なサイズのリフト アンド シフト" - サーバーを "Azure VM 上の SQL Server" へ。 SQL Server 資格情報を使用できない場合は、これをお勧めします。
- 1 つの評価で SQL デプロイ用の複数の移行ターゲットの対応性とコストの見積もりをカバーする強化されたユーザー エクスペリエンス。
再計算する前に、既存の評価をエクスポートすることをお勧めします。
物理サーバー上の一部のネットワーク アダプターのパフォーマンス データが表示されません
この問題は、物理サーバーで Hyper-V 仮想化が有効になっている場合に発生する可能性があります。 これらのサーバーでは、製品のギャップのため、Azure Migrate では現在、物理と仮想両方のネットワーク アダプターが検出されます。 ネットワーク スループットは、検出された仮想ネットワーク アダプターでのみキャプチャされます。
物理サーバーに対して推奨される Azure VM SKU が大きすぎます
この問題は、物理サーバーで Hyper-V 仮想化が有効になっている場合に発生する可能性があります。 これらのサーバーの場合、Azure Migrate では現在、物理と仮想両方のネットワーク アダプターが検出されます。 その結果、検出されたネットワーク アダプターの数が実際の数より多くなります。 Azure VM 評価によって必要な数のネットワーク アダプターをサポートできる Azure VM が選択されるため、これによりサイズが大きすぎる VM になる可能性があります。 ネットワーク アダプター数のサイズ変更への影響の詳細については、こちらを参照してください。 この製品のギャップは、今後対処されます。
物理サーバーの準備カテゴリが "準備ができていません" とマークされています
Hyper-V の仮想化が有効になっている物理サーバーの場合、準備カテゴリが誤って準備ができていませんとマークされることがあります。 これらのサーバーでは、製品のギャップのため、Azure Migrate では現在、物理と仮想両方のアダプターが検出されます。 その結果、検出されたネットワーク アダプターの数が実際の数より多くなります。 オンプレミスに合わせた評価とパフォーマンスベースの評価のどちらでも、Azure VM 評価によって必要な数のネットワーク アダプターをサポートできる Azure VM が選択されます。 ネットワーク アダプターの数が、Azure VM でサポートされている NIC の最大数である 32 を超えていると検出された場合、サーバーは準備ができていませんとマークされます。 NIC の数のサイズ設定への影響の詳細については、こちらを参照してください。
検出される NIC の数が、物理サーバーの実際の数より多くなります
この問題は、物理サーバーで Hyper-V 仮想化が有効になっている場合に発生する可能性があります。 これらのサーバーの場合、Azure Migrate では現在、物理と仮想両方のアダプターが検出されます。 その結果、検出された NIC の数が実際の数より多くなります。
ネットワーク トラフィックをキャプチャする
ネットワーク トラフィック ログを収集するには:
- Azure portal にサインインします。
- F12 キーを選択して開発者ツールを起動します。 必要な場合は、[ナビゲーション時にエントリをクリア] の設定をオフにします。
- [ネットワーク] タブを選択し、ネットワーク トラフィックのキャプチャを開始します。
- Chrome では、[Preserve log]\(ログの保持\) を選択します。 自動で記録が開始されるはずです。 赤い円は、トラフィックがキャプチャされていることを示しています。 赤い円が表示されない場合は、黒い円を選択して開始します。
- Microsoft Edge または Internet Explorer では、自動で記録が開始されるはずです。 開始されない場合は、緑色の再生ボタンを選択します。
- エラーを再現してみます。
- 記録中にエラーが発生したら、記録を停止し、記録されたアクティビティのコピーを保存します。
- Chrome では、右クリックして [Save as HAR with content]\(内容を HAR ファイルに保存する\) を選択します。 この操作により、ログが .har ファイルとして圧縮されエクスポートされます。
- Microsoft Edge または Internet Explorer で、[キャプチャしたトラフィックのエクスポート] オプションを選択します。 この操作により、ログが圧縮されてエクスポートされます。
- [コンソール] タブを選択し、いずれかの警告またはエラーを確認します。 コンソール ログを保存するには次の操作を行います。
- Chrome では、コンソール ログのどこかを右クリックします。 [名前を付けて保存] を選択し、ログをエクスポートして zip 圧縮します。
- Microsoft Edge または Internet Explorer では、エラーを右クリックして [すべてコピー] を選択します。
- 開発者ツールを閉じます。
評価でのオペレーティング システムのデータはどこから検出されますか?
- VMware VM の場合、既定では、vCenter Server によって提供されるオペレーティング システムのデータです。
- VMware Linux VM の場合は、アプリケーション検出が有効になっていると、OS の詳細はゲスト VM からフェッチされます。 評価に含まれる OS の詳細を確認するには、[検出済みサーバー] ビューに移動し、[オペレーティング システム] 列の値にマウス ポインターを合わせます。 ポップアップするテキストで、表示されている OS データが vCenter Server から収集されたものか、VM の資格情報を使用してゲスト VM から収集されたものかを確認できます。
- Windows VM の場合は、オペレーティング システムの詳細は常に vCenter Server からフェッチされます。
- Hyper-V VM の場合は、オペレーティング システムのデータは Hyper-V ホストから収集されます。
- 物理サーバーの場合は、サーバーからフェッチされます。