معماری Workspace ONE UEM چیست؟ بررسی ویژگی های آن – قسمت سوم (پایانی)

در قسمت اول و دوم مقاله در مورد معماری و ویژگی های معماری Workspace ONE UEM و همچنین در مورد معماریOn-Premises صحبت کردیم، حال به ادمه مقاله خواهیم پرداخت.

 تعدیل بار یا Load Balancing

برای حذف یک نقطه‌ی خرابی واحد، می‌توان بیش از یک Instance از اجزای Workspace ONE UEM EM را پشت یک تعدیل‌‌کننده‌ی بار خارجی پیاده‌سازی کرد. این استراتژی نه تنها افزونگی را فراهم می‌کند، بلکه این امکان را فراهم می‌نماید که بار و پردازش روی چندین Instance از جزء مربوطه پخش شوند. برای اطمینان حاصل کردن از اینکه خود تعدیل‌‌کننده‌ی بار تبدیل به یک نقطه‌ی خرابی واحد نشود، اکثر تعدیل‌‌کنندگان بار امکان تنظیم چندین Node را در یک پیکربندی با دسترس‌پذیری بالا یا HA یا به‌صورت Active/Passive فراهم می‌کنند.

ترافیک AirWatch Cloud Connector توسط جزء AirWatch Cloud Messaging تعدیل بار می‌شود. این ترافیک نیازمند یک تعدیل‌‌کننده‌ی بار جداگانه نمی باشد، چندین AirWatch Cloud Connector در یک گروه سازمانی واحد که برای دسترس‌پذیری بالا به سرور پیام‌رسانی Cloud یکسانی متصل می‌شوند، همگی می‌توانند انتظار دریافت ترافیک را در یک پیکربندی Active/Active داشته باشند. نحوه‌ی مسیریابی ترافیک توسط جزء مربوطه تعیین می‌شود و به مقدار بار موجود بستگی دارد.

مقیاس‌پذیری و دسترس‌پذیری

اجزای اصلی Workspace ONE UEM را می‌توان در یک طراحی واحد و اشتراکی پیاده‌سازی کرد، اما این پیاده‌سازی فقط برای موارد Proof-of-Concept پیشنهاد می‌شود. برای استفاده‌ی تولیدی، جهت پاسخ به نیازهای بار و اکثر طراحی‌های معماری شبکه، اجزای اصلی برنامه کاربردی معمولاً روی دو سرور جداگانه و اختصاصی Admin Console و Device Services نصب می‌شوند. برای یک محیط با دسترس‌پذیری بالا و جهت پاسخ به تقاضاهای بارِ پیاده‌سازی‌های بزرگ، چندین جزء از هر کدام از این اجزا را می‌توان روی سرورهای اختصاصی پشت یک تعدیل‌‌کننده‌ی بار پیاده‌سازی کرد. جدول زیر استراتژی پیاده‌سازی برای سرویس‌های دستگاه Workspace ONE UEM را نمایش می دهد.

تصمیم	چهار Instance از سرورهای سرویس‌های دستگاه Workspace ONE UEM در DMZ پیاده‌سازی شدند.
توجیه	برای رسیدگی به بار و پشتیبانی از پنجاه هزار دستگاه به سه سرور نیاز است. سرور چهارم برای افزونگی مورد استفاده قرار می‌گیرد. این سرورها حاوی اجزای زیر خواهند بود: سرویس‌های دستگاه Workspace ONE UEM.

جدول زیر استراتژی پیاده‌سازی برای سرورهای کنسول Workspace ONE UEM را نمایش می دهد.

تصمیم	سه Instance از سرورهای کنسول Workspace ONE UEM در شبکه‌ی داخلی نصب شدند.
توجیه	با توجه به بار و برای پشتیبانی از پنجاه هزار دستگاه به دو سرور نیاز است. سرور سوم برای افزونگی مورد استفاده قرار می‌گیرد. این سرورها حاوی اجزای زیر هستند: کنسول Workspace ONE UEM Admin.

در محیط‌های بزرگ‌تر که معمولاً شامل پنجاه‌هزار دستگاه یا بیشتر می‌باشد، سرویس‌های API و AWCM باید روی سرورهای جداگانه و اختصاصی قرار داشته باشند و بار خود را از سرورهای Device Services و Admin Console حذف کنند. جدول زیر استراتژی پیاده‌سازی برای سرورهای AWCM را نمایش میدهد.

تصمیم	دو Instance از سرورهای AWCM در شبکه‌ی داخلی پیاده‌سازی شدند.
توجیه	برای پشتیبانی از پیاده‌سازی‌های پنجاه‌هزار دستگاه و بیشتر، VMware پیشنهاد می‌کند که عملکرد AWCM از عملکرد Device Services جداسازی گردد.

جدول زیر استراتژی پیاده‌سازی برای سرورهای API را نشان می دهد.

تصمیم	یک پیاده‌سازی On-Premises از Workspace ONE UEM و اجزای مورد نیاز، دو Instance از سرورهای API بودند که در شبکه‌ی داخلی پیاده‌سازی شدند.
توجیه	برای پشتیبانی از پیاده‌سازی‌های پنجاه‌هزار دستگاه و بیشتر، VMware پیشنهاد می‌کند که عملکرد AWCM از عملکرد Device Services جداسازی گردد.

چندین Instance از AirWatch Cloud Connector یا ACC را می‌توان در شبکه‌ی داخلی برای یک محیط با دسترس‌پذیری بالا پیاده‌سازی نمود. بار برای این سرویس بدون نیاز به یک تعدیل‌‌کننده‌ی بار خارجی تعدیل‌ می‌گردد.

بیشتر بخوانید: معماری Workspace ONE UEM چیست؟ بررسی ویژگی های آن – قسمت اول

استراتژی پیاده‌سازی برای ACC در جدول زیر نمایش داده شده است.

تصمیم	سه Instance از AirWatch Cloud Connector پیاده‌سازی شدند.
توجیه	دو ACC Instance برمبنای Load مورد نیاز هستند و سومین مورد برای افزونگی اضافه می‌شود.

Workspace ONE UEM را می‌توان به‌صورت افقی توسعه داد تا فارغ از تعداد دستگاه‌ها، پاسخگوی تقاضاها باشد.  به دلیل میزان داده‌هایی که درون و خارج از دیتابیس Workspace ONE UEM جریان دارد، اندازه‌گیری درست سرور دیتابیس برای یک پیاده‌سازی موفق حیاتی است.

این معماری مرجع طوری طراحی شده است که حداکثر با پنجاه‌هزار دستگاه تطبیق داشته باشد و امکان رشد در طول زمان را بدون نیاز به طراحی مجدد فراهم کند. چندین Node از هر جزء خدمات دستگاه، Admin Consoles، سرورهای API، سرورهای AWCM، AirWatch Cloud Connectorها برای پاسخ به تقاضاها پیشنهاد می‌شوند. برای تضمین قابلیت خودترمیمی هر سرویس در یک سایت واحد، سرورهای برنامه کاربردی بیشتری اضافه می‌شوند. مثلاً Nodeهای خدمات دستگاه به جای سه Nodeی مورد استفاده قرار می‌گیرند که برای پاسخ به تقاضای بار مورد نیاز هستند.

بیشتر بخوانید: معماری Workspace ONE UEM چیست؟ بررسی ویژگی های آن – قسمت دوم

شکل بالا اجزای Workspace ONE UEM توسعه‌یافته به‌صورت Single-Site و On-Premises را نشان داده، این شکل یک محیط توسعه‌یافته را نشان می‌دهد که برای حداکثر پنجاه‌هزار دستگاه مناسب است. این محیط همچنین امکان رشد اضافی در طول زمان را بدون طراحی مجدد ممکن می‌سازد، زیرا از سرورهای API اختصاصی و سرورهای AWCM استفاده می‌کند.

• سرورهای خدمات دستگاه Workspace ONE UEM در DMZ قرار دارند و یک تعدیل‌‌کننده‌ی بار، بار را توزیع می‌کند.
• خدمات کنسول Workspace ONE UEM Admin، Memcached، سرورهای AWCM و سرورهای API در شبکه‌ی داخلی با یک تعدیل‌‌کننده‌ی بار، که روبه‌روی آن‌ها قرار دارد Host می‌شوند.
• سرورهای AirWatch Cloud Connector در شبکه‌ی داخلی Host می‌شوند و می‌توانند از اتصال خروجی استفاده کنند، بدون اینکه به یک تعدیل‌‌کننده‌ی بار خارجی نیاز داشته باشند.

برای این معماری مرجع از Split DNS استفاده شد؛ یعنی نام دامین با صلاحیت کامل یا FQDN یکسانی هم به‌صورت داخلی و هم خارجی برای دسترسی کاربر به سرور خدمات دستگاه Workspace ONE UEM مورد استفاده قرار گرفت.  Split DNSیک الزام مهم برای پیاده‌سازی On-Premises از Workspace ONE UEM نیست، اما تجربه‌ی کاربری را بهبود می‌بخشد.

طراحی Multi-Site

سرورهای Workspace ONE UEM درواقع Endpoint اصلی برای مدیریت و آماده‌سازی دستگاه‌های کاربر نهایی هستند. این سرورها باید طوری پیاده‌سازی شوند که در یک سایت دارای دسترس‌پذیری بالا باشند و در یک دیتاسنتر ثانویه نیز برای Failover و افزونگی پیاده‌سازی گردند. یک پالیسی پشتیبان‌گیری قدرتمند برای سرورهای برنامه کاربردی و سرورهای دیتابیس می‌توانند قدم‌های مورد نیاز برای بازیابی یک محیط Workspace ONE UEM به مکانی دیگر را به حداقل برسانند.

می‌توان با استفاده از فرایندها و روش‌هایی که پاسخگوی پالیسی‌های  Disaster Recovery یا DR هستند، DR را برای راهکار Workspace ONE UEM پیکربندی نمود.  Workspace ONE UEMهیچ وابستگی به پیکربندی DR ندارد، اما شدیداً پیشنهاد می‌شود که نوعی فرایند Failover برای سناریوهای DR توسعه داده شود. اجزای Workspace ONE UEM می‌توانند پیکربندی گردند تا با سناریوهای Disaster Recovery متداول تطبیق پیدا کنند.

Workspace ONE UEM حاوی اجزای اصلی زیر است که باید برای افزونگی طراحی شوند:

• خدمات دستگاه Workspace ONE UEM
• کنسول Workspace ONE UEM Admin
• سرور Workspace ONE UEM AWCM
• سرور Workspace ONE UEM API
• AirWatch Cloud Connector
• سرور Memcached
• سرور دیتابیس SQL

جدول زیر استراتژی خودترمیمی سایت برای Workspace ONE UEM را نشان می دهد.

تصمیم	یک سایت جدید با Workspace ONE UEM تنظیم شد.
توجیه	این استراتژی Disaster Recovery و خودترمیمی را برای پیاده‌سازی‌ On-Premises از Workspace ONE UEM فراهم می‌کند.

سرورهای برنامه کاربردی Workspace ONE UEM و AirWatch Cloud Connectorها

برای فراهم کردن خودترمیمی سایت، هر سایت نیازمند گروه برنامه کاربردی Workspace ONE UEM و سرورهای Connector خود است تا این امکان فراهم گردد که سایت به‌صورت مستقل و بدون اتکا به سایت دیگری کار کند. یک سایت به‌عنوان یک پیاده‌سازی Active اجرا می‌شود، درحالی‌که دیگری دارای پیاده‌سازی Passive است.

در هر سایت، سرورهای کافی برنامه کاربردی باید نصب شوند تا افزونگی Local فراهم گردد و سایت بتواند به‌تنهایی بار را تحمل کند. Hostشدن سرورهای Device Services در DMZ انجام می‌شوند، درحالی‌که سرور Admin Console در شبکه‌ی داخلی قرار دارد. هر سایت دارای یک تعدیل‌‌کننده‌ی بار Local است که بار را بین سرورهای Local Device Services توزیع می‌کند و بدون هیچ قطعی سرویس یا نیاز به Failover به یک سایت Backup، به خرابی یک سرور مجزا رسیدگی می‌شود. روبه‌روی هر تعدیل‌‌کننده‌ی بار سایت، از یک تعدیل‌‌کننده‌ی بار سراسری استفاده می‌گردد. در هر سایت، سرورهای AirWatch Cloud Connector در شبکه‌ی داخلی Host می‌شوند و می‌توانند از یک اتصال خروجی استفاده نمایند. جدول زیر استراتژی Disaster Recovery برای سرورهای برنامه کاربردی Workspace ONE UEM را نشان داده است.

تصمیم	مجموعه‌ای ثانویه از سرورها در یک دیتاسنتر ثانویه نصب شد. تعداد و عملکرد سرورها با چیزی که برای سایت اصلی اندازه‌گیری شده بود، یکسان بود.
توجیه	این استراتژی ظرفیت Disaster Recovery کاملی را برای تمام سرویس‌های Workspace ONE UEM به‌صورت On-Premises فراهم می‌کند.

سرورهای کنسول Multi-Site

در هنگام پیاده‌سازی چندین سرور کنسول، برخی از سرویس‌های Workspace ONE UEM باید فقط روی یک سرور کنسول اصلی فعال باشند تا از حداکثر عملکرد اطمینان حاصل گردد. پس از کامل شدن نصب  Workspace ONE UEM، این سرویس‌ها باید روی سرورهایی که اصلی نیستند غیرفعال گردند.

سرویس‌های Workspace ONE UEM که باید فقط روی یک سرور فعال باشند، عبارت‌اند از:

• AirWatch Device Scheduler
• AirWatch GEM Inventory Service
• Directory Sync
• Content Delivery Service

وقتی‌که سرورهای کنسول Workspace ONE UEM ارتقا داده شوند، Content Delivery Service به‌طور خودکار ری‌استارت می‌شود. سپس باید به‌صورت دستی سرویس‌های مربوطه را روی تمام سرورهای اضافی غیرفعال نمود تا بهترین عملکرد حفظ شود.

دیتابیس Multi-Site

همانطور که قبلاً اشاره شد، Workspace ONE UEM از Microsoft SQL Server 2012 و نسخه‌های بعدی آن و کلاستر آن پشتیبانی می‌کند که گروه‌های دسترس‌پذیری Always On را ارائه می‌دهد. این امر امکان پیاده‌سازی چندین Instance از سرورهای Device Services و سرورهای کنسول Workspace ONE UEM را فراهم می‌کند که به دیتابیس یکسانی اشاره دارند. این دیتابیس توسط یک گروه دسترس‌پذیری حفاظت می‌شود و یک Listener گروه دسترس‌پذیری نقش تنها هدف اتصال دیتابیس را برای تمام Instanceها بازی می‌کند.

برای این طراحی، یک Instance دیتابیس Active/Passive با استفاده از SQL Server Always On پیکربندی شده، این امر امکان Failover به یک سایت ثانویه را درصورتی‌که سایت از دسترس خارج شود، فراهم می‌کند. Failover بین سایتی دیتابیس، بسته به پیکربندی SQL Server Always On می‌تواند خودکار باشد، هرچند بدون وقفه نیست.

برای این معماری مرجع، یک پیاده‌سازی Always On با مشخصات زیر انتخاب شده است:

• از هیچ دیسک اشتراکی استفاده نشود.
• Instance دیتابیس اصلی در طول تولید عادی در سایت 1 اجرا شد.

استراتژی برای پیاده‌سازی Multi-Site از دیتابیس On-Premises در جدول زیر نمایش داده شده است.

تصمیم	از یک دیتابیس Microsoft SQL Always-On استفاده شد.
توجیه	این استراتژی، امکان همسان‌سازی دیتابیس را از سایت اصلی به سایت بازیابی فراهم کرده و امکان بازیابی عملکرد دیتابیس را ارائه می‌دهد.

Failover به سایت ثانویه

یک طراحی Workspace ONE UEM به‌صورت Multi-Site این امکان را فراهم می‌کند که ادمین‌ها بتوانند دسترس‌پذیری مداومی را از سرویس‌های Workspace ONE UEM حفظ کنند، برای شرایطی که یک فاجعه سایت Active اصلی را غیرقابل دسترسی نماید. نمودار زیر نمونه‌ای از معماری Multi-Site را نمایش می‌دهد.

برای انجام Failover به یک سایت ثانویه، ممکن است به یک مداخله‌ی دستی برای دو لایه از راهکار نیاز باشد:

• دیتابیس: Failover بین سایتی دیتابیس، بسته به پیکربندی SQL Server Always On می‌تواند خودکار باشد. در صورت لزوم، باید اقداماتی را انجام داد تا به‌صورت دستی کنترل شود که کدام سایت دارای SQL Node فعال است.
• خدمات دستگاه: تعدیل‌‌کننده‌ی بار سراسری کنترل می‌کند که ترافیک به کدام سایت هدایت گردد. در طول عملیات عادی، تعدیل‌‌کننده‌ی بار سراسری ترافیک را به تعدیل‌‌کننده‌ی بار Local روبه‌روی سرورهای Device Service در سایت 1 هدایت می‌نماید. در یک سناریوی Failover، تعدیل‌‌کننده‌ی بار سراسری باید تغییر کند تا ترافیک را به تعدیل‌‌کننده‌ی بار Local معادل در سایت 2 هدایت نماید.
• سرورهای کنسول: وقتی چندین سرور کنسول پیاده‌سازی می‌شوند، باید اطمینان حاصل کرد که سرویس‌های Workspace ONE UEM که قبلاً در سرورهای کنسول Multi-Site به آن‌ها اشاره شد، فقط روی سرورهای اصلی فعال هستند و روی سرورهای غیراصلی برای سایت 2 غیرفعال می‌باشند.