Score:2

ย้ายเว็บเซิร์ฟเวอร์ไปยังศูนย์ข้อมูลใหม่และ IP ใหม่

ธง in

ฉันมีเว็บเซิร์ฟเวอร์ที่โฮสต์โดเมนมากกว่า 200 โดเมน แต่จำเป็นต้องย้ายไปยังศูนย์ข้อมูลอื่นและรับที่อยู่ IP ใหม่ แต่เนื่องจากการตั้งค่า DNS ทั้งหมดต้องอัปเดตด้วยตนเอง ฉันจึงคิดว่าคุณสามารถตั้งค่าพร็อกซีแบบโปร่งใสที่ที่อยู่ IP เก่าที่ส่งต่อการรับส่งข้อมูล http/https ทั้งหมดไปยัง IP ใหม่ได้หรือไม่ ดังนั้นผู้เยี่ยมชมจึงไม่พบว่าการย้ายไปยัง DNS กำลังได้รับการแก้ไข

ความคิดแรกของฉันคือการใช้ nginx แต่คิดว่ามันจะทำให้เกิดปัญหากับใบรับรอง SSL ในโดเมน มีวิธีที่ดีในการแก้ปัญหาหรือไม่?

cn flag
เราพูดถึงที่อยู่ IP จำนวนเท่าใด หนึ่ง? แล้วทำไมคุณถึงไม่ใช้ CNAME เพื่อที่การเปลี่ยนแปลงง่ายๆ จะเปลี่ยนเส้นทางโดเมนทั้งหมด
djdomi avatar
za flag
ในตอนแรกให้ลด ttl ของบันทึกใด ๆ ให้เหลือน้อยที่สุด หลังจากนั้นรอ 3-5 วัน ตรวจสอบว่า ทำการซิงค์เริ่มต้นของเซิร์ฟเวอร์เก่าของคุณกับเซิร์ฟเวอร์ใหม่ ตั้งค่าชื่อโดเมนในเครื่องเป็น IP ใหม่ผ่านโฮสต์เพื่อค้นหาข้อผิดพลาด โดยปกติจะไม่สร้างปัญหาใด ๆ ที่จะมีใบรับรองเดียวกันบน 2 เซิร์ฟเวอร์พร้อมกัน ตรวจสอบ และถ้าไม่เป็นไร คุณสามารถเปลี่ยนรายการจริงได้ เตือนให้ลบรายการโฮสต์
Guntram Blohm avatar
in flag
สมมติว่าเซิร์ฟเวอร์ของคุณใช้ linux คุณไม่จำเป็นต้องเรียกใช้ nginx เพียงเรียกใช้บางอย่างเช่น `socat -T 900 TCP-LISTEN:443,reuseaddr,fork TCP-CONNECT:newserver:443` บนเซิร์ฟเวอร์เก่า (ตรวจสอบให้แน่ใจว่ารีสตาร์ท รอดจากการรีบูต ...) ซึ่งจะส่งต่อการเชื่อมต่อบนพื้นฐาน TCP และช่วยให้คุณไม่ต้องปวดหัวกับการกำหนดค่า nginx ให้ถูกต้อง
Score:5
ธง us

ฉันใช้กระบวนการย้ายข้อมูลต่อไปนี้ในกรณีเหล่านี้:

  1. เปลี่ยน DNS TTL เป็นค่าต่ำสุด
  2. รอให้ DNS TTL อัปเดต
  3. คัดลอกคีย์ / ใบรับรองไปยังเซิร์ฟเวอร์ใหม่
  4. ทำให้ไซต์เข้าสู่โหมดการบำรุงรักษา
  5. ซิงโครไนซ์ไฟล์/ฐานข้อมูลกับเซิร์ฟเวอร์ใหม่
  6. ตั้งค่าพร็อกซีย้อนกลับจากเซิร์ฟเวอร์เก่าไปยังเซิร์ฟเวอร์ใหม่
  7. ลบโหมดการบำรุงรักษาบนเซิร์ฟเวอร์ใหม่
  8. เปลี่ยนรายการ DNS เพื่อชี้ไปยังเซิร์ฟเวอร์ใหม่

ขั้นตอนที่ 6 ตรวจสอบให้แน่ใจว่าผู้ใช้ปลายทางไม่ได้ลงเอยที่เซิร์ฟเวอร์เก่า แม้ว่า DNS ของพวกเขาจะแก้ไขเป็น IP ของเซิร์ฟเวอร์เก่าแล้วก็ตาม

หลังจากนี้ ให้ตรวจสอบบันทึกเซิร์ฟเวอร์เก่าเพื่อดูว่าการรับส่งข้อมูลหยุดลงเมื่อใด จากนั้นคุณสามารถรื้อการตั้งค่าเก่าได้

ตั้งค่าพร็อกซีย้อนกลับโดยใช้ proxy_pass คำสั่ง หากที่อยู่ IP ของผู้ใช้ปลายทางเป็นข้อมูลที่สำคัญ คุณต้องเพิ่มลงในส่วนหัว HTTP บนเซิร์ฟเวอร์เก่า -> คำขอเซิร์ฟเวอร์ใหม่ และบอกเซิร์ฟเวอร์ใหม่ให้ใช้ค่าส่วนหัวเป็นที่อยู่ IP

The Tech Guy avatar
in flag
มันค่อนข้างเป็นไปในทิศทางที่ฉันคิดไว้ แต่ไม่คิดว่าฉันจะหาวิธีจัดการส่วน https ได้โดยไม่ต้องติดตั้งใบรับรอง SSL ทั้งหมดบนพร็อกซีเซิร์ฟเวอร์ เพราะที่ไหนสักแห่งไม่ต้องการข้อมูลจริงๆ แต่เพียงอย่างเดียว ต้องรับและส่งต่อข้อมูล ต้องเป็นทราฟฟิกทั้ง 80/HTTP และ 443/HTTPS
us flag
คุณอาจใช้โมดูล nginx `stream` เพื่อส่งต่อการเชื่อมต่อ TCP ตามที่เป็นไปยังเซิร์ฟเวอร์ใหม่ ในกรณีนั้นเซิร์ฟเวอร์ใหม่เท่านั้นที่ต้องการใบรับรองทั้งหมด
Score:2
ธง ng

ก่อนอื่นคุณอาจต้องการตัดสินใจ (หรือประมาณการ) ว่าคุณต้องการเสียสละอะไรเมื่อคุณจะย้าย:

  1. ความง่ายดายในการเปลี่ยนแปลง (หากหลายประเด็นด้านล่างมีความสำคัญ การเปลี่ยนแปลงจะเป็นโครงการแทนที่จะเป็นงาน คุณอาจไม่มีความเชี่ยวชาญที่จำเป็นเช่นกัน)
  2. เวลาหยุดทำงาน (เป็นไปได้ไหมที่จะดำเนินการเปลี่ยนแปลงทั้งหมดในเวลากลางคืนหรือเมื่อกิจกรรมของผู้ใช้ของคุณน้อยที่สุด)
  3. ความสอดคล้องของบันทึกการเข้าถึง (อาจค่อนข้างสำคัญและพร็อกซี http หรือ tcp จะปกปิดที่อยู่ IP ระยะไกล)
  4. ความสอดคล้องของข้อมูลที่แสดงต่อผู้ใช้ (ผู้ใช้บางคนยอมรับได้หรือไม่ที่จะเห็นข้อมูลเก่า)
  5. ความเป็นไปได้ของการอัปเดตเนื้อหาชั่วขณะหนึ่ง
  6. ความปลอดภัยของข้อมูล (ในบางกรณี สิ่งสำคัญคือต้องรักษาข้อมูลให้ปลอดภัยจากความเสียหายและ/หรือการรั่วไหล แม้ว่าจะหมายถึงการหยุดทำงานก็ตาม)
  7. เวลาที่มีอยู่ (สัญญาโฮสติ้งของคุณหมด)
  8. ความสอดคล้องของเซสชันผู้ใช้ (ซึ่งรวมอยู่ในจุดที่ 4 อย่างเป็นทางการ แต่สมควรได้รับการพิจารณาเพิ่มเติมเนื่องจากการบรรเทาที่เป็นไปได้ที่แตกต่างกัน)

ขึ้นอยู่กับการรวมกันของด้านบน คุณอาจต้องการใช้อย่างน้อยหนึ่งรายการเหล่านี้:

  • พร็อกซี TCP (เช่น socat)
  • พร็อกซี HTTP (nginx, ปลาหมึก, ฯลฯ ... )
  • โซลูชันการกำหนดเส้นทาง/VPN ที่ซับซ้อนเพื่อให้เซิร์ฟเวอร์เดียวตอบสนองต่อคำขอที่อยู่ IP 2 แห่ง
  • การจำลองฐานข้อมูล
  • การโยกย้ายเครื่องเสมือน

สิ่งที่คุณต้องการไม่ว่าจะเลือกกลยุทธ์ใดก็ตาม ได้แก่:

  1. การลด DNS TTL (คุณสามารถเพิ่มกลับได้หลังจากทุกอย่างพร้อม)
  2. การสำรองข้อมูล - ใช่ สิ่งเลวร้ายมักเกิดขึ้นระหว่างการเปลี่ยนผ่านและการย้ายข้อมูล
  3. แผน
  4. แผนการย้อนกลับหากแผนการเปลี่ยนผ่านล้มเหลว
cn flag
+1 สำหรับการกล่าวถึงปัญหาการย้ายฐานข้อมูลสด (หรือ VM) นี่เป็นส่วนที่ยากในการย้ายไซต์โดยไม่รบกวนผู้ใช้และเสี่ยงต่อข้อมูลสูญหาย ฉันมีประสบการณ์ที่ดีกับ MySQL และการจำลองแบบเป็นวงกลมสำหรับสิ่งนี้ หากทำได้ถูกต้องก็ไม่จำเป็นต้องเร่งรัดขั้นตอนใดๆ
cn flag
อีกหนึ่งรายการ: ความสอดคล้องของเซสชันผู้ใช้ หากเซสชันถูกจัดเก็บไว้ในฐานข้อมูล สิ่งนี้จะครอบคลุมแต่เช่น เซสชันตามไฟล์/เรดิสต้องการการย้ายข้อมูลของตนเอง หรือผู้ใช้ที่ใช้งานอยู่จะพบว่าเซสชันนั้นหยุดทำงานทันทีที่พวกเขาเริ่มพูดคุยกับโฮสต์ใหม่
Score:0
ธง in

อีกทางเลือกหนึ่งคือการใช้ NAT, VPN และการกำหนดเส้นทางนโยบายร่วมกัน

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

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา