تفاوت دسکتاپ‌های Persistent و Non-Persistent در Horizon View

VMWare Horizon View روش‌های متفاوتی را برای ایجاد و اختصاص دسکتاپ‌های مجازی به کاربران فراهم می‌کند. درک کامل مزایا و محدودیت‌های هریک از این روش‌ها جهت طراحی صحیح یک زیرساخت استاندارد، بسیار حائز اهمیت است. راه حل نهایی می‌تواند شامل چندین Desktop Pool به همراه ترکیبی از روش‌های مختلف Cloning و User Assignment باشد.

در Horizon View دو نوع Desktop Pool وجود دارد (بدون در نظر گرفتن RDS):

• Automated Pool : در این روش از vCenter Server برای ایجاد خودکار ماشین‌های مجازی از یک Image اصلی، استفاده می‌شود. در اکثر سناریوها نیز از همین روش استفاده می‌شود.
• Manual Pool : در این روش دسکتاپ‌ها از قبل ایجاد شده اند و می‌توانند یک ماشین مجازی و یا حتی یک دسکتاپ فیزیکی باشند. این نوع از Pool به ندرت و تنها در مواقع به خصوصی به کار گرفته می‌شود.

همچنین دو روش نیز برای ارائه دسکتاپ‌ها به کاربران وجود دارد:

• Dedicated: در این روش یک دسکتاپ مشخص به یک کاربر به خصوص، ارائه داده می‌شود. هیچ کاربر دیگری دسترسی استفاده از این دسکتاپ را ندارد حتی اگر کاربر مربوط به این دسکتاپ در حال استفاده از آن نباشد. علاوه بر اینکه می‌توان هر دسکتاپ را (قبل از لاگین کاربران) به طور مشخص به یک کاربر به خصوص ارائه داد، می‌توان تنظیمات را به گونه‌ای انجام داد که پس از لاگین هر کاربر، یک دسکتاپ به صورت تصادفی از Pool به آنها اختصاص یافته و در دفعات بعدی نیز همان دسکتاپ به آنها ارائه شود.
• Floating: این روش به کاربران اجازه می‌دهد که به هریک از دسکتاپ‌های موجود در Pool دسترسی داشته باشند، به طوری که با هربار Log Off و Log On، یک دسکتاپ متفاوت به صورت تصادفی از Pool به کاربر ارائه می‌شود.

دو روش نیز برای Cloning یا همان Provisioning وجود دارد:

• Full Clone: در واقع در این روش برای ایجاد دسکتاپ‌ها از یک Template استفاده می‌شود. به تعداد موردنظر از Template ایجاد شده، VM ساخته می‌شود که حجم هر ماشین مجازی دقیقاً به اندازه VM اصلی خواهد بود. با این تفاسیر اگر فرض کنیم حجم ماشین مجازی اصلی 25 گیگابایت است، و نیاز به 100 دسکتاپ داشته باشیم، حجم نهایی مجموع ماشین‌های مجازی 2.5 ترابایت خواهد بود که حجم قابل توجهی است و ایجاد این تعداد از دسکتاپ‌ها با این حجم ممکن است زمان بسیار زیادی به طول انجامد. بدیهی است پس از اینکه دسکتاپ‌ها ایجاد می‌شوند، نسخه‌های کاملا مستقل از Image اصلی بوده که باید توسط ابزارهای دیگر مانند Altiris، WSUS، SCCM و اسکریپت‌های مختلف مدیریت و آپدیت شوند.
• Linked Clone: در این روش از View Composer برای ایجاد دسکتاپ‌ها استفاده می‌شود که نیاز به فضای بسیار کمتری برای ذخیره سازی دارد و مدیریت و نگهداری دسکتاپ‌ها را ساده‌تر می‌کند. Linked Cloneها برای ایجاد دسکتاپ‌ها از یک Snapshot (از VM اصلی) به عنوان Image استفاده می‌کنند. وقتی یک Linked Clone Desktop Pool ایجاد می‌کنیم، ابتدا یک Replica VM ساخته شده و سپس تعداد دسکتاپ‌های موردنیاز به عنوان Childهای این VM ایجاد می‌شوند. دسکتاپ‌ها (Child VM) از روی دیسک Replica VM عملیات Read را انجام می‌دهند و تغییرات را نیز روی یک دیسک از نوع Differencing می‌نویسند. قبل از روشن کردن دسکتاپ‌ها حجم اشغال شده در حد کیلوبایت بوده و هنگام استفاده از آنها با توجه به نوع سیستم عامل، نرم افزارهای نصب شده و حجم Pagefile، بین 1 تا 5 گیگابایت متغیر خواهد بود. با این حال این روش نسبت به روش Full Clone فضای بسیار کمتری را نیاز دارد و حدود 80 درصد صرفه جویی در Storage را به همراه خواهد داشت. لازم به ذکر است می‌توان در این روش تنظیماتی اعمال کرد که پس از Log Off، دسکتاپ رفرش شده و تمامی تغییرات انجام شده به حالت اول بازگردد.

چطور بهترین روش را برای ایجاد Desktop Pool انتخاب کنیم؟

در حالت ایده آل (به دلیل مزایا و قابلیت‌های زیادی که در اختیار ما قرار می‌دهد) بهترین روش استفاده از Automated Linked Clone Floating Pool است، ولی ممکن است در موارد خاص و برای گروهی از کاربران، استفاده از این روش مناسب نباشد.

در نظر داشته باشید در Horizon می‌توانید Desktop Pool‌های جداگانه با روش‌های متفاوت ایجاد کنید و هرکدام را به دپارتمان‌ها یا گروه‌های کاربری متفاوت اختصاص دهید. در اغلب موارد، تقریباً تمامی کاربران نیاز به نرم افزارهای روزانه مثل Windows، Office، Adobe Reader، Flash Player و… دارند. با این حال ممکن است دپارتمانی در سازمان وجود داشته باشد که وجود نرم افزارهای روزانه و معمولی ذکر شده برای آنها کافی باشد و تنها 2 یا چند کاربر نیاز به نرم افزاری مثل MS Project داشته باشند. در این مورد به جای ایجاد یک Pool مجزا برای این 2 کاربر می‌توان نرم افزار موردنظر را به صورت ThinApp در اختیار این کاربران گذاشت. استفاده از Full Clone در این حالت به هیچ وجه پیشنهاد نمی‌شود چرا که تأثیر قابل توجهی بر Storage و هزینه‌های سازمان خواهد داشت.

اگر با سناریویی مواجه هستید که نمی‌توانید نرم افزارهای موردنیاز کاربران را با استفاده از ThinApp ارائه دهید و گروهی از کاربران می‌بایست خودشان برنامه‌های مختلف خود را نصب و تست کنند، آنگاه باید از Automated Full Clone Pool استفاده کرد و همانطور که قبلا نیز توضیح داده شد، دسکتاپ‌های ایجاد شده در این Pool نیاز به فضای ذخیره سازی بیشتری دارند و مدیریت آنها می‌بایست توسط نرم افزارها و سرویس‌هایی نظیر SCCM یا Altiris انجام شود.

فرض کنید سازمانی با دپارتمان‌ها و نیازمندی‌های زیر داریم:

• دپارتمان پشتیبانی تلفنی (۲۵۰ کاربر)

نیازمندی‌ها: Word، Outlook، CRM مبتنی بر وب

نوع Pool پیشنهادی: Automated Linked Clone Floating Pool

دلیل: استفاده از ۱.۲۵ ترابایت به جای ۶.۲۵ ترابایت فضای ذخیره سازی، تنها نیاز به نرم افزارهای معمولی، وجود تنها یک ایمیج اصلی برای ۲۵۰ کاربر که مدیریت و عملیات بروزرسانی را ساده تر می‌کند.

• دپارتمان مالی (۱۰ کاربر)

نیازمندی‌ها: MS Office، نرم افزار حقوق و دستمزد و مالی

نوع Pool پیشنهادی: Automated Linked Clone Floating Pool

دلیل: نیاز به فضای ذخیره سازی کمتر، با فرض اینکه امکان ThinApp کردن نرم افزار مالی وجود ندارد می‌بایست یک ایمیج اصلی برای کاربران این دپارتمان ایجاد کرد و در مجموع تا الان 2 ایمیج اصلی برای 260 کاربر جهت مدیریت و بروزرسانی داریم.

• مدیریت دپارتمان مالی (۲ کاربر)

نیازمندی‌ها: نرم افزارهای حقوق و دستمزد مالی، MS Office به اضافه‌ی MS Project

نوع Pool پیشنهادی: Automated Linked Clone Floating Pool

دلیل: می‌توان از ایمیج قبلی که مربوط به کاربران دپارتمان مالی بود، استفاده کرد و تنها MS Project را به صورت ThinApp در اختیار این 2 کاربر گذاشت. بنابراین همچنان دو ایمیج اصلی برای 262 کاربر، نیاز به مدیریت و بروزرسانی خواهند داشت. بدیهیست در صورتی که کاربر سومی نیاز به استفاده از MS Project داشته باشد، می‌توان User مربوطه را به گروه اضافه کرد.

• دپارتمان برنامه نویسی (۵ کاربر)

نیازمندی‌ها: MS Office، Visual Studio، دسترسی Local Admin برای نصب و تست نرم افزارها

نوع Pool پیشنهادی: Automated Full Clone Dedicated Assignment

دلیل: این کاربران باید دسکتاپ خود را برای نصب نرم افزار و تست داشته باشند و امکان ThinApp کردن هر اپلیکیشن ایجاد شده وجود ندارد چرا که برنامه نویسان به طور مداوم در حال تغییر و تست نرم افزارها هستند بنابراین نیاز به یک ایمیج جدید به همراه نرم افزارهای قید شده وجود دارد. مدیریت آپدیت‌ها می‌تواند با Altiris یا نرم افزارها و سرویس‌های مشابه انجام شود.

در نهایت 3 ایمیج اصلی برای 267 کاربر در 4 دپارتمان با نیازمندی‌های متفاوت خواهیم داشت. عملیات مدیریت و نگهداری دسکتاپ‌ها تا حد امکان ساده نگه داشته شده و به دلیل استفاده از Linked Clone و قابلیت ThinApp صرفه جویی قابل توجهی در مصرف Storage انجام شده است.