אופטימיזציה של אחסון דואר ב-Zimbra Collaboration Suite

באחד שלנו מאמרים קודמים, המוקדש לתכנון תשתית בעת הטמעת Zimbra Collabortion Suite בארגון, נאמר כי המגבלה העיקרית בתפעול פתרון זה היא מהירות ה-I/O של התקני דיסק באחסון דואר. ואכן, בתקופה שבה כמה מאות עובדים של ארגון ניגשים בו-זמנית לאותו אחסון דואר, ייתכן שרוחב הערוץ לכתיבה וקריאה של מידע מכוננים קשיחים לא יספיק לתפעול רספונסיבי של השירות. ואם עבור התקנות קטנות של Zimbra זו לא תהיה בעיה מיוחדת, אז במקרה של ארגונים גדולים וספקי SaaS, כל זה יכול להוביל לאימייל לא מגיב וכתוצאה מכך לירידה ביעילות העובדים, כמו גם להפרה של SLAs. לכן, בעת תכנון והפעלה של התקנות זימברה בקנה מידה גדול, יש להקדיש תשומת לב מיוחדת לייעול הביצועים של כוננים קשיחים באחסון דואר. הבה נבחן שני מקרים וננסה לגלות אילו שיטות לייעול העומס על אחסון הדיסק ניתן ליישם בכל אחד מהם.

1. אופטימיזציה בעת תכנון מתקן זימברה בקנה מידה גדול

במהלך שלב התכנון של התקנת זימברה בעומס גבוה, המנהל יצטרך לבחור באיזו מערכת אחסון להשתמש. על מנת להחליט בסוגיה זו, עליך לדעת שהעומס העיקרי על כוננים קשיחים מגיע מ-MariaDB DBMS הכלולים בחבילת Zimbra Collaboration Suite, מנוע החיפוש Apache Lucene ו-Blob Storage. לכן על מנת להפעיל את מוצרי התוכנה הללו בתנאי עומס גבוה, יש צורך להשתמש בציוד מהיר ואמין.

בתנאים רגילים, ניתן להתקין את Zimbra הן על RAID של כוננים קשיחים והן על אחסון המחובר באמצעות פרוטוקול NFS. עבור התקנות קטנות מאוד, אתה יכול להתקין את Zimbra על כונן SATA רגיל. עם זאת, בהקשר של התקנות גדולות, כל הטכנולוגיות הללו מדגימות חסרונות שונים בדמות מהירות הקלטה מופחתת או אמינות נמוכה, דבר שאינו מקובל לא עבור ארגונים גדולים ולא, במיוחד עבור ספקי SaaS.

זו הסיבה שבתשתיות זימברה בקנה מידה גדול עדיף להשתמש ב-SAN. טכנולוגיה זו היא שמסוגלת כיום לספק את התפוקה הגדולה ביותר עבור התקני אחסון ובמקביל, הודות ליכולת לחבר כמות גדולה של מטמון, השימוש בה למעשה אינו מהווה סיכונים משמעותיים עבור הארגון. מומלץ להשתמש ב-NVRAM, המשמש ב-SAN רבים כדי להאיץ דברים במהלך הכתיבה. אבל עדיף להשבית את שמירה במטמון של נתונים מוקלטים על הדיסקים עצמם, שכן זה יכול להוביל לנזק בלתי הפיך למדיה ואובדן נתונים אם מתרחשות בעיות חשמל.

באשר לבחירת מערכת קבצים, הבחירה הטובה ביותר תהיה להשתמש ב-Linux Ext3/Ext4 הסטנדרטי. הניואנס העיקרי הקשור למערכת הקבצים הוא שיש להרכיב אותה עם הפרמטר -נואטיים. אפשרות זו תשבית את הפונקציה של רישום זמן הגישה האחרונה לקבצים, מה שאומר שהיא תפחית מאוד את העומס בקריאה ובכתיבה. באופן כללי, בעת יצירת מערכת קבצים ext3 או ext4 עבור Zimbra, עליך להשתמש בפרמטרי השירות הבאים mke2fs:

-j — ליצירת יומן מערכת קבצים צור את מערכת הקבצים עם יומן ext3/ext4.
-L שם - כדי ליצור שם אמצעי אחסון כדי להשתמש בו ב-/etc/fstab
-O dir_index - להשתמש בעץ חיפוש גיבוב כדי להאיץ חיפושי קבצים בספריות גדולות
-מ 2 - לשמור 2% מהנפח במערכות קבצים גדולות עבור ספריית השורש
-גודל J=400 - ליצור מגזין גדול
-ב 4096 - כדי לקבוע את גודל הבלוק בבתים
10240 - עבור אחסון הודעות, הגדרה זו צריכה להתאים לגודל ההודעה הממוצע. כדאי לשים לב היטב לפרמטר זה, מכיוון שלא ניתן לשנות את ערכו מאוחר יותר.

מומלץ גם להפעיל dirsync עבור אחסון בלובים, אחסון מטא נתונים של חיפוש Lucene ואחסון תור MTA. זה צריך להיעשות כי Zimbra בדרך כלל משתמש בכלי השירות fsync לכתיבה מובטחת של כתם עם נתונים לדיסק. עם זאת, כאשר חנות הדואר של Zimbra או MTA יוצרת קבצים חדשים במהלך מסירת ההודעות, יש צורך לכתוב לדיסק את השינויים המתרחשים בתיקיות המתאימות. זו הסיבה, גם אם הקובץ כבר נכתב לדיסק באמצעות fsync, ייתכן שלרשומה של הוספה לספרייה לא יהיה זמן להיכתב לדיסק, וכתוצאה מכך היא עלולה ללכת לאיבוד עקב כשל פתאומי בשרת. בזכות השימוש dirsync ניתן להימנע מבעיות אלו.

2. אופטימיזציה עם תשתית Zimbra פועלת

לא פעם קורה שאחרי מספר שנים של שימוש ב-Zimbra, מספר המשתמשים בה עולה משמעותית והשירות הופך פחות ופחות רספונסיבי מדי יום. הדרך לצאת מהמצב הזה ברורה: אתה רק צריך להוסיף שרתים חדשים לתשתית כדי שהשירות יחזור לעבוד מהר כמו קודם. בינתיים, לא תמיד ניתן להוסיף מיד שרתים חדשים לתשתית על מנת להגביר את הביצועים שלה. מנהלי IT נאלצים לעתים קרובות להשקיע זמן רב בתיאום רכישת שרתים חדשים עם מחלקת הנהלת החשבונות או האבטחה; בנוסף, הם לרוב מאוכזבים על ידי ספקים שיכולים לספק שרת חדש באיחור או אפילו לספק את הדבר הלא נכון.

כמובן, עדיף לבנות את תשתית הצימברה שלך עם רזרבה כדי שתהיה תמיד רזרבה להרחבתה ולא תלויה באף אחד, אולם אם כבר נעשתה טעות, מנהל ה-IT יכול רק להחליק את ההשלכות שלה שכן ככל האפשר. לדוגמה, מנהל IT יכול להשיג הגברת פרודוקטיביות קטנה על ידי השבתה זמנית של שירותי מערכת לינוקס הניגשים באופן קבוע לכוננים קשיחים במהלך הפעולה ולכן יכולים להשפיע לרעה על הביצועים של Zimbra. אז אתה יכול להשבית זמנית:

autofs, netfs - שירותי גילוי מערכת קבצים מרוחקים
כוסות - שירות הדפסה
xinetd, vsftpd - שירותי *NIX מובנים שכנראה לא תזדקק להם
portmap, rpcsvcgssd, rpcgssd, rpcidmapd - שירותי קריאת פרוצדורה מרחוק, המשמשים בדרך כלל בשילוב עם מערכות קבצים ברשת
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap - כפילויות של כלי העזר העיקריים הכלולים בחבילת Zimbra Collaboration
slocate/updatedb - מכיוון שזמברה מאחסנת כל הודעה בקובץ נפרד, הריצת שירות updatedb כל יום עלולה לגרום לבעיות, ולכן ניתן לעשות זאת באופן ידני בזמן העומס המינימלי על השרתים

חסכון במשאבי מערכת כתוצאה מהשבתת שירותים אלו לא יהיה משמעותי במיוחד, אך גם זה יכול להיות שימושי מאוד בתנאים הקרובים לכוח עליון. לאחר הוספת השרת החדש לתשתית Zimbra, מומלץ להפעיל מחדש את השירותים שהושבתו בעבר.

כמו כן, ניתן לייעל את פעולת זימברה על ידי העברת שירות ה-syslog לשרת נפרד כך שבזמן הפעולה הוא לא יטען את הכוננים הקשיחים של אחסון הדואר. כמעט כל מחשב מתאים למטרות הללו, אפילו Raspberry Pi זול בלוח יחיד.

מקור: www.habr.com