실시간 고수준 참조 디자인
변경 제안
PDF
이 섹션에서는 Azure NetApp Files SMB 볼륨을 사용하는 AOAG 구성에서 SQL 데이터베이스 자산의 실시간 구축에 대해 설명합니다.
-
노드 수: 4
-
데이터베이스 수: 21
-
가용성 그룹 수: 4
-
백업 보존: 7일
-
백업 아카이브: 365일
|
Azure NetApp Files 공유를 통해 Azure 가상 시스템에서 SQL Server와 FCI를 배포하면 데이터의 단일 복사본을 통해 비용 효율적인 모델을 제공할 수 있습니다. 이 솔루션은 파일 경로가 보조 복제본과 다를 경우 추가 파일 작업 문제를 방지할 수 있습니다. |
다음 이미지는 노드에 분산된 AOAG 내의 데이터베이스를 보여 줍니다.
데이터 레이아웃
tempdb와 함께 사용자 데이터베이스 파일(.mdf) 및 사용자 데이터베이스 트랜잭션 로그 파일(.ldf)은 동일한 볼륨에 저장됩니다. 서비스 수준은 울트라입니다.
이 구성은 노드 4개와 AGS 4개로 구성됩니다. 21개의 데이터베이스(동적 AX, SharePoint, RDS 연결 브로커 및 인덱싱 서비스의 일부)는 모두 Azure NetApp Files 볼륨에 저장됩니다. 데이터베이스는 AOAG 노드 간에 균형을 이루어 노드의 리소스를 효과적으로 사용합니다. AOAG 구성에 참여하는 4개의 D32 v3 인스턴스가 WSFC에 추가됩니다. 이러한 4개 노드는 Azure 가상 네트워크에 프로비저닝되며 사내의 경우 마이그레이션되지 않습니다.
-
참고: *
-
응용 프로그램 및 실행된 쿼리의 특성에 따라 로그에 더 많은 성능 및 처리량이 필요한 경우 데이터베이스 파일을 프리미엄 서비스 수준에 배치하고 로그를 Ultra 서비스 수준에 저장할 수 있습니다.
-
tempdb 파일이 Azure NetApp Files에 배치된 경우 Azure NetApp Files 볼륨은 사용자 데이터베이스 파일과 분리되어야 합니다. 다음은 AOAG의 데이터베이스 파일 배포 예입니다.
-
참고: *
-
스냅샷 복사본 기반 데이터 보호의 이점을 유지하려면 동일한 볼륨에 데이터와 로그 데이터를 결합하지 않는 것이 좋습니다.
-
보조 데이터베이스의 파일 경로가 해당 기본 데이터베이스의 경로와 다른 경우 기본 복제본에 대해 수행되는 추가 파일 작업이 보조 데이터베이스에서 실패할 수 있습니다. 이 문제는 공유 경로가 운영 노드와 보조 노드에서 다른 경우(컴퓨터 계정이 서로 다르기 때문에) 발생할 수 있습니다. 이 실패로 인해 보조 데이터베이스가 일시 중단될 수 있습니다. 확장 또는 성능 패턴을 예측할 수 없고 나중에 파일을 추가하는 것이 계획이면 Azure NetApp Files를 사용하는 SQL Server 장애 조치 클러스터를 사용할 수 있습니다. 대부분의 구축 환경에서 Azure NetApp Files은 성능 요구사항을 충족합니다.
마이그레이션
온프레미스 SQL Server 사용자 데이터베이스를 Azure 가상 머신의 SQL Server로 마이그레이션하는 방법에는 여러 가지가 있습니다. 마이그레이션은 온라인 또는 오프라인일 수 있습니다. 선택한 옵션은 SQL Server 버전, 비즈니스 요구 사항 및 조직 내에서 정의된 SLA에 따라 다릅니다. 데이터베이스 마이그레이션 프로세스 중에 다운타임을 최소화하려면 AlwaysOn 옵션 또는 트랜잭션 복제 옵션을 사용하는 것이 좋습니다. 이러한 방법을 사용할 수 없는 경우 데이터베이스를 수동으로 마이그레이션할 수 있습니다.
시스템 간에 데이터베이스를 이동하는 가장 간단하고 철저한 테스트를 거친 접근 방식은 백업 및 복원입니다. 일반적으로 데이터베이스 백업 후 Azure로 데이터베이스 백업 복사본을 사용하여 시작할 수 있습니다. 그런 다음 데이터베이스를 복원할 수 있습니다. 최상의 데이터 전송 성능을 얻으려면 압축된 백업 파일을 사용하여 데이터베이스 파일을 Azure VM으로 마이그레이션합니다. 이 문서에서 참조되는 고급 설계에서는 Azure 파일 동기화를 사용하여 Azure 파일 저장소에 대한 백업 방식을 사용한 다음 Azure NetApp Files로 복원합니다.
|
|
Azure 마이그레이션을 사용하여 SQL Server 워크로드를 검색, 평가, 마이그레이션할 수 있습니다. |
마이그레이션을 수행하려면 다음 단계를 따르십시오.
-
요구 사항에 따라 연결을 설정합니다.
-
온-프레미스 파일 공유 위치에 전체 데이터베이스 백업을 수행합니다.
-
Azure 파일 동기화를 사용하여 Azure 파일 공유에 백업 파일을 복사합니다.
-
원하는 버전의 SQL Server로 VM을 프로비저닝합니다.
-
명령 프롬프트에서 "copy" 명령을 사용하여 백업 파일을 VM에 복사합니다.
-
전체 데이터베이스를 Azure 가상 머신의 SQL Server로 복구합니다.
|
|
21개 데이터베이스를 복원하는 데 약 9시간이 걸렸습니다. 이 접근 방식은 이 시나리오에만 적용됩니다. 그러나 아래 나열된 다른 마이그레이션 기술은 고객의 상황과 요구 사항에 따라 사용할 수 있습니다. |
온-프레미스 SQL Server에서 Azure NetApp Files로 데이터를 이동하는 기타 마이그레이션 옵션은 다음과 같습니다.
-
데이터와 로그 파일을 분리하고 Azure Blob 저장소에 복사한 다음 URL에서 ANF 파일 공유가 마운트된 Azure VM의 SQL Server에 연결합니다.
-
Always On Availability Group Deployment On-Premises를 사용하는 경우 를 사용합니다 "Azure 복제본 추가 마법사" 를 눌러 Azure에서 복제본을 생성한 다음 페일오버를 수행합니다.
-
SQL Server를 사용합니다 "트랜잭션 복제" Azure SQL Server 인스턴스를 구독자로 구성하려면 복제를 사용하지 않도록 설정하고 사용자를 Azure 데이터베이스 인스턴스로 지정합니다.
-
Windows 가져오기/내보내기 서비스를 사용하여 하드 드라이브를 배송합니다.
백업 및 복구
백업 및 복구는 모든 SQL Server 배포의 중요한 부분입니다. AOAG와 같은 고가용성 솔루션과 함께 다양한 데이터 장애 및 손실 시나리오에서 신속하게 복구할 수 있는 적절한 안전망을 갖추고 있어야 합니다. SQL Server 데이터베이스 정지 도구, Azure 백업(스트리밍) 또는 Commvault와 같은 타사 백업 도구를 사용하여 데이터베이스의 애플리케이션 정합성이 보장되는 백업을 수행할 수 있습니다.
Azure NetApp Files 스냅샷 기술을 사용하면 성능이나 네트워크 활용도에 영향을 주지 않고 사용자 데이터베이스의 시점(PiT) 복사본을 쉽게 생성할 수 있습니다. 또한 이 기술을 사용하면 스냅샷 복사본을 새 볼륨으로 복원하거나 복원 볼륨 기능을 사용하여 스냅샷 복사본이 생성된 시점의 상태로 빠르게 되돌릴 수 있습니다. Azure NetApp Files 스냅샷 프로세스는 매우 빠르고 효율적이므로 Azure 백업에서 제공되는 스트리밍 백업과 달리 매일 여러 번 백업할 수 있습니다. 특정 날짜에 여러 개의 Snapshot 복사본이 가능하므로 RPO 및 RTO 시간이 크게 줄어들 수 있습니다. 스냅샷 복사본을 생성하기 전에 데이터가 손상되지 않고 디스크에 적절히 플러시되도록 응용 프로그램 일관성을 추가하려면 SQL Server 데이터베이스 정지 도구를 사용합니다 ("SCSQLAPI 도구"; 이 링크에 액세스하려면 NetApp SSO 로그인 자격 증명이 필요합니다.) 이 툴은 PowerShell 내에서 실행할 수 있습니다. PowerShell은 SQL Server 데이터베이스를 중지시키고 애플리케이션 정합성이 보장되는 스토리지 Snapshot 복사본을 백업에 사용할 수 있도록 합니다.
-
참고: *
-
SCSQLAPI 도구는 2016 및 2017 버전의 SQL Server만 지원합니다.
-
SCSQLAPI 도구는 한 번에 하나의 데이터베이스에서만 작동합니다.
-
파일을 별도의 Azure NetApp Files 볼륨에 배치하여 각 데이터베이스에서 격리합니다.
SCSQL API의 방대한 제한으로 인해 "Azure 백업" SLA 요구사항을 충족하기 위해 데이터 보호에 사용되었습니다. Azure 가상 머신 및 Azure NetApp Files에서 실행되는 SQL Server의 스트림 기반 백업을 제공합니다. Azure Backup은 빈번한 로그 백업 및 최대 1초의 피트 복구를 통해 15분 RPO를 실현합니다.
모니터링
Azure NetApp Files는 Azure Monitor와 통합되어 시계열 데이터를 제공하며, 할당된 스토리지, 실제 스토리지 사용량, 볼륨 IOPS, 처리량, 디스크 읽기 바이트/초, 디스크 쓰기 바이트/초, 디스크 읽기/초 및 디스크 쓰기/초, 관련 지연 시간 이 데이터를 사용하여 경고 병목 현상을 식별하고 상태 점검을 수행하여 SQL Server 배포가 최적의 구성으로 실행되고 있는지 확인할 수 있습니다.
이 HLD에서 ScienceLogic은 적절한 서비스 보안 주체를 사용하여 메트릭을 노출하여 Azure NetApp Files를 모니터링하는 데 사용됩니다. 다음 그림은 Azure NetApp Files 메트릭 옵션의 예입니다.
일반 클론을 사용한 DevTest
Azure NetApp Files를 사용하면 응용 프로그램 개발 주기 동안 현재 데이터베이스 구조 및 콘텐츠를 사용하여 구현해야 하는 기능을 테스트하기 위해 데이터베이스의 즉각적인 복사본을 만들 수 있으며, 데이터 웨어하우스를 채울 때 데이터 추출 및 조작 도구를 사용할 수 있습니다. 실수로 삭제하거나 변경한 데이터를 복구할 수도 있습니다. 이 프로세스에서는 Azure Blob 컨테이너에서 데이터를 복사할 필요가 없어 매우 효율적입니다. 볼륨이 복원된 후 읽기/쓰기 작업에 사용할 수 있어 검증 및 출시 시간이 크게 단축됩니다. 이 기능은 애플리케이션 일관성을 위해 SCSQLAPI와 함께 사용해야 합니다. 이 접근 방식은 Azure NetApp Files와 함께 새로운 볼륨으로 복원 옵션을 활용하는 또 다른 연속 비용 최적화 기술을 제공합니다.
-
참고: *
-
새 볼륨 복원 옵션을 사용하여 스냅샷 복사본에서 생성된 볼륨은 용량 풀의 용량을 사용합니다.
-
REST 또는 Azure CLI를 사용하여 복제된 볼륨을 삭제하여 추가 비용을 방지할 수 있습니다(용량 풀을 늘려야 하는 경우).
하이브리드 스토리지 옵션
SQL Server 가용성 그룹의 모든 노드에 대해 동일한 스토리지를 사용하는 것이 권장되지만, 여러 스토리지 옵션을 사용할 수 있는 시나리오가 있습니다. 이 시나리오는 AOAG의 노드가 Azure NetApp Files SMB 파일 공유에 연결되어 있고 두 번째 노드가 Azure 프리미엄 디스크에 연결되어 있는 Azure NetApp Files에 대해 가능합니다. 이 경우 Azure NetApp Files SMB 공유가 사용자 데이터베이스의 기본 복사본을 갖고 있고 프리미엄 디스크가 보조 복사본으로 사용되는지 확인하십시오.
-
참고: *
-
이러한 구축에서 페일오버 문제를 방지하려면 SMB 볼륨에서 지속적인 가용성을 활성화해야 합니다. 지속적으로 사용 가능한 속성이 없으므로 스토리지 계층에 백그라운드 유지 관리가 있는 경우 데이터베이스에 장애가 발생할 수 있습니다.
-
데이터베이스의 기본 복사본을 Azure NetApp Files SMB 파일 공유에 유지합니다.
비즈니스 연속성
재해 복구는 일반적으로 모든 구현에서 나중에 고려해야 하는 사안입니다. 그러나 비즈니스에 영향을 주지 않도록 초기 설계 및 구축 단계에서 재해 복구를 해결해야 합니다. Azure NetApp Files를 사용하면 CRR(Cross-Region Replication) 기능을 사용하여 블록 레벨의 볼륨 데이터를 페어링된 영역으로 복제하여 예기치 않은 지역 운영 중단을 처리할 수 있습니다. CRR 지원 대상 볼륨을 읽기 작업에 사용할 수 있으므로 재해 복구 시뮬레이션에 적합합니다. 또한 CRR 대상을 가장 낮은 서비스 수준(예: 표준)으로 할당하여 전체 TCO를 줄일 수 있습니다. 페일오버 발생 시 복제를 깨고 각 볼륨을 읽기/쓰기 가능하게 만들 수 있습니다. 또한 동적 서비스 수준 기능을 사용하여 재해 복구 비용을 크게 줄여 볼륨의 서비스 수준을 변경할 수 있습니다. 이는 Azure 내에서 블록 복제를 사용하는 Azure NetApp Files의 또 다른 고유한 기능입니다.
장기적인 스냅샷 복사본 아카이브
많은 조직에서는 필수 규정 준수 요구 사항으로 데이터베이스 파일의 스냅샷 데이터를 장기간 보존해야 합니다. 이 프로세스는 HLD에서 사용되지 않지만 를 사용하여 간단한 배치 스크립트를 사용하여 쉽게 수행할 수 있습니다 "AzCopy" 를 눌러 Azure Blob 컨테이너에 스냅샷 디렉토리를 복사합니다. 예약된 작업을 사용하여 특정 일정에 따라 배치 스크립트를 트리거할 수 있습니다. 이 프로세스는 다음과 같은 단계로 구성되어 있습니다.
-
AzCopy V10 실행 파일을 다운로드합니다. exe 파일이기 때문에 설치할 것이 없습니다.
-
적절한 권한이 있는 컨테이너 수준에서 SAS 토큰을 사용하여 AzCopy에 권한을 부여합니다.
-
AzCopy가 승인된 후 데이터 전송이 시작됩니다.
-
참고: *
-
배치 파일에서 SAS 토큰에 나타나는 % 문자를 이스케이프해야 합니다. 이 작업은 SAS 토큰 문자열의 기존 % 문자 옆에 % 문자를 추가하여 수행할 수 있습니다.
-
를 클릭합니다 "보안 전송이 필요합니다" 저장소 계정 설정에 따라 저장소 계정에 대한 연결이 TLS(Transport Layer Security)로 보호되는지 여부가 결정됩니다. 이 설정은 기본적으로 사용됩니다. 다음 배치 스크립트 예제에서는 스냅샷 복사본 디렉토리에서 지정된 Blob 컨테이너로 데이터를 재귀적으로 복제합니다.
-
SET source="Z:\~snapshot" echo %source% SET dest="https://testanfacct.blob.core.windows.net/azcoptst?sp=racwdl&st=2020-10-21T18:41:35Z&se=2021-10-22T18:41:00Z&sv=2019-12-12&sr=c&sig=ZxRUJwFlLXgHS8As7HzXJOaDXXVJ7PxxIX3ACpx56XY%%3D" echo %dest%
다음 명령 예는 PowerShell에서 실행됩니다.
–recursive
INFO: Scanning... INFO: Any empty folders will not be processed, because source and/or destination doesn't have full folder support Job b3731dd8-da61-9441-7281-17a4db09ce30 has started Log file is located at: C:\Users\niyaz\.azcopy\b3731dd8-da61-9441-7281-17a4db09ce30.log 0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total, INFO: azcopy.exe: A newer version 10.10.0 is available to download 0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total, Job b3731dd8-da61-9441-7281-17a4db09ce30 summary Elapsed Time (Minutes): 0.0333 Number of File Transfers: 2 Number of Folder Property Transfers: 0 Total Number of Transfers: 2 Number of Transfers Completed: 2 Number of Transfers Failed: 0 Number of Transfers Skipped: 0 TotalBytesTransferred: 5 Final Job Status: Completed
-
참고: *
-
Azure NetApp Files에서는 장기 보존을 위한 유사한 백업 기능을 곧 사용할 수 있습니다.
-
배치 스크립트는 모든 영역의 Blob 컨테이너에 데이터를 복사해야 하는 모든 시나리오에서 사용할 수 있습니다.
비용 최적화
데이터베이스에 전혀 영향을 주지 않는 볼륨 재구성 및 동적 서비스 수준 변경을 통해 Azure NetApp Files은 Azure에서 지속적인 비용 최적화를 지원합니다. 이 HLD에서는 워크로드 폭증을 처리하기 위해 추가 스토리지의 오버 프로비저닝을 방지하기 위해 이 기능이 광범위하게 사용됩니다.
Azure 경고 로그와 함께 Azure 기능을 만들어 볼륨 크기를 쉽게 조정할 수 있습니다.