שכפול נתונים

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

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

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

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

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

שכפול בדרך כלל מתבצע על העברת תמונות של הנתונים כל בזמן מסוים או על ידי רישום יומן של השינויים שהתבצעו מאז ביצוע השכפול האחרון (או על ידי שילוב שלהם). השכפול יכול להתבצע באופן חד-כיווני או דו/רב-כיווני (במיוחד במערכות אשכולות או במערכות מבוזרות).

השוואה למושגים דומים

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

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

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

מבוא

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

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

יתרונות וחסרונות

היתרונות העיקריים של השכפול הם:

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

החסרונות העיקריים של השכפול:

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

שכפול במערכות מבוזרות

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

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

מודלים לשכפול במערכות מבוזרות

מספר דגמים נמצאים בשימוש נרחב לשכפול נתונים, שלכל אחד מהם תכונות משלו וביצועים משלו:

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

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

שכפול נתונים

ישנן 5 שיטות עיקריות לשכפול של הנתונים והן (מהצמודה ביותר למשתמש הקצה לרחוקה ביותר ממנו):

1. שכפול על ידי היישום - בשיטה זו היישום עצמו אחראי להפצת המידע, גישה זו איננה מקובלת כיום מכיוון שמרבית התוכנות הרלוונטיות משתמשות במסדי נתונים, עם זאת Lotus Notes עדיין משתמש בגישה זו
2. שכפול על ידי מסד הנתונים - גישה זו מסתמכת על מסד הנתונים של התוכנה, היא מוגבלת הן על ידי הצורך במסד נתונים זהה (הגם שלעיתים יש תמיכה במסדי נתונים אחרים) והן על ידי כך שקובצי קונפיגורציה חיוניים מסוימים של התוכנה עלולים לא להיות מופצים. לרוב גם הפצת Directory service נכללת בסוג וזאת משום שההפצה מתבצעת ברמת מסד הנתונים של התוכנה
3. שכפול האחסון ברמת השרת - גישה זו מסתמכת על שכפול של הנתונים בשרת, ברמת ה־LVM או מערכת הקבצים ולרוב היא מוגבלת לשרת המקומי. מערכות RAID אינן נחשבות לרוב כטכניקת שכפול הגם שניתן לדמות בעזרתן שכפול סנכרוני. ניתן להשתמש גם בתוכנות סינכרון על מנת לשכפל נתונים בקנה מידה קטן (למשל בין המחשב הנייד למחשב הקבוע או לכונן רשת)
4. שכפול האחסון על ידי התקן ברשת - בשיטה זו קיים ברשת האחסון התקן המשכפל את הנתונים ליעדים נוספים על המקורי
5. שכפול האחסון על ידי מערך הדיסקים - בשיטה זו מערך הדיסקים עצמו (שעשוי להיות NAS, SAN או לעיתים נדירות גם DAS) אחראי על ביצוע השכפול

חלוקה נוספת של שיטות השכפול היא לפי המרחק הפיזי:

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

שכפול של מסד נתונים

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

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

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

גישות מקובלות לשכפול נתונים במערכות מסדי נתונים כוללות את^[1]:

• שכפול מבוסס הדק (trigger): רוב תוכנות מסדי הנתונים (כולל אורקל, IBM DB2, מיקרוסופט SQL Server ו־Sybase Adaptive Server Enterprise ‏(ASE) מציעות פונקציונליות זו. טכניקה זו מטפלת הן בנתונים חדשים והן בעדכון נתונים קיימים והיא תומכת הן במצב סינכרוני והן במצב אסינכרוני (על ידי שמירת נתוני ביניים). שיטה זו מתאימה בעיקר לשכפול סלקטיבי של הנתונים (למשל נתוני כוח אדם הספיציפי ולא טבלאות הקוד הקבועות) ולא לשכפול של כל הנתונים. השיטה מחייבת לרוב לבחור עמודות ספיציפיות, עם סוגי נתונים סטנדרטי ומובנים (לרוב אין תמיכה ב־*LOB-ים למשל) והיא מוגבלת מבחינת שינויי הסכמה המתאפשרים מבלי לשבור את השכפול. ניתן לשפר את הביצועים של שיטה זו על ידי שימוש בשליחה אסינכרונית הצוברת את הנתונים ומשדרת אותם ביחד (ולעומת זאת עלולה להקטין את רמת העדכניות של הנתונים).
• שכפול מבוסס SQL: השכפול מתבצע על ידי שליחה תדירה של משפטי SQL ממסד נתונים אחד למשנהו. קוד ה־SQL מכיל נתונים מטבלאות מסוימות נשמר בקובץ ביניים או מבוצע ישירות במסד הנתונים השני. גישה זו רגישה לשינויים בסכמת מסד הנתונים ודורשת בדרך כלל זה ביצוע תחזוקה סדירה על מנת להתייחס אליהם ולכן איננה בשימוש נרחב. גישה זו דורשת גם משאבים משמעותיים לביצוע של קוד ה־SQL (לרוב קוד script המבוצע בזמנים קבועים) הדרוש הן למציאת הנתונים והן לעדכונם. יתרונה של גישה זו הוא בכך שאיננה מחייבת תמיכה מיוחדת של תוכנת מסד הנתונים (מעבר לתמיכה הסטנדרטית בקוד SQL) כך שהיא נתמכת על ידי כל סוגי מסדי הנתונים (מערכות מסוימות כמו Data Gaurd לוגי של אורקל מסוגלות לייצור את קוד ה־SQL הדרוש אוטומטית, מה שמקל על השימוש בטכניקה זו). עם זאת מערכת כזאת מוגבלת על ידי מגבלות השימוש בקוד SQL של המשתמש המריץ אותה במערכת המטרה, דבר המקשה על זיהוי של מבצע הפעולה המקורית (מה שעשוי להיות בעייתי בסביבות מאובטחות).
• שכפול מבוסס יומן: גישה זו מבוססת על משלוח יומני הפעילות של מסד הנתונים אל מסד נתונים מרוחק ויישום של הפעולות שם כך שהנתונים במסד המרוחק מסתנכרנים עם המקור. אתחול התהליך מתבצע על בסיס עותק מלא של מסד הנתונים המועתק לשרת האחר. לאחר האתחול יומן הטרנזקציות של מסד הנתונים המקורי נשלח למסד הנתונים המרוחק, לרוב בצורה אסינכרונית. גישה זו יכולה לתמוך בכל גודל של מסד הנתונים וכמות צריכת המשאבים שלה תלויה באופן ישיר בכמות הפעולות המתבצעות בפועל. לרוב ספקי מסדי הנתונים אינם תומכים ביישום פעולות היומן על מערכות מסדי נתונים אחרות אולם ישנן תוכנות צד שלישי התומכות בכך. ישנן גם תוכנות התומכות (כמו אורקל) ביכולת לשלוח רק חלק מהיומן ובכך להקטין את התקשורת ואת צריכת המשאבים של השכפול. מימוש של ספקי צד שלישי של שכפול מסוג זה נתקל לרוב באי תיעוד מלא של היומן ובשינויי מבנה תכופים שלו אולם מצד שני עשוי לאפשר שימוש בגישה זו על מנת לעדכן סוגים שונים של מערכות מסדי נתונים (מה שנתמך לעיתים על ידי הספקים עצמם, למשל Sybase).

בנוסף לגישות אלו המתמקדות בשכפול "פנימי" של מסד הנתונים ניתן לשכפל (גם או רק) את האחסון עליו נשמרים קובצי מסד הנתונים. למשל אורקל תומך ב־ASM שהוא סוג של LVM המיועד למטרה זו ומסדי נתונים אחרים תומכים במערכות חיצוניות למטרה זו (לדוגמה MySQL תומך ב־DBRD למטרה זו). יצירת תמונת נתונים (כל הנתונים בזמן מסוים) נתמכת על ידי סוגי מסדי הנתונים - על ידי רישום של הפעולות שבוצעו ביומן, או על ידי שמירת רישום של הפעולות האחרונות במסד הנתונים (למשל rollback segments או undo tablespace באורקל) או על ידי יצירת תמונות בקבצים נפרדים (למשל ב־SQL Serever בסיוע Volume Shadow Copy Service של חלונות). גם אשכולות יכולים לשמש למטרה זו (דוגמאות לכך כוללות את RAC של אורקל ושימוש ב־memcached עבור MySQL).

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

תוצאות השכפול יכולות (עם תלות מסוימת בגישה בה משתמשים בשביל לבצע את השכפול) להיות משלושה סוגים:

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

שכפול האחסון

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

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

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

פתרונות אלו מסווגים לרוב לפי טיפולם בפעולות כתיבה:

• שכפול סינכרוני - מימוש של "אפס אובדן נתונים" באמצעות טיפול בפעולות הכתיבה האטומיות, כלומר הכתיבה או מתבצעת בשלמותה בשני הצדדים (כלומר התקבל אישור הן מהאחסון המקומי והן מהמרוחק) או בכלל לא. רוב היישומים יחכו עד להשלמת פעולת הכתיבה לפני שימשיכו בעבודה ולכן פעולה זו עשויה להקטין באופן ניכר את ביצועי המערכת, עם זאת מערכות מסדי נתונים אינן סובלות לרוב מבעיה זו (הגם שהתוכנה שמשתמשת בהן עדיין עשויה לסבול ממנה). הביצועים של גישה זו מתדרדרים באופן פרופורציונלי למרחק וזאת כתוצאה מהעיכוב הנגרם על ידי מגבלת מהירות האור - למשל במרחק 10 ק"מ, הזמן המהיר ביותר לקבלת התגובה הוא 67 מיקרו שנייה ואילו במערכות המקובלות כיום (2009) כל המטמון המקומי נכתב בזמן של כ־10-20 מיקרו שניות. הכישלון של שכפול סנכרוני או אפילו רק אובדן רוחב פס מספיק (על פי ההגדרה של המערכת) גורמת לאי ביצוע של כל פעולת הכתיבה ולכן התוצאה המעשית היא הקפאת מערכת האחסון המקומית ולמעשה זאת המשמעות של הבטחת אפס אובדן נתונים. עם זאת, מערכות מסחריות רבות לא יקפאו במצב מסוכן כזה, אלא פשוט ימשיכו בפעולת הכתיבה המקומית ויאבדו את המטרה הרצויה - אי צורך בשחזור.
• שכפול אסינכרוני - כתיבה נחשבת כמושלמת כשהאחסון המקומי ביצע אותה. האחסון המרוחק מתעדכן, אבל בדרך כלל עם פיגור קטן. רמת הביצועים משתפרת מאוד (יחסית לשכפול הסינכרוני), אבל במקרה של אובדן האחסון המקומי, האחסון המרוחק איננו מכיל בהכרח את העותק הנוכחי של הנתונים והנתונים העדכניים ביותר עלולים ללכת לאיבוד. עם זאת בתכנון נכון, המערכת המרוחקת עדיין נמצאת במצב עקבי כך שניתן להעלות אותה (גם אם באיבוד נתונים מסוים) במהירות רבה בהרבה מגיבוי על טייפ.
• שכפול חצי סינכרוני - כתיבה נחשבת כמושלמת כשהאחסון המקומי ביצעה אותה והשרת מרוחק מאשר כי קיבל את המידע וכתב אותה לזיכרון או לקובץ יומן ייעודי. בפועל האחסון המרוחק לא ביצע כתיבה מיד אבל זאת מבוצעת באופן אסינכרוני והתוצאה היא ביצועים טובים יותר מאשר שכפול סינכרוני אבל עם סיכון מוגבר לכשל של כתיבה המרוחקת (אותו ניתן להקטין על ידי שמירה קפדנית על היומן).
• שכפול של מידע בנקודת זמן - מבצע "הקפאה בזמן" של הנתונים באופן מקומי או מרוחק. השכפול יכול להתבצע בשתי שיטות עיקריות:
  • יצירת עותק של השינויים שנעשו על ידי המשתמש - שיטה זו יוצרת "מצביעים" הקובעים לאיזה נתון יש להתייחס כאשר קוראים את הנתונים - העותק הנוכחי או העותק השמור
  • העתקת הנתונים הנדרסים על ידי המשתמש לעותק נפרד - בדרך כלל בשילוב עם העתקה של כל הנתונים כאשר המערכת איננה בעומס ולעיתים גם עם העתקה חלקית מראש. העתקה כזאת מתבצע מתבצעת לרוב בשיטה "העתקה בזמן כתיבה" (Copy on Write) שמשתמשת במצביעים (בדומה לשיטה הקודמת) אולם ישנן גם אפשרויות אחרות, למשל WAFL של NetApp הכותבת את הנתונים החדשים (ולא הישנים) בצד

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

שכפול מבוסס שרת

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

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

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

שכפול מבוסס שרת עשוי להתבצע על ידי מודלים של מערכות ההפעלה המספקים שירותי שכפול נתונים בסיסיים כגון Microsoft Data Protection Manager ‏(DPM) או מערכת המבוססת על פתרונות של ZFS, QFS. ו־SAMfs.

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

יתרונות של השיטה הזאת כוללים:

• העלות עשויה להיות נמוכה מאוד (עקרונית, ניתן לעיתים להשתמש במערכת ההפעלה הקיימת ובדיסקים הקיימים)
• אפשרות שימוש באחסון הטרוגני (מכיוון שהשכפול נעשה ברמת השרת)
• ניתן לרוב להשתמש באחסון DAS ואין צורך באחסון SAN או NAS
• כמה פתרונות יכולים לאפשר לשרת כולו להיבנות מחדש במהירות מכוננים פנימיים משוכפלים כאשר זמין שרת דומה שיכול לשמש כמחליף
• שכפול כזה משתמש בדרך כלל ברשת ה־IP הקיימת
• רוב המוצרים תומכים בהעברת נתונים ברמה של בתים ולא ברמת הבלוק, מה שעשוי לדרוש פחות רוחב פס

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

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

מימושים נפוצים:

• מודול DRBD בלינוקס
• Legato Octopus ו־RepliStor
• NSI Doubletake
• Veritas Volume Replicator ‏(VVR) של Symantec (מאפשר שימוש ברפליקציה אסינכרונית עם שמירה על חיוב כתיבה)
• Fujistu Softek TDMF
• Peer PeerSync
• Diasoft File Replication Pro
• SoftwarePursuits SureSync
• XOsoft WANSync

שכפול בהתקני הרשת

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

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

ישנן שתי גרסאות עיקריות של מנגנון כזה:

• מחוץ לנתיב העיקרי: ההתקן שוכן מחוץ לנתיב הנתונים העיקרי ולכן הקלט/פלט לא עובר דרכו כך שההתקן מבצע את השכפול ללא השפעה על פעולות הקלט/פלט של היישום (כלומר ללא השפעה, לפחות ברמה התאורטית, על הביצועים והאמינות)
• בנתיב העיקרי: ההתקן נמצא בנתיב הנתונים העיקרי ולכן הקלט/פלט עובר דרכו כך שיש השפעה על פעולות הקלט/פלט של היישום

יתרונות שיטה זו:

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

חסרונותיה של שיטה זו:

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

מימושים נפוצים:

• FalconStor Replication & Mirroring (תתי בלוקים הטרוגוניים מבחינת נקודות זמן, שכפול אסינכרוני וסינכרוני)
• HP StorageApps

שכפול מבוסס מערך דיסקים

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

יתרונותיה של השיטה כוללים:

• טכנולוגיה בוגרת
• ישנה תמיכה מרכזית בשרתים רבים כך שהניהול קל יותר
• תומך היטב בסביבה מקומית של שכפול נתונים סינכרוני מעל Fibre Channel
• שימושי ביותר עבור מיינפרם (שלרוב קשה להפעיל שרת גיבוי שלו) ולרוב ניתן להשתמש במערכות התקשורת FICON ו־ESCON שלו
• עבודת השכפול מבוצעת במערך ולא על השרת כך שמשאבי השרת נחסכים
• אין צורך בשרתים בצד השני אלא רק במערכי הדיסקים

חסרונותיה של השיטה כוללים:

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

מימושים נפוצים:

• SRDF של EMC
• PPRC של IBM ו־Global Mirror (הידועים יחד כ־IBM Copy Services)
• TrueCopy של היטאצ'י
• HP DRM

שכפול בזיכרון משותף מבוזר

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

שכפול ראשי-גיבוי ושרתים ראשיים מרובים

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

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

ג'ים גריי ניתח את שיטת שכפול השרתים הראשיים המרובים במודול ההטרנזקציות ובסופו של דבר פרסם מאמר המצוטט רבות שנקרא "The Dangers of Replication and a Solution". במאמר הוא טען כי אם לא ניתן לחלק את הנתונים בדרך טבעית כלשהי כך שניתן להתייחס למסד הנתונים כאל N מסדי נתונים הרי הקונפליקטים בבקרת המקביליות יביאו להרעה משמעותית בביצועים ברצינות מושפל וקבוצת העתקים כנראה תאט כפונקציה של N ואכן הגישות הנפוצות ביותר עשויים לגרום להרעה בביצועים מסדר גודל של O(n³)‎ ולפיכך חלוקת הנתונים ניתנת לביצוע מעשי רק במצבים שבהם יש לנתונים יש מפתח חלוקה טבעי.

אולם למעשה המצב לא תמיד כל כך עגום, לדוגמה, ב־1985-1987, הוצע מודל וירטואלי סנכרוני והתקבל כסטדרנט שהיה בשימוש ב־Isis Toolkit, Horus, Transis, Ensemble, ־Totem, Spread, C-Ensemble ובמערכות Phoenix ו־Quicksilver והיווה את הבסיס עבור הסבלנות לתקלות של סטדרנט CORBA. כיום המודל משמש גם בלוגיקת השכפול שלIBM Websphere ושל Windows Server 2008 Enterprise clustering של מיקרוסופט. הסינכרון הווירטואלי מאפשר את הגישה הרב ראשית בה קבוצה של תהליכים משתפת פעולה כדי למקבל היבטים מסוימים בתהליך העיבוד של הבקשה. אמנם בשיטה זו ניתן להשתמש רק עבור כמה צורות של נתונים בזיכרון אבל כאשר היא אפשרית אזי היא מאיצה את התהליך באופן התלוי ליניארית בגודל של הקבוצה.

ראו גם

• שיקוף נתונים
• Continuous data protection
• שכפול עצמי

קישורים חיצוניים

• Sushant Goel, Adaptive Middleware for Data Replication, Dr. Buyya's Cyberhome
• Jacob Farmer, Crash Course Wide Area Replication, SNIA

הערות שוליים

1. Noel Yuhanna, Database Replication: A Flexible Technology for Data Integration Tasks, September 1, 2005