Inmage של מיקרוסופט פתרון DR חסר ונחות לעומת Double Take

פוסט נבחר

אחד החוסרים הגדולים בענן של מיקרוסופט Azure היה רפליקציה. לקוחות שרצו לעבור לענן או להשתמש בענן של מיקרוסופט להמשכיות עסקית השתמשו בכלים צד ג'. לפתח פתרון רפליקציה טוב לוקח זמן ולכן מיקרוסופט קנתה לאחרונה פתרון שנקרא Inmage והכניסה אותו סל המוצרים שלה לענן Azure. הפתרון Imnage מספק רפליקציה מבוססת Block level של שרתי Windows פיזיים, וירטואלים מ VMware או Hyper-v לענן Azure לצרכי מגרציה או המשכיות עסקית.

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

הפתרון מוטמע עם 5 רכיבים:  Agent בכול שרת מקור, שרת עיבוד מרכזי שיושב באתר הראשי ואחראי להעברת המידע ליעד, שרת יעד שמקבל את הרפליקציה ומדווח לקונסול, שרת יעד לדיסקים שמחזיק את הדיסקים וקונסול ניהול. שרת העיבוד אחראי לדחיסה הצפנה ורוחב הפס לרפליקציה עבור כל שרתי המקור ללא יכולת לגראנולאריות ברמת שרת. Inmage משתמש במנגנון רפליקציה מבוסס Block Level שהוא לא Application Consistent לכן משתמש ב Periodic Consistent Point שיוצר נקודות בזמן שהם "קונסיסטנטים" לאפליקציה כגון Data Base.  לכן ה RPO שמוצע יהיה של שעות.

Inmage יודע לרפלק Windows 2008 R2 ומעלה בלבד. לא לינוקסים או כל מערכת אחרת. כמו כן  מרפלק שרתים שלמים או חלקים בשרת ללא יכולת להגנה פרטנית אפליקטיבית (Geo Cluster). ההגנה היא על שרתים פיזיים, VMware, Hyper-v עם Agent שמותקן בכל שרת. ללא יכולות Host base ללא Agents. לא ברור אם יודע לבצע Fail back חזרה לשרתים פיזיים, VMware או בכלל.

 

מסורבל או יעיל?

הפתרון הוא תוספת נחמדה לכלים של מיקרוסופט שמביא יכולות חדשות למשפחת Azure כגון מגרציה והגנה לאתר מרוחק. יחד עם זאת, הפתרון רחוק מהרמה הנדרשת היום לארגונים ומביא יכולות חלקיות בלבד עם התקנה ויישום מסורבלים (שרת ביניים באתר לקוח – לא ברור), RPO גבוה, מגוון שיטות יישום נמוך, ללא תמיכה בלינוקסים או במערכות הפעלה יותר ישנות והתאוששות בענן מרוחק. ככלל פתרון DR מוץ למדינה לא יעיל אם הלקוחות שלך והסביבה העסקית שלך היא בארץ שכן כל עבודת Client Server על Latency שמעל 50MLS היא מאוד קשה. המוצר כרגע מוטמע בלקוחות בודדים בעולם עם ניסיון מועט בשוק.

אם משווים את הפתרון ל Double-Take, ישנו פער עצום ביכולות. ראשית Double-Take הוא מוצר הקיים בשוק מעל ל 20 שנה, עם מעל ל 40 אלף לקוחות בעולם ומאות בארץ. שנית למוצר קיימים 24 פטנטים רשומים וכיום מהווה פתרון הרפליקציה הטוב והיעיל ביותר בשוק מעצם העובדה שמבצע Real Time Byte Level Replication ולא Block Level כמו כל שאר הספקים. שיטה זו מאפשרת ל Double-Take להיות "קונסיסטנטי" לאפליקציות כמו Data Bases בזמן אמת ללא הצורך לבצע Snapshots או כל שיטה אחרת היוצרת נקודות בזמן ולכן הוא המוצר היחיד בשוק שנותן RPO קרוב ל 0 אמיתי (איבוד מידע קרוב ל 0) עם שמירה על Data Base Consistency בזמן אמת. כמו כן, שיטת הרפליקציה היא גרנולארית יותר ולכן מעביר פחות מידע על גבי הקו בזמן נתון  - הכי חסכוני בקו. ל Double-Take מגוון שיטות ליישום. מספק שיטות כגון: P2V, V2P, P2P, V2V (גם בין וירטואליזציות שונות) וכמובן גם Host base ללא Agents ל VMware ו Hyper-v. בנוסף Double-Take מכיל יכולות Geo Cluster ומספק הגנה אפליקטיבית למערכות כגון Exchange, SQL, Oracle, File servers או אפליקציות נוספות ברפליקציה רק של האפליקציה להתאוששות אוטומטית מהירה גם בין אתרים שונים (RTO של שניות). Double-Take מגן על קלסטרים קיימים ויודע לבצע Cluster-to-Cluster protection או Cluster to Stand-alone protection. שיטת הרפליקציה של Double-Take מאוד פשוטה ולא מצריכה שרתי "ביניים", כל Agent בשרת המקור מתרפלק ישירות ל Agent בשרת היעד ללא תלות בשרת מרכזי באתר המקור שמהווה סיכון לנפילה. ניתן להגיע להגדרה גראנולרית בכל שרת בנושאים של רוחב פס, הצפנה ודחיסה.

לסיכום: Inmage מספק פתרון פשוט ללקוחות שרוצים להגן ל Azure בעיקר. אני לא בטוח שהסרבול במערכת והיכולות הבסיסיות שהוא מציע מספיק טובים כיום. המוצר הוא בינוני במקרה הטוב. Double-Take הוא מוצר המוביל את השוק בתחום ה DR ולכן למיקרוסופט יש דרך ארוכה כדי להתקרב ליכולות שלו.

להלן סיכום טבלת השוואה בין הפתרונות:

 

Microsoft InMage

Double-Take Availability

 

שיטת רפליקציה

Block Level – with snapshots

Byte Level Real Time

Keep Application Consistency

לא.

חייב לבצע Snapshot או כול שיטה מתוזמנת שלמירה על שרידות האפליקציה

כן.

בזמן אמת ללא Snapshots.

RPO

דקות או שעות לפי סנפשוטים ששומרים על Consistency

קרוב ל 0

יישום

שרת מקור מתרפלק לשרת ביניים באתר מקור ואז לשרת יעד.

שרת מקור מתרפלק ישירות לשרת יעד

 

חומרה במקור

פיזים, VMware, אמזון

פיזי, VMware, Hyper-v וכל תשתית ענן

מערכות הפעלה

Windows2008 R2 ומעלה, לא לינוקסים

Windows 2003 ומעלה, לינוקס – רוב הגרסאות היום

ייעול רוחב פס

Block Level פחות חסכוני כי מעביר יותר חומר על הקו

שיטת Byte Level חסכונית + QOS לקו  + דחיסה

חזרה לאחור Fail Back

 

מוגבל

יש בכול שיטה

X2X

שיטות רפליקציה ופתרונות

P2V, V2V

 

P2V, P2P, V2P, V2V, Host Base, Geo Cluster

X2X אמיתי

 


פתרונות המשכיות עסקית – Veeam מול Double-Take

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

ראשית אפרט למה נבנה ויועד כול מוצר. Veeam, הוא מוצר שנבנה כפתרון גיבוי למערכות VMware או Hyper-v על גבי LAN בעיקר, פתרון לחברות שאין להם Storage או פתרון גיבוי למקרה של תקלה ב Storage מקומי. לעומתו, Double-Take הוא מוצר רפליקציה ב Real Time שמיועד לשכפל שרתים פיזיים ווירטואלים לאתר DR עם קונסול מרכזי לשליטה. הוא תוכנן ומיושם כפתרון BCP לאתר DR.

שתי הפתרונות מבצעים רפליקציה שהיא A Synchronic מה שאומר שה RPO (כמות איבוד המידע) גדול מ 0. הרפליקציה של Veeam היא ברמת Block Level ואין לו אפשרות לשמור על Consistency של המידע בזמן אמת. לכן משתמש ב Snapshots על מנת לצור נקודות בזמן שהם Consistent ומספק למשתמש בזמן Fail Over נקודות בזמן לחזור אליהם בטווחים. ככול שרוצים שהטווחים יהיו קצרים יותר (איבוד המידע – RPO יהיה קצר יותר), יש ליצור יותר Snapshots מה שמעיט משמעותית את שרת המקור. ל Double-Take ישנה טכנולוגיה ייחודית שמספקת רפליקציה שנקראת Real Time Byte Level. המשמעות שלה היא שהיא מבוצעת כול הזמן ב Real Time ולכן ה RPO שמספקת הוא מילי שניות. כמו כן שומרת על Consistency של המידע בזמן אמת ללא שימוש ב Snapshots וללא פגיעה בביצועי שרת המקור.

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

כאשר רוצים פתרון המשכיות עסקית לאתר DRP, רוב הארגונים מעדיפים אתר מרוחק פיזית שאליו מרפלקים את המידע על גבי WAN. ברפליקציה לאתרים מרוחקים על גבי WAN, Veeam מאפשר להגביל את רוחב הפס בשימוש ולא מספק דחיסה לשימוש יעיל בקו ולכן מיועד בעיקר לתשתית LAN. Double-Take מאפשר תזמון לשליטה במהלך היום והלילה ברוחב הפס ושלוש רמות של דחיסה לשימוש יעיל בכול היום בקו. כמו כן, רפליקציה שהיא Byte Level היא הרבה יותר יעילה מרפליקציה שהיא Block Level על גבי פסי תקשורת איטיים.

מרבית הארגונים כיום עובדים עם וירטואליזציה אך ישנם הרבה ארגונים שעדיין מחזיקים שרתים פיזיים בעיקר למערכות הקריטיות ביותר שחשוב שירופלקו לאתר ה DR. Veeam מיועד אך ורק למערכות VMware ו Hyper-v כפתרון לוירטואליזציה בלבד (V2V). Double-Take מספק פתרון רפליקציה לסביבה וירטואלית (V2V) מלא גם ב VMware, גם ב Hyper-v וגם ביניהם. כמו כן מאפשר Geo Cluster ע"י שכפול Node מקלסטר מיקרוסופט קיים או שכפול קלסטר שלם על גבי WAN, שכפול שרת מלא פיזי מול פיזי (P2P), פיזי מול וירטואלי (P2V), רפליקציה רק לאפליקציות רפליקציה לענן ציבורי או מענן ציבורי, רפליקציה ל IMAGE ומיגרציה בין חומרות שונות. למעשה מספק X2X, כל תשתית לכול תשתית.

לסיכום, ארגונים שמחפשים פתרון גיבוי מקומי לוירטואליזציה על גבי LAN  עם שחזור גרנולארי למערכות וירטואליזציה בלבד, כדאי שישתמשו ב Veeam כפתרון. ארגון שמחפש פתרון DRP או BCP או HA לאתר מרוחק מומלץ שישתמש בפתרונות של Double-Take שלמעשה הוא מוצר שתוכנן להמשכיות עסקית, מספק גמישות לכול מערכת X2X , מספק אמינות שהמידע והמערכות אכן יעלו בצד השני מהר ודואג שאיבוד המידע יהיה מנמאלי וקרוב ל 0.


Double-Take 6.0.1 – סט חידושים מחמים להמשכיות עסקית \ DRP לחורף קר

Double-Take הינו פתרון מבוסס תוכנה להמשכיות עסקית עם יכולות ייחודיות כגון הגנה ב Real Time והגנה של כול תשתית לכול תשתית (לדוגמה הגנה על חדר מחשב לענן ציבורי ולהפך). לפרטים נוספים על Double-Take קרא פה.

ביחד עם צאת Windows 2012 Server, Double-Take השיקה עדכון חדש למוצריה שתואם להשקת ה Windows ומכיל מספר גדול של יכולות חדשות ושיפורים. העדכון (6.0.1) הוא אבן דרך הראשונה מאז צאת גרסה 6.0 שהכילה שיפורים גדולים ומשמעותיים כגון Universal Virtual Appliance המאפשר לרפלק Windows ו Linux ל Host VMware אחד, שיפורים בממשקים ועוד (קרא פה עוד). ראשית החידוש הראשון הוא תמיכה מלאה בהתקנת Double-Take על גבי Windows 2012 – התקנה של הקונסול השליטה וגם התקנה של ה Agent לרפליקציה. כול ה Jobs נתמכים ב Windows 2012 כגון רפליקציה של קבצים ותיקיות, רפליקציה שרת מלא X2X, רפליקציה של SQL, Hyper-v Host Base, Geo Cluster, מיגרציה של מידע ומגרציה של שרתים שלמים. למעשה ניתן לרפלק כול שרת אשר מותקן עליו Windows 2012 בכול אחת משיטות רפליקציה אילו. לדוגמה, אם מותקן שרת עם Windows 2012 עם SAP ו SQL, ניתן לרפלק אותו בתצורת Full Server Replication לשרת וירטואלי עם Windows 2012 נקי בענן הציבורי ולקבל פתרון DRP לשרת זה לענן.

הגרסה החדשה תומכת ב CSV Cluster Hyper-v 2012. ז"א שניתן להתקין את ה Agent של Double-Take על גבי ה Host של Hyper-v שנמצא ב CSV Cluster ולהגן על המכונות הוירטואליות ברמת ה Host לאתר DRP. אבל, Hyper-v 2012 מכיל יכולת חדשה שנקראת – Hyper-v Replicator שמספקת יכולת רפליקציה של שרתים וירטואלים לאתר DRP, אז למה צריך להשתמש ב Double-Take? בקצרה, Hyper-v Replicator הוא מוצר מאוד בסיסי שמספק הגנה חלקית בלבד עם יכולות מאוד מוגבלות שמעמיסות על ה Hyper-v Host. היכולת החדשה של Hyper-v מתאימה לארגונים קטנים בלבד שרוצים פתרון פשוט לאתר חלופי קרוב. לפרטים נוספים קרא מאמר שלי בנושא.

ישנם עוד חידושים רבים שכוללים שיפורים ותיקון תקלות. להלן רשימת החידושים והשיפורים:

הערת ביאור: Virtual Appliance הוא שרת וירטואלי שמתקינים על Host ESX או Hyper-v שנמצא באתר ה DRP ומאפשר לקבל אליו רפליקציה משרתים פיזיים, וירטואלים, Linux או Windows.

  • תמיכה ב VHDX – הפורמט החדש של קבצי הוירטואליזציה של Hyper-v לביצוע רפליקציה בתצורת Host Level.
  • תמיכה ב Direct I/O של לינוקס.
  • תיקון תקלה בא חלק מה Roles And Features לא היו מופיעים לאחר ביצוע Fail Over ב Windows.
  • ביטול פירמוט דיסקים בעת יצירתם ב Job חדש ל ESX.
  • תיקון תקלה שגרמה לבעיות תקשורת בין הקונסול לשרתים על גבי WAN.
  • שיפור עבודה עם הזיכרון של Double-Take Management Service.
  • הגדלת גודל מקסימלי של קובץ LOG.
  • שיפור זמני יצירת Thick Disk ב ESX.
  • שיפור זמני ריענון מסך בעת ביצוע פעולות Exclude לתיקיות מרובות קבצים.
  • שיפור פעולת Double-Take בהגנה על שרתים פיזיים לוירטואלים גם ל Fail Over וגם ל Fail Back.
  • הגנה על Exchange ו SQL גם בסביבות מרובות דומיינים.
  • שיפור ביצועי הגנה של שרתים פיזיים לוירטואלים בתצורת Many to Virtual Appliance.
  • בעת נפילת שרתי מקור ברפליקציית Hyper-v Host, תיקון הודעת Unknown/error שמקבלים בקונסול.
  • ניתן לבצע רפליקציה משרת פיזי עם MultiPathing ל Virtual Appliance על גבי ESX.
  • תיקון בעיית Failover ב Minimal Install Linux Enterprise 6.
  • שיפור תמיכה ב SQL למשתמשים ללא הרשאות Admin על ה SQL.
  • יצירת JOB ל DR בלבד ב Cluster של שרתי קבצים.
  • תמיכה בהגנה על Multiple Linux swap volume ל Universal Virtual Appliance.
  • אפשרות לבצע אקטיבציה לשרתי Linux מה Double-Take Console.

אפשר בהחלט לראות שגרסה 6.0.1 היא חידוש מרענן שמוסיף יכולות חשובות כגון תמיכה ב Windows 2012, תמיכה ב Hyper-v CSV Cluster ל Host Replication ועוד. Double-Take כהרגלם מוכיחים שהם "Up to Date" תמיד, כבר 20 שנה ומובילים את התחום בהפרש ניכר מכול שאר המתחרים בתחום.


פתרון DRP מבוסס רפליקציית Storage אל מול פתרון מבוסס תוכנה – Host Base Replication

ארגון שמחפש פתרון סינכרוני ז"א RPO = 0 חייב לפנות לספקי תשתית ו Storage  ולרכוש את המערכות היקרות. רוב הארגונים שמחפשים פתרון טוב ולא מאוד מאוד יקר יסתפקו בפתרון א.סינכרוני שמספק RPO טוב של אפילו שניות בודדות. אם נשווה פתרונות א.סינכרונים להמשכיות עסקית של Storage אל מוצר כגון Double-Take שהוא פתרון Host base replication (פתרון DRP אפליקטיבי), נראה מספר הבדלים…

Storage הוא רכיב חומרה חיוני שנמצא ברוב הארגונים הבינונים ובכול הארגונים הגדולים. קשה למצוא היום ארגון מודרני שעובד עם וירטואליזציה ומערכות עם Up Time גבוהה שלא משתמש ב Storage. ישנה עת בה עולה השאלה באיזה טכנולוגיה להשתמש על מנת ליצור המשכיות עסקית לאתר מרוחק. בד"כ השאלה עולה כשאר נגמרת תקופת האחריות על ה Storage ואז ישנה דילמה אם להרחיב את האחריות או לרכוש Storage חדש. יצרני ה Storage לוחצים את הלקוחות לפינה בכך שמעלים את מחירי האחריות כול כך שלא שווה ללקוח לרכוש הרחבת אחריות אלא Storage חדש. כמו כן, מיד מציעים ללקוח (שאין לו פתרון DR) לרכוש Storage נוסף, להציבו באתר מרוחק ולבצע Storage Replication על מנת להגן על המידע. נושא זה עולה גם בד"כ כאשר לארגון אין פתרון DR לחלוטין וישנה דרישה מהנהלה בעקבות רגולציה או השבתה שקרתה.

בנושא המשכיות עסקית, עולות לארגונים דילמות רבות כגון על מה להגן, לאיפה ובאיזה רמת זמינות. דילמה שאני נתקל בא רבות בארגונים שאני מייעץ להם, היא דילמה בנוגע לתשתית הרפליקציה: רפליקציה מבוססת Storage או רפליקציה מבוססת תוכנה (Host Base Replication)? התשובה לכך תלויה מאוד בצרכי הארגון. ראשית חשוב להבין איזה סוגי רפליקציות יש: ישנם שתי סוגי של רפליקציות. רפליקציה סינכרונית ורפליקציה א.סינכרונית. רפליקציה סינכרונית היא רפליקציה שכותבת את המידע של המערכות קודם כול באתר ה DR לפני שנכתב באתר המקור. על מנת לא להאט את המערכות באתר המקור, רפליקציה מהסוג הזה צריכה תשתית מאוד חזקה כגון קו תקשורת מסוג Dark Fiber שיודע להעביר קצבים של 10GBit , ומערכת Storage תומכת שיודעת להעביר ולקבל קצבים כאלו כגון EMC symmetrix כבדים עם Recover Point וכדו'. מערכות כאלו מאוד יקרות ובד"כ מוטמעות בלקוחות גדולים מאוד שיכולים להרשות לעצמם. רפליקציה סינכרונית מספקת RPO = 0  (Recover Point Objective) ז"א 0 איבוד מידע מובטח. רפליקציה א.סינכרונית היא רפליקציה שמבצעת כתיבה לאתר המרוחק רק לאחר שהתבצע באתר המקור. לכן הרפליקציה הזו זולה בהרבה ומיושמת ברוב הארגונים עם אתרי DR. ישנם מגוון גדול של פתרונות שמספקות את הרפליקציה הזו וההבדל הגדול ביניהם הוא רמת  ה RPO שיכולה להיות מילי שניות עד כמה ימים, תלוי בטכנולוגיה שבוחרים.

ארגון שמחפש פתרון סינכרוני ז"א RPO = 0 חייב לפנות לספקי תשתית ו Storage  ולרכוש את המערכות היקרות. רוב הארגונים שמחפשים פתרון טוב ולא מאוד מאוד יקר יסתפקו בפתרון א.סינכרוני שמספק RPO טוב של אפילו שניות בודדות. אם נשווה פתרונות א.סינכרונים להמשכיות עסקית של Storage אל מוצר כגון Double-Take שהוא פתרון Host base replication (פתרון DRP אפליקטיבי), נראה מספר הבדלים.

Storage מבצע רפליקציה שהיא Block Level. Block Level בבסיסו לא שומר על Consistency (עמידות) של מערכות כגון Exchange, SQL, Oracle וכדו'. לכן ה Storage חייב לבצע פעולה מקדימה כגון Snapshot, להשתמש ב VSS של Windows או להכניס מערכת ל Back mode על מנת שהמידע שירופלק לאתר ה DRP יהיה Consistent. הפעולה הזו תצור מרווחים של נקודות בזמן שבהם ניתן לבצע שחזור באתר ה DR שיכולים להיות 10 דקות או רבע שעה. לכן ה RPO של רפלקציית סטורג' נעה בין 10 דקות לרבע שעה (הפסד מידע). לעומתו ה Double-Take מבצע רפליקציה שנקראת Real Time Byte Level Replication שהיא רפליקציה בזמן אמת ברמת Byte. רפליקציה ברמת Byte היא ברמה גראנולארית יותר מ Block ומשתמשת במנגנון כתיבת ה Driver של מערכת ההפעלה ובכך מוודאת את ה Consistency של ה bytes עוד לפני שהם מעוברים לאתר ה DR. לכן ה RPO שמשיגים הוא מילי שניותמשתמש במנגנון בזמן אמת licationדקות לרבע שעה ם ניתן לבצע  א.סינכרוני שמספק ת מסוג  המערכות קודם כול בארת ה  והקרוב ביותר ל 0 שניתן להגיע בא.סינכרוני, ז"א מילי שניות של איבוד מידע.

על מנת לבצע רפליקציה ברמת ה Storage, חייבים לרכוש שתי מכונות מאותו ספק לפחות (Netapp, EMC, HP וכדו'). לא ניתן לבצע רפליקציה בין Storages מספקים שונים, לדוגמה, לא ניתן לרפלק Netapp ל EMC. לכן, כאשר מתכננים רפליקציה ל DRP עם Storage, יש להתחשב בעליות הכרוכות ברכישה, תחזוקה ותמיכה של שתי Storages. לפתרון של Double-Take, לא משנה מ Storage המקור ומה Storage היעד. Double-Take מבצע רפליקציה בין שרתים ולא משנה לו מה התשתית מתחת. לדוגמה ניתן לבצע רפלקיציה של שרת IBM שנמצע על Storage מסוג Dell לשרת HP שנמצע על Storage של Hitachi. כמו כן ניתן לבצע רפליקציה שהיא P2V ל VMware או Hyper-v, רפליקציה V2P או V2V גם בין תשתיות וירטואליזציה שונות כגון Hyper-v ל VMware ולהפך. במידה ורוצים להתקדם לענן, ניתן לבצע רפליקציה של השרתים בארגון לענן הפרטי או הציבורי – גמישות מלאה.

רפליקציה מבוססת Storage משכפלת את החומר בתוך ה Storage בלבד. זה טוב אם יש רק שרתים וירטואלים ו\או NAS Filer. אך במידה ויש שרתים פיזיים שמחזיקים דיסק מקומי עם מערכת הפעלה, אז הרפליקציה של ה Storage תעזור להעביר רק דיסקים חיצוניים שמחוברים לשרת כגון LUNs. גם אם השרתים מותקנים על BFS (Boot From SAN), יש צורך לרכוש שרתים זהים לחלוטין לאתר ה DR, נושא שמייקר את הפתרון מאוד. כמו כן, אם מבצעים רפליקציה לשרתים וירטואלים, תמיד מומלץ להשתמש במנגנוני DRP מנוהלים כגון SRM של VMware אחרת יש לבצע פעולות רבות כדי להתאושש באתר ה DR. Double-Take מאפשר רפליקציה של שרתים פיזיים לשרתים וירטואלים ישירות – P2V, גם אם יש להם LUNs בסטורג' באתר המקור. בכך מקבלים פתרון Real Time P2V replication ששומר על השרתים הפיזיים וחוסך ב Storage ובשרתים באתר ה DR. Double-Take יודע גם לבצע V2V ובכך נותן פתרון מקיף ל DRP ללקוח שיש לו שרתים פיזיים וורטואלים בקונסול אחד.

יש לשים לב לנושאים נוספים כגון זמינות אתר ה DR בשוטף כאתר אקטיבי. ה Storage נועל את אתר ה DR לכתיבה בלבד וללא זמינות לעבודה בשוטף בשונה מ Double-Take שניתן להרים שרתים באתר ה DR ללא בעיה בלי "להפיל" את ההגנה. נושא נוסף הוא רוחב הפס לאתר ה DR. רפליקצה שמבוססת Block היא הרבה פחות יעילה מ Byte  ולכן "זוללת" רוחב פס ומחייבת רוחב פס רחב בעת ביצוע רפליקציה עם Storage  לעומת Double-take שיודע לעבוד על קווי תקשורת איטיים של עד  2 MB ולשמור על Real Time!

איפה כן מומלץ להשתמש ב Storage Replication? קודם כול במקרים בהם יש צורך בפתרון סינכרוני מלא ז"א RPO חייב להיות 0, צריך לקחת בחשבון שהפתרון הוא יקר מאוד. כמו כן, כאשר עובדים עם מערכת כגון NAS Filer שמתפקדת כשרת קבצים. פה אין ברירה וחייבים להשתמש ברפליקציה של Storage  שכן לא ניתן להתקין סוכן של Double-take על גבי מערכת ההפעלה של ה Storage. מקרה נוסף הוא אם רוצים להשתמש ב SRM של VMware כפתרון DRP  לשרתים וירטואלים אז חייבים להשתמש ברפליקציית Storage שכן SRM מחייב זאת.

לסיכום, פתרון מבוסס Storage לאתר DRP הוא פתרון טוב למי שרוצה לשמור על המידע. אבל מה לעשות, המידע לא מספיק, המשכיות עסקית זה לשמור על העסק מתפקד וכדי שעסק יתפקד, צריך גם לשמור על השרתים והאפליקציות עם מנגנון שנבנה ל DR לכול  תשתית. לכן, פתרון Host Base Replication כגון Double-Take עדיף ברוב המקרים.


האם Hyper-v Replicator הוא ה Feature הכי משמעותי ב Windows Server 2012?

התשובה הקצרה היא – "לא". ישנם כול כך הרבה יתרונות ושיפורים ל Windows server 2012 שלא ניתן להכניס לכתבה אחת. המערכת הוכרזה אתמול ב 4/9/2012 וכבר עשרות אלפי משתמשים בעולם הורידו את הגרסה להתנסות. המערכת מחילה שיפורים רבים ומעניינים בתחום הוירטואליזציה והמשכיות עסקית ו Hyper-v Replicator הוא בהחלט תוספת מרעננת אך הפתרון רחוק מלהיות פתרון DRP בסטנדרטים שקיימים היום.

אחד הנושאים הבעייתיים ביותר במכירת Hyper-v לארגונים הוא חוסר בפתרון DRP מובנה ב Hyper-v. לקוחות מחפשים פתרון שיהיה קל ליישום ותחזוקה ושבעת אסון יעבוד ומהר. על מנת לממש פתרון DRP ל Hyper-v הלקוחות היו צריכים למצוא פתרונות יצירתיים כגון כתיבת סקריפטים שמסרבלים את יישום ה DRP ומקשים על התחזוקה או להעביר את שרתי ה Host לתצורה של BFS (Boot From San) שמגדילים את העלות משמעותית (דורש Storage Replication ו Hosts פיזיים זהים באתר מקור ויעד) או פתרונות צד ג'.

Windows Server  2012 מגיע עם מספר יכולות חדשות כגון Hyper-v משופר, File System  חדש (ReFS),  Server Manager משופר ועוד. בתחום ה HA  השיפור המשמעותי הוא Hyper-v Cluster שתומך עד 63 Nodes ועד 4000 VMs.בתחום ה DRP השיפור המשמעותי הוא Hyper-v Replica שמציע פתרון מובנה להתאוששות מאסון. ה Hyper-v Replica מצטרף לשאר היכולות הקיימות במוצר כגון Live Migration להעברת שרתים באופן חם בין Hosts ו Live Storage Migration להגירת מכונות בין Storages ועוד.

Hyper-v Replica הוא מנגנון רפליקציה א-סינכרונית מובנת ב Hyper-v שיודע לשכפל מכונות וירטואליות על גבי WAN בין Hosts ללא צורך בשרתי Hosts זהים או במערכי אחסון זהים עם Storage Replication. הפעולה מתבצעת ע"י שכפול ראשוני ע"י העתקה רגילה של ה VHD משרת המקור ליעד (ניתן לשחזר אותו מגיבוי או להעביר אותו ידנית לאתר היעד), ביצוע Snapshot כול 5 דקות ורפליקציה של ה Snapshot הזה בתצורת Block Level Replication לאתר היעד. הרפליקציה היא לא Real Time וצריך לשים לב שיש איבוד מידע של 5 דקות ויותר בפתרונות מבוססי LAN. כמו כן בפתרון DR לאתר מרוחק על גבי WAN ישנם הפרשים של עד 15 דקות איבוד מידע. הרפליקציה בתצורה א-סינכרונית מאפשרת רפליקציה של נפחים גדולים על קווי תקשורת יחסית איטיים. Hyper-v Replica מאפשר דחיסה ברמה אחת לכן יש לשים לב לרוחב הפס וכמות החומר שרוצים להעביר.

על מנת להפעיל את היכולת הזו ב Hyper-v ישנה אפשרות להגדיר את ה Host ב Hyper-v Settings ובאיזה Port יבצע את הרפליקציה כולל אימות ושימוש בתעבורה מוצפנת – HTTPS. לאחר שה Host הוגדר ניתן לבחור על איזה שרתים רוצים להגן ואיזה כוננים (קבצי VHD). ניתן להגדיר גם שימוש בנקודות התאוששות אופציונאלי (Snapshot) למצב בו נרצה לבצע Fail Over לנקודה אחורה בזמן. ניתן להגדיר עד 15 Snapshots ביום שמבוצעים על שרת המקור ולכן בחלק מהזמן הרפליקציה מתבצעת לאותו חומר פעמיים ויותר.

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

חשוב לדאוג בשרת היעד לנפח מתאים למכונות המרופלקות ועוד 50% נוסף לקבציי השינויים והלוגים. בתסריטים בהם בשרתי המקור יש קלסטר מסוג CSV, חשוב לשים לב שבמידה ומבצעים Live Migration לשרת מוגן, השרת יצטרך לבצע סנכרון מחדש מול שרת היעד ל DR, לכן מומלץ לא לבצע Live Migration באופן שוטף לשרתים מוגנים כדי למנוע עומס בדיסק המקומי ובתקשורת. כמו כן גורם לשרת להיות לא ממוגן עד שיסיים את הסנכרון מחדש.

Hyper-v Replica הוא בשורה טובה וחידוש מעניין בתוך Windows Server 2012. להלן יתרונותיו:

  1. פתרון מובנה בתוך Windows Server 2012.
  2. מבצע רפליקציה בהפרשים  של 5 דקות על גבי LAN ו 15 דקות על גבי WAN.
  3. שומר על Consistency של מערכת הפעלה ואפליקציות.
  4. ללא תלות בחומרת ה Hosts וב Storage.
  5. ניתן לחזור אחורה בזמן באתר ה DR באמצעות Snapshots.
  6. עובד על גבי WAN עם דחיסה.
  7. הצפנה על גבי HTTPS – לא דורש VPN.
  8. קלות בתפעול – ישירות מהקונסול של ה Hyper-v.
  9. ללא עלות – מובנה בתוך ה Windows.

אם משווים אותו למוצר ותיק בתחום ה DRP/BCP כגון Double-Take Availability רואים את חסרונות הבאים:

  1. לא עובד עם Storage לכן פחות מתאים לארגונים שיש להם רפליקציה של Storage.
  2. לא פתרון Real Time עם RPO של 5 עד 15 דקות איבוד של נתונים.
  3. מבצע Hyper-v ל Hyper-v בלבד ולא יודע להגן על מערכות אחרות או שרתים פיזיים.
  4. ה Snapshots לחזרה אחורה בזמן מתבצעים בשרת המקור ולכן יוצר תעבורה כפולה לאותו חומר לשרת היעד. כמו כן מעמיס על ה Storage או הדיסקים המקומיים.
  5. בשרת היעד יש להיערך עם דיסק פי 1.5 משרת המקור.
  6. בעת העברת שרתים מוגנים ב Live Migration השרתים יבצעו סנכרון מחדש שיעמיס על תשתית המקור והשרתים לא יהיו מוגנים באותו חלון זמן.
  7. התמיכה ב WAN מוגבלת לרמה אחת של דחיסה ללא Throttling. יש לחשב טוב את רוחב הפס לפני יישום.
  8. ללא מנגנון ניטור או התרעות. יש להפעיל מערכת צד ג' לנושא.
  9. לא ניתן לגבות שרתים מרופלקים באתר יעד כי הדיסקים שלהם "תפוסים".

לסיכום נראה שמיקרוסופט בהחלט ביצעה צעד יפה בהכנסת טכנולוגיית הרפליקציה ל Hyper-v שנותנת מענה יפה ל VMware עם ESXi 5.1 SRM replication. הטכנולוגיה מתאימה בעיקר לארגוני SMB שלא צריכים הגנה ב Real Time, לא משתמשים ב Storage Replication, משתמשים ב Hyper-v בלבד ויש להם אתר משנה עם Hyper-v נוסף. כך ניתן לבצע רפליקציה בין שתי שרתי ה Hyper-v. ארגונים כאלו בד"כ קצרים ברוחב פס לכן יש לשים לב לנפחים שמעוברים על הקו שכן Hyper-v Replica לא מאוד חסכוני בנפחים גדולים.


מה ההבדל בין אקרוניס (Acronis) לבין Double-Take?

בהרבה פגישות והרצאות בהם אני מציג את הפתרונות של Double-Take, לקוחות שאולים אותי מה ההבדל בין אקרוניס (Acronis) לבין Double-Take. למעשה, ישנם הבדלים רבים. ראשית היעוד של המוצרים. Acronis הוא מוצר שמיועד יותר לתחום הגיבויים המבצע גיבוי מתוזמן. Double-Take לעומתו הוא פתרון רחב לתחום המשכיות עסקית.

ישנם מספר תחומים בהם ישנם הבדלים:

שיטת גיבוי נתונים

Acronis מגבה את נתוני השרתים באופן מתוזמן ולא מספק הגנה בזמן אמת. ל Double-Take מנגנון רפליקציה Real-Time Byte Level להגנה בזמן אמת על שרת שלם ובכך מספק RPO קרוב ל 0.

זמינות High Availability

Acronis מספק גיבוי ושיחזור של נתונים או שרתים. Double-Take מספק אפשרויות Fail Over ו Fail Back בלחיצת כפתור. ה Fail Over יכול להתבצע לשרת מלא כולל מערכת הפעלה, אפליקציות ומסדי נתונים או ברמה אפליקטיבית בלבד. כמו כן ה Fail Over יכול לשנות את שם השרת, IP ו DNS לפי צרכי הארגון.

 

 

עבודה על קווי תקשורת איטיים – Wan Optimization

Acronis לא מסוגל לבצע כיווץ לגיבוי שהוא מבצע על גבי ה WAN אך כן מספק שליטה ברוחב פס לכול רפליקציה. Double-Take מספק דחיסה בשלוש רמות ושליטה ברוחב הפס לכול שרת עם תזמון ז"א ניתן להחליט שבמהלך היום מספקים לשרת רוחב פס של 512KB ובלילה 5MB לרפליקציה של הנתונים.

לסיכום ניתן לראות ש Acronis הוא כלי המיועד בעיקר לגיבויים של שרתים בתוך ה LAN לעומת Double-Take המתאים לארגונים שצריכים פתרון רחב שכולל המשכיות עסקית High Availability, פתרון לאתר DRP / BCP ו / או פתרון לרפליקציה בזמן אמת (ללא איבוד מידע או חלון גיבוי).