드라이브 대 마운트 포인트?

이전 Senior DBA는 회사 전체의 모든 SQL Server에서 모든 드라이브에 대한 마운트 지점을 설정했습니다. 새로운 Senior DBA 는 마운트 포인트 가 표준을 변경하기를 원한다는 사실에 충격을받습니다 .

수많은 인터넷 검색 결과에 따르면 마운트 지점을 사용하지 않는 (SQL Server 2000 이후) 이유를 찾을 수 없습니다.

누구든지이 주제에 관한 Windows OS 제한 사항을 알고 있습니까?

• 최근에 "OS가 마운트 포인트를 인식하지 못한다"는 주장을 듣고 있습니다. (우리가 사용하는 Windows Server 버전에 대한 연구 결과에 따르면 사실이 아닙니다).

SQL Server에서 탑재 지점을 사용하지 않는 증거 또는 경험 기반 이유가 있습니까?

• 드라이브 문자가 부족하면 문제가되지 않는다고 가정하십시오.

마운트 포인트는 워크로드를 분리하는 데 매우 유용하다는 것을 이해하고 있습니다.

마운트 포인트가 실제로 데이터 파일, 로그 파일 및 tempdb에 대해 각각 하나의 드라이브보다 여러 유형의 데이터 및 로그 파일 (시스템 데이터베이스 파일, 사용자 데이터베이스 파일, tempDB)의 워크로드를보다 효율적으로 분리 / 분리한다는 사실을 누구나 확인하거나 반박 할 수 있습니까? ?

마운트 포인트의 다른 끝에 무엇이 있는지에 따라 다릅니다. 마운트가 모두 LUN이 동일한 물리적 드라이브에 분산되어 있으면 이득이 없습니다. LUNS가 공유 된 느린 iSCSI 채널에있는 경우 이득이 없을 수 있습니다. LUNS가 모두 1 개의 컨트롤러 아래에 있다면 얼마나 많은 변수가 사용 중인지 알 수 있습니다. 답이 없습니다.

탑재 지점의 구성을 확인하려면 Boe Prox의 PowerShell 을 사용하여 탑재 지점 찾기를 참조하십시오 .

SQL Server 는 마운트 지점에 문제가 없습니다. 이들은 OS 수준에서 정의되며 SQL Server는 "알지 못합니다 " ¹ 마운트 된 드라이브와 동일한 볼륨이 아닙니다.

그러나 일부 모니터링 도구 는 마지막 문장을 기반으로 잘못된 정보를 제공 할 수 있습니다.

예를 들어 다음과 같은 3 개의 마운트 지점이있는 경우

1. C:\SQLData\SQL_Data 모든 .MDB 파일이 저장된 위치
2. C:\SQLData\SQL_Logs 모든 .LDF 파일이 저장된 위치
3. C:\SQLData\SQL_Backups 모든 .BAK 및 .TRN 백업 파일이 저장되는 위치

그런 다음 SQL Server는 아무런 문제없이 작동합니다. 그러나 디스크 공간이 부족할 때 경고하는 일종의 도구를 실행하면 디스크 아래에 마운트 된 볼륨이 아닌 C :를 검사 할 수 있으므로 해당 마운트 지점이 디스크 공간이 부족한시기를 알 수 없습니다. 또한 다양한 "모범 사례"쿼리는 SQL Server가 동일한 디스크에 있다고 생각 하기 때문에 데이터, 로그 및 백업이 모두 같은 디스크에 없어야한다는 잘못된 경고 를 발생시킵니다. 이들은 잘못된 플래그이며 무시할 수 있습니다.

그러나 기본적으로 서버 모니터링에서 C : 드라이브에 충분한 공간이 있고 각 마운트 지점이 있는지 확인하기 위해 몇 가지 추가 단계를 설정하려고합니다 .

SQL Server에서 탑재 지점을 사용한 시간은 내가 유일하게 겪었던 문제입니다. 사용 가능한 공간에 대한 잘못된 데이터를 제공하는 SQL Server 시스템 상태 보고서 및 모든 데이터를 가져서는 안된다는 잘못된 오류 같은 드라이브에. 이러한 오류가 잘못된 오류임을 알고 있으므로 무시하기 쉽습니다.

¹ SQL Server에는 탑재 지점을 인식 할 수있는 데이터가 있지만 실제 사용 관점에서는 동작에 차이가 없습니다. OS가 특정 사항을 처리하도록 신뢰하는 것은 "그냥 작동합니다". 로컬 드라이브로 연결된 iSCSI LUN의 세부 사항을 처리하기 위해 OS를 신뢰하는 것처럼.

CM_Dayton의 답변 과 Sean Gallardy의 답변 외에도 아직 마운트 포인트로 식별되지 않은 문제는 보안과 관련이 있습니다. 탑재 지점 폴더에 대한 SQL 권한 설정 지침 을 인용하려면 다음과 같이하십시오.

마운트 지점 루트 폴더는 일반 폴더처럼 보이고 폴더에 액세스하는 것과 같은 방식으로 액세스되지만 일반 폴더는 아닙니다. 결과적으로 마운트 지점 루트 폴더에 대한 권한을 설정하면 일반 폴더와 같은 방식으로 권한이 "상위 볼륨"에서 상속되지 않습니다. 실제로, 그들은 전혀 상속되지 않습니다. 마운트 된 볼륨이 "부모 볼륨"의 자식 인 것처럼 보이지만 그렇지 않습니다. “부모 볼륨”의 경로를 통해 마운트 된 볼륨에 액세스하는 것입니다.

간단히 말해서, 마운트 지점 루트 폴더를 사용하려면 마운트 폴더에 대한 권한을 다르게 지정해야합니다. 일반 폴더에서와 같이 권한을 할당하는 대신 볼륨에 대한 권한을 할당해야합니다. 다시, 같은 기사에서 (강조 표시는 Microsoft의 것입니다) :

잡았다

불행히도 여전히 Windows 탐색기를 통해 마운트 지점 루트 폴더에 대한 권한을 설정 /보기 할 수 있습니다. 마운트 지점 루트 폴더의 권한이 유효 해 보이고 "적절한"상속 된 권한을 볼 수 있기 때문에 예기치 않은 결과가 발생할 수 있습니다 그러나 이는 마운트 된 볼륨에 적용된 권한이 아닙니다.

• https://connect.microsoft.com/SQLServer/feedback/details/569895/installation-of-sql-server-2008-r2-on-mount-points-fails

지침

1. 마운트 지점 루트 폴더에 직접 파일 을 두지 않는 것이 좋습니다 . 이렇게하면 폴더 권한을 항상 확인하는 경향이 있기 때문에 권한 관리가 훨씬 간단 해집니다.이 경우에는 잘못된 것입니다. 대신 마운트 지점 루트 폴더 아래에 하위 폴더를 만들고 해당 하위 폴더에 대한 적절한 권한을 설정하십시오 . 하위 폴더는 일반 폴더이므로 관찰하고 설정 한 폴더 권한은 실제로 적용되는 권한입니다. 따라서 이전 예를 사용하여 새 폴더 D : \ FolderForVol3 ** SubfolderXYZ **를 작성하려고합니다. 이제 평소와 같이 새 SubfolderXYZ 폴더 에 대해 폴더 권한을 설정하십시오 .
2. 항목을 마운트 지점 루트 폴더에 직접 배치해야하는 경우 (권장 방법은 아님) 폴더 권한이 아닌 볼륨 권한을 설정해야합니다. 마운트 포인트 루트 폴더 권한이 마운트 된 볼륨에서 실제로 설정되는 권한이 아니기 때문입니다 (마운트 포인트 루트 폴더가 실제 폴더가 아니기 때문). 다음과 같이 볼륨 권한을 설정할 수 있습니다.
   • 시작-> 실행-> diskmgmt.msc (볼륨 http://technet.microsoft.com/en-us/library/cc740097.aspx 의 속성보기 )
   • 볼륨-> 속성-> 보안 탭을 선택하십시오.
3. SQL에서 사용할 새 폴더를 추가하는 경우 SQL 액세스에 필요한 권한을 알고 있어야합니다.
   • SQL Server 2012부터는 각 서비스에 대한 서비스 별 SID에 권한이 할당됩니다. http://msdn.microsoft.com/en-us/library/jj219062.aspx
   • Windows 서비스 계정 및 권한 구성 http://msdn.microsoft.com/en-us/library/ms143504.aspx

MS가 권장하는대로 마운트 지점 아래의 하위 폴더에 모든 것을 중첩하지 않으려면 권한을 가장 쉽게 할당하는 방법은 cacls.exe유틸리티를 사용하는 것입니다. 이에 대한 자세한 지침 은 Windows Server 2003에서 NTFS 파일 시스템 볼륨의 루트 디렉토리에 권한을 적용 할 수 없음 에서 찾을 수 있습니다 .

아직 완전히 해결 된 문제라고 생각하지 않습니다. 탑재 지점 권한 문제가있는 이 최신 질문 SQL Server FCI 설치 는 SQL Server 2016이 설치된 Windows 2012에서도 여전히 발생할 수 있음을 보여줍니다.

할당하려는 보안에 따라 명령이 다를 수 있지만 테스트는 성공의 열쇠이므로 라이브 마운트 포인트에 대해 명령을 실행하기 전에 명령에 익숙해 지므로 \E플래그 처럼 단순한 것을 잊어 버린 경우 보안을 신속하게 중단시킬 수 있습니다 .

수많은 인터넷 검색 결과에 따르면 마운트 지점을 사용하지 않는 (SQL Server 2000 이후) 이유를 찾을 수 없습니다.

주된 이유는 누군가가 그들과 함께 나쁜 경험을했거나 (또는 ​​반대로, 그들과 경험이 전혀 없음) 영원히 완전히 쫓아 버리기 때문입니다. 이것을 개인 취향이라고합니다.

이제이 있는 경우 이용하지 수있는 몇 가지 이유가. 내가 생각할 수있는 가장 큰 이유는 타사 드라이버 또는 응용 프로그램 / 도구 (필터 드라이버, 디스크 복제 등)가 지원하지 않기 때문입니다. 이에 대한 간단한 예는 특정 클러스터 크기 만 있고 특정 볼륨에 대해 2TB를 초과 할 수없는 NTFS 이외의 다른 것을 지원하지 않는 블록 수준 디스크 복제 도구입니다.

누구든지이 주제에 관한 Windows OS 제한 사항을 알고 있습니까?

아닙니다. 많은 마운트 포인트를 만들 수 있습니다. 사실, 일반적으로 Windows Server 내부에서 상당한 한계에 도달하기 전에 장치 인터페이스에 문제가 있습니다 (17 세 이상의 Windows Server 버전을 사용하지 않는 경우 ...).

• 요즘 "OS가 마운트 포인트를 인식하지 못한다"는 주장을 듣고 있습니다. (우리가 사용하는 Windows Server 버전에 대한 연구 결과에 따르면 사실이 아닙니다).

OS가 마운트 포인트를 인식하지 못하면 마운트 포인트를 어떻게 사용할 수 있습니까? 그건 말이되지 않습니다.

OS가 마운트 포인트를 인식하지 못하면 마운트 포인트를 추적하고 메타 데이터를 쿼리하는 이유는 무엇입니까? 또한 마운트 지점은 OS가 지원하거나 지원하지 않는 파일 시스템의 구성입니다. 모든 파일 시스템이 마운트 지점을 지원하지는 않지만 Windows Server에서 가장 일반적인 파일 시스템은 NTFS이며 실제로 마운트 지점을 지원 하며 잠시 동안 존재합니다.

이 사실이 아닌 아이템을 집으로 가져 오려면 Windows 클러스터링에는 실제로 볼륨에 대한 마운트 지점을 사용하는 CSV (Cluster Shared Volumes)라는 기술이 있습니다. 이는 기술을 사용하는 기본 항목입니다. 나는 당신에게 이것을 말한 사람이라면 누구나이 문제에 대해 교육을 받아야한다고 말해야합니다.

SQL Server에서 탑재 지점을 사용하지 않는 증거 또는 경험 기반 이유가 있습니까?

그렇습니다. Windows NT 4를 실행하는 서버는 항상 하나 있습니다. 사용하지 마십시오. 또한 지원되는 버전의 Windows Server를 실행하고 있고 최신 상태를 유지 하고 싶을 수도 있습니다 .

그러나 위에서 설명한 것처럼 지원되지 않거나 제대로 작동하지 않는 타사 항목이있을 수 있습니다. 해당 제공자를 삭제하고 새로운 제공자를 찾으십시오.

마운트 포인트는 워크로드를 분리하는 데 매우 유용하다는 것을 이해하고 있습니다.

마운트 포인트는 매우 유용합니다. 그것들을 사용하는 방법은 여러 가지가 있으며, 가장 일반적인 방법은 Windows의 드라이브 문자 제한을 극복하는 것입니다. 그 다음으로 가장 일반적으로 사용되는 것은 관리하기 어려운 작은 크기의 드라이브 (LUN, 가상 디스크 [VMDK, VHDX])를 사용하여 매우 크고 거의 관리 할 수없는 모노리스 볼륨을 피할 수 있도록하는 것입니다. 단일 LUN, 가상 디스크 등) 특히 구현이 가능한 사용량보다 적은 구 버전 NTFS의 경우 (예 : 구 버전의 Windows의 경우 최대 NTFS 크기는 2TB)

워크로드 분리는 또 다른 유용한 용도입니다. 당신은 확실히 알 수 있습니다, 많은 용도가 있으며 그것은 개인적인 사용 사례에 달려 있습니다. 모든 것이 마운트 포인트가되어야한다는 담요 선언과 같은 부적절한 사용법 도 있습니다. 그것은 그 시점에서 미친 관리 오버 헤드입니다.

탑재 지점은 응용 프로그램이 공유 된 서버 또는 일반적인 DZ 볼륨 이상의 데이터를 분할하기위한 방법입니다.

예를 들어 e:드라이브 에 하나의 응용 프로그램 데이터, 로그 및 임시 파일을 모두 설치할 수 있습니다 . E:/MP_1비즈니스 A에 대한 데이터 파일을 E:/MP_2보유하고 로그 E:/mp_3파일에 비즈니스 A에 대한 임시 파일을 보유 할 수 있습니다. 그런 다음 F:드라이브 의 마운트 지점에 비즈니스 B가 있습니다. 각 마운트 지점에는 고유 한 공간이 있습니다.

OS에는 MP에 전혀 문제가 없습니다. 클러스터 및 Always On은 MP에 문제가 없습니다. 나는 SQL 서버의 대부분을 MP에 설치 한 잘 알려진 은행에서 일했습니다. DBA가이를 사용하고 개념을 이해하면이를 필요로하는 상점에서보다 쉬운 솔루션으로 발전시킬 것입니다.

MP 루트에 아무것도 설치하지 않는 것으로 언급되었습니다. 맞아 그거야. MP 루트에는 D의 루트에 아무것도 설치하지 않는 것처럼 아무것도 없습니다.

Foglight, Guardiam, EMS 및 PBM과 같은 감사 및 모니터링 솔루션에도 탑재 지점에 문제가 없습니다.