วิธีสร้างระบบ Postfix ที่มีความพร้อมใช้งานสูง


12

ฉันต้องการตั้งค่ามิเรอร์ระยะไกลสำหรับเซิร์ฟเวอร์ postfix (ซึ่งเนื้อหาของเมลเซิร์ฟเวอร์ทั้งสองควรเหมือนกันได้ตลอดเวลา)

แนวคิดคือหากเซิร์ฟเวอร์หลักล่มในบางจุดเซิร์ฟเวอร์มิรเรอร์จะเข้าแทนที่จัดการอีเมลขาเข้าใหม่และเมื่อเซิร์ฟเวอร์อีเมลขึ้นมาอีกครั้งจะอัปเดตด้วยอีเมลใหม่และส่งคืน มันเป็นตัวควบคุมในการจัดการจดหมายขาเข้าใหม่

เซิร์ฟเวอร์อีเมลจะถูกโฮสต์ในสถานที่ต่าง ๆ (เช่น maindomain.com, themirrorsite.com)

การรับเซิร์ฟเวอร์สำรองข้อมูลที่เรียบง่ายนั้นไม่ยากเกินไป:

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

มีวิธีที่จะทำให้การกำหนดค่าที่ต้องการสำเร็จหรือไม่?

คำตอบ:


22

ผลลัพธ์ที่คุณต้องการเพื่อให้บรรลุและลักษณะที่คุณตัดสินใจจะทำนั้นแตกต่างกันมาก สิ่งที่คุณต้องการนำไปใช้นั้นเป็นความคิดที่ไม่ดีและหากคุณสามารถจัดการให้มันทำงานได้มันจะไม่ทำงานนานมาก (หรือดีมาก)

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

อย่างไรก็ตามให้ฉันวางสถานการณ์สองสามอย่างเพื่อให้คุณได้ลิ้มรสสิ่งที่เป็นไปได้ในทางปฏิบัติและมีประโยชน์:

  • มั่นใจได้ว่าจะไม่มีจดหมายหาย: (ฉันไม่คิดว่านี่เป็นสิ่งที่คุณต้องการเนื่องจากเอกสารที่คุณอ้างถึงครอบคลุมเพียงพอ) สิ่งที่คุณต้องการที่นี่คือการรับประกันว่าไม่ว่าระยะเวลาในการส่งจดหมายและโครงสร้างพื้นฐานการจัดการของคุณจะไม่ลดลง ตีกลับจดหมายใด ๆ และคุณสามารถควบคุมได้เมื่อมีการส่งมอบ สำหรับสิ่งนี้ MX สำรองนอกไซต์ "แบบง่าย" จะทำงานได้อย่างเพียงพอ ฉันพูดว่า "ง่าย" เพราะคุณจำเป็นต้องทำซ้ำข้อมูลจำนวนมากไปยังการสำรองข้อมูล (ตรรกะการต่อต้านสแปมทั้งหมดข้อมูลผู้ใช้ / นามแฝงที่ถูกต้องเพื่อให้คุณสามารถตีกลับจดหมายที่ไม่ถูกต้องในเวลา SMTP สิ่งต่างๆ) แต่สคริปต์ทั้งหมด อัตโนมัติและใช้งานได้อย่างเป็นธรรมกับการดูแลเล็กน้อย ตราบใดที่คุณมีดิสก์เพียงพอที่จะจัดคิวจดหมายทั้งหมด
  • การรับรองความพร้อมใช้งานของระบบเมลแบบเต็ม : ดูเหมือนว่านี่คือสิ่งที่คุณต้องการ แต่ไม่ง่ายหรือสวย โดยทั่วไปคุณต้องการให้บริการอีเมล "เต็ม" กับฐานผู้ใช้ของคุณในกรณีที่ไซต์ล้มเหลวโดยสิ้นเชิง โดยหลักการแล้วสิ่งนี้เป็นไปไม่ได้เพราะการจำลองแบบไม่ได้เกิดขึ้นทันที แต่คุณสามารถได้รับความน่าเชื่อถือในระดับที่เหมาะสมอย่างน้อยที่สุด บิตยากไม่ใช่ MTA แม้ว่า; มันเป็นที่เก็บจดหมาย คุณจะต้องคิดหาวิธีในการจำลองการดำเนินการจัดเก็บเมลทั้งหมด (การส่งจดหมายใหม่การเปลี่ยนแปลงสถานะข้อความการลบ) ไปยังไซต์ที่สองในเวลาใกล้เคียงแบบเรียลไทม์ - และทำทั้งสองวิธี . คุณสามารถใช้ตัวเลือกที่ถูกของ rsync เป็นระยะ (ด้วยความเสี่ยงที่สิ่งใด ๆ ที่ทำตั้งแต่ rsync ล่าสุดจะหายไปตลอดกาลถ้าคุณต้องการ failover) หรือใช้เทคนิคการจำลองแบบไฟล์ - หรือบล็อกระดับต่างๆเพื่อลองและทำให้สิ่งต่าง ๆ ตรงกันแบบเรียลไทม์ (ลดปริมาณการสูญเสียข้อมูลเพื่อแลกกับการกำหนดค่าและการดำเนินการที่ซับซ้อนมากขึ้น) . ระบบเมลบางระบบมีการรองรับการจำลองแบบในตัวซึ่งทำให้ชีวิตง่ายขึ้น จากนั้นก็มีปัญหาทั้งหมดของการล้มเหลวและคุณจะทำอย่างไรแล้วล้มเหลวกลับซึ่งเป็นเรื่องที่ยากขึ้นอีกครั้งและในที่สุดคุณก็ต้องทดสอบเป็นระยะเพื่อให้แน่ใจว่าการอัปเกรดระบบปฏิบัติการของคุณนั้นทำได้ไม่นาน ทำลายอะไร ...

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

มีหลายครั้งที่คุณต้องการความพร้อมใช้งานสูงเป็นพิเศษและฉันได้สร้างระบบที่รับรองแล้ว แต่มันไม่ง่ายและในหลาย ๆ กรณีพวกเขาไม่คุ้มค่าซึ่งเป็นสิ่งที่เราต้องการ ใช่ฮานั้นเจ๋งและเซ็กซี่และคุณได้รับความเชื่อถือในการสร้างความซับซ้อนที่สูงตระหง่าน แต่เราไม่ได้อยู่ที่นี่เพื่อตีสองหน้าอัตตาจรของเรา เรามาที่นี่เพื่อส่งมอบคุณค่าทางธุรกิจและฉันขอโทษ แต่ Rube Goldberg มีคลัสเตอร์หลายเว็บไซต์พร้อมใช้งานสูงไม่น่าจะให้คุณค่ามากเท่ากับบริการอีเมลที่เรียบง่ายและมีประสิทธิภาพและเป็นครั้งคราว "เรา" ขออภัยที่ระบบจดหมายหยุดทำงานเราจะมีระบบให้บริการในอีกหนึ่งชั่วโมงโปรดแจ้งให้เราทราบหากมีกาแฟและมัฟฟินกับเรา "ประกาศ


2
ไม่สามารถพูดได้ดีกว่านี้
voretaq7

4
ขออภัยที่ฉันสามารถให้ +1 เดียว
mailq

ฉันคิดว่า NAS นั้นแก้ปัญหาการจัดเก็บและซิงค์เมลโดยทั่วไปใช่ไหม โดยเฉพาะอย่างยิ่งถ้าร้านค้าอีเมลของคุณมีขนาดใหญ่และคุณกำลังโฮสต์อีเมลสำหรับหลายโดเมน
เออร์นี่

ไม่ NAS เป็นเรื่องเกี่ยวกับ 5% ของปัญหาทั้งหมดและทำสิ่งที่ไม่ดีต่อประสิทธิภาพและความสามารถในการปรับขนาดของคุณ
womble

1

คุณสามารถทำได้โดย MX DNS failover + ระบบจำลองข้อมูล

สำหรับ MX failover: สองเมลเซิร์ฟเวอร์ต้องการความช่วยเหลือในการกำหนดค่า dns สำหรับแบ็กอัพ

สำหรับการจำลองข้อมูล: http://www.drbd.org/docs/install/

- $


drbd จะทำงานกับเซิร์ฟเวอร์ที่ไม่ได้อยู่ใน LAN เดียวกันหรือไม่ เซิร์ฟเวอร์หลักและเซิร์ฟเวอร์ที่ล้มเหลวควรสื่อสารผ่านอินเทอร์เน็ตเท่านั้นดังนั้นฉันจึงไม่แน่ใจว่าจะใช้งานได้หรือไม่
VanHackman

DRBD มีผลิตภัณฑ์พร็อกซี่ที่เป็นกรรมสิทธิ์ซึ่งปรับปรุงการจำลองแบบ WAN อย่างมาก มันไม่ถูกและไม่รับประกันว่าจะทำให้ทุกสิ่งทันสมัยอยู่เสมอ
womble

1

ฉันใช้dbmailเพื่อให้ได้โซลูชันที่คล้ายกัน dbmail เก็บอีเมลทั้งหมดไว้ในฐานข้อมูล คุณสามารถตั้งค่าการจำลองแบบฐานข้อมูลเพื่อให้แน่ใจว่าอีเมลของคุณจะถูกเก็บไว้ในสถานที่ห่างไกล ทำให้การจัดการระบบอีเมลมีความซับซ้อนมากขึ้นเนื่องจากคุณต้องจัดการฐานข้อมูลและอีเมล


0

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


3
Mirroring Postfix เป็นวิธีที่ง่าย แต่นั่นไม่ใช่ปัญหา สิ่งที่ยากคือวิธีการซิงโครไนซ์ที่เก็บเมล (mbox หรือ Maildir) การจัดเก็บเมลบน NFS สำหรับ IMAP นั้นแทบจะเป็นไปไม่ได้และนำไปสู่การล้มเหลวในจุดเดียวอีกครั้ง
mailq
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.