תכנון התשתית להתקנת חבילת Zimbra Collaboration

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

התכונה העיקרית של Zimbra בהשוואה לפתרונות אחרים היא שבמקרה של ZCS, צוואר הבקבוק הופך לעתים רחוקות לאספקת מעבד או RAM. המגבלה העיקרית היא בדרך כלל מהירות הקלט והפלט של הדיסק הקשיח, ולכן יש לתת את עיקר תשומת הלב למאגרי נתונים. דרישות המינימום המוצהרות רשמית עבור Zimbra בסביבת ייצור הן מעבד 4 ליבות 64 סיביות עם מהירות שעון של 2 גיגה-הרץ, 10 גיגה-בייט לקבצי מערכת ויומנים ו-8 גיגה-בייט של זיכרון RAM. בדרך כלל, מאפיינים אלה מספיקים לתפעול שרת רספונסיבי. אבל מה אם אתה צריך ליישם את Zimbra עבור 10 משתמשים? אילו שרתים וכיצד יש ליישם במקרה זה?

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

לפיכך, בעת תכנון תשתית ל-10.000 איש, יהיה צורך ליצור שרתי LDAP, MTA ו-Proxy ו-4 אחסון דואר. שימו לב שניתן להפוך שרתי LDAP, MTA ו-Proxy לווירטואליים. זה יוזיל את עלות חומרת השרת ויקל על גיבוי ושחזור נתונים, אך מצד שני, במקרה של כשל בשרת פיזי, אתה מסתכן בהיותך מייד ללא MTA, LDAP ו-Proxy. לכן הבחירה בין שרתים פיזיים או וירטואליים צריכה להיעשות על סמך כמה זמן השבתה אתה יכול להרשות לעצמך במקרה חירום. מאחסני דואר, לעומת זאת, יוצבו בצורה הטובה ביותר על שרתים פיזיים, שכן עליהם יתרחש המספר העיקרי של מחזורי הכתיבה, אשר מגבילים את הביצועים של זימברה, ולכן מספר גדול יותר של ערוצים להעברת נתונים יתרחש באופן משמעותי להגביר את הביצועים של Zimbra.

באופן עקרוני, לאחר יצירת שרתי LDAP, MTA, Proxy, אחסון רשת ושילובם לתשתית אחת, ה-Zimbra Collaboration Suite ל-10000 משתמשים מוכנה להפעלה. תוכנית הפעולה של תצורה כזו תהיה פשוטה למדי:

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

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

מכיוון שאין מערכת גיבוי מובנית ב-Zimbra OSE, נזדקק ל-Zextras Backup, התומך בגיבוי בזמן אמת, ובאחסון חיצוני. מאחר ו-Zextras Backup, בעת ביצוע גיבויים מלאים ומצטברים, מכניס את כל הנתונים לתיקיית /opt/zimbra/backup, יהיה סביר להרכיב לתוכה אחסון חיצוני, רשת או אפילו ענן, כך שבמקרה של אחד השרתים קורס, יש לך מדיה עם עותק גיבוי עדכני בזמן חירום. ניתן לפרוס אותו הן על שרת פיזי מיותר, והן על מכונה וירטואלית ובענן. כמו כן, מומלץ להתקין MTA עם מסנן דואר זבל מול השרת עם Zimbra Proxy כדי להפחית את כמות תעבורת הזבל הנכנסת לשרת.

כתוצאה מכך, תשתית Zimbra המאובטחת תיראה בערך כך:

בתצורה זו תשתית זימברה תוכל לא רק לספק שירותים איכותיים ל-10.000 משתמשים, אלא גם במקרה של מצב חירום היא תאפשר לבטל את השלכותיו במהירות האפשרית.

מקור: www.habr.com