ในหนึ่งของเรา ซึ่งอุทิศให้กับการวางแผนโครงสร้างพื้นฐานเมื่อใช้ Zimbra Collabortion Suite ในองค์กร กล่าวกันว่าข้อจำกัดหลักในการทำงานของโซลูชันนี้คือความเร็ว I/O ของอุปกรณ์ดิสก์ในพื้นที่จัดเก็บเมล แท้จริงแล้ว ในช่วงเวลาที่พนักงานหลายร้อยคนขององค์กรเข้าถึงพื้นที่จัดเก็บเมลเดียวกันพร้อมกัน ความกว้างของช่องทางในการเขียนและอ่านข้อมูลจากฮาร์ดไดรฟ์อาจไม่เพียงพอสำหรับการดำเนินการแบบตอบสนองของบริการ และหากการติดตั้ง Zimbra ขนาดเล็กจะไม่เป็นปัญหาเฉพาะ ในกรณีขององค์กรขนาดใหญ่และผู้ให้บริการ SaaS ทั้งหมดนี้สามารถนำไปสู่อีเมลที่ไม่ตอบสนองและเป็นผลให้ประสิทธิภาพของพนักงานลดลงตลอดจนการละเมิด ของ SLA ด้วยเหตุนี้เมื่อออกแบบและดำเนินการติดตั้ง Zimbra ขนาดใหญ่ จึงควรให้ความใส่ใจเป็นพิเศษในการเพิ่มประสิทธิภาพการทำงานของฮาร์ดไดรฟ์ในพื้นที่จัดเก็บเมล ลองดูสองกรณีแล้วลองค้นหาว่าวิธีการใดในการเพิ่มประสิทธิภาพโหลดบนที่เก็บข้อมูลดิสก์ที่สามารถนำมาใช้ในแต่ละกรณีได้
1. การเพิ่มประสิทธิภาพเมื่อออกแบบการติดตั้ง Zimbra ขนาดใหญ่
ในระหว่างขั้นตอนการออกแบบการติดตั้ง Zimbra ที่มีโหลดสูง ผู้ดูแลระบบจะต้องเลือกว่าจะใช้ระบบจัดเก็บข้อมูลใด เพื่อตัดสินใจเกี่ยวกับปัญหานี้ คุณควรทราบว่าโหลดหลักบนฮาร์ดไดรฟ์มาจาก MariaDB DBMS ที่รวมอยู่ใน Zimbra Collaboration Suite, โปรแกรมค้นหา Apache Lucene และพื้นที่เก็บข้อมูล Blob นั่นคือเหตุผลว่าทำไมในการใช้งานผลิตภัณฑ์ซอฟต์แวร์เหล่านี้ภายใต้สภาวะโหลดสูง จึงจำเป็นต้องใช้อุปกรณ์ความเร็วสูงและเชื่อถือได้
ภายใต้สภาวะปกติ Zimbra สามารถติดตั้งได้ทั้งบน RAID ของฮาร์ดไดรฟ์และบนที่เก็บข้อมูลที่เชื่อมต่อผ่านโปรโตคอล NFS สำหรับการติดตั้งที่มีขนาดเล็กมาก คุณสามารถติดตั้ง Zimbra บนไดรฟ์ SATA ทั่วไปได้ อย่างไรก็ตาม ในบริบทของการติดตั้งขนาดใหญ่ เทคโนโลยีทั้งหมดเหล่านี้แสดงให้เห็นถึงข้อเสียหลายประการในรูปแบบของความเร็วในการบันทึกที่ลดลงหรือความน่าเชื่อถือต่ำ ซึ่งเป็นที่ยอมรับไม่ได้สำหรับองค์กรขนาดใหญ่หรือโดยเฉพาะอย่างยิ่งสำหรับผู้ให้บริการ SaaS
นี่คือเหตุผลว่าทำไมในโครงสร้างพื้นฐานของ Zimbra ขนาดใหญ่ จึงควรใช้ SAN ดีที่สุด เป็นเทคโนโลยีนี้ที่สามารถให้ปริมาณงานสูงสุดสำหรับอุปกรณ์จัดเก็บข้อมูลและในเวลาเดียวกันด้วยความสามารถในการเชื่อมต่อแคชจำนวนมากการใช้งานจึงไม่ก่อให้เกิดความเสี่ยงที่สำคัญสำหรับองค์กร เป็นความคิดที่ดีที่จะใช้ NVRAM ซึ่งใช้ใน SAN หลายแห่งเพื่อเพิ่มความเร็วระหว่างการเขียน แต่จะเป็นการดีกว่าถ้าปิดใช้งานการแคชข้อมูลที่บันทึกไว้ในดิสก์ด้วยตนเองเนื่องจากอาจทำให้เกิดความเสียหายต่อสื่อที่แก้ไขไม่ได้และการสูญเสียข้อมูลหากเกิดปัญหาด้านพลังงาน
สำหรับการเลือกระบบไฟล์ ตัวเลือกที่ดีที่สุดคือการใช้ Linux Ext3/Ext4 มาตรฐาน ความแตกต่างหลักที่เกี่ยวข้องกับระบบไฟล์คือควรเมานต์ด้วยพารามิเตอร์ -noatime. ตัวเลือกนี้จะปิดการใช้งานฟังก์ชั่นการบันทึกเวลาของการเข้าถึงไฟล์ครั้งล่าสุดซึ่งหมายความว่าจะช่วยลดภาระในการอ่านและการเขียนได้อย่างมาก โดยทั่วไป เมื่อสร้างระบบไฟล์ ext3 หรือ ext4 สำหรับ Zimbra คุณควรใช้พารามิเตอร์ยูทิลิตี้ต่อไปนี้ mke2fs:
-j — เพื่อสร้างระบบไฟล์เจอร์นัล สร้างระบบไฟล์ด้วยเจอร์นัล ext3/ext4
-ชื่อ - เพื่อสร้างชื่อวอลุ่มเพื่อใช้ใน /etc/fstab
-O dir_index - หากต้องการใช้แผนผังการค้นหาแบบแฮชเพื่อเพิ่มความเร็วในการค้นหาไฟล์ในไดเร็กทอรีขนาดใหญ่
-m 2 — เพื่อสำรอง 2% ของโวลุ่มในระบบไฟล์ขนาดใหญ่สำหรับไดเร็กทอรีราก
-ขนาดเจ=400 — เพื่อสร้างนิตยสารขนาดใหญ่
-ข 4096 — เพื่อกำหนดขนาดบล็อกเป็นไบต์
-ฉัน 10240 - สำหรับการจัดเก็บข้อความ การตั้งค่านี้ควรสอดคล้องกับขนาดข้อความโดยเฉลี่ย คุณควรใส่ใจกับพารามิเตอร์นี้เป็นพิเศษ เนื่องจากค่าของมันไม่สามารถเปลี่ยนแปลงได้ในภายหลัง
ขอแนะนำให้เปิดใช้งานด้วย ไดร์ซิงค์ สำหรับที่เก็บข้อมูล Blob, ที่เก็บข้อมูลเมตาการค้นหา Lucene และที่เก็บข้อมูลคิว MTA ควรทำเช่นนี้เพราะโดยปกติแล้ว Zimbra จะใช้ยูทิลิตี้นี้ เอฟซิงค์ เพื่อการรับประกันการเขียนหยดพร้อมข้อมูลลงดิสก์ อย่างไรก็ตาม เมื่อที่เก็บเมลของ Zimbra หรือ MTA สร้างไฟล์ใหม่ระหว่างการส่งข้อความ จำเป็นต้องเขียนการเปลี่ยนแปลงที่เกิดขึ้นในโฟลเดอร์ที่เกี่ยวข้องลงดิสก์ นั่นคือสาเหตุแม้ว่าไฟล์จะถูกเขียนลงดิสก์แล้วก็ตาม เอฟซิงค์บันทึกการเพิ่มลงในไดเร็กทอรีอาจไม่มีเวลาเขียนลงดิสก์และอาจสูญหายเนื่องจากเซิร์ฟเวอร์ขัดข้องกะทันหัน ขอบคุณการใช้งาน ไดร์ซิงค์ ปัญหาเหล่านี้สามารถหลีกเลี่ยงได้
2. การเพิ่มประสิทธิภาพด้วยการทำงานของโครงสร้างพื้นฐานของ Zimbra
มักเกิดขึ้นหลังจากใช้ Zimbra เป็นเวลาหลายปี จำนวนผู้ใช้เพิ่มขึ้นอย่างมาก และบริการตอบสนองน้อยลงทุกวัน ทางออกจากสถานการณ์นี้ชัดเจน: คุณเพียงแค่ต้องเพิ่มเซิร์ฟเวอร์ใหม่ลงในโครงสร้างพื้นฐานเพื่อให้บริการทำงานได้อีกครั้งอย่างรวดเร็วเหมือนเมื่อก่อน ในขณะเดียวกัน เป็นไปไม่ได้เสมอไปที่จะเพิ่มเซิร์ฟเวอร์ใหม่ลงในโครงสร้างพื้นฐานทันทีเพื่อเพิ่มประสิทธิภาพ ผู้จัดการฝ่าย IT มักจะต้องใช้เวลานานในการประสานงานในการซื้อเซิร์ฟเวอร์ใหม่กับแผนกบัญชีหรือความปลอดภัย นอกจากนี้ พวกเขามักจะผิดหวังจากซัพพลายเออร์ที่สามารถส่งมอบเซิร์ฟเวอร์ใหม่ล่าช้าหรือแม้กระทั่งส่งมอบผิด
แน่นอนว่า วิธีที่ดีที่สุดคือสร้างโครงสร้างพื้นฐาน Zimbra ของคุณโดยมีการสำรองไว้เพื่อให้มีสำรองไว้สำหรับการขยายอยู่เสมอ และไม่ขึ้นอยู่กับใครก็ตาม อย่างไรก็ตาม หากเกิดข้อผิดพลาดขึ้น ผู้จัดการฝ่าย IT จะทำได้แค่แก้ไขผลที่ตามมาให้ราบรื่นเท่านั้น มากที่สุดเท่าที่จะเป็นไปได้ ตัวอย่างเช่น ผู้จัดการฝ่ายไอทีสามารถเพิ่มประสิทธิภาพการทำงานได้เล็กน้อยโดยการปิดใช้งานบริการระบบ Linux ชั่วคราวที่เข้าถึงฮาร์ดไดรฟ์เป็นประจำระหว่างการทำงาน และอาจส่งผลเสียต่อประสิทธิภาพของ Zimbra ดังนั้น คุณสามารถปิดใช้งานได้ชั่วคราว:
autofs, netfs - บริการค้นหาระบบไฟล์ระยะไกล
ถ้วย — บริการการพิมพ์
xinetd, vsftpd - บริการ *NIX ในตัวที่คุณอาจไม่ต้องการ
พอร์ตแมป, rpcsvcgssd, rpcgssd, rpcidmapd — บริการเรียกขั้นตอนระยะไกล ซึ่งโดยปกติจะใช้ร่วมกับระบบไฟล์เครือข่าย
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — การซ้ำซ้อนของยูทิลิตี้หลักที่รวมอยู่ใน Zimbra Collaboration Suite
เลื่อน/updatedb - เนื่องจาก Zimbra เก็บแต่ละข้อความไว้ในไฟล์แยกกัน การเรียกใช้บริการที่อัพเดตทุกวันอาจทำให้เกิดปัญหาได้ ดังนั้นจึงเป็นไปได้ที่จะดำเนินการด้วยตนเองในระหว่างที่มีการโหลดน้อยที่สุดบนเซิร์ฟเวอร์
การประหยัดทรัพยากรระบบอันเป็นผลมาจากการปิดใช้งานบริการเหล่านี้จะไม่มีความสำคัญมากนัก แต่ถึงแม้จะมีประโยชน์มากในสภาวะที่ใกล้เคียงกับเหตุสุดวิสัย เมื่อเพิ่มเซิร์ฟเวอร์ใหม่ลงในโครงสร้างพื้นฐานของ Zimbra ขอแนะนำให้เปิดใช้งานบริการที่ปิดใช้งานก่อนหน้านี้อีกครั้ง
คุณยังสามารถเพิ่มประสิทธิภาพการทำงานของ Zimbra ได้ด้วยการย้ายบริการ syslog ไปยังเซิร์ฟเวอร์อื่น เพื่อไม่ให้โหลดฮาร์ดไดรฟ์ของพื้นที่จัดเก็บเมลระหว่างการดำเนินการ คอมพิวเตอร์เกือบทุกเครื่องเหมาะสำหรับวัตถุประสงค์เหล่านี้ แม้แต่ Raspberry Pi บอร์ดเดี่ยวราคาถูกก็ตาม
ที่มา: will.com