محصولات آکو
HPE
DELL
Broadcom
خدمات آکو
بلاگ
دانلود
HPE
DELL
Broadcom
Vmware
درباره ما
ارتباط با ما
مهاجرت از فیزیکال به مجازی یا P2V فرایندی است که در آن سیستمعامل، دادهها، نرمافزارها و تنظیمات یک سرور فیزیکی به یک ماشین مجازی قابل اجرا در زیرساخت VMware منتقل میشوند. این راهکار برای تجمیع سرورها، کاهش وابستگی به سختافزار قدیمی، سادهتر شدن مدیریت و آمادهسازی زیرساخت برای توسعه آینده کاربرد دارد؛ با این حال موفقیت آن به ارزیابی سازگاری، Backup قابل بازیابی، طراحی شبکه و Storage، برنامه Cutover و آزمون کامل سرویسها وابسته است.
- P2V جایگزین Backup نیست؛ پیش از تبدیل باید نسخه پشتیبان مستقل و قابل Restore داشته باشید.
- نسخه Converter، سیستمعامل مبدأ، Firmware از نوع BIOS یا UEFI و نسخه مقصد باید جداگانه بررسی شوند.
- در زمان Cutover نباید سرور فیزیکی و ماشین مجازی با IP، Hostname یا هویت یکسان همزمان در شبکه فعال باشند.
- برای Database، Domain Controller، Cluster و نرمافزارهای دارای تراکنش فعال، برنامه مهاجرت باید با الزامات همان سرویس هماهنگ شود.
- پس از تبدیل، Right-Sizing منابع، نصب VMware Tools و تست Application مهمتر از صرفاً روشن شدن VM است.
P2V چیست و چه تفاوتی با V2V و V2P دارد؟
P2V مخفف Physical to Virtual است و به تبدیل یک سیستم فیزیکی روشن یا خاموش به ماشین مجازی گفته میشود. خروجی معمولاً شامل دیسکهای مجازی، تنظیمات CPU و RAM، کارت شبکه مجازی و فایلهای پیکربندی VM است. هدف این فرایند کپی ساده فایلها نیست؛ بلکه باید سیستمعامل مقصد بتواند پس از تغییر سختافزار، در محیط مجازی Boot شود و سرویسهای آن بدون ناسازگاری ادامه کار دهند.
P2V یعنی بازسازی یک سرور فیزیکی بهصورت ماشین مجازی، به شکلی که سیستمعامل و Applicationهای آن روی Hypervisor اجرا شوند و وابستگی مستقیم به سختافزار قبلی کاهش یابد.
تفاوت P2V، V2V و V2P
| نوع تبدیل | مبدأ | مقصد | کاربرد متداول |
|---|---|---|---|
| P2V | سرور یا سیستم فیزیکی | ماشین مجازی | تجمیع سرورها، حفظ سیستم قدیمی و مهاجرت به دیتاسنتر مجازی |
| V2V | ماشین مجازی یا فرمت مجازی دیگر | ماشین مجازی در پلتفرم یا فرمت جدید | انتقال بین Hypervisorها، Datastoreها یا محیطهای مدیریتی |
| V2P | ماشین مجازی | سختافزار فیزیکی | سناریوهای خاص سازگاری، بازیابی یا بازگشت به Bare Metal |
اجزای VMware در یک پروژه P2V
VMware vSphere پلتفرم اصلی مجازیسازی سازمانی است؛ ESXi نقش Hypervisor را دارد و ماشینهای مجازی روی Hostهای آن اجرا میشوند. vCenter Server مدیریت متمرکز Hostها، شبکه، Storage، Cluster و ماشینهای مجازی را فراهم میکند. vCenter Converter Standalone نیز ابزار متداول برای تبدیل ماشین فیزیکی یا برخی فرمتهای مجازی به VM است. پس از تبدیل، VMware Tools برای درایورهای بهینه، Shutdown هماهنگ، اطلاعات Guest و برخی قابلیتهای مدیریتی اهمیت دارد.
چرا سازمانها از مهاجرت P2V استفاده میکنند؟
ارزش واقعی P2V زمانی مشخص میشود که بخشی از یک برنامه Modernization باشد، نه صرفاً انتقال یک سرور قدیمی به فایل VMDK. سازمان باید بداند کدام Workload ارزش مجازیسازی دارد، کدام سرویس باید بازطراحی شود و کدام سیستم به دلیل محدودیت فنی یا تجاری بهتر است روی سختافزار فیزیکی باقی بماند.
کاهش وابستگی به سختافزار قدیمی
تجمیع و استفاده بهتر از منابع
مدیریت متمرکز و استاندارد
تسهیل تست و Disaster Recovery
حفظ Applicationهای Legacy
آمادگی برای Hybrid Cloud
سناریوهای مناسب و نامناسب
P2V برای File Server، Application Server، سامانههای داخلی با مصرف متوسط، محیطهای Test و بسیاری از Workloadهای عمومی مناسب است. در مقابل، سیستمهایی که به سختافزار اختصاصی، Dongle فیزیکی، کارت PCI خاص، Latency بسیار پایین یا تجهیزات صنعتی وابستهاند، باید جداگانه ارزیابی شوند. همچنین برای Workloadهای تراکنشی حساس، مجازیسازی باید با روشهای Application-Aware، Replication یا Backup سازگار با Vendor ترکیب شود.
ارزیابی و پیشنیازهای مهاجرت P2V
مهمترین بخش پروژه پیش از اجرای Converter انجام میشود. Inventory ناقص، نبود Backup قابل Restore، کمبود فضای Datastore یا عدم شناخت وابستگی Applicationها میتواند یک تبدیل ظاهراً موفق را در زمان Cutover به اختلال عملیاتی تبدیل کند.
جمعآوری Inventory و بررسی سازگاری
- نسخه و معماری سیستمعامل، وضعیت Patch و نوع Boot شامل BIOS یا UEFI را ثبت کنید.
- CPU، RAM، حجم واقعی داده، تعداد Diskها، Partition Table و نرخ تغییر داده را اندازهگیری کنید.
- سرویسها، Scheduled Taskها، License Binding، Certificateها و وابستگی به IP یا MAC Address را شناسایی کنید.
- نوع Storage Controller، نرمافزارهای مدیریت سختافزار و Driverهای اختصاصی Vendor را فهرست کنید.
- سازگاری سیستمعامل مبدأ و مقصد را با مستندات نسخه Converter و ماتریس VMware بررسی کنید.
Converter Standalone 6.6 روی سیستمعامل Windows نصب میشود. برای P2V سیستم Linux از Helper VM و ارتباط SSH استفاده میشود. همچنین در مستندات این نسخه، Diskهای 4Kn بهعنوان محدودیت مطرح شدهاند؛ بنابراین Sector Size و Firmware سرور را پیش از پروژه بررسی کنید.
Backup، Application Consistency و برنامه Cutover
قبل از شروع، Backup مستقل از سیستم تهیه و Restore آن آزمایش شود. برای Databaseها و سرویسهای تراکنشی، تنها کپی Block-Level تضمینکننده سازگاری Application نیست. ممکن است لازم باشد سرویس متوقف، Transactionها Flush، Logها هماهنگ یا از روش پشتیبانگیری Application-Aware استفاده شود. زمان Cutover باید شامل توقف تغییرات، Sync نهایی در صورت پشتیبانی، خاموش کردن مبدأ، روشن کردن مقصد و آزمون سرویس باشد.
ظرفیت Storage، شبکه و پورتهای ارتباطی
Datastore مقصد باید علاوه بر حجم فعلی داده، فضای رشد، Snapshotهای احتمالی و سربار عملیاتی را پوشش دهد. نرخ انتقال به Bandwidth شبکه، Latency، میزان داده و تغییرات همزمان روی مبدأ وابسته است. در سناریوی Windows، ارتباط میان Converter، Source، vCenter و ESXi به پورتهایی مانند 443، 902، 903، 445 و پورت Agent وابسته است؛ در Linux نیز SSH روی پورت 22 و دسترسی Helper VM اهمیت دارد. قبل از Migration، Firewall و مسیرهای Routing را تست کنید.
جلوگیری از تداخل هویت در شبکه
Destination VM را در شبکه ایزوله یا Port Group آزمایشی روشن کنید. تا زمانی که Source خاموش نشده، اتصال همزمان دو سیستم با Hostname، IP یا License Identity یکسان میتواند باعث Conflict، اختلال DNS، مشکل Domain و رفتار نامشخص Application شود.
ابزارها و انتخاب مقصد در VMware
انتخاب ابزار و Target باید بر اساس اندازه پروژه، سیستمعاملها، سطح Downtime قابل قبول و معماری مقصد انجام شود. برای یک سرور مستقل ممکن است Converter کافی باشد؛ اما مهاجرت گسترده دیتاسنتر به Cloud یا محیط جدید، به Orchestration، Replication و روشهایی مانند VMware HCX برای مهاجرت دیتاسنتر نیاز دارد.
VMware vCenter Converter Standalone
Converter Standalone فرایند شناسایی Source، انتخاب Destination، تنظیم VM، کپی Volumeها و Reconfiguration را از طریق Wizard مدیریت میکند. نسخه 6.6 برای تبدیل سیستمهای Windows و Linux و برخی منابع مجازی ارائه شده است؛ با این حال عبارت «پشتیبانی از ESXi» بهتنهایی کافی نیست و باید نوع Source، Guest OS، Firmware، Hardware Version و مقصد Managed یا Standalone بررسی شود.
ESXi یا VMware Workstation؛ کدام مقصد مناسبتر است؟
برای سرویسهای سازمانی و Production، مقصد معمولاً ESXi تحت مدیریت vCenter است، زیرا قابلیتهای HA، مدیریت متمرکز، شبکه و Storage سازمانی را فراهم میکند. Workstation بیشتر برای Lab، تست، توسعه و بررسی اولیه مناسب است. برای شناخت تفاوت معماری و کاربرد این دو گزینه، مقاله تفاوت VMware Workstation و VMware ESXi مسیر انتخاب را روشنتر میکند.
Thin یا Thick Provisioning
| گزینه | رفتار ظرفیت | مزیت | نکته مدیریتی |
|---|---|---|---|
| Thin Provisioning | فضا متناسب با داده نوشتهشده مصرف میشود | کاهش مصرف اولیه Datastore و انعطاف بیشتر | نیازمند Monitoring دقیق ظرفیت و جلوگیری از Overcommit کنترلنشده است |
| Thick Lazy Zeroed | کل ظرفیت از ابتدا رزرو میشود و Blockها هنگام استفاده Zero میشوند | ظرفیت تضمینشده برای VM | فضای بیشتری از ابتدا اشغال میکند و باید با سیاست Storage هماهنگ باشد |
| Thick Eager Zeroed | ظرفیت رزرو و Blockها از ابتدا Zero میشوند | برای برخی قابلیتها و Workloadهای خاص مناسب است | زمان Provisioning و مصرف فضا بیشتر است؛ انتخاب آن باید دلیل فنی داشته باشد |
انتخاب Thin یا Thick باید با نوع Datastore، سیاست Storage، رشد داده، عملکرد مورد انتظار و رویه Capacity Management هماهنگ شود. Thin به معنای ظرفیت نامحدود نیست و Thick نیز بهصورت خودکار عملکرد بهتر را در همه سناریوها تضمین نمیکند.
مراحل عملی مهاجرت فیزیکال به مجازی با VMware
روش زیر یک چارچوب اجرایی عمومی است. جزئیات هر پروژه باید بر اساس نوع سیستمعامل، Application، روش Backup و سطح حساسیت سرویس تنظیم شود.
- Scope پروژه را مشخص کنید: سرورها، مالک سرویس، SLA، Downtime مجاز و معیار موفقیت را ثبت کنید.
- Inventory و Dependency Map بسازید: ارتباط با Database، DNS، Active Directory، Storage، License Server و سیستمهای جانبی را مستند کنید.
- Backup و Restore Test انجام دهید: قبل از هر تغییر، امکان بازگشت واقعی را اثبات کنید.
- Source را آماده کنید: سلامت File System، فضای آزاد، Event Log، سرویسها و Driverهای ناسازگار را بررسی کنید؛ پاکسازی باید کنترلشده باشد.
- Converter را روی Windows مناسب نصب کنید: حساب Administrator، دسترسی شبکه، DNS Resolution و پورتهای لازم را کنترل کنید.
- Source و Destination را تعریف کنید: Credentials، ESXi یا vCenter، Datacenter، Cluster، Host، Datastore و Port Group را انتخاب کنید.
- منابع VM را تنظیم کنید: vCPU، RAM، Disk Layout، نوع Provisioning، Controller و NIC را متناسب با نیاز واقعی تعیین کنید.
- Conversion اولیه را اجرا و مانیتور کنید: Progress، Log، نرخ انتقال، خطاهای Agent و فضای Datastore را زیر نظر بگیرید.
- Cutover را اجرا کنید: تغییرات Application را متوقف، Sync نهایی را در صورت امکان انجام، Source را خاموش و Destination را در شبکه کنترلشده روشن کنید.
- Validation و تحویل انجام دهید: Boot، Network، Storage، سرویسها، Performance، Backup، Monitoring و تایید مالک Application را ثبت کنید.
تبدیل Powered-On میتواند بخش عمده داده را هنگام روشن بودن Source کپی کند، اما Cutover بدون وقفه کامل تضمین نمیشود. مدت قطعی نهایی به Sync تغییرات، زمان Boot، کنترل سرویسها و آزمون Application وابسته است.
اقدامات ضروری پس از تبدیل سرور فیزیکی به VM
پایان Job در Converter به معنای پایان پروژه نیست. ماشین مجازی باید از نظر Boot، عملکرد، امنیت، Backup و عملیات روزمره آماده Production شود.
بررسی Boot، Controller، NIC و VMware Tools
- Boot Mode، ترتیب Diskها و Controller مجازی را بررسی کنید.
- VMware Tools را نصب یا بهروزرسانی کنید و Driverهای NIC و Storage مجازی را کنترل کنید.
- Agentها و Utilityهای مخصوص سختافزار فیزیکی را تنها پس از اطمینان و طبق Change Plan حذف کنید.
- IP، DNS، Gateway، VLAN، MTU و Firewall داخل Guest را تست کنید.
- زمان سیستم، NTP و رفتار Time Synchronization را با طراحی Domain و Application هماهنگ کنید.
تست سرویسها و Right-Sizing منابع
CPU و RAM سرور فیزیکی را بدون تحلیل عیناً به VM منتقل نکنید. معیارهایی مانند CPU Ready، Memory Pressure، Disk Latency، IOPS و Network Throughput باید پس از مهاجرت اندازهگیری شوند. مقاله بهینهسازی کارایی ماشینهای مجازی در VMware برای مرحله Tuning مفید است. در محیطهای بزرگ، کنترل VM Sprawl در VMware نیز مانع رشد بیقاعده منابع میشود.
Backup، Monitoring و مستندسازی
ماشین مجازی جدید باید وارد Jobهای Backup، Monitoring، Patch Management، CMDB و سیاستهای امنیتی شود. Snapshot دائمی جایگزین Backup نیست. Baseline اولیه Performance، ظرفیت Disk و وضعیت سرویسها را ثبت کنید تا مشکلات بعدی با داده قابل اندازهگیری مقایسه شوند.
خطاهای رایج P2V و راهکارهای عیبیابی
| مشکل | علتهای محتمل | اقدام پیشنهادی |
|---|---|---|
| Agent نصب یا اجرا نمیشود | Permission ناکافی، Port مسدود، DNS نامعتبر، Firewall یا Endpoint Security | حساب Administrator، دسترسی پورتهای مورد نیاز، Name Resolution و Logهای Converter را بررسی کنید؛ بهجای خاموش کردن کامل امنیت، Exception موقت و کنترلشده بسازید. |
| Job در درصد مشخص متوقف میشود | Timeout، فضای ناکافی، خطای Source Volume، ارتباط ESXi یا مشکل Sync | converter-worker و converter-agent Log، سلامت File System، فضای Datastore و Connectivity را تحلیل کنید. |
| VM پس از تبدیل Boot نمیشود | ناسازگاری BIOS یا UEFI، Controller، Boot Disk یا Driver | Firmware ماشین مجازی، ترتیب Boot، نوع SCSI Controller و Reconfiguration سیستمعامل را بازبینی کنید. |
| شبکه در Guest در دسترس نیست | NIC جدید، IP باقیمانده روی Adapter مخفی، VLAN اشتباه یا Driver ناقص | VMware Tools، Port Group، Adapter Type، Ghost NIC و تنظیمات IP را بررسی کنید. |
| کندی پس از P2V | vCPU بیش از نیاز، RAM نامناسب، Storage Latency، Thin Growth یا Driver قدیمی | با Metric واقعی Right-Size کنید، Latency و Queue را بسنجید و از افزایش کورکورانه منابع پرهیز کنید. |
| Application یا License فعال نمیشود | وابستگی به Hardware ID، MAC Address، Dongle، Hostname یا Certificate | قبل از Cutover سیاست License Vendor را بررسی و Rehost یا Reactivation را برنامهریزی کنید. |
برخی Endpoint Securityها ممکن است نصب Agent یا انتقال Block را محدود کنند، اما خاموش کردن کامل و بدون کنترل آنها ریسک امنیتی دارد. ابتدا Log و Policy را بررسی کنید، Exception محدود بسازید و بلافاصله پس از عملیات تنظیمات حفاظتی را بازگردانید.
بهترین روشها و برنامه Rollback
Migration را بهصورت Pilot اجرا کنید
قبل از مهاجرت Workloadهای حیاتی، یک سرور کمریسک با معماری مشابه را تبدیل کنید. این Pilot به شناسایی مشکل Firewall، Datastore، NIC، Template منابع و فرایند Cutover کمک میکند.
معیار موفقیت و نقطه بازگشت تعریف کنید
Rollback باید دارای Trigger روشن باشد؛ برای مثال Boot نشدن VM، عدم دسترسی به Database، خطای Data Integrity یا عبور Downtime از حد تعیینشده. تا زمان تایید نهایی، Source را حذف یا Reformat نکنید و روشن کردن مجدد آن را فقط پس از خاموش و ایزوله کردن Destination انجام دهید.
فرایند را مستند و قابل تکرار کنید
Runbook باید شامل Inventory، Screenshot تنظیمات، Credential Owner، پورتها، زمانبندی، مسئول هر مرحله، Test Case، Validation Result و روش بازگشت باشد. در پروژه چندسروری، Wave Planning و اولویتبندی براساس Dependency از تبدیل همزمان سیستمهای وابسته جلوگیری میکند.
مطالب و خدمات مرتبط
سوالات متداول درباره مهاجرت P2V با VMware
آیا P2V بدون قطعی سرویس انجام میشود؟
بخش عمده کپی داده در برخی سناریوهای Powered-On هنگام فعالیت Source انجام میشود، اما برای Cutover، جلوگیری از تغییرات و روشن کردن Destination معمولاً یک بازه قطعی کنترلشده لازم است. مدت آن به حجم تغییرات و تست سرویس وابسته است.
آیا مهاجرت P2V ممکن است باعث از بین رفتن داده شود؟
در اجرای صحیح، هدف حفظ داده است؛ با این حال خطای File System، تغییرات همزمان Application یا مشکل Storage میتواند ریسک ایجاد کند. Backup مستقل و Restore Test پیششرط پروژه است.
آیا Converter 6.6 با همه نسخههای ESXi سازگار است؟
خیر. سازگاری فقط با شماره ESXi تعیین نمیشود و به Guest OS، نوع Source، Firmware، Hardware Version و مقصد Managed یا Standalone وابسته است. پیش از پروژه باید مستندات همان نسخه و ماتریس سازگاری بررسی شود.
برای P2V سرور Linux چه نکتهای مهم است؟
Converter روی Windows نصب میشود و برای Linux از Helper VM و SSH استفاده میکند. دسترسی شبکه Helper VM به Source، پورت 22، تنظیم IP و پشتیبانی Distribution باید بررسی شوند.
هزینه و زمان یک پروژه P2V چگونه تعیین میشود؟
تعداد سرورها، حجم و نرخ تغییر داده، پیچیدگی Application، Downtime مجاز، طراحی مقصد، آزمونها و نیاز به Rollback عوامل اصلی هستند. یک سرور ساده ممکن است در چند ساعت تبدیل شود، اما پروژه سازمانی چندسروری به Wave Planning و زمان بیشتری نیاز دارد.
آیا پس از P2V میتوان VM را به Cloud منتقل کرد؟
از نظر فنی ممکن است، اما شبکه، IP Plan، وابستگی Application، Security، لایسنس، Storage و فرمت مقصد باید بررسی شوند. P2V تنها مرحله اول است و Cloud Migration معمولاً طراحی مستقل میخواهد.
جمعبندی؛ P2V موفق یک پروژه تبدیل نیست، یک پروژه انتقال سرویس است
مهاجرت P2V با VMware زمانی موفق است که ماشین مجازی جدید فقط Boot نشود، بلکه سرویس آن با Performance قابل قبول، شبکه صحیح، Backup فعال، امنیت مناسب و امکان Rollback تحویل داده شود. استفاده از Converter، انتخاب ESXi یا Workstation و تنظیم Thin یا Thick بخشی از کار هستند؛ تصمیمهای اصلی به شناخت Application، سازگاری سیستمعامل، ظرفیت مقصد، مدیریت Downtime و آزمون پس از مهاجرت مربوط میشوند.
برای سرورهای کمریسک میتوان از یک Runbook استاندارد استفاده کرد، اما Workloadهای حیاتی، Databaseها، Domain Controllerها و سیستمهای دارای وابستگی سختافزاری به ارزیابی و طراحی اختصاصی نیاز دارند.