کلون چیست؟ چگونه بدون نصب مجدد، یک سرور مشابه بسازیم؟

در مدیریت زیرساخت سرور و هاستینگ، وقتی می‌پرسیم کلون چیست، پاسخ کوتاه و سرراست است: کلون (Clone) که گاهی در تلفظ عامیانه «کولون» هم گفته می‌شود، نسخۀ تکثیرشده‌ای از یک سیستم، دیسک یا ماشین مجازی است که برای ساختن محیطی مشابه منبع اصلی به کار می‌رود. آشنایی دقیق با اینکه Clone چیست، به مدیران شبکه و متخصصان زیرساخت اجازه می‌دهد بدون نیاز به نصب و پیکربندی دوبارۀ تمام اجزا، از وضعیت فعلی سرور یک نمونۀ جدید بسازند. البته میزان استقلال این نسخۀ جدید، به نوع کلون، فناوری مجازی‌سازی و روش کلون‌گیری بستگی دارد.

در این مطلب از وبلاگ مبین هاست بررسی می‌کنیم کلونینگ چیست، چه انواعی دارد، کجای دنیای مجازی‌سازی و VDI می‌ایستد و چه مرزی با مفاهیمی مثل Snapshot ،Backup ،Template و Replication دارد. در ادامه نیز سراغ پیش‌نیازهای آماده‌سازی ویندوز و لینوکس، چالش لایسنس‌ها و مراحل عملی ساخت کلون سرور می‌رویم. با ما همراه باشید.

کلون چیست و چگونه کار می‌کند؟

به فرایند ساخت یک نسخه مشابه از داده‌ها، دیسک یا ماشین مجازی، کلونینگ (Cloning) یا همانندسازی می‌گویند. در این عملیات، اطلاعات و ساختارهای لازم از سیستم مبدأ به نمونۀ جدید منتقل می‌شوند تا محیط مقصد دقیقاً بر پایۀ وضعیت منبع شکل بگیرد. این انتقال داده در سطح دیسک، بسته به ابزاری که به کار می‌برید، یا به‌صورت کپی بلوک‌به‌بلوک (Block-by-Block) انجام می‌شود یا بر پایۀ فایل و Snapshot پیش می‌رود. وقتی هدفْ ساختن یک کلون کامل باشد، دیسک جدید باید کاملاً مستقل از دیسک مبدأ کار کند؛ به همین دلیل ساختار پارتیشن‌ها، فایل‌های سیستم‌عامل و بخش‌های مربوط به راه‌اندازی (Boot) همگی به محیط جدید منتقل می‌شوند.

در محیط‌های مجازی نیز کلون‌گیری معمولاً از روی یک ماشین مجازی مبدأ انجام می‌گیرد. در این حالت، هایپروایزر یا پلتفرم مدیریت مجازی‌سازی، پیکربندی ماشین و دیسک‌های مجازی آن را در قالب یک ماشین جدید بازسازی می‌کند. طبیعتاً در این مرحله باید شناسه‌هایی مانند UUID ،MAC Address و مشخصات شبکه‌ای سیستم‌عامل سفارشی‌سازی شوند تا ماشین جدید از دید زیرساخت و شبکه، هویتی جداگانه داشته باشد.

با این حساب، کلون را نباید صرفاً یک «کپی ساده از فایل‌ها» دانست؛ به این دلیل که خروجی این کار یک ماشین مجازی کامل، یک دیسک قابل بوت یا محیط عملیاتی تازه‌ای است که مستقیماً برای استقرار سرویس، تست، مهاجرت یا توسعۀ نرم‌افزار آماده است.

انواع کلون در مجازی‌سازی چیست؟

حالا که دربارۀ Cloning چیست اطلاعات موردنیازمان را به دست آوردیم، به این موضوع می‌پردازیم که وقتی صحبت از این می‌شود که Clone در مجازی‌ سازی چیست، باید میان دو رویکرد اصلی تفاوت قائل شویم: اول، روش‌هایی که نسخه‌ای کاملاً مستقل می‌سازند و دوم، روش‌هایی که بخشی از داده را با ماشین والد (Parent) به اشتراک می‌گذارند.

در جدول زیر، دو مدل Full Clone و Linked Clone را از نظر مفهومی مقایسه کرده‌ایم؛ اما توجه داشته باشید که مراحل عملی ساخت کلون در بخش‌های بعدی، مشخصاً بر اساس VMware vSphere 8.0 و vCenter Server 8.0 نوشته شده‌اند. تأکید روی این تفکیک به آن خاطر است که Linked Clone کاربرد تاریخی مشخصی در اکوسیستم Horizon و View Composer داشته و نباید آن را با کلون‌های معمولی در محیط vSphere یکی دانست.

شاخص مقایسه	Full Clone	Linked Clone
میزان استقلال	مستقل از دیسک والد پس از تکمیل کپی	وابسته به دیسک یا زنجیرۀ والد
مصرف فضای ذخیره‌سازی	نیازمند فضای متناسب با کل داده‌های کپی‌شده	کمتر (به دلیل اشتراک بخشی از داده با والد)
سرعت ایجاد	وابسته به حجم داده و سرعت زیرساخت ذخیره‌سازی	معمولاً سریع‌تر به دلیل کپی نشدن کامل داده‌های والد
وضعیت دیسک پس از ایجاد	دیسک کاملاً مستقل از ماشین مبدأ	وابسته به دیسک پایه یا والد
عملکرد پس از ایجاد	عدم وابستگی به زنجیرۀ Snapshot والد	وابسته به ساختار والد و زنجیره دیسک
کاربرد رایج	ایجاد سرور مستقل، استقرار عملیاتی و مهاجرت	سناریوهای خاص یا قدیمی‌تر مبتنی بر دیسک والد

فول کلون (Full Clone) چیست؟

فول کلون نسخه‌ای کاملاً مستقل از ماشین مجازی مبدأ است که تمام دیسک‌های اجرایی آن به مقصد منتقل یا تکثیر می‌شوند. ویژگی کلیدی Full Clone در این است که به‌محض پایان عملیات کپی، ماشین جدید روی پای خودش می‌ایستد و برای خواندن و نوشتن اطلاعات هیچ نیازی به دیسک والد ندارد.

همین استقلال باعث می‌شود که برای راه‌اندازی سرورهای عملیاتی (Production)، محیط‌های تست، مهاجرت یا استقرار سرویس‌های جدید، Full Clone انتخابی مطمئن باشد. در این وضعیت، حتی اگر ماشین مبدأ خاموش یا به کل حذف شود، خللی در کارکرد دیسک ماشین کلون‌شده پیش نمی‌آید. با این وجود، استقلال دیسک به معنای آماده بودن تمام تنظیمات نرم‌افزاری نیست؛ مواردی مثل IP Address ،Hostname، شناسه‌های سیستم‌عامل، گواهی‌های امنیتی (Certificates)، سرویس‌های وابسته و لایسنس‌ها همچنان باید پس از کلون‌گیری بازبینی شوند.

لینکد کلون (Linked Clone) چیست؟

برخلاف مدل قبلی، در Linked Clone ماشین جدید اطلاعات پایه را از دیسک والد می‌خواند و فقط تغییرات اختصاصی خودش را روی دیسک‌های وابسته (Delta) می‌نویسد. از آنجا که در این معماری نیازی به کپی کردن دوبارۀ تمام داده‌های ماشین والد برای هر نمونه جدید نیست، مصرف فضای ذخیره‌سازی به شکل محسوسی پایین می‌آید و ساخت ماشین‌های جدید سریع‌تر پیش می‌رود.

اما روی دیگر سکه، وابستگی دائمی به ماشین والد است. اگر ساختار والد، Snapshot پایه یا زنجیرۀ دیسک با مشکلی روبه‌رو شود، کلون‌های وابسته هم تحت تأثیر قرار می‌گیرند. به همین علت، Linked Clone جایگزین مستقلی برای Full Clone به حساب نمی‌آید و صرفاً در معماری‌های خاصی به کار می‌رود. خوب است بدانید در محیط‌های دسکتاپ مجازی Horizon نیز فناوری Linked Clone مبتنی بر View Composer دیگر قدیمی شده است و طبق مستندات رسمی Omnissa، در نسخۀ Horizon 8 فناوری Instant Clone جای آن را گرفته است.

تفاوت کلون و Snapshot چیست؟

در مدیریت روزمرۀ سرورها، گاهی کلون با مفاهیمی مثل Snapshot ،Image یا Replication اشتباه گرفته می‌شود. برای ترسیم مرز دقیق بین این دو، کافی است به هدف آن‌ها نگاه کنیم: کلون یک ماشین یا دیسک جدید و قابل استفاده می‌سازد، در حالی که Snapshot فقط وضعیت فعلی ماشین را در یک لحظه زمانی خاص ثبت می‌کند تا اگر مشکلی پیش آمد، بتوان موقتاً به آن نقطه برگشت.

وقتی از ماشینی Snapshot می‌گیرید، تغییرات بعدی در فایل‌های Delta ذخیره می‌شوند؛ یعنی اسنپ‌شات به‌تنهایی یک کپی مستقل نیست و برای بازیابی اطلاعات کاملاً به دیسک‌های پایه تکیه دارد. در مقابل، Full Clone یک نمونۀ مجزا می‌سازد که پس از تکمیل، هیچ وابستگی به زنجیرۀ Snapshot والد نخواهد داشت.

ویژگی	کلون سرور (Full Clone)	Snapshot
هدف اصلی	ایجاد نمونۀ جدید و مجزا از ماشین یا دیسک	ثبت وضعیت ماشین در یک نقطۀ زمانی مشخص
میزان وابستگی	بدون وابستگی دیسکی به والد پس از تکمیل	وابسته به دیسک پایه و زنجیرۀ Snapshot
ساختار ذخیره‌سازی	ایجاد دیسک و داده‌های مستقل	ثبت تغییرات جدید در Delta Disk
کاربرد اصلی	استقرار سرویس، تست، مهاجرت و ساخت VM جدید	بازگشت سریع و موقت به وضعیت قبلی (Rollback)
تأثیر بر عملکرد	مستقل از زنجیرۀ Snapshot والد	افت احتمالی عملکرد در صورت نگهداری طولانی‌مدت و رشد Delta
هویت ماشین	قابلیت دریافت شناسه‌های شبکه‌ای و سیستمی جدید	حفظ هویت همان ماشین اصلی

شرکت Broadcom در راهنمای Best Practices خود صراحتاً هشدار می‌دهد که نباید به Snapshot به چشم Backup نگاه کرد. طبق توصیۀ این شرکت، برای حفظ کارایی سیستم بهتر است بیش از ۲ تا ۳ اسنپ‌شات در یک زنجیرۀ نسازید و هیچ اسنپ‌شاتی را بیش از ۷۲ ساعت نگه ندارید؛ چرا که رشد مداوم Delta Disk به مرور زمان هم فضای استوریج را می‌بلعد و هم عملکرد ماشین را کند می‌کند؛ بنابراین Snapshot صرفاً یک نقطۀ بازگشت کوتاه‌مدت است و برای داشتن یک سرور مستقل باید سراغ Clone رفت.

تفاوت کلون دیسک و پشتیبان‌گیری (Backup) چیست؟

همان‌طور که اسنپ‌شات جای کلون را نمی‌گیرد، پشتیبان‌گیری (Backup) هم مأموریت متفاوتی دارد. در عملیات Disk Clone، ساختار و محتوای یک دیسک عیناً روی دیسک یا مقصد دیگری کپی می‌شود. اگر اجزای حیاتی مثل Boot Loader، ساختار پارتیشن‌ها و فایل‌های سیستم‌عامل به‌درستی منتقل شوند و سخت‌افزار یا ماشین مجازی مقصد هم با آن‌ها سازگار باشد، دیسک کلون‌شده می‌تواند مستقیماً سیستم را بالا بیاورد.

اما Backup برای روز مبادا و بازیابی تاریخی طراحی شده است. در پشتیبان‌گیری، داده‌ها معمولاً در قالب فایل‌های پشتیبان یا ساختارهای آرشیوی ذخیره می‌شوند تا اگر اطلاعاتی به اشتباه پاک شد یا سیستم آسیب دید، بتوان به نسخه‌های قبلی در تاریخ‌های مختلف برگشت کلون فقط وضعیت فعلی را تکثیر می‌کند، در حالی که بکاپ تاریخچه‌ای از نسخه‌های مختلف داده را نگه می‌دارد. به همین خاطر، یک سازمان ممکن است برای مهاجرت سریع سرور از Clone کمک بگیرد، اما برای محافظت از داده‌ها در برابر حوادث، به سراغ Backup برود.

کاربردهای کلون در هاستینگ و شبکه چیست؟

در زیرساخت‌های هاستینگ، کلونینگ دست مدیران سیستم را برای ساختن ماشین‌هایی با پیکربندی مشابه باز می‌گذارد فرض کنید قرار است ده‌ها سرور با تنظیمات پایه یکسان راه‌اندازی شود؛ به جای اینکه هر بار سیستم‌عامل را از صفر نصب کنید، پارتیشن‌بندی انجام دهید و سرویس‌ها و سیاست‌های امنیتی را دستی ست کنید، یک ماشین پایۀ استاندارد می‌سازید و بقیۀ سرورها را از روی آن تکثیر می‌کنید.

در معماری‌های ابری و محیط‌هایی که تحویل ماشین مجازی (Provisioning) به‌شکل خودکار انجام می‌شود نیز کلون یا فناوری‌های مشابه آن، بخشی از خط تولید نمونه‌های جدید هستند. البته در زیرساخت‌های مدرن، کلون معمولاً تنها نیست و در کنار ابزارهایی مثل Template ،Image ،Orchestration و Automation به کار گرفته می‌شود.

سطح زیرساخت	مؤلفه ایجادشده	هدف عملیاتی
سیستم مبدأ	ماشین پایه یا Golden Image	نگهداری سیستم‌عامل، پکیج‌ها و تنظیمات استاندارد
محیط آزمایشی (Test)	کلون سرور تست	بررسی آپدیت‌ها، پچ‌ها و تغییرات پیش از اعمال روی محیط اصلی
محیط عملیاتی (Production)	ماشین مستقل بر اساس Clone یا Image	راه‌اندازی سریع سرویس جدید با پیکربندی استاندارد
زیرساخت ابری	Instanceهای جدید	افزایش ظرفیت یا ساخت محیط‌های مشابه (در صورت پشتیبانی پلتفرم)

نقش کلون در پیاده‌سازی VDI چیست؟

برای اینکه ببینیم کلونینگ چطور در دسکتاپ‌های مجازی به کار می‌آید، ابتدا باید بدانیم VDI چیست؟ و چرا سازمان‌ها سراغ آن می‌روند. در معماری VDI (یا Virtual Desktop Infrastructure)، به جای نصب و مدیریت جداگانه سیستم‌عامل برای تک‌تک کاربران، یک تصویر پایۀ استاندارد (Golden Image) آماده می‌شود و دسکتاپ‌های مجازی کاربران از روی آن ساخته می‌شوند.

در پلتفرم Horizon 8، فناوری Instant Clone بار اصلی ساخت Desktop Pool را به دوش می‌کشد. طبق مستندات رسمی Omnissa، این فناوری با تکیه بر قابلیت vmFork و Instant Clone API در vCenter Server، علاوه بر اشتراک‌گذاری دیسک، در مرحلۀ اولیه ساخت، بخشی از حافظۀ (Memory) ماشین والد را هم به اشتراک می‌گذارد؛ معماری هوشمندانه‌ای که هم مصرف استوریج را به حداقل می‌رساند و هم سرعت Provisioning را به شکل چشمگیری بالا می‌برد.

Instant Clone چیست؟

Instant Clone روشی مدرن برای تکثیر سریع ماشین‌های مجازی از روی یک Golden Image بر پایۀ فناوری vmFork است. در Horizon 8، این روش برای ساخت خودکار Desktop Pool به کار می‌رود و در اغلب سناریوها جایگزین Linked Clone مبتنی بر View Composer شده است. در جریان این فرایند، Horizon از ساختارهای میانی خودش مثل Internal Template ،Replica VM و Parent VM بهره می‌گیرد تا دسکتاپ‌های جدید در کمترین زمان آماده شوند

Linked Clone در VDI چه جایگاهی دارد؟

در نسل‌های قبلی VDI، روش Linked Clone وظیفۀ تکثیر دسکتاپ‌ها را با حفظ وابستگی به دیسک پایه بر عهده داشت و در محیط Horizon به سرویس View Composer متکی بود. اما با معرفی Instant Clone برای Desktop Poolهای پایدار و غیرپایدار در Horizon 8، مدل Linked Clone عملاً به یک معماری قدیمی تبدیل شده است.

آماده‌سازی لینوکس پیش از کلون چیست؟

کلون گرفتن از سرورهای لینوکسی بدون آماده‌سازی سیستم‌عامل، معمولاً دردسرساز می‌شود؛ چرا که شناسه‌های اختصاصی ماشین مبدأ عیناً به ماشین جدید منتقل می‌شوند و هویت شبکه را به هم می‌ریزند.

مهم‌ترین بخش در این زمینه، فایل /etc/machine-id است. مستندات Broadcom دربارۀ کلون کردن Ubuntu نشان می‌دهد که اگر machine-id در ماشین‌های کلون‌شده یکسان بماند، ممکن است در برخی سناریوهای DHCP همه ماشین‌ها رفتار یکسانی در معرفی خود به شبکه نشان دهند و IP تکراری بگیرند. در RHEL 9 نیز Broadcom توصیه می‌کند پیش از تبدیل ماشین به Template یا گرفتن Clone، از وجود ابزارهایی مثل D-Bus مطمئن شوید و فایل /etc/machine-id را طوری آماده کنید که در زمان استقرار، شناسه جدیدی تولید کند. در محیط‌های Horizon هم مستندات Omnissa آماده‌سازی جداگانه سیستم‌عامل، وضعیت دیسک و تنظیمات ماشین پایه را پیش از ساخت Instant Clone از روی Golden Image لینوکس الزامی می‌دانند.

به‌طور خلاصه، پیش از کلون کردن یک ماشین مجازی لینوکس، باید تکلیف این موارد را مشخص کنید:

• شناسه سیستم: بررسی و ریست کردن /etc/machine-id برای تولید شناسۀ یکتا در ماشین جدید.
• هویت شبکه: بازبینی تنظیمات شبکه و تغییر Hostname.
• دسترسی‌ها و سرویس‌ها: بررسی کلیدهای SSH، سرویس‌های وابسته و هر اطلاعاتی که باید در سرور جدید منحصربه‌فرد باشد.

وضعیت لایسنس‌های وابسته به IP بعد از کلون

یکی از چالش‌هایی که گاهی تا لحظۀ روشن شدن سرور جدید پنهان می‌ماند، وضعیت لایسنس (License) نرم‌افزارهاست. بسیاری از برنامه‌های سازمانی، پایگاه‌های داده و محصولات امنیتی، لایسنس خود را به مشخصات هویتی سرور مثل IP Address ،MAC Address ،Hostname ،UUID یا Machine ID گره می‌زنند.

وقتی از چنین سروری کلون می‌گیرید و هویت ماشین جدید تغییر می‌کند، نرم‌افزار مقصد ممکن است لایسنس را نامعتبر تشخیص دهد، اعتبارسنجی مجدد بخواهد یا نیاز به ثبت دوباره داشته باشد. از آنجا که سیاست لایسنس‌دهی هر شرکت متفاوت است، پیش از کلون کردن سرورهای شامل نرم‌افزارهای تجاری، حتماً مستندات سازنده را بررسی کنید تا هنگام روشن کردن ماشین جدید غافلگیر نشوید.

تفاوت کلون با Template و Replication چیست؟

در ادبیات مجازی‌سازی، گاهی نام Clone ،Template و Replication در کنار هم یا به‌جای هم برده می‌شود، اما هرکدام کارکرد مشخصی دارند:

• Clone (کلون): یک نمونه جدید از ماشین یا دیسک فعلی می‌سازد که بسته به روش انتخابی، می‌تواند مستقل یا وابسته به والد باشد.
• Template (قالب): یک الگوی پایه (حاوی Golden Image و تنظیمات استاندارد) برای استقرار ماشین‌های جدید است هدف از Template داشتن یک منبع استاندارد برای Provisioning است، نه اینکه خودش مثل یک ماشین عادی سرویس عملیاتی ارائه دهد.
• Replication (همگام‌سازی): فرایند انتقال و همگام‌سازی تغییرات میان مبدأ و مقصد است مثلاً در vSphere Replication، پس از همگام‌سازی اولیه، تغییرات دیسک ماشین به‌صورت دوره‌ای و بر اساس شاخص RPO به مقصد منتقل می‌شوند تا در مواقع بحران (Disaster Recovery) از سرویس محافظت شود.

ویژگی	Clone	Template	Replication
هدف اصلی	ایجاد نمونۀ جدید	ایجاد الگوی استقرار	حفظ نسخه‌ای همگام از ماشین در مقصد
نوع عملیات	تکثیر در زمان مشخص	الگوی پایه	انتقال مداوم یا دوره‌ای تغییرات
خروجی	ماشین یا دیسک کلون‌شده	Image/Template برای استقرار	Replica در سایت یا زیرساخت مقصد
استفاده رایج	تست، مهاجرت و ایجاد VM جدید	Provisioning استاندارد	Disaster Recovery و حفاظت از سرویس
وابستگی زمانی	بیشتر نقطه‌ای	مبتنی بر Image پایه	استمرار همگام‌سازی بر اساس RPO

به بیان ساده، Clone «یک نمونۀ تازه می‌سازد»، Template می‌گوید «از روی این الگوی استاندارد ماشین‌های بعدی را بساز» و Replication «تغییرات ماشین اصلی را در مقصد به‌روز نگه می‌دارد».

مزایا و معایب کلون سرور چیست؟

استفاده از کلون سرور روند استقرار سیستم‌های مشابه را بسیار سریع‌تر می‌کند، اما مانند هر فناوری زیرساختی، در کنار مزایا، محدودیت‌هایی هم دارد که به ترتیب عبارت‌اند از:

مزایای کلونینگ

• سرعت در راه‌اندازی: وقتی یک ماشین از قبل نصب و پیکربندی شده باشد، ساختن نمونه‌های مشابه دیگر نیازی به تکرار مراحل زمان‌بر نصب ندارد.
• استانداردسازی زیرساخت: تکیه بر یک ماشین پایۀ مطمئن، باعث می‌شود تنظیمات سیستم‌عامل، پکیج‌ها و سیاست‌های اولیه در تمام سرورهای جدید یکدست باقی بمانند.
• کاهش خطای انسانی: حذف عملیات دستی و تکراری، احتمال بروز تفاوت‌های ناخواسته میان سرورهای مشابه را به حداقل می‌رساند.
• تسهیل تست و توسعه: تیم‌های فنی می‌توانند پیش از اعمال تغییرات زیرساختی یا آپدیت نرم‌افزار روی محیط اصلی، همه‌چیز را روی نسخه‌ای مشابه آزمایش کنند.
• کارایی در مهاجرت: در سناریوهایی که به یک ماشین مستقل در مقصد نیاز است، Full Clone راه‌حل بسیار خوبی است.

چالش‌ها و معایب

• مصرف فضای ذخیره‌سازی: ساخت دیسک مستقل در روش Full Clone، به فضای خالی از جنس همان داده‌های کپی‌شده نیاز دارد.
• احتمال تداخل هویتی: اگر مشخصاتی مثل Hostname ،IP ،MAC یا Machine ID اصلاح نشوند، ماشین جدید در شبکه یا سرویس‌ها با ماشین مبدأ تداخل پیدا می‌کند.
• مسائل لایسنس: نرم‌افزارهای وابسته به هویت ماشین یا شبکه، ممکن است پس از کلون نیاز به فعال‌سازی یا ثبت دوباره داشته باشند.
• نیاز به برنامه‌ریزی منابع: هر ماشین کلون‌شده سهم جداگانه‌ای از CPU ،RAM ،Storage و شبکه می‌طلبد؛ بنابراین پیش از تکثیر سرورها باید ظرفیت واقعی زیرساخت سنجیده شود.

مراحل ساخت کلون در VMware vSphere 8.0 چیست؟

از آنجا که جزئیات اجرایی در هر پلتفرم متفاوت است، مراحل زیر را مشخصاً بر اساس محیط VMware vSphere 8.0 و vCenter Server 8.0 (از طریق رابط vSphere Client) مرور می‌کنیم:

1. آماده‌سازی ماشین مجازی مبدأ: پیش از شروع، وضعیت دیسک‌ها، اسنپ‌شات‌ها، شبکه، منابع CPU و RAM و وابستگی‌های نرم‌افزاری را بررسی کنید. اگر سیستم‌عامل ویندوز است، Broadcom توصیه می‌کند برای جلوگیری از تکرار شناسه امنیتی (SID)، ماشین مبدأ را با Sysprep به حالت Generalize ببرید یا از قابلیت Guest Customization استفاده کنید. در لینوکس هم حتماً /etc/machine-id ،Hostname و تنظیمات شبکه را چک کنید.
2. انتخاب ماشین مجازی مبدأ: در محیط vSphere Client، روی ماشین مجازی مبدأ (ماشینی که می‌خواهید از وضعیت فعلی‌اش نمونه جدیدی بسازید) راست‌کلیک کرده و طبق مستندات Broadcom مسیر Clone > Clone to Virtual Machine را انتخاب کنید.
3. تعیین نام و محل ماشین جدید: در پنجرۀ Clone Wizard، نام ماشین جدید و محل قرارگیری آن را در Inventory مشخص کنید. انتخاب یک نام دقیق و متمایز کمک می‌کند در مدیریت روزمره، ماشین جدید را به‌راحتی از ماشین مبدأ تشخیص دهید.
4. انتخاب Compute Resource: میزبان (Host) یا کلاستری را که قرار است ماشین جدید روی آن اجرا شود برگزینید و سازگاری پردازنده، شبکه و Storage آن را با ماشین جدید بسنجید.
5. انتخاب Datastore: دیتاستور مقصد را با توجه به فضای خالی موردنیاز دیسک‌ها انتخاب کنید. در vSphere Client این امکان هم وجود دارد که برای VMهای بزرگ، دیسک‌های مختلف یک ماشین را روی Storageهای متفاوتی توزیع کنید.
6. سفارشی‌سازی سخت‌افزار و شبکه: در صورت نیاز، CPU ،RAM، کارت شبکه (Network Adapter) و سایر مشخصات سخت‌افزاری را اصلاح کنید. در برخی سناریوها، برداشتن تیک گزینۀ Connect At Power On ایدۀ خوبی است تا ماشین جدید پیش از بررسی نهایی تنظیمات، وارد شبکه عملیاتی نشود و تداخلی ایجاد نکند.
7. سفارشی‌سازی سیستم‌عامل: برای تغییر خودکار اطلاعاتی مثل Hostname، IP Address و هویت سیستم‌عامل، از بخش Guest OS Customization کمک بگیرید؛ مرحله‌ای که به‌ویژه در ویندوز مانع از تکرار SID می‌شود.
8. بررسی تنظیمات و اجرای عملیات: پس از مرور نهایی تنظیمات، عملیات Clone را اجرا کنید. مدت‌زمان این فرایند عدد ثابتی ندارد و مستقیماً به حجم داده، سرعت Storage و شرایط I/O زیرساخت بستگی دارد.
9. بررسی ماشین کلون‌شده: پس از پایان کپی، سرور جدید را روشن کنید و پیش از تحویل به محیط عملیاتی، وضعیت Boot، شبکه، Hostname ،IP، سرویس‌ها، لایسنس‌ها و برنامه‌های نصب‌شده را به دقت تست کنید.

تفاوت کلون در حالت روشن و خاموش چیست؟

در محیط vSphere می‌توان از ماشین روشن هم کلون گرفت که در برخی سناریوها با ایجاد یک Snapshot موقت همراه می‌شود و طبیعی است که محدودیت‌های زنجیره اسنپ‌شات روی آن اثر بگذارد. با این حال، برای بارهای کاری حساس مانند پایگاه‌های داده (Databases)، بحث اصلی فقط روشن یا خاموش بودن ماشین نیست، بلکه حفظ یکپارچگی داده‌ها (Consistency) مطرح است. از آنجا که Broadcom اسنپ‌شات ماشین مجازی را جایگزین Backup آگاه از دیتابیس نمی‌داند، تصمیم‌گیری دربارۀ کلون گرفتن در حالت روشن یا خاموش باید با توجه به نوع برنامه، حساسیت داده و سطح Consistency موردنیاز انجام شود.

تفاوت کلون با معماری RAID چیست؟

برای درک مرز میان کلون و معماری RAID، ابتدا باید به یاد بیاوریم RAID چیست. معماری RAID راهکاری برای ترکیب چند دیسک در سطح Storage است تا افزونگی (Redundancy)، دسترس‌پذیری یا سرعت دیسک بهبود یابد.

مثلاً در RAID 1، داده‌ها به‌شکل آینه‌ای روی دو دیسک نوشته می‌شوند تا اگر یکی از دیسک‌ها سوخت، سرور از کار نیفتد. اما RAID نسخۀ مستقلی در برابر تغییرات ناخواسته ایجاد نمی‌کند؛ اگر فایلی به اشتباه حذف یا خراب شود، همان تغییر بلافاصله روی دیسک آینه هم اعمال می‌شود. بنابراین RAID ،Backup و Clone سه مفهوم مجزا هستند: RAID روی افزونگی لحظه‌ای استوریج تمرکز دارد، در حالی که Clone یک نمونۀ مستقل در یک نقطۀ زمانی مشخص می‌سازد و هیچ‌یک نیاز به دیگری را از بین نمی‌برد.

چه خطاهایی در فرایند کلون کردن رخ می‌دهد؟

بی‌توجهی به پیش‌نیازهای فنی هنگام کلون‌گیری، معمولاً به یکی از خطاهای عملیاتی زیر منجر می‌شود:

• تداخل IP: وارد شدن ماشین جدید به شبکه با همان IP استاتیک ماشین مبدأ، یا دریافت IP یکسان از DHCP به خاطر تغییر نکردن شناسه‌هایی مثل Machine ID.
• تکرار Hostname: بروز ابهام در شبکه و سامانه‌های مدیریتی به دلیل یکسان ماندن نام سرور.
• تکرار SID در ویندوز: ایجاد Computer SID تکراری در اثر کلون کردن ویندوز بدون Generalize یا Customization مناسب.
• تکرار Machine ID در لینوکس: اختلال در شناسایی ماشین کلون‌شده در برخی توزیع‌ها به دلیل باقی ماندن /etc/machine-id.
• قفل بودن یا پیچیدگی زنجیره Snapshot: اختلال در عملیات کلون (به‌ویژه در ماشین روشن) به دلیل وجود اسنپ‌شات‌های متعدد یا شرایط خاص دیسک.
• کمبود فضای Storage: ناتمام ماندن Full Clone به علت نبود ظرفیت کافی در Datastore مقصد.
• مشکل لایسنس: از کار افتادن یا نیاز به اعتبارسنجی مجدد نرم‌افزارها پس از تغییر IP ،Hostname یا UUID.

کاربرد کلون در تست، توسعه و سرورهای سازمانی

در تیم‌های DevOps، کلون ابزاری کاربردی برای ساختن محیط آزمایشی (Test Environment) مشابه محیط اصلی (Production) است. تیم توسعه می‌تواند نسخۀ جدید نرم‌افزار، پچ‌ها یا تغییرات کانفیگ را ابتدا روی ماشین کلون‌شده بیازماید تا خطای ناشی از تفاوت دو محیط به حداقل برسد. البته کلون به‌تنهایی یکسان ماندن دو محیط را تضمین نمی‌کند و پس از کلون‌گیری ممکن است نسخه‌های نرم‌افزار، داده‌ها، Secrets، متغیرهای محیطی یا سرویس‌های خارجی تفاوت داشته باشند. به همین دلیل، کلون زمانی بیشترین ارزش را دارد که در کنار مدیریت Configuration و فرایند استاندارد Deployment به کار رود.

در محیط‌های سازمانی هم زمانی که برای یک پروژه جدید به سروری مستقل با همان تنظیمات سرور قبلی (شامل سیستم‌عامل، وب‌سرور و ابزارهای مدیریتی) نیاز باشد، Full Clone بار مراحل تکراری نصب را از دوش تیم فنی برمی‌دارد؛ تنها کافی است پس از ساخت سرور، مواردی که نباید بین دو ماشین مشترک بمانند (مثل IP ،Hostname، لایسنس و Certificateها) اصلاح شوند.

چرا Full Clone با Snapshot تفاوت عملکردی دارد؟

گاهی گفته می‌شود که کلون «بدون افت کارایی» عمل می‌کند، اما این عبارت باید دقیق‌تر به کار برده شود؛ به این دلیل که که عملکرد نهایی هر ماشینی به منابع CPU ،RAM، سرعت Storage و شرایط I/O مقصد گره خورده است.

تفاوت عملکردی اصلی در این نکته نهفته است که در Full Clone، پس از پایان عملیات کپی، ماشین جدید دیگر به زنجیرۀ Snapshot دیسک والد وابسته نیست و برای دسترسی به وضعیت جاری نیازی به خواندن زنجیره Delta Disk ندارد. در نقطۀ مقابل، همان‌طور که Broadcom هشدار می‌دهد، نگهداری طولانی‌مدت اسنپ‌شات‌ها (بیش از ۲ تا ۳ عدد یا طولانی‌تر از ۷۲ ساعت) با بزرگ کردن Delta Disk مستقیماً روی فضای ذخیره‌سازی و سرعت سیستم اثر منفی می‌گذارد؛ بنابراین منظور از عدم افت کارایی در Full Clone، صرفاً رهایی از سربار زنجیره Snapshot والد است، نه تضمین سرعت یکسان روی هر نوع استوریج و بار کاری.

کلام آخر

درک مرز دقیق میان Clone ،Snapshot ،Template ،Backup و Replication به مدیران زیرساخت کمک می‌کند برای هر نیازی سراغ ابزار درست بروند. هر جا هدفْ ساختن یک سرور کاملاً مستقل باشد، Full Clone به کار می‌آید؛ Linked Clone روشی وابسته به دیسک والد است و در محیط‌های دسکتاپ مجازی Horizon 8 نیز فناوری Instant Clone جایگزین مدل قدیمی View Composer Linked Clone شده است.

فراموش نکنید که کلون‌گیری صرفاً یک عملیات کپی نیست و خروجی پایدار و بی‌نقص زمانی حاصل می‌شود که پیش و پس از کلون، آماده‌سازی سیستم‌عامل (بررسی SID در ویندوز و Machine ID در لینوکس)، ظرفیت Storage، تنظیمات شبکه، لایسنس نرم‌افزارها و منابع سخت‌افزاری متناسب با معماری سرور به دقت مدیریت شوند.

سوالات متداول

آیا کلون باعث تداخل آدرس آی‌پی می‌شود؟

فرایند ساخت کلون چقدر زمان می‌برد؟

آیا برای کلون گرفتن باید سرور خاموش شود؟

آیا بعد از کلون باید لایسنس نرم‌افزار را دوباره فعال کرد؟

آیا Clone همان Template است؟

آیا Clone با Replication تفاوت دارد؟