פתרון 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 עדיף ברוב המקרים.


כתיבת תגובה

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

*

     

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