Azure에서 SQL Server를 실행하기위한 저장소 고려 사항

Azure 또는 모든 클라우드 플랫폼에 SQL Server 배포? 오랜 기간 동안 사내 구축 환경에서 구축 한 것처럼 저장소를 프로비저닝하는 대신 Azure의 저장소를 사내 구축 환경에 액세스 할 수 있었던 저장소와 정확히 같지는 않습니다. 일부 전통적인 "모범 사례"는 추가 비용을 들여 최적의 성과를 내지 못할 수도 있습니다. 그러나 의도 한 이익을 제공하지는 않습니다. SQL Server 가상 컴퓨터의 Azure에 대한 성능 지침에서도 많은 논의를하고 있습니다.

디스크 유형

나는 여기에 UltraSSD, Premium Storage 또는 다른 디스크 유형을 사용해야한다고 말하지 않습니다. 옵션과 각 디스크 유형이 테이블에 가져 오는 것을 알고 있어야합니다. 물론 클라우드의 다른 모든 것과 마찬가지로 지출하는 돈이 많을수록 더 많은 전력, 속도, 처리량 등을 얻을 수 있습니다. 트릭은 스토리지 고려 사항에 적합한 최적의 구성을 찾는 것이므로 원하는 결과를 얻기에 충분할만큼의 시간을 소비합니다.

크기는 중요해

클라우드의 많은 것들과 마찬가지로 특정 사양이 함께 묶여 있습니다. 서버의 경우 더 많은 RAM을 원한다면 더 많은 CPU가 필요하지 않더라도 더 많은 CPU를 얻을 수 있습니다. 스토리지의 경우 IOPS, 처리량 및 크기가 모두 묶여 있습니다. 더 많은 IOPS를 원한다면 더 큰 디스크가 필요합니다. 더 많은 공간이 필요하면 더 많은 IOPS를 얻게됩니다. 물론 스토리지 클래스 간을 이동하여 어느 정도이를 피할 수 있지만 더 많은 IOPS가 필요하면 다른 스토리지 유형에서 더 많은 공간을 확보 할 수 있습니다. 가상 시스템 인스턴스의 크기도 중요합니다. 결국 저장소 구성과 관계없이 전체 처리량은 인스턴스 크기가 허용하는 범위 내에서 제한됩니다. 따라서 다시 한번 원하는 스토리지 성능을 달성하기 위해 필요한 것보다 많은 RAM과 CPU를 지불해야 할 수도 있습니다. 최대 IOPS 및 MBps 처리량에서 인스턴스 크기가 지원할 수있는 것이 무엇인지 이해하십시오. Azure에서는 인스턴스 크기가 스토리지 성능 문제로 인해 병목 현상이되는 경우가 많습니다.

RAID 0 사용

RAID 0은 전통적으로 스토리지 구성 옵션의 세 번째 요소입니다. 모든 RAID 옵션의 성능과 스토리지 활용도를 가장 잘 조합 할 수는 있지만 심각한 재해가 발생할 위험이 있습니다. RAID 0 스트라이프 세트의 하나의 디스크 만 실패하면 전체 스트라이프 세트가 실패합니다. 따라서 전통적으로 RAID 0은 데이터 손실이 허용되고 고성능이 바람직한 시나리오에서만 사용됩니다. 그러나 Azure 소프트웨어에서는 RAID 0이 바람직하며 많은 경우에 권장됩니다. Azure에서 RAID 0으로 어떻게 벗어날 수 있습니까? 대답은 쉽습니다. Azure 가상 머신 인스턴스에 표시하는 각 디스크는 이미 백엔드에 세 가지 중복성을 가지고 있습니다. 스트라이프 세트를 잃기 전에 여러 번 실패 할 필요가 있음을 의미합니다. RAID 0을 사용하면 여러 디스크를 결합 할 수 있습니다. 결합 된 스트라이프 세트의 전체 성능은 스트라이프 세트에 추가하는 각 추가 디스크에 대해 100 % 증가합니다. 따라서 예를 들어 10,000 IOPS의 요구 사항이있는 경우 Premium Storage가 P50으로 7,500 IOPS를 초과하므로 UltraSSD가 필요하다고 생각할 수 있습니다. 그러나 두 개의 P50을 RAID 0에 배치하면 최대 15,000 IOPS를 달성 할 수 있습니다. 이것은 많은 IOPS를 지원하는 Standard_F16s_v2 또는 이와 비슷한 크기의 인스턴스를 실행하고 있다고 가정합니다. Windows 2012 이상에서는 Simple Storage Space를 생성하여 RAID 0을 달성합니다. Windows Server 2008 R2에서 동적 디스크를 사용하여 RAID 0 스트라이프 볼륨을 생성 할 수 있습니다. 조심성있는 한마디. 로컬 스토리지 공간을 사용하고 DataKeeper를 사용하여 가용성 그룹 또는 SANless 장애 조치 클러스터 인스턴스를 구성하려는 경우 클러스터를 만들기 전에 스토리지를 구성하는 것이 가장 좋습니다. 그냥 알림. SQL Server 2008 R2 인스턴스를 Azure로 이동하는 데는 약 두 달 밖에 걸리지 않습니다. 높은 가용성을 보장하기 위해 Azure에 SQL Server 2008 R2 FCI를 배포하는 방법에 관한 저의 게시물을 확인하십시오.

로그 파일과 데이터 파일 분리하지 마라.

전통적으로 로그 및 데이터 파일은 서로 다른 실제 디스크에 상주합니다. 로그 파일에는 많은 쓰기 활동이 있고 데이터 파일에는 더 많은 읽기 활동이있는 경향이 있습니다. 따라서 때로는 스토리지가 이러한 특성을 기반으로 최적화됩니다. 또한 복구를 위해 로그와 데이터 파일을 다른 디스크에 보관하는 것이 바람직합니다. 적절한 백업 전략을 사용하여 데이터를 잃어 버리면 데이터 손실없이 데이터베이스를 복구 할 수 있습니다. 클라우드 기반 스토리지의 경우 단일 볼륨을 잃을 가능성이 매우 낮습니다. 이제 스토리지 고려 사항에 대해 생각하고 있습니다. 우연히 스토리지를 잃어 버렸다면 전체 스토리지 클러스터가 3 중 이중화와 함께 점심 식사를 먹었을 가능성이 큽니다. 따라서 로그를 E : logs에 넣고 F : data에 데이터를 넣는 것이 옳은 것처럼 느껴지지만 실제로는 스스로 해를 끼치고 있습니다. 예를 들어, 로그에는 P20을, 데이터에는 P20을 제공합니다. 각 볼륨의 크기는 512 GiB이고 2,300 IOPS로 제한됩니다. 로그 파일의 크기는 모두 필요하지 않을 수도 있습니다. 그러나 그것은 당신에게 당신의 데이터 파일을위한 성장의 여지가 충분하지 않을 수도 있습니다. 결국 여분의 공간을 위해 더 비싼 P30으로 이동해야합니다. 이 두 볼륨을 4,600 IOPS를 지원하는 멋진 1TB 볼륨으로 스트라이프하는 것이 훨씬 더 좋지 않습니까? 이렇게하면 로그 파일과 데이터 파일 모두 증가 된 IOPS를 이용할 수 있습니다. 또한 데이터 파일 용 P30 디스크로 이동하지 않아도 스토리지 활용도를 최적화하고 클라우드 스토리지 비용을 줄였습니다. 동일한 파일 및 파일 그룹을 보유합니다. 당신이하는 일에 대해 정말로 열심히 생각하십시오. 일단 클라우드로 이동하면 여전히 의미가 있는지 여부.  이해가되는 것은 과거에했던 일에 직관적이지 못할 수도 있습니다. 의심 스러울 때는 KISS 규칙 인 Keep It Simple Stupid를 따르십시오! 클라우드의 장점은 스토리지를 추가하거나 인스턴스 크기를 늘리거나 성능 대비 비용을 최적화하는 데 필요한 모든 작업을 수행 할 수 있다는 것입니다.

TempDB에 대해 수행 할 작업

로컬 SSD, 일명 D : 드라이브를 사용하십시오. D 드라이브는 tempdb에 가장 적합한 위치입니다. 로컬 드라이브이기 때문에 데이터는 "임시"로 간주됩니다. 서버가 이동되고 재부팅되면 손실 될 수 있음을 의미합니다. 괜찮아. Tempdb는 SQL이 시작될 때마다 재생성됩니다. 로컬 SSD는 빠르며 대기 시간이 짧습니다. 그러나 로컬이므로 읽기 및 쓰기가 인스턴스 크기의 전체 저장소 IOPS 제한에 기여하지 않습니다. 그래서 효과적으로 그것은 무료 IOPS입니다! 왜 우위를 차지하지 않겠습니까? SIOS DataKeeper를 사용하여 SANless SQL Server FCI를 구축하는 경우 미러링되지 않은 D 드라이브의 볼륨 리소스를 만들어야합니다. 이렇게하면 TempDB를 불필요하게 복제 할 필요가 없습니다.

마운트 포인트가 사용되지 않게 됨

탑재 지점은 SQL Server의 여러 인스턴스가 동일한 Windows 클러스터에 설치된 경우 SQL Server FCI 구성에서 일반적으로 사용됩니다. 이렇게하면 SQL Server 라이센스의 전체 비용이 절감됩니다. 서버 사용률을 높임으로써 비용을 절감 할 수 있습니다. 과거에 논의한 것처럼 일반적으로 각 SQL Server 인스턴스와 연결된 드라이브가 다섯 개 이상있을 수 있습니다. 각 드라이브가 드라이브 문자를 소비해야한다면 약 3 ~ 4 개의 인스턴스에서 문자가 부족합니다. 따라서 각 드라이브에 문자를주는 대신 마운트 지점을 사용하여 각 인스턴스가 단일 드라이브 문자 인 루트 드라이브로 서비스 될 수 있도록했습니다. 루트 드라이브에는 드라이브 문자가없는 별도의 물리적 디스크에 매핑되는 마운트 지점이 있습니다. 그러나 위에서 설명한 것처럼 개별 디스크를 많이 사용하는 개념은 클라우드에서 실제로 의미가 없습니다. 따라서 마운트 지점은 클라우드에서 쓸모 없게됩니다. 대신 설명 된대로 RAID 0 스트라이프를 만드십시오. 각 클러스터 된 인스턴스 SQL Server는 단순히 공간, 성능 및 비용에 맞게 최적화 된 고유 한 개별 볼륨을 갖습니다. 이것은 드라이브 문자가 부족한 문제를 해결합니다. 또한 클라우드 스토리지 비용을 줄이면서 스토리지 사용 및 성능을 훨씬 향상시킵니다.

결론

이 게시물은 점에서 벗어나 결정적인 가이드가 아닙니다. 이 게시물의 핵심은 Azure에서 SQL Server를 실행하는 것과 관련하여 클라우드 및 스토리지 고려 사항에 대해 다르게 생각하게하는 것입니다. 단순히 온 프레미스 (on-premise)에서 수행 한 작업을 클라우드에서 다시 생성하지 마십시오. 이는 거의 항상 최적의 성능보다 낮아지고 필요한 것보다 훨씬 많은 스토리지 비용을 초래합니다. Clusteringformeremortals.com의 허락을 받아 재현