시스템 수준 내결함성 조치

 

마지막으로 수정된 항목: 2006-08-16

이 섹션에는 Exchange 2003 조직의 내결함성 향상을 위한 시스템 수준의 고려 사항과 전략이 있습니다. 특히 시스템 수준이란 Exchange 2003 인프라와 이 인프라에 내결함성을 구현하기 위해 권장되는 최적의 방법을 말합니다.

다음 그림에서는 안정된 Exchange 2003 인프라와 높은 수준의 내결함성을 유지하기 위한 최적의 방법을 보여 줍니다.

인프라 수준 내결함성 조치

이 섹션에서는 Exchange 2003 인프라의 각 수준에서 내결함성을 디자인하는 방법을 설명합니다. 특히 이 섹션에서는 다음 정보를 제공합니다.

• 방화벽 및 주변 네트워크 구현
• Active Directory 및 DNS(Domain Name System)에 대한 안정적인 액세스 보장
• Exchange 프런트 엔드 서버에 대한 안정적인 액세스 보장
• Exchange 프로토콜 가상 서버 구성
• 안정적인 백 엔드 저장소 솔루션 구현
• 서버 클러스터링 솔루션 구현
• 모니터링 전략 구현
• 재해 복구 전략 구현

방화벽 및 주변 네트워크 구현

Exchange 2003 토폴로지에 주변 네트워크와 프런트 엔드/백 엔드 서버 아키텍처를 포함하는 것이 좋습니다. 다음 그림에서는 고급 역방향 프록시 서버(이 경우 ISA(Internet Security and Acceleration) Server 2000 기능 팩 1)에서 제공하는 추가 보안과 함께 이 토폴로지를 보여 줍니다.

주변 네트워크에 ISA Server 2000 기능 팩 1을 배포하는 것은 메시징 시스템 보안을 위한 방법 중 하나입니다. 그 밖에 인터넷 프로토콜 보안(IPSec)이나 SSL(Secure Sockets Layer)과 같은 전송 수준 보안을 사용하는 방법도 있습니다.

안전한 Exchange 토폴로지 디자인에 대한 자세한 내용은 Exchange Server 2003 메시징 시스템 계획의 "인프라 계획"을 참조하십시오.

Exchange 2003과 함께 ISA Server 2000을 사용하는 방법에 대한 자세한 내용은 Using ISA Server 2000 with Exchange Server 2003을 참조하십시오.

Active Directory 및 DNS(Domain Name System)에 대한 안정적인 액세스 보장

Exchange는 Active Directory와 DNS(Domain Name System)에 많이 의존합니다. Active Directory와 DNS에 안정적이고 효과적으로 액세스하려면 도메인 컨트롤러, 글로벌 카탈로그 서버 및 DNS 서버에 오류가 발생하지 않도록 잘 보호해야 합니다.

도메인 컨트롤러

도메인 컨트롤러는 도메인 데이터베이스를 호스팅하고 클라이언트가 Exchange에 로그온 및 액세스하는 데 필요한 인증 서비스를 수행합니다. Exchange나 Windows를 통해 사용자를 인증할 수 있어야 합니다. Exchange 2003은 도메인 컨트롤러를 사용하여 시스템 및 서버 구성 정보를 얻습니다. Windows Server 2003에서는 도메인 데이터베이스가 Active Directory 데이터베이스에 포함되고 Windows Server 2003 도메인 포리스트에서는 포리스트 구성과 스키마 컨테이너 복사본도 함께 호스팅하는 도메인 컨트롤러 간에 Active Directory 정보가 복제됩니다.

도메인 컨트롤러는 Active Directory 인프라에서 글로벌 카탈로그 서버, 작업 마스터, 간단한 도메인 컨트롤러 등 다양한 역할을 맡을 수 있습니다.

글로벌 카탈로그 서버

글로벌 카탈로그 서버는 글로벌 카탈로그를 호스팅하는 도메인 컨트롤러입니다. 글로벌 카탈로그 서버는 유니버설 그룹 구성원에 대한 정보를 포함하기 때문에 로그온에 필요합니다. 이 구성원은 사용자에게 리소스에 액세스할 수 있는 권한을 부여하거나 거부합니다. 글로벌 카탈로그 서버에 연결할 수 없으면 사용자의 유니버설 구성원을 확인할 수 없으므로 로그온 액세스가 거부됩니다.

Exchange 서버가 있는 도메인마다 글로벌 카탈로그 서버가 적어도 하나씩 설치되어 있어야 합니다.

도메인 컨트롤러 및 글로벌 카탈로그 서버를 위한 최적의 방법

도메인 컨트롤러에는 필수적인 Active Directory 정보가 들어 있으므로 조직의 도메인 컨트롤러에 오류가 발생하지 않도록 잘 보호해야 합니다.

다음은 Active Directory 도메인 컨트롤러와 글로벌 카탈로그 서버를 배포하고 구성하기 위한 최적의 방법입니다.

• 조직에 필요한 경우가 아니면 도메인 컨트롤러에서 Exchange 2003을 실행하지 않습니다. 도메인 컨트롤러에서 Exchange 실행할 때의 영향에 대한 자세한 내용은 이 항목 뒷부분의 "도메인 컨트롤러에서 Exchange 2003 실행"을 참조하십시오.

• Active Directory 사이트마다 도메인 컨트롤러가 적어도 두 대는 있어야 합니다. 사이트에서 도메인 컨트롤러를 사용할 수 없으면 Exchange에서 다른 도메인 컨트롤러를 찾습니다. 이 사항은 WAN을 통해서만 조직의 도메인 컨트롤러에 액세스할 수 있을 경우 특히 중요합니다. 이 현상은 성능 문제로 인해 발생할 수 있으며 이로 인해 단일 지점에서 오류가 발생할 수 있습니다.

• Active Directory 사이트마다 글로벌 카탈로그 서버가 적어도 두 대는 있어야 합니다. 사이트에서 글로벌 카탈로그 서버를 사용할 수 없으면 Exchange에서 다른 글로벌 카탈로그 서버를 찾습니다. 이 사항은 WAN을 통해서만 조직의 다른 글로벌 카탈로그 서버에 액세스할 수 있을 경우 특히 중요합니다. 이 현상은 성능 문제로 인해 발생할 수 있으며 이로 인해 단일 지점에서 오류가 발생할 수 있습니다.

  참고

  성능 요구 사항에서 도메인당 도메인 컨트롤러 두 대와 글로벌 카탈로그 서버 두 대의 대역폭을 요구하지 않으면 모든 도메인 컨트롤러를 글로벌 카탈로그 서버로 구성해 보십시오. 이 시나리오에서는 Exchange 2003 조직에 글로벌 카탈로그 서비스를 제공하기 위해 모든 도메인 컨트롤러를 사용합니다.

• 프로세서 모델과 속도가 비슷하다고 가정할 경우 Exchange 프로세서와 글로벌 카탈로그 서버 프로세서의 비율은 일반적으로 4:1입니다. 그러나 글로벌 카탈로그 서버 사용량이 많을수록 Active Directory 데이터베이스나 메일 그룹이 클 경우 글로벌 카탈로그 서버가 많이 필요할 수 있습니다.

• 11명 이상의 사용자를 처리하는 지점에서는 Exchange 서버가 있는 위치마다 글로벌 카탈로그 서버를 하나씩 설치해야 합니다. 그러나 중복을 위해 두 대의 글로벌 카탈로그 서버를 배포하는 것이 가장 좋습니다. 실제 사이트에 두 대의 글로벌 카탈로그 서버가 없으면 기존 도메인 컨트롤러를 글로벌 카탈로그 서버로 구성할 수 있습니다.

• 아키텍처에 사이트당 서브넷이 여러 개일 경우 서브넷당 한 대 이상의 도메인 컨트롤러와 한 대 이상의 글로벌 카탈로그 서버를 설치하여 가용성을 높일 수 있습니다. 그러면 라우터에 오류가 발생하더라도 도메인 컨트롤러에 계속 액세스할 수 있습니다.

• 인프라 마스터 역할이 할당된 서버는 글로벌 카탈로그 서버가 아니어야 합니다. 인프라 마스터 역할에 대한 자세한 내용은 Windows 2000 Server 도움말의 "글로벌 카탈로그 및 인프라 마스터" 항목을 참조하십시오.

• 모든 Exchange 2003 도메인 컨트롤러에서 LDAP 대기 시간 모니터링을 고려합니다. Exchange 모니터링에 대한 자세한 내용은 소프트웨어 모니터링 및 오류 검색 도구 구현을 참조하십시오.

• 요구 사항에 따라 20에서 40으로 LDAP 스레드 증가를 고려합니다. Exchange 튜닝에 대한 자세한 내용은 Exchange Server 2003 성능 및 확장성 가이드를 참조하십시오.

• 도메인 컨트롤러에 대한 철저한 백업 계획이 있어야 합니다.

도메인 컨트롤러에서 Exchange 2003 실행

Windows 도메인 컨트롤러 기능을 겸하는 서버에서 Exchange 2003을 실행하지 않는 것이 최적의 방법입니다. 대신 Exchange 서버와 Windows 도메인 컨트롤러를 별도로 구성해야 합니다.

그러나 도메인 컨트롤러에서 Exchange 2003을 실행해야 하는 조직에서는 다음 제한 사항을 고려하십시오.

• 도메인 컨트롤러에서 Exchange 2003을 실행하면 도메인 컨트롤러만 사용되므로 도메인 컨트롤러에 오류가 발생할 경우 Exchange에서 다른 도메인 컨트롤러로 장애 조치할 수 없습니다.
• Exchange 서버가 Exchange 클라이언트 컴퓨터 역할 이외에 도메인 컨트롤러 작업을 수행하면 사용자 로드가 많은 시간에 해당 서버의 성능이 저하될 수 있습니다.
• 도메인 컨트롤러에서 Exchange 2003을 실행하면 Active Directory 관리자와 Exchange 관리자의 보안 및 재해 복구 책임이 겹칠 수 있습니다.
• 도메인 컨트롤러 기능을 겸하는 Exchange 2003 서버는 Windows 클러스터에 포함될 수 없습니다. 특히 Exchange 2003은 Active Directory와 공존하는 클러스터된 Exchange 2003 서버를 지원하지 않습니다. 예를 들어 로컬 서버에 로그온하는 Exchange 관리자는 도메인 컨트롤러에 대한 실제 콘솔 액세스 권한이 있으므로 Active Directory에서 권한을 향상시킬 수 있습니다.
• 서버가 메시징 시스템의 유일한 도메인 컨트롤러일 경우 글로벌 카탈로그 서버여야 합니다.
• 도메인 컨트롤러에서 Exchange 2003을 실행할 경우 /3GB 스위치를 사용하지 마십시오. 이 스위치를 사용하면 Exchange 캐시가 시스템 메모리를 독점할 수 있습니다. 또한 사용자 연결 수가 적기 때문에 /3GB 스위치가 필요 없습니다.
• 모든 서비스가 LocalSystem으로 실행되므로 보안 버그가 있을 경우 노출 위험이 커집니다. 예를 들어 도메인 컨트롤러에서 Exchange 2003을 실행하면 공격자의 Active Directory 액세스를 허용하는 Active Directory 버그로 인해 Exchange 액세스도 허용됩니다.
• Exchange 2003을 실행하는 도메인 컨트롤러는 다시 시작하거나 종료하는 데 약 10분 이상이 걸립니다. 그 이유는 Lsass.exe와 같은 Active Directory 관련 서비스가 Exchange 서비스보다 먼저 종료되어 Active Directory 서비스를 검색하는 동안 Exchange 서비스에 계속 오류가 발생하기 때문입니다. 실패한 서비스의 시간 제한을 변경하거나 서버를 종료하기 전에 수동으로 Exchange 서비스를 중지하여 이 문제를 해결할 수 있습니다.

Domain Name System 및 Windows Internet Name Service 가용성

도메인 컨트롤러 및 글로벌 카탈로그 서버 서비스와 마찬가지로 DNS(Domain Name System) 서비스도 Exchange 2003 조직의 가용성을 위해 필수적입니다. Windows Server 2003 네트워크에서 사용자는 DNS와 WINS(Windows Internet Name Service)를 사용하여 리소스를 찾습니다. DNS 서버에 오류가 발생하면 사용자가 메시징 시스템을 찾지 못할 수 있습니다.

Exchange 2003 토폴로지에 안정적인 DNS 액세스를 포함하려면 다음 사항을 고려하십시오.

• 네트워크에 보조 DNS 서버가 있어야 합니다. 주 DNS 서버에 오류가 발생하면 이 보조 서버가 사용자를 올바른 서버에 연결할 수 있어야 합니다.
• Windows Server 2003 DNS 영역을 Active Directory에 통합합니다. 이 시나리오에서 각 도메인 컨트롤러는 DNS 서버가 될 수 있습니다.
• 두 개 이상의 DNS 주소로 각 클라이언트 컴퓨터를 구성합니다.
• 두 대의 DNS 서버를 클라이언트와 같은 사이트에 배치하는 것이 가장 좋습니다. DNS 서버가 클라이언트와 다른 사이트에 있으면 주 DNS 서버는 클라이언트와 같은 사이트에 있는 서버여야 합니다.
• 이름 확인 기능과 DNS 기능이 둘 다 올바르게 작동하고 있는지 확인합니다. 자세한 내용은 Microsoft 기술 자료 문서 322856 "HOW TO: Exchange Server 사용을 위한 DNS 구성"을 참조하십시오.
• Exchange를 배포하기 전에 허브 사이트와 모든 위치에서 DNS가 제대로 구성되어 있는지 확인합니다.
• Exchange에는 WINS가 필요합니다. WINS를 사용하지 않고도 Exchange 2003을 실행할 수는 있지만 권장되지는 않습니다. WINS를 사용하여 NetBIOS 이름을 확인하면 가용성이 높아집니다. 예를 들어 일부 구성에서 WINS를 사용하면 NetBIOS 이름이 중복되어 이름 확인 오류가 발생할 가능성이 없어집니다. 자세한 내용은 Microsoft 기술 자료 문서 837391, "Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality"를 참조하십시오.

DNS 및 WINS 배포에 대한 자세한 내용은 Microsoft Windows Server 2003 Deployment Kit의 "Deploying DNS" 및 "Deploying WINS"를 참조하십시오.

Exchange 프런트 엔드 서버에 대한 안정적인 액세스 보장

조직에 둘 이상의 Exchange 서버가 있는 경우 Exchange 프런트 엔드/백 엔드 서버 아키텍처를 사용하는 것이 좋습니다. 프런트 엔드/백 엔드 아키텍처는 클라이언트 액세스 성능 및 가용성 면에서 몇 가지 이점을 제공합니다.

인터넷 클라이언트는 프런트 엔드 서버를 통해 사서함에 액세스합니다. 그러나 기본 Exchange 2003 구성에서 MAPI 클라이언트는 프런트 엔드 서버를 사용할 수 없으며 백 엔드 서버를 통해 직접 사서함에 액세스합니다.

프런트 엔드 서버에서 HTTP, POP3 및 IMAP4를 사용할 경우 프런트 엔드 서버가 백 엔드 서버의 로드 처리 업무의 일부를 오프로드하므로 성능이 향상됩니다.

MAPI, HTTP, POP3 또는 IMAP4를 지원하려는 경우 Exchange 프런트 엔드/백 엔드 서버 아키텍처를 사용하면 다음과 같은 이점이 있습니다.

• 프런트 엔드 서버에서 서버 간의 처리 작업 균형을 조정합니다. 예를 들어 프런트 엔드 서버가 인증, 암호화 및 암호 해독 프로세스를 수행하여 Exchange 백 엔드 서버 성능이 향상됩니다.
• 메시징 시스템 보안이 향상됩니다. 자세한 내용은 이 항목 뒷부분의 "보안 조치"를 참조하십시오.
• 메시징 시스템에 중복성과 로드 균형 조정을 통합하려는 경우 Exchange 프런트 엔드 서버에서 네트워크 로드 균형 조정(NLB)을 사용할 수 있습니다.

Exchange 2003 프런트 엔드 및 백 엔드 아키텍처 계획에 대한 자세한 내용은 Exchange Server 2003 메시징 시스템 계획의 "인프라 계획"을 참조하십시오.

프런트 엔드 및 백 엔드 서버 배포에 대한 자세한 내용은 Using Microsoft Exchange 2000 Front-End Servers를 참조하십시오. 이 문서에서는 Exchange 2000에 초점을 맞추고 있지만 Exchange 2003에도 적용되는 내용입니다.

메시징 시스템에 내결함성을 구축하려면 NLB를 사용하는 Exchange 프런트 엔드 서버 구현을 고려해 보십시오. 또한 프런트 엔드 서버에 중복 가상 서버를 구성해야 합니다.

프런트 엔드 서버에서 네트워크 로드 균형 조정 사용

네트워크 로드 균형 조정(NLB)은 높은 확장성과 성능을 필요로 하는 IP 기반 응용 프로그램과 서비스에 대해 로드 균형 조정 지원을 제공하는 Windows Server 2003 서비스입니다. NLB가 Exchange 2003 프런트 엔드 서버에서 구현되면 프런트 엔드 서비스로 인한 지체를 해결할 수 있습니다.

다음 그림에서는 NLB가 포함된 기본적인 프런트 엔드/백 엔드 아키텍처를 보여 줍니다.

NLB 클러스터는 둘 이상의 Exchange 프런트 엔드 서버에 동적으로 IP 소통량을 분산시키고 프런트 엔드 서버 사이에 클라이언트 요청을 투명하게 분산시키며 클라이언트가 단일 서버 네임스페이스를 사용하여 사서함에 액세스할 수 있게 허용합니다.

NLB 클러스터는 그 숫자만큼 다음 구성 요소의 확장성과 성능을 향상시키는 컴퓨터입니다.

• 웹 서버
• ISA 서버를 실행하는 컴퓨터(프록시 및 방화벽 서버의 경우)
• TCP/IP 및 UDP(User Datagram Protocol) 소통량을 받아 들이는 그 밖의 응용 프로그램

NLB 클러스터 노드에는 대개 하드웨어 및 소프트웨어가 이상적으로 구성되어 있으므로 서비스를 제공하는 NLB 클러스터 노드에 관계없이 사용자가 일관된 프런트 엔드 서비스 성능을 경험할 수 있습니다. NLB 클러스터의 노드는 모두 액티브입니다.

NLB에 대한 자세한 내용은 Microsoft Windows Server 2003 Deployment Kit의 "Designing Network Load Balancing" 및 "Deploying Network Load Balancing"을 참조하십시오.

네트워크 로드 균형 조정 및 확장성

NLB를 사용하면 Exchange 2003 프런트 엔드 서버에서 요구가 증가함에 따라 스케일 업하거나 스케일 아웃할 수 있습니다. Exchange 사용자에게 빠른 서비스를 제공하는 것이 주된 목표라면 일반적으로 프로세서와 메모리를 추가하는 등의 스케일 업이 좋은 해결 방법입니다. 그러나 프런트 엔드 서버에 내결함성 조치를 구현하려면 서버 추가와 같은 스케일 아웃이 가장 알맞습니다. NLB를 사용하면 필요할 경우 서버 32대까지 스케일 아웃할 수 있습니다. 스케일 아웃을 수행하면 NLB 클러스터의 서버가 늘어날 경우 서버 오류의 영향을 받는 사용자가 적어지므로 내결함성이 높아집니다.

Exchange 프로토콜 가상 서버 구성

Exchange 2003 메시징 시스템을 구성할 때는 Exchange System Manager를 사용하여 특정 프런트 엔드 서버에서 지원할 각 프로토콜에 대해 프로토콜 가상 서버를 만드십시오.

프런트 엔드 서버의 가용성과 성능을 극대화하려면 프로토콜 가상 서버를 구성할 때 다음 권장 사항을 고려하십시오.

• Exchange 2003 프런트 엔드 서버에 대해 NLB를 구성할 때는 NLB 프런트 엔드 서버의 모든 프로토콜 가상 서버가 같은 설정으로 구성되었는지 확인해야 합니다.

  중요

  NLB 클러스터의 프로토콜 가상 서버들이 일치하지 않으면 라우팅되는 서버에 따라 전자 메일 클라이언트에서 다른 동작이 수행될 수 있습니다.

• 프런트 엔드 서버에서 NLB를 사용하지 않는 경우 각각의 프런트 엔드 서버에 추가 프로토콜 가상 서버를 만들지 않습니다. 예를 들어 같은 프런트 엔드 서버에 같은 HTTP 프로토콜 가상 서버 두 개를 만들지 마십시오. 추가 가상 서버는 성능에 심각한 영향을 미칠 수 있으므로 기본 가상 서버를 적절히 구성할 수 없을 때만 추가 가상 서버를 만들어야 합니다.

Exchange 프로토콜 가상 서버 구성에 대한 자세한 내용은 Exchange Server 2003 관리 가이드를 참조하십시오.

Exchange 2003 프런트 엔드 서버 튜닝에 대한 자세한 내용은 Exchange Server 2003 성능 및 확장성 가이드를 참조하십시오.

안정적인 백 엔드 저장소 솔루션 구현

내결함성을 갖춘 메시징 시스템을 실현하려면 안정적인 저장소 전략이 가장 중요합니다. 안정적인 저장소 솔루션을 구현하고 구성하려면 다음 사항을 숙지해야 합니다.

• Exchange 2003 데이터베이스 기술
• Exchange 데이터 구성 및 유지 관리를 위한 최적의 방법
• RAID 및 SAN(Storage Area Network)과 같은 고급 저장소 기술
• 안정적인 백 엔드 저장소 솔루션 계획 및 구현에 대한 자세한 내용은 안정적인 백 엔드 저장소 솔루션 계획을 참조하십시오.

서버 클러스터링 솔루션 구현

서버 클러스터링은 리소스 장애 조치를 허용하여 Exchange 2003 조직을 위한 내결함성을 제공합니다. 특히 클러스터 서비스를 사용하는 서버 클러스터는 데이터 무결성을 유지하고 데이터베이스, 메시징 시스템, 파일 및 인쇄 서비스를 포함하여 백 엔드 서버의 업무상 중요한 응용 프로그램과 서비스에 대해 장애 조치 지원과 높은 수준의 가용성을 제공합니다.

다음 그림에서는 노드 세 개는 액티브이고 한 개는 패시브인 4노드 클러스터의 예를 보여 줍니다.

서버 클러스터의 노드는 데이터에 대한 액세스를 공유합니다. 노드는 액티브 또는 패시브일 수 있으며 각 노드 구성은 운영 모드(액티브 또는 패시브)와 장애 조치 구성 방법에 따라 다릅니다. 장애 조치를 처리하도록 지정된 서버는 오류가 발생한 노드의 작업 부하를 처리할 수 있는 크기여야 합니다.

Exchange 서버 클러스터 계획에 대한 자세한 내용은 Exchange 클러스터링 계획을 참조하십시오.

클러스터링의 이점

조직에서 서버 클러스터링을 사용하면 장애 조치와 확장성이라는 두 가지 이점을 경험할 수 있습니다.

장애 조치

장애 조치는 서버 클러스터링의 가장 중요한 이점 중 하나입니다. 클러스터에 있는 서버 하나가 작동을 멈추면 오류가 발생한 서버의 작업 부하가 클러스터의 다른 서버로 장애 조치됩니다. 장애 조치가 수행되면 응용 프로그램과 데이터를 계속 사용할 수 있습니다. Windows 클러스터링 기술은 다음 세 가지 특정 오류 유형을 방지합니다.

• 응용 프로그램 및 서비스 오류. 이러한 오류는 응용 프로그램 소프트웨어와 필수 서비스에 영향을 미칩니다.
• 시스템 및 하드웨어 오류. 이러한 오류는 CPU, 드라이브, 메모리, 네트워크 어댑터 및 전원 공급 장치와 같은 하드웨어 구성 요소에 영향을 미칩니다.
• 복수 사이트 조직의 사이트 오류. 이러한 오류는 자연 재해, 정전 또는 연결 중단으로 인해 발생할 수 있습니다. 이러한 유형의 오류를 방지하려면 고급 geoclustering 솔루션을 구현해야 합니다. 자세한 내용은 이 항목 뒷부분의 "여러 실제 사이트 사용"을 참조하십시오.

서버 클러스터링을 수행하면 이러한 오류 유형을 방지하여 메시징 환경에 다음과 같은 두 가지 이점이 있습니다.

• 높은 수준의 가용성 예약되지 않은 중단을 줄이고 최종 사용자에게 신뢰할 수 있는 액세스 서비스를 제공하는 기능입니다.
• 높은 안정성 시스템 오류 빈도를 줄이는 기능입니다.

확장성

서버 클러스터링의 또 다른 이점은 확장성입니다. 클러스터에 노드를 추가할 수 있으므로 Windows 서버 클러스터를 크게 확장할 수 있습니다.

클러스터링 제한

서버 클러스터링은 데이터 수준에서 보다는 응용 프로그램 수준에서 내결함성을 제공합니다. 서버 클러스터링 솔루션을 구현할 때는 철저한 데이터 보호 및 복구 솔루션을 구현하여 바이러스, 손상 및 데이터에 대한 그 밖의 위협을 방지합니다. 클러스터링 기술은 바이러스, 소프트웨어 손상 또는 실수로 인한 오류를 방지할 수 없습니다.

클러스터링 및 내결함성이 있는 하드웨어 비교

클러스터링과 내결함성이 있는 하드웨어는 모두 CPU, 메모리, 팬 또는 PCI 버스 오류와 같은 구성 요소 오류로부터 시스템을 보호합니다. 클러스터링과 내결함성이 있는 하드웨어를 함께 종단 간 솔루션으로 사용할 수도 있지만 두 방법의 높은 수준 가용성 방식에는 다음과 같은 차이가 있습니다.

• 클러스터링은 응용 프로그램이나 운영 체제 오류를 방지합니다. 그러나 내결함성이 있는 하드웨어(또는 서버가 실행되는 동안 장치를 추가할 수 있도록 허용하며 전원이 켜진 상태로 스왑할 수 있는 하드웨어를 사용하는 서버)를 사용하는 독립 실행형 서버(클러스터되지 않은 서버)는 이러한 오류 유형을 방지할 수 없습니다.
• 클러스터링을 사용하면 사용자가 전체 Exchange 서비스를 계속해서 사용하면서 클러스터 노드 중 하나에서 업그레이드하거나 설치할 수 있습니다. 클러스터되지 않은 독립 실행형 서버를 사용하면 때때로 Exchange 서비스를 중지하여 업그레이드하거나 설치해야 합니다. 업그레이드하거나 설치하는 동안 Exchange 서비스를 계속해서 사용할 수 있는 방법에 대한 자세한 내용은 Exchange Server 2003 관리 가이드의 "Exchange 가상 서버 또는 Exchange 리소스를 오프라인 상태로 만들기"를 참조하십시오.

모니터링 전략 구현

높은 수준의 가용성을 구현하려면 네트워크, 응용 프로그램, 데이터 및 하드웨어를 지속적으로 모니터링하는 것이 중요합니다. 소프트웨어 모니터링 도구와 기술을 사용하면 시스템 상태를 확인하고 오류가 발생하기 전에 잠재된 문제점을 파악할 수 있습니다.

가용성을 극대화하려면 서버와 응용 프로그램을 지속적으로 관리 및 모니터링하고 문제를 해결해야 합니다. 문제가 발생하면 신속하게 대처하여 최대한 빨리 데이터를 사용할 수 있도록 복구해야 합니다. Microsoft Operations Manager용 Exchange 2003 관리 팩을 사용하여 Exchange 2003 조직을 모니터링할 수 있습니다.

Exchange 2003 관리 팩, Microsoft Operations Manager 및 그 밖의 모니터링 도구에 대한 자세한 내용은 소프트웨어 모니터링 및 오류 검색 도구 구현을 참조하십시오.

재해 복구 솔루션 구현

조직의 내결함성을 높이려면 제대로 계획된 백업 및 복구 전략을 개발하여 구현해야 합니다. 복구할 준비가 되면 대부분의 오류를 복구할 수 있습니다.

추가 시스템 수준의 최적의 방법

Exchange 2003 인프라의 내결함성 향상 조치를 고려한 후에는 다음과 같은 시스템 수준의 최적의 방법을 추가로 고려해 보십시오.

• 서버의 실제 환경 보호 실제 환경이 보호되도록 예방 조치를 취합니다.
• 보안 조치 사용 권한 설정, 보안 패치, 실제 컴퓨터 보안, 바이러스 방지 및 스팸 방지 솔루션을 구현합니다.
• 메시지 라우팅 내결함성이 있는 네트워크 하드웨어를 사용하고 라우팅 그룹과 커넥터를 제대로 구성합니다.
• 여러 실제 사이트 사용 한 개 이상의 원격 사이트로 데이터를 미러링하거나 geoclustering을 구현해 사이트에 오류가 발생할 경우 장애 조치를 허용하여 사이트 오류로부터 데이터를 보호합니다.
• 작업 절차 서버를 유지 관리 및 모니터링하고 표준화된 절차를 사용하며 재해 복구 절차를 테스트합니다.
• 사전 테스팅 및 시험 배포 프로덕션 환경에서 메시징 시스템을 배포하기 전에 사전에 시험 환경에서 성능과 확장성을 테스트합니다.

서버의 실제 환경 보호

서버 가용성을 유지하려면 서버를 실행할 환경의 표준을 높은 수준으로 유지해야 합니다. 서버 하드웨어 수명과 안정성을 높이려면 다음 사항을 고려하십시오.

• 온도 및 습도 용도에 맞는 환경이 갖춰진 장소, 특히 온도와 습도를 세세히 조절할 수 있는 장소에 업무상 중요한 서버를 설치합니다. 컴퓨터는 약 섭씨 21도(화씨 70도)에서 최적의 성능을 발휘합니다. 대개 사무실에서는 온도가 문제시되지 않습니다. 그러나 에어컨이 꺼져 있는 여름철 장기 휴가의 영향을 고려해야 합니다.
• 먼지 또는 오염 물질 가능하면 서버와 다른 장비에 먼지가 묻거나 오염되지 않도록 주의하고 자주 확인하십시오. 먼지나 오염 물질로 인해 구성 요소의 기능이 차단되거나 과열되어 때때로 작동이 중단되는 오류가 발생할 수 있습니다. 서버 케이스가 열려 있으면 장치를 청소해야 하는지 즉시 확인하고 청소가 필요할 경우 주변의 다른 장치도 모두 확인하십시오.
• 전원 공급 장치 재해 복구 계획과 마찬가지로 정전이 발생하기 이전에 정전에 대한 계획을 세우는 것이 가장 좋은 방법이며 이 계획에는 업무 운영에 가장 중요한 리소스 확인이 포함됩니다. 가능하다면 두 개 이상의 회로를 통해 컴퓨터가 있는 장소에 전력을 공급하고 전원 사이에 중복 전원 공급 장치를 나누십시오. 두 개의 회로는 건물 외부에 있는 전원에서 각각 시작되는 것이 가장 좋습니다. 각 위치에서 제공할 수 있는 최대 전력의 양을 알아야 합니다. 각 위치에 서버 수가 너무 많으면 추가 서버에 공급할 전원이 부족해질 수 있습니다. 컴퓨터 센터에 전원 오류가 발생할 경우 사용할 수 있도록 백업 전원 공급 장치를 고려해 보십시오. 지역 내의 다른 건물이나 컴퓨터 센터에서 멀리 떨어진 지역에 계속 컴퓨터 서비스를 제공해야 하는 경우가 있습니다. UPS(무정전 전원 공급 장치) 장치를 사용하여 단기간의 정전을 처리하고 대기 생성기를 사용하여 장기간의 정전을 처리할 수 있습니다. 정전되었을 경우 백업 전원이 필요한 장비로 라우터와 같은 네트워크 장비를 확인하십시오.
• 케이블 관리 케이블이 물리적으로 손상되지 않도록 케이블 관리 시스템이나 정리용 끈을 사용하여 정돈하십시오. 케이블이 본체에 제대로 연결되어 있어야 실수로 분리되는 것을 방지할 수 있습니다. 가능하다면 모든 케이블을 양 끝에 단단히 연결하십시오. 또한 착탈식 랙마운트 장비에 케이블을 연결할 여유 공간이 있고 케이블이 엉키거나 파손되지 않았는지 확인하십시오. 중복 케이블 집합 경로를 제대로 설정하십시오. 복수 전원이나 네트워크 통신을 사용할 경우 케이블을 여러 위치에서 본체에 연결하십시오. 그러면 케이블 하나에 문제가 생겨도 다른 케이블이 계속 작동합니다. 이중 전원 공급 장치를 같은 전선에 연결하지 마십시오. 가능하다면 별도의 회로에 연결된 별도의 콘센트나 UPS 장치를 사용하여 단일 지점에서 오류가 발생하지 않도록 합니다.

보안 조치

보안은 가용성 수준이 높은 메시징 시스템 실현에 필수적인 구성 요소입니다. 여러 가지 보안 조치를 고려해야 하지만 다음 사항은 특히 중요합니다.

• 사용 권한 설정
• 보안 패치
• 실제 보안
• 바이러스 방지
• 스팸 방지 솔루션

위의 조치와 그 밖의 보안 조치에 대한 자세한 내용은 Exchange Server 2003 보안 강화 가이드를 참조하십시오.

메시지 라우팅 고려 사항

라우팅 토폴로지는 메시징 시스템의 기초이므로 네트워크, 대역폭 및 지리적인 사항을 고려하여 라우팅 토폴로지를 계획해야 합니다.

라우팅은 Exchange에서 서버 간에 메시지를 전송하는 방법을 설명합니다. 라우팅 토폴로지를 계획할 때는 Exchange 안에서 메시지가 전송되는 방식을 이해하고 가장 효율적인 메시지 전송 토폴로지를 계획해야 합니다. 또한 Exchange 조직 외부의 메시징 시스템에 대한 커넥터 위치를 계획해야 합니다. 신중한 계획을 통해 네트워크 소통량 볼륨을 줄이고 Exchange와 Windows 서비스를 최적화할 수 있습니다.

안정적이고 사용하기 쉬운 메시징 라우팅을 위해서는 다음과 같은 고급 권장 사항을 고려하십시오.

• 물리적 네트워크에 중복성이 갖춰져 있는지 확인합니다. 자세한 내용은 이 단원 앞부분의 "네트워크 하드웨어"를 참조하십시오.
• 커넥터와 라우팅 그룹이 제대로 구성되어 있는지 확인합니다. 예를 들어 일부 시나리오에서 Exchange System Manager를 사용하여 중복 커넥터 경로를 구성하면 단일 지점에서의 오류 발생을 제한할 수 있습니다.
• 여러 경로를 통해 모든 브리지헤더 서버에 연결되도록 커넥터를 구성합니다.
• 필요할 경우 SMTP(Simple Mail Transfer Protocol) 게이트웨이 서버가 중복되는지 확인합니다. 일반적으로 대규모 데이터 센터에서는 인바운드 및 아웃바운드 SMTP 소통량만을 처리하도록 전용 Exchange 2003 서버를 지정하는 것이 좋습니다. 대개 이러한 서버를 SMTP 게이트웨이 서버 또는 SMTP 허브라고 합니다. 이러한 서버는 클라이언트와 Exchange 2003 사서함 서버(백 엔드 서버) 간 SMTP 전자 메일 이동을 담당합니다.

라우팅 그룹과 커넥터 만들기를 위한 권장 사항을 비롯하여 라우팅 디자인과 구성 계획에 대한 자세한 내용은 Exchange Server 2003 메시징 시스템 계획을 참조하십시오.

메시징 라우팅 구성 방법에 대한 자세한 내용은 Exchange Server 2003 전송 및 라우팅 가이드를 참조하십시오.

여러 실제 사이트 사용

재해 복구 기능을 향상시키고 가용성을 높이기 위해 일부 조직에서는 여러 개의 실제 사이트를 사용합니다. 대부분의 복수 사이트 디자인에는 주 사이트 한 개와 주 사이트를 미러링하는 원격 사이트 한 개 이상이 포함됩니다. 사이트 간에 구성 요소와 데이터가 미러링되는 수준은 SLA 및 업무 요구 사항에 따라 달라집니다. 여러 지역에 분산된 클러스터를 구현하는 방법도 있습니다. 여러 지역에 분산된 클러스터를 사용할 경우 재해가 발생하면 한 사이트의 응용 프로그램이 다른 사이트로 장애 조치할 수 있습니다.

다음 섹션에는 사이트 미러링과 geoclustering에 대한 자세한 내용이 있습니다.

사이트 미러링

사이트 미러링에는 동기 복제나 비동기 복제를 사용하여 주 사이트에서 한 개 이상의 원격 사이트로 Exchange 2003 데이터베이스 및 트랜잭션 로그 데이터와 같은 데이터를 미러링하는 작업이 포함됩니다.

주 사이트에서 전체 사이트 오류가 발생할 경우 미러된 사이트에서 Exchange 서비스를 온라인 상태로 만드는 데 걸리는 시간은 Exchange 조직의 복잡도, 미리 구성된 대기 하드웨어 수, 관리 지원 수준 등에 따라 달라집니다. 예를 들어 조직에서 미리 계획한 재해 복구 절차 집합에 따라 24시간 안에 Exchange 메시징 시스템을 온라인 상태로 만들 수 있습니다. 24시간의 가동 중지 시간이 길 수도 있지만 오류 발생 시점과 비슷하게 데이터를 복구할 수 있습니다. Exchange 데이터의 동기 및 비동기 복제에 대한 자세한 내용은 저장소 기술 개요의 "Exchange 데이터 복제 기술"을 참조하십시오.

여러 지역에 분산된 클러스터

여러 지역에 분산된 클러스터를 구현하여 더 효과적으로 사이트 수준에서 내결함성을 향상시킬 수 있습니다. Windows Server 2003을 사용하여 여러 지역에 분산된 클러스터를 배포하려면 VLAN(가상 LAN)을 사용하여 멀리 있는 SAN에 연결합니다.

여러 지역에 분산된 클러스터 구성은 복잡할 수도 있으며 클러스터된 서버는 Microsoft가 지원하는 구성 요소만 사용해야 합니다. 정식 구성을 제공하는 공급업체를 통해서만 여러 지역에 분산된 클러스터를 배포해야 합니다.

Exchange 2003에서의 여러 지역에 분산된 클러스터 솔루션에 대한 자세한 내용은 Exchange 클러스터링 계획을 참조하십시오.

Windows Server 2003 및 여러 지역에 분산된 클러스터에 대한 자세한 내용은 Geographically를 참조하십시오.

유용한 운영 정보

Exchange 2003 메시징 시스템을 운영하고 관리할 때는 IT 부서에서 표준 IP 구현 방법을 사용해야 합니다. 이 섹션에는 응용 프로그램과 컴퓨터의 가용성 극대화를 위한 유용한 정보가 있습니다. 이 정보는 클러스터된 환경과 클러스터되지 않은 환경에 모두 적용됩니다.

• 여러 버전의 운영 체제와 서비스 팩 및 오래된 응용 프로그램에 대해 최소한도로 지원하거나 지원하지 않음
  여러 소프트웨어 및 하드웨어 버전을 다양하게 조합하여 한 가지 시스템이나 네트워크와 상호 작용하는 시스템에서 함께 사용할 때는 안정적인 지원을 제공하기가 어렵습니다. 신기술을 지원하지 않는 오래된 소프트웨어, 프로토콜, 드라이버 및 관련 하드웨어는 실용성이 떨어집니다. 새로운 운영 체제, 응용 프로그램 및 하드웨어를 계획, 테스트, 설치하는 데 필요한 리소스나 시간에 대해서는 여기서 다루지 않습니다. 소프트웨어 업그레이드를 계획할 때는 사용자와 협력하여 필요한 기능을 확인하십시오. 사용자가 간편하게 소프트웨어를 전환하도록 사용자를 교육하고 소프트웨어 및 지원 예산에 앞으로 필요한 응용 프로그램과 운영 체제 업그레이드 비용을 포함하십시오.

• 불안정한 응용 프로그램 격리
  불안정한 응용 프로그램은 업무에 반드시 필요하지만 안정성 표준에 맞지 않는 응용 프로그램입니다. 불안정한 응용 프로그램으로 작업해야 할 경우 다음 두 가지 방법을 사용할 수 있습니다.

  • 회사의 가장 중요한 서버에서 불안정한 응용 프로그램을 제거합니다. 불안정한 응용 프로그램을 발견하면 격리 조치를 취하고 업무상 중요한 서버에서 해당 응용 프로그램을 실행하지 마십시오.
  • 충분한 모니터링을 제공하고 필요할 때 자동 재시작 옵션을 사용합니다. 충분한 모니터링을 위해서는 정기적으로 중요한 시스템 성능 측정 스냅샷을 만들어야 합니다. 서비스 스냅인을 사용하여 응용 프로그램이나 서비스를 자동으로 다시 시작하도록 설정할 수 있습니다. Windows 서비스에 대한 자세한 내용은 Windows Server 2003 도움말의 "서비스 개요"를 참조하십시오.

• 표준화된 하드웨어 사용
  호환되지 않는 하드웨어를 사용하면 성능이 저하되거나 데이터를 잃을 수 있습니다. 새로운 시스템, 여분의 부품 및 대체 부품에 맞는 하드웨어 표준을 유지하고 준수하십시오.

• 앞으로의 용량 요구 사항을 위한 계획
  가용성 수준이 높은 시스템을 위해서는 용량 계획이 중요합니다. 현재 시스템에 있는 여유 용량을 알아 보려면 사용량이 최대일 때 시스템을 자세히 살피고 모니터링하십시오.

• 작업 절차 목록의 지속적인 업데이트
  루트 시스템 문제를 해결할 때는 작업 및 지원 일정에서 오래된 절차를 제거해야 합니다. 예를 들어 소프트웨어를 교체하거나 업그레이드할 때 특정 절차가 필요 없어지거나 더 이상 유효하지 않을 수 있습니다. 특히 일상적으로 수행되는 절차에 주의하십시오. 모든 절차가 필요하고 근본적인 원인을 찾지 못한 문제의 일시적인 해결책이 아닌지 확인하십시오.

• 적절한 모니터링 수행
  메시징 시스템을 적절하게 모니터링하지 않으면 문제가 심화되어 시스템 오류를 유발하기 전에 문제를 찾을 수 없습니다. 모니터링을 수행하지 않으면 응용 프로그램이나 서버 오류가 발생해야 문제를 발견할 수 있습니다.

• 대처하기 전에 문제의 특성 확인
  운영 부서가 제대로 교육을 받지 못하고 문제에 대처하기 전에 문제를 자세히 분석할 수 없을 경우 담당자는 문제에 맞지 않은 대응에 많은 시간을 소모할 뿐 아니라 맨 처음 문제의 징후가 나타나고 실제 오류가 발생한 시점 사이의 결정적인 시기에 모니터링 도구를 효과적으로 사용하지 못할 수도 있습니다.

• 증상이 아닌 문제의 근본 원인 처리
  오류가 발생하거나 단기적 예방 유지 관리를 수행할 때는 증상을 치료하여 서비스를 효과적으로 복원할 수 있지만 표준 작업 절차에 증상 치료를 추가하면 관리하기 어려워질 수 있습니다. 지원 담당자가 증상 치료에 시간과 노력을 낭비하여 새로운 오류에 적절히 대처할 수 없습니다.

• 오류 상황을 해결하려고 서비스와 서버를 중지 및 다시 시작하는 방법을 사용하지 않도록 주의
  경우에 따라서는 서버를 중지하고 다시 시작해야 하지만 문제가 일시적으로 해결될 뿐 근본 원인이 해결되지 않으면 다른 문제가 발생할 수 있습니다.

사전 테스팅 및 시험 배포

새로운 솔루션을 배포하기 전에 이 솔루션이 내결함성을 갖춘 하드웨어이거나 네트워크 하드웨어, 소프트웨어 모니터링 도구 또는 Windows 클러스터링 솔루션이거나 간에 프로덕션 환경에서 배포하기 전에 솔루션을 철저하게 테스트해야 합니다. 격리된 연구실에서 테스트를 거친 후에 몇몇 사용자에게만 영향을 미치는 시험 배포에서 솔루션을 테스트한 다음 필요에 따라 디자인을 조정하십시오. 시험 배포 결과가 양호하면 프로덕션 환경에 본격적으로 배포합니다.

Exchange 조직의 사용자 수에 따라 단계별로 본격적인 배포를 수행할 수도 있습니다. 각 단계를 마친 후 다음 사용자 그룹을 배포하기 전에 추가 사용자의 처리 로드가 증가해도 시스템에서 감당할 수 있는지 확인하십시오. 테스트 및 시험 배포 설정에 대한 자세한 내용은 Microsoft Windows Server 2003 Deployment Kit의 "Designing a Test Environment" 및 "Designing a Pilot Project"를 참조하십시오.

Exchange 용량 계획 도구

사용자 로드 관리에 필요한 Exchange 서버 수를 확인하려면 다음 용량 계획 도구를 사용합니다.

• Exchange Server Load Simulator 2003(LoadSim)
• ESP(Exchange Server Stress and Performance) 도구
• Jetstress

Exchange Server Load Simulator 2003

Exchange Server Load Simulator 2003(LoadSim)을 사용하면 MAPI 클라이언트가 Exchange에서 차지할 로드를 시뮬레이트할 수 있습니다. 클라이언트 컴퓨터에서 LoadSim 테스트를 실행하면 로드를 시뮬레이트할 수 있습니다. 이러한 테스트는 Exchange 서버에 메시징 요청을 보내서 서버에 로드를 가합니다.

이러한 테스트 결과를 사용하여 다음을 수행합니다.

• 클라이언트 로드 상태에서 서버 구성에 대한 클라이언트 컴퓨터 응답 시간을 계산합니다.
• 서버당 사용자 수를 예측합니다.
• 서버의 병목 현상을 확인합니다.

LoadSim 2003은 Downloads for Exchange Server 2003 웹 사이트에서 다운로드할 수 있습니다.

Exchange Server Stress and Performance 도구

ESP(Exchange Server Stress and Performance) 2003 도구는 확장성이 뛰어난 Exchange용 스트레스 및 성능 도구로 하나 이상의 프로토콜 서비스에 동시에 액세스함으로써 수많은 클라이언트 세션을 시뮬레이트합니다. 스크립트는 시뮬레이트된 각 사용자가 수행하는 작업을 제어합니다. 스크립트는 서버와 통신하기 위한 논리를 포함합니다. DLL(테스트 모듈)은 이러한 스크립트를 실행합니다. 테스트 모듈은 인터넷 프로토콜, API(응용 프로그래밍 인터페이스) 호출 또는 OLE DB와 같은 인터페이스를 통해 서버에 연결합니다.

ESP는 확장 가능한 모듈식 도구로 현재 다음을 포함한 대다수 인터넷 프로토콜의 모듈을 제공합니다.

• WebDAV
• IMAP4(Internet Message Access Protocol version 4rev1)
• LDAP(Lightweight Directory Access Protocol)
• OLE DB
• POP3(Post Office Protocol version 3)
• SMTP(Simple Mail Transfer Protocol)

ESP 2003은 https://go.microsoft.com/fwlink/?linkid=27881에서 다운로드할 수 있습니다.

Jetstress

Exchange 2003은 디스크를 많이 사용하는 응용 프로그램입니다. Exchange가 제대로 작동하려면 빠르고 안정적인 디스크 하위 시스템이 필요합니다. Jetstress(Jetstress.exe)는 관리자가 프로덕션 환경에서 Exchange 서버를 배포하기 전에 디스크 하위 시스템의 성능과 안정성을 확인하는 데 유용한 Exchange 도구입니다. Jetstress 및 Exchange 백 엔드 저장소에 대한 자세한 내용은 안정적인 백 엔드 저장소 솔루션 계획을 참조하십시오.

Jetstress는 https://go.microsoft.com/fwlink/?linkid=27883에서 다운로드할 수 있습니다.