최근 네트워크 및 시스템 팀과 SQL 파일을 다른 SAN LUN에 배치하는 방법에 대해 논의했습니다. 그들은 이제 SAN EMC 관리 프로세스로 인해 SQL 파일 (데이터/로그/Lob/인덱스/백업, 특히 TLog)을 다른 스핀들이있는 별도의 드라이브에 넣을 시간과 노력을 낭비하고 있다고 생각했습니다. 자,이 토론에 대한 귀하의 아이디어와 비전에 참여하고 진술하여 저를 도울 수 있습니까?SAN에 SQL 파일 배치
본인의 SAN 관리자와 동의하는 경향이 있습니다. 오늘날 대부분의 SAN은 RAID-10 또는 유사한 기술을 실행하고 있으며, 많은 드라이브에 걸쳐 있고 매우 높은 IOPS를 처리합니다. SQL Server 데이터 및 로그에 대해 스핀들을 물리적으로 분리하면 적은 수의 드라이브와 낮은 IOPS 기능으로 로컬 스토리지 시대로 돌아갑니다.
그래서 스케일링 용도로만 SQL 데이터를 별도의 LUN에 배치 할 가치가 있습니다. LUN을 여러 파일 시스템으로 분할하지 마십시오. 파괴 된 도로를 보았습니다.
다른 실제 스핀들에 다른 볼륨 넣기 - 이는 많은 요인에 따라 달라집니다.
작업량, OLTP 또는 OLAP (트랜잭션 또는 분석)이란 무엇입니까? 스토리지 배열이란 무엇입니까? 기존 RAID (LUN이 RAID 그룹에 있습니까?) 또는 가상화 된 프로비저닝 (RAID 그룹 (예 : VNX, VMAX, Unity)의 "익스텐트"풀에있는 LUN)입니까? 씬 프로비저닝을 사용하고 있습니까? 규모를 어떻게 조정 하시겠습니까?
현재 저장 장치에 어떤 작업 부하가 걸리고 있는지 측정하십시오. IOPS는 물론 IO 블록 크기도 측정합니다. IOPS 만 의미가 없으므로 볼륨 배치를 결정하기 위해 IO 작업의 크기를 알고 싶습니다. 기존 기술 또는 가상 기술을 사용하여 어떤 기술을 사용하고 있는지 확인하십시오. 최고의 성능 측정 수단으로 대기 시간을 사용하십시오.
이렇게하면 시작한 스토리지 담당자와 대화해야합니다.
https://www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-shared-drives/ – manderson