جابجایی ماشینهای مجازی میان دو دیتاسنتر معمولاً از خودِ انتقال دیسک سختتر است. مسئله اصلی حفظ شبکه، کنترل قطعی سرویس، هماهنگی تیمها و داشتن مسیر بازگشت است. VCF Operations HCX 9.1 در VMware Cloud Foundation 9.1 برای همین فاصله طراحی شده است: یک لایه Mobility که محیط قدیمی را به مقصد VCF متصل میکند، بدون آنکه مجبور باشید پیش از مهاجرت همه شبکهها و برنامهها را بازطراحی کنید.
در VCF 9.1 تجربه استقرار سمت مقصد با VCF Operations یکپارچه شده، اما HCX همچنان یک Optional Component است. این تمایز مهم است: وجود VCF 9.1 بهتنهایی به معنی آمادهبودن مسیر مهاجرت نیست. Binary باید دریافت شود، HCX Manager نصب شود، Site Pair و Service Mesh ساخته شود و پیشنیازهای شبکه و گواهی دقیقاً بررسی شوند. این مقاله یک راهنمای تصمیمگیری و طراحی است و با مطلب کلی مقایسه VVF و VCF 9.1 همپوشانی ایجاد نمیکند.
VCF Operations HCX 9.1 دقیقاً چیست؟
HCX یک لایه انتزاع برای جابجایی Workload، اتصال شبکهای و هماهنگکردن دو سایت است. در سمت مقصد VCF 9.1، مدیر میتواند Binary نسخه HCX 9.1 را از مسیر Build > Lifecycle > VCF Instances > Binary Management وارد و سپس آن را از بخش مدیریت اجزای VCF نصب کند. مستند رسمی Broadcom این مسیر را بهعنوان تجربه جدید و متمرکز معرفی میکند. در سمت منبع قدیمی، استقرار HCX Manager معمولاً همچنان با OVA و پیکربندی دستی انجام میشود.
عبارت VCF Operations HCX نباید با ماژول مانیتورینگ شبکه اشتباه شود. VCF Operations for Networks 9.1 برای دیدپذیری، تحلیل Flow و عیبیابی شبکه است؛ HCX برای Mobility، Network Extension و ساخت مسیر مهاجرت میان سایتها بهکار میرود. این دو مکملاند، نه جایگزین هم.
تغییر مهم در VCF 9.1: استقرار یکپارچه، نه مهاجرت خودکار
در نسلهای پیشین، HCX بیشتر مانند یک محصول جانبی با چرخه استقرار مستقل دیده میشد. در VCF 9.1، استقرار HCX Manager در سایت مقصد از رابط VCF Operations انجام میشود و اطلاعات مقصد از همان VCF Instance گرفته میشود. نتیجه، کاهش کار دستی و همراستایی بهتر با Lifecycle پلتفرم است؛ اما طراحی زیرشبکهها، MTU، Firewall، DNS، Site Pair و Service Mesh هنوز تصمیم معماری است.
| محور | VCF 8 / HCX 4.x | VCF 9.0 | VCF 9.1 |
|---|---|---|---|
| مدل استقرار | عمدتاً مستقل و Appliance محور | همراستا با معماری جدید VCF، با وابستگی بیشتر به BOM | استقرار متمرکز HCX Manager مقصد از VCF Operations |
| نقش در پلتفرم | ابزار Mobility در کنار VCF | Workload Mobility در معماری VCF 9 | Optional Component قابل نصب در VCF Instance |
| سایت مبدأ قدیمی | استقرار دستی متداول | بسته به توپولوژی و نسخه مبدأ | برای سناریوی Legacy-to-VCF همچنان OVA و تنظیم دستی مبدأ |
| کنترل نسخه | Compatibility Matrix و Entitlement مستقل مهم بود | BOM مقصد اهمیت جدی دارد | Binary Management، BOM و گواهی SAN باید همزمان کنترل شوند |
| نتیجه عملی | انعطاف بالا، عملیات پراکندهتر | گذار به مدل VCF 9 | نصب سادهتر در مقصد؛ طراحی شبکه همچنان تخصصی |
این جدول به معنی امکان Upgrade مستقیم هر ترکیب قدیمی نیست. Broadcom برای نمونه مستند کرده است که نصب HCX 9.1 روی vCenter 9.0.x میتواند به دلیل نبود Privilege موردنیاز شکست بخورد؛ برای VCF 9.0.x باید نسخه HCX منطبق با BOM همان نسخه انتخاب شود. بنابراین «جدیدترین نسخه» همیشه «نسخه درست» نیست.
معماری HCX در مسیر Workload Mobility
HCX Manager
HCX Manager نقطه کنترل هر سایت است. Managerها با Site Pair به یکدیگر متصل میشوند و کانال مدیریتی آنها بهطور معمول روی TCP 443 شکل میگیرد. در VCF 9.1 میتوان Manager مقصد را از VCF Operations مستقر کرد. برای سایت قدیمی باید FQDN، IP، DNS، NTP، vCenter و در صورت وجود NSX آماده باشد. Broadcom همچنین تأکید دارد که رکوردهای A مربوط به FQDN دو Manager پیش از استقرار ساخته شوند.
Network Profile و Compute Profile
Network Profile مشخص میکند ترافیک Management، vMotion، Replication و Uplink از کدام شبکه و IP Pool عبور کند. Compute Profile نیز منابع محاسباتی، Datastore، Distributed Switch و سرویسهای HCX را به یک طراحی قابل استقرار تبدیل میکند. اشتباه متداول این است که یک VLAN را برای همه نقشها انتخاب کنیم و بعد انتظار جداسازی، ظرفیت و عیبیابی ساده داشته باشیم. جداسازی منطقی یا فیزیکی تابع ظرفیت، امنیت و توپولوژی هر سایت است.
Service Mesh و Service Applianceها
پس از Site Pair، Service Mesh میان Compute Profileهای دو سایت ساخته میشود. این مرحله Applianceهای لازم از جمله Interconnect و Network Extension را مستقر میکند. Interconnect مسیر انتقال و Replication را فراهم میکند و Network Extension امکان میدهد سگمنت لایه ۲ برای دوره مهاجرت در دو سایت در دسترس باشد. این قابلیت برای کاهش تغییرات همزمان مفید است، ولی نباید به یک معماری دائمی بدون برنامه خروج تبدیل شود.
برای تونل رمزگذاریشده میان Applianceهای IX و NE معمولاً UDP 4500 و برای آزمون کارایی TCP/UDP 5201 مطرح است. Broadcom توصیه میکند MTU دو مسیر هماهنگ باشد و برای شبکههای Management، Replication و vMotion تا حد امکان از Subnetهای محلی موجود استفاده شود. بازکردن صرفِ پورتها کافی نیست؛ Latency، Loss، Bandwidth، NAT و مسیر برگشت نیز باید آزموده شوند.
روشهای مهاجرت؛ انتخاب بر اساس RTO و ریسک
HCX چند الگوی Mobility را در اختیار تیم قرار میدهد. انتخاب روش باید با نسخهها، نوع Workload، محدودیت سرویس و نتیجه Compatibility Check تطبیق داده شود.
- HCX vMotion: برای جابجایی آنلاین یک Workload با وقفه بسیار کم، مشروط به آمادهبودن مسیر vMotion و سازگاری زیرساخت.
- Bulk Migration: برای گروه بزرگی از VMها؛ داده پیشکپی میشود و Cutover در پنجره کنترلشده انجام میگیرد.
- Replication Assisted vMotion یا RAV: ترکیب Replication با تجربه Cutover نزدیک به vMotion برای سناریوهایی که نسخه و طراحی آن را پشتیبانی میکند.
- OS Assisted Migration یا OSAM: برای بعضی Workloadهای مبتنی بر Agent و سناریوهایی که مهاجرت در سطح سیستمعامل مناسبتر است.
نام یک روش، تضمین سازگاری آن با هر VM نیست. Encryption، Snapshot، دیسکهای خاص، RDM، نسخه سختافزار مجازی، وضعیت VMware Tools، ظرفیت Datastore و سیاستهای مقصد باید در موج آزمایشی کنترل شوند. برای آموزش عملی این لایهها، صفحه آموزش VMware و آموزش مجازی سازی ابرکلاس نقطه شروع مجموعه است؛ HCX زمانی درست فهمیده میشود که شبکه، vSphere، NSX و عملیات VCF کنار هم دیده شوند.
سناریوی واقعی: انتقال از vSphere 8 به VCF 9.1
فرض کنیم سازمانی یک دیتاسنتر vSphere 8 دارد و مقصد جدید VCF 9.1 را ساخته است. بازطراحی IP برنامهها پیش از مهاجرت ریسک زیادی دارد. مسیر منطقی چنین است:
- نسخههای vCenter، ESXi، NSX و HCX را با Compatibility Matrix و BOM بررسی کنید.
- در مقصد، Binary منطبق HCX 9.1 را وارد و HCX Manager را از VCF Operations نصب کنید.
- در مبدأ قدیمی، OVA نسخه پشتیبانیشده را مستقر و اتصال vCenter و SSO را کامل کنید.
- DNS دوطرفه، NTP، Certificate، MTU و پورتهای مدیریتی و تونل را پیش از Site Pair تست کنید.
- Network Profile و Compute Profile را با IP Poolهای رزروشده بسازید.
- Site Pair را از مبدأ به مقصد و سپس Service Mesh را ایجاد کنید.
- یک موج Pilot با VM کمریسک اجرا، Cutover، Rollback و رفتار مانیتورینگ را ثبت کنید.
- برای موجهای بعدی Runbook، ترتیب وابستگی برنامهها و معیار Go/No-Go داشته باشید.
Network Extension در این سناریو فرصت میدهد IP بعضی سرویسها موقتاً ثابت بماند. بااینحال، Gateway، مسیر North-South، Firewall Rule، DHCP، ARP و سیاست امنیتی مقصد باید روشن باشد. Extension ابزار گذار است، نه مجوزی برای Stretch دائمی همه VLANها.
پیشنیازها و کنترلهای قبل از نصب
| حوزه | کنترل ضروری | پیامد بیتوجهی |
|---|---|---|
| نسخه و BOM | تطبیق VCF، vCenter، NSX و HCX با اسناد همان Release | شکست نصب یا نبود Privilege |
| DNS و NTP | Forward/Reverse Resolution و زمان یکسان در دو سایت | شکست Pairing، Certificate و احراز هویت |
| Certificate | وجود SAN معتبر و انطباق نام FQDN | شکست Import در VCF Operations 9.1 |
| شبکه | IP Pool، Route، MTU، UDP 4500، TCP 443 و مسیر بازگشت | تونل ناپایدار یا مهاجرت متوقف |
| ظرفیت | CPU/RAM برای Manager و Applianceها، Datastore و Bandwidth | کاهش Throughput یا شکست Service Mesh |
| امنیت | Least Privilege، ثبت تغییرات و کنترل دسترسی بینسایتی | سطح حمله و دسترسی غیرضروری |
در VCF Operations 9.1 واردکردن HCX 9.1 با گواهی فاقد Subject Alternative Name ممکن است با خطای عدم تطابق CN/SAN شکست بخورد. راه درست، صدور مجدد گواهی با SANهای صحیح است، نه غیرفعالکردن کنترل اعتبارسنجی. همچنین VCF SSO در HCX 9.1 قابل استفاده است، به شرط آنکه پیکربندی مربوطه کامل شده باشد.
محدودیتها و خطاهای شناختهشدهای که باید جدی گرفت
وابستگی دقیق به نسخه مقصد
KB رسمی Broadcom توضیح میدهد که نصب جدید HCX 9.1 روی VCSA 9.0.x میتواند به دلیل Privilege موجودنبودن در آن نسخه شکست بخورد. راهکار، نصب HCX منطبق با BOM پلتفرم است. این مورد دلیل خوبی است که Binary دانلودشده را صرفاً براساس نام محصول انتخاب نکنیم.
RAV و Bulk Migration روی پورت 8123
در یک مشکل شناختهشده HCX 9.1، سرویس hbrsrv روی Interconnect ممکن است بهجای آدرس لازم روی localhost Bind شود و RAV یا Bulk Migration با خطای HTTP روی پورت 8123 شکست بخورد. Broadcom برای این وضعیت بررسی Log و راهکار عملیاتی مشخص ارائه کرده است. قبل از موج بزرگ، حتماً یک مهاجرت آزمایشی اجرا و سلامت Replication Channel کنترل شود.
OSAM و Force Cleanup
پس از تکمیل OSAM، استفاده عجولانه از Force Cleanup میتواند خطر حذف VM مقصد را ایجاد کند. اگر وضعیت Job با وضعیت واقعی Workload همخوان نیست، ابتدا Runbook و KB مربوطه بررسی شود. Cleanup یک عملیات بیخطر نمایشی نیست.
VMware Cloud Director
برای VCD 10.6.x و HCX 9.x نباید Direct Integration را فرض کرد. طبق KB رسمی، در مسیر VCF Automation 9.1 باید HCX دو سمت مستقیماً به vCenter زیربنایی ثبت شود و مهاجرت Namespace به شکل vCenter-to-vCenter طراحی شود. اگر Cloud Director بخشی از معماری است، این محدودیت قبل از خرید یا زمانبندی پروژه باید بررسی شود. مقاله VCF Automation 9.1 نقش لایه Automation را جداگانه توضیح میدهد.
لایسنس، دانلود و پیادهسازی در محیط آفلاین یا ایران
HCX در VCF 9.1 یک Optional Component است؛ اما سطح Entitlement، روش دریافت Binary و قابلیتهای مجاز باید براساس قرارداد Broadcom، BOM و پرتال پشتیبانی همان مشتری کنترل شود. از روی عبارت «VCF 9.1» نمیتوان نتیجه گرفت همه قابلیتهای HCX در هر Subscription فعالاند. در طراحی تجاری، SKU و Entitlement را جدا از امکان فنی استقرار تأیید کنید.
برای محیطهای محدود یا آفلاین، چالش اصلی فقط دانلود OVA نیست. Binary صحیح، Hash، گواهی، DNS داخلی، NTP، Repository، مسیر انتقال امن فایل و مستندسازی Download Token باید پیش از Change Window آماده شود. در ایران نیز محدودیت دسترسی به پرتال و سرویسهای خارجی میتواند برنامه دریافت فایل و پشتیبانی را تحت تأثیر قرار دهد. راهکار حرفهای، نگهداری Repository کنترلشده از Binaryهای مجاز و منطبق با BOM است؛ استفاده از فایل ناشناس یا نسخه نامنطبق ریسک امنیت و Supportability ایجاد میکند.
HCX در نقشه آموزش VCF
HCX یک ابزار تکمحصولی نیست؛ نقطه اتصال چند مهارت است. در یک مسیر درست آموزش VCF، کارآموز باید Lifecycle و VCF Operations، طراحی vSphere و NSX، Certificate، Routing و Migration Runbook را کنار هم ببیند. برای تیمی که بیشتر با آموزش VVF شروع کرده، تفاوت مهم این است که Workload Mobility میان سایتها و مدیریت اجزای VCF به طراحی گستردهتری از یک کلاستر vSphere نیاز دارد. همچنین مطالعه VCF Operations 9.1 کمک میکند جایگاه Lifecycle و مدیریت متمرکز HCX روشنتر شود.
جمعبندی فنی
ارزش VCF Operations HCX 9.1 در «سادهکردن استقرار مقصد» و ایجاد یک پل کنترلشده برای Workload Mobility است. این نسخه اصطکاک نصب را کاهش میدهد، اما پیچیدگی واقعی مهاجرت را حذف نمیکند. پروژه موفق به چهار چیز وابسته است: نسخه و BOM درست، شبکه و Certificate قابل پیشبینی، موج آزمایشی واقعی و برنامه خروج از Network Extension.
اگر فقط HCX Manager را نصب کنید، هنوز مهاجرتی طراحی نشده است. خروجی حرفهای باید شامل Site Pair مستند، Service Mesh پایدار، Port Matrix، Inventory وابستگیها، Runbook Cutover و Rollback و معیار پذیرش پس از انتقال باشد. HCX ابزار اجرای این برنامه است، نه جایگزین آن.
پرسشهای متداول
آیا VCF Operations HCX 9.1 جزء اجباری VCF 9.1 است؟
خیر. HCX در مسیر Lifecycle بهصورت Optional Component نصب میشود. نیاز فنی و Entitlement آن باید جداگانه بررسی شود.
آیا میتوان HCX 9.1 را روی هر محیط VCF 9.0 نصب کرد؟
خیر. Broadcom برای نصب HCX 9.1 روی بعضی محیطهای VCSA 9.0.x مشکل سازگاری Privilege را مستند کرده است. نسخه HCX باید با BOM مقصد منطبق باشد.
آیا Network Extension یعنی شبکه را برای همیشه Stretch کنیم؟
خیر. Extension بهترین ارزش را بهعنوان ابزار گذار دارد. برای ماندگاری بلندمدت باید اثر آن بر Routing، Failure Domain، Latency و عملیات امنیتی بررسی شود.
برای Site Pair چه چیزی بیشتر از همه خطا ایجاد میکند؟
DNS دوطرفه، NTP، Certificate با SAN صحیح، TCP 443 و دسترسی مدیریتی از عوامل اصلیاند. بعد از Pairing نیز MTU، UDP 4500 و IP Poolهای Applianceها تعیینکنندهاند.
آیا HCX مستقیماً با VMware Cloud Director 10.6.x یکپارچه میشود؟
برای HCX 9.x نباید Direct Integration با VCD 10.6.x را فرض کرد. Broadcom مسیر ثبت مستقیم HCX به vCenterهای زیربنایی و مهاجرت vCenter-to-vCenter را مستند کرده است.
بهترین روش شروع پروژه HCX چیست؟
یک Pilot کمریسک با چند VM نماینده انتخاب کنید، همه Checkها و زمانها را ثبت کنید و فقط پس از اثبات Cutover و Rollback به سراغ موجهای بزرگ بروید.
