زیرساخت مجازی Azure برای VDI محلی

معرفی

Azure Virtual Desktop Hybrid به سازمان‌ها یک مسیر دیگر بین VDI سنتی محلی و دسکتاپ‌های کاملاً میزبانی شده در Azure می‌دهد. این مقاله توضیح می‌دهد که معماری چگونه کار می‌کند، چگونه Azure Arc میزبان‌های محلی جلسه را به AVD متصل می‌کند، چه تغییراتی برای زیرساخت VDI موجود ایجاد می‌شود و چه محدودیت‌هایی باقی می‌ماند. همچنین بررسی می‌کند که چه زمانی Hybrid AVD منطقی است و تیم‌های IT قبل از پذیرش آن باید چه مواردی را ارزیابی کنند.

Azure Virtual Desktop Hybrid چیست؟

مدل استقرار Azure Virtual Desktop Hybrid جایی است که سرویس Azure Virtual Desktop هنوز توسط مایکروسافت در Azure میزبانی و مدیریت می‌شود، اما میزبان‌های جلسه ویندوز که دسکتاپ‌ها و برنامه‌ها را ارائه می‌دهند، در محل قرار دارند.

مایکروسافت از Azure Arc برای برقراری ارتباط بین محیط‌ها استفاده می‌کند. تمام رایانه‌های محلی پشتیبانی شده، سرورهای فعال شده با Azure Arc خواهند بود. سپس، افزونه Azure Virtual Desktop Arc اجزای مورد نیاز AVD را نصب کرده و این رایانه را به عنوان یک میزبان جلسه در یک استخر میزبان AVD ثبت می‌کند.

همه چیز برای کاربر نهایی بیشتر یا کمتر همانند زمانی است که از AVD مستقر در Azure استفاده می‌کند. کاربران از طریق برنامه ویندوز به دسکتاپ‌ها یا برنامه‌های اختصاص داده شده دسترسی پیدا می‌کنند. با این حال، تفاوت این است که بار کاری ویندوز از زیرساخت مشتری ارائه خواهد شد و نه از محاسبات Azure.

بنابراین جدایی زیرساخت وجود دارد که:

جزء	جایی که اجرا می‌شود	چه کسی آن را مدیریت می‌کند
خدمات AVD و واسطه‌گری	آزور	مایکروسافت
استخرهای میزبان، گروه‌های برنامه و تخصیص‌ها	آزور	مشتری آنها را پیکربندی می‌کند
میزبان‌های جلسه ویندوز	در محل	مشتری
هایپر وایزر یا زیرساخت فیزیکی	در محل	مشتری
سیستم‌عامل و برنامه‌های میزبان جلسه	در محل	مشتری
شبکه‌سازی محلی و ذخیره‌سازی	در محل	مشتری
ادغام Azure Arc	آزور + در محل	وابستگی مشترک

نکته اصلی این است که "هیبرید" توصیفی از توزیع عناصر متمایز در معماری VDI است. Azure Virtual Desktop به تنهایی هرگز به یک راه حل کاملاً محلی تبدیل نشد.

چگونه Azure Virtual Desktop Hybrid کار می‌کند؟

معماری با ماشین‌هایی آغاز می‌شود که دسکتاپ‌ها یا برنامه‌ها را ارائه می‌دهند. سازمان‌ها ماشین‌های مجازی ویندوز پشتیبانی‌شده یا دستگاه‌های فیزیکی بدون سر پشتیبانی‌شده را بر روی زیرساخت خود فراهم می‌کنند.

عامل ماشین متصل به Azure هر میزبان جلسه را با Azure Arc ثبت می‌کند. سپس یک افزونه Arc برای دسکتاپ مجازی Azure می‌تواند اجزای مورد نیاز AVD را نصب کرده و ماشین را با یک استخر میزبان AVD ثبت کند.

Azure Arc هیچ گونه ماشین مجازی زیرساختی را ارائه یا مدیریت نمی‌کند. میزبان جلسه بخشی از زیرساخت محلی سازمان است، به این معنی که تیم IT سازمان مسئول چرخه عمر میزبان جلسه، ظرفیت و پلتفرم مجازی‌سازی زیرساختی است.

زمانی که یک کاربر متصل می‌شود، Azure Virtual Desktop قابلیت‌های سمت سرویس را برای کشف منابع، احراز هویت دسترسی و میانجی‌گری جلسه فراهم می‌کند. بار کاری واقعی ویندوز بر روی میزبان جلسه محلی اجرا می‌شود.

این معماری سرویس AVD را از میزبان‌های جلسه جدا می‌کند و AVD هیبریدی را از هر دو متمایز می‌سازد. VDI سنتی محلی و AVD میزبانی شده در Azure استاندارد: مایکروسافت خدمات ابری را مدیریت می‌کند، اما مشتری همچنان زیرساخت محاسباتی را اداره می‌کند.

چگونه AVD هیبریدی یک محیط VDI موجود در محل را تغییر می‌دهد؟

برای محیط‌های VDI موجود، چالش تنها این نیست که آیا سرورهای فعلی می‌توانند در مرکز داده حفظ شوند، بلکه این است که کدام لایه‌های معماری موجود حفظ شده‌اند، کدام AVD جایگزین شده و کدام مسئولیت‌های عملیاتی توسط سازمان حفظ شده‌اند.

کامپیوتر موجود می‌تواند در محل باقی بماند

برخلاف مهاجرت کامل Azure AVD، جایی که محاسبات میزبان جلسه به Azure منتقل می‌شود، این مورد نیاز به تغییرات در میزبان‌های جلسه موجود در مرکز داده ندارد.

سازمان‌ها می‌توانند از ماشین‌های مجازی ویندوز پشتیبانی‌شده بر روی هایپر وایزر مورد نظر خود در دیتاسنترهای محلی خود بهره‌برداری کنند. این می‌تواند در مواردی که زیرساخت مجازی‌سازی موجود قابل توجهی وجود دارد یا برنامه‌ها به شدت به سیستم‌های محلی موجود وابسته هستند، مفید باشد.

وجود سخت‌افزار موجود به این معنی نیست که محیط VDI تغییر نکرده است، با این حال، میزبان‌های جلسه باید با مشخصات مایکروسافت و قبل از اینکه بتوانند با Azure Virtual Hybrid Desktop استفاده شوند، باید به عنوان Azure Arc-enabled ثبت نام شوند.

کنترل پنل VDI به Azure منتقل می‌شود

مهم‌ترین تفاوت‌های معماری در بالای میزبان‌های جلسه ظاهر می‌شوند.

به جای راه‌اندازی کامل زیرساخت تحویل دسکتاپ درون‌سازمانی، سازمان از پلتفرم Azure Virtual Desktop استفاده می‌کند. مایکروسافت اجزای اصلی سرویس را برای کشف منابع، واسطه‌گری و اتصال دروازه‌ای ارائه می‌دهد.

سازمان‌ها مسئولیت پیکربندی استخرهای میزبان، گروه‌های برنامه، فضای کار و حقوق کاربران را حفظ می‌کنند، اما این منابع اکنون بخشی از معماری AVD هستند. واسطه‌ها، دروازه‌ها و اجزای مدیریتی قبلی ممکن است دیگر نیازی به انجام همان عملکردها نداشته باشند.

مدیریت زیرساخت محلی باقی می‌ماند

انتقال لایه خدمات به Azure زیرساخت پشتیبانی را تحت مدیریت مایکروسافت قرار نمی‌دهد.

تیم‌های IT مسئول تأمین، وصله‌گذاری و نگهداری سخت‌افزار محلی، سیستم‌های عامل، برنامه‌ها، شبکه، ذخیره‌سازی و پلتفرم مجازی‌سازی زیرین هستند. مایکروسافت به‌طور صریح مستند می‌کند که Azure Virtual Desktop Hybrid به‌طور خودکار ماشین‌های مجازی میزبان جلسه محلی را تأمین نمی‌کند و وضعیت قدرت آن‌ها را مدیریت نمی‌کند.

هیبرید AVD باید به عنوان یک توزیع مجدد از مسئولیت‌های VDI درک شود نه به عنوان انتقال کل پشته راه‌حل به مایکروسافت.

در کدام موارد منطقی است که میزبان‌های جلسه AVD در محل نگه داشته شوند؟

اگر Azure قبلاً خدمات AVD را ارائه می‌دهد، رفتن به مسیر قرار دادن آن میزبان جلسه در Azure ممکن است ساده‌ترین راه به نظر برسد. هیبرید زمانی مطرح می‌شود که توجیه فنی، هزینه یا عملیاتی برای نگه‌داشتن بارهای کاری در مرکز داده وجود داشته باشد.

برنامه‌های قدیمی و وابستگی‌های محلی

برنامه‌هایی که مجازی‌سازی می‌شوند معمولاً برنامه‌های ویندوزی هستند که به شدت به پایگاه‌های داده محلی، اشتراک‌گذاری فایل، خدمات احراز هویت، دستگاه‌های جانبی یا سایر سیستم‌های پشتیبان وابسته‌اند.

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

این به ویژه در مورد برنامه‌های کاربردی کسب‌وکار قدیمی که برای کار در یک محیط شبکه محلی طراحی شده بودند.

موقعیت داده و الزامات زیرساخت

برخی از شرکت‌ها نیاز دارند که بارهای کاری یا داده‌های خاصی در زیرساختی که تحت کنترل آن‌هاست، به دلایل قانونی، قراردادی یا عملیاتی قرار داشته باشند.

AVD هیبریدی اجازه می‌دهد پردازش دسکتاپ و برنامه‌ها محلی باقی بماند در حالی که از Azure برای خدمات تحویل دسکتاپ استفاده می‌کند. با این حال، تیم‌های IT باید این گزینه معماری را با دقت در برابر الزامات انطباق خود تحلیل کنند زیرا مدل هیبریدی هنوز به Microsoft Azure وابسته است.

سرمایه‌گذاری در مرکز داده موجود

سازمان‌هایی که ظرفیت اضافی در سرورها، ذخیره‌سازی و منابع مجازی‌سازی دارند، ممکن است انگیزه فوری کمی برای تغییر این وضعیت داشته باشند.

AVD هیبریدی می‌تواند به چنین شرکت‌هایی اجازه دهد تا ظرفیت جدیدی را در امواجی به دست آورند که منابع محاسباتی موجود به پردازش بارهای کاری ادامه می‌دهند در حالی که سطح کنترل در اطراف آن تغییر می‌کند. این معماری همچنین به مدرنیزاسیون تدریجی کمک می‌کند زیرا بارهای کاری مختلف می‌توانند با سرعت‌های متفاوت منتقل شوند.

بارهای حساس به تأخیر در Backend

برای برخی از برنامه‌ها، نزدیکی میزبان جلسه به منابعی که مصرف می‌کند، مهم‌تر از نزدیکی میزبان جلسه به کاربر نهایی است.

برنامه‌هایی که تماس‌های مکرر با پایگاه‌های داده محلی، سیستم‌های ذخیره‌سازی یا زیرساخت‌های دیگر دارند، ممکن است عملکرد خوبی نداشته باشند اگر این وابستگی‌ها در یک WAN توزیع شوند. با نگه‌داشتن جلسه ویندوز به صورت محلی، نزدیکی به این منابع می‌تواند حفظ شود.

زمانی که AVD هیبریدی ممکن است مناسب نباشد

ارزش نگه‌داشتن میزبان‌های جلسه در محل کاهش می‌یابد اگر هدف سازمان حذف زیرساخت مرکز داده باشد نه نگهداری آن. در چنین سناریویی، استفاده از AVD میزبانی شده در Azure ممکن است بهتر با مدل عملیاتی مورد نظر سازگار باشد.

تیم‌های IT همچنین باید در نظر بگیرند که آیا واقعاً به مدل خدمات Azure Virtual Desktop نیاز دارند یا خیر. اگر نیاز اصلی این باشد انتشار امن برنامه‌های ویندوز یا دسکتاپ‌های متمرکز در حالی که کنترل مستقیم زیرساخت را حفظ می‌کند، یک پلن کنترل VDI وابسته به Azure می‌تواند پیچیدگی‌های معماری غیرضروری را معرفی کند.

آیا AVD هیبریدی VPNها و دروازه‌های RD را حذف می‌کند؟

Azure Virtual Desktop بسیاری از پیچیدگی‌های اتصال خارجی را با اجازه دادن به سازمان‌ها برای جلوگیری از افشای میزبان‌های جلسه فردی به اینترنت یا استقرار یک دروازه استاندارد Remote Desktop (RD Gateway) برای AVD از بین می‌برد.

AVD از زیرساخت خدمات مایکروسافت برای اتصال از طریق خدمات مایکروسافت استفاده می‌کند. حمل و نقل پیش‌فرض از اتصال معکوس مبتنی بر TCP استفاده می‌کند، در حالی که RDP Shortpath می‌تواند یک حمل و نقل مبتنی بر UDP را در صورتی که شبکه و پیکربندی آن را پشتیبانی کند، مذاکره کند.

برای سازمان‌هایی که در حال حاضر یک محیط VDI دارند که از یک اتصال پروتکل دسکتاپ از راه دور (RDP) ورودی استفاده می‌کند و همچنین روش‌های دیگری مانند دسترسی VPN یا دروازه‌های RD مدیریت شده محلی برای دسترسی از راه دور این می‌تواند به طور قابل توجهی معماری دسترسی خارجی را تغییر دهد.

نیازمندی‌های اتصال شبکه حذف نشده‌اند. میزبان‌های جلسه محلی هنوز باید به خدمات مناسب Azure متصل شوند، در حالی که برنامه‌ها به دسترسی قابل اعتماد به وابستگی‌های محلی نیاز دارند. بنابراین، ملاحظات اتصال مانند DNS، هویت، پیکربندی فایروال، مسیریابی و تاب‌آوری هنوز عناصر طراحی مهمی هستند.

محدودیت‌های Azure Virtual Desktop Hybrid چیست؟

Hybrid AVD انعطاف‌پذیری در استقرار ارائه می‌دهد، اما تفاوت‌های مهمی با AVD میزبانی شده در Azure وجود دارد که می‌تواند بر معماری و عملیات تأثیر بگذارد.

مایکروسافت در حال حاضر چندین را تعریف می‌کند قابلیت‌های مدیریت میزبان جلسه به عنوان پشتیبانی نشده برای Hybrid AVD:

• مدیریت توان
• مقیاس‌پذیری خودکار دسکتاپ مجازی Azure
• هنگام اتصال VM را شروع کنید
• پیکربندی میزبان جلسه

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

علاوه بر این، پشتیبانی از سیستم عامل متفاوت است زیرا هیچ پشتیبانی برای Azure Virtual Desktop Hybrid با Windows 10 Enterprise multi-session و Windows 11 Enterprise multi-session وجود ندارد. این یک تفاوت قابل توجه است زیرا سیستم‌های عامل کلاینت ویندوز چند جلسه‌ای یک ویژگی کلیدی از AVD میزبانی شده در Azure هستند.

نیازمندی‌های مجوز باید با دقت بررسی شوند و سیستم عامل و مورد استفاده مورد نظر در نظر گرفته شوند. باید تأیید شود که آیا نیازمندی‌های مجوز Hybrid Azure Virtual Desktop مایکروسافت فراتر از مجوزهای موجود VDI، خدمات دسکتاپ از راه دور یا مجوزهای Microsoft 365 اعمال می‌شود یا خیر.

در نهایت، داشتن میزبان‌های محلی جلسه به معنای مستقل بودن استقرار AVD از ابر نیست، زیرا سرویس مدیریت شده مایکروسافت Azure Virtual Desktop همچنان بخشی جدایی‌ناپذیر از معماری است.

AVD میزبانی شده در Azure در مقابل AVD هیبریدی در مقابل VDI سنتی در محل

نسخه نهایی جمله (بازنویسی شده، با استفاده از کلمات متفاوت، با تغییر در ساختار یا طول برخی جملات):

	VDI سنتی محلی	دسکتاپ مجازی Azure هیبریدی	AVD میزبانی شده در Azure
میزبان‌های جلسه	در محل	در محل	آزور
خدمات VDI/صفحه کنترل	معمولاً زیرساخت مشتری/فروشنده	مایکروسافت AVD در آژور	مایکروسافت AVD در آژور
هایپر وایزر محلی مورد نیاز است	به طور معمول بله	بله برای میزبان‌های مبتنی بر VM	نه
مدیریت محاسبات محلی	مشتری	مشتری	قابل اعمال نیست به محاسبات محلی
ویژگی‌های چرخه عمر VM AVD بومی	نه	محدود	پشتیبانی گسترده
نزدیکی به برنامه‌های محلی	بالا	بالا	بستگی به طراحی شبکه دارد
وابستگی به Azure	بسته به محصول	بله	بله
مصرف محاسبات Azure	نه	برای میزبان‌های جلسه محلی مناسب نیست	بله

بنابراین، AVD هیبریدی دارای معماری میانه‌ای است که در آن بارهای کاری از ابر (مدیریت شده توسط مایکروسافت) ارائه می‌شوند، اما محاسبات محلی توسط مشتری مدیریت می‌شود.

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

چگونه باید تیم‌های IT یک انتقال به AVD هیبریدی را ارزیابی کنند؟

یک ارزیابی AVD هیبریدی باید نه با Azure بلکه با بارهای کاری و وابستگی‌ها آغاز شود.

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

وضعیت فعلی استک VDI باید به مدل AVD نگاشته شود. کدام کارگزاران، دروازه‌ها و خدمات مدیریتی توسط Azure Virtual Desktop جایگزین خواهند شد؟ چه مسئولیت‌های عملیاتی باقی خواهند ماند؟

مدیریت چرخه حیات میزبان جلسه یک ملاحظه کلیدی است. اگر پلتفرم VDI موجود شامل تأمین خودکار، شروع/متوقف کردن یا مقیاس‌گذاری ماشین‌های مجازی باشد، ارزیابی کنید که آیا این قابلیت‌ها در AVD هیبریدی موجود است یا اینکه فرض کنید که کنترل پنل Azure آنها را جایگزین خواهد کرد.

شناسایی، شبکه‌سازی، مجوزدهی، تاب‌آوری و مسئولیت‌های عملیاتی باید به‌عنوان یک گروه ارزیابی شوند. هدف تنها تعیین این نیست که آیا ماشین‌های موجود می‌توانند با Azure Virtual Desktop ثبت‌نام شوند، بلکه آیا جداسازی زیرساخت VDI بین Azure و مرکز داده محیطی ساده‌تر و پایدارتر تولید خواهد کرد.

به دنبال راهی ساده‌تر برای ارائه برنامه‌های ویندوز و دسکتاپ‌ها هستید؟

AVD هیبریدی زمانی منطقی است که یک سازمان به طور خاص می‌خواهد از Azure Virtual Desktop استفاده کند در حالی که میزبان‌های جلسه را در محل نگه می‌دارد. اما هر سازمانی نیاز ندارد که معماری تحویل دسکتاپ خود را بین یک سرویس مدیریت شده توسط Azure و محاسبات مدیریت شده محلی تقسیم کند.

جایی که نیاز اصلی به انتشار برنامه‌های ویندوز یا دسکتاپ‌های کامل به‌طور ایمن از زیرساخت موجود ویندوز است، TSplus دسترسی از راه دور یک گزینه مستقیم‌تر را ارائه می‌دهد. سازمان‌ها می‌توانند برنامه‌ها و دسکتاپ‌ها را از طریق دسترسی مبتنی بر HTML5 یا سازگار با RDP ارائه دهند در حالی که کنترل بر روی محل اجرای زیرساخت پشتیبانی را حفظ می‌کنند.

نتیجه

زیرساخت مجازی Azure Hybrid یک راه حل میانه بین VDI سنتی در محل و AVD میزبانی شده در Azure ارائه می‌دهد. این زیرساخت خدمات کلیدی تحویل دسکتاپ را به Azure منتقل می‌کند در حالی که به میزبان‌های جلسه ویندوز و بارهای کاری آن‌ها اجازه می‌دهد در زیرساخت موجود باقی بمانند.

عامل تعیین‌کننده این است که آیا نگه‌داشتن این بارهای کاری به‌صورت محلی مزیت فنی یا عملی واضحی را فراهم می‌کند یا خیر. تیم‌های IT باید وابستگی‌های برنامه، مدیریت زیرساخت، شبکه‌سازی، مجوزها و وابستگی به Azure را به‌طور همزمان ارزیابی کنند قبل از اینکه تصمیم بگیرند آیا Hybrid AVD واقعاً محیط VDI آن‌ها را ساده‌تر می‌کند یا خیر.