ビジネス継続性とデータベース復旧 - SQL Server on LinuxBusiness continuity and database recovery - SQL Server on Linux

このトピックに適用されますはいSQL ServerありませんAzure SQL DatabaseありませんAzure SQL Data Warehouseありません。並列データ ウェアハウスTHIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

この記事では、SQL Server での高可用性とディザスター リカバリーのためのビジネス継続性ソリューションの概要を提供します。This article provides an overview of business continuity solutions for high availability and disaster recovery in SQL Server.

SQL Server を展開するすべての人が行う必要がある 1 つの共通タスクは、すべてのミッション クリティカルな SQL Server インスタンスとそれらに含まれるデータベースを、ビジネスおよびエンド ユーザーが必要とするときに (9 時から 5 時であろうと、24 時間であろうと) 使えるようにすることです。One common task everyone deploying SQL Server has to account for is making sure that all mission critical SQL Server instances and the databases within them are available when the business and end users need them, whether that is 9 to 5 or around the clock. 目標は、最小限の中断または中断なく、ビジネスを継続させることです。The goal is to keep the business up and running with minimal or no interruption. この概念は、ビジネス継続性とも呼ばれます。This concept is also known as business continuity.

SQL Server 2017 では、多くの新機能の導入と、既存機能への強化が行われ、そのいくつかは可用性に対するものです。SQL Server 2017 introduces many new features or enhancements to existing ones, some of which are for availability. SQL Server 2017 の最大の補強は、Linux ディストリビューションでの SQL Server のサポートです。The biggest addition to SQL Server 2017 is the support for SQL Server on Linux distributions. SQL Server 2017 の新機能の完全なリストについては、「SQL Server 2017 の新機能」のトピックを参照してください。For a full list of the new features in SQL Server 2017, see the topic What's new in SQL Server.

この記事では、SQL Server 2017 の可用性シナリオと、SQL Server 2017 の新機能と強化された機能について重点的に取り上げます。This article is focused on covering the availability scenarios in SQL Server 2017 as well as the new and enhanced availability features in SQL Server 2017. シナリオには、Windows Server と Linux の両方にまたがって SQL Server を展開できるハイブリッドなものと、データベースの読み取り可能なコピーの数を増やすことができるものが含まれます。The scenarios include hybrid ones that will be able to span SQL Server deployments on both Windows Server and Linux, as well as ones that can increase the number of readable copies of a database. この記事では、SQL Server 以外の可用性オプション (仮想化によって提供される可用性オプションなど) は取り上げません。ここで説明しているものはすべて、パブリック クラウドであれ、オンプレミスのハイパーバイザー サーバーであれ、ゲスト仮想マシン内の SQL Server のインストールに適用されます。While this article does not cover availability options external to SQL Server, such as those provided by virtualization, everything discussed here applies to SQL Server installations inside a guest virtual machine whether in the public cloud or hosted by anon premises hypervisor server.

可用性機能を使用した SQL Server 2017 のシナリオSQL Server 2017 scenarios using the availability features

可用性グループ、FCI、およびログ配布は、さまざまな方法で使用でき、必ずしも可用性を高めるためだけのものではありません。Availability groups, FCIs, and log shipping can be used in a variety of ways, and not necessarily just for availability purposes. 可用性機能を使用できる 4 つの主な方法があります。There are four main ways the availability features can be used:

  • 高可用性High availability
  • ディザスター リカバリーDisaster recovery
  • 移行とアップグレードMigrations and upgrades
  • 1 つ以上のデータベースの読み取り可能なコピーのスケール アウトScaling out readable copies of one or more databases

各セクションでは、その特定のシナリオに使用できる関連機能について説明します。Each section will discuss the relevant features that can be used for that particular scenario. SQL Server レプリケーションの機能については、取り上げません。The one feature not covered is SQL Server replication. これは Always On の傘下の可用性機能としては正式に指定されていませんが、特定のシナリオでデータに冗長性を持たせるためによく使用されます。While not officially designated as an availability feature under the Always On umbrella, it is often used for making data redundant in certain scenarios. レプリケーションは、SQL Server on Linux の将来のリリースで追加される予定です。Replication will be added to SQL Server on Linux in a future release.

重要

SQL Server の可用性機能は、可用性ソリューションの最も基本的なビルディング ブロックである、堅牢で十分にテストされたバックアップと復元方法を持つという要件に取って代わるものではありません。The SQL Server availability features do not replace the requirement to have a robust, well tested backup and restore strategy, the most fundamental building block of any availability solution.

高可用性High availability

データ センターの局所またはクラウド領域内の 1 つの領域で問題が発生した場合に、SQL Server インスタンスまたはデータベースを使用できることを保証することが重要です。Ensuring that SQL Server instances or database are available in the case of a problem that is local to a data center or single region in the cloud region is important. このセクションでは、SQL Server の可用性機能がそのタスクでどのように役立つかを説明します。This section will cover how the SQL Server availability features can assist in that task. 記載されているすべての機能は、Windows Server と Linux の両方で使用できます。All of the features described are available both on Windows Server as well as on Linux.

Always On 可用性グループAlways on availability groups

SQL Server 2012 で導入された、Always On 可用性グループ (可用性グループ) は、データベースの各トランザクションを、そのデータベースのコピーを含むレプリカと呼ばれる別のインスタンスに、特殊な状態で送信することによって、データベース レベルの保護を提供します。Introduced in SQL Server 2012, Always On Availability Groups (availability groups) provide database-level protection by sending each transaction of a database to another instance, known as a replica, that contains a copy of that database in a special state. 可用性グループは、Standard Edition または Enterprise Edition に展開できます。An availability group can be deployed on Standard or Enterprise Editions. 可用性グループに参加しているインスタンスは、スタンドアロンまたは Always On フェールオーバー クラスター インスタンス (FCI、次のセクションで説明) のいずれかにすることができます。The instances participating in an availability group can be either standalone or Always On Failover Cluster Instances (FCIs, described in the next section). トランザクションは、発生したときにレプリカに送信されるため、回復ポイントの目標と復旧時間の目標の要件がより低い可用性グループが推奨されます。Since the transactions are sent to a replica as they happen, availability groups are recommended where there are requirements for lower recovery point and recovery time objectives. レプリカ間のデータ移動は、同期または非同期で行うことができます。Enterprise Edition では、最大 3 つのレプリカ (プライマリを含む) を同期で行うことを許可しています。Data movement between replicas can be synchronous or asynchronous, with Enterprise Edition allowing up to three replicas (including the primary) as synchronous. 可用性グループには、プライマリ レプリカにあるデータベースの完全な読み取り/書き込みコピーが 1 つありますが、すべてのセカンダリ レプリカはエンド ユーザーやアプリケーションから直接トランザクションを受け取れません。An availability group has one fully read/write copy of the database which is on the primary replica, while all secondary replicas cannot receive transactions directly from end users or applications.

注意

Always On は、SQL Server での可用性機能の総称で、可用性グループと FCI の両方が含まれます。Always On is an umbrella term for the availability features in SQL Server and covers both availability groups and FCIs. Always On は、可用性グループ機能の名前ではありません。Always On is not the name of the availability group feature.

可用性グループは、データベース レベルの保護のみを提供し、インスタンス レベルの保護は提供していないため、トランザクション ログにキャプチャされていないものや、データベースに構成されていないものはすべて、セカンダリ レプリカごとに手動で同期する必要があります。Because availability groups only provide database-level, and not instance-level, protection, anything not captured in the transaction log or configured in the database will need to manually synchronized for each secondary replica. 手動で同期する必要があるオブジェクトの例としては、インスタンス レベル、リンク サーバー、および SQL Server エージェント ジョブでのログインがあります。Some examples of objects that must be synchronized manually are logins at the instance level, linked servers, and SQL Server Agent jobs.

可用性グループには、リスナーと呼ばれる別のコンポーネントもあります。これは、プライマリ レプリカをホストしている SQL Server インスタンスがわからなくても、アプリケーションとエンド ユーザーが接続できるようにします。An availability group also has another component called the listener, which allows applications and end users to connect without needing to know which SQL Server instance is hosting the primary replica. 各可用性グループには、独自のリスナーがあります。Each availability group would have its own listener. リスナーの実装は、Windows Server と Linux ではわずかに異なりますが、提供される機能とその使用方法は同じです。While the implementations of the listener are slightly different on Windows Server versus Linux, the functionality it provides and how it is used is the same. 次の図は、Windows Server フェールオーバー クラスター (WSFC) を使用している Windows Server ベースの可用性グループを示しています。The picture below shows a Windows Server-based availability group which is using a Windows Server Failover Cluster (WSFC). OS レイヤーでの基になるクラスターは、Linux または Windows Server 上にあるかどうかに関係なく、可用性に必要です。An underlying cluster at the OS layer is required for availability whether it is on Linux or Windows Server. この例では、基になるクラスターが WSFC の単純な 2 つのサーバー (ノード) 構成を示しています。The example shows a simple two server, or node, configuration where a WSFC is the underlying cluster.

単純な可用性グループ

レプリカに関しては、Standard Edition と Enterprise Edition で最大数が異なります。Standard and Enterprise Edition have different maximums when it comes to replicas. Standard Edition の可用性グループ (基本的な可用性グループ ) は、可用性グループ内で 2 つのレプリカ (プライマリとセカンダリ) と 1 つのデータベースのみをサポートします。An availability group in Standard Edition, known as a Basic Availability Group, supports two replicas (one primary and one secondary) with only a single database in the availability group. Enterprise Edition は、1 つの可用性グループに複数のデータベースを構成できるだけでなく、最大 9 つのレプリカ (1 つのプライマリ、8 つのセカンダリ) を持つこともできます。Enterprise Edition not only allows multiple databases to be configured in a single availability group, but also can have up to nine total replicas (one primary, eight secondary). Enterprise Edition では、読み取り可能なセカンダリ レプリカ、セカンダリ レプリカからバックアップを作成するなど、その他の利点ももたらされます。Enterprise edition also provides other optional benefits such as readable secondary replicas, the ability to make backups off of a secondary replica, and more.

注意

SQL Server 2012 で廃止されたデータベース ミラーリングは、Linux バージョンの SQL Server では使用できず、追加される予定もありません。Database mirroring, which was deprecated in SQL Server 2012, is not available on the Linux version of SQL Server nor will it be added. まだデータベース ミラーリングを使用しているお客様は、データベース ミラーリングの後継である可用性グループへの移行計画を開始する必要があります。Customers still using database mirroring should start planning to migrate to availability groups, which is the replacement for database mirroring.

可用性に関しては、可用性グループは自動フェールオーバーまたは手動フェールオーバーを提供できます。When it comes to availability, availability groups can provide either automatic or manual failover. 自動フェールオーバーは、同期データ移動が構成されていて、プライマリとセカンダリのレプリカ上のデータベースが同期状態にある場合に発生する可能性があります。Automatic failover can occur if synchronous data movement is configured and the database on the primary and secondary replica are in a synchronized state. リスナーが使用され、アプリケーションが .NET (3.5 と更新、または 4.0) 以降を使用している限り、フェールオーバーは最小限に抑えて、リスナーが利用される場合にエンド ユーザーに影響が及ばないようにします。As long as the listener is used and the application uses a later version of .NET (3.5 with an update, or 4.0 and above), the failover should be handled with minimal to no impact to end users if a listener is utilized. セカンダリ レプリカを新しいプライマリ レプリカにするフェールオーバーは、自動または手動に構成でき、通常は数秒で測定されます。Failover to make a secondary replica the new primary replica can be configured to be automatic or manual, and generally is measured in seconds.

次のリストは、Windows Server と Linux 上の可用性グループでのいくつかの違いを示しています。The list below highlights some differences with availability groups on Windows Server versus Linux:

  • Linux と Windows Server での基になるクラスターの動作の違いにより、可用性グループのすべてのフェールオーバー (手動または自動) は、Linux 上のクラスターを介して行われます。Due to differences in the way the underlying cluster works on Linux and Windows Server, all failovers (manual or automatic) of availability groups are done via the cluster on Linux. Windows Server ベースの可用性グループの展開では、SQL Server 経由での手動フェールオーバーを行う必要があります。On Windows Server-based availability group deployments, manual failovers must be done via SQL Server. 自動フェールオーバーは、Windows Server でも Linux でも基になるクラスターによって処理されます。Automatic failovers are handled by the underlying cluster on both Windows Server and Linux.
  • SQL Server 2017 では、Linux での可用性グループの構成は 3 つ以上のレプリカが推奨されます。In SQL Server 2017, the recommended configuration for availability groups on Linux will be a minimum of three replicas. これは、基になるクラスタリングの動作方法に起因します。This is due to the way that the underlying clustering works. 2 つのレプリカの構成用に改善されたソリューションは、リリース後に提供されます。An improved solution for a two replica configuration will come post-release.
  • Linux では、各リスナーで使用される共通名は、Windows Server のようにクラスターではなく、DNS で定義されます。On Linux, the common name used by each listener is defined in DNS and not in the cluster like it is on Windows Server.

SQL Server 2017 では、可用性グループに対して、次の新機能と機能強化が導入されています。In SQL Server 2017, there are some new features and enhancements to availability groups:

  • クラスターの種類Cluster types
  • REQUIRED_SECONDARIES_TO_COMMITREQUIRED_SECONDARIES_TO_COMMIT
  • Windows Server ベースの構成に対する Microsoft 分散トランザクション コーディネーター (DTC) サポートの強化Enhanced Microsoft Distributor Transaction Coordinator (DTC) support for Windows Server-based configurations
  • 読み取り専用データベースに対するスケール アウト シナリオの追加 (この記事内で後ほど説明)Additional scale out scenarios for read only databases (described later in this article)
AlwaysOn 可用性グループのクラスターの種類Always on availability group cluster types

Windows Server でのクラスタリングの組み込みの可用性フォームは、フェールオーバー クラスタリングと呼ばれる機能を通じて有効化されます。The built-in availability form of clustering in Windows Server is enabled via a feature named Failover Clustering. これにより可用性グループまたは FCI で使用される WSFC を構築できます。It allows you to build a WSFC to be used with an availability group or FCI. 可用性グループおよび FCI の統合は、SQL Server に同梱されているクラスター対応のリソース DLL で提供されます。Integration for availability groups and FCIs is provided by a cluster-aware resource DLLs shipped by SQL Server.

サポートされている各 Linux ディストリビューションには、Pacemaker クラスター ソリューションの独自のバージョンが同梱されています。Each supported Linux distribution ships its own version of the Pacemaker cluster solution. SQL Server 2017 on Linux では、Pacemaker の使用をサポートしています。SQL Server 2017 on Linux supports the use of Pacemaker. Pacemaker は、各ディストリビューションが独自のスタックと統合できるオープン スタック ソリューションです。Pacemaker is an open stack solution that each distribution can then integrate with their stack. Pacemaker はディストリビューションに同梱されていますが、Windows Server でのフェールオーバー クラスタリング機能ほどには統合されていません。While the distributions ship Pacemaker, it is not as integrated as the Failover Clustering feature in Windows Server.

WSFC と Pacemaker は、違うものというよりも類似したものです。A WSFC and Pacemaker are more similar than different. どちらも個別のサーバーを使用してそれらを構成で結合し、可用性を提供する方法を提供し、リソース、制約 (異なる方法で実装されている場合でも)、フェールオーバーなどの概念を持っています。Both provide a way to take individual servers and combine them in a configuration to provide availability, and have concepts of things like resources, constraints (even if implemented differently), failover, and so on. 可用性グループと自動フェールオーバーなどを含む FCI の構成の両方で Pacemaker をサポートするため、Microsoft では Pacemaker 用に mssql-server-ha パッケージを提供しています。これは、WSFC でのリソース DLL に似ていますが、まったく同じではありません。To support Pacemaker for both availability group and FCI configurations including things like automatic failover, Microsoft provides the mssql-server-ha package, which is similar to, but not exactly the same as, the resource DLLs in a WSFC, for Pacemaker. WSFC と Pacemaker の違いの 1 つは、Pacemaker にはネットワーク名リソースがないことです。これは、WSFC でリスナーの名前 (または FCI の名前) を抽象化するのに役立つコンポーネントです。One of the differences between a WSFC and Pacemaker is that there is no network name resource in Pacemaker, which is the component that helps to abstract the name of the listener (or the name of the FCI) on a WSFC. DNS は、その名前解決を Linux 上で提供しています。DNS provides that name resolution on Linux.

クラスター スタックの違いにより、可用性グループに対していくつか変更する必要があります。これは、WSFC によってネイティブで処理されるメタデータの一部を SQL Server が処理しなければならないからです。Because of the difference in the cluster stack, some changes needed to be made for availability groups because SQL Server has to handle some of the metadata that is natively handled by a WSFC. 最も[!IMPORTANT]な変更は、可用性グループに対するクラスターの種類の導入です。The most [!IMPORTANT] change is the introduction of a cluster type for an availability group. これは、cluster_type 列と cluster_type_desc 列の sys.availability_groups に格納されます。This is stored in sys.availability_groups in the cluster_type and cluster_type_desc columns. 次の 3 つのクラスターの種類があります。There are three cluster types:

  • WSFCWSFC
  • ExternalExternal
  • なしNone

可用性を必要とするすべての可用性グループが、基になるクラスター (SQL Server 2017 の場合、WSFC または Pacemaker) を使用する必要があります。All availability groups that require availability must use an underlying cluster, which in the case of SQL Server 2017 means a WSFC or Pacemaker. 基になる WSFC を使用する Windows Server ベースの可用性グループの場合、既定のクラスターの種類が WSFC なので設定する必要はありません。For Windows Server-based availability groups that use an underlying WSFC, the default cluster type is WSFC and does not need to be set. Linux ベースの可用性グループの場合、可用性グループを作成するときに、クラスターの種類を External に設定する必要があります。For Linux-based availability groups, when creating the availability group, the cluster type must be set to External. Pacemaker との統合は、可用性グループが作成された後に構成されますが、WSFC では作成時に行われます。The integration with Pacemaker is configured after the availability group is created, whereas on a WSFC, it is done at creation time.

None のクラスターの種類は、Windows Server と Linux の可用性グループの両方で使用できます。A cluster type of None can be used with both Windows Server and Linux availability groups. クラスターの種類を None に設定することは、可用性グループが基になるクラスターを必要としないことを意味します。Setting the cluster type to None means that the availability group does not require an underlying cluster. つまり、SQL Server 2017 は、クラスターなしで可用性グループをサポートする最初の SQL Server のバージョンですが、そのトレードオフとして、この構成が高可用性ソリューションとしてサポートされません。This means SQL Server 2017 is the first version of SQL Server to support availability groups without a cluster, but the tradeoff is that this configuration is not supported as a high availability solution.

重要

SQL Server 2017 では、可用性グループの作成後に、そのクラスターの種類を変更することはできません。SQL Server 2017 does not allow the ability to change a cluster type for an availability group after it is created. つまり、可用性グループを None から External または WSFC (またはその逆) に切り替えることはできません。This means that an availability group cannot be switched from None to External or WSFC, or vice versa.

データベースの読み取り専用コピーを追加することだけを検討しているユーザー、または移行やアップグレードを提供している可用性グループは欲しいが、基になるクラスターやレプリケーションにより複雑さが増すことを好まないユーザーにとっては、クラスターの種類が None の可用性グループが、最適なソリューションです。For those who are only looking to just add additional read only copies of a database, or like what an availability group provides for migration/upgrades but do not want to be tied to the additional complexity of an underlying cluster or even the replication, an availability group with a cluster type of None is a perfect solution. 詳しくは、「移行とアップグレード」と「読み取りスケール」のセクションをご覧ください。For more information, see the sections Migrations and Upgrades and read-scale.

次のスクリーンショットは、SSMS での異なるクラスターの種類のサポートを示しています。The screenshot below shows the support for the different kinds of cluster types in SSMS. 17.1 以降のバージョンを実行する必要があります。You must be running version 17.1 or later. 次のスクリーンショットはバージョン 17.2 のものです。The screenshot below is from version 17.2.

SSMS の可用性グループ オプション

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITREQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016 では、Enterprise Edition でのサポートされる同期レプリカの数が 2 つから 3 つに増えました。SQL Server 2016 increased support for the number of synchronous replicas from two to three in Enterprise Edition. しかし、1 つのセカンダリ レプリカを同期したものの、他のレプリカで問題が発生した場合、動作を制御する方法がなく、プライマリ レプリカに誤動作しているレプリカを待機するか、先に進むかを指示できませんでした。However, if one secondary replica was synchronized but the other was having a problem, there was no way to control the behavior to tell the primary to either wait for the misbehaving replica or to allow it to move on. つまり、セカンダリ レプリカが同期されていない状態 (セカンダリ レプリカ上でデータの損失が発生している) でも、ある時点でプライマリ レプリカが書き込みトラフィックを受信し続けることになります。This means that the primary replica at some point would continue to receive write traffic even though the secondary replica would not be in a synchronized state, which means that there is data loss on the secondary replica. SQL Server 2017 では、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT という名前の同期レプリカがある場合に発生する動作を制御できるオプションが追加されました。In SQL Server 2017, there is now an option to be able to control the behavior of what happens when there are synchronous replicas named REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. オプションの動作は次のとおりです。The option works as follows:

  • 指定可能な 3 つの値は、0、1、2 です。There are three possible values: 0, 1, and 2
  • 値は同期する必要があるセカンダリ レプリカの数で、データの損失、可用性グループの可用性、およびフェールオーバーに影響します。The value is the number of secondary replicas that must be synchronized, which has implications for data loss, availability group availability, and failover
  • WSFC およびクラスターの種類 None の場合、既定値は 0 で、手動で 1 または 2 に設定することができます。For WSFCs and a cluster type of None, the default value is 0, and can be manually set to 1 or 2
  • クラスターの種類が External の場合、既定では、クラスター メカニズムによって値が設定され、手動でオーバーライドすることができます。For a cluster type of External, by default, the cluster mechanism will set this and it can be overridden manually. 同期レプリカが 3 つの場合は、既定値は 1 になります。For three synchronous replicas, the default value will be 1. Linux では、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT の値は、クラスターの可用性グループ リソースで構成されます。On Linux, the value for REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT is configured on the availability group resource in the cluster. Windows では、Transact-SQL を通じて設定されます。On Windows, it is set via Transact-SQL.

0 より大きい値は、より高いデータ保護を提供します。これは、必要な数のセカンダリ レプリカが使用できない場合、それが解決されるまでプライマリが使用できないからです。A value that is higher than 0 ensures higher data protection because if the required number of secondary replicas is not available, the primary will not be available until that is resolved. セカンダリ レプリカの数が適切な状態でなかった場合、自動フェールオーバーが行われないため、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT はフェールオーバーの動作にも影響します。REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT also affects failover behavior since automatic failover could not occur if the right number of secondary replicas were not in the proper state. Linux では、値 0 は自動フェールオーバーを許可しないため、Linux では、自動フェールオーバーで同期を使用する場合は、自動フェールオーバーを実現するため 0 より大きい値を設定する必要があります。On Linux, a value of 0 will not allow automatic failover, so on Linux, when using synchronous with automatic failover, the value must be set higher than 0 to achieve automatic failover. Windows Server で値 0 は、SQL Server 2016 以前の動作です。0 on Windows Server is the SQL Server 2016 and earlier behavior.

Microsoft 分散トランザクション コーディネーターのサポートの強化Enhanced Microsoft distributed transaction coordinator support

SQL Server 2016 以前では、表面下の DTC を使用する分散トランザクションを必要とするアプリケーションの SQL Server での可用性を取得する唯一の方法は、FCI を展開することでした。Before SQL Server 2016, the only way to get availability in SQL Server for applications that require distributed transactions which use DTC underneath the covers was to deploy FCIs. 分散トランザクションは、次の 2 つのいずれかの方法で実行できます。A distributed transaction can be done in one of two ways:

  • 同じ SQL Server インスタンスで複数のデータベースにまたがるトランザクションA transaction that spans more than one database in the same SQL Server instance
  • 複数の SQL Server インスタンスにまたがる、または場合によっては SQL Server 以外のデータ ソースが関与するトランザクションA transaction that spans more than one SQL Server instance or possibly involves a non-SQL Server data source

SQL Server 2016 では、後者のシナリオをカバーする可用性グループで DTC の部分的なサポートが導入されました。SQL Server 2016 introduced partial support for DTC with availability groups that covered the latter scenario. SQL Server 2017 により、DTC を使用した両方のシナリオがサポートされるようになりました。SQL Server 2017 completes the story by supporting both scenarios with DTC.

可用性グループに対する DTC のもう 1 つのサポート強化があります。SQL Server 2016 では、可用性グループに対する DTC のサポートを有効にできるのは、可用性グループが作成されたときだけで、後から追加することはできませんでした。Another enhancement to DTC support for availability groups is that in SQL Server 2016, enabling support for DTC to an availability group could only be done when the availability group was created, and could not be added later. SQL Server 2017 では、可用性グループを作成した後でも DTC サポートを追加することができます。In SQL Server 2017, DTC support can also be added to an availability group after it is created.

注意

DTC サポートは、Windows Server ベースの SQL Server インスタンス内のデータベースにのみ構成できます。DTC support can only be configured for databases in Windows Server-based SQL Server instances. DTC がアプリケーションの要件である場合、SQL Server の展開に Windows Server を OS として使用する必要があります。Linux は使用できません。If DTC is an requirement for your application, you must use Windows Server as the OS for your SQL Server deployment, and cannot use Linux.

Always On フェールオーバー クラスター インスタンスAlways on failover cluster instances

クラスター化されたインストールは、SQL Server バージョン 6.5 以降の機能です。Clustered installations have been a feature of SQL Server since version 6.5. FCI は、インスタンスと呼ばれる SQL Server のインストール全体の可用性を実現する実証済みの方法です。FCIs are a proven method of providing availability for the entire installation of SQL Server, known as an instance. データベース、SQL Server エージェント ジョブ、リンク サーバーなど、インスタンス内のすべてのものが別のサーバーに移動すると、基になるサーバーに問題が生じる可能性があります。This means that everything inside the instance, including databases, SQL Server Agent jobs, linked servers, et al., will move to another server should the underlying server encounter a problem. すべての FCI には、何らかの共有ストレージが必要です。ネットワーク経由で提供されるものでもかまいません。All FCIs require some sort of shared storage, even if it is provided via networking. FCI のリソースを実行および所有できるのは、一度に 1 つのノードのみです。The FCI’s resources can only be running and owned by one node at any given time. 次の図は、FCI を所有するクラスターの最初のノードを示しています。これは、それに関連付けられた共有ストレージ リソースを所有 (ストレージへの実線で示されています) していることも意味します。In the picture below, the first node of the cluster owns the FCI, which also means it owns the shared storage resources associated with it denoted by the solid line to the storage.

フェールオーバー クラスター インスタンス

フェールオーバー後は、所有権は次の図にように変更されます。After a failover, ownership changes as is seen in the picture below.

フェールオーバー後

FCI ではデータ損失は発生しませんが、データのコピーが 1 つ存在するため、基になる共有ストレージが単一障害点になります。There is zero data loss with an FCI, but the underlying shared storage is a single point of failure since there is one copy of the data. FCI は多くの場合、データベースの冗長コピーを持つために、可用性グループやログ配布などの別の可用性メソッドと組み合わされます。FCIs are often combined with another availability method, such as an availability group or log shipping, to have redundant copies of databases. 展開される追加の方法では、FCI と物理的に分離したストレージを使用してください。The additional method deployed should use physically separate storage from the FCI. FCI が別のノードにフェールオーバーすると、1 つのノードで停止してから別のノードで開始します。サーバーの電源をオフにしてからオンにするのと似ています。When the FCI fails over to another node, it stops on one node and starts on another, not unlike powering a server off and turning it on. FCI は、通常の復旧プロセスを行います。つまり、ロール フォワードする必要があるすべてのトランザクションと、完了していないすべてのトランザクションがロールバックされます。An FCI goes through the normal recovery process, meaning any transactions that need to be rolled forward will be, and any transactions that are incomplete will be rolled back. したがって、データベースは、データ ポイントから障害または手動フェールオーバーの時点まで整合性があるため、データ損失が生じません。Therefore, the database is consistent from a data point to the time of the failure or manual failover, hence no data loss. データベースは、復旧が完了しないと利用できないため、復旧時間はさまざまな要因によって異なり、通常は可用性グループのフェールオーバーよりも長くなります。Databases are only available after recovery is complete, so recovery time will depend on many factors, and will generally be longer than failing over an availability group. トレードオフとして、可用性グループをフェールオーバーするときに、SQL Server エージェント ジョブを有効にするなど、データベースを使用できるようにするために追加のタスクが必要になる場合があります。The tradeoff is that when you fail over an availability group, there may be additional tasks required to make a database usable, such as enabling a SQL Server Agent jobs job.

可用性グループと同様に、FCI は基になるクラスターのどのノードによってホストされているかを抽象化します。Like an availability group, FCIs abstract which node of the underlying cluster is hosting it. FCI は常に同じ名前を保持します。An FCI always retains the same name. アプリケーションとエンド ユーザーはノードに接続せず、FCI に割り当てられている一意の名前が使用されます。Applications and end users never connect to the nodes; the unique name assigned to the FCI is used. FCI は、プライマリまたはセカンダリのいずれかのレプリカをホストしているインスタンスの 1 つとして、可用性グループに参加できます。An FCI can participate in an availability group as one of the instances hosing either a primary or secondary replica.

次のリストは、Windows Server と Linux 上の FCI でのいくつかの違いを示しています。The list below highlights some differences with FCIs on Windows Server versus Linux:

  • Windows Server では、FCI はインストール プロセスの一部です。On Windows Server, an FCI is part of the installation process. Linux では、FCI は SQL Server のインストール後に構成されます。An FCI on Linux is configured after installing SQL Server.
  • Linux は、ホストあたり 1 つの SQL Server のインストールしかサポートしないため、すべての FCI が既定のインスタンスになります。Linux only supports a single installation of SQL Server per host, so all FCIs will be a default instance. Windows Server は、WSFC あたり最大 25 の FCI をサポートします。Windows Server supports up to 25 FCIs per WSFC.
  • Linux で FCI によって使用される共通名は DNS で定義され、FCI 用に作成されたリソースと同じ名前である必要があります。The common name used by FCIs in Linux is defined in DNS, and should be the same as the resource created for the FCI.

ログ配布Log shipping

復旧ポイントの目標と復旧時間の目標により柔軟性がある場合、またはデータベースが非常にミッション クリティカルであると見なされていない場合は、ログ配布が SQL Server におけるもう 1 つの実証済みの可用性機能となります。If recovery point and recovery time objectives are more flexible, or databases are not considered to be highly mission critical, log shipping is another proven availability feature in SQL Server. SQL Server のネイティブ バックアップに基づき、ログ配布のプロセスによってトランザクション ログ バックアップが自動的に生成され、ウォーム スタンバイ状態であることが判明している 1 つ以上のインスタンスにコピーされ、そのスタンバイにトランザクション ログ バックアップが自動的に適用されます。Based on SQL Server’s native backups, the process for log shipping automatically generates transaction log backups, copies them to one or more instances known as a warm standby, and automatically applies the transaction log backups to that standby. ログ配布は、SQL Server エージェント ジョブを使用して、バックアップ、コピー、およびトランザクション ログ バックアップの適用のプロセスを自動化します。Log shipping uses SQL Server Agent jobs to automate the process of backing up, copying, and applying the transaction log backups.

重要

Linux では、SQL Server エージェント ジョブは SQL Server 自体のインストールの一部として含まれません。On Linux, SQL Server Agent jobs is not included as part of the installation of SQL Server itself. これは、ログ配布を使用するためにインストールする必要があるパッケージ mssql-server-Agent ジョブで使用できます。It is available in the package mssql-server-Agent jobs which must also be installed to use log shipping.

ログ配布

ほぼ間違いなく、一部の容量でログ配布を使用する最大の利点は、ヒューマン エラーに対処することです。Arguably the biggest advantage of using log shipping in some capacity is that it accounts for human error. トランザクション ログの適用が遅れる場合があります。The application of transaction logs can be delayed. そのため、他のユーザーが WHERE 句なしで UPDATE のようなものを発行すると、スタンバイに変更されずに、プライマリ システムの修復中にスタンバイに切り替えることができます。Therefore, if someone issues something like an UPDATE without a WHERE clause, the standby may not have the change so you could switch to that while you repair the primary system. ログ配布は構成が容易ですが、プライマリからウォーム スタンバイ状態に切り替える (ロール切り替えと呼ばれます) のは常に手動です。While log shipping is easy to configure, switching from the primary to a warm standby, known as a role change, is always manual. ロール切り替えは Transact-SQL を介して開始され、可用性グループと同様に、トランザクション ログにキャプチャされないすべてのオブジェクトを手動で同期する必要があります。A role change is initiated via Transact-SQL, and like an availability group, all objects not captured in the transaction log must be manually synchronized. 1 つの可用性グループには複数のデータベースを含めることができるのに対し、ログ配布はデータベースごとに構成する必要があります。Log shipping also needs to be configured per database, whereas a single availability group can contain multiple databases. 可用性グループや FCI とは異なり、ログ配布にはロール切り替えの抽象化がありません。Unlike an availability group or FCI, log shipping has no abstraction for a role change. アプリケーションでこれを処理できる必要があります。Applications must be able to handle this. DNS エイリアス (CNAME) などの手法も使用できますが、切り替え後に DNS の更新に時間がかかるなど、良い点と悪い点があります。Techniques such as a DNS alias (CNAME) could be employed, but there are pros and cons, such as the time it takes for DNS to refresh after the switch.

ディザスター リカバリーDisaster recovery

プライマリ可用性の場所で地震や洪水などの重大な事態が発生した場合、企業は自社のシステムを別の場所で稼働させるために準備する必要があります。When your primary availability location experiences a catastrophic event like an earthquake or flood, the business must be prepared to have its systems come online elsewhere. このセクションでは、SQL Server の可用性機能がビジネス継続性にどのように役立つことができるかを説明します。This section will cover how the SQL Server availability features can assist with business continuity.

Always On 可用性グループAlways on availability groups

可用性グループの利点の 1 つは、高可用性とディザスター リカバリーの両方を 1 つの機能を使用して構成できることです。One of the benefits of availability groups is that both high availability and disaster recovery can be configured using a single feature. 共有ストレージも高可用性であることを確認することなく、高可用性のために 1 つのデータ センターにローカルのレプリカを持ち、ディザスター リカバリーのために他のデータ センターにリモートのレプリカをそれぞれ個別のストレージで持つ方がはるかに簡単です。Without the requirement for ensuring that shared storage is also highly available, it is much easier to have replicas that are local in one data center for high availability, and remote ones in other data centers for disaster recovery each with separate storage. データベースの追加のコピーを持つことは、冗長性を確保するためのトレードオフです。Having additional copies of the database is the tradeoff for ensuring redundancy. 複数のデータ センターにまたがる可用性グループの例を次に示します。An example of an availability group that spans multiple data centers is shown below. 1 つのプライマリ レプリカがすべてのセカンダリ レプリカの同期を維持する役割を担っています。One primary replica is responsible for keeping all secondary replicas synchronized.

可用性グループ

クラスターの種類が None の可用性グループ以外では、可用性グループは、すべてのレプリカが同じ基になるクラスターの一部である必要があります。WSFC または Pacemaker であるかどうかは関係ありません。Outside of an availability group with a cluster type of none, an availability group requires that all replicas are part of the same underlying cluster whether it is a WSFC or Pacemaker. これは、上の図では、WSFC が 2 つの異なるデータ センターで機能するために拡張され、複雑さが増すことを意味します。This means that in the picture above, the WSFC is stretched to work in two different data centers which adds complexity. プラットフォーム (Windows Server または Linux) は関係ありません。regardless of the platform (Windows Server or Linux). 離れた距離でクラスターを拡張することで、複雑さが増します。Stretching clusters across distance adds complexity. SQL Server 2016 で導入された分散型可用性グループにより、可用性グループは異なるクラスター上に構成されている可用性グループにまたがることができます。Introduced in SQL Server 2016, a distributed availability group allows an availability group to span availability groups configured on different clusters. これにより、すべてのノードを同じクラスターに参加させるという要件から解放され、ディザスター リカバリーの構成がはるかに容易になります。This decouples the requirement to have the nodes all participate in the same cluster, which makes configuring disaster recovery much easier. 分散型可用性グループの詳細については、「分散型可用性グループ」を参照してください。For more information on distributed availability groups, see Distributed availability groups.

分散型可用性グループ

Always On フェールオーバー クラスター インスタンスAlways on failover cluster instances

FCI はディザスター リカバリーに使用できます。FCIs can be used for disaster recovery. 通常の可用性グループと同様に、基になるクラスター メカニズムをすべての場所に拡張する必要があり、複雑さが増します。As with a normal availability group, the underlying cluster mechanism must also be extended to all locations which adds complexity. FCI には、共有ストレージという別の考慮事項があります。There is an additional consideration for FCIs: the shared storage. 同じディスクをプライマリとセカンダリ サイトで使用できる必要があるため、FCI によって使用されているディスクが別の場所に存在していることを確認するには、ハードウェア レイヤーでストレージ ベンダーによって提供される機能などの外部の方法や、Windows Server でストレージ レプリカを使用する必要があります。The same disks need to be available in the primary and secondary sites, so an external method such as functionality provided by the storage vendor at the hardware layer or using storage Replica in Windows Server, is required to ensure that the disks used by the FCI exist elsewhere.

Always On FCI

ログ配布Log shipping

ログ配布は、SQL Server データベースにディザスター リカバリーを提供するための最も古い方法の 1 つです。Log shipping is one of the oldest methods of providing disaster recovery for SQL Server databases. ログ配布は、他のオプションでは環境、管理者のスキルまたは予算により困難になる可能性がある場合に、コスト効果の高い、よりシンプルなディザスター リカバリーを提供するために、可用性グループおよび FCI と組み合わせて使用されることがよくあります。Log shipping is often used in conjunction with availability groups and FCIs to provide cost-effective and simpler disaster recovery where other options may be challenging due to environment, administrative skills, or budget. ログ配布用の高可用性のシナリオと同様に、ヒューマン エラーに対処するため、多くの環境でトランザクション ログの読み込みに遅延が生じます。Similar to the high availability story for log shipping, many environments will delay the loading of a transaction log to account for human error.

移行とアップグレード Migrations and upgrades

新しいインスタンスを展開する場合、または古いインスタンスをアップグレードする場合に、ビジネスでは長時間の停止は許されません。When deploying new instances or upgrading old ones, a business cannot tolerate long outage. このセクションでは、SQL Server の機能を使用することで、計画的なアーキテクチャの変更、サーバーの切り替え、プラットフォームの変更 (Windows Server から Linux、またはその逆など)、または修正プログラムの適用時のダウンタイムをいかに最小限に抑えられるかについて説明します。This section will discuss how the availability features of SQL Server can be used to minimize the downtime in a planned architecture change, server switch, platform change (such as Windows Server to Linux or vice versa), or during patching.

注意

移行とアップグレードでは、バックアップして他の場所でそれらを復元するなどの他の方法も使用できますが、Other methods, such as using backups and restoring them elsewhere, can also be used for migrations and upgrades. このドキュメントでは説明しません。They are not discussed in this paper.

Always On 可用性グループAlways on availability groups

1 つ以上の可用性グループを含む既存のインスタンスは、SQL Server 2017 にインプレース アップグレードできます。An existing instance containing one or more availability groups can be upgraded in place to SQL Server 2017. これにはある程度のダウンタイムが必要になりますが、適切に計画することで最小限に抑えることができます。While this will require some amount of downtime, with the right amount of planning, it can be minimized.

目標が構成変更 (オペレーティング システムまたは SQL Server のバージョンを含む) ではなく、新しいサーバーへの移行の場合、これらのサーバーをノードとして既存の基になるクラスターに追加して、可用性グループに追加することができます。If the goal is to migrate to new servers and not change the configuration (including the operating system or SQL Server version), those servers could be added as nodes to the existing underlying cluster and added to the availability group. レプリカが正しい状態になったら、新しいサーバーに手動フェールオーバーしてから、古いサーバーを可用性グループから削除し、最終的には使用停止にすることができます。Once the replica or replicas are in the right state, a manual failover could occur to a new server, and then the old ones could be removed from the availability group, and ultimately, decommissioned.

分散型可用性グループは、新しい構成に移行または SQL Server をアップグレードするもう 1 つの方法でもあります。Distributed AGs are also another method to migrate to a new configuration or upgrade SQL Server. 分散型可用性グループは、異なるアーキテクチャ上でさまざまな基になる可用性グループをサポートするため、たとえば、Windows Server 2012 R2 で実行されている SQL Server 2016 から Windows Sever 2016 で実行されている SQL Server 2017 に変更することができます。Because a distributed AG supports different underlying AGs on different architectures, for example, you could change from SQL Server 2016 running on Windows Server 2012 R2 to SQL Server 2017 running on Windows Sever 2016.

分散型可用性グループ

最後に、クラスターの種類が None の可用性グループは、移行またはアップグレードにも使用できます。Finally, availability groups with a cluster type of None can also be used for migration or upgrading. 一般的な可用性グループの構成では、クラスターの種類を混在させることはできないため、すべてのレプリカを None にする必要があります。You cannot mix and match cluster types in a typical availability group configuration, so all replicas would need to be a type of None. 異なるクラスターの種類で構成された可用性グループにまたがるには、分散型可用性グループを使用できます。A distributed availability group can be used to span availability groups configured with different cluster types. この方法は異なる OS プラットフォームでもサポートされます。This method is also supported across the different OS platforms.

移行とアップグレードのための可用性グループのすべてのバリエーションでは、最も時間のかかる作業の部分 (データの同期化) を徐々に実行できます。All variants of availability groups for migrations and upgrades allow the most time consuming portion of the work to be done over time – data synchronization. 新しい構成への切り替えを開始する場合、カットオーバーが短時間の停止であるのに対し、データの同期を含め、すべての作業が完了する必要がある場合は長時間のダウンタイムが発生します。When it comes time to initiate the switch to the new configuration, the cutover will be a brief outage versus one long period of downtime where all the work, including data synchronization, would need to be completed.

可用性グループは、修正プログラムの適用が完了するまで、プライマリ レプリカからセカンダリ レプリカに手動でフェールオーバーすることで、基になる OS の修正プログラムの適用中のダウンタイムを最小限にできます。Availability groups can provide minimal downtime during patching of the underlying OS by manually failing over the primary to a secondary replica while the patching is being completed. オペレーティング システムの観点からは、元になる OS のサービスで (常にではありませんが) しばしば再起動が必要になることがあるため、Windows Server ではこれを行うのがより一般的です。From an operating system perspective, doing this would be more common on Windows Server since often, but not always, servicing the underlying OS may require a reboot. Linux の修正プログラムの適用には再起動が必要ですが、滅多に発生しません。Patching Linux sometimes needs a reboot, but it can be infrequent.

可用性グループに参加している SQL Server インスタンスに修正プログラムを適用しても、可用性グループのアーキテクチャの複雑度によっては、ダウンタイムを最小限に抑えることができます。Patching SQL Server instances participating in an availability group can also minimize downtime depending on how complex the availability group architecture is. 可用性グループに参加しているサーバーに修正プログラムを適用するには、最初にセカンダリ レプリカに修正プログラムを適用します。To patch servers participating in an availability group, a secondary replica is patched first. 正しい数のレプリカに修正プログラムが適用されたら、プライマリ レプリカを別のノードに手動でフェールオーバーしてアップグレードを行います。Once the right number of replicas are patched, the primary replica is manually failed over to another node to do the upgrade. この時点で残りのすべてのセカンダリ レプリカもアップグレードできます。Any remaining secondary replicas at that point can be upgraded, too.

Always On フェールオーバー クラスター インスタンスAlways on failover cluster instances

FCI 単独では従来の移行またはアップグレードを支援することはできません。可用性グループまたはログ配布を FCI 内のデータベースと構成する他のすべてのオブジェクト用に構成する必要があります。FCIs on their own cannot assist with a traditional migration or upgrade; an availability group or log shipping would have to be configured for the databases in the FCI and all other objects accounted for. ただし、基になる Windows Server に修正プログラムを適用する必要がある場合は、Windows Server の FCI がまだ一般的なオプションです。However, FCIs under Windows Server are still a popular option for when the underlying Windows Servers need to be patched. 手動フェールオーバーを開始できます。これは、Windows Server に修正プログラムが適用される間ずっとインスタンスを使用不可にする代わりに、短時間停止することを意味します。A manual failover can be initiated, which means a brief outage instead of having the instance completely unavailable for the entire time Windows Server is being patched. FCI は、SQL Server 2017 にインプレース アップグレードできます。An FCI can be upgraded in place to SQL Server 2017. 詳細については、「SQL Server フェールオーバー クラスター インスタンスのアップグレード」を参照してください。For information, see Upgrade a SQL Server Failover Cluster Instance.

ログ配布Log shipping

ログ配布は、データベースの移行とアップグレードの両方でいまだに一般的なオプションです。Log shipping is still a popular option to both migrate and upgrade databases. 可用性グループと似ていますが、今回はトランザクション ログを同期方法として使用します。データの伝達は、サーバーを切り替える前に十分な余裕をもって開始できます。Similar to availability groups, but this time using the transaction log as the synchronization method, the data propagation can be started well in advance of the server switch. 切り替え時に、ソースですべてのトラフィックが停止したら、最後のトランザクション ログを取得し、コピーし、新しい構成に適用する必要があります。At the time of the switch, once all traffic is stopped at the source, a final transaction log would need to be taken, copied, and applied to the new configuration. その時点で、データベースをオンラインにすることができます。At that point, the database can be brought online. ログ配布は遅いネットワークに寛大なことが多く、可用性グループや分散型可用性グループを使用して行う切り替えよりも切り替えに若干時間がかかる場合がありますが、通常は数分で、数時間、数日、数週間かかるわけではありません。Log shipping is often more tolerant of slower networks, and while the switch may be slightly longer than one done using an availability group or a distributed availability group, it is usually measured in minutes – not hours, days, or weeks.

可用性グループと同様に、ログ配布は修正プログラムの適用時に別のサーバーに切り替える方法を提供できます。Similar to availability groups, log shipping can provide a way to switch to another server in the event of patching.

その他の SQL Server の展開方法と可用性Other SQL Server deployment methods and availability

SQL Server on Linux では、他に 2 つの展開方法があります。コンテナーと Azure (または別のパブリック クラウド プロバイダー) を使用することです。There are two other deployment methods for SQL Server on Linux: containers and using Azure (or another public cloud provider). このペーパーで示したように、SQL Server の展開方法に関係なく、可用性に対する一般的な必要性が存在します。The general need for availability as presented throughout this paper exists regardless of how SQL Server is deployed. SQL Server を高可用性にするという点では、これら 2 つの方法にはいくつか特に注意が必要な点があります。These two methods have some special considerations when it comes to making SQL Server highly available.

Docker を使用したコンテナーは、Windows Server または Linux に SQL Server を展開する新しい方法です。Containers using Docker are a new way of deploying SQL Server, either for Windows Server or Linux. コンテナーとは、実行する準備ができている SQL Server の完全なイメージです。A container is a complete image of SQL Server that is ready to run. ただし、現在は、クラスタリングのためのネイティブ サポートはないため、直接、高可用性またはディザスター リカバリーを管理します。However, there is currently no native support for clustering, and thus, direct high availability or disaster recovery. 現時点では、コンテナーを使用して SQL Server データベースを使用可能にするためのオプションは、ログ配布およびバックアップと復元です。Currently, the options to make SQL Server databases available using containers would be log shipping and backup and restore. 前に述べたよう、クラスターの種類が None の可用性グループを構成できますが、真の可用性の構成とは見なされません。While an availability group with a cluster type of None can be configured, as noted earlier, it is not considered a true availability configuration. Microsoft では、コンテナーを使用して可用性グループまたは FCI を有効にする方法を検討しています。Microsoft is looking at ways to enable availability groups or FCIs using containers.

現在コンテナーを使用していて、コンテナーが失われた場合、コンテナー プラットフォームによっては、もう一度展開して、使用していた共有ストレージにアタッチすることができます。If you are using containers today, if the container is lost, depending on the container platform, it can be deployed again and attached to the shared storage that was used. このメカニズムの一部は、コンテナー オーケストレーターによって提供されます。Some of this mechanism is provided by the container orchestrator. これにより、ある程度の復元性が提供されますが、データベースの復旧に伴うある程度のダウンタイムが発生し、可用性グループまたは FCI を使用している場合ほどの真の高可用性は得られません。While this does provide some resiliency, there will be some downtime associated with database recovery and is not truly highly available as it would be if using an availability group or FCI.

Linux の IaaS 仮想マシンは、Azure を使用してインストールされた SQL Server で展開できます。Linux IaaS virtual machines can be deployed with SQL Server installed using Azure. オンプレミス ベースのインストールと同じく、サポートされているインストールでは、Pacemaker の外部にある STONITH (Shoot the Other Node in the Head) を使用する必要があります。As with on premises-based installations, a supported installation requires the use of STONITH (Shoot the Other Node in the Head) which is external to Pacemaker itself. STONITH は、フェンス可用性エージェントを介して提供されます。STONITH is provided via fencing availability agents. ディストリビューションによってはプラットフォームの一部として同梱しているものもありますが、それ以外は外部のハードウェアとソフトウェアのベンダーに依存しています。Some distributions ship them as part of the platform, others rely on external hardware and software vendors. サポートされているソリューションをパブリック クラウドに展開できるように、好みの Linux ディストリビューションでどのような STONITH が提供されているかを確認してください。Check with your preferred Linux distribution to see what forms of STONITH are provided so that a supported solution can be deployed in the public cloud.

クロスプラットフォームおよび Linux ディストリビューションの相互運用性Cross-platform and Linux distribution interoperability

SQL Server は、Windows Server と Linux の両方でサポートされるようになりました。このセクションでは、他の目的だけでなく、可用性のためにこれらを連携させる方法のシナリオに加え、複数の Linux ディストリビューションを取り入れたソリューションのシナリオについて説明します。With SQL Server now supported on both Windows Server and Linux, this section covers the scenarios of how they can work together for availability in addition to other purposes, as well as the story for solutions that will incorporate more than one Linux distribution.

クロスプラットフォームと相互運用性のシナリオを説明する前に、2 つのファクトについて述べておく必要があります。Before covering the cross-platform and interoperability scenarios, two facts need to be stated:

  • WSFC ベースの FCI または可用性グループが Linux ベースの FCI または可用性グループと直接連動するシナリオはありません。There are no scenarios where a WSFC-based FCI or availability group will work with a Linux-based FCI or availability group directly. WSFC は Pacemaker ノードで拡張することはできません。その逆も同様です。A WSFC cannot be extended by a Pacemaker node and vice versa.
  • Linux ディストリビューションを混在させることは FCI または External のクラスターの種類を持つ可用性グループではサポートされていません。Mixing Linux distributions is not supported with FCIs or an availability group that has a cluster type of External. そのシナリオでは、すべての可用性グループのレプリカに同じディストリビューションを構成するだけでなく、同じバージョンにする必要もあります。All availability group replicas in that scenario must be configured not only the same Linux distribution, but also the same version. SQL Server が 2 つのプラットフォーム間または複数の Linux のディストリビューションで動作できる 2 つのサポートされている方法は、可用性グループとログ配布です。The two supported ways that SQL Server can operate across the two platforms or multiple distributions of Linux are availability groups and log shipping.

分散型可用性グループDistributed availability groups

分散型可用性グループは、可用性グループの構成にまたがることを目的としており、可用性グループの下のこれらの 2 つの基になるクラスターが 2 つの異なる WSFC、Linux ディストリビューション、または WSFC とその他の Linux 上のものかどうかは関係ありません。Distributed availability groups are designed to span availability group configurations, whether those two underlying clusters underneath the availability groups are two different WSFCs, Linux distributions, or one on a WSFC and the other on Linux. 分散型可用性グループは、クロスプラットフォーム ソリューションを持つ主要な手段になります。A distributed availability group will be the primary method of having a cross platform solution. 分散型可用性グループは、Windows Server ベースの SQL Server インフラストラクチャから Linux ベースへの変換など、移行のための主要なソリューションでもあります (それが会社が指定するものである場合)。A distributed availability group is also the primary solution for migrations such as converting from a Windows Server-based SQL Server infrastructure to a Linux-based one if that is what your company wants to do. 前述のように、可用性グループ、特に分散型可用性グループは、アプリケーションが使用できない時間を最小限に抑えます。As noted above, availability groups, and especially distributed availability groups, would minimize the time that an application would be unavailable for use. WSFC と Pacemaker にまたがる分散型可用性グループの例を次に示します。An example of a distributed availability group that spans a WSFC and Pacemaker is shown below.

分散型可用性グループ

可用性グループが None のクラスターの種類で構成されている場合は、Windows Server と Linux だけでなく複数の Linux ディストリビューションにまたがることができます。If an availability group is configured with a cluster type of None, it can span Windows Server and Linux as well as multiple Linux distributions. これは、真の高可用性構成ではないため、ミッション クリティカルな展開には使用すべきではありませんが、読み取りスケールまたは移行/アップグレードのシナリオには使用できます。Since this is not a true high availability configuration, it should not be used for mission critical deployments, but for read-scale or migration/upgrade scenarios.

ログ配布Log shipping

ログ配布はバックアップと復元にのみ基づいているため、Windows Server の SQL Server と SQL Server on Linux では、データベース、ファイル構造などに違いはありません。Since log shipping is just based on backup and restore, and there are no differences in the databases, file structures, etc., for SQL Server on Windows Server versus SQL Server on Linux. つまり、ログ配布は、Windows Server ベースの SQL Server のインストール間で構成でき、Linux ベースでも Linux のディストリビューション間でも構成できます。This means that log shipping can be configured between a Windows Server-based SQL Server installation and a Linux one as well as between distributions of Linux. それ以外はすべて同じです。Everything else remains the same. 注意が必要な点は、可用性グループと同じように、ソースの SQL Server のメジャー バージョンが、ターゲットのバージョンよりも新しい場合には、ログ配布が機能しないことだけです。The only caveat is that log shipping, just like an availability group, cannot work when the source is at a higher SQL Server major version against a target that is at a lower version of SQL Server.

読み取りスケール read-scale

SQL Server 2012 で導入されて以来、セカンダリ レプリカは読み取り専用クエリに使用することができます。Since their introduction in SQL Server 2012, secondary replicas have had the ability to be used for read-only queries. 可用性グループで実現できる 2 つの方法があります。セカンダリへの直接アクセスを許可することと、リスナーを使用する必要がある読み取り専用のルーティングを構成することです。There are two ways that can be achieved with an availability group: by allowing direct access to the secondary as well as configuring read only routing which requires the use of the listener. SQL Server 2016 で導入された、ラウンドロビン アルゴリズムを使用したリスナーを通じて読み取り専用の接続を負荷分散する機能により、読み取り専用の要求をすべての読み取り可能なレプリカに分散させることができます。SQL Server 2016 introduced the ability to load balance read-only connections via the listener using a round robin algorithm, allowing read-only requests to be spread across all readable replicas.

注意

読み取り可能なセカンダリ レプリカは Enterprise Edition のみの機能で、読み取り可能なレプリカをホストする各インスタンスには、SQL Server ライセンスが必要です。Readable secondary replicas is a feature only in Enterprise Edition, and each instance hosting a readable replica would need a SQL Server license.

可用性グループを使用してデータベースの読み取り可能なコピーを拡張することは、 SQL Server 2016 の分散型可用性グループで初めて導入されました。Scaling readable copies of a database via availability groups was first introduced with distributed availability groups in SQL Server 2016. これにより企業は、最小限の構成でデータベースの読み取り専用のコピーをローカルだけでなく、地域およびグローバルで持つことができ、クエリがローカルで実行されることでネットワーク トラフィックと遅延を削減することができます。This would allow companies to have read-only copies of the database not only locally, but regionally and globally with a minimal amount of configuration and reduce network traffic and latency by having queries executed locally. 可用性グループの各プライマリ レプリカは、完全に読み書き可能なコピーでなくても、他の 2 つの可用性グループをシードできるため、各分散型可用性グループは読み取り可能なデータのコピーを最大 27 個までサポートできます。Each primary replica of an availability group can seed two other availability groups even if it is not the fully read/write copy, so each distributed availability group can support up to 27 copies of the data that are readable.

分散型可用性グループ

SQL Server 2017 から、None のクラスターの種類で構成されている可用性グループを使用して、ほぼリアルタイムの読み取り専用ソリューションを作成できます。Starting with SQL Server 2017, It is possible to create a near-real time, read-only solution with availability groups configured with a cluster type of None. 目的が可用性グループを読み取り可能なセカンダリ レプリカに使用することで、可用性ではない場合は、これを行うことで WSFC または Pacemaker を使用することの複雑さが解消され、より簡単な展開方法で可用性グループの読み取り可能の利点が得られます。If the goal is to use availability groups for readable secondary replicas and not availability, doing this removes the complexity of using a WSFC or Pacemaker, and gives the readable benefits of an availability group in a simpler deployment method.

主な注意点は、クラスターの種類が None の基になるクラスターがないため、読み取り専用ルーティングの構成が少し異なることだけです。The only major caveat is that due to no underlying cluster with a cluster type of None, configuring read only routing is a little different. SQL Server の観点からは、クラスターが存在しない場合でも、要求をルーティングするために引き続きリスナーが必要です。From a SQL Server perspective, a listener is still required to route the requests even though there is no cluster. 従来のリスナーを構成する代わりに、IP アドレスまたはプライマリ レプリカの名前が使用されます。Instead of configuring a traditional listener, the IP address or name of the primary replica is used. プライマリ レプリカは、読み取り専用の要求をルーティングするために使用されます。The primary replica is then used to route the read only requests.

ログ配布のウォーム スタンバイは、データベース WITH STANDBY を復元することで読み取り可能な使用量に対して技術的に構成できます。A log shipping warm standby can technically be configured for readable usage by restoring the database WITH STANDBY. しかし、トランザクション ログは復元するためのデータベースを排他的に使用する必要があるため、その間はユーザーがデータベースにアクセスできないことを意味します。However, because the transaction logs require exclusive use of the database for restoration, it means that users cannot be accessing the database while that happens. これにより、ログ配布が理想的とは言えないソリューションになります。ほぼリアルタイムのデータが必要な場合には特にそうなります。This makes log shipping a less than ideal solution – especially if near real-time data is required.

可用性グループを使用したすべての読み取りスケールのシナリオで注意すべきことは、すべてのデータがライブであるトランザクション レプリケーションを使用する場合とは異なり、各セカンダリ レプリカは、一意のインデックスを適用できる状態になく、そのレプリカはプライマリの完全なコピーであることです。One thing that should be noted for all read-scale scenarios with availability groups is that unlike using transactional replication where all of the data is live, each secondary replica is not in a state where unique indexes can be applied, the replica is an exact copy of the primary. これは、レポートに任意のインデックスが必要な場合やデータを操作する必要がある場合は、プライマリ レプリカ上のデータベースで行う必要があることを意味します。This means that if any indexes are required for reporting or data needs to be manipulated, it must be done on the database(s) on the primary replica. その柔軟性が必要な場合は、レプリケーションが読み取り可能なデータにより適したソリューションです。If you need that flexibility, replication is a better solution for readable data.

概要Summary

SQL Server 2017 のインスタンスとデータベースは、同じ機能を使用して Windows Server と Linux の両方で高可用性にすることができます。Instances and databases of SQL Server 2017 can be made highly available using the same features on both Windows Server and Linux. ローカルの高可用性とディザスター リカバリーの標準的な可用性シナリオの他に、SQL Server の可用性機能を使用することで、アップグレードと移行に伴うダウンタイムを最小限に抑えることができます。Besides standard availability scenarios of local high availability and disaster recovery, downtime associated with upgrades and migrations can be minimized with the availability features in SQL Server. 可用性グループは、同じアーキテクチャの一部としてデータベースの追加のコピーを提供して、読み取り可能なコピーをスケール アウトすることもできます。Availability groups can also provide additional copies of a database as part of the same architecture to scale out readable copies. SQL Server 2017 を使用して、新しいソリューションを展開する場合でも、またはアップグレードを検討している場合でも、SQL Server 2017 には必要とする可用性と信頼性が備わってます。Whether you are deploying a new solution using SQL Server 2017 or considering an upgrade, SQL Server 2017 has the availability and reliability you require.