שכפול DFS דרך VPN: הנעילה היא לא מה שאתם מקבלים

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

המיתוס: VPN הופך את העותקים למערכת קבצים אחת

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

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

מה DFSR באמת משכפל

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

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

שטח staging הוא קיבולת עבודה, לא גיבוי

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

staging אינו גיבוי, והפצת שינויים אינה היסטוריית גרסאות.

הזרעה מראש היא אופטימיזציה, לא קיצור דרך

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

אמתו את המצב ההתחלתי לפני שמשתמשים תלויים ביעד, לא אחרי התלונה הראשונה.

בחרו את החלון והגדירו מה פירוש עדכני

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

כתבו את המשפט הזה, כי «הפיגור הוא ארבעים דקות» מדאיג רק אם אף אחד לא הגדיר את היעד.

קבלו עם זרימת העבודה, לא עם קובץ אחד

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

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