آزمایشگاههای خانگی معمولاً چرخه عمر پیشبینیپذیری دارند. من عاشق نجاتدادن سرورهای بزرگ و بهرهبردن از هستهها و حافظه بیشترشان هستم؛ تا اینکه یادم میآید دفعه پیش چرا تجهیزاتم را کوچکتر کردم. مجموعهای از فنهای ۱۵ هزار دور در دقیقه در اتاقخوابم، حاصلی جز گرمای بیشتر، سروصدای آزاردهنده و قبض برق سرسامآور ندارد.
میخواهم در جهت مخالف حرکت کنم و هرجا شد از سختافزارهای کوچکتر و کمصداتر بهره ببرم. به همین دلیل، یک مینیپیسی Zotac ZBOX مجهز به Celeron N3160 و ۸ گیگابایت رم، گزینهای ایدئال برای آزمایش بود. این بار بهجای آنکه بیدرنگ دوباره Proxmox را نصب کنم، هایپروایزر کمترشناختهشدهای به نام XCP-ng را آزمودم. عملکردش بسیار بهتر از انتظارم بود؛ اما دو رابط مدیریتی آن دقیقاً نشان دادند که این هایپروایزر در چه نوع آزمایشگاه خانگیای معنا پیدا میکند.
کوچکسازی را تا رسیدن به یک سلرون ادامه دادم
گریز من از سرورهای غران با سختافزاری آغاز شد که بهزحمت حداقلهای پیشنهادی را داشت
بیایید صادق باشیم؛ Zotac ZBOX CI325 Nano بیشتر شبیه دستگاهی است که باید پشت تلویزیون پنهان شود، نه سامانهای برای میزبانی از یک هایپروایزر سازمانی. مشخصاتش هم کمکی به تغییر این برداشت نمیکرد:
- پردازنده Celeron N3160 با چهار هسته کممصرف
- ۸ گیگابایت حافظه DDR3L
- درایو SSD با ظرفیت ۱۲۰ گیگابایت
- دو درگاه شبکه اترنت گیگابیتی
- آداپتور وایفای و بلوتوث
XCP-ng دستکم ۷۰ گیگابایت فضای ذخیرهسازی و ۸ گیگابایت رم را پیشنهاد میکند؛ بنابراین مینیپیسی Zotac دقیقاً در مرز این پیشنیازها قرار داشت و چیزی اضافه برایش باقی نمیماند.
برای آمادهسازی نصب، قابلیت مجازیسازی Intel را فعال و Secure Boot را غیرفعال کردم. مطابق دستورالعمل XCP-ng، میانافزار BIOS را در حالت UEFI نگه داشتم. با استفاده از Rufus و فایل ISO مربوط به XCP-ng یک حافظه USB راهانداز ساختم؛ اما وقتی نصبکننده نزدیک به پنج دقیقه صفحهای خالی نشان داد، کار گره خورد. داشتم خودم را برای بازگشت به حالت راهاندازی قدیمی آماده میکردم که سرانجام صفحه آغازین نصبکننده پدیدار شد.
پس Zotac ناسازگار نبود؛ فقط این کار کمی فراتر از توان معمولش بود.
از آنجا به بعد، از رسانه نصب محلی استفاده کردم، تخصیص پویای مبتنی بر فایل EXT را برگزیدم و رابط متصل eth1 را از راه DHCP پیکربندی کردم. نصبکننده تنظیم سرورهای زمان و منطقه زمانی را نیز بیهیچ دردسری انجام داد.
نخستین راهاندازی دوباره پس از اجرای yum update اولین دردسر واقعی را آشکار کرد. XCP-ng بدون نشانی مدیریتی بالا آمد و در نتیجه رابط وب آن در دسترس نبود. با واداشتن آداپتور به تمدید اجاره شبکه، نشانی 192.168.1.191 بیدرنگ بازگشت و از آن زمان تاکنون این مشکل دوباره رخ نداده است.
اندکی بعد، کنسول میزبان از نصب سالم و بینقص خبر میداد. برخلاف VMware ESXi، این جعبه کوچک و بیفن فرایند نصب را بدون حتی یک مشکل سازگاری پشت سر گذاشت.
اکساو لایت تقریباً بیدرنگ میزبان را آماده استفاده کرد
پیشخوان سبک آن آنقدر سنجیده بود که به مدیر جداگانهای نیاز نداشت
Xen Orchestra (XO) Lite مستقیماً از نشانی https://192.168.1.191 بارگذاری شد و برای ورود از مشخصات کاربر ریشهای که هنگام نصب ساخته بودم استفاده کردم. بنابراین، فقط برای اطمینان از کارکرد هایپروایزر نیازی به راهاندازی یک سرور مدیریتی جداگانه نداشتم.
پیشخوان آن تأیید کرد که هر چهار هسته پردازنده، ۸ گیگابایت رم و دو آداپتور اترنت گیگابیتی پشتیبانی و بهدرستی شناسایی شدهاند. این سامانه ۲ گیگابایت رم را به دامنه کنترلی XCP-ng اختصاص داد و ۶ گیگابایت چشمگیر را برای ماشینهای مهمان باقی گذاشت. البته واژه کلیدی اینجا «اختصاص داد» است؛ زیرا تمام این حافظه را برای میزبان کنار میگذاشت، نه اینکه تکتک بایتهایش را مصرف کند.
XO Lite با رابط ساده و مرورگرمحور خود برای مدیریت هایپروایزر، واقعاً پخته و پرداختشده به نظر میرسید. صفحهها سریع باز میشدند، چیدمان تمیز بود و حتی پردازنده Celeron نیز بدون کندی از پس آن برمیآمد. بااینحال، چند ایراد وجود داشت. روند افزودن یک ماشین مجازی تازه چندان روشن و سرراست نبود و دکمه کلیپبورد کنسول نیز تنها وعده میداد: «بهزودی».
بزرگترین نقطهضعف در مقایسه با Proxmox و ESXi زمانی نمایان شد که خواستم یک ماشین مجازی را از روی فایل ISO راهاندازی کنم. XCP-ng تصویرهای نصب را مخزن ذخیرهسازی جداگانهای برای فایلهای ISO در نظر میگیرد، نه فایلهایی که بتوان بهسادگی از راه مرورگر بارگذاری کرد. ازآنجاکه پردازنده Celeron از پس رمزنگاری SCP برنمیآمد، فایل ISO را روی یک حافظه USB ریختم و آن را بهصورت فقطخواندنی سوار کردم:
mkdir -p /mnt/usb-isomount -o ro /dev/sdc1 /mnt/usb-isoسپس محل اتصال را با xe بهعنوان مخزن ISO ثبت کردم:
xe sr-create name-label="USB ISO Library" type=iso content-type=iso device-config:location=/mnt/usb-iso device-config:legacy_mode=trueاین روش بینقص کار کرد، اما در عین حال برخی محدودیتهای استفاده از یک رابط سبک برای مدیریت هایپروایزر را نیز آشکار ساخت.
ماشین مجازی بهطرز شگفتآوری روان بود
دو هسته پردازنده و ۲ گیبیبایت رم، این آزمایش را به یک دسکتاپ کاربردی تبدیل کردند
با استفاده از الگوی ۶۴ بیتی اوبونتو در XCP-ng، یک ماشین مجازی لینوکس لوبونتو ساختم. میانافزار BIOS، دو پردازنده مجازی، ۲ گیگابایت رم و یک دیسک ۲۰ گیگابایتی با تخصیص تنک را برگزیدم. لوبونتو از مخزن ISO مستقر روی حافظه USB، سریع و بیدردسر نصب شد. مهمتر اینکه محیط دسکتاپ آن بهطرز شگفتآوری روان باقی ماند؛ آن هم روی پردازندهای که همزمان بار این ماشین مجازی و یک هایپروایزر مستقیم روی سختافزار را به دوش میکشید.
درون سیستم مهمان، عامل مدیریتی XCP-ng و OpenSSH را نصب کردم:
sudo apt update sudo apt install xe-guest-utilities openssh-server با فرمان زیر مطمئن شدم که عامل در حال اجراست:
systemctl status xe-daemon --no-pager پس از آن، محیط دسکتاپ بهطور محسوسی سریعتر به نظر میرسید؛ هرچند نمیتوانم با اطمینان بگویم این بهبود تنها حاصل ابزارهای سیستم مهمان بود. لینوکس درایورهای اصلی شبکه و ذخیرهسازی Xen را نیز از پیش در خود دارد، بنابراین انتظار میرفت شبکه از همان ابتدا کار کند.
نصب OpenSSH ضروری بود، زیرا کنسول XO Lite هنوز از قابلیت کلیپبورد پشتیبانی نمیکند. کادر متن و دکمه مربوط به آن وجود دارند، اما با تلاش برای استفاده از آنها، پیامی نمایش داده میشود که میگوید این قابلیت بهزودی ارائه خواهد شد.
روند مدیریت بینقص نبود و در برخی بخشها دشواریهایی داشت، اما در مجموع هایپروایزر زیربنایی آن بهاندازهای کارآمد و پایدار بود که بتوان روی میزبانی با ۸ گیگابایت رم، یک ماشین مجازی راهاندازی کرد.
نسخه کامل زن ارکسترا نشان داد XCP-ng واقعاً برای چه ساخته شده است
البته نیمی از رم کل سرورم را هم بلعید
XO Lite برای ساخت و اداره یک ماشین مجازی کافی بود، اما هرگز قرار نبود نماینده تمام تجربه XCP-ng باشد. این پلتفرم بهگونهای طراحی شده است که در کنار Xen Orchestra، مدیریت متمرکز میزبانها، پایش و پشتیبانگیری را فراهم کند. Xen Orchestra تنها با فشردن یک دکمه از طریق XO Lite قابل راهاندازی بود؛ بنابراین ماشین مجازی لوبونتو را خاموش کردم و آن را به همین روش نصب کردم.
مرورگر هشدار داد که تا پایان راهاندازی، صفحه را بازآوری نکنم و زبانه را نبندم. تا اینجا همهچیز خوب بود، اما پس از گذشت یک ساعت دیگر مطمئن شده بودم که نصب متوقف شده است. پیشرفت کار را مستقیماً از طریق SSH بررسی کردم:
xe task-list params=name-label,status,progress میزان پیشرفت را ۸۶٫۹ درصد گزارش کرد. باز هم آشکار بود که پردازنده بیچاره سلرون با تمام توان مشغول کار است.
وقتی XOA سرانجام راه افتاد، ناچار شدم با اطلاعات ورود کاربر ریشه میزبان، بهصورت دستی دوباره به 192.168.1.191 متصل شوم. این رابط بود که ظرفیت واقعی XCP-ng را آشکار کرد؛ اتصالهای سرور، خوشهها، پایش، نسخههای پشتیبان، تاریخچه وظایف و مدیریت زیرساخت را همگی در یکجا گرد آورده بود.
متأسفانه این پرداختگی روی چنین سختافزاری بهای سنگینی داشت. XCP-ng دو گیگابایت، XOA چهار گیگابایت و لوبونتو نیز دو گیگابایت باقیمانده رم را به خود اختصاص داده بودند. اکنون میزان تخصیص رم دقیقاً به ۱۰۰ درصد رسیده بود، اما با وجود این، پس از راهاندازی لوبونتو محیط دسکتاپ آن همچنان روان کار میکرد.
از ترس فشاری که ممکن بود به مینیپیسی Zotan وارد شود، خیلی زود یک اسنپشات از ماشین مجازی روی دیسک ساختم تا این قابلیت را بیازمایم. ظاهر دسکتاپ لوبونتو را تغییر دادم و یک فایل نشانگر ساده افزودم:
echo "Created after the XOA snapshot" > ~/Desktop/AFTER-SNAPSHOT.txt پس از خاموش کردن ماشین مجازی، آن را به اسنپشات بازگرداندم و دوباره راهاندازی کردم. تصویر زمینه قدیمی برگشته و فایل نشانگر ناپدید شده بود. این موضوع را با فرمان زیر بررسی کردم:
test -e ~/Desktop/AFTER-SNAPSHOT.txt && echo "File survived" || echo "Rollback removed the test file" که نتیجه زیر را برگرداند:
Rollback removed the test file
XOA برای این مینیپیسی بهطرز خندهداری سنگین و بزرگ بود، اما بهخوبی نشان داد که XCP-ng با در اختیار داشتن توان پردازشی بیشتر، چرا به هایپروایزری قدرتمند برای آزمایشگاه خانگی تبدیل میشود.
اسنپشات تنها بهعنوان نقطهای کوتاهمدت برای بازگردانی در نظر گرفته میشود، نه نسخه پشتیبان. این تصویر همچنان به فضای ذخیرهسازی اصلی ماشین مجازی وابسته است و با انباشته شدن بلوکهای تغییریافته بزرگتر میشود. نگهداشتن نامحدود یک اسنپشات، بهمرور زمان فضای ذخیرهسازی و منابع چشمگیری مصرف خواهد کرد.
XCP-ng جای پروکسماکس را نگرفت، اما ویامور را کنار زد
با مدیریت بیش از یک میزبان، معادله انتخاب تغییر میکند
به نظر من، XCP-ng برای یک سرور کوچک آزمایشگاه خانگی نتوانست جای Proxmox را بگیرد. Proxmox رابط مدیریتی خود را روی همان میزبان نگه میدارد، میتوان فایلهای ISO را بهآسانی در آن بارگذاری کرد و بدون نیاز به راهاندازی یک سامانه مجزای ۴ گیگابایتی، همه امکانات مورد نیازم را در اختیارم میگذارد. پایه Debian آن نیز از سختافزارهای قدیمی بسیار بیشتری پشتیبانی میکند.
XCP-ng از من میخواست مجموعهای متفاوت از کاستیها را بپذیرم. XO Lite هنوز کامل نشده است و راهاندازی XOA هم زمان بسیار زیادی میبرد و نیمی از حافظهٔ رم این دستگاه را میبلعد. وقتی از مجموعهسرورها استفاده نمیکنم، جدا کردن هایپروایزر از رابط مدیریتیاش واقعاً زیادهروی به نظر میرسد.
از دید من، این الگو بیش از رویکرد یکپارچهٔ Proxmox به ESXi و vCenter شرکت VMware شباهت دارد. تفاوت در این است که XCP-ng همان سبک معماری را در اختیارم گذاشت، بیآنکه مرا به بازگشتن به VMware وسوسه کند.
برای یک سرور مستقل و جمعوجور، همچنان Proxmox را نصب میکنم؛ اما برای آزمایشگاه خانگی بزرگتر یا چندمیزبانه، پیش از ESXi/vCenter بیتردید XCP-ng را جدی بررسی خواهم کرد. XCP-ng با واداشتن این سرور کوچک به انجام کارهای بیشتر دلم را نبرد؛ فقط نشانم داد که اگر فرصتی برای ساختن هایپروایزرهایم از پایه داشتم، واقعاً چه میخواستم.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Gregory Gibson است. مشاهده مقاله اصلی