ورود به پنل کاربری
SERVER VIRTUALIZATION

راه‌اندازی سرور
مجازی‌سازی

چند سرویس سازمانی، یک زیرساخت قابل مدیریت. مجازی‌سازی می‌تواند استفاده از منابع و توسعهٔ سرویس‌ها را ساده‌تر کند؛ به شرط اینکه ظرفیت، امنیت و بازیابی از ابتدا طراحی شوند، نه اینکه فقط چند ماشین مجازی ساخته شود.

نمودار مفهومی سه ماشین مجازی روی یک میزبان و نسخهٔ پشتیبان مستقل

نمودار مفهومی آموزشی؛ بکاپ مستقل است و یک میزبان به‌تنهایی افزونگی ایجاد نمی‌کند.

سرور مجازی‌سازی چیست؟

در مجازی‌سازی سرور، یک بستر مدیریتی به نام Hypervisor منابع میزبان فیزیکی را در اختیار چند ماشین مجازی قرار می‌دهد. هر ماشین، سیستم‌عامل و سرویس‌های خود را دارد و منابعی مانند پردازنده، حافظه، دیسک و کارت شبکهٔ مجازی برای آن تعریف می‌شود.

منظور این راهنما، طراحی و راه‌اندازی بستر مجازی‌سازی داخل زیرساخت سازمان است؛ نه صرفاً خرید یک VPS از شرکت میزبان. نتیجهٔ مطلوب، سرویس‌هایی با ظرفیت مشخص، مدیریت قابل پیگیری و برنامهٔ بازیابی آزمون‌پذیر است.

۱

شناخت سرویس‌ها

ثبت وابستگی‌ها، مصرف منابع و میزان توقف قابل قبول.

۲

طراحی زیرساخت

انتخاب میزبان، ذخیره‌سازی، شبکه، بستر و بکاپ.

۳

اجرای آزمایشی

ارزیابی یک سرویس با بار واقعی و آزمون بازیابی.

۴

مهاجرت و تحویل

انتقال مرحله‌ای، پایش عملکرد و ثبت مستندات.

چه زمانی راه‌اندازی سرور مجازی‌سازی کاربرد دارد؟

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

  • تفکیک سرویس‌ها: فایل‌سرور و نرم‌افزار سازمانی می‌توانند در ماشین‌های مجزا با منابع و مجوزهای مشخص اجرا شوند.
  • توسعهٔ قابل برنامه‌ریزی: افزودن سرویس جدید بر اساس ظرفیت باقی‌مانده انجام می‌شود، نه با فرض نامحدودبودن میزبان.
  • محیط آزمایشی: تغییرات نرم‌افزاری پیش از اعمال در سرویس اصلی، در محیط مناسب بررسی می‌شوند.
  • مدیریت و پایش: موجودی ماشین‌ها، مصرف منابع و وضعیت اجرای سرویس‌ها از یک ساختار روشن پیگیری می‌شود.
چند ماشین مجازی روی یک سرور، چند نقطهٔ مستقل برای تحمل خرابی نیستند. خاموشی یا خرابی میزبان می‌تواند همهٔ آن‌ها را از دسترس خارج کند؛ برق پشتیبان، بکاپ و در صورت نیاز میزبان‌های افزونه باید جداگانه طراحی شوند.

پیش‌نیازهای سخت‌افزاری و نرم‌افزاری مجازی‌سازی

قبل از خرید یا نصب، مدل دقیق سرور، پردازنده، کنترلر ذخیره‌سازی، کارت شبکه و نسخهٔ بستر بررسی می‌شود. پشتیبانی از مجازی‌سازی سخت‌افزاری و تنظیمات BIOS یا UEFI اهمیت دارد؛ برای مثال، Hyper-V به پردازندهٔ ۶۴ بیتی با SLAT و فعال‌بودن قابلیت‌های لازم نیاز دارد. جزئیات را با پیش‌نیازهای رسمی Hyper-V تطبیق دهید.

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

CPU و RAM: مصرف هم‌زمان، نه جمع حدس‌ها

تعداد ماشین‌ها به‌تنهایی معیار انتخاب پردازنده و RAM نیست. مصرف واقعی سرویس‌ها در ساعات شلوغ، نیاز میزبان و ظرفیت رشد باید بررسی شوند. تخصیص بیش از اندازهٔ vCPU نیز لزوماً عملکرد را بهتر نمی‌کند. منابع اولیه را متناسب تعیین کنید و با مشاهدهٔ عملکرد نرم‌افزار اصلاح کنید؛ ظرفیت برای همهٔ سرویس‌های هم‌زمان باید قابل دفاع باشد.

ذخیره‌سازی و شبکه: فراتر از ظرفیت دیسک

فضای قابل استفاده، تأخیر و توان پاسخ‌گویی ذخیره‌ساز، رشد داده و فضای لازم برای عملیات بکاپ بررسی می‌شوند. چند ماشین روی یک ذخیره‌ساز ممکن است هم‌زمان درخواست‌های سنگین داشته باشند. ظرفیت و مسیر شبکه برای کاربران، مدیریت، بکاپ و در صورت نیاز مهاجرت ماشین‌ها نیز باید طراحی شوند. RAID یا دیسک افزونه، جای نسخهٔ پشتیبان مستقل را نمی‌گیرد.

  • فهرست سرویس‌ها، سیستم‌عامل‌ها و وابستگی نرم‌افزارها
  • اندازه‌گیری منابع در زمان عادی و اوج مصرف، همراه با برنامهٔ رشد
  • مجوز و پشتیبانی بستر، سیستم‌عامل مهمان و نرم‌افزارها
  • طرح شبکه، آدرس‌دهی، DNS و دسترسی مدیریتی محدود
  • برق، تهویه، ظرفیت ذخیره‌سازی و مقصد مستقل برای بکاپ
  • زمان بازیابی موردنیاز و میزان ازدست‌رفتن دادهٔ قابل قبول برای هر سرویس

انتخاب VMware، Hyper-V یا Proxmox

نام محصول نباید جای نیازسنجی را بگیرد. انتخاب مناسب، بستری است که با تجهیزات، نرم‌افزارهای ضروری، مدل پشتیبانی و توان تیم نگهداری سازمان سازگار باشد. شرایط مجوز و پشتیبانی در زمان خرید باید دوباره بررسی شوند؛ نسخهٔ رایگان یا شرایط قدیمی یک محصول را مبنای بودجهٔ پروژه قرار ندهید.

  • VMware vSphere: سازگاری تجهیزات، نسخه‌های اجزا، مجوز، ابزار مدیریت و بکاپ منتخب را بررسی کنید.
  • Microsoft Hyper-V: برای محیطی که نیاز به یکپارچگی با ابزارهای مدیریت Windows Server دارد، گزینه‌ای قابل بررسی است؛ مجوز سیستم‌عامل‌های مهمان و ظرفیت میزبان همچنان مهم‌اند.
  • Proxmox VE: طبق معرفی رسمی محصول، ماشین‌های مجازی KVM و کانتینرهای LXC را مدیریت می‌کند. ماشین مجازی و کانتینر را در طراحی یکسان فرض نکنید؛ سازگاری نرم‌افزار، ذخیره‌سازی، بکاپ و پشتیبانی را ارزیابی کنید.

پیش از تصمیم نهایی، یک سرویس آزمایشی و مسیر بازیابی آن را روی گزینهٔ منتخب بررسی کنید. این راهنما جای دستورالعمل نصب نسخهٔ مشخص یک محصول نیست؛ جزئیات اجرا باید از مستندات همان نسخه گرفته شود.

مراحل راه‌اندازی سرور مجازی‌سازی سازمانی

  1. نیازسنجی و موجودی: ثبت سرویس‌ها، کاربران، بار کاری، وابستگی‌ها، محدودیت‌های نرم‌افزاری و هدف پایداری.
  2. طراحی: تعیین میزبان‌ها، منابع، ذخیره‌سازی، شبکه، روش مدیریت، مجوزها و برنامهٔ پشتیبان‌گیری.
  3. آماده‌سازی: کنترل سازگاری، تنظیمات سخت‌افزار، نسخه‌های پشتیبانی‌شده و آماده‌کردن برق و شبکه.
  4. نصب و پیکربندی بستر: تنظیم دسترسی مدیران، شبکه‌های لازم، مقصد ذخیره‌سازی و پایش؛ بدون انتشار مستقیم پنل مدیریت روی اینترنت.
  5. ایجاد ماشین آزمایشی: نصب سیستم‌عامل سازگار، تخصیص منابع اولیه و آزمون شبکه، سرویس و بکاپ.
  6. انتقال مرحله‌ای: مهاجرت سرویس‌های تأییدشده با زمان‌بندی، اطلاع‌رسانی و مسیر بازگشت مشخص.
  7. تحویل: آزمون عملکرد از سمت کاربر، ثبت تنظیمات، بررسی بازیابی و توافق بر مسئولیت نگهداری.

امنیت میزبان و ماشین‌های مجازی

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

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

Snapshot، بکاپ و High Availability یک چیز نیستند

Snapshot یا Checkpoint برای بازگشت کوتاه‌مدت در تغییرات کاربرد دارد، اما ممکن است به دیسک‌ها و ذخیره‌ساز همان میزبان وابسته باشد. مایکروسافت نیز در مستندات Checkpoint تأکید می‌کند که Snapshot استاندارد، بکاپ کامل نیست. نوع Checkpoint و سازگاری آن با سرویس‌هایی مانند پایگاه داده و اکتیو دایرکتوری باید بررسی شود.

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

High Availability به طراحی چند میزبان و اجزای لازم برای جابه‌جایی یا راه‌اندازی مجدد سرویس روی میزبان سالم وابسته است. Failover Clustering یکی از راهکارهای این حوزه است؛ HA جای بکاپ را نمی‌گیرد و خرابی برنامهٔ داخل ماشین یا حذف اشتباه داده را خودبه‌خود حل نمی‌کند.

مهاجرت سرور فیزیکی به ماشین مجازی

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

انتقال را از سرویس کم‌ریسک‌تر شروع کنید. معیار پذیرش باید عملکرد نرم‌افزار از سمت کاربر و حفظ صحت داده باشد، نه صرفاً روشن‌شدن ماشین. زمان توقف و نحوهٔ هماهنگ‌کردن آخرین تغییرات داده از قبل مشخص شوند. در بازگشت احتمالی نیز نباید دو نسخهٔ سرویس با داده‌های متفاوت و نقش هم‌زمان روی شبکه فعال شوند؛ مسیر بازگشت باید با مسئول برنامه هماهنگ باشد.

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

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

برای برآورد اولیه، فهرست نرم‌افزارها، تعداد کاربران هم‌زمان، مشخصات سرور فعلی، حجم داده و رشد آن، محدودیت زمان توقف و مشکلات موجود را آماده کنید. محدودهٔ اجرا، اقلام تحویل و هزینهٔ نگهداری دوره‌ای باید روشن باشد. عدد قیمت یا درصد صرفه‌جویی بدون این اطلاعات، مبنای مطمئنی برای تصمیم نیست.

چک‌لیست تحویل بستر مجازی‌سازی

  • عملکرد نرم‌افزارهای ضروری و ارتباط کاربران در شرایط بار مورد انتظار
  • مصرف CPU، RAM، تأخیر ذخیره‌سازی و ظرفیت شبکه در آزمون
  • درستی مجوزها و محدودبودن دسترسی‌های مدیریتی
  • اجرای بکاپ و بازیابی نمونهٔ تأییدشده در محیط مناسب
  • آزمون سناریوی خرابی فقط در محدودهٔ مجاز و با برنامهٔ ایمن، اگر افزونگی جزو قرارداد است
  • مستندات ماشین‌ها، منابع، شبکه‌ها، نگهداری، مسئولیت‌ها و مسیرهای بازیابی

درخواست بررسی و اجرای مجازی‌سازی در ویوان نت

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

مثال آموزشی، نه نمونه‌کار واقعی

سناریوی آموزشی: تجمیع چند سرویس یک شرکت

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

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

این مثال، پروژهٔ واقعی ویوان نت نیست و عدد نتیجه یا تضمین صرفه‌جویی ارائه نمی‌کند؛ هدف آن نشان‌دادن روش تصمیم‌گیری و معیار تحویل است.

راهنماهای مرتبط با مجازی‌سازی

برای طراحی حفاظت از داده و نگهداری، بخش‌های پشتیبان‌گیری و بازیابی و پشتیبانی و مانیتورینگ را هم ببینید.

این راهنما از مجموعهٔ مجازی‌سازی و پردازش ابری ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت را ببینید.

پرسش‌های متداول درباره سرور مجازی‌سازی

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

برای اجرای چند ماشین مجازی می‌توان از یک میزبان شروع کرد، اما همهٔ آن‌ها به سلامت همان میزبان وابسته‌اند. تعداد میزبان‌ها و طراحی افزونگی باید با نیاز تداوم سرویس و بودجه تعیین شود.

چه مقدار RAM و CPU برای سرور مجازی‌سازی مناسب است؟

عدد ثابت برای همهٔ سازمان‌ها وجود ندارد. مصرف واقعی و هم‌زمان نرم‌افزارها، منابع موردنیاز میزبان و ظرفیت رشد بررسی می‌شوند؛ سرعت ذخیره‌سازی و شبکه نیز بخشی از ظرفیت‌سنجی است.

VMware، Hyper-V یا Proxmox؛ کدام را انتخاب کنیم؟

انتخاب به سازگاری سخت‌افزار و نرم‌افزار، شرایط مجوز و پشتیبانی، امکانات موردنیاز و مهارت تیم بستگی دارد. بهتر است گزینهٔ منتخب با یک سرویس آزمایشی و سناریوی بازیابی ارزیابی شود.

آیا Snapshot جای بکاپ ماشین مجازی را می‌گیرد؟

خیر. Snapshot یا Checkpoint معمولاً برای بازگشت کوتاه‌مدت تغییرات استفاده می‌شود و ممکن است به همان ذخیره‌ساز وابسته باشد. نسخهٔ پشتیبان مستقل، نگهداری تاریخی و آزمون بازیابی همچنان لازم است.

مهاجرت از سرور فیزیکی به مجازی بدون قطعی انجام می‌شود؟

این موضوع به نرم‌افزار، حجم داده و روش انتقال بستگی دارد. زمان توقف، سازگاری مجوزها و مسیر بازگشت باید پیش از مهاجرت مشخص شوند؛ قطعی صفر برای همهٔ پروژه‌ها قابل وعده نیست.

هزینه راه‌اندازی سرور مجازی‌سازی چطور برآورد می‌شود؟

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

منابع فنی و مطالعهٔ بیشتر

جزئیات نسخه و سازگاری را پیش از اجرا از مستندات رسمی بررسی کنید:

مجازی‌سازی را با شناخت نیاز سازمان شروع کنید

سرویس‌های فعلی و هدف توسعه را توضیح دهید تا مسیر مناسب ظرفیت‌سنجی، اجرا و بازیابی بررسی شود.

ثبت درخواست مشاوره ←