توزیع بار در Exchange 2016 نسبت به نسخه‌های قدیمی ساده‌تر شده است. با تثبیت تعداد نقش‌ها در سرور Exchange در نسخه‌های جدیدتر، تعداد تصمیم کمتری باید گرفته شود و راهکارهایی کنترل ترافیک که توسط Exchange بکار گرفته می‌شود،آن را به‌آسانی در توزیع بار ترافیک قابل‌اطمینان می‌کند.
نحوه LoadBalance کردن IP ها برای ایمیل های ارسالی توسط Exchange
اگر شما قصد مهاجرت از نسخه‌های قبلی رادارید، بعضی تنظیمات تغییرات قابل‌ملاحظه‌ای پیداکرده است. در Exchange 2010 راهکار توزیع بار پیچیده و مشکل بود. زمانی که شما از Clent AccessArray برای ل توزیع بار استفاده می‌کردید به‌غیراز ترافیک تحت وب، ترافیک پروتکل MAPI نیز نیاز به توزیع بار داشت که این کار باعث پیچیدگی بیشتر و وابستگی بین سرورها و پروتکل‌های آن‌ها را بیشتر می‌نمود.
راه‌اندازی، پیکربندی و نگهداری توزیع بار در Exchange 2010 نیازمند مهارت و دقت بیشتری در پیکربندی بود و بخصوص اگر قصد انجام این کار برای سرویسی مانند SSL را داشته باشیم. در Exchange 2013، توزیع بار به‌صورت قابل‌ملاحظه‌ای ساده‌تر شده است و هم‌چنین تعداد نقش‌ها به دو نقش Mailbox و Client Access تعدیل پیداکرده است.
در Exchange 2016 همه‌چیز ساده‌تر گشته و سرور Exchange یک نقش دارد آن‌هم نقش Mailbox می‌باشد؛ و همین یک نقش mailbox تمامی قابلیت‌ها و توانایی‌های Exchange 2013 که چند نقش داشت را انجام می‌دهد؛ و تمامی ترافیک ورودی کلاینت‌ها که قصد اتصال به هرکدام از سرورهای Mailbox را داشته باشند و مسیریابی آن را به‌صورت بهینه‌تر و مؤثرتر انجام می‌دهد. و این بدان معنی می‌باشد که در Exchange 2016 تصمیم برای انجام توزیع بار بسیار آسان می‌باشد. در این مقاله ما به چگونگی انجام توزیع بار در Exchange 2016 و فراهم کردن یک نمونه کاربردی توزیع بار می‌پردازیم.
تغییرات در اتصال کلاینت‌ها به Exchange 2016
یکی از بزرگ‌ترین تغییراتی که در Exchange 2016 اتفاق افتاده است تعداد نقش‌های موجود در آن می‌باشد. در Exchange 2010، نقش‌های Client Access,Hub Transport,Mailbox,Unified Messaging وجود داشت و در Exchange 2013 تعداد نقش‌ها به Client Acees,Mailbox تعدیل یافت. در Exchange 2016 این تعدیل ادامه پیداکرده و فقط نقش Mailbox باقی‌مانده است. در داخل سرور Mailbox مؤلفه Client Access Proxy که در Exchange 2013 معرفی شد هنوز حضور دارد و درنتیجه در Exchange 2016 سه نقش client access, hub transport, unfied messaging به‌صورت غیرقابل‌تفکیک بر روی یک سرور قرار دارند و مایکروسافت راه‌اندازی یک سرور تمام نقش را برای توسعه این سرویس الزامی کرده است.
در Exchange 2013 نقش client access کار بخصوصی انجام نمی‌داد و بدین‌صورت بود که اگر یک کاربر قصد اتصال به mailbox خود را داشت این درخواست به‌صورت پروکسی به سرور mailbox که میل باکس کاربر بر روی آن قرار داشت ارجاع داده می‌شد و سرویس‌هایی مانند اوتلوک عملیات پردازشی را در سرور mailbox انجام می‌دادند و نقش‌های اضافی حذف می‌گردید. نقش Mailbox در Exchange 2016 در حال حاضر شامل تمامی این قابلیت‌ها می‌باشد، به این معنی می‌باشد که دو سرور که میل باکس‌های مجزا بر روی آن‌ها قرار دارد در صورت نیاز ترافیک را برای یکدیگر پروکسی می‌کنند. سرور Mailbox که نسخه اصلی یک میل باکس در اختیارش می‌باشد به درخواست‌های برای دسترسی به آن میل باکس پاسخ‌دهی می‌کند حتی اگر کاربر درخواستش را به سرور Mailbox دیگری بفرستد. و در نهیت تمامی ترافیک که به سرور Exchane می‌رسد بر روی پروتکل HtTTP/HTTPS می‌باشد و دیگر هیچ کلاینتی به‌صورت مستقیم نمی‌تواند از پروتکل MAPI استفاده نماید.
بهبودهای انجام‌شده بر روی توزیع بار LoadBalancing
دسترسی HTTPS-only از سمت کلاینت‌ها به سرور بدین معنی می‌باشد که فقط یک پروتکل ارتباطی وجود دارد که در مورد آن ملاحظاتی داریم؛ و پروتکل HTTP یک انتخاب پرهزینه به خاطر خطاهایی که به انجام آن معروف می‌باشد. بهبود دوم راهکاری است در وابستگی بین پروتکل‌ها ایجادشده است. اوتلوک تحت وب عملیات پردازشی رو بر روی همان سروری انجام می‌دهد که دیتابیس ایمیل درخواستی قرارداد؛ و برای آن فرقی ندارد که کدام توزیع‌کننده بار (Load Balancer) ترافیک را به سمت آن هدایت کرده استو وقتی یک توزیع‌کننده بار (Load Balancer) ترافیک را به سمت هر سروری هدایت کند تأثیر قابل‌توجه در کارایی نمی‌گذارد زیرا نشست owa در حال اجرا می‌باشد.
چالش در وابستگی نشست در احراز هویت forms-based نیز مرتفع گردیده است. درگذشته بدین‌صورت بود که از وابستگی استفاده می‌شد تا از تلاش مجدد برای لاگین نمودن جلوگیری شود وقتی توزیع‌کننده بار (Load Balancer) ترافیک را به سرور دیگری می‌فرستد. این مشکل در Exchange 2013 با بهبود به‌کارگیری از کوکی‌ها در وب توسط Exchange مرتفع گردید. کوکی‌های مربوط به احراز هویت در رمزنگاری گواهی دیجیتال بعد از لاگین کاربر به آن کمک می‌کنند؛ و این ممکن می‌سازد که کاربری که لاگین نموده ادامه کارش را بر روی یک Client access دیگر بدون احراز هویت انجام دهد.با فرض اینکه سرورها از یک گواهی دیجیتال به‌صورت اشتراکی استفاده کنند پس توانایی رمزگشایی کوکی احراز هویت که کلاینت ارائه می‌کند را دارا می‌باشند.
ساختار ساده‌شده جدید این موقعیت را فراهم می‌کند که توزیع بار به ساده‌ترین حالت ممکن قابل انجام باشد. اگر مایل باشید می‌توانید از DNS Round robin که تکنیکی می‌باشد که به‌صورت ساده‌ای پی سرورها را در اختیار کلاینت‌ها می‌گذارد و اگر یکی از سرورها به‌صورت کامل دچار مشکل گردد، این پروتکل به‌قدری هوشمند می‌باشد که می‌تواند این ارتباط را با یک سرور دیگر برقرار کند. در مورد DNS Round roubin تعدادی اختلال در عملکرد ممکن است وجود داشته باشد. درواقع نمی‌توان آن را یک توزیع بار (LoadBalanc) کامل نامید و هیچ تضمینی وجود ندارد که سرورها مقدار ترافیک مناسبی دریافت کنند؛ و هیچ مانیتورینگ در لایه سرویس انجام نمی‌دهد. برای مثال درصورتی‌که یک سرویس مانند owa دچار اختلال گردد بجای اینکه کاربر را به سرور دیگر هدایت کند صفحه ارور را به کاربر نشان می‌دهد؛ و از دیگر معایب آن این است که اگر بر روی اینترنت نشر (publish) شده باشد به ازای هر سرور نیاز به یک ای پی آدرس اینترنتی دارد.
ما می‌خواهیم توزیع‌کننده باری داشته باشیم تا هرکدام یک از سرویس‌های نمایی Exchange (از نگاه کلاینت) را مونیتور نماید و اگر خطایی رخ داد ترافیک را به سمت سرور دیگری هدایت کند و هم‌چنین ما به توزیع‌کننده باری نیاز داریم که بتواند تا حدی توزیع و پخش بار را طوری انجام دهد که فقط یک سرور گلوگاه اتصال کاربران به صندوق‌های صوتی نباشد. و ما می‌توانیم این کار را در لایه ۴ و لایه ۷ انجام دهیم. در حالت لایه ۴ توزیع‌کننده بار نمی‌تواند محتوای ترافیک درخواستی را ببیند و به‌صورت ساده‌ای ترافیک را به یک مقصد مشخص ارسال می‌کند؛ اما در توزیع بار در لایه ۷ امکان بازرسی محتوا و تصمیم‌گیری بر اساس آن وجود دارد.
توزیع بار در لایه ۴ نیاز به منابع مصرفی کمتری دارد و به ازای هر ای پی فقط یک سرویس قابل پیکربندی می‌باشد (مانند سرویس OWA, ActiveSync,MAPI-HTTP) و از مزایای آن پیکربندی آسان و معایب آن این است که ممکن است یک سرور در حال سرویس‌دهی باشد در صورتی یکی از سرویس‌های حیاتی آن قطع باشد و در این صورت کاربر با خطا مواجه می‌شود. بنابراین برای مانیتورینگ سرویس‌های Exchange در لایه ۴ به ازای هر سرویس نیاز به یک ای پی داریم. درصورتی‌که در مانیتورینگ در لایه ۷ به دلیل فهم مسیر (path) در ترافیک HTTP فقط نیاز به یک ای پی داریم.
نحوه LoadBalance کردن IP ها برای ایمیل های ارسالی توسط Exchange
آموزش کامل نصب میل سرور Microsoft Exchange Server 2016
دانلود Exchange Server 2013 ,2010
دانلود SQL Server 2014 Enterprise x64
اموزش ﻧﺼﺐ و راه اﻧﺪازي ﺳﺮورSQL 2014