این مقاله یکی از مجموعه سری‌هایی است که چارچوب و راهنمای معماری، طراحی و پیاده‌سازی Workspace ONE و راهکارهای Horizon یعنی VMware Workspace ONE و VMware Workspace ONE and VMware Horizon Reference Architecture را پوشش میدهد.
مدل برنامه کاربردی لحظه‌‌ای VMware App Volumes برنامه‌های کاربردی تحت مدیریت IT و Suitهای آنها را در Containerهایی که مدیریت تعریف نموده جدا می‌کند.
شکل بالا App Volumes Just-in-Time Application Model را نشان میدهد، این نسخه از معماری مرجع App Volumes با استفاده از VMware App Volumes 4 ساخته شد که خود معماری مشابه با نسخه‌های App Volumes 2.x دارد اما در اجزا، مدیریت چرخه عمر و واژه‌شناسی متفاوت است. App Volumes 4 Feature Review یک Demo تعاملی است که در آشنایی سریع‌تر با مفاهی جدید کمک می‌کند.
می توان گفت VMware App Volumes دو کار را پیش می‌برد اولین کار ارسال آن دسته از Programهای نرم‌افزاری است که در Golden Image ماشین مجازی برای VDI و RDSH نیستند. App Volumes یک یا چند Program را براساس الزامات استفاده هرکدام در چند Package گروه‌بندی می‌کند. هر Package شامل یک دیسک مجازی است که شامل یک یا چند Program است که باهم Capture شده‌اند.
Packageها به برنامه‌های کاربردی اضافه می‌شوند و این برنامه‌ها جهت ارجاع دادن Packageها به موجودیت‌های AD مانند کاربر، گروه، واحد سازمانی یا OU و ماشین استفاده می‌شوند. می‌توانند این Packageها را هربار که کاربران به حساب دسکتاپ یا استارت‌آپ ماشین خود وارد می‌شوند وارد و نصب نمود. برای مواردی که از VDI استفاده می‌شود، Packageها در Login نصب می‌شوند اما برای RDSH به واسطه اینکه Packageها به حساب ماشین ارجاع داده می‌شوند، هنگام شروع سرویس App Volumes نصب می‌گردند.
VMware App Volumes همچنین Volumeهایی را ارائه میدهد که توسط کاربران قابل Writeکردن بوده و در موارد خاصی استفاده می‌شوند. Volumeهای قابل Write یک مکانیزم برای Captureکردن داده‌های پروفایل کاربر، برنامه‌های کاربردی نصب شده از سوی کاربر که با Packageها فراهم نمی‌شوند یا هر دو را فراهم می‌کنند. این امر احتمال نیاز به دسکتاپ‌های دائمی برای موارد استفاده را کاهش میدهد. داده‌های پروفایل کاربر و برنامه‌های کاربردی که کاربر نصب کرده با اتصال به دسکتاپ‌های مجازی مختلف کاربر را دنبال می‌کنند.
App Volumes Agent در سیستم عملیاتی Guest ماشین‌های مجازی غیر دائم نصب می‌گردد، این Agent با InstanceهایApp Volumes Manager ارتباط برقرار می‌کند تا امتیازات Volumeهای قابل Write و Package 0 را تعیین نماید. Packageها و دیسک‌های مجازی Volumeهای قابل Write به سیستم عملیاتی Guest ماشین مجازی ضمیمه می‌شوند و برنامه‌های کاربردی و تنظیمات شخصی را برای End-Userها فراهم می‌کنند.
شکل بالا اجزای منطقی VMware App Volumes را نمایش می دهد. اجزا و ویژگی‌های App Volumes در جدول زیر توضیح داده شده‌اند.
| اجزا | توضیحات |
|
App Volumes Manager |
|
|
App Volumes Agent |
|
|
برنامه کاربردی |
|
|
Package |
|
|
برنامه |
|
|
Marker |
|
|
Volume قابل Write |
|
|
دیتابیس |
|
|
Active Directory |
|
|
VMware vCenter Server® |
|
|
ماشین‌های مجازی Package کننده |
|
|
گروه ذخیره‌ساز |
گروهی از Datastoreها برای همسان‌سازی Packageها و توزیع Volumeهای قابل Write |
شکل زیر معماری پیشرفته و منطقی اجزای App Volumes را نشان داده و با استفاده از Load Balancerهای Third-Party، آن را با چندین سرور App Volumes Manager بطور زیرساختی توسعه داده.
ملاحظات کلیدی طراحی VMware App Volumes چیست
باید حداقل از دو سرور App Volumes Manager استفاده نمود که ترجیحا باید پشت Load Balancer پیکربندی شوند. این امر نیازمند یک SQL Server استراکی است.
- یک App Volumes Instace با دیتابیس SQL محدود می‌شود.
- هر برنامه کاربردی که در حالت Kernel است باید درون Base Image باشد نه Package
- باید از گروه‌های ذخیره‌ساز جهت متراکم‌سازی بار و IOPS استفاده نمود (درصورت عدم استفاده از VMware vSAN™
بیشتر بخوانید: بررسی مایکروسافت SQL Server در زیرساخت VMware vSAN
توجه داشته باشید Packageها نسبت به خواندن بسیار حساس هستند
- گروه‌های ذخیره‌ساز ممکن است هنوز برای کاربران vSAN جهت همسان‌سازی Packageها قابل استفاده باشند.
- باید Packageها را در ذخیره‌سازیی قرار داد که برای خواندن طراحی شده است (100درصد خواندن).
- باید Volumeهای قابل Write در ذخیره‌ساز‌های مخصوص IOPS تصادفی قرار گیرند (50/50 خواندن/نوشتن).
- حداقل تعداد Package باید به هر کاربر یا تجهیزات اختصاص یابد.
- App Volumes 4 بطور پیش‌فرض دارای پیکربندی Machine Managers بوده و تنها در صورت نیاز می‌توان در آن تغییراتی ایجاد نمود.
شکل بالا پیکربندی پیش‌فرض Machine Managers را نمایش میدهد. توجه داشته باشید در نسخه‌های قبلی App Volumes، پیکربندی گزینه Mount ESXi یا Mount On Host جهت کاهش بار vCenter Server و بهبود عملکرد App Volumes پیشنهاد می‌شد. VMware App Volumes 4 و نسخه‌های پس از آن پیشرفت‌های جدیدی در ارتباط با vCenter Server حاصل نمودند و بیشتر کارها دیگر نیازمند فعال‌سازی گزینه Mount ESXi نیستند.
می‌توان گزینه ذخیره‌ساز Mount Local را در App Volumes فعال نمود تا ابتدا ذخیره‌ساز Local و بعد ذخیره‌ساز مرکزی را چک کرد. Packageها اگر بطور Local در ESXi (vSphere) Host ذخیره شوند سریع‌تر نصب می‌شوند. باید VMDKها را در ذخیره‌ساز Local قرار داده و در صورت خرابی vSphere Host برای امنیت بیشتر باید نسخه‌های رونویسی شده آنها را در ذخیره‌ساز مرکزی قرار داد. پس از آن ماشین‌های مجازی می‌توانند در Hostهای دیگر که به VMDKهای درون ذخیره‌ساز مرکزی دسترسی دارند Reboot شوند. اگر بخواهیم Mount ESXi یا Mount Local را فعال کنیم، تمامی Hostهای vSphere باید اطلاعات کاربری یکسانی داشته باشند و دسترسی Root-Level نیاز نیست.
App Volumes در یک محیط Horizon
- یک اصل کلیدی در طراحی محیط VMware Horizon® استفاده از Podها و Blockها است که راهبردی قابل تکرار و توسعه را به ارمغان می‌آورد.
- باید هنگام معماری App Volumes طراحی و توسعه Horizon Block را درنظر داشت.
جدول زیر استراتژی پیاده‌سازی App Volumes در Horizon Pods را نمایش می دهد.
| تصمیم | یک Instance App Volumes در هر Pod مربوط به هر Site پیاده‌سازی شده است. مدیریت ماشین App Volumes برای ارتباط با vCenter Server در هر Block منابع پیکربندی شده است. |
| هم ترازی | استانداردسازی در رویکرد Block و Pod معماری را ساده‌تر نموده و مدیریت را آسان می‌کند. |
در یک محیط تولیدی Horizon، رعایت Best Practiceهای زیر بسیار مهم است:
- Best Practiceهای اندازه‌گیری و توسعه
- Best Practiceهای توسعه‌پذیری vSphere
- Best Practiceهای معماری vSphere
دسترسی و مقیاس‌پذیری
همانند تمامی Workloadهای Server، پیشنهاد می‌شود که سازمان‌ها سرورهای App Volumes Manager را به عنوان ماشین‌های مجازی vSphere، Host کنند. قابلیت‌های دسترسی vSphere مانند Cluster HA ،VMware vSphere® Replication™ و VMware Site Recovery Manager™ می‌توانند پیاده‌سازی App Volumes را کامل کرده و باید برای پیاده‌سازی محصولات درنظر گرفته شوند.
در محیط‌های تولیدی، نباید تنها یک سرور App Volumes Manager پیاده‌سازی گردد. پیاده‌سازی یک Load-Balancer سازمانی برای مدیریت چندین سرور App Volumes Manager متصل به یک Instance دیتابیس SQL Server متمرکز با قابلیت خود ترمیمی بسیار بهتر است. همانند تمامی Workloadهای تولیدی که در vSphere اجرا می‌شوند، پیکربندی Host، کلاستر، شبکه و ذخیره‌ساز اصلی باید از لحاظ دسترسی طبق Best Practiceهای VMware باشند.
بیشتر بخوانید: معرفی و بررسی کلاستر Big Data در SQL Server
App Volumes Managers
App Volumes Managers نقاط اصلی مدیریت و پیکربندی هستند و نقش واسطه میان Volumeها و Agentها را دارند. برای محیط تولیدی، باید حداقل دو سرور App Volumes Manager را پیاده‌سازی نمود. App Volumes Manager مستقل از وضعیت است – تمامی داده‌های لازم برای App Volumes در دیتابیس SQL قرار دارد. پیاده‌سازی دو سرور App Volumes Manager، دسترسی سرویس‌های App Volumes را مطمئن ساخته و بار کاربر را توزیع می‌کند. با وجود اینکه ممکن است دو App Volumes Manager از طراحی همزمان 8000 کاربر پشتیبانی کند، مدیریت‌های مضاعف جهت تطبیق بازه‌های سنگین استفاده همزمان مانند Logon Stormها لازم‌اند.
| تصمیم | چهار سرور App Volumes Manager با یک Load Balancer پیاده‌سازی شده‌اند. |
| هم ترازی | این راهبرد الزامات بارها را رفع نموده و از افزونگی جلوگیری می‌کند. |
