대본:
- VMWare에서 실행되는 Exchange 2010 VM
- 데이터 120GB
- 실행 기간은 토요일 오전 12시~오전 8시(필요한 경우 약간 연장될 수 있음)
두 가지 액션으로 가득 찬 질문:
데이터 저장소를 마운트 해제하고, Exchange VM의 스냅샷을 만들고, C 및 D(데이터베이스) 드라이브의 드라이브 수준 조각 모음을 실행하고, 데이터 저장소를 다시 마운트하고 스냅샷을 제거하고 싶습니다(모든 것이 정상인 경우).
다른 옵션은 Exchange VM의 스냅샷 찍기, 데이터 저장소 마운트 해제, 오프라인으로 ESEUTIL 실행 및 C 드라이브 조각 모음(D 드라이브 아님), 데이터 저장소 다시 마운트 및 스냅샷 제거(모든 것이 정상인 경우)입니다.
당신의 생각은 무엇입니까? Exchange 서버 조각 모음/오류 검사에 올바른 접근 방식을 취하고 있습니까?
답변1
일반적인 경고 메시지를 만족시키기 위해 드라이브 + DB의 조각 모음을 수행하기 전에 몇 가지 작업을 수행합니다.
그것으로부터 무엇을 얻을 것으로 기대합니까? 사용자가 모두 Outlook 캐시 모드를 사용하는 경우 Exchange Server 조각화는 사용자와 크게 관련이 없습니다. Exchange에 충분한 RAM이 제공되면 각 사서함의 청크가 RAM에 저장되므로 디스크의 중요성이 줄어듭니다. Modern Exchange는 실제로 다음에서 실행되도록 설계되었습니다.더 느리게디스크와 이전 Exchange(2000/2003).
VM 내부 조각 모음은 여러분이 생각하는 것과 다릅니다. 실제 디스크와 교환 DB 사이에는 여러 수준의 추상화가 있습니다. 공유된 iSCSI 디스크 세트에서 LUN을 제공하는 RAID 세트가 있습니다. 해당 LUN이 실제 디스크에서 연속되어 있는지 어떻게 알 수 있습니까? 특히 씬 프로비저닝된 경우에는 그럴 것 같습니다. 그러면 VMWare에서 생성한 .vmdk 파일이 있는데, 이 파일 자체가 조각화되어 있을 가능성이 높습니다. 씬 프로비저닝을 했나요? 아니면 초기 생성 후 .vmdk 크기를 변경한 적이 있나요? iSCSI부터 시작하여 vmdk, 게스트 OS, Exchange까지 다양한 수준을 모두 거친다면 어떤 결과가 나올까요? 그렇다면 OWA가 더 빨라질 수도 있습니다.
요점은 가상 프로덕션 시스템이 조각 모음되어 실제로 사용자 경험이 개선되는 것을 본 적이 없다는 것입니다. 불가능하다고 말하는 것이 아닙니다... 단지 가능성이 낮다고 말하는 것뿐입니다.
VMWare VM 및 조각 모음에 대한 팁: http://blogs.vmware.com/vsphere/2011/09/should-i-defrag-my-guest-os.html
해당 링크에서 흥미로운 인용문 하나:
"VMware 내부적으로 SAN 또는 NAS 기반 데이터 저장소에 있는 게스트 OS의 조각 모음을 수행한 후에도 성능이 눈에 띄게 향상되지 않았다는 점을 지적하고 싶습니다."