שרידות שרתים לאתר DR – זה יכול להיות גם אחרת

Double-Take מביא גמישות ויכולות שלא נראו עד כה בתחום שרידות שרתים ואתר DR

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

מה הוא SLA טיפוסי לשרת? מהוא רמת הזמינות לשרתים הקריטים שלך באירגון שאתה נותן למשתמשים שלך או ללקוחות שלך? האם אתה מנסה להשיג לאפליקציות הקרטיות חמש תשעיות (99.999%)? אפשר לראות  שסטאטיסטית 80% ממנהלי IT רוצים לקבל לפחות 99% Up Time לשרתים ולאפליקציות הקריטיות אצלם בארגון לעומת 20% שלא חשבו על כך בכלל. לפני 15 שנה דואר אלקטרוני היה "Nice to Have". היום שרת דואר למטה שווה איבוד הכנסה מיידי ברוב האירגונים.

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

אז מה זה Down time? רבים חושבים ש Down time זה הזמן שמודדים מרגע נפילת השרת עד שמחזירים אותו לפעולה. אבל, האמת, ש Down time למעשה חיבור של שתי מרכיבים. האחד הוא RPO (Recovery Point Objective), מרגע הנפילה ועד לגיבוי האחרון, כמה זמן של מידע איבדתי? לדוגמה נניח שביצענו גיבוי ב 12 בלילה. והנפילה של השרת הייתה ב 3 אחרה"צ. ה RPO הוא 15 שעות כי איבדתי 15 שעות של מידע. המרכיב השני הוא RTO ( Recovery Time Objective) כמה זמן לקח לי להרים את השרת חזרה. יכול להיות שעתיים אבל יכול להיות גם 8 שעות. חיבור של שניהם ביחד יוצר לי Down Time. לפי הדוגמה RPO 15 שעות + RTO נניח 4 שעות. סה"כ Down Time של 19 שעות! זה הרבה לשרת קריטי…

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

חברת Double-Take היא חברה אמריקאית מהוותיקות ביותר בתחום ה DR ו HA של שרתים. נוסדה בשנת 1991 וממוקמת בארה"ב עם סניפים בכול רחבי העולם. לחברה מעל ל 30,000 לקוחות ומעל 300,000 רישיונות שנמכרו. בינהם נמצאות רוב חברות ה Fortune 500 של ארה"ב וחברות רבות בכול רחבי העולם. מוצר השרידות של Double-Take קיים כבר 12 שנה והיום בגרסה 5.2. למוצר 22 פטנטים יחודיים שאפשרים לו להיות מוצר השרידות מספר אחד בעולם. המוצר למעשה מבצע רפליקציה בין שרתים. הוא משכפל את כול המידע משרת מקור לשרת יעד על גבי WAN ובעת קריסה מעלה אוטומטית את שרת היעד.

המוצר כולל יכולות רבות אך החשובות בינהם הם:

  1. רפליקציה של מידע ברמת Byte Level. כול Byte שנרשם בשרת המקור משוכפל לשרת היעד. זה נושא חשוב שכן רוב המתחרים מבצעים רפליקציה ברמת Block שמאיט את התהליך.
  2. רפליקציה על גבי ה WAN. בנוסף לכך שמתבצעת רפלקיציה ברמת Byte (נפח דטה קטן) המידע נדחס בשלוש רמות (לפי רוחב הפס) ומסונכרן עם Throttling לשליטה לפי עמוסים ביום. אפשר עם המוצר לרפלק שרתים על קו של 2MB .
  3. רפליקציה על גבי רשת TCPIP. רוב המוצרים היום ל DR מתבססים על רפליקציה של סטורג' שמוגבלת במרחק, ברוחב פס וגם מאוד יקרה.
  4. תמיכה בכול אפליקציה. ל Double-Take יש שלוש רמות של רפליקציה. ברמת תקייה בלבד, ברמת אפליקציה (הגנה על SQL, Exchange, Oracle וכדו'), וברמת שרת מלא – רפליקציה של כול השרת על גבי ה WAN (Continues Image). בכך יכולה להגן על כול שרת וכול אפליקציה, גם על אילו שלא מגיעות עם מנגנון הגנה.
  5. פתרון משלים ל Hyper-v ול VMware. המוצר יכול לבצע רפליקציה לשרתים וירטואלים ברמת ה VM עצמו אך גם ברמת ה Host. ז"א רפליקציה על גבי ה WAN בין שתי Hosts ללא כול מערכת צד ג' כגון סטורג', Cluster או SRM.
  6. רפליקציה בין שרתים פיזיים לוירטואלים. Double-Take יודע לרפלק שרתים פיזיים לוירטואלים ובכך לתת פתרון ל DR איכותי גם לשרתים פיזיים ללא שימוש ב BFS (Continues P2V). כמו כן Double Take יודע לבצע X2X ז"א גם רפלקיציה  של V2P.
  7. ניהול ואטומציה. ל Double-Take קונסול מרכזי לניהול כול מערך ה DR ו HA ושליטה מלאה ברפליקציות. Double-Take נותן מענה מרמה של נפילה של שרת בודד עד נפילה של כול האתר בצורה אוטומטית או יזומה. Double-Take מאפשר גם Fail Back בצורה שקופה ללא down time.

הבשורה הגדולה כאן היא גמישות. גמישות במערכות ההפעלה, גמישות בחומרה, גמשיות בוירטואליזציה וגמישות בפתרון. באמצעות Double-Take תכלו לבחור מה חשוב לכם יותר בשרידות האירגונית וכך לעצב את הפתרון לפי התשתית שלכם ולא לעצב את התשתית שלכם לפי הפתרון כמו בשאר המוצרים שמטפלים ב DR.

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

בכול שאלה אשמח אם תפנו אלי.

כותב: ארז פז

CTO ומיסד חברת Singular. בעל 15 שנות ניסיון בתחום.

052-6943035

erez@singular.co.il


כתיבת תגובה

האימייל שלך לא יוצג באתר. (*) שדות חובה מסומנים

*

     

תגי HTML מותרים: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>