نکاتی در مورد طراحی دسکتاپ Horizon View بخش دوم

لایه اصلی

این لایه شامل یک سیستم عامل بهینه شده است که بر اساس نیازهای تجاری و درخواست های شما پیکربندی و ایجاد می شود.  agentهایی مثل View Agent و AV (آنتی ویروس) بر روی ایمیج اصلی نصب می شوند. این شما هستید که تصمیم می گیرید چه برنامه هایی بر روی Image Base  قرار گیرد. برنامه ها باید نیازهای سازمان را مرتفع نمایند و یا بر اساس pool مورد نظر شما نصب شوند. بسته های نرم افزاری مثل مایکروسافت آفیس و PDF reader و مرورگرها و … .حتما به ماهیت نرم افزارها توجه داشته باشید برنامه هایی وجود دارند که  امکان مجازی سازی بوسیله ی  ThinApp را ندارند. بعضی از این برنامه ها به صورت مستقیم با درایورهای سیستم ارتباط داشته و یا در shell اجرا می شوند. این دسته از اپلیکیشن ها باید بر روی base image نصب گردند. اگر از linked cloneها و یا instanceها استفاده می نمایید باید از صحت و سلامت base image خود مطمئن شوید. وقتی base image سالم باشد با خیالی آسوده می توانید صدها دسکتاپ سالم با سرعتی فوق العاده بسازید. این نکته را فراموش نکنید که اگر احیانا ایمیج اصلی شما مشکل داشته باشید با صدها دسکتاپ خراب مواجه می شوید !!

Application

استراتژی مربوط به برنامه ها را مشخص نمایید. این استراتژی شامل جزئیات تحویل برنامه به کاربر می باشد. بعضی از برنامه ها بعنوان سیستم عامل اصلی base معرفی می شوند در حالیکه ممکن است دربقیه پکیج از ThinAppها و یا App Volumeها استفاده نمایید. ( در مورد این دو قابلیت بعدا صحبت خواهیم کرد), همچنین با قابلیت Workspace ONE می توانید برنامه های مورد نیاز خود را به صورت یک پورتال Web-base ارائه بدهید. روش های رساندن برنامه ها به کاربر بسیار متفاوت است. فراموش نکنید که متدهایی در Citrix XenApp و یا SaaS-based وجود دارد که در سایر پلتفرم ها استفاده می شود.

پروفایل های کاربران و محیط مدیریتی:

سرانجام، نگاهی به ارائه با Persona یا یوزرپروفایل بر روی دسکتاپ داشته باشیم. به این فکر کنید که با داشتن persona می توانید همه چیز یک دسکتاپ شخصی را در اختیار داشته باشید. برای مثال تنظیمات برنامه ها، محتویات تمام مستندات و آیکن های موجود بر روی دسکتاپ ها همه و همه را خواهید داشت. راه های بسیار زیادی برای بدست آوردن این موارد وجود دارد. مثلا redirect کردن پروفایل ها، Group Policy، View Persona Management، VMware UEM و بقیه محصولات جانبی third party application)) مثل LiquidWare Lab’s Profile Umity هر جا که امکان داشت از راهکارهای ساده استفاده نمایید و محصولات جانبی (Third party production) را در جهت راحتی کارها در اختیار بگیرید. با استفاده از شیوه های بیان شده سربارهای سیستم را کاهش می دهید. با توجه به سطوح بهینه سازی در نظر گرفته شده برای کاربران ممکن است نیازهای متفاوتی در جهت استفاده از محصولات ایجاد گردد تا بدین وسیله بهینه سازی View Persona Management و Redirect پروفایل کاربران توسط Group Policy به یک فایل سرور صورت پذیرد. موارد مربوط به پروفایل کاربران بعد از لاگین شدن در VDI توسط Group Policy دریافت شده و بر روی دسکتاپ مجازی کاربر قرار می گیرد. یک فایل از پروفایل فراخوانی شده و بر روی دسکتاپ لوکال جهت استفاده های کش می گردد. هر تغییری بر روی پروفایل به صورت لوکال بر روی VDI دسکتاپ ذخیره می گردد. اما در فواصل معین بر روی فایل سرور آپلود شده و به آنجا باز می گردد.

Disaster Recovery and backup

به همراه هر راهکار پیشنهادی بحث Backup وDisaster Recovery (تهیه نسخه های پشتیبان) یکی از گزینه های بسیار مهم می باشد. با Horizon View، باید از قسمت های مختلفی بکاپ تهیه کنید. در زیر اشاره ای کلی به این موارد خواهیم داشت.

گزینه های بکاپ و ریکاوری : در راهکار View مواردی اصلی وجود دارند که حتما و حتما باید از آنها بکاپ تهیه گردد. این موارد عبارت اند از:

  • View Connection Servers
  • View Security Servers
  • Microsoft Lightweight Directory Service
  • View Composer Database
  • vCenter Database
  • vCenter
  • File servers containing ThinApp and View Persona Data
  • Golden images
  • Full clone and persistent desktop images

همان گونه که مشاهده می کنید موارد بسیار زیادی وجود دارد که باید از آنها بکاپ گرفت تا لایه های حفاظتی شما امن و قابل اطمینان باشد. از طریق Horizon View Adminitrator، زمانبندی تهیه بکاپ را مشخص می نمایید. این قسمت شامل تنظیمات زمانبدی بکاپ  از LDAP و View Composer Database می باشد. این بکاپ در مسیر زیراز سرور View Connection گرفته می شود .

C:Program dataVMWareVDMbackups

مطمئن شوید که فایل های بکاپ به صورت منظم و درست در یک فضای ذخیره سازی خارجی قرار بگیرند. توصیه اکید ما این است که از تمام کاپوننت های سرور توسط یک نرم افزار مورد اطمینان نسخه پشتیبان تهیه گردد. برنامه هایی مانند Veeam Backup & Replication و یا VMware Data Protection مورد تایید می باشند. همان طور که قبلا اشاره شد محافظت و نگهداری از Full Cloneها با استفاده از Horizon Mirage صورت می گیرد.

Disaster Recovery Option:

با توجه به یکپارچه سازی Horizon View با View Composer و vCenter Server، ریپلیکیت replicate از محیط عملیاتی با یک DR سایت توصیه نمی شود. به همین ترتیب، Horizon View برای استفاده از قابلیت VMware SRM پشتیبانی نمی شود. روش های مختلفی جهت راه اندازی DR در راهکار View وجود دارد. ما فقط به توضیح یک مورد بسنده می کنیم. نخست، کامپوننت های مهم محیط View باید شناسایی شوند. اغلب موارد زیر حائز اهمیت می باشند:

  • User’s Persona
  • ThinApp application
  • Golden images
  • Full clone desktops

اگر کامپوننت های بالا در DR وجود دارد پس می توانید اعلام کنید که محیط View شما در صورت بروز Disaster کاملا قابل بازیابی می باشد. سایت DR با یک View اختصاصی از قبل کانفیگ شده و تمام کامپوننت های مورد نیاز مانند vCenter Server، View Connection Server و … در آن وجود دارد. توجه داشته باشید که در هنگام Disaster مواردی را که باید سریعا بازگردانی کنید مشخص نمایید تا کمترین خلل به بیزینس سازمان شما وارد گردد.

مواردی مثل User’s Persona، برنامه های ThinApp و App Volume ها همه و همه بر روی فایل سرور قرار دارند. می توانید از تکنولوژی های قابل توجهی مثل Microsoft Distributed File System Replication (DRFS) یا شبیه به آن استفاده نمایید. این امکان به شما اجازه می دهد که یک کپی از دیتاها در هر دو حالت عملیاتی و DR سایت داشته باشید. حتی می توانید از مواردی مثل Golden Image یک OVF تهیه کرده و به سایت DR بفرستید. با این کار می توانید دسکتاپ Poolها را از طریق Golden Image موجود در سایت DR براحتی Recompose کنید. نظر به ماهیت دسکتاپ های Full Clone که مثل VMهای استاندارد می باشتد براحتی می توانید مستقیما عمل replicate را بین SANها زده و از سایت اصلی به سایت DR منتقل نمایید. سرانجام باید در مورد چگونگی اتصال کاربران در مواقع خطا و یا Fail  شدن سیستم به سایت DR فکر کنید.

ساده ترین حالت اتصال برای یک کاربر از طریق وارد کردن آدرس سرور در مرورگر و یا از طریق برنامه Horizon Client می باشد. شما می توانید با استفاده از Load Balancer آدرس مربوطه را به سمت سایت DR هدایت نمایید. همان طور که مشاهده میکنید ساخت سایت DR در Horizon View راهکار ساده ای نمی باشد. اما وقتی همه چیز از دسترس خارج می شود با این سطح از پیش بینی و آینده نگری می توانید موارد مورد نیاز را بازیابی نمایید.

فراموش نکنید که شما با شرکت قوی با نام VMware طرف حساب هستید. این توانایی وجود دارد که دسکتاپ های شما به صورت یک سرویس با نام Horizon Air Cloud-Hosted Desktop and Apps Service ارائه شود.

مثالی از سناریوهای واقعی:

طرح زیر بر اساس یک کمپانی ساختگی و تخیلی با نام PVO ایجاد شده است. این شرکت نیاز دارد تا راهکارVDI را راه اندازی نماید. در دیاگرام زیر توپولوژی از وضعیت Network کنونی و موقعیت ها مشخص گردیده است.

کمپانی مورد بحت سه دفتر دارد: یک دفتر مرکزی، دو سایت راه دور( خارج از شرکت) که سایت های راه دور برای تیم توسعه نرم افزار درنظر گرفته شده است. کمپانی دو دیتاسنتر همانند شکل بالا دارد. درهر دیتاسنتر این توانایی وجود دارد که اگر اتفاق غیرمنتظره ای رخ داد دیتاسنتر دوم بعنوان پشتیبان وارد جریان شود.

نیازهای  کاربران:

در این مثال، ما یک ارزیابی برای جمع آوری اطلاعات انجام دادیم که بر اساس آن تعداد کل کاربران 5،750 نفر می باشد. یک تصویر کلی از مدل استفاده کاربران و نیازهای آنها و محل استقرار هر کاربر مشخص شده است. جزئیات بیشتر در جدول زیرنشان دیده میشود. در حال حاضر اطلاعاتی بر روی انواع یوزرها و نیازهایشان داریم.

Application Developer:

در سناریویی که مثال زدیم دو سایت راه دور وجود دارد اما از توپولوژی نتورک می توانید متوجه شوید که سایت ها با استفاده از WAN به دیتاسنتر B وصل شده اند. آنها فقط از دسکتاپ هایی استفاده میکنند که نیازمند داشتن برنامه ی آفیس بوده و دسترسی از بیرون هم وجود ندارند. در این سناریو ما یک pool اختصاصی ایجاد کرده ایم که دارای persistent دسکتاپ می باشد. قابلیت دیگری که می توانیم پیکربندی کنیم حالت Floating به همراه  non-persistent desktop و استفاده از App Volume ها است تا با استفاده از این قابلیت ها بتوانیم امکان نصب برنامه ها را در داخل دسکتاپ به کاربران بدهیم. با توجه به ماهیت کاری کاربران هر کدام از دسکتاپ ها نیاز به RAM و CPU مشخصی دارند.

Office Worker:

این کاربران کارهای عمومی را انجام میدهند و داشتن یک دسکتاپ معمولی برای آنها کافی می باشد. (2Cpu &2 GB memory) این دسکتاپ ها به صورت بالقوه کاندیدای عالی برای Floating، Non-Persistence دسکتاپ می باشند. برنامه هایی مثل آفیس به صورت پیش فرض بر روی base image این دسکتاپ ها قرار می گیرد و هر برنامه جانبی از طریق App Volume ارائه می شود.

پیمانکاران:

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

مهندس ها:

دو تیم در واحد مهندسی وجود دارند. تیم 1 که کارهای سنگینی با نرم افزار CAD میکنند و طراحان قابلی هستند و تیم 2 که بیشتر شرایط آموزشی را سپری میکنند و کارهای سبکتری با سیستم انجام میدهند. تیم 1 به یک گرافیک کارت سطح بالا با ریسورس های قوی نیاز دارند تا بتوانند برنامه CAD را بدون مشکل اجرا نمایند. در حالیکه در تیم 2 نیازی به موارد بیان شده نیست. البته آنها با کاربران استاندارد تفاوت دارند و نسبت به این دسته از کاربران نیازهای بیشتری خواهند داشت. راهکار مناسب برای گروه مهندسی ارائه تکنولوژی NVIDIA Accelerated می باشد. همان گونه که در مطالب قبلی اشاره شد این راهکار نیاز به سخت افزارهای اختصاصی دارد.

فروش:

دپارتمان فروش ساختاری مشابه با کارکنان دفتری دارد بنابراین می تواند دسکتاپ poolی با مشخصات Floating، Non-persistent  داشته باشد. تنها نقطه کلیدی و متفاوت تیم فروش با کارکنان دفتری در دسترسی های آنها می باشد. فروشی ها نیاز به دسترسی از بیرون دارند. حال که ما نیازهای کاربران را می دانیم می توانیم ساخت دسکتاپ poolها را شروع نماییم.

طراحی Pool:

طراحی pod بر اساس سناریو چیده شده  شما انجام می شود و هر دسکتاپ مشابه در یک Pool قرار می گیرد. بر اساس اطلاعاتی که جمع آوری کردیم می توانیم طراحی و ساخت Pool را انجام دهیم. حاصل این طراحی چیزی شبیه به دیاگرام زیرمی باشد:

در این طراحی تمام کارمندان اداری و فروش  در یک دسکتاپ pool مشابه قرار دارند. حال اگر هر کدام از این گروه ها نیاز به برنامه های خاص خودشان را داشته باشند اگر طریق راهکار ThinApp برنامه را به آنها می دهیم. استفاده از معماری Pod  و Block یک مزیت محسوب می شود. روش پیاده سازی ما هم در این سناریو استفاده از این مزیت می باشد. یک Pod در دیتاسنتر A و یکی هم در دیتاسنترB ایجاد میکنیم. با اینکار وضعیت پیچیدگی شبکه را کمتر کرده و سناریو را به سمت سهولت در مشکل یابی و فهم موضوع هدایت میکنیم. البته فراموش نکنید که CloudPod به صورت پیش فرض و ماهیتا ساده سازی به همراه دارد. Developerها بین سایت ها جابجا می شوند به همین دلیل یک Pool عمومی برای این کاربران ایجاد می نماییم. باید اضافه کنیم که یک  Pool اختصاصی هم برای این دسته از کاربران داریم. ما می توانیم Floating دسکتاپ ها را پیاده سازی کرده و از App Volume ها استفاده کنیم. این کار برای آن است که developerها بتوانند برنامه های مورد استفاده خود را نصب کنند.

حالا که یک ایده ای کلی در مورد Pool داریم میتوانیم کار را با طراحی Pod و بلاک های مدیریتی شروع نماییم.

برآورد بلاک های دسکتاپ:

در دیتاسنتر A، با Pod1 حدود 5،500 ماشین مجازی داریم. 2،000 دسکتاپ مجازی در هر بلاک پشتیبانی می شود. با احتساب وضعیت موجود نیاز به سه بلاک جهت پیکربندی داریم که در هر بلاک حدود 1،800 دسکتاپ قرار می گیرد.در دیتاسنترB، حدود 250 دسکتاپ مجازی داریم بنابراین یک بلاک کار ما را راه می اندازد. چه تعدادی دسکتاپ بر روی هر سرور قرار بدهیم؟ برای این مثال، برای کاربران آفیس ، 98 دسکتاپ مجازی بر روی هر هاست قرار میدهیم. برای کارهای پردازشی سنگین و امور مهندسی 50 دسکتاپ مجازی برای هر هاست درنظر میگیریم. فراموش نکنید که کاربران بخش مهندسی به سخت افزار GPU اختصاصی نیاز دارند.با این وضعیت برای هر کدام از بخش ها یک کلاستر در نظر میگیریم. تعداد هاست های مورد نیاز برای pod1 چیزی شبیه به دیاگرام زیر می باشد. توجه داشته باشید که کاربران با هر مقدار از استفاده در این مثال بر روی سروری با دو عدد CPU با  3GHZ فرکانس کاری به همراه 10 Core قرار میگیرند. پروفایل کاربران Light برابر است با 300Mhz  و برای پاور یوزرها 1.1GHZ می باشد.

Pod2 در دیتاسنتر B شامل ماشین های مجازی برای اپلیکیشن های مورد نیاز تیم توسعه می باشد و وضعیتی شبیه به دیاگرام زیر دارد:

با استفاده از Pod1 این قابلیت را داریم که تعداد زیادی هاست را وارد کلاستر نماییم البته محدودیت تعداد هاست بر روی یک کلاستر 32 عدد می باشد. بنابراین بهتر است دو کلاستر برای هر بلاک دسکتاپ با تعدادی سرور که بین این دو کلاستر پخش شده اند ایجاد کنیم. یکی از کلاسترها جدا شده و وظیفه ساپورت کاربران گرافیکی را برعهده دارد.

طراحی که ما درنظر گرفتیم چیزی شبیه به دیاگرام زیر می باشد:

برآورد نیازهای Storage:

همان طور که قبلا توضیح داده شد این امکان وجود دارد که IOPS مورد نیاز خود را محاسبه نمایید. در این سناریو ما به صورت کلی 30 عدد IOPS برای هر ماشین مجازی مشاهده میکنیم . 70/30  نسبت read/write در یک RAID5 با ظرفیت دیسک 10GB می باشد. با توجه به متغییرها می توانیم کار را همانند زیر شروع نماییم:

اگر از ThinApp و یا App Volume در بستر مجازی خود استفاده میکنید حتما در مورد ظرفیت و کارایی مورد نیاز محاسبات دقیقی را بعمل آورید.

اندازه بلاک های مدیریتی :

پیکربندی و زیرساخت کامپوینت ها مانند زیر می باشد:

نیازهای شبکه:

تمام موارد یک به یک طراحی و مشخص شد و حالا نوبت به یکی از اصلی ترین المان های ممکن در این زیرساخت رسیده است. عکس زیر وضعیت شبکه را در این طراحی به تصویر میکشد:

 با اتمام این بخش ، تئوری های مطالب به پایان رسید و امیدوارم یک دیدگاه کلی نسبت به زیر ساخت Horizon View برای شما ایجاد شده باشد. در مطالب آتی مباحث عملیاتی و نصب را شروع میکنیم و عملا وارد محیط آزمایشگاهی می شویم. امید است مثل همیشه همراه ما باشید.

تجربه ارائه دسکتاپ بوسیله PCoIP
بررسی پروتکل Blast Extreme
بررسی سخت افزارهای گرافیکی در Horizon View – بخش اول
بررسی سخت افزارهای گرافیکی در Horizon View – بخش دوم
پشتیبانی از ارتباطات یکپارچه (Unified Communication) در Horizon View
معیارهای موفقیت در پروژه VMware Horizon
طراحی محیط عملیاتی VMware Horizon : فاز سوم
بررسی نکات کلیدی و زیرساخت های مورد نیاز VMware Horizon
محاسبه IOPS (Input/Output operations Per Second) در طراحی Horizon View
بررسی Load Balancing در Horizon View

6 دیدگاه
  1. mac777 says

    بسیار عالی …

    1. اشکان پزشکی says

      نظر لطف شماست

  2. taghipour39 says

    با تشکر از شما

  3. DevilJin34 says

    سلام
    ممنون از مطالب مفیدتون
    یه سوال دارم:
    اگه من نرم افزار های گرافیکی رو از طریق ThinApp به کلاینت هام بدم دیگه نیازی به کارت گرافیک روی VM های کلاینت ها ندارم؟
    هدفم اینه که نرم افزار های گرافیکی رو یه جا مجتمع کنم و از کارت های Quadro و یا GTX استفاده کنم تا مجبور به خرید کارت های گرون قیمت GRID نباشم

    1. اشکان پزشکی says

      دوست عزیز همانطور که در مطالب قبلی توضیح داده شد توصیه VMware خرید کارت گرافیکی و نصب بر روی سرور می باشد. بالاترین کارایی و پایداری در آن حالت را خواهید داشت.

      1. DevilJin34 says

        ممنون از پاسخ
        ولی سوال من اینه:
        اگه نرم افزاری به وسیله remote app و یا ThinApp به کلاینت داده شده باشه آیا داشتن یا نداشتن گرافیک سمت کلاینت تاثیری داره؟
        چون تا جایی که من میدونم تمام پردازش سمت سرور انجام میشه

دیدگاه

آدرس ایمیل شما منتشر نخواهد شد.