قبل از مجازی‌سازی سرور این موارد را بررسی کنید؛ هر زیرساختی آماده مهاجرت نیست

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

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

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

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

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

آیا منابع پردازشی و حافظه برای مجازی‌سازی کافی هستند؟

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

در بخش حافظه نیز باید مصرف عادی و اوج مصرف را جداگانه بررسی کرد. کمبود RAM می‌تواند هایپروایزر یا Hypervisor را به استفاده از روش‌های جبران حافظه مانند Swapping وادار کند. این وضعیت معمولاً تأخیر ماشین‌های مجازی را افزایش می‌دهد. ظرفیت زیرساخت نباید فقط برای شرایط عادی کافی باشد. کلاستر باید هنگام تعمیر یا خروج یکی از Hostها نیز بتواند سرویس‌های حیاتی را فعال نگه دارد. سازمان باید ظرفیت رشد و منابع موردنیاز ابزارهای پشتیبان‌گیری، امنیتی و مدیریتی را هم محاسبه کند.

Storage و شبکه چه محدودیت‌هایی برای محیط مجازی ایجاد می‌کنند؟

وجود Hostهای قدرتمند به‌تنهایی عملکرد مناسب ماشین‌های مجازی را تضمین نمی‌کند؛ زیرا Storage و شبکه اغلب گلوگاه اصلی زیرساخت مجازی هستند. در Storage، ظرفیت اسمی کافی نیست. تعداد عملیات ورودی و خروجی، تأخیر، توان عملیاتی و الگوی دسترسی برنامه‌ها نیز اهمیت دارند. روشن‌شدن هم‌زمان ماشین‌ها، پشتیبان‌گیری، ساخت Snapshot و جابه‌جایی ماشین مجازی می‌توانند فشار زیادی بر Storage وارد کنند و عملکرد سرویس‌ها را کاهش دهند.

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

پیش از مهاجرت کدام سرویس‌ها و وابستگی‌ها باید شناسایی شوند؟

هر سرور بخشی از یک زنجیره خدمات است. یک برنامه ممکن است به پایگاه داده، DNS، Active Directory، گواهی دیجیتال یا فضای ذخیره‌سازی مشترک وابسته باشد. انتقال سرور بدون شناخت این ارتباطات می‌تواند سرویس‌های دیگر را مختل کند.

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

• ارتباط برنامه‌ها با پایگاه‌های داده
• وابستگی به DNS، DHCP و Active Directory
• آدرس‌های IP ثابت و قوانین فایروال
• گواهی‌های دیجیتال و سرویس‌های احراز هویت
• پردازش‌های دوره‌ای و وظایف زمان‌بندی‌شده
• قفل‌های سخت‌افزاری و محدودیت‌های مجوز نرم‌افزار
• ابزارهای پشتیبان‌گیری، کنترل و مدیریت زیرساخت

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

امنیت و پایداری زیرساخت مجازی چگونه باید طراحی شود؟

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

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

راهکار امنیتی نیز باید با محیط مجازی سازگار باشد و بدون ایجاد فشار زیاد بر منابع مشترک، از بارهای کاری محافظت کند. Kaspersky Hybrid Cloud Security برای حفاظت متمرکز از بارهای کاری فیزیکی، مجازی و ابری طراحی شده است. سازمان باید این راهکار را پس از ارزیابی فنی و متناسب با معماری، اهمیت سرویس‌ها و ظرفیت زیرساخت تنظیم کند.

چگونه مشخص کنیم زیرساخت آماده مجازی‌سازی است؟

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

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

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

• کدام سرویس‌ها اکنون آماده مهاجرت‌اند؟
• کدام بخش‌ها پیش از مهاجرت به اصلاح نیاز دارند؟
• برای حفاظت از بارهای کاری چه کنترل‌هایی باید اضافه شوند؟

این پاسخ‌ها، مسیر مهاجرت را روشن می‌کنند و از تصمیم‌گیری براساس حدس جلوگیری می‌کنند.

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

جمع‌بندی

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

قبل از مجازی‌سازی سرور، آمادگی زیرساخت را بررسی کنید

برچسب ها : زیرساخت مجازی,زیرساخت سرور سازمانی,ماشین مجازی