در قسمت اول مقاله در مورد ملاحظات کلیدی طراحی VMware App Volumes صحبت کردیم، اینکه App Volumes در یک محیط Horizon چگونه است.
استفاده از چندین vCenter Server
تنظیمات چندین vCenter Servers راهی برای توسعه به یک Pod بزرگ Horizon برای چندین دیتاسنتر یا چندین سایت است. با مدیریت‌های ماشینی می‌توان از اطلاعات اعتباری مختلف برای هر vCenter Server استفاده نمود اما نام‌های Datastore و Host مربوط به vSphere باید در تمامی محیط‌های vCenter Server خاص باشند. پس از فعال‌سازی پشتیبانی Multi-vCenter-Server در محیط خود، بازگشت به پیکربندی یک vCenter Server واحد پیشنهاد نمی‌شود.
توجه: در یک محیط Multi-vCenter-Server، یک Package به ذخیره‌سازی متصل است که برای هر vCenter Server قابل دسترس باشد. ممکن است یک Package مشخص در App Volumes Manager به یک ماشین مجازی که به ذخیره‌ساز دسترسی ندارد محول شده باشد. جهت جلوگیری از این مشکل، باید از گروه‌های ذخیره‌ساز برای همسان‌سازی Packageها در سراسر vCenter Servers استفاده نمود.
ملاحظات بکارگیری چندین دامین AD
App Volumes از محیط‌هایی پشتیبانی می‌کند که صرف نظر از نیاز به انواع Trust پیکربندی شده میان آنها دارای چندین دامین Active Directory میباشند. یک مدیر می‌تواند چندین دامین Active Directory را از طریق Configuration > Active Directories Tab در App Volumes Manager اضافه نماید و یک حساب با حداقل اجازه Read-Only برای هر دامین لازم می باشد. باید هر دامینی که از طریق کامپیوتر، گروه یا User Object برای App Volumes قابل دسترس است را اضافه نمود. علاوه بر آن آبجکت_هایی که به دامین ملحق نشده‌اند با فعال‌سازی این تنظیمات مجاز خواهند شد. شکل زیر فعال‌سازی آبجگت هایی که به دامین ملحق نشده‌اند را نمایش می دهد.
بیشتر بخوانید: استفاده از VMware ThinApp در کنار VMware App Volumes – قسمت اول
ملاحظات vSphere
پیکربندی‌های Host تاثیر مهمی بر عملکرد دارند و باید در طی هر مرحله از توسعه زیرساختی، تمامی Best Practiceهای ESXi را در نظر گرفت. جهت پشتیبانی از عملکرد بهینه Packageها و Volumeهای قابل Write، باید به عناصر ذخیره‌ساز Host که در زیر شرح داده شده‌اند توجه ویژه نمود:
- Policyهای ذخیره‌ساز Host
- پیکربندی شبکه ذخیره‌ساز
- HBA یا پیکربندی آداپتور شبکه
- پیکربندی چندمسیره
- پیکربندی Queue-Depth
برای دریافت بهترین نتیجه، باید هنگام پیکربندی Hostها و Clusterها از پیشنهادات ذخیره‌ساز همتا پیروی نمود.
Load Balancing
باید حداقل از دو App Volumes Manager در تولید استفاده نمود و هر App Volumes Agent را به یک Load Balancer پیکربندی نمود. پیشنهاد می‌شود که برای عملکرد و دسترسی بالا، یک Load Balancer که در مقابل App Volumes Managerها قرار گرفته اتصالات میان هر سرور را متعادل سازد.
با وجود اینکه یک Load Balancer برای محیط‌های تولیدی پیشنهاد می‌شود، می‌توان بطور جایگزین App Volumes Agent را طوری پیکربندی نمود که با چندین سرور App Volumes Manager ارتباط برقرار کند. نگرانی اصلی درباره App Volumes Managerها رسیدگی به طوفان Loginهاست. در طی فرآیند Login، Packageهای مبتنی بر کاربر و Volumeهای قابل Write باید به Guest OS درون ماشین‌های مجازی ضمیمه شده‌باشند. هرچه تعداد عملیات همزمان ضمیمه بیشتر باشد، زمان بیشتری برای Log In کردن تمامی کاربران لازم است.
برای App Volumes 4 تعداد دقیق کاربرانی که هر App Volumes Manager می‌تواند به آنها رسیدگی کند متفاوت است و به Load و ویژگی‌های هر محیط بستگی دارد. VMware پیشنهاد می‌کند Load را تست نموده و سپس تعداد سرورهای App Volumes Manager را به درستی بدست آورد. برای اندازه‌گیری این طراحی، فرض بر این شد که هر App Volumes Manager قادر است به 2000 کاربر رسیدگی کند.
شکل زیر نشان میدهد که دسکتاپ‌های مجازی و Hostهای RDS یا برنامه‌های کاربردی منتشر شده چگونه می‌توانند به یک Load Balancer که Load را به دو App Volumes Manager توزیع می‌کند Point شوند. شکل بالا App Volumes Managers Load Balancing را نمایش میدهد.
جدول 5زیر راهبردی برای توسعه‌پذیری و دسترسی App Volumes را نمایش میدهد.
| تصمیم | یک Load Balancer جلوی سرورهای App Volumes Manager قرار گرفته است VMware NSX Advanced Load Balancer (Avi Networks سابق) مورد استفاده قرار گرفت. |
| Justification |
در صورت بروز مشکل برای هر یک از Managerها، Load Balancer به درستی Load را توزیع نموده و سرویس‌ها را در دسترس قرار میدهد |
باید توجه داشت پیکربندی مضاعفی برای سرورهای App Volumes Manager مورد نیاز نیست. همچنین می‌توان Load Balancerهای Third-Party را مورد استفاده قرار داد و باید از راهنمایی ارائه شده از سوی Vendor مربوطه پیروی کرد. تنظیمات رایج در جدول زیر شرح داده شده‌اند. جدول زیر تنظیمات Load Balancing برای App Volumes Managerها را نمایش میدهد.
| اجزا | تنظیمات |
| Health Monitor |
Type = HTTPSSend Interval = 30 secondsReceive Timeout = 10 secondsClient Request Data = |
| Pool |
Port = 443Load Balancing Algorithm = Least ConnectionsPersistence = Source IP Use SSL to backend servers |
| پروفایل برنامه کاربردی |
Type = HTTPHTTP Request Header = X-Forward-For |
| سرویس مجازی |
Type = Layer 7Ports = 80, 443Enable SSLValid SSL Certificate |
طراحی دیتابیس
App Volumes 4 جهت ذخیره‌سازی تنظیمات پیکربندی، ارجاعات و Metadataها از یک دیتابیس Microsoft SQL Server استفاده می‌کند. این دیتابیس جنبه کلیدی این طراحی است و باید برای تمامی سرورهای App Volumes Manager قابل دسترس باشد. یک Instance App Volumes توسط دیتابیس SQL تعریف شده است و چندین سرور App Volumes Manager به یک دیتابیس SQL متصل می‌شوند.
برای محیط‌های غیر تولیدی App Volumes، می‌توان از قابلیت دیتابیس Microsoft SQL Server Express استفاده کرد که در برنامه نصب کننده App Volumes Manager لحاظ شده است. نباید از SQL Server Express برای پیاده‌سازی‌های بزرگ‌تر یا امور تولیدی استفاده نمود.
App Volumes هم با Failover Cluster Instances یا FCI مربوط به SQL Server و هم با گروه‌های دسترسی SQL Server Always On به خوبی کار می‌کند. جدول زیر استراتژی اجرا برای دیتابیس SQL
| تصمیم | دیتابیس SQL در یک Microsoft SQL Server با دسترسی بالا قرار گرفت. این سرور دیتابیس بر روی یک Windows Server Failover Cluster نصب شده و یک گروه دسترسی Always On جهت فراهم‌سازی دسترسی بالا استفاده شد. |
| هم ترازی | یک گروه دسترسی Always On به Failover خودکار دست پیدا می‌کند. هردو سرور App Volumes Manager به Listener گروه دسترسی برای سرور SQL متصل هستند. |
ذخیره‌ساز
اجرای موفق App Volumes نیازمند طراحی دقیق پیرامون اندازه Disk Volume، IOPS ذخیره‌ساز و همسان‌سازی آن است.
جایگذاری Template Package و Volume قابل Write
زمانی که Packageها و Volumeهای قابل Write جدید پیاده‌سازی می‌شوند، Templateهای از پیش تعریف شده به عنوان منبع رونوشت استفاده می‌شوند. مدیران باید این Templateها را در یک پلتفرم ذخیره‌ساز اشتراکی متمرکز جای دهند. همانند تمامی Storage Objectهای اشتراکی تولیدی، ذخیره‌ساز Template باید در سطح بالایی از خودترمیمی، دسترسی و بازیابی قرار گیرد.
اندازه‌گیری Package و Volumeهای قابل Write برای موفقیت در یک محیط تولیدی حیاتی است. Volumeهای Package باید به قدری بزرگ باشند که برنامه‌ها بتوانند نصب شوند و نرم‌افزارها بروزرسانی گردند. Packageها باید همیشه حداقل 20 درصد فضای خالی داشته باشند تا مدیران بتوانند بدون اندازه‌گیری دوباره Volumeهای Package برنامه‌ها را بروزرسانی نمایند.
Volumeهای قابل Write باید به قدر کافی اندازه‌گیری شوند تا تمامی اطلاعات کاربران را در خود جای دهند، درصورتی که تعداد کل کاربران Volumeهای قابل Write در زمان پیاده‌سازی اولیه App Volumes نامشخص باشد، پلتفرم‌های ذخیره‌سازی که قابلیت اندازه‌گیری دوباره Volume را دارند بسیار مفید هستند.
از آنجایی که Packageها و Volumeهای قابل Write از VMware vSphere® VMFS که یک Virtual Machine File System کلاستر شده و Thin Provision شده از VMware است استفاده می‌کنند، ذخیره‌ساز بطور ناگهانی مورد استفاده قرار نمی‌گیرد. به هنگام مدیریت محیط‌های ذخیره‌ساز Thin Provisionشده باید از Best Practiceهای VMware پیروی نمود و مانیتور کردن فضای خالی در محیط‌های تولیدی بزرگ بسیار حیاتی است.
قابلیت ایجاد تاخیر در Volumeهای قابل Write
دو قابلیت Policy می‌تواند مدیریت فضای خالی را برای Volumeهای قابل Write پیچیده سازند:
- قابلیت ایجاد Volumeهای قابل Write در Login بعدی کاربر به معنای آن است که فرآیندهای ذخیره‌ساز و تخصیص ظرفیت تحت تاثیر Loginکردن کاربران است.
- قابلیت محدودیت دسترسی Volumeهای قابل Write و همچنین ایجاد اولیه به دسکتاپ‌ها یا گروه‌های دسکتاپ خاص به معنای آن است که Login کردن کاربران تعیین کننده زمان کپی شدن یک Template از Volumeهای قابل Write میباشد.
- در یک محیط بزرگ App Volumes، معمولا نباید اجازه داد که رفتار کاربر تعیین کننده عملیات ذخیره‌ساز و تخصیص ظرفیت باشد. به همین دلیل، VMware پیشنهاد می‌کند که ایجاد Volumeهای قابل Write هنگام دادن امتیازات انجام شود تا اینکه تاخیر صورت گیرد.
