Active Active Netapp Solution

פוסט נבחר

אני מסתובב בהרבה ארגונים בארץ ואני חייב לציין שרוב הארגונים שאני מכיר שעובדים עם NAS משתמשים ב Netapp. Netapp הוא המוביל הבלתי מעורער של יישומי ה NAS בארץ. יישומי NAS הם בד"כ שרתי קבצים המספקים גישה באמצעות פרוטקולי CIFS למערכות מיקרוסופט או NFS למערכות לינוקס. משתמשים בהם בעיקר לאחסון קבצים לעבודה משותפת של משתמשים, לעבודה של אפליקציות, לכונני רשת עבוד משתמשים וקבצים אישיים.

ארגון שכולל יותר מסניף אחד צריך לבחור אם הוא מספק Netapp Storage לכול סניף או משתמש בשרתי קבצים מקומי (Windows או Linux) למשתמשים באותו אתר. היתרון הוא שכול אתר יכול לעבוד מקומית על החומר שלו. החיסרון הוא שאין שיתוף מידע. כך נוצר מצב בו משתמש שרוצה לעבוד על קובץ שנמצא באתר אחר, צריך להעתיק אותו מקומית ובכך ליצור כפילות של קבצים ומידע לא תואם בין אתרים. כמו כן במידה ומשתמש נודד מאתר לאתר הוא לא יכול לעבוד על החומר שלו וצריך להתחבר על קווי התקשורת שמאטים את העבודה שלו.

בנושא הגיבוי, כול Netapp Storage או שרת קבצים מגובה מקומית בסניף או מרופלק באמצעות Snap Mirror על גבי הרשת ל Storage המרכזי בשיטת Active Passive שם מגובה לדיסקים או לקלטות. לאתר DR בדרך מרפלקים את ה Storage הראשי גם ב Snap Miror ל Netapp Storages נוסף שנמצא באתר הגיבוי שהוא פסיבי לחלוטין.

חברת PEER Software יצרה פתרון ייחודי המותאם ל Netapp שיודע לבצע רפליקציה דו כיוונית בין Netapp ל Netapp וגם ל Windows לצרכי קולברציה. הרפליקציה היא בשיטת Real Time Byte Level המבוצעת בזמן אמת ללא חלונות זמן. כמו כן היא דו כיוונית ומאפשר קריאה וכתיבה בכול האתרים בו זמנית. כך שלמעשה כול האתרים רואים את כול החומר המשותף ויכולים לעבוד עליו במקביל. הפתרון כולל מערכת נעילת קבצים למניעת קונפליקטים כך שאם משתמש פותח קובץ באתר א', משתמש שני באתר ב' יכול לפתוח אותו קובץ מקומית לקריאה בלבד. לאחר מכן ברגע שהמשתמש באתר א' סוגר את הקובץ, השינוי מתרפלק לאתר ב' והקובץ נפתח לקריאה וכתיבה באתר ב'. לבסוף הטכנולוגיה כוללת שימוש ב DFS של מיקרוסופט לצורך הכוונה אוטומטית כך שמשתמש שנודד מאתר לאתר תמיד יפתח את הקבצים שקרובים אליו פיזית.

במידה ויש אסון אין צורך לבצע Fail Over בקונסול של Netapp. החומר כבר זמין באתר המשני אקטיבי בתצורת Read Write. DFS כבר יפנה את המשתמשים אוטומטית לשם…

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

להלן נקודות המפתח:

  1. PEER היום הפתרון היחיד בעולם שיודע לרפלק Netapp ב Real Time באמצעות שימוש ב fPolicy.

  2. רפליקציה בשיטת Real Time Byte Level עם מנגנון Multithread גרנולרית וחסכונית ברוחב פס לקווי תקשורת איטיים.

  3. רפליקציה בין סוגי Neatapp שונים וגם ל Windows.

  4. רפליקציה בתצורת Mesh בין אתרים מרובים בעולם.

  5. מערכת נעילת קבצים למניעת כפילויות.

  6. שימוש ב DFS להכוונת משתמשים לאתר הקרוב אליהם.

  7. תמיכה ב CIFS.

  8. מערכת ניהול והתראות מרכזית.

אשמח לענות על כול שאלה בנושא.

להלן ברושור בנושא.

 


רפליקציית קבצים מנטאפ (Netapp) ל Windows

פוסט נבחר

Netapp היא אחת חברות ה Storage המובילות בעולם עם ליין מוצרים מרשים ויכולות רבות. בארץ ישנם הטמעות Netapp רבות בארגונים בכול הגדלים. Storage Netapp עונה על צרכים רבים כגון נפחי אחסון, ביצועי IOPS גבוהים, שרידות, המשכיות עסקית וכדו'. הצורך השכיח ביותר של ארגונים עליהם Netapp עונה הוא שרת קבצים מנוהל בתוך ה Storage – NAS. שימוש ב NAS על גבי Storage מאפשר ביצועים גבוהים בעבודה עם קבצים בכמויות ובגדלים משתנים בשונה משרת קבצים שיוצר צוור בקבוק של מערכת הפעלה.

כיועץ לפתרונות רפליקציה, לא פעם אני מגיע לארגון שמשתמש ב Netapp כשרת קבצים NAS וצריך פתרון המשכיות עסקית או רפליקציה. הפתרונות היחידים שמציעים לו ספקים הם רכישת Netapp נוסף ושימוש ב Snapmirror לבצע רפליקציה בין שני ה Netapp על גבי WAN או שימוש ב Netapp שיתופי באתר Hosting וביצוע רפלקציה עם Snapmirror. הארגון נשאר "שבוי" בכך שהוא בחר נכון בשימוש ב Netapp לשיפור ביצועים אך מוגבל מאוד בפתרון הרפליקציה.

החסרונות בשיטות לרפליקצית Netapp ה"סטנדרטיות" הן:

  1. לביצוע רפליקציה חייבים לרכוש Netapp נוסף בעלות נוספת.
  2. האפשרות הנוספת היא שימוש ב Netapp שיתופי שנמצא במספר קטן של ספקי ענן מקומיים בלבד. כמו כן, ישנה סכנה של זליגת מידע וניצול Over Commit בביצועים ונפחים של ספק הענן.
  3. הרפליקציה היא Snapmirror שהחסרונות שלה:
  4. מבצע רפליקציה Block Level שמחייבת Snapshots לשמירה על Consistency.
  5. מחייב רוחב פס מתאים בנפחים.
  6. ביצוע Snapshots ב Storage מקור גוזל משאבים ב Storage.
  7. עובד רק מ Netapp ל Netapp.

כמובן שניתן להשתמש בטכנולוגיות Netapp כגון Metro Cluster או Snapmirror סינכרוני אך זה דורש שימוש בקו אופטי בין האתרים בעלויות מאוד גבוהות.

הפתרון הוא מוצר בשם PEER המאפשר רפליקציה של Netapp ל Windows. המוצר הוא היחיד מסוגו בשוק שיודע לבצע רפליקציה Real Time Byte Level מכול Netapp NAS עם CIFS לכול Windows. באמצעות פתרון ייחודי זה ניתן לצור אתר DRP לכול ארגון עם Netapp NAS שיכול להיות בכול מקום. למשל ניתן לרפלק את ה Netapp לשרת Windows בענן של Amazon בארה"ב או לשרת Windows בספק ענן מקומי או פשוט לסניף אחר של הארגון.

הייחוד של PEER עם Netapp היא היכולת שלו לעבוד עם ה fPolicy של ה Netapp ולקבל ממנו התראות בזמן אמת על כול שינוי בכול קובץ. יכולות זו הפכת את PEER למוצר היחיד בשוק שיודע לרפלק Netapp NAS ל Windows ב Real Time. כמו כן אפשר להשתמש ב PEER במספר תסריטים כגון רפליקציה של Windows ל Netapp, Netapp ל Netapp או Windows ל Windows.

PEER מגיע במספר גרסאות שונות למספר יישומים. הגרסאות הנפוצות הם PEER Sync Server לרפליקציה של Netapp לאתר DRP או לצורך גיבוי ו PEER Link לרפליקציה דו כיוונית של Netapp ל Windows או ל Netapp אחר לצרכי שיתוף וקולבצרציה. היתרונות הגדולים של PEER הם:

  1.  שימוש ב fPolicy של Netapp לצורך רפליקציה בזמן אמת.
  2. רפליקציה Netapp to Netapp, Netapp to Windows, Windows to Netapp או Windows to Windows.
  3. רפליקציה בתצורת Real Time Byte Level – רפליקציה בזמן אמת עם איבוד מידע קרוב ל 0.
  4. רפליקציה מאוד יעילה שכן מעבירה רק חלקי קובץ ברמת Byte Level ושימוש ב Multi Thread להעתקה.
  5. רפליקציה שרצה על גבי WAN על קווי תקשורת איטיים עם Latency גבוה ושומרת על Real Time.
  6. רפלקיציה דו כיוונית לפתרונות שיתוף וקולברציה בין סניפים עם נעילת קבצים גם בין Netapp ל Windows.

ישנם פתרונות נוספים שניתן לבצע עם PEER כגון רפליקציה לצורך מיגרציה מ Windows ל Netapp או להפך, רפליקציה מ Netapp לתחנות עבודה לצורך שיפור ביצועים של Netapp, רפליקציה לצורך גיבוי אתרים מרוחקים וכדו'.

תוכלו לפנות אלי בכול שאלה, לצורך קבלת גרסת הדגמה ולהתנסות.

ארז פז – יועץ לפתרונות רפליקציה

erez@singular.co.il

052-6943035


העתקת קבצים \ העברת קבצים מכול NAS לכול Windows

פוסט נבחר

פתרון לקבצים גדולים \ שיתוף קבצים \ שליחת קבצים גדולים

Storage הפך היום לכלי הכרחי בארגונים בינוניים וגדולים למספר מטרות כגון ריכוז נפחי מידע גדולים, ביצועים טובים בעבודה עם דיסקים וזמינות גבוהה. כמו כן כאשר רוצים ליצור Cluster לזמינות שרתים חייבים להשתמש ב Storage. רוב הארגונים משתמשים בשתי תצורת ממשק ל Storage שהם SAN לצורך חשיפת LUN כדיסקים לשרתים ו NAS כשרת קבצים (Filer).

העברת קבצים ורפליקצית קבצים

אחד האתגרים שיש לארגונים היא היכולת לרפלק (להעתיק \ לסנכרן) שרתי קבצים לצרכים שונים כגון אתר DRP, גיבוי אתרים מרוחקים, הורדת עומס מסטורג', העתקת תכנים לתחנות קולברציה ושיתוף בין סניפים וכדו'. אם שרת הקבצים הוא Windows ניתן לרפלק אותו ע" כלים שונים כגון DFSR המובנה. אך אם שרת הקבצים יושב על NAS אז מוגבלים לכלים שספקי ה Storage מספקים.

חברת PEER האמריקאית יצרה פתרון שמבצע רפליקציה מכול NAS או Windows לכול NAS או Windows. באמצעות פתרון זה ניתן לבצע רפליקציה מתוזמנת או ב Real Time של כול שרת קבצים לא משנה אם הוא מבוסס Windows או NAS לכול Windows או NAS. הפתרון נקרא PEER Sync. הפתרון מאוד חזק אך פשוט ליישום, לדוגמה, אם רוצים לרפלק קבצים לאתר DRP מ Storage NAS EMC VNX באתר המרכזי ל Windows באתר מרוחק במשרד משני או בענן (למשל ב Amazon), מתקינים על שרת ה Windows המרוחק את הפתרון PEER Sync server ומגדירים בו Job לרפליקציה מה NAS לשרת ה Windows. ניתן לרפלק על Port מסוים מוצפן אחד וכך לשמור על אבטחת מידע גם על גבי האינטרנט.

דוגמה נוספת היא: ארגון מעונין לרפלק שרת Windows בסניף מרוחק ל Netapp NAS באתר הראשי לצורך גיבוי השרת ב NAS. על שרת ה Windows מתקינים את PEER Sync server ועל יד ה Netapp מתקינים שרת Windows נוסף ועליו מתקינים PEER Listener. מגדירים ב PEER Sync server את ה Job שירפלק מה Windows ל Netapp וזהו.

הפתרון מורכב בד"כ משרת PEER Sync שמחזיק את ה Jobs והוא שרת המקור ומ Listener שיושב בשרת היעד. הפתרון מאוד יעיל ומאוד "קל" שרת ה PEER Sync שוקל 12MB וה Listener שוקל 3MB בלבד!

עם PEER Sync עוד ניתן לבצע רפליקציה ב Real Time בין Netapp NAS ל Netapp NAS, בין Netapp NAS ל Windows, בין Windows ל Netapp ובין Windows ל Windows. היתרון הגדול של PEER Sync אל מול Snap Mirror של Netapp הוא ש PEER Sync מרפלק ב Real Time Byte Level בשונה מ Snap Mirror שמבצע Snapshots והרפליקציה היא Block Level ומתוזמנת במרווחי זמן של דקות או שעות (תלוי ברוחב הפס). כמו כן, Snap Mirror יודע לרפלק רק בין Netapp לעומת PEER Sync שיודע לרפלק גם בין Netapp ל Windows ולהפך.

 File Sharing בין סניפים היא אחת היכולות המרכזיות והמעניינות ביותר של PEER

להלן תמצית של היכולות המרכזיות של ל PEER Sync:

  1. רפליקציה Real Time Byte Level – רפליקציה בזמן אמת אשר מעבירה חלק יחסי של קבצים בלבד ברמת Byte בלבד.
  2. רפליקציה מכול NAS או Windows לכול NAS או Windows.
  3. רפליקציה Real Time ל Netapp עם שימוש ב fPolicy.
  4. רפליקציה מתוזמנת או Real Time.
  5. רפליקציה משרתים או NAS לתחנות או מתחנות לצרכי גיבוי או הורדת עומס מ NAS.
  6. רפליקציה דו כיוונית לצרכי שיתוף וקולבורציה.
  7. מערכת נעילת קבצים למניעת כפילויות ברפליקציה דו כיוונית לצרכי שיתוף קבצים.
  8. המערכת מבצעת דחיסה ושימוש יעיל ב WAN.
  9. התקנה והגדרה פשוטה ומהירה.
  10. כלי ניהול והתראה לארגוני Enterprise לניהול מאוד ואלפי Jobs.

שליחת קבצים – Send File

Peer Sync הוא פתרון יעיל לתסריטים רבים של העברת קבצים ורפליקציה של קבצים לארגונים שרוצים לשכפל קבצים בתוך האתר, לסניפים מרוחקים או לענן. הפתרון הוא היחיד מסוגו לרפלקציה ב Real Time מ Netapp ומספק פתרון לרפליקציה לכול NAS או שרת Windows.

 לפרטים נוספים

העתקת קבצים \ העברת קבצים מכול NAS לכול Windows


לחסוך ב 90% מנפח הוירטואליזציה על גבי ה Storage!

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

כאשר מתכננים רכישה של סטורג' חדש, לקוחים בחשבון שלושה נושאים: ביצועים, שרידות ונפח – בסדר הזה. לאחר שמחשבים את כמות ה I/O הדרוש ניתן בקלות לחשב כמה Disk Spindles צריכים על מנת  לעמוד בדרישת הביצועים לפי טכנולוגיית הדיסקים (FC, SAS, SATA וכדו'). כמו כן, צריכים להבחין ביחס בין קריאה לכתיבה שכן בפרויקטים כדוגמת VDI היחס הוא לעיתים 90/10. בנושא שרידות  צריך לשים לב שיש מספיק Spindles לעמוד בדרישות הביצועים בשימוש ב RAID שכן RAID יוצר קריאות I/O נוספות. בנושא נפח, צריך לחשב את כמות הנפח הדרוש אך לשים לב ש Spindles דורש נפח ברוטו יותר גדול. לדוגמה, אם לארגון יש 500 שרתים וירטואלים שכול אחד מהם משתמש ב 50 GB של Storage, צריך 25TB  נפח של Storage. כדי לעמוד ב 20,000 IOPS עם דיסקים 15K 450GB FC, שכול אחד מהם יכול לספק 200 IOPS, יש צורך ב 100 דיסקים. אבל 100 דיסקים של 450GB מספקים 45TB שזה הרבה מעבר לנפח האמיתי שהארגון צריך.

נקודה נוספת שצריך לשים לב, היא שבוירטואליזציה מתבצעות כתיבות I/O בצורה איטנסיבית ואקראית בכול שרת Host. דיסק המספק 200 IOPS לא יתקרב למהירות הזו מנקודת המבט של המכונה הוירטואלית. זאת הסיבה מדוע חייבים לבצע הוכחת יכולות לסטורג' בתשתית האמתית של הארגון כדי לקבל תמונת מבט אמתית של הביצועים.

Virsto הוא פתרון ייחודי בשוק שמאפשר שיפור ביצועים של עד פי 10 ויותר לסביבות וירטואליות על גבי Storage, כמו כן מקטין את השימוש ב Storage ב 90% ומאפשר ביצוע מאות Clones לשרתים וירטואלים בשניות בודדות. המוצר מיועד ל VMware ESX 5.1 ומטה ול Hyper-v 2012 ומטה. מכונות וירטואליות יוצרות בכול תשתית קריאות I/O בצורה לא מסודרת ואקראית ומתנקזות ל Driver אחד ב Host שמנסה לעמוד בקצב. כל מכונה וירטואלית תמתין עד שתקבל Acknowledge מה Host שהכתיבה התבצעה ותעבור לכתיבה הבאה, עניין שמעקב מאוד את המכונה הווירטואלית. Virsto כולל טכנולוגיה ייחודית בה הוא מבצע סדר קריאות ה I/O של המכונות הווירטואליות בכול Host ומעביר דרכו את הקריאות. בעת שמכונה וירטואלית מנסה לכתוב, הוא תופס את הכתיבה, שם אותה ב Log זמני ומיד שולח Acknowledge למכונה הוירטואלית שהכתיבה התבצעה, לאחר מכן Virsto מבצע את הכתיבה בפועל בצורה  A synchronicלדיסק. באופן הזה משפר את הביצועים של ה VMs בכתיבה עד פי 10 ויותר ואת הביצועים של הקריאה ב 20%.

ע"י שימוש ב Virsto הארגון בדוגמה שלנו יכול לקבל ביצועים הרבה יותר גדולים ובכך להשתמש בפחות דיסקים. במקום ב 100 דיסקים ב 20. אבל 20 דיסקים של 450GB  הם 9 TB ואמרנו שצריך 25 TB. גם פה Virsto מסייעת ע"י שימוש בטכנולוגיית Thin Provisioning. כדי לקבל ביצועים ממכונות וירטואליות כיום, ארגונים בד"כ יוצרים דיסקים בפורמט FIX. הארגון פה בדוגמה משתמש ב 500 שרתים וירטואלים עם 50 GB כול אחד. אך למעשה רוב הסיכויים שרוב המכונות הוירטואליות לא מתקרבות לשימוש ב 50GB  וצורכות 500 MB או 1GB . Virsto תנהל את כול נושא ה Thin Provisioning ותגרום לשרתים לחשוב שיש להם 50GB , למעשה יהיה להם רק את הנפח בשימוש. באופן זה ניתן לחסוך בין 70% ל 90% מנפח ה Storage. הטכנולוגיה של Virsto לשיפור ביצועים מונעת כל פגיעה בביצועים עקב שימוש ב Thin Provisioning.

ל  Virsto ישנה טכנולוגיה נוספת שמאיצה ביצועי יצירת Clones וגם חוסכת במקום נוסף ב Storage. הטכנולוגיה נקראת Single Image Management. בכול פעם שהארגון יצור שרת חדש מ Image קיים, Virsto  יוריד את נפח השרת המשוכפל ללא פגיעה בביצועים. Virsto מייצר Golden Image שנקרא vClone ומנהלת את כול הקריאות לדיסק הזה. Virsto תמקם את ה vClonee בדיסק מהיר וכול שאר המכונות יחשבו שיש להם גישה בלעדית לאותו Master. השיטה הזו הרבה יותר יעילה מ De-dup כי היא לא מייצרת מאות בלוקים בדיסק שצריך לבצע עליהם תהליך De-dup מלכתחילה.

החיסכון ב 90% של נפח ה Storage מתבטא באופן הבא: שיפור ביצועים של עד פי 10 ויותר לחסכון בכמות ה IOPS הדרוש. ז"א אם ארגון צריך 20,000 IOPS, עם Virsto הוא יכול להסתפק בחומרה שתספק 2000 IOPS בלבד. אין צורך בדיסקים FIX, Virsto ע"י שימוש בטכנולוגיית Thin Provisioning תנהל את צריכת הדיסק של הוירטואלים ללא ירידת ביצועים. בכול יצירת שרת עתידי, Virsto תנהל את ה vClone (Master Image) שלו ותחסוך ב 90% מהנפח העתידי שלו.


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