Нова служба RPC Client Access Service в Exchange 2010 (частина 1), Комерція, Різне, статті

Введення


Серед архітектурних нововведень, привнесених в Exchange Server 2010, є і нова служба клієнтського доступу RPC Client Access Service, що змінює знайому нам бізнес-логіку клієнтського доступу. Ця нова служба передає поштові з’єднання Outlook MAPI від back-end “них поштових серверів і доступ до каталогів від контролерів доменів / серверів глобальних каталогів на рівні даних до серверів Client Access посередником.


У цій статті ми почнемо з ностальгічного огляду бізнес-логіки в часи Exchange 2000/2003 з її концепцією front-end “них і back-end” них серверів. Потім поговоримо про поліпшення, внесених при введенні серверної ролі Client Access в Exchange 2007. Після цього ми впритул займемося новою службою RPC Client Access Service з Exchange 2010. Ми дізнаємося, як працює ця служба, і як можна призначити статичні порти для MAPI-з’єднань.


Давайте приступимо.


Короткий огляд архітектури front-end “ов і back-end” ов в Exchange 2000/2003


У Exchange 2000 і 2003 у нас була базова архітектура front-end “ов і back-end” ов, в якій front-end-сервери брали запити від клієнтів та передавали їх back-end-серверів для обробки. Front-end-сервер в Exchange 2000/2003 міг передавати RPC на базі HTTP (зараз це називається Outlook Anywhere), HTTPS (OWA, Entourage і т.д.), POP і IMAP відповідним back-end-серверів. Front-end-сервери також підтримували множинні звернення до даних спільної папки на back-end-серверах.


У Exchange 2000/2003 внутрішні клієнти Outlook MAPI взагалі не використовували front-end-сервери, вони безпосередньо з’єднувалися з back-end-серверами за допомогою MAPI на базі RPC. І взагалі, так як компонент DSProxy не запускався на front-end-серверах, у вас не було можливості вказати клієнтам Outlook MAPI NetBIOS-ім’я або FQDN front-end-сервера.


У Exchange 2000/2003 компонент DSAccess також отримував доступ до служби Netlogon на серверах контролера домену та глобального каталогу в Active Directory безпосередньо за допомогою Remote Procedure Call (RPC), а потім клієнти Outlook підключаються прямо до DC / GC. Outlook 2000 і більш ранні версії підключалися до DSProxy.



Рисунок 1: Архітектура front-end “ов і back-end” ов в Exchange 2000/2003

Одним з переваг front-end-серверів в Exchange 2000/2003 було те, що вони дозволяли вам налаштовувати один простір імен (наприклад, mail.domain.com). У такому просторі імен користувачам не потрібно було знати ім’я сервера, на якому зберігався їх поштовий ящик. Іншою перевагою було те, що шифрування і дешифрування SSL було віддано front-end-серверів, що звільняло дороге процесорний час back-end-серверів. Але все-таки front-end-сервери були всього лише проксі-серверами, які самі нічого не обробляли. Вони лише виробляли аутентифікацію і відправляли запити на доступ до back-end-серверів; при цьому позначалися ще й обмеження 32-бітної архітектури, яка, крім іншого, обмежувала максимальний обсяг пам’яті серверів Exchange 2000/2003 до 4ГБ.


Загальна інформація про серверну ролі Client Access в Exchange 2007


Коли був випущений Exchange 2007, все значно покращився. Сенс запровадження ролі Client Access Server (CAS) в Exchange 2007 був в тому, щоб оптимізувати роботу серверної ролі Mailbox. На відміну від front-end-серверів в Exchange 2007, роль CAS – це не просто проксі-сервер. Наприклад, серверу CAS дістається обробка бізнес-логіки політик Exchange ActiveSync Policies і сегментації OWA. Крім того, рендеринг UI OWA також відбувається на сервері CAS, а не на сервері Mailbox. Взагалі, всі клієнтські з’єднання, крім Outlook (MAPI) використовують сервери CAS в якості кінцевої точки з’єднання в інфраструктурі Exchange 2007. Це знімає велику частину навантаження, яка лежала на back-end-поштових ящиках в Exchange 2000/2003.



Малюнок 2: Архітектура клієнтського доступу в Exchange 2007

Потім з’являється служба PRC Client Access Server в Exchange 2010


У Exchange 2010 всі заходить ще далі. У Exchange 2010 з’єднання MAPI і з’єднання з каталогами також віддані ролі CAS. Це реалізовано за допомогою нової служби в CAS, відомої як служба RPC Client Access.



Малюнок 3: Служба RPC Client Access в оснащенні MMC Services на сервері CAS

Це означає, що клієнти MAPI тепер не підключаються безпосередньо до сервера Mailbox, коли вони відкривають поштовий ящик. Замість цього вони підключаються до служби RPC Client Access, яка далі звертається до Active directory і серверу Mailbox. Для отримання інформації по каталогу Outlook підключається до кінцевої точки NSPI на сервері Client Access Server, а потім NSPI звертається до Active Directory через відповідний драйвер. Як відомо, кінцева точка NSPI заміщає компонент DSProxy в Exchange 2007.



Малюнок 4: Архітектура клієнтського доступу в Exchange 2010

Чим це відрізняється від клієнтів Outlook Anywhere (RPC на базі HTTP), що підключаються до поштової скриньки в Exchange 2007? Ну, хоча клієнти Outlook Anywhere підключалися до компоненту RPC Proxy на сервері CAS, вони також зверталися за допомогою MAPI на базі RPC безпосередньо до сервера Mailbox і до кінцевої точки NSPI в Active Directory.


Хто-небудь з вас обов’язково поцікавиться, які ж переваги служби RPC Client Access. Їх декілька. По-перше, тому що MAPI-з’єднання і з’єднання з каталогами відійшли до ролі Client Access Server (Проміжна ланка), у Exchange тепер є тільки один спільний шлях, через який відбувається передача всіх даних. Це не тільки покращує цілісність при застосуванні бізнес-логіки у клієнтів. Це спрощує роботу з клієнтом при перенастроюванні або при збоях у випадку, якщо ви встановили високодоступное рішення, яке використовує функцію Database Availability Group (DAG), про яку я розповім докладніше в наступних статтях. Якщо користувач клієнта Outlook і помітить відключення, воно буде тривати не більше 30 секунд; в Exchange 2007 це займало кілька хвилин, справа могла дійти до півгодини при наявності складної топології AD, що складається з безлічі вузлів AD і контролерів доменів, за допомогою яких працював DNS.


І, нарешті, наявність одного шляху доступу до даних дозволяє збільшити число одночасних з’єднань і поштових скриньок на поштовому сервері. У Exchange 2007 поштовий сервер міг працювати з 64000 сполук, а в Exchange 2010 це число збільшено до 250000.


Масиви CAS в Exchange 2010


Тепер, коли в інфраструктурі Exchange 2010 велика роль відводиться серверів Client Access Server, клієнтам необхідно вміти швидко перепідключатися до іншого сервера CAS у випадку, якщо той сервер, з яким вони працювали, відключається за плановими або позаплановим причин. Знайомтеся з новою функцією Exchange 2010 – масивом Client Access! Як зрозуміло з назви, це масив серверів CAS. Точніше, це масив, що складається з усіх серверів CAS в тому вузлі Active Directory, де створювався цей масив. Тобто, замість підключення до FQDN сервера CAS, клієнт Outlook може підключитися до FQDN масиву CAS (наприклад, outlook.domain.com). Це гарантує, що у клієнтів Outlook, з’єднаних через MAPI, з’єднання не пропадає навіть у разі збою бази даних поштових скриньок і у випадках перенастроювання.


Ось як все це працює відносно масивів CAS. У базі даних поштових скриньок в Exchange 2010 є атрибут під назвою RpcClientAccessServer. При створенні нової поштової бази даних у вузлі Active Directory, де масив CAS не був створений, цей атрибут отримує значення першого сервера CAS, встановленого в даному вузлі AD. Значення даного атрибута можна подивитися, запустивши наступну команду:


Get-MailboxDatabase <DB name> / fl RpcClientAccessserver



Рисунок 5: FQDN сервера RPC Client Access Server, зазначений в поштовій базі даних

Якщо масив CAS існує у вузлі AD, при створенні нової поштової бази даних атрибут автоматично встановлюється на FQDN масиву CAS. Тому масиву CAS відомо, на якій поштовий сервер і на яку базу даних потрібно направляти користувача.

Масив CAS налаштовується наступним чином. Спочатку відбувається створення масиву CAS за допомогою наступної команди:


New-ClientAccessServer “Name” назва масиву CAS “” Fqdn -Site



Малюнок 6: Створення нового масиву CAS

Після створення масиву CAS вам потрібно створити запис у вашому внутрішньому DNS під назвою outlook.domain.com, що вказує на віртуальний IP-адресу вашого внутрішнього рішення з балансування навантаження.



Рисунок 7: Створення запису для масиву CAS в DNS

Все ще можна використовувати Windows NLB разом з масивом CAS, оскільки серверна роль Mailbox не встановлена ​​на тій же машині, і всі поштові бази даних на сервері не захищені Database Availability Group (WNLB і кластеризація можуть при цьому конфліктувати, тому такий сценарій не підтримується). Ви, звичайно, також можете вирішити використовувати масив CAS разом із зовнішніми пристроями балансування навантаження, що рекомендується, особливо у випадку, якщо у вас більше 8 вузлів CAS.


Якщо ви користуєтеся WNLB, є резон у створенні кластера WNLB, при цьому потрібно занести в DNS запис із зазначенням на WNLB VIP і переконатися в тому, що TCP-порт 135 (EndPoint Mapper) і динамічний діапазон RPC (TCP 1023-65535) додані в список правил для портів.


Зауваження: Далі в цьому циклі статей я покажу вам, як встановити статичні порти для MAPI і для доступу до каталогів.


Якщо ви користуєтеся третьестороннім рішенням для балансування навантаження, вам необхідно створити правила на відповідному пристрої, що працює з round-robin-трафіком, для потрібних портів.


І, нарешті, якщо ви створювали поштові бази даних на серверах Mailbox у вузлі AD перед тим, як створювати масив CAS, вам слід поміняти FQDN, зазначений в атрибуті RpcClientAccessServer, для цих баз даних. Це робиться за допомогою наступної команди:


Set-MailboxDatabase <name of DB> -RpcClientAccessServer “outlook.domain.com”



Рисунок 8: Зміна значення атрибута RpcClientAccessServer для будь-яких існуючих поштових баз даних

Тепер outlook.domain.com у нас має бути видно як FQDN.



Рисунок 9: Атрибут RpcClientAccessServer встановлений як FQDN масиву CAS

Якщо ви захищаєте поштові бази даних за допомогою Database Availability Group, та копія відповідної бази даних на іншому сайті AD стає активною, не забувайте, що сервери CAS безпосередньо звертаються до сервера Mailbox, на якому розташовується поштова база даних. Ця взаємодія буде відбуватися за допомогою RPC, оскільки і сервери CAS, і сервери Mailbox працюють з RPC. Це важлива обставина. Якщо весь вузол припинить роботу, клієнти не будуть автоматично перепідключатися до серверів CAS на іншому сайті. Це зажадає ручного втручання. Така тема заслуговує окремої статті і виходить за рамки цієї статті.


Нарешті, не забувайте, що масив CAS використовується тільки клієнтами Outlook MAPI для підключення до поштових скриньок, спільних папок і active directory. Вам все ще потрібен WNLB або зовнішнім Балансувальник навантаження для OWA, Autodiscover, Exchange ActiveSync, служби доступності і так далі.


Це все, чим я хотів поділитися з вами в першій частині; чекайте виходу другої частини цього циклу статей – її опублікують в недалекому майбутньому.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*