Exchange Server 2013 강의: 1일차

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

강의 메모 시리즈:

집에서 홀로 끙끙대며 보던 강의를 직접!

※ 꼭 가상화와 클라우드를 필수적으로 붙어야 하는 단어라는 생각은 하지 않는 것이 좋다.

Microsoft Official Course

Core Solution or Advanced 두 가지 코스가 있음

[배포와 관리]

백오피스: 링크, 익스체인지 등을 아울러 말함(사무 환경)
클라이언트 오피스: excel, powerpoint, outlook 등

__Active Directory

Exchange Server를 사용하려면 Active Directory의 이해가 필요하다.
AD 인프라 없이는 사용 불가능.
AD는 데이터베이스. 층이 나누어져 있다. 계층화되어 있음.
포리스트는 익스체인지 조직과 매칭이 됨
스키마는 청사진, 설계도라는 뜻.

AD 개체에 Exchange 특성값을 붙임. (Exchange 설치 전에는 그런 값이 들어가 있지 않음)

Ex) smtp address

익스체인지가 올라가고 나면 사용자를 만들 때 smtp address를 만들 수 있도록 공간을 미리 할당 – 스키마의 역할

AD에 설정을 넣어놓고 여러 Exchange 서버에서 이를 활용. 동일한 정보를 활용하게 됨.

중요한 정보를 인덱싱한 글로벌 카탈로그를 exchange에서 활용.

메일 사용 개체와 사서함 사용 개체에 대한 Exchange 개체 특성

__Exchange에서 사용하는 DNS 요구 사항

AD 의 DNS는 Internal DNS로 두고, External DNS를 또 별도로 사용하는 경우가 많음

Exchange Server 2013은 DNS의 SRV 레코드를 가장 먼저 찾음

AD DC를 찾는 듯.(사용자 개체를 찾는 등의 활동을 위해)

Host 레코드(A 레코드)

Exchange 서버가 AD에 조인되어 있어야 함. 서버들을 찾는 데 DNS를 사용.

MX 레코드

Smtp 서버에 대한 메일 교환 레코드가 등록되어 있어야 함

기타

SPF와 Sender ID에 추가 DNS 레코드가 필요할 수 있음.
- 메일 헤더에서 확인 가능하다고 함

__설치 요구사항

2008 R2 이상에서 설치 가능
2008 R2 Standard 에는 MBX는 안 됨.(클러스터링 기능이 없어서)
2008 R2에 설치할 때는 추가 컴포넌트들을 많이 설치해야 함
NTFS 파일 시스템을 사용해야 함
도메인 및 포리스트 수준은 2003 이상을 사용해야 함(타임머신은 없다)
DC와 GC를 찾기 위해 DNS 서버가 반드시 있어야 함

__설치 매개 변수

GUI로 할 수도 있지만 무인설치 시 사용
KT도 CAS, MBX 각각 8대씩이라고 함.
삼성에서 Exchange 서버가 총 500대 정도라고 함
완전히 새롭게 설치할 때는 매개 변수 안써도 됨.
기존의 레거시 환경에 들어가니까 준비를 해줘~라는 의미

/PrepareAD 등
미리 자리 마련해줘! 라는 뜻

__Exchange Server 역할

MBX, CAS 두 가지임

SP1에서 Edge가 추가됨

경계구간의 SMTP Gateway 대신 Edge 서버를 올릴 수 있음.

예전 2010때는 5가지 역할이 제공됨

소프트웨어는 앞서갔는데 하드웨어가 따라가지 못함
- 하드웨어에 한 번에 다 올릴 수가 없었다.
지금은 하드웨어 성능을 제대로 뽑아냄.
Role과 Role 간의 의존성을 줄일 수 있어 지금이 이득

※ 2016버전을 위해 백오피스들도 새롭게 나올 예정.

CAS(웹 서버)

클라이언트 인증
리디렉션과 프록시 서비스
클라이언트 프로토콜(HTTP, POP, IMAP, SMTP)을 위한 지원

MBX(데이터베이스)

MBX와 공용 폴더 DB
전송 서비스
통합 메시징

클라이언트 연결은 RPC over HTTPS를 사용한 연결만 성립됨

사용자단에서는 443포트만 있으면 됨.
RPC 통신을 HTTPS로 캡슐화해서 사용
거의 10년 정도 종속되 있던 RPC에서 벗어남

__배포 옵션

Exchange 자체도 2가지

Standard
Enterprise

Exchange CAL

Standard
Enterprise

기본적인 아카이빙 솔루션을 Exchange에서 제공하지만, Enterprise를 사용할 때 가능.(함정!)

※ 온프레미스 익스체인지 서버 가격 = 윈도우 서버 라이선스+서버의 CAL 라이선스 + Exchange 라이선스 + 익스체인지의 CAL 라이선스

※ 다 귀찮으면? Office 365를 사용하면 됨.

현재 Office 365를 많이 쓰는 곳은 학교, 게임 회사라고 보면 됨
교직원은 온프레미스, 학생들은 Office 365.
집에서는 연간 구독권을 사서 쓰면 편하다.

배포 시나리오

단일 서버 배포(교재에 필기한 B)
다중 서버 배포(A)
하이브리드 배포(365와 섞어 씀)

__하이브리드 배포

메일 주소가 하나로!

공유 도메인 사용, 라우팅도 자동으로 되도록(온프레미스 계정과 Office 365 계정을 자동으로)
통합 전체 주소 목록
약속 있음/없음 및 일정 공유
메일 흐름의 중앙 통제
단일 OWA URL(이것도 Office 365/온프레미스 구분하여 자동으로)
기존 사서함을 클라우드로 이전하는 기능(이것도…)
중앙화된 사서함 관리(ECP인 듯)
클라우드 기반 메시지 아카이빙(Office 365에서도 아카이빙, 저널링 가능)

하이브리드 배포를 위한 추가 구성요소

Federation Gateway(Office 365와 AD의 포리스트 간의 관계를 맺어줌)
- ADFS Proxy와 동일
AD Synchronization(계정 단일화)
- 사용자 계정은 온프레미스에서 관리하고, Office 365로 프로비저닝

__온프레미스 vs 하이브리드

TechNet의 그림을 확인

__업그레이드와 마이그레이션 옵션

2003과 그 이전 버전	지원 안 함(빅뱅 마이그레이션 필요. 완전 새롭게 설치해서 옛날 데이터를 불러와야 함.)
2007	지원.(사전 구성이 좀 필요하긴 함. 인증서와 관련된 항목들. Exchange Team Blog를 참고하면 좋음)
2010	지원.(따로 해줄 것이 별로 없음)

※ 2003 -> 2007 -> 2010 이런식으로 올릴 수는 있으나 단계별 문제가 있을 수 있음. 그래서 2003을 완전히 버리고 새로 설치해서 옮길 것인가? 등을 고민해야 함

__VM 으로 배포하기

대규모 환경에서는 물리 머신을 쓰는 것이 좋음

VM의 성능 저하가 있을 수 있기 때문
소규모에서는 좋음

VM에서 스냅숏 사용 금지

AD 인프라는 다 그래요~
- 큰일날 수 있음
자체의 고가용성 기능을 사용해야 함
- CAS: L4 로드밸런싱, MBX: 클러스터링
- Hyper-V에서 제공하는 고가용성을 섞어서 사용하지 마라.

__설치 단계

업데이트 검사
라이선스 동의
권장 설정
서버 역할 선택
설치 공간과 위치
1. 설치 공간도 중요!
2. 운영체제 볼륨에 로그가 많이 쌓여서 공간이 부족한 상황이 발생할 수 있다.
Exchange 조직
멀웨어 보호 설정
1. 최초 설치때는 껐다가 설치 이후에 켜도 된다고 함
준비 검사

__무인 설치 방법

__설치 이후 작업

서비스 기능 확인

Exchange Server의 보안 설정

물리적 액세스 제한
통신 제한
공격 받을 수 있는 취약점 축소
권한 제한

추가 소프트웨어 설치와 구성

안티바이러스
- Forefront 권장
안티스팸
백업 소프트웨어
- System Center의 DPM 권장
모니터링 도구와 에이전트
- System Center Operation Manager 권장

※ 익스체인지 서버에는 딱 익스체인지만 설치!

Windows Server는 1 Server 1 Role을 권장

__설치 트러블슈팅

ExchangeSetupLogs 폴더에서 로그 파일 확인

꼭 확인할 것. 나중에 문제가 생길 수 있음.

일반적인 이슈 확인

디스크 공간 부족
소프트웨어 구성요소 누락
잘못된 DNS 구성
잘못된 도메인 기능 수준
AD 권한 부족
Exchange 권한 부족

[ Exchange Server 2013 관리 ]

__Exchange Server 2013 관리 방법

※ 2010과는 큰 차이가 있음: 관리 콘솔이 웹이라는 점.

EAC: Exchange Administration Center
OWA: Outlook Web Apps 옵션
EMS: Exchange Management Shell(PowerShell+Exchange Module)

__OWA로 사용자 사서함 속성 관리

※2010과는 달리 OWA가 Outlook에서 제공하는 거의 대부분의 중요 기능을 함께 제공하는 쪽으로 발전 중

사용자는 Outlook Web App을 사용해 다음 기능을 관리할 수 있다.

OWA 설정
받는 편지함 규칙
메시지 추적
사이트 사서함
모바일 기기
텍스트 메시징(SMS로 메일 알림)
그룹 멤버십
삭제된 메시지 복구
차단 및 허용 목록
암호 변경
앱 관리

__PowerShell이란?

개체 기반 관리 환경이다.

윈도우 환경에서 자동화나 벌크 작업 시 괜찮은 툴이 부족한 아쉬움을 극복

※ 결과물이 텍스트가 아니라 개체임. 파이프라인을 이용해 마음대로 출력 형태를 변경 가능

다음의 작업을 가능하게 해줌

자동화 스크립트 생성
배치 수정 수행
GUI에서 수정할 수 없는 설정에 액세스

PowerShell이 MS의 GUI관리의 토대를 제공

※PowerShell은 기본적으로 ‘엔진’임

IIS를 올리면 PowerShell에서 IIS 관련 명령을 추가로 사용 가능.

※ DevOps! 꼭 몸값의 부분이 아니더라도 자신의 작업을 자동화하고 도구를 스스로 만들어서 더 편리하게 업무 가능.

__PowerShell 구문

Cmdlet 이름은 동사와 명사의 쌍

Get + EventLog
Set + ExecutionPolicy
New + VM

Cmdlet 매개 변수로 동작을 수정하고 구성 정보를 제공. 매개 변수에 포함되는 내용은 …

Named
- -EventLog System, -UserName John
Switch
- -Verbose, -Debug, -Confirm(확인)
Positional(위치 매개변수)
- Get-EventLog System
- Get-EventLog -LogName System

※ get-help cmdlet

Get-help New-ADUser –FULL -ONLINE
- -FULL: 전체 내용 보기
- -ONLINE: TechNet 웹 사이트의 최신 정보를 보여줌

공통 매개 변수

-WhatIf: 어떤 변경이 있는지 시뮬레이션만 해봄
-Debug
-Verbose
-Confirm: 한번 더 물어봄

__도움말 액세스

Get-Help 또는 Help

또는 Get-EventLog -help 가능

※ Get-Help와 같이 Get-으로 시작하는 것은 Get-을 생략 가능하다고 함!

별칭

ls와 dir은 Get-ChildItem의 Alias.
Get-Alias를 입력하면 별칭을 알 수 있다.
- Get-Command -Noun *alias
  - -Noun: 명사 부분만 알 때 사용
  - -Verb: 동사 부분만 사용할 때

※ 도움말 업데이트 가능

__Exchange Management Shell 이란?

RBAC 권한 적용

시스템의 권한에 따라 쉘의 권한이 제한됨

※ 연락처를 만들면 전체 Exchange 사용자들이 해당 연락처를 공유 가능. 협력사 메일 주소를 추가해 놓으면 편리.

※ Get-MailboxSatistics -Server lon-ex1 : 현재 메일박스 서버 상태 확인

[ MBX 서버 계획과 구성 ]

__MBX 서버 역할

MBX 역할

사서함 데이터베이스 호스팅
공용 폴더에 대한 호스팅
- 데이터를 공유하는 폴더 개념
전송과 메시지 라우팅 서비스(메시지가 흘러가는 경로에 대해 컨트롤)
- 허브 전송 서비스
- 사서함 전송 서비스
통합 메시징 서비스
고가용성 서비스

※ 클러스터링을 시스템에서 설치!(고가용성을 구성하면)

MBX 서버 역할 기능 향상

DAG를 위한 트랜잭션 로그 개선
향상된 사이트 복구

※ Exchange가 여러 사이트에 걸칠 수 있는데,

※ 사이트에는 DC가 있는 것이 좋다.

네트워크의 속도가 다르면 서브넷을 나눠 사이트를 분리하는 것이 좋다.

__MBX와 클라이언트 및 CAS가 상호작용하는 방식

CAS: 상태의 비저장
MBX: 상태의 저장

분류: 메일 헤더를 보고 판단

내부 주소로 보내고 받는 경우 MBX 서버 내에서 끝남

※ Pickup Directory와 Replay Directory

2-3 그림을 잘 확인!

__MBX 저장소

파일 구성

Edb
Log
Chk
Tmp.edb
E##Res00001.jrs

※ 백업된 DB에서 특정 메일만 빼고 싶을 때 관련된 유틸리티를 사용하면 됨. System Center DPM을 사용해도 좋음.

__DB 로그 고려사항

DB에 변경이 커밋되기 전에 트랜젝션 로그에 로깅됨

각 트랜잭션 로그 파일의 크기는 1MB

트랜잭션 로그 파일은 자동으로 삭제되지 않는다.

순환 로깅은 기존 것을 바꾸는 방식이라 권장하지 않음

로그 파일에 대해서는 다음의 가이드라인 참고

정기적으로 Exchange Server 백업 수행
트랜잭션 로그를 전용 드라이브로 옮기자
중복 디스크 어레이에 트랜잭션 로그 파일을 놓는다
로그 디스크에 충분한 여유 공간
로그 디스크에 압축을 사용하지 말 것

__MBX 업데이트 방식

메시지 수신
메시지 기록
1. DB와 버퍼 두 곳에 기록됨
DB에 기록
업데이트(잘 기록되었다고 체크함)
클라이언트 액세스(클라이언트에서 메일을 볼 수 있음)

※ 트랜잭션 로그가 쌓이는 디스크를 포맷하는 사이즈를 어떻게 할 것인지 생각할 수 있다. 4096으로 하면? 1byte가 만들어져도 4096을 차지함.

※ Active Directory도 EDB 기술을 사용함. Microsoft 젯(?)데이터베이스 엔진을 쓴다고 함.

__스토리지 옵션

MBX만 고려하면 됨.

디스크 스토리지 옵션

DAS : 서버에 직접 연결하는 스토리지
SAN
- 급이 여러 가지다. 예전에는 high-end급 고가의 SAN을 썼지만, 지금은 저렴한 것을 써도 괜찮다.

※ 인프라(네트워크)만 좋으면 NAS를 쓸 수 있음.

10G 망에서는 로컬 스토리지보다 빠를 수 있다.

RAID 옵션

JBOD: 이기종의 디스크를 하나의 큰 덩어리를 논리적으로 나눠쓸 수 있음. 하지만 장애가 나면??
- MBX 고가용성을 필수로 해줘야 함.
RAID 5와 0+1을 많이 씀. 보통 RAID 5를 쓴다.

__MBX 데이터베이스에서 데이터 가져오기와 내보내기

사용자 사서함 데이터를 .pst로 내보내거나 사용자 사서함으로 .pst를 가져올 수 있다.

New-MailboxImport/ExportRequest
- Mailbox Import Export 역할을 해당 작업을 수행하는 사용자에게 할당해야 함

[ MBX 서버 배포 계획하기 ]

__MBX 하드웨어 계획

CPU

64-bit
Multicore 권장
코어 하나 당 1,000 액티브 사서함

※ 고가용성 구성 시 패시브 사서함도 있음

Memory

사서함 서버 당 최소 8GB
50 메시지/day 당 3MB

※ 최소 8GB + 메시지 당 메모리 더해줘야 함

※ 사서함 사용량은 삭제된 메일이 보존되는 기간을 감안해서 계산해야 함

Ex)

34,000 mailbox 기준으로 서버 당 4,250 mailbox를 사용할 때, 사용자 당 사서함 1GB씩 할당.

솔루션 제작자 권장 산식

1인당 하루 수/발신량

수신: 40개, 발신:160개

메일 사서함을 위한 스토리지 디스크 용량 게산식

실제 메일 DB와 로그가 저장되는 곳 RAID 1+0 권장
Restore Space: Raid 5
DB Growth Factor: 20%
Transaction Log Space factor: 15%
Free Space factor: 20%(순수 여융공간.)
Restore Space factor: one of active(MDB)

필요 스토리지 디스크 용량 계산

사서함 서버 1대 장애 발생시 7개의 서버로 운용이 가능한 저장공간

1GB*4250MBX*2(active,passive)=8.3TB
DB 증가량(20%): 8.3TB*1.2=9.96TB
Tx log space factor(15%)=9.96TB*

위 내용은 강사님 블로그에 있다고 함.

※ MS에서 제공하는 엑셀도 있다고 함.

__MBX를 위한 스토리지 계획

다음을 고려

복제된 DB 사본이 필요한 스토리지 양을 증가시킴
- 패시브의 수에 따라 필요 용량이 커짐
느린 디스크는 GB당 비용이 낮다
DAS는 SAN보다 훨씬 저렴하다
JBOD은 데이터베이스의 세 개 이상의 복제본이 있을 때 고려하자
- 물리적인 보호 장치는 없다. 소프트웨어적으로 구축
SAN이 사용될 경우 전형적으로 DB 사본을 더 적게 가져간다.
RAID 사용해 중복성을 높인다
Exchange Server MBX 서버 역할 요구사항 계산기 사용.

DB를 설계할 때 고려

Log file과 DB 스토리지를 분리
- 복제가 사용되지 않을 때 복구 기능을 향상
인덱스용 공간 할당
단일 항목 복구를 위한 공간을 할당
- 백업을 부어넣어서 복구해야 할 공간
보관 사서함(아카이빙)을 위한 공간을 할당한다
- 아카이빙은 오래된 메일을 그쪽으로 쌓는 거니까… 디스크가 빠르지 않아도 됨
복구 DB를 위한 공간을 할당한다

__고가용성을 위한 MBX 계획

DAG를 사용해 MBX 고가용성 구현 가능

MBX DB 이름은 조직에서 고유해야 한다
스토리지 경로는 DB의 모든 사본에 대해 동일해야 한다
DAG는 Windows Server의 장애 조치 클러스터링 기능을 요구한다.(옛날에는 그래서 윈도우 버전이 중요했지만, 지금은 그렇지 않다)
Exchange Server 2013 도구로 완전히 관리 가능
DAG는 공용 폴더도 보호 가능(옛날에는 아니었다고.. ㅎㄷㄷ)

__MBX 가상화 고려사항

다음 고려

동일한 하드웨어 요구사항을 갖는다(물리적인 요구 사항과 논리적인 요구 사항이 동일)
동적 메모리는 사용하지 않는다
가상 프로세서 할당을 2:1 비율로 제한한다
- 권장은 1:1인데… 물리 프로세서가 2개 필요한데 가상으로 1개 적용하는 등의 행위
가상 디스크를 동적으로 확장하지 않는다
차이점 보관용이나 스냅숏은 사용하지 않는다
가상 디스크 성능 테스트 필요
- 마이크로소프트의 젯스트레스(JetStress?) 테스트 도구들이 있음
필요하다면 pass-through와 iSCSI 스토리지 사용
- Pass-Through를 사용할 때에는 백업/복원 시 주의

__MBX DB 계획 고려사항

사서함 DB를 계획할 때 먼저 독립형 사서함 서버인지 DAG인지 결정

결정 시 다음을 기준으로 함

백업 정책
- Full -backup 기간, 증분 백업 주기 ?
MBX DB 크기
- DB가 너무 크면 복구 시 시간이 너무 많이 걸리겠죠
- 장애 시 복구에 시간이 너무 많이 걸리면?
- 윈도우 서버에서는 온라인 상에서 디스크 체크 가능
  - Fix 시에는 오프라인 상태여야 하지만, 사용자가 선택 가능
데이터베이스와 트랜잭션 로그 위치
스토리지 솔루션

__MBX 서버 역할 요구사항 계산기(Requirement Calculator)

MS에서 제공하는 무료 도구로 서버 배포를 설계하는데 도움을 줌

엑셀 파일 내용 중에서…

※ 지연 데이터베이스: 잘못된 내용이 쭉 동기화되면 안되니까, 하루 정도 뒤에 동기화되는 데이터베이스

※ Total Send/Receive Capa/Mailbox/day : 하루에 주고받는 메일 수

※ Retention : 삭제된 메일이 복구 가능한 날짜

※ 배포 탭에서 FAIL 시뮬레이션 가능

__MBX 서버 역할 성능 검증

성능 평가를 위해?