Cara terbaik untuk mengubah alamat IP situs - dari perspektif pengguna akhir?

10

Saya memang membaca banyak tanya-jawab yang relevan di sini, tetapi saya masih tidak yakin apa jawaban terbaiknya.

Saya memindahkan beberapa situs dari alamat IP "1.abc" ke "2.def". Sampai sekarang di DNS yang ada saya mengatur semua TTL ke 300 detik, dan saya memiliki zona DNS baru yang siap digunakan (pada AWS Route 53), dengan nameserver baru dan semua TTL pada 60 detik. Jadi saya yakin saya siap, dari perspektif DNS. Setelah pindah, setelah beberapa hari saya akan mengatur TTL ke nomor yang lebih masuk akal di Rute 53.

Saya telah memperingatkan semua pengguna saya tentang pemindahan dan saya memiliki waktu yang ditentukan untuk pemindahan tersebut. Saya mengatakan kepada mereka bahwa setelah langkah selesai dan jika 24 jam telah berlalu dan mereka masih melihat situs-situs lama (terkunci), mereka harus me-reboot komputer mereka untuk memaksa siram cache DNS lokal.

Saya tidak mengerti bagaimana browser pengguna (cache) berperan dalam hal ini. Eksperimen saya sendiri dengan file host lokal (Win7) memberi tahu saya ada sesuatu tentang browser yang tidak membiarkan alamat IP lama pergi - saya harus pergi ke history-> menghapus semuanya untuk mendapatkan lokasi situs baru untuk ditampilkan , bahkan setelahipconfig /flushdns

(EDIT) - Saya tidak memiliki akses root ke server lama, jadi saya tidak dapat mengimplementasikan jawaban yang diterima untuk pertanyaan ini .

Pertanyaan: Saya benar-benar tidak ingin pengguna saya harus berurusan dengan itu, jadi apakah ada sesuatu yang bisa saya lakukan untuk memaksa semua browser di luar sana untuk melakukan cache ulang? Dan jika demikian, berapa lama saya membiarkannya hidup?

Terima kasih...

domain-name-system migration CC
sumber
My own experiments with a local hosts file (Win7) tell me there is something about the browser that is not letting the old IP address goBisakah Anda memberikan beberapa info tentang ini? Afaik, browser tidak melakukan cache catatan DNS selama lebih dari 1 menit.
Tanmay
Tidak yakin, tetapi setelah beberapa ipconfig / flushdns dan "ctrl-F5" (di Firefox), saya terus mendapatkan campuran halaman dari situs lama dan situs baru ... akhirnya harus menghapus "segalanya" dan memulai kembali browser. Saya tidak ingin pengguna saya harus melakukan hal serupa ...
CC
JBTW, solusi dalam tautan yang Anda berikan juga dapat berfungsi jika Anda memiliki akses root ke server baru. Perbarui data DNS dan teruskan semua lalu lintas dari ke server baru ke yang lama, sampai DNS telah disebarkan dengan benar.
Tanmay
terima kasih ... tapi kemudian saya harus menyinkronkan yang lama kembali ke yang baru (database, dll) lagi nanti, bukan?
CC
Anda harus menyinkronkan basis data satu kali, tepat sebelum mematikan penerusan.
Tanmay

Jawaban:

15

Tidak bisa. Masalahnya adalah bahwa respons DNS dapat di-cache di mana saja antara pengguna dan server DNS dan tidak ada cara untuk membatalkannya.

Namun apa yang dapat Anda lakukan - segera setelah Anda memiliki data dalam sinkronisasi dan situs kedua Anda siap, Anda dapat mengkonfigurasi ulang server asli untuk berperilaku sebagai proxy dan meneruskan semua permintaan ke lokasi baru.

Dengan cara ini, Anda dapat mencapai hampir 0s downtime dari situs web Anda.

Memperbarui

Jika Anda tidak memiliki akses root, ada beberapa opsi:

  • Lakukan proxy di PHP

  • Konfigurasikan proxy di server kedua (jika Anda memiliki akses root di sana), alihkan DNS dan ketika Anda siap ganti proxy ke server web

  • Metode ini dapat menjadi sumber masalah Memiliki 2 alamat (www.domain.tld dan www2.domain.tld). Konfigurasikan www2 (yang sama dengan www) dan atur catatan DNS yang benar. Kemudian siapkan versi www situs Anda dan lakukan pergantian DNS. Tetapkan pengalihan semua permintaan di server lama ke subdomain www2.

Yarik Dot
sumber
Maukah Anda sedikit memperluas ini, atau dengan pointer ke artikel atau T / A yang bisa saya baca? Saya tidak memiliki akses root ke server yang ada jadi saya tidak bisa secara langsung memanipulasi tabel IP ... jadi mungkin ada cara alternatif?
CC
@ CC mungkin Anda memiliki akses untuk mengganti aplikasi Anda dengan instance HAProxy? Atau ganti kode aplikasi Anda dengan yang lain yang semata-mata meneruskan permintaan ke server baru?
Jason Martin
@JasonMartin - Saya memiliki akses ke .htaccess dan kode aplikasi. Jadi, ya saya mungkin bisa mengambil URL yang diminta dan meneruskan ke alamat IP baru - mungkin saya harus mencobanya?
CC
@ CC kedengarannya menjanjikan. DNS adalah alat yang 'pada akhirnya konsisten', dan beberapa server DNS menetapkan tingkat di TTL mereka dan akan mengabaikan 300-an Anda. Jika Anda ingin menghindari gangguan di sana, proxy penerusan adalah yang terbaik.
Jason Martin
4

Secara teori, mengatur TTL domain ke sesuatu yang rendah dan menunggu perubahan itu terjadi, kemudian mengubah IP, akan menghasilkan migrasi yang hampir transparan. Lagi pula, itulah inti dari TTL yang dapat dikonfigurasi.

Dalam praktiknya, orang salah mengonfigurasi hal-hal dan alat-alat rusak. Itu sebabnya Anda mungkin perlu memberikan instruksi kepada pengguna Anda untuk menghapus cache lokal mereka jika semuanya tidak berfungsi dengan benar.

Anda tidak melakukan kesalahan apa pun.

Lightness Races di Orbit
sumber
Haruskah saya segera beralih ke AWS Route 53 DNS baru - dengan alamat IP lama - lalu setelah migrasi dilakukan cukup ubah alamat IP ke yang baru? - atau hanya mengubah DNS ke yang baru dan mengubah IP pada saat yang sama?
CC
1
@ CC: Saya bukan administrator jaringan jadi ambil ini dengan sejumput garam (dan saya senang mendengar sebaliknya dari guru ServerFault), tapi saya pribadi merekomendasikan untuk tidak mengubah keduanya sekaligus. Dapatkan DNS Anda beres, kemudian lakukan perubahan IP dan biarkan DNS baru melakukan tugasnya dengan membantu Anda dengan bagian terakhir itu.
Lightness Races in Orbit
1
Yah saya mencoba percobaan. Satu situs, saya mengubah jam DNS sebelumnya, lalu mengubah alamat IP catatan A nanti. Bekerja dengan sempurna. Situs lain saya mengubah keduanya sekaligus. Itu meronta-ronta antara alamat IP lama / baru selama berjam-jam - Saya akhirnya menghapus zona AWS Route 53 dan kembali melakukannya dengan cara yang sama seperti situs pertama. Bekerja dengan sempurna. Jadi tidak perlu sedikit pun garam - Anda sangat tepat!
CC
1

Alamat lama Anda akan di-cache dan digunakan untuk waktu yang lama - kebanyakan oleh bot.

Bagaimana saya melakukannya:

  • Buat catatan A, misalnya www2.yourdomain.com, menunjuk ke IP baru. Catatan ini seharusnya tidak pernah digunakan sebelumnya; oleh karena itu tidak pernah di-cache.
  • Redirect kueri di server lama ke www2.yourdomain.com
  • Monitor pengalihan, dan ketika lalu lintas mereda ke tingkat yang dapat diterima, hapus server lama.
  • Dan akhirnya setelah server lama dihapus, redirect www2.yourdomain.comke www.yourdomain.com.

Pastikan untuk menggunakan 301 redirect permanen. https://en.wikipedia.org/wiki/HTTP_301

ClickLabs
sumber
Perasaan saya adalah bahwa dia seharusnya tidak menggunakan 301 untuk putaran pertama pengalihan, tetapi hanya untuk yang kedua. Apakah ada alasan khusus yang seharusnya diketahui oleh seseorang dengan kebijaksanaan SEO esoteris?
Acak832
@ Random832 Permanen memberi tahu agen pengguna untuk melupakan url lama dan mis. Memperbarui bookmark untuk menunjuk ke url baru (jadi lain kali, mereka mungkin mengakses url baru secara langsung). Tidak ada salahnya mengarahkan ulang lagi (atau bahkan kembali ke url asli). Redirect sementara di sisi lain memberitahu agen-pengguna untuk menjaga url asli (karena redirect mungkin terjadi pada target yang berbeda atau tidak sama sekali lain kali). Oleh karena itu dengan pengalihan sementara, pemantauan pengalihan tidak akan pernah jatuh ke "tingkat yang dapat diterima".
Hagen von Eitzen
@HagenvonEitzen Ini akan jatuh ke tingkat yang dapat diterima karena browser berhenti mendapatkan alamat IP server lama untuk www.domainanda.com, yang merupakan hal DNS dan tidak akan terpengaruh oleh jenis pengalihan HTTP yang digunakan. Dan "karena pengalihan mungkin terjadi ... tidak sama sekali lain kali" karena itu justru benar.
Acak832
0

Kedengarannya Anda berencana mengubah server nama Anda secara bersamaan? Karena cara server nama ditemukan, mereka membutuhkan waktu lebih lama untuk memperbarui daripada catatan biasa - sering kali sekitar 24 jam atau lebih lama.

Saya sangat menyarankan Anda memperbarui DNS di penyedia Anda saat ini sebelum mengubah DNS, atau mengubah server nama Anda 7 hari sebelum Anda mengubah IP situs web.

Komputer dan browser modern cukup andal dalam mematuhi TTL dengan DNS, tetapi Anda harus memahami keseluruhan rantai untuk hasil terbaik.

codatory
sumber
Terima kasih, dan ya ini mencerminkan komentar saya di bawah jawaban Lightness, di atas. Resolver memang menyegarkan nameserver dengan cepat - dalam beberapa menit. Kuncinya adalah melakukan itu terlebih dahulu, lalu tunggu beberapa jam sebelum mengubah alamat IP tujuan. Keduanya sekaligus adalah buruk ... sangat buruk.
CC