วิธีที่ดีที่สุดในการเปลี่ยนที่อยู่ IP ของเว็บไซต์จากมุมมองของผู้ใช้

10

ฉันได้อ่านคำถามที่เกี่ยวข้องมากมายที่นี่ แต่ฉันยังไม่แน่ใจว่าคำตอบที่ดีที่สุดคืออะไร

ฉันกำลังย้ายเว็บไซต์สองสามแห่งจากที่อยู่ IP "1.abc" เป็น "2.def" ณ ตอนนี้ใน DNS ที่มีอยู่ฉันตั้งค่า TTL ทั้งหมดเป็น 300 วินาทีและฉันมีโซน DNS ใหม่ที่พร้อมใช้งาน (บน AWS Route 53) พร้อมเนมเซิร์ฟเวอร์ใหม่และ TTL ทั้งหมดที่ 60 วินาที ดังนั้นฉันเชื่อว่าฉันพร้อมแล้วจากมุมมอง DNS หลังจากย้ายไปไม่กี่วันฉันจะตั้งค่า TTL เป็นตัวเลขที่สมเหตุสมผลมากขึ้นที่ถนนหมายเลข 53

ฉันได้เตือนผู้ใช้ของฉันเกี่ยวกับการย้ายและฉันมีหน้าต่างเวลาที่กำหนดสำหรับการย้าย ฉันบอกพวกเขาว่าเมื่อการย้ายเสร็จสมบูรณ์และถ้าหากผ่านไป 24 ชั่วโมงแล้วและพวกเขายังคงเห็นไซต์เก่า (ถูกล็อก) พวกเขาควรรีบูตคอมพิวเตอร์เพื่อบังคับให้แคช DNS ในเครื่องไม่ทำงาน

ฉันไม่เข้าใจว่าเบราว์เซอร์ผู้ใช้ (แคช) มีบทบาทอย่างไรในเรื่องนี้ การทดลองของฉันกับไฟล์โฮสต์ในเครื่อง (Win7) บอกฉันว่ามีบางอย่างเกี่ยวกับเบราว์เซอร์ที่ไม่ปล่อยให้ที่อยู่ IP เก่าไป - ฉันต้องไปที่ประวัติ -> ล้างข้อมูลทุกอย่างเพื่อให้ได้ตำแหน่งไซต์ใหม่เพื่อแสดง ขึ้นแม้หลังจากipconfig /flushdns

(แก้ไข) - ฉันไม่มีสิทธิ์เข้าถึงรูทไปยังเซิร์ฟเวอร์เก่าดังนั้นฉันจึงไม่สามารถใช้คำตอบที่ได้รับการยอมรับสำหรับคำถามนี้

คำถาม: ฉันไม่ต้องการให้ผู้ใช้ของฉันต้องจัดการกับสิ่งนั้นดังนั้นจึงมีสิ่งที่ฉันสามารถทำได้เพื่อบังคับให้เบราว์เซอร์ทั้งหมดออกจากแคชอีกครั้งหรือไม่ และถ้าเป็นเช่นนั้นฉันจะเปิดทิ้งไว้นานเท่าใด

ขอบคุณ ...

domain-name-system migration

— CC
แหล่งที่มา

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 go

คุณสามารถให้ข้อมูลเกี่ยวกับเรื่องนี้ได้ไหม? ส่วนเบราว์เซอร์ไม่ได้แคชระเบียน DNS นานกว่า 1 นาที

— Tanmay

ไม่แน่ใจ แต่หลังจากหลาย ipconfig / flushdns และ "ctrl-F5" (ใน Firefox) ฉันยังคงได้รับหน้าจากทั้งเว็บไซต์เก่าและเว็บไซต์ใหม่ ... ในที่สุดก็ต้องล้าง "ทุกอย่าง" และเริ่มใหม่ เบราว์เซอร์ ฉันไม่ต้องการให้ผู้ใช้ของฉันต้องทำสิ่งที่คล้ายกัน ...

— CC

JBTW โซลูชันในลิงก์ที่คุณให้สามารถทำงานได้หากคุณมีสิทธิ์เข้าถึงรูทไปยังเซิร์ฟเวอร์ใหม่ อัปเดตระเบียน DNS และส่งต่อการรับส่งข้อมูลทั้งหมดจากไปยังเซิร์ฟเวอร์ใหม่ไปยังเซิร์ฟเวอร์เก่าจนกระทั่ง DNS แพร่กระจายอย่างถูกต้อง

— Tanmay

ขอบคุณ ... แต่ฉันจะต้องซิงค์ข้อมูลเก่ากลับไปยังใหม่ (ฐานข้อมูล ฯลฯ ) อีกครั้งในภายหลังใช่ไหม

— CC

คุณจะต้องซิงค์ฐานข้อมูลหนึ่งครั้งก่อนที่จะปิดการส่งต่อ

— Tanmay

15

ไม่คุณไม่สามารถ ปัญหาคือการตอบสนอง DNS สามารถแคชที่ใดก็ได้ระหว่างผู้ใช้และเซิร์ฟเวอร์ DNS และไม่มีทางที่จะทำให้พวกเขาถูกต้อง

อย่างไรก็ตามสิ่งที่คุณสามารถทำได้ - ทันทีที่คุณมีข้อมูลที่ซิงค์และไซต์ที่สองของคุณพร้อมคุณสามารถกำหนดค่าเซิร์ฟเวอร์ดั้งเดิมให้ทำหน้าที่เป็นพร็อกซีและส่งคำขอทั้งหมดไปยังตำแหน่งใหม่

ด้วยวิธีนี้คุณจะสามารถทำให้เว็บไซต์ของคุณหยุดทำงานได้เกือบ 0 วินาที

ปรับปรุง

หากคุณไม่มีสิทธิ์เข้าถึงรูทมีหลายตัวเลือก:

ดำเนินการมอบฉันทะใน PHP
กำหนดค่าพร็อกซีบนเซิร์ฟเวอร์ที่สอง (ถ้าคุณมีการเข้าถึงรูท), เปลี่ยน DNS และเมื่อคุณพร้อมเปลี่ยนพร็อกซีเป็นเว็บเซิร์ฟเวอร์
วิธีนี้อาจเป็นสาเหตุของปัญหามี 2 ที่อยู่ (www.domain.tld และ www2.domain.tld) กำหนดค่า www2 (ซึ่งเหมือนกับ www) และตั้งค่าระเบียน DNS ที่ถูกต้อง จากนั้นเตรียมรุ่น www ของไซต์ของคุณและทำการสลับ DNS ตั้งค่าการเปลี่ยนเส้นทางของคำขอทั้งหมดบนเซิร์ฟเวอร์เก่าไปยังโดเมนย่อย www2

— Yarik Dot
แหล่งที่มา

คุณจะช่วยขยายจุดเล็ก ๆ นี้หรือชี้ไปยังบทความหรือ Q / A ที่ฉันสามารถอ่านได้หรือไม่? ฉันไม่มีสิทธิ์เข้าถึงรูทไปยังเซิร์ฟเวอร์ที่มีอยู่แล้วดังนั้นฉันจึงไม่สามารถจัดการตาราง IP โดยตรง ... ดังนั้นอาจมีวิธีอื่นหรือไม่

— CC

@CC บางทีคุณสามารถเข้าถึงเพื่อแทนที่แอปพลิเคชันของคุณด้วยอินสแตนซ์ HAProxy ได้หรือไม่ หรือแทนที่รหัสแอปพลิเคชันของคุณด้วยรหัสอื่นที่ส่งต่อคำขอไปยังเซิร์ฟเวอร์ใหม่อย่างหมดจดหรือไม่

— Jason Martin

@JasonMartin - ฉันมีสิทธิ์เข้าถึง. htaccess และรหัสแอปพลิเคชัน ใช่ฉันอาจจับ URL ที่ร้องขอและส่งต่อไปยังที่อยู่ IP ใหม่ - บางทีฉันควรลองดู

— CC

@ CC ที่มีแนวโน้มแล้ว DNS เป็นเครื่องมือ 'ในที่สุดสอดคล้องกัน' และเซิร์ฟเวอร์ DNS บางตัวตั้งค่าขั้นใน TTL และจะเพิกเฉยต่อ 300 ของคุณ หากคุณต้องการหลีกเลี่ยงการหยุดชะงักที่นั่นพร็อกซีการส่งต่อเป็นทางออกที่ดีที่สุด

— Jason Martin

4

ในทางทฤษฎีแล้วการตั้งค่า TTL ของโดเมนให้อยู่ในระดับต่ำและรอให้การเปลี่ยนแปลงนั้นเกิดขึ้นจากนั้นจึงเปลี่ยน IP น่าจะส่งผลให้เกิดการโยกย้ายอย่างใกล้ชิด ท้ายที่สุดนั่นคือจุดรวมทั้งหมดของ TTL ที่สามารถกำหนดค่าได้

ในทางปฏิบัติผู้คนกำหนดค่าสิ่งต่าง ๆ และเครื่องมือผิดพลาด นั่นเป็นเหตุผลที่คุณอาจต้องให้คำแนะนำแก่ผู้ใช้ของคุณในการล้างแคชในตัวเครื่องหากสิ่งที่ใช้ไม่ได้

คุณไม่ได้ทำอะไรผิด

— Lightness Races ในวงโคจร
แหล่งที่มา

ฉันควรเปลี่ยนไปใช้ AWS Route 53 DNS ใหม่ทันทีด้วยที่อยู่ IP เก่าแล้วหลังจากย้ายข้อมูลเสร็จแล้วเพียงแค่เปลี่ยนที่อยู่ IP เป็นที่อยู่ใหม่ - หรือเพียงแค่เปลี่ยน DNS เป็นใหม่และเปลี่ยน IP ในเวลาเดียวกันได้หรือไม่

— CC

1

@CC: ฉันไม่ได้เป็นผู้ดูแลระบบเครือข่ายดังนั้นเอาสิ่งเล็ก ๆ น้อย ๆ (และฉันยินดีที่จะได้ยินอย่างอื่นจากปรมาจารย์ ServerFault) แต่ฉันขอแนะนำว่าไม่ควรเปลี่ยนทั้งสองอย่างพร้อมกัน ทำให้ DNS ของคุณแยกออกจากนั้นทำการเปลี่ยนแปลง IP และให้ DNS ใหม่ทำงานได้โดยช่วยคุณในส่วนสุดท้าย

— การแข่งขัน Lightness ใน Orbit

1

ฉันลองทดสอบดู หนึ่งไซต์ฉันเปลี่ยน DNS ก่อนล่วงหน้าจากนั้นเปลี่ยนที่อยู่ IP ของเรคคอร์ดในภายหลัง ทำงานได้อย่างสมบูรณ์แบบ เว็บไซต์อื่นที่ฉันเปลี่ยนทั้งสองในครั้งเดียว มันน่าตื่นเต้นระหว่างที่อยู่ IP เก่า / ใหม่เป็นเวลาหลายชั่วโมง - ในที่สุดฉันก็ลบโซน AWS Route 53 และทำเช่นเดียวกันกับไซต์แรก ทำงานได้อย่างสมบูรณ์แบบ ดังนั้นไม่จำเป็นต้องใช้เกลือนิดหน่อย - คุณเป็นที่รู้จัก

— CC

1

ที่อยู่เก่าของคุณจะถูกแคชและใช้เป็นเวลานานอย่างหลีกเลี่ยงไม่ได้

ฉันจะทำอย่างไร:

สร้างระเบียน A ตัวอย่างเช่นwww2.yourdomain.comชี้ไปที่ IP ใหม่ ไม่ควรใช้บันทึกนี้มาก่อน จึงไม่เคยแคช
เปลี่ยนเส้นทางการสืบค้นบนเซิร์ฟเวอร์เก่าไปที่ www2.yourdomain.com
มอนิเตอร์การเปลี่ยนเส้นทางและเมื่อปริมาณการใช้ข้อมูลลดลงสู่ระดับที่ยอมรับได้ให้ลบเซิร์ฟเวอร์เก่าออก
และในที่สุดก็ครั้งเดียวเซิร์ฟเวอร์เก่าจะถูกเอาออกเปลี่ยนเส้นทางไปยังwww2.yourdomain.comwww.yourdomain.com

ตรวจสอบให้แน่ใจว่าใช้การเปลี่ยนเส้นทางถาวร 301 ครั้ง https://en.wikipedia.org/wiki/HTTP_301

— ClickLabs
แหล่งที่มา

ความรู้สึกของฉันคือว่าเขาไม่ควรใช้ 301 สำหรับการเปลี่ยนเส้นทางในรอบแรก แต่เฉพาะสำหรับวินาที มีเหตุผลใดที่เขาควรที่จะรู้จักกับคนที่มีความรู้เรื่อง SEO ที่ลึกลับเท่านั้น?

— Random832

@ Random832 ถาวรบอกให้ตัวแทนผู้ใช้ลืมเกี่ยวกับ URL เก่าและเช่นอัปเดตที่คั่นหน้าเพื่อชี้ไปที่ URL ใหม่ (ดังนั้นในครั้งต่อไปพวกเขาอาจเข้าถึง URL ใหม่โดยตรง) ไม่มีอันตรายใด ๆ ในการเปลี่ยนเส้นทางในภายหลังอีกครั้ง (หรือแม้แต่กลับไปที่ URL ดั้งเดิม) การเปลี่ยนเส้นทางชั่วคราวในทางกลับกันจะบอกให้ user-agent เก็บ url ดั้งเดิมไว้ (เพราะการเปลี่ยนเส้นทางอาจเกิดขึ้นกับเป้าหมายอื่นหรือไม่ในคราวถัดไป) ดังนั้นด้วยการเปลี่ยนเส้นทางชั่วคราวการตรวจสอบการเปลี่ยนเส้นทางจะไม่ตกอยู่ใน "ระดับที่ยอมรับได้"

— Hagen von Eitzen

@HagenvonEitzen มันจะลดลงไปอยู่ในระดับที่ยอมรับได้เนื่องจากเบราว์เซอร์หยุดรับที่อยู่ IP ของเซิร์ฟเวอร์เก่าสำหรับ www.yourdomain.com ซึ่งเป็นสิ่ง DNS และจะไม่ได้รับผลกระทบจากการเปลี่ยนเส้นทาง HTTP ที่ใช้ และ "เนื่องจากการเปลี่ยนเส้นทางอาจเกิดขึ้น ... ไม่ได้เลยในครั้งต่อไป" จึงเป็นความจริงอย่างแม่นยำ

— Random832

0

ดูเหมือนว่าคุณกำลังวางแผนจะเปลี่ยนเนมเซิร์ฟเวอร์ของคุณในเวลาเดียวกันใช่ไหม เนื่องจากวิธีการค้นพบเซิร์ฟเวอร์ชื่อพวกเขาใช้เวลาในการอัปเดตมากกว่าบันทึกปกติบ่อยครั้งประมาณ 24 ชั่วโมงหรือนานกว่านั้น

ฉันขอแนะนำให้คุณอัปเดต DNS ที่ผู้ให้บริการปัจจุบันของคุณก่อนที่จะเปลี่ยน DNS หรือเปลี่ยนเนมเซิร์ฟเวอร์ของคุณ 7 วันก่อนที่คุณจะเปลี่ยนเว็บไซต์ IP

คอมพิวเตอร์และเบราว์เซอร์ที่ทันสมัยมีความน่าเชื่อถือในการเชื่อฟัง TTL กับ DNS แต่คุณต้องเข้าใจทั้งเครือข่ายเพื่อให้ได้ผลลัพธ์ที่ดีที่สุด

— codatory
แหล่งที่มา

ขอบคุณและใช่สิ่งนี้สะท้อนความคิดเห็นของฉันภายใต้คำตอบของ Lightness ข้างต้น ตัวแก้ปัญหาทำการรีเฟรชเนมเซิร์ฟเวอร์อย่างรวดเร็ว - ภายในไม่กี่นาที กุญแจสำคัญคือต้องทำก่อนจากนั้นรอสองสามชั่วโมงก่อนเปลี่ยนที่อยู่ IP ปลายทาง ทั้งสองครั้งไม่ดี ... แย่มาก

— CC