การวางแผนโครงสร้างพื้นฐานสำหรับการติดตั้ง Zimbra Collaboration Suite

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

การวางแผนโครงสร้างพื้นฐานสำหรับการติดตั้ง Zimbra Collaboration Suite

คุณสมบัติหลักของ Zimbra เมื่อเปรียบเทียบกับโซลูชันอื่นคือ ในกรณีของ ZCS คอขวดนั้นแทบจะไม่มีกำลังของโปรเซสเซอร์หรือ RAM ข้อจำกัดหลักคือความเร็วของอินพุตและเอาต์พุตของฮาร์ดไดรฟ์ ดังนั้นจึงควรให้ความสนใจหลักกับการจัดเก็บข้อมูล ข้อกำหนดขั้นต่ำที่ระบุไว้อย่างเป็นทางการสำหรับ Zimbra ในสภาพแวดล้อมการใช้งานจริงคือโปรเซสเซอร์ 4-core 64-บิต ที่มีความเร็วสัญญาณนาฬิกา 2 กิกะเฮิรตซ์, 10 กิกะไบต์สำหรับไฟล์ระบบและบันทึก และ RAM อย่างน้อย 8 กิกะไบต์ โดยทั่วไป คุณลักษณะเหล่านี้จะเพียงพอสำหรับเซิร์ฟเวอร์ในการทำงานแบบตอบสนอง แต่ถ้าคุณต้องใช้ Zimbra สำหรับผู้ใช้นับหมื่นคนล่ะ? เซิร์ฟเวอร์ใดและควรนำไปใช้อย่างไรในกรณีนี้

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

ดังนั้น เมื่อออกแบบโครงสร้างพื้นฐานสำหรับคน 10.000 คน คุณจะต้องสร้างเซิร์ฟเวอร์ LDAP, MTA และพร็อกซี และที่เก็บเมล 4 แห่ง โปรดทราบว่าเซิร์ฟเวอร์ LDAP, MTA และพร็อกซีสามารถสร้างเป็นเสมือนได้ วิธีนี้จะลดต้นทุนของฮาร์ดแวร์เซิร์ฟเวอร์และทำให้การสำรองและกู้คืนข้อมูลง่ายขึ้น แต่ในทางกลับกัน หากเซิร์ฟเวอร์จริงล้มเหลว คุณอาจเสี่ยงที่จะขาด MTA, LDAP และ Proxy ทันที นั่นคือเหตุผลที่ควรเลือกระหว่างเซิร์ฟเวอร์จริงหรือเซิร์ฟเวอร์เสมือนโดยพิจารณาจากระยะเวลาหยุดทำงานที่คุณสามารถทำได้ในกรณีฉุกเฉิน พื้นที่จัดเก็บเมลควรวางไว้บนเซิร์ฟเวอร์จริงดีที่สุด เนื่องจากรอบการเขียนส่วนใหญ่จะเกิดขึ้น ซึ่งจำกัดประสิทธิภาพของ Zimbra ดังนั้นช่องทางการถ่ายโอนข้อมูลจำนวนมากขึ้นจะช่วยเพิ่มประสิทธิภาพการทำงานของ Zimbra ได้อย่างมาก

โดยหลักการแล้ว หลังจากที่สร้าง LDAP, MTA, พร็อกซีเซิร์ฟเวอร์, ที่เก็บข้อมูลเครือข่าย และรวมไว้ในโครงสร้างพื้นฐานเดียวแล้ว Zimbra Collaboration Suite สำหรับผู้ใช้ 10000 รายก็พร้อมสำหรับการทดสอบใช้งาน การดำเนินการของการกำหนดค่านี้จะค่อนข้างง่าย:

การวางแผนโครงสร้างพื้นฐานสำหรับการติดตั้ง Zimbra Collaboration Suite

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

วิธีการหลักคือความซ้ำซ้อนของฮาร์ดแวร์ ในกรณีที่เซิร์ฟเวอร์หลักล้มเหลว โหนด MTA และพร็อกซีเพิ่มเติมสามารถเข้ารับหน้าที่เป็นเซิร์ฟเวอร์หลักได้ชั่วคราว การทำซ้ำโหนดของโครงสร้างพื้นฐานที่สำคัญแทบจะเป็นแนวคิดที่ดีเสมอไป แต่ก็ไม่สามารถทำได้ในระดับที่ต้องการเสมอไป ตัวอย่างที่เด่นชัดคือการสำรองเซิร์ฟเวอร์ที่ใช้จัดเก็บเมล ในปัจจุบัน Zimbra Collaboration Suite Open-Source Edition ไม่รองรับการสร้างร้านค้าที่ซ้ำกัน ดังนั้นหากหนึ่งในเซิร์ฟเวอร์เหล่านี้ล้มเหลว ก็ไม่สามารถหลีกเลี่ยงการหยุดทำงานได้ และเพื่อลดเวลาหยุดทำงานที่เกิดจากความล้มเหลวของร้านเมล ผู้จัดการฝ่ายไอทีสามารถติดตั้งสำเนาสำรองได้ บนเซิร์ฟเวอร์อื่น

เนื่องจากไม่มีระบบสำรองข้อมูลในตัวใน Zimbra OSE เราจึงจำเป็นต้องมี Zextras Backup ซึ่งรองรับการสำรองข้อมูลแบบเรียลไทม์และพื้นที่จัดเก็บข้อมูลภายนอก เนื่องจาก Zextras Backup เมื่อทำการสำรองข้อมูลแบบเต็มและแบบเพิ่มหน่วย จะใส่ข้อมูลทั้งหมดไว้ในโฟลเดอร์ /opt/zimbra/backup จึงสมเหตุสมผลที่จะติดตั้งที่เก็บข้อมูลภายนอก เครือข่าย หรือแม้แต่ระบบคลาวด์ลงไป ดังนั้นหากเซิร์ฟเวอร์ตัวใดตัวหนึ่งล้มเหลว คุณจะมีสื่อพร้อมสำเนาสำรองที่เป็นปัจจุบันในขณะเกิดเหตุฉุกเฉิน สามารถปรับใช้บนเซิร์ฟเวอร์กายภาพสำรอง บนเครื่องเสมือน หรือในระบบคลาวด์ เป็นความคิดที่ดีที่จะติดตั้ง MTA พร้อมตัวกรองสแปมที่ด้านหน้าเซิร์ฟเวอร์ Zimbra Proxy เพื่อลดปริมาณการรับส่งข้อมูลขยะที่มาถึงเซิร์ฟเวอร์

ด้วยเหตุนี้โครงสร้างพื้นฐานของ Zimbra ที่ได้รับการป้องกันจะมีลักษณะดังนี้:

การวางแผนโครงสร้างพื้นฐานสำหรับการติดตั้ง Zimbra Collaboration Suite

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

ที่มา: will.com

เพิ่มความคิดเห็น