معرفی
زیرساخت دسکتاپ مجازی (VDI) مدیریت متمرکز دسکتاپ را ساده میکند، اما اجزای مرتبط آن میتوانند تغییر پلتفرمها را دشوار کنند. از کارگزاران اتصال اختصاصی گرفته تا محدودیتهای مجوز، این وابستگیها میتوانند گزینههای فناوری اطلاعات را محدود کرده و پیچیدگی مهاجرت را افزایش دهند. این مقاله علل و خطرات قفل شدن در فروشندگان VDI را بررسی میکند، توضیح میدهد که چگونه میتوان آنها را کاهش داد و مراحل عملی برای حفظ انعطافپذیری در ارائه برنامههای ویندوز را بیان میکند.
VDI قفلسازی فروشنده چیست؟
قفل شدن فروشنده VDI وضعیتی است که در آن یک سازمان به شدت به یک پلتفرم خاص مجازیسازی دسکتاپ وابسته میشود به طوری که تغییر فروشندگان برای شرکت بسیار چالشبرانگیز، پرهزینه یا مختلکننده خواهد بود.
اجزای VDI مانند هایپر وایزرها، کارگزاران اتصال، تصاویر دسکتاپ، پروفایلهای کاربری، سیستمهای احراز هویت و سایر ابزارهای مدیریت معمولاً در محیطهای VDI ترکیب میشوند. با این حال، با وجود اینکه جدا هستند، ممکن است به مستندات و پیکربندی خاص فروشنده نیاز داشته باشند تا به طور موفقیتآمیز با یکدیگر تعامل داشته باشند.
دلیل این است که، هرچند برنامههای نوشته شده به زبان ویندوز معمولاً در هر جایی کار میکنند، دسکتاپهای ساخته شده برای یک محیط VDI خاص به زمان قابل توجهی برای پیکربندی مجدد نیاز دارند. بنابراین، قفل شدن به فروشنده یک مشکل غیرقابل حل نیست، اما موانع قابل توجهی برای سازمانهایی که به دنبال تغییر پلتفرم هستند، ایجاد میکند.
علتهای قفل شدن فروشنده در محیطهای VDI چیست؟
قفل شدن فروشنده VDI به ندرت ناشی از یک محدودیت فنی خاص است. این معمولاً ناشی از وابستگیهای متعدد به زیرساختهای مرتبط، ابزارهای مدیریت، مجوزها و پیکربندیهای برنامه است.
بروکرهای اتصال و ابزارهای مدیریت اختصاصی
کارگزاران اتصال مسئول مدیریت اتصالات کاربران به دسکتاپهای مجازی هستند در حالی که ابزارهای مدیریت برای تأمین، قرار دادن و نگهداری دسکتاپها و برنامهها استفاده میشوند. ابزارهایی مانند Citrix Virtual Apps and Desktops، Omnissa Horizon و Azure Virtual Desktop با استفاده از زیرساختهای مدیریت و تکنیکهای پیکربندی مختلف ساخته شدهاند.
این بدان معناست که هنگام انتقال از یک پلتفرم به پلتفرم دیگر، ممکن است نیاز به بازسازی استخرهای دسکتاپ، برنامهها، اتصالات و ابزارهای خودکار باشد. خود برنامهها میتوانند همانند باقی بمانند، اما پیادهسازی آنها بسته به نرمافزار اولیه متفاوت خواهد بود.
وابستگیهای هایپرویزر و زیرساخت
پلتفرمهای VDI به زیرساختی نیاز دارند که قادر به میزبانی و مدیریت دسکتاپهای مجازی باشد. این ممکن است شامل فناوریهای خاص هایپر وایزر، ابر، ذخیرهسازی یا تأمین باشد.
فرآیند مهاجرت ممکن است شامل چندین وظیفه باشد:
- تبدیل یا بازسازی تصاویر ماشین مجازی
- پیکربندی مجدد شبکه، ذخیرهسازی و تخصیص منابع
- جایگزینی ابزارهای تأمین خاص فروشنده
- وی تأیید سازگاری و عملکرد برنامه
- بازسازی مکانیزمهای دسترسی و بازیابی از فاجعه
با این حال، مفهوم قابلیت حمل همیشه به محیط تحویل دسکتاپ گسترش نمییابد. مهاجرت موفق یک ماشین مجازی تضمین نمیکند که محیط تحویل اطراف بدون تغییر عمل کند.
مجوزها و محدودیتهای قراردادی
پیادهسازیهای VDI معمولاً به چندین مجوز مختلف نیاز دارند - برای سیستمهای عامل، محصولات مجازیسازی، حقوق دسترسی کاربران، ابزارهای مدیریت و برنامههای شخص ثالث.
فروشندگان از نظر بستهبندی یا جداسازی این فناوریها تفاوتهای قابل توجهی دارند که میتواند برنامهریزی بودجه و انتقال به زیرساختهای جدید را پیچیدهتر کند.
این موضوع به ویژه زمانی اهمیت دارد که سازمانها بخواهند از یک پشته VDI به پشتهای دیگر منتقل شوند، به عنوان مثال، از راهحلهای محلی به راهحلهای مبتنی بر ابر، زیرا مدلهای مجوز برای سیستمهای عامل، حقوق کاربران و مصرف زیرساخت میتواند به طور چشمگیری تغییر کند.
وبسایت Microsoft Learn یک بینش در مورد مجوزهای Azure Virtual Desktop و اینکه چگونه به سیستمعاملها و موارد استفاده مختلف اعمال میشود.
بنابراین، تحلیل کل ساختار مجوزها، از جمله پیامدهای هرگونه تعهد قراردادی، هنگام اتخاذ تصمیم ضروری است، نه تنها هزینههای اشتراک.
وابستگیهای برنامه و پروفایل کاربر
برنامههای ویندوز ممکن است وابستگیهای متعددی به سیستمعامل، رجیستری، درایورها، مکان یا خدمات دیگر داشته باشند.
این نوع برنامهها معمولاً در محیطهای VDI مجازیسازی میشوند، با جنبههای خاصی از الزامات که در تصاویر اصلی ساخته شده یا در ابزارهای مدیریت پروفایل پیشرفته گنجانده شدهاند. برخی شرکتها ابزارها و اسکریپتهای خود را برای پاسخگویی به نیازهای خاص برنامه خود در ارتباط با بقیه زیرساخت ایجاد و نگهداری میکنند.
در این شرایط، جدا کردن برنامهها از عناصر پشتیبانی آنها به شدت چالشبرانگیز میشود و بدهی فنی قابل توجهی را به وجود میآورد و قابلیت حمل را به شدت دشوار میکند.
حتی اگر خود برنامه قابل حمل باشد، هنوز عناصر ضروری وجود دارند، مانند نصب، پیکربندی، تنظیمات کاربر و مدیریت دادهها که باید در محیط جدید دوباره برقرار شوند. درک تمایز بین بستهبندی برنامههای ویندوز و انتشار برنامهها میتواند به تیمهای IT کمک کند تا الزامات استقرار نرمافزار را از وابستگیهای تحویل برنامه جدا کنند.
خطرات قفل شدن با فروشنده VDI چیست؟
وابستگی به فروشنده مشکلات خاصی را زمانی که یک سازمان مجبور است استراتژی زیرساخت خود را تغییر دهد، به تغییرات مجوزها سازگار شود یا فناوریهای جدید تحویل برنامه را اتخاذ کند، به وجود میآورد.
ریسکهای اصلی به هزینهها، انعطافپذیری معماری و تداوم عملیاتی مربوط میشود.
افزایش هزینههای زیرساخت و مجوزها
یک محیط VDI به شدت متصل میتواند برای یک سازمان دشوار باشد که اجزای زیرساخت خود را بهینهسازی کند.
زمانی که شرایط مجوز تغییر کند یا هزینه زیرساخت افزایش یابد، ممکن است نیاز به یک پروژه مهاجرت در مقیاس بزرگ باشد اگر آنها قصد تغییر ارائهدهندگان را داشته باشند. این میتواند موقعیت مذاکره آنها و توانایی بهینهسازی هزینهها را آسیبپذیر کند.
علاوه بر این، ارائه تمام برنامهها از طریق یک دسکتاپ مجازی کامل میتواند بار اضافی غیرضروری برای بارهای کاری که فقط به یک یا دو برنامه ویندوز نیاز دارند، ایجاد کند.
انتشار برنامه به هیچ وجه ارزانتر از VDI نیست: اقتصاد این دو رویکرد بسته به چگالی بارهای کاری، سیستمعاملهای مورد نیاز، اثر زیرساخت و الزامات مدیریت و اداره متفاوت خواهد بود.
کاهش انعطافپذیری معماری
سازمانهایی که به دنبال پذیرش زیرساخت ترکیبی، جایگزینی سرورهای قدیمی، تغییر بین ارائهدهندگان میزبانی یا حتی پذیرش فناوریهای جدید تحویل هستند، ممکن است گزینههای خود را به دلیل وابستگیهای خاص فروشنده موجود محدود ببینند.
یک پلتفرم VDI که به یک زیرساخت خاص وابسته است ممکن است نیاز به طراحی مجدد کامل برنامههایی داشته باشد که برای ارائه بر روی سایر زیرساختها و ارائهدهندگان میزبانی در نظر گرفته شدهاند و در نتیجه فرآیند تحول دیجیتال را کند میکند.
افزایش پیچیدگی مهاجرت
انتقال فروشندگان VDI تنها در مورد مهاجرت ماشینهای مجازی نیست.
مدیران همچنین باید احراز هویت، پروفایلهای کاربری، تنظیمات برنامه، چاپ، دسترسی به فایل، سیاستهای امنیتی و رفتار جلسه را حفظ کنند.
مستندات ضعیف این وابستگیها میتواند فرآیند را سختتر کند تا بدون حادثه قابل اندازهگیری، آزمایش و اجرا باشد.
افزایش در معرض تغییرات فروشنده
توقف تولید محصول، مدلهای جدید مجوز، تغییرات پشتیبانی یا الزامات زیرساخت ممکن است نیاز به تغییر در استراتژی استقرار داشته باشند.
هرچه وابستگی به یک پلتفرم استقرار واحد بیشتر باشد، تأثیر عملیاتی بالقوه این تغییرات بر کسبوکار بیشتر خواهد بود.
حفظ گزینههای تحویل جایگزین میتواند این ریسک را کاهش دهد و انعطافپذیری بیشتری ایجاد کند زیرا نیازهای کسبوکار یا فناوری تغییر میکند.
چگونه میتوانید خطرات ناشی از قفل شدن در یک فروشنده VDI را کاهش دهید؟
کاهش وابستگی به فروشندگان VDI نیازمند مجموعهای از ملاحظات فنی، مرتبط با بار کاری و معماری است.
ایده این است که از فروشندگان اجتناب نشود، بلکه اجازه تغییرات پلتفرم بدون مختل کردن سایر جنبههای تحویل برنامه داده شود.
1. بررسی وابستگیهای موجود VDI
اولین قدم شناسایی این است که چه چیزی برای ارائه برنامهها و دسکتاپها حیاتی است و چه اجزایی به فناوری خاص فروشندگان وابسته هستند.
یک فهرست وابستگی باید به سوالات زیر پاسخ دهد:
| جزء | سوالات برای بررسی |
|---|---|
| کارگزار اتصال | آیا میتوان تخصیصهای دسکتاپ و برنامه را در جای دیگری بازسازی کرد؟ |
| هایپر وایزر | آیا ماشینهای مجازی و تصاویر میتوانند به زیرساختهای جایگزین منتقل شوند؟ |
| برنامه ها | آیا برنامهها به تصاویر، سیستمعاملها یا درایورهای خاصی نیاز دارند؟ |
| پروفایلهای کاربری | آیا تنظیمات و دادهها میتوانند به طور مستقل منتقل شوند؟ |
| احراز هویت | آیا سیاستهای هویتی به ادغامهای اختصاصی مرتبط هستند؟ |
| مجوزدهی | چه تعهدات، حقوق دسترسی و هزینههای خروجی اعمال میشود؟ |
| اتوماسیون | کدام اسکریپتها به APIها یا ابزارهای خاص فروشنده وابستهاند؟ |
موجودی همچنین باید شامل مالکان برنامه، اهمیت کسب و کار، الزامات بازیابی و سفارشیسازیهای undocumented باشد.
این طبقهبندی میتواند به مدیران IT کمک کند تا درک کنند کدام وابستگیها به راحتی قابل جایگزینی هستند و کدامها نیاز به طراحی مجدد قابل توجهی دارند.
2. جداسازی تحویل برنامه از زیرساخت دسکتاپ
یکی از بهترین روشها برای کاهش نیاز به VDI این است که اطمینان حاصل شود هر برنامه واقعاً به چنین راهحل پیچیدهای نیاز دارد.
در حالی که VDI دسکتاپهای مجازی را ارائه میدهد، انتشار برنامهها فراهم میکند دسترسی از راه دور به برنامههای فردی بدون لزوم ارائه یک دسکتاپ کامل.
هر دو روش برنامهها را متمرکز میکنند، اما به شیوههای مختلف.
| نیازمندی | VDI کامل | انتشار برنامه مبتنی بر جلسه |
|---|---|---|
| کامپیوتر شخصی کامل | به خوبی مناسب | نه هدف اصلی |
| برنامههای ویندوز فردی | پشتیبانی شده | به خوبی مناسب |
| جداسازی سیستم عامل دسکتاپ اختصاصی | در دسترس | بهطور کلی از میزبانهای جلسه مشترک استفاده میکند |
| پیکربندیهای تخصصی دسکتاپ | اغلب مناسب | بستگی به سازگاری دارد |
| مدیریت متمرکز برنامه | پشتیبانی شده | پشتیبانی شده |
| دسترسی مبتنی بر مرورگر | وابسته به پلتفرم | با راهحلهای سازگار در دسترس است |
| تحویل بدون یک استک کامل VDI | بهطور کلی نیست | ممکن است |
تفاوت معماری است، نه عملکردی.
بسیاری از این سیستمهای VDI قبلاً اجازه انتشار برنامهها را میدهند، بنابراین اجازه دادن به انتشار برنامهها لزوماً به شما کمک نمیکند تا از قفل شدن به فروشنده جلوگیری کنید، مگر اینکه آن برنامهها بتوانند از سطح کنترل VDI جدا شوند.
به عنوان مثال، فرض کنید که شما یک بخش حسابداری دارید که به یک برنامه مالی ویندوز نیاز دارد اما نیازی به دسکتاپهای مجازی خود ندارد. با انتشار برنامه در یک سیستم ویندوز (به درستی تنظیم شده)، میتوانید از مجبور کردن همه به استفاده از VDI جلوگیری کنید و در عین حال مدیریت برنامه را متمرکز نگه دارید.
از سوی دیگر، افرادی که به دسکتاپهای دائمی نیاز دارند، جایی که هر کاربر دارای جلسه دسکتاپ خود است، ممکن است به VDI کامل نیاز داشته باشند.
3. معماریهای مدولار و قابل همکاری را اتخاذ کنید
معماریهای مدولار امکان جایگزینی عناصر فردی را بدون ایجاد اختلال در محیط کلی تحویل برنامه فراهم میکنند.
تیمهای IT باید در صورت امکان به موارد زیر اولویت دهند:
- شناسایی و احراز هویت استاندارد شده
- کد برنامه قابل حمل و وابستگیهای مستند شده
- اطلاعات کاربر جدا شده از تصاویر دسکتاپ
- زیرساخت به عنوان کد: استقرار تکرارپذیر، اتوماسیون
- تحویل که در نقاط پایانی و محیطهای میزبانی کار میکند
توجه داشته باشید که جداسازی دادههای کاربر از تصاویر دسکتاپ، هم مهاجرتها و هم بازیابی از فاجعه را سادهتر خواهد کرد: به همین ترتیب، زیرساخت به عنوان کد به عملیات کمک خواهد کرد تا محیطها را با ثبات بهتر بازسازی کنند.
با این حال، حتی استانداردهای باز و اتوماسیون نیز ممکن است از قفل شدن فروشنده جلوگیری نکنند: اغلب تفاوتهای ظریفی در پیادهسازی بین فناوریهای مختلف فروشندگان وجود دارد و اسکریپتها ممکن است شامل فراخوانی به APIهای اختصاصی باشند.
بنابراین، هدف جلوگیری از اتصال غیرضروری بین اجزای برنامه و زیرساخت، مدیریت و اجزای عملیاتی است.
4. تحویل برنامه هیبریدی را در نظر بگیرید
سازمانها نیازی به انتخاب بین حفظ تمام زیرساخت VDI خود یا جایگزینی آن با چیزی کاملاً متفاوت ندارند.
آنها میتوانند یک استراتژی ترکیبی را اتخاذ کنند که بارهای کاری مختلف را بر اساس نیازهای خود به کار میگیرد.
یک سازمان میتواند از دسکتاپهای اختصاصی برای کاربران حرفهای استفاده کند در حالی که برنامههای تجاری سازگار را بر روی میزبانهای جلسه ویندوز مشترک میزبانی کند.
آنها همچنین میتوانند برنامههای قدیمی را از طریق مرورگرها ارائه دهند. برای نرمافزارهای ویندوز که به راحتی قابل بازنویسی نیستند، درک چگونه نرمافزار ویندوز را به وب منتشر کنیم میتواند به تیمهای IT کمک کند تا تحویل مبتنی بر مرورگر را به عنوان بخشی از استراتژی هیبریدی خود ارزیابی کنند.
بهترین است که برنامههای محلی زمانی حفظ شوند که متمرکز کردن تأثیر چندانی بر بهبود عملکرد کلی نداشته باشد.
این استراتژی به بخش IT این امکان را میدهد که سرمایهگذاریهای موجود در زیرساخت خود را حفظ کند در حالی که به آرامی به فناوریهای جدید منتقل میشود.
چالش این رویکرد این است که پیچیدگی اضافی ایجاد میکند و نیاز به مدیریت هویت جامعتر، تدابیر امنیتی یکسان در تمام پلتفرمها، قوانین نظارتی و رویههای پشتیبانی دارد.
5. مقایسه هزینه کل مدلهای تحویل
صرف صرفهجویی در مجوزها هزینهاثربخشی یک معماری تحویل برنامه جایگزین را تعیین نمیکند.
تیمهای IT باید هزینه کلی مالکیت را شامل زیرساخت، هزینههای نرمافزاری، مدیریت، امنیت و مهاجرت ارزیابی کنند.
| دسته هزینه | معیارهای ارزیابی |
|---|---|
| نرمافزار | مجوزها، اشتراکها، پشتیبانی و تمدیدها |
| زیرساخت | محاسبات، ذخیرهسازی، شبکهسازی و مصرف ابری |
| سیستمهای عامل | مجوزهای ویندوز و حقوق دسترسی قابل اجرا |
| مدیریت | تهیه، نگهداری، نظارت و عیبیابی |
| امنیت | MFA، کنترلهای دسترسی، حسابرسی و مدیریت امنیت |
| مهاجرت | آزمایش، پیکربندی، آموزش و استقرار |
| تداوم کسب و کار | دسترسپذیری، پشتیبانگیری، بازیابی و در معرض خرابی |
انتشار برنامه میتواند نیاز به اجزای خاص در یک محیط VDI را کاهش دهد، اما الزامات خاص خود را برای استقرار و مجوز دارد.
به عنوان مثال، پیکربندیهای میزبانی جلسه خدمات دسکتاپ از راه دور مایکروسافت (RDS) سنتی به مجوزهای دسترسی کلاینت RDS مناسب نیاز دارند که در مستندات CAL RDS مایکروسافت .
نیازمندیهای مجوز باید بر اساس معماری واقعی، محصول تحویل و شرایط و ضوابط مربوط به مایکروسافت تأیید شوند.
هدف باید کاهش هزینههای کل باشد در حالی که هنوز امنیت، عملکرد و قابلیت اطمینان لازم برای برآورده کردن نیازهای کسب و کار را ارائه میدهد.
برای مهاجرت از قفل تأمینکننده VDI چه اقداماتی لازم است؟
کاهش وابستگی به فروشنده به صورت تدریجی بسیار ایمنتر از انجام یک جایگزینی کامل از پلتفرم است.
مهاجرت مرحلهای به تیمهای IT این فرصت را میدهد که روشهای جایگزین تحویل را آزمایش کنند در حالی که وضعیت موجود را حفظ میکنند.
مرحله ۱: طبقهبندی برنامهها بر اساس الزامات تحویل
ابتدا برنامهها را بر اساس وابستگیهای فنی و نیازهای کاربران نهایی گروهبندی کنید. سه دسته کلی بهویژه برای شناسایی مفید هستند:
- برنامههایی که به دسکتاپهای کامل نیاز دارند - بارهای کاری که به یک محیط سیستمعامل اختصاصی، پیکربندی خاص یا ایزولاسیون در سطح دسکتاپ نیاز دارند
- برنامههای مناسب برای انتشار از راه دور–برنامههای ویندوز، سازگار با محیطهای میزبان جلسه مشترک/اختصاصی پشتیبانی شده
- برنامههای مناسب برای دسترسی محلی یا بومی مرورگر - نرمافزاری که دیگر نیازی به اجرا در یک محیط VDI ندارد
این طبقهبندی میتواند به مدیر کمک کند تا نامزدهای مدلهای تحویل جایگزین را شناسایی کند که نیاز به سازگاریهای قابل توجهی ندارند.
مرحله ۲: انتخاب یک بار کاری آزمایشی با ریسک پایین
یک برنامه را انتخاب کنید که نیازهای منابع به وضوح تعریف شده، وابستگیهای کمی داشته باشد و دارای یک پایگاه کاربری محدود باشد.
از شروع با برنامههای حیاتی کسبوکار که به ادغامهای پیچیده جانبی، درایورهای منحصر به فرد یا اجزای قدیمی آسیبپذیر وابسته هستند، خودداری کنید.
پایلوت باید توانایی زیرساخت جایگزین را برای بازتولید مناسب عملکردهای اساسی و تجربه کاربری محیط اصلی اثبات کند.
مرحله ۳: اعتبارسنجی سازگاری، عملکرد و امنیت
قبل از مقیاسگذاری، عملکردها و ویژگیهای عملیاتی را در محیطهای واقعی آزمایش کنید.
پروژه مهاجرت تحویل برنامه باید شامل مناطق زیر در سناریوی آزمایش باشد:
- نصب برنامه، وابستگیها و مجوزها
- احراز هویت، MFA و مجوزهای کاربری
- پروفایلهای کاربری، تنظیمات و دسترسی به فایل
- چاپ، کلیپ بورد و هدایت دستگاههای جانبی
- همزمانی جلسه و مصرف منابع
- تاخیر، پاسخگویی و اتصال مجدد
- ثبت، نظارت و سیاستهای امنیتی
- پروسههای پشتیبانگیری، بازیابی و بازگشت
اجرای موفق برنامهها تضمینی برای سازگاری کامل نیست.
برای مثال، یک برنامه ممکن است به خوبی به تنهایی کار کند اما زمانی که چندین کاربر سعی میکنند آن را به طور همزمان اجرا کنند یا اسناد را بر روی چاپگرها چاپ کنند، شکست بخورد.
تیمهای IT باید تستها و معیارهای عملکرد لازم برای جلسات، برنامهها، امنیت و ویژگیهای بازگشت به حالت قبلی را طراحی کنند.
مرحله ۴: مهاجرت برنامهها در مراحل کنترلشده
پس از اینکه پایلوت معیارهای پذیرش خود را برآورده کرد، استقرار را بر اساس اولویتهای کسبوکار و پیچیدگی فنی گسترش دهید.
انتقال محیط تحویل اصلی را در طول انتقال حفظ کنید، در صورت امکان، به مدیران این امکان را میدهد که عملکرد را مقایسه کنند، به طور مؤثر عیبیابی کنند و در صورت نیاز به فرآیندهای تثبیتشده بازگردند.
معیارهای موفقیت سند، تعیین مسئولیتها و ایجاد رویههای بازگشت برای هر مرحله از مهاجرت. این اقدامات همچنین به مقاومت برنامه کمک به سازمانها برای حفظ عملکردهای اساسی کسبوکار در طول تغییرات زیرساختی.
مرحله ۵: بررسی وابستگیهای باقیمانده
مسئله قفل شدن فروشنده محدود به یک مورد خاص نیست.
برنامههای جدید، نیاز به ارتقاء پلتفرم، تغییرات در مجوزها یا سفارشیسازی عملیاتی میتواند پس از اتمام مهاجرت وابستگیهای اضافی ایجاد کند.
بنابراین، بررسیهای دورهای برای اطمینان از اینکه برنامهها میتوانند به کار خود در پلتفرم هدف ادامه دهند، اینکه پیکربندیها به درستی ثبت شدهاند و اینکه سایر روشهای تحویل در دسترس باقی ماندهاند، ضروری است.
این به محیط جدید اجازه میدهد تا از تبدیل شدن به یک قفل فروشنده دیگر جلوگیری کند.
در کدام موارد VDI راه حل مناسبی برای نگهداری است؟
کاهش وابستگی به فروشندگان VDI نیاز به جایگزینی کلی VDI ندارد.
VDI ارزش مشروعی برای سناریوهایی دارد که نیاز به سیستمهای عامل اختصاصی، دسکتاپهای دائمی، برنامههای گرافیکی فشرده یا جداسازی بار کاری که میزبانهای جلسه مشترک نمیتوانند ارائه دهند، دارند.
این همچنین برای ارائه دسکتاپهای استاندارد شده و مدیریت شده به صورت مرکزی با سیاستهای مدیریت دسکتاپ سازگار ارزشمند است.
تصمیم به پذیرش یک معماری متفاوت باید بر اساس رفتار برنامه، نیازهای امنیتی، الزامات کاربر و عوامل اقتصادی باشد.
برای اکثر سازمانها، یک معماری توزیعشده عملیتر از مجبور کردن همه برنامهها به یک مدل تحویل یکسان است.
نگهداشتن VDI برای بارهای کاری که به آن نیاز دارند در حالی که از انتشار مستقل برنامه برای بارهای کاری دیگر استفاده میشود، به کاهش قفل شدن VDI بدون رها کردن قابلیتهای VDI کمک میکند.
چگونه میتواند تحویل برنامه به طور بلندمدت انعطافپذیر باقی بماند؟
انعطافپذیری بلندمدت یک سیستم از طریق توانایی حفظ کنترل بر رابطه زیرساخت برنامه و دسترسی کاربر به دست میآید.
برنامهها باید به گونهای طراحی شوند که امکان ادامه عملکرد آنها بر روی ارائهدهندگان زیرساخت، هایپر وایزرها یا پلتفرمهای مجازیسازی دسکتاپ که ممکن است تغییر کنند، فراهم باشد.
این رویکرد نیاز به توجه دقیق به مستندسازی صحیح وابستگیها، جداسازی دادههای برنامه از مکانیزمهای تحویل آن، حفظ پیکربندی قابل تکرار و بررسی مداوم رویکردها و پیکربندیهای جایگزین دارد.
به عنوان مثال، در حالی که یک برنامه نوشته شده برای ویندوز ممکن است به سرورهای ویندوز مدیریت شده مرکزی در یک سازمان جدید که از نرمافزار یا هایپر وایزرهای میزبانی متفاوتی استفاده میکند، منتقل شود یا نرمافزار واسط VDI خود را جایگزین کرده باشد، این به این معنی نیست که برنامه به طور جهانی قابل حمل است.
برنامهها باید برای توانایی خود در عملکرد بر روی زیرساختهای مختلف، از جمله تغییرات در سیستمعامل پایه، مجوزهای مناسب، سازگاری خاص برنامه یا ویژگیهای عملکردی آزمایش شوند.
یک معیار مفید برای انعطافپذیری، قابلیت حمل برنامه بین محیطهای بهطور قابل توجهی متفاوت است.
اگر مهاجرت یک برنامه به زیرساختی متفاوت، اما پشتیبانی شده، نیاز به بازسازی گسترده عناصر غیر مرتبط به دلیل وجود وابستگیهای زیاد داشته باشد، این نشان میدهد که کار زیادی باید انجام شود قبل از اینکه برنامه قابل حمل در نظر گرفته شود.
این معیار میتواند بهطور تکراری اعمال شود تا به تدریج انعطافپذیری نیازهای زیرساخت یک برنامه را افزایش دهد یا تنظیمات عملیاتی را بدون نیاز به بازسازی کامل خود برنامه انجام دهد.
به دنبال راهی سادهتر برای ارائه برنامههای ویندوز هستید؟
TSplus دسترسی از راه دور یک گزینه جایگزین برای سازمانهایی که میخواهند برنامههای ویندوز را منتشر کنند و دسکتاپهای از راه دور را بدون استقرار یک پشته کامل VDI سنتی ارائه دهند. با انتشار برنامه، دسترسی از طریق مرورگر HTML5 و پشتیبانی از محیطهای ویندوزی که بهصورت محلی یا در ابر میزبانی میشوند، به تیمهای IT کمک میکند تا گزینههای تحویل را متنوع کنند در حالی که کنترل متمرکز را حفظ میکنند.
نتیجه
قفل شدن فروشنده VDI زمانی پرهزینه میشود که برنامهها به زیرساخت، مجوزها و سیستمهای مدیریت بهطور محکم وابسته باشند. نقشهبرداری از این وابستگیها و معرفی روشهای تحویل جایگزین میتواند به سازمانها کمک کند تا کنترل را حفظ کنند بدون اینکه بهطور کامل VDI را رها کنند.
یک معماری انعطافپذیر به تیمهای IT اجازه میدهد تا بارهای کاری مناسب را بر روی دسکتاپهای مجازی نگه دارند در حالی که دسترسی به دیگران را ساده میکند، ریسک مهاجرت را کاهش میدهد و گزینههای آینده را حفظ میکند.
TSplus دسترسی از راه دور آزمایشی رایگان
جایگزین نهایی Citrix/RDS برای دسترسی به دسکتاپ/برنامه. ایمن، مقرون به صرفه، محلی/ابری