در دنیای مدرن IT، زیرساخت مجازیسازی ستون فقرات سرویسهای دیجیتال سازمانها محسوب میشود. هر ساعت خرابی (Downtime) میتواند به معنای خسارت مالی مستقیم، آسیب به اعتبار برند و نقض SLA با مشتریان باشد. در این میان، دو قابلیت VMware vSphere HA و DRS نقش کلیدی در تضمین پایداری و کارایی زیرساخت مجازی ایفا میکنند.
vSphere High Availability یا HA یک مکانیزم خودکار برای تشخیص خرابی و راهاندازی مجدد ماشینهای مجازی است، در حالی که Distributed Resource Scheduler یا DRS وظیفه توزیع هوشمند بار کاری را بین هاستهای ESXi بر عهده دارد. این دو قابلیت مستقل از هم طراحی شدهاند اما در کنار یکدیگر، یک Cluster مقاوم و بهینه ایجاد میکنند.
این مقاله با تکیه بر مستندات رسمی VMware (اکنون Broadcom)، گزارش فنی عملکرد DRS در vSphere 7.0 و منابع معتبر تخصصی، معماری داخلی هر دو قابلیت، تفاوتهای فنی، روش پیکربندی و سناریوهای واقعی کاربرد را بررسی میکند.
بیشتر بخوانید: HA چیست؟
چرا پایداری و کارایی در زیرساخت مجازی حیاتی است
زیرساختهای مجازیسازی بهواسطه تجمیع منابع، نقطه شکست واحد (Single Point of Failure) را در سطح هاست فیزیکی ایجاد میکنند. یک ESXi Host که دهها VM روی آن در حال اجراست، در صورت خرابی تمام آن VMها را به یکباره تحت تأثیر قرار میدهد. در عین حال، توزیع نامتعادل منابع میتواند باعث شود برخی هاستها overload شده و برخی دیگر ظرفیت خالی داشته باشند که منجر به کاهش کیفیت سرویس میشود.
HA و DRS دو لایه مستقل اما مکمل برای مقابله با این دو چالش هستند: HA برای ادامهکاری پس از خرابی غیرمنتظره، و DRS برای بهینهسازی مستمر توزیع منابع.
vSphere Cluster: بستر مشترک HA و DRS
هر دو قابلیت در بستر vSphere Cluster تعریف میشوند. یک Cluster مجموعهای از ESXi Hostهاست که منابع آنها (CPU، RAM، Storage، Network) به صورت یکپارچه مدیریت میشود. vCenter Server به عنوان صفحه کنترل مرکزی، پیکربندی Cluster، سیاستهای HA/DRS و وضعیت VMها را مدیریت میکند.
- پیشنیاز مشترک: Shared Storage قابل دسترس از تمام هاستهای Cluster
- پیشنیاز مشترک: شبکه Management مشترک بین هاستها
- پیشنیاز DRS: شبکه vMotion فعال و پهنای باند کافی
- پیشنیاز DRS: لایسنس vSphere Enterprise Plus یا معادل
VMware vSphere HA (High Availability)
HA چیست و چه مشکلی را حل میکند
vSphere High Availability یک قابلیت تعبیهشده در vSphere است که در صورت خرابی یک ESXi Host یا VM، به صورت خودکار ماشینهای مجازی را روی هاستهای سالم دیگر راهاندازی مجدد میکند. هدف اصلی HA تداوم سرویس (Business Continuity) پس از رویدادهای غیرمنتظرهای مانند خرابی سختافزار، قطع برق یا کرش سیستمعامل ESXi است.
نکته مهم: HA یک راهکار HA (High Availability) است، نه FT (Fault Tolerance). در HA، VM دچار Downtime کوتاهی میشود تا روی هاست دیگری Restart شود. برای بدون Downtime کامل، باید از vSphere FT استفاده کرد.
HA در vSphere 5.0 با جایگزینی عامل قدیمی AAM (Automated Availability Manager) با عامل FDM (Fault Domain Manager) متحول شد. FDM رویکرد مقاومتری داشته و وابستگی به DNS را از بین برد، مکانیزم Datastore Heartbeat را اضافه کرد و معماری Master/Slave را به جای Primary/Secondary معرفی نمود.
معماری داخلی HA: عامل FDM
قلب HA، عامل FDM (Fault Domain Manager) است که روی هر ESXi Host نصب میشود. مطابق منابع معتبر از جمله Yellow Bricks Deep Dive و مستندات Broadcom، FDM مسئولیتهای زیر را بر عهده دارد:
- تبادل اطلاعات وضعیت هاست، منابع و VMها با سایر هاستهای Cluster
- پیادهسازی مکانیزمهای Heartbeat (Network و Datastore)
- تعیین جایگاه VM پس از Failover (VM Placement)
- مدیریت Restart VMها بر اساس اولویتبندی
- ارتباط با vCenter Server برای گزارش وضعیت Cluster
مکانیزم انتخاب Master (Election)
به محض فعالسازی HA، یک فرآیند Election بین تمام هاستها آغاز میشود. طبق مستندات رسمی، هاستی که بیشترین تعداد Datastore به آن متصل است، Master میشود. در صورت تساوی، هاستی با بزرگترین Managed Object ID (MOID) انتخاب میشود. تنها یک Master در هر Cluster وجود دارد.
نقش Master در HA
- تشخیص خرابی هاستهای Slave از طریق Network Heartbeat
- تعیین VMهایی که باید پس از Failover راهاندازی شوند
- انتخاب هاست مقصد برای Restart هر VM
- ارتباط مستمر با vCenter Server برای گزارش وضعیت Cluster
- اجرای سیاستهای Admission Control
نقش Slave در HA
- ارسال Network Heartbeat به Master هر یک ثانیه یکبار
- نظارت بر وضعیت VMهای در حال اجرا و اطلاعرسانی به Master
- شرکت در فرآیند Election جدید در صورت خرابی Master
- نگهداری اطلاعات پیکربندی Cluster به صورت Local
مکانیزم Heartbeat: دو لایه تشخیص خرابی
Network Heartbeat
هر Slave هر ثانیه یک Heartbeat به Master ارسال میکند و Master نیز همین کار را با Slaveها انجام میدهد. این ارتباط Point-to-Point است و از Multicast استفاده نمیکند. اگر Master به مدت پیشفرض ۱۵ ثانیه Heartbeat دریافت نکند، مراحل بررسی بیشتر آغاز میشود.
Datastore Heartbeat
اگر Network Heartbeat قطع شود، HA بلافاصله تصمیمگیری نمیکند. به جای آن، Datastore Heartbeat بررسی میشود. در هر Datastore مشترک، یک پوشه با نام vSphere-HA ایجاد میشود که هر هاست فایل هارتبیت خود را در آن بهروز میکند. به صورت پیشفرض حداقل دو Datastore برای این منظور انتخاب میشوند (قابل افزایش تا ۵).
اصل طراحی: Datastore Heartbeat جلوگیری از راهاندازی اشتباه VM در سناریوی Network Isolation را تضمین میکند. اگر هاست از شبکه جدا شده اما هنوز Storage دارد، HA مطمئن میشود قبل از تصمیم، وضعیت واقعی هاست را بداند.
انواع خرابیهایی که HA تشخیص میدهد
Host Failure — خرابی کامل هاست
هاست دیگر هیچ Network Heartbeat و Datastore Heartbeat ارسال نمیکند. Master آن را Failed اعلام کرده و تمام VMهای Protected روی هاستهای سالم Restart میشوند. این رایجترین سناریوی استفاده از HA است.
Host Isolation — جداشدن از شبکه Management
هاست هنوز در حال اجراست اما از شبکه Management جدا شده. در این حالت HA سه رفتار قابل تنظیم دارد: Disabled (هیچ اقدامی نشود)، Shut Down and Restart VMs (نیاز به VMware Tools) و Power Off and Restart VMs. رفتار Shut Down ترجیح داده میشود چون تغییرات Disk را Flush میکند.
Network Partition — بخشی از هاستها قادر به ارتباط با Master نیستند
اگر شبکه به گونهای تقسیم شود که برخی Slaveها Master اصلی را نبینند، در هر Partition یک Master موقت انتخاب میشود. این سناریو پیچیدهتر است و میتواند منجر به Split-Brain شود. ویژگی VMCP (VM Component Protection) در vSphere 6+ برای مقابله با این سناریو معرفی شده است.
VM Failure — خرابی سیستمعامل میهمان
با فعالسازی VM Monitoring، HA میتواند کرش سیستمعامل داخل VM را نیز تشخیص دهد. این از طریق نظارت بر Heartbeat های VMware Tools انجام میشود. نیاز به نصب VMware Tools در VM دارد.
Application Failure — خرابی اپلیکیشن
با فعالسازی Application Monitoring، میتوان یک برنامه خاص (مانند یک Database Service) را نظارت کرد. اگر اپلیکیشن Heartbeat ارسال نکند، VM راهاندازی مجدد میشود. این قابلیت به API های خاص نیاز دارد.
Admission Control: تضمین منابع برای Failover
Admission Control (AC) یکی از مهمترین مفاهیم HA است که اطمینان میدهد در صورت خرابی هاست، منابع کافی برای راهاندازی VMها وجود داشته باشد. AC از پاورآن شدن VMهایی که ظرفیت Failover Cluster را نقض میکنند جلوگیری میکند.
سیاست Cluster Failures Tolerate
سادهترین روش: تعیین تعداد هاستهایی که Cluster باید توانایی تحمل خرابی آنها را داشته باشد. vSphere بهطور خودکار درصد منابع رزرو شده را محاسبه میکند.
سیاست Cluster Resource Percentage
تعیین دستی درصدی از CPU و Memory که به عنوان ظرفیت Failover رزرو میشود. کنترل بیشتری در اختیار میگذارد اما نیاز به محاسبه دقیق دارد.
سیاست Dedicated Failover Hosts
تعیین هاستهای مشخص به عنوان ظرفیت رزرو. این هاستها معمولاً خالی هستند و فقط در زمان Failover استفاده میشوند. گرانقیمتترین روش از نظر TCO.
نکته: طبق مستندات رسمی Broadcom، تنظیم Performance Degradation VMs Tolerate در سیاست AC (معرفیشده در vSphere 6.5) امکان میدهد مشخص شود حداکثر چند درصد کاهش عملکرد پس از Failover قابل قبول است. این تنظیم فقط زمانی فعال است که DRS نیز روشن باشد.
Restart Priority: اولویتبندی راهاندازی VM
در صورت Failover، تمام VMها همزمان راهاندازی نمیشوند. HA از اولویتبندی Restart Priority استفاده میکند:
- Highest: VM های زیرساختی مانند DNS، DHCP، Domain Controller
- High: سرورهای application لایه اول
- Medium: سرورهای عادی (پیشفرض)
- Low: VM های کماهمیتتر
- Disabled: این VM توسط HA راهاندازی نمیشود
علاوه بر این، میتوان VM Dependency Rules تعریف کرد که بگوید «گروه A فقط پس از راهاندازی گروه B شروع شود». این برای محیطهایی که Application Stack مرحلهای دارند بسیار مفید است.
VMware vSphere DRS (Distributed Resource Scheduler)
DRS چیست و چه مشکلی را حل میکند
vSphere Distributed Resource Scheduler یک موتور هوشمند توزیع منابع است که وضعیت CPU و Memory تمام هاستها و VMهای یک Cluster را بررسی میکند و در صورت عدم تعادل، VMها را با استفاده از vMotion به هاست مناسبتر منتقل میکند. DRS این کار را بدون هیچ Downtime ای برای VM انجام میدهد.
طبق گزارش فنی رسمی VMware در مورد Load Balancing Performance of DRS in vSphere 7.0، نسل جدید DRS رویکردی VM-Centric دارد: به جای تعادل در سطح Cluster (Host-level balancing)، تمرکز اصلی آن بر بهبود وضعیت هر VM به صورت مجزاست.
DRS قبل از vSphere 7 از یک معیار به نام Imbalance Metric استفاده میکرد که بر اساس انحراف معیار (Standard Deviation) بار هاستها محاسبه میشد. این رویکرد ممکن بود حتی در یک Cluster بهظاهر متعادل، VMهایی وجود داشته باشند که از منابع کافی برخوردار نباشند.
تحول DRS در vSphere 7: از Cluster-Centric به VM-Centric
در vSphere 7.0، VMware DRS را از پایه بازطراحی کرد. مهمترین تغییرات عبارتند از:
- معیار جدید: VM DRS Score — معیار «خوشبختی VM» جایگزین Imbalance Metric شد
- فرکانس اجرا: از هر ۵ دقیقه به هر ۱ دقیقه کاهش یافت
- رویکرد: VM-Centric به جای Cluster-Centric
- کارایی بیشتر: DRS VMهای کوچکتر را برای vMotion ترجیح میدهد تا سرعت Migration بیشتر باشد
- Network-Awareness: DRS بار شبکه هاستها را نیز در محاسبات خود لحاظ میکند
منبع: VMware White Paper — Load Balancing Performance of DRS in vSphere 7.0 (2020). در این مستند رسمی VMware آمده است: «The new DRS is workload-centric and issues vMotions that improve the resource availability for VMs.»
VM DRS Score چگونه محاسبه میشود
VM DRS Score یک عدد بین ۰ تا ۱۰۰ است که نشان میدهد یک VM چقدر «خوشحال» است — یعنی چقدر از منابعی که میخواهد واقعاً دریافت میکند. DRS این امتیاز را برای همه VMها روی همه هاستها محاسبه میکند و اگر انتقال یک VM امتیاز آن را بهبود میبخشد، هزینه vMotion را در نظر میگیرد:
- اگر سود انتقال > هزینه vMotion باشد: DRS vMotion را صادر میکند
- اگر سود انتقال < هزینه vMotion باشد: VM در جای خود میماند
عوامل مؤثر در VM DRS Score: مصرف CPU فعلی VM، حافظه فعلی VM، Reservation و Limit های تعریفشده، ظرفیت آزاد هاست مقصد، بار شبکه هاست مقصد.
حالتهای کاری DRS (Automation Level)
Manual
DRS توصیههای Migration را در vSphere Client نشان میدهد اما هیچ vMotion ای را خودکار اجرا نمیکند. مدیر باید هر توصیه را دستی تأیید یا رد کند. مناسب برای محیطهای حساس که هر تغییری باید بررسی شود.
Partially Automated
DRS در زمان Power On یک VM، آن را به بهترین هاست هدایت میکند (Initial Placement خودکار). اما برای Load Balancing در طول زمان، فقط توصیه میدهد و اجرا نمیکند.
Fully Automated
DRS هم Placement اولیه و هم Load Balancing مستمر را بدون دخالت مدیر انجام میدهد. این حالت برای محیطهای Production با workload متغیر توصیه میشود. مدیر میتواند Migration Threshold را تنظیم کند تا DRS چقدر حساس باشد.
قابلیتهای پیشرفته DRS
VM/Host Affinity Rules
قوانین Affinity تعریف میکنند که کدام VMها باید کنار هم یا دور از هم باشند:
- VM-VM Affinity: «این دو VM همیشه روی یک هاست باشند» — برای VM هایی که کارایی بیشتری با proximity دارند
- VM-VM Anti-Affinity: «این دو VM هرگز روی یک هاست نباشند» — برای instance های مختلف یک App برای تحملپذیری
- VM-Host Affinity: «این VM فقط روی این گروه از هاستها اجرا شود» — برای الزامات لایسنس یا compliance
- VM-Host Anti-Affinity: «این VM روی این هاستها اجرا نشود»
توجه: قوانین Must (الزامی) بر توصیههای DRS اولویت دارند. اگر رعایت قوانین الزامی ممکن نباشد، VM روشن نخواهد شد.
Resource Pools
Resource Pool ها امکان تقسیم منابع Cluster را بین گروههای مختلف VM فراهم میکنند. میتوان Share، Reservation و Limit را برای هر Pool تعریف کرد. مثلاً میتوان ۴۰٪ منابع را به VM های Production و ۲۰٪ را به VM های Test اختصاص داد.
Proactive HA (معرفیشده در vSphere 6.5)
Proactive HA یک قابلیت ترکیبی است که در آن تأمینکنندگان سختافزار (از جمله HPE) یک Plugin برای vCenter ارائه میدهند که سلامت اجزای فیزیکی مانند حافظه، دیسک، منبع تغذیه، فنها و کارتهای شبکه را به DRS اطلاع میدهد. اگر یک جزء دچار خرابی جزئی شود، DRS قبل از خرابی کامل VM ها را از آن هاست خارج میکند.
- Quarantine Mode: DRS از قرار دادن VM جدید روی هاست آسیبدیده خودداری میکند
- Maintenance Mode: DRS تمام VM های هاست را به هاستهای سالم منتقل میکند
مقایسه فنی عمیق HA در برابر DRS
جدول زیر مقایسه جامعی از دو قابلیت ارائه میدهد:
| معیار مقایسه | vSphere HA | vSphere DRS | نکته کلیدی |
| هدف اصلی | Availability — دسترسپذیری | Performance — تعادل منابع | مکمل هم هستند |
| محرک فعالسازی | خرابی هاست یا VM | عدم تعادل منابع | ماهیت متفاوت |
| زمان واکنش | چند ثانیه تا دقیقه | هر یک دقیقه (vSphere 7+) | در vSphere 7 از 5 دقیقه به 1 دقیقه کاهش یافت |
| تأثیر بر VM | Restart (Downtime کوتاه) | Live vMotion (بدون Downtime) | HA = downtime ناخواسته |
| وابستگی به vMotion | خیر | بله — الزامی | شبکه vMotion باید سالم باشد |
| نیاز به Shared Storage | بله | بله | هر دو به SAN/NAS نیاز دارند |
| لایسنس موردنیاز | vSphere Essentials+ | vSphere Enterprise Plus | DRS لایسنس بالاتر نیاز دارد |
| نقش vCenter | پیکربندی؛ HA بدون vCenter کار میکند | ضروری برای عملکرد | HA مستقلتر است |
| نوع خرابی تشخیصداده | Host/VM/App Failure | Resource Imbalance | هدف متفاوت |
| کاربرد اصلی | تداوم کسبوکار پس از خرابی | بهینهسازی منابع مستمر | هر دو در Production ضروری |
HA و DRS: رقیب یا مکمل؟
یک سوءتفاهم رایج این است که HA و DRS کارکردهای مشابهی دارند. واقعیت این است که آنها دو مشکل کاملاً متفاوت را حل میکنند:
- HA پاسخدهی Reactive است: واکنش به رویدادی که اتفاق افتاده (خرابی هاست)
- DRS پاسخدهی Proactive است: بهینهسازی مستمر قبل از بروز مشکل
- HA باعث Downtime کوتاه میشود؛ DRS هیچ Downtime ای ایجاد نمیکند
- HA برای Storage مشترک (تمام VM روی shared datastore)؛ DRS نیاز به vMotion دارد
طبق مستندات رسمی Broadcom (techdocs.broadcom.com): «Using vSphere HA with DRS combines automatic failover with load balancing. This combination can result in a more balanced cluster after vSphere HA has moved virtual machines to different hosts.» این یعنی حتی پس از یک رویداد HA Failover، DRS بلافاصله Cluster را مجدداً متعادل میکند.
تعامل HA و DRS پس از Failover
یکی از قدرتمندترین جنبههای استفاده ترکیبی از HA و DRS، رفتار آنها پس از یک رویداد Failover است:
- ۱. هاست A خراب میشود و VM های آن باید Restart شوند
- ۲. HA Master، هاستهای مناسب برای Restart VM ها را انتخاب میکند
- ۳. در صورت فعال بودن DRS: HA از DRS برای تعیین بهترین هاست مقصد کمک میگیرد
- ۴. VM ها روی هاستهای باقیمانده بین بقیه هاستها توزیع میشوند
- ۵. پس از Restart، DRS Cluster را مجدداً بررسی کرده و بار را متعادل میکند
نکته فنی مهم: در vSphere 7+، حتی اگر vCenter Server در دسترس نباشد، HA میتواند از Simple Placement Engine (SPE) خود برای تعیین هاست مقصد استفاده کند. SPE یک رویکرد Round-Robin دارد اما Affinity Rules از نوع Must را رعایت میکند.
راهنمای پیکربندی گامبهگام
پیشنیازهای محیط
- vCenter Server: نسخه هماهنگ با ESXi hosts
- لایسنس: HA نیاز به vSphere Standard/Enterprise؛ DRS نیاز به Enterprise Plus
- Shared Storage: SAN (iSCSI/FC) یا NAS (NFS) قابل دسترس از تمام هاستها
- Network: Management Network با NIC Teaming برای Redundancy
- vMotion Network (برای DRS): شبکه جداگانه با حداقل ۱۰Gbps
- VMware Tools: نصبشده در تمام VM ها برای VM Monitoring
فعالسازی و پیکربندی HA
مرحله ۱: ایجاد Cluster
در vSphere Client، به Datacenter رفته و یک Cluster جدید ایجاد کنید. در این مرحله میتوانید HA را فعال کنید. هاستهای مورد نظر را به Cluster اضافه کنید.
مرحله ۲: تنظیم Failures and Responses
- Host Failure Response: Restart VMs (توصیه میشود)
- Host Isolation Response: Shut Down and Restart VMs (نیاز به VMware Tools)
- VM Monitoring: فعال با Sensitivity متوسط برای شروع
- Heartbeat Datastores: حداقل ۲ Datastore انتخاب کنید؛ ترجیحاً در Storage Array های مختلف
مرحله ۳: پیکربندی Admission Control
- روش پیشنهادی برای اکثر محیطها: Cluster Failures Tolerate = 1
- Performance Degradation VMs Tolerate: ۲۰٪ پیشفرض خوبی است
- اگر هاستها ناهمگون هستند: از Percentage-based AC استفاده کنید
مرحله ۴: تنظیم Restart Priority برای VM های حیاتی
برای هر VM که نقش زیرساختی دارد (DNS، AD، DHCP)، Restart Priority را روی Highest قرار دهید. برای VM های Application لایه اول، High. برای سایرین Medium.
فعالسازی و پیکربندی DRS
مرحله ۱: فعالسازی DRS در Cluster
در تنظیمات همان Cluster، به بخش DRS رفته و آن را فعال کنید. Automation Level را برای شروع روی Partially Automated قرار دهید تا رفتار DRS را بدون تغییر خودکار بررسی کنید.
مرحله ۲: تنظیم Migration Threshold
- Conservative (سطح ۱): فقط برای ترازبندیهای ضروری
- سطح ۳ (پیشفرض): برای محیطهای با workload پایدار
- Aggressive (سطح ۵): برای workload های متغیر و پویا
مرحله ۳: تعریف VM/Host Rules
قوانین Anti-Affinity برای VM های مشابه (مثلاً دو Web Server) ایجاد کنید. این تضمین میکند که یک Host Failure تمام نمونههای یک App را تحت تأثیر نگذارد.
مرحله ۴: تست و پایش
پس از فعالسازی، بخش DRS History در vSphere Client را بررسی کنید. وقتی از رفتار DRS مطمئن شدید، Automation Level را به Fully Automated تغییر دهید.
تست عملکرد پس از پیکربندی
- تست HA: یک هاست غیرحیاتی را به حالت Isolated ببرید (NIC Management را قطع کنید) و مطمئن شوید VM ها Restart میشوند
- تست DRS: با ابزار stress روی چند VM بار مصنوعی ایجاد کنید و توصیههای DRS را بررسی کنید
- بررسی لاگها: /var/log/vmware/fdm.log روی ESXi hosts برای HA، و DRS History در vSphere Client
سناریوهای واقعی و تصمیمگیری
جدول زیر راهنمای تصمیمگیری برای انتخاب پیکربندی مناسب را در سناریوهای مختلف ارائه میدهد:
| سناریو | توصیه | دلیل |
| دیتابیس OLTP حساس | HA + DRS Manual | VM بدون vMotion ناگهانی — HA برای failover |
| محیط VDI با کاربران متعدد | HA + DRS Fully Auto | DRS بار کاربران را بین هاستها توزیع میکند |
| Web Application با ترافیک متغیر | HA + DRS Fully Auto | DRS در ساعات اوج بار، VM ها را جابجا میکند |
| محیط تست و توسعه | DRS Partially Auto | نیاز کمتر به HA؛ DRS برای صرفهجویی منابع |
| Cluster HPC / Batch | DRS Fully Auto + Anti-Affinity | توزیع بهینه workload های سنگین |
| دو VM از یک App باید جدا باشند | DRS Anti-Affinity Rule | تضمین میکند دو نمونه روی هاستهای متفاوت باشند |
اشتباهات رایج و راهحل آنها
اشتباه ۱: فعال کردن HA بدون Heartbeat Datastore مناسب
اگر Heartbeat Datastore به درستی پیکربندی نشود، HA ممکن است در سناریوی Network Isolation وارد عمل شود در حالی که VM ها هنوز سالم هستند (False Positive). راهحل: حداقل دو Datastore از Storage Array های مختلف انتخاب کنید.
اشتباه ۲: DRS Fully Auto در محیطهای دیتابیس بدون Anti-Affinity
اگر دو نمونه از یک دیتابیس (Primary و Secondary) روی یک هاست قرار گیرند و آن هاست خراب شود، هر دو از دست میروند. راهحل: Anti-Affinity Rule اجباری بین نمونههای دیتابیس تعریف کنید.
اشتباه ۳: Admission Control خیلی محافظهکارانه
تنظیم AC برای تحمل خرابی ۲ یا بیشتر هاست در یک Cluster کوچک ممکن است منابع زیادی را Block کند و از Power On شدن VM ها جلوگیری کند. راهحل: AC را متناسب با اندازه Cluster و اهمیت workload تنظیم کنید.
اشتباه ۴: فقط DRS بدون HA
DRS میتواند VM ها را بین هاستها جابجا کند اما در صورت خرابی فیزیکی یک هاست، VM های آن را راهاندازی نخواهد کرد. HA این خلاء را پر میکند. در محیطهای Production، هر دو باید فعال باشند.
HPE و VMware vSphere: سختافزار بهینه برای HA و DRS
چرا سختافزار اهمیت دارد
کارایی HA و DRS به شدت به کیفیت سختافزار وابسته است. سرعت تشخیص خرابی HA، سرعت vMotion در DRS، و قابلیت اطمینان Shared Storage همه به سختافزار زیرین بستگی دارند. HPE به عنوان یکی از معتمدترین تأمینکنندگان سختافزار enterprise، پلتفرمهایی ارائه میدهد که به صورت خاص برای محیطهای VMware بهینهسازی شدهاند.
HPE ProLiant Gen11 و Gen12: پایه Cluster های vSphere
سرورهای HPE ProLiant Gen11 و نسل جدیدتر Gen12 در Broadcom Compatibility Guide (BCG) تأیید شده و برای اجرای vSphere 8.x و 9.x گواهینامه دارند. ویژگیهای کلیدی برای HA و DRS:
- HPE Intelligent System Tuning (IST): پروفایل Virtualization – Power Efficient برای بهترین تعادل عملکرد و مصرف انرژی در محیط VMware
- HPE Flexible Slot Power Supply: حذف نقطه شکست منبع تغذیه — کاهش نیاز به HA
- HPE iLO (Integrated Lights-Out): مدیریت خارج از باند که به HA کمک میکند تفاوت خرابی واقعی و Isolation را تشخیص دهد
- NIC های ۱۰/25/100 Gbps: پهنای باند کافی برای vMotion سریع در DRS
Proactive HA با Plugin HPE
HPE یک Plugin رسمی برای vCenter ارائه میدهد که سلامت اجزای ProLiant را به DRS گزارش میدهد. این Plugin به عنوان بخشی از HPE OneView for VMware vCenter (OV4VC) ارائه میشود. مطابق مستندات Pearson IT Certification در رابطه با vSphere Proactive HA، «Hardware partners offer a vCenter Server plug-in to provide the health status of the system memory, local storage, power supplies, cooling fans, and network adapters.»
- Memory Failure Detection: تشخیص خرابی جزئی DIMM پیش از خرابی کامل
- Storage Controller Health: وضعیت HPE Smart Array Controller
- Power Supply Redundancy: هشدار زودهنگام از دست دادن Redundancy
- Thermal Status: پیش از آسیب ناشی از گرما، VM ها تخلیه میشوند
HPE Storage و vSphere VAAI/VASA
راهکارهای storage HPE از جمله HPE Primera و HPE Alletra از VAAI (vStorage APIs for Array Integration) و VASA (vStorage APIs for Storage Awareness) پشتیبانی میکنند که تأثیر مستقیم بر HA دارند:
- VAAI Hardware Offload: عملیات Clone، Zeroing و vMotion به آرایه Storage واگذار میشود — کاهش بار CPU هاست در حین vMotion DRS
- VASA PDL/APD Detection: HPE Storage رویدادهای Permanent Device Loss را به vSphere HA اطلاع میدهد تا VMCP (VM Component Protection) بتواند واکنش نشان دهد
- vSAN ReadyNode: HPE ProLiant سرورهای تأییدشده برای HPE vSAN ReadyNode که HA و DRS را در معماری Hyperconverged پشتیبانی میکنند
HPE GreenLake for VMware
HPE GreenLake for VMware یک راهکار as-a-service است که زیرساخت VMware از جمله vSphere Cluster های با HA و DRS پیشپیکربندیشده را در مدل Consumption-based ارائه میدهد. این راهکار برای سازمانهایی که میخواهند از مزایای HA و DRS بهرهمند شوند بدون اینکه پیچیدگیهای پیکربندی را مدیریت کنند، مناسب است.
چکلیست نهایی و جمعبندی
چکلیست پیش از فعالسازی HA
- ✅ تمام هاستها در Cluster Shared Storage یکسانی دارند
- ✅ Management Network با NIC Teaming پیکربندی شده
- ✅ VMware Tools روی تمام VM های حیاتی نصب است
- ✅ حداقل ۲ Heartbeat Datastore از Storage Array های مختلف انتخاب شده
- ✅ Admission Control سیاست مناسب دارد
- ✅ VM های زیرساختی (DNS، AD) دارای Restart Priority = Highest هستند
- ✅ Host Isolation Response به درستی تنظیم شده
چکلیست پیش از فعالسازی DRS
- ✅ لایسنس vSphere Enterprise Plus یا معادل موجود است
- ✅ vMotion Network پیکربندی و تست شده
- ✅ تمام هاستها به یک vMotion Network دسترسی دارند
- ✅ Anti-Affinity Rules برای VM های مشابه تعریف شده
- ✅ Resource Pools برای جداسازی محیطهای مختلف ایجاد شده
- ✅ DRS در حالت Partially Automated تست شده قبل از Fully Auto
- ✅ Migration Threshold متناسب با workload تنظیم شده
جمعبندی
vSphere HA و DRS دو ستون اصلی یک زیرساخت مجازی مقاوم و بهینه هستند. HA پایداری را در برابر خرابیهای غیرمنتظره تضمین میکند، در حالی که DRS کارایی مستمر منابع را بهینه میکند. این دو قابلیت نه تنها با یکدیگر سازگار هستند، بلکه مکمل هم هستند و استفاده همزمان از هر دو یک Cluster بسیار قویتر از استفاده جداگانه ایجاد میکند.
با ظهور nسل جدید DRS در vSphere 7 که رویکرد VM-Centric دارد و با فرکانس اجرای بالاتر عمل میکند، اهمیت DRS در محیطهای مدرن بیشتر شده است. Proactive HA نیز با ادغام اطلاعات سلامت سختافزار (مانند Plugin HPE) مرز بین HA و DRS را در هم میشکند و یک لایه حفاظتی پیشگیرانه ایجاد میکند.
برای سازمانهایی که از تجهیزات HPE استفاده میکنند، ترکیب HPE ProLiant با vSphere HA و DRS، همراه با Proactive HA Plugin و storage های HPE با پشتیبانی VAAI/VASA، یک زیرساخت مجازیسازی درجه یک ایجاد میکند.
