شناخت سرویسها
ثبت وابستگیها، مصرف منابع و میزان توقف قابل قبول.
در حال آمادهسازی صفحه
چند سرویس سازمانی، یک زیرساخت قابل مدیریت. مجازیسازی میتواند استفاده از منابع و توسعهٔ سرویسها را سادهتر کند؛ به شرط اینکه ظرفیت، امنیت و بازیابی از ابتدا طراحی شوند، نه اینکه فقط چند ماشین مجازی ساخته شود.
نمودار مفهومی آموزشی؛ بکاپ مستقل است و یک میزبان بهتنهایی افزونگی ایجاد نمیکند.
در مجازیسازی سرور، یک بستر مدیریتی به نام Hypervisor منابع میزبان فیزیکی را در اختیار چند ماشین مجازی قرار میدهد. هر ماشین، سیستمعامل و سرویسهای خود را دارد و منابعی مانند پردازنده، حافظه، دیسک و کارت شبکهٔ مجازی برای آن تعریف میشود.
منظور این راهنما، طراحی و راهاندازی بستر مجازیسازی داخل زیرساخت سازمان است؛ نه صرفاً خرید یک VPS از شرکت میزبان. نتیجهٔ مطلوب، سرویسهایی با ظرفیت مشخص، مدیریت قابل پیگیری و برنامهٔ بازیابی آزمونپذیر است.
ثبت وابستگیها، مصرف منابع و میزان توقف قابل قبول.
انتخاب میزبان، ذخیرهسازی، شبکه، بستر و بکاپ.
ارزیابی یک سرویس با بار واقعی و آزمون بازیابی.
انتقال مرحلهای، پایش عملکرد و ثبت مستندات.
وقتی چند سرور جداگانه، سرویسهایی با بار متفاوت اجرا میکنند، بررسی امکان تجمیع آنها میتواند منطقی باشد. ساخت محیط آزمایش، توسعهٔ سریعتر یک سرویس و مدیریت متمرکز ماشینها نیز از کاربردهای این بستر است. با این حال، کاهش هزینه یا افزایش سرعت برای هر سازمان نتیجهٔ خودکار نیست؛ طراحی نامناسب ممکن است چند سرویس را همزمان با یک گلوگاه درگیر کند.
قبل از خرید یا نصب، مدل دقیق سرور، پردازنده، کنترلر ذخیرهسازی، کارت شبکه و نسخهٔ بستر بررسی میشود. پشتیبانی از مجازیسازی سختافزاری و تنظیمات BIOS یا UEFI اهمیت دارد؛ برای مثال، Hyper-V به پردازندهٔ ۶۴ بیتی با SLAT و فعالبودن قابلیتهای لازم نیاز دارد. جزئیات را با پیشنیازهای رسمی Hyper-V تطبیق دهید.
در VMware هم سازگاری سرور و تجهیزات با نسخهٔ موردنظر از راهنمای رسمی سازگاری سختافزار کنترل میشود. سازگاری سیستمعامل مهمان، نرمافزار کسبوکار و ابزار پشتیبانگیری باید پیش از انتخاب نهایی مشخص شود؛ روشنشدن یک ماشین مجازی به معنی پشتیبانی رسمی همهٔ اجزای آن نیست.
تعداد ماشینها بهتنهایی معیار انتخاب پردازنده و RAM نیست. مصرف واقعی سرویسها در ساعات شلوغ، نیاز میزبان و ظرفیت رشد باید بررسی شوند. تخصیص بیش از اندازهٔ vCPU نیز لزوماً عملکرد را بهتر نمیکند. منابع اولیه را متناسب تعیین کنید و با مشاهدهٔ عملکرد نرمافزار اصلاح کنید؛ ظرفیت برای همهٔ سرویسهای همزمان باید قابل دفاع باشد.
فضای قابل استفاده، تأخیر و توان پاسخگویی ذخیرهساز، رشد داده و فضای لازم برای عملیات بکاپ بررسی میشوند. چند ماشین روی یک ذخیرهساز ممکن است همزمان درخواستهای سنگین داشته باشند. ظرفیت و مسیر شبکه برای کاربران، مدیریت، بکاپ و در صورت نیاز مهاجرت ماشینها نیز باید طراحی شوند. RAID یا دیسک افزونه، جای نسخهٔ پشتیبان مستقل را نمیگیرد.
نام محصول نباید جای نیازسنجی را بگیرد. انتخاب مناسب، بستری است که با تجهیزات، نرمافزارهای ضروری، مدل پشتیبانی و توان تیم نگهداری سازمان سازگار باشد. شرایط مجوز و پشتیبانی در زمان خرید باید دوباره بررسی شوند؛ نسخهٔ رایگان یا شرایط قدیمی یک محصول را مبنای بودجهٔ پروژه قرار ندهید.
پیش از تصمیم نهایی، یک سرویس آزمایشی و مسیر بازیابی آن را روی گزینهٔ منتخب بررسی کنید. این راهنما جای دستورالعمل نصب نسخهٔ مشخص یک محصول نیست؛ جزئیات اجرا باید از مستندات همان نسخه گرفته شود.
میزبان مجازیسازی به چند سرویس دسترسی دارد و باید مانند بخش حساس زیرساخت مدیریت شود. حساب مدیر با حساب روزمره جدا باشد، مجوزها محدود و قابل بازبینی باشند و بهروزرسانیها در برنامهٔ نگهداری قرار بگیرند. دسترسی از بیرون سازمان از مسیر کنترلشده و با احراز هویت متناسب انجام شود؛ فعالکردن قابلیتهای امنیتی یک محصول به بررسی سازگاری و روش مدیریت آن نیاز دارد.
جداسازی شبکهٔ مدیریت و محدودکردن ارتباطات ماشینها باید با طرح واقعی شبکه هماهنگ باشد. رخدادها، ظرفیت دیسک، سلامت ذخیرهسازی و موفقیت بکاپ پایش شوند. مجازیبودن یک سرور بهتنهایی آن را در برابر بدافزار، تنظیم اشتباه یا دسترسی غیرمجاز ایمن نمیکند.
Snapshot یا Checkpoint برای بازگشت کوتاهمدت در تغییرات کاربرد دارد، اما ممکن است به دیسکها و ذخیرهساز همان میزبان وابسته باشد. مایکروسافت نیز در مستندات Checkpoint تأکید میکند که Snapshot استاندارد، بکاپ کامل نیست. نوع Checkpoint و سازگاری آن با سرویسهایی مانند پایگاه داده و اکتیو دایرکتوری باید بررسی شود.
برنامهٔ بکاپ به مقصد مستقل، نسخههای تاریخی، مجوزهای محافظتشده و آزمون بازیابی نیاز دارد. وجود فایل بکاپ یا پیام «موفق» کافی نیست؛ باید بازیابی ماشین و عملکرد سرویس داخل آن بررسی شود. طراحی را با هدف زمان بازیابی و میزان دادهٔ قابل ازدسترفتن هماهنگ کنید.
High Availability به طراحی چند میزبان و اجزای لازم برای جابهجایی یا راهاندازی مجدد سرویس روی میزبان سالم وابسته است. Failover Clustering یکی از راهکارهای این حوزه است؛ HA جای بکاپ را نمیگیرد و خرابی برنامهٔ داخل ماشین یا حذف اشتباه داده را خودبهخود حل نمیکند.
پیش از انتقال، وابستگی نرمافزار به سختافزار، مجوز، قفل سختافزاری، سرویسهای شبکه، حجم داده و روش پشتیبانگیری بررسی میشوند. بعضی نرمافزارها محدودیت پشتیبانی در محیط مجازی دارند؛ برای آنها تأیید سازنده و انتخاب روش انتقال ضروری است.
انتقال را از سرویس کمریسکتر شروع کنید. معیار پذیرش باید عملکرد نرمافزار از سمت کاربر و حفظ صحت داده باشد، نه صرفاً روشنشدن ماشین. زمان توقف و نحوهٔ هماهنگکردن آخرین تغییرات داده از قبل مشخص شوند. در بازگشت احتمالی نیز نباید دو نسخهٔ سرویس با دادههای متفاوت و نقش همزمان روی شبکه فعال شوند؛ مسیر بازگشت باید با مسئول برنامه هماهنگ باشد.
هزینهٔ پروژه شامل نصب Hypervisor بهتنهایی نیست. خرید یا ارتقای میزبان، دیسک و شبکه، مجوزها، پشتیبانی، طراحی بکاپ، نیاز افزونگی، انتقال داده و آزمون سرویسها در برآورد اثر دارند. پروژهٔ یک میزبان برای چند سرویس کمبار با زیرساخت چندمیزبانی برای نرمافزار حیاتی یکسان نیست.
برای برآورد اولیه، فهرست نرمافزارها، تعداد کاربران همزمان، مشخصات سرور فعلی، حجم داده و رشد آن، محدودیت زمان توقف و مشکلات موجود را آماده کنید. محدودهٔ اجرا، اقلام تحویل و هزینهٔ نگهداری دورهای باید روشن باشد. عدد قیمت یا درصد صرفهجویی بدون این اطلاعات، مبنای مطمئنی برای تصمیم نیست.
برای بررسی وضعیت زیرساخت، شرح نیاز و سرویسهای فعلی را در بخش پشتیبانی ویوان نت ثبت کنید. در پیام عمومی، رمز، کلید دسترسی یا اطلاعات محرمانهٔ سرور را ننویسید. نیازسنجی مشخص میکند بستر تازه، ارتقای میزبان موجود یا روش دیگری برای سازمان شما مناسبتر است.
فرض کنید یک مجموعه، فایلسرور، سرویس هویت و نرمافزار داخلی را روی سرورهای قدیمی اجرا میکند. پیش از تجمیع، مصرف منابع و وابستگیهای هر سرویس ثبت میشوند. اگر همه به یک میزبان منتقل شوند، خرابی آن میزبان روی همهٔ سرویسها اثر دارد؛ این ریسک باید پیش از انتخاب تجهیزات با مسئول کسبوکار بررسی شود.
برای اجرای آزمایشی، یک سرویس کمریسک و دادهٔ غیرحساس در محیط جدا انتخاب میشود. عملکرد از سمت کاربر، بکاپ و بازیابی بررسی میشوند. اگر سرویس از محدودیت توافقشده عبور کرد، منابع یا طراحی اصلاح میشوند؛ افزایش تعداد ماشینها بدون ظرفیتسنجی مرحلهٔ بعدی نیست.
این مثال، پروژهٔ واقعی ویوان نت نیست و عدد نتیجه یا تضمین صرفهجویی ارائه نمیکند؛ هدف آن نشاندادن روش تصمیمگیری و معیار تحویل است.
این راهنما از مجموعهٔ مجازیسازی و پردازش ابری ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت را ببینید.
برای اجرای چند ماشین مجازی میتوان از یک میزبان شروع کرد، اما همهٔ آنها به سلامت همان میزبان وابستهاند. تعداد میزبانها و طراحی افزونگی باید با نیاز تداوم سرویس و بودجه تعیین شود.
عدد ثابت برای همهٔ سازمانها وجود ندارد. مصرف واقعی و همزمان نرمافزارها، منابع موردنیاز میزبان و ظرفیت رشد بررسی میشوند؛ سرعت ذخیرهسازی و شبکه نیز بخشی از ظرفیتسنجی است.
انتخاب به سازگاری سختافزار و نرمافزار، شرایط مجوز و پشتیبانی، امکانات موردنیاز و مهارت تیم بستگی دارد. بهتر است گزینهٔ منتخب با یک سرویس آزمایشی و سناریوی بازیابی ارزیابی شود.
خیر. Snapshot یا Checkpoint معمولاً برای بازگشت کوتاهمدت تغییرات استفاده میشود و ممکن است به همان ذخیرهساز وابسته باشد. نسخهٔ پشتیبان مستقل، نگهداری تاریخی و آزمون بازیابی همچنان لازم است.
این موضوع به نرمافزار، حجم داده و روش انتقال بستگی دارد. زمان توقف، سازگاری مجوزها و مسیر بازگشت باید پیش از مهاجرت مشخص شوند؛ قطعی صفر برای همهٔ پروژهها قابل وعده نیست.
تعداد سرویسها، سختافزار و ذخیرهسازی، مجوزها و پشتیبانی، شبکه، بکاپ، نیاز افزونگی و پیچیدگی مهاجرت بر هزینه اثر دارند. برآورد قابل اتکا پس از نیازسنجی و تعیین اقلام تحویل انجام میشود.
جزئیات نسخه و سازگاری را پیش از اجرا از مستندات رسمی بررسی کنید:
سرویسهای فعلی و هدف توسعه را توضیح دهید تا مسیر مناسب ظرفیتسنجی، اجرا و بازیابی بررسی شود.
ثبت درخواست مشاوره ←