仮想コア サービス層、Azure ハイブリッド特典、および移行vCore service tiers, Azure Hybrid Benefit, and migration

仮想コア ベースの購入モデルでは、コンピューティングおよびストレージ リソースを個別にスケーリングし、オンプレミスのパフォーマンスを一致させて、コストを最適化できます。The vCore-based purchasing model enables you to independently scale compute and storage resources, match on-premises performance, and optimize price. ハードウェアの世代を選択することもできます。It also enables you to choose generation of hardware:

  • Gen4 - Intel E5-2673 v3 (Haswell) 2.4 GHz プロセッサに基づく最大 24 個の論理 CPU、仮想コア = 1 PP (物理コア)、7 GB/コア、接続されている SSDGen4 - Up to 24 logical CPUs based on Intel E5-2673 v3 (Haswell) 2.4 GHz processors, vCore = 1 PP (physical core), 7 GB per core, attached SSD
  • Gen5 - Intel E5-2673 v4 (Broadwell) 2.3 GHz プロセッサに基づく最大 80 個の論理 CPU、仮想コア = 1 LP (ハイパースレッド)、5.1 GB/コア、高速 eNVM SSDGen5 - Up to 80 logical CPUs based on Intel E5-2673 v4 (Broadwell) 2.3 GHz processors, vCore=1 LP (hyper-thread), 5.1 GB per core, fast eNVM SSD

Gen4 ハードウェアでは、仮想コアあたり大幅に多くのメモリが提供されます。Gen4 hardware offers substantially more memory per vCore. 一方、Gen5 ハードウェアでは、コンピューティング リソースをはるかに高くまでスケールアップできます。However, Gen5 hardware allows you to scale up compute resources much higher.

注意

DTU ベースのサービス レベルの詳細については、DTU ベースのサービス レベルに関するページを参照してください。For information about DTU-based service tiers, see DTU-based service tiers. DTU ベースのサービス レベルと仮想コアベースのサービス レベルの違いの詳細については、Azure SQL Database の購入モデルに関するページを参照してください。For information about differentiating DTU-based service tiers and vCore-based service tiers, see Azure SQL Database purchasing models.

サービス レベルの特性Service tier characteristics

仮想コア モデルでは、General Purpose、Hyperscale、Business Critical の 3 つのサービス レベルが提供されます。The vCore model provides three service tiers General Purpose, Hyperscale and Business Critical. サービス レベルは、さまざまなコンピューティング サイズ、高可用性の設計、障害の分離、ストレージの種類、ストレージのサイズ、IO 範囲によって区別されます。Service tiers are differentiated by a range of compute sizes, high availability design, fault isolation, types and size of storage and IO range. バックアップ用に必要なストレージと保有期間を個別に構成する必要があります。You must separately configure the required storage and retention period for backups. Azure portal で、(データベースではなく) [サーバー] > [マネージド バックアップ] > [ポリシーの構成] > [Point In Time Restore Configuration](ポイント イン タイム リストア構成) > [7 - 35 days](7 ~ 35 日) の順に移動します。In the Azure portal, go to Server (not the database) > Managed Backups > Configure Policy > Point In Time Restore Configuration > 7 - 35 days.

次の表は、この 3 つのレベルの違いを把握するうえで役立ちます。The following table helps you understand the differences between the three tiers:

汎用General Purpose Business CriticalBusiness Critical ハイパースケール (プレビュー)Hyperscale (preview)
最適な用途Best for ほとんどのビジネス ワークロード。Most business workloads. 予算重視のスケーラブルでバランスの取れたコンピューティングおよびストレージ オプションを提供します。Offers budget oriented balanced and scalable compute and storage options. IO 要件の高いビジネス アプリケーション。Business applications with high IO requirements. 分離された複数のレプリカを使用して、最高の耐障害性が提供されます。Offers highest resilience to failures using several isolated replicas. 高度にスケーラブルなストレージと読み取りスケールの要件を持つほとんどのビジネス ワークロードMost business workloads with highly scalable storage and read-scale requirements
ComputeCompute Gen4:1 ~ 24 仮想コアGen4: 1 to 24 vCore
Gen5:1 ~ 80 仮想コアGen5: 1 to 80 vCore
Gen4:1 ~ 24 仮想コアGen4: 1 to 24 vCore
Gen5:1 ~ 80 仮想コアGen5: 1 to 80 vCore
Gen4:1 ~ 24 仮想コアGen4: 1 to 24 vCore
Gen5:1 ~ 80 仮想コアGen5: 1 to 80 vCore
メモリMemory Gen4:コアあたり 7 GBGen4: 7 GB per core
Gen5:コアあたり 5.1 GBGen5: 5.1 GB per core
Gen4:コアあたり 7 GBGen4: 7 GB per core
Gen5:コアあたり 5.1 GBGen5: 5.1 GB per core
Gen4:コアあたり 7 GBGen4: 7 GB per core
Gen5:コアあたり 5.1 GBGen5: 5.1 GB per core
StorageStorage リモート ストレージの使用:Uses remote storage:
単一データベース:5 GB – 4 TBSingle database: 5 GB – 4 TB
Managed Instance:32 GB ~ 8 TBManaged Instance: 32 GB - 8 TB
ローカル SSD ストレージの使用:Uses local SSD storage:
単一データベース:5 GB – 4 TBSingle database: 5 GB – 4 TB
Managed Instance:32 GB ~ 4 TBManaged Instance: 32 GB - 4 TB
柔軟性が高く、必要に応じて自動拡張されるストレージ。Flexible, autogrow of storage as needed. 最大 100 TB のストレージなどをサポートします。Supports up to 100 TB storage and beyond. ローカル バッファー プール キャッシュとローカル データ ストレージ用のローカル SSD ストレージ。Local SSD storage for local buffer pool cache and local data storage. 最終的な長期データ ストアとしての Azure リモート ストレージ。Azure remote storage as final long-term data store.
IO スループット (概算)IO throughput (approximate) 単一データベース:仮想コアあたり 500 IOPS (最大 7000 IOPS)Single database: 500 IOPS per vCore with 7000 maximum IOPS
Managed Instance:ファイル サイズに依存Managed Instance: Depends on size of file
コアあたり 5000 IOPS (最大 200,000 IOPS)5000 IOPS per core with 200,000 maximum IOPS TBDTBD
可用性Availability 1 レプリカ、読み取りスケールなし1 replica, no read-scale 3 レプリカ、1 読み取りスケール レプリカ3 replicas, 1 read-scale replica,
ゾーン冗長 HAzone redundant HA
??
バックアップBackups RA-GRS、7 ~ 35 日 (既定では 7 日)RA-GRS, 7-35 days (7 days by default) RA-GRS、7 ~ 35 日 (既定では 7 日)RA-GRS, 7-35 days (7 days by default) Azure リモート ストレージおよび復元のスナップショットベースのバックアップは、高速復旧のためにこのようなスナップショットを使用します。snapshot-based backup in Azure remote storage and restores use these snapshots for fast recovery. バックアップは瞬時に行われ、Compute の IO パフォーマンスには影響しません。Backups are instantaneous and do not impact the IO performance of Compute. 復元は非常に高速で、データ操作のサイズにはなりません (数時間 ~ 数日ではなく、分単位で行われます)。Restores are very fast and are not a size of data operation (taking minutes rather than hours or days).
インメモリIn-Memory サポートされていませんNot supported サポートされていますSupported サポートされていませんNot supported

注意

Azure 無料アカウントと組み合わせて Basic サービス レベルで無料の Azure SQL Database を取得して、Azure を探索できます。You can get a free Azure SQL database at the Basic service tier in conjunction with a Azure free account to explore Azure. 詳細については、「Azure の無料アカウントでマネージド クラウド データベースを作成する」をご覧ください。For information, see Create a managed cloud database with your Azure free account.

重要

必要なコンピューティング能力が仮想コア 1 つ分を下回る場合は、DTU ベースの購入モデルを使用します。If you need less than one vCore of compute capacity, use the DTU-based purchasing model.

Azure ハイブリッド特典Azure Hybrid Benefit

仮想コアベースの購入モデルでは、SQL Server 向け Azure ハイブリッド特典を利用して、お使いの既存のライセンスを SQL Database の割引料金のライセンスに交換できます。In the vCore-based purchasing model, you can exchange your existing licenses for discounted rates on SQL Database using the Azure Hybrid Benefit for SQL Server. この Azure 特典では、オンプレミスのソフトウェア アシュアランス付き SQL Server ライセンスを利用することで、オンプレミスの SQL Server ライセンスで Azure SQL Database の料金が最大 30% オフになります。This Azure benefit allows you to use your on-premises SQL Server licenses to save up to 30% on Azure SQL Database using your on-premises SQL Server licenses with Software Assurance.

価格

Azure ハイブリッド特典では、SQL データベース エンジン自体については既存の SQL Server ライセンスを使用して、基になる Azure インフラストラクチャについてのみ支払うか (BasePrice)、それとも基になるインフラストラクチャと SQL Server ライセンスの両方を支払うか (LicenseIncluded) を選択できます。With the Azure Hybrid Benefit, you can choose to only pay for the underlying Azure infrastructure using your existing SQL Server license for the SQL database engine itself (BasePrice) or pay for both the underlying infrastructure and the SQL Server license (LicenseIncluded). Azure portal または次の API のいずれかを使用して、ライセンス モデルを選択または変更できます。You can choose or change your licensing model using the Azure portal or using one of the following APIs.

DTU モデルから仮想コア モデルへの移行Migration from DTU model to vCore model

データベースの移行Migration of a database

DTU ベースの購入モデルから仮想コア ベースの購入モデルへデータベースを移行することは、DTU ベースの購入モデルの Standard および Premium データベース間のアップグレードまたはダウングレードとほぼ同じです。Migrating a database from the DTU-based purchasing model to the vCore-based purchasing model is similar to upgrading or downgrading between Standard and Premium databases in the DTU-based purchasing model.

DTU ベースのモデルから仮想コアベースのモデルへの移行は、Standard データベースと Premium データベースの間で geo レプリケーション関係をアップグレードまたはダウングレードするのと似ています。Migrating from the DTU-based model to the vCore-based model is similar to upgrading or downgrading the geo-replication relationships between Standard and Premium databases. geo レプリケーションを終了する必要はありませんが、ユーザーは、シーケンス処理ルールに従う必要があります。It does not require terminating geo-replication but the user must observe the sequencing rules. アップグレードの場合は、最初にセカンダリ データベースをアップグレードしてから、プライマリをアップグレードする必要があります。When upgrading, you must upgrade the secondary database first, and then upgrade the primary. ダウングレードは逆の順序で行います。つまり、最初にプライマリ データベースをダウングレードしてから、セカンダリをダウングレードします。When downgrading, reverse the order: you must downgrade the primary database first, and then downgrade the secondary.

2 つのエラスティック プールの間で geo レプリケーションを使用している場合は、一方のプールをプライマリとして指定し、もう一方をセカンダリとして指定することをお勧めします。When using geo-replication between two elastic pools, it is recommended that you designate one pool as the primary and the other – as the secondary. その場合、エラスティック プールの移行でも同じガイダンスが使用されます。In that case, migrating elastic pools should use the same guidance. ただし、技術的には、1 つのエラスティック プールに、プライマリ データベースとセカンダリ データベースの両方を含めることができます。However, it is technically it is possible that an elastic pool contains both primary and secondary databases. この場合、正しく移行するには、使用率の高い方のプールを "プライマリ" と見なし、適宜シーケンス処理ルールに従います。In this case, to properly migrate you should treat the pool with the higher utilization as “primary” and follow the sequencing rules accordingly.

次の表に、具体的な移行シナリオのガイダンスを示します。The following table provides guidance for the specific migration scenarios:

現在のサービス レベルCurrent service tier 移行先のサービス レベルTarget service tier 移行の種類Migration type ユーザー操作User actions
標準Standard 汎用General purpose ラテラルLateral 任意の順序で移行できますが、適切な仮想コア サイズを確保する必要があります*Can migrate in any order, but need to ensure an appropriate vCore sizing*
PremiumPremium Business CriticalBusiness Critical ラテラルLateral 任意の順序で移行できますが、適切な仮想コア サイズを確保する必要があります*Can migrate in any order, but need to ensure appropriate vCore sizing*
標準Standard Business CriticalBusiness Critical アップグレードUpgrade セカンダリを最初に移行する必要がありますMust migrate secondary first
Business CriticalBusiness Critical 標準Standard ダウングレードDowngrade プライマリを最初に移行する必要がありますMust migrate primary first
PremiumPremium 汎用General purpose ダウングレードDowngrade プライマリを最初に移行する必要がありますMust migrate primary first
汎用General purpose PremiumPremium アップグレードUpgrade セカンダリを最初に移行する必要がありますMust migrate secondary first
Business CriticalBusiness Critical 汎用General purpose ダウングレードDowngrade プライマリを最初に移行する必要がありますMust migrate primary first
汎用General purpose Business CriticalBusiness Critical アップグレードUpgrade セカンダリを最初に移行する必要がありますMust migrate secondary first

* Standard レベルでは 100 DTU ごとに 1 つ以上の仮想コア、Premium レベルでは 125 DTU ごとに 1 つ以上の仮想コアが必要です* Each 100 DTU in Standard tier requires at least 1 vCore and each 125 DTU in Premium tier requires at least 1 vCore

フェールオーバー グループの移行Migration of failover groups

複数のデータベースが含まれるフェールオーバー グループの移行では、プライマリ データベースとセカンダリ データベースを個別に移行する必要があります。Migration of failover groups with multiple databases requires individual migration of the primary and secondary databases. その処理中は、同じ考慮事項とシーケンス処理ルールが適用されます。During that process, the same considerations and sequencing rules apply. データベースが仮想コアベースのモデルに変換された後も、フェールオーバー グループには、同じポリシー設定が引き続き有効になります。After the databases are converted to the vCore-based model, the failover group will remain in effect with the same policy settings.

geo レプリケーション セカンダリの作成Creation of a geo-replication secondary

プライマリと同じサービス レベルを使用して、geo セカンダリのみを作成できます。You can only create a geo-secondary using the same service tier as the primary. ログ生成率が高いデータベースの場合、プライマリと同じコンピューティング サイズでセカンダリを作成することをお勧めします。For database with high log generation rate, it is advised that the secondary is created with the same compute size as the primary. 単一プライマリ データベースに対してエラスティック プールに geo セカンダリを作成する場合、そのプールの maxVCore 設定を、プライマリ データベースのコンピューティング サイズと一致させることをお勧めします。If you are creating a geo-secondary in the elastic pool for a single primary database, it is advised that the pool has the maxVCore setting that matches the primary database compute size. geo セカンダリの作成先エラスティック プールと、そのプライマリがあるエラスティック プールが異なる場合、その 2 つのプールの maxVCore 設定を同じにすることをお勧めしますIf you are creating a geo-secondary in the elastic pool for a primary in another elastic pool, it is advised that the pools have the same maxVCore settings

データベースのコピーを使用した、DTU ベースのデータベースから仮想コアベースのデータベースへの変換Using database copy to convert a DTU-based database to a vCore-based database

DTU ベース コンピューティング サイズのデータベースを、仮想コアベース コンピューティング サイズのデータベースにコピーする場合、コピー先のコンピューティング サイズが、コピー元データベースの最大データベース サイズをサポートしている限り、制限や特別なシーケンス処理は伴いません。You can copy any database with a DTU-based compute size to a database with a vCore-based compute size without restrictions or special sequencing as long as the target compute size supports the maximum database size of the source database. データベースのコピーによって、コピー操作を開始した時点のデータ スナップショットが作成されるので、コピー元とコピー先の間でデータ同期が行われません。The database copy creates a snapshot of data as of the starting time of the copy operation and does not perform data synchronization between the source and the target.

次の手順Next steps