High Availability
High Available نمودن یک سرور Exchange به دو بخش تقسیم می گردد:
۱٫ High Available نمودن Client Access Services (پروتکل هایی که با استفاده از آنها می توان از طریق Outlook، OWA، ActiveSync و سایر کلاینت ها، به Mailbox دسترسی یافت)
۲٫ High Available نمودن سرور MBX (دیتابیس هایی که Mailbox ها را میزبانی می کنند)
منظور از High Available نمودن یک سرور یا سرویس آن است که Down Time برای آن سرور یا سرویس، کمتر از ۱۰% باشد.
High Available نمودن Client Access Services:
این سرویس ها، مسئولیت دو مورد زیرین را دارا هستند:
-
پروتکل های ارتباطی کلاینت ها (HTTP، POP، IMAP)
-
سرویس Front-End Transport
Client Access Services، ترافیک ارسالی را Authenticate می کند و آن را به سرور MBX که میزبان یک Active Copy از Mailbox Database است، Forward می نماید. بهترین روش برای High Available نمودن Client Access Services، استفاده از DNS Round Robin است. استفاده از Windows NLB، راه حل مناسبی نیست چرا که NLB، نمی تواند Service Failure را ساپرت کند و اگر OS سرور پا بر جا باشد اما سرویس های آن، Fail شده باشند، باز هم Request های کلاینت ها را به این سرور هدایت خواهد کرد و در نتیجه کلاینت ها قادر به اتصال به سرویس Client Access نخواهند بود.
اگر فرض کنیم در یک سایت دارای دو سرور Exchange، به نام های EXC1.company.com و EXC2.company.com باشیم که هر یک سرویس Client Access خود را دارا هستند، در DNS دو A Record با نام مشترک Mail.company.com ایجاد می کنیم و IP Address یکی از آنها را IP Address متعلق به EXC1 و IP Address دیگری را IP Address متعلق به EXC2، وارد می کنیم. این رکوردها به صورت Round Robin در اختیار کلاینت ها قرار خواهند گرفت و اگر بطور مثال یکی از سرور های Exchange و یا سرویس های آن، Fail شود و کلاینت نتواند با آن HTTPS Connection برقرار کند، این بار DNS، رکورد دیگر (A Record دیگر) را در اختیار کلاینت قرار می دهد و کلاینت به Exchange دیگر، متصل خواهد شد.
نکته یک: Certificate های نصب شده بر روی هر دو سرور باید یکسان باشد.
نکته دو: TTL مربوط به رکورد Mail.company.com را به ۲ دقیقه، کاهش می دهیم. برای اینکار در کنسول DNS، در قسمت View، چک مارک Advanced را می زنیم و بدین ترتیب می توانیم TTL هر رکورد را مشاهده کنیم و تغییر دهیم.
نکته سه: آدرس های Internal یا External یا هر دو (بسته به نوع طراحی ما) در:
Outlook Anywhere به Https://Mail.company.com
OWA به Https://Mail.company.com/owa
EAC به Https://Mail.company.com/ecp
ActiveSync به Https://Mail.company.com/Microsoft-Server-ActiveSync
EWS به Https://Mail.company.com/EWS/Exchange.asmx
OAB به Https://Mail.company.com/OAB
تغییر می دهیم.
نکته چهار: همانگونه که در قسمت Autodiscovery توضیح داده شد، به ازای هر سرویس Client Access بر روی هر سرور Exchange نصب شده، یک SCP Object در Active Directory ایجاد می گردد که URL مربوط به Autodiscover را باز می گرداند. برای Update نمودن SCP در EMS از cmdlet های زیر برای EXC1 و EXC2 استفاده می شود:
Set-ClientAccessService –Identity “EXC1” –AutoDiscoverServiceInternalUri ‘https://mail.company.com/AutoDiscover/AutoDiscover.xml’
و همین فرآیند را برای EXC2، تکرار می کنیم.
Database Group Availability (DAG)
High Available نمودن سرورهای MBX، با عنوان DAG شناخته می شود. DAG از قابلیت Failover Clustering در Windows Server استفاده می کند.
قابلیت Windows Failover Cluster، به صورت اتوماتیک بر روی سرورهای MBX که در DAG شرکت می کنند، نصب می شود و نیازی به نصب آن به صورت Manually نیست.
سرورهای MBX که در یک DAG قرار می گیرند، باید دارای سیستم عامل یکسان باشند و هر سرور MBX می تواند عضو تنها یک DAG باشد.
در یک Cluster، مفهوم Quorum، به معنای حداکثر تعداد Node هایی است که Cluster می تواند Fail شدن آنها را تحمل کند و همچنان به کار خود ادامه دهد. به عبارت دیگر، Fail شدن Node های یک Cluster بیش از Quorum، سبب Stop شدن Cluster می گردد. پیکربندی Quorum توسط خود نرم افزار Cluster، برای آن Cluster تعیین می گردد.
حد تحمل (Quorum) به طریقه زیر محاسبه می گردد:
Qourum=(N/2)+1
که در آن N، تعداد اعضای شرکت کننده در Cluster است. بطور مثال اگر:
تعداد اعضای DAG، ۶ عضو باشد:
Qourum=(6/2)+1=4
یعنی ۳ عضو را می تواند از دست بدهد و Cluster به کار خود ادامه دهد
تعداد اعضای DAG، ۹ باشد:
Qourum=(9/2)+1=5
یعنی ۴ عضو را می تواند از دست بدهد.
تعداد اعضای DAG، ۱۳ باشد:
Qourum=(13/2)+1=7
یعنی ۶ عضو را می تواند از دست بدهد.
تعداد اعضای DAG، ۱۵ باشد:
Qourum=(15/2)+1=8
یعنی ۷ عضو را می تواند از دست بدهد
سروری که پیکربندی Qourum را نگهداری می کند، Witness Server نامیده می شود. یک Member Server باید به عنوان Witness Server پیکربندی شود. از DC هم می توان به عنوان Witness Server استفاده کرد که البته توصیه نمی شود.
نکته مهم: عضو یک DAG نمی تواند به عنوان Witness Server پیکربندی شود.
پیکربندی یک Member Server به عنوان Witness Server:
ابتدا File Server Role را بر روی این سرور نصب می کنیم
-
گروه Exchange Trusted Sub System را در گروه Local Administrators این سرور، می کنیم.
-
یک Shared Folder، به نام WitnessShare ایجاد می کنیم
پیکربندی DAG
سناریوی پیاده سازی DAG، برای دو سرور را در نظر می گیریم
الف- پیکربندی کارت شبکه:
وجود دو کارت شبکه، بر روی هر سرور، که یکی از آنها برای ارتباطات کلاینت ها (MAPI) و دیگری برای Replication ترافیک DAG (REPL) استفاده می شود، توصیه می گردد. البته کارت شبکه REPL باید با کارت شبکه MAPI، در دو Subnet متفاوت باشند.
سپس ترتیب این کارت شبکه ها را تعیین می کنیم. به این منظور در محیط Network Connections، کلید ALT را می گیریم. آنگاه بر روی Advanced کلیک می نماییم و Advanced Settings را انتخاب می کنیم و کارت شبکه MAPI را در ابتدای فهرست قرار می دهیم.
همچنین از کارت شبکه REPL، با کلیک راست بر روی آن، Properties می گیریم. آنگاه در:
Internet Protocol Version 4 (TCP/IP) ——-> Properties ——-> Advanced ——-> DNS TAB
چک مارک Register this connection’s addresses in DNS را بر می داریم
نکته: کارت شبکه REPL نباید Default Gateway داشته باشد.
ب- Pre-Stage نمودن Cluster Name Object (CNO):
برای Per-Stage نمودن CNO، یک Computer Object به نامی که می خواهیم DAG را به آن نام بخوانیم، ایجاد می کنیم و سپس آن را Disable می نماییم.
سپس از این Computer Account، با کلیک راست بر روی آن، Properties می گیریم و در Security TAB، به گروه Exchange Trusted Subsystem و Computer Account های متعلق به هر دو سرور MBX، سطح دسترسی (Permission) از نوع Full Control می دهیم.
ج- ایجاد Database Availability Group:
به این منظور در:
EAC —–> Servers ——> database availability groups TAB
بر روی +، کلیک می کنیم. در قسمت Database availability group name، نامی را که قبلا” به Computer Account متعلق CNO داده بودیم، وارد می کنیم. در قسمت Witness Server، نام FQDN متعلق به Witness Server را وارد می کنیم. در قسمت Witness Directory، مسیر فولدری را که قبلا” در Witness Server ایجاد کرده بودیم، وارد می کنیم.
در قسمت Database availability group IP address، یک یا چند IP Address برای DAG در نظر می گیریم. این IP Address، باید در Range کارت شبکه MAPI باشد و توسط هر دو سرور MBX، قابل دسترسی باشد. (اگر این قسمت خالی باشد، IP Address از DHCP گرفته خواهد شد) و در انتها بر روی Save کلیک می کنیم.
د- افزودن اعضای DAG:
به این منظور بر روی DAG ایجاد شده در مرحله قبل، دبل کلیک می کنیم و دو سرور MBX را به عنوان اعضای DAG به آن Add می کنیم. بدین ترتیب، اجزاء Windows Failover Cluster بر روی هر دو سرور MBX عضو، نصب می گردد.
ه- کپی کردن Database:
-
ایجاد یک Database جدید در سرور MBX اول: به این منظور در:
EAC —–> servers —–> database TAB
بر روی + کلیک می کنیم. در قسمت Mailbox database، یک نام برای دیتابیس انتخاب می کنیم. در قسمت Server، بر روی Brows کلیک می کنیم و سرور MBX اول را وارد می کنیم. در قسمت Database file path و Log folder path، مسیر مورد نظر را وارد می کنیم. باید توجه کرد که درایوهایی که در این مسیر مورد استفاده قرار می گیرند، باید بر روی سرور MBX دوم نیز وجود داشته باشد.
-
پس از ایجاد Database، آن را انتخاب نموده و بر روی … کلیک می کنیم. و گزینه Add database copy را انتخاب می کنیم. در قسمت Specify Mailbox Server، بر روی Brows کلیک نموده و سرور MBX دوم را وارد می کنیم. این سرور نگاهدارنده کپی Passive از Database خواهد بود. در قسمت Activation Preference number، اولویت Active بودن Database تعیین می گردد. این عدد برای دیتابیس Active که بر روی MBX اول قرار دارد، یک است و در نتیجه برای اولین Copy بر روی MBX دوم، این عدد دو خواهد بود.
در انتها بر روی Save کلیک می کنیم. بدین ترتیب بعد از کپی شدن دیتابیس، Replication میان دو دیتابیس برقرار می گردد.
نکته: یک دیتابیس را حداکثر تا ۱۶ بار می توان کپی کرد.
نکته: اگر Content index برای یک Passive Database در وضعیت Failed باشد، با فرض اینکه نام سرور MBX2 و نام دیتابیس HADatabase باشد، آنگاه می توان از cmdlet زیر استفاده کرد:
Update-MailboxDatabaseCopy “HADatabase\MBX2” –CatalogOnly
در دو حالت Active Database در حالت Dismounted قرار می گیرد و یکی از کپی های Passive Database به صورت Mounted در می آید:
-
Failover: حالتی است که یک اتفاق برنامه ریزی نشده از قبیل Failure سرور میزبان Active Database پیش می آید. در این حالت فرآیند Active شدن Passive Database به صورت اتوماتیک صورت می گیرد.
-
Switchover: حالتی است که به صورت برنامه ریزی شده، سرور میزبان Active Database به صورت موقت توسط Administrator از دسترس خارج می گردد. از آن جمله می توان از نصب Update بر روی این سرور، ذکر کرد. در این حالت بر روی Database مورد نظر کلیک می کنیم. در قسمت سمت راست، بر روی Activate کلیک می نماییم.
نکته: هر عضو DAG می تواند میزبان Active Database خود و Passive Database اعضای دیگر باشد.
