ابر پرسان | بررسی نکات کلیدی و زیرساخت های مورد نیاز VMware Horizon
رایانش ابری, ابر عمومی, ابر خصوصی, ابر ترکیبی, نرم افزار به عنوان سرویس, دسکتاپ به عنوان سرویس, دیتابیس به عنوان سرویس, ارتباط به عنوان سرویس, زیرساخت به عنوان سرویس, Cloud Computing, Public Cloud, Private Cloud, Hybrid Cloud, Software as a Service, Desktop as a Service, Database as a Service, Communication as a Service, Infrastructure as a Service, SaaS, PaaS, IaaS, DBaaS, CaaS
15804
rtl,post-template-default,single,single-post,postid-15804,single-format-standard,ajax_fade,page_not_loaded,,qode-title-hidden,qode-theme-ver-9.3,wpb-js-composer js-comp-ver-4.11.2.1,vc_responsive

بررسی نکات کلیدی و زیرساخت های مورد نیاز VMware Horizon

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

سرورهای ESXi

با هر زیرساخت مجازی باید اطمینان حاصل نمایید که redundancy ایجاد شده استاندارد می باشد. این بدین معنی است که مطمئن شوید که سرورهایی که انتخاب کرده اید دارای پاورهای redundant بوده و هارددیسک ها به صورت RAID بسته شده اند و SSD ها برایESXi ها به صورت mirror در نظر گرفته شده اند. چند کارت شبکه بر روی سرور در نظر گرفته اید تا بحث Failure را کاملا پوشش داده و در صورت خراب شدن یکی از کارت­ها، کارت دیگر به صورت خودکار جایگزین شود.

بر اساس نیازهای موجود و با توجه به بودجه تعداد هاست های خود را مشخص نمایید و تا حد امکان سعی بر این باشد که تمامی این هاست ها شبیه به یکدیگر باشند. در بیشتر محیط های عملیاتی سناریو بر اساس N+1 هاست در نظر گرفته می شود. این بدین معناست که تعدادی از هاست ها برای اجرا شدن دسکتاپ های مجازی می باشند. حال گزینه +۱ یعنی هاست اضافه ای که اجازه خطا را به شما می دهد. بعبارتی دیگر در صورت بروز هرگونه خطا یا قطعی در سیستم شما مطمئن هستید که این قطعی تاثیری بر روی سیستم و کاربران نخواهد گذاشت.

حتما به خاطر دارید که برای طراحی مناسب و کاربردی باید دو محیط متفاوت را در نظر میگرفتید:

  • اولی بلاک مدیریتی زیرساخت را شامل می شوند.
  •  دومی هاست های ماشین های مجازی می باشند.
  • مورد بعدی که بسیار مهم است تنظیمات مربوط به CPU و Memory می­باشد.

بعنوان یک قاعده کلی در محیط VDI هرگز از Memory به صورت غیرمعمول استفاده نکنید و اجازه ندهید از حد مورد نظر فراتر برود. اینکار می تواند تاثیرات منفی بسیار زیادی را به همراه داشته باشد. در نظر بگیرید همین الان به memory نیاز دارید ولی در دسترس نیست! مسلما این شرایط مناسب و توصیه شده نمی باشد.

وقتی به سراغ CPU می رویم اکثریت ادمین ها اعلام می­کنند هیچگونه مشکلی در این زمینه ندارند و همه چیز امن و امان می باشد تا زمانی که به ناگهان overcommit رخ می­دهد. وقتی CPU به مرحله  over commitment می رسد خیلی باید مراقب بود و این اتفاق ناخوشایند را به هیچ عنوان نباید نادیده بگیریم. وضعیت CPU های خود را می توانید از طریق vCenter و یا با دستور ESXTOP و یا برنامه های مشابه مانیتور کنید.  وقتی در حال چک کردن وضعیت CPU ها هستید مطمئن شوید که وضعیت برای هر vCPU در محیط دسکتاپ ها زیر ۵ درصد قرار دارد. در محیطی که مشغول به تست هستید شاید وضعیت CPU بالاتر از ۵ درصد کاملا مطنقی و مورد قبول باشد اما فراموش نکنید که ممکن است در آینده ای نزدیک و پس از خروج از محیط pilot با مشکل مواجه شوید. به طور کلی اگر برای هر vCPU وضعیت بالاتر از ۱۰ درصد برود مسلما تاثیر مستقیمی بر روی کاربران خواهد داشت  پس از همین الان مشکل را برطرف کرده و کار امروز را به فردا نسپارید.

برآورد CPU و Memory

تعداد هاستی که برای زیرساخت Horizon View نیاز دارید ارتباط مستقیمی با تعداد دسکتاپ ها و مقدار CPU و RAM  ی که میخواهید برای دسکتاپ ها اختصاص بدهید دارد. چه مقدار CPU می توانیم برای زیرساخت در نظر بگیریم و چه مقدار رم و سی پی یو می توانیم برای سرورها درنظر بگیریم. وقتی در این موارد صحبت میکنیم به دنبال شرایطی هستیم که چه مقداری رم و سی پی یو در زیرساخت داریم تا بتوانیم با اولویت مقرون به صرفه بودن و بدون هدر رفت منابع بهترین شرایط را ایجاد نماییم.

زمانی که پلتفرم سرورها را انتخاب می نمایید، باید در نظر داشته باشید اگر یک سرور FAIL شود چه تاثیراتی بر روی کسب و کار شما خواهد گذاشت. همین طور گاهی اوقات، ممکن است یک هاست با دو عدد CPU فیزیکی را در نظر بگیرید که از لحاظ طراحی شرایط بهتری نسبت به چهار عدد CPU فیزیکی دارد زیرا Core های هر CPU بیشتر می باشد. مطمئن شوید که در محاسبات خود به overhead های مربوط به ESXi ها جهت فعال سازی و اجرای ماشین های مجازی توجه داشته اید. همچنین بحث تخصیص مموری و گرافیک را هم در نظر بگیرید. تصویر زیر مقادیر معمولی از overheadهای مورد نیاز هر VM می باشد:

شبکه Network

به صورت کلی دو دیدگاه بر روی ESXi هاست وجود دارد: ۱GB یا ۱۰GB . شما همیشه تمایل دارید برای اطمینان حداقل دو عدد multiport داشته باشید تا کارت شبکه شما ترافیک را تفکیک کرده و طراحی انعطاف پذیری در شبکه ایجاد نمایید. نیازمندی شما به سرعت ۱GB یا ۱۰GB بستگی به ترافیک های VM LAN های موجود بر روی زیرساخت دارد. این مورد کاملا به موارد استفاده شما باز می گردد. اگر به طور خیلی زیاد بر روی دسکتاپ های مجازی خود از streaming دارید بنابراین ۱۰GB می تواند بهترین درخواست باشد. به هر صورت مطمئن شوید که نیازهای شبکه را به درستی و عمیقا درک کرده اید. به دست آوردن یک نتیجه اشتباه مسلما تجربه ی مناسبی برای کاربران و خود شما نخواهد بود.

گرافیک

درخواست های گرافیکی کاربران باید با دقت و در طی مراحل POC و تست پروژه در اختیار آنها قرار بگیرد. تمام فاکتورها در این زمینه باید مورد توجه قرار داشته باشد. نیازهای گرافیکی بر اساس graphic acceleration و offloading تاثیر مستقیمی بر روی انتخاب سخت افزارهای سرور خواهد داشت. این کارت ها با توجه به  گرانی قیمت و محدودیت در پاور و کولینگ و همچنین به دلیل کم بودن تعداد اسلات PCI موجود بر روی سرورها باید با دقت مضاعفی انتخاب شود.

Storage

در مورد مبحث ذخیره سازی می توانیم یک کتاب به رشته تحریر درآوریم. طراحی و ایجاد آپشن های مختلف با توجه به محیط VDI صورت می­پذیرد.علاوه بر شبکه، استورج یکی از قسمت های مهم می باشد. اولین، و واضح ترین  دلیل این است که شما نمی خواهید در نهایت با استورجی ناکافی و غیر مطمئن پروژه خود را  گسترش دهید. دلیل دوم رها کردن کاربران ناراضی و ناموفق ماندن پروژه است. این یک نکته کلیدی است. وقتی اسم Storage می آید به دو نکته توجه کنید: کارایی و ظرفیت آن

ظرفیت

اولین مرحله تعیین مقدار فضای ذخیره سازی برای محیط Horizon View می باشد. المان هایی که در زیرساخت مجازی شما با هم در ارتباط و اشتراک هستند را باید در نظر بگیرید. اولین و ساده ترین قدم این است که میزان فضای مورد نیاز برای کامپوننت های هر سرور را به صورت کلی در نظر بگیرید. اغلب کامپوننت های هر سرور روی یک استورج موجود می باشند و زیرساخت مجازی و دسکتاپ ها بر روی یک استورج مستقل دیگر وجود دارند. هر چند این امر اجباری نبوده و بستگی به نوع استفاده استورج و سطح جداسازی آن دارد اما توصیه می شود که حتما این استاندارد را رعایت فرمایید. سطح نیازها از استورج بر اساس نوع تکنولوژی که قصد استفاده از آن را دارید باید مشخص گردد مواردی مانند linked clone، linked clones with persistence disk ویا Full clones. با Linked clones، باید درک درستی از رشدLinked clone  بین عملیات refresh و recompose داشته باشید. شکل زیر مثال مناسبی برای درک مطلب است.

Replica از یک Linked clone ایجاد میشود که بر روی یک استورج لوکال با سرعت بالا قرار می­گیرد، هم replica و هم linked clone می توانند بر روی سرور لوکال یا SAN قرار داشته باشند. فعال سازی این مورد در Horizon view انجام می شود و  شما میتوانید مسیری که replica در آن قرار می گیرد را انتخاب نمایید. توصیه می شود replica برروی fast storage قرار داده شود مثلا بر روی local SSD قرار گیرد. توصیه میکنیم در مرحله pilot و POC حتما اطلاعات مربوط به میزان استفاده از storage را جمع آوری کنید. هنگامی که شما اطلاعات را بدست می آورید، با کمک آنها می توانید تخمین بزنید میزان مصرف storage چقدر بوده است و همین امر در گسترش وضعیت کمک شایانی به شما میکند. اسکرین شات زیر یک نمونه از نیازمندی های storage در دسکتاپ pool را به تصویر میکشد:

در طی مرحله proof of concept، متوجه می شویم که ظرفیت مورد نیاز برای دسکتاپ های linked clones چه مقداری می باشد. این یک مولفه اصلی و کلیدی است که تمام ظرفیت مورد نیاز برای راهکار پیشنهادی را همراه با آینده نگری تخمین زده و پیش بینی کنیم. در داستان استورج ما قسمت دیگری با نام کارایی داریم .

Performance

حالا که از میزان فضای لازم برای محیط Horizon View خود آگاه هستید وقت آن رسیده که وضعیت کارایی Performance را نیز مشخص نمایید. مثل همیشه توصیه میکنیم درک درستی از میزان نیازمندی ها و کارایی در حین POC و مرحله pilot بدست بیاورید و از آن برای انتخاب سایز storage استفاده نمایید. وقتی محیط مجازی را مورد آزمون قرار می­دهید دنبال این هستید که میزان تاخیر خواندن / نوشتن را مشخص نمایید. میزان تاخیری که مورد قبول می باشد بستگی به workload ی دارد که کاربران توسط برنامه های مورد استفاده ایجاد میکنند. هر چند متوسط تاخیر در پایین ترین حالت ۲۵ میلی ثانیه می باشد که این عدد برای کاربران بسیار مناسب است.اما ایده آل کجاست؟

Horizon View راهکارهای مربوطه به خود را دارد که با نام View Storage Accelerator (VSA) یا Content Based Read Cache(CBRC) نامیده می شود. این قابلیت امکانی بوجود می آورد که تا ۲GB از مموری که برای سرور ESXi قرار گرفته است می تواند بعنوان کش برای بیشترین بلاک های خوانده شده اخیر اختصاص داده شود. همان طور که قبلا صحبت شد boot شدن سیستم عامل دسکتاپ ها نیازمند بلاک های مشابه می باشد و این می تواند توسط مموری تامین گردد و همین روال باعث شتاب در این روند می شود.

به خاطر داشته باشید که وقتی که از Instant Clones استفاده می نمایید CBRC مورد نیاز نمی باشد. راهکار دیگری که وجود دارد View Composer Array Integration (VCAI) است. پروسس های ساخته شده توسط Linked Cloned می توانند بر روی استورج آفلود شوند بدون اینکه تاثیری بر روی CPU داشته باشند. VCAI توسط Instant Clones پشتیبانی نمی شود. نرم افزارهای جانبی بسیار زیادی در بازار وجود دارند که می توانند مشکلات شما را در زمینه performance استورج برطرف سازند برنامه هایی مثل ILIO products، Atlantis Computing و …

منبع: وبسایت Technet24.ir

لینک منبع:  https://technet24.ir/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%86%DA%A9%D8%A7%D8%AA-%DA%A9%D9%84%DB%8C%D8%AF%DB%8C-%D9%88-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D9%87%D8%A7%DB%8C-%D9%85%D9%88%D8%B1%D8%AF-%D9%86%DB%8C%D8%A7-8577

بدون دیدگاه

ارسال یک دیدگاه