信頼性に関する推奨事項
Azure Advisor を使用して、ビジネスに不可欠なアプリケーションの継続稼働を保証し、さらに向上させることができます。 信頼性に関する推奨事項は、Advisor ダッシュボードの [信頼性] タブで得ることができます。
Azure Portal にサインインします。
任意のページから [Advisor] を検索して選択します。
Advisor ダッシュボードで、[信頼性] タブを選びます。
AI サービス
2 GB のストレージ クォータを超えようとしています。 Standard Search サービスを作成します
2 GB のストレージ クォータを超えようとしています。 Standard Search サービスを作成します。 ストレージ クォータを超えると、インデックス作成操作の機能は停止します。
詳細については、「Azure AI Search におけるサービスの制限」を参照してください。
50 MB のストレージ クォータを超えようとしています。 Basic または Standard Search サービスを作成します
50 MB のストレージ クォータを超えようとしています。 Basic または Standard Search サービスを作成します。 ストレージ クォータを超えると、インデックス作成操作の機能は停止します。
詳細については、「Azure AI Search におけるサービスの制限」を参照してください。
使用可能なストレージ クォータを超えようとしています。 さらにストレージが必要な場合はパーティションを追加します
使用可能なストレージ クォータを超えようとしています。 さらにストレージが必要な場合はパーティションを追加します。 ストレージ クォータを超えても、引き続きクエリを実行できますが、インデックス作成操作は機能しなくなります。
詳細については、「Azure AI Search におけるサービスの制限」を参照してください
このリソースのクォータ超過
リソースのクォータが超過したことが検出されました。 まもなく自動的に補充されるのでそれまで待つこともできますが、リソースをブロック解除してすぐに再使用する場合は、有料 SKU にアップグレードできます。
Cognitive Service - CognitiveServiceQuotaExceeded (このリソースのクォータ超過) に関する詳細を確認してください。
アプリケーションをアップグレードして Azure OpenAI から最新の API バージョンを使用する
以前の API バージョンで使用されている Azure OpenAI リソースがあることが検出されました。 最新の機能を活用するには、最新の REST API バージョンを使用してください。
Cognitive Service - CogSvcApiVersionOpenAI (アプリケーションをアップグレードして Azure OpenAI から最新の API バージョンを使用する) に関する詳細を確認してください。
アプリケーションをアップグレードして Azure OpenAI から最新の API バージョンを使用する
以前の API バージョンで使用されている Azure OpenAI リソースがあることが検出されました。 最新の機能を活用するには、最新の REST API バージョンを使用してください。
Cognitive Service - API バージョン: OpenAI (アプリケーションをアップグレードして Azure OpenAI から最新の API バージョンを使用する) に関する詳細を確認してください。
分析
Ubuntu 16.04 が実行されているクラスターはサポート対象外です
HDInsight クラスターで Ubuntu 16.04 LTS が引き続き使用されていることを検出しました。 2022 年 11 月 30 日以降、Ubuntu 16.04 LTS 上の Azure HDInsight クラスターのサポートは終了しています。 既存のクラスターはそのまま動作しますが、Microsoft からのサポートはありません。 最新のイメージを使用してクラスターを再構築することをご検討ください。
HDInsight クラスター - ubuntu1604HdiClusters (Ubuntu 16.04 を実行しているクラスターはサポート対象外) に関する詳細を確認してください。
HDInsight クラスターをアップグレードする
お使いのクラスターで最新のイメージが使われていないことが検出されました。 最新バージョンの HDInsight イメージを使用して、オープンソース更新プログラム、Azure 更新プログラム、セキュリティ修正プログラムを最大限に活用することをお勧めします。 HDInsight のリリースは、30 日から 60 日ごとに行われます。 最新リリースに移行することを検討してください。
HDInsight クラスター - upgradeHDInsightCluster (HDInsight クラスターのアップグレード) に関する詳細を確認してください。
お使いのクラスターは 1 年前に作成されました
お使いのクラスターは 1 年前に作成されたものであることが検出されました。 ベスト プラクティスの一部として、最新の HDInsight イメージを使用して、オープンソース更新プログラム、Azure 更新プログラム、セキュリティ修正プログラムを最大限に活用することをお勧めします。 クラスターのアップグレードに推奨される最大期間は、6 か月未満です。
HDInsight クラスター - clusterOlderThanAYear (クラスターは 1 年前に作成された) に関する詳細を確認してください。
Kafka クラスター ディスクがほぼいっぱいです
HDInsight クラスターで Kafka ブローカーによって使用されるデータ ディスクはほぼいっぱいです。 それが発生すると、ディスク不足のエラーのために Apache Kafka ブローカー プロセスが起動できず、失敗します。 軽減するには、すべての Kafka トピックの保持時間を見つけ、古いファイルをバックアップし、ブローカーを再起動してください。
HDInsight クラスター - KafkaDiskSpaceFull (Kafka クラスター ディスクがほぼいっぱいです) に関する詳細を確認してください。
カスタム仮想ネットワークでのクラスターの作成には、より多くのアクセス許可が必要です
カスタム仮想ネットワークを持つクラスターは、仮想ネットワーク参加アクセス許可なしで作成されました。 作成操作を実行するユーザーが、2023 年 9 月 30 日より以前に Microsoft.Network/virtualNetworks/subnets/join のアクションに対する権限を持っていることを確認してください。
HDInsight クラスター - EnforceVNetJoinPermissionCheck (カスタム VNet でのクラスターの作成にはより大きな権限が必要) に関する詳細を確認してください。
HDInsight 4.0 Kafka クラスターでの Kafka 1.1 の非推奨化
2020 年 7 月 1 日以降、HDInsight 4.0 で Kafka 1.1 を使用して新しい Kafka クラスターを作成することはできません。 既存のクラスターはそのまま動作しますが、Microsoft からのサポートはありません。 システムやサポートが中断される可能性を回避するため、2020 年 6 月 30 日までに HDInsight 4.0 で Kafka 2.1 に移行することを検討してください。
HDInsight クラスター - KafkaVersionRetirement (HDInsight 4.0 Kafka クラスターでの Kafka 1.1 の非推奨化) に関する詳細を確認してください。
HDInsight Spark クラスターでの Spark の古いバージョンの非推奨化
2020 年 7 月 1 日以降、HDInsight 3.6 で Spark 2.1 と 2.2 を使用して、また HDInsight 4.0 で Spark 2.3 を使用して新しい Spark クラスターを作成することはできません。 既存のクラスターはそのまま動作しますが、Microsoft からのサポートはありません。
HDInsight クラスター - SparkVersionRetirement (HDInsight Spark クラスターでの Spark の古いバージョンの非推奨化) に関する詳細を確認してください。
HDInsight クラスターへの重要な更新プログラムの適用を有効にする
HDInsight サービスにより、証明書に関連する重要な更新プログラムがクラスターに適用されています。 しかし、サブスクリプションの 1 つ以上のポリシーによって、HDInsight service がクラスターに関連付けられているネットワーク リソースを作成または変更できず、この更新プログラムの適用ができません。 2021 年 1 月 13 日午後 5 時 (UTC) より前に、クラスターに関連付けられているネットワーク リソース (ロード バランサー、ネットワーク インターフェイス、パブリック IP アドレスなど) を HDInsight サービスで作成または変更できるように対応してください。 HDInsight チームは、2021 年 1 月 13 日午後 5 時 (UTC) から 2021 年 1 月 16 日午後 5 時 (UTC) までの間に更新を行います。 この更新プログラムを適用しないと、クラスターが異常になり、使用できなくなる可能性があります。
HDInsight クラスター - GCSCertRotation (HDInsight クラスターへの重要な更新プログラムの適用を有効にする) に関する詳細を確認してください。
HDInsight クラスターをドロップして再作成し、重要な更新プログラムを適用します
HDInsight サービスにより、実行中のすべてのクラスターに対して重要な証明書の更新プログラムの適用が試行されました。 ただし、一部のカスタム構成の変更により、一部のクラスターに証明書の更新プログラムを適用できません。
HDInsight クラスター - GCSCertRotationRound2 (HDInsight クラスターをドロップして再作成し、重要な更新プログラムを適用する) に関する詳細を確認してください。
HDInsight クラスターをドロップして再作成し、重要な更新プログラムを適用します
HDInsight サービスにより、実行中のすべてのクラスターに対して重要な証明書の更新プログラムの適用が試行されました。 ただし、一部のカスタム構成の変更により、一部のクラスターに証明書の更新プログラムを適用できません。 クラスターが異常な状態になり、使用できなくなるのを防ぐために、2021 年 1 月 25 日の前にクラスターを削除して再作成してください。
HDInsight クラスター - GCSCertRotationR3DropRecreate (HDInsight クラスターをドロップして再作成し、重要な更新プログラムを適用する) に関する詳細を確認してください。
重要な更新プログラムを HDInsight クラスターに適用する
HDInsight サービスにより、実行中のすべてのクラスターに対して重要な証明書の更新プログラムの適用が試行されました。 しかし、サブスクリプションの 1 つ以上のポリシーによって、HDInsight service がクラスターに関連付けられているネットワーク リソースを作成または変更できず、更新プログラムの適用ができません。 クラスターに関連付けられているネットワーク リソースを HDInsight サービスで作成または変更できるように、ポリシーの割り当てを削除または更新してください。 ポリシーの割り当ては、HDInsight チームが 2021 年 1 月 21 日午後 5時 (UTC) から 2021 年 1 月 23 日午後 5時 (UTC) の間に更新を行う場合、2021 年 1 月 21 日午後 5時 (UTC) 以前に行ってください。 ポリシーの更新を確認するには、クラスターがあるのと同じリソース グループとサブネットでネットワーク リソースを作成してみてください。 この更新プログラムを適用しないと、クラスターが異常になり、使用できなくなる可能性があります。 また、クラスターが異常な状態になり、使用できなくなるのを防ぐために、2021 年 1 月 25 日より前にクラスターを削除して再作成することもできます。 クラスターに更新プログラムを適用できなかった場合は、HDInsight サービスから別の通知が届きます。
HDInsight クラスター - GCSCertRotationR3PlanPatch (重要な更新プログラムを HDInsight クラスターに適用する) に関する詳細を確認してください。
対処が必要: 2021 年 3 月 1 日より前に A8 から A11 の HDInsight クラスターを移行してください
お客様には A8、A9、A10、または A11 のアクティブな HDInsight クラスターが 1 つ以上あるため、この通知をお送りしています。 A8 から A11 の仮想マシン (VM) は、2021 年 3 月 1 日にすべてのリージョンで廃止されます。 その日付を過ぎると、A8 から A11 を使用しているすべてのクラスターが割り当てを解除されます。 その日より前に、影響を受けるクラスターを HDInsight でサポートされている別の VM (https://azure.microsoft.com/pricing/details/hdinsight/) に移行してください。 詳細については、「詳細情報」のリンクを参照するか、askhdinsight@microsoft.com にお問い合わせください
HDInsight クラスター - VM Deprecation (対処が必要: 2021 年 3 月 1 日より前に A8 から A11 の HDInsight クラスターを移行する) に関する詳細を確認してください。
Compute
Cloud Services (クラシック) は廃止されます。 2024 年 8 月 31 日より前に移行してください
Cloud Services (クラシック) は廃止されます。 データやビジネス継続性が失われるのを避けるため、2024 年 8 月 31 日より前に移行してください。
リソース - Cloud Services の廃止 (Cloud Services (クラシック) は廃止。2024 年 8 月 31 日より前に移行)に関する詳細を確認してください。
Premium 対応 VM に接続されている Standard ディスクを Premium ディスクにアップグレードする
Premium 対応の仮想マシンで Standard ディスクを使用していることを確認しました。Standard ディスクを Premium ディスクにアップグレードすることをお勧めします。 すべてのオペレーティング システム ディスクとデータ ディスクに Premium Storage を使用している単一インスタンスの仮想マシンはすべて、少なくとも 99.9% の仮想マシンの接続が保証されます。 アップグレードを決めるときは、次の点に考慮します。 まず、アップグレードには VM の再起動が必要であり、このプロセスが完了するまでに 3 から 5 分かかるということです。 2 つ目として、リストにある VM がミッション クリティカルな運用 VM である場合には、向上する可用性と、Premium ディスクのコストを比較してください。
仮想マシン - MigrateStandardStorageAccountToPremium (Premium 対応 VM に接続されている Standard ディスクを Premium ディスクにアップグレードする) に関する詳細を確認してください。
仮想マシンのレプリケーションを有効にして、リージョンの障害からアプリケーションを保護する
他のリージョンへのレプリケーションが有効になっていない仮想マシンは、リージョンの障害に対する回復性がありません。 マシンをレプリケートすることによって、Azure リージョン内での障害発生時にビジネスへの悪影響が大幅に低減されます。 障害発生時にリモートの Azure リージョンですばやくマシンを起動できるように、次の一覧に示すすべてのビジネス クリティカルな仮想マシンのレプリケーションを有効にすることを強くお勧めします。 仮想マシン - ASRUnprotectedVMs (仮想マシンのレプリケーションを有効にして、リージョンの障害からアプリケーションを保護する) に関する詳細を確認してください。
追加コストなしで VM を Premium Unmanaged Disks から Premium Managed Disks にアップグレードする
追加コストなしで Premium Managed Disks に移行可能な VM で Unmanaged Disks が使用されていることが確認されました。 Azure Managed Disks では、高い回復性、簡素化されたサービス管理、高いスケーリング目標、および複数のディスクの種類での多くの選択肢が提供されます。 このアップグレードは、ポータルを介して 5 分未満で完了できます。
仮想マシン - UpgradeVMToManagedDisksWithoutAdditionalCost (追加コストなしで VM を Premium Unmanaged Disks から Premium Managed Disks にアップグレードする) に関する詳細を確認してください。
送信接続プロトコルを Azure Site Recovery 用のサービス タグに更新する
IP アドレス ベースのフィルター処理の使用は、ファイアウォールに対する送信接続を制御するための脆弱な方法と見なされます。 接続を制御するための代替手段として、サービス タグを使用することをお勧めします。 サービス タグを使用し、マシンに対して Azure Site Recovery サービスへの接続を許可することを、強くお勧めします。
仮想マシン - ASRUpdateOutboundConnectivityProtocolToServiceTags (送信接続プロトコルを Azure Site Recovery 用のサービス タグに更新する) に関する詳細を確認してください。
新しい RHUI 4 IP を許可するようにファイアウォール構成を更新する
Virtual Machine Scale Sets は、2023 年 10 月 12 日に RHUI4 サーバーからのパッケージ コンテンツの受信を開始しています。 ファイアウォールとプロキシ経由で RHUI 3 IP [https://aka.ms/rhui-server-list] を許可している場合は、新しい RHUI 4 IP [https://aka.ms/rhui-server-list] が RHEL パッケージの更新プログラムを引き続き受信することを許可してください。
仮想マシン - Rhui3ToRhui4MigrationV2 (新しい RHUI 4 IP を許可するようにファイアウォール構成を更新する) に関する詳細を確認してください。
サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されている
サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されています。 イメージが非推奨になると、非推奨のイメージから新しい VM を作成することはできません。 ワークロードの中断を防ぐために、新しいバージョンのイメージにアップグレードしてください。
仮想マシン - VMRunningDeprecatedOfferLevelImage (サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されている) に関する詳細を確認してください。
サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されている
サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されています。 イメージが非推奨になると、非推奨のイメージから新しい VM を作成することはできません。 ワークロードの中断を防ぐために、新しい SKU のイメージにアップグレードしてください。
仮想マシン - VMRunningDeprecatedPlanLevelImage (サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されている) に関する詳細を確認してください。
サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されている
サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されています。 イメージが非推奨になると、非推奨のイメージから新しい VM を作成することはできません。 ワークロードの中断を防ぐために、新しいバージョンのイメージにアップグレードしてください。
仮想マシン - VMRunningDeprecatedImage (サブスクリプション内の仮想マシンが、非推奨になる予定のイメージで実行されている) に関する詳細を確認してください。
Availability Zones を使用して回復性と可用性を向上させる
Azure の Availability Zones (AZ) は、アプリケーションとデータをデータセンターの障害から保護するのに役立ちます。 それぞれの AZ は、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 ゾーン VM を使用するソリューションを設計することで、他のゾーンで障害から VM を分離できます。
仮想マシン - AvailabilityZoneVM (回復性と可用性を向上するために可用性ゾーンを使用する) に関する詳細を確認してください。
データの信頼性を改善するために Managed Disks を使用する
ストレージ アカウントまたはストレージ スケール ユニットを共有するディスクを使用する可用性セット内の仮想マシンは、停止時のストレージ スケール ユニットの単一障害に対する回復性がありません。 Azure Managed Disks に移行すると、可用性セット内の異なる VM のディスクが十分に分離され、単一障害点が回避されます。
可用性セット - ManagedDisksAvSet (データの信頼性を改善するために Managed Disks を使用する) に関する詳細を確認してください。
Azure Virtual Desktop 環境に必要な URL へのアクセスがない
仮想マシンが制限された環境で実行される場合、セッション ホストを正常にデプロイして Azure Virtual Desktop に登録するには、URL のセットを許可リストに追加する必要があります。 [詳細情報] リンクにアクセスすると、デプロイを成功させ、セッション ホストを機能させるにはブロックを解除する必要がある URL の最小限の一覧が表示されます。 許可リストに含まれていない特定の URL については、アプリケーションのイベント ログでイベント 3702 を検索することもできます。
仮想マシン - SessionHostNeedsAssistanceForUrlCheck (Azure Virtual Desktop 環境に必要な URL へのアクセスがない) の詳細を確認してください。
新しい RHUI 4 IP を許可するようにファイアウォール構成を更新する
Virtual Machine Scale Sets は、2023 年 10 月 12 日に RHUI4 サーバーからのパッケージ コンテンツの受信を開始しています。 ファイアウォールとプロキシ経由で RHUI 3 IP [https://aka.ms/rhui-server-list] を許可している場合は、新しい RHUI 4 IP [https://aka.ms/rhui-server-list] が RHEL パッケージの更新プログラムを引き続き受信することを許可してください。
仮想マシン スケール セット - Rhui3ToRhui4MigrationVMSS (新しい RHUI 4 IP を許可するようにファイアウォール構成を更新する) に関する詳細を確認してください。
サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されている
サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されています。 イメージが非推奨になると、仮想マシン スケール セットのワークロードはスケールアウトされなくなります。ワークロードの中断を防ぐために、新しいバージョンのイメージにアップグレードしてください。
仮想マシン スケール セット - VMScaleSetRunningDeprecatedOfferImage (サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されている) に関する詳細を確認してください。
サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されている
サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されています。 イメージが非推奨になると、仮想マシン スケール セットのワークロードはスケールアウトされなくなります。ワークロードの中断を防ぐために、新しいバージョンのイメージにアップグレードしてください。
仮想マシン スケール セット - VMScaleSetRunningDeprecatedImage (サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されている) に関する詳細を確認してください。
サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されている
サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されています。 イメージが非推奨になると、仮想マシン スケール セットのワークロードはスケールアウトされなくなります。ワークロードの中断を防ぐために、新しいプランのイメージにアップグレードしてください。
仮想マシン スケール セット - VMScaleSetRunningDeprecatedPlanImage (サブスクリプション内の仮想マシン スケール セットが、非推奨になる予定のイメージで実行されている) に関する詳細を確認してください。
Containers
コンテナー アプリの最小レプリカ数を増やす
コンテナー アプリに設定されている最小レプリカ数が、最適な数を下回っている可能性があることが検出されました。 可用性を高めるために、最小レプリカ数を増やすことを検討してください。
Microsoft App Container App - ContainerAppMinimalReplicaCountTooLow (コンテナー アプリの最小レプリカ数を増やす) に関する詳細を確認してください。
カスタム ドメイン証明書を更新する
アップロードしたカスタム ドメイン証明書の有効期限がもうすぐ切れることを検出しました。 証明書を更新し、コンテナー アプリの新しい証明書をアップロードしてください。
Microsoft アプリ Container App - ContainerAppCustomDomainCertificateNearExpiration (カスタム ドメイン証明書を更新する) に関する詳細を確認してください。
DNS の問題を回避するために再作成する必要がある、Container Apps 環境で潜在的なネットワークの問題が特定されました
Container Apps 環境で、ネットワークに関する潜在的な問題が特定されました。 この潜在的なネットワークの問題が起きないようにするには、新しい Container Apps 環境を作成し、新しい環境で Container Apps を再作成して、前の Container Apps 環境を削除します
マネージド環境 - CreateNewContainerAppsEnvironment (Container Apps 環境で、DNS の問題を回避するために Container Apps 環境を再作成する必要がある潜在的なネットワーク問題が確認された) に関する詳細を確認してください。
App Service証明書の更新に必要なドメイン検証
現在発行保留中状態にあり、ドメイン検証が必要な App Service 証明書があります。 ドメインの所有権の検証に失敗すると、証明書の発行が失敗します。 App Service 証明書については、ドメイン検証が自動化されていないため、ユーザーによるアクションが必要です。
App Service 証明書 - ASCDomainVerificationRequired (App Service 証明書の更新に必要なドメイン検証) に関する詳細を確認してください。
非推奨の B シリーズを使用するノード プールがあるクラスター
クラスターに、非推奨のバースト可能な VM SKU を使用するノード プールが 1 つ以上あります。 バースト可能な VM では、vCPU 機能が 100% 完全になることは保証されません。 B シリーズの VM が運用環境で使用されていないことを確認してください。
Kubernetes サービス - ClustersUsingBSeriesVMs (非推奨の B シリーズを使用するノード プールがあるクラスター) に関する詳細を確認してください。
ミッション クリティカルおよび運用クラスター向けの Standard レベルへアップグレードする
このクラスターには 10 を超えるノードがあり、Standard レベルが有効になっていません。 Free レベルの Kubernetes コントロール プレーンには限られたリソースしかなく、運用環境での使用や 10 以上のノードでの使用を目的としていません。
Kubernetes サービス - UseStandardpricingtier (ミッション クリティカルおよび運用クラスター向けの Standard レベルへアップグレードする) に関する詳細を確認してください。
ポット中断バジェットを推奨
ポッド中断バジェットが推奨されます。 サービスの高可用性が向上します。
Kubernetes Service - PodDisruptionBudgetsRecommended (ポッド中断バジェットが推奨される) に関する詳細を確認してください。
Azure Arc 対応 Kubernetes の最新バージョンのエージェントにアップグレードする
Azure Arc 対応 Kubernetes の最適なエクスペリエンス、向上した安定性、新機能のため、エージェントを最新のバージョンにアップグレードします。
Kubernetes - Azure Arc - Arc 対応 K8s エージェントのバージョンのアップグレード (Azure Arc 対応 Kubernetes の最新バージョンのエージェントにアップグレードする) に関する詳細を確認してください。
データベース
レプリケーション - 現在主キーがないテーブルに、主キーを追加する
内部監視に基づいて、レプリカ サーバーにおけるレプリケーションの大幅な遅延が確認されました。 この遅延は、レプリカ サーバーが主キーがないテーブルでリレー ログを再生していることが原因で発生しています。 レプリカがプライマリと同期し、変更に対応できるようにするには、プライマリ サーバーのテーブルに主キーを追加します。 主キーが追加されたら、レプリカ サーバーを再作成してください。
Azure Database for MySQL フレキシブル サーバー - MySqlFlexibleServerReplicaMissingPKfb41 (レプリケーション - 現在主キーがないテーブルに主キーを追加する) に関する詳細を確認してください。
高可用性 - 現在主キーがないテーブルに主キーを追加する
内部監視システムによって、高可用性スタンバイ サーバーにおけるレプリケーションの大幅な遅延が確認されました。 主キーがないテーブルのリレー ログがスタンバイ サーバーで再生されていることが、この遅延の主な原因です。 この問題に対処してベスト プラクティスに従うために、すべてのテーブルに主キーを追加することをお勧めします。 主キーを追加したら、高可用性を無効にしてから再度有効にすることで問題を軽減してください。
Azure Database for MySQL フレキシブル サーバー - MySqlFlexibleServerHAMissingPKcf38 (高可用性 - 現在主キーがないテーブルに主キーを追加する) に関する詳細を確認してください。
メモリの断片化が多いことで、可用性が影響を受ける可能性があります。 回避するために断片化メモリ予約を増やす
断片化やメモリ負荷によって、フェールオーバーまたは管理操作の最中に可用性インシデントが発生する可能性があります。 断片化に備えてメモリの予約を増やすと、メモリ負荷が高い状況で実行しているときのキャッシュ エラーを減らすことができます。 断片化に備えたメモリは、詳細設定オプション領域で利用可能な maxfragmentationmemory-reserved 設定を使用して増やすことができます。
仮想マシンで SQL の Azure Backup を有効にする
Azure Backup を使用して仮想マシン上の SQL データベースのバックアップを有効にし、SQL AG 統合によるゼロインフラストラクチャ バックアップ、ポイントインタイム リストア、一元管理の利点を実現します。
SQL 仮想マシン - EnableAzBackupForSQL (仮想マシンで SQL の Azure バックアップを有効にする) に関する詳細を確認してください。
非アクティブな論理レプリケーション スロットを削除して PostgreSQL の可用性を向上させる
内部システムによると、お使いの PostgreSQL サーバーには非アクティブな論理レプリケーション スロットが存在する可能性があります。 これには即時の対応が必要です。 非アクティブな論理レプリケーションにより、WAL ファイルを保持し、スナップショット ファイルを蓄積する結果となり、サーバーのパフォーマンスが低下したり、使用できなくなったりする可能性があります。 パフォーマンスと可用性を向上させるには、すぐに対応することを強くお勧めします。 非アクティブなレプリケーション スロットを削除するか、このスロットから変更の使用を開始して、スロットのログ シーケンス番号 (LSN) を進めてサーバーの現在の LSN に近い値にします。
PostgreSQL サーバー - OrcasPostgreSqlLogicalReplicationSlots (非アクティブな論理レプリケーション スロットを削除して PostgreSQL の可用性を向上させる) に関する詳細を確認してください。
非アクティブな論理レプリケーション スロットを削除して PostgreSQL の可用性を向上させる
内部システムによると、お使いの PostgreSQL フレキシブル サーバーには非アクティブな論理レプリケーション スロットが存在する可能性があります。 これには即時の対応が必要です。 非アクティブな論理レプリケーション スロットにより、WAL ファイルを保持し、スナップショット ファイルを蓄積する結果となり、サーバーのパフォーマンスが低下したり、使用できなくなったりする可能性があります。 パフォーマンスと可用性を向上させるには、すぐに対応することを強くお勧めします。 非アクティブなレプリケーション スロットを削除するか、このスロットから変更の使用を開始して、スロットのログ シーケンス番号 (LSN) を進めてサーバーの現在の LSN に近い値にします。
Azure Database for PostgreSQL フレキシブル サーバー - OrcasPostgreSqlFlexibleServerLogicalReplicationSlots (非アクティブな論理レプリケーション スロットを削除して PostgreSQL の可用性を向上させる) に関する詳細を確認してください。
Azure Cosmos DB コンテナーで同期 (Consistent) インデックス モードを構成する
Azure Cosmos DB コンテナーが Lazy インデックス作成モードで構成されていることが検出されました。クエリ結果の鮮度に影響を与える可能性があります。 Consistent モードに切り替えることをお勧めします。
Azure Cosmos DB アカウント - CosmosDBLazyIndexing (Azure Cosmos DB コンテナーで同期 (Consistent) インデックス モードを構成する) に関する詳細を確認してください。
古い Azure Cosmos DB SDK を最新バージョンにアップグレードする
Azure Cosmos DB アカウントで、古いバージョンの SDK が使用されています。 最新の修正、パフォーマンスの向上、新機能を入手するため、最新バージョンにアップグレードすることをお勧めします。
Azure Cosmos DB アカウント - CosmosDBUpgradeOldSDK (古い Azure Cosmos DB SDK を最新バージョンにアップグレードする) に関する詳細を確認してください。
古い Azure Cosmos DB SDK を最新バージョンにアップグレードする
Azure Cosmos DB アカウントで、古いバージョンの SDK が使用されています。 最新の修正、パフォーマンスの向上、新機能を入手するため、最新バージョンにアップグレードすることをお勧めします。
Azure Cosmos DB アカウント - CosmosDBUpgradeOutdatedSDK (古い Azure Cosmos DB SDK を最新バージョンにアップグレードする) に関する詳細を確認してください。
パーティション キーを使用して Azure Cosmos DB コンテナーを構成する
Azure Cosmos DB のパーティション分割されていないコレクションが、プロビジョニング済みのストレージ クォータに近づいています。 サービスによって自動的にスケール アウトできるように、これらのコレクションをパーティション キーが定義された新しいコレクションに移行してください。
Azure Cosmos DB アカウント - CosmosDBFixedCollections (パーティション キーを使用して Azure Cosmos DB コンテナーを構成する) に関する詳細を確認してください。
Azure Cosmos DB for MongoDB アカウントを v4.0 にアップグレードして、クエリとストレージのコストを削減し、新機能を利用する
お使いの Azure Cosmos DB for MongoDB アカウントは、バージョン 4.0 へのアップグレード対象です。 v4.0 の新しいストレージ形式にアップグレードすると、ストレージ コストを最大 55%、クエリ コストを最大 45% 削減できます。 また、v4.0 には、そのほかにもマルチドキュメント トランザクションなど数多くの機能が含まれています。
Azure Cosmos DB アカウント - CosmosDBMongoSelfServeUpgrade (Azure Cosmos DB for MongoDB アカウントを v4.0 にアップグレードして、クエリとストレージのコストを削減し、新機能を利用する) に関する詳細を確認してください。
Azure Cosmos DB の運用ワークロードに 2 番目のリージョンを追加する
名前と構成に基づいて、以下の Azure Cosmos DB アカウントが運用環境のワークロードに使用されている可能性があることを検出しました。 これらのアカウントは、現在、1 つの Azure リージョンで実行されています。 少なくとも 2 つの Azure リージョンが含まれるように構成することで、可用性を高めることができます。
Note
リージョンを追加すると、追加コストが発生します。
Azure Cosmos DB アカウント - CosmosDBSingleRegionProdAccounts (Azure Cosmos DB の運用ワークロードに 2 番目のリージョンを追加する) に関する詳細を確認してください。
Azure Cosmos DB for MongoDB アカウントでサーバー側の再試行 (SSR) を有効にする
お使いのアカウントで 16500 エラー コードの TooManyRequests エラーがスローされていることを確認しました。 サーバー側の再試行 (SSR) を有効にすると、この問題を軽減するのに役立ちます。
Azure Cosmos DB アカウント - CosmosDBMongoServerSideRetries (Azure Cosmos DB for MongoDB アカウントでサーバー側の再試行 (SSR) を有効にする) に関する詳細を確認してください。
Azure Cosmos DB for MongoDB アカウントを v4.0 に移行して、クエリとストレージのコストを削減し、新機能を利用する
お使いのデータベース アカウントを新しいデータベース アカウントに移行して、Azure Cosmos DB for MongoDB の v4.0 を活用します。 v4.0 の新しいストレージ形式にアップグレードすると、ストレージ コストを最大 55%、クエリ コストを最大 45% 削減できます。 また、v4.0 には、そのほかにもマルチドキュメント トランザクションなど数多くの機能が含まれています。 また、アップグレードの際には、既存アカウントのデータを、バージョン 4.0 を使用して作成した新しいアカウントに移行する必要があります。 Azure Data Factory または Studio 3T が、データの移行を支援します。
Azure Cosmos DB アカウント - CosmosDBMongoMigrationUpgrade (Azure Cosmos DB for MongoDB アカウントを v4.0 に移行して、クエリとストレージのコストを削減し、新機能を利用する) に関する詳細を確認してください。
Azure Cosmos DB アカウントが、暗号化キーをホストする、リンクされた Azure Key Vault にアクセスできない
キー コンテナーの構成により、Azure Cosmos DB アカウントからキー コンテナーに接続し、マネージド暗号化キーにアクセスすることができないようです。 キーのローテーションを最近実行した場合は、以前のキーまたはキーのバージョンが有効であり、Azure Cosmos DB でのローテーションが完了するまで使用可能であることを確認してください。 前のキーまたはキー バージョンは、24 時間後、または Azure Key Vault 監査ログに Azure Cosmos DB からそのキーまたはキー バージョンに対するアクティビティが出現しなくなった後に無効にすることができます。
Azure Cosmos DB アカウント - CosmosDBKeyVaultWrap (Azure Cosmos DB アカウントが、暗号化キーをホストする、リンクされた Azure Key Vault にアクセスできない) に関する詳細を確認してください。
メタデータの操作によってレートが制限されないようにする
お使いのアカウントでメタデータ操作が多数見つかりました。 データベースとコレクションに関するメタデータを含む Azure Cosmos DB 内のデータは、パーティション間で分散されます。 メタデータの操作には、システム予約済み要求ユニット (RU) の制限があります。 メタデータ操作の数が多い場合、レート制限が発生する可能性があります。 コード内で静的な Azure Cosmos DB クライアント インスタンスを使用し、データベースとコレクションの名前をキャッシュすることで、レートが制限されないようにしてください。
Azure Cosmos DB アカウント - CosmosDBHighMetadataOperations (メタデータの操作によってレートが制限されないようにする) に関する詳細を確認してください。
新しい 3.6 以降のエンドポイントを使用して、アップグレードされた Azure Cosmos DB for MongoDB アカウントに接続する
お使いのアプリケーションの一部で、アップグレードされた Azure Cosmos DB for MongoDB アカウントに接続するために、レガシ 3.2 エンドポイント [accountname].documents.azure.com が使用されていることが確認されました。 新しいエンドポイント [accountname].mongo.cosmos.azure.com (または、ソブリン、政府機関向け、制限されたクラウドでそれに相当するもの) を使用してください。
Azure Cosmos DB アカウント - CosmosDBMongoNudge36AwayFrom32 (新しい 3.6 以降のエンドポイントを使用して、アップグレードされた Azure Cosmos DB for MongoDB アカウントに接続する) に関する詳細を確認してください。
重大な問題を回避するため、Async Java SDK v2 の 2.6.14 バージョンにアップグレードしてください。または、Async Java SDK v2 は非推奨になっているので、Java SDK v4 にアップグレードしてください
バージョン 2.6.13 以前の Azure Cosmos DB Async Java SDK v2 には、グローバル論理シーケンス番号 (LSN) が最大整数値に達するとエラーが発生するという重大なバグがあります。 このサービス エラーは、Azure Cosmos DB コンテナーの有効期間中に大量のトランザクションが発生した後に発生します。 注: Async Java SDK v2 に重要な修正プログラムが出されていますが、Java SDK v4 に移行することを強くお勧めします。
重大な問題を回避するため、現在推奨されているバージョンの Java SDK v4 にアップグレードしてください
バージョン 4.15 以前の Azure Cosmos DB Java SDK v4 には、グローバル論理シーケンス番号 (LSN) が最大整数値に達するとエラーが発生するという重大なバグがあります。 このサービス エラーは、Azure Cosmos DB コンテナーの有効期間中に大量のトランザクションが発生した後に発生します。
Azure Cosmos DB アカウント - CosmosDBMaxGlobalLSNReachedV4 (重大な問題を回避するため、現在推奨されているバージョンの Java SDK v4 にアップグレードする) に関する詳細を確認してください。
統合
FarmBeats API の最新バージョンにアップグレードする
FarmBeats API の廃止予定のバージョンが呼び出されていることがわかりました。 FarmBeats API の最新バージョンに切り替えて、FarmBeats、最新の機能、向上したパフォーマンスに継続的にアクセスできるようにすることをお勧めします。
Azure FarmBeats - FarmBeatsApiVersion (FarmBeats API の最新バージョンにアップグレードする) に関する詳細を確認してください。
最新のADMA Java SDK バージョンにアップグレードする
Azure Data Manager for Agriculture (ADMA) Java SDK の非推奨になる予定のバージョンが呼び出されていることがわかりました。 SDK の最新バージョンに切り替えて、中断されることなく ADMA、最新の機能、向上したパフォーマンスにアクセスできるようにすることをお勧めします。
Azure FarmBeats - FarmBeatsJavaSdkVersion (ADMA Java SDK の最新バージョンにアップグレードする) に関する詳細を確認してください。
最新の ADMA DotNet SDK バージョンにアップグレードする
ADMA DotNet SDK の非推奨になる予定のバージョンが呼び出されていることがわかりました。 SDK の最新バージョンに切り替えて、中断されることなく ADMA、最新の機能、向上したパフォーマンスにアクセスできるようにすることをお勧めします。
Azure FarmBeats - FarmBeatsDotNetSdkVersion (ADMA DotNet SDK の最新バージョンにアップグレードする) に関する詳細を確認してください。
最新のADMA JavaScript SDKバージョンにアップグレードする
ADMA JavaScript SDK の非推奨になる予定のバージョンが呼び出されていることがわかりました。 SDK の最新バージョンに切り替えて、中断されることなく ADMA、最新の機能、向上したパフォーマンスにアクセスできるようにすることをお勧めします。
Azure FarmBeats - FarmBeatsJavaScriptSdkVersion (ADMA JavaScript SDK の最新バージョンにアップグレードする) に関する詳細を確認してください。
最新の ADMA Python SDK バージョンにアップグレードする
ADMA Python SDK の非推奨になる予定のバージョンが呼び出されていることがわかりました。 SDK の最新バージョンに切り替えて、中断されることなく ADMA、最新の機能、向上したパフォーマンスにアクセスできるようにすることをお勧めします。
Azure FarmBeats - FarmBeatsPythonSdkVersion (ADMA Python SDK の最新バージョンにアップグレードする) に関する詳細を確認してください。
SSL/TLS の再ネゴシエーションがブロックされた
SSL/TLS の再ネゴシエーションの試行がブロックされました。 再ネゴシエーションは、既に確立されている接続でクライアント証明書が要求された場合に発生します。 ブロックされている場合は、ポリシー式での 'context.Request.Certificate' の読み取りで 'null' が返されます。 クライアント証明書の認証シナリオをサポートするには、一覧に表示されているホスト名で [クライアント証明書のネゴシエート] を有効にします。 ブラウザーベースのクライアントの場合、このオプションを有効にすると、証明書を要求するメッセージがクライアントに表示されることがあります。
API Management - TlsRenegotiationBlocked (SSL/TLS の再ネゴシエーションがブロックされた) に関する詳細を確認してください。
ホスト名証明書のローテーションに失敗しました
API Management サービスにより、Key Vault のホスト名証明書を更新できませんでした。 証明書が Key Vault に存在し、API Management サービス ID にシークレットの読み取りアクセスが許可されていることを確認します。 それ以外の場合は、API Management サービスで Key Vault から証明書の更新を取得できず、その結果、古い証明書を使用しているサービスやランタイム API トラフィックがブロックされる可能性があります。
API Management - HostnameCertRotationFail (ホスト名証明書のローテーションが失敗した) に関する詳細を確認してください。
モノのインターネット (IoT)
デバイス クライアント SDK を IotHub のサポートされているバージョンにアップグレードする
デバイスの一部またはすべてで、古い SDK が使用されています。サポートされているバージョンの SDK にアップグレードすることをお勧めします。 推奨事項の詳細を参照してください。
IoT ハブ - UpgradeDeviceClientSdk (デバイス クライアント SDK を IotHub のサポートされているバージョンにアップグレードする) に関する詳細を確認してください。
IoT Hub で潜在的なデバイス ストームが検出された
デバイス ストームとは、2 台以上のデバイスにより、IoT Hub への接続時に同じデバイス ID の資格情報が使用されている場合のことです。 2 台目のデバイス (B) が接続されると、1 台目のデバイス (A) は切断されます。 次に、(A) により、再接続が試行されます。これにより、(B) が切断されます。
IoT ハブ - IoTHubDeviceStorm (IoT ハブで潜在的なデバイス ストームが検出された) に関する詳細を確認してください。
Device Update for IoT Hub SDK をサポートされているバージョンにアップグレードする
Device Update for IoT Hub インスタンスで古いバージョンの SDK が使用されています。 最新の修正、パフォーマンスの向上、新機能を入手するため、最新バージョンにアップグレードすることをお勧めします。
IoT ハブ - DU_SDK_Advisor_Recommendation (Device Update for IoT Hub SDK がサポートされているバージョンにアップグレードする) に関する詳細を確認してください。
IoT Hub クォータの超過が検出されました
IoT Hubが 1 日のメッセージ クォータを超えたことが検出されました。 IoT ハブが今後 1 日のメッセージ クォータを超えないようにするには、ユニットを追加するか、SKU レベルを上げてください。
IoT ハブ - IoTHubQuotaExceededAdvisor (IoT ハブ クォータの超過が検出されました) に関する詳細を確認してください。
デバイス クライアント SDK を IoT Hub がサポートされているバージョンにアップグレードする
デバイスの一部またはすべてで、古い SDK が使用されています。サポートされているバージョンの SDK にアップグレードすることをお勧めします。 以下のリンクで詳細を確認してください。
IoT ハブ - UpgradeDeviceClientSdk (デバイス クライアント SDK を IotHub のサポートされているバージョンにアップグレードする) に関する詳細を確認してください。
Microsoft Edge デバイス ランタイムを IoT Hub でサポートされているバージョンにアップグレードする
Microsoft Edge デバイスの一部またはすべてで、古いバージョンが使用されています。サポートされている最新バージョンのランタイムにアップグレードすることをお勧めします。 以下のリンクで詳細を確認してください。
IoT ハブ - UpgradeEdgeSdk (Microsoft Edge デバイス ランタイムを IoT Hub でサポートされているバージョンにアップグレードする) に関する詳細を確認してください。
Media
サービスの継続性を確保するために、Media Services のクォータまたは制限を引き上げる
メディア アカウントがクォータ制限に達しようとしています。 メディア アカウントの資産、コンテンツ キー ポリシー、およびストリーム ポリシーの現在の使用状況を確認してください。 サービスの中断を回避するには、クォータ制限に近づいているエンティティのクォータ制限の引き上げを要求してください。 チケットを開き、関連する詳細を追加することによって、クォータ制限の引き上げを要求できます。 上限を上げようとして別の Azure Media アカウントを作成しないでください。
Media Services - AccountQuotaLimit (サービスの継続性を確保するために、Media Services のクォータまたは制限を引き上げる) に関する詳細を確認してください。
ネットワーク
Check Point 仮想マシンで、ネットワーク接続が失われる可能性がある
お使いの仮想マシンで、プラットフォームのサービス操作が発生した場合にネットワーク接続が失われる可能性があるとわかっているバージョンの Check Point イメージが実行されていることが確認されました。 イメージの新しいバージョンにアップグレードすることをお勧めします。 イメージをアップグレードする方法の詳細については、Check Point にお問い合わせください。
仮想マシン - CheckPointPlatformServicingKnownIssueA (Check Point 仮想マシンで、ネットワーク接続が失われる可能性がある) に関する詳細を確認してください。
最新バージョンの Azure Connected Machine エージェントにアップグレードする
Azure Connected Machine エージェントは、バグの修正、安定性の向上、および新機能を伴って定期的に更新されます。 最適な Azure Arc エクスペリエンスを得るために、エージェントを最新バージョンにアップグレードします。
Connected Machine エージェント - Azure Arc - ArcServerAgentVersion (最新バージョンの Azure Connected Machine エージェントにアップグレードする) に関する詳細を確認してください。
Azure Front Door 顧客証明書のシークレット バージョンを ‘最新’ に切り替える
Azure Front Door (AFD) で Azure Key Vault の最新のシークレット バージョンが参照されるようにするために AFD 顧客証明書のシークレットを "最新" に構成し、シークレットを自動的にローテーションできるようにすることをお勧めします。
Front Door プロファイル - SwitchVersionBYOC (Azure Front Door 顧客証明書のシークレット バージョンを ‘最新’ に切り替える) に関する詳細を確認してください。
DNS TXT レコードを DNS プロバイダーに追加してドメインの所有権を検証します。
DNS TXT レコードを DNS プロバイダーに追加してドメインの所有権を検証します。
Front Door プロファイル - ValidateDomainOwnership (DNS TXT レコードを DNS プロバイダーに追加してドメインの所有権を検証する) に関する詳細を確認してください。
Azure Front Door マネージド証明書を更新するためにドメインの所有権を再検証する
ドメインが AFD エンドポイントにマップされている CNAME ではないため、Azure Front Door はマネージド証明書を自動的に更新できません。 マネージド証明書が自動的に更新されるように、ドメインの所有権を再検証してください。
Front Door プロファイル - RevalidateDomainOwnership (Azure Front Door マネージド証明書を更新するためにドメインの所有権を再検証する) に関する詳細を確認してください。
サービスの中断を回避するために、期限切れの Azure Front Door 顧客証明書を更新する
Azure Front Door Standard プロファイルと Premium プロファイルの一部の顧客証明書の有効期限が切れています。 サービスの中断を回避するために、証明書を期間内に更新してください。
Front Door プロファイル - RenewExpiredBYOC (サービスの中断を回避するために、期限切れの Azure Front Door 顧客証明書を更新する) に関する詳細を確認してください。
フォールト トレランスを確保するために SKU をアップグレードするかインスタンスを追加する
2 つ以上の中規模または大規模なインスタンスをデプロイすると、計画済みまたは計画外のメンテナンスによる機能停止中のビジネス継続性が確保されます。
Azure Advisor を使用してアプリケーションの信頼性を向上させる - アプリケーション ゲートウェイのフォールト トレランスを確保するの詳細については、こちらをご覧ください。
サイトの整合性を確保するため、ホスト名を上書きしない
Application Gateway を構成するときは、ホスト名を上書きしないようにしてください。 Application Gateway のフロントエンドのドメインが、バックエンドへのアクセスに使用されるものと異なっていると、Cookie やリダイレクト URL が破損する可能性があります。 フロントエンド ドメインが異なるとすべての状況で問題となるわけではありません。REST API などの特定のカテゴリのバックエンドでは、一般に影響は比較的小さいです。 バックエンドがドメインの違いに対応できることを確認するか、バックエンドに対してホスト名を上書きする必要がないように Application Gateway の構成を更新してください。 App Serviceで使用する場合は、Web アプリにカスタム ドメイン名をアタッチし、バックエンドにホスト名を *.azurewebsites.net 使用しないようにします。
アプリケーション ゲートウェイ - AppGatewayHostOverride (サイトの整合性を確保するため、ホスト名を上書きしない) に関する詳細を確認してください。
Azure WAF RuleSet CRS 3.1/3.2 を Log4j 2 の脆弱性ルールで更新
Log4j 2 の脆弱性 (CVE-2021-44228) に対応して、この脆弱性からの保護の強化に役立てるために、Application Gateway で Azure Web Application Firewall (WAF) RuleSet CRS 3.1/3.2 が更新されました。 これはルール 944240 で提供されています。これを有効にするために必要な操作はありません。
アプリケーション ゲートウェイ - AppGwLog4JCVEPatchNotification (Azure WAF RuleSet CRS 3.1/3.2 は log4j2 脆弱性ルールで更新されている) に関する詳細を確認してください。
Log4j 2 の脆弱性を軽減するための追加の保護 (CVE-2021-44228)
Log4j 2 の脆弱性の影響を軽減するために、次の手順をお勧めします:
- バックエンド サーバーで Log4j 2 をバージョン 2.15.0 にアップグレードします。 アップグレードできない場合は、提供されているシステム プロパティのガイダンス リンクに従ってください。
- WAF SKU にアップグレードすることにより WAF コアルールセット (CRS) を利用します。
アプリケーション ゲートウェイ - AppGwLog4JCVEGenericNotification (Log4j 2 の脆弱性を軽減するための追加の保護 (CVE-2021-44228)) に関する詳細を確認してください。
Application Gateway ユーザーの 仮想ネットワーク アクセス許可を更新します
セキュリティを向上させ、Azure 全体でより一貫したエクスペリエンスを提供するには、すべてのユーザーは仮想ネットワーク内にアプリケーション ゲートウェイを作成または更新する前に権限チェックに合格する必要があります。 ユーザーまたはサービス プリンシパルには、少なくとも Microsoft.Network/virtualNetworks/subnets/join/action アクセス許可が含まれている必要があります。
Application Gateway - AppGwLinkedAccessFailureRecmmendation (Application Gateway ユーザーの VNet 権限の更新) に関する詳細を確認してください。
バージョンのない Key Vault シークレット識別子を使用して証明書を参照する
使用可能な場合は常に、バージョンのないシークレット識別子を使用して、アプリケーション ゲートウェイ リソースが新しい証明書バージョンを常に自動的に取得できるようにすることを強くお勧めします。 例: https://myvault.vault.azure.net/secrets/mysecret/
Application Gateway - AppGwAdvisorRecommendationForCertificateUpdate (バージョンのない Key Vault シークレット識別子を使用して証明書を参照) に関する詳細を確認してください。
クロスプレミスの回復性のために Virtual Network に複数の ExpressRoute 回線を実装する
ExpressRoute ゲートウェイに 1 つの ExpressRoute 回線のみが関連付けられていることが検出されました。 1 つ以上の追加回線をゲートウェイに接続して、ピアリングの場所の冗長性と回復性を確保する
仮想ネットワーク ゲートウェイ - ExpressRouteGatewayRedundancy (クロスプレミスの回復性のために Virtual Network に複数の ExpressRoute 回線を実装する) に関する詳細を確認してください。
ExpressRoute 回線をエンドツーエンドで監視するために Network Performance Monitor に ExpressRoute モニターを実装する
現在、Network Performance Monitor の ExpressRoute モニターがExpressRoute 回線を監視していないことを検出しました。 ExpressRoute モニターには、オンプレミスから Azure、Azure からオンプレミスへのトラフィックの損失、待機時間、パフォーマンスなどをエンド ツー エンドで監視する機能が用意されています
ExpressRoute 回線 - ExpressRouteGatewayE2EMonitoring (ExpressRoute 回線をエンドツーエンドで監視するために Network Performance Monitor に ExpressRoute モニターを実装する) に関する詳細を確認してください。
ExpressRoute Global Reach を使用してディザスター リカバリーの設計を改善する
ExpressRoute 回線が 2 つ以上の異なる場所にピアリングされているようです。 ExpressRoute Global Reach を使用して相互に接続して、一方の回線で接続が失われても、オンプレミスのネットワークと Azure の環境の間でトラフィックのフローを継続できるようにします。 同じ metro 内または metro 間で、異なるピアリング場所にある回線間で Global Reach 接続を確立できます。
ExpressRoute 回線 - UseGlobalReachForDR (ExpressRoute Global Reach を使用してディザスター リカバリーの設計を改善する) に関する詳細を確認してください。
可能であれば別のリージョンで、プロファイルに少なくとも 1 つ以上のエンドポイントを追加する
プロファイルには、エンドポイントの 1 つで障害が発生した場合に可用性を確保するために、複数のエンドポイントを設定する必要があります。 また、それらのエンドポイントを異なるリージョンに配置することをお勧めします。
Traffic Manager プロファイル - GeneralProfile (可能であれば別のリージョンで、プロファイルに少なくとも 1 つ以上のエンドポイントを追加する) に関する詳細を確認してください。
"[すべて (世界)]" に構成されたエンドポイントを追加する
地理的なルーティングの場合、トラフィックは、定義されているリージョンに基づいてエンドポイントにルーティングされます。 リージョンで障害が発生した場合、定義済みのフェールオーバーはありません。 [リージョンのグループ化] で地理的なプロファイルが [すべて (世界)] に構成されたエンドポイントを配置すると、トラフィックのブラック ホール化が回避され、サービスの可用性が維持されます。
Traffic Manager プロファイル - GeographicProfile ("[すべて (世界)]" に構成されたエンドポイントを追加する) に関する詳細を確認してください。
あるエンドポイントを別の Azure リージョンに追加または移動する
この近接プロファイルに関連付けられているすべてのエンドポイントは、同じリージョンにあります。 他のリージョンからのユーザーは、接続しようとするときの待機時間が長くなる可能性があります。 エンドポイントを別のリージョンに追加または移動すると、近接ルーティングの全体的なパフォーマンスが向上すると共に、あるリージョン内のすべてのエンドポイントで障害が発生した場合の可用性が向上します。
Traffic Manager プロファイル - ProximityProfile (あるエンドポイントを別の Azure リージョンに追加または移動する) に関する詳細を確認してください。
Basic ゲートウェイから運用ゲートウェイ SKU への移行
VPN ゲートウェイ Basic SKU は開発またはテストのシナリオ用に設計されています。 運用環境用に VPN ゲートウェイを使用している場合は、運用 SKU に移行してください。 運用 SKU には、安定性と可用性の向上に加えて、トンネル数の増加、BGP サポート、アクティブ/アクティブ、カスタム IPsec/IKE ポリシーが備わっています。
仮想ネットワーク ゲートウェイ - BasicVPNGateway (Basic ゲートウェイから運用ゲートウェイ SKU への移行) に関する詳細を確認してください。
アウトバウンド接続用の NAT ゲートウェイを使用する
仮想ネットワークからの送信トラフィックに NAT ゲートウェイを使用して、SNAT ポートの枯渇による接続エラーのリスクを回避します。 NAT ゲートウェイは動的にスケーリングされ、インターネットに向かうトラフィックに対してセキュリティで保護された接続を提供します。
仮想ネットワーク - natGateway (アウトバウンド接続用の NAT ゲートウェイを使用する) に関する詳細を確認してください。
Application Gateway ユーザーの 仮想ネットワーク アクセス許可を更新します
セキュリティを向上させ、Azure 全体でより一貫したエクスペリエンスを提供するには、すべてのユーザーは仮想ネットワーク内にアプリケーション ゲートウェイを作成または更新する前に権限チェックに合格する必要があります。 ユーザーまたはサービス プリンシパルには、少なくとも Microsoft.Network/virtualNetworks/subnets/join/action アクセス許可が含まれている必要があります。
Application Gateway - AppGwLinkedAccessFailureRecmmendation (Application Gateway ユーザーの VNet 権限の更新) に関する詳細を確認してください。
バージョンのない Key Vault シークレット識別子を使用して証明書を参照する
使用可能な場合は常に、バージョンのないシークレット識別子を使用して、アプリケーション ゲートウェイ リソースが新しい証明書バージョンを常に自動的に取得できるようにすることを強くお勧めします。 例: https://myvault.vault.azure.net/secrets/mysecret/
Application Gateway - AppGwAdvisorRecommendationForCertificateUpdate (バージョンのない Key Vault シークレット識別子を使用して証明書を参照) に関する詳細を確認してください。
冗長性を確保するためにアクティブ/アクティブ ゲートウェイを有効にする
アクティブ/アクティブ構成では、VPN ゲートウェイの両方のインスタンスによって、オンプレミスの VPN デバイスへの S2S VPN トンネルが確立されます。 1 つのゲートウェイ インスタンスに対して計画メンテナンスまたは計画外のイベントが発生した場合、トラフィックは、もう一方のアクティブな IPsec トンネルに自動的に切り替えられます。
仮想ネットワーク ゲートウェイ - VNetGatewayActiveActive (冗長性を確保するためにアクティブ/アクティブ ゲートウェイを有効にする) に関する詳細を確認してください。
マネージド TLS 証明書を使用する
TLS 証明書を Front Door で管理すると、運用コストが削減され、証明書の更新忘れにより発生する停止コストを回避できます。
マネージド TLS 証明書を使用するの詳細については、こちらをご覧ください。
配信元グループに配信元が 1 つしかない場合に正常性プローブを無効にする
配信元が 1 つだけの場合、正常性プローブが異常な状態を報告した場合でも、Front Door は常にその配信元にトラフィックをルーティングします。 正常性プローブの状態は、Front Door の動作変更に対しては何も行いません。 このシナリオでは、正常性プローブの利点がないため、配信元のトラフィックを減らすために無効にする必要があります。
正常性プローブのベスト プラクティスの詳細については、こちらをご覧ください。
Azure Front Door と配信元で同じドメイン名を使用する
Web アプリケーションの前面でリバース プロキシを使うときは、元の HTTP ホスト名を維持することをお勧めします。 バックエンド アプリケーション サーバーに提供されるものとは異なるホスト名をリバース プロキシで使うと、Cookie やリダイレクト URL が正しく機能しない可能性があります。 たとえば、セッション状態が失われたり、認証が失敗したり、バックエンド URL が誤ってエンド ユーザーに公開されたりすることがあります。 アプリケーション サーバーが Web ブラウザーと同じドメインを認識するように、初期要求のホスト名を保持することで、これらの問題を回避できます。
Azure Front Door と配信元で同じドメイン名を使用するの詳細については、こちらをご覧ください。
Azure 用の SAP
SAP ワークロードの ASCS HA のセットアップで Pacemaker の構成の "concurrent-fencing" パラメーターを有効にする
concurrent-fencing パラメーターを true に設定すると、フェンシング操作を並列に実行できます。 ASCS HA セットアップの場合は Pacemaker クラスター構成のこのパラメーターを 'true' に設定します。
Central Server インスタンス - ConcurrentFencingHAASCSRH (SAP ワークロードの ASCS HA セットアップで、Pacemaker 構成の 'concurrent-fencing' パラメーターを有効にする) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップの Pacemaker の構成で、stonith が有効になっていることを確認する
Pacemaker クラスターでは、ノード レベルフェンスの実装は STONITH (ヘッド内の他のノードをシュートする) リソースを使用して行われます。 お使いのワークロードの HA クラスター構成で 'stonith-enable' が 'true' に設定されていることを確認します。
Central Server インスタンス - StonithEnabledHAASCSRH (SAP ワークロードの ASCS HA セットアップで、Pacemaker 構成の stonith を必ず有効にする) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップの場合はクラスター構成の stonith タイムアウトを 144 に設定する
SAP on Azure の推奨事項に従って、HA クラスターの stonith タイムアウトを 144 に設定します。
Central Server インスタンス - StonithTimeOutHAASCS (SAP ワークロードの ASCS HA セットアップでクラスター構成の stonith タイムアウトを 144 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA のセットアップで、Pacemaker クラスターの corosync トークンを 30000 に設定する
corosync トークン設定は、直接使用されるタイムアウト、または HA クラスターでの実際のトークン タイムアウト計算のベースとして使用されるタイムアウトを決定します。 Sap on Azure の推奨事項に従って、corosync トークンを 30000 に設定して、メモリを保持するメンテナンスを許可します。
Central Server インスタンス - CorosyncTokenHAASCSRH (SAP ワークロードでの ASCS HA セットアップで Pacemaker クラスターの corosync トークンを 30000 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップの Pacemaker の構成で、予想される投票パラメーターを 2 に設定する
2 ノード HA クラスターでは、SAP on Azure の推奨事項に従ってクォーラム投票を 2 に設定します。
Central Server インスタンス - ExpectedVotesHAASCSRH (SAP ワークロードの ASCS HA セットアップで Pacemaker 構成の予想される投票パラメーターを 2 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA のセットアップにおいて Pacemaker クラスターで "token_retransmits_before_loss_const" を 10 に設定する
corosync token_retransmits_before_loss_const は、HA クラスターがタイムアウトする前にトークン再送信が試みられる数を決定します。 ASCS HA セットアップの推奨事項に従って、totem.token_retransmits_before_loss_const を 10 に設定します。
Central Server インスタンス - TokenRestransmitsHAASCSSLE (SAP ワークロードの ASCS HA セットアップで Pacemaker クラスターの 'token_retransmits_before_loss_const' を 10 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA のセットアップで、Pacemaker クラスターの corosync トークンを 30000 に設定する
corosync トークン設定は、直接使用されるタイムアウト、または HA クラスターでの実際のトークン タイムアウト計算のベースとして使用されるタイムアウトを決定します。 Sap on Azure の推奨事項に従って、corosync トークンを 30000 に設定して、メモリを保持するメンテナンスを許可します。
Central Server インスタンス - CorosyncTokenHAASCSSLE (SAP ワークロードの ASCS HA セットアップで Pacemaker クラスターの corosync トークンを 30000 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA のセットアップで、Pacemaker クラスターの "corosync max_messages" を 20 に設定する
corosync max_messages 定数では、トークンの受信時に 1 つのプロセッサで送信できるメッセージの最大数を指定します。 Pacemaker クラスターの構成では、corosync トークン パラメーターの 20 倍に設定することをお勧めします。
Central Server インスタンス - CorosyncMaxMessagesHAASCSSLE (SAP ワークロードの ASCS HA セットアップで Pacemaker クラスターの 'corosync max_messages' を 20 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップの場合は Pacemaker クラスターの 'corosync consensus' を 36000 に設定する
corosync のパラメーター 'consensus' は、クラスター構成のメンバーシップの新しいラウンドを開始する前に、コンセンサスが達成されるのを待つ時間をミリ秒単位で指定します。 ASCS HA セットアップの場合は Pacemaker クラスター構成の corosync トークンの 1.2 倍に設定することをお勧めします。
Central Server インスタンス - CorosyncConsensusHAASCSSLE (SAP ワークロードの ASCS HA セットアップで Pacemaker クラスターの 'corosync consensus' を 36000 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップの場合はクラスター構成の expected_votes パラメーターを 2 に設定する
2 ノード HA クラスターでは、SAP on Azure の推奨事項に従ってクォーラム パラメーター expected_votes を 2 に設定します。
Central Server インスタンス - ExpectedVotesHAASCSSLE (SAP ワークロードの ASCS HA セットアップで行うクラスターの構成で、expected_votes を 2 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップの場合はクラスター構成の two_node パラメーターを 1 に設定する
2 ノード HA クラスターでは、SAP on Azure の推奨事項に従ってクォーラム パラメーター 'two_node' を 1 に設定します。
Central Server インスタンス - TwoNodesParametersHAASCSSLE (SAP ワークロードの ASCS HA セットアップでクラスター構成の two_node パラメーターを 1 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップの場合は Pacemaker クラスターの 'corosync join' を 60 に設定する
corosync join のタイムアウトは、メンバーシップ プロトコルで参加メッセージを待機する時間をミリ秒単位で指定します。 ASCS HA セットアップの Pacemaker クラスター構成では 60 に設定することをお勧めします。
Central Server インスタンスの詳細 - CorosyncJoinHAASCSSLE (SAP ワークロードの ASCS HA セットアップで Pacemaker クラスターの 'corosync join' を 60 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップの場合はクラスター構成の stonith が有効になっていることを確認する
Pacemaker クラスターでは、ノード レベルフェンスの実装は STONITH (ヘッド内の他のノードをシュートする) リソースを使用して行われます。 HA クラスター構成で 'stonith-enable' が 'true' に設定されていることを確認します。
Central Server インスタンス - StonithEnabledHAASCS (SAP ワークロードの ASCS HA セットアップで、クラスター構成の stonith が有効になっていることを確認する) に関する詳細を確認してください。
ASCS HA セットアップ用の Azure フェンス エージェントを使用して Pacemaker 構成で stonith-timeout を 900 に設定する
ASCS HA セットアップ用の Pacemaker の信頼性の高い機能を実現するには、stonith-timeout を 900 に設定します。 この stonith-timeout の設定は、マネージド ID またはサービス プリンシパルのどちらかを使用して、フェンス処理のために Azure フェンス エージェントを使用している場合に適用されます。
Central Server インスタンス - StonithTimeOutHAASCSSLE (ASCS HA セットアップで Azure フェンス エージェントを使用した Pacemaker 構成で stonith-timeout を 900 に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA のセットアップで Pacemaker の構成の "concurrent-fencing" パラメーターを有効にする
concurrent-fencing パラメーターを true に設定すると、フェンシング操作を並列に実行できます。 ASCS HA セットアップの場合は Pacemaker クラスター構成のこのパラメーターを 'true' に設定します。
Central Server インスタンス - ConcurrentFencingHAASCSSLE (SAP ワークロードの ASCS HA セットアップで Pacemaker 構成の 'concurrent-fencing' パラメーターを有効にする) に関する詳細を確認してください。
SAP ワークロードでの ASCS HA セットアップ用の Pacemaker 構成で softdog 構成ファイルを作成する
softdog タイマーは、linux OS のカーネル モジュールとして読み込まれます。 このタイマーは、システムがハングしたことを検出すると、システム リセットをトリガーします。 ASCS HA セットアップ用の Pacemaker クラスターで softdog 構成ファイルが作成されていることを確認します。
Central Server インスタンス - SoftdogConfigHAASCSSLE (SAP ワークロードの ASCS HA セットアップで Pacemaker 構成の softdog 構成ファイルを作成する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップで Pacemaler 用に softdog モジュールが読み込まれるようにする
softdog タイマーは、linux OS のカーネル モジュールとして読み込まれます。 このタイマーは、システムがハングしたことを検出すると、システム リセットをトリガーします。 まず、softdog 構成ファイルを作成したことを確認してから、ASCS HA セットアップ用の Pacemaker 構成で softdog モジュールを読み込みます。
Central Server インスタンス - softdogmoduleloadedHAASCSSLE (SAP ワークロードの ASCS HA セットアップで、Pacemaker 用に softdog モジュールが読み込まれるようにする) に関する詳細を確認してください。
ASCS HA セットアップの Pacemaker 構成に、fence_azure_arm のインスタンスが 1 つ存在することを確認する
fence_azure_arm は、Azure Resource Manager の I/O フェンス エージェントです。 ASCS HA セットアップの Pacemaker 構成に、fence_azure_arm のインスタンスが 1 つ存在することを確認してください。 fence_azure_arm の要件は、マネージド ID またはサービス プリンシパルのいずれかと共に、フェンス処理のために Azure フェンス エージェントを使用している場合に適用されます。
Central Server インスタンス - FenceAzureArmHAASCSSLE (ASCS HA セットアップ用の Pacemaker 構成に fence_azure_arm のインスタンスが 1 つあることを確認する) に関する詳細を確認してください。
SAP ワークロードで ASCS HA 設定用の Azure Load Balancer のフローティング IP を有効にする
SAP ワークロードでの ASCS インスタンスの HA 設定に関する負荷分散規則で HA ポートを有効にします。 ロード バランサーを開き、[負荷分散規則] を選択し、規則を追加または編集して推奨設定を有効にします。
Central Server インスタンス - ASCSHAEnableLBPorts (SAP ワークロードの ASCS HA セットアップで、Azure Load Balancer の HA ポートを有効にする) に関する詳細を確認してください。
SAP ワークロードで ASCS HA セットアップ用の Azure Load Balancer のフローティング IP を有効にする
SAP ワークロードでの ASCS インスタンスの HA 設定用の Azure Load Balancer の負荷分散規則でフローティング IP を有効にします。 ロード バランサーを開き、[負荷分散規則] を選択し、規則を追加または編集して推奨設定を有効にします。
Central Server インスタンス - ASCSHAEnableFloatingIpLB (SAP ワークロードの ASCS HA セットアップで Azure Load Balancer のフローティング IP を有効にする) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップで Azure Load Balancer のアイドル タイムアウトを 30 分に設定する
ロード バランサーのタイムアウトを防ぐには、すべての Azure 負荷分散規則の "アイドル タイムアウト (分)" が最大値の 30 分に設定されていることを確認します。 ロード バランサーを開き、[負荷分散規則] を選択し、規則を追加または編集して推奨設定を有効にします。
Central Server インスタンス - ASCSHASetIdleTimeOutLB (SAP ワークロードの ASCS HA セットアップで Azure Load Balancer のアイドル タイムアウトを 30 分に設定する) に関する詳細を確認してください。
SAP ワークロードの ASCS HA セットアップで Azure Load Balancer の背後に配置された VM 上の TCP タイムスタンプを無効にする
Azure Load Balancer の背後に配置された VM 上の TCP タイムスタンプを無効にします。 TCP タイムスタンプを有効にすると、TCP パケットが VM のゲスト OS TCP スタックによって破棄されるため、正常性プローブが失敗する原因になります。 TCP パケットが破棄されると、ロード バランサーがエンドポイントをダウンとしてマークする場合があります。
Central Server インスタンス - ASCSLBHADisableTCP (SAP ワークロードの ASCS HA セットアップで、Azure Load Balancer の背後に配置された VM の TCP タイムスタンプを無効にする) に関する詳細を確認してください。
Redhat OS を使用する VM に対して HA 対応 SAP ワークロードでのクラスターのコフィギュレーションで stonith を有効にする
Pacemaker クラスターでは、ノード レベルフェンスの実装は STONITH (ヘッド内の他のノードをシュートする) リソースを使用して行われます。 お使いのワークロードの HA クラスター構成で 'stonith-enable' が 'true' に設定されていることを確認します。
データベース インスタンス- StonithEnabledHARH (Redhat OS を使用する VM の HA を有効にした SAP ワークロードで、クラスター構成の stonith を有効にする) に関する詳細を確認してください。
HA が有効な SAP ワークロードのクラスターの構成に対して stonith タイムアウトを 144 に設定する
SAP on Azure の推奨事項に従って、HA クラスターの stonith タイムアウトを 144 に設定します。
データベース インスタンス - StonithTimeoutHASLE (HA が有効な SAP ワークロードのクラスター構成に対して stonith タイムアウトを 144 に設定する) に関する詳細を確認してください。
SUSE OS を使用する VM に対して HA 対応 SAP ワークロードでのクラスターのコフィギュレーションで stonith を有効にする
Pacemaker クラスターでは、ノード レベルフェンスの実装は STONITH (ヘッド内の他のノードをシュートする) リソースを使用して行われます。 HA クラスター構成で 'stonith-enable' が 'true' に設定されていることを確認します。
データベース インスタンス - StonithEnabledHASLE (SUSE OS を使用する VM の HA 対応 SAP ワークロードでクラスター構成の stonith を有効にする) に関する詳細を確認してください。
HANA DB HA セットアップ用の Azure フェンス エージェントを使用して Pacemaker 構成で stonith-timeout を 900 に設定する
HANA DB HA セットアップで Pacemaker の信頼性の高い機能を確保するには stonith-timeout を 900 に設定します。 この設定は、マネージド ID またはサービス プリンシパルでフェンス処理に Azure フェンス エージェントを使用している場合に重要です。
データベース インスタンス - StonithTimeOutSuseHDB (HANA DB HA セットアップで Azure フェンス エージェントを使用する Pacemaker 構成の stonith-timeout を 900 に設定する) に関する詳細を確認してください。
Pacemaker クラスターのcorosyncトークンを、Redhat OS を使用した VM 用 HA 対応 HANA DB の場合は 30000 に設定する
corosync トークン設定は、直接使用されるタイムアウト、または HA クラスターでの実際のトークン タイムアウト計算のベースとして使用されるタイムアウトを決定します。 Sap on Azure の推奨事項に従って、corosync トークンを 30000 に設定して、メモリを保持するメンテナンスを許可します。
データベース インスタンス - CorosyncTokenHARH (Redhat OS を使用する VM 用 HA 対応 HANA DB で Pacemaker クラスターのcorosync トークンを 30000 に設定する) に関する詳細を確認してください。
HA 対応 SAP ワークロードのクラスター構成で予想される投票パラメーターを 2 に設定する
2 ノード HA クラスターでは、SAP on Azure の推奨事項に従ってクォーラム投票を 2 に設定します。
データベース インスタンス - ExpectedVotesParamtersHARH (HA 対応 SAP ワークロードのクラスター構成で、予想される投票パラメーターを 2 に設定する) に関する詳細を確認してください。
Pacemaker クラスターのコロ同期トークンを、SUSE OS を使用した VM 用 HA 対応 HANA DB の場合は 30000 に設定する
corosync トークン設定は、直接使用されるタイムアウト、または HA クラスターでの実際のトークン タイムアウト計算のベースとして使用されるタイムアウトを決定します。 Sap on Azure の推奨事項に従って、corosync トークンを 30000 に設定して、メモリを保持するメンテナンスを許可します。
データベース インスタンス - CorosyncTokenHASLE (SUSE OS を使する VM の HA 対応 HANA DB で Pacemaker クラスターの corosync を 30000 に設定する) に関する詳細を確認してください。
HANA DB HA セットアップ向けの Pacemaker の構成で、パラメーター PREFER_SITE_TAKEOVER を "true" に設定する
SAP HANA トポロジの PREFER_SITE_TAKEOVER パラメーターは、HANA SR リソース エージェントが、障害が発生したプライマリのローカルでの再起動ではなく、セカンダリ インスタンスへの引き継ぎを優先するかどうかを定義します。 HANA DB HA セットアップの機能の信頼性を高くするには、これを "true" に設定します。
データベース インスタンス - PreferSiteTakeOverHARH (HANA DB HA セットアップで Pacemaker 構成の PREFER_SITE_TAKEOVER パラメーターを 'true' に設定する) に関する詳細を確認してください。
HANA DB HA のセットアップの Pacemaker の構成で "concurrent-fencing" パラメーターを有効にする
concurrent-fencing パラメーターを true に設定すると、フェンシング操作を並列に実行できます。 HANA DB HA セットアップ向けの Pacemaker クラスターの構成では、このパラメーターを 'true' に設定します。
データベース インスタンス - ConcurrentFencingHARH (HANA DB HA セットアップで Pacemaker 構成の 'concurrent-fencing' パラメーターを有効にする) に関する詳細を確認してください。
HA が有効な SAP ワークロードのクラスター構成でパラメーター PREFER_SITE_TAKEOVER を "true" に設定する
SAP HANA トポロジの PREFER_SITE_TAKEOVER パラメーターは、HANA SR リソース エージェントが、障害が発生したプライマリのローカルでの再起動ではなく、セカンダリ インスタンスへの引き継ぎを優先するかどうかを定義します。 HANA DB HA セットアップの機能の信頼性を高くするには、これを "true" に設定します。
データベース インスタンス - PreferSiteTakeoverHDB (HA 対応 SAP ワークロードのクラスター構成でパラメーター PREFER_SITE_TAKEOVER を 'true' に設定する) に関する詳細を確認してください。
HA 対応 SAP ワークロードの Pacemaker クラスターで "token_retransmits_before_loss_const" を 10 に設定する
corosync token_retransmits_before_loss_const は、HA クラスターがタイムアウトする前に試みるトークン再送信の数を決定します。 HANA DB HA セットアップの推奨事項に従って、totem.token_retransmits_before_loss_const を 10 に設定します。
データベース インスタンス - TokenRetransmitsHDB (HA を有効にした SAP ワークロードの Pacemaker クラスターで 'token_retransmits_before_loss_const' を 10 に設定する) に関する詳細を確認してください。
HA 対応 SAP ワークロードのクラスター構成で two_node パラメーターを 1 に設定する
2 ノード HA クラスターでは、SAP on Azure の推奨事項に従ってクォーラム パラメーター 'two_node' を 1 に設定します。
データベース インスタンス - TwoNodeParameterSuseHDB (HA を有効にした SAP ワークロードのクラスター構成で two_node パラメーターを 1 に設定する) に関する詳細を確認してください。
HA 対応 SAP ワークロードのクラスターの構成で "concurrent-fencing" パラメーターを有効にする
concurrent-fencing パラメーターを true に設定すると、フェンシング操作を並列に実行できます。 HANA DB HA セットアップ向けの Pacemaker クラスターの構成では、このパラメーターを 'true' に設定します。
データベース インスタンス - ConcurrentFencingSuseHDB (HA を有効にした SAP ワークロードのクラスター構成で 'concurrent-fencing' パラメーターを有効にする) に関する詳細を確認してください。
SAP ワークロードの HA 対応 HANA DB で、Pacemaker クラスターの "corosync join" を 60 に設定する
corosync join のタイムアウトは、メンバーシップ プロトコルで参加メッセージを待機する時間をミリ秒単位で指定します。 HANA DB HA セットアップ用の Pacemaker クラスター構成では 60 に設定することをお勧めします。
データベース インスタンス - CorosyncHDB (SAP ワークロードの HA を有効にした HANA DB で、Pacemaker クラスターの 'corosync join' を 60 に設定する) に関する詳細を確認してください。
SAP ワークロードの HA 対応 HANA DB で、Pacemaker クラスターの "corosync max_messages" を 20 に設定する
corosync max_messages 定数では、トークンの受信時に 1 つのプロセッサで送信できるメッセージの最大数を指定します。 Pacemaker クラスターの構成では、corosync トークン パラメーターの 20 倍に設定することをお勧めします。
データベース インスタンス - CorosyncMaxMessageHDB (SAP ワークロードの HA を有効にした HANA DB で、Pacemaker クラスターの 'corosync max_messages' を 20 に設定する) に関する詳細を確認してください。
SAP ワークロードの HA 対応 HANA DB で、Pacemaker クラスターの "corosync consensus" を 36000 に設定する
corosync のパラメーター "consensus" は、クラスター構成のメンバーシップの新しいラウンドを開始する前に、コンセンサスが達成されるのを待つ時間をミリ秒単位で指定します。 HANA DB HA のセットアップでは、Pacemaker クラスター構成の corosync トークンの 1.2 倍に設定することをお勧めします。
データベース インスタンス- CorosyncConsensusHDB (SAP ワークロードの HA を有効にした HANA DB で、Pacemaker クラスターの 'corosync consensus' を 36000 に設定する) に関する詳細を確認してください。
SAP ワークロードでの HA 対応 HANA DB 用の Pacemaker 構成で softdog 構成ファイルを作成する
softdog タイマーは、linux OS のカーネル モジュールとして読み込まれます。 このタイマーは、システムがハングしたことを検出すると、システム リセットをトリガーします。 HANA DB HA セットアップ用の Pacemaker クラスターで softdog 構成ファイルが作成されていることを確認します。
データベース インスタンス - SoftdogConfigSuseHDB (SAP ワークロードの HA 対応 HANA DB 用の Pacemaker 構成で softdog 構成ファイルを作成する) に関する詳細を確認してください。
HANA DB HA セットアップの Pacemaker 構成に、fence_azure_arm のインスタンスが 1 つ存在することを確認する
fence_azure_arm は、Azure Resource Manager の I/O フェンス エージェントです。 HANA DB HA セットアップの Pacemaker 構成に、fence_azure_arm のインスタンスが 1 つ存在することを確認してください。 マネージド ID またはサービス プリンシパルのどちらかを使用してフェンス処理するために Azure フェンス エージェントを使用している場合は、fence_azure arm インスタンスの要件が適用されます。
データベース インスタンス - FenceAzureArmSuseHDB (HANA DB HA セットアップで Pacemaker 構成に fence_azure_arm のインスタンスが 1 つあることを確認する) に関する詳細を確認してください。
SAP ワークロードの HA を有効にした HANA DB で Pacemaler 用に softdog モジュールが読み込まれていることを確認する
softdog タイマーは、linux OS のカーネル モジュールとして読み込まれます。 このタイマーは、システムがハングしたことを検出すると、システム リセットをトリガーします。 まず、softdog 構成ファイルを作成したことを確認してから、HANA DB HA セットアップ用の Pacemaker 構成で softdog モジュールを読み込みます。
データベース インスタンス - SoftdogModuleSuseHDB (SAP ワークロードで HA を有効にした HANA DB の Pacemaker に softdog モジュールが読み込まれるようにする) に関する詳細を確認してください。
SAP ワークロードの HANA DB HA セットアップで Azure Load Balancer のアイドル タイムアウトを 30 分に設定する
ロード バランサーのタイムアウトを防ぐには、すべての Azure 負荷分散規則の "アイドル タイムアウト (分)" が最大値の 30 分に設定されていることを確認します。 ロード バランサーを開き、[負荷分散規則] を選択し、規則を追加または編集して推奨設定を有効にします。
データベース インスタンス - DBHASetIdleTimeOutLB (SAP ワークロードの HANA DB HA セットアップで Azure Load Balancer のアイドル タイムアウトを 30 分に設定する) に関する詳細を確認してください。
SAP ワークロードで HANA DB HA セットアップ用の Azure Load Balancer でフローティング IP を有効にする
SAP ワークロードでの HANA DB インスタンスの HA 設定用の Azure Load Balancer の負荷分散規則でフローティング IP を有効にします。 ロード バランサーを開き、[負荷分散規則] を選択し、規則を追加または編集して推奨設定を有効にします。
データベース インスタンス - DBHAEnableFloatingIpLB (SAP ワークロードの HANA DB HA セットアップで Azure Load Balancer のフローティング IP を有効にする) に関する詳細を確認してください。
SAP ワークロードで HANA DB HA 設定用の Azure Load Balancer のフローティング IP を有効にする
SAP ワークロードでの HANA DB インスタンスの HA 設定に関する負荷分散規則で HA ポートを有効にします。 ロード バランサーを開き、[負荷分散規則] を選択し、規則を追加または編集して推奨設定を有効にします。
データベース インスタンス - DBHAEnableLBPorts (SAP ワークロードの HANA DB HA セットアップで Azure Load Balancer の HA ポートを有効にする) に関する詳細を確認してください。
SAP ワークロードの HANA DB HA セットアップで Azure Load Balancer の背後に配置された VM 上の TCP タイムスタンプを無効にする
Azure Load Balancer の背後に配置された VM 上の TCP タイムスタンプを無効にします。 TCP タイムスタンプを有効にすると、TCP パケットが VM のゲスト OS TCP スタックによって破棄されるため、正常性プローブが失敗する原因になります。 TCP パケットが破棄されると、ロード バランサーがエンドポイントをダウンとしてマークする場合があります。
データベース インスタンス - DBLBHADisableTCP (SAP ワークロードの HANA DB HA セットアップで Azure Load Balancer の背後に配置された VM で TCP タイムスタンプを無効にする) に関する詳細を確認してください。
HANA DB HA セットアップ用の Pacemaker 構成には、fence_azure_arm のインスタンスが 1 つ存在する必要があります
fence_azure_arm は、Azure Resource Manager の I/O フェンス エージェントです。 HANA DB HA セットアップの Pacemaker 構成に、fence_azure_arm のインスタンスが 1 つ存在することを確認します。 fence_azure_arm の要件は、マネージド ID またはサービス プリンシパルのいずれかと共に、フェンス処理のために Azure フェンス エージェントを使用している場合に必要です。
データベース インスタンス - FenceAzureArmSuseHDB (HANA DB HA セットアップで Pacemaker 構成に fence_azure_arm のインスタンスが 1 つあることが必要) に関する詳細を確認してください。
記憶域
Recovery Services コンテナーの論理的な削除を有効にする
論理的な削除のオプションを使用すると、削除後に追加の期間、Recovery Services コンテナーにバックアップ データを保存しておくことができます。 追加の期間には、データが完全に削除される前にデータを取り出すことができます。
Recovery Services コンテナー - AB-SoftDeleteRsv (Recovery Services コンテナーの論理的な削除を有効にする) に関する詳細を確認してください。
Recovery Services コンテナーのリージョン間の復元を有効にする
geo 冗長コンテナーのリージョン間の復元を有効にします。
Recovery Services コンテナー - CRR を有効にする (Recovery Services コンテナーのリージョン間の復元を有効にする) に関する詳細を確認してください。
仮想マシンでバックアップを有効にする
ご利用の仮想マシンに対するバックアップを有効にし、データをセキュリティで保護します。
仮想マシン (クラシック) - EnableBackup (仮想マシンでバックアップを有効にする) に関する詳細を確認してください。
BLOB バックアップの作成
BLOB バックアップを構成します。
ストレージ アカウント - ConfigureBlobBackup (BLOB バックアップの構成) に関する詳細を確認してください。
Azure Backup を有効にして、データのシンプルで信頼性が高く、コスト効率の高い保護を実現する
Azure の堅牢な、一括選択のバックアップを使用して、情報とアプリケーションを安全に維持します。 Azure Backup をアクティブ化して、VM、SQL データベース、アプリケーション、ファイル共有などの、広範なワークロードに対してコスト効率の高い保護を実現します。
サブスクリプション - AzureBackupService (Azure Backup を有効にして、シンプルで信頼性が高く、コスト効率の高いデータの保護を実現する) に関する詳細を確認してください。
ADLS Gen2 に移行する必要がある ADLS Gen1 アカウントがある
既にお知らせしたとおり、Azure Data Lake Storage Gen1 は、2024 年 2 月 29 日に廃止される予定です。 データ レイクを Azure Data Lake Storage Gen2 に移行しておくことを強くお勧めします。 Azure Data Lake Storage Gen2 には、ビッグ データ分析用に設計された高度な機能が用意されており、Azure Blob Storage 上に構築されています。
Data Lake Store アカウント - ADLSGen1_Deprecation (ADLS Gen2 に移行する必要がある ADLS Gen1 アカウントがある) に関する詳細を確認してください。
ADLS Gen2 に移行する必要がある ADLS Gen1 アカウントがある
既にお知らせしたとおり、Azure Data Lake Storage Gen1 は、2024 年 2 月 29 日に廃止される予定です。 データ レイクを Azure Data Lake Storage Gen2 に移行することを強くお勧めします。これは、ビッグ データ分析用に設計された高度な機能を提供します。 Azure Data Lake Storage Gen 2 は、Azure Blob Storage 上に構築されています。
Data Lake Store アカウント - ADLSGen1_Deprecation (ADLS Gen2 に移行する必要がある ADLS Gen1 アカウントがある) に関する詳細を確認してください。
BLOB データを保護するために論理的な削除を有効にする
論理的な削除を有効にすると、削除されたデータは、完全に消去されるのではなく、“論理的に” 削除された状態に移行します。 データを上書きした場合、上書きされたデータの状態を保存するために、論理的に削除されたスナップショットが生成されます。 論理的に削除されたデータが完全に有効期限切れになって復旧できなくなるまでの時間を構成することができます。
ストレージ アカウント - StorageSoftDelete (BLOB データを保護するために論理的な削除を有効にする) に関する詳細を確認してください。
容量の上限に近づいているストレージ アカウントでのマネージド ディスクの使用
Premium Storage の容量制限に達しようとしているストレージ アカウントで、Premium SSD アンマネージド ディスクが使用されていることが確認されました。 この上限に達したときに発生するエラーを回避するために、アカウントの容量制限のないマネージド ディスクに移行することをお勧めします。 この移行はポータルを使用して 5 分以内に完了できます。
ストレージ アカウント - StoragePremiumBlobQuotaLimit (容量の上限に近づいているストレージ アカウントに Managed Disks を使用する) に関する詳細を確認してください。
ゾーン冗長ストレージ (ZRS) を有効にした Azure ディスクを使用して回復性と可用性を高める
ZRS を有効にした Azure ディスクでは、リージョン内の 3 つの可用性ゾーン間でデータの同期レプリケーションが行われ、アプリケーションを中断することなく、ゾーンの障害に対する耐性をディスクに提供します。 回復性と可用性を高めるために、LRS から ZRS にディスクを移行してください。
詳細については、Azure マネージド ディスクの種類の変更に関するページを参照してください。
データの信頼性を改善するために Managed Disks を使用する
ストレージ アカウントまたはストレージ スケール ユニットを共有するディスクを使用する可用性セット内の仮想マシンは、停止時のストレージ スケール ユニットの単一障害に対する回復性がありません。 Azure Managed Disks に移行すると、可用性セット内の異なる VM のディスクが十分に分離され、単一障害点が回避されます。
可用性セット - ManagedDisksAvSet (データの信頼性を改善するために Managed Disks を使用する) に関する詳細を確認してください。
Azure NetApp Files リソースのディザスター リカバリー戦略を実装する
リージョンまたはゾーンの障害が発生した場合のデータや機能の損失を回避するには、リージョン間レプリケーションや Azure NetApp Files ボリュームのクロス ゾーン レプリケーションなどの一般的なディザスター リカバリー手法を実装します
ボリュームの詳細 - ANFCRRCZRRecommendation (Azure NetApp Files リソースのディザスター リカバリー戦略を実装する) に関する詳細を確認してください。
Azure NetApp Files で SMB ボリュームの継続的な可用性を可能にする
継続的可用性のために SMB ボリュームを有効にするための推奨事項。
ボリューム - anfcaenablement (Azure NetApp Files で SMB ボリュームの継続的な可用性を有効にする) に関する詳細を確認してください。
Azure NetApp Files で使用されるタイムアウト値については、SAP 構成を確認してください
Azure NetApp Files で使用されている SAP の高可用性は、アプリケーションの中断を防ぐために適切なタイムアウト値を設定する必要があります。 ドキュメントを確認して、構成がドキュメントに記載されているタイムアウト値を満たしていることを確認します。
ボリューム - SAPTimeoutsANF (Azure NetApp Files で使用されるタイムアウト値については、SAP 構成を確認する) に関する詳細を確認してください。
Web
CPU 不足を避けるために App Service プランをスケールアウトすることを検討する
お使いのアプリは過去 2 日間に 90% 超の CPU に達しました。 CPU の使用率が高いと、アプリの実行時に問題が発生する可能性があります。この問題を解決するには、アプリをスケールアウトします。
App Service - AppServiceCPUExhaustion (CPU 不足を避けるために App Service プランをスケールアウトすることを検討する) に関する詳細を確認してください。
App Service リソースのバックアップ データベース設定を修正する
DB 構成が無効なため、アプリのバックアップが常に失敗します。詳細については、バックアップ履歴を参照してください。
App Service - AppServiceFixBackupDatabaseSettings (App Service リソースのバックアップ データベース設定を修正する) に関する詳細を確認してください。
メモリ不足を避けるために App Service プラン SKU をスケールアップすることを検討する
アプリを含む App Service プランは、割り当てられたメモリの 85% 超に達しました。 メモリ消費量が多いと、アプリの実行時に問題が発生する可能性があります。 App Service プラン内のどのアプリがメモリを消費しているかを調査し、必要に応じて、メモリ リソースを増やしてより高いプランにスケール アップします。
App Service - AppServiceMemoryExhaustion (メモリ不足を避けるために App Service プラン SKU をスケールアップすることを検討する) に関する詳細を確認してください。
App Service リソースをスケールアップしてクォータ制限を削除する
お使いのアプリは共有 App Service プランの一部であり、クォータに複数回達しています。 クォータに達すると、Web アプリで受信要求を受け取ることができなくなります。 クォータを削除するには、Standard プランにアップグレードします。
App Service - AppServiceRemoveQuota (App Service リソースをスケールアップしてクォータ制限を削除する) に関する詳細を確認してください。
App Service リソースのデプロイ スロットを使用する
過去 1 週間に複数回アプリケーションをデプロイしました。 デプロイ スロットは、変更を管理し、運用 Web アプリへのデプロイの影響を軽減するために役立ちます。
App Service - AppServiceUseDeploymentSlots (App Service リソースのデプロイ スロットを使用する) に関する詳細を確認してください。
App Service リソースのバックアップ ストレージ設定を修正する
ストレージ設定が無効なため、アプリのバックアップが常に失敗します。詳細については、バックアップ履歴を参照してください。
App Service - AppServiceFixBackupStorageSettings (App Service リソースのバックアップ ストレージ設定を修正する) に関する詳細を確認してください。
App Service リソースを Standard 以上に移行し、デプロイ スロットを使用する
過去 1 週間に複数回アプリケーションをデプロイしました。 デプロイ スロットは、変更を管理し、運用 Web アプリへのデプロイの影響を軽減するために役立ちます。
App Service - AppServiceStandardOrHigher (App Service リソースを Standard 以上に移行し、デプロイ スロットを使用する) に関する詳細を確認してください。
ユーザー エクスペリエンスと可用性を最適化するには、App Service プランをスケールアウトすることを検討します
定期的なメンテナンスの間にコールド スタートの遅延とサービスの中断を回避するには、App Service プランを少なくとも 2 インスタンスにスケールアウトすることを検討します。
App Service プラン - AppServiceNumberOfInstances (ユーザー エクスペリエンスと可用性を最適化するため、App Service プランのスケールアウトを検討する) に関する詳細を確認してください。
ハンドルされない例外が原因でワーカー プロセスがクラッシュした場合はアプリケーション コードを修正する必要がある
次のスレッドが原因で、アプリにハンドルされない例外が発生したため、アプリケーション可用性への影響を防ぐためにアプリケーション コードを修正する必要があることがわかりました。 クラッシュはコード内の例外でプロセスが終了した場合に発生します。
App Service - AppServiceProactiveCrashMonitoring (ハンドルされない例外が原因でワーカー プロセスがクラッシュしたため、アプリケーション コードを修正する必要がある) に関する詳細を確認してください。
App Service 構成を 64 ビットに変更することを検討してください
アプリケーションが 32 ビットで実行されており、メモリが 2 GB の制限に達していることが確認されました。 Web Worker ロールで使用可能な追加のメモリを利用できるように、64 ビット プロセスへの切り替えを検討してください。 このアクションにより Web アプリの再起動がトリガーされるため、それに応じてスケジュールします。
App Service の 32 ビットの制限事項の詳細を確認してください。
Azure Fluid Relay クライアント ライブラリをアップグレードする
最近、古いクライアント ライブラリを使用して Azure Fluid Relay サービスを呼び出しました。 お使いの Azure Fluid Relay クライアント ライブラリを最新バージョンにアップグレードして、アプリケーションが引き続き動作するようにする必要があります。 アップグレードすると、最新の機能が提供され、パフォーマンスと安定性が向上します。 使用する最新バージョンとアップグレード方法の詳細については、次の記事を参照してください。
Fluid Relay サーバー - UpgradeClientLibrary (Azure Fluid Relay クライアント ライブラリをアップグレードする) に関する詳細を確認してください。
このサブスクリプション内の静的 Web アプリのホスティング プランを Standard SKU にアップグレードすることを検討する
このサブスクリプション内のすべての無料の SKU 静的 Web アプリで使用される帯域幅合計が、100 GB の月ごとの制限を超えています。 調整を回避するために、これらのアプリを Standard SKU にアップグレードすることを検討してください。
静的 Web アプリ - StaticWebAppsUpgradeToStandardSKU (このサブスクリプション内の静的 Web アプリのホスティング プランを Standard SKU にアップグレードすることを検討する) に関する詳細を確認してください。