Exchange DAG

Database Availability Groups یا به اختصار DAG یک رهیافت High Availability برای Exchange Server است. در این مطلب، ابتدا نگاهی بر تعاریف اولیه داریم و سپس گام به به گام به بررسی طراحی و راه اندازی DAG و راهبری DAG در یک محیط آزمایشی می پردازیم.

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

Database Availability Group

یک DAG می تواند شامل تا ۱۶ دیتابیس مختلف و شامل یک یا بیشتر سرور غیر Exchange برای File Witness Server باشد. سرور هایی که در یک DAG قرار می گیرند می توانند یک کپی از Mailbox Database را نگه داری کنند. محدودیت Exchnage برای نگه داری Mailbox Databases ها روی یک سرور ۱۰۰ دیتا بیس است که شامل دیتابیس های Active و Passive می گردد. تصویر زیر، نمونه ای از این سناریو را به تصویر می کشد.

image166

در مثال فوق، یک کپی از دیتابیس DB1 روی EXMB1 به صورت Active در حال اجرا است. سایر اعضای DAG یک کپی Passive از DB1 را دارا هستند. اعضای DAG برای دسترسی پذیری Mailbox با یکدیگر در ارتباط هستند. این ارتباطات به منظور نگه داری آخرین نسخه تغییرات نیز صورت می پذیرد. اگر سروری که دیتابیس Active را میزبانی می کند با مشکلی رو به رو گردد، بر اساس شرایط، یکی از اعضای دیگر DAG وضعیت دیتا بیس خود را به Acitve تغییر می دهد تا کلاینت ها همچنان قادر به دریافت اطلاعات Mailbox خود باشند. تصویر زیر این شرایط را متصور می شود.

image163

یک سرور که در یک DAG است می تواند شامل ترکیبی از دیتابیس های Active و Passive باشد و وضعیت Active/Passive بودن یک DB مستقل از سایر DB ها است. تصویر زیر مثالی از این شرایط را نشان می دهد.

image160

در مثال فوق، سه سرور با سه دیتابیس مختلف در یک DAG وجود دارند.

Continuous Replication

هر عضو DAG به منظور نگه داری یک دیتابیس به روز در یک فرایند پیوسته همگام سازی شرکت می کند. فراید همگام سازی بین Mailbox Server ها در Exchange با دو متد مختلف صورت می پذیرد:

۱) File Mode replication: هر تراکنش در یک log file به صورت کامل نوشته می شود و سپس از سروری که دارای Active Database است روی هر سروری در آن DAG که دارای Passive Database است کپی می شود.

اعضای DAG با دریافت Log file مربوطه تراکنش را به Passive Database خود اعمال می کنند. کمبود واضح File Mode Replication آن است که تراکنش هایی که هنوز Log file مربوط به آن ها به سایر اعضای DAG کپی نشده است ممکن است از دست بروند اگر سروری که Active Database را نگه داری می کند با اختلال رو به رو شود. با این وجود با استفاده از روش های دیگر Recovery امکان بازگردانی تراکنش های از دست رفته وجود دارد. به همین جهت File Mode Replication در راه اندازی اولیه DAG به کار گرفته می شود.

۲) Block Mode Replication: پس از آنکه همگام سازی اولیه خاتمه یافت؛ روش Replication به صورت خودکار به این روش سوییچ می شود. در حالی که هر تراکنش یک Log File روی سروری که Active DB را دارا است نوشته می شود، آن Log File روی Active Server بافر شده و آن بافر به اعضای دیگر DAG که Passive Database را نگه داری می کنند ارسال می شود. زمانی که بافر تکمیل شود، سایر اعضای DAG می توانند عملیات ساخت Transaction Log خود را انجام دهند و آن را روی کپی Passive خود اعمال نمایند. مزیت این روش نسبت به روش پیشن آن است که احتمال از دست رفتن log های مربوطه کاهش می یابد.

Quorum برای Exchange 2013 DAG

یک Exchange DAG از Windows Failover Clustering و Quorum استفاده می کند. عملیات مربوطه توسط Exchange به صورت خودکار صورت می گیرد. اگر با مفوم Quorum آشنایی ندارید، آن را یک فرایند رای گیری تصور کنید که اکثریت آرا به عنوان تصمیم اتخاذ می شود. به دلیل آنکه اکثریت آرا برای انکه Quorum لازم است، بر اساس تعداد نود ها دو مکانیزم مختلف وجود دارد. در یک DAG با تعداد فردی نود از اکثریت نود ها استفاده می شود. (Node Majority)

image157

در مثال تصویری فوق، سه عضو DAG وجود دارند که در زمان وقوع یک مشکل در یک سرور امکان Quorum را دارند اما زمانی که ۲ سرور با مشکل رو به رو شوند Quorum از دست می رود. برای یک DAG با تعداد زوجی نود، از اکثریت نود ها و فایل های به اشتراک گذاشته شده استفاده می شود (Node and File Share Majority). این متد دارای یک مرحله اضافه است که به آن File Share Witness گفته می شود. عموما File Share Witness یک Exchange Server دیگر است که در همان سایتی که Exchnage DAG است وجود دارد.

image154

در مثال فوق وجود چهار عضو DAGبه انضمام File Share Witness – FSW برای Quorum استفاده می گردد. DAG می تواند Quorum را تا وجود اختلال روی دو سرور مدیریت کند، اما زمانی که سه سرور از دسترس خارج شود Quorum از دست می رود.

DAG هایی که روی Window Server 2012 ایجاد گردند با کمک بهره گیری از قابلیت Dynamic Quorum در برابر وقوع خطا روی تعداد نود های بیشتری مقاومت دارند. زمانی که Option فوق Enable باشد، Cluster به صورت داینامیک Vote Assignment ها را بر اساس وضعیت هر نود مدیریت می کند. Vote های نود هایی که Active Membership کلاستر را ترک کنند حذف می شود.

Database Availability Networks

یک شبکه DAG به یک یا چند IP Subnet که چند نود DAG در آن حضور دارند و جهت ارتباط Replication و سایر ترافیک ها مورد استفاده قرار می گیرد گفته می شود.

image151

هر DAG Network شامل Subnet ای برای ارتباط MAPI و در حالات بهبود یافته شامل Subnet هایی برای Replication است. وجود Subnet های اختصاصی برای Replication سبب می شود Utilization پهنای باند از سمت کلاینت ها مدیریت شود.

image148

High Availability and Site Resilience

DAG هم برای HA و هم برای Site Resilience به کار گرفته می شود. DAG هایی که برای HA ایجاد می گردند در یک Active Directory Site قرار دارند.

image145

DAG هایی که به منظور Site Resilience ایجاد می گردند اغلب در دو دیتا سنتر مختلف وجود دارند و به منظور دسترسی پذیری سرویس Mailbox پس از با اختلال رو به رو شدن تمام سایت است. به عبارت دیگر در یک Disaster (سانحه) لازم است ایجاد گردد.

image142

در سناریو های Site Resilience به نسبت سناریو های HA موضوعات فنی بیشتری لازم است مورد توجه قرار گیرد. این سند روی پیاده سازی HA متمرکز شده است.

آماده سازی پیش از راه اندازی

DAG روی سرور های دارای Mailbox Role اجرای می گردد. هر چند وجود یا عدم وجود Client Access role ارتباطی به راه اندازی DAG ندارد، در برخی از سناریو ها Client Access نباید روی آن سرور نصب گردد. به عنوان مثال:

۱) در بسیاری از پیاده سازی ها، از Network Load Balancing یا NLB برای Client Access Role استفاده می گردد. در این صورت NLB برای Client Access Role امکان حضور در کنار Clustering برای Mailbox role را ندارد.

۲) در Exchnage 2013 امکان حذف کردن یک Server Role به تنهایی وجود ندارد. اگر این احتمال وجود دارد که Client Access ممکن است لازم باشد به هر دلیلی از روی حذف گردد.

همچنین لازم است اقدامات لازم جهت انتخاب نسخه مناسب سیستم عامل با توجه به ویژگی های Clustering صورت پذیرد.

در سناریوی زیر دو Exchange Server به همراه یک File Witness Server وجود دارد.

image139

به کمک وجود DAG Incremental Deployment امکان راه اندازی DAG روی Mailbox server هایی که در حال سرویس دهی هستند وجود دارد.

تنظیم مجوز های دسترسی برای File Witness

از آنجایی که File Witness Server یک Exchange Server نیست، لازم است مجوز های دسترسی تنظیم گردند. گروه Exchange Trusted Subsystem روی Active Directory لازم است به گروه Local Administrators اضافه گردد.

image136

علاوه بر آن، نیاز به نصب File Server role وجود دارد. برای این منظور در PowerShell از دستور Add-WindowsFeature FS-FileServer استفاده می کنیم و در نهایت لازم است دسترسی های فایروال برای File and Printer Sharing امکان پذیر گردد.

image133

اگر File Witness Server یک Exchange Server است، به صورت پیش فرض مجوز های لازم وجود دارد. اگر به صورت دستی دایرکتوری File Witness Server را معین نکرده باشید در SystemRoot%\DAGFileShareWitnesses% ایجاد می گردد. اگر دایرکتوری را معین کرده باشید، تا زمانی که DAG دارای member شود ساخته نخواهد شد و پس از آن دارای Witness Folders خواهد بود.

image130

تنظیمات شبکه

در این سناریو از دو Subnet مختلف استفاده می گردد. وجود Subnet های اختصاصی برای Replication اجباری نیست. اگر Replication Network در نظر می گیرد لازم است که اطمینان حاصل نمایید DNS Registration غیر فعال است. همچنین در بسیاری از سناریو ها وجود Default Gateway بدون دلیل است.

image127

image124

مدیریت دیتا بیس های موجود

پیش از ایجاد DAG ممکن است لازم باشد اقدامات مختلفی جهت مدیریت دیتابیس ها صورت گیرد. در این سناریو “Mailbox DataBase1” روی E15MB1 از Default Path به Storage ای که به نگه داری دیتابیس تخصیص داده شده است منتقل شده است. این دیتا بیس شامل Mailbox هایی برای تعدادی از افراد می باشد. همچنین Mailbox Database 2 رویE15MB2 از آنجایی که شامل هیچ Mailbox ای نبوده است حذف شده است. با توجه به شرایط محیط عملیاتی، روش های مدیریت دیتابیس می تواند متمایز باشد.

Pre-Stage کردن اکانت کلاستر

بر اساس شرایط سناریوی اجرا ممکن است لازم باشد اکانت Cluster Name Object – CNO از پیش ساخته شود. Pre-Stage کردن اکانت در تمام سناریو ها توصیه می شود. CNO یک کامپیوتر امانت روی Active Directory است.

برای ساخت اکانت، در کنسول Active Directory Users and Computers یک کامپیوتر اکانت با نامی که قصد دارید برای DAG استفاده کنید ایجاد کرده و آن را Disable کنید.

image118

سپس لازم است که به اولین عضوی که قصد دارید در DAG اضافه کنید، روی اکانت ساخته شده مجوز Full Control دهید.

image115

Deploy کردن DAG

برای این منظور در Exchange Admin Center در قسمت Servers -> Database Availability Groups آیکون + را زده و اطلاعات زیر را وارد نمایید:

فیلد شرح
DAG name نام DAG که لازم است با نام CNO ساخته شده یکی باشد.
Witness server برای تمام DAG وجود Witness Server الزامی است.
Witness directory این فیلد اختیاری است. اگر معین نگردد، از دایرکتوری پیش فرض مشروح شده در قسمت قبلی استفاده می شود.
IP address آدرس IP مربوط به DAG. اگر معین نگردد از طریق DHCP دریافت می گردد.

image109

در پایان گزینه Save را بزنید.

image106

افزودن دیتا بیس به DAG

زمانی که DAG ساخته می شود، شامل هیچ عضوی نمی باشد. در قسمت atabase Availability Group، لازم است DAG مطلوب را انتخاب کرده و گزینه Manage DAG Membership را بزنید.

image103

سرور هایی که می خواهید به DAG اضافه کنید را انتخاب کنید و Save را بزنید. این فرایند، Windows Failover Clustering را روی Windows Server 2012 راه اندازی می کند و اعضای انتخاب شده را به DAG Cluster ایجاد شده می افزاید.

تذکر: اگر از یک سرور غیر Exchange به عنوان File Witness Server استفاده نمایید، در این مرحله ممکن است با پیام هشداری رو به رو شوید که Exchange Trusted Subsystem عضو گروه Local Administrators نمی باشد. در صورتی که Exchange Trusted Subsystem را در مراحل پیشین عضو گروه Local Administrators کرده اید، به راحتی این پیام را در نظر نگیرید.

image100

با اتمام فرایند، اعضای DAG در قسمت member Servers قابل مشاهده خواهند بود.

image97

تنظیم کپی های دیتابیس ها

در این مرحله دو Mailbox Server در یک DAG و یک دیتا بیس وجود دارد. شکل زیر وضعیت کنونی را نمایش می دهد.

image94

در این مرحله قصد داریم، انجام همگام سازی دیتابیس را به سرور دیگر تنظیم کنیم. یکی از مهمترین اقدامات پیش از افزودن Database بررسی وجود همان مسیر روی سرور دیگری که قصد افزودن دیتابیس به آن را داریم می باشد.

image91

اکنون لازم است در قسمت Servers -> Databases در ECP گزینه Add a database copy را می زنیم.

image88

سپس با استفاده از browse، لازم است Mailbox Server مورد نظر را که قصد افزودن کپی را به آن داریم اضافه می کنیم.

image85

Activation preference number به صورت خودکار و به صورت Incremental (افزایشی) تولید می شود. از آنجایی که E15MB1 قبلا دارای یک دیتا بیس با preference 1 است، در مثال ۲ انتخاب شده است. Activation preference عموما باید منعکس کننده ی ترتیبی باشد که شما برای نگه داری دیتابیس Active ترجیح می دهید زیرا در سناریو های Failover خودکار به عنوان یک فاکتور در نظر گرفته می شود. همچنین امکان rebalance کردن به صورت دستی وجود دارد.

با زدن گزینه More Options تنظیمات بیشتری برای replay lag و postponing انجام Seed اولیه Database copy را می توانید مشاهده کنید. با زدن دکمه Save ساخت Database Copy آغاز می شود.

image82

اگر به مسیر File Path روی Server ای که Database copy را روی ان اضافه می کنید نگاه کنید، باید فایل های دیتابیس و Transaction log را بتوانید مشاهده کنید.

image79

یک دیتا بیس کوچک نباید بیشتر از دقایقی کوتاه طول بکشد اما دیتابیس های بزرگتر و شبکه ها کند تر سبب می شوند که زمان بیشتری برای ساخت نیاز باشد.

image76

زمانی که عملیات تکمیل شود، سرور دوم هم دارای database خواهد بود و با فراید continuous replication آن copy را به روز نگه می دارد.

image73

همچنین در Exchange Admin Center می توان مشاهده کرد که دو سرور دارای دیتا بیس هستند.

image70

همچنین با cmdlet زیر می توانید، وضعیت سرور های یک دیتابیس را کنترل کنید.

image67

مدیریت Switchover دیتابیس ها

دیتابیس های روی یک DAG که به صورت مداوم دارای Replication هستند، عموما در یکی از وضعیت های Passive یا Active قرار می گیرند. علاوه بر آن وضعیت های دیگری همانند Seeding و یا به دلیل مشکلات وجود دارد. در این قسمت تنها شرایط Healthy مورد بررسی قرار می گیرد.

Active Database، یک کپی از دیتابیس است که روی یک سرور عضو یک DAG وجود دارد و در به کلاینت های Mailbox Server سرویس می دهد. یک Passive Database که حداکثر تا ۱۵ تا می توانند باشند، سایر کپی های دیتابیس هستند که روی همان DAG قرار دارد. تغییرات از Active Database روی Passive Database ها کپی می شود.

image64

Active Database می تواند بین اعضای یک DAG جا به جا شود. نکته قابل توجه آن است که این عملیات یک جا به جایی واقعی و انتقال فیزیکی اطلاعات بین اعضای DAG نمی باشد و فقط دیتابیس فعال Dismount شده و یک دیتابیس غیرفعال (Passive) دیگر Mount می شود.

دو روش برای انتقال Database Copy وجود دارد:

۱) Failover: یک رویداد برنامه ریزی نشده است همانند Server Failures که سبب جا به جایی Active Database می شود.

۲) Switchover: یک رویداد برنامه ریزی شده مدیریتی است برای عملیاتی همچون نگه داری و آزمایش سیستم مقاومت در برابر خطا به کار گرفته می شود.

دو دیتابیس مختلف روی دو سرور مختلف را در نظر بگیرید به طوری که هر سرور دارای یک دیتابیس فعال (Active) باشد:

image61

برای انتقال Database1 به E15MB2 کافی است، آن را انتخاب کرده و وضعیت دیتابیس کپی را چک نماییم. همانظور که در تصویر مشاهده کنید وضعیت دیتابیس کپی Healthy است و طول صف آن صفر است بنابراین برای عملیات انتقال شرایط مناسبی وجود دارد. با زدن Activate می توان عملیات Switchover را ادامه داد.

image58

پس از تایید، عملیات انجام می گردد.

image55

در نهایت می توانید وضعیت دیتابیس ها بررسی نمایید.

image52

Reseed کردن یک Failed Database

بنا بر دلایل گوناگونی ممکن است یک دیتابیس در وضعیت Failed قرار بگیرد همانند Failure های سخت افزاری. پس از حل مشکل دلیل اصلی Failure لازم است دیتابیس Reseed گردد. Reseed کردن فرایندی است که تحت آن یک کپی جدید از دیتابیس را با استفاده از Replication از یک عضو دیگر DAG ایجاد می کند.

در اینجا به صورت عمدی یک Database Failure ایجاد کرده ایم که از طریق Cmdlet زیر در PowerShell قابل مشاهده است.

image49

زمان مورد نیاز جهت انجام Reseed همانطور که قبلا اشاره شده وابسته به حجم دیتابیس و پهنای باند شبکه Replication است. به صورت پیش فرض Reseed شدن از روی Active Database صورت می گیرد. اگر DAG member ها فقط در یک Subnet با پهنای باند مناسب باشند، این موضوع قابل توجه نخواهد بود.

image46

در حالی که اگر اعضای DAG در سایت های مختلفی در یک شبکه WAN باشند، موضوع قابل توجه می شود. خوشبختانه امکان انتخاب Source (منبع) جهت انجام Reseed وجود دارد و به این صورت می توان بهترین سرور عضوی یک DAG را از لحاظ پهنای باند جهت Reseed انتخاب کرد.

image43

Reseed کردن با استفاده از Exchange Admin Center

در قسمت Servers -> Databases، ابتدا دیتابیسی که قصد Reseed کردن آن را دارید انتخاب کنید.

image40

و سپس گزینه Update را کلیک کنید.

image37

با استفاده از browse می توانید Source Server را انتخاب کنید.

image34

عملیات Reseed با زدن دکمه Save آغار می شود.

image31

Reseed کردن با استفاده از PowerShell

در PowerShell می توانید با استفاده از دستور زیر Reseed را انجام دهید و Source را انتخاب نمایید.

image28

اگر با خطایی مبنی بر وجود Transaction Log Files از قبل مواجه شده اید، می توانید از سوییچ -DeleteExistingFiles استفاده کنید. همچنین برای Reseed های طولانی اگر نمی خواهید Exchange Management Shell را باز رها کنید و یا در اسکریپت ها اگر نمی خواهید اجرای اسکریپت تا اتمام Reseed متوقف شود، می توانید از سوییچ -BeginSeed استفاده کنید.

حذف کردن یک عضو از DAG

در یک محیط Exchange ممکن است بنا به دلایل مختلفی لازم باشد یک عضوی از DAG حذف گردد و یا Exchange Server از یک Server به صورت کامل حذف گردد. در این شرایط پیش از uninstall کردن Exchange لازم است ابتدا آن سرور از DAG خارج گردد.

image25

برای این منظور لازم است رویه زیر اتخاذ گردد:

۱- حذف تمام Database copy ها

۲- حذف کردن Exchange Server از DAG

اگر می خواهید Exchange Server را uninstall کنید، لازم است تمام دیتابیس های روی سرور را حذف نمایید.

برای این منظور کافی است در Servers -> Databases، دیتابیس مطلوب را انتخاب کنید و گزینه Remove مربوط به Server مطلوب را بزنید.

image22

همچنین با استفاده از دستور PowerShell زیر می توانید تمام Database های موجود روی Server را حذف نمایید.

image19

برای حذف کردن یک سرور از یک DAG به قسمت Database Availability Groups رفته و دکمه Manage DAG Membership را بزنید.

image16

سپس سرور مورد نظر را انتخاب کنید و دکمه – را بزنید.

image13

همچنین با دستور PowerShell زیر می توانید به صورت مشابه عمل کنید.

image8

در نهایت برای پاک کردن Exchange از روی سرور می توانید به صورت معمول از طریق Programs and Features عمل کنید.

<

p align=”center”>image3

یک دیدگاه در “Exchange DAG

  1. با سلام و خسته نباشید بابت سایت بسیار خوبتون سوال منه اینه که من دوتا سرور اکسچنج دارم که عضو dag می باشند ولی متاسفانه یکی از سرور ها خاموش بشه اون یکی قادر به سرویس دهی نمی باشد اصلا دیتا بیس دیسمونت می شه

    exchange 2013
    windows 2012r2

پاسخ دهید

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