Exchange Server 2013 강의: 4일차

2015년 1월 29일 윈도우 서버+가상화 333 조회 수

강의 메모 시리즈:

__고가용성 구성요소

애플리케이션과 인프라의 모든 부분이 의존하는 다음의 요소는 고가용성 구현이 필요

데이터 센터 인프라
서버 하드웨어
스토리지
네트워크 인프라
인터넷
네트워크 서비스

__DAG?

DB 사본 복제와 활성화를 위한 인프라를 제공하는 서버의 모음을 제공

DAG

Exchange 서버 관리 도구로 모든 설치와 구성을 하더라도, 장애조치 클러스터링 기능 필요
- 2008에서 사용하려면 Standard Edition은 안 됨
활성 관리자를 사용해 장애조치 제어
Exchange Server 2007에서 소개한 연속 복제 기술의 확장된 버전을 사용
사서함 서버가 설치된 후 생성
다른 DB에 영향을 주지 않고 해당 그룹의 또 다른 서버에서 단일 DB 활성화
별도 서버에서 단일 DB의 16개 사본까지 허용
복제 경계를 정의

__DAG 동작 방식 이해

연속 복제는 DAG의 여러 서버에 걸쳐 DB를 보호

RAID나 클러스터링과 비슷한 느낌.

__CAS에서 고가용성

여러 대의 CAS 부하 분산 구성

DNS 라운드로빈
네트워크/하드웨어 부하 분산
- 돈이 좀 있으면…

__전송 고가용성 이해

__Edge 전송 서버에서 고가용성 동작 방식 이해

Edge 서버 배포를 할 때에는 인증서를 만들어줘서 …

__사이트 복구(Site Resilience)란?

하나의 사이트가 장애라도 다른 사이트로 서비스

사이트 복구는 사이트의 실패를 살려주는 메시징 시스템의 기능이다.

대체 데이터 센터를 다른 위치에
DAG를 AD에 걸쳐 확장 가능
해당 사이트에 역할과 서비스가 이미 존재해야 한다

[ 고가용성 사서함 DB 구성 ]

__쿼럼(Quorum)이란?

쿼럼은 서비스 제공을 위해 충분한 클러스터 멤버를 사용할 수 있는지 확인하기 위해 투표자의 합의를 사용한다

멤버는 투표를 할 수 있다

Exchange 2013 DAG 쿼럼

Windows Server 2012에서 투표에 기반
쿼럼 모드에 따라 노드의 파일 공유, 공유 디스크에서 투표 가능
쿼럼을 위해 미러링 모니터 서버와 노드 과반수 사용
- 짝수의 사서함 서버를 가진 DAG는 미러링 모니터 서버(witnesss server) 사용
  - 카스 서버 중에서 한 대를 만들 수 있음
- 홀수 사서함 서버를 가진 DAG는 노드 과반수(node majority)를 사용

필요하다면 투표하지 않는 노드를 가질 수 있다.

__DAG를 구성하기 위한 소프트웨어 및 하드웨어 구성요소 계획

일반 구성

동일한 도메인 노드
도메인 컨트롤러가 아니어야 함

2008 Datacenter, Enterprise 필요

네트워크 구성

DAG용 네트워크 어댑터가 있어야 함
- 복제용 네트워크를 따로 빼기 위해서 IP와 네트워크 카드가 필요한 것임
- 허브 스위치가 따로 필요
대기시간 250ms 미만

DAG MAPI 네트워크에서 하나의 IP를 가져야 함

미러 모니터링 서버

※ DB서버는 네트워크 포트가 넉넉한 것이 좋다

__활성 관리자란?(Active Manager)

DAG의 각 서버에서 프로세스 실행

한 노드는 PAM
남은 노드는 SAM

어떤 DB 사본이 액티브이고 어떤 사본이 패시브인지 관리

DB 상태 정보를 저장

DB 전환(switchover)과 장애조치(failover) 프로세스 관리

DB 고가용성: switchover
서버 고가용성: failover

직접 관리 구성이 필요하지 않다

※ Exchange 2010은 한 DB에 장애가 나면 Passive 가 두개 있을 때 아무것이나 살림. 2013은 리소스를 봐서 부하를 덜 받는 곳을 active로 만듬.

__연속 복제(Continuous Replication)?

DAG의 핵심: 데이터 일관성…

File Mode: 로그 파일을 이용하는 모드

Block Mode: 트랜잭션 로그가 버퍼에 기록됨. 메모리 단위로 넘어감. 버퍼가 다 찰때까지 각각의 서버로 동기화되다가 비워지면 … 이게 File 을 이용했을 때보다 빠르죠

__DAG 구성

DAG 구성을 위해 다음을 정의해야 한다

Witness 서버
Witness 디렉터리
DAG IP 주소 – DAG가 사용하는 IP 주소

대규모 또는 멀티 사이트 구현을 위해 다음 설정을 추가 구성(Large Scale일 때, 외부에 서비스하겠다고 했을 때)

복제를 포함하는 DAG 네트워크
DAG 네트워크 압축
DAG 네트워크 암호화
등등

__DAG 구성

DAG 생성, DAG에 사서함 서버 추가, DAG 구성 후에…

DB 복제 생성

활성화 기본 설정 번호 설정
- 우선 순위에 따라 동작
재생 지연 시간 설정
- 트랜잭션 로그가 재생되는 것을 지연
자르기 지연 기간 설정

__지연 사서함 데이터베이스 복사본이란?(Lagged Mailbox Database Copies)

하나의 카피를 지연 카피를 만들어 놓고 24시간 지연해놓으면 다른 DB와 24시간 차이가 나니까. 문제가 발생했을 때 이 하나를 가지고 복구를 시킬 수 있죠. 하루의 차이는 트랜잭션 로그 등을 찾아 동기화 시켜주면 됨.

지연 데이터베이스는 데이터베이스에 로그 파일을 커밋하기 위해 지연된 재생 지연 시간(replay lag time)을 사용하는 DB

지연 DB를 만들어 다음을 방지

DB 논리적 손상
저장소 논리적 손상
잘못된 관리에서의 보호(Rogue Admin Protection)

__DAG 구성

클러스터링과 비슷하게 논리적인 컴퓨터를 만들어야 함, 설정하면서 자동으로 사용되기 때문에 disable. 해당 논리 컴퓨터에 Security 권한을 주고 ECP에 들어감. DAG 메뉴에 가서 새로 만들기. 모니터 서버를 CAS1으로 해주고 Witness 디렉터리를 만들어 정보 저장. DAG IP를 줌. 이러면 DAG 그룹이 만들어짐.

멤버십을 설정(DAG 그룹에 포함될 MBX 서버)해서 MBX 서버들을 선택. 이러면 MBX 1과 2에 Cluster를 올림. 이것이 정상적으로 잘 올라가야 함. 만약에 실습 환경에서 잘 안만들어지면 MBX 서버의 Exchange 관련 서비스(앞의 2개 빼고 모두) Restart 해보라고.

Successfully 되면 DB 사본을 만듦. Add database copy 명령을 씀. 적절한 MBX 서버를 선택하고 Activeation Preference Number 지정. DB 사본이 만들어지겠죠.

다 되면 Test-ReplicationHealth 로 체크

Get-MailboxDatabaseCopyStatus -Server LON-MBX1

해당 서버에 대한 복제 상태에 대해 보여줌

checkdatabaseRedundancy

※ Failover 클러스터링을

__장애조치(Failover) 프로세스 이해

실패가 발생하면, 실패한 DB에 대해 다음의 단계가 일어남

Active Manager에서 활성화할 최적 사본을 결정
대상 서버의 복제 서비스에서 최적의 source로부터 잃어버린 로그 파일 복제를 시도
- 성공: 해당 DB는 데이터 손실 없이 마운트됨
- 실패: 장애조치, 해당 DB는 AutoDatabaseMountDial 설정을 기반으로 마운트됨
마운트된 DB는 새로운 로그 파일 생성(동일한 로그 생성 시퀀스 사용)
..(다 못적음 ㅠㅠ)

__DAG 계획과 모니터링, 관리

DAG 관리를 위한 필요 권한 할당

조직 관리
DAGs
DB 복사본

실패가 통지되지 않을 수도 있다

왠만한 작은 오류는 서비스를 재시작하는 등의 과정을 거치면 해결되기 때문에 자가 힐링으로 복구 시도해보고 안되면 통지함

Exchange Server 2013은 DAG 모니터링과 관리를 위한 몇 가지 스크립트와 명령을 포함

DAG를 설치하면 관련 PowerShell 스크립트 파일이 생겨서 사용해볼 수 있음
- Progra~1\Exchange Server\V15\Scripts

System Center Operations Manager 2012 Sp1의 사용 고려

[ 고가용성 CAS 구성 ]

※ CAS는 로드밸런싱. 윈도우 서버에 소프트웨어 로드밸런서 기능도 있다고 함.

※ DNS를 만들 때 동일한 이름으로 여러 개의 IP를 줌(돌아가면서 순서대로 적용됨)

DNS 라운드 로빈: 돈이 없을 때, L4 로드밸런서가 있으면 더 좋음.

__CAS 고가용성 계획

CAS는 모든 클라이언트에서 사용됨

__네트워크 부하 분산이란?

NLB를 사용하면 전형적으로 웹 기반 서버 애플리케이션에 고가용성과 확장성을 제공할 수 있다
NLB로 하나의 IP주소로 두 대 이상의 서버에 접근 가능
NLB는 NLB 클러스터의 모든 서버에서 동일한 구성으로 같은 서버 애플리케이션을 실행해야 함
클라이언트 요청은 공통 알고리즘을 기반으로 NLB 클러스터의 가용한 서버들에 의해 분산됨
..

__고가용성 CAS 구현 고려사항

모든 CAS 서버에 인증서
모든 CAS 서버는 동일한 프로토콜을 사용
하드웨어 or 소프트웨어 로드 밸런서를 사용
4계층 또는 7계층 부하 분산 사용

__고가용성을 위한 CAS 구성 옵션

[ 재해 복구 계획과 구현 ]

※ 백업 및 복구

__데이터 손실 시나리오

개별 항목 손실
사서함 손실
DB 손상
서버 손상

__데이터 손실 완화 기능

데이터 손실 완화는 백업으로부터 복구의 필요성을 피하게 해준다

데이터 손실 완화에 포함되는 것

삭제된 항목 복구
단일 항목 복구
원본 위치 유지
- 법적 보존 e-discovery
삭제된 사서함 보존
- 바로 영구삭제 하지 않고 일정 기간동안 유지
DAGs
- 일종의 손실 완화 기능 – 사서함이 문제있을 때 다른쪽을 쓸 수 있게
섀도우 중복성

__재해 완화 전략 계획

고려사항에 포함할 것들

삭제된 항목 보존 증가는 DB 크기의 증가
삭제된 사서함 보존 증가는 DB 크기의 증가
DAG는 DB손상과 서버 손상에 대한 서비스 중단 방지
재생 지연 시간(Replay Lag Time)으로 DAG의 패시브 사본에 데이터 손상이 발생하는 것을 방지

__Exchange 서버 자체 데이터 보호

자체 기능

고가용성
단일 항목 복구와 원본 위치 유지
지연된 사서함 데이터베이스 사본으로 적기 데이터베이스 복구
대용량 사서함 관리를 위한 보관 사서함, 보존 및 보관 정책, 원본 유지 eDiscovery
- 스토리지 자체에서 WORM(Write Once, Read Many를 지원하는지가 관건) 국제 규격을 만족하는 장비
- 앞으로는 eDiscovery와 Archiving이 중요해짐

Exchange 자체 데이터 보호로 비용을 줄여주는 요소

단순화된 관리
백업 소프트웨어나 하드웨어 필요 없음
- DAG만 잘 되어도…
RAID 필요 없음

__재해 복구를 위한 타임라인

RTO(Recovery Time Object)에서 다음을 결정

복원되는 시간
얼마나 빨리 복원되는지

RPO(Recovery P O)

어떤 시점으로부터 재해 복구가 수행되는가
복원되는 양
RPO가 0라는 말은 데이터 손실이 있으면 안된다는 말
RPO가 10시간이면 복원되는 사이의 데이터(10시간)는 날아감
- 10시간 전 1번 백업, 복원 시 10시간 전의 데이터로 복원하게 됨

RTO와 RPO를 기반으로…

복원 시간을 짧게 하기 위해 DB를 작게 유지
로그를 별도의 드라이브에 저장

__백업과 복구가 필요한 시나리오

시나리오

단일 항목 복구 사용이 설정되지 않았을 때 메시지를 복구
사서함 보존 기간이 경과했을 때 사서함을 복구
항목 보존 기간이 경과한 공용 폴더를 복구
DAG를 사용하지 않을 때 실패한 데이터베이스를 복구
DAG를 사용하지 않을 때 실패한 서버를 복구

백업을 통해 규정 준수 요구사항에 맞출 수 있다

[ 백업 계획 및 구현 ]

백업 요구사항

Exchange 서버 역할	백업되는 데이터.
전체 역할	서버의 시스템 상태와 DC의 AD 데이터베이스.
MBX서버	데이터베이스와 트랜잭션로그. 메시지 추적 로그 UM 사용자 지정 음성 안내.
CAS서버	IIS구성 인증서

__백업 소프트웨어 선택

Windows Server 백업

Exchange Server를 실행하는 컴퓨터에서 로컬로 실행
테이프로 백업 못함
전체 DB만 복원
패시브 DAG 사본을 백업할 수 없음
- Active DAG만 됨

DPM(Data Protection Manager)

Exchange Server를 실행하는 컴퓨터에서 에이전트 사용
전형적으로 디스크에 백업 후 테이브로 아카이빙
DB나 사서함을 복원할 수 있음
패시브 DAG 사본을 백업할 수 있음

3rd Party

VSS 를 지원해야 함
개별 항목 복원
브릭 수준(brick-level) 백업 수행

__백업 미디어 선택

미디어	설명.
테이프	물리적으로 이동하기 쉽고 내구성이 좋음. 싸다. 느리다. 마지막 백업 용도로 씀.
디스크	백업 성능을 높일 수 있음. 빠르지만 비쌈
SAN-기반	주 네트웍의 백업 트래픽을 SAN에서 유지 가능. 더 비쌈.

__VSS 백업 동작 방식

Exchange 2013과 VSS 백업 관련 서비스

Exchange Information Store
Exchange Replication
Volume Shadow Copy

※ 백업 후 이벤트로그 중에서 2021, 2110 을 확인하면 좋음

__Exchange 기능 복구를 위한 옵션

유실된 서버 역할 대체 방법

동등한 기능을 갖춘 새로운 서버를 만든다
기존 Exchange 서버에 역할을 추가한다

손실된 서버를 복원하는 방법

새로운 서버를 만든다
- OS 새로설치하고 기존 설정들이 복원
시스템 상태를 복원한다(optional)
복구 모드로 Exchange Server 설치
- Exchange 자체를 복구 모드로 설치
모든 데이터 복원

__MBX 데이터와 DB 복구 옵션

옵션	설명.
DB 복원	기존 DB 대체
DB 복구	데이터 복구를 위해 DB를 대체 위치에 복원.
DB 이식성	특정 서버를 복구하지 않고 DB 복원.
발신음 복구	이력 사서함 콘텐츠가 복원되기 전에 서버 기능을 신속하게 복원
DAG 복구	다른 MBX에 마운트

__고려사항

DAG를 써서 복구할 일 자체를 많지 않게 만들기

트랜잭션 로그와 데이터베이스 분리

복구 데이터베이스용 디스크 공간을 마련해라

사서함 데이터베이스를 보다 적은 크기로 사용

동기화 및 백업/복구에 시간이 많이 걸리지 않도록.

__CAS 복구 계획

CAS의 기본 기능은 기존 서버 백업 없이 복구 가능

실패한 CAS를 대체

__Exchange 서버 데이터베이스 손상 복구

New-MailboxRepairRequest

예전(2003,2007)에는 isinteg.exe 썼는데, 이것보다 낫다.
- 데이터베이스가 오프라인되지 않아도 된다
- PowerShell로 해당 프로세스를 자동화 가능

__복구 데이터베이스를 사용한 데이터 복구 프로세스

※ 기존 백업에서 마운트, 추출, 복구

복구 DB 시나리오

발신음(Dial-Tone) 복구
개별 사서함 복구
특정 항목 복구

발신음 복구란?

사용자 사서함에 데이터를 복원하지 않고 임시 사서함을 만들어주고 우선 쓰게 해준다음 백그라운드에서 복원해 그것으로 갱신해줌

발신음 복구 구현 절차

발신음 DB 생성
필요한 경우 새로운 발신음 DB를 사용하도록 실패한 DB 사서함을 구성
복구 DB에서 복구하고자 하는 DB와 로그파일 복원
이전단계에서 복구한 DB와 발신음 데이터베이스를 바꿈
발신음 DB의 콘텐츠를 내보내고 복구된 원래 DB로 가져오기 함

[ 메시지 전송 계획과 구성 ]

메시지 전송 서비스

Exchange 2013의 메시지 라우팅 변경사항

라우팅에서 DAG를 인식
전송 서비슨는 MBX 서버에서 실행
원격 대상에 대한 큐 작업이 보다 정확함
연결된 커넥터는 사용되지 않음

라우팅 대상과 배달 그룹

라우팅 대상(메일이 전달되는 대상에 대한 경로)

사서함 DB
커넥터
- 송수신 커넥터 포함
메일 그룹 확장 서버
- Sales 그룹의 멤버들을 보내주는 역할을 하는 녀석이 메일 그룹 확장 서버임. Default는 지정하지 않아 전체가 메일 그룹 확장 서버이지만, 지정하게 되면 그 녀석만 해당 역할을 함

배달 그룹(Delivery Group): 배달의 경계가 되는 것

라우팅가능한 DAG
- DAG 그룹이 여러 개 있을 수 있으니 먼저 DAG1, 2중 어디로 가야 하는지 판단
사서함 배달 그룹
- MBX 서버들, 예를 들면 2007 MBX 서버, 2010 MBX 서버, 2013 MBX 서버들을 이야기
커넥터 원본서버
- 커넥터를 제공해주는 서버
AD DS 사이트
- 사이트를 걸쳐 놓을 수 있는데, 사이트가 많을 때 A 사이트에 들어온 메일이 실제 B에 가야한다고 했을 때 A 사이트 자체가 배달 그룹이 되는 것이죠.
서버 목록
- Exchange 서버 하나하나 별로 들어가고 …

※ 메일이 계층별로 들어간다는 말이죠. 탐색기를 확장하듯 큰 범위로 들어가서 줄이고 줄이고 해서 타깃을 찾아감

__SMTP 트래픽

MBX에서 메일을 보내요
메일 제출 서비스에서 Send 로 나가죠. 다른 서버가 있으면 Hub Transport 리시버가 받고, Queue에 들어가 카테고라이저에 들어가 내부 사용자면 내부 서버의 어디라고 판단 후 딜리버리 큐에 들어가서 다시 Send에 들어가서 메일 DB에 들어가는 식으로 . 들어오는 것은 반대가 되겠죠.

__프론트엔드 전송 서비스의 라우팅

__전송 서비스의 라우팅

__기본 메시지 흐름 수정

__SMTP 메시지 배달 트러블슈팅을 위한 도구

큐 뷰어

배달되지 않은 메시지를 확인하고 관리하는 데 사용

메시지 추적 & 추적 로그 탐색기

메시지가 잘 배달되었는지

프로토콜 로깅

프로토콜 단에서 나오는 로그 확인 가능. 로그가 많이 쌓이니 필요에 따라 하는 것이 좋다.

텔넷

SMTP 포트가 응답하는지 여부를 확인하거나 커넥터에 직접 SMTP 메일을 보내는데 사용

원격 연결 분석기 웹사이트

인터넷에서 Exchange 서비스에 대한 연결을 시험하는데 사용

※ SCL: 스팸 지수

NDR(No Delivery Report)을 보내주지 않는 것이 낫다. 스패머들이 수집하기 때문에.
- 내부에서 내부로 보낼 때는 상관없다.

__전송 에이전트(Transport Agent Service)

기본 전송 에이전트

전송 규칙 에이전트
- 원본 메일 + 커스텀 메시지(에이전트에 의해 자동으로 작업됨)
저널링 에이전트
- AD RMS 라이선스 에이전트

※ 개발해서 커스텀 에이전트를 만들 수 있음

※ Exchange Server 2010 도움말을 chm 파일로 내려받아 놓자.

책보다 저 자료가 더 좋다.
http://www.microsoft.com/ko-kr/download/details.aspx?id=1573

__Exchange 메시지 전송 계획하기

※ 메일이 흘러다니는 흐름에서 규칙이나 방향을 조정

메시지 전송 관리할 수 있는 곳

CAS 서버
MBX 서버
Edge 전송 서버
3rd Party 게이트웨이

메시지 전송을 계획할 때 다음을 고려

전자메일 도메인
- 당연.
초기에 SMTP 연결을 수락하는 위치
- 접점이 되는 SMTP 연결. 내/외부
SMTP 트래픽 검사
SMTP 릴레이 필요성
- 거쳐서 발송되게끔 하는 것
조직 내부에서 SMTP 트래픽
보안 SMTP 트래픽
SMTP를 사용하지 않는 시스템과의 통신

※ 공지나 이벤트성 페이지 등을 담은 메일을 다량 발송하는 서버는 사내 Exchange와 연결하면 안 됨.

__허용 도메인과 원격 도메인 계획하기

허용 도메인은 Exchange 서버가 전자메일을 수락할 SMTP 도메인 이름을 정의

신뢰할 수 있는 도메인
1. Adatum.com 등 MX 레코드에 등록된 값
내부 릴레이 도메인
1. KT 그룹사인데 자회사는 contoso.com 이고 bbb.com 임. 바깥 방화벽 안에 다 들어갔을 때 서로간에 contoso.com은 CAS단에서 송신커넥터를 만들어 bbb와 연결하고, bbb.com은 contoso.com의 송신커넥터를 만들어 연결
외부 릴레이 도메인
1. Samsung.com과 apple.com의 관계. 전혀 다른 회사. 메일을 보낼 때 중간에 누가 가로챌 수 있으니 지정해서 우리끼리 주고받자. 두 곳이 커넥터를 연결해 받음.(송/수신 커넥터)
2. 정보가 유출되면 반사이익을 얻는 곳이 있어서 서로 신뢰할 수 있도록 …

원격 도메인은 Exchange 조직의 외부의 SMTP 도메인을 정의

원격 도메인에 설정 가능한 속성