רפליקציית קבצים מנטאפ (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

גם לכם יש עוד בית (בית מגורים) למקרה אסון?

נניח שעל מנת לקבל ביטוח על הבית שלכם, חברת הביטוח הייתה דורשת ממכם לרכוש בית נוסף קצת יותר קטן למקרה של אסון. ז"א שאם הבית שלכם נחרב או עולה באש יהיה לכם בית נוסף כגיבוי. נשמע הזוי, לא? זה בדיוק מה שרוב הארגונים עושים היום! יש להם אתר DRP שהוא ב 80% זהה לאתר המקור והם משתמשים בו רק בעת חירום. אתם מבינים את גודל ההוצאה???

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

מעבר לכך מקבלים את כול שאר היתרונות כגון: שימוש עצמאי ושליטה מלאה בשרתים עם פורטל שליטה ללא צורך לתקשר מול הספק (Self Provision), הספק דואג לתחזוקת החווה עם החומרה והתוכנה העדכניים ביותר, כמו כן, דואג לאבטחה ולתקשורת מהירה. מה שצריך זה רק קו אינטרנט, ספק ענן ותוכנת רפליקציה.

Double-Take היא התוכנה היחידה בעולם שיודעת לבצע רפליקציה בזמן אמת, כול תשתית לכול ענן. זה לא משנה אם יש לך שרתים פיזיים או וירטואלים, Hyper-v או VMware, מערכת הפעלה Windows או לינוקס. תוכל לקפלק את השרתים שלכם לענן לצרכי DRP.

לאחרונה יצרנו שת"פ עם מיקרוסופט לאור יציאת שירות חדש בענן שלהם (AZURE) שמספק מכונות וירטואליות On demand. באמצעות Double-Take לקוחות מיקרוסופט יכולים לרפלק את כול התשתית שלהם לענן של מיקרוסופט. להלן מאמר שכתבתי בבלוג של מיקרוסופט TechNet עם דוגמה להגנה על שרת פיזי לענן של מיקרוסופט. קריאה נעימה.

 

פתרונות המשכיות עסקית – 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.

המשכיות עסקית בצל האיום הביטחוני

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

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

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

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

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

ישנם מספר ספקים מקומיים וגלובאלים שמספקים פתרונות ענן ציבורי מאובטחים ודרכם ניתן ליצור סביבה דינאמית לאתר חלופי שיהווה פתרון בעת חרום. ספקים אילו מספקים שרתים וירטואלים אליהם ניתן לרפלק (להעביר באופן שוטף) את שרתים שבהם נמצאים האפליקציות והמידע של הארגון. כמו כן ספקי הענן הציבורי מציעים סביבה מאובטחת השומרת על המידע וחיבור מאובטח לאתר המקור, אתר ניהול דרכו ניתן לנהל את השרתים הוירטואלים, שרידות מקומית ולעיתים גיבוי. באמצעות תוכנות רפליקציה ניתן לבצע שכפול של המערכות ולבצע Fail Over (מעבר לאתר חלופי) בעת אסון בצורה יזומה. בין הספקים הגלובלים המובילים היום ניתן למצוא את מיקרוסופט עם פתרון ה Azure ו Amazon עם פתרון EC2. בתוכנות הרפליקציה ניתן למצוא את Double-Take כמוביל בתחום הרפליקציה בזמן אמת ו VMware עם יכולות שכפול מובנות.

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

ההרצאה המלאה מכנס CloudCon 2012 על המשכיות עסקית

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

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

צפייה נעימה :) .

להלן הלינק לאתר עם הסרטונים.

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 שנה ומובילים את התחום בהפרש ניכר מכול שאר המתחרים בתחום.

לחסוך ב 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% מהנפח העתידי שלו.

רשמים מכנס CloudCon 2012

ביום שלישי האחרון הייתי שותף ומציג בכנס CloudCon 2012 שנערך במלון דויד אינטרקונטיננטל בת"א. לכנס הגיעו להערכתי כ 200 משתתפים שכללו אירגונים שונים בארץ, יועצים וספקי תשתית. כול הכנס סבב סביב פתרונות הענן החדשים שיש כיום בתחום ה IT וכיצד ניתן לקדם אותם אצל ארגונים. אני, כחלק מהחסות שלקחנו ב Singular יחד עם חברת Vision Solutions, בצעתי שתי מצגות. הראשונה הייתה הצצה כללית על פתרונות Double-Take להמשכיות עסקית לענן ומעבר לענן ללא השבתה. במצגת השנייה נכנסתי יותר לעומק איך הטכנולוגיה עובדת עם סרטוטים. את המצגת השנייה העברתי עם ה iPad שלי עם עט מיוחדת ל iPad שזה היה מגניב לכשעצמו :)

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

פה נכנס Double-Take. באמצעות הטכנולוגיה הייחודית שלו, הוא מאפשר לשכפל ולרפלק כול שרת מכול תשתית לכול ענן. שרתים פיזיים, שרתים וירטואלים מכול טכנולוגיה כגון VMware, Hyper-v, Xen ועוד. לא משנה מה סוג ה Storage באתר מקור. כמו כן הרפליקציה שלו היא Real Time Byte Level שזה אומר שה RPO קרוב ל 0 (איבוד מידע של שניות בלבד) והמידע נשאר עמיד (Consistent) ללא Snapshots.

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

לצפייה בסרטון מהכנס בו מראיינים אותי - אני מדבר מדקה 01:15

לצפייה בתמונות מהכנס.

להורדת המצגות: מצגת 1, מצגת 2.

כנס CloudCon 2012 ו… הפתעה!

ביום שלישי הקרוב יתקיים כנס CloudCon 2012 של אנשים ומחשבים. אנחנו ב Singular לקחנו חסות משותפת עם חברת Vision Solutions האמריקאית (חברת האם של Double-Take). בכנס הזה אני מרצה שתי הרצאות כול אחת 15 דקות במליאה הראשית. במצגת הראשונה ב 09:30 אספר באופן כללי על הפתרון של Double-Take Availability וכיצד הוא מאפשר לצור אתר DRP מכול תשתית לכול ענן כמו כן אספר על פתרון Double-Take Move שמאפשר להעביר כול שרת לענן ללא השבתה. במצגת השנייה ב 13:00 אכנס קצת יותר לעומק ברמה התכנית לשיטת הרפליצקיה עם מספר הדגמות מגניבות.

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

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

אשמח לראותכם  :)

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