ابتدا سرور جدید را آماده و آزمایش کنید، داده‌ها را با روش سازگاری مورد پشتیبانی برنامه کپی نمایید، یک بازه زمانی تغییر تعریف کنید و محیط قدیمی را حفظ نمایید. بازگشت باید نوشتن‌های پذیرفته‌شده روی سرور جدید را در نظر بگیرد، نه فقط یک تغییر DNS.
پیش از جابه‌جایی ماشین، سرویس را فهرست‌برداری کنید
یک مهاجرت شامل چیزی بیش از فایل‌های برنامه است. پایگاه‌های داده، بارگذاری‌ها، کارهای زمان‌بندی‌شده، کارگران صف، گواهی‌ها، دامنه‌ها، اسرار و یکپارچه‌سازی‌های خروجی را فهرست کنید. نسخه‌های نرم‌افزار و فرض‌های عملیاتی مهم مانند مجوزهای فایل و مسیرهای ذخیره‌سازی را ثبت نمایید. یک سرور اختصاصی تازه ممکن است وابستگی فراموش‌شده‌ای را آشکار کند که سال‌ها پیش بی‌سروصدا روی محیط قدیمی نصب شده بود.
برای تصمیم تغییر، یک مسئول تعیین کنید و تعریف نمایید که موفقیت چه شکلی دارد. بررسی‌های قابل مشاهده برای کاربر، سازگاری داده و توانایی بازیابی دسترسی را بگنجانید. پیش از اعلام تاریخ مهاجرت، تأیید کنید که پیکربندی جدید تحویل داده شده و قابل استفاده است. تأیید سفارش یا مشخصات سخت‌افزاری فهرست‌شده با یک مقصد کارآمد آماده دریافت داده‌های تولیدی یکسان نیست.
مقصد را به‌عنوان یک محیط جداگانه بسازید
پشته مورد نیاز را نصب کنید، مدیریت را برقرار نمایید و فایروال مورد نظر را پیکربندی کنید. اسرار را خصوصی نگه دارید و مجوزهای سرویس را آگاهانه تنظیم نمایید. پیش از انتقال ترافیک عمومی، رفتار نام میزبان و گواهی مورد انتظار برنامه را بررسی کنید. مستندات میزبان مجازی Apache نشان می‌دهد چرا مسیریابی نام میزبان یک تصمیم پیکربندی جداگانه از آدرس سرور است. یک صفحه پیش‌فرض کارآمد اثبات نمی‌کند که میزبان برنامه صحیح پیکربندی شده است.
برای تمرین از یک مجموعه داده بازیابی‌شده نماینده استفاده کنید، با ایمیل خروجی، پرداخت‌ها و کارهای زمان‌بندی‌شده غیرفعال یا هدایت‌شده به سیستم‌های آزمایشی ایمن. این کار مانع می‌شود محیط آزمایش روی کاربران واقعی عمل کند. ورود، بارگذاری‌ها، کارهای پس‌زمینه و بازیابی را تمرین کنید. رویه و مدت آن را ثبت نمایید تا بازه واقعی بر پایه یک فرآیند مشاهده‌شده باشد، نه خوش‌بینی.
یک مرز داده سازگار انتخاب کنید
از یک روش پشتیبان‌گیری یا تکرار مورد پشتیبانی پایگاه داده و برنامه استفاده کنید. PostgreSQL بین دامپ‌های SQL، پشتیبان‌گیری‌های فایل‌سیستم و آرشیو پیوسته تمایز قائل می‌شود که هر یک فرض‌های خود را دارند. راهنمای دامپ آن اشاره می‌کند که دامپ‌های پایگاه داده می‌توانند به‌صورت داخلی سازگار باشند، در حالی که نقش‌های سطح خوشه و سایر جزئیات نیازمند رسیدگی جداگانه هستند. الزامات سیستم دقیقی که اجرا می‌کنید را بخوانید، نه اینکه فایل‌های داده باز را بی‌رویه کپی کنید.
برنامه‌ریزی کنید که پایگاه داده چگونه با بارگذاری‌ها و وضعیت صف مرتبط است. اگر یک رکورد به فایلی اشاره کند که در زمان متفاوتی کپی شده، برنامه بازیابی‌شده می‌تواند ناقص باشد، حتی اگر هر دو کپی به‌تنهایی موفق بوده باشند. تصمیم بگیرید که آیا نوشتن‌ها را کوتاه‌مدت متوقف کنید، از یک ترتیب تکرار آزمایش‌شده استفاده نمایید یا یک خروجی مخصوص برنامه انجام دهید. آن تصمیم سازگاری را در راهنما صریح نگه دارید.
| مرحله | شواهد مورد نیاز | تصمیم |
|---|---|---|
| تمرین | برنامه و داده بازیابی‌شده بررسی‌ها را می‌گذرانند | مقصد می‌تواند برای تغییر در نظر گرفته شود |
| همگام‌سازی نهایی | نقطه بازیابی سازگار تعریف‌شده | فقط با تغییرات باقی‌مانده درک‌شده ادامه دهید |
| تغییر ترافیک | مسیریابی صحیح و رفتار گواهی | هر دو مقصد را پایش کنید |
| بازگشت | محل تمام نوشتن‌های تازه پذیرفته‌شده | پیش از بازگرداندن ترافیک، داده‌ها را تطبیق دهید |
مسیریابی ترافیک را بدون وعده تغییرات فوری آماده کنید
DNS مدت زنده‌ماندن را کنترل می‌کند که تعیین می‌کند رکوردها چه مدت می‌توانند کش شوند، همان‌طور که در مستندات DNS کلودفلر توضیح داده شده است. اگر DNS بخشی از مهاجرت است، TTL را زودتر بررسی کنید و اجازه دهید رکوردهای کش‌شده موجود تحت تنظیم قبلی خود منقضی شوند. تغییر مقدار در لحظه تغییر نمی‌تواند هر پاسخ کش‌شده را به‌صورت گذشته‌نگر کوتاه کند. کلاینت‌های مختلف ممکن است در طول انتقال به مقصدهای متفاوتی برسند.
تا زمانی که تغییرات مسیریابی تثبیت شوند، محیط قدیمی را در دسترس نگه دارید، با یک سیاست آگاهانه درباره اینکه آیا هنوز می‌تواند نوشتن‌ها را بپذیرد. از اجرای مصرف‌کنندگان صف تکراری یا کارهای زمان‌بندی‌شده خودداری کنید، مگر اینکه برنامه برای آن طراحی شده باشد. درخواست‌ها را در هر دو طرف پایش کنید و نام میزبان مورد نظر، گواهی TLS و نسخه برنامه را از کلاینت‌های مستقل تأیید نمایید.
بازگشت را پس از آغاز نوشتن‌ها تعریف کنید
پیش از آنکه سیستم جدید تغییرات را بپذیرد، بازگرداندن ترافیک ممکن است نسبتاً ساده باشد. پس از آن، یک بازگشت صرف DNS می‌تواند کار را از دست بدهد یا دو تاریخچه متضاد ایجاد کند. تعریف کنید که رکوردها و بارگذاری‌های تازه‌ایجادشده چگونه حفظ یا تطبیق خواهند شد. اگر برنامه نمی‌تواند آن‌ها را به‌طور ایمن ادغام کند، یک دوره نگهداری کنترل‌شده ممکن است بر بازگشت بداهه به نسخه قدیمی ترجیح داشته باشد.
شرایطی را تعیین کنید که نیازمند توقف مهاجرت هستند و مسئول تصمیم را در دسترس نگه دارید. گزارش‌ها و شواهد مفید را تحت قواعد نگهداری پروژه حفظ کنید. ماشین قدیمی یا نسخه بازیابی مستقل آن را صرفاً به این دلیل که صفحه اصلی یک بار بارگذاری شده حذف نکنید. دوره نگهداری باید نیازهای توافق‌شده تأیید و بازگشت را پوشش دهد.
مهاجرت را با بررسی‌های عملیاتی ببندید
پس از تغییر، پشتیبان‌گیری‌ها، هشدارها، تمدید گواهی، کارهای زمان‌بندی‌شده و بازیابی دسترسی را بررسی کنید. تأیید نمایید که میزبان پایش‌شده مقصد جدید است و هیچ یکپارچه‌سازی آزمایشی در تولید باقی نمانده است. خطاهای برنامه و زمان‌های قابل مشاهده برای کاربر را تحت ترافیک عادی بررسی کنید. فهرست و راهنما را به‌روزرسانی کنید تا مدیر بعدی مجبور نباشد آنچه تغییر کرده را حدس بزند.
خانواده‌های اختصاصی SwissOctet پیکربندی‌های فیزیکی متفاوتی ارائه می‌دهند، اما کار مهاجرت و کمک مدیریت‌شده باید برای سرویس انتخاب‌شده تأیید شود. از کاتالوگ برای انتخاب منابع مناسب استفاده کنید، سپس یک انتقال آزمایش‌شده حول داده‌های برنامه خود بسازید. یک مهاجرت زمانی کامل است که سرویس و فرآیند بازیابی آن روی مقصد کار کنند، نه صرفاً زمانی که فایل‌ها منتقل شده باشند.
چک‌لیست عملی شما.
- داده‌ها، کارها، اسرار و یکپارچه‌سازی‌ها را فهرست کنید.
- پیش از زمان‌بندی، مقصد تحویل‌شده را بررسی کنید.
- با یکپارچه‌سازی‌های خارجی ایمن تمرین کنید.
- سازگاری پایگاه داده و بارگذاری را تعریف کنید.
- انتقال مسیریابی و جلوگیری از کارهای تکراری را برنامه‌ریزی کنید.
- بازگشت برای نوشتن‌های جدید را مشخص کنید.
- پس از تغییر، پشتیبان‌گیری‌ها و پایش را بررسی کنید.
جزئیاتی که اهمیت دارند.
آیا می‌توانم با کپی کردن پوشه برنامه مهاجرت کنم؟+
فقط اگر همه چیز مورد نیاز سرویس را در بر بگیرد و سازگاری را حفظ کند. پایگاه‌های داده، بارگذاری‌ها، کارها، اسرار و پیکربندی معمولاً نیازمند توجه جداگانه هستند.
آیا کاهش TTL DNS تغییر را فوری می‌کند؟+
خیر. پاسخ‌های قبلاً کش‌شده می‌توانند تا پایان عمر قبلی خود باقی بمانند و کلاینت‌ها ممکن است در زمان‌های متفاوتی به‌روزرسانی شوند.
آیا بازگشت فقط اشاره DNS به سرور قدیمی است؟+
پس از پذیرش نوشتن توسط سرور جدید، خیر. باید آن رکوردها و فایل‌ها را پیش از بازگرداندن ترافیک در نظر بگیرید.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- PostgreSQL: پشتیبان‌گیری و بازیابی www.postgresql.org
- PostgreSQL: سازگاری و بازیابی دامپ SQL www.postgresql.org
- Apache: مستندات میزبان مجازی httpd.apache.org
- کلودفلر DNS: مدت زنده‌ماندن developers.cloudflare.com
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.