비즈니스 연속성 및 데이터베이스 복구-Linux에서 SQL ServerBusiness continuity and database recovery - SQL Server on Linux

이 문서에서는 SQL Server의 고가용성 및 재해 복구를 위한 비즈니스 연속성 솔루션에 대한 개요를 제공합니다.This article provides an overview of business continuity solutions for high availability and disaster recovery in SQL Server.

SQL Server를 배포하는 모든 사람들이 공통적으로 해야 할 작업 중 하나는 모든 중요한 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의 새로운 기능을 참조하십시오.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. 가용성 기능을 사용할 수 있는 주요 방법은 네 가지입니다.There are four main ways the availability features can be used:

  • 고가용성High availability
  • 재해 복구Disaster recovery
  • 마이그레이션 및 업그레이드Migrations and upgrades
  • 하나 이상의 데이터베이스에서 읽을 수 있는 복사본 확장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. 복제는 향후 릴리스에서 Linux의 SQL Server에 추가될 예정입니다.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

클라우드 지역의 데이터 센터 또는 단일 지역에 국한된 문제가 발생하는 경우 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 또는 Enterprise Edition에 배포할 수 있습니다.An availability group can be deployed on Standard or Enterprise Editions. 가용성 그룹에 참여하는 인스턴스는 독립 실행형이거나 Always On FCI(Failover Cluster Instance, 다음 섹션 참조)일 수 있습니다.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. 가용성 그룹에는 주 복제본에 있는 데이터베이스의 완전 읽기/쓰기 복사본이 하나 있고 모든 보조 복제본은 최종 사용자 또는 응용 프로그램에서 직접 트랜잭션을 수신할 수 없습니다.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. 아래 그림은 WSFC(Windows Server 장애 조치 클러스터)를 사용하는 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가 기본 클러스터인 단순한 두 개의 서버 또는 노드 구성을 보여줍니다.The example shows a simple two server, or node, configuration where a WSFC is the underlying cluster.

단순한 가용성 그룹

Standard 및 Enterprise Edition은 복제본에 대한 최대값이 다릅니다.Standard and Enterprise Edition have different maximums when it comes to replicas. 기본 가용성 그룹이라고 하는 Standard Edition의 가용성 그룹은 가용성 그룹의 데이터베이스가 하나뿐인 두 개의 복제본(주 복제본과 보조 복제본)을 지원합니다.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은 하나의 가용성 그룹에 여러 데이터베이스를 구성할 수 있을 뿐 아니라 최대 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.

가용성과 관련하여 가용성 그룹은 자동 또는 수동 장애 조치(failover)를 제공할 수 있습니다.When it comes to availability, availability groups can provide either automatic or manual failover. 자동 장애 조치(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 이상)이 사용되는 한, 수신기가 사용되는 경우 최종 사용자에게 거의 영향을 미치지 않으면서 장애 조치(failover)가 처리되어야 합니다.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)는 자동 또는 수동으로 구성될 수 있으며 일반적으로 초 단위로 측정됩니다.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에서 기본 클러스터가 작동하는 방식의 차이로 인해 가용성 그룹의 모든 장애 조치(failover)(수동 또는 자동)는 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를 통해 수동 장애 조치(failover)를 수행해야 합니다.On Windows Server-based availability group deployments, manual failovers must be done via SQL Server. 자동 장애 조치(failover)는 Windows Server와 Linux의 기본 클러스터에서 처리됩니다.Automatic failovers are handled by the underlying cluster on both Windows Server and Linux.
  • SQL Server 2017에서 Linux의 가용성 그룹에 권장되는 구성은 최소 세 개의 복제본입니다.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. 두 개 복제본 구성을 위한 향상된 솔루션이 나중에 릴리즈될 예정입니다.An improved solution for a two replica configuration will come post-release.
  • Linux에서 각 수신기에서 사용되는 일반 이름은 DNS에 정의되며 Windows Server에서처럼 클러스터에 정의되지 않습니다.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(Distributor Transaction Coordinator) 지원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)
Always On 가용성 그룹 클러스터 유형Always on availability group cluster types

Windows Server에 기본 제공되는 클러스터링의 가용성 형태는 장애 조치(failover) 클러스터링이라는 기능을 통해 활성화됩니다.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. Linux의 SQL Server 2017은 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의 장애 조치(failover) 클러스터링 기능만큼 통합되어 있지 않습니다.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. 둘 다 개별 서버를 구성으로 결합하여 가용성을 제공하는 방법을 제공하고 리소스, 제약 조건(다르게 구현되는 경우에도), 장애 조치(failover) 등의 개념을 제공합니다.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. 가용성 그룹과 자동 장애 조치(failover)와 같은 FCI 구성 양쪽 모두에 대해 Pacemaker를 지원하기 위해 Microsoft는 mssql-server-ha 패키지를 제공합니다. 이것은 Pacemaker용 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의 차이 중 하나는 Pacemaker에 네트워크 이름 리소스가 없다는 것입니다. 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.

클러스터 스택의 차이로 인해, SQL Server는 WSFC에서 기본적으로 처리하는 일부 메타 데이터를 처리해야 하기 때문에 가용성 그룹에 대한 일부 변경이 필요했습니다.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. 클러스터 유형은 세 가지입니다.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 기반 가용성 그룹의 경우 가용성 그룹을 만들 때 클러스터 유형을 외부로 설정해야 합니다.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.

없음이라는 클러스터 유형은 Windows Server 및 Linux 가용성 그룹 모두에서 사용할 수 있습니다.A cluster type of None can be used with both Windows Server and Linux availability groups. 클러스터 유형을 없음으로 설정하면 가용성 그룹에 기본 클러스터가 필요하지 않다는 의미입니다.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. 즉, 가용성 그룹을 없음에서 외부 또는 WSFC로 또는 그 반대로 전환할 수 없습니다.This means that an availability group cannot be switched from None to External or WSFC, or vice versa.

데이터베이스의 읽기 전용 복사본만 추가하려는 경우 또는 가용성 그룹이 마이그레이션/업그레이드에 제공하는 기능은 필요하지만 기본 클러스터나 복제의 추가 복잡성에 관여하지 않으려는 경우에는 클러스터 유형이 없음인 가용성 그룹이 완벽한 솔루션이 될 수 있습니다.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-out.

아래 스크린샷은 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 AG 옵션

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. 하지만 하나의 보조 복제본이 동기화되었지만 다른 복제본에 문제가 있다면 오작동하는 복제본을 기다리거나 그대로 진행하도록 기본 복제본에 알리는 동작을 제어할 방법이 없습니다.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:

  • 가능한 값은 0, 1 및 2입니다.There are three possible values: 0, 1, and 2
  • 이 값은 동기화해야 하는 보조 복제본의 수이며 데이터 손실, 가용성 그룹 가용성 및 장애 조치(failover)에 영향을 미칩니다.The value is the number of secondary replicas that must be synchronized, which has implications for data loss, availability group availability, and failover
  • WSFC 및 클러스터 유형이 없음인 경우 기본값은 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
  • 클러스터 유형이 외부인 경우 기본적으로 클러스터 메커니즘에 의해 이 값이 설정되며 수동으로 재정의할 수 있습니다.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는 장애 조치(failover) 동작에도 영향을 주는데 이것은 필요한 수의 보조 복제본이 적절한 상태가 아니면 자동 장애 조치가 발생할 수 없기 때문입니다.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이면 자동 장애 조치(failover)를 허용하지 않으므로 Linux에서 자동 장애 조치(failover)와 함께 동기를 사용할 경우 자동 장애 조치를 수행하려면 값을 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 DTC(Distributed Transaction Coordinator) 지원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. 분산 트랜잭션은 다음 두 가지 방법 중 하나로 수행할 수 있습니다.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 지원의 또 다른 개선 사항은 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 장애 조치(failover) 클러스터 인스턴스Always on failover cluster instances

클러스터형 설치는 버전 6.5부터 SQL Server의 기능입니다.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의 리소스는 주어진 시간에 한 노드에서만 실행 및 소유할 수 있습니다.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.

장애 조치(Failover) 클러스터 인스턴스

장애 조치(failover) 후에는 아래 그림과 같이 소유권이 변경됩니다.After a failover, ownership changes as is seen in the picture below.

사후 장애 조치(Failover)

FCI에서는 데이터 손실이 거의 없지만 데이터 복사본이 하나이기 때문에 기본 공유 저장소는 단일 실패 지점입니다.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가 다른 노드로 장애 조치(failover)되면 노드를 중지하고 다른 노드에서 시작하기 때문에 서버의 전원을 껐다 켜는 것과는 다릅니다.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. 따라서 데이터베이스는 장애 또는 수동 장애 조치(failover) 시간의 데이터 지점과 일관성을 유지하기 때문에 데이터 손실이 없습니다.Therefore, the database is consistent from a data point to the time of the failure or manual failover, hence no data loss. 데이터베이스는 복구가 완료된 후에만 사용할 수 있으며 복구 시간은 다양한 요인에 따라 달라지며 일반적으로 가용성 그룹의 장애 조치(failover) 시간보다 길어집니다.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. 가용성 그룹을 장애 조치(failover)하면 데이터베이스를 사용할 수 있도록 만드는 데 필요한 추가 작업(예: 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는 주 또는 보조 복제본을 호스트하는 인스턴스 중 하나로 가용성 그룹에 참여할 수 있습니다.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에서는 호스트당 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의 입증된 또 다른 가용성 기능이 될 수 있습니다.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의 기본 백업을 기반으로 로그 전달 프로세스는 트랜잭션 로그 백업을 자동으로 생성하고, 이것을 웜 대기라는 하나 이상의 인스턴스에 복사하고, 트랜잭션 로그 백업을 해당 대기 인스턴스에 자동으로 적용합니다.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. 단일 가용성 그룹에는 여러 데이터베이스가 포함될 수 있지만 로그 전달은 데이터베이스별로 구성해야 합니다.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

가용성 그룹의 장점 중 하나는 단일 기능을 사용하여 고가용성 및 재해 복구를 구성할 수 있다는 점입니다.One of the benefits of availability groups is that both high availability and disaster recovery can be configured using a single feature. 공유 저장소의 고가용성을 보장하지 않고도 각각 별개의 저장소를 사용하여 고가용성을 위해 하나의 데이터 센터에 로컬인 복제본을 확보하고 재해 복구를 위해 다른 데이터 센터에 원격 복제본을 확보하는 것이 훨씬 쉽습니다.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. 하나의 주 복제본은 모든 보조 복제본을 동기화된 상태로 유지할 책임이 있습니다.One primary replica is responsible for keeping all secondary replicas synchronized.

가용성 그룹

클러스터 유형이 없음인 가용성 그룹 외부에서 가용성 그룹은 모든 복제본이 동일한 기본 클러스터(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는 두 개의 서로 다른 데이터 센터에서 작동하도록 확장되어 복잡성이 추가됩니다.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 장애 조치(failover) 클러스터 인스턴스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 데이터베이스에 재해 복구를 제공하는 가장 오래된 방법 중 하나입니다.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

하나 이상의 가용성 그룹을 포함하는 기존 인스턴스를 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.

분산형 AG는 새로운 구성으로 마이그레이션하거나 SQL Server를 업그레이드하는 또 다른 방법입니다.Distributed AGs are also another method to migrate to a new configuration or upgrade SQL Server. 예를 들어 분산형 AG는 서로 다른 아키텍처에서 서로 다른 기본 AG를 지원하기 때문에 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.

분산형 AG

마지막으로 클러스터 유형이 없음인 가용성 그룹을 마이그레이션이나 업그레이드에 사용할 수도 있습니다.Finally, availability groups with a cluster type of None can also be used for migration or upgrading. 일반적인 가용성 그룹 구성에서 클러스터 유형을 짜맞출 수 없으므로 모든 복제본의 유형이 없음이어야 합니다.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.

가용성 그룹은 패치 적용이 완료되는 동안 주 복제본을 보조 복제본으로 수동 장애 조치(failover)하여 기본 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. 운영 체제 측면에서 볼 때 이렇게 하는 것이 Windows Server에서 더 일반적일 수 있습니다. 그 이유는 자주는 아니지만 종종 기본 OS를 서비스하는 경우 재부팅이 필요하기 때문입니다.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. 적절한 수의 복제본에 패치가 적용되면 주 복제본을 다른 노드로 수동으로 장애 조치(failover)하여 업그레이드를 수행합니다.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 장애 조치(failover) 클러스터 인스턴스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 기반 FCI는 기본 Windows Server에 패치를 적용해야 하는 경우 여전히 많이 사용되는 옵션입니다.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 장애 조치(failover) 클러스터 인스턴스 업그레이드를 참조하세요.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

Linux에서 SQL Server에 대한 다른 두 가지 배포 방법은 컨테이너 및 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의 가용성을 높이는 데 있어 특별한 고려 사항이 있습니다.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. 클러스터 유형이 없음인 가용성 그룹을 구성할 수 있지만 앞에서 설명한 것처럼 실제 가용성 구성으로 간주되지는 않습니다.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.

Azure를 사용하여 SQL Server를 설치하면 Linux IaaS 가상 컴퓨터를 배포할 수 있습니다.Linux IaaS virtual machines can be deployed with SQL Server installed using Azure. 온-프레미스 기반 설치에서와 마찬가지로 지원되는 설치에서는 Pacemaker 외부에 있는 STONITH(헤드에 있는 다른 노드 맞추기)를 사용해야 합니다.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

이 섹션에서는 Windows Server와 Linux 모두에서 지원되는 SQL Server를 사용하여 다른 용도 외에 가용성을 위해 함께 작동할 수 있는 방법은 물론 둘 이상의 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.

플랫폼 간 시나리오 및 상호 운용성 시나리오를 언급하기 전에 두 가지 사실을 명시해야 합니다.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.
  • FCI 또는 클러스터 유형이 외부인 가용성 그룹에서는 Linux 배포판 혼합을 지원하지 않습니다.Mixing Linux distributions is not supported with FCIs or an availability group that has a cluster type of External. 해당 시나리오의 모든 가용성 그룹 복제본은 동일한 Linux 배포판뿐만 아니라 동일한 버전으로 구성되어야 합니다.All availability group replicas in that scenario must be configured not only the same Linux distribution, but also the same version. SQL Server를 두 개의 플랫폼 또는 Linux의 여러 배포판에서 작동할 수 있도록 지원되는 두 가지 방법은 가용성 그룹과 로그 전달입니다.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

분산형 가용성 그룹은 가용성 그룹 하에 있는 두 개의 기본 클러스터가 두 개의 서로 다른 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.

분산형 가용성 그룹

가용성 그룹의 클러스터 유형이 없음으로 구성되어 있으면 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와 Linux의 SQL Server에 대한 데이터베이스, 파일 구조 등에 차이가 없습니다.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 하위 버전에 있고 원본이 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-out

SQL Server 2012에서 도입된 이후, 보조 복제본은 읽기 전용 쿼리에 사용될 수 있습니다.Since their introduction in SQL Server 2012, secondary replicas have had the ability to be used for read-only queries. 가용성 그룹으로 작업을 수행할 수 있는 방법은 두 가지 입니다. 보조 복제본에 직접 액세스를 허용하는 방법과 읽기 전용 라우팅을 구성하는 방법입니다. 후자 경우 수신기를 사용해야 합니다.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. 가용성 그룹에 있는 각각의 주 복제본은 완전한 읽기/쓰기 복사본이 아니더라도 두 개의 다른 가용성 그룹을 시드할 수 있기 때문에 분산형 가용성 그룹마다 읽기 가능한 데이터의 복사본을 최대 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부터 클러스터 유형이 없음으로 구성된 가용성 그룹을 사용하여 거의 실시간에 가까운 읽기 전용 솔루션을 만들 수 있습니다.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.

유일한 주의 사항은 클러스터 유형이 없음인 경우 기본 클러스터가 없으므로 읽기 전용 라우팅을 구성하는 것이 약간 다르다는 것입니다.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.

로그 전달 웜 대기는 데이터베이스를 대기 상태로 복원하여 기술적으로 읽을 수 있는 용도로 구성할 수 있습니다.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-out 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.