다음을 통해 공유


고가용성 전략

 

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2007-08-31

이 항목에서는 Microsoft Exchange Server 2007의 고가용성에 대한 전반적인 개요를 제공하며 사용자의 조직에 적합한 가용성 솔루션을 선택하기 위한 권장 결정 프로세스에 대해서도 소개합니다.

가용성고가용성은 이 용어가 사용되는 컨텍스트와 관련된 사용자에 따라 매우 다른 의미를 지닐 수 있습니다. 이 용어들은 전반적으로 하드웨어만의 가용성 대상부터 메시징 서비스의 중요한 대상에 이르기까지의 다양한 업무 목표와 기술 요구 사항을 설명합니다.

일반적으로 조직에서 가용성 대상과 관련하여 잘못된 기대를 할 수 있습니다. 또한 조직에서 비용적 측면을 파악하기 전에 실제 지불하려는 비용에 비해 높은 수준의 가용성을 요구할 수도 있습니다.

대부분의 가용성 솔루션의 비용 측면에는 다음과 같은 요소가 포함되며 그 외에도 다양한 요소가 있을 수 있습니다.

  • 하드웨어

  • 소프트웨어

  • 네트워크 인프라

  • 교육

  • 편리성

  • 작업 비용

편리성은 정보 기술 서비스 또는 구성 요소를 제공하고 유지 관리하기 위해 타사 서비스 공급자와 맺은 계약 합의 사항 또는 조직 내의 정보 기술 부서와 맺은 작업 계약을 의미합니다.

가용성

가용성은 응용 프로그램, 서비스 또는 시스템에서 제공하는 서비스 수준을 의미합니다. 고가용성 시스템에서는 계획되거나 계획되지 않은 중지 시간이 최소화됩니다. 가용성은 대개 서비스 또는 시스템을 사용할 수 있는 시간의 백분율로 표시됩니다. 예를 들어, 일년에 8.75시간 동안 사용할 수 없는 서비스의 경우는 99.9%로 표시됩니다.

가용성을 높이려면 내결함성 메커니즘을 구현함으로써 서비스의 종속성 및 구성 요소의 장애에 따른 영향을 차단하거나 최소화해야 합니다. 내결함성은 오류 구성 요소의 단일 지점에 대해 중복성을 구현함으로써 이루어집니다.

Microsoft Exchange 가용성을 계획할 때는 메시징 인프라의 일부인 모든 구성 요소를 고려합니다. 일부 구성 요소는 하위 구성 요소가 있는 다른 서비스일 수도 있습니다. 메시징 서비스 가용성은 인프라의 일부인 각 구성 요소의 가용성에 의해 결정됩니다.

가용성 요구 사항 정의

서비스의 가용성은 많은 부문을 고려해야 합니다. 다양한 접근 방법을 실시하여 필요한 가용성 수준을 제공할 수 있으며 각각의 방법에는 자체적인 비용 측면이 있습니다.

그러나 가용성 요구 사항은 이러한 측면을 완전히 파악하지 못하고 고객에 의해 비교적 단순한 조건으로 표현되는 경우가 많습니다. 이러한 상황으로 고객과 정보 기술 조직 사이에 오해가 발생하게 되고 투자 수준이 부적절해지며 결국에는 잘못된 기대감을 가진 탓에 고객의 불만으로 이어지게 될 수 있습니다.

하나의 99.5% 가용성 요구 사항은 다른 99.5% 가용성 요구 사항과 다를 수 있습니다. 하나의 요구 사항은 하드웨어 플랫폼만의 가용성을 말하지만 다른 요구 사항은 전체 종단 간 서비스의 가용성을 말할 수 있습니다. 전체 종단 간 서비스 가용성에 대한 정의인 경우에도 큰 차이가 있습니다. 가용성 요구 사항을 측정하는 방법을 정확히 파악하는 것이 중요합니다. 예를 들면 다음과 같습니다.

  • 기본 서버의 모든 하드웨어와 소프트웨어가 정상적으로 작동하며 응용 프로그램에서 사용자 연결을 받아들일 준비가 되어 있다면 이러한 솔루션을 100% 가용성이 있다고 생각할 수 있습니까?

  • 100명의 사용자가 있지만 이들 중 25%가 로컬 네트워크 장애로 인해 연결되지 않는다면 그래도 이러한 솔루션을 100% 가용성이 있다고 생각할 수 있습니까?

  • 100명의 사용자 중에서 단 한 명의 사용자만 연결하여 작업을 처리할 수 있다면 이러한 솔루션을 단 1% 가용성이 있다고 생각할 수 있습니까?

  • 100명의 사용자가 모두 연결은 되지만 서비스 품질 저하로 3개의 고객 트랜잭션 중 2개만 사용할 수 있거나 성능이 좋지 않다면 이러한 경우 가용성 측정에 어떻게 영향을 줍니까?

가용성을 측정하는 기간도 가용성의 정의에 상당한 영향을 줄 수 있습니다. 연간 99.9% 가용성 요구 사항에서는 중지 시간을 8.75시간까지 허용합니다. 월간 99.9% 가용성 요구 사항에서는 월별 중지 시간을 40분씩만 허용합니다.

계획된 유지 관리 작업, 서비스 팩 업데이트 및 소프트웨어 업데이트를 위한 중지 시간도 식별하고 조정해야 합니다. 가능한 계획된 중지 시간의 양은 가용성 요구 사항의 정의에 상당한 영향을 줍니다.

RTM 버전의 Microsoft Exchange Server 2007에는 비용을 절감하고 가동 시간을 늘릴 수 있는 새로운 기능이 포함되어 있습니다.

  • 로컬 연속 복제   LCR(로컬 연속 복제)은 기본 제공되는 기술을 사용하여 프로덕션 저장소 그룹과 동일한 서버에 연결된 보조 디스크 세트에 저장소 그룹의 복사본을 만들어서 유지 관리하기 위한 단일 서버 솔루션입니다. LCR은 비동기 로그 전달, 로그 재생 및 데이터 복사본으로의 빠른 수동 전환을 제공합니다. LCR에 대한 자세한 내용은 로컬 연속 복제를 참조하십시오.

  • 클러스터 연속 복제   CCR(클러스터 연속 복제)은 Exchange 2007의 복제 및 재생 기능을 Microsoft 클러스터 서비스의 장애 조치 기능과 결합합니다. CCR은 단일 데이터 센터 또는 두 데이터 센터 사이에서 단일 지점 오류 없이 배포할 수 있는 솔루션입니다. CCR에 대한 자세한 내용은 클러스터 연속 복제를 참조하십시오. CCR은 이전 Exchange Server 버전의 클러스터링 및 Exchange 2007의 단일 복사본 클러스터에 비해 몇 가지 장점을 제공합니다. 이러한 장점에 대한 자세한 내용은 단일 복사본 클러스터와 비교하여 클러스터 연속 복제의 이점을 참조하십시오.

  • 단일 복사본 클러스터   이전 Exchange Server 버전에서 공유 저장소 클러스터라고 하던 SCC(단일 복사본 클러스터)가 일부 크게 변경되고 개선되어 Exchange 2007에서 제공됩니다. SCC에 대한 자세한 내용은 단일 복사본 클러스터를 참조하십시오.

Microsoft Exchange Server 2007 SP1(서비스 팩 1)에는 사이트 복원을 위한 추가 기능이 포함되어 있습니다.

  • 대기 연속 복제   SCR(대기 연속 복제)은 Exchange 2007 SP1에 도입된 새로운 기능입니다. 이름이 암시하듯이 SCR은 대기 복구 서버를 사용하는 시나리오를 위해 설계되었습니다. SCR은 기존의 연속 복제 기능을 확장하여 Exchange 2007 사서함 서버에 새로운 데이터 가용성 시나리오를 사용할 수 있도록 합니다. SCR에서는 LCR 및 CCR과 동일한 로그 전달 및 재생 기술을 사용하여 추가 배포 옵션 및 구성을 제공합니다. SCR을 사용하면 독립 실행형 사서함 서버 및 클러스터된 사서함 서버의 데이터를 복제할 수 있습니다. SCR에 대한 자세한 내용은 대기 연속 복제를 참조하십시오.

이러한 기능은 다양한 가용성 요구 사항에 맞는 향상된 복구 성능을 제공합니다. 다음 표에서는 다양한 가용성 요구 사항을 보여주며, Exchange 2007 솔루션과 Exchange Server 2003에 있는 재해 복구 솔루션에 대한 비교 정보를 제공합니다. Exchange 2007의 고가용성 구성에 대한 자세한 내용은 고가용성 배포을 참조하십시오.

가용성 요구 사항에 따른 고가용성 솔루션 비교

가용성 요구 사항 Exchange 2003 솔루션 Exchange 2007 RTM 솔루션 Exchange 2007 SP1 솔루션

장기 보관

일일 전체 백업. 동일하게 다시 구축된 서버로 백업 복원.

주간 전체 백업 및 일일 증분 백업. 서버로 백업 복원.

주간 전체 백업 및 일일 증분 백업. 서버로 백업 복원.

사용자 오류에 대한 응답

7일 폐기 기본값. 7일 후 동일하게 다시 구축된 서버에 백업 복원.

14일 폐기 기본값. 14일 후 서버로 백업 복원.

14일 폐기 기본값. 14일 후 서버로 백업 복원.

오류에 대한 복구:

  • 디스크

  • 하드웨어

  • 공유 저장소

동일하게 다시 구축된 서버로 백업 복원.

연속 복제. 복원 필요 없음.

독립 장애 또는 CCR 이중 장애: 데이터베이스 이식성 또는 대체 위치에서의 발신음.

연속 복제. 복원 필요 없음.

독립 장애 또는 CCR 이중 장애: 데이터베이스 이식성 또는 대체 위치에서의 발신음.

사이트 전체 재해에 대한 복구

동일하게 다시 구축된 서버로 백업 복원.

보조 사이트에 연속 복제. 복원 필요 없음.

독립 장애 또는 CCR 이중 장애: 데이터베이스 이식성 또는 대체 위치에서의 발신음.

보조 사이트에 대기 연속 복제. 복원 필요 없음.

데이터베이스 이식성 또는 대기 서버 활성화.

적합한 가용성 솔루션 선택

몇 가지 구성을 사용해 Exchange 2007 배포의 가용성을 향상시킬 수 있습니다. 올바른 가용성 솔루션을 선택하기 위해서는 선택한 옵션 집합을 분석하여 비즈니스 목표 및 가용성 요구에 가장 적합한 솔루션을 결정해야 합니다. 이를 위한 한 가지 방법은 각 오류 유형에 대한 섹션을 포함하는 테이블을 작성하는 것입니다. 테이블의 각 섹션에 오류의 가용성 요구 사항과 일치하는 복구 전략을 제공하는 각 솔루션을 나타내는 행을 포함시킵니다. 열에는 솔루션의 중요 요소를 기록합니다. 일반적인 요소는 다음과 같습니다.

  • 복구 시간

  • 복구가 데이터에 미치는 영향

  • 관련 하드웨어 및 소프트웨어 비용

  • 관련 리소스 비용

  • 이벤트 발생 가능성

  • 비즈니스에 미치는 영향

  • 복잡성 위험

  • 타사 솔루션

  • 장점

  • 단점

이러한 테이블을 완성한 후에 비용 분석을 위한 몇 가지 솔루션을 선택합니다. 선택한 각 솔루션에 대해 사서함별 예상 비용을 산정해야 합니다. 이 경우도 테이블로 나타낼 수 있습니다. 비용 테이블에는 각 솔루션이 비즈니스 목표 달성을 위해 특징적으로 제공하는 이점을 설명하는 행을 포함시킵니다. 몇 가지 선택에 대해 평가해야 합니다. 요구 사항에 적합하지만 조직에서 일반적으로 사용하던 솔루션과는 다른 솔루션을 하나 이상 선택합니다.

마지막으로 비즈니스 목표, 가용성 요구 사항, 가능한 솔루션 및 비용 분석 결과를 검토하여 솔루션을 선택하십시오. 이 과정 중에 올바른 결정을 내리기 위해 고려해야 할 요인은 다음과 같습니다.

  • 우선 순위가 지정된 비즈니스 목표 다양한 목표가 서로 충돌할 수 있으므로 우선 순위를 정하는 일은 중요합니다.

  • 더 이상 적용할 수 없는 기존의 사실 거부 설계 및 평가 단계 중에 Exchange 2007의 모든 잠재적 능력을 활용합니다. 경험에 비추어 볼 때 가장 비용 효과적인 솔루션은 백업, 저장 및 운영에 대한 새로운 접근 방식을 통해 구현될 수 있습니다.

  • 메시징 시스템의 단일 지점에서의 오류 발생 검사   단일 SAN(저장소 영역 네트워크)에 저장된 사서함 데이터의 단일 복사본은 데이터가 오류나 손상에 대해 완전히 보호되지 않음을 의미합니다. 이러한 데이터의 단일 복사본에는 SAN에서 제공되는 중복의 양과 상관 없이 오류나 손상이 발생되는 몇 가지 방식이 있습니다. SCC를 사용할 경우 SAN 오류로 인해 서비스는 몇 시간의 데이터 손실이나 며칠 간의 작업 중단을 경험할 수 있습니다. CCR은 한 서버에서 오류가 발생할 때 일부 데이터 손실을 가져올 수 있으나 두 개의 데이터 복사본을 유지 관리하는 가용성 솔루션입니다. CCR에서는 전송 쓰레기 수거통이라는 허브 전송 서버 기능을 사용하여, 서버에 오류가 발생했을 때 대부분의 데이터 손실을 막을 수 있습니다. 따라서 대부분의 오류 상황에서 사서함 데이터가 보존됩니다.

  • 각 솔루션에서 사용할 수 있는 다양한 저장소 옵션 활용 CCR은 조직에서 직접 연결 저장소와 같은 보다 다양한 저장소 솔루션을 사용할 수 있도록 합니다. CCR은 관련된 복잡성 및 비용을 줄이는 SAN 패브릭을 요구하지 않습니다. 따라서 SAN이나 저가 저장소 솔루션의 직접 연결 저장소를 보다 쉽게 배포하고 운영할 수 있습니다.

  • CCR 및 LCR을 사용하여 일반적으로 매일 수행하는 전체 백업에서 덜 자주 수행되는 전체 백업 및 일일 증분 전략으로 백업 전략을 변경할 수 있음 CCR 및 LCR은 최초 오류에서의 복구에 대해 더 짧은 SLA(서비스 수준 계약)도 지원할 수 있습니다. 이중 오류(복사 오류 또는 손상)에서의 복구에 대한 SLA를 현재 복원 SLA보다 더 늘려야 할 수 있습니다. 일반적으로 백업 비용이 TCO(총 소유 비용)의 주요 구성 요소이므로 이와 같이 변경하면 TCO를 획기적으로 절감할 수 있습니다. 또한 디스크 기반 백업 전략으로 전환해도 백업 비용을 줄일 수 있습니다.

  • 솔루션을 만들기 위해 Exchange 2007의 연속 복제 기술 사용에 대해 조사   CCR에서는 타사 복제 기술이 필요하지 않습니다. 현재 CCR은 각 노드에 하나의 데이터 복사본이 유지되는 2노드 클러스터를 지원합니다. 이 기술을 사용한 사이트 복원 솔루션의 이점은 다음과 같습니다.

    • 백업 데이터 센터의 사서함 데이터를 클라이언트에서 사용할 수 있습니다.

    • 연속 복제는 대부분의 타사 솔루션보다 더 적은 양의 데이터를 이동시킵니다.

    • 사이트 복원 솔루션을 만들기 위해 필요한 통합 작업이 더 적습니다.

  • 다양한 옵션과 연관된 비용 및 복구 작업을 확인할 수 있는 테이블 만들기   비용 테이블의 경우 기존 방식보다 나은 몇 가지 옵션을 포함하는지 확인하십시오. 테이블의 팩트를 사용하여 다음과 같은 솔루션을 만듭니다.

    • 비즈니스 요구 사항에 가장 적합한 솔루션을 제공합니다.

    • 비용 요구 사항을 만족시킵니다.

    • 조직에서 지원할 수 있는 배포 및 운영 복잡성 수준을 나타냅니다.

기본 제품 및 구성 요소

제품 및 구성 요소의 배포는 엄격한 가용성 및 안정성 요구 사항을 충족하는 기능에 기반을 두어야 합니다. 이러한 요구 사항은 가용성 설계 시 반드시 고려되어야 합니다. 이러한 기본 제품 및 구성 요소가 신뢰할 수 없고 기본 제품 및 구성 요소에 오류가 발생하기 쉬운 경우에는 더 높은 수준의 가용성을 얻는 데 필요한 추가 투자가 낭비되고 가용성의 수준은 충족되지 않습니다.

서비스 관리 프로세스

효과적인 서비스 관리 프로세스를 통해 더 높은 수준의 가용성을 얻을 수 있습니다. 가용성 관리, 사고 관리, 문제 관리 및 변경 관리와 같은 프로세스는 메시징 서비스의 전체적인 관리에서 중요한 역할을 수행합니다.

시스템 관리

시스템 관리에서는 모니터링, 진단 및 자동화된 오류 복구를 제공해야 하며 이를 통해 잠재적 및 실제 오류를 빨리 감지하고 해결할 수 있습니다.

전체 중복을 사용한 특별 해결책

100퍼센트 범위의 가용성에 지속적으로 도달하려면 전체 중복이 통합된 값비싼 솔루션이 필요합니다. 중복은 복제 구성 요소를 사용하여 가용성을 향상시키는 기술입니다. 엄격한 가용성 요구 사항을 충족시켜야 하는 경우 이러한 구성 요소는 동시에 자율적으로 작동되어야 합니다.

가용성 목표 및 SLA 요구 사항 설정

높은 수준의 가용성을 얻으려면 먼저 좋은 품질의 제품과 구성 요소를 사용해야 합니다. 그러나 이러한 제품 및 구성 요소만으로는 필요한 수준의 지속적으로 유지되는 고가용성을 전달하기 어렵습니다. 개발 초기 단계의 설계 과정에서는 가용성 목표를 고려해야 합니다. 이러한 접근 방법을 통해 재작업과 관련된 비용의 증가, 요구되는 가용성을 충족시키는 데 필요한 계획되지 않은 업그레이드, 인프라를 모니터링하기 위한 계획되지 않은 도구 그리고 인프라, 유지 관리, 서비스 측면에서 단일 지점에서의 오류 발생을 피하기 위한 계획되지 않은 비용 발생의 가능성을 방지할 수 있습니다.

고가용성을 얻기 위한 첫 번째 단계 중 하나는 조직에 설정되어 있는 SLA에 대해 검토하는 것입니다. SLA를 설정한 후 해당 계약에 가장 적합한 Exchange 2007 배포 및 서버 구성을 결정할 수 있습니다.

다음은 재해 복구와 관련된 고가용성을 위한 주요 고려 사항입니다.

  • 허용되는 가동 중지 시간   Exchange 서비스 가용성에 대한 조직의 정의에 기초하여 조직에 허용되는 최대 가동 중지 시간을 고려합니다. 가동 중지 시간에 대한 조직의 정의에 따라 메시징 발신음 복구 전략을 사용하여 조직의 SLA를 충족할 수 있습니다. 메시징 발신음 복구 전략은 임시 사서함을 사용자에게 제공하여 재해 뒤에 전자 메일 메시지를 즉시 주고받을 수 있도록 합니다. 이 전략은 기록 사서함 데이터를 복구하기 전에 전자 메일 서비스를 신속하게 복원합니다. 대개 최종적으로 기록 및 임시 사서함 데이터를 병합하여 복구가 완료됩니다.

  • 허용되는 복구 시간   각 유형의 재해 복구 작업에 허용되는 최대 시간을 고려합니다. 예를 들어 사서함, 단일 데이터베이스 또는 Exchange 2007을 실행하는 전체 서버를 복구하는 데 걸리는 대략적인 기간을 지정해야 합니다.

  • 데이터 손실 허용 범위   Exchange 데이터의 임시 또는 영구 손실에 대한 조직에서의 허용 범위를 고려합니다. 예를 들어 사용자가 4시간 내에 메시지를 주고받을 수 있는 경우에 한하여 이전 백업부터 24시간 동안 사서함 데이터의 일시적인 손실을 조직에서 허용할 수 있습니다. 다른 경우에는 모든 Exchange 데이터를 오류가 발생한 시점부터 4시간 내에 복원하도록 요구하는 것처럼 더 엄격한 요구 사항을 고려할 수 있습니다.

조직에 대한 가동 중지 시간의 영향을 고려하고 메시징 환경에서 달성하려는 작동 시간 수준을 결정한 후에 SLA를 설정한 준비가 됩니다. SLA 요구 사항은 스토리지, 클러스터링, 백업 및 복구와 같은 구성 요소가 조직에서 포함되는 방법을 결정합니다.

SLA를 평가할 때는 먼저 일반 작업의 시간과 계획된 가동 중지 시간에 대한 기대치를 식별해야 합니다. 그런 다음 메시지 배달 시간, 서버 작동 시간 백분율, 필요한 저장소 공간, Exchange 데이터베이스를 복구하는 데 걸리는 시간 등을 비롯한 가용성, 성능 및 복구 기능에 대한 회사의 기대치를 확인해야 합니다.

또한 계획되지 않은 가동 중지 시간의 예상 비용을 식별하여 적절한 양의 내결함성을 메시징 시스템에서 사용해야 합니다.

Exchange 2007 및 Windows Server 2003의 기능은 SLA를 충족하도록 조직을 디자인하는 방법에 영향을 줄 수 있습니다. 예를 들어, LCR(로컬 연속 복제), CCR(클러스터 연속 복제), SCC(단일 복사본 클러스터), VSS(볼륨 섀도 복사본 서비스), 복구 저장소 그룹, 데이터베이스 이식성 및 발신음 이식성 기능을 사용하면 이전에 SLA에서 적용되던 제한을 극복할 수 있습니다.

다음 표에서는 SLA에 포함할 수 있는 몇 가지 범주와 특정 요소를 보여줍니다.

일반적인 엔터프라이즈 수준 SLA의 범주와 요소

SLA 범주 SLA 요소 예제

작업 시간

  • 메시징 서비스를 사용자가 사용할 수 있는 시간

  • 계획된 가동 중지 시간에 예약된 시간(유지 관리)

  • 네트워크 변경이나 사용자에게 영향을 줄 수 있는 기타 변경 내용에 대한 사전 고지 정도

서비스 가용성

  • Exchange 서비스가 실행 중인 시간 백분율

  • 사서함 저장소가 탑재된 시간 백분율

  • 도메인 컨트롤러 서비스가 실행 중인 시간 백분율

시스템 성능

  • 메시징 시스템에서 동시에 지원하는 내부 사용자 수

  • 메시징 시스템에서 동시에 지원하는 원격으로 연결된 사용자 수

  • 시간 단위당 지원되는 메시징 트랜잭션 수

  • 사용자가 경험하는 대기 시간과 같은 허용되는 성능 수준

재해 복구

  • 개별 데이터베이스 오류, 사서함 서버 오류, 도메인 컨트롤러 오류, 사이트 오류 등과 같이 각 오류 유형의 복구에 허용되는 시간

  • 사용자가 기록 데이터에 액세스하지 않고 전자 메일 메시지를 주고받을 수 있도록 백업 메일 시스템을 제공하는 데 걸리는 시간(메시징 발신음이라고 함)

  • 데이터를 오류 지점으로 복구하는 데 걸리는 시간

지원 센터 및 지원

  • 사용자가 지원 센터에 연락하기 위해 사용할 수 있는 특정 방법

  • 다양한 유형의 문제에 대한 지원 센터의 대응 시간

  • 문제 에스컬레이션 절차에 대한 지원 센터의 절차

기타

  • 사용자당 필요한 저장소 공간

  • 메시징 시스템에 대한 원격 액세스와 같은 특수한 기능이 필요한 사용자 수

다양한 성능 측정값을 SLA에 포함하면 사용자의 특정 성능 요구 사항을 충족하는 데 도움이 됩니다. 예를 들어 클라이언트 및 사서함 서버 간에 대기 시간이 높거나 사용 가능한 대역폭이 낮을 경우 사용자는 시스템 관리자와 다르게 성능 수준을 보게 됩니다. 특히 시스템 관리자가 성능이 허용되는 정도라고 간주하더라도 사용자는 성능 수준이 나쁘다고 생각하게 됩니다. 따라서 디스크 I/O(입/출력) 대기 시간 수준을 모니터링해야 합니다.

참고

또한 각 SLA 요소에 대해 가용성 목표와 함께 성능을 측정하는 데 사용할 특정 성능 벤치마크를 결정해야 합니다. 이외에도 정보 기술 관리자 및 기타 관리자에게 통계를 제공하는 빈도를 결정해야 합니다.

공급업체와 서비스 수준 계약 체결

고가용성 솔루션을 중요시하는 대부분의 기업은 타사 공급업체의 서비스를 사용하여 고가용성 목표를 달성합니다. 이러한 경우에 고가용성 메시징 시스템을 실현하려면 외부 하드웨어 및 소프트웨어 공급업체의 서비스가 필요합니다. 대처가 느린 공급업체와 제대로 교육을 받지 못한 공급업체 직원으로 인해 메시징 시스템의 가용성이 저하될 수 있습니다.

각 주요 공급업체와 SLA를 협상해야 합니다. 공급업체와 SLA를 체결하면 메시징 시스템은 사양에 맞는 성능을 제공하고 필요한 성장을 지원하며 특정 표준에 맞게 사용될 수 있습니다. SLA가 없을 경우 메시징 시스템을 사용할 수 없는 시간이 크게 늘어날 수 있습니다.

중요

직원들이 각 SLA의 조건을 알고 있는지 확인해야 합니다. 예를 들어 대부분의 하드웨어 공급업체 SLA에는 공급업체의 지원 담당자나 조직의 인증된 특정 직원만 서버 케이스를 열 수 있도록 허용하는 조항이 있습니다. 조건을 준수하지 않으면 SLA를 위반하게 되어 공급업제 보증 또는 책임이 무효가 될 수 있습니다.

주요 공급업체와 SLA를 체결하는 것 외에도 지원 요청 훈련을 수행하여 에스컬레이션 절차를 정기적으로 테스트해야 합니다. 최신 연락처 정보를 갖고 있는지 확인하려면 호출기 및 전화 연락망도 테스트해야 합니다.

가용성을 위한 고려 사항

가용성 요구 사항을 확인하기 위해 다음 문제를 고려하는 것이 좋습니다.

  • 제안된 인프라 설계에서의 오류 발생에 대한 취약성을 이해합니다. 단일 지점에서 오류가 발생하지 않도록 해야 합니다. 단일 오류 발생 지점은 중복 기능이 없는 메시징 인프라 내의 구성 요소이므로 오류가 발생하면 사용자에게 영향을 미칠 수 있습니다. 해당 솔루션에 대해 제안된 기술 설계에서 전체 종단 간 구성을 다루어야 합니다.

  • 메시징 서비스 비즈니스에 필요한 최소 가용성 수준 및 메시징 인프라의 각 구성 요소에 대한 안정성, 유지 관리, 서비스 측면에서의 최소 수준을 고려합니다.

  • 지정한 요구 사항에 부합하는지 확인하기 위해 새 구성 요소를 테스트하거나 시뮬레이션하는 기능을 고려합니다. 설계상의 새 구성 요소가 기술된 요구 사항을 충족할 수 있는지 평가하려면 시작한 테스팅 환경에서 예상된 가용성을 산출할 수 있는지 확인하는 것이 중요합니다. 또한 구성 요소를 서비스 받을 때도 테스팅을 수행해야 합니다. 구성 요소가 볼륨 및 스트레스 조건 하에서 계속 작동하는지 확인하려면 새 정보 기술 서비스에 대한 사용자의 기대 요구를 만들어내는 시뮬레이션 도구의 사용을 신중히 고려해야 합니다.

고가용성을 위한 고려 사항

고가용성 메시징 솔루션에는 모니터링 솔루션, 서비스 관리 프로세스, 시스템 관리 도구 및 중복성에의 투자 및 배포가 필요합니다. 고가용성 배포를 위해 이 종단 간 구성에서 단일 지점에서 오류가 발생하지 않도록 하는 것이 중요합니다. 고가용성 설계에서는 단일 지점에서의 오류 발생 방지 및 대체 구성 요소의 제공을 고려하여 구성 요소에 오류가 발생할 경우에도 업무 작업 중단 시간을 최소화해야 합니다. 또한 인프라에 대한 변경 내용 구현과 같이 유지 관리 작업을 수용하는 데 필요한 정상적인 업무 작업에 대한 계획된 중단 시간의 영향을 없애거나 최소화해야 합니다. 복구 조건에서는 설계 복구 단계를 위한 설계에서의 주요 목표로 빠른 복구 및 서비스 복귀를 정의해야 합니다.

메시징 솔루션을 위한 배포 계획을 개발하려면 해당 솔루션의 목표를 파악해야 합니다. 이 요소는 솔루션의 가용성 특성을 디자인할 때 특히 중요합니다. 업무 목표는 서로 충돌하는 경우가 많습니다. 예를 들어, 가용성 목표에 100%의 가용성이 포함되는 동시에 1주일 동안의 가용 기간 내에 최신 보안 업그레이드도 적용해야 하는 경우가 있습니다. 또한 비용으로 인해 배포 계획에서 문제가 발생할 수도 있습니다. 모든 업무 요구 사항을 식별하고 해당 요구 사항에 대해 사용 가능한 옵션을 평가하는 계획 방식을 따르면 업무에 적합한 솔루션을 가장 효율적으로 파악할 수 있습니다.

고가용성을 달성하려면 조직의 운영 방식을 지속적으로 확인해야 합니다. 중단 현상의 모든 원인을 파악해야 합니다. 프로세스를 변경함으로써 중단을 방지할 수 있는 경우에는 적절한 프로세스 변경 작업을 수행해야 합니다.

가용성을 최대화하는 또 다른 주요 요소는 Exchange 환경을 사전 모니터링하는 것입니다. 환경을 사전에 모니터링하면 시스템 내의 문제 영역에서 오류 및 중단 현상이 발생하기 전에 해당 영역을 확인할 수 있습니다. 또한 모니터링을 수행하면 시스템에서 자동으로 복구하지 않는 문제에 대해 운영 직원에게 알릴 수 있습니다. 이러한 상황에 대해 적시에 대응하면 중단 기간이 단축되므로 가용성이 높아집니다.

Exchange 2007은 데이터 센터 내의 인프라에 종속 관계를 적용합니다. 그러므로 Exchange의 가용성은 해당 종속 관계에 의해 제공되는 가용성의 제약을 받습니다. 조직에서는 각 종속 관계에 대해 SLA를 설정해야 합니다. SLA는 제공되는 서비스의 가용성과 오류가 발생하는 경우의 복구 시간을 지정해야 합니다. 예를 들어, Active Directory 디렉터리 서비스는 Exchange의 주요 종속 관계입니다. Active Directory의 가용성이 Exchange의 가용성 목표보다 낮으면 Exchange가 해당 목표에 도달하지 못할 가능성이 높습니다.

Exchange 2007의 가용성은 정보 기술 인프라 내의 다른 서비스 가용성에 따라 달라집니다. Active Directory 및 네트워킹 같은 서비스가 제대로 작동해야 Exchange도 작동합니다. 이러한 서비스의 가용성은 Exchange 가용성에 직접적으로 영향을 줍니다. 따라서 Exchange의 가용성 요구 사항은 이에 종속된 요소의 가용성 요구 사항보다 낮아야 합니다. 종속된 요소는 다음과 같습니다.

  • Active Directory

  • DNS(Domain Name System)

  • TCP/IP 네트워크

  • 저장소 하위 시스템

  • 백업 서비스

  • 모니터링 서비스

  • 데이터 센터 인프라(전원 및 냉방)

업무 목표와 Exchange 종속성에 대한 SLA를 설정한 후에는 메시징 서비스에 대한 초기 가용성 요구 사항 목록을 개발하는 것이 좋습니다. 이 목록에는 각각의 일반 오류 클래스 및 예상 RTO(Recovery Time Objective)가 포함되어야 합니다. 데이터 관련 오류의 경우에는 이 목록에 해당 오류가 데이터에 미치는 영향을 나타내는 내용도 포함되어야 합니다. RPO(Recovery Time Objective)를 통해 이를 지정할 수 있습니다. RPO는 사후 복구를 수행할 수 있는 데이터 수준을 정의하는 시간을 지정하여 데이터에 대한 영향을 표시합니다. 다음과 같은 오류를 고려해야 합니다.

  • 단일 메일 항목 손실

  • 단일 사서함 손실

  • 데이터베이스 손실 또는 손상

  • 디스크 오류

  • 디스크 볼륨 오류 또는 손상

  • 저장소 단위 오류

  • 서버 오류

  • 네트워크 연결 끊김

  • 데이터 센터 오류

대부분의 조직에서는 설정된 가용성 요구 사항이 사용자 유형에 따라 달라집니다. 예를 들어 메시징 시스템을 사용하여 배송 또는 판매를 추적하는 사용자도 있고 중요하지 않은 메시지를 관리하는 사용자도 있습니다. 메시지 시스템을 사용하여 중요한 프로세스를 관리하는 사용자의 RTO 및 RPO는 최대한 짧아야 하는 반면 메시징 시스템을 통해 중요하지 않은 프로세스를 관리하는 사용자의 RTO 및 RPO는 더 길어도 됩니다.

자세한 내용

Exchange 2007의 사이트 복원에 대한 자세한 내용은 Site Resilience Configurations을 참조하십시오.