다음을 통해 공유

Exchange 2010 LUN 아키텍처 이해

  • 아티클

마지막으로 수정된 항목: 2010-01-22

대부분의 경우 운영 체제에서 인식하는 실제 디스크 또는 최적의 LUN(논리 단위 번호)은 운영 체제에 디스크를 제공하는 데 사용되는 하드웨어에서 요약됩니다. LUN 아키텍처는 Microsoft Exchange Server 2010에서 사용됩니다.

Exchange 2010에서는 다양한 방식으로 LUN을 디자인할 수 있지만 LUN이 복잡해지지 않도록 다음과 같은 디자인 방식을 사용하는 것이 좋습니다.

  • 데이터베이스당 LUN 1개
  • 데이터베이스당 LUN 2개
  • 백업 세트당 LUN 2개

데이터베이스당 LUN 1개

데이터베이스당 LUN을 하나씩 구성하는 아키텍처에서는 데이터베이스와 해당 로그 파일이 모두 같은 LUN에 위치합니다. 데이터베이스당 LUN을 하나만 사용하는 LUN 아키텍처를 배포하려면 복사본이 2개 이상이고 하드웨어 기반 VSS(볼륨 섀도 복사본 서비스) 솔루션을 사용하지 않는 DAG(데이터베이스 가용성 그룹)이 필요합니다.

이 전략을 사용하는 경우의 몇 가지 이점은 다음과 같습니다.

  • 관리할 LUN 수가 줄어들어 저장소 관리가 간편해집니다.
  • 백업 작업의 수도 줄일 수 있습니다.
  • LUN 간에 스핀들을 공유하지 않는 경우 데이터베이스 간의 성능을 유동적으로 격리할 수 있습니다.

이 전략과 관련한 문제점은 하드웨어 기반 VSS 백업 및 복원 절차(예: 스냅숏 복제)를 수행하는 기능을 제한한다는 점입니다. VSS에 대한 자세한 내용은 Exchange Server 2003의 볼륨 섀도 복사본 서비스 사용에 대한 모범 사례를 참조하십시오.

맨 위로 이동

데이터베이스당 LUN 2개

Exchange 2010을 사용하는 경우 최대 100개의 데이터베이스가 있으면 제공해야 하는 LUN의 수는 백업 전략에 따라 달라집니다. 복구 시간 목표가 낮거나 빠른 복구를 위해 VSS 복제본을 사용하는 경우에는 각 데이터베이스를 고유한 트랜잭션 로그 LUN 및 데이터베이스 LUN에 배치하는 것이 좋습니다. 이렇게 하면 사용 가능한 드라이브 문자 수가 초과되어 볼륨 탑재 지점을 사용해야 하기 때문입니다.

이 전략을 사용하는 경우의 몇 가지 이점은 다음과 같습니다.

  • 하드웨어 기반 VSS를 데이터베이스 수준에서 사용할 수 있으므로 단일 데이터베이스 백업 및 복원을 수행할 수 있습니다.
  • LUN 간에 스핀들을 공유하지 않는 경우 데이터베이스 간의 성능을 유동적으로 격리할 수 있습니다.
  • 단일 LUN에서 발생하는 용량 또는 손상 문제가 하나의 데이터베이스에만 영향을 주기 때문에 안정성을 높일 수 있습니다. 기본 제공 사서함 복구 기능을 활용하지 않는 경우 이는 매우 중요한 고려 사항입니다.

이 전략을 사용하는 경우의 몇 가지 문제점은 다음과 같습니다.

  • 100개의 데이터베이스에 200개의 LUN이 필요하기 때문에 일부 저장소 배열 최대값을 초과할 수 있습니다.
  • 각 데이터베이스에 별도의 LUN을 지정하면 서버당 더 많은 LUN이 필요하므로 관리 비용 및 복잡성이 증가합니다.

맨 위로 이동

백업 세트당 LUN 2개

백업 집합은 야간에 전체 백업되는 여러 데이터베이스의 집합입니다. 데이터베이스의 1/7 분량에 대해 야간에 전체 백업을 수행하는 솔루션(예: 매일 증분 또는 차등 백업을 수행하고 주 단위 또는 격월로 전체 백업 사용)을 사용하면 백업할 모든 데이터베이스를 동일한 로그 및 데이터베이스 LUN에 배치하여 복잡도를 낮출 수 있습니다. 또한 이렇게 하면 서버의 LUN 수도 줄일 수 있습니다.

이 전략을 사용하는 경우의 몇 가지 이점은 다음과 같습니다.

  • 관리할 LUN 수가 줄어들어 저장소 관리가 간편해집니다.
  • 백업 작업의 수도 줄일 수 있습니다.

이 전략을 사용하는 경우의 몇 가지 문제점은 다음과 같습니다.

맨 위로 이동