אפשרויות שכפול ו-DR

מטרת מאמר זה

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

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

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

אפשרות ראשונה: PaperTrail – PaperTrail Replication (זמינות גבוהה)

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

כאשר שכפול מוגדר באפליקציית PaperTrail, נדרשים שני רישיונות PaperTrail ושני השרתים נדרשים להיות מקוונים עם נתיב HTTP רציף פתוח ביניהם.

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

יש להשבית את כל תהליכי הייבוא ​​האוטומטיים בשרת הראשי
PaperTrail בשרת הראשי הנוכחי חייב להיות במצב לא מקוון (כדי לקבל מצב סטטי של נתונים)
גיבוי DB מהמאסטר נלקח והוכנס ל-Slave DB
מאגר קבצים ואינדקס נתונים (קבצים בדיסק) שהועתקו מהמאסטר לעבד
הגדרת מאפייני DB, מאגר קבצים ואינדקס של שכפול הן במערכות המאסטר והן במערכות ה-Slave (תצורה לא מקוונת של PaperTrail)
מרווחי שכפול (2) וקיזוזים המוגדרים הן במערכות המאסטר והן במערכות ה-Slave (תצורה לא מקוונת של PaperTrail)
שינויי תצורה ברישיון PaperTrail במערכת ה-Slave (רישיון ספציפי לארח)
יש להביא את מופע ה-Master PaperTrail באופן מקוון במלואו
יש להביא את מופע Slave PaperTrail באופן מקוון במלואו
שינוי תצורה מקוונת במופע ה-Slave PaperTrail כדי לשנות את שרת מאגר הקבצים מהשם המארח של המאסטר לזה של ה-Slave
הפעל מחדש את מערכת Slave PaperTrail כדי לאפשר את השינויים בחנות הקבצים לעיל
בדיקה בסיסית עם נתוני דמה כדי להבטיח שכפול מוצלח בין מאסטר ל-Slave (בדיקה דו-כיוונית)
הפעל מחדש את כל תהליכי הייבוא ​​האוטומטיים בשרת הראשי

לאחר ההגדרה וההפעלה, שני המופעים של ה-front-end PaperTrail זמינים כממשקים נפרדים, בלתי תלויים זה בזה, עם חיבור HTTP לשכפול שינויים מכל צד לצד השני (Master > Slave ו-Slave > Master).

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

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

יתרונות שכפול

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

חסרונות שכפול

השלכות עלויות הקשורות לשני רישיונות שרת PaperTrail, כולל כל המודולים הרלוונטיים (למשל זרימת עבודה, API, eSign). רישיונות משתמש ייטענו בשתי המערכות, אך יחויבו רק פעם אחת
השלכות עלויות הקשורות לעלויות SUA בכל שרת
אינו משמש ככספת כשל לשחזור ישויות (מסמכים, צמתים וכו') שנמחקו בטעות בכל אחת מהמערכות. לאחר ביצוע, עסקת המחיקה נדחפת למערכת המשוכפלת
התקנה מורכבת ביותר
סיכון גבוה הכרוך בשכפול של עסקאות, במיוחד ברמת הפיתוח המותאם אישית הקיים (ומתמשך) על הסביבה. זה יצטרך להיבדק ביסודיות במצב הנוכחי כדי להבטיח שעסקאות אינן משוכפלות כאשר כל מערכת שולחת עסקה משלה החוצה (למשל אימיילים, קריאות API, תוספות DB חיצוניות)
כל פיתוח מותאם אישית חדש יצטרך להיבדק על הגדרת סביבה לצורך שכפול לפני שיש לשקול אותו לפריסה למערכות LIVE
אם אחת מהמערכות תהיה במצב לא מקוון במשך תקופה ממושכת, הניסיון החוזר של PaperTrail של עסקאות שכפול כושלות יכנס למצב מת. לאחר מכן יהיה צורך לבנות מחדש את השכפול מאפס עם זמן ההשבתה הקשור.
רצוי מאוד שמערכת DEV מלאה (עם הגדרת שכפול מאסטר ו-Slave) תהיה זמינה לבדיקה. זה ייכנס

קבל רישיון PaperTrail נוספים ועלויות SUA

שכפול תיאור גרפי

אפשרות שנייה: מערכת המתנה קרה (שכפול של מאגר קבצים בתור WORM)

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

עם גישה זו, נדרש רק רישיון FULL PaperTrail יחיד (שרת, מודולים ומשתמשים) מכיוון שרק מופע אחד של היישום מקוון. מערכת Cold Standby תדרוש רישיון שרת בלבד, אשר נגבה כהשכרה חודשית. עלויות SUA יחולו רק על שרת בודד, בעוד ששניהם ישודרגו. מאגר קבצים משני של PaperTrail מוגדר באפליקציה כ-WORM (כתוב פעם אחת, קרא הרבה) קבצים.

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

למרות שרצוי ש-PaperTrail ב-Master ייסגר ואז עותק של מאגר מאגר הקבצים יילקח במצב סטטי למערכת המתנה קרה, זה לא הכרח (PaperTrail מספק סנכרון של חנות הקבצים מהראשי ל-Cold Standby. WORM בזמן מקוון).
אחסון קבצי WORM משני מוגדר ב-PaperTrail ב-Master כך שיצביע על המיקום המרוחק
יש להפעיל מחדש את PaperTrail ב-Master כדי לבצע את השינוי ב-File Store
סנכרון מאגר הקבצים פועל מהמאגר הראשי ל-WORM (אופציונלי תלוי בהחלטה שהתקבלה בשלב 1 לעיל)

במקרה של בדיקת DR / שחזור נתונים שנמחקו בטעות

PaperTrail על המאסטר ממשיך לרוץ ללא הפרעה עם השכפול המתמשך של WORM File Store ללא פגע
הגיבוי האחרון של DB מנותק ונבלע במערכת המתנה קרה
רישיון PaperTrail נוסף למערכת Cold Standby ופרטי SMTP מוסרים כדי להבטיח שלא יישלחו מיילים
PaperTrail על מערכת Cold Standby מובא באינטרנט
שם השרת Run As עבור מאגר הקבצים WORM משתנה לשם המארח של מערכת Cold Standby
כל עבודות הייבוא ​​האוטומטי נשארות כפי שהן. אלה לא יפעלו מכיוון ששם ההפעלה כשרת מתייחס למערכת הראשית
PaperTrail במערכת Cold Standby מופעל מחדש כדי לבצע את השינוי ב-File Store
יצירת אינדקס של נתונים נבנה מחדש במערכת המתנה קרה
ניתן לעיין במבנה מסד הנתונים המפנה למסמכים ולרשומות דרך החזית הקדמית של PaperTrail. תצוגה מקדימה והורדה של מסמכים תטופל על ידי חנות הקבצים של WORM
לשחזור נתונים שנמחקו בטעות בלבד: ניתן לייצא מסמכים ממערכת Cold Standby ולייבא אותם חזרה למערכת המאסטר באמצעות פונקציונליות רגילה של PaperTrail בכל מערכת
PaperTrail על כיבוי מערכת Cold Standby והרישיון הזמני נשלל

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

עם גישה זו, נדרש רק רישיון FULL PaperTrail יחיד (שרת, מודולים ומשתמשים) מכיוון שרק מופע אחד של היישום מקוון. מערכת Cold Standby תדרוש רישיון שרת בלבד, אשר נגבה כהשכרה חודשית. עלויות SUA יחולו רק על שרת בודד, בעוד ששניהם ישודרגו. מאגר קבצים משני של PaperTrail מוגדר באפליקציה כ-WORM (כתוב פעם אחת, קרא הרבה) קבצים.

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

למרות שרצוי ש-PaperTrail ב-Master ייסגר ואז עותק של מאגר מאגר הקבצים יילקח במצב סטטי למערכת המתנה קרה, זה לא הכרח (PaperTrail מספק סנכרון של חנות הקבצים מהראשי ל-Cold Standby. WORM בזמן מקוון).
אחסון קבצי WORM משני מוגדר ב-PaperTrail ב-Master כך שיצביע על המיקום המרוחק
יש להפעיל מחדש את PaperTrail ב-Master כדי לבצע את השינוי ב-File Store
סנכרון מאגר הקבצים פועל מהמאגר הראשי ל-WORM (אופציונלי תלוי בהחלטה שהתקבלה בשלב 1 לעיל)

במקרה של כשל מלא במערכת המאסטר

הגיבוי האחרון של DB מנותק ונבלע במערכת המתנה קרה
רישיון PaperTrail נוסף למערכת Cold Standby
PaperTrail על מערכת Cold Standby מובא באינטרנט
שם השרת Run As עבור מאגר הקבצים WORM משתנה לשם המארח של מערכת Cold Standby
שם השרת ההפעלה של כל עבודות הייבוא ​​האוטומטי משתנה לשם המארח של מערכת המתנה קרה
PaperTrail במערכת Cold Standby מופעל מחדש כדי לבצע את השינוי ב-File Store
יצירת אינדקס של נתונים נבנה מחדש במערכת המתנה קרה
ניתן לעיין במבנה מסד הנתונים המפנה למסמכים ולרשומות דרך החזית הקדמית של PaperTrail. תצוגה מקדימה והורדה של מסמך

חנות הקבצים של WORM תספק אותם
ניתן להעניק גישה לחזית ה-PaperTrail (נשלטת על ידי שינויי DNS למשל)

מקצועני המתנה קרה

נדרש רישיון שרת בלבד עבור מערכת Cold Standby כעלות השכרה חודשית. אין השלכות עלות עבור משתמשים, מודולים או SUA
הגדרה פשוטה שנבדקה ובוצעה ביסודיות במערכות ייצור LIVE על ידי צוות התמיכה של Egis
אין סיכון הקשור לשכפול של עסקאות, מכיוון שרק מופע בודד של PaperTrail (ו-DB משויך) מקוון בכל עת
אין צורך בבדיקה מקיפה של פיתוח מותאם אישית נוכחי ועתידי ספציפי לשכפול של File Store
מספק בטיחות כשל לשחזור מסמכים שנמחקו בטעות במאסטר. ניתן להגדיר גיבוי DB מתוזמן חוזר ב-PaperTrail, אשר יזרוק לחנות הקבצים הראשית (עם עותק שנשלח גם לחנות WORM). ניתן לשחזר את ה-DB לסביבת PaperTrail נפרדת ולאחר מכן להתחבר לחנות WORM כדי לשחזר מסמכים ולייבא אותם בחזרה ל-Master
מספק לבדיקות DR ישירות על מערכת המתנה הקרה המרוחקת ללא כל השפעה או הפרעה לפעילות הייצור הרגילה
PaperTrail נשלח עם מנגנון בנוי מראש לחיבור דליים של Amazon S3 כחנות קבצים מרחוק מבוססת ענן
PaperTrail נשלח עם מנגנון שנבנה מראש לחיבור מיקומי נתיב UNC כמאגר קבצים מרוחק
חסרונות של המתנה קרה
זמן ההובלה להפעלת מערכת ההמתנה הקרה אינו מיידי
נתונים זמינים רק עד לנקודת הגיבוי האחרון של DB (תלוי בתדירות של לוח הזמנים של גיבוי DB)
יהיה צורך לבנות מחדש את מנוע החיפוש לאינדקס מבוסס הדיסק של PaperTrail לפני שהחיפוש והקישור יפעלו במלואם
אם חומרת המערכת הראשית תהפוך לזמינה שוב, יש צורך בכיבוי של PaperTrail והעתק של מאגר הקבצים בחזרה למאסטר. יש לגבות את ה-DB ממערכת Cold Standby ולהיכנס בחזרה לתוך המאסטר

תיאור גרפי בהמתנה קר – מאסטר אונליין

תיאור גרפי בהמתנה קר – מאסטר לא מקוון

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