Active Directory 및 Exchange 아키텍처 질문 및 문제


11

상황에 대한 배경은 다음과 같습니다.

현재 우리는 3 개의 완전한 Active Directory 및 Exchange 시스템을 갖춘 3 개의 개별 회사로 설정되었습니다. 3 개의 사무실 (미국에 1 개, 유럽에 2 개)은 3 방향 VPN 설정을 통해 연결됩니다 (따라서 각 사무실은 다른 2 개와 안전하게 통신합니다). 각 설정마다 Active Directory에 양방향 트러스트 관계 설정이 있습니다. 모든 시스템에서 Server 2003 및 Exchange 2003을 실행하고 있습니다.

회사와 사용자 80 명 사이에 약 160 개의 사서함이 있습니다 (추가 사서함은 IT 하위 시스템, 전달 계정 또는 기타 용도를위한 것임).

회사는 단지 신뢰 관계가 아닌 공식적으로 합병하고 있습니다. 따라서 각 사무실이 동일한 시스템 (Exchange 및 Active Directory)에있을뿐만 아니라 IT 인프라를 통합하는 중복 솔루션이 많이 있습니다 (중복이 많이 있습니다).

그들은 IT 인프라를 도입하고 감사하기 위해 외부 회사를 고용했습니다. IT 인프라 아웃소싱에 대한 공식적인 권장 사항을 제시했으며 서비스를 제공 할 대상을 추측했습니다.

나는 무엇을 해야할지 알아내는 임무를 맡았습니다. 나는 그것에 대해 꽤 생각했고 두 가지 옵션을 생각해 냈습니다. 기본적인 차이점은 Exchange가 호스팅되는 위치 (내부적으로 외부에서 조달)입니다. 아웃소싱은 이해하기 쉬우므로 내부 설정에 대해 자세히 설명하겠습니다.

고 가용성이 필요하기 때문에 지리적 중복성이 기본적으로 제공되기를 원합니다. 따라서 다음과 같이해야합니다 (사무실 Site1, Site2 및 Site3).

사이트 1 :

  • FSMO Active Directory 역할
  • Exchange 사서함 역할-기본
  • Exchange 클라이언트 액세스, 허브 전송 서버 역할
  • DFS 파일 공유 역할 (공유 드라이브의 경우)

사이트 2 :

  • 사이트 1에서 복제 된 Active Directory 역할
  • Exchange 사서함 역할-CCR 복제를 사용하여 복제 된 보조
  • Exchange 클라이언트 액세스, 허브 전송 서버 역할
  • DFS 파일 공유 역할

사이트 3 :

  • 사이트 1에서 복제 된 Active Directory 역할
  • Exchange 클라이언트 액세스, 허브 전송 서버 역할
  • 파일 공유 감시 (페일 오버 용)
  • DFS 파일 공유 역할

따라서 기본적으로 클러스터는 다른 사이트 (또는 시스템)를 중단시키지 않고 단일 사이트 장애에서도 살아남을 수 있어야합니다. 이중 사이트 장애가 발생하면 Exchange가 완전히 중지됩니다.

그래서 내 관심사는 다음과 같습니다.

  1. 이것이 합리적인 설정입니까? 아니면 너무 복잡한 일입니까?
  2. 필요한 서버 수 (CCR 사서함 역할이 유일하게 설치된 역할이므로 각 사이트에서 3 개)
  3. 사이트 또는 서버가 다운되면 사용 가능한 노드로 자동 장애 조치 (failover)되는 합산 된 상태로 작동합니까?
  4. 각 사무실은 해당 사용자에 대해 로컬 클라이언트 액세스 서버를 지정하므로 해당 서버는 모든 로컬 요청에 대해 단일 실패 지점이됩니다 (단, 수동 DNS 변경으로 해결할 수 있음)
  5. 이 서버가 작동하려면 모든 서버가 동일한 IP 서브넷에 있어야합니까? 또는 계층 적 DNS를 사용하여 벗어날 수 있습니까 (clientaccess.site1.foo.com 등)?
  6. 이렇게하면 각 사무실을 MX 레코드로 설정할 수 있습니다 (인터넷에 연결하기 위해 각 사무실에 허브 전송 서버가 있기 때문에). 한 사무실이 다운되면 다른 사무실에서 여전히 이메일을받을 수 있어야합니다. 맞습니까?
  7. 유지 보수성. 이 설정이 장기적으로 유지하기 (사무실 추가, 사무실 제거, 서버 업그레이드 (OS 및 하드웨어 모두) 등)하기에는 너무 복잡 할까 걱정됩니다. 정당한 두려움입니까?

이제 서버 2003 또는 2008과 함께 갈 것인지에 대한 질문도 있습니다. 내부 Exchange 경로를 사용하면 2008로 업그레이드 할 수있는 힘을 확신 할 수 있습니다 (사실 Exchange 2010을 사용하려면 업그레이드해야 함). ...하지만 정말로 필요한가 아니면 내 "원하는"사람 중 하나만 계획에 몰래 들어가는 것입니다.

이제 저의 일부는 이러한 문제 중 일부 (또는 대부분)를 완화시키기 때문에 아웃소싱 된 Exchange를 사용하려고합니다. 그러나 비용을 살펴본 후 손익분기 점은 약 1 년이므로 아웃소싱 비용이 훨씬 비쌉니다. 우리가 의존하는 일부 기능은 적어도 우리가 본 회사와 같은 아웃소싱이 불가능하다는 사실과 함께 공유 공유 함, SSO를 포함한 Active Directory 커플 링, 중앙 집중식 관리, 데이터 보안 등이 있습니다. 그래서 나는 이것과 함께 갈 곳에 대해 정말로 찢어졌습니다 ...

이것은 내가 시도하고있는이 규모의 첫 번째 프로젝트이므로 도움을 주시면 감사하겠습니다 ...

미리 감사드립니다 (책에 대해 죄송합니다) ...


잘 작성되고 문서화 된 질문에 +1 내가 할 수 있다면 아바타에 +2를 줄 것이다.
pauska

답변:


6

우리는 이미 하나의 회사라는 사실을 제외하고 비슷한 상황에 처해 있습니다. 그러나 캠브리지, 런던, 스톡홀름, 상하이 및 애틀랜타에 사무소가 있습니다. 모두 VPN을 통해 연결되었습니다. 이 중 3 대에는 Exchange 서버가 있습니다 (Exchange 2010의 2 대, 세 번째 서버는 곧 업그레이드 될 예정 임). 대부분의 도메인 컨트롤러는 Windows 2003을 실행하지만 모두 Windows 2008로 업그레이드하는 중입니다. 약 150 명의 직원이 있으며, 전 세계에 퍼져 있습니다. 상황과 매우 비슷합니다.

그래서 여기 내 관점에서 몇 가지 대답이 있습니다.

  1. 적절한 IT 팀이 있다면 아웃소싱을 고려하지 않을 것입니다. 실제로, 당신의 팀이 괜찮지 않더라도, 나는 그것을 괜찮게 만드는 데 약간의 노력을 기울일 것입니다. 응답 시간이 훨씬 빨라지고 보안 설정이 더 간단하지만 무엇보다도 중요합니다. IT 팀은 IT 인프라를 최상의 상태로 유지하는 데 주력 할 것입니다. 아웃소싱 제공 업체의 주요 초점은 최상의 서비스를 제공하지 않고 귀하로부터 최대한의 돈을 버는 것입니다.
  2. 계획된 설정은 매우 가능합니다. 가장 큰 과제는 모든 것을 공통 도메인으로 마이그레이션하는 것이지만 단계별로 수행 할 수 있습니다.
  3. 필요한 대부분의 서버는 팔과 다리 비용이 들지 않습니다. 추가 서버를 구입해야 할 경우 자본 지출이 적습니다.
  4. 그것이 작동하는지의 여부는 퍼블릭 DNS와 내부 라우팅이 얼마나 잘 구성되어 있는지에 달려 있습니다. 확실히 작동하도록 만들 수 있습니다.
  5. 각 사무실마다 별도의 서브넷을 사용하는 것이 좋습니다. A A 시스템 관리자 삶을 만든다 LOT 쉽게. 각 사무실에 적절한 크기의 서브넷 하나를 사용한 다음 사이트 또는 OSPF 간의 트래픽에 정적 라우팅을 사용하십시오 (대부분의 괜찮은 VPN 라우터는 선반에서 OSPF를 제공합니다). 실제로 대부분의 사무실에는 2 개의 개별 서브넷이 있으며 일반적인 회사 트래픽은 엔지니어링 트래픽과 분리되어 있습니다 (엔지니어는 DNS, DHCP, 비디오 스트리밍 등 많은 기능을 수행하는 경향이 있기 때문에). 그리고 그것은 아름답게 작동합니다. 실제로 사무실의 엔지니어가 어디에서 왔는지 알 필요없이 다른 곳의 스 트리머에서 비디오 스트림을 사용할 수있는 시점까지 도달했습니다.
  6. 모든 컴퓨터를 하나의 큰 서브넷에 두지 마십시오 . 당신은 당신의 머리를 찢어 것입니다. 약속.
  7. 3 개의 공용 메일 게이트웨이 (인터넷 연결 대역폭이 가장 높은 사무실에 위치)는 모두 동일하게 구성되어 있으며 메일이 최종 사서함으로 배포되는 가장 가까운 Exchange 서버로 전달됩니다. 전혀 문제 없습니다.
  8. 라우팅 등에 대한 기본 사항을 파악하면 유지 관리가 어렵지 않습니다. 이 사이트 전체에 약 150 개의 서버, 약 24 개의 VPN 라우터, 수십 개의 관리되는 스위치가 있습니다. 우리는 혼합 설치 (30 % Windows, 70 % Linux, 서버 및 워크 스테이션) 및 4 명에게보고합니다. 전혀 문제가 없습니다.

배우는 능력을 믿으면 성공할 것입니다. 계획이 좋습니다. Windows Server 2008을 사용하여 Exchange Server를 하나씩 Exchange 2010으로 마이그레이션하려고합니다. Exchange를 마이그레이션하려면 약간의 외부 도움이 필요할 수 있습니다 (필요한 경우 일반적으로 Exchange에 능숙합니다). 초기 자본 배치를 두려워하여 모든 것을 하나씩 마이그레이션 할 수도 있습니다. 하나의 큰 팽창으로이 모든 것을 할 필요가 없습니다.


와! 정답입니다! 글쎄, 당신이 만드는 몇 가지 요점에 대답하겠습니다. 첫째, 꼭 필요한 경우가 아니면 모든 것을 하나의 서브넷에 두지 않겠습니다. 내가 생각하는 것은 각 사무실마다 특정 서브넷 (예 : 사이트 1 컴퓨터의 경우 172.25.50.0, 사이트 1 서버의 경우 172.25.55.0, 사이트 2 컴퓨터의 경우 172.25.60.0 등)을 사용하여 하나의 클래스 C 서브넷에 모든 것을 배치하는 것입니다. 그러면 마스크를 지정하기 만하면 모든 것을 관리 할 수 ​​있습니다 ... 하나의 참고, 여러 사서함 서버 (사이트 당 하나씩)를 제안합니까? 아니면 중복성을 위해 복제 된 단일 모 놀리 식 사서함 서버?
ircmaxell

아니면 서브넷과 관련하여 정확히 경고 한 것입니까? 각 사무실에 완전히 별도의 서브넷 (같은 \ C의 일부조차 아님)을 제공하는 것이 더 좋습니까?
ircmaxell

Subnetting : 당신이 묘사하는 것은 우리가하는 일과 내가 생각하고있는 것과 매우 유사한 것인데, 상황에 따라 세부적인 레이아웃이 결정되기 때문에 규범 적이기를 원하지 않았습니다.
wolfgangsz

전자 메일 : 사이트의 모든 사용자를위한 로컬 사서함과 다른 사이트 사서함을위한 DAG (Exchange 2010 개념이며 매우 유용함)를 사용하는 것이 좋습니다.
wolfgangsz

충분히 공평합니다 (2010 년에 나타 났으며 그것이 우리가 원하는 것 같습니다). 저는 무역 개발자입니다. 그러나 시스템 관리자가 약 1 년 전에 떠났을 때 나는 내 사이트에 대한 책임을 맡았습니다. 나는 그것을 좋아하고 많은 것을 배웠지 만 여전히 배울 것이 많다 ... 그래서 이런 것들에 대한 위생 점검을받는 것이 정말 좋고 유용하다 ... 고마워요!
ircmaxell
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.