چگونه یک سرور محلی را به AWS منتقل کنیم (کتابچه راهنمای ساده)

معرفی

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

قبل از مهاجرت هر چیزی چه تصمیمی باید بگیرید؟

کدام استراتژی مهاجرت به این سرور (هفت R آمازون وب سرویس) مناسب است؟

سریع‌ترین راه برای از دست دادن زمان، مهاجرت به چیز اشتباه است. قبل از اینکه هر عاملی را نصب کنید، تصمیم بگیرید که کدام استراتژی مهاجرت شایسته سرور است تا چیزی را که باید بازنشسته یا جایگزین شود، جابجا نکنید. در عمل، بسیاری از تیم‌ها با مجازی‌سازی برای سرعت شروع می‌کنند و سپس بعد از اینکه بار کاری در AWS پایدار شد، بهینه‌سازی می‌کنند.

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

• میزبانی مجدد: با سرعت حرکت کنید و تغییرات را به حداقل برسانید زمانی که زمان محدود است.
• تغییر پلتفرم: برنامه را نگه دارید اما تغییرات کوچکی برای سازگاری با AWS ایجاد کنید.
• بازنگری: تلاش را برای تمایزهای حیاتی کسب و کار ذخیره کنید.
• خرید مجدد: جایگزین با نرم‌افزار به عنوان سرویس به جای مهاجرت سرور.
• بازنشسته/نگه‌دارید: سیستم‌های غیرقابل استفاده را حذف کنید یا بارهای کاری محدود را در محل نگه دارید.

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

RTO/RPO چیست، پنجره زمان خرابی و محرک‌های بازگشت به حالت قبل چیست؟

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

تعریف و مستندسازی:

• RTO: حداکثر زمان قابل قبول برای خرابی.
• RPO: حداکثر از دست دادن داده قابل قبول.
• زمان توقف: زمانی که مجاز به تغییر ترافیک تولید هستید.
• بازگشت به حالت قبلی: شرایط خاص شکست (قطع دسترسی، تراکنش‌های ناموفق، عدم تطابق داده‌ها).
• مکانیزم انتقال: تغییرات DNS flip، سوئیچ بارگذاری متعادل‌کننده، تغییرات مسیریابی/فایروال.

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

چه چیزی را باید در AWS و در محل اول آماده کنید؟

مبانی اتصال و فایروال برای تکرار

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

الگوهای متداول اتصال:

• خروجی اینترنت عمومی (ساده‌ترین زمانی که مجاز باشد)
• VPN نقطه به نقطه (متداول برای اتصال خصوصی)
• اتصال مستقیم (بیشتر قابل پیش‌بینی برای محیط‌های بزرگتر)

بررسی‌های پیش از پرواز:

• خروجی HTTPS به طور قابل اعتمادی از شبکه منبع کار می‌کند
• رفتار پروکسی درک شده و با جریان مهاجرت آزمایش شده است
• تیم‌های امنیتی خروجی مورد نیاز برای پنجره مهاجرت را تأیید می‌کنند

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

چک لیست حداقلی منطقه فرود AWS

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

عناصر حداقل منطقه فرود:

• A VPC و زیرشبکه‌ها جایی که نمونه‌ها راه‌اندازی خواهند شد (معمولاً تست جداگانه در مقابل تولید)
• گروه‌های امنیتی با جریان‌های واقعی برنامه هماهنگ شده است (از "اکنون باز کنید، بعداً اصلاح کنید" پرهیز کنید)
• مدیریت هویت و دسترسی آماده برای عملیات مهاجرت و دسترسی و ابزارهای روز دوم
• پایه برچسب‌گذاری بنابراین مالکیت و ردیابی هزینه‌ها پس از انتقال واضح است

همچنین کمک می‌کند تا زودتر تصمیم بگیریم که مدیران چگونه به نمونه‌ها (بستین، VPN و نحوه دسترسی به اینترنت خروجی فراهم خواهد شد (دروازه NAT، پروکسی). این انتخاب‌ها بر روی وصله‌گذاری، عامل‌های نظارت و عیب‌یابی در روز اول تأثیر می‌گذارد.

چک لیست آمادگی سرور منبع

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

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

• سازگاری OS/بار کاری با رویکرد مهاجرت
• فضای دیسک کافی و I/O پایدار برای بار اضافی تکرار
• وابستگی‌های نقشه‌برداری شده: DNS , AD/LDAP داخلی PKI/گواهی‌نامه‌ها پایگاه‌های داده، اشتراک‌ها
• سختی پنهان: IPهای سخت‌کد شده، TLS قدیمی، وظایف زمان‌بندی شده غیرمعمول
• موارد خاصی که زودتر علامت‌گذاری شده‌اند: کنترل‌کننده‌های دامنه، خوشه‌ها، دستگاه‌ها، مجوزهای دانگل

قبل از ترک این مرحله، مواردی که "باید ثابت بمانند" مانند نام میزبان، الزامات آدرس IP یا پیوندهای گواهی را ثبت کنید، زیرا این موارد به طور مستقیم بر تنظیمات راه‌اندازی AWS و توالی انتقال شما تأثیر می‌گذارند.

چگونه یک سرور را با AWS MGN به AWS منتقل کنید؟

MGN را راه‌اندازی کرده و پیش‌فرض‌های تکرار را تنظیم کنید

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

پیش‌فرض‌های تکرار را از ابتدا تنظیم کنید:

• استراتژی زیرشبکه هدف و قرارگیری شبکه
• پایه گروه امنیتی برای نمونه‌های راه‌اندازی شده
• رفتار ذخیره‌سازی (نقشه‌برداری حجم، رمزنگاری انتظارات)
• کاهش تکرار برای محافظت از ترافیک تولید

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

نرم‌افزار را نصب کنید و همگام‌سازی اولیه را کامل کنید

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

راهنمای عملیاتی:

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

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

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

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

حداقل لیست بررسی اعتبارسنجی:

• راه‌اندازی کامل می‌شود و خدمات به‌طور صحیح آغاز می‌شوند
• آزمایش‌های دود برنامه برای جریان‌های کاری کلیدی موفقیت‌آمیز است
• احراز هویت کار می‌کند (AD/LDAP/محلی)
• مسیرهای داده کار می‌کنند (اتصالات پایگاه داده، اشتراک‌های فایل، یکپارچه‌سازی‌ها)
• وظایف زمان‌بندی شده و خدمات پس‌زمینه طبق انتظار اجرا می‌شوند
• گزارش‌ها و سیگنال‌های نظارتی در جایی که تیم عملیات شما انتظار دارد ظاهر شوند

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

انتقال را راه‌اندازی کرده و نهایی کنید

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

ضروریات اجرای انتقال:

• تأیید برنامه تغییرات و ارتباطات
• راه‌اندازی نمونه برش و تغییر ترافیک (DNS/LB/مسیر‌یابی)
• بازبینی فهرست تأیید با تمرکز بیشتر بر یکپارچگی داده‌ها
• در صورت نیاز، محرک‌های بازگشت را اعمال کنید و ترافیک را به‌طور تمیز برگردانید.
• انتقال نهایی را انجام دهید و منابع آزمایشی را حذف یا خاتمه دهید

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

چه چیزی معمولاً خراب می‌شود و بعد از انتقال باید چه کار کنید؟

خروجی شبکه، وابستگی‌های DNS/AD و "انتقال و جابجایی انجام نشده است"

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

شایع‌ترین نقاط شکست:

• ترافیک HTTPS خروجی توسط پروکسی مسدود یا تغییر یافته است بازرسی TLS
• تغییرات حل DNS (مسائل افق تقسیم، قوانین حل‌کننده گمشده)
• شکاف‌های دسترسی AD/LDAP از VPC
• زنجیره‌های PKI داخلی در محیط جدید گم شده یا مورد اعتماد نیستند
• نقاط پایانی سخت‌افزاری و فرضیات قدیمی درباره مسیرهای شبکه محلی

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

پایداری پس از انتقال: امنیت، پشتیبان‌گیری، نظارت، هزینه

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

اقدامات فوری پس از برش:

• تأیید کنید که نظارت/هشدار فعال و متعلق به شماست
• اطمینان حاصل کنید که پشتیبان‌گیری‌ها فعال هستند و تأیید صحت بازیابی را کامل کنید
• گروه‌های امنیتی را تقویت کرده و حداقل دسترسی را اعمال کنید مدیریت هویت و دسترسی
• رویکرد پچینگ و دسترسی مدیریتی را استاندارد کنید (مسیرهای قابل حسابرسی)
• پس از جمع‌آوری داده‌های واقعی استفاده، شروع به بهینه‌سازی اندازه‌گیری کنید
• اجبار برچسب‌گذاری برای جلوگیری از انحراف هزینه "مالک ناشناخته"

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

TSplus در کجا قرار می‌گیرد پس از اینکه سرورها را به AWS منتقل کردید؟

پس از اینکه بارهای کاری ویندوز بر روی AWS اجرا می‌شوند، بسیاری از تیم‌ها هنوز به یک روش ساده برای انتشار برنامه‌ها و دسکتاپ‌های ویندوز به کاربران بدون ساخت یک زیرساخت سنگین VDI نیاز دارند. TSplus دسترسی از راه دور نشر برنامه و دسترسی به دسکتاپ از راه دور برای سرورهای ویندوز در AWS، محیط‌های محلی یا ترکیبی را با مدیریت ساده و مجوزهای قابل پیش‌بینی که مناسب عملیات SMB و بازار میانه است، ارائه می‌دهد.

نتیجه

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