כששרת נופל, הבעיה היא לא רק הפסקת חשמל. הבעיה האמיתית היא כמה זמן יש לכם להגיב, אילו מערכות חייבות להישאר פעילות, ומה יקרה אם הגיבוי שחושב על הנייר לא יעמוד בעומס בשטח. לכן, כששואלים איך לחשב גיבוי לסביבת שרתים, לא מספיק לקחת את ההספק של השרתים ולחפש UPS מתאים. צריך להבין את התמונה המלאה – עומס אמיתי, זמן שהייה נדרש, תנאי אתר, שרידות, וצמיחה צפויה.
ברוב הארגונים, חישוב הגיבוי מתחיל בכלל בשאלה הלא נכונה. במקום לשאול "איזה UPS צריך", נכון יותר לשאול "מה חייב להישאר פעיל, לכמה זמן, ובאיזה תרחיש תקלה". יש הבדל גדול בין חדר שרתים קטן שצריך 10 דקות כדי לבצע כיבוי מסודר, לבין אתר תפעולי שצריך להמשיך לעבוד עד להתנעת גנרטור או עד להעברת עומס מסודרת. אותו ציוד קצה, אבל דרישת הגיבוי שונה לגמרי.
איך לחשב גיבוי לסביבת שרתים – מתחילים מהעומס האמיתי
השלב הראשון הוא מיפוי מדויק של כל הצרכנים שיישבו על הגיבוי. לא רק שרתים. גם מערכי אחסון, מתגים, נתבים, Firewalls, מערכות טלפוניה, קונסולות ניהול, ציוד KVM, ולעיתים גם מערכות קירור נקודתיות או רכיבי בקרה. טעות נפוצה היא לחשב רק את השרתים עצמם, ואז לגלות שבזמן אמת רכיב תקשורת קריטי לא חובר ל-UPS או שהתווסף עומס בלי לעדכן את התכנון.
כדי לחשב נכון, אוספים את נתוני ההספק של כל רכיב. עדיף למדוד צריכה בפועל ולא להסתמך רק על מדבקת יצרן. למה? כי ספק כוח של שרת יכול להיות מדורג על 800W, אבל הצריכה בפועל בזמן עבודה שוטפת תהיה שונה מאוד. מצד שני, אם מחשבים רק לפי ממוצע צריכה שגרתי ומתעלמים מקפיצות עומס, מקבלים מערכת גבולית. הפתרון המקצועי הוא להסתכל גם על צריכה שוטפת, גם על Peak סביר, וגם על תרחישי עומס חריגים.
במונחים פשוטים, מחשבים את סך ההספק ב-Watt של כל הציוד הקריטי, ואז מוסיפים מרווח תכנוני. ברוב המקרים, מרווח של 20% עד 30% הוא נקודת פתיחה סבירה, אבל זה תלוי בסוג האתר. באתר דינמי עם גידול מהיר, וירטואליזציה, או תוספות ציוד תכופות, המרווח יכול להיות גבוה יותר.
לא להתבלבל בין kVA ל-kW
אחת הטעויות השכיחות בתחום היא לבחור מערכת לפי kVA בלבד. בפועל, מה שמעניין אתכם הוא גם ההספק הפעיל ב-kW וגם מקדם ההספק של ה-UPS. שני דגמים עם אותו דירוג kVA לא בהכרח יתנו אותו כושר נשיאה אמיתי. אם הסביבה שלכם צורכת 8kW, לא מספיק למצוא מערכת שנשמעת "גדולה" על הנייר. צריך לוודא שהיא מספקת את ההספק הפעיל הנדרש, עם רזרבה מתאימה.
בסביבת שרתים מודרנית, שבה יש ספקי כוח יעילים ועומסים אלקטרוניים משתנים, ההתאמה הזו קריטית. תכנון לפי מספר חלקי או כללי מדי עלול להביא למצב שבו המערכת אמנם קיימת, אבל לא מגבה באמת את מה שצריך.
זמן גיבוי הוא לא מספר שרירותי
אחרי שמבינים את העומס, מגיעה השאלה השנייה – לכמה זמן צריך לגבות. כאן אין תשובה אחת נכונה, כי זמן הגיבוי צריך להיגזר מהתהליך העסקי והטכני, לא מהעדפה כללית.
אם המטרה היא כיבוי מסודר של שרתים ומערכות אחסון, ייתכן ש-10 עד 15 דקות יספיקו. אם קיים גנרטור, צריך לחשב את זמן ההתנעה, הייצוב והעברת העומס בפועל, ולהוסיף מרווח ביטחון. אם מדובר באתר שבו כל דקה של השבתה מייצרת נזק תפעולי או שירותי, ייתכן שיידרש זמן גיבוי ארוך יותר, או תכנון מדורג שבו חלק מהעומסים מגובים לזמן ארוך וחלקם לזמן קצר.
כאן נכנס שיקול חשוב: לא כל הציוד צריך לקבל אותו SLA. לעיתים נכון יותר להפריד בין עומסים קריטיים לעומסים חשובים אך לא חיוניים. לדוגמה, מערך תקשורת ליבה, אחסון ובקרת גישה יקבלו עדיפות ברורה, בעוד שרתים משניים או רכיבים לא קריטיים יישבו על קו נפרד או יכובו מוקדם יותר. ההפרדה הזו משפיעה ישירות על גודל המערכת, על עלות הסוללות ועל היכולת לתחזק את הפתרון לאורך זמן.
הנוסחה הפשוטה – והמלכוד שבתוכה
על פניו, החישוב נראה פשוט: אם העומס הוא 10kW ורוצים 30 דקות גיבוי, בוחרים מערכת וסוללות שמתאימות להספק הזה למשך חצי שעה. אבל המציאות מורכבת יותר. קיבולת הסוללות מושפעת מטמפרטורת החדר, מהזדקנות המצברים, מעומס בפועל, מאופן הפריקה, ומיעילות המערכת.
במילים אחרות, 30 דקות על הנייר אינן בהכרח 30 דקות אחרי שנתיים-שלוש של עבודה, במיוחד אם חדר השרתים אינו נשמר בתנאים תרמיים נכונים. לכן, תכנון רציני לא מבוסס רק על נתון קטלוגי אלא על תנאי אתר אמיתיים, כולל שחיקה צפויה.
איך לחשב גיבוי לסביבת שרתים עם צמיחה עתידית
סביבת שרתים כמעט אף פעם לא נשארת סטטית. מצטרף שרת חדש, מתווסף מערך אחסון, נכנס ציוד אבטחה, מתבצעת הרחבת תקשורת. אם מחשבים גיבוי רק לפי מצב קיים, מהר מאוד מגלים שהמערכת הגיעה לרוויה.
לכן, בחישוב נכון בודקים לא רק מה מחובר היום אלא גם מה מתוכנן ל-12 עד 36 החודשים הקרובים. לפעמים נכון לבחור מערכת מודולרית שתאפשר להגדיל הספק או זמן גיבוי בלי להחליף את כל התשתית. במקרים אחרים עדיף לתכנן מראש ארון סוללות נוסף, חלוקת מעגלים נכונה, ויכולת ניטור שתאפשר לדעת בזמן אמת איפה אתם עומדים מול מגבלות המערכת.
הנקודה הזו חשובה במיוחד בארגונים שבהם ה-IT צומח מהר יותר מתשתית החשמל. לא מעט חדרי שרתים נראים תקינים עד לרגע תקלה, ואז מתברר שה-UPS לא עודכן לפי תמונת העומס בפועל.
לא רק UPS – גם התשתית מסביב קובעת
מערכת גיבוי טובה יכולה להיכשל אם התשתית שסביבה לא מתוכננת נכון. הזנה חשמלית לא מאוזנת, מעגלים ללא סלקטיביות, כבלי הזנה לא מתאימים, חום חריג בחדר, ארון צפוף מדי, או היעדר ניטור – כל אלה יכולים לפגוע בתפקוד בפועל.
לכן, כשמחשבים גיבוי לסביבת שרתים, בודקים גם את מעטפת החדר. האם יש חלוקה מסודרת בין A feed ל-B feed? האם ה-PDU תואם לעומסים? האם קיים מנגנון מעקב אחרי בריאות המצברים? האם יש התראות לפני כשל? האם ניתן לבצע תחזוקה בלי לסכן רציפות? אלו שאלות הנדסיות, אבל הן מתורגמות ישירות לסיכון עסקי.
בסביבות קריטיות, גם הבדיקות שאחרי ההתקנה הן חלק מהחישוב. אם לא בוצעו בדיקות עומסים, סימולציות מעבר, אימות זמן גיבוי והצלבת נתוני צריכה, אין ודאות שהמערכת תעמוד בתרחיש אמיתי.
מתי חישוב פשוט מספיק, ומתי צריך אפיון מלא
עסק קטן עם ארון תקשורת אחד, שרת בודד, ציוד תקשורת בסיסי ודרישת גיבוי קצרה יכול לעיתים להסתפק בחישוב יחסית ישיר. גם כאן כדאי לעבוד מסודר, אבל המורכבות נמוכה יותר.
לעומת זאת, ברגע שיש כמה ארונות, מערכות וירטואליזציה, אחסון מרכזי, תלות בזמינות שירותים, אתר ייצור, מוקד שירות, או אינטגרציה עם גנרטור וניטור – כבר לא נכון לעבוד לפי חישוב כללי. נדרש אפיון מלא שכולל עומסים, תרחישי כשל, חלוקת עדיפויות, זמן גיבוי נדרש, מגבלות מקום, דרישות תחזוקה ותקציב.
כאן גם נכנס שיקול כלכלי אמיתי. מערכת גדולה מדי תייקר את הפרויקט ואת התחזוקה ללא צורך. מערכת קטנה מדי תיצור תחושת ביטחון מדומה. המטרה איננה לקנות "כמה שיותר", אלא להתאים פתרון מדויק לדרישת הרציפות של הארגון.
הטעות היקרה ביותר היא להניח
הנחות הן מקור מרכזי לבעיות בתחום הזה. להניח שהעומס לא השתנה, שהסוללות יתנו את אותו ביצוע לאורך שנים, שהגנרטור תמיד יתניע בזמן, או שהשרתים יכבו לפי התכנון – כל אלה עלולים להפוך אירוע קצר להשבתה משמעותית.
בפועל, תכנון גיבוי נכון הוא שילוב בין נתונים, מדידה, ניסיון שטח ויכולת לראות את כל שרשרת התשתית. זו בדיוק הסיבה שבאתרים קריטיים לא מסתפקים בהתאמת מוצר, אלא בודקים את סביבת העבודה כולה – מהלוח החשמלי ועד לזמן הגיבוי בפועל תחת עומס.
בארגונים רבים, העבודה הנכונה מתחילה במדידה באתר ובאפיון מסודר של העומסים והתרחישים. כך אפשר לקבוע אם נדרש UPS אונליין, מערכת מודולרית, הרחבת מצברים, הפרדת עומסים, שדרוג הזנה או שילוב מלא עם מערך החשמל והניטור. עבור לקוחות שמנהלים סביבה קריטית, זה ההבדל בין רכישת ציוד לבין הקמת פתרון שאפשר לסמוך עליו. זה גם המקום שבו גוף ביצועי מנוסה כמו DCE מביא ערך מעבר למפרט – בתכנון, בבדיקות ובווידוא שהמערכת שתוכננה אכן תעמוד ברגע האמת.
אם אתם בוחנים עכשיו גיבוי לחדר שרתים או לאתר תפעולי, אל תתחילו בקטלוג. התחילו בשאלה כמה זמן מותר לכם להיות בלי המערכת, ומה באמת חייב להישאר חי כשהחשמל נופל.
