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

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

مقیاس‌پذیری

 با استفاده از یک نصب‌کننده‌ی واحد، می‌توان چندین Instance از ACC را با نصب آن‌ها روی سرورهای اختصاصی پیکربندی کرد. ترافیک به‌طور خودکار توسط جزء AWCM تعدیل بار می‌شود و نیازمند یک تعدیل‌‌کننده‌ی بار مجزا نیست. چندین Instance از ACC می‌توانند ترافیک را دریافت کنند، یعنی از پیکربندی Live-Live استفاده نمایند، به شرط اینکه Instanceها در گروه ‌سازمان‌دهی یکسانی باشند و به سرور AWCM یکسانی  برای دسترس‌پذیری بالا متصل شوند. ترافیک با استفاده از یک الگوریتم LRU یا همان Least Recently Used مسیریابی می‌شود که تمام اتصالات قابل‌دسترسی را بررسی می‌کند تا تصمیم بگیرد که باید برای مسیریابی درخواست بعدی از کدام ACC Node استفاده کند. جدول زیر استراتژی برای توسعه‌ی پیاده‌سازی ACC را نمایش می دهد.

تصمیم	سه Instance از AirWatch Cloud Connector در شبکه‌ی داخلی پیاده‌سازی شدند. این Instanceها روی VMهای Windows Server 2016 نصب شده بودند.
توجیه	دو ACC Instance برمبنای Load مورد نیاز هستند و سومین مورد برای افزونگی اضافه می‌شود.

نصب AirWatch Cloud Connector

معماری On-Premises

معماری Workspace ONE UEM از سرویس‌های جداگانه‌ای تشکیل شده است که می‌توانند روی یک معماری با یک یا چند سرور نصب شوند و به الزامات امنیتی و Load پاسخ دهند. Endpointهای سرویس را می‌توان روی حوزه‌های امنیتی مختلفی پخش کرد، آن‌هایی که نیازمند دسترسی خارجی و ورودی هستند، در یک DMZ قرار دارند و همانطور که در شکل زیر نمایش داده شده است، کنسول مدیریتی در یک شبکه‌ی داخلی حفاظت شده قرار دارد.

همسان‌سازی با منابع داخلی مثل Active Directory یا یک Certificate Authority را می‌توان مستقیماً از اجزای اصلی، یعنی Device Services و Admin Console یا با استفاده از یک AirWatch Cloud Connector انجام داد. متصل‌کننده‌ی جداگانه می‌تواند در حالت اتصال خروجی، درون LAN اجرا شود، یعنی متصل‌کننده هیچ اتصال ورودی را از DMZ دریافت‌ نمی‌کند.

پیاده‌سازی به سه جزء اصلی تقسیم می‌شود:

• کنسول Workspace ONE UEM Admin
• خدمات دستگاه Workspace ONE UEM
• AirWatch Cloud Connector

AirWatch Cloud Messaging Service را می‌توان به‌عنوان بخشی از سرور Workspace ONE UEM Device Services نصب کرد و API Endpoint به‌عنوان بخشی از سرور Admin Console نصب می‌گردد. بسته به مقیاس محیط، این موارد همچنین می‌توانند روی سرورهای مجزا نصب گردند. علاوه بر اجزایی که در معماری مبتنی بر Cloud توضیح داده شدند، اجزای دیگری نیز برای پیاده‌سازی On-Premises مورد نیاز هستند. جدول زیر اجزای اضافی On-Premises Workspace ONE UEM را نمایش می دهد.

جزء	شرح
دیتابیس	دیتابیس Microsoft SQL Server که داده‌های دستگاه و محیط Workspace ONE UEM را ذخیره می‌کند. تمام داده‌های پیکربندی برنامه کاربردی مرتبط، مثل پروفایل‌ها و پالیسی‌های تطبیق‌پذیری در این دیتابیس باقی می‌مانند. در نتیجه، اکثر بار کاری Backend برنامه کاربردی همینجا پردازش می‌شود.
سرور Memcached	یک برنامه کاربردی Data Caching توزیعی که بار کاری را روی دیتابیس Workspace ONE UEM کاهش می‌دهد. این سرور برای پیاده‌سازی‌های بیشتر از 5000 دستگاه تعبیه شده است.

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

تصمیم	یک پیاده‌سازی On-Premises از Workspace ONE UEM و اجزای مورد نیاز آن، طراحی، مقیاس‌بندی و پیاده‌سازی شد تا پنجاه هزار دستگاه را پشتیبانی کند و امکان رشد اضافی، بدون نیاز به طراحی مجدد را در طول زمان فراهم نمود.
توجیه	این کار تأییدیه‌ی طراحی و پیاده‌سازی یک On-Premises Instance از Workspace ONE UEM را فراهم می‌کند.

دیتابیس

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

Windows Server Failover Clustering یا WSFC نیز می‌تواند برای بهبود دسترس‌پذیری و افزونگی دیتابیس Local مورد استفاده قرار گیرد. در یک کلاستر WSFC، دو Windows Server با هم در یک کلاستر قرار می‌گیرند تا یک Instance از SQL Server را اجرا کنند که Instance کلاستر SQL Server Failover یا FCI نام دارد. Failover شدن خدمات SQL Server بین این دو Windows Server خودکار است.

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

معماری Workspace ONE UEM روی یک دیتابیس SQL خارجی اجرا می‌شود، پیش از اجرای نصب‌کننده‌ی دیتابیس Workspace ONE UEM، ادمین دیتابیس باید یک طرح و دیتابیس خارجی خالی را آماده کند. کاربران دارای License می‌توانند از یک سرور دیتابیس Microsoft SQL Server 2012، SQL Server 2014 یا SQL Server 2016 استفاده نمایند تا یک محیط دیتابیس با دسترس‌پذیری بالا را تنظیم کنند. در جدول  پایین  استراتژی پیاده‌سازی برای دیتابیس Workspace ONE UEM به‌صورت On-Premises نمایش داده شده است.

تصمیم	یک دیتابیس Microsoft SQL خارجی برای این طراحی پیاده‌سازی شده بود.
توجیه	یک دیتابیس SQL خارجی برای تولید پیشنهاد می‌شود که امکان مقیاس‌پذیری و افزونگی را فراهم می‌کند.

Memcached

Memcached یک برنامه کاربردی Data-Caching توزیعی است که برای استفاده در محیط‌های Workspace ONE UEM قابل‌دسترسی می‌باشد. این برنامه‌ی کاربردی بار کاری روی دیتابیس را کاهش می‌دهد.  Memcached جایگزین راهکار Caching قبلی، یعنی AW Cache می‌شود و برای پیاده‌سازی‌های بیشتر از 5000 دستگاه پیشنهاد می‌گردد.

وقتی که Memcached در کنسول Workspace ONE UEM فعال‌سازی شود، شروع می‌کند به ذخیره‌ی تنظیمات سیستم و اطلاعات درخت گروه سازمان که در دسترس اجزای Workspace ONE UEM قرار دارند. وقتی که درخواستی برای داده ارسال شود، Workspace ONE UEM به‌طور خودکار نتایج ذخیره شده در حافظه توسط Memcached را چک می‌کند و سپس به سراغ چک کردن دیتابیس می‌رود؛ همین امر باعث کاهش بار کاری می‌گردد. اگر این فرایند دچار خرابی شود، داده‌های نتایج از دیتابیس بازیابی می‌گردند و برای Queryهای آینده در Memcached ذخیره می‌شوند. با اضافه شدن مقادیر جدید و تغییر مقادیر موجود، این مقادیر هم به Memcached و هم دیتابیس نوشته می‌شوند.

باید به این نکته توجه داشت که تمام جفت‌های Key و مقدار در Memcached پس از 24 ساعت منقضی می‌شوند. می‌توان چندین سرور Memcached را با هر Caching بخشی از داده پیاده‌سازی کرد تا یک خرابی سرور واحد سرویس را دچار تنزل نکند. با وجود دو سرور، 50 درصد از داده‌ها روی سرور 1 و 50 درصد دیگر روی سرور 2 قرار می‌گیرند، بدون اینکه همسان‌سازی بین سرورها انجام شود. یک جدول Hash به سرویس‌ها می‌گوید که کدام داده‌ها روی کدام سرور ذخیره شده‌اند.

اگر سرور 1 به هر دلیلی قطعی را تجربه کند، فقط 50 درصد از Cache تحت تأثیر قرار می‌گیرد. وقتی سرویس‌ها به دیتابیس Failover می‌کنند و می‌خواهند آیتم‌های جمع‌آوری‌شده را Cache کنند، جدول‌ها روی سرور دوم بازسازی می‌شوند.

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

تصمیم	دو سرور Memcached در شبکه‌ی داخلی پیاده‌سازی شدند.
توجیه	سرورهای Memcached برای محیط‌هایی با بیش از 5000 دستگاه پیشنهاد می‌شوند. سرور Memcached بار روی دیتابیس SQL را کاهش می‌دهند.