توزیع بار در Load balancing Exchange Server 2016 نسبت به نسخه‌های قدیمی ساده‌تر شده است. با تثبیت تعداد نقش‌ها در سرور Exchange در نسخه‌های جدیدتر، تعداد تصمیم کمتری باید گرفته شود و راهکارهایی کنترل ترافیک که توسط Exchange بکار گرفته می‌شود، آن را به آسانی در توزیع بار ترافیک قابل‌اطمینان می‌کند.
اگر شما قصد مهاجرت از نسخه‌های قبلی را دارید، بعضی تنظیمات تغییرات قابل ملاحظه‌ای پیداکرده است. در Exchange 2010 راهکار توزیع بار پیچیده و مشکل بود. زمانی که شما از Clent Access Array برای توزیع بار استفاده می‌کردید به غیر از ترافیک تحت وب، ترافیک پروتکل MAPI نیز نیاز به توزیع بار داشت که این کار باعث پیچیدگی بیشتر و وابستگی بین سرورها و پروتکل‌های آن‌ها را بیشتر می‌نمود.
راه‌اندازی، پیکربندی و نگهداری توزیع بار در Exchange 2010 نیازمند مهارت و دقت بیشتری در پیکربندی بود و بخصوص اگر قصد انجام این کار برای سرویسی مانند SSL را داشته باشیم.
در Exchange 2013، توزیع بار به‌صورت قابل‌ملاحظه‌ای ساده‌تر شده است و هم چنین تعداد نقش‌ها به دو نقش Mailbox و Client Access تعدیل پیداکرده است.
در Exchange 2016 همه چیز ساده‌تر گشته و سرور Exchange یک نقش دارد آن هم نقش Mailbox می‌باشد؛ و همین یک نقش mailbox تمامی قابلیت‌ها و توانایی‌های Exchange 2013 که چند نقش داشت را انجام می‌دهد؛ و تمامی ترافیک ورودی کلاینت‌ها که قصد اتصال به هرکدام از سرورهای Mailbox را داشته باشند و مسیریابی آن را به‌صورت بهینه‌تر و مؤثرتر انجام می‌دهد. و این بدان معنی می‌باشد که در Exchange 2016 تصمیم برای انجام توزیع بار بسیار آسان می‌باشد.
در این مقاله ما به چگونگی انجام توزیع بار در Load balancing Exchange Server 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 می‌رسد بر روی پروتکل HTTP/HTTPS می‌باشد و دیگر هیچ کلاینتی به‌صورت مستقیم نمی‌تواند از پروتکل MAPI استفاده نماید.
بهبودهای انجام‌شده بر روی توزیع بار Load balancing Exchange Server 2016
دسترسی HTTPS-only از سمت کلاینت‌ها به سرور بدین معنی می‌باشد که فقط یک پروتکل ارتباطی وجود دارد که در مورد آن ملاحظاتی داریم؛ و پروتکل HTTP یک انتخاب پرهزینه به خاطر خطاهایی که به انجام آن معروف می‌باشد.
بهبود دوم راهکاری است در وابستگی بین پروتکل‌ها ایجاد شده است. اوتلوک تحت وب عملیات پردازشی رو بر روی همان سروری انجام می‌دهد که دیتابیس ایمیل درخواستی قرارداد؛ و برای آن فرقی ندارد که کدام توزیع‌کننده بار (Load balancing Exchange Server) ترافیک را به سمت آن هدایت کرده استو وقتی یک توزیع‌کننده بار (Load balancing Exchange Server) ترافیک را به سمت هر سروری هدایت کند تأثیر قابل‌توجه در کارایی نمی‌گذارد زیرا نشست owa در حال اجرا می‌باشد.
چالش در وابستگی نشست در احراز هویت forms-based نیز مرتفع گردیده است. درگذشته بدین‌صورت بود که از وابستگی استفاده می‌شد تا از تلاش مجدد برای لاگین نمودن جلوگیری شود وقتی توزیع‌کننده بار (Load Balancer) ترافیک را به سرور دیگری می‌فرستد. این مشکل در Exchange 2013 با بهبود به‌کارگیری از کوکی‌ها در وب توسط Exchange مرتفع گردید.
کوکی‌های مربوط به احراز هویت در رمزنگاری گواهی دیجیتال بعد از لاگین کاربر به آن کمک می‌کنند؛ و این ممکن می‌سازد که کاربری که لاگین نموده ادامه کارش را بر روی یک Client access دیگر بدون احراز هویت انجام دهد.با فرض اینکه سرورها از یک گواهی دیجیتال به‌صورت اشتراکی استفاده کنند پس توانایی رمزگشایی کوکی احراز هویت که کلاینت ارائه می‌کند را دارا می‌باشند.
ساختار ساده‌شده جدید این موقعیت را فراهم می‌کند که توزیع بار به ساده‌ترین حالت ممکن قابل انجام باشد. اگر مایل باشید می‌توانید از DNS Round robin که تکنیکی می‌باشد که به‌صورت ساده‌ای پی سرورها را در اختیار کلاینت‌ها می‌گذارد و اگر یکی از سرورها به‌صورت کامل دچار مشکل گردد، این پروتکل به‌قدری هوشمند می‌باشد که می‌تواند این ارتباط را با یک سرور دیگر برقرار کند.
در مورد DNS Round roubin تعدادی اختلال در عملکرد ممکن است وجود داشته باشد. درواقع نمی‌توان آن را یک توزیع بار (LoadBalanc) کامل نامید و هیچ تضمینی وجود ندارد که سرورها مقدار ترافیک مناسبی دریافت کنند؛ و هیچ مانیتورینگ در لایه سرویس انجام نمی‌دهد. برای مثال درصورتی‌که یک سرویس مانند owa دچار اختلال گردد بجای اینکه کاربر را به سرور دیگر هدایت کند صفحه ارور را به کاربر نشان می‌دهد؛ و از دیگر معایب آن این است که اگر بر روی اینترنت نشر (publish) شده باشد به ازای هر سرور نیاز به یک ای پی آدرس اینترنتی دارد.
ما می‌خواهیم توزیع‌کننده باری داشته باشیم تا هر کدام یک از سرویس‌های نمایی Exchange (از نگاه کلاینت) را مونیتور نماید و اگر خطایی رخ داد ترافیک را به سمت سرور دیگری هدایت کند و هم‌چنین ما به توزیع‌کننده باری نیاز داریم که بتواند تا حدی توزیع و پخش بار را طوری انجام دهد که فقط یک سرور گلوگاه اتصال کاربران به صندوق‌های صوتی نباشد.
و ما می‌توانیم این کار را در لایه 4 و لایه 7 انجام دهیم. در حالت لایه 4 توزیع‌کننده بار نمی‌تواند محتوای ترافیک درخواستی را ببیند و به‌صورت ساده‌ای ترافیک را به یک مقصد مشخص ارسال می‌کند؛ اما در توزیع بار در لایه 7 امکان بازرسی محتوا و تصمیم‌گیری بر اساس آن وجود دارد.
توزیع بار در لایه 4 نیاز به منابع مصرفی کمتری دارد و به ازای هر ای پی فقط یک سرویس قابل پیکربندی می‌باشد (مانند سرویس OWA, ActiveSync,MAPI-HTTP) و از مزایای آن پیکربندی آسان و معایب آن این است که ممکن است یک سرور در حال سرویس‌دهی باشد در صورتی یکی از سرویس‌های حیاتی آن قطع باشد و در این صورت کاربر با خطا مواجه می‌شود.
بنابراین برای مانیتورینگ سرویس‌های Exchange در لایه 4 به ازای هر سرویس نیاز به یک ای پی داریم. درصورتی‌که در مانیتورینگ در لایه 7 به دلیل فهم مسیر (path) در ترافیک HTTP فقط نیاز به یک ای پی داریم.(/owa, /ActiveSync, /mapi)
منبع: raika
