Exchange CAS high availability

Database Availability Group برای High Availability برای سرور رول های Mailbox، High Availability را فراهم می آورد، برای سرور رول های Client Access Server نیاز به رهیافت دیگری جهت High Availability است. در Exchange 2010 High Availability برای Client Access Server از طریق راه اندازی یک CAS Array و یک روش Load Balancing همانند دیوایس های سخت افزاری و یا Windows NLB فراهم می شد. در Exchange 2013 دیگر CAS Array وجود ندارد و سایر تغییرات معماری Exchange 2013 سبب شده است تا Load Balancing از طریق متد دیگری صورت پذیرد با این وجود مفهوم single namespace for Outlook connectivity همچنان بلا تغییر باقی مانده است.

این مقاله آموزشی ترجمه ای است با تصرف بر آموزش های منتشر شده توسط Paul Cunningham. وی که Microsoft Exchange MVP است، مقالات آموزشی متعدد و موثری را برای متخصصین منتشر کرده..

ساختار مفروض

در یک سایت، دو Client Access Server و سه سرور برای Mailbox Server در حالت Multi-role به صورت زیر فرض شده اند.

image

وضعیتی را تصور کنید که یک کاربر به E15MB2 متصل شده است. برای این منظور هیچ تنظیماتی لازم نیست و Outlook Auto discover کرده است. همچنین E15MB2 دارای Active Database است.

image3

مشکلات زمانی آغاز می شوند که، E15MB2 بر حسب هر دلیلی، Offline شود. Database ها بر اساس وجود DAG امکان Failover دارند. با این وجود کاربری که به E15MB2 متصل بوده است، دیگر قادر به دسترسی Mailbox خود نخواهد بود زیرا Client Access مربوطه دیگر در دسترس نیست.

image6

در نهایت با استفاده از Auto Discover کاربر می تواند به Client Access Server دیگر در سایت متصل شود. با این وجود این تجربه کاربری مناسبی نیست.

ساختار HA

برای بهبود این وضعیت لازم است نگاهی بر ساختار Outlook Anywhere داشته باشیم. همانطور که می دانید، Outlook Anywhere ارتباط RPC/MAPI را برای کاربران Exchange روی HTTP یا HTTPSفراهم می آورد که پیش تر برای ارتباط External استفاده می شد، با توجه به تغییرات معماری Exchange 2013 برای ارتباطات Internal نیز استفاده می شود.

در وضعیت پیش فرض، هر کدام از CAS ها با اسم خودشان برای Outlook Anywhere تنظیم شده اند.

image9

لازم است یک نام یکتا را جایگزین FQDN پیش فرض کنیم. نکته قابل توجه آن است که علاوه بر InternalHostname لازم است InternalClientsRequireSSL نیز به روز گردد. در این آزمایشگاه طبیعتا استفاده از SSL الزامی نمی باشد. از cmdlet زیر می توان برای تغییر نام کلیه سرویس دهندگان Outlook Anywhere استفاده کرد.

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname mail.exchange2013demo.com -InternalClientsRequireSsl $false

همچنین لازم است اطمینان حاصل کنیم که نام های DNS مربوطه برای Resolve کردن Client Access Server وجود دارند. با توجه به آنکه Load Balancer وجود ندارد، در اینجا به استفاده از DNS Round Robin اکتفا می کنیم با این وجود استفاده از Load Balancer می تواند گزینه مناسب تری باشد.

image12

پس از گذشتن مدتی و ریستارت شدن Outlook، کلاینت اکنون به namespace جدید متصل می گردد. تغییرات اعمال شده روی Client Access Server ها آنی نیست و ۱۵ دقیقه زمان جهت به روز رسانی تنظیمات نیاز است. زمانی که Outlook autoconfiguration test مقدار جدید را برای(Exchange HTTP(S باز گرداند، می توانید اطمینان حاصل کنید که تغییرات صورت گرفته اند.

image15

با استفاده از netstat می توان دید که mail.exchange2013demo.com به ۱۹۲٫۱۶۸٫۰٫۱۸۸ متصل شده و همچنین Outlook به E15MB2 متصل است.

برای آزمایش دسترسی پذیری سرویس، E15MB2 را می توان خاموش کرد. بدون استفاده از Load Balancing، ۲۰ ثانیه زمان برد تا کلاینت ها Time Out شوند و دوباره کانکشن خود را ایجاد کنند و به IP دیگر متصل گردند.

image18

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *