

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Amazon EC2 for SQL Server
<a name="ec2-sql"></a>

Amazon EC2는 자체 관리형 SQL Server 데이터베이스를 지원합니다. 즉, 인프라 및 데이터베이스 환경 설정을 완전히 제어할 수 있습니다. Amazon EC2에서 데이터베이스를 실행하는 것은 자체 서버에서 데이터베이스를 실행하는 것과 매우 유사합니다. 데이터베이스 및 운영 체제 수준 액세스를 완전히 제어할 수 있으므로 원하는 도구를 사용하여 운영 체제, 데이터베이스 소프트웨어, 패치, 데이터 복제, 백업 및 복원을 관리할 수 있습니다. 이 마이그레이션 옵션을 사용하려면 AWS 아키텍처 모범 사례에 따라 EC2 인스턴스, 스토리지 볼륨, 확장성, 네트워킹 및 보안을 포함한 모든 구성 요소를 설정, 구성, 관리 및 조정해야 합니다. 동일하거나 다른 AWS 리전의 인스턴스에서 데이터 복제 및 복구는 사용자의 책임입니다.

## Amazon EC2를 선택해야 하는 경우
<a name="ec2-sql-choosing"></a>

Amazon EC2는 다음과 같은 경우 SQL Server 데이터베이스에 적합한 마이그레이션 옵션입니다.
+ 데이터베이스를 완전히 제어하고 기본 운영 체제, 데이터베이스 설치 및 구성에 액세스할 수 있어야 합니다.
+ 백업 및 복구, 운영 체제 및 데이터베이스 패치 적용, 운영 체제 및 데이터베이스 매개 변수 조정, 보안 관리, 고가용성 또는 복제 구성 등 데이터베이스를 관리하고자 합니다.
+ 현재 Amazon RDS에서 지원하지 않는 기능과 옵션을 사용하고 싶습니다. 자세한 내용은 Amazon RDS 설명서의 [지원되지 않는 기능 및 지원이 제한된 기능](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport)을 참조하세요.
+ Amazon RDS에서 지원하지 않는 특정 SQL Server 버전이 필요합니다. 지원되는 버전 및 에디션 목록은Amazon RDS 설명서의 [Amazon RDS 기반 SQL Server 버전](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport)을 참조하세요.
+ 데이터베이스 크기 및 성능 요구 사항은 현재 Amazon RDS for SQL Server 서비스를 초과합니다. 자세한 내용은 Amazon RDS 설명서의 [Amazon RDS DB 인스턴스 스토리지](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)를 참조하십시오.
+ 애플리케이션과 호환되지 않을 수 있는 자동 소프트웨어 패치는 피하는 것이 좋습니다.
+ Amazon RDS for SQL Server 라이선스 포함 모델을 사용하는 대신 자체 라이선스를 사용하는 것이 좋습니다.
+ 현재 한도보다 높은 IOPS와 스토리지 용량을 달성하고자 합니다. 자세한 내용은 Amazon RDS 설명서의 [Amazon RDS DB 인스턴스 스토리지](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)를 참조하십시오.

Amazon EC2에서 현재 지원되는 SQL Server 기능 및 버전 목록은 이 가이드 뒷부분에 나오는 [Amazon EC2와 Amazon RDS 중 선택](comparison.md)을 참조하세요.

# 높은 가용성
<a name="ec2-sql-ha"></a>

Amazon EC2 기반 SQL Server 데이터베이스와 함께 SQL Server가 지원되는 모든 복제 기술을 사용하여 고가용성, 데이터 보호 및 재해 복구를 달성할 수 있습니다. 일반적인 솔루션으로는 로그 전달, 데이터베이스 미러링, Always On 가용성 그룹, Always On 장애 조치 클러스터 인스턴스 등이 있습니다.

다음 다이어그램은 단일 AWS 리전 내의 여러 가용 영역에서 Amazon EC2의 SQL Server를 사용하는 방법을 보여줍니다. 기본 데이터베이스는 읽기-쓰기 데이터베이스이고, 보조 데이터베이스는 로그 전달, 데이터베이스 미러링 또는 고가용성을 위한 Always On 가용성 그룹으로 구성됩니다. 기본 데이터베이스의 모든 트랜잭션 데이터는 전송되며 로그 전달의 경우 보조 데이터베이스에 비동기적으로, Always On 가용성 그룹 및 미러링의 경우 비동기적으로 적용할 수 있습니다.

 ![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png) 

# 로그 전달
<a name="ec2-log-shipping"></a>

로그 전달을 사용하면 기본 데이터베이스 인스턴스에서 별도의 DB 인스턴스에 있는 하나 이상의 보조 데이터베이스(*웜 스탠바이라고도* 함)로 트랜잭션 로그 백업을 자동으로 전송할 수 있습니다. 로그 전달은 SQL Server 에이전트 작업을 사용하여 트랜잭션 로그 백업의 백업, 복사 및 적용 프로세스를 자동화합니다. 로그 전달은 일반적으로 재해 복구 기능으로 간주되지만 기본 DB 인스턴스에 장애가 발생할 경우 보조 DB 인스턴스를 승격시켜 고가용성을 제공할 수도 있습니다. RTO와 RPO가 유연하거나 데이터베이스가 업무상 매우 중요하다고 간주되지 않는 경우 SQL Server 데이터베이스의 가용성을 높이기 위해 로그 전달을 사용해 보세요.

로그 전달은 필요할 때 기본 데이터베이스의 읽기 전용 복사본으로 사용할 수 있도록 보조 데이터베이스에 대한 액세스를 제공함으로써 데이터베이스의 가용성을 높입니다. 래그 지연(더 긴 지연 시간)을 구성하여 이러한 변경 내용이 보조 데이터베이스로 전달되기 전에 기본 데이터베이스에서 실수로 변경된 데이터를 복구할 수 있습니다.

기본 및 보조 DB 인스턴스를 별도의 가용 영역에서 실행하고 모니터 인스턴스를 배포하여 로그 전달의 모든 세부 정보를 추적하는 것이 좋습니다. 로그 전달 그룹의 백업, 복사, 복원 및 실패 이벤트는 모니터 인스턴스에서 사용할 수 있습니다. 로그 전달 구성은 기본 서버에서 보조 서버로 자동 장애 조치되지 않습니다. 하지만 기본 데이터베이스를 사용할 수 없게 되면 보조 데이터베이스를 수동으로 온라인 상태로 만들 수 있습니다.

로그 전달은 대개 재해 복구 솔루션으로 사용되지만 애플리케이션 요구 사항에 따라 고가용성 솔루션으로도 사용될 수 있습니다. 다음과 같은 경우 로그 전달을 사용하세요.
+ RTO 및 RPO 요구 사항은 유연합니다. 로그 전달은 분 단위의 RPO와 몇 분에서 몇 시간의 RTO를 제공합니다.
+ 보조 데이터베이스로의 자동 장애 조치는 필요하지 않습니다.
+ 보조 데이터베이스에서 읽고 싶지만 복원 작업 중에는 가독성이 필요하지 않습니다.

로그 전달에 대한 자세한 정보는 [Microsoft SQL Server 설명서](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server)를 참조하세요.

# 데이터베이스 미러링
<a name="ec2-db-mirroring"></a>

데이터베이스 미러링은 EC2 인스턴스에 있는 데이터베이스를 가져와 별도의 DB 인스턴스에 전체 또는 거의 완전한 읽기 전용 사본(미러)을 제공합니다. Amazon RDS는 데이터베이스 미러링을 사용하여 Amazon RDS for SQL Server에 대한 다중 AZ 지원을 제공합니다. 이 기능은 데이터베이스의 가용성과 보호를 향상시키고 업그레이드 중에도 데이터베이스를 계속 사용할 수 있는 메커니즘을 제공합니다.

**참고**  
[Microsoft 설명서에](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server) 따르면 데이터베이스 미러링은 향후 SQL Server 버전에서 제거될 예정입니다. 대신 Always On 가용성 그룹을 사용할 계획을 세워야 합니다.

데이터베이스 미러링에서 SQL 서버는 다음 세 가지 역할 중 하나를 수행할 수 있습니다.
+ 기본 서버는 데이터베이스의 기본 읽기/쓰기 버전을 호스팅합니다.
+ 주요 데이터베이스의 복사본을 호스팅하는 미러 서버.
+ 선택적 미러링 모니터 서버. 이 서버는 보안 강화 모드에서만 사용할 수 있습니다. 데이터베이스 미러 상태를 모니터링하고 기본 데이터베이스에서 미러 데이터베이스로의 장애 조치를 자동화합니다.

기본 서버와 미러 서버 간에 미러링 세션이 설정됩니다. 미러링 중에는 주요 데이터베이스에서 수행된 모든 데이터베이스 변경 내용이 미러 데이터베이스에서도 수행됩니다. 데이터베이스 미러링은 동기 또는 비동기 작업일 수 있습니다. 이는 보호 우선 모드와 고성능 모드의 두 가지 미러링 작동 모드로 결정됩니다.
+ **안전 강화 모드:** 이 모드는 동기 작업을 사용합니다. 이 모드에서 데이터베이스 미러링 세션은 주요 데이터베이스의 삽입, 업데이트 및 삭제 작업을 최대한 빨리 미러 데이터베이스와 동기화합니다. 데이터베이스가 동기화되는 즉시 주요 데이터베이스와 미러 데이터베이스 모두에서 트랜잭션이 커밋됩니다. 미러 데이터베이스가 같거나 다른 가용 영역에 있지만 같은 AWS 리전 내에서 호스팅되는 경우 이 운영 모드를 사용하는 것이 좋습니다.
+ **고성능 모드:** 이 모드는 비동기 작업을 사용합니다. 이 모드에서 데이터베이스 미러링 세션은 주요 데이터베이스의 삽입, 업데이트 및 삭제 작업을 미러 데이터베이스와 동기화하지만 주요 데이터베이스가 트랜잭션을 커밋하는 시간과 미러 데이터베이스가 트랜잭션을 커밋하는 시간 사이에 지연이 발생할 수 있습니다. 미러 데이터베이스가 서로 다른 AWS 리전에 있는 경우이 모드를 사용하는 것이 좋습니다.

다음과 같은 경우 데이터베이스 미러링을 사용하세요.
+ RTO 및 RPO 요구 사항이 엄격하며 기본 데이터베이스와 보조 데이터베이스 간에 지연이 있어서는 안 됩니다. 데이터베이스 미러링은 0초(동기 커밋 포함)의 RPO와 초\$1분의 RTO를 제공합니다.
+ 보조 데이터베이스에서 읽을 필요는 없습니다.
+ 미러링 모니터 서버가 동기화 모드로 구성되어 있을 때 자동 장애 조치를 수행하려고 합니다.
+ 기본 옵션인 Always On 가용성 그룹은 사용할 수 없습니다.

제한 사항:
+ 일대일 장애 조치만 지원됩니다. 여러 데이터베이스 대상을 기본 데이터베이스와 동기화할 수 없습니다.

미러링에 대한 자세한 정보는 [Microsoft SQL Server 설명서](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server)를 참조하세요.

# Always On 가용성 그룹
<a name="ec2-always-on"></a>

SQL Server Always On 가용성 그룹은 SQL Server 데이터베이스를 위한 고가용성 및 재해 복구 솔루션을 제공합니다. 가용성 그룹은 함께 장애 조치되는 사용자 데이터베이스 집합으로 구성됩니다. 여기에는 기본 읽기/쓰기 데이터베이스 세트 하나와 관련된 보조 데이터베이스의 여러 세트(1\$18개)가 포함됩니다. 보조 데이터베이스를 애플리케이션 계층에서 기본 데이터베이스의 읽기 전용 복사본으로 사용할 수 있도록 만들어(SQL Server Enterprise 에디션만 해당) 읽기 워크로드를 위한 스케일 아웃 아키텍처를 제공할 수 있습니다. 보조 데이터베이스를 백업 작업에 사용할 수도 있습니다.

SQL Server Always On 가용성 그룹은 동기 및 비동기 커밋 모드를 모두 지원합니다. 동기 모드에서 기본 복제본은 변경 사항이 보조 복제본의 로그에 커밋되거나 기록된 후 데이터베이스 트랜잭션을 커밋합니다. 이 모드를 사용하면 복제본이 동기화된 경우 계획된 수동 장애 조치와 자동 장애 조치를 수행할 수 있습니다. 동일한 환경 내의 SQL Server 인스턴스 간에 동기 커밋 모드를 사용할 수 있습니다(예: 모든 인스턴스가 온프레미스이거나 모든 인스턴스가 있는 경우 AWS).

비동기 커밋 모드에서 기본 복제본은 보조 복제본을 기다리지 않고 데이터베이스 트랜잭션을 커밋합니다. 다른 환경에 있는 SQL Server 인스턴스 간에 비동기 커밋 모드를 사용할 수 있습니다(예: 온프레미스 및에 인스턴스가 있는 경우 AWS).

고가용성 또는 재해 복구를 위해 Always On 가용성 그룹을 사용할 수 있습니다. 다음과 같은 경우 이 방법을 사용하세요.
+ 엄격한 RTO 및 RPO 요구 사항이 있습니다. Always On 가용성 그룹은 초 단위의 RPO와 초에서 분 단위의 RTO를 제공합니다.
+ 데이터베이스 그룹을 관리하고 장애 조치하려고 합니다. Always On 가용성 그룹은 SQL Server 2019의 동기 커밋 모드에서 0-4개의 보조 복제본을 지원합니다.
+ 동기식 커밋 모드에서 자동 장애 조치를 사용하려는 경우 미러링 모니터 서버가 필요하지 않습니다.
+ 보조 데이터베이스에서 읽고 싶습니다.
+ 여러 데이터베이스 대상을 기본 데이터베이스와 동기화하려고 합니다.

SQL Server 2016 SP1부터 SQL Server Standard 에디션은 가용성 그룹별로 읽을 수 없는 단일 보조 데이터베이스 및 리스너에 대한 기본적인 고가용성을 제공합니다. 또한 가용성 그룹당 최대 두 개의 노드를 지원합니다.

# Always On 장애 조치 클러스터 인스턴스
<a name="ec2-fci"></a>

SQL Server Always On 장애 조치 클러스터 인스턴스(FCI)는 Windows Server 장애 조치 클러스터링(WSFC)을 사용하여 서버 인스턴스 수준에서 고가용성을 제공합니다. FCI는 SQL Server의 전체 설치에 고가용성을 제공하기 위해 WSFC 노드에 설치되는 SQL Server의 단일 인스턴스입니다. 기본 노드에 하드웨어, 운영 체제, 애플리케이션 또는 서비스 장애가 발생하는 경우 SQL Server 인스턴스 내의 모든 항목이 다른 WSFC 노드로 이동됩니다. 여기에는 시스템 데이터베이스, SQL Server 로그인, SQL Server 에이전트 작업 및 인증서가 포함됩니다.

FCI는 일반적으로 다음과 같은 경우 Always On 가용성 그룹보다 선호됩니다.
+ 엔터프라이즈 에디션 대신 SQL Server 스탠다드 에디션을 사용하고 있습니다.
+ 인스턴스당 많은 수의 작은 데이터베이스가 있습니다.
+ SQL Server 에이전트 작업, 로그인 등과 같은 인스턴스 수준 개체를 지속적으로 수정하고 있습니다.

FCIs 있습니다 AWS.
+ 영구 예약이 포함된 Amazon EBS Multi-Attach
+ Amazon FSx for Windows File Server
+ Amazon FSx for NetApp ONTAP
+  AWS 파트너의 솔루션

## 영구 예약이 포함된 Amazon EBS Multi-Attach 사용
<a name="fci-multi-attach"></a>

[NVMe 예약이 포함된 Amazon EBS Multi-Attach](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html)는 Windows Server 장애 조치 클러스터에서 공유 스토리지로 Amazon EBS `io2` 볼륨을 사용하여 SQL Server FCI를 생성할 수 있도록 지원합니다. 이 기능을 통해 Amazon EBS `io2` 볼륨을 사용하여 장애 조치 클러스터를 구축할 수 있으므로, 장애 조치 클러스터 설정 프로세스가 간소화됩니다. 이러한 볼륨은 동일한 가용 영역에 있는 인스턴스에만 연결할 수 있습니다. Amazon EBS `io2` 볼륨을 사용하여 Windows Server 장애 조치 클러스터를 배포하려면 latest AWS NVMe 드라이버를 사용해야 합니다.

Amazon EBS 볼륨 및 인스턴스 저장소 볼륨은 [Nitro 기반 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)에서 NVMe 블록 디바이스로 표시됩니다. WSFC 및 SQL Server FCI를 구성하기 위해 Amazon EBS `io2` 볼륨을 사용할 경우, [SCSI 영구 예약 기능](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations)이 구성된 [AWS NVMe 드라이버](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html)가 설치되어 있어야 합니다.

이 기능에 대한 자세한 내용은 AWS 블로그 게시물 [How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach on Windows Server](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/)를 참조하세요.

## Amazon FSx for Windows File Server 사용
<a name="fci-fsx-windows"></a>

[Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)는 완전 관리형 공유 파일 스토리지를 제공합니다. 두 가용 영역에 스토리지를 동기식으로 자동 복제하여 고가용성을 제공합니다. FSx for Windows File Server를 파일 스토리지로 사용하면 Amazon EC2 기반 SQL Server 고가용성 배포를 간소화하고 최적화하는 데 도움이 됩니다.

Microsoft SQL Server에서 고가용성은 일반적으로 WSFC의 여러 데이터베이스 노드에 걸쳐 배포되며, 각 노드는 공유 파일 스토리지에 액세스할 수 있습니다. FSx for Windows File Server를 SQL Server 고가용성 배포를 위한 공유 스토리지로 사용하는 방법은 활성 데이터 파일을 위한 스토리지와 SMB 파일 공유 감시 두 가지가 있습니다.

FSx for Windows File Server를 사용하여 SQL Server FCI 배포의 복잡성과 비용을 줄이는 방법에 대한 자세한 내용은 블로그 게시물 [Amazon FSx for Windows File Server를 사용하여 Microsoft SQL Server 고가용성 배포 간소화](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)를 참조하세요. 해당 블로그 게시물에서는 Amazon FSx Multi-AZ 파일 시스템을 공유 스토리지 솔루션으로 사용하여 SQL Server FCI를 배포하는 단계별 지침도 제공합니다. 자세한 내용은 [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) 설명서를 참조하세요.

## Amazon FSx for NetApp ONTAP 사용
<a name="fci-fsx-ontap"></a>

Amazon FSx for NetApp ONTAP는 NetApp ONTAP 파일 시스템을 기반으로 한 완전 관리형 서비스로, 신뢰성 높고 확장 가능하며 성능이 우수하고 기능이 풍부한 파일 스토리지를 제공합니다. FSx for ONTAP는 NetApp 파일 시스템의 친숙한 기능, 성능, API 작업을 완전 관리형 AWS 서비스의 민첩성, 확장성 및 단순성과 결합합니다.

FSx for ONTAP는 Windows 및 Linux 시스템에서 NFS, SMB, iSCSI 프로토콜을 통한 다중 프로토콜 데이터 액세스를 제공합니다. 블로그 게시물 [Amazon FSx for NetApp ONTAP를 사용한 SQL Server 고가용성 배포](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/)에 설명된 대로 SQL Server Always On FCI 아키텍처를 고가용성으로 구축할 수 있습니다. 또한 FSx for ONTAP은 복구 시간 목표(RTO) 및 복구 시점 목표(RPO) 요구 사항을 충족하기 위해 SQL Server 환경을 다른 AWS 리전 로 장애 조치하는 빠른 방법을 제공할 수 있습니다. 자세한 내용은 블로그 게시물 [FSx for ONTAP를 사용하여 SQL Server Always-On 장애 조치 클러스터 인스턴스용 HA 및 DR 구현](https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/)을 참조하세요.

Always On 가용성 그룹 및 단일 노드 배포 AWS Launch Wizard 를 지원 AWS하여를 사용하여에 SQL Server 솔루션을 배포할 수도 있습니다. Launch Wizard는 FSx for ONTAP를 공유 스토리지로 사용하여 Amazon EC2에서 SQL Server Always On FCI를 배포하는 기능을 지원합니다. 이 서비스는 복잡한 수동 배포 과정을 가이드 기반 콘솔 마법사로 대체하여 공유 스토리지를 사용하는 온프레미스 SQL Server 워크로드 마이그레이션을 빠르게 진행할 수 있도록 함으로써 시간을 절약하고 효율성을 높입니다. Launch Wizard가 몇 시간 안에 SQL Server FCIs를 프로비저닝하고 구성하는 데 도움이 되는 방법에 대한 자세한 내용은 블로그 게시물 [Simplify SQL Server Always On deployments with AWS Launch Wizard and Amazon FSx](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/)를 참조하세요. Launch Wizard는 또한 [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/)를 공유 스토리지 솔루션으로 사용하여 SQL Server Always On FCI 배포를 지원합니다.

## AWS 파트너의 솔루션 사용
<a name="fci-partners"></a>
+ [SIOS DataKeeper](https://us.sios.com/)는 AWS 리전 및 가용 영역에서 고가용성 클러스터 장애 조치 지원을 제공합니다. SIOS DataKeeper는 [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=3c91e2f7-fc8d-4cce-a8aa-1e37abcb4408)에서 제공됩니다.
+ DH2i의 [DxEnterprise](https://dh2i.com/dxenterprise-high-availability/)를 사용하면 Kubernetes 내 SQL Server 가용성 그룹에 대한 완전 자동 장애 조치와 Windows와 Linux에 대한 통합 인스턴스 장애 조치를 활성화할 수 있습니다. D2HI 역시 [AWS Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b)에서 제공됩니다.

# FSx for Windows File Server
<a name="ec2-fsx"></a>

FSx for Windows File Server는 SMB(서버 메시지 블록) 프로토콜을 사용하여 액세스할 수 있는 안정성과 확장성이 뛰어난 완전 관리형 파일 스토리지를 제공합니다. Windows Server를 기반으로 구축되었으며 사용자 할당량, 최종 사용자 파일 복원 및 Microsoft Active Directory(AD) 통합과 같은 광범위한 관리 기능을 제공합니다. 단일 AZ 및 다중 AZ 배포 옵션, 완전 관리형 백업, 저장된 데이터 및 전송 중인 데이터의 암호화를 제공합니다. 솔리드 스테이트 드라이브(SSD) 및 하드 디스크 드라이브(HDD) 스토리지 옵션을 사용하여 워크로드의 비용 및 성능을 최적화할 수 있으며, 언제든지 스토리지를 확장하고 파일 시스템의 처리 성능을 변경할 수 있습니다. Amazon FSx 파일 스토리지는 및 온프레미스에서 실행되는 Windows AWS, Linux 컴퓨팅 인스턴스에서 액세스할 수 있습니다.

Amazon FSx는 지속적 가용성(CA) 파일 공유 및 더 작은 파일 시스템을 지원하므로 고가용성 SQL Server 배포를 위한 공유 Windows 스토리지를 더 쉽게 배포할 수 있습니다. 이 옵션은 다음과 같은 사용 사례에 적합합니다.
+ WSFC 인스턴스의 SQL Server 노드에서 사용하는 공유 스토리지로 사용됩니다.
+ WSFC가 있는 모든 SQL Server 클러스터에서 사용할 수 있는 SMB 파일 공유 감시자로 사용할 수 있습니다.

Amazon FSx는 파일 시스템당 최대 2GB/초의 기준 처리량, 수십만 IOPS, 1밀리초 미만의 일관된 지연 시간으로 빠른 성능을 제공합니다.

SQL 인스턴스에 적합한 성능을 제공하기 위해 파일 시스템 크기와 무관한 처리량 수준을 선택할 수 있습니다. 처리량 용량 수준이 높을수록 파일 서버가 액세스하는 SQL Server 인스턴스에 제공할 수 있는 IOPS 수준도 높아집니다.

스토리지 용량에 따라 저장할 수 있는 데이터의 양뿐만 아니라 스토리지에서 수행할 수 있는 IOPS 수도 결정됩니다. 각 기가바이트의 스토리지는 3IOPS를 제공합니다. 각 파일 시스템의 크기를 최대 64TB까지 프로비저닝할 수 있습니다.

SQL Server 고가용성 배포의 복잡성과 비용을 줄이기 위해 Amazon FSx를 구성하고 사용하는 방법에 대한 자세한 내용은 AWS 스토리지 블로그의 [FSx for Windows File Server를 사용하여 Microsoft SQL Server 고가용성 배포 간소화](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/)를 참조하세요. 새 CA 공유를 생성하는 방법에 대한 자세한 내용은 [FSx for Windows File Server 설명서](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share)를 참조하세요.

# 재해 복구
<a name="ec2-sql-dr"></a>

많은 조직에서 SQL Server 데이터베이스의 고가용성을 구현하지만, 진정한 IT 복원력이 필요한 조직에는 이 정도로는 충분하지 않습니다. 업무상 중요한 데이터베이스의 데이터 손실과 가동 중지 시간을 방지하려면 재해 복구 솔루션을 구현하는 것이 좋습니다. SQL Server 배포에 다중 리전 재해 복구 아키텍처를 채택하면 다음과 같은 이점을 얻을 수 있습니다.
+ 비즈니스 연속성 달성
+ 지리적으로 분산된 고객층의 지연 시간을 개선하세요 
+ 감사 및 규제 요구 사항 충족

재해 복구 옵션에는 [로그 전송](ec2-log-shipping.md), [Always On 가용성 그룹](ec2-always-on.md), [Amazon S3에 저장되고 리전 간에 복제되는 Amazon EBS 스냅샷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html), [Always On 가용성 그룹과 결합된 Always On 장애 조치 클러스터 인스턴스(FCIs)](ec2-fci.md) 및 분산 가용성 그룹이 포함됩니다. Amazon S3 AWS 

## 분산 가용성 그룹
<a name="ec2-distributed-groups"></a>

가용성 그룹이 분산된 아키텍처는 다중 리전 SQL Server 배포에 가장 적합한 접근 방식입니다. 분산 가용성 그룹은 두 개의 개별 가용성 그룹에 걸쳐 있는 특수한 유형의 가용성 그룹입니다. 가용성 그룹으로 구성된 가용성 그룹이라고 생각하시면 됩니다. 기본 가용성 그룹은 서로 다른 두 WSFC 클러스터에 구성됩니다.

분산 가용성 그룹은 느슨하게 결합되어 있으므로 단일 WSFC 클러스터가 필요하지 않고 SQL Server에서 유지 관리합니다. WSFC 클러스터는 개별적으로 유지 관리되고 전송은 주로 두 가용성 그룹 간에 비동기로 이루어지므로 다른 사이트에서 재해 복구를 구성하기가 더 쉽습니다. 각 가용성 그룹의 기본 복제본은 자체 보조 복제본을 동기화합니다.

분산 가용성 그룹은 현재 수동 장애 조치만 지원합니다. 데이터가 손실되지 않도록 글로벌 기본 데이터베이스, 즉 기본 가용성 그룹의 데이터베이스에서 모든 트랜잭션을 중지하세요. 그런 다음 분산 가용성 그룹을 동기 커밋으로 설정합니다.